All the reading

UI/UX

7 lessons, about 30 minutes. The check's questions come from these.

Screen hierarchy and focus

1. Make one screen understandable

4 min

Key point

One screen, one job

A good screen makes one job obvious. The user should know where they are, what matters most, and what to do next.

Before you polish colours or fonts, decide the screen’s primary action. Everything else should support it or move lower.

Start with a 5-second read

Open one screen from your project. Show it to a friend for 5 seconds. Then hide it and ask: what is this screen for, and what would you tap first?

If they cannot answer, the screen has a hierarchy problem. This is common in hackathon apps because teams add features fast and give every element equal weight.

Your to-do

Build the hierarchy

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name the screen in one short title, like “Track expenses” or “Find blood donors”.
Choose one primary action, like “Add expense”, “Request donor”, or “Generate summary”.
Place the primary action where it is easy to notice without hunting.
Group related details together instead of scattering cards, buttons, and stats.
Move secondary actions lower, smaller, or behind a menu if they are not needed first.

0 of 5 done

Common mistake

Equal weight breaks clarity

Spacing and type systems

2. Fix spacing and alignment

4 min

Key point

One spacing rule

Things that belong together should sit close together. Things that are different should have more space between them.

This is how a user understands your screen before reading every word.

Why it matters

A hackathon app often has many pieces: forms, cards, filters, buttons, charts, and status text. If every gap is random, the screen feels messy even when the code works.

Good spacing helps recruiters and judges scan your work fast. They can see what is primary, what is secondary, and what action to take next.

Your to-do

Use a spacing scale

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Colour and UI copy

4. Use colour with contrast

4 min

Key point

Remember this

Colour should make your screen clearer, not just prettier. If text, buttons, and status messages are hard to read, your UI fails even if the palette looks good.

Start with roles

Do not pick random colours screen by screen. Give each colour a job.

For a hackathon app, you usually need background, surface, text, muted text, primary action, success, warning, and error. Keep it small so your screens feel connected.

Your to-do

Build a palette

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Choose one main brand colour for primary buttons and links.
Choose neutral colours for background, cards, borders, and text.
Choose status colours for success, warning, and error.
Test colours on real screens, not only in a palette generator.
Remove colours that do not have a clear job.

0 of 5 done

States and submission proof

5. Design empty and error states

5 min

Key point

The core idea

A state is part of the interface, not an afterthought. Empty and error states should help the user continue without guessing.

For your hackathon app, this matters in flows like login, search, payments, form submission, dashboards, bookings, and uploaded files.

Empty is useful

An empty state appears when there is no data yet. A new user has no notes. A search has no results. A hostel complaint app has no complaints filed yet.

Do not leave a blank box. Tell the user what is missing, why it is normal, and what they can do next.

Your to-do

Build an empty state

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

10 questions, 7 to pass.

Example

Screen audit file

Use a small note file before editing the UI. This helps your team agree quickly, even if you are building in React, Flutter, or plain HTML.

Keep it in your repo so reviewers can see that your design choices were intentional.

screen-audit.md

Screen: Student budget dashboard
User goal: Check spending and add a new expense
Primary action: Add expense
Most important info: This month’s remaining budget
Secondary info: Recent expenses, category split
Remove or move lower: Export CSV, settings, old alerts
5-second test result: Friend noticed remaining budget, but tapped category split first
Fix: Make Add expense the only primary button and move category split below recent expenses

Tip

Use AI for critique

You can ask ChatGPT, Gemini, or Claude to review a screenshot. Do not ask for a redesign first. Ask what the screen’s main action appears to be.

Check the answer against your real goal. If the AI guesses wrong, a recruiter or judge may also miss it.

Prompt:
Look at this app screen as a first-time user.
1. What do you think this screen is for?
2. What is the first action you would take?
3. Which elements compete for attention?
Keep the answer short and practical.

Example

Tailwind example

This card uses repeated spacing values. The title, text, input, and button share one left edge. The button is not floating randomly.

