The process of taking an idea for a new tool or feature, or a solution to an existing problem, and turning it into something people actually want to use, is not always simple or easy. It’s easy to make mistakes in planning. So we need prototyping to test ideas. The trouble with prototypes is that they involve a trade-off between how useful they are and how costly and time-consuming they are, which means that in the past they’d often be used to validate designs rather than invalidate and iterate on them.
Rapid prototyping changes that, and it changes the design and development process at the same time. Now, it’s not planning but testing that determines the shape of the final product. In this post, we’ll look at how that’s achieved and why it matters, but first, we’ll get to grips with what rapid prototyping is.
What is rapid prototyping?
Rapid prototyping allows us to build something we can test and assess, quickly and with as little capital outlay as possible. That means we can test it more before we build the production version and deploy it, meaning we can make our mistakes quickly and inexpensively.
A different approach to building software can only go so far before its effects become more far-reaching and profound. This is also true of rapid prototyping. It changes the way we think about designing software, moving the emphasis from planning to iteration, which means it changes the processes we use to develop it too. Approaches to software development like waterfall leave too little room for iteration to allow full use of this approach. Agile is perfect for it.
However, there’s no reason to iterate if there’s no feedback from the target activity. We need data to base changes on, and we have to get it quickly and relatively cheaply. We can’t test new features by deploying them to production, because of the expense (and risk!). That’s why user experience is often where rapid prototyping shines.
The majority of rapid prototyping is on the basis of UX, for two reasons. First, because software sinks or swims by UX, even when the end-user isn’t the purchaser: the literature of SaaS, formal and otherwise, is filled with commentary on how important it is to get buy-in from end-users. Without it, salespeople bypass CRM, marketers make their own arrangements on their own ad-hoc stacks of spreadsheets and freeware, logistics data can’t be relied on and productivity suffers throughout the organization. Second, we can obtain user experience data relatively quickly from observing and surveying test users, and rapidly alter UX elements on the basis of this data.
We’re all familiar with this idea. Rapid prototyping doesn’t enable us to herd users onto the gravel pathway, but to pave the path they’re already using.
How does rapid prototyping differ from plain old prototyping?
Rapid prototyping uses different processes to create prototypes. It’s not just the same thing done faster. That distinction exists in physical production where different tools and systems are used. It exists in software development too for the same reason.
In software, we use different processes and tools too. Rapid prototyping uses a three-phase iterative process.
The rapid prototyping process
The process involved is relatively simple.
Teams develop one or more initial prototypes, working from the design document (a living document which is updated on the basis of previous tests, or a best-practice-plus-best-estimates template if no data is yet available). The stage of development dictates the quality, fidelity and interactivity of prototypes, but as a rule, higher fidelity is required for live user testing.
The prototype is shared with the testing group. This might be another team within the organization with other skills, or who resemble the target audience. It might be live users of the extant product who have signed up for early access to a new feature. Or it might be test users. Design and usability are evaluated and feedback is passed back to the team.
The design document is updated, scope and requirements changed, and a new prototype is created based on the feedback received.
There’s nothing unique about this process. What’s different about rapid prototyping is the expectation that the process will be repeated until a set cut-off (number of iterations, time, or some other factor) is reached, and that feedback and iteration rather than planning will inform major design decisions.
High-fidelity vs low-fidelity prototyping
Fidelity, in prototyping, means degree of approximation to the finished product. A freehand pencil sketch on a piece of paper is as low-fidelity as it gets. A fully functional piece of software being tested for the final time before general release is as high-fidelity as it could be.
Lower-fidelity prototypes are quicker and easier to produce, so they’re typically used in the very early stages. Higher-fidelity prototypes are costlier and more time-consuming. As Google Ventures’ Daniel Burka says in Jake Knapp’s Sprint, ‘the ideal prototype should be “Goldilocks quality.” If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night, and you won’t finish. You need Goldilocks quality. Not too high, not too low, but just right.’
By the time live users are testing the product, though, the rule of thumb is that it should be indistinguishable from the finished product — to them. You might know that it’s a limited-feature, lightweight version that doesn’t closely resemble the eventual release. If they do, they’ll offer helpful suggestions — which are of limited value — instead of genuine user feedback data, which is gold dust.
Rapid prototyping code
We don’t always prototype and test a whole product — any more than physical engineers build a whole plane, then find out if it flies. They test components separately; so do we. Rapid prototyping uses doodles and sketches, and rapidly-created high-fidelity flows built in tools like Invision. But it also uses sections of real code, especially when it comes to testing components like checkout flows: high-value, simple, and extremely sensitive to UX.
Typically, even live code won’t be totally faithful to the finished product. You might use different frameworks of a different database structure, chosen for speed rather than long-term viability. There’s no reason for rapid prototyping to cause us to develop an overly complicated or poorly-coded product (rather the reverse), but the prototypes themselves can be a bit quick and dirty under the hood. We’ll typically architect for disposability, meaning that by the time we’re testing specific elements of a mostly-built tool we’re working to segregate the code as much as possible from the main codebase. That way we can iterate it in isolation — or throw it away if we have to, without disturbing the functionality of the main tool.
Why rapid prototyping is used
Rapid prototyping offers three critical advantages: it’s much faster, less expensive, and gives you a model of the finished piece that you can comprehensively assess and test much sooner. Rapid prototyping delivers:
- Verification. Designers and developers can check with stakeholders: is this what you meant? Is this how you want the product to work? Sometimes, clients and other stakeholders give imprecise instructions or don’t fully know what they want. Resolving those issues at the wireframe stage saves hours of expensive developer and designer time.
- Integration. Rapid prototyping fits perfectly with agile software development; same mentality, same processes, same goals. In fact, it’s the only prototyping methodology quick enough to keep up with agile!
- Bridging the gap. Before any code is written, rapid prototyping tools can offer surprisingly lifelike previews into software appearance and functionality.
- Buy-in and consensus. Related to the first point, rapid prototyping has the potential to get everyone in the company on the same page about requirements, expectations, and objectives, quickly and through their own experience rather than persuasion or debate. The result, buy-in throughout the organization, makes developing effective software faster and cheaper.
- Live demonstrations. In demonstrations with stakeholders, someone can request a change and it can be made and demonstrated on the fly. This can also be done to demonstrate why the idea had already been dismissed, demonstrating adverse effects on usability. The alternative, rewriting real code, can’t be done in the confines of a meeting and costs money as well as time.
Custom analytics and rapid prototyping
Web dashboard application custom built to manage Bloomberg's complex internal data structure - built by AndPlus
Bloomberg, the leading financial services information company, developed and launched a sophisticated information tool to help major banks with their risk management. AndPlus designed an intuitive web app that lets users access, analyze and leverage the ‘dark data’ within their networks.
Bloomberg might be technical experts in this space, but they didn’t have the technical bandwidth available for this project, and the UX element was not their core strength either. AndPlus’ front-end development experience, together with extensive skills with large datasets and complex APIs, meant we were a perfect match. Being comfortable with agile meant we were able to help Bloomberg experiment with new features, then rapidly iterate on them to meet their customers’ needs. Rapid prototyping enabled us to build the features Bloomberg needed, without taking forever or breaking the bank; it also let us ratchet up the quality of our planning and our code as we dialed in what their customers wanted through successive iterations.
‘The quality of the work got better over time, which is a product of their understanding more over time of what we were trying to build and what our coding style is like,’ said David Cutler, Bloomberg’s senior product manager. ‘We really needed a partner who could offer us consulting on how things can be done efficiently and that is something that they were able to do for us as well.’
To learn more about how we used rapid prototyping to build custom analytics for one of the world’s foremost information companies, read the case study here.
- Rapid prototyping differs from traditional prototyping in its conceptual approach, the tools used, and the emphasis on multiple iterative cycles. It’s there to develop the product, not confirm the plan
- Because it focuses on short iterative cycles, rapid prototyping is a great match for agile development
- It’s often used to develop UX-centric tools and applications because UX is less predictable than other functions, and more improvable by testing
- We’ll typically use higher-fidelity prototypes as we move from testing inside the organization to doing live user testing
- Rapid prototyping is well suited to developing even complex applications like the one we built for Bloomberg