Web Design
Wireframing and prototyping before you build
Wireframes and prototypes let you test a site or app before a line of code is written, when a change costs minutes instead of weeks. We map structure, sketch flows and build clickable prototypes you can put in front of real people.
Who it is for: Founders and teams planning a new site, app or feature who want proof the flow works before paying for development.
Everything in this service
- Low-fidelity wireframes for every key screen
- User flows for the journeys that matter
- Clickable prototypes in Figma
- Stakeholder and user walkthroughs
- A validated blueprint the design phase builds on
What to expect
- Flow problems found before development, not after
- Stakeholders aligned on something they can click
- A cheaper, faster design and build phase
How wireframing & prototyping actually works
Fidelity levels and when each one earns its cost
Fidelity means how finished something looks. It runs from a sketch on paper through grey-box wireframes to a design that could be mistaken for the real product. Higher fidelity is not better. It is more expensive and it changes the kind of feedback you get, which is the more important effect.
A rough sketch invites structural criticism. People say the order is wrong or something is missing, because the artefact clearly is not finished and nobody feels rude questioning it. A polished mock-up invites cosmetic criticism. People discuss the shade of blue and the photograph, and the same structural flaw goes unmentioned because the thing looks decided. This is not a failing of your colleagues, it is a predictable response to how finished something appears.
So match fidelity to the question. Settling what goes on a page and in what order: low fidelity, and quickly. Testing whether people can complete a multi-step task: medium fidelity, clickable, with real labels and real content, because fake labels make tasks impossible to test honestly. Testing whether a visual treatment reads as trustworthy or whether a specific micro-interaction feels right: high fidelity, and only for the screens where that question actually matters.
- Low fidelity for structure and content order, and it should be fast
- Medium fidelity with real labels and content for task testing
- High fidelity only for visual and interaction questions, on selected screens
- Use grey boxes deliberately, they keep feedback on structure
- Real content beats placeholder text at every fidelity level
Prototype to answer a question, not to build a demo
The most common waste in prototyping is building every screen. A prototype is not a small version of the product. It is an instrument for answering a specific question at low cost, and any screen that does not serve that question is decoration.
Start by writing the question down. Can a first-time user complete sign-up without help. Do people understand the pricing structure. Will an operations team accept this replacement for their spreadsheet. Each of those needs a different prototype, and most need only a handful of screens. Everything else can stay as a link that goes nowhere, and testers accept that readily when you tell them at the start.
Prototype the risky parts. Risk lives where the flow is new, where several systems meet, where a decision is irreversible for the user, or where the team disagrees. The parts everyone already understands, a standard contact form for example, do not need prototyping at all. A good rule: if you already know what the test will show, you do not need to run it, and if you cannot say what result would change your plan, the prototype is not worth building.
- Write the question the prototype must answer before building it
- Build only the screens on the path to that answer
- Prototype the risky and disputed flows, not the familiar ones
- Skip the prototype if the result would not change any decision
- Tell testers up front which parts are not built
Running a test that produces usable answers
A prototype test goes wrong in predictable ways. The facilitator explains too much, the task is unrealistic, or the session becomes a discussion about opinions rather than an observation of behaviour.
Set a scenario with a motive, not an instruction. Instead of asking someone to click through and tell you what they think, ask them to imagine their fridge has broken and they need someone out today, then find out whether this company can help and arrange it. That gives them a reason to make choices, and their choices are the data. Then stay quiet. When someone pauses, count to five before speaking. The pause is often where the finding is.
Ask what they expected to happen rather than whether they liked it. If someone clicks the wrong thing, ask what they thought it would do, because the answer tells you what the label meant to them. Record sessions with permission and take notes on behaviour rather than quotes. Afterwards, group problems by how many people hit them and whether they blocked the task. Three people failing the same step outranks one person disliking the header. Fix the blockers, then run another round, because a second round on a revised prototype catches problems the first round hid behind the first problem.
- Give a scenario with a motive, not a click-by-click instruction
- Stay silent through hesitation, the pause is the finding
- Ask what they expected, not whether they liked it
- Rank issues by frequency and by whether they blocked the task
- Run a second round after fixes, the first round masks later problems
Why a wireframe stage lowers the cost of the build
Changing a wireframe takes minutes. Changing a design file takes hours. Changing built software takes days and carries the risk of breaking something else. The cost of a change rises steeply the later it happens, which is the entire argument for doing structural thinking early.
The changes that hurt most are structural. Realising the flow needs an extra step, that two features should be one screen, or that a whole section is unnecessary. Caught at wireframe stage these are edits. Caught after development they mean rework across design, code, tests and sometimes the data model.
There is a second benefit that is less obvious. Wireframes force content decisions early. Someone has to decide what actually goes in each section, and that is usually when a team discovers the content does not exist, or that three sections say the same thing. Finding that during wireframing gives writers weeks of lead time. Finding it during development means launching with placeholder text or delaying the launch, and both are expensive in different ways.
- Structural changes are cheap early and expensive late
- Wireframes surface missing content while there is still time to write it
- Stakeholder disagreement is easier to resolve over a rough layout
- Estimates from a wireframed scope are far more reliable
- A validated structure gives designers a brief instead of a blank canvas
Handover: what developers actually need from a prototype
A prototype communicates intent, but it does not communicate everything a developer needs, and the gaps are where build time gets lost. A clickable file shows the happy path at one screen size with tidy content. Software has to handle everything else.
The useful handover covers what the prototype cannot show. Behaviour between the breakpoints, not just the mobile and desktop layouts. What happens with an empty list, a very long name, a slow connection, a failed request. Which parts are genuinely interactive versus faked for the demo, because a prototype can imply behaviour that is expensive to build and nobody has priced. Validation rules and error messages written out as words. Keyboard order and focus behaviour, since a prototype is clicked with a mouse and reveals nothing about tab order.
The other half is a conversation. Half an hour walking a developer through the flows catches assumptions that no document surfaces, and it usually produces a cheaper alternative for at least one interaction. Bringing development into the prototype review before it is final is better still, because a small change made then can remove days of work later. And when questions come up mid-build, the prototype should be updated rather than answered in a chat thread, otherwise the file stops matching what is being built and everyone quietly stops trusting it.
- Specify behaviour between breakpoints, not just two fixed layouts
- Define empty, loading, error and long-content cases explicitly
- Say which interactions are real and which are faked for the demo
- Write validation rules and error wording as actual text
- Walk developers through it live, then keep the file updated as things change
Common mistakes that waste a prototyping stage
Prototyping fails in a few repeatable ways, and all of them are avoidable once named.
The first is polishing too early, which shifts every conversation to appearance. The second is using lorem text, which hides the fact that the real heading is four times longer and the real product names do not fit. The third is prototyping every screen, which converts a fast validation exercise into a slow parallel build. The fourth is showing it only to colleagues, who know the product too well to struggle with it and who therefore validate nothing.
The last one is subtler. Teams run the test, collect clear findings, and then build the original plan anyway because the schedule was already agreed. That is the most expensive mistake of all, because you paid for the information and then discarded it. If there is no genuine willingness to change the plan, skip the prototype and save the money.
- Do not add polish before the structure is settled
- Use real content, placeholder text hides real problems
- Prototype the risky flows only, not the whole product
- Test with people outside the team, colleagues know too much
- Only run the test if you are prepared to act on the result
A clear path, step by step
- 01
Map the journeys
We define who uses the product, what they need to do, and in what order.
- 02
Wireframe
Fast, low-fidelity screens that settle structure and content before visuals distract.
- 03
Prototype
Screens linked into a clickable flow you can actually try, not just look at.
- 04
Test and revise
Walkthroughs with your team or users, revised until the flow holds up.
Why choose us for this
We prototype the risky flows, not every screen
Feedback rounds are fast because fidelity is deliberately low
The prototype feeds straight into design and build, nothing wasted
Common questions
Why not go straight to design?
Because visual design hides structural problems. A polished screen gets compliments; a wireframe gets honest questions about whether the flow makes sense. Structure first is cheaper every time.
What does a prototype look like?
A set of linked screens in Figma you open in a browser and click through like a real product. No code, but real enough to test whether people can complete the journey.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase