Wireframing is out, prototyping is in: here’s why

OK, so it is a bit of an inflammatory title for an article, but I think for a lot of web development projects, it is now true. A few years ago, the standard process for building a decently complex website involved an initial stage of producing wireframes. These were generally static, greyscale ‘blueprints’ for the layout of the website, illustrating where content would be positioned, what kind of UI (User Interface) elements are to be used, and how data will be input by users, and displayed when output.

It’s conceptually an essential part of a successful website development project, because it allows the development team and any stakeholders to fully understand how a site or app will function from a user’s perspective, as well as interrogate how the site will be built (technically), all without wasting time and money by jumping straight into design and coding.

Fast forward a couple of years to the present day and there are a few reasons why I don’t think this process cuts it anymore, and why I think that first sketching with a paper and pen, and then building proper HTML prototypes is by far the best option.

Responsive design

As everyone now knows, responsive design is a superb solution for building websites that will display their content and interfaces well across a range of devices with different sized screens. The way a responsive website is developed means that its layout adapts depending on the size of the screen of the device it is being viewed on. To product static wireframes for a responsive website means producing ideally at least three wireframes for each page — one for desktop width, one for tablet and one for mobile.

Not only does this start to become impractical because the sheer number and therefore flexibility of the wireframes becomes unwieldy, but static wireframes also fail to demonstrate how a layout will change if a user flips their phone or tablet from landscape to portrait — a realistic use case scenario. Wireframes are beneficial in part because they are quick and easy to change, based on interrogation, testing and feedback. Replicating changes across three wireframes for each page starts to impinge upon this benefit. Responsive design has arguably swung the responsibility for effective design more towards developers, and away from photoshop designers. HTML prototypes allow us to investigate usable ‘real world’ solutions (for example to a navigation menu) in a way that static wireframes just can’t. Which brings me to…

Interaction design

Interaction design is the design of the more animated, dynamic, ‘live’ aspects of web interfaces. Bits that slide open when you click on them, drag and drop interfaces, shopping carts that glow softly when you add a product to them, sliders that allow you to specify the amount and duration of a loan you are applying for, and so on. While I don’t think that all of these should be played around with at a prototyping stage, if something is a fundamental part of a website’s interface, and strongly influences how someone will either access content, or input data into a website or app, then it’s pretty important. Once again, producing HTML prototypes allow us truly to test and experience the more interactive areas of a website, and gauge their effectiveness before getting stuck into web development properly.

Interaction design is more important than ever before, and more ‘alive’ and reactive interfaces are commonplace. This is partly due to the prevalence of mobile apps, where simple apps with beautiful and whimsical interactions are hugely popular. Just think of all the wonderful ways different iPhone apps style the interaction when you drag down on an interface to refresh a feed – my personal favourite is the Google+ app, where a handful of coloured bands feel like they will almost snap as they get thinner and thinner the more you drag downwards, only to bounce back delightfully as the feed refreshes.

This is an example of an interaction you don’t need to worry about at the prototyping stage, but sliders that determine the duration and amount of a loan you are applying for? They are such a fundamental part of that particular experience that in an equivalent development project it would be mad not to prototype that, as opposed to having a static picture of it to try and evaluate.

User flows

As important to the layout of individual pages in a website or app is the way a user flows through those different pages, and navigates to find bits of content and functionality. Of course there have been ‘clickable’ wireframes for a while now, which allow you to click from one static image to another, but it’s just not the same as a truly navigable prototype that you can view in a browser.

Websites are only going to get more and more transactional — meaning that they will involve more heavy interaction from users — the inputting of information to enable some kind of functionality, or as part of a business process. So many websites are now in the very least lead generation tools of some kind, and the barriers to entry for ecommerce are becoming so low as to make it almost ubiquitous. A lot of businesses understand that they can offer some kind of social, commercial or content based experience on their website that they can make more relevant and valuable by tailoring it to each person.

