Prior to beginning our responsive design project for the departments of the University of Michigan Medical School late last year, the design team here at Palantir came to an important realization — it’s extremely ineffective to design static snapshots to describe a responsive layout. Not only does it generate a lot of redundant design work, but there’s just no way to convey all the greatness of a responsive layout to a client in a compelling way.

As a solution to these shortcomings, we proposed creating HTML + CSS prototypes of the wireframes and designs.

Outlined below are just some of the benefits we experienced while adding these ideas to our existing process.

Transparency

A prototype explains exactly how a responsive layout works by being a real functioning thing as opposed to just a static picture of the proposed thing “to be built at a later date.” The “real-ness” of a prototype can also ease a lot of client concerns that may exist in the early stages of a project. Seeing is believing, as they say, and a prototype in-hand will go a long way towards generating excitement for the project if the client can actually manipulate the browser themselves and see their future site magically adapt.

Accuracy

A prototype allows the designer to create a more accurate end product. It gives him/her the ability to exert complete control over critical design details such as type styles, margins, and padding, etcetera. When values are specified in CSS it greatly reduces the chance for human error and it gets applied exactly — without fault — to render a fully accurate page. But that’s not all, a prototype actually gets rendered by the browser as well, and you can’t get more accurate than that! Again, we’re seeing the same idea here: the difference between making a picture of a thing versus actually making it.

Precision

Designing in the browser is a very precise process. It communicates important design details to the developers in a way where nothing gets lost in translation. A designer’s intent normally needs to be interpreted by a developer, which can lead to a lot of inefficient and unnecessary back-and-forth. A prototype’s hard values in code can’t be misinterpreted the way a manual measurement of a photoshop file can. This gives the designer the confidence to indulge in all those wonderful details with the knowledge that they will make it through to the finished product.

Agility

We learned that this process can be far more liberating than at first thought. Altering a single CSS class will populate the change throughout the entire prototype at once, reducing the amount of busywork — making changes towards the end of the project more quick and efficient. This, ultimately, made our team seem more nimble and “responsive” as whole when it came to addressing client feedback. What at first seemed like a ton of up-front effort on our part was actually a fairly smooth transition that paid huge dividends throughout the course of the project. You can see some of the results at at uofmhealth.org.

So the next time you find yourself facing the prospect of grinding though 6–10 separate files just to describe a single page in a responsive layout, consider this handy list of benefits and recommend prototyping and designing in the browser to your team. If your experience is anything like ours, you’ll never want to go back.