freedzhost.cloud

Web design module 3: responsive, tokens and systems

Level BeginnerEstimated time 14 hRead first Web design module 2: the tools and the rulesA word you don't know? Glossary

Fourteen sessions to bring the mockup to life: it adapts to screens (responsive), to dark mode, and it becomes a system — tokens, documented components, micro-interactions, clickable prototype. This is the module where the drawing becomes a deliverable a developer can build without guessing.

Day 29 — Responsive 1/3: relative units

Goal: know when to measure in px, rem, % or vw.

Theory 1/2: the pixel that is not one

The "CSS pixel" (px) is not a screen pixel: it is a reference unit, scaled by zoom and by dense screens. Four units make responsive: px, for what must not move (1-2px borders, radii); the rem, equal to the document's root font size (16px by default, but the user may have raised it in their settings — text sizes and spacings in rem respect that choice, in px they ignore it); the %, relative to the parent (column widths); and vw/vh, percentages of the window, useful sparingly (a heading in vw grows with the screen but can turn huge or tiny: cap it). This path's rule: texts and spacings in rem, widths in % or grid columns, px for strokes.

Endless generated exercise (needs JavaScript): convert px to rem (16px root).

Theory 2/2: why rem is an accessibility question

WCAG criterion 1.4.4 requires text to be resizable to 200% without loss of content or function. Text sized in rem follows the browser's font-size setting; text in px does not (page zoom compensates, but degrades the layout: overflowing columns, horizontal scroll). The same logic touches spacings: a margin in rem breathes when text grows. The rem has one trap: do not change the root size yourself without reason — the whole mental conversion chain (16px = 1rem) rests on the default.

Why size texts in rem rather than px?

  1. it loads faster
  2. to respect the user's font-size setting (WCAG 1.4.4)
  3. because px is deprecated
Answer

Rem follows the user's preference; px ignores it. Px stays correct for what must not change: borders, radii.

