freedzhost.cloud

Web design module 2: the tools and the rules

Level BeginnerEstimated time 14 hRead first Web design module 1: see like a designerA word you don't know? Glossary

Fourteen sessions to move from the eye to the hand: Penpot, the open-source design tool that runs in the browser, then the rules that make an interface usable by everyone — contrast, targets, focus, plain language, forms, navigation. Each rule is explained first, then applied in a drawing.

Day 15 — Penpot 1/3: the canvas

Goal: create a Penpot file and draw a first simple screen in it.

Theory 1/2: the tool and its objects

Penpot is an open-source interface design tool (MPL 2.0 license) that runs entirely in the browser: create a free account on design.penpot.app, nothing to install. Three objects structure every file: the page (a workbench; a file can hold several), the board (a frame that represents a screen, with a width and a height — the "artboard" equivalent elsewhere), and layers (shapes, texts, images, stacked in the left panel). The central zone, infinite, is the canvas: boards are laid side by side to compare screens. Penpot saves everything continuously: no "save" button.

In Penpot, a "board" is…

  1. a comment on the design
  2. a frame that represents a screen, with its size
  3. a color palette
Answer

The board is the screen: a sized frame (e.g. 1440×900 for desktop) containing the layers.

Theory 2/2: the basic moves

Five moves are enough for today: create a board (frame icon, then click-drag or pick a preset in the right panel), draw a rectangle (R), write a text (T), move pixel by pixel with the arrows (Shift+arrow for bigger steps), and align two objects with the magnetic guides that appear in red while moving. The right panel tunes the selected object: position, size, fill, border, corner radius, shadow. Everything you learned in module 1 — sizes, colors, spacings — is typed there, in numbers, not by eye.

The red lines that appear while moving an object serve to…

  1. align the object on its neighbors or on the board
  2. signal an error
  3. measure a distance in inches
Answer

They are alignment guides: they snap edges and centers, to align without computing.

Practice (30 min)

  1. Create your account on design.penpot.app, then a file "Web design path" and a page "D15".
  2. Create a desktop board (1440×900). Draw a card in it: rectangle with rounded corners (8px), a heading, two lines of text, a button (rectangle + text).
  3. Apply your day 6 palette and your day 4 scale: neutral background, dark text, accent button. Spacings in multiples of 8.
  4. Hover the inspector to check every spacing is 8, 16, 24 or 32.

Success criterion: a drawn, aligned card, every spacing a multiple of 8, every color from your palette.

Agent tip: an agent will not drive Penpot for you, but it prepares your values: "Generate the settings list for a card (sizes, corners, discreet shadow, spacings in multiples of 8) from this palette: [hex]." Trap: it will invent too-strong shadows. Proof: the final shadow stays under 20% opacity, checked in the right panel.

Recap (10 min)

Three lines: page, board, layer; the five moves; why we type numbers. Then redraw the card without notes, on a fresh page.

Day 16 — Penpot 2/3: shared colors and typographies

Goal: centralize colors and text styles in the file's library.

Theory 1/2: why centralize

When a color is typed by hand into ten objects, changing it means ten fixes — and an eleventh forgotten. Penpot, like any serious tool, lets you save a color to the file library (the Assets panel): objects reference it, and editing the library color updates everything. Same principle for typography styles: you save "Body 16/24 Inter regular", "Heading 25/31 Inter bold", and each text applies a style instead of isolated values. It is the design version of the golden rule of code: one piece of information, one single place. On day 35, this habit will take its industry name: design tokens.

We save colors to the library in order to…

  1. make them prettier
  2. export the file faster
  3. change a color once and see it applied everywhere
Answer

One piece of information, one place: the reference is edited, the uses follow.

Theory 2/2: naming to find

A good color name tells its role, not its hue: text-primary, surface-page, accent, accent-hover, error. "Blue-500" becomes useless the day the blue turns green; "accent" stays true. Keep both levels if you like: hues in a "primitive" group (blue/500), roles in a "semantic" group (accent → references the same value). Same discipline for texts: the name tells the use (section-heading), not the look (bold-25px). A well-named library reads like the table of contents of your design.

The best name for the action button color is…

  1. bright-blue
  2. accent
  3. #3B82F6
Answer

accent names the role: it survives a hue change and tells what the color is for.

