Wireframe or Interactive Prototype?

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.

Wireframe teddy bear

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:

  1. Deciding on what things should be included in a page;
  2. Investigating where things should be placed on a page;
  3. Creating low-fidelity mock-ups to help build the ‘skeleton’ of an application without investing too much time;
  4. 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.

Prototype car of the future

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.

Crazy prototype gadget

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!

About John Clark

My name is John Clark and I previously ran a software house called Reynard Thomson, from which this blog originally grew. In the meantime, we launched a video-based user testing service (Kupima) which didn't really take off, and I have since moved into a new field specialising on software-based research & development consultancy. I'm active on LinkedIn, and would love to connect to anyone who has an interest in software prototyping or R&D: http://uk.linkedin.com/in/jtclarkuk/
This entry was posted in Good Design, Prototyping and tagged , , , , , , , . Bookmark the permalink.

4 Responses to Wireframe or Interactive Prototype?

  1. Hi there,

    How come I haven’t found your blog until now? I mean you do a really good job in explaining the process of wireframing/prototyping and creation of good software. Excellent! :-)

    I personally believe that a combined approach is a good way to go. I’m not sure but I feel like right now there’s a limitation given by the tools we have. We limit ourself to artifacts that don’t fully communicate the concepts and the future product design.

    Cheers,

    Cristian

  2. Pingback: 6 steps where you should user test | The Kupima Blog

  3. Thanks , I have just been looking for information approximately this topic for
    ages and yours is the best I’ve discovered till now. But, what about the conclusion? Are you sure concerning the source?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>