The only way to truly experience and evaluate a website design is in a web browser. That sounds obvious but it bears repeating. While this fact can’t be denied it is often conceptual design mock-ups that take responsibility for critique and direction. The assumption being that as a more efficient intermediate they’re good enough.

High-fidelity design mock-ups have established themselves as a waypoint within the process of website making. Somewhere between the initial briefing and final deployment lies the well honed Don Draper reveal followed by — and who are we kidding? — client sign-off.

Designing with Code

Some responsive design aficionados are keen to scoff at this practice. If you’re not “designing in the browser” it’s time to get with the program. Their manifesto being that design mock-ups in [software of choice] cannot possibly be appropriate any longer.

Has responsive website design really changed the game that much?

Not in the slightest. First and foremost there exists a logically naive assumption that working directly with the medium is a shortcut to success. Or indeed the easiest way to find a solution. Secondly, I’m raising a bit of a straw man here, I hope. I don’t for one second believe anyone actually feels liberated designing in code alone without any in-between conceptualisation. It’s hard to know for sure with all the conference soundbites so often repeated.

Web design, of course, is more than just applying visual style. It requires aspects of user research, information architecture, content hierarchy, state and interaction design. The explosion in web-accessible devices has only highlighted flaws in what was deemed a suitable result.

The browser gives us direct feedback on what’s becoming an ever more difficult and scrutinised task. With that said, I’m hard pressed to think of anything more stifling than to use HTML & CSS to achieve the waypoints that lead to a final design. It’s a horribly tedious and distracting way to express creativity. This idea shuns high-fidelity design mock-ups for another equally inadequate extreme. The browser is a terrible tool for design. Sure, both methods can deliver a website, but are these polar opposites our only option?

A Matter of Process

Rather than dropping everything we know — which seems to be the sentiment behind the “RWD has killed Photoshop” notion — we need to adjust our process so that we can develop alongside design. Agile, not waterfall.

Getting this right allows us to see the actual in-browser experience while design can happen outside of the browser. Where it can flourish. Where common sense tells us text rendering will vary. Where imagination allows us to mentally visualise fluid components as we sketch them. Iterate and adapt quickly. Experiment with many mediums.

That doesn’t mean it’s ever wrong to make design decisions by editing code now and then — I do it often — but there’s no reason to impose this limitation. Intermediates exist.