Practice (30 min)

  1. In your Penpot file, open the Assets panel and save your colors: background, text, accent, darker accent (hover), error, success. Name them by role.
  2. Save four typography styles: small (12-14px), body (16px/1.5), section heading, main heading — all from your day 4 scale, in a Google Fonts typeface (Inter is available in Penpot).
  3. Redo the day 15 card: replace every hand-typed value with the library color or style.
  4. Edit the accent color in the library and check the button follows.

Success criterion: the card holds no isolated value anymore: everything comes from the library, and changing the accent updates it.

Agent tip: "Here is my palette: [hex + roles]. Propose a complete semantic naming (primitives + roles) and flag the missing roles for a form." Trap: it will add roles you have no use for — trim. Proof: every proposed name matches a real element of your mockup.

Recap (10 min)

Three lines: what the library does, naming the role not the hue, the link with day 35's tokens. Then recreate your five colors and four styles from memory.

Day 17 — Penpot 3/3: components

Goal: turn your button into a reusable component, with its states.

Theory 1/2: the component and its copies

A component is an object defined once and reused in as many copies as needed: edit the main component, the copies follow. It is the answer to day 12's question ("same = same look"): instead of copy-pasting a button and praying to forget nothing, you create the "Button" component and place instances. In Penpot: select the group of objects, right-click → "Create component"; it appears in Assets, and dragging from Assets creates a linked copy. Copies keep their own texts — the "Save" label of one copy does not change the others — but shape, colors and spacings stay driven by the main component. Penpot also supports component variants (several versions grouped, like states), a recent addition to the tool.

You change the color of the main "Button" component. The copies…

  1. keep their old color
  2. follow the main component
  3. are deleted
Answer

Copies inherit from the main: that is the whole point. Only contents (texts) stay specific to each copy.

Theory 2/2: drawing the states

Day 13 listed a button's states: rest, hover, focus, active, disabled. In design, each state becomes a version of the component: same geometry, only the fill, outline or opacity changes. Sound conventions: hover = accent one step darker; focus = a 2-3px outline in a color contrasted at 3:1, offset by 2px, as browsers do; disabled = near-zero saturation, never just "a bit paler", or it stays confused with rest. Keep the states side by side on the canvas: identical alignment and spacing between versions show that only color changes.

The focus indicator must…

  1. be visible and contrast at 3:1 with its surroundings
  2. be removed for aesthetics
  3. appear only on click
Answer

WCAG 2.4.7 requires a visible focus, 1.4.11 its 3:1 contrast. Removing it makes keyboard navigation blind.

Practice (30 min)

  1. In Penpot, select your card's button (grouped rectangle + text) and make it a component.
  2. Draw the five states side by side: rest, hover, focus, active, disabled. Name each version (button/rest, button/hover…).
  3. Place three copies of the "rest" state on the board with different labels; check that editing the main component updates the shapes without touching the labels.
  4. Measure your focus outline's contrast against the background (WebAIM): it must reach 3:1.

Success criterion: a "Button" component in Assets, five states drawn, three linked copies, and a focus measured at 3:1 or more.

Agent tip: "Describe the five states of a button as a table: state, properties that change, proposed value from my accent #…" Trap: it will forget active or give a disabled too close to rest. Proof: compare its table to your drawing, and squint at rest/disabled.

Recap (10 min)

Three lines: component vs copy, what stays linked and what stays free, the five states' settings. Then recreate the five states without notes.

Day 18 — The wireframe

Goal: sketch a page in low fidelity, without color or typefaces.

Theory 1/2: low fidelity protects decisions

A wireframe is a page's plan: gray rectangles for images, bars for text, labels for actions. Its poverty is deliberate: without color or typography, nobody argues about the button's blue — the conversation is about what matters at this stage: which information, in which order, with which priority. Changing a structure costs ten minutes in a wireframe, ten hours in a polished mockup. It is also a thinking tool: drawing the page in gray forces you to decide the real content — a real heading, not "lorem ipsum" — before deciding its look.

Why does the wireframe deliberately stay gray and unstyled?

  1. to draw faster, no other reason
  2. so the discussion is about structure and content, not colors
  3. because color is expensive to print
Answer

Low fidelity isolates structural decisions: as long as everything is gray, nobody debates the button's hue.

Theory 2/2: the wireframe vocabulary

Five conventions are enough: a thick bar for a heading, thin bars for text lines, a crossed rectangle for an image or video, a filled rectangle with a label for a button, and margin annotations for what the drawing cannot say ("this menu opens on click"). Work at the most constraining size first — mobile — because content that fits in 375px wide fits everywhere (more on day 30). The question to ask for each block, in order: is it necessary? is it in the right place? is it the right relative size?

