Prototyping towards a better user experience

Designing websites has traditionally been an expensive and laboured experience. Many hours have been spent pouring over information architecture, deliberating interactions, elaborating upon wireframes and creating pixel-perfect Photoshop and Illustrator compositions, only for those design artefacts to be archived neatly away, on a server, never to be seen again.

What if there was a better way to use our time, energy and resources? How much better would our final products be if we spent what valuable time we had on real design thinking and execution? We can give our clients much greater value for money with only a small change in our perspective and a big change in our process.

In essence, I’m talking about designing, or as Dan Mall suggests, deciding in the browser. Instead of creating a series of disposable deliverables, such as Axure prototypes and OmniGraffle wireframes, we should consider an evolutionary process, from sketches to the final website. Everything we make or do should move us towards creating a final product with as little waste as possible.

Enter prototyping in code, using the faithful web browser.

Prototyping in code, in the browser, is scary stuff to many designers. It’s something developers do, not designers, which is somewhat at odds with where the Web is today. With the proliferation of mobile devices and responsive design gaining significant traction, along with the increasing maturity of web typography, designing in the browser instead of on static comps is becoming a matter of necessity. As Cennydd Bowles puts it, “designers should be able to code to the level they require to produce excellent work. Usually that’s ‘some’, but not ‘lots’.”

Jared Spool, another proponent of designers knowing how to code suggests “you’ll better understand the medium you’re working in…If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster. Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.”

“Whilst it’s good to know that HTML describes the structure of a page, CSS handles the layout and decoration, and JavaScript can be employed to add behaviours, there’s no voodoo involved,” says Alex Morris. “There are no hidden traps or anything that can go mysteriously wrong, what you write is what you get.”

Designing in the browser, with HTML and CSS, can produce prototypes that communicate the intent of a design more clearly and effectively than any wireframing tool ever can. Indeed, if we are to think about Responsive Web Design, traditional prototyping tools simply do not support this paradigm, pushing us towards designing in the browser, using browser-based technologies.

While I’m a proponent of writing your own code, with the proliferation of frameworks such as Foundation, Bootstrap and Ratchet, and tools like Gridset, Mixture.io, Divshot and Jetstrap, prototyping in HTML, and across different devices, has become remarkably simple and accessible to a broad audience.

Through designing in code and in the browser, the users you’re testing the product experience on, or the client you’re presenting the product to, get to see and engage with it in it’s natural environment. Interactions, behaviours, typography, content and forms are all represented as they would be in the end product. By building prototypes in this way, closer to the product’s intended experience, the feedback you receive from users and clients will more accurately reflect that of the final product; no leap of the imagination is required.