We often talk about wireframe prototyping and rich, interactive prototyping, which are both powerful techniques for getting conceptual designs into a form that can be explored and expanded.
Where to actually use either approach, though, is something that would benefit from covering off here; a recent email from a reader reminded me that I’d promised to give some tips a while back and so, without further ado, here we go…
Wireframes
Leaving sketches and paper-prototypes to one side, Wireframe prototypes are the quickest way to explore a visual concept.
Wireframes are a little bit like the plans for a house; they represent the outlines without getting hung up on the actual implementation. It’s about deciding on the layout of a floor, if you will, without getting concerned with the colour of the carpet.
By limiting ourselves to essentially static designs, we have to gloss over a lot of the implementation detail. We won’t attempt to model how a dynamic panel works, or the validation on an order form. We will, however, be able to quickly create visual representations of designs for forms and pages with a minimum of fuss. We’ll be able to do it quickly, and because our tools don’t attempt to let us do anything particularly complicated (such as navigating between wireframe ‘pages’), we won’t get distracted as much and can focus on our designs.
Wireframes, then, are ideal for the earlier stages of requirements prototyping, when there are layouts and ‘broad-stroke’ design choices to be explored.
Wireframes are suitable for:
- Deciding on what things should be included in a page;
- Investigating where things should be placed on a page;
- Creating low-fidelity mock-ups to help build the ’skeleton’ of an application without investing too much time;
- Comparing and contrasting different layouts;
…and so forth.
What Wireframing doesn’t do so well is allow modelling of paths through a system, or interaction, or the finer detail of design.
Interactive (Rich) Prototyping
Rich prototypes are more commonly used once the basic decisions about a design have been made. In other words, by the time we switch to rich prototyping, we generally know how many pages, and roughly what will be on each page. We may not know how the various parts of a page will work, nor how individual pages will inter-relate with other pages, but the basic shape of a design is there.
The move to rich prototyping is borne of a need to explore the specific implementation of designs. In other words, modelling how functionality works, rather than simply glossing over such detail. A good example for a rich prototype would be building a tabbed dialog so that clicks on tabs change the content, showing the tab state change and effectively simulating a real tabbed dialog.
Rich prototyping takes a proportionately longer time to do than Wireframe prototype development, due to the need to provide additional detail, interaction with forms, navigation and even simulated data. Rich prototyping also varies in its complexity – it’s possible to create incredibly rich and accurate simulations of key pages, whilst building lower-fidelity versions of less important pages. This allows the designer to prioritise her efforts to ensure that maximum value is extracted from the creation of prototypes with regard to ironing out any design gremlins.
Rich prototypes are suitable for:
1) Exploring the finer design details once the basic shape is in place;
2) Providing a realistic ‘finished system’ experience to allow users to get a chance to try out the complexities of a design ahead of the development phase;
3) Really ‘getting inside’ a design of key pages to ensure that a design really does work.
The drawback of rich prototyping is generally in the time it takes to do, and the need to use (often expensive) software.
A combined approach
The purpose of this article was to give a few reasons why a designer might choose a wireframe or a rich prototype approach. However, the best approach is generally to mix and match as suits the needs of the project.
For instance, work with the business to mould the basic shape of a system using wireframing techniques, comparing alternative layouts or page compositions, without worrying too much about how it looks and the finer detail of how each page will work. Once the major layout and composition detail is stable, select parts of the design which might be either fundamentally important to the success of a design (e.g. a registration process) or involve a slightly unusual layout or functionality. These are the things that can then be modelled in a rich prototype, and examined in more detail – perhaps by using them as the basis for user feedback sessions.
Whichever method you use, be assured that just by adopting requirements prototyping techniques into your project, you are dramatically increasing your project’s chances of success!
One tactic which is worth covering is to understand your audience and how they will perceive your prototype. A technical audience will doubtless look at your prototype in an entirely different way to a business audience, which in turn will probably look for different things than would an audience of end-users. The key is to tailor your approach to demonstrating your prototype so that:
‘Free’ training simulations allow the user to try systems out without imposing structure on what they should do, or how they should do it. Whilst there may be context sensitive help or general guidance on training objectives, the user is left to their own devices to explore the system and make their own discoveries. In these ‘unguided’ simulations, as we aren’t focusing on workflow or operational tasks. We simply want the user to gain confidence in, and awareness of, the system and how to navigate within it.
