Wireframes and Visual Hierarchy

Introduction

This is lesson 2 of chapter 7, aligned with course 7 of the Meta Front-End Developer pathway ("Principles of UX/UI Design", domain ux-ui). In the previous lesson, research told you what Harbor Workshops visitors need: see seat availability early, see the total price before the form, and reach the Reserve control easily on a phone. Now you must decide where things go and how much attention each one gets.

This lesson teaches the tools that turn requirements into a layout: sketches, wireframes, and prototypes, followed by the principles that make a screen readable: visual hierarchy, grouping, spacing, alignment, typography, color, and consistency. It ends with a bridge to code: how a design becomes components, tokens, and responsive CSS. The scenario is original, and you do not need design software; paper or any simple drawing tool is enough.

Learning objectives

By the end of this lesson you can:

1. Distinguish sketches, wireframes, mockups, and prototypes, and choose the right fidelity for a question.
2. Draw a low-fidelity wireframe for a mobile-first page from requirements.
3. Apply visual hierarchy using size, weight, color, contrast, position, and whitespace.
4. Use Gestalt principles (proximity, similarity, alignment, common region) to group content.
5. Choose a readable type scale, line length, and spacing system.
6. Use a consistent color system and a small set of reusable components.
7. Translate a design into layout structure, design tokens, and responsive rules.

1. From idea to interface: levels of fidelity

Work from low to high fidelity. Wireframes are deliberately plain so people discuss structure and priorities, not whether a shade of blue is pretty. Changing a box on paper costs seconds; changing a coded page costs hours.

Mobile first

Start with the smallest screen. A narrow viewport forces you to decide what really matters: one column, the most important content first, large touch targets. You then add layout for larger screens (two or three columns, side panels). This matches how you will write CSS, with base styles for small screens and @media (min-width: …) rules to enhance.

2. Drawing a wireframe

A wireframe uses boxes, lines, and labels. Convention helps: a box with an X or a gray rectangle for an image, horizontal lines for text, rounded rectangles for buttons.

Requirements from research (workshop list page):

1. Show date, price, and seats left on every card.
2. Make filters by date and category easy to reach.
3. Make Reserve reachable by keyboard, screen reader, and thumb.

A text wireframe of the mobile page:

+--------------------------------+
| [Logo]                  [Menu] |   header
+--------------------------------+
| Find a workshop                |   page title (h1)
| [ Search...................]   |
| [Date v] [Category v]          |   filters, one row
+--------------------------------+
| +----------------------------+ |
| | [image 16:9]               | |
| | Wheel pottery              | |   card title (h2)
| | Sat 14 Mar, 10:00          |
| | 3 seats left     EUR 35    |   key facts together
| | [ Reserve ]                |   primary action
| +----------------------------+ |
| +----------------------------+ |
| | ... next card ...          | |
+--------------------------------+

Notes on decisions: the key facts (date, seats, price) sit close together under the title because research said these drive decisions; the primary action is the only filled button, placed at the card bottom where a thumb reaches; filters stay above the list so users see them before scrolling.

On desktop the same content may become a three-column grid of cards with the filters in a left sidebar. The order in the HTML stays logical (header, filters, list) because that order is also what a keyboard and a screen reader follow.

3. Visual hierarchy

Visual hierarchy is the arrangement of elements so that viewers see the most important thing first, then the next. It guides the eye and reduces effort. Users scan pages rather than reading them, usually in an F or Z shape, so you must signal priority.

Tools of hierarchy

Use only as many emphasis levels as needed. If everything is bold, red, and large, nothing stands out. A good test is the squint test: blur your eyes or the screenshot; you should still see the page title, the primary action, and the groups.

One primary action per view

Each screen should have one clearly dominant action, such as "Reserve". Secondary actions (such as "Details") use a quieter style, such as an outlined or text button. Destructive actions (such as "Cancel booking") should look distinct and require confirmation.

4. Grouping and layout principles

The Gestalt principles explain how people perceive groups. They give you reasons for layout decisions.

Grid and spacing

