Prototyping services that show you what works before you pay to build it.
About to sign off a build? Need the board onside? A clickable prototype lets you test the idea with real people first, while changes still cost hours, not weeks.
For Teams About to Commit Budget, Win Sign-Off or Test Something New
Find out on a Tuesday afternoon, not three months into the build.
Maybe you've got budget earmarked for a redesign and want proof before it's spent. Maybe the board needs to see something before they'll say yes. Or maybe there's a new feature or flow nobody's sure users will manage. All three are prototyping jobs.
Our prototyping services turn an idea into something people can click, from rough sketches to near-finished screens. We build only what needs testing, keep you in every review, and tell you straight when something isn't working.
Why Teams come to us?
“We don't want to pay to find out it doesn't work.”
We test the idea as a clickable prototype first. If it falls over, it falls over in a shared link, not in code you've paid for.
“The board wants to see it before they'll approve it.”
Boards rarely get excited by a deck. Give them something to click through on their own laptop and the conversation moves from "what if" to "when".
“We want real users to try it before we build it.”
Prototypes can go straight into usability testing. We watch real people use the flow, note where they stall and fix it before anyone writes code.
“We don't know if this new feature will actually work."
Walking through a prototype surfaces the awkward bits early, like the missing back button or the form that asks twice. At this stage they're a ten-minute fix.
The Gecko Way™
Our approach to successful projects
Before we sketch anything, we want to know what the prototype has to prove. Is it a go or no-go on a new feature? Something the board needs to see before signing off the build budget? A checkout flow nobody quite trusts? We'll look at what you already have (research from a UX strategy piece, analytics, support tickets, the complaints your sales team keep hearing) and talk to the people who'll be reviewing it. By the end of this stage we've agreed the handful of flows worth prototyping and, just as usefully, the parts of the site nobody's questioning, so no time or budget goes on them. Getting this right shapes the rest of the prototyping process.
Next we decide how finished the prototype needs to look, because the answer changes with the question. If you're testing whether a journey makes sense at all, a low fidelity prototype made of plain grey boxes is quicker to build and stops people getting distracted by colours. If the board needs to picture the finished thing, or you're testing the detail of how a form behaves, high fidelity earns its keep. We'll also agree who reviews what and when, and whether the prototype will go in front of real users. Settling this upfront means the scope, and the cost, are clear before any building starts.
Then we build it. Screens are linked together so you can click through the flow the way a customer would, on a laptop or a phone. We use your real content wherever we can, because "lorem ipsum" has a habit of hiding problems, like a product name that's twice as long as the box it's meant to sit in. You'll get a shareable link early and we'll review it together in short rounds, rather than disappearing for a fortnight and unveiling something. If a step feels clunky when we click through it with you, we change it while it's still quick and cheap to change. It's rapid prototyping in the plain sense: quick rounds, quick changes.
Now the prototype gets put to work. That might mean stakeholder walkthroughs, a session with your board, or usability testing with real users, where we watch people try to complete tasks and note exactly where they hesitate. We'll pull the feedback together and tell you plainly what it says, including the bits you might have preferred not to hear. If the idea doesn't hold up, that's a good result at this stage (honestly), because you've found out for the cost of a prototype rather than the cost of a build. Then we iterate, and test again if the changes are big enough to need it.
Once the prototype's validated, it becomes the blueprint for what comes next. You get the prototype itself, plus a short record of what was tested, what changed and why, and the decisions agreed along the way, so nobody has to rely on memory six months later. If we're carrying on into full design and development, our designers and developers pick it up directly (they'll usually have sat in on the reviews already). If you're taking it elsewhere, it's yours to take. Either way, the thing that gets built is the thing that was tested, not somebody's fresh interpretation of it.
What's Included in Our Prototyping Services
Flow & Feature Definition
Prototyping a whole website is rarely a good use of anyone's budget. Most of the risk sits in a few places: the booking journey, the new account area, the donation form that's losing half its users by step three. We work with you to pick those out, based on what the project's meant to achieve and where a wrong call would cost the most.
You'll come away with a short, agreed list of flows or features to prototype, each with a line on what it needs to prove. That list keeps the work focused and the cost sensible, and it gives your stakeholders a clear idea of what they're actually being asked to judge.
Low & High Fidelity Prototyping
Low fidelity prototypes are deliberately plain: grey boxes, simple labels, no brand colours. They're quick to make and quick to change, which makes them ideal for testing structure, page order and whether a journey makes sense.
High fidelity prototypes look close to the finished thing, with your branding, real content and realistic touches like dropdowns and error messages. They take longer, but they're what you want when you're testing detail or showing a board what they're buying.
Plenty of projects use both, starting rough to settle the structure and moving to high fidelity once the big questions are answered. We'll recommend which fits, and explain why. When speed matters most, rapid prototyping in low fidelity gets a rough journey in front of people fast.
Clickable Prototypes for Review
A clickable prototype links screens together so people can move through them as they would on a real site: tap a button, open a menu, fill in a form, land on the confirmation page. It's shared as a simple link, so anyone can open it on their own laptop or phone without installing anything. That matters when you're after buy-in.
A board member who's clicked through the new journey themselves tends to ask better questions than one who's flicked through a slide deck, and they find it far easier to picture what the investment gets them. We can also walk your stakeholders through it with you, if you'd like some backup in the room.
Usability Testing on the Prototype
If you want evidence rather than opinion, we can put the prototype in front of real users before anything's built. Participants are asked to complete specific tasks, like finding a price or booking a call, while we watch where they hesitate, misread a label or give up altogether. A prototype is one of the cheapest points in a project to run usability testing, because everything you learn can still be changed in minutes.
You'll get a clear summary of what we saw, what it means and what we'd change. It's optional, and not every project needs it, but when a decision is expensive or hotly debated, watching a handful of people try the thing settles it quickly.
Feedback & Iteration
Feedback only helps if something happens to it. After each round of reviews or testing, we pull the comments together, sort the genuine problems from the personal preferences, and agree with you what changes. Then we update the prototype and, where it's worth doing, test the new version again. This loop is the whole reason to prototype.
Moving a button, rewording a step or cutting a page from the flow takes minutes at this stage. The same change after launch can mean design time, development time, testing and a release. We'll also tell you when a piece of feedback points the wrong way, because not every comment from a review deserves a change. Most of the value in the prototyping process comes from this back-and-forth rather than the first version.
Handoff into Design & Development
Once the prototype's validated, it moves into full design and development with nothing lost in translation. Designers use it as the agreed starting point for the finished visual design, and developers can see exactly how each screen should behave, from what happens when a field's left empty to where each button leads.
Alongside the prototype you get a record of the decisions made and the reasons behind them, which saves a lot of "why did we do it this way?" conversations later. If Gecko is designing and building the site, often in Umbraco, the same team carries it through. If you're working with another developer, the handoff is written so they can pick it up cleanly.
What's Included in Our Prototyping Services
Flow & Feature Definition
Prototyping a whole website is rarely a good use of anyone's budget. Most of the risk sits in a few places: the booking journey, the new account area, the donation form that's losing half its users by step three. We work with you to pick those out, based on what the project's meant to achieve and where a wrong call would cost the most.
You'll come away with a short, agreed list of flows or features to prototype, each with a line on what it needs to prove. That list keeps the work focused and the cost sensible, and it gives your stakeholders a clear idea of what they're actually being asked to judge.
Low & High Fidelity Prototyping
Low fidelity prototypes are deliberately plain: grey boxes, simple labels, no brand colours. They're quick to make and quick to change, which makes them ideal for testing structure, page order and whether a journey makes sense.
High fidelity prototypes look close to the finished thing, with your branding, real content and realistic touches like dropdowns and error messages. They take longer, but they're what you want when you're testing detail or showing a board what they're buying.
Plenty of projects use both, starting rough to settle the structure and moving to high fidelity once the big questions are answered. We'll recommend which fits, and explain why. When speed matters most, rapid prototyping in low fidelity gets a rough journey in front of people fast.
Clickable Prototypes for Review
A clickable prototype links screens together so people can move through them as they would on a real site: tap a button, open a menu, fill in a form, land on the confirmation page. It's shared as a simple link, so anyone can open it on their own laptop or phone without installing anything. That matters when you're after buy-in.
A board member who's clicked through the new journey themselves tends to ask better questions than one who's flicked through a slide deck, and they find it far easier to picture what the investment gets them. We can also walk your stakeholders through it with you, if you'd like some backup in the room.
Usability Testing on the Prototype
If you want evidence rather than opinion, we can put the prototype in front of real users before anything's built. Participants are asked to complete specific tasks, like finding a price or booking a call, while we watch where they hesitate, misread a label or give up altogether. A prototype is one of the cheapest points in a project to run usability testing, because everything you learn can still be changed in minutes.
You'll get a clear summary of what we saw, what it means and what we'd change. It's optional, and not every project needs it, but when a decision is expensive or hotly debated, watching a handful of people try the thing settles it quickly.
Feedback & Iteration
Feedback only helps if something happens to it. After each round of reviews or testing, we pull the comments together, sort the genuine problems from the personal preferences, and agree with you what changes. Then we update the prototype and, where it's worth doing, test the new version again. This loop is the whole reason to prototype.
Moving a button, rewording a step or cutting a page from the flow takes minutes at this stage. The same change after launch can mean design time, development time, testing and a release. We'll also tell you when a piece of feedback points the wrong way, because not every comment from a review deserves a change. Most of the value in the prototyping process comes from this back-and-forth rather than the first version.
Handoff into Design & Development
Once the prototype's validated, it moves into full design and development with nothing lost in translation. Designers use it as the agreed starting point for the finished visual design, and developers can see exactly how each screen should behave, from what happens when a field's left empty to where each button leads.
Alongside the prototype you get a record of the decisions made and the reasons behind them, which saves a lot of "why did we do it this way?" conversations later. If Gecko is designing and building the site, often in Umbraco, the same team carries it through. If you're working with another developer, the handoff is written so they can pick it up cleanly.
"When your team's already clicked through every step of the prototype, I can build it once instead of rebuilding it after launch."
John Logan, Full Stack Developer at Gecko
Prototyping Case Study
[CASE STUDY PARAGRAPH, ~60-70 WORDS: TO BE WRITTEN ONCE A CONFIRMED PROTOTYPING PROJECT IS AVAILABLE. DO NOT PUBLISH AS-IS.]
A prototype is a working model of a website, app or feature that people can click through before it's built for real. It looks and behaves enough like the finished thing to test whether an idea works, without paying to design and develop all of it. You need one when getting it wrong would be expensive: a redesign with a big budget attached, a new feature you're not sure users want, or a project the board won't approve on a written proposal alone. Our prototyping services sit between the thinking and the building. If you're still working out what the site needs to do, UX strategy is usually the step before. Once the prototype's validated, it moves into UI/UX design. Whether it's a new product idea or a change to an existing journey, the principle's the same. One thing to be clear on: we prototype websites and digital products, so if you're after a physical prototype of a product, a manufacturing specialist is the right call.
A wireframe is a static layout of a single page. It shows where things go (the navigation, the headline, the form) but you can't click on anything. A prototype links screens together so you can move through a journey the way a user would, pressing buttons, opening menus and filling in forms. Wireframes are good for agreeing structure. Prototypes tell you whether that structure actually works when someone's using it. In practice, a low fidelity prototype is often a set of wireframes that have been joined up, so the two aren't competing options. One is a drawing of the room, the other lets you walk through the door. Both have a place in a good design process, usually wireframes first and a prototype once there's a journey to test. Where behaviour matters as much as layout, like a form that checks entries as you type, we can build functional prototypes that respond much like the real thing. Functional prototyping takes a little longer, so we save it for the moments that need it.
It depends on how many flows are being prototyped, the level of fidelity and whether usability testing is included. A single low fidelity journey can come together quickly, while several high fidelity flows with a round of user testing and iteration will naturally take longer. As a guide, most prototyping projects take [TYPICAL TIMELINE, TO CONFIRM WITH MARK]. We'll give you a timeline before we start, based on the specific flows we've agreed, and we'll tell you early if anything shifts. If you're working towards a board meeting or a budget deadline, let us know the date at the start and we'll plan backwards from it. If time's tight, rapid prototyping that sticks to low fidelity and one or two key flows is the quickest route to an answer. Most of that time goes on review and iteration, which is where the prototyping process does its most useful work. The functional parts, like forms, search and account areas, usually take the longest, because that's where most of the questions are.
Yes, and it's one of the best times to do it. We can run usability testing on the prototype itself, asking real participants to complete tasks while we watch where they get stuck, misread something or give up. Because nothing's been built yet, whatever we find can be fixed in minutes rather than development sprints. Testing works on both low and high fidelity prototypes, though the questions differ: low fidelity is best for testing structure and journeys, high fidelity for detail like wording and form behaviour. You can find out more about how sessions run on our Usability Testing page. Testing with users at this point is the cheapest way to learn a lesson you'd otherwise learn after launch. Adding a testing round to the prototyping process is optional, but it's usually where the clearest answers come from. Our designers watch the sessions too, so what users struggle with goes straight into the next version.
We can. Gecko designs and builds websites, with Umbraco as our home turf, so a validated prototype can move straight into full UI/UX design and development with the same people who've been involved from the start. You don't have to carry on with us, though. The prototype and the record of decisions are yours, and they're set up so another team can pick them up. Plenty of clients find it easier to keep everything under one roof, because nothing gets lost between the people who tested the idea and the people building it, and we can look after the site with ongoing support once it's live. The same applies if you've got in-house design teams who'd rather take the finished visual design on themselves. It means one team from concept to production, with no gaps in the handover. And if functional prototyping has already settled how the forms behave, development starts from a working reference rather than a guess.
The cost depends on the number of flows, the level of fidelity, and whether usability testing is part of the work. A single low fidelity journey costs far less than several high fidelity flows with testing and a couple of rounds of iteration. [PRICE GUIDANCE OR TYPICAL RANGE, TO CONFIRM]. What we can promise is a fixed quote once we've agreed the scope together, so you know the number before any work starts and it won't creep. Weigh it against what you're protecting, too. Compared with the build it's de-risking, a prototype is a much smaller commitment, and a lot cheaper than rebuilding a feature nobody uses. If budget's the main concern, rapid prototyping in low fidelity is the lightest-touch way to start. Rounds of user feedback add to the cost too, so we'll agree how many are included up front. A prototype isn't a production tool either, so none of your budget goes on making it ready to go live.
Rapid prototyping means building a quick, rough version of a journey, testing it and changing it in short cycles, rather than perfecting one version before anyone sees it. In web and UX work, rapid prototypes are usually low fidelity: linked screens with simple layouts and real wording, made fast enough that nobody minds throwing one away. The speed is the point. You can try two or three versions of a sign-up flow in the time it would take to polish one, then let users or stakeholders tell you which works. The same term is used in manufacturing for 3D printing physical parts, which is a different service altogether. Ours is rapid prototyping for websites and digital products. It usually picks up where early concept modelling on paper leaves off, and it skips animations and special effects entirely, because neither tells you whether a journey works.
Then the prototype has done its job, and done it cheaply. Finding out that a feature confuses people, or a journey has one step too many, is far better now than three months after launch. It's rarely all-or-nothing, though. Most of the time testing shows which parts work and which need changing, and we iterate from there. Occasionally it shows the idea needs a proper rethink, and we'll tell you that plainly rather than polishing something that won't land. Either way, you go back to your stakeholders with evidence instead of a hunch, which is a much stronger place to argue from. The same goes for a brand-new product idea: better to find out it needs reworking from a prototype than from a quiet launch. Rapid prototypes are built to be changed or binned, so there's nothing precious to protect. Finding a problem this early in the product development cycle is exactly what they're for.
Yes, and it's often where prototyping earns its place fastest. You don't need a full redesign on the table. If one journey is underperforming (an enquiry form people abandon halfway, a menu nobody can find anything in), we can prototype a better version and test it before anyone touches the live site. That's especially handy if you've inherited a website you didn't choose and aren't sure what's safe to change. The prototype shows how the improved version would look and behave. Once it's validated, we can take it from concept to production on your current site, or as part of a bigger rebuild if testing shows that's the better route. Often it's as simple as prototyping one or two drop-in alternatives for a single section and testing them against what's there now. And because the same team designs and builds, you're not passing a prototype from a design studio to a separate developer and hoping nothing gets lost in between.
Not much. A rough idea of what you're planning to build or change, what's making you nervous about it, and any dates you're working to (a board meeting, a budget round, a launch). If you've got existing research, analytics or a UX strategy, bring those along, but you don't need them to start. From there we'll book a short call, talk through what the prototype needs to prove, and come back with a scope and a fixed quote. Get in touch and tell us what you're thinking of building. We'll help you work out which parts are worth testing first. Even a half-formed product idea is enough to start that conversation. If you're still at the concept modelling stage, with sketches on a whiteboard, that's a perfectly good place to start.
Tell us what you're thinking of building and what's worrying you about it. In a free 30-minute call, we'll help you work out which flows are worth prototyping, what level of detail makes sense, and whether usability testing would earn its place. You'll come away with a clearer picture of what a prototype should prove before anyone's asked to sign off a bigger budget. There's no sales pitch and no obligation to carry on with us, just a useful conversation about your project.
