Amey-Thakur Wireframing and prototyping
Wireframes and prototypes are how you think through and test a design before it is expensive to change. The core idea: work at the lowest fidelity that answers the question you have, so you iterate on cheap artifacts and only build what has earned it.
Method
- Match fidelity to the question. Testing structure and flow? A rough low-fidelity wireframe (boxes and labels, no color or polish) is faster and invites bolder feedback. Testing visual design or a real interaction? Higher fidelity. Do not polish pixels while the layout is still in question; low-fi first, detail later (see user-flows).
- Wireframe to decide layout and priority, not looks. A wireframe settles what goes on the screen, where, and in what hierarchy, without the distraction of color and copy (see visual-hierarchy, information-architecture). Grayscale and placeholder content keep the conversation on structure. Resolve the big questions here.
- Prototype to test interaction and flow. A clickable prototype (linked screens) lets people actually move through the flow and reveals what a static mockup cannot: is the path obvious, does the interaction make sense, where do they hesitate (see interaction-design, user-flows). You feel the friction only by moving through it.
- Use real content, not lorem ipsum, once fidelity rises. Fake filler hides real problems: the label that is too long, the empty state, the name that wraps. Design with realistic content and the awkward cases (the long string, the zero-items view; see empty-and-error-states), or they surface only after build.
- Keep it disposable. Wireframes and early prototypes are for learning and are meant to be thrown away; getting attached to one, or over-investing in polishing an exploration, defeats the purpose. Make several rough options rather than one precious one, early on.
- Put prototypes in front of users and stakeholders. A prototype is the cheapest thing to test (see usability-testing) and the clearest way to align a team on what is being built before code (avoiding the "that's not what I meant" after launch). Feedback on a prototype costs nothing to act on; feedback on shipped code costs a rewrite.
Boundaries
- Prototypes simulate; they are not the product. Interactions feel different at real speed with real data and edge cases, so a prototype that tested well still needs verification once built (see the verify ethic in usability-testing).
- Fidelity has a cost curve: high-fidelity prototypes approach the effort of building, so know when to stop prototyping and build (or build a thin real version instead; see mvp-scoping).
- Wireframes communicate design intent, not implementation; the engineering handoff (specs, tokens, states) is a separate step (see design-systems, empty-and-error-states).