Mikel Rosenthal · Senior Designer
← Method

From
brief
to build

What happens between the moment requirements land and the moment an engineer starts

September 2026
Contents
01Intake: the first 48 hours
02The workspace: the skill library
03Mapping: six directions
04Handoff: what developers get
The claim

The process didn’t change. The cycle time did.

  • The same order of operations a good designer has always run: problem, evidence, structure, form, proof.
  • Claude is where the thinking gets written down, structured and stress-tested. Not where it gets decided.
  • Everything here is reproducible: same skills, same inputs, same shape of output, whoever runs it.
  • AI-forward in the workflow, hand-finished in what ships. Twenty-three years of judgment is the part that doesn’t automate.
Track record

Where the method came from

SystemWhereRole
EdisonGE Healthcare · 40+ clinical productsCore contributor · Red Dot 2020
FIBERBlue Cross Blue Shield · three teamsBuilt from nothing to 54 components
TUCMTransUnion · global, multi-regionSystem and visual identity
PathfinderAvant · regulated lendingSole design-systems contributor
EnterpriseVerizon · iOS, Android, webPost-rebrand audit and token layer
The arc

Ten weeks, end to end

Day 1 Week 1 Week 3 Week 6 Week 10 Intake Evaluate Map Design Hand off Brief becomes context Audit or overview Six directions System, then screens Spec, QA, release

The first week produces no screens on purpose. It produces the context everything after it is generated and judged against.

01

Intake

01 · Intake

The first 48 hours

  • Read everything once with no design tool open, and log every question it raises.
  • Rewrite the brief as one structured file: problem, metric, users, constraints, assumptions.
  • Take the real constraints from an engineer before trusting a single requirement.
  • Rank every assumption by what it costs us to be wrong about it.
  • Send back the three questions whose answers change the shape of the work.
01 · Intake

One file, not a folder

What’s in it

The problem in the client’s own words. The metric it has to move. The users and the job they’re hiring the product for. Hard constraints from engineering. Assumptions, ranked. Open questions, owned and dated.

Why it’s first

It is the context every later step reads from, and the thing re-read when scope drifts. A model amplifies whatever context it is given, so a vague brief buys confident, plausible, wrong output at speed.

02

The workspace

02 · The workspace

What a skill actually is

A description

What the skill does and when to use it. At rest, this is the only part in context. It is how the model knows the capability exists at all.

A procedure

The steps, the rubric, the output format. Loaded only when a task matches, so a library of ten costs almost nothing until one is needed.

Bundled files

Templates, checklists, schemas and scripts it opens on demand. Rubrics and report formats live here, versioned like code, not retyped.

02 · The workspace

The library: evaluating

SkillWhat it doesWhat ships with it
brief-intakeTurns a raw brief into the structured project fileIntake template, question bank
heuristic-auditRates a live product against heuristics and WCAG 2.2Rubric, severity scale, report format
ds-inventoryInventories components, extracts tokens, reports driftToken schema, coverage matrix
research-synthesisTranscripts into insights with counts and implicationsEvidence rules, insight template
02 · The workspace

The library: making and shipping

SkillWhat it doesWhat ships with it
flow-mapFlows, plus the full state matrix for every screenState checklist, notation
copy-standardsErrors, empty states and labels in the product’s voiceVoice guide, message patterns
a11y-specFocus order, roles, labels and contrast pairs per screenWCAG 2.2 checklist
handoff-specAnnotated spec, token export, state matrix, QA listSpec template, QA checklist
critiqueArgues against the work before the team sees itRubric, common-failure list
02 · The workspace

Two entry points, two first moves

Evaluating a design system

The question is coverage and consistency, so the work starts with artifacts: the code, the library, every screen that ships. It is a counting exercise before it is a taste one: what exists, what’s duplicated, what has drifted, what has no owner. Verizon’s post-rebrand system started exactly here.

A product design overview

The question is whether the thing does the right job, so the work starts with people: who uses it, what they are trying to finish, where they give up. Artifacts come second. A perfectly consistent product can still be the wrong product. SurePeople’s PRISM platform started here.

