Product Design

A formal heuristic evaluation of one complete task in an app you use and dislike — the deliverable working designers are actually paid to produce.

1. Pick one task, end to end. Sign-up to first value, or checkout, or cancelling a subscription. Screenshot every screen and every state, including errors and empty states.
2. Walk it twice. Once as a first-time user, recording impressions; once step by step against Nielsen's ten heuristics. The two passes catch different problems.
3. Log every violation identically. Screenshot, heuristic violated, what a user would expect, what actually happens, and the likely consequence. Expect 15–25 findings on a real product.
4. Rate severity and justify it. Use the 0–4 scale, scoring frequency, impact and persistence separately. Unjustified severity is just opinion.
5. Propose fixes that fit their constraints. Changes their team could ship this quarter, shown as marked-up screenshots — not a redesign of the product.
6. Rank by severity against effort. Present the top five in that order. Twenty-five unranked findings get skimmed and ignored.

Scope guard: one task, no redesign concept. One rigorous evaluation is more persuasive in a portfolio review than three unsolicited redesigns.

A moderated usability test of three tasks with five people who are not designers, run to a script and synthesised into ranked findings.

1. Write the script before recruiting. Three tasks phrased as goals — "find out what it would cost to ship two of these to Delhi" — never as instructions like "click the shipping tab". A leading task produces a useless test.
2. Recruit five who resemble the real user. Not five designers, not five friends who will be kind. Note how each differs from your target so you know what your findings do not cover.
3. Say four sentences, then stop talking. Think aloud; there are no wrong answers; we are testing the product, not you; I cannot help during the task. Then let the silence run — the silence is the data.
4. Record behaviour, not opinion. Time on task, completion, hesitation points, and what they clicked versus what they said. Stated preference afterwards is the least reliable thing in the session.
5. Synthesise across sessions. Group observations into issues, then count how many of the five hit each, how badly, and whether they recovered unaided.
6. Rank, and name the surprise. Order by frequency times severity, and write the one finding that contradicted your expectation. If nothing surprised you, the tasks were too easy.

Scope guard: five moderated sessions, three tasks, no survey and no analytics. Five is enough to find most of it, and watching is the whole point.

A semantic colour system and type scale that provably passes contrast in both light and dark themes — delivered as a contrast matrix, not a swatch grid.

1. Name by role, never by colour. surface, surface-raised, text, text-muted, border, accent, and the four states — success, warning, danger, info. "brand-blue-600" tells a component nothing about when to use it.
2. Build the ramps in a perceptual space. Nine steps per hue in OKLCH or LCH so lightness steps evenly — Leonardo or oklch() directly. Hex picked by eye is uneven, and the dark theme is where it shows.
3. Derive dark, do not invert it. Map roles to different steps for dark, with lower saturation on large surfaces. Flipping lightness is what produces the muddy dark themes you have seen.
4. Build the matrix. Every text role against every surface role, with the measured ratio, in both themes: AA for body text, 3:1 for large text and for UI borders and focus rings.
5. Check what colour alone is carrying. Simulate deuteranopia and protanopia, and make sure every state signalled by colour is also signalled by an icon, a weight or a label.
6. Ship it as tokens. CSS custom properties for both themes, a type scale of six sizes with line height and weight, and one demo page built from the tokens alone.

Scope guard: one accent hue, one neutral ramp, four states. The contrast matrix is the artefact; the swatch grid is what everyone else submits.

Ten components built on your tokens, with every variant and state, documented the way the GOV.UK Design System documents its own — including when not to use each one.

1. Pick the ten that compose. Button, text input, select, checkbox and radio, card, modal, table, alert, navigation, empty state. Enough to build a real screen from nothing else.
2. Every state, every component. Default, hover, focus-visible, active, disabled, loading, error, and read-only where it applies. Missing states are what makes a system unusable during build.
3. Bind to tokens, never to values. Figma variables or CSS custom properties throughout. Then flip the theme and confirm all ten change with no manual edits.
4. Document the decision, not the anatomy. When to use it, what to use instead, the content rules — button labels as verbs, error text that says what to do — and one accessibility note each.
5. Record what you rejected. A paragraph per component on the alternative you tried and why it lost. This is the section that shows you can design a system rather than draw one.
6. Prove it on a real screen. Assemble a settings page or a checkout using only these components. Anything you have to draw by hand is a missing component or a missing variant — list which.

Scope guard: ten documented properly beats forty undocumented. No icon set, no illustration style, no marketing components.

One case study built from research and design you actually did — with the version that failed left in, because a case study with no dead ends reads as fiction and reviewers know it.

1. Open on the constraint. The real one: two weeks, a legacy API, a regulatory requirement, one engineer. Constraints are what make the decisions worth reading.
2. State the problem with evidence. A number or a quote from your five-user test, not "users were frustrated". Say how you knew and how confident you were.
3. Show the version that failed. The design you tested that did not work, what specifically broke in the sessions, and the moment you decided to change direction.
4. Explain exactly three decisions. For each: the options, what you chose, the trade-off you accepted, and who ends up worse off. Three explained beats twenty screenshots.
5. Report the outcome honestly. Measured where you can; estimated and clearly labelled as an estimate where you cannot. Never a number you cannot source.
6. End with what is still wrong. What you would fix next and why it was not done. Reviewers read this section to find out whether you can see your own work clearly.

Scope guard: one project, roughly 1,200 words, process compressed but visible. No hero mockup on a floating phone, no invented metrics.