01
Ideation
Before anything gets drawn I want the bet written in one sentence somebody can
disagree with. On Box Buddy that sentence was: if a distressed child can’t finish
it alone, it doesn’t ship. Every scope call afterward came out of defending that
line. This stage is mostly arguing, and arguing is far cheaper in week one than in
week six when there’s a build to unpick.
ProducesThe bet in writing, the in-and-out scope lines,
and a rough map of the flows.
02
Research
On MassXR I sat with active-duty maintainers across several cohorts, and what they
told me moved the design further than any internal review did. Amazon was three
people with opposite relationships to the same data: an employee who only wants to
know where she stands, a manager scanning twelve reports before a calibration
meeting, leadership looking at the whole pipeline. One screen cannot serve those
three, and you only learn that by asking. At Los Alamos the deliverable wasn’t a
study at all, it was the templates and SOPs that made the next person’s study
comparable to mine.
ProducesUser types with real differences between them,
journeys, a findings doc, and sometimes the research standard the rest of the team
then works from.
03
Design
Foundations first, every time: type scale, colour roles, spacing, elevation,
tokens. Then components with their states and variants, and only then screens,
assembled out of those components rather than drawn freehand. Mayo ran patient and
provider as two products on one library, same cards and charts, opposite
information priorities, and that only works if the library was built to bend that
way from the start. I annotate as I go, because an annotation written three weeks
later is a guess about what I was thinking.
ProducesA Figma library (tokens, variants, annotated
components) and the screens built on top of it.
04
Testing
Usability sessions where my job is to shut up and watch, plus the accessibility
pass, which on Mayo meant contrast ratios, 44pt targets, keyboard order and screen
reader labels on every component before any of it shipped. My first games job was
QA at Epic, so I’m comfortable being the person who files the unglamorous bug.
The useful output isn’t a score. It’s a ranked list of what has to change, with
the things I’d defend not changing marked as such.
ProducesTest plan, session notes, the accessibility
audit, and a ranked change list.
05
Iteration
The abnormal lab result component at Mayo went through more versions than anything
I’ve designed. Surfacing a bad number without causing panic turns out to be a copy
problem, a colour problem and a hierarchy problem at once, and fixing one of those
broke the other two for a while. This is the stage that loops: a testing finding
sends the work back into Design, the new version goes back into Testing, and it
runs until the thing stops failing. I keep the versions in Figma version history
with the reason attached, so the decision is still auditable months later.
ProducesSide-by-side versions with the reason each one
changed, and a decisions page in the file.
06
Implementation
Handoff is not a link to a Figma file. I stay in the build: annotate the spec,
answer the engineer’s question about the empty state nobody designed, then QA what
got built against what was designed, screen by screen. I write front-end code too
(React, HTML and CSS, C# in Unity), which mostly means I know when I’m asking for
something expensive and can offer the cheap version before anyone has to push back.
Box Buddy’s two mini-games shipped in Unity, so there the handoff was partly to
myself.
ProducesAnnotated specs and redlines, a QA pass against
the design, and the tickets that come out of it.
Worth saying plainly, since the iterations on these
pages are all high fidelity: there is very little paper in my process. Most of my
thinking happens at full fidelity inside a design system, because once the foundations
exist a real component is faster to build than a drawing of one. So the versions you see
are versions of the actual thing rather than wireframes of it.
