Wireframes are dead, long live rapid prototyping


Wireframes, your time is up. You’ve served your purpose. You’ve brought order where there was once chaos and provided gainful employment for thousands of UX designers, but I’m afraid now it’s time for you to go to the big recycling bin in the sky. You’re just no longer cut out for the cut and thrust of UX design and have been replaced by that young upstart called rapid prototyping. In this article I argue why you too should ditch wireframes and embrace rapid prototyping.

What are wireframes?

In the same way that architectural drawings might outline what goes where for buildings, wireframes outline what goes where for a set of UI screens. Wireframes typically outline the components for a screen, together with any associated behaviours, such as what happens when a button is click and where a hyperlink should go. They don’t show exactly how a screen will appear, only how it will be composed and how it will behave. For example:

An example wireframe with footnotes

Wireframes are usually put together by a UX designer (or designers) prior to any visual design work and are typically constructed using diagramming tools such as Visio and Omnigraffle, or design and drawing tools such as InDesign and Fireworks. They typically form part of the functional specification for a system, outlining all the requirements for each screen, and as such are usually annotated (as is the case with the example above), often in excruciating detail.

Why ditch wireframes?

So what’s so wrong with wireframes? Well wireframes themselves are not necessarily bad; it’s more the sort of design behaviour they encourage and the way they are often used (and abused) in projects. Here are some reasons why for the vast majority of projects wireframes should be consigned to the rubbish bin.

  • Wireframes (which are static by nature) are not well suited to defining dynamic on-page interactions, such as expanding content, AJAX style reveals and animations. As the boundaries between web and desktop applications become increasingly blurred and on-page interactions become more common place wireframes simply no longer cut the mustard.
  • Wireframes are not very user friendly (which is kind of ironic for a UX design tool). Project stakeholders are often intimidated by what they perceive to be very technical documentation and find it difficult to understand exactly what wireframes are, and what they show.
  • Wireframes are typically very open to interpretation. Wireframes look like they’re very exacting and specific but because behaviours and interactions have to be described they are by nature very open to interpretation. One project stakeholder can read a wireframe very differently from another which can lead to confusion and misinterpretation.
  • Wireframes can encourage the ‘lob it over the fence’ approach to design. Designers can spend ages meticulously creating, annotating and updating wireframes and then lob them over the fence for the development team to build; safe in the knowledge that everything is documented, so any dialogue can be avoided.
  • Wireframes can be too prescriptive. Many visual designers can feel that wireframes reduce their role to little more than a colouring in exercise; one of applying the necessary branding and look and feel for each screen rather than carrying out proper design work.
  • Wireframes often add unnecessary drag to the design process and can encourage death by documentation (a particularly nasty way to go). Creating and annotating detailed wireframes takes considerable time and effort; time and effort that is usually better spent iterating and improving designs, rather than specifying them.

Bypassing wireframes with rapid prototyping

If wireframes are so flawed what’s the alternative? Simple, the alternative is to bypass wireframes altogether and either go straight from sketch / outline designs to developing working code (in an Agile fashion), or as is more use common use a rapid prototyping tool to create a prototype. There are now loads of great rapid prototyping tools out there such as Axure (my own favourite), Balsamiq, EasyPrototype and iPoltz. If you’ve got mad web design skills you can also always create a prototype directly in HTML and CSS.

There are a number of advantages of rapid prototyping over wireframes including:

  • Prototypes are a much better at communicating a design. It’s much easier to sit down with designers, developers, product owners and of course users to get feedback and to run through design ideas if everyone can see how things might work with their own eyes.
  • Prototypes are more user friendly. Where as people are often scared off by wireframes everyone understands what a prototype is (just make it clear that prototypes are very different from the finished article).
  • Prototypes require less documentation as they are less open to interpretation and on-page interactions can be mocked up. If you do need to document your prototypes (hopefully with an emphasis on ‘just enough’ documentation) then you’ll find yourself having to write many fewer comments for a prototype than a set of wireframes.
  • Prototypes better support user-centred design. It’s much easier to carry out usability testing with a prototype than a set of wireframes and to get lots of juicy feedback from users in general.
  • Prototypes require less work. If you are careful to prototype ‘just enough’ to get the feedback that you need then prototypes typically require less work than wireframes because you’ll need to write (and maintain) less documentation.

Of course like wireframes, prototypes can also be misused. A classic mistake is to mock-up a design to the nth degree and then chuck this over the fence for the development team to build. Prototypes can also be even more prescriptive than wireframes, so it’s just as easy for visual designers to get upset because they feel left out of the loop. This is why it’s so important to always prototype ‘just enough’ to get the feedback you need and to approach prototyping as a collaborative exercise. Designers, developers, product owners and of course users should all be involved in creating, critiquing and evaluating prototypes. This is why I’ve found it best to sketch designs before you even think about touching any prototyping tools.

That’s great, but I still need a paper trail…

If you work in the sort of place where documentation still reigns supreme and the project manager will look at you like a crazy person if you tell him that a prototype with some comments is all the specification required, then fear not. If you absolutely must have wireframe like documentation you can still get by without wireframes because some rapid prototyping tools such as Axure will automatically spit out specification documentation for you. Granted what it spits out isn’t fantastic but it’s much easier than having to maintain a prototype and a separate set of wireframes. As a last resort you can also always screen grab pages using the excellent Screengrab! Firefox plugin and create your own specification document. On screen annotation tools such Protonotes and WebNotes allow you to easily add comments to your prototype so there isn’t even a need to add footnotes to your screen grabs. You can simply grab the pages with the comments shown, so you see, there really aren’t any excuses for not ditching those wireframes!

More about rapid prototyping