02 · Track A

Auditing a design system, in order

  • Inventory what actually ships, from the code and the screens, not the library’s contents page.
  • Diff the token layer against what engineering shipped, in Dev Mode and Code Connect, with a front-end engineer.
  • Build a coverage matrix: which screens use components, which use detached copies.
  • Score each component on states, accessibility, documentation and adoption.
  • Report drift with a cost attached and a sequenced fix list, not a list of sins.
02 · Track A

What the drift report says

FindingCountCostFix
Greys not on the ramp23Re-theming is impossibleMap to four steps
Button variants in code9Every screen re-decidesCollapse to three
Components with no focus state14Keyboard users stallFix the primitive once
Screens with detached instances31%Fixes stop propagatingRe-link the top ten flows
Spacing values in use17Rhythm reads accidentalSnap to the 8-point scale
02 · Track B

A product overview, in order

  • Name the jobs: what someone hires this product to finish today, in their language.
  • Map the current journey end to end, including the parts that happen outside the product.
  • Draw the information architecture as it is, then as it should be, and diff the two.
  • Build the metric tree: the business number on top, the behaviors that move it beneath.
  • Pick the two flows carrying the most value and park everything else, in writing.
03

Mapping

03 · Mapping

Up, down, across

Up: the business

Every screen resolves to a number someone is accountable for. If the path from pixel to P&L can’t be traced, the work is decoration.

Down: the system

Every element resolves to a token and a component. Anything that can’t is either a gap in the system or an indulgence.

Across: siblings

The same pattern wherever it already appears. Most problems have been solved once in this product already. Adopt, don’t invent a second one.

03 · Mapping

Back, forward, out

Back: the data

What the API actually returns: slowly, partially, stale, or not at all. The data model is a design input, not an implementation detail.

Forward: time

Every state the screen will pass through, and what it looks like at ten times the content and three years of accumulated cruft.

Out: the edges

Keyboard, screen reader, small screen, long strings, other languages, no network. The edges are where the product loses people quietly.

03 · Mapping

Pathfinder, mapped six ways

  • Up: the number was whether a borrower finishes the application or abandons it.
  • Down: the system shipped alongside the product, never ahead of it. Patterns earned their place.
  • Across: states carried from application into servicing rather than solved a second time.
  • Back: a regulated lender’s constraints. What underwriting can return, and when, is a design input.
  • Forward & out: error handling and edge cases, with WCAG 2.2 held as a gate, not a cleanup pass.
03 · Mapping

54

Production components in FIBER, adopted by three teams, with a coded library that matched the design source in naming, structure and behavior. Parity is the whole point. A component that doesn’t match its code is a suggestion.

04

Handoff

04 · Handoff

What a developer gets

ArtifactWhat’s in itWhat it prevents
Token exportColor, type, spacing, radius, elevationTranslation and eyeballing
State matrixDefault, hover, focus, active, disabled, loading, error, emptyStates invented in code
Annotated flowsBehavior written as rules, not redlinesBreakage on real content
Accessibility specFocus order, roles, labels, contrast ratios, 44px targetsA final-week audit panic
Design QA listChecked on staging before releaseHandoff ending at delivery
04 · Handoff

What is never delegated

  • The problem statement. If it wasn’t argued with a human, it isn’t agreed.
  • Talking to users. A synthesis skill is worthless without transcripts someone earned.
  • The final visual call. Models average toward the mean. Hand-finished is the whole difference.
  • Anything stated as fact. Every number in a deliverable traces to a source, or it gets cut.
04 · Handoff
The tooling compresses the loop. It doesn’t decide what the loop is for.
The short version, if we only have a minute
Mikel Rosenthal · Senior Designer

See it
run
live

Given a brief and an hour: the intake file, the skills that fire, and the first map, on your product

mikelrosenthal@me.com  mikelrosenthal.com

← MethodSkill libraryCase studyFiles ↗