freedzhost.cloud

Web design module 4: the project — a complete personal page

Level BeginnerEstimated time 17 hRead first Web design module 3: responsive, tokens and systemsA word you don't know? Glossary

Seventeen sessions, one single deliverable: your personal page, designed end to end with the path's full method — brief, real content, wireframes, art direction, mobile and desktop mockups, dark mode, accessibility audit, prototype, critique and iteration. This is the module you will show; it is deliberately the longest, and it is the one you trim when life interferes.

Day 43 — The brief

Goal: write the brief of your personal page: one page, five answers.

Theory 1/2: the brief protects the project

The brief is the document that decides before drawing: without it, every choice is renegotiated at every session. A personal page brief answers five questions in one page at most: who (you, in one line: what you do, what you are looking for), for whom (the typical visitor: recruiter, client, peer — only one), what (the measurable goal: being contacted, showing three projects), with what (the available contents: bio, projects, links — not the ones that would need creating), how (the constraints: one single page, two widths, two themes, deadline). The "for whom" question is the one that changes everything: a page for a recruiter puts experience first, a page for clients puts work first.

The brief question that changes the page structure most is…

  1. the color palette
  2. whom the page is for
  3. the hosting choice
Answer

The typical visitor decides the section order: recruiter → experience first; client → work first.

Theory 2/2: numbered commitments

A useful brief holds measurable commitments, which will serve as acceptance criteria on day 59: "the goal (contacting me) is visible without scrolling on mobile and desktop", "body text contrast ≥ 4.5:1 in both themes", "the page fits in five sections at most", "content is 100% real — zero lorem ipsum". Also write the non-goals: what the page will not do (no blog, no twenty-project portfolio, no complex form). A brief without non-goals is a project without an end: it is what we will reread on day 57 to arbitrate the critique.

The brief's non-goals serve to…

  1. fill the page
  2. justify delays
  3. bound the scope: what is not in them will not be done
Answer

They close doors: every "no X" is a discussion avoided on day 55.

Practice (30 min)

  1. Write your brief in the notebook: the five questions, ten lines each at most.
  2. Add four numbered commitments (goal visibility, contrast, section count, real content) and three non-goals.
  3. Read it aloud: every fuzzy phrase ("a modern page") is replaced by a fact ("the visitor finds my contact address in one click").

Success criterion: a one-page brief with five answers, four numbered commitments, three non-goals — and zero adjectives without a measure.

Agent tip: "Here is my brief: [paste]. Spot every non-measurable claim and propose its numbered version; flag any contradiction between goal and contents." Trap: it will add ambitions instead of trimming. Demand: "propose nothing to add, only to clarify or remove". Proof: every remark cites the brief line concerned.

Recap (10 min)

Three lines: the five questions, what a numbered commitment is, the role of non-goals. Then recite your five answers without notes.

Day 44 — The benchmark

Goal: analyze five real personal pages to draw choices, not copies.

Theory 1/2: analyzing to decide

The benchmark is not idea theft: it is day 14's grid applied to pages playing the same role as yours. Five pages are enough, chosen in your field: for each, the six criteria (hierarchy, typography, color, contrast, spacing, grid) plus two project-specific questions: what does the visitor see without scrolling, and how does the page fill its goal. Note what works (to reuse: a pattern, a section order), what fails (to avoid) and what distinguishes (what nobody does that would serve your visitor). The synthesis fits in one table: one row per page, one column per criterion.

Theory 2/2: personal page patterns

Successful personal pages share patterns: the hero answering in one sentence "who are you and whom do you work for", the proofs (projects, clients, numbers) right after, the single action repeated (the same "contact me" button top and bottom), and sober sections — four to six, no more. The most common defect is the opposite of a brief: a page trying to speak to everyone ends up with no order and twelve sections. The benchmark shows it better than any course: compare the clearest and the most confused of your five, and write what separates them in one sentence.

The most common defect of a personal page is…

  1. trying to speak to everyone: twelve sections, no order
  2. too small a typeface
  3. a white background
Answer

No typical visitor: everything is there, nothing leads. Day 43's brief is the preventive cure.

Practice (30 min)

  1. Pick five personal pages from people in your field (search "portfolio" + your job).
  2. Fill the table: six criteria + "without scrolling" + "goal". One row per page, short words.
  3. Write three decision lines: one pattern to reuse, one fault to avoid, one distinction to try.

Success criterion: the table filled for five pages, and three written decisions that will feed day 46's zoning.

Agent tip: "Here are five personal page URLs: […]. For each, say what one sees without scrolling and how it fills its goal." Trap: without a browser, an LLM sees nothing and will describe from memory — give it screenshots, not URLs. Proof: every observation cites an element visible on the screenshot.

Recap (10 min)

