Approach
Settle the specification first.
Then build the working prototype.
Every case on this site follows one sequence: learn the rules of the programme, pin the specification down with the people who own the process, generate the screens with AI-Figma MCP, and hand engineers a prototype they can click through. The speed comes from the first step, not the tooling.
- Specification review
- AI-Figma MCP
- Working prototype
The sequence
Specification review with internal stakeholders
I sit down with the people who own the process and pin down what is being built, sentence by sentence. Any ambiguity that survives this meeting comes back later as rework. It looks like the slowest step and it decides every step after it.
AI-Figma MCP prompt
The settled specification becomes the prompt. When the specification is clear, the prompt is short. When it is not, a longer prompt does not steady the result. The quality of the prompt is mostly decided in the step before it. *
Working prototype
Screens a reviewer can click through, not a static mockup. Reviewers check the result instead of imagining it. This is also where the gaps in the original design show up. Each one gets a decision, recorded with its reason, so it can be reversed rather than rediscovered later.
Handoff to developers
The prototype does not replace the specification document. It sits beside it as the artefact engineers and I discuss. Less has to be explained, so less can be read two ways.
* AI-Figma MCP is a Model Context Protocol connection that lets an AI assistant build screens directly in Figma.
The result
With that sequence in place, specification delivery and the screen planning that follows went from an average of 1–2 months to 1–1.5 weeks on internal projects. That is an internal measure, and it is conditional: it holds only when the specification review comes first. Skip the meeting and the same prompt does not produce the same result. The sequence was applied end to end on the renewable-energy convergence case, where 12 Figma screens became a working mobile prototype in a month.
The limit I found
Once production stops being the bottleneck, the next bottleneck is how much a stakeholder can absorb. I once showed a working prototype before anyone had asked for one, and instead of settling the discussion it created confusion. Whether I could build something and whether it was the right moment to show it turned out to be two different questions. Since then I decide deliberately what to show and when.
Three ways of looking at a problem
How a tangled problem becomes a design problem.
Before the specification review, I look at the same problem three ways: who depends on whom and under which rules, what the person is trying to do and what blocks them, and what the evidence actually shows. The diagram below is how those three readings turn one messy situation into something I can specify and test.
Select a perspective to see which parts of the problem it picks out.
01 / Interconnected complexity
02 / Structure · categorize
Systems Thinking
Actors · Rules · Dependencies
User Empathy
Goals · Context · Barriers
UX Research
Qualitative observations · Quantitative measures · Evidence & patterns
03 / A solvable design equation
Three perspectives, one structure
System relationships, human context and research evidence turn an ambiguous challenge into a specific design problem.
A testable solution hypothesis
What needs to change for this person to achieve their goal within these constraints?
What to checkMake the hypothesis tangible in a prototype, then examine user feedback alongside behavioral measures.
Test → learn → reframe the problem
Three perspectives, one structure