Use a grid (for example 12 columns on desktop, 4 on mobile) and a spacing scale built on a base unit, such as 4 or 8 pixels: 4, 8, 16, 24, 32, 48. Choosing from a short list instead of arbitrary values produces rhythm and consistency, and makes CSS easier to maintain.

Whitespace

Whitespace (empty space) is not wasted space. It improves comprehension by separating groups, and it makes interfaces look calmer. Dense pages may be right for expert tools, but for a booking site aimed at busy people, generous spacing helps.

5. Typography

Text is most of the interface, so typography is a core design skill.

• Type scale: pick a small set of sizes with a consistent ratio, for example 14, 16, 20, 24, 32 px, rather than inventing sizes screen by screen.
• Body size: 16 px (1rem) is a common minimum for body text on the web. Use relative units (rem) so users who increase their default font size are respected.
• Line length: aim for roughly 45 to 75 characters per line in text columns; use max-width: 65ch for articles.
• Line height: 1.4 to 1.6 for body text improves readability.
• Font choice: limit yourself to one or two families. Use weight and size, not many typefaces, to create hierarchy.
• Alignment: left-align paragraphs in left-to-right languages. Centered long text is harder to read.
• Contrast: text needs sufficient contrast with its background (covered in the next lesson).

:root {
  --font-body: system-ui, -apple-system, 'Segoe UI', Roboto, sans-serif;
  --text-sm: 0.875rem;
  --text-md: 1rem;
  --text-lg: 1.25rem;
  --text-xl: 1.5rem;
  --text-2xl: 2rem;
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 1rem;
  --space-4: 1.5rem;
  --space-5: 2rem;
}

body { font-family: var(--font-body); font-size: var(--text-md); line-height: 1.5; }
h1 { font-size: var(--text-2xl); }
h2 { font-size: var(--text-xl); }
.prose { max-width: 65ch; }

6. Color

Color supports hierarchy and meaning, but should never be the only way to carry meaning (a point developed in the next lesson).

• Build a palette with: one primary (brand and main actions), one or two neutrals (text and backgrounds), and semantic colors (success, warning, error, information).
• Use the 60-30-10 rule as a starting guide: about 60% neutral background, 30% secondary surface or text, 10% accent.
• Keep accents for actions and key information. If everything is colorful, hierarchy is lost.
• Check contrast between text and background, and consider dark mode as a second set of values.
• Note cultural meanings of color, such as red for danger in many contexts but luck in others.

7. Consistency, components, and design systems

Consistency lowers the learning effort: once users learn that a blue filled button is the main action, they expect it everywhere. Two types matter:

• Internal consistency: the same patterns inside your product.
• External consistency: following conventions of the wider web (a logo links home, a magnifier means search, underlined text means a link).

A design system collects reusable parts: colors, type scale, spacing, components (button, card, input, alert), and usage rules. Even a small project benefits from a mini system. In React this maps naturally to the code you already know:

function Button({ variant = 'primary', children, ...props }) {
  return <button className={`btn btn--${variant}`} {...props}>{children}</button>;
}

.btn { padding: var(--space-2) var(--space-4); border-radius: 0.5rem; font-weight: 600; min-height: 44px; }
.btn--primary { background: var(--color-primary); color: var(--color-on-primary); border: 0; }
.btn--secondary { background: transparent; color: var(--color-primary); border: 2px solid currentColor; }

The min-height: 44px gives a comfortable touch target. Common guidance suggests at least 44 by 44 CSS pixels for touch, while WCAG 2.2 sets a minimum of 24 by 24 pixels at level AA, as the next lesson explains.

Responsive layout for the card grid

.card-grid {
  display: grid;
  gap: var(--space-4);
  grid-template-columns: 1fr;                /* mobile first: one column */
}
@media (min-width: 48rem) {
  .card-grid { grid-template-columns: repeat(2, 1fr); }
}
@media (min-width: 72rem) {
  .card-grid { grid-template-columns: repeat(3, 1fr); }
}

Alternatively, grid-template-columns: repeat(auto-fill, minmax(18rem, 1fr)) makes a grid that adapts without breakpoints.

Worked example: improving a cluttered booking card