In a wireframe, an image is represented by…

  1. a rectangle with a diagonal cross
  2. a blurred photo
  3. a black square
Answer

The crossed rectangle: universal, it says "visual here" without distracting.

Practice (30 min)

  1. Pick the home page of a site you know well. List its blocks in vertical order in the notebook (banner, hero, three arguments, testimonial, footer…).
  2. In Penpot, create a mobile board (375×812) and redraw that page as a wireframe: bars, crossed rectangles, buttons. No color, no styled typeface.
  3. Check: every action is a labeled button, every text has its approximate real length, the block order follows day 10's hierarchy.

Success criterion: a complete, gray mobile wireframe where each block answers the three questions (necessary, place, relative size).

Agent tip: "Here is my page's ordered block list: [paste]. Critique the order from the viewpoint of a visitor discovering the service, and propose one single improvement." Trap: it cannot see your drawing — describe the blocks, not your intentions. Proof: every critique cites the block and the visitor concerned.

Recap (10 min)

Three lines: what low fidelity protects, the five conventions, the three questions per block. Then redo the wireframe on paper, without notes.

Day 19 — From wireframe to mockup

Goal: apply palette, scale and spacings to your wireframe to make it a mockup.

Theory 1/2: one rule at a time

The mockup (high fidelity) is the dressed wireframe. The passage happens in layers, never all at once: typography first (apply the library styles to every text), then color (background, texts, accent — the 60-30-10 distribution), then spacings (everything in multiples of 8), and finally details (corners, borders, discreet shadows, states). This order has a reason: each layer can break the previous one if touched later — a text changing size overflows, an accent applied too early scatters. Working in layers also lets you step back one level without losing everything.

In the wireframe → mockup passage, which layer comes first?

  1. shadows
  2. color
  3. typography
Answer

Typography: text sizes set the dimensions of everything else. Color next, spacings, details.

Theory 2/2: real content, always

The mockup is drawn with real content — the real headings, the real labels, a plausible text length. "Lorem ipsum" hides problems: it has an even density real prose lacks (long labels, accented words, capitals), and it spares you from deciding what the page must say. Practical rule: if the final content does not exist yet, write it yourself, however imperfect — a mockup with a mediocre real heading teaches more than one with perfect fake Latin. This is also the time to test the limits: the longest expected heading, the longest user name, the empty list. A design that only survives ideal content is not finished.

Why ban lorem ipsum from a mockup?

  1. because Latin is old-fashioned
  2. because an even fake text hides overflows and spares you from deciding the content
  3. because it costs money
Answer

Real content reveals real lengths and real choices. Lorem ipsum postpones both to development day — the worst moment.

Practice (30 min)

  1. Duplicate the day 18 wireframe onto a new board (same structure, same order).
  2. Apply the layers in order: library typography styles, then library colors (60-30-10), then spacings in multiples of 8, then 8px corners and a discreet shadow on the card if there is one.
  3. Replace all fake text with real content written by you; test the longest plausible heading.
  4. Final squint test: is the hierarchy that pops the one you wanted?

Success criterion: a finished mobile mockup, 100% library (colors and styles), real content, squint test matching the intended hierarchy.

Agent tip: describe your mockup block by block with its values: "Check my 60-30-10 distribution and my size hierarchies; flag anything outside my scale." Trap: it will politely approve if you do not ask for gaps. Demand: "list every value that is not in my scale, one per line". Proof: cross-check one reported gap in Penpot.

Recap (10 min)

Three lines: the layers' order, why real content, what the squint test checks. Then redo the layered passage on a small block without notes.

Day 20 — Setting a grid in Penpot

Goal: equip a desktop board with a 12-column grid and align a mockup on it.

Theory 1/2: the tool's grid

Day 11 explained the 12-column grid; Penpot makes it concrete: select a board, and in the right panel, the "Guides" (or "Grid") section lets you add a column grid — count, gutter, margins. Sound starting settings for a 1440px board: 12 columns, 24px gutter, 80 to 120px side margins, leaving a working width around 1200px. The grid shows or hides, it never exports: it is a drawing aid, not a design element. Once set, every block of the mockup starts and ends on column boundaries; gutters never hold content.

A grid's gutter…

  1. never holds content
  2. hosts small texts
  3. is always 10px
Answer

The gutter is the separation between columns: placing content in it breaks the whole grid's alignment.