Practice (30 min)

  1. In the devtools, set the root font size to 24px (Settings/Preferences, or the browser's font-size preference) and visit two known sites: which follow? Which stay frozen? Note it.
  2. Analysis: on a site that follows, inspect the text sizes: are they in rem? Record three values.
  3. Micro-exercise: convert your day 4 type scale to rem (base 16): 12, 16, 20, 25, 31, 39 → ? Write both columns in the notebook.

Success criterion: two sites tested at the 24px setting with the verdict noted, and your scale converted to rem without error.

Agent tip: "Convert this scale to rem (16px base): 12, 16, 20, 25, 31, 39. Give a px/rem table, and flag values that don't come out clean." Trap: 31px = 1.9375rem, it may round silently. Demand exact values. Proof: divide two of the values by hand.

Recap (10 min)

Three lines: the four units and their roles, what 1.4.4 measures, the rem trap. Then redo the scale conversion without notes.

Day 30 — Responsive 2/3: mobile-first and breakpoints

Goal: design for the most constraining screen first and pick breakpoints from the content.

Theory 1/2: mobile-first

Designing mobile-first — starting from the narrow screen, enriching as it widens — is not a fashion but a discipline: at 375px wide, every element must justify its presence and its order. The hard decision (what is essential?) is made where room is scarce, not at the end when everything must fit. The reverse, "desktop first", produces rich pages then cut down by deleting — and mobile inherits the leftovers. Mobile traffic has been more than half of worldwide web traffic since 2016-2017; on many consumer services, it is the majority. The narrow constraint is not a punishment: it is a priority filter.

The main argument for mobile-first is…

  1. the space constraint forces content priorities
  2. phones are faster
  3. desktops are disappearing
Answer

It is a prioritization discipline: what fits in 375px fits everywhere, and widening adds instead of deleting.

Theory 2/2: breakpoints

A breakpoint is the width where the layout changes: one column becomes three, the menu becomes a hamburger. Two schools: follow devices (360-428px phones, 768px tablet, 1024-1440px desktop — common landmarks, not standards) or follow content: widen the window until the layout breaks, and place the breakpoint there. Good practice mixes both: design at the common widths, check the in-between widths. Three breakpoints are enough for most sites (mobile, tablet, desktop); every added breakpoint is one more layout to maintain.

A well-chosen breakpoint is placed…

  1. at the exact width of the latest iPhone
  2. at random, added as needed
  3. where the layout stops working, starting from common widths
Answer

Content decides: start from the usual widths (375, 768, 1280) and adjust where the layout actually breaks.

Practice (30 min)

  1. In the devtools, open device mode (Ctrl+Shift+M in Chrome/Firefox) on a site you like. Slowly drag the width from 360 to 1440px: note each width where the layout changes.
  2. For each observed breakpoint, note what changes: column count, menu, sizes?
  3. Micro-exercise: in the notebook, list for your day 19 mockup what will change at each breakpoint: "375px: 1 column, hamburger; 768px: 2 columns; 1280px: 3 columns, full bar".

Success criterion: a real site's breakpoints recorded with what changes at each, and your mockup's breakpoint plan written.

Agent tip: "Here are my page's blocks and their order: [list]. Propose a breakpoint plan (375/768/1280): at each width, the layout and what changes." Trap: it will apply recipes without looking at your content. Proof: every proposed change answers a problem visible when you resize.

Recap (10 min)

Three lines: what mobile-first forces you to decide, how a breakpoint is placed, why three are enough. Then recite your breakpoint plan without notes.

Day 31 — Responsive 3/3: adapting a screen

Goal: properly adapt a desktop mockup to mobile.

Theory 1/2: the adaptation patterns

Four patterns cover most desktop → mobile adaptations: stacking (columns become rows, in importance order — day 20), collapse (the menu becomes a hamburger, filters become a panel), resizing (the visual goes from half-screen to full width, heading sizes drop one or two scale steps) and substitution (a too-wide table becomes a list of cards — same content, different shape). Mobile is not a shrunk desktop: targets move to the finger (44px of comfort, day 24), text stays at 16px minimum to avoid iOS's forced zoom on fields, and vertical scroll replaces horizontal density.

An eight-column table on mobile best becomes…

  1. the same table, smaller
  2. a list of stacked cards, same content, different shape
  3. an image of the table
Answer

Substitution: eight columns in 375px are illegible; one card per row keeps the content readable. Shrinking is not adapting.

Theory 2/2: the classic adaptation mistakes

Three faults return in beginners' adaptations: shrinking body text "to make it fit" (mobile deserves the same 16px, not less), tightening spacings (on the contrary, stacking needs constant vertical air — your 16-24-48 from day 9), and hiding content without reason (mobile is a reorganization, not an amputation — you collapse what is secondary, you do not delete it). Truth test: walk the mobile version with your thumb: are the main actions reachable, the targets large enough, the text legible without zoom?

On mobile, body text should…

  1. stay at 16px minimum
  2. drop to 12-13px to save room
  3. go up to 20px
Answer

16px: below that, reading tires and iOS zooms form fields. Room is won by stacking, not by shrinking.

Practice (30 min)

  1. In Penpot, adapt the day 20 desktop mockup to a 375px mobile board: stack the columns in importance order, collapse the menu into a hamburger, bring heading sizes one or two steps down.
  2. Check the three classic faults: body at 16px, vertical spacings from the scale, no content deleted (collapsed, yes; amputated, no).
  3. Thumb test: picture the lower zone of the screen: is your main action there, or at least reachable without contortion?

Success criterion: a complete mobile version, no content lost, 16px body, touch targets respected, hierarchy identical to desktop.

Agent tip: "Here is my page's desktop structure: [blocks]. Propose the mobile adaptation (stacking order, what collapses, what is substituted) and flag any content that would be removed — there must be none." Trap: it will happily propose to "hide". Proof: before/after inventory, every desktop block has a mobile address.

Recap (10 min)

Three lines: the four patterns, the three classic faults, the thumb test. Then give the four patterns without notes.

Day 32 — Testing without devices

Goal: check a design under real conditions with devtools alone.

Theory 1/2: the browser's evaluation kit

Device mode (Ctrl+Shift+M) simulates widths, pixel densities and touchscreens; Chrome's "Rendering" panel emulates prefers-color-scheme (dark mode), prefers-reduced-motion and vision deficiencies (protanopia, deuteranopia, blurred vision); zooming to 200% (Ctrl+wheel) reproduces the enlargement WCAG 1.4.4 requires; and keyboard only (Tab, Shift+Tab, Enter, Escape) tests operability. Add network throttling to see the page load slowly. None of these tests replaces a real device in real hands, but together they catch most faults before anyone suffers them.

To check a design survives the WCAG text enlargement, you…

  1. shrink the window
  2. change the screen resolution
  3. zoom the page to 200% or double the root font size
Answer

200% zoom (or doubled root font): criterion 1.4.4 requires everything stays legible and usable.

Theory 2/2: the ten-minute test protocol

A written protocol avoids "looks fine to me". Ours, ten steps for any page: (1) normal desktop reading; (2) 375px width; (3) intermediate 700px width; (4) 200% zoom; (5) keyboard only, top to bottom; (6) deuteranopia emulation; (7) dark mode if planned; (8) contrast of the main pairs measured; (9) texts read aloud; (10) full scroll hunting for horizontal overflows. Each step produces one notebook line: OK or problem + rule + fix. Ten minutes, ten lines: the minimal version of what a team calls a design review.

Horizontal overflow (lateral scroll) on mobile is usually caused by…

  1. text too long
  2. a fixed-width element exceeding the window
  3. dark mode
Answer

A fixed width (a table, an image, a px-sized block) exceeding 375px. Step 10 spots it immediately.

Practice (30 min)

  1. Apply the ten-step protocol to a real page of your choice. Notebook open: one line per step.
  2. Record at least one real problem (there is almost always one) and write it in problem + rule + fix format.
  3. Apply steps 2, 4 and 5 to your Penpot mockup from days 19-31 (export as PNG for the zoom, simulate the keyboard by describing the expected tab order).

Success criterion: the protocol applied to a real page with ten lines in the notebook and one problem written in full format.

Agent tip: an agent with a drivable browser can run steps 2 to 8 alone: "Load this page at 375px, zoom to 200%, list overflows and contrasts under 4.5:1, with screenshots." Trap: its contrast measurements still need checking (day 23). Proof: demand the screenshots and re-measure one pair by hand.

Recap (10 min)

Three lines: the devtools' evaluation tools, the ten steps, each line's format. Then recite the protocol without notes.

Day 33 — Dark mode 1/2: the principles

Goal: derive a dark palette that respects hierarchy and contrast.

Theory 1/2: dark is not inverted

Mechanically inverting a light palette fails: a pure black (#000) background tires (pure white text "vibrates" on it by halation) and shadows become invisible. Proven design systems (Google's Material, Apple's HIG) converge: backgrounds in very dark gray rather than black (Material recommends #121212), text in off-white (87% opacity in Material, roughly #FFF at 87%), and elevation reads as lightening: the higher a surface floats (card, menu, modal), the lighter its gray — where light mode uses shadow. The accent, meanwhile, is slightly desaturated and lightened: a vivid saturated blue on dark background bleeds visually and loses measured contrast.

In dark mode, the card resting on the page is distinguished by…

  1. a stronger shadow
  2. a gray slightly lighter than the background
  3. a white border
Answer

In dark, elevation is expressed through lightness: the higher the surface, the lighter it is. Shadows are nearly invisible there.

Theory 2/2: the thresholds do not change

Good news: WCAG thresholds are identical in dark mode — 4.5:1 body text, 3:1 large text and components. Bad news: everything must be re-measured, because relationships invert (a medium gray text that passed on white can fail on dark gray, and vice versa). Two specific traps: semantic colors (an error red designed for light is often too dark on a black background — lighten it) and images with a "stuck" white background (plan their variant or their frame). Dark mode is chosen by the system preference (prefers-color-scheme) and can always be overridden by hand: a user may prefer light even at night.

Text contrast in dark mode must reach…

  1. the same WCAG thresholds as light: 4.5:1 for body text
  2. half of it, since dark tires less
  3. 7:1 mandatory
Answer

Thresholds do not change with the theme: 4.5:1 and 3:1, re-measured pair by pair.

Practice (30 min)

  1. In the notebook, derive your day 23 palette in a dark version: background (~#121212), card surface (one step lighter), main text (white at ~87%), secondary text, lightened and desaturated accent, lightened error.
  2. Measure each text/background pair in WebAIM: all must pass their thresholds. Fix by lightness otherwise.
  3. Today's analysis: enable dark mode on a site that offers it (devtools: Rendering → emulate prefers-color-scheme: dark). Record its background, surface and text: check the elevation rule.

Success criterion: a complete dark palette, every pair measured AA, and the elevation rule checked on a real site.

Agent tip: "Derive my light palette [hex] into a dark palette (Material rules: #121212, elevation by lightening, desaturated accent), with the AA ratios of each pair." Trap: it will invent the ratios. Proof: every pair re-measured in WebAIM before entering the library.

Recap (10 min)

Three lines: why no pure black, elevation through lightness, what gets re-measured. Then re-derive the dark palette without notes.

Day 34 — Dark mode 2/2: fine-tuning

Goal: draw a complete screen in dark mode and fix what breaks.

Theory 1/2: components in dark

Every component has its adaptation: fields keep a visible border at 3:1 (on a dark background, a medium gray border disappears — lighten it); focus stays contrasted in both themes (test the light outline on a dark background); shadows give way to light elevation and possibly a 5-10% opacity border edge; images and logos: a black logo on transparent disappears — plan the light version or a chip. State colors (error, success, warning) are redefined for dark in the library: same roles, different values — the first concrete application of day 16's semantic naming.

A black logo on a transparent background, in dark mode…

  1. stays as is
  2. gets a white shadow
  3. is replaced by its light variant or set on a chip
Answer

It disappears on a dark background: light variant or chip. The classic case forcing assets to be thought in two themes.

Theory 2/2: organizing the two themes

Two themes in one file is a debt if managed by hand: every screen exists twice and diverges. The sound organization: one drawing, colors referenced by role, and two sets of values (light/dark) for the same role names — exactly the structure of themed design tokens, which Penpot manages natively (Tokens tab, sets and themes), applied on day 36. Meanwhile, the minimal discipline: both versions of a screen side by side, same components, only color references change. If you catch yourself redrawing a component for dark, the role was not named.

The right structure for managing two themes is…

  1. two separate files
  2. one drawing, colors named by role, two sets of values
  3. redrawing every screen in dark
Answer

Roles are stable, values change: one drawing, two sets. Any drawn duplication will diverge.

Practice (30 min)

  1. In Penpot, duplicate the day 19 mockup and switch the copy to dark with the day 33 palette: backgrounds, texts, accent, states.
  2. Fix the four sensitive points: field borders at 3:1, contrasted focus, shadows replaced by elevation, every dark logo or image handled.
  3. Cross test: measure the button's and the secondary text's contrast in both themes (WebAIM), note the four ratios.
  4. Gray test of both themes (day 24): nothing important disappears.

Success criterion: the screen exists in light and dark, same components, every pair measured AA in both themes.

Agent tip: "Compare my two themes [lists of hex pairs]: detect roles missing a dark value and pairs under AA." Trap: it will flag "taste problems" instead of missing measurements. Proof: its output is a list of roles and ratios, not opinions — every ratio re-checked in WebAIM.

Recap (10 min)

Three lines: the four component adaptations, the roles + value sets organization, the cross test. Then redo the list of sensitive points without notes.

Day 35 — Design tokens 1/2: naming decisions

Goal: understand what a design token is and name yours on three levels.

Theory 1/2: one decision, one name, one value

A design token is a design decision stored as a name and a value: color.accent = #3B82F6, space.md = 16, font.body = 1rem/1.5 Inter. The day 16 Penpot library was a draft of it; the token adds the core idea: this name is the contract between design and code — the developer does not write #3B82F6 but accent, and changing the value changes the whole product. The W3C hosts a working group (Design Tokens Community Group) standardizing a JSON exchange format between tools. Tokens cover colors, spacings, text sizes, radii, shadows, animation durations: any value that repeats deserves a name.

A design token is…

  1. a named design decision, shared between design and code
  2. a typeface
  3. an API password
Answer

Name + value + role: the contract that keeps isolated values from diverging between mockup and product.

Theory 2/2: the three levels

Tokens organize in three layers. Primitives: raw material, named by what it is — blue.500, gray.100, space.4 (= 16px). Semantic: the role, referencing a primitive — color.text.primary = gray.900, color.accent = blue.500, surface.raised = white. Component tokens, optional: button.background = color.accent. The benefit appears at change time: dark mode only redefines the semantic layer (surface.raised goes from white to gray.800), and a rebrand only touches the primitives. The naming rule stays day 16's: the name tells the role, never the look — color.error, not color.red.

button.background = color.accent is a token at the…

  1. primitive level
  2. semantic level
  3. component level
Answer

Component: it names a property of a precise component and references a semantic, which references a primitive. Three layers, three reasons to change.

Practice (30 min)

  1. Inventory in the notebook every repeated value of your mockup: colors, spacings, text sizes, radii, shadow, durations.
  2. Write them as tokens on three levels: primitives (blue.500, gray.50…, space.1 to space.16), semantic (background, surface, text.primary, text.secondary, accent, error, border), component (button.background, card.surface, field.border).
  3. Check coverage: every value of the mockup has a token; every token is used somewhere. Delete the orphans.

Success criterion: a three-level token list covering the whole mockup, no orphan, named by role.

Agent tip: "Here are my design values: [list]. Structure them as tokens on three levels (primitive/semantic/component) in the W3C Design Tokens format, and flag any value that does not repeat — it may not deserve a token." Trap: it will create useless layers. Proof: every cited token appears in your mockup.

Recap (10 min)

Three lines: what a token is, the three levels and what changes at each, the naming rule. Then rewrite your first ten tokens without notes.

Day 36 — Design tokens 2/2: the token sheet

Goal: materialize your tokens in Penpot and export the reference.

Theory 1/2: tokens in the tool

Penpot manages tokens natively: the Tokens tab of the left panel lets you create token sets — colors, dimensions, radii — and organize them into themes, for example "light" and "dark", giving two values to the same role name: that is day 34's organization, tooled. A token applied to an object updates when the theme changes: the end of duplicated screens. Export (JSON) produces the reference sheet a developer turns into CSS variables (--color-accent: #3B82F6) — design and code finally share the same vocabulary, and the mockup becomes an executable specification instead of an image to interpret.

Token "themes" serve to…

  1. change the document's font
  2. give two sets of values (light/dark) to the same roles, and switch the whole file
  3. export images
Answer

A theme is a set of values: roles are stable, values change, the whole file switches at once.

Theory 2/2: scales as tokens

Your day 4 and day 8 scales become token families: space.1 = 4px to space.16 = 64px (the index says the number of 4-steps, the value can be guessed), font.size.100 = 0.75rem to font.size.600 = 3rem. Writing the scale as tokens has two virtues: it forbids improvised intermediate values (there is no space.7.5), and it makes reviews legible — "this should be space.6 instead of space.4" is a precise remark. A shadow also becomes a token (shadow.card), as do day 39's transition durations (motion.fast = 150ms). Anything used twice deserves a name; anything used once does not.

space.6 in a 4px-step scale equals…

  1. 24px
  2. 6px
  3. 32px
Answer

6 × 4 = 24px. The index counts the steps: the value rebuilds itself without documentation.

Practice (30 min)

  1. In Penpot, Tokens tab: create your sets — semantic colors, spacings, text sizes, radius, shadow.
  2. Create two themes (light, dark) with the day 23 and day 33 values; apply tokens to the day 34 mockup's objects in place of library colors.
  3. Switch theme: the whole screen must go dark with no touch-up.
  4. Export the tokens as JSON and paste them in the notebook: that is your design's specification.

Success criterion: the mockup holds no isolated value anymore, theme switching works with no touch-up, and the exported JSON is in the notebook.

Agent tip: "Turn this token JSON into CSS variables (:root, dark theme under [data-theme="dark"]). One variable name per token, no value changed." Trap: it will "fix" values on the way. Demand: "change no value". Proof: diff its CSS against your JSON — only the names change format.

Recap (10 min)

Three lines: sets, themes, export; the scale as tokens; the "twice = a name" rule. Then rewrite your spacing scale as tokens without notes.

Day 37 — Design system 1/2: atoms and molecules

Goal: break an interface down into a system of reusable components.

Theory 1/2: atomic design

Brad Frost published in 2013 the metaphor that stayed canonical: an interface composes like matter. Atoms: button, label, field, icon — indivisible. Molecules: a field + its label + its error message = a complete "form field". Organisms: the header, the product card, the whole form. Then templates (the page without its real content) and pages. The metaphor is not a dogma — many teams stop at three levels — but it forces the right question: at which reuse level does what I am drawing sit? A design system is this breakdown, applied and documented: tokens (day 35), components (day 17) and their usage rules.

A "search field" (label + field + button) is…

  1. an atom
  2. a molecule
  3. a page
Answer

A molecule: several atoms assembled into a functional unit. The button alone is an atom; the results page, an organism or more.

Theory 2/2: why systematize

The design system cures three ills: inconsistency (day 12 — same behavior, same look), slowness (you assemble instead of redrawing) and design/code divergence (the component carries the same name on both sides). Public systems — DSFR, GOV.UK, IBM's Carbon, Shopify's Polaris — show the target structure: for each component, a name, a usage ("when to use it / when not to"), its variants, its states, its accessibility rules. At your scale, the system fits on one Penpot page: the tokens, the project's atoms and molecules, laid out and named. The symmetric trap: systematizing too early. Only factorize after two real uses — a system written before the need freezes bad guesses.

You turn a drawing into a system component…

  1. as soon as it looks good
  2. before starting the screens
  3. when it has served twice
Answer

After two real uses: before that, you do not know yet what varies. Factorizing early freezes bad guesses.

Practice (30 min)

  1. List every element of your module 2-3 mockups and classify them: atom, molecule, organism.
  2. Keep as components only those used (or planned) twice. The others stay drawings.
  3. In Penpot, create the "System" page: tokens recalled at the top, then the components laid out in a grid, named by role.
  4. For each component, note in the notebook: name, usage ("serves…, does not serve…"), states.

Success criterion: the System page holds your factorized components (no orphan), each named with usage and states in the notebook.

Agent tip: "Here are my project's screens [describe]. List the recurring components, classify them as atoms/molecules/organisms, and propose a role name for each." Trap: it will factorize everything, even the unique. Demand: "list only what appears twice". Proof: every component in its list cites the two places it serves.

Recap (10 min)

Three lines: the five levels, the three ills cured, the two-uses rule. Then redraw your components' classification without notes.

Day 38 — Design system 2/2: documenting a component

Goal: write a component's complete sheet, one a developer can follow alone.

Theory 1/2: the minimal sheet

An undocumented component is a component that will be misused. The minimal sheet has six sections: the name (the same in design and code); the usage — when to use it, and above all when not to ("secondary button: never for the page's main action"); the variants (primary/secondary/danger, sizes); the states (rest, hover, focus, active, disabled — day 13); the accessibility rules (pair contrast, target size, mandatory label or icon with an accessible name); and the tokens used (button.background = color.accent…). Large documentations add "do / don't" examples: it is the most-read section, write it early.

The most useful section of a component sheet is…

  1. when to use it and when not to
  2. its version history
  3. its author's name
Answer

Usage and its limits: that is what keeps the component from being hijacked. The rest describes, this one decides.

Theory 2/2: documenting for someone who was not there

The test of a good sheet: someone discovering the project can assemble a correct screen without asking you anything. That imposes three disciplines: show everything (every variant and every state drawn, not described from memory), measure everything (values come from tokens, never "about"), and write the implicit rules — button order (primary on the right in common practice), spacing between buttons (space.2), behavior when the label is long. What is not written will be improvised; what is improvised will diverge. The sheet is not bureaucracy: it is the project's memory, including for you in three months.

"The button is about 40px tall" is a bad sheet line because…

  1. 40px is too much
  2. the value must reference an exact token, not an approximation
  3. you must speak in rem only
Answer

"About" invites sloppiness: the sheet cites the token (size.touch = 2.5rem), which holds the value in one place.

Practice (30 min)

  1. Pick your primary button. In the notebook (or a Penpot page), write its complete sheet in six sections.
  2. Draw its variants and five states in the sheet, each with the tokens concerned.
  3. Write the "do / don't" section: two examples of each, taken from your own mockups.
  4. Reader test: reread the sheet forgetting you wrote it — every question it leaves is a line to add.

Success criterion: a six-section sheet, variants and states drawn, zero "about", and the do/don't section filled.

Agent tip: "Read this component sheet as a developer who has never seen the project. List the questions it leaves unanswered." One of the best LLM uses: the tireless naive reader. Trap: it will ask philosophical questions. Demand: "only questions that block coding the component". Proof: every question turns into a line added to the sheet.

Recap (10 min)

Three lines: the six sections, the reader test, why tokens replace "about". Then recite the six sections without notes.

Day 39 — Micro-interactions

Goal: specify the small animations that inform, never decorating at the expense of use.

Theory 1/2: four parts, three durations

Dan Saffer described the micro-interaction in four parts: the trigger (click, hover, data arriving), the rules (what changes), the feedback (what the user sees) and the loops and modes (what happens on repetition). Their role is functional: confirm the action registered (the button that presses in), show the relationship between two states (the menu sliding from the edge says where it comes from), or soften a wait (the loading skeleton). Proven dosages: 100-200ms for immediate feedback (hover, press), 200-300ms for a state change (opening); beyond 500ms the interface feels slow; exit faster than entrance, and natural acceleration (ease-out for what enters, ease-in for what leaves).

The right duration for a button hover feedback is…

  1. 800ms so people notice it
  2. 0ms, all animation is useless
  3. 100-200ms
Answer

100-200ms: perceived as instant but readable. Beyond 300-500ms, the interface feels slow.

Theory 2/2: motion is not free

Motion can seriously disturb: vestibular disorders (nausea facing parallax and large translations), attention difficulties, photosensitive epilepsy (nothing may flash more than three times a second — criterion 2.3.1). The prefers-reduced-motion system preference lets the user ask for calm: the design respects it by planning the reduced version (simple fades instead of translations). Two common-sense rules complete: never animate what the user must read or aim at during the motion, and any repeating animation (loading) must be stoppable or explainable. A successful micro-interaction is one you do not notice — test it by removal: if nothing is missing, it was decorative.

prefers-reduced-motion is…

  1. a system preference the design must respect by replacing translations with fades
  2. a browser performance setting
  3. a battery standard
Answer

The user asks for calm (vestibular disorders, attention): replace large motions with fades, do not remove the information.

Practice (30 min)

  1. Today's analysis: on a polished site, spot three micro-interactions (button hover, menu opening, loading). For each, time by eye: instant, fast, slow? What does it say?
  2. Micro-exercise: specify in the notebook your project's three micro-interactions: trigger, rule, feedback, duration, curve, reduced-motion version.
  3. In Penpot, annotate the components concerned: "hover: darker accent background, 150ms, ease-out".

Success criterion: three complete specifications (four parts + duration + curve + reduced version), placed as annotations on the mockup.

Agent tip: "Specify the micro-interaction of a mobile menu opening: Saffer's four parts, duration, curve, prefers-reduced-motion version." Trap: it will propose "snappy 300ms" for everything. Demand justification for each duration. Proof: every value fits the lesson's ranges, or is justified by the use.

Recap (10 min)

Three lines: the four parts, the duration ranges, the two respect rules. Then re-specify one micro-interaction without notes.

Day 40 — The clickable prototype

Goal: link your screens into a navigable prototype, shareable by a link.

Theory 1/2: what a prototype proves

The prototype is the mockup set in motion: you click, you navigate, you discover what separate images hid — the unreachable screen, the action without return, the absurd sequence. In Penpot, the Prototype tab links boards: select an element (the button), drag the link to the target board, pick the trigger (click) and the action (navigate, open as overlay). Flows name the journeys (sign-up, purchase), each with its starting point. Presentation mode (View mode) plays the prototype, and a share link makes it testable by anyone, no account needed. The fidelity rule: the prototype proves sequences and returns, not effects — no point animating until the journey is right.

A prototype serves first to check…

  1. animations
  2. screen sequences and possible returns
  3. colors
Answer

Navigation: every action leads somewhere, every screen offers a way back. Static images do not show that.

Theory 2/2: drawing the side paths

The happy path is a third of the work. A complete prototype also covers: the return (every secondary screen says how to leave it), empty states (the list with no element, the search with no result), errors (the refused form, the missing page) and the start (first visit, no data). Counting screens is a good reflex: a small app fits in 4 to 8 boards — beyond that, the scope needs shrinking, not the prototype stretching. Every link in the prototype is a promise: a button without destination is a design fault, not a detail.

Beyond the happy path, a complete prototype covers…

  1. only the home page
  2. transition animations
  3. returns, empty states, errors, first visit
Answer

The side paths: that is where users get lost, and where static mockups stay mute.

Practice (30 min)

  1. In Penpot, assemble three screens of your project (e.g.: list → detail → form) as separate boards.
  2. Link them in Prototype: every button leads somewhere, every secondary screen has its return. Name the flow.
  3. Add an empty state (the list with no element) and link the path leading to it.
  4. Test in View mode: walk the whole flow, then try to get lost. Create the share link.

Success criterion: a playable prototype end to end with no dead end, an empty state, and a generated share link.

Agent tip: "Here are my screens and their actions: [list]. Build the navigation graph and flag any dead end (screen with no exit) or broken promise (button with no destination)." Trap: it will assume "obvious" links. Demand: "list only the links I declared". Proof: every reported dead end exists in the prototype.

Recap (10 min)

Three lines: what the prototype proves, the side paths, the button-destination rule. Then redraw your screen graph without notes.

Day 41 — Getting your prototype tested

Goal: collect useful feedback on your prototype, without steering the answers.

Theory 1/2: asking is not testing

"Do you like it?" produces politeness, not information. The useful test puts the user in a situation: give a task ("find the annual price", "sign up for the newsletter"), then stay silent and watch — the "think aloud" method: the person comments on what they do and look for. Do not defend your design, do not explain: every explanation you give is an interface fault discovered. Jakob Nielsen showed five testers are enough to reveal most problems of a simple journey; one, run honestly, already reveals more than ten lounge opinions. The five-second test completes: show the screen five seconds, hide it, ask "what does this page offer?" — it is day 10's squint test with fresh eyes.

The first rule of a user test is…

  1. explain the design before starting
  2. give a task, stay silent, observe
  3. ask "do you like the colors?"
Answer

You observe a behavior, you do not collect an opinion. Every explanation given is a fault discovered.

Theory 2/2: sorting what you hear

Feedback sorts into three baskets: observed behavior (she did not find the button — a fact, it weighs heavy), the solution suggestion ("you should make it red" — the problem is real, the solution is yours to find: why did she not see the button?), and taste ("I prefer green" — note it, do not act). A problem seen once is a lead; seen twice, it is a project. Record every test in the notebook in day 14's format: observation, rule, proposal. And keep the reverse reflex: what the tester achieved without hesitation is a strength to preserve in the iteration — a redesign that breaks what worked is a regression, not progress.

A tester says: "your button should be red". The right reflex is…

  1. look for the problem behind the suggestion (did she not see the button?) and design your own solution
  2. make it red
  3. ignore the feedback
Answer

The suggestion signals a real problem (visibility), but the solution is yours: contrast, place, label — not necessarily red.

Practice (30 min)

  1. Prepare the test: two written tasks, the day 40 prototype's share link, notebook open.
  2. Have a real person test it (relative, colleague): minimal briefing, silence, observation. Note every hesitation.
  3. If nobody is available: five-second test on yourself after a break, then reread the prototype with fresh eyes.
  4. Sort the feedback into three baskets and write at least two findings in problem + rule + proposal format.

Success criterion: one test run (a real person preferably), feedback sorted, two actionable findings in the notebook.

Agent tip: "Play a novice user: here are my screens described […]. For the task 'find the price', say aloud where you click and what makes you hesitate." Trap: an LLM never truly gets confused — it simulates confusion. Proof: its hesitations must name a precise element (label, place) you can check; they prepare the real test, they do not replace it.

Recap (10 min)

Three lines: task + silence + observation, the three baskets, what to preserve. Then rewrite your two test tasks without notes.

Day 42 — Module 3 review: a small app

Goal: assemble the whole module: a mini-app prototyped, in light and dark, documented.

Theory 1/2: a designer's complete deliverable

What you produce today is what a team expects from a product designer: the screens (mobile + desktop), the tokens (named, light and dark themes), the components (factorized, a sheet for the main one), the prototype (complete flows, empty states and errors) and the proof (measured contrasts, day 32's test protocol passed). Nothing done since day 29 is disposable: every brick of the module is a section of the deliverable. The working order is the module's: structure (responsive), values (tokens and themes), pieces (components), motion (prototype), proof (tests).

Theory 2/2: picking a tenable scope

Today's subject: a small list app — groceries, reading, chores. Four screens are enough: the list (with its empty state), the add screen (day 26's form), detail or edit, and one simple setting (theme toggle, for instance). The review's trap is ambition: every added screen must pass every filter (two themes, two widths, states). Four complete screens beat eight sketched ones — the path's golden rule applied to design: regularity and finish come before quantity.

For the review, the right scope is…

  1. eight sketched screens
  2. four complete screens: two themes, two widths, empty states and errors
  3. one single perfect screen
Answer

Four complete screens: the prototype must show a journey, and every screen passes every filter. A sketch proves nothing.

Practice (30 min)

  1. Sketch the four screens in a quick wireframe (10 minutes maximum — drawing is already acquired).
  2. Build the screens in Penpot with your existing tokens and components; create what is missing (the list row) as a component.
  3. Link everything into a prototype: complete add flow, empty state at start, returns everywhere.
  4. Switch to dark theme, run day 32's test protocol (at least steps 2, 4, 5, 8) and note the result.

Success criterion: four screens, two themes, a prototype without dead ends, and the protocol passed with its lines in the notebook.

Agent tip: "Here is my deliverable: [inventory of screens/tokens/components/flows]. Play the project manager: what is missing before handing it to a developer?" Trap: it will demand exhaustiveness (sheets for everything). Proof: every reported gap matches a real question a developer would ask.

Recap (10 min)

Three lines: the five sections of the deliverable, the working order, the scope rule. Then recite the deliverable without notes — module 4 will have you produce it a second time, bigger.

Found this useful? Tell us what to measure next.

Comments

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