Three lines: the benchmark method, the four personal-page patterns, your three decisions. Then recite the patterns without notes.

Day 45 — Content first

Goal: write all the page's texts, before any drawing.

Theory 1/2: design serves content, not the reverse

Day 19 set it: no lorem ipsum. Today, you write the full real content — and it is often the hardest session of the path, because writing "who I am" in one sentence forces you to decide it. A personal page's content: the heading (who you are, for whom, in one sentence — "Web developer, I help nonprofits…"), the presentation (three to five sentences, first person, facts before adjectives), the proofs (three projects, each with: the problem, your role, the result — two sentences each), the links (professional profile, code, e-mail). Everything is read aloud (day 25): what sounds hollow goes.

A project's presentation, on a personal page, contains…

  1. the technology list and nothing else
  2. the problem, your role, the result
  3. a long personal story
Answer

Problem, role, result: that is what a recruiter or a client looks for. The technology list is one proof among others, not the story.

Theory 2/2: writing short is a design choice

Every word less is one typographic setting less: a five-word heading fits on one mobile line, a two-sentence project fits in a card. Honest bounds for a personal page: heading ≤ 8 words, presentation ≤ 60 words, project ≤ 40 words, one idea per sentence (day 25). Write the short variants before drawing: the main button's label ("Contact me"), the contact section's message, the images' alternative texts (day 24 — alt text is content, it is written here). This text file is the project's source of truth: the mockup will hold nothing that is not in it.

The images' alternative text is written…

  1. here, with the rest of the content — it is content
  2. at coding time
  3. never, it is automatic
Answer

Alt text is written content, not a technical option: it is decided with the page's texts.

Practice (30 min)

  1. Write the complete content file: heading, presentation, three projects (problem/role/result), contact, labels, alts.
  2. Apply the bounds: heading ≤ 8 words, presentation ≤ 60, projects ≤ 40 each. Count.
  3. Read everything aloud; cut every sentence that leaves you breathless.
  4. Check against day 43's brief: every text serves the typical visitor and the goal. What does not serve goes out.

Success criterion: a complete content file, within bounds, read aloud, validated against the brief.

Agent tip: the LLM's home turf: "Here is my presentation: [paste]. Cut it to 60 words without losing facts; list what you removed." Trap: it will smooth it into emptiness ("passionate about…"). Demand: "keep every fact, remove every adjective". Proof: both versions side by side, every fact of yours survives in its version.

Recap (10 min)

Three lines: the four content blocks, the bounds, why the text file is the source of truth. Then rewrite your heading without notes.

Day 46 — Structure and zoning

Goal: order the page's sections and draw its zoning.

Theory 1/2: order is an argument

On a single page, section order is the argument: what the visitor reads second depends on what they accepted first. The proven order for a personal page: hero (who, for whom, action), proofs (the three projects), presentation (once credibility is established), contact (when the desire exists), footer. The brief may bend it — a recruiter may want experience before projects — but never at random: each section earns its place by answering the question the previous one left. Test the order aloud: "you are looking for X → here is that I do X → here are the proofs → here is who I am → write to me". If the sentence sounds right, the order is.

In the classic personal-page order, the detailed presentation comes…

  1. first, before everything
  2. in the footer
  3. after the proofs, once credibility is established
Answer

After the proofs: "who I am" is read once "what I do" is seen. The hero carries the one-sentence version.

Theory 2/2: zoning

The zoning is the section plan: one rectangle per section, in vertical order, each with its function and main content ("proofs: three project cards"). It is even poorer than the wireframe: no internal detail, just the page's partition. Its role is to reveal balance: three proof sections in a row tire, alternating rhythms (full width / cards / text) breathes. It is also the document where length is decided: each section must earn the scroll it costs. If a section serves neither the goal nor comprehension, it goes out — the brief arbitrates.

Zoning differs from a wireframe in that it…

  1. is in color
  2. shows only the section partition, no internal detail
  3. is drawn in Penpot
Answer

Zoning: the partition and order of sections. Wireframe: each section's internal detail. One decides the plan, the other the furniture.

Practice (30 min)

  1. List your candidate sections from day 45's content file.
  2. Order them along the argument; read the order aloud in "you are looking for X → …" format.
  3. Draw the zoning in the notebook: one rectangle per section, function + main content annotated, width rhythm noted.
  4. Arbitrate: any section serving neither the goal nor comprehension goes out, with the brief cited in support.

Success criterion: a zoning of four to six sections, order justified aloud, each section tied to the brief's goal.

Agent tip: "Here are my sections and my brief: [paste]. Critique the order as my typical visitor would: which question does each section leave, does the next answer it?" Trap: it will propose the standard order even if your brief bends it. Proof: every critique cites the brief, not a general usage.

Recap (10 min)

Three lines: order as argument, zoning vs wireframe, arbitration by the brief. Then redraw your zoning without notes.

