Markup vs. Mockup

Mike Atherton
Jun 29, 2012 · 4 min read

Yesterday on Twitter I became briefly embroiled in what I’m calling the ‘markup vs mockup’ debate, sparked by this article. In case you’ve been in UX Siberia (not a conference, though it should be) the dogma du jour is that ‘designers’ (by which we mean visual and interaction designers) should be able to ‘code’ (by which we mean implement — nay, initiate — their designs using HTML, CSS and perhaps a dash of jQuery).

There’s a bunch of reasons why, all discussed better elsewhere. But briefly:

  • It’s more efficient than making disposable interim wireframes and comps that ultimately get translated into markup anyway. Lean, if you must.
  • It gives you a high-fidelity interactive prototype sooner in the process, thus better to test the efficacy of your design before it hits an expensive development stage.
  • You’re working with the native materials of the medium (linked web pages and interaction affordances), rather than an abstraction of them.

This last point is the thrust of the article above, and it’s why I look to hire designers who are markup-friendly. Web design isn’t print design. It shares some superficial similarities, such as a need for clear information hierarchy and the cadences of typography, colour and rhythm. Unlike print, web layout is inherently variable, unpredictable even. And this is to say nothing of the complex, animated, state-changing interaction patterns that advance modern web applications. You’re not just designing lipsum-filled chrome here; web design is the harmonising of content, context, affordance and flow into a pleasurable, meaningful and motivating experience.

It has a grammar all its own, and can you really grasp the grammar without first learning the language? In today’s richly-interactive, responsive, cross-platform, transmedia web of data, how much of a given interface can you really communicate via bitmap mockup or wireframe? How painful is it to keep these updated as the design iterates? At what point does it become easier to ‘just do it’ natively in markup rather than document every state and exception?

These aren’t rhetorical questions. You should use whatever method plays best to your skills and company culture. User Experience takes a lot of crafting and ideation and getting busy with the Sharpies, Post-Its and Mental Notes can be a way of life in itself. Perhaps your working day entirely operates at this more conceptual level and so you’re happy to leave the specifics of cross-browser implementation to the other designers (aka ‘front-end developers’). That’s fine and dandy. I’m not going to say “You’re not a UX Designer if…”. That would be naive and idiotic.

Only…well, I wouldn’t hire you. The company I work for is stacked with engineers working Agile to deliver rich web and mobile applications. We’re on a mission to improve our user experience, and the centerpiece of this is a beautiful interface. We’ll standardise where we can; adopting well-crafted, reusable templates and patterns. But still, to hand a developer a sketch or annotated wireframe for each user story is to leave too much to chance. How do I know how many milliseconds my hover state should animate over without trying it first? How can I ensure my webfonts feel right and render nicely across browsers if I’m mocking up in Photoshop? In Agile development, user stories get split across both iterations and teams. Visual consistency is a challenge when you’re asking a developer to take your mockup and turn it into the real thing. And should you find you’ve overlooked or miscalculated detail in those mockups, good luck trying to disrupt the iteration to get your changes incorporated.

Better then to define as much of the interface aesthetic as we can before development begins. And better for happy cross-functional teams when working from a position of deeper empathy. Collaboration, not coexistence. The days of Morlocks and Eloi are thankfully over.

While I respect everyone’s freedom of religion, devoutly I adore the code-conversant UI designer. Markup is just the beginning. HTML document design, metadata structures, server caching, URI design — all of these things and more profoundly affect a user’s experience so to ignore them or dismiss them as technical implementation is negligent. Sure, you can keep it high-level and outsource detail. Or you can get your hands dirty, as the print designer does with ink and substrate, or as the author moves from plotting and characterisation to sentence-construction and actual spelling. I for one prefer the novels of Tom Clancy to those by TOM CLANCY (with shhh the bloke who actually wrote it).

In closing, I’m given to wonder: is the group who advocate mockup over markup limited to those who can’t code? Are they simply Canuting to avoid professional redundancy? Or a slightly different question: Would any skilled markup web designers choose to go back to being mockup designers?

Originally published on reduxd.com June 29, 2012

Mike Atherton

Written by

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade