Weeks, aligned to dev milestones
6–12
Daily overlap with Pacific time, minimum
4h
Four working agreements
01
Every screen has a metric behind it
If the number a feature is meant to move can’t be stated, that is a strategy conversation, not a design task. An hour spent finding the metric is cheaper than two weeks designing the wrong thing.
02
Decisions are recorded in the file
Decisions, assumptions and open questions live next to the frames they affect, not in a call half the team missed. A remote team runs on written artifacts or it runs on re-litigation.
03
A recommendation, not a menu
The client holds final say. The designer’s job is to make the choice easy: the recommended option, what it trades, and the alternative rejected and why.
04
Handoff is a phase, not a delivery
Design stays in the sprint. Office hours for engineers, design review on staging, and spec corrections when reality disagrees with the drawing. It will.
The phases
Each phase ends in a decision, not a deliverable
The phases compress or stretch with scope. An MVP runs in six weeks. An enterprise platform takes twelve. The order never changes, and no phase closes without its gate. The gate protects the budget. A wrong call in phase 01 is cheap to reverse. The same call in phase 05 is not.
01 Frame
Week 1
Agree on the problem before anyone opens Figma. Most briefs arrive describing a solution. The first task is to find the problem underneath it and write down how success will be measured.
Activities
- A 90-minute stakeholder alignment workshop
- A constraints inventory with the lead engineer
- A competitive teardown of three to five products
Outputs
- A one-page problem statement, in the client’s words
- Success metrics mapped to business KPIs
- A ranked assumption register, each with an owner
- A research plan scoped to the decisions it informs
The gate
The client signs the problem statement and the metrics. If the metric can’t be written, the feature isn’t designed yet. The work returns to strategy.
02 Learn
Weeks 1–2
Replace the loudest opinion in the room with evidence, sized to the risk. Research is scoped to the decision it informs, never run as a checkbox.
Activities
- Five to eight interviews, or a moderated pass on what exists
- A heuristic evaluation of the current experience
- Analytics review wherever there’s data
- A card sort when IA is the actual question
Outputs
- Ten insights maximum, each with a design implication
- A current-state journey map with friction marked
- A friction list ranked by frequency times severity
The gate
Findings review with the client and PM. Every insight becomes a design constraint or is parked on the record. Nothing sits in a deck doing nothing.
On timeline pressure: a two-day audit suits a mature product with analytics. A week of interviews suits a new flow with no users yet. The choice is stated up front, along with what skipping the other one costs.
03 Architect
Weeks 2–4
Get the structure right while it is still cheap to change. Low fidelity on purpose. Grey boxes invite structural objections. Polished screens invite opinions about color.
Activities
- Story map, then site map, then flows for the critical paths
- Lo-fi wireframes of every state, not just the happy path
- A content model pass: what data each screen needs
Outputs
- Annotated flow diagrams an engineer can estimate from
- A complete lo-fi wireframe set
- An edge-case matrix, the screens nobody asks for
The gate
Feasibility check with engineering, then a client walkthrough on lo-fi. Structural objections are free at this gate and expensive at the next one.
04 Design
Weeks 4–8
High-fidelity screens built on a system, not a pile of artboards. The library is built as the screens are built. That is the only way it survives contact with a deadline.
Activities
- Two visual directions maximum, one recommended
- Atomic order: tokens, then primitives, then components, then screens
- Hi-fi screens for every state the wireframes named
- A clickable prototype of the critical paths
Outputs
- A Figma library on variables and variants, named to match code
- Visual guidelines: type, color roles, icons, imagery, motion
- An interactive prototype, the thing that ends arguments
The gate
Internal design critique first, client review second. The team tears the work apart before the client sees it. That is the point of having a design team.
05 Validate
Weeks 8–12
Prove it works, then make it hard to build wrong. Usability testing before development is the cheapest insurance on the project. Friction found here costs hours, not sprints.
Activities
- A five-participant moderated test, then a fix pass
- A live handoff walkthrough of the system
- Office hours through the build, design QA on staging
Outputs
- Usability findings with severity ratings and a fix log
- Annotated specs: spacing, behavior, breakpoints, accessibility
- Token export, state matrix, and a design-QA checklist
The gate
Engineering confirms in writing that it can be built as specified. Then design QA signs off on staging before anything ships.
Cadence
The weekly rhythm
Remote work fails on rhythm, not on talent. These five rituals are fixed on every project. They are what keep several engagements running at once without anything going quiet.
DayRitualWho’s in itWhat comes out
MonWritten status and open decisionsPM, clientFive bullets: shipped, in progress, blocked, decisions needed, risk
TueWorking session in the live fileClient stakeholdersDecisions logged next to the frames. No follow-up recap needed
WedInternal design critiqueDesign team, design leadRevisions, plus one mistake named out loud
ThuEngineering office hoursEngineers, QAAnswered specs and updated annotations, same day
FriDemo and decision-log updateEveryone, async-friendlyA five-minute recorded walkthrough anyone can watch later
Time zones: the working day carries at least four hours of overlap with Pacific time. Synchronous hours go to the things that need a human: workshops, critiques, client reviews. Everything else is async by default, which is what makes parallel projects possible.
Handoff contract
The handoff package
When the promise to a client is that development builds it exactly as shown, the spec has to be good enough to make that true. This is the checklist, delivered every time.
Tokens
Named to match code
Color roles, type scale, spacing, radii, elevation, as Figma Variables with the same names the front end uses. Exportable, not screenshotable.
Components
Every state, defined
Default, hover, focus-visible, active, disabled, loading, error, empty. If a state isn’t in the library it isn’t designed, and it will get invented in code.
Behavior
Rules, not redlines
Written as conditions, like “the rail collapses when the content column drops under 480px”, so layouts survive content the mockup never had.
Accessibility
Specified, not assumed
Focus order, roles and labels, contrast pairs recorded with their ratios, targets at 44px. WCAG 2.2 held as a gate, not a final-week audit.
Content
Real strings, real lengths
Microcopy written by the designer and reviewed with the client, including the error messages, the empty states, and the longest name in the database.
Presence
Design, during the build
A live walkthrough at handoff, weekly office hours, and design review on staging. The spec starts a conversation. It is not a wall to throw work over.
Working relationships
How the method works with a team
The part of the method that isn’t on a timeline. Six relationships, and what each one gets.
Engineers
Work happens in engineering’s tools
Dev Mode, Code Connect, Storybook, the repo. The design source is validated against what shipped, not against the library’s own claims. At Verizon, tokens and variables were diffed against production code across two platform teams, and the drift was caught before release.
Product and business partners
A working screen beats a principle
A screen that works settles more than an argued principle. Every recommendation states what it gives up and why. The client still decides. The designer’s job is to make the trade visible first.
Other designers
Adoption is the metric, not compliance
Reviews, office hours, and mentoring on correct usage and accessibility. FIBER’s 54 components were adopted by three product teams because the library answered their questions, not because a policy required it. Edison ran the same way across GE Healthcare’s matrixed organization and 40-plus products.
Embedded and self-directed
One systems designer on a small team
At Avant, one design-systems contributor sat inside a product team of three, with three engineers and a PM. Day to day that meant designing the application and servicing flows, proving each pattern in a real screen, and moving it into the library the same week. The library work came out of the product work.
Handoff
Teams run the system on their own
Standards, documentation and recorded reviews, so the system keeps working after the engagement ends. FIBER had intake, a release cadence, versioning and deprecation written down. That is what let three teams keep using it without a call to the designer.
Remote
Distributed teams stay in step in writing
Async docs, recorded walkthroughs, and written decisions next to the frames they affect. Every Friday ends with a five-minute recorded demo anyone can watch later. [MIKEL: add one specific remote habit here]
Ambiguity protocol
When the brief contradicts itself
Client work means digesting information that is incomplete, changing, and sometimes contradicts itself. That isn’t a failure of the client. It’s the normal condition of the job. Four moves, in order.
01
Write the contradiction down, in their words
Two stakeholders wanting opposite things is a business decision wearing a design costume. The difference is not quietly split. Both positions are named, the cost of each is shown, and the choice goes back to the client with a recommendation attached.
02
Separate the assumption from the constraint
Everything ambiguous goes on the assumption register with an owner and a cost of being wrong. Cheap-to-test assumptions get tested this week. Expensive ones get decided by the client, on the record, so nobody relitigates them in month three.
03
Build the smallest thing that settles it
A one-day clickable prototype ends arguments that a two-week email thread only deepens. When a debate has gone two rounds without new information, the debating stops and the artifact that answers it gets built.
04
Push back with a proposal attached
“That doesn’t work” is noise. “That will cost the onboarding funnel. Here is the alternative, what it trades, and how it would be measured in two weeks” is the job. Pushing back on a brief only earns trust when it arrives with the replacement.
In practice
Where the method came from
Five design systems built from scratch and two mature ones evolved. The gates above aren’t theory. Each one exists because skipping it cost something on one of these.
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
Pathfinder · Avant
The system shipped alongside the product, never ahead of it
One design-systems contributor, embedded with a product team of three, three engineers and a PM, on a regulated lender. Every pattern was proven in a real screen before it entered the library. That is why phase 04 builds the system as the screens get built rather than in front of them. The number that mattered was whether a borrower finished the application or abandoned it.
FIBER · BCBS
Fifty-four components, and a coded library that matched them
Built from nothing, adopted by three product teams, documented like a product: intake, release cadence, versioning and deprecation. The coded library matched the design source in naming, structure and behavior. That parity is why the handoff contract above is as specific as it is. A component that doesn’t match its code is a suggestion.
A lesson applied
Constraints were carried into wireframes without being tested
A stated back-end constraint was accepted in week one, carried into the structure, and only questioned at hi-fi, where changing it is expensive. That is why a constraints inventory with the lead engineer is now part of phase 01 instead of something addressed the week after.
Onboarding
The first 30 days
How the method starts inside a new team. Nothing here needs a reorg.
01
Week one: read, then inventory with an engineer
The brief, the library, the docs and the backlog are read with no design tool open. Then an inventory with the lead engineer of what actually ships against what the library claims. The gap between the two is the plan.
02
Week two: one visible fix
The drift with the highest cost gets fixed at the primitive, once. A missing focus state, greys off the ramp, a component with three button variants in code. Small, shipped, and visible to the team.
03
Week three: a written plan
What was found, what to sequence, what each item costs and what it closes. One page, with the trade-offs stated, so the team can argue about the ranking without arguing about the facts.
04
Week four: a rhythm
Weekly critique, engineering office hours, and a decision log next to the frames. By day 30 the team knows where to find the answer without asking.
The method, on one project
One project against these five phases: the brief as it arrived, the problem underneath it, the gate where direction changed, and the screen that came out. Then what went wrong, and what the second version fixed.
mikelrosenthal@me.com
mikelrosenthal.com