Theory 2/2: desktop versus mobile

On desktop, the grid multiplies side-by-side blocks (three cards of 4 columns). On mobile, a single content column: blocks stack. The mobile grid is therefore simpler — often 4 columns that mostly set the side margins (16 to 24px) — and the real work is the stacking order: what was side by side must follow in an order that respects the hierarchy. Rule: the mobile vertical order follows importance, not desktop position. A "call to action" panel placed on the right on desktop often comes before secondary content on mobile.

On mobile, the blocks' stacking order follows…

  1. their left-right position on desktop
  2. their importance for the user
  3. their size
Answer

Importance: in a single column, the reading order is the hierarchy made literal.

Practice (30 min)

  1. Create a desktop 1440×900 board and set the grid: 12 columns, 24px gutter, 96px margins.
  2. Adapt the day 19 mobile mockup to desktop: same content, but blocks align on the columns (e.g. text over 7 columns, visual over 5; or three cards of 4).
  3. Check every edge: it starts and ends on a column boundary. No content in gutters or margins.
  4. Hide then show the grid: the page must stay aligned without it.

Success criterion: a desktop mockup with every edge on the grid, same hierarchy as the mobile version.

Agent tip: "For a 1440px board, 12 columns, 24px gutter, 96px margins, compute the column width and the width of 4 columns + 3 gutters." Trap: it may round without saying. Proof: the column is (1440 − 192 − 11×24) ÷ 12 = 74px, redo the math by hand.

Recap (10 min)

Three lines: the desktop grid settings, the gutter rule, the mobile stacking order. Then recompute the column width without notes.

Day 21 — Flex layout

Goal: build a component whose spacings hold when content changes.

Theory 1/2: boxes that adapt

In a "free" drawing, lengthening a heading shifts everything by hand. Penpot's Flex layout (the equivalent of the browsers' flexbox, and of Figma's auto-layout) makes a box smart: its children line up in a row or a column, with a constant gap between them and a constant padding around them. Lengthen the heading, the button shifts; add a line, the card grows — day 8's spacings become properties of the box, not frozen distances. It is also what brings design closer to development: the mockup describes rules (gap of 16, padding of 24), exactly like the CSS that will build it.

The main benefit of Flex layout is…

  1. prettier drawing
  2. lighter image exports
  3. spacings that hold when content changes
Answer

Gap and padding are rules of the box: content changes, spacings hold.

Theory 2/2: the settings that matter

Five settings cover the essentials: direction (row or column), the gap between children, the padding on the four sides, the alignment (start, center, space-between) and each child's sizing behavior: fixed (it keeps its size), fill (it takes the available room) or fit content (it adjusts to what it holds). A typical product card: column direction, gap 12, padding 24, image on "fill" for width, texts on "fit content". The classic trap is leaving everything fixed: the component turns rigid again and Flex layout is useless.

A button whose width must follow its label is set to…

  1. fixed
  2. fit content
  3. fill
Answer

"Fit content": the box hugs the label, plus padding. "Fixed" breaks at the first long label, "fill" stretches the button to full width.

Practice (30 min)

  1. In Penpot, rebuild the day 15-16 card in Flex layout: select the board or group, enable "Flex layout" in the right panel, column direction.
  2. Set: gap 12 or 16, padding 24, button on "fit content", heading and text on "fill" width.
  3. Robustness test: double the heading length, then change the button label to "Discover the complete collection". The spacings must hold on their own.
  4. Duplicate the card into three copies inside a Flex layout row (gap 24): the three cards align with no manual adjustment.

Success criterion: the card survives the long heading and long label with no manual fix, and three copies align by the gap rule alone.

Agent tip: "Here is my card's structure (image, heading, text, button) and my gap values. Tell me which flex settings (direction, alignment, children sizing) you would pick, and why." Trap: it will describe CSS — translate to Penpot's settings, which carry the same names. Proof: apply and run the long-heading test.

Recap (10 min)

Three lines: what Flex layout replaces, the five settings, the three sizing behaviors. Then rebuild the flexible card without notes.

Day 22 — Accessibility 1/3: for whom, what for

Goal: understand what accessibility covers and what the WCAG standard requires.

Theory 1/2: accessibility concerns everyone

