Lesson 14 · Web interface design¶

UX and UI¶

Both matter. A perfect UI on a bad UX gives you a beautiful app nobody uses.

Wireframe, mockup, prototype¶

Wireframe — the structure¶

Grey, no colours, no photos, no final fonts. Just rectangles and placeholder text.

The purpose: decide what is on screen and where, without being distracted by looks.

Mockup — the appearance¶

The wireframe + colours, typography, images, real spacing. It looks like the final product but does nothing.

Prototype — the behaviour¶

The mockups linked together, with transitions. It can be clicked and navigated. We build it in lesson 16.

The grid and breakpoints¶

Mobile-first¶

You design for the phone first, then expand. The reasons:

1. Over 60% of web traffic comes from phones.
2. The phone is the harshest constraint — if it fits there, it fits anywhere.
3. Expanding is easier than compressing. A desktop design squeezed onto a phone almost always ends up cluttered.

Standard breakpoints¶

Interface components and their states¶

An interface element is not an image. It has states, and each one must be drawn.

The mandatory states¶

The basic components¶

The touch target¶

On a phone, any element that gets pressed must have at least 44 × 44 px of active area — no matter how small the icon inside it is.

    ┌──────────────┐
    │   ┌──────┐   │   ← active area: 44 × 44
    │   │ icon │   │   ← the icon: 24 × 24
    │   │24×24 │   │
    │   └──────┘   │
    └──────────────┘

Accessibility in interfaces¶

On top of the contrast from lesson 03:

Handoff — what you give the developer¶

A badly handed-over design costs more time than doing it properly would have taken.

What the developer receives¶

Dev Mode¶

Figma has a dedicated mode (the toggle at the top right). A developer with access sees:

• Dimensions, spacing and colours as CSS, directly copyable
• Style and component names
• Distances between elements, measured automatically
• Assets to download

The cases everyone forgets¶

Draw them, even if they look boring:

Exercises¶

Exercise 1 — Flow and wireframe¶

Write the flow in words for "a visitor wants to see the details of a club project", then draw the wireframes of the screens, at 390 px wide.

┌────────────────────┐
│ ☰   Logo        🔍 │  ← header, 56 px
├────────────────────┤
│ Projects           │  ← page title
│                    │
│ ┌────────────────┐ │
│ │ ╲╱  Title      │ │  ← card: image + title + tag
│ │ ╱╲  ▬▬▬▬ ▬▬    │ │
│ └────────────────┘ │
│ ┌────────────────┐ │
│ │ ╲╱  Title      │ │
│ │ ╱╲  ▬▬▬▬ ▬▬    │ │
│ └────────────────┘ │
└────────────────────┘

Exercise 2 — One form field, every state¶

Draw a labelled text field in all six mandatory states. Check the contrast of each.

Exercise 3 — The same screen at three widths¶

Take the list screen from exercise 1 and draw it at 390, 768 and 1440 px. Note exactly what changes at each threshold.

Mini-project: the club's project page¶

Design three screens of a website for the computer science club — the home page, the project list and a single project page — at all three breakpoints, using the visual identity from lesson 12.

Summary¶

• UX = what the user can do; UI = how it looks and behaves.
• Write the flow in words before drawing a screen.
• Wireframe (structure, grey, 15 minutes) → mockup (appearance) → prototype (behaviour).
• Mobile-first: 390 → 768 → 1440 px; 4 → 8 → 12 columns.
• Every component has 6 states: default, hover, focus, active, disabled, loading.
• The focus outline is never removed.
• Minimum touch target: 44 × 44 px.
• Contrast: 4.5:1 text, 3:1 interactive elements.
• The label sits above the field; a placeholder is not a label.
• Handoff = a Figma link + components with states + 3 breakpoints + assets + the edge cases.

Next step: → Lesson 15: Visual identity for the computer science club