Prototypes are designed to be cheap, fast and throwaway. Keep it simple, iterate quickly, and don’t get carried away!
I recently shared a tutorial for prototyping in Axure RP. The tutorial (you can watch it here) takes you through the creation of a predictive search bar.
In this video, I make a fairly complex prototype. It uses a whole bunch of Axure’s most advanced features, so that the end result is super realistic.
But here’s the thing.
At the risk of poo-pooing my own tutorial, it doesn’t need to be this complicated.
When prototyping goes too far
My search bar tutorial was 45 minutes long. However, consider that I’d done this quite a few times before. For the uninitiated it might have taken a lot longer.
If you really need a super realistic prototype then I don’t think there’s a problem here.
- Perhaps you need to user test in a realistic environment.
- Maybe you need to see it working with real content.
- Or you could be giving a demo to some important stakeholders, and you want to make sure everything is crystal clear.
In some cases it’s warranted to prototype in this high level of detail. In most situations though, it’s probably overkill.
UX is all about rapid iteration.
It’s about coming up with an idea quickly and sharing it. If that idea fails, it should fail quickly. It means we can go back to the drawing board and try something new, with little time lost.
When you’re in the early stages of design, speed is of the essence. You want to create prototypes with the minimum level of effort. The sooner something can be tested, the better. As the fantastic folk at GDS will tell you - cut the crap and just show the thing.
The best prototyping approach communicates an idea as early as possible. If you can save time, but still get the idea across - then that’s the approach you should take.
It’s about being efficient over being a perfectionist. Perfection can come later.
Choosing your prototype fidelity
In the past I’ve talked a lot about design fidelity. Selecting the appropriate level of visual polish in your layouts.
This same principle of fidelity applies for interactivity, as well.
Choose the right level of prototype fidelity to communicate an idea. There are many ways to make a prototype, each offering different levels of fidelity and realism. You can make them…
- With paper. And your hands. Stringing together a series of sketches or print-outs can be more than enough for some informal user testing.
- With a sequence of stills. A series of non-interactive designs can be strung together in something easy like keynote or powerpoint. It’s not clever, but it’s effective when working with a fairly straightforward sequence of screens.
- With a ‘faked’ interaction. A really basic prototype made in something like Invision or Balsamiq can simulate interactions, even if the functionality doesn’t actually work.
- With a realistic, working logic. Like the tutorial I shared last week, your prototypes be built to demonstrate ‘realistic’ interactions. You can use a powerful tools like Axure RP, or even real code!
An example of prototype fidelity
Let’s go back to that predictive search field example.
Say we wanted to user test this feature, and we needed a prototype. We can set our prototype fidelity by selecting from a number of different approaches.
The fast way
Paper prototyping would be the fastest way to get this done.
We sketch out the search bar in it’s default state. In our testing, we’d ask the user how they would interact with it. When the user tells us what they would type, we write that straight onto in our sketch. We literally draw it on a piece of paper.
After this we can quickly throw down another piece of paper, with a drawing of our dropdown. Some mock-predictions can be written into this on the fly.
The longer way
We make a sequence of still wireframes that reflect the ‘ideal’ interaction, joined together like a series of slides. We can use Powerpoint of Keynote to do this.
They’re just still flat wireframes. The user can’t type anything in themselves. During testing, we’d ask them what they would have typed in, if it really worked. We may need to verbally explain how it would have applied to their specific search, but they’ll get the idea.
The longest way
We make a fully interactive prototype that the user can actually type into.
By doing this we can see specifically what they would type into the search box. The drop down appears when the user begins to type, and contains actual suggestions.
This means going to the lengths that I described in the Axure tutorial. We’re essentially creating our prototype to work just like the real thing.
The best option? As always, it depends
Like everything else in our field, there’s no right or wrong approach. Any of the three methods above would have worked.
Just understand that prototyping doesn’t always need be complicated. If there’s a requirement to make something fancy (and you have the time), then great. But don’t get carried away when it’s unneeded.
Choose your prototype fidelity based on the situation. Use your design time efficiently, and iterate quickly. After all, that’s what UX is all about.