Most expensive website and software mistakes are made before anyone writes a line of code. Nobody notices them at that point. A checkout flow with one step too many, a dashboard that answers the wrong question, a navigation menu built around your org chart instead of your customers' goals: each one looks harmless in a meeting. It only gets expensive once it has been built, tested, connected to a database and shipped.
UX prototyping lets you find those mistakes while they're still cheap. You build a realistic, clickable model of your product, put it in front of real people, and learn what works before development starts. This guide covers how prototyping saves time and money, which kind of prototype fits which stage, how to run a short prototyping sprint, and what a clean handoff to developers looks like. It also covers the cases where you can skip prototyping altogether.
Key takeaways
- A change made in a design file usually takes minutes. The same change after development can mean rework across the front end, the back end, testing and content.
- Pick the cheapest prototype that answers your current question. Sketches and wireframes test structure, and clickable and high-fidelity prototypes test behavior and polish.
- Testing with around five representative users per round is often enough to expose the biggest usability problems.
- A good handoff covers more than screens. It includes design tokens, component states, responsive rules and accessibility notes based on WCAG 2.2.
- A focused prototyping sprint typically takes 2–3 weeks and makes development quotes more accurate, because the scope is visible rather than imagined.
The cost of change: why fixing things in design is cheaper
Software engineering has a long-standing rule of thumb called the cost of change curve. The later a problem is discovered, the more it costs to fix. Estimates vary by study and project type, but the pattern is consistent. A fix during requirements or design costs a small fraction of the same fix after release, and the multiplier is often quoted as anywhere from several times to an order of magnitude or more.
The reason is simple. At the design stage, a change touches one thing, the design file. After development, the same change can touch many layers at once:
- Front-end code: templates, components, CSS and JavaScript.
- Back-end logic: database fields, API endpoints and validation rules.
- Content: copy and images written for the old layout.
- Quality assurance: regression testing across browsers and devices.
For example, say testing shows users abandon a SaaS signup at the "company size" field. In a prototype, moving that field to a later step takes about ten minutes. In a live product, it can mean reworking form state, the signup API and analytics events, then retesting the whole flow.
A prototype is the cheapest version of your product that can still teach you something true about your users.
Prototypes also settle arguments early. When stakeholders can click through a flow, opinions turn into observations, and fewer "change requests" during development turn out to be first-time feedback.
Prototype fidelity levels explained
Fidelity means how closely a prototype resembles the finished product. Higher fidelity isn't automatically better. Each level answers different questions, and polishing visuals too early can stop people from questioning the structure underneath.
Sketches
Paper or whiteboard sketches are the fastest way to explore ideas. They're ideal for comparing several layout approaches in an hour and for getting stakeholders aligned on the basic concept before anyone opens a design tool.
Wireframes
Wireframes are grayscale layouts that define structure, hierarchy and content priority. They show where things go and how much space each element gets, but leave out the visual style. Wireframes are where most information architecture decisions get tested.
Clickable prototypes
A clickable prototype links wireframes or mid-fidelity screens so people can move through real tasks: sign up, find a product, book a demo. It's the cheapest way to test flows with users, because it behaves enough like a product for people to act naturally.
High-fidelity prototypes
High-fidelity prototypes look and feel close to the final product, with real brand colors, typography, realistic content, micro-interactions and responsive variants. They're used for final validation, stakeholder sign-off, investor demos and developer handoff.
| Fidelity level | Typical effort | Best for testing | Not suitable for |
|---|---|---|---|
| Sketch | Minutes to hours | Concepts, layout options, early alignment | User testing with outsiders, estimates |
| Wireframe | Hours to a few days | Content hierarchy, navigation, page structure | Brand perception, visual polish |
| Clickable prototype | Several days | User flows, task completion, findability | Performance, real data edge cases |
| High-fidelity prototype | One to several weeks | Final usability, visual design, stakeholder sign-off, handoff | Rapid exploration of many ideas |
User flows and information architecture
Before drawing screens, map how people move through the product and how content is organized. These two artifacts are the skeleton every prototype hangs on.
User flows
A user flow is a diagram of the steps someone takes to complete a goal, including decisions, errors and alternative paths. For a business website, the key flows might be "find a service and request a quote" or "read a case study and book a call." For a SaaS product, they're usually signup, onboarding, the core "aha" action, upgrading and inviting teammates.
Good flows include the unhappy paths, such as a wrong password, an expired card or empty search results. These states take up a large share of development time, and they're often missing from early estimates.
Information architecture
Information architecture (IA) is how content is grouped, labeled and connected. For websites, that usually means a sitemap and navigation model. For applications, it means the structure of modules, settings and permissions. Two lightweight research methods help:
- Card sorting: users group topics into categories that make sense to them, which reveals the mental model your navigation should match.
- Tree testing: users try to find items in a text-only version of your navigation, which tests your labels and hierarchy without any visual design.
If you're planning a new website, putting a draft sitemap in your brief makes this stage much faster. Our guide on how to write a web project brief explains what to include.
Usability testing with five users
You don't need a research lab or a big budget to test a prototype. The Nielsen Norman Group's widely cited analysis argues that testing with around five users per round uncovers most of the significant usability problems. After that, each extra participant mostly confirms what you've already seen. The better approach is to run several small rounds, fixing issues between each one.
How to run a simple test
- Recruit representative users. Customers, prospects or people in the right role. Colleagues don't count.
- Write task scenarios, not instructions. "Find out how to get a quote for a 10-page website," not "Click the Pricing link."
- Ask them to think aloud. Narration shows you why something fails, not just that it fails.
- Stay quiet and observe. Hesitation, wrong clicks and backtracking are the data you came for.
- Record and synthesize. Note each issue, how often it came up and how severe it was. Fix the critical ones, then retest.
Remote sessions over video calls of 30–45 minutes each work well, so a full round fits into a day or two.
Prototyping tools
The tooling market has consolidated, and for most teams the choice is straightforward:
- Figma is the de facto standard for interface design and prototyping. It's browser-based and collaborative, with interactive components, variables and a developer inspection mode. The Figma Help Center documents its prototyping features, and it's the tool we use for prototypes at EveryCode.
- Whiteboarding tools such as FigJam or Miro work well for user flows, sitemaps and workshops.
- Code-based prototypes make sense when you need to test what design tools can't simulate well, such as complex data tables, drag-and-drop or real-time behavior.
The tool matters less than testing what you build with real users.
Design systems and component inventory
As a prototype matures, repeated patterns start to appear: buttons, form fields, cards, modals, alerts, tables. Collecting them into a component inventory, and eventually a design system, keeps both design and development faster and more consistent.
What a practical design system includes
- Design tokens: named values for color, typography, spacing, border radius, shadows and breakpoints (for example,
color-primary-600orspace-4). - Components: reusable UI elements with documented variants (primary, secondary, destructive) and sizes.
- States: default, hover, focus, active, disabled, loading, error and empty for every interactive element.
- Patterns: repeatable combinations such as search with filters, multi-step forms or pricing tables.
For WordPress projects, the component inventory maps onto custom Gutenberg blocks and theme templates. For SaaS products, it maps onto a React or Vue component library. Either way, each component is designed once and built once, which makes the project easier to estimate and extend.
Handoff to developers: specs, tokens, states and accessibility
A beautiful prototype can still produce a messy build if the handoff is vague. Developers need answers to questions that static mockups don't cover. What happens when the name is 60 characters long? Where does this column go on mobile? What does the error message say?
What a developer-ready handoff contains
- Specs: spacing, sizes, typography and grid rules, ideally inspectable directly in the design file rather than redlined by hand.
- Tokens: exported design tokens that developers can turn into CSS custom properties or theme settings.
- States and edge cases: loading, empty, error, success, long content and permission-restricted views.
- Responsive behavior: layouts for key breakpoints and notes on how components reflow between them.
- Interaction notes: animations, transitions, validation timing and keyboard behavior.
- Content and assets: final or near-final copy, optimized icons (SVG) and image guidelines.
Accessibility basics from WCAG 2.2
Accessibility is much cheaper to design in than to retrofit. The Web Content Accessibility Guidelines (WCAG) 2.2 are the current W3C recommendation, and level AA is the usual target for business websites and applications. At the prototype stage, check at least the following:
- Color contrast: at least 4.5:1 for normal body text, 3:1 for large text, and 3:1 for UI components and meaningful graphics.
- Visible focus: every interactive element needs a clear focus indicator, and sticky headers or cookie banners must not completely hide the focused element (a requirement added in 2.2).
- Target size: WCAG 2.2 adds a minimum target size of 24 by 24 CSS pixels for pointer targets, with some exceptions. Larger targets are better on mobile.
- Dragging alternatives: any drag-and-drop action needs a single-pointer alternative, such as buttons to move items.
- Forms: visible labels, clear error messages that explain how to fix the problem, no asking users to re-enter information they already provided in the same process, and login flows that don't rely solely on memorizing or transcribing codes.
- Consistent help: if you offer help (a contact link, chat, FAQ), put it in the same place across pages.
The W3C's summary of what's new in WCAG 2.2 is a good, readable starting point for non-specialists.
How prototypes de-risk SaaS and WordPress projects
SaaS and web applications
For a SaaS product, the biggest risk usually isn't technical. It's building features nobody uses, or building the right features in a way people can't figure out. A clickable prototype lets you validate the core workflow with potential customers, and even pre-sell it, before you pay for back-end architecture. It also gives developers a precise picture of screens, roles and data, which produces more reliable estimates for an MVP. If you're at that stage, our guide on how to build a SaaS MVP covers what comes next, and our web application and SaaS development team can take a validated prototype straight into production.
WordPress websites
On WordPress projects, prototyping settles which page templates you really need, which sections should be reusable blocks, and what editors can change. That keeps the template count and the budget under control, and it avoids a site that looks great at launch but is painful for the marketing team to update. Our WordPress theme and website development projects build directly from approved prototypes, so each designed component becomes a matching editable block.
A typical 2–3 week prototyping sprint
The exact plan depends on scope, but most website and MVP prototyping engagements follow a similar rhythm. Here's a typical three-week version. Smaller projects compress the first two weeks into one.
| Timing | Activities | Output |
|---|---|---|
| Days 1–2 | Kickoff, review the brief, stakeholder interviews, competitor and reference review | Agreed goals, audiences, success metrics and constraints |
| Days 3–5 | User flows, sitemap or app structure, low-fidelity sketches | Approved flows and information architecture |
| Week 2 | Wireframes for key screens, clickable prototype of priority flows, first usability test round | Tested clickable prototype and an issue list |
| Week 3 (first half) | Iterate on findings, apply visual design, build the component inventory | High-fidelity prototype of core screens |
| Week 3 (second half) | Optional second test round, accessibility review, handoff documentation, development estimate | Developer-ready handoff and a refined quote |
Timeline and cost vary with the number of unique screens, user roles and integrations. For broader budgeting context, see our breakdown of WordPress website development costs.
Prototyping deliverables checklist
By the end of a prototyping phase, you should have something you can hand to any competent development team. Use this checklist to confirm nothing is missing:
- Documented goals, target users and success metrics
- User flows for every priority task, including error and empty states
- Sitemap or application structure with agreed labels
- Wireframes for all unique templates or screens
- Clickable prototype covering the core journeys
- Usability test notes, with the issues found and how each was resolved
- High-fidelity designs for desktop and mobile breakpoints
- Component inventory with variants and interaction states
- Design tokens (color, typography, spacing, breakpoints)
- Accessibility notes (contrast, focus order, target sizes, form labels)
- Content plan: what's final, what's placeholder, and who owns each piece
- A development scope and estimate based on the approved prototype
When you can skip (or shrink) prototyping
Prototyping is an investment, and not every project needs the full version. You can usually scale it down or skip it when:
- The project is small and conventional. A single landing page or a simple brochure site built on well-understood patterns may only need a wireframe and a design review.
- You're rebuilding something proven. If an existing product works well and the goal is a technical migration with the same user experience, the current product is effectively your prototype.
- The work is mostly back-end. Integrations, performance work, data migrations and many plugin projects have little or no user interface to prototype. A clear technical spec matters more there.
- A trusted design system already exists. If new features can be assembled from tested components, a quick flow review may be all you need.
Even then, a short conversation about user flows almost always pays off. Skipping prototyping should be a deliberate decision, not a default.
Frequently asked questions
How much does UX prototyping cost compared to development?
It depends on scope, but prototyping is usually a modest share of the total project budget, and it often pays for itself by reducing rework and change requests during development. It also leads to more accurate development quotes, because the scope is visible and agreed before the build starts.
How long does it take to prototype a website or app?
A focused prototyping sprint typically takes 2–3 weeks for a business website or SaaS MVP. Smaller projects, such as a single landing page, may need only a few days of wireframing. Complex applications with many user roles can take longer.
Is five users really enough for usability testing?
For finding the most significant usability problems in a single round, around five representative users is usually enough. It's more effective to run several small rounds and fix issues between them than to run one large test. Quantitative questions, like measuring conversion rates, need much larger samples.
What is the difference between a wireframe and a prototype?
A wireframe is a static, usually grayscale layout that defines structure and content hierarchy. A prototype is interactive: screens are linked so people can click through tasks. A prototype can be low fidelity (linked wireframes) or high fidelity (close to the final visual design).
Can developers build directly from a Figma prototype?
Yes, if the handoff is complete. Developers need specs, design tokens, component states, responsive behavior, interaction notes and accessibility requirements, not just static screens. A well-prepared Figma file lets developers inspect measurements and export assets directly.
Do I need prototyping for a WordPress website?
For most custom WordPress sites, yes. It helps settle which templates and reusable blocks you need and what editors should be able to change. That keeps the build focused and the budget predictable. A very small site built on standard patterns may only need wireframes.
Planning a new product or website and want to test it before you pay for development? Our custom development and UX prototyping services take you from idea to a tested, developer-ready prototype. Then we build it. Tell us about your project in the project planner to get a free quote after discovery, or browse our fixed-price packages on the pricing page.
