Every designer has a workflow. Not every designer has documented it. Here’s my summary of the exact process I follow from the moment a problem lands on my desk to the moment developers have everything they need to build it.
Phase 1: Understand the problem
Before I open Figma, I need to understand what I’m actually solving. This means asking uncomfortable questions: What is the user trying to accomplish? What’s getting in their way? What does success look like, and for whom?
My go-to tools at this stage are unstructured notes, competitive audits, and, if I have access to users, research. Even a handful of informal conversations can completely reframe a problem. I’d rather spend an extra day here than spend two weeks designing the wrong thing.
Phase 2: Define the object model
This is a step many designers skip, and it shows in the work.
Before I think about screens, I think about objects: the nouns of the product. What are the core things the user interacts with? What relationships exist between them? What actions can be performed on each?
This is rooted in OOUX (Object-Oriented UX), and it’s one of the most valuable frameworks I’ve added to my practice. When your object model is clear, your information architecture, navigation, and component structure all follow naturally.
Phase 3: Information architecture and flows
With a clear object model, I map out the structure of the experience. Where does each object live? How does a user move between them? What are the critical user flows?
I’m not designing screens yet…I’m drawing boxes and arrows. This phase is fast and cheap, which is exactly the point. Changes at this stage cost nothing. Changes at the hi-fi prototype stage cost everything.
Phase 4: Lo-fi wireframes
Now I open Figma. But I’m still not finalizing visual designs…I’m problem-solving in low fidelity. Grayscale (or OOUX colors), rough, fast. I’m working out layout, hierarchy, and content structure before I commit to any visual decisions.
Wireframes are a thinking tool, not a deliverable. I don’t show polished wireframes to stakeholders. I use them to pressure-test my own thinking before I invest in high-fidelity visual design.
Phase 5: Visual design
This is where the design system earns its keep. With tokens, components, and guidelines already in place, visual design becomes about applying a system thoughtfully rather than making hundreds of micro-decisions from scratch.
I work at true hi-fi from this point — real copy, real components, real states. I design for every meaningful state a component or screen can be in: empty, loading, error, success, and edge cases. Designing the happy path only is one of the most common and costly mistakes in product design.
Phase 6: Prototyping
Interactive prototypes serve two purposes: testing and alignment. I build prototypes to validate flows with users before handoff, and to communicate interactions to developers that static screens can’t capture.
In 2026, Figma’s prototyping capabilities have made this faster than ever. For complex interactions, I’ll sometimes build a quick HTML/CSS prototype in VS Code to demonstrate something more precisely, especially for animation and motion.
Phase 7: Accessibility review
Before anything goes to handoff, I run an accessibility pass. This means checking color contrast against WCAG standards, verifying keyboard navigation capability and focus order, reviewing component semantics, and making sure interactive elements have appropriate labels.
Accessibility isn’t a final checklist, though…ideally it’s woven into every phase. But if I had to pick one moment to do a dedicated audit, it’s here, before developers start building.
Phase 8: Handoff
A good handoff isn’t just a Figma link. It includes:
- Annotated specs: interaction notes, state documentation, edge case callouts
- Component documentation: what each component is, when to use it, what it shouldn’t do
- Asset exports: icons, images, and anything that needs to live outside Figma
- A conversation: I walk developers through the work. Questions caught in a 30-minute sync save days of back-and-forth later
The handoff isn’t the end of my involvement. I stay available through development, review builds against the designs, and flag discrepancies early. The design isn’t done until it’s shipped.
A workflow is only as good as the thinking behind it. The tools change. The phases shift. But the goal is always the same: understand the problem deeply, solve it deliberately, and hand it off clearly.