Designing accessible means designing for varied abilities: visual impairments (color blindness, low vision, blindness — about 2 billion people live with a vision impairment according to the WHO), motor (keyboard or voice navigation), hearing (captions), cognitive (plain language, consistency). But disability is often temporary or situational: an arm in a sling, a screen in full sunlight, a slow connection, fatigue, a foreign language. Microsoft sums this up in its Inclusive Design: disability is a mismatch between the person and their context, not a property of the person. An accessible interface is simply an interface that works in more situations — captions serve the deaf viewer and the train passenger alike.

"Situational" disability means for example…

  1. a rare disease
  2. reading a screen in full sunlight or using a phone one-handed
  3. a server outage
Answer

Sunlight, a busy arm, noise: context creates the disability. Designing for these situations improves everyone's experience.

Theory 2/2: WCAG and the four principles

The WCAG (Web Content Accessibility Guidelines, from the W3C — version 2.2 published in October 2023) are the worldwide reference, turned into legal requirements in the European Union for public services and, since the European Accessibility Act (applicable since June 2025), for a large share of online private services. Three levels: A (minimum), AA (the standard target), AAA (strengthened). Every criterion falls under four principles, the POUR mnemonic: Perceivable (information can be perceived: contrasts, text alternatives), Operable (one can act: keyboard, large enough targets, no trap), Understandable (clear language, predictable behavior), Robust (compatible with assistive technologies). The official filterable reference is the W3C quick reference.

"Being able to use the whole interface from the keyboard" falls under the principle…

  1. Operable
  2. Perceivable
  3. Robust
Answer

Operable: acting, whatever the way. Contrast falls under Perceivable, screen reader compatibility under Robust.

Practice (30 min)

  1. Today's analysis: walk a known site's home page by keyboard only: Tab to move forward, Shift+Tab to go back, Enter to activate. Count: can you always see where you are? Can you reach everything?
  2. Read the A11Y Project checklist and spot three criteria you can already check on a mockup (contrast, targets, focus).
  3. Micro-exercise: in the notebook, list for your day 19 mockup three disability situations (permanent, temporary, situational) and what in your design already answers them, or not yet.

Success criterion: a documented keyboard walk (what works, what is missing) and three situations tied to concrete elements of your mockup.

Agent tip: "Explain WCAG criterion 2.4.7 (focus visible) with a concrete failure example and a success example." Trap: criterion numbers are exactly the kind of detail an LLM mixes up (2.4.7 vs 2.4.11). Proof: open the cited criterion in the W3C quick reference and compare the titles.

Recap (10 min)

Three lines: the three disability types, the four POUR principles, the A/AA/AAA levels. Then give the four principles without notes.

Day 23 — Accessibility 2/3: contrast applied

Goal: fix a complete palette so it passes level AA everywhere it is required.

Theory 1/2: where contrast applies

Day 7 set the thresholds: 4.5:1 for body text, 3:1 for large text (24px, or 18.5px bold) and for meaning-bearing interface elements — a field's border, an icon without label, the focus outline (criterion 1.4.11, "non-text contrast"). Two exemptions to know: purely decorative elements and disabled components are not subject to the thresholds, and neither are logotypes. A frequent trap: text over an image — contrast is then measured against the lightest part of the image under the text, and the honest fix is a darkening veil or a solid background behind the text, not the hope the photo stays dark.

Endless generated exercise (needs JavaScript): the AA thresholds, normal and large text.

Theory 2/2: the fixing method

Fixing a contrast does not mean changing identity: you work the lightness (the L of HSL, day 5), which is what the ratio measures, keeping hue and saturation. Recipe: for text too pale on a light background, lower its lightness in 5% steps until it passes 4.5:1; for an accent too light to carry white text, darken the accent or switch the text to dark — measure both and keep the better ratio. Then document the approved pair: "accent-700 (#…, 5.1:1 on page background): the only accent version allowed under text". The palette becomes a system of approved pairs, and day 36 will turn them into tokens.

To move a gray text from 3.5:1 to 4.5:1 on a white background, you…

  1. increase the gray's saturation
  2. lower the gray's lightness (darker gray)
  3. change the typeface
Answer

The ratio measures luminance: lower the lightness. Saturation and typeface change nothing in the math.

Practice (30 min)

  1. List in the notebook every text/background pair of your day 19 mockup: body on background, secondary on background, white on accent, accent on background, text on card…
  2. Measure each pair in the WebAIM checker and write the ratio next to the pair.
  3. For each pair under the threshold, fix by lightness (5% steps) until it passes, and update the color in the Penpot library.
  4. Write the usage rule: for each color, the backgrounds on which it may carry text.

