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?
It's not the despair. It's the hope. 
Probably heading off topic but the mention of print designers brought back a memory that probably shows my age…I used to work with print designers who predated all the photoshop nonsense. Two things were sent off to the people who actually did the printing: the document and the print spec. The document was the content marked up to indicate headings and paragraphs and lists and footnotes; the print spec said how those elements should appear: indents, leading, font faces, font styles etc.So just like the html / css split with less of the complexity of how things render in various agents on various devices. But still splitting out the document and document design from the appearance.All that disappeared with apple macs and photoshop and illustrator and WYSIWYG interfaces. Which, in my ever so humble opinion, just made designers lazy and completely unable to recognise the separation of concerns that’s important to the web (and to print and to any kind of design really). Mockup tools just play to that laziness. And desire for *control*Over the years I’ve met a fair number of designers who did graphic design at art college and they were all without exception useless because all they seem to have been trained to do was lay out other peoples artwork in photoshop. The best "new media" designers I’ve worked with were a jewelry designer, a claymation animator and a fine artist. But for the love of god never employ a "graphic designer". The old man in me just thinks art education went badly wrong in the 1980s when every art college got macs and every student spent 3 years trying to work themBack on point: photoshop was never even a decent tool for doing print design. It was probably fine if you needed to do some "desktop publishing" of some leaflets for your local hairdresser. It’s certainly not a decent tool for web design.
All I really want is a ZX81 for to play the mazogs game ram. Happy to swap a copy of acrojet CBM 64 or possibly a double cassette version of Last Ninja. Hope you are well, mate. Spinglebong.
I advocate UX designers who can design and can code but who don’t specialise in it.
ie a team of T-Shaped specialists who work well together will produce better work faster than a team of all-rounders.
When I’m designing interactions I know I will be coding, I’ve always got how easy this will be to code in the back of my mind. I know it shouldn’t but knowing I’ll be coding it usually limits my creativity because there are deadlines and budgets to keep to.
However, Knowing what’s possible with code and its constraints allows me to design great interactions but being able to communicate them to a specialist front-end dev allows them to get built better and faster.
There’s certainly room for both types of person it just depends on the company. If you don’t have the budget to pay a couple of specialists and you have the time to wait for a talented generalist to come along then that’s the best way to go. For agencies though, who have bigger budgets and less time to look then specialists may suit.