Day 47 — Mobile wireframe

Goal: draw the page's complete mobile wireframe, with real content.

Theory 1/2: mobile sets the structure

Day 30 set mobile-first: start from the narrow screen. Today it is for real: a 375px board in Penpot, all the zoning's sections, stacked in the decided order. Day 18's conventions apply (bars, crossed rectangles, labeled buttons), with one difference: day 45's content is real, so text bars have the real texts' length — count the words, draw the matching line. This wireframe is the first length test: does the eight-word heading fit in two lines? Does the project card breathe? What overflows in gray will overflow in color: fix it now, it costs a stroke.

Theory 2/2: low-fidelity checks

Before moving to desktop, four checks: vertical hierarchy (in one column, order is hierarchy — day 20: the eye cannot skip a section), targets (every button is 44px tall, day 24), rhythm (inter-section spacings are constant — your space.12 or space.16, day 36) and completeness (all of the content file has a place, nothing is added). The mobile wireframe is the project's most important document: every decision it settles correctly is one the mockups will not have to redo.

Why draw mobile before desktop?

  1. it is faster
  2. the narrow screen forces order and priorities; widening will add instead of deleting
  3. desktop is outdated
Answer

Mobile-first: the constraint decides priorities. In one column, vertical order is hierarchy itself.

Practice (30 min)

  1. In Penpot, mobile board 375×812 (taller: the page scrolls — stretch the board to the content's height).
  2. Draw each zoning section in gray: bars at the real texts' length, crossed rectangles for visuals, labeled buttons.
  3. Run the four checks: hierarchy, 44px targets, steady rhythm, content completeness.
  4. Fix what overflows or is missing, in gray pencil, not by adding style.

Success criterion: the complete mobile wireframe, four checks passed and noted, zero color.

Agent tip: describe your wireframe section by section: "Check my completeness: here is my content file and the list of drawn blocks — what has no place?" Trap: it will propose adding sections. Demand: "flag gaps, add nothing". Proof: every content-file line points to a block.

Recap (10 min)

Three lines: why mobile first, the four checks, why bars at real length. Then redraw the wireframe from memory, in the notebook.

Day 48 — Desktop wireframe

Goal: adapt the wireframe onto the 12-column grid without betraying the mobile hierarchy.

Theory 1/2: enrich, not fill

Desktop offers width; the danger is filling it. The adaptation reverses day 31's patterns: stacking becomes columns (the hero text over 7, the visual over 5; the three projects in three 4-column cards), substitution unfolds (navigation becomes a visible bar), but the hierarchy does not change: what was first on mobile stays first to the eye. Day 20's grid is set first (12 columns, 24px gutter, ~96 margins) and the wireframe aligns block by block. Working width recalls day 3: text columns stay capped at ~65-75 characters — a paragraph over 12 columns is a fault, even on a 27-inch screen.

On desktop, a body-text paragraph occupies at most…

  1. 12 columns
  2. half, always
  3. the width that keeps 45-75 characters per line — often 6 to 8 columns
Answer

Line length bounds text, not the grid: 6-8 columns depending on the mockup. Twelve columns of body text are illegible.

Theory 2/2: the first screen

The part visible without scrolling ("above the fold") carries a special weight: day 44's benchmark showed it — it must hold who + for whom + action. On desktop, the hero has horizontal room: text on the left, an optional visual on the right — but the main action stays in the first screen, no exception. Beware the fashionable full-screen hero: if it occupies exactly 100% of the height, the visitor does not know there is more. Keep a fragment of the next section visible at the bottom: it is the promise of the scroll.

A hero occupying exactly 100% of the screen height risks…

  1. the visitor not knowing there is more: keeping a fragment visible promises the scroll
  2. bad search ranking
  3. nothing, it is standard practice
Answer

The exact full screen looks like a complete page. A fragment of what follows visible at the bottom says "keep going".

Practice (30 min)

  1. In Penpot, desktop 1440px board + 12-column grid (24px gutter, 96px margins).
  2. Adapt each mobile-wireframe section onto the grid: columns, cards, visible navigation bar.
  3. Check: hierarchy identical to mobile, texts capped at 6-8 columns, main action in the first screen, fragment of the next section visible.
  4. Squint test of both wireframes side by side: same reading order.

Success criterion: the desktop wireframe aligned on the grid, identical hierarchy, complete first screen (who/for whom/action).

Agent tip: "Here is my mobile wireframe described block by block: […]. Propose each section's column split (over 12) for desktop, justifying by hierarchy." Trap: it will balance everything into equal columns — asymmetry (7/5) serves hierarchy. Proof: every proposal cites the block's rank in the mobile hierarchy.

Recap (10 min)

Three lines: enrich without filling, the text-column cap, the scroll's promise. Then redraw the column split without notes.

Day 49 — Art direction 1/2: the moodboard

Goal: explore two to three visual directions and materialize them as moodboards.

Theory 1/2: deciding the atmosphere before the colors

Art direction is the choice of an atmosphere serving the message: "sober and precise", "warm and crafted", "bold and dense". It is decided in words first: three adjectives drawn from the brief (your typical visitor must recognize themselves, not only you), then a moodboard: a board juxtaposing screenshots, candidate typefaces, colors, textures — not to copy, but to see whether the pieces form a system. Two or three distinct directions, not ten: forced variety (one "classic" direction, one "lively") clarifies the choice. The moodboard is never shown as-is to a client or recruiter: it is a decision tool, not a deliverable.

Theory 2/2: typefaces carry half the atmosphere

Day 2 showed it: serif and sans-serif do not say the same thing. For a personal page, two strategies suffice: one single family sans-serif in several weights (Inter, Source Sans — the safe road, distinction comes from sizes and weights), or two contrasted families (a serif for headings — Merriweather, Fraunces — a sans-serif for text: more character, more risk). Pairing rules: contrast roles, not neighboring families (two close sans-serifs = an invisible but perceptible taste fault), and check both candidates on real text — accented capitals and tall punctuation betray an ill-equipped typeface in languages that use them.

Pairing two close sans-serifs (Inter + Roboto) is…

  1. good practice
  2. a fault: role contrast must be clear — either one family, or frankly different families
  3. mandatory on the web
Answer

Two close families look alike enough to clash, not enough to merge. One family with weights, or two frankly contrasted families.

Practice (30 min)

  1. Draw three adjectives from your brief; write them at the top of the notebook.
  2. Build two moodboards (two Penpot pages or two notebook pages): for each, one candidate typeface tested on your real heading (Google Fonts), one candidate accent color, two inspiration screenshots.
  3. Write under each moodboard how it serves the three adjectives — and what it risks.

Success criterion: two distinct directions, each tied to the brief's adjectives, typefaces tested on the real heading.

Agent tip: "My brief says: [3 adjectives]. Compare these two directions: [describe typefaces + colors]. Which serves each adjective best, and what does each risk?" Trap: it will pick the most "trendy". Demand an adjective-by-adjective ruling. Proof: every argument cites a brief adjective and a visible property (weight, serifs, saturation).

Recap (10 min)

Three lines: adjectives first, moodboard next; the two typography strategies; the real-text test. Then recite your three adjectives without notes.

Day 50 — Art direction 2/2: palette and tokens

Goal: freeze the chosen direction into a measured palette and named tokens.

Theory 1/2: from atmosphere to values

Today you choose — and you prove. The chosen direction becomes: a 60-30-10 palette (background neutral, text color, accent, plus the semantic error/success), a type scale (16px base, chosen ratio, day 4) and the finishes (corner radius, shadow style, border thickness — day 13). Every value becomes a token (day 35), measured before entering: every text/background pair passes AA in WebAIM (day 23), the dark version is derived right now (day 33) — discovering it on day 54 would cost a redo. This is the session where the project stops being an intention: everything after only applies decisions already made.

Theory 2/2: the project's style sheet

Record everything in the notebook on one page, the "style sheet": primitive and semantic tokens (two sets: light, dark), the text scale with roles (body, small, section-heading, hero), the spacing scale, radius, shadow, durations (day 39). This page is a promise to your future self: no value outside this sheet will enter the mockup. When the temptation of a "slightly different" gray comes, the answer is: add a token, or give up. Days 51 to 54 will draw fast, because everything is already decided.

Why derive the dark palette as early as day 50?

  1. because a contrast measured late costs a redo: both themes are measured before drawing
  2. because dark mode is mandatory
  3. to impress at the benchmark
Answer

Measure early: every pair of both themes passes AA before the first mockup. Discovering a failure on day 54 means redoing four days.

Practice (30 min)

  1. Pick the direction (reread the risks written on day 49); write in the notebook why the other is dropped.
  2. Freeze the complete palette and measure every pair in WebAIM, light theme then dark. Fix by lightness.
  3. Write the style sheet: all tokens, both value sets, the scales, the finishes.
  4. Enter the tokens in Penpot (sets + themes, day 36).

Success criterion: a one-page style sheet, every pair AA in both themes, tokens entered in Penpot.

Agent tip: "Here is my light palette and its measured ratios: […]. Derive the dark palette (day 33 rules) and list the pairs to re-measure." Trap and proof, unchanged since day 23: its ratios do not count, only WebAIM counts. Have it produce the list, measure yourself.

Recap (10 min)

Three lines: what the direction becomes, why measure both themes now, the style sheet's promise. Then rewrite your main tokens without notes.

Day 51 — Mockup 1/4: header and hero

Goal: draw the mobile header and hero, entirely from tokens.

Theory 1/2: the hero is a drawn sentence

The hero carries the brief's three elements: who, for whom, action. Its drawing applies all of module 1: the heading at the scale's largest step, tighter line height (1.1-1.2 — large sizes need less, day 3), the short presentation at body size, the primary button in accent, 44px target, and grouping space: heading and button tied, the whole detached from what follows (day 9). The mobile header: logo or name on the left, hamburger labeled "Menu" on the right (day 27). Every value comes from day 50's tokens — if a value is missing, you do not invent it: you add the token to the style sheet, then apply it.

Theory 2/2: working in layers, still

Day 19's order stays the law: typography first (library styles applied to real texts), color next (tokens), spacings (Flex layout where the section fits, day 21), details last. The temptation to "finish" the button before the heading is placed is the shortest road to endless touch-ups: each layer stabilizes the next one's dimensions. At the end of the session, the first mobile screen exists: squint test, then day 32's protocol (steps 2 and 8).

If a value is missing from the style sheet mid-drawing, you…

  1. invent it by eye
  2. add the token to the style sheet, then apply it
  3. copy the neighbor's
Answer

Style sheet first: an improvised value is a programmed divergence between screens and themes.

Practice (30 min)

  1. On a 375px mobile board, draw the header (name + labeled hamburger) with your tokens.
  2. Draw the hero: real heading (largest step, 1.15 line height), short presentation, primary button (day 17's component if reusable).
  3. Apply the layers in order; every new value goes through the style sheet first.
  4. Squint test + contrast check of the button pair and the heading.

Success criterion: header + mobile hero finished, 100% tokens, squint test conform, AA contrasts checked.

Agent tip: "Here is my hero described (sizes, tokens, spacings): […]. Check it against the rules: line height of large sizes, button target, proximity grouping." Trap: it will flatter. Demand: "cite every gap, or say explicitly there is none". Proof: every cited gap is found in the mockup.

Recap (10 min)

Three lines: the hero's three elements, the layers' order, the missing-token rule. Then redraw the hero in the notebook without notes.

Day 52 — Mockup 2/4: the sections

Goal: draw the mobile content sections: projects, presentation, contact.

Theory 1/2: the project card, molecule of the day

The project card is the page's central molecule: a visual (or initials if you have none — a rectangle tinted with desaturated accent does very well), the project title, two sentences (problem/role/result, day 45), a discreet link or button. Build it in Flex layout (day 21: the card grows with the text), factorize it as a component (day 17): the three projects are three copies of one component, only contents change. It is day 12's rule applied to your own page: three cards identical in structure — consistency is what reads as professional. The projects section stacks them (mobile) with your scale's constant gap.

Theory 2/2: text sections and contact

The presentation is a text section: section heading, paragraph capped at comfortable line length even on mobile (375px lands there naturally, day 3). The contact section repeats the main action: same button, same label as the hero (day 12 — "Save" does not become "Confirm"), plus links as underlined text. Vertical rhythm: between sections, your largest spacing; inside, the related spacings (day 9). Each finished section passes the same micro-protocol: squint test, contrast of new pairs, targets.

The contact section's button uses…

  1. a different label, for variety
  2. a different style, to mark the end
  3. the same component and same label as the hero
Answer

Same component, same label: repeating the single action is a convention serving the brief's goal.

Practice (30 min)

  1. Build the project card in Flex layout; make it a component; place three copies with real contents.
  2. Draw the presentation and contact sections (main action repeated, links underlined).
  3. Tune the vertical rhythm: constant inter-section spacing, related internal spacings.
  4. Micro-protocol on each section: squint, contrasts, targets.

Success criterion: the mobile page complete from top to contact, three cards from one component, steady rhythm, micro-protocol passed.

Agent tip: "Here is my project card's structure: […]. List everything that must stay identical between the three copies and what may vary." Trap: it will vary the structure "for personality". Proof: the three copies differ by content alone — check by comparing layers in Penpot.

Recap (10 min)

Three lines: the project card's anatomy, why a component, the two-level rhythm. Then redraw the card without notes.

Day 53 — Mockup 3/4: footer and states

Goal: finish the mobile page: footer, interactive states, edge cases.

Theory 1/2: the footer and the states

The footer is the safety net: whoever reaches the bottom without having clicked looks there for contact, links, legal. It repeats the main action one last time, the secondary links, and stays visually calm (a slightly distinct background — a surface token, day 34). Then come the states: take every interactive element of the page and check its states exist (day 13): buttons (five), links (hover, focus), fields if any. Draw the states strip next to the page: it will be the documentation's first deliverable (day 38). Finally, day 19's edge cases: the longest project title, the longest presentation — the page must absorb them without breaking.

Theory 2/2: the "cold" reread

Before adapting, one discipline: let the page rest a night (or an hour), then reread it as a visitor. Three questions, in order: what does this page offer me? (does the hero answer in five seconds?); what proves it? (are the projects credible and legible?); what can I do now? (is the action visible, repeated, labeled?). Every "meh" becomes a finding in day 14's format: measurable, rule cited, fix proposed. It is the last easy pass: after desktop and dark, every correction costs three times more.

We reread the mockup "cold" before adapting because…

  1. every fix costs more once the other widths and themes are drawn
  2. mobile does not matter
  3. the session must be filled
Answer

A fix's cost grows with the number of adaptations: mobile alone today, ×4 tomorrow. Rereading now is the project's economy.

Practice (30 min)

  1. Draw the footer: repeated action, secondary links, surface background.
  2. Draw the states strip of all the page's interactives (buttons, links): rest, hover, focus, active, disabled.
  3. Test the edge cases: longest project title, longest presentation, inside the component.
  4. Close everything; come back after a break and note three findings in full format; fix what is measurable.

Success criterion: mobile page finished (footer included), states strip drawn, edge cases absorbed, three reread findings handled.

Agent tip: "Here is my mobile page described section by section: […]. Play the discovering visitor: answer the three questions (what, proof, action) citing precise elements." Trap: it will paper over holes out of politeness. Demand: "if an answer is not readable in my description, say 'not found'". Proof: every answer cites an existing element.

Recap (10 min)

Three lines: the footer's role, the states strip, the three cold questions. Then recite the three questions without notes.

Day 54 — Mockup 4/4: desktop and dark mode

Goal: adapt the complete page to desktop, then switch both to dark.

Theory 1/2: the disciplined adaptation

Day 48's desktop wireframe already made the structural decisions; today you dress it, section by section, with the same tokens and the same components. The discipline fits in one sentence: no new decision — hierarchy, texts, colors, states are the mobile ones; only geometry changes (columns, grid, visible navigation bar, side-by-side cards). If a value is missing, same rule as day 51: the token joins the style sheet first. A well-made adaptation is almost boring: proof that the system (tokens + components) works in your place.

Theory 2/2: the theme switch

Tokens and their two themes (days 36, 50) prove themselves today: switch the theme in Penpot and walk both widths in dark. What breaks is a forgotten token (a hand-typed color somewhere) or an unplanned asset (day 34: images, shadows). Fix at the source: the color becomes a token, never a local touch-up. Finish by re-measuring the key pairs in dark (body text, accent, focus) — measured on day 50, confirmed today on the real drawing.

A color breaks at the dark switch. The fix is…

  1. touch up that occurrence by hand
  2. replace it with the role token: the fix happens once, at the source
  3. drop dark mode
Answer

At the source: a local touch-up recreates the divergence tokens exist to prevent.

Practice (30 min)

  1. Draw the complete desktop page on its grid, section by section, tokens and components from mobile.
  2. Switch both widths to the dark theme; hunt every breakage and fix it at the source (token).
  3. Re-measure in dark: body text, button, focus — WebAIM, three ratios noted.
  4. Day 32's protocol on the four versions (steps 2, 3, 4, 8): one line per step in the notebook.

Success criterion: four versions (mobile/desktop × light/dark) consistent, zero color outside tokens, dark ratios confirmed.

Agent tip: "Here is my token list with both values: […]. Detect cross-theme inconsistencies (a role without a dark value, two roles with the same value)." Trap: it will flag imaginary "risks". Demand: "only gaps and duplicates". Proof: every reported line checks against the style sheet.

Recap (10 min)

Three lines: no new decision, the switch as token test, fixing at the source. Then narrate the adaptation without notes.

Day 55 — The project's accessibility audit

Goal: run the full project through the accessibility sieve and fix what fails.

Theory 1/2: the project's checklist

The audit replays, in order, everything days 22 to 24 set: contrasts (every text/background pair of both themes measured — not the style sheet's, the real drawing's), typography (body ≥ 16px, line height 1.4-1.6, lines ≤ 75 characters), targets (every interactive ≥ 24px, 44 aimed), focus (a drawn indicator for every interactive, 3:1), color alone (underlined links, errors with icon + text, grayscale test), contents (alts written, action labels, no reference to position or color), motion (a reduced version planned for every animation). The A11Y Project checklist serves as cross-reference.

Theory 2/2: fixing without breaking

Every failure is handled in day 28's format: measured observation, rule, fix — at the source (token, component), never at the occurrence. And every fix re-passes the checks it risks breaking: darkening an accent changes its contrast on three backgrounds, not one. The audit ends with the conformance table in the notebook: one line per check, OK or fixed + proof. This table is the most precious part of the file: a recruiter or a client can verify it without taking your word.

An accent darkened to pass AA on the background must be re-measured…

  1. only on that background
  2. never, the math is enough
  3. on every background where it carries text
Answer

On every background: fixing at the source changes the token, hence every pair using it.

Practice (30 min)

  1. Write the checklist in the notebook, seven families, one line per check.
  2. Run each check on the page's four versions; measure, do not assume.
  3. Fix every failure at the source and re-measure the pairs touched.
  4. Finish the conformance table: every line OK or fixed + numbered proof.

Success criterion: the complete conformance table, seven families, every failure fixed at the source with its proof.

Agent tip: "Here is my conformance table: […]. List the WCAG 2.2 AA checks a page like this should also pass and that are missing from it." Trap: it will list code criteria (ARIA) beyond a mockup's reach. Demand: "only what can be checked on a drawing". Proof: every addition cites its criterion number, checked in the W3C quick reference.

Recap (10 min)

Three lines: the seven families, fixing at the source, the table as proof. Then recite the seven families without notes.

Day 56 — The project's prototype

Goal: link the page into a shareable prototype, with its reduced-motion version documented.

Theory 1/2: prototyping a single page

A personal page prototypes differently from an app: the journey is vertical. The links to create: the header to its anchors (the "Contact" button scrolls to the section), the mobile menu opening (an overlay from the hamburger), outbound links (simulated), and back to top. In Penpot, the Prototype tab links boards; the overlay is set with "open overlay" positioned manually. Keep the prototype light: it must let a tester walk the page and open the menu, not simulate a whole site. Create the share link at the end of the session — it is day 57's test object.

Theory 2/2: documenting motion

The Penpot prototype will not carry your final animations: they are documented. Take day 39's sheet back: for each of the page's micro-interactions (hovers, menu opening, back to top), write the full line in the notebook: trigger, change, duration, curve, prefers-reduced-motion version. Three to five lines suffice — a sober personal page has no more. This document joins the file: the developer who builds the page will have nothing to guess, and you will have proven the motion was designed, not suffered.

In the file, each micro-interaction is documented with…

  1. trigger, change, duration, curve, reduced-motion version
  2. a video
  3. nothing, animations are judged by eye
Answer

Day 39's full line: what is not written will be improvised — and reduced-motion is the first casualty.

Practice (30 min)

  1. In Penpot, link: navigation anchors, hamburger → menu overlay, back to top.
  2. Test the full journey in View mode, mobile and desktop.
  3. Create the share link and check it in a private window (no account).
  4. Write the motion sheet: one full line per micro-interaction.

Success criterion: a shareable prototype without dead ends, working menu, and the motion sheet in the notebook.

Agent tip: "Here are my prototype's links: [list]. Build the graph and flag any dead end or any interactive element without a destination." Trap: as on day 40, it will assume obvious links. Demand the declared list only. Proof: every reported dead end reproduces in View mode.

Recap (10 min)

Three lines: what a single page's prototype must allow, the motion sheet, the link tested without an account. Then recite the mandatory links without notes.

Day 57 — The critique

Goal: submit the project to external critique and self-critique, and sort the feedback.

Theory 1/2: testing with a human

Day 41's method, this time for real: two tasks ("who is this person and what do they offer?", "contact them"), the prototype link, silence, observation. Add the five-second test on the hero: page shown five seconds, hidden, "what do you remember?". If the answer is not your brief's sentence, the hero is not working. One tester is enough today; two is better. Everything is recorded in behavior / suggestion / taste format — and day 43's brief arbitrates: feedback serving the typical visitor weighs, personal taste is archived without guilt.

Theory 2/2: self-critique on the table

In parallel, self-critique: day 14's six-criterion grid applied to your four versions, plus a reread of the file (brief → content → zoning → wireframes → mockups → tokens → audit → prototype) hunting for chain breaks — a brief decision missing from the mockup, an orphan token, a numbered commitment never checked. Honest critique ends with a prioritized iteration list: use first (what blocked the tester), measurements next (a contrast, a target), comfort last (a rhythm, an alignment). It is day 58's work list, not an inventory of regrets.

Facing "I don't like the blue" feedback, the brief serves to…

  1. change the blue immediately
  2. arbitrate: personal taste is archived, only feedback serving the typical visitor weighs
  3. delete the brief
Answer

The brief arbitrates: it decided the visitor and the goal; one tester's taste changes neither.

Practice (30 min)

  1. Run the human test (two tasks + five seconds). Record every observation.
  2. Run the self-critique: six criteria on the four versions, reread of the full chain.
  3. Merge into one prioritized iteration list: use, measurements, comfort. Every line in observation + rule + proposal format.

Success criterion: one test run and recorded, the self-critique written, a prioritized iteration list ready for tomorrow.

Agent tip: "Here is my project described (brief, sections, tokens, audit): […]. Play three distinct testers — a hurried recruiter, a peer from the field, a novice — and report what each sees in five seconds and where they hesitate." Trap: three simulated opinions are not worth one human; the LLM prepares and complements the test, it does not replace it. Proof: cited hesitations point to real elements of the mockup.

Recap (10 min)

Three lines: the test protocol, arbitration by the brief, iteration priority order. Then recite the three priorities without notes.

Day 58 — Iterate

Goal: apply the prioritized iterations, measure every fix, freeze the result.

Theory 1/2: iterating is fixing at the source

Day 57's list runs in its order — use, measurements, comfort — and every fix follows day 54's rule: at the source (token, component, content), never at the occurrence; then propagated to the four versions; then re-measured (the check it serves and those it touches, day 55). An iteration closes when its proof exists: "the tester did not see the contact button → button duplicated in the projects section → re-test: found in 4 seconds". Without proof, a fix is a hope. If a fix reveals another, it joins the list at its priority — you do not "take the opportunity" of being in the file to repair on the side without noting it.

Theory 2/2: knowing how to freeze

The project's last risk is endless iteration: there will always be a fairer gray. The freeze criterion was written on day 43: the brief's numbered commitments. All met + "use" and "measurements" iteration lists at zero = the project is done. What remains in the "comfort" column joins an explicit "later" list — the polite version of the non-goal: not "forgotten", but "not now, written here". Freezing is not giving up: it makes the project showable, and showing is part of the job.

The project freezes when…

  1. you run out of ideas
  2. the deadline has passed
  3. the brief's commitments are met and the use/measurement iterations are settled, with proofs
Answer

The brief decides the end: commitments met, high priorities settled and proven. The rest joins the "later" list, in writing.

Practice (30 min)

  1. Run the iteration list in order: fix at the source, propagate to the four versions, re-measure.
  2. For each "use" iteration, re-test the precise point (yourself cold, or the tester if available).
  3. Close: check every brief commitment one by one, write the "later" list.
  4. Export the final screenshots (four versions) from Penpot — they join the file.

Success criterion: every settled iteration has its proof, the brief's commitments all ticked, the final exports made.

Agent tip: "Here is my iteration list and my fixes: […]. Check each fix has its proof (measurement or re-test) and flag those without." Trap: it will declare the proof "implicit". Demand: "a proof is a number or a test, else the line is not settled". Proof: every settled line cites its number.

Recap (10 min)

Three lines: source fix + propagation + re-measurement, an iteration's proof, the freeze criterion. Then recite the freeze criterion without notes.

Day 59 — Final checklist and review

Goal: close the project's file, check the path's checklist, decide what comes next.

Theory 1/2: the final file

The deliverable you show is not an image: it is a file in eight pieces — the brief (D43), the benchmark (D44), the content (D45), the zoning and wireframes (D46-48), the style sheet and tokens (D50), the mockups in four versions (D51-54), the conformance table (D55) and the prototype with its motion sheet (D56), closed by the iteration journal (D57-58). This file says exactly what an employer or a client wants to know: this person decides with rules, measures what they claim, and finishes what they start. Publish it: the Penpot share link, the screenshots, the cleaned notebook — a page of your future site, precisely.

Theory 2/2: what comes next

The path ends, practice continues — design is only kept up by exercise. Three roads: redesign one real page a month with day 28's method (the notebook keeps your before/afters); read the public systems (DSFR, GOV.UK, Carbon) as continuing courses — every component sheet there is a lesson; and code your mockups: HTML/CSS is this path's natural continuation (tokens become variables, components become elements), the site's web development path takes over. Keep the rhythm: one steady hour beats a heroic week — you know it, you did it fifty-nine times.

The final file proves above all that…

  1. you decide with rules, measure what you claim and finish what you start
  2. you can use Penpot
  3. you have good taste
Answer

Tool and taste cannot be proven; method can. That is what the file documents, piece by piece.

Practice (30 min)

  1. Assemble the file: the eight pieces, in order, each up to date.
  2. Run the checklist from the path's home page, item by item. For each ticked box, cite the proof (session, measurement, deliverable).
  3. Write the review in the notebook: what you do without notes today that you could not do on day 1; the two points you will rework first.
  4. Publish or share the file with one person of your choice.

Success criterion: the complete file, the checklist passed with its proofs, and the review written. The path is done when the file can be shown.

Agent tip: "Here is my eight-piece file: [summaries]. Play the recruiter: what convinces you, what leaves you hungry?" Trap: it will judge the summary, not the pieces — its remarks are rereading leads, not a verdict. Proof: every reserve cited checks against the piece concerned.

Recap (10 min)

Three lines: the eight pieces, what the file proves, your road ahead. Then — one last time — recite the full method without notes: look, measure, decide, prove.

Found this useful? Tell us what to measure next.

Comments

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