Problem. The first draft of a Harbor Workshops card shows: title, date, price, seats left, instructor, a 40-word description, three tags, a heart icon, and two buttons ("Details" and "Reserve") of equal style. In testing, three of five participants hesitate for several seconds and one taps "Details" when they meant to reserve. Redesign the hierarchy.

Reasoning, step by step.

1. Identify the decision-driving facts from research: date, seats, price. They must be visible at a glance.
2. Rank all elements: Level 1: title, Reserve. Level 2: date, seats, price. Level 3: instructor, tags. Level 4: description (move to the detail page).
3. Apply tools: title in the largest weight; Reserve as the single filled button; "Details" becomes a text link under the title; date, seats, and price share one row using the same small size and semi-bold weight; instructor and tags in lighter, smaller text.
4. Reduce: remove the description from the card; keep tags to one or two, or move them to filters.
5. Check spacing and touch: 16 px between groups, 8 px inside groups, buttons at least 44 px high with space between them.
6. Verify: run the squint test, then repeat the five-person test.

Solution. A card with a clear order: title, facts row, Reserve button, with a secondary "Details" link. Participants identify the primary action quickly and the accidental taps stop.

Why other choices are weaker.

• Making both buttons larger and colored gives two competing primary actions.
• Adding borders around every element creates visual noise; proximity and spacing group content more cleanly.
• Shrinking the text to fit more hurts legibility and accessibility.

Common pitfalls and exam tips

• Everything shouting. Overusing bold, color, and size removes hierarchy.
• Decoration over function. Style should support tasks, not distract from them.
• Designing desktop first. The mobile layout is then cramped and unplanned.
• Fixed pixel font sizes. They ignore user settings; prefer rem.
• Inconsistent spacing. Random values make pages look unfinished; use a scale.
• Low-fidelity confusion. A wireframe is for structure; do not debate colors there.
• Exam tip: match tools to purposes: proximity and common region = grouping; size, weight, contrast = emphasis; prototype = testing interaction; wireframe = structure.

Mini case study: the event calendar page

A neighborhood association has an events page with ten sections of equal size, three font families, red used for both "Today" labels and error messages, and a "Register" link styled like body text. Volunteers say they miss events and cannot find how to register.

Tasks. Name four problems and give a specific fix for each.

Commented solution.

1. No hierarchy (equal-sized sections): make the next upcoming event larger or place it first, and use a clear heading level structure.
2. Too many typefaces: reduce to one family and use size and weight for emphasis, which also speeds loading.
3. Color with two meanings: red now signals both "today" and "error". Reserve red for errors and use a distinct, non-error accent for today's events, and add text so color is not the only signal.
4. The primary action looks like plain text: style "Register" as the one filled button per event, with a visible focus style and a target at least 44 px high.

Key terms

• Wireframe: a low-fidelity layout sketch showing structure and priorities.
• Prototype: an interactive model used to test a flow.
• Visual hierarchy: arrangement that signals the order of importance.
• Gestalt principles: rules describing how people group visual elements.
• Whitespace: empty space that separates and emphasizes.
• Type scale: a consistent set of font sizes.
• Design token: a named design value, such as a color or a space unit.
• Design system: reusable components, tokens, and rules.
• Mobile first: designing and coding for small screens before large ones.

Summary checklist

• I choose sketch, wireframe, mockup, or prototype according to the question.
• I draw mobile-first wireframes from research requirements.
• I use size, weight, contrast, position, and whitespace to create hierarchy.
• I apply proximity, similarity, common region, and alignment to group content.
• I use a type scale, rem units, readable line length, and line height.
• I keep a small palette and never rely on color alone.
• I define tokens and reusable components for consistency.
• I build responsive layouts with CSS Grid or Flexbox.

Official sources

• Meta Front-End Developer Professional Certificate (opens in a new tab)
• Course 7: Principles of UX/UI Design (opens in a new tab)
• MDN: Responsive design (opens in a new tab)
• MDN: CSS grid layout (opens in a new tab)
• web.dev: Learn Design (opens in a new tab)
• Figma Help Center (opens in a new tab)