Use the same idea in React, Next.js, plain HTML, Flutter, or Figma.

<div className="max-w-md p-6 space-y-6 rounded-xl border bg-white">
  <div className="space-y-2">
    <h2 className="text-xl font-semibold">Create study group</h2>
    <p className="text-sm text-gray-600">
      Add your college, subject, and preferred time.
    </p>
  </div>

  <div className="space-y-4">
    <label className="block space-y-1">
      <span className="text-sm font-medium">Subject</span>
      <input className="w-full rounded-md border px-3 py-2" />
    </label>

    <button className="w-full rounded-md bg-black px-4 py-2 text-white">
      Create group
    </button>
  </div>
</div>

3. Choose readable type

5 min

Key point

One idea

Readable type is not about fancy fonts. It is about size, spacing, weight, and consistency.

Use fewer text styles, make body text comfortable, and make headings clearly different from normal text.

What readable means

A recruiter may open your project on a laptop. A judge may check it on a phone in a noisy hall. Your text has to work in both places.

For most app screens, start with 16px body text. Use 20px to 24px for section headings. Use 28px to 32px only for main page titles.

Your to-do

Set a type scale

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Pick one font family for the whole app.
Set body text to 16px or 1rem.
Set line height around 1.5 for paragraphs and descriptions.
Use 2 to 4 font weights only, such as regular, medium, semibold, and bold.
Save these as reusable styles, classes, or design tokens.

0 of 5 done

Common mistake

Many hackathon UIs use tiny grey text because it looks clean in a screenshot. It becomes hard to read on a phone, especially outdoors or in a crowded college venue.

Do not use 12px for important labels, inputs, errors, or button text. Keep small text for helper notes only, and check contrast in the next lesson.

Example

Simple CSS setup

You can define a small type system once and reuse it across your screens. This is enough for most hackathon apps.

Use class names that describe purpose, not appearance. Later, if you change sizes, your screens stay easier to maintain.

