There is a moment in every product project where an idea has to become a thing. Until then it exists in documents, conversations, and everyone's slightly different mental picture of it — pictures that turn out, reliably, not to match.
Design and prototyping is where those pictures get reconciled. Not by discussing the idea more precisely, but by building something people can look at, click through, and fail to use. The failures are the point. They are far cheaper to discover in a prototype than in production.
What is UX/UI design and prototyping?
UX/UI design is the work of turning product requirements into an interface people can use: structure, flows, screens, states, and the visual system that holds them together. Prototyping is making that design interactive enough to be tested before anything gets built.
The two belong together because design decisions are hypotheses. A navigation structure is a bet about how users think. A form layout is a bet about what people are willing to provide. A prototype is how you check the bet before paying for it.
The output is twofold: a validated interface, and a specification complete enough that development doesn't have to guess.
Fidelity: matching the artefact to the question
The most consequential decision in prototyping is how finished to make it — and the most common mistake is making it too finished too early.
Low fidelity — sketches and greyscale wireframes. Structure, hierarchy, and flow, with no visual design. Fast to produce and fast to discard, which is exactly what you want while the fundamental shape is still in question.
Mid fidelity — refined wireframes with real content, accurate spacing, and working interaction. Detailed enough to test task completion, not so detailed that people comment on the colours.
High fidelity — full visual design, real content, complete interaction. What development builds from, and what you use for realistic usability testing and stakeholder sign-off.
Here is the thing most teams learn the expensive way: a polished prototype gets you feedback about polish. Show someone a finished-looking screen and they will comment on the colour of the button. Show them a greyscale wireframe and they will tell you the flow doesn't make sense.
If the open question is structural, low fidelity gets a better answer, faster, and at a fraction of the cost. High fidelity is for when the structure is settled and the remaining questions are about execution.
Working through fidelity levels in order also protects the budget. Changing a wireframe costs an hour. Changing a high-fidelity design system component costs a day. Changing it after the build costs a sprint.
Why prototype at all
Because reading a spec and using a product are different activities. Stakeholders approve documents describing flows they would find confusing in practice. A clickable prototype makes the flow real enough that the confusion surfaces before it's expensive.
Because it makes disagreement productive. Two people can agree on "streamlined onboarding" for months while picturing entirely different things. A prototype forces the difference into the open, where it can be resolved in an afternoon.
Because it's the last cheap moment to change your mind. The cost of altering a decision rises steeply from wireframe to design to code to production. Prototyping concentrates the changes in the cheapest phase.
Because you can test it with real users. Five to eight participants clicking through a prototype will surface most serious usability problems. Doing that before development is the highest-leverage hour in the entire project.
The process
Inputs
Design work starts from something: discovery findings, an audit, analytics, existing research, or at minimum a clear articulation of who the user is and what they need to accomplish. Design without inputs is decoration — it will look considered and be based on nothing.
Information architecture
Structure before surface. How content and functionality are organised, what belongs together, what the labels are, how deep the hierarchy runs. IA errors are the most expensive kind because everything else is built on top of them, and they are almost impossible to fix later without a rebuild.
User flows
The paths through the product, including the ones nobody enjoys mapping — errors, empty states, interruptions, permissions, expired sessions. Products that only work on the happy path feel broken within minutes of real use, and the happy path is the easy 20% of the work.
Wireframes
Layout, hierarchy, and content priority, resolved without visual design in the way. This is where most of the actual thinking happens.
Interactive prototype
The wireframes connected into something clickable. Enough interaction to walk a real task end to end — which is the minimum needed for testing to produce useful results.
Visual design
Typography, colour, spacing, imagery, and component design, applied so they support usability rather than compete with it. Colour that carries meaning consistently. Type that establishes hierarchy. Interactive elements that look interactive. Contrast that meets accessibility requirements rather than just looking acceptable on the designer's monitor.
Specification and handoff
Every state documented: default, hover, focus, active, disabled, loading, error, empty. Behaviour at each breakpoint. What happens when the text is longer than the mockup, when the image fails, when the list is empty, when the connection drops. This is the part most commonly skimped, and it is where design quality gets quietly lost.
What makes a prototype actually useful
It covers a complete task. A prototype demonstrating three disconnected screens tests nothing. Users need to attempt a real goal from start to finish.
It includes the unhappy paths. What happens on a wrong entry, a failed payment, an empty result. These are where products lose people, and they're routinely omitted from prototypes because they're less satisfying to build.
It uses real content. Lorem ipsum hides problems. Actual product names, actual error messages, and actual worst-case text lengths reveal layout failures that placeholder text conceals entirely.
It matches its fidelity to its purpose. A prototype for stakeholder sign-off and a prototype for structural testing are different artefacts. Building one and using it for both wastes effort in one direction and produces bad data in the other.
Design systems and components
For anything beyond a handful of screens, designing in components rather than pages pays for itself quickly.
A component-based approach means buttons, form fields, cards, and navigation are defined once with all their states, then reused. The benefits compound: consistency without policing, faster design of new screens, faster development because engineers build a component once, and dramatically cheaper changes — updating a component updates every instance.
The cost is upfront investment, and it isn't always justified. A five-screen MVP doesn't need a design system. A multi-role platform expected to grow for years absolutely does, and building one retroactively is significantly more expensive than starting with it.
The honest guidance: match the system's ambition to the product's actual trajectory, not to how thorough it feels to build one.
Handoff: where design quality leaks away
A design that development can't implement accurately isn't a good design. Handoff is a deliverable, not an afterthought.
What development actually needs:
- Every state specified, not just the default one
- Responsive behaviour defined at real breakpoints, not implied by a desktop mockup
- Spacing and sizing as values, so measurements aren't estimated from a screenshot
- Component definitions with variants and usage rules
- Edge case behaviour documented rather than left to be decided under deadline pressure
- Accessibility requirements stated: focus order, labels, contrast, keyboard behaviour
- Someone available to answer questions, because ambiguity always surfaces during implementation
That last one matters more than the documentation. Design questions arise in every build. If nobody is available, developers make reasonable guesses, and the accumulated guesses are how a design ships looking subtly wrong in ways nobody can point to individually.
Common mistakes
Designing without research. Every design decision is an assumption about users. Without inputs, they're all untested, and the interface is a coherent expression of guesswork.
Jumping to high fidelity. Skipping structure to get to visuals means fundamental problems are discovered after they've become expensive to fix.
Designing only the happy path. Real usage involves errors, empty states, and slow connections. A design that ignores them is roughly 20% finished.
Placeholder content. Lorem ipsum and perfectly-sized sample text hide the layout failures that real content produces immediately.
Aesthetics over usability. Low-contrast text, ambiguous icons without labels, and controls that don't look interactive are all recurring costs of design decided on appearance.
Treating accessibility as a later pass. Retrofitting is expensive and produces worse results than designing for it from the start. Contrast, focus states, and semantic structure are design decisions, not remediation tasks.
Incomplete handoff. The most common way good design becomes mediocre product.
How we approach design and prototyping
Fidelity follows the question. We don't produce polished screens while the structure is still in doubt — it wastes budget and, worse, it gets you the wrong feedback. Structure gets settled in greyscale, where changes are cheap and reviewers comment on what matters.
Prototypes are built to be tested, not admired. That means complete tasks, real content, and the failure states included. A prototype that only demonstrates the ideal path hasn't tested anything you didn't already believe.
Design decisions are explained. Every significant choice has a reason — a usability principle, a research finding, a documented pattern. It means proposals can be challenged on substance rather than taste, which is a considerably better basis for a design conversation.
Handoff is treated as a deliverable. States, breakpoints, edge cases, and accessibility requirements documented, and availability during the build to resolve what documentation didn't anticipate.
The approach is grounded in certification from the Nielsen Norman Group — the institution that shaped modern UX practice — in information architecture, journey mapping, usability testing, UX leadership, and analytics, and thirteen years of work across agencies, startups, and corporate teams in insurtech, fintech, health, education, enterprise, and transportation.
Every engagement is run personally. No account layer between you and the person doing the work.
Frequently asked questions
What's the difference between a wireframe and a prototype?
A wireframe is a static layout showing structure and hierarchy. A prototype is interactive — you can click through it and attempt a task. Wireframes answer "what goes where"; prototypes answer "does this work when someone actually uses it."
Do we need a prototype if we're building anyway?
Almost always yes. Prototyping typically adds days to a timeline and removes weeks of rework, because it surfaces problems while they're still cheap. The exception is very small, well-understood changes to established patterns.
How long does design and prototyping take?
For an MVP-scale product, roughly four to eight weeks from inputs to development-ready design, depending on the number of screens, the number of user roles, and how quickly decisions get made. Decision speed is more often the constraint than complexity.
Can you work with our existing design system?
Yes — and it's usually preferable. Working within an established system produces faster, more consistent results and avoids the divergence that comes from designing around one.
Do you do usability testing on the prototype?
It can be included, and it's worth it. Five to eight participants attempting real tasks catches the majority of serious problems, and catching them pre-development is where the value is. If you'd rather run it internally, we'll structure the prototype to make that straightforward.
What do developers receive?
A complete specification: all states, responsive behaviour at defined breakpoints, spacing and sizing values, component definitions with variants, edge case behaviour, and accessibility requirements — plus availability to answer the questions that always come up mid-build.
Do you design for accessibility?
It's built into the process rather than added at the end. Contrast ratios, focus states, keyboard navigation, and semantic structure are design decisions. Retrofitting them costs more and produces worse outcomes than designing with them from the start.
Where to start
If your team is discussing a feature and you suspect everyone is picturing something slightly different, that's the signal. A prototype resolves it in days, and it's the cheapest disagreement you'll ever have.