What is is rapid prototyping? And how can is rapid prototyping applied to web design. Let’s first define what “traditional” UI prototyping is. UI prototyping is basically a way of using visuals to describe what words can’t. It shows the design and the programming of how a certain system should behave and look.
Rapid prototyping is the natural progression of “traditional” UI prototyping (duh…). It could be defined as taking an iterative approach to designing a UI.
It’s (in general terms) the process of rapidly sketching a desirable outcome of the UI of a webpage, web-app or mobile app. This process has clear benefits in that it during the process helps in reaching a level of validation from the future users of the system, from project stakeholders but also its designers.
Having a repetitive design process is very efficient when you want to generate feedback early (and quickly). And believe me, that is something you want. Getting feedback early and often will improve the final design but also drastically reduce the need for alterations to the design during the actual programming of the system.
Today, rapid prototyping for web design can be done in a lot of ways. By pasting paper sketches to a wall or through actual working prototypes with real content.
The idea is that rapid prototyping quickly generates feedback which in turn is used to continue refining the prototype until enough questions have been answered.
Rapid prototyping should, more than anything, assist designers in experimenting with different approaches and ideas. Sketches/prototypes/wireframes should speed up design discussions and more quickly reach a common understanding faster and better.
How the rapid prototyping process works
Rapid prototyping involves multiple iterations of a three-step process:
- Create prototype
Starting with established design patterns and after talking to initial users create the first mockup of the system.
- Share and listen
Share the prototype with your users (and key project stakeholders) listen to what they say and evaluate if you’re on the right track.
- Refine the prototype
Based on received feedback, identify the areas that needs further refinement.
Rapid prototype scoping
The initial prototype should be small with a few defined areas sketched out. This prototype could (not necessarily should…) then expand in scope during the course of different iterations until a consensus is reached and the prototype is delivered for final development. This process should be fast. How fast obviously depends on the project and the scope of the prototype.Note, the prototype, not the project.
Important to understand is that a rapid prototype is not done in order for it to later morph into a fully functional prototype. It’s there to assist in helping putting into visuals the UX of the final product. That’s why it’s always good to, before you start out, decide on why you’re doing the prototype.
Is a prototype really needed?
Let’s be honest. Not everything needs to be prototyped. A lot of design patterns are well established and there is really no need for prototyping. But whenever you have a design pattern that is slightly new or novel, prototyping it is a good idea.
When thinking about a new functionality, a new type of workflow, a new technology or even a new “type” of visual design prototyping is probably a good idea. Put an example here
How much prototyping is enough?
Ever heard of Paretos principle? In short, this principle states that; for many events, roughly 80% of the effects come from 20% of the causes. This principle can be put to good use when doing rapid prototyping.
In fact, one could say that 20% of a UIs functionality is being used 80% of the time. Focus on that 20%. Another take on this is what 37 Signals used to call epicenter design.
Identify the Job-To-Be-Done of the different elements
Once decided which parts of the UI is crucial for your prototype you should identify the jobs you want these design elements or functionalites to do. This is a different approach from working with personas but I believe it’s more efficient.
- Decide what the job for the different UI elements are
- Identify in what context they will be performed
- Roughly identify who will use these functionalities
When starting iterating your prototypes start by first “sketching horizontally”, sketch the most important landing pages first. Conduct a quick review of this first iteration to check that you’re on the right track. Following iterations should then focus on the different UI elements your team decided as being part of the 20% of functionalities.
Decide on correct level of fidelity
With fidelity we refer to the amount of realism of the prototype. Depending on the ambition of the prototype and its design you have different options for fidelity:
- Sketched or “graphically designed”
If you’ve been in the web industry for a while you know that this can be especially tricky. Prototypes with too much detail can easily derail any design review. Especially if clients are involved. Presenting too much detail too soon have the tendency of getting users focused on visuals instead of concepts. (You can read more about this here). More refined visuals could be introduced in future iterations of the prototype. (brand, colors etc)
- Static or “clickable”
No mystery here really. A good rule of thumb would be to add the minimal interactivity necessary (for example, avoid including landing pages not relevant for the current iteration)
- Does it need lorum ipsum or “real” copy
Just like detailed visuals have a tendency to derail design reviews, detailed content can have the same exact effect. As the prototype evolves, add more “real” content and study what effect it has on the overall design.
Prototyping fidelity options
The fastest way to get started is of course using pen and paper. Anyone can do it, no special skills needed. It’s the perfect tool during initial brainstorming sessions and can be done in both group settings or alone. Sketchbooks, whiteboards, flip charts are the obvious go-to tools in this phase.
Starting off with paper prototyping is a great way to force project stakeholders to focus on how the system will be used rather than what colors and how border radius of certain boxes. It has the added bonus in that it opens up designers to be more open to changes based on what feedback they got from their users.
Low fidelity prototyping is ideal for rapid prototyping. There are no steep learning curves, they’re adaptable and agile.
Here we start to use tools like Balsamiq or Omnigraffle in order to create our prototypes. Compared to paper it takes more time and it doesn’t lend itself very much to spontaneous collaboration but the result is more realistic.
Medium fidelity prototyping is more efficient when you want to focus on the actual behavior of your solution. You’d do good avoiding including any visual elements, colors, branding etc.
A great thing with medium fidelity tools like Balsamiq is that they actually give you the option of presenting prototypes that “look low-fidelity” but acts “medium fidelity”. This way you trick your users to think of the prototype as a draft and not as a final design. You could also go the opposite way and introduce elements designed in Photoshop to a Balsamiq mockup, making a medium fidelity solution look high-fidelity.
Some times more realistic prototypes are required. For example when you need to show the possibilites of what a new technology. (mobile apps/smartphones/wearables comes to mind)
High-fidelity prototypes compared to low fidelity protoypesi are of course more time-consuming. But today there are numerous applications that actually lets you simulate very advanced simulations by simply dragging and dropping UI widgets. Axure and Invisionapp are great examples of high-fidelity tools.
Creating high-fidelity prototypes also comes with the added value that they lend themselves well to conducting deep usability testing.
Today, high-fidelity prototyping is faster than one would think. Especially if you consider what you get (a high level of interactivity combined with refined visuals).
With more and more tech-savvy web designers entering the web industry, sketching directly in CSS is getting popular.
Selecting a fidelity level
This is of course tricky and it depends on multiple things. But it seems as almost all new apps/websites starts as paper prototypes. Then moving to a tool like Balsamiq or directly to a high-fidelity tool like UXPin. But it all depends on how complex the system is (is it a one-page-app, or a redesign of a multi-language webpage for an NGO).
Sometimes the fidelity level depends on what kind of professionals you have on your team. For example, small web agencies would do good in moving directly from paper prototyping to CSS sketching (using Flexbox for example). Sometimes the type of client dictates what level of fidelity to be employed.
How to select tools
Depending on what fidelity level you choose, you have a wide variety of tools to choose from. To get you started we’ve compiled a list of 70 design collaboration tools.
Based on your needs and the requirements of the projects you work on evaluate which tool would be most appropriate.
Here are some questions to consider when evaluating different tools:
- How fast can I share my prototype to others?
- Can the tool capture comments and feedback?
- Can my team learn to use it in a day?
- Does it work for webapps as well as mobile apps?
- Are there any reusable widgets available?
- Can I collaborate in real-time with others when building the prototype?
- Is there a free trial?
Getting started with rapid prototyping
Here are a few points to keep in mind when starting out:
- Design collaboratively as early as possible. Identify and invite crucial project stakeholders in the prototyping early. This will give you a better end product but it will also give stakeholders a sense of ownership. (because they essentially helped you design the product)
- Follow the 80/20 rule. Focus the prototype to solve the 20% of functionality that will drive 80% of the usage.
- Build up a library of templates, stencils and design patterns that you can re-use for future projects.