Consider almost any travel or airline website, where we generally filter huge amounts of content by inputting a lot of information about our travel and cost preferences. All of these online processes require us to work through multiple steps. To ensure that these complex experiences are intuitive and simple on the surface requires more than just static wireframes and a dash of imagination — prototypes let developers, marketing types, usability experts and business owners/managers get a strong idea of how an online experience will be, and in the process improve it more effectively.

Available frameworks

So even if you agree with the fact that HTML prototypes are far more valuable and effective, there is still the issue of the time they take to produce. Well, with the advent of beautiful and usability focused front end frameworks like Twitter Bootstrap and Zurb Foundation, this doesn’t need to be an issue any more.

Established interface patterns, and bits of interactivity are included ‘out of the box’, as is responsiveness. Once you are familiar with a framework like Twitter Bootstrap, creating even complex interfaces that can be played around with on a desktop computer, and on a mobile phone, that very accurately represent a final product is relatively easy. Of course not all user experience folks are familiar with HTML, CSS and Javascript — they come from a range of different backgrounds, and formal UX and usability training doesn’t usually include any coding. The web development industry has always been marvellous for its ‘teach yourself’ ethic though, so, UX people — learn to code!

Designers of physical products learned a long time ago that there is no replacement for a prototype. It doesn’t matter what you have sketched down on paper, you can only really find out of something is going to work — is going to be effective for the purpose for which it was designed — when you have it in your hands. And so it is with websites and apps too. If you want to build something intuitive, simple, addictive, and powerful… prototype it first.

I think the point is not that a sketch could be described as a wireframe – yes of course – but that in a typical development project wireframes represent key milestones and artefact sign-off points. It’s a development methodology point – eg replacing wireframe sign-off with prototype sign-off.

Hi Guest, I’m not quite sure what your question actually is. The focus of this article was to explain the benefit of the prototyping side of preliminary UX work, so I didn’t go into the sketching/low-fidelity side of things. Whether doing static (medium to high fidelity) wireframes, or creating an HTML prototype, I think you should start by sketching with a paper and pen. Sketches are not enough to gain the full benefit of either wireframing or prototyping, so they are not a substitute for either.

I’d be interested to hear if you have had different experiences of going straight from sketches to development on decently complex websites in your own projects?

So the short answer to your question is that I can’t answer it, since I have never not believed what I have written.

michael

I have been pounding on this idea for quite a while now – unfortunately steerage has always come from UX designers without any coding experience. There are however a few wrinkles to the article in my opinion, the main one being the time it takes to get a semi functional HTML prototype together and which will adapt speedily along with the UX research – and from that perspective the wire frame will still win from a resource perspective. Personally, I use flash as a prototyping tool to emulate HTML mobile tools which allows me to very simply adjust the visual building blocks and flows as I like at about 1/20th of the development time, but this skill set is also quite rare.

Ruan

The example mentioned of the steps involved in an airline or travel website – to recreate these in a prototype vs. just a click through wireframe would require almost building a completely functional site pulling the required values from a database. Click through wireframes done in software like Invision would make sense in the earlier stages of a project.

Anne Burnett

I have been doing IxD (Web/UI/UX design, etc.) for over 17 years and I have always believed that html/css prototypes are far superior to wireframes. Even without the advent of responsive design and font icons, click-through prototypes force me to think through significant details I wouldn’t otherwise, saving time and grief during implementation. I can also do richer experimentation with a click-through prototype than with wireframes because I can convey a more emotionally compelling UX. I do hand-code html/css and for me it’s a very fast way to prototype, faster than wireframing in many cases. I do find wireframes useful for documenting flows and other spec-like details, or processes I can’t code. I now find the prototype/wireframe combination perfect for me. So, with a solid knowledge of html/css, even doing low-fi or wireframe-like designs in html/css is faster and more comprehensive than traditional wireframes. But I haven’t met other UX professionals that hand-code, so that seems like a fairly common limitation in the job market.