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.
No ad to show here.
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.
