A wireframe is the structure of a screen with no visual design: boxes, content and hierarchy. A mockup is a static, visually designed screen that shows what it will look like. A prototype is interactive, so people can click or tap through it and you can test whether the flow works. You usually move from wireframe to mockup to prototype, but good teams skip steps when the question allows it.
Use wireframes to agree on structure, mockups to agree on look, and prototypes to test behaviour. Pick the lowest fidelity that answers your current question.
| Wireframe | Mockup | Prototype | |
|---|---|---|---|
| What it shows | Structure and content | Final visual design | Interaction and flow |
| Fidelity | Low | High (static) | Low to high, interactive |
| Time to make | Minutes to hours | Hours to days | Hours to days |
| Best question | What goes where? | How should it look? | Can people use it? |
| Feedback from | Team, stakeholders | Stakeholders, brand | Real users |
| Tools | Paper, Figma | Figma | Figma, code, AI builders |
| Risk | Looks unfinished | Feels done too early | Polish hides problems |
Nielsen Norman Group's guidance on prototype fidelity is a good rule: low-fidelity prototypes are fast and invite honest feedback, high-fidelity ones are better for testing details like visual hierarchy and interaction. The mistake is polishing before you know the structure is right.
At Accern we used Procreate sketches, storyboards and flows before Figma screens, because the hard part was agreeing on a path through a confusing product, not the visuals.
Prototypes no longer have to be clickable pictures. With AI coding tools I often go from Figma frames to a working build, because some questions only real behaviour can answer: does this glass lens feel right when pressed, does this film scrub smoothly. Traveme and Say More are examples.
Wireframes are best tested with your team and a few stakeholders. Ask whether the structure supports the main task, whether anything important is missing and whether the order makes sense. Keep them grey on purpose so nobody argues about colour.
Mockups are for visual agreement: brand fit, hierarchy, readability and states. Review them on real devices at real sizes, not only zoomed out on a big monitor.
Prototypes are for users. Give people a task, stay quiet and watch where they hesitate. Five sessions usually show the biggest problems. If the question is about feel, timing or motion, use a coded prototype; static clickable screens cannot answer it.
My process starts rough and ends real. For product work that means sketches and flows, then Figma screens, then a prototype people can use. For my experiments the last step is often a working build rather than a Figma prototype.
Whatever the fidelity, write down the one question each artifact should answer before you make it.
Usually the wireframe. Agree on structure and content before spending time on visual design.
No. A mockup is static. A prototype is interactive, so you can test how people move through it.
Yes, when the structure is already known, for example a small change inside an existing design system.
Figma covers all three for most teams. For realistic behaviour, a coded prototype can be worth the extra effort.
Match the artifact to the question. Wireframes for structure, mockups for look, prototypes for behaviour, and real code when feel is what you need to judge.
Need a product designer or design engineer for your product? I work remotely with teams worldwide, from research to shipped code.