Success criterion: every pair of the mockup measured, every offender fixed and documented, the Penpot library up to date.

Agent tip: "Here are my text/background pairs: [hex]. For each, say whether it passes AA for normal text, and propose a lightness fix if it fails." Trap: head-computed ratios are often wrong (day 7). Proof: every fixed pair is re-checked in WebAIM — the checker is the source of truth.

Recap (10 min)

Three lines: the three thresholds and their targets, the lightness fixing method, why document the pairs. Then redo a fix without notes.

Day 24 — Accessibility 3/3: targets, focus, beyond color

Goal: apply the three usage rules that complete contrast.

Theory 1/2: target size and focus

WCAG 2.2 requires touch targets (buttons, links, checkboxes) to measure at least 24×24 CSS pixels (criterion 2.5.8, level AA), with a few exceptions (links within a line of text, spaced targets). Platform guides aim higher — 44×44 points at Apple, 48×48 at Google: remember 24 as the legal floor and 40-48 as comfort. Visible focus (2.4.7) requires you to always see which element is active from the keyboard: never remove the focus outline without replacing it with an indicator at least as visible, contrasted at 3:1. Finally, text must be able to be enlarged to 200% without loss of content (1.4.4) — one more reason for the relative units of day 29.

The WCAG 2.2 AA floor for a touch target is…

  1. 16×16 px
  2. 44×44 px
  3. 24×24 px
Answer

24×24 CSS px (2.5.8). The 44×44 come from the Apple/Google guides and level AAA: recommended comfort, not the AA floor.

Theory 2/2: never encode by color alone

Criterion 1.4.1 forbids information resting on color alone: the link must be underlined or distinguished otherwise than by hue, the error announced by an icon and a text, the pie chart labeled directly. The test is simple: view your screen in grayscale (Chrome devtools emulate it: Rendering panel → "Emulate vision deficiencies", or a screenshot converted to black and white) — whatever disappears was encoded by color alone. Add the text alternative: every image carrying information has an equivalent text (the alt attribute, code side; design side, we write that text in the mockup). A purely decorative image gets an empty alt so it is skipped, not a missing alt.

The quick test of the "color alone" criterion is to…

  1. look at the screen in grayscale: nothing important may disappear
  2. change the screen resolution
  3. print the page
Answer

In grayscale, any information encoded by color alone vanishes. What survives is accessible to the color-blind.

Practice (30 min)

  1. Audit your day 19 mockup: does every button and link measure at least 24×24 (ideally 40+)? Fix sizes in Penpot.
  2. Check every inline link is underlined (or distinguished otherwise than by color), and every planned error state has its icon and message.
  3. Grayscale test: export the mockup as PNG, convert it to black and white (any image viewer does): list what loses its meaning.
  4. Write the alternative text of every informative image of the mockup, in the notebook.

Success criterion: all targets at 24px minimum, no meaning carried by color alone in the gray test, and one alt written per informative image.

Agent tip: "Write the alternative text of this image: [describe the image and its role in the page]. Rule: the role in the page first, the description next, 125 characters max." Trap: it will describe the image instead of its function ("blue button" instead of "search"). Proof: the alt read aloud replaces the image without loss.

Recap (10 min)

Three lines: target sizes, the focus rule, the grayscale test. Then redo the targets/focus/color audit on a known screen without notes.

Day 25 — Plain language

Goal: write an interface's texts: labels, error messages, buttons.

Theory 1/2: microcopy

Microcopy is the set of small interface texts: button labels, field labels, error messages, confirmations, empty states. Its rules fit in four points: action verbs for buttons ("Save draft" beats "OK": the label says what will happen), short active sentences ("We could not save" beats "An error occurred while saving"), the user's vocabulary rather than trade jargon, and the important part first ("3 fields to fix" before the polite phrase). A good error message answers three questions: what happened, is it serious, what to do now. "Error 500" answers none of them.

The best label for the final button of a sign-up form is…

  1. "OK"
  2. "Create my account"
  3. "Submit the form"
Answer

The verb that tells the action and its benefit. "OK" says nothing, "Submit" describes the mechanism, not the outcome.

Theory 2/2: writing for everyone

Plain language is also an accessibility criterion (the "Understandable" principle): sentences under 20-25 words, active voice, one term per thing (do not alternate "cart" and "basket"), no double negatives, no reference to shape or position ("click the green button on the right" excludes those who see neither color nor screen — prefer "click "Save""). For long content, WCAG recommendation 3.1.5 (AAA) targets a lower-secondary reading level: that is not dumbing down, it is respecting everyone's time. Home test: read the text aloud; any sentence that leaves you breathless is to be cut.

