Wireframes, Visual Hierarchy, and Figma Prototypes

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's simulated research, Harbor Workshops visitors needed to 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. All research counts and results below are fictional teaching examples. Paper is sufficient for exploring layout here; the official Meta course also teaches wireframes, components, and interactive prototypes in Figma. Practise that tool for its course activities.

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

Choose fidelity to answer the current question, rather than automatically polishing every stage. A plain wireframe can focus discussion on structure and priorities; a prototype can be made from paper, linked frames, or code. Revising a sketch is often cheaper than revising an implemented interaction, but effort depends on the change.

Mobile first

For this exercise, start with a narrow 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 supports base styles for narrow screens and @media (min-width: …) enhancements. Mobile first is a useful approach, not the only valid workflow: every approach still needs explicit narrow-screen, zoom, and content checks.

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, wrap as needed
+--------------------------------+
| +----------------------------+ |
| | [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: key facts stay together under the title, followed by the card's main action. This is a layout hypothesis based on the simulated brief. A bottom-of-card position does not guarantee thumb reach on every device. Let filters and facts wrap or stack at narrow widths and enlarged text sizes; the ASCII drawing is not a fixed-width implementation.

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. Reading and scanning depend on task, layout, language, and user. Signal priority without assuming everyone follows an F or Z pattern.

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 distinguish the page title, primary action, and groups. This is a visual heuristic, not evidence of accessibility or successful task completion.

A clear primary action for each task

Make the next action clear within each task or group. A list can legitimately repeat Reserve on several cards. Give secondary actions a quieter but still readable style. Use links for navigation and buttons for actions, regardless of appearance. For destructive operations, choose confirmation or a reliable undo according to the consequences; confirmation is not necessary for every reversible action.

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: define a small reusable set, such as 14, 16, 20, 24, and 32 px equivalents. These values do not form a fixed mathematical ratio; consistency means applying the same roles across screens.
• Body size: 1rem follows the root font size: often 16 CSS pixels at browser defaults, but not always. Keep the root responsive to user preferences. WCAG does not prescribe a universal 16 px minimum; check the actual font, resizing, and reflow.
• Line length: roughly 45 to 75 characters is a starting heuristic for English prose, not an AA conformance rule. max-width: 65ch limits width using the font's zero-glyph measure, not an exact count of characters.
• Line height: try 1.4 to 1.6 for body text, then check the font and content. WCAG text-spacing requirements concern surviving user overrides; they do not mandate one authored line height.
• 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;
  --color-primary: #0b5cad;
  --color-on-primary: #ffffff;
}

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).
• Treat the 60-30-10 rule as an optional palette heuristic, not a measured usability result or accessibility requirement. Favor a restrained palette that supports the task.
• 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', type = 'button', className = '', children, ...props }) {
  const classes = ['btn', `btn--${variant}`, className].filter(Boolean).join(' ');
  return <button {...props} type={type} className={classes}>{children}</button>;
}

.btn { padding: var(--space-2) var(--space-4); border-radius: 0.5rem; font: inherit; font-weight: 600; min-width: 44px; min-height: 44px; box-sizing: border-box; }
.btn:focus-visible { outline: 3px solid #0b5cad; outline-offset: 2px; }
.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 component preserves added classes and defaults to a non-submitting button; use type="submit" explicitly for form submission. Here variant is primary or secondary, and the supplied palette assumes a white/light surface; check focus and text contrast on every actual background. Both target dimensions use a 44 CSS pixel project goal. WCAG 2.2 AA criterion 2.5.8 uses 24 by 24 CSS pixels with defined exceptions, including spacing; 44 by 44 also appears in the stricter AAA criterion 2.5.5, which has its own exceptions.

Responsive layout for the card grid

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

Alternatively, grid-template-columns: repeat(auto-fill, minmax(min(18rem, 100%), 1fr)) lets tracks adapt without a fixed minimum wider than the container. Allow long content to wrap and images to shrink as well. Review CSS Grid, Flexbox, and responsive breakpoints for the layout implementation.

Build a small Figma prototype

Use the wireframe to practise the official course's prototyping skill:

1. Create top-level frames for the workshop list, booking form, and confirmation. Add a separate error state so the flow is not limited to success.
2. In the Prototype tab, select the Reserve object and connect it to the form frame. Configure a click/tap trigger and a navigation action.
3. Connect the form's confirmation action to the confirmation frame and provide a way back. These connections simulate navigation; they do not submit payment or reserve real seats.
4. Set the list as the starting frame, preview the flow, and check that its links lead to the intended states before a participant session.
5. Document missing behavior, such as real validation, keyboard interactions, and assistive technology support. A clickable visual prototype cannot establish the accessibility of the eventual HTML.

Start with simple transitions so motion does not distract from the task. The next lesson's WCAG 2.2 checks and usability testing explains how to turn this flow into an evaluation plan.

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 the fictional test notes, 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 a group that wraps when needed; instructor and tags have a secondary style that retains readable size and sufficient text contrast.
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, controls with a project target of at least 44 by 44 CSS pixels and space between them.
6. Verify: use the squint test for an initial visual review, then run another task-based round with relevant participants. Look for hesitation and mistaken activation; do not assume a fixed number will uncover every issue.

Solution. A card with a clear order: title, facts row, Reserve button, with a secondary "Details" link. The hypothesis is that users will identify the action more easily; reduced hesitation and mistaken taps must be checked in a new round rather than asserted as observed results.

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 study tips

• Everything shouting. Overusing bold, color, and size removes hierarchy.
• Decoration over function. Style should support tasks, not distract from them.
• Leaving narrow layouts unplanned. Whatever your starting viewport, check small screens, text enlargement, and long content.
• Ignoring text preferences. Pixel-based fonts can still page-zoom, but do not follow browser default-font changes as relative sizes can. rem is helpful when the root size remains user-responsive.
• Inconsistent spacing. Random values make pages look unfinished; use a scale.
• Low-fidelity confusion. A wireframe is for structure; do not debate colors there.
• Study 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 can reduce font downloads if fewer font files are needed.
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 project target at least 44 by 44 CSS pixels. Preserve link semantics when Register navigates to another page.

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.

Sources and further reading

• 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)

• Figma: Connect your prototype (opens in a new tab)

• Figma: Guide to prototyping (opens in a new tab)

• MDN: CSS length units (opens in a new tab)

• MDN: Button behavior (opens in a new tab)

• W3C: Target Size (Minimum) (opens in a new tab)