/* styles.css */
:root {
  font-family: Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

body {
  font-size: 16px;
  line-height: 1.5;
}

.page-title {
  font-size: 32px;
  line-height: 1.2;
  font-weight: 700;
}

.section-title {
  font-size: 22px;
  line-height: 1.3;
  font-weight: 600;
}

.body-text {
  font-size: 16px;
  line-height: 1.5;
  font-weight: 400;
}

.helper-text {
  font-size: 14px;
  line-height: 1.4;
  font-weight: 400;
}

.button-text {
  font-size: 16px;
  line-height: 1;
  font-weight: 600;
}

Tip

Use AI carefully

You can ask ChatGPT or Gemini to create a type scale for your app. Give it your app type, target device, and framework.

Check the result yourself. Remove extra font sizes. Make sure body text is at least 16px and that headings are clearly larger than body text.

Prompt:
I am building a mobile-first hackathon app for college students in India.
Create a simple readable type scale for React CSS.
I need styles for page title, section title, body text, helper text, input labels, errors, and buttons.
Use only 4 font sizes and 3 font weights.

Check real screens

Do not judge type only inside Figma or your code editor. Run the app and read it like a user.

Open three working screens. Can you scan the title first, then the important action, then the details? If everything feels equally loud, reduce weights and sizes.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your project on a phone-sized screen in the browser.
List every font size used on your three main screens.
Replace random sizes with 4 to 6 reusable text styles.
Set body, input, button, and error text to readable sizes.
Commit the change with a message like "Set readable type scale".

0 of 5 done

Example

Token example

Store colours as tokens in code. This makes your React, Next.js, or plain CSS project easier to keep consistent across screens.

Here is a simple CSS file for a student event app.

:root {
  --color-bg: #F8FAFC;
  --color-surface: #FFFFFF;
  --color-text: #0F172A;
  --color-muted: #475569;
  --color-border: #CBD5E1;

  --color-primary: #2563EB;
  --color-primary-text: #FFFFFF;

  --color-success: #15803D;
  --color-warning: #B45309;
  --color-error: #B91C1C;
}

body {
  background: var(--color-bg);
  color: var(--color-text);
}

.card {
  background: var(--color-surface);
  border: 1px solid var(--color-border);
}

.button-primary {
  background: var(--color-primary);
  color: var(--color-primary-text);
}

.error-text {
  color: var(--color-error);
}

6. Write clear UI copy

4 min

Key point

One job per line

Good UI copy tells the user what this thing is, what just happened, or what to do next. It should reduce thinking, not decorate the screen.

Where copy matters

In a hackathon app, recruiters and judges scan fast. They should not need you standing next to the laptop to explain every button.

Focus on high-impact places: screen titles, form labels, button text, empty states, error messages, confirmation messages, and navigation labels.

Your to-do

Write useful buttons

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Start with a verb: Save, Pay, Join, Upload, Book, Create.
Say the result, not the component: Use “Create team” instead of “Submit”.
Match the user’s goal: Use “Pay ₹199” instead of “Continue” when payment is next.
Keep primary button copy to 2 to 4 words when possible.
Use the same label for the same action across all screens.

0 of 5 done

Common mistake

Do not blame users

Bad error copy sounds like a scolding: “Invalid input” or “You entered wrong data”. Good error copy explains the problem and the fix.

If your app can detect the issue, say exactly what is missing. If it cannot, give a safe next step.

Example

Before and after

Here is a simple copy pass for a student project submission form. Notice how every line helps the user move forward.

Screen title
Before: Details
After: Submit your project

Label
Before: Link
After: Public GitHub repository link

Helper text
Before: Enter valid link
After: Paste a public repo URL, like https://github.com/name/project

Primary button
Before: Submit
After: Submit project

Error
Before: Invalid URL
After: Use a public GitHub link that starts with https://github.com/

Empty state
Before: No data
After: No projects submitted yet. Submit your first project to get feedback.

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to rewrite UI copy. Give it your screen goal, user type, and current text.

Check that the output is short, clear, and true. AI often makes copy sound too formal or promises something your app does not do.

Prompt:
Rewrite this UI copy for a college hackathon project app.
User: student builder in India.
Goal: submit a project for review.
Tone: clear, short, friendly, not salesy.
Keep button labels under 4 words.

Current copy:
Title: Details
Button: Continue
Error: Invalid
Empty state: Nothing here

Your to-do

Copy checklist

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Replace “Submit”, “Next”, and “Continue” when a clearer action exists.
Make every error answer two questions: what went wrong, and how do I fix it?
Use normal words your college friends would understand.
Remove extra words like “kindly”, “please note”, “successfully done”, and “dear user”.
Read the screen aloud once to catch awkward or confusing text.

0 of 5 done

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open three main screens or flows in your project.
List every title, label, button, empty state, and error message.
Rewrite unclear buttons with action plus result, like “Create team”.
Rewrite errors so they explain the fix, not just the failure.
Commit the copy changes to your public repository.

0 of 5 done

Example

React example

This example handles three states for a simple events list: loading, empty, and error. You can adapt the same pattern for jobs, notes, complaints, expenses, or team members.

Keep the button copy specific. “Try again” is better than “Submit” after a failed load.

function EventsList({ loading, error, events, onRetry, onCreate }) {
  if (loading) {
    return <p className="status">Loading events...</p>;
  }

  if (error) {
    return (
      <section className="state state-error" role="alert">
        <h2>Could not load events</h2>
        <p>Check your connection and try again.</p>
        <button onClick={onRetry}>Try again</button>
      </section>
    );
  }

  if (events.length === 0) {
    return (
      <section className="state">
        <h2>No events added yet</h2>
        <p>Create your first event so students can register.</p>
        <button onClick={onCreate}>Add event</button>
      </section>
    );
  }

  return (
    <ul>
      {events.map((event) => (
        <li key={event.id}>{event.name}</li>
      ))}
    </ul>
  );
}

Tip

Use AI carefully

Ask ChatGPT, Gemini, or Claude for empty and error copy for each screen. Give it your app idea, user type, and action.

Then check three things yourself: is it specific, does it tell the user what to do next, and is it short enough for a phone screen?

Prompt:
I am building a hackathon app for college students to split canteen expenses.
Write empty states and error messages for these screens:
1. No groups yet
2. No expenses in a group
3. Failed to add expense
4. Invalid UPI ID
Keep each message short and include a clear next action.

7. Submit your designed project

4 min

Key point

Proof beats polish

Your submission should prove that a user can understand and use the app. Do not only say what the app does. Show the screens and states that make it usable.

What to submit

Pick at least 3 working screens or flows from your project. A flow can be login to dashboard, search to results, or add item to confirmation.

Each chosen screen should show the design work from this track: hierarchy, spacing, readable type, contrast, empty or error states, and clear UI copy.

Your to-do

Check your screens

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open the app on your phone or a narrow browser width.
Check that the main action is easy to find without explaining it.
Check that text is readable at normal zoom.
Trigger one empty state and one error state if your app has them.
Fix unclear button labels like Submit, OK, or Click here.

0 of 5 done

Example

README proof section

Add a small section like this to your public repo README. It helps judges, mentors, and recruiters review your work fast.

## Interface design proof

Project: Campus Lost and Found

Working screens / flows:
1. Home to item details
   - Clear main action: "Report found item"
   - Cards use consistent spacing and readable titles

2. Search results
   - Empty state shown when no item matches
   - Empty copy: "No items found. Try a different keyword or category."

3. Report item form
   - Error state shown for missing photo
   - Error copy: "Add a photo so others can identify the item."

Design checks:
- Main headings are larger than body text
- Buttons have visible contrast against the background
- Form labels are clear without placeholder-only text
- Screens work on mobile width

Screenshots:
- /docs/screens/home.png
- /docs/screens/search-empty.png
- /docs/screens/report-error.png

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to review your README and screenshot notes. Paste only public details. Ask it to find missing proof, vague labels, and unclear error copy.

Do not accept generic praise. Check if its suggestions match your real screens. If it mentions a screen or feature you do not have, remove it.

Common mistake

Common submission miss

Many teams submit a GitHub link and a demo video, but no design proof. The reviewer then has to guess what improved.

Make it obvious. Name the 3 screens. Mention the empty and error states. Add screenshots in a docs/screens folder or include them in your README.

Your to-do

Final submission check

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Push your latest code to a public repository.
Add screenshots or a short screen recording that shows the 3 screens or flows.
Update the README with the interface design proof section.
Test the public repo link in an incognito window.
Submit the HackIndia project with the repo link and a short design summary.

0 of 5 done

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Choose the 3 screens or flows you will show.
Take one screenshot of each screen or important state.
Create a docs/screens folder in your repo.
Paste the README proof section and edit it for your project.
Write a 2 sentence design summary for your HackIndia submission.

0 of 5 done

UI/UX

1. Make one screen understandable

One screen, one job

Start with a 5-second read

Build the hierarchy

Equal weight breaks clarity

2. Fix spacing and alignment

One spacing rule

Why it matters

Use a spacing scale

4. Use colour with contrast

Remember this

Start with roles

Build a palette

5. Design empty and error states

The core idea

Empty is useful

Build an empty state

Screen audit file

Use AI for critique

Do this now

Random gaps

Align the edges

Use AI lightly

Tailwind example

Do this now

3. Choose readable type

One idea

What readable means

Set a type scale

Common mistake

Simple CSS setup

Use AI carefully

Check real screens

Do this now

Common colour mistakes

Check contrast early

Token example

Use AI carefully

Do this now

6. Write clear UI copy

One job per line

Where copy matters

Write useful buttons

Do not blame users

Before and after

Use AI carefully

Copy checklist

Do this now

Errors need recovery

Common mistake

React example

Use AI carefully

Do this now

7. Submit your designed project

Proof beats polish

What to submit

Check your screens

README proof section

Use AI carefully

Common submission miss

Final submission check

Do this now