"Click the green button at the top right" is bad guidance because…

  1. it depends on color and position, invisible to part of the users — better: name the button
  2. it is too long
  3. green is aggressive
Answer

Name the element ("click "Save""): the name survives the screen reader, grayscale and responsive.

Practice (30 min)

  1. Today's analysis: open the sign-up or contact form of two known sites. Record five labels or messages in the notebook, and for each: action verb or not? jargon or not?
  2. Micro-exercise: rewrite these five bland texts — "Error: invalid field", "Submit", "Your request has been taken into account", "Incorrect password", "Loading…" — into messages that say what is happening and what to do.
  3. Apply: write the real texts of your day 19 mockup (headings, buttons, error messages of the form if there is one).

Success criterion: five texts rewritten in "what + what to do" format, and the final texts placed in the mockup.

Agent tip: this is where the LLM is strong: "Rewrite this error message for a non-technical user: what happened, what to do. Direct tone, one sentence." Trap: it will embellish and lengthen. Proof: every message fits in one sentence, starts with the fact, ends with the action.

Recap (10 min)

Three lines: the four microcopy rules, an error message's three questions, why name rather than point. Then rewrite "Error 500" without notes.

Day 26 — Forms

Goal: draw a complete form with its labels, errors and states.

Theory 1/2: the anatomy of a field

