Skip to content
Process

Brief
to build,
without
the drift

A practical method for complex product and design systems work

I use one repeatable loop: clarify the outcome, map the system, explore with evidence, turn decisions into reusable parts, and stay with the build until it ships. It is structured enough for enterprise teams and flexible enough for the messy middle of real work.

AI speeds the research synthesis, variation, prototyping, and documentation passes. It does not replace judgment. The goal is fewer handoff gaps and a clearer path from business need to working interface.

Years designing complex software

23

Design systems built from scratch

5

FIBER components documented

54

Avant marketers enabled

350+

Edison, GE Healthcare

Red Dot
2020

Methodology

The working model

The method follows the same logic used by strong product teams: understand the problem, make the structure visible, explore alternatives, test the decision, and document what should scale. Each phase ends with a gate so the work moves forward because the decision is clear, not because the calendar says so.

01 · Clarify

Name the outcome

Turn the request into a measurable problem. I capture the audience, business goal, constraints, risks, and the decisions the work has to settle. If the brief contradicts itself, the contradiction is written down and resolved before the project pretends to be simple.

Decision gate

A shared problem statement, success metric, and assumption list with owners.

02 · Map

See the whole system

Before visual design, I map the flow, state model, content model, data dependencies, and component inventory. The goal is to see the product as a connected system so the team can estimate the right shape, not just the visible screen.

Decision gate

Critical paths, edge states, and technical constraints reviewed with product and engineering.

03 · Explore

Compare real options

Develop a small set of meaningfully different directions, using real content and the hardest screens. AI can multiply the draft options. Taste, evidence, and feasibility decide which one survives.

Decision gate

One recommended direction, the trade-offs behind it, and the alternatives rejected.

04 · Systemize

Make decisions reusable

Design the interface as a system while designing the screens. Tokens, components, interaction states, accessibility behavior, and content rules are captured where the team will use them.

Decision gate

Reusable decisions live in the library or the spec before they appear in the finished screen.

05 · Ship

Stay through the build

Handoff is active participation: walkthroughs, QA, staging review, and governance for what changes next. The work is not done when the file is tidy. It is done when the product can keep improving without drifting.

Decision gate

Engineering confirms the build path, design QA signs off, and the next-system backlog is clear.

Why it works

A clearer path through messy work

Decisions are easier to make

Every recommendation names the option, the trade-off, and the reason. Stakeholders choose with context instead of reacting to taste.

The team sees risk earlier

Assumptions, constraints, edge states, and feasibility questions are surfaced before high fidelity makes them expensive to change.

Handoff becomes buildable

Engineers get behavior, states, tokens, accessibility notes, and content rules. The spec explains how the interface should survive real data.

The system lasts past launch

Components, documentation, decision logs, and governance keep the product from drifting the next time new work enters the pipeline.

01 · Four-minute read

Detailed method

The full operating model: working agreements, phase gates, weekly cadence, handoff requirements, ambiguity protocol, and the first 30 days inside a team.

Read the method → 02 · 26 slides, 20 minutes

From brief to build

The presentation version of the process: intake, the fork between system work and product work, mapping directions, and the handoff package developers receive.

Open the deck → 03 · 34 files, loadable

Skill library

Nine documented skills that move from brief intake to developer handoff, with rubrics, templates, and worked examples for repeatable AI-assisted design work.

Read the docs → 04 · The audit, eight-minute read

Pathfinder audited

A design system built from scratch, then evaluated with the skill library: source-backed counts, findings, evidence, and what the audit still cannot prove.

Read the audit →
Google Drive ↗ The source files Skill files, examples, and folder structure ready to review or reuse. Interactive The intake form Seven steps from raw brief to project file, with a sample to walk through Runbook Ten-minute live demo Four beats, with the exact prompts. Worked example Design-system drift report One primitive fix closing eleven findings. Worked example Critique of the work Seven fronts, ranked, each with a proposal. PDF Résumé Staff visual product design and design systems.

Run the method on your product

Send the brief, the product URL, or the system that is drifting. I will turn it into a structured path: what to learn, what to map, what to build, and what to hand off.

mikelrosenthal@me.com mikelrosenthal.com +1 (773) 490-6923