A form field has four parts: the label (always visible, above the field — never a placeholder that disappears while typing: the placeholder is an example, not a label), the field itself (40-48px tall, border contrasted at 3:1), the optional help (expected format, as permanent text under the label), and the error message (under the field, tied to it, with an icon). A single column, fields sized to their expected content (a postal code is not as wide as an e-mail), related fields grouped under a section heading: form usability research (Luke Wroblewski's work since 2008) shows these choices measurably cut completion time and drop-outs.

Why can't the placeholder act as the label?

  1. it is ugly
  2. it disappears while typing and its contrast is often insufficient: the user loses the instruction
  3. it slows the page down
Answer

Gone at the first typed character, the placeholder leaves the user without the instruction. The label stays permanently visible, above the field.

Theory 2/2: validating without punishing

Validation is tuned like a polite conversation: do not flag an error during typing (too early), validate the field when it is left, and re-validate live a field being fixed. The error sits next to the field concerned and is summarized at the top if the form is long. Required fields get an asterisk with its legend ("* required") — or better, mark the optional fields, if they are the minority. The primary button repeats the action ("Create my account"), the secondary button stays discreet. And the golden rule: never empty a form after an error — the worst pattern, turning a typo into a dropout.

The right moment to validate a field is…

  1. on every keystroke
  2. only when the form is submitted
  3. when the user leaves the field, then live while they fix it
Answer

Too early punishes ongoing typing; too late piles up errors. Validation on leaving the field, corrected live, is the proven compromise.

Practice (30 min)

  1. In Penpot, draw a sign-up form: name, e-mail, password (with help "12 characters minimum"), acceptance checkbox, "Create my account" button.
  2. Next to it, draw the same form in error state: invalid e-mail — message under the field, icon, contrasted red border, summary at the top.
  3. Check: permanent visible labels, 44px-tall fields, borders at 3:1, button at the right height with an action label, nothing encoded by color alone.

Success criterion: two versions of the form (rest, error) passing the eight checks of the practice.

Agent tip: "List the possible errors of this form (name, e-mail, password, checkbox) and write each message in what+what-to-do format." Trap: it will forget edge cases (empty field, e-mail already taken, password too short). Proof: confront its list with the cases your form actually rejects — every rejection has its message.

Recap (10 min)

Three lines: the four parts of a field, the validation moment, the golden rule of forms. Then redraw the field in error without notes.

Day 27 — Navigation

Goal: design the tree structure and menus of a small site.

Theory 1/2: information architecture

Before menus, the site map: which pages, grouped how. The proven method is card sorting: write each content on a card, have users group them, name the groups with them. Two rules hold without research: a main menu stays short (the rule of thumb of 5 to 7 entries comes from working-memory limits — take it as prudence, not law), and labels say what you will find, not the internal service name ("Pricing" beats "Offer"). The "three-click rule" myth has been tested and disproved (User Interface Engineering studies, 2003): what keeps the user is not the click count but the certainty, at each click, of being on the right track — the "scent of information".

The "three-click rule"…

  1. is a WCAG standard
  2. is a myth: what matters is that each click visibly gets closer to the goal
  3. forbids deep menus
Answer

Tested and disproved: users do not drop at the fourth click, they drop when the scent goes cold.

Theory 2/2: navigation patterns

Four patterns cover most of the web: the horizontal bar in the header (the standard, logo on the left clickable to home), the hamburger menu on mobile (the "Menu" label next to the icon improves discoverability), the breadcrumb telling where you are in the tree (Home › Section › Page) and the footer, which receives everything that has no place in the main menu (legal, contact, site map). On every page, three landmarks must answer "where am I": the active menu entry distinguished (not by color alone), the page title repeating the clicked label, and the breadcrumb as soon as the site goes deeper than two levels.

The breadcrumb becomes useful…

  1. as soon as the site goes deeper than two levels
  2. only on admin sites
  3. never, it is outdated
Answer

It answers "where am I" in deep trees — documentation, e-commerce, administration.

Practice (30 min)

  1. Today's analysis: on service-public.fr, spot the three "where am I" landmarks on a deep page. Note the main menu's entry count and the chosen labels.
  2. Micro-exercise: invent the tree of a bakery site: 6 to 10 pages, grouped, labels in the customer's vocabulary. Draw it in the notebook.
  3. In Penpot, draw this site's desktop header (horizontal bar, active entry distinguished) and its mobile version (hamburger + "Menu" label).

Success criterion: a complete tree in the notebook, two headers drawn, and a real site's three landmarks recorded.

Agent tip: "Here are my 12 contents: [list]. Propose a grouping into 5-7 menu entries with labels in the customer's vocabulary, and justify each group in one line." Trap: it will use your internal vocabulary. Demand: "reword each label as what the visitor looks for". Proof: every content of the list appears in a group, none is lost.

Recap (10 min)

Three lines: card sorting, the three-click myth, the three "where am I" landmarks. Then redraw your tree without notes.

Day 28 — Module 2 review: an accessible redesign

Goal: redesign a real page in Penpot applying every rule of the module.

Theory 1/2: the redesign method

Redesigning is not redrawing to taste: it is fixing against rules. The method has four steps: audit first (the six-criterion grid of day 14, plus the accessibility checks of days 22-24: contrast of pairs, target sizes, color alone), then prioritize — the faults that prevent use (body text contrast, focus, targets) before comfort faults (rhythm, alignments); fix in the tool, in layers (typography, color, spacings, details, day 19); prove finally: every fix delivered with its before/after measurement. This "problem, rule, fix, proof" format is exactly that of a professional audit report — day 28 is practice at writing one.

Theory 2/2: what to keep, what to change

A redesign respects what works: the information structure, the contents, the conventions users have learned (day 12). You change what fails measurements, not what you dislike. Two safeguards: any fix that breaks another rule is rejected (darkening a text under 12px is not a fix), and the redesigned version must pass the same audit without a new fault. Keep before and after side by side: the comparison is your first designer deliverable, and it will be part of the final project.

In a redesign, you fix first…

  1. what you dislike aesthetically
  2. what fails measurements and prevents use (contrast, targets, focus)
  3. the colors first
Answer

Use first, measured; taste next. An audit starting with "I don't like this blue" is not an audit.

Practice (30 min)

  1. Pick a visibly improvable real page (an association, a small business, a local administration site).
  2. Audit it: six-criterion grid + accessibility checks. Write six measured findings in "problem, rule, fix" format.
  3. In Penpot, redesign the most faulty zone (header, a card, the form): quick wireframe then layered mockup, with your library.
  4. Document before/after: one screenshot of each, and the measurement proving each fix (ratio before → ratio after).

Success criterion: an audit of six measured findings, a zone redesigned in Penpot, and a documented before/after with its numerical proofs.

Agent tip: "Here is my audit (6 measured findings) and my fixes. Check that no fix introduces a new fault (contrast, target, color alone) and flag any finding without a measurement." Trap: it cannot measure — it reasons over your numbers. Proof: every "after" is re-measured in WebAIM or the inspector, never copied from its answer.

Recap (10 min)

Three lines: the four steps of a redesign, the use/comfort priority, the report format. Then recite the method without notes — it will serve the module 4 project.

Found this useful? Tell us what to measure next.

Comments

No account, no tracker: a comment is read by a human before it appears.