Designing with Code

To code or not to code? For designers, that’s a very contentious question. Clients like designers who code because (among other reasons) that’s one less body on payroll. Design advocates, on the other hand, often see code as a technical limitation that stifles creativity. To make matters worse, the information ecologies we all work in refuse to stand still. By looking carefully at some of our favorite arguments, however – and by taking them within the context of our ever-evolving digital landscape – we can begin to make a case for when working in code makes sense.

Several years ago, Andrew Maier penned an article on the use of prototypes in website design and development. In light of my own recent work in prototyping, one of the comments to that article stood out:

Any kind of prototype that involves programming or markup sounds scary to me –that’s the fastest route to a “developer-y” looking site rather than a truly designed –graphically as well as functionally designed –site.

This comment caught my eye because it is the same concern I often hear today, a full three years later. And here’s why this is a big deal: given the content and information architecture challenges that the responsive, multi-context web presents there are now better reasons than ever before to integrate coded prototypes into the design process. By paying close attention early on to the integrity of the narratives we create at the most basic level of communication, we can build the foundation necessary to effectively articulate those narratives far and wide.

Why we’re afraid to commit

If pressed to describe their relationship with code, many designers would hunt around for the “it’s complicated” checkbox. We may have already been sold on prototyping (see Todd Zaki Warfel, Jeff Gothelf, and Stephen Hay if you’re not yet convinced), but we’re still afraid of our beautiful UX getting all bent out of shape and smudged up by an engineering toolset (and mindset).

The source of this dread is no mystery. In his seminal 2004 book on design in technology, The Inmates Are Running the Asylum, Alan Cooper writes that “when engineers invent, they arrive at their solution through a succession of practical, possible steps. Because of this, their solution will always be a derivative of the old, beginning solution, which is often not good enough.” Cooper goes on to argue that interaction designers are in a unique position to break this cycle of derivative solutions by “keep[ing] a healthy suspicion of all assumptions about what cannot be done.”

Whether they’ve read Cooper’s book or not, many designers have implicitly heeded this advice and translated it into an “I design it, you build it” workflow. In many cases, this delivers the results Cooper promises: designers and developers frequently challenge one another to synthesize new ideas and novel solutions – ideas and solutions neither of them would have been able to come up with on their own.

What’s different now

With the growing need of responsive web solutions and adaptive, flexible content, there are new reasons for designers to roll up their sleeves and get into “code.” Since HTML is, at its core, a layer of description wrapped around content, working at this level helps designers think more critically about their content and about the architectural implications of that content. While considering markup won’t replace our content audit, user research, or taxonomy work any time soon, it can increasingly function as an important part of the design process.

HTML prototyping helps us discover and vet the IA step Information Architect Dan Klyn refers to as “choreography,” or the “appropriate unfolding” of content: the link between taxonomy and the interaction-level design typically represented in prototypes. When we address the architectural underpinnings of our content’s choreography early on, we ensure that we haven’t driven off course, and left our intent on the side of the road. What’s more, the benefits of HTML prototyping present themselves when we apply even the most basic of HTML’s elements. Creating a linear, semantic document calling out our navigation, header, teaser, aside, and paragraph elements forces us to think critically about how these elements relate to each other in context.

Now look at that same document on a tablet, or on a phone. Does it tell the same story? Does (should) it follow the same choreography? We might find that our content needs to break into summaries or teasers at different places in different contexts. We might also find that the navigation patterns that work on a phone are overly simplistic with regards to the desktop experience. Each of these insights forces us to think about how our content models need to adapt to accommodate new contexts. (For an in depth and practical look at creating content models, see Sara Wachter-Boettcher’s Content Everywhere.)

Why it matters

In her brilliant book Content Strategy for Mobile, Karen McGrane encourages us to stop thinking about content in terms of “pages” and to start thinking about it in terms of “packages.” A content package might contain things like long and short headlines, teasers, summaries, body copy, and pull quotes. Early HTML prototyping helps us decide which of these elements we need –and helps us think of them as pieces that combine across contexts to create a cohesive experience.

Whereas many of the excellent, commercially available prototyping tools are centered around interaction and design, early HTML prototyping is a way for us to begin to prototype our information architecture –and to test the architectural hypotheses we’ve laid out in our conceptual and taxonomy work. It also puts us in the right frame of mind to break out of the page metaphor.

In her keynote at DrupalCon in May, Karen McGrane traces the history of the page metaphor. This ubiquitous concept comes to us –surprise –from Xerox, maker of printers. Of course they would think about content in the digital age as coming together on pages: pages have been the cornerstone of their business for over a century! When we move to thinking of content as a resource that can be pulled into view when and how it is needed, we’ve already taken a huge step toward creating the responsive and adaptive information environments we need to meet the demands of the mobile ecosphere.

How to get started

So how can you get started designing with code? Both Jeff Gothelf and Stephen Hay stress the importance of sketching. I’ll reiterate that here: although our goal is to eventually end up in code, sketching out your rough ideas before diving into markup will keep you from committing to mediocre ideas you’re reluctant to change because they’re already saved to disk.

Use pen and paper or a whiteboard to work out a hypothesis and then write your markup to match. Does it work with your content? Check it out on mobile, on a tablet. Revise and refine. Consider how your content needs to adapt to convey the same concepts in different contexts.

There’s no way around the fact that you will need to understand the basic elements of HTML and CSS. Fortunately, these are not overly complicated and online resources abound. HTML alone allows you to author structured content in a semantically correct way. CSS (with help from media queries) allows you to shape the visual hierarchy of content and adjust it to different contexts.

If you’re new to HTML and CSS, learn a little bit at a time – and fake what you can’t build. You don’t need to have a fully functional AJAX calls or form validation in order to gain insight. Stephen Hay suggests capturing and printing screenshots to show to stakeholders early in the prototyping process. This way you can show exactly the ideas you want to convey without risking stakeholders getting caught up in the fact that a button doesn’t work, or links aren’t yet connected to their destinations.

Finally, allow your process to grow and develop over time. It will. We may never strive – or want – to be standards-compliant, cross-browser, front-end rockstars, but with a little bit of knowledge, practice, and experience, HTML prototyping can become a valuable addition to our content strategy and information architecture toolkit.

About the Author

Andy Fitzgerald

Andy Fitzgerald is a Senior User Experience Architect at Deloitte Digital in Seattle. Andy's recent work focuses primarily on mobile, but he has spent the better part of a decade massaging truculent bits of information into difficult digital spaces. Andy blogs at andyfitzgerald.org. Find him on Twitter at @andybywire.

Write for UX Booth

Contribute to UX Booth
Contribute

Contribute a guest post to UX Booth and let the community know what's important to you!



Comments

  1. One of the challenges I find with being able to do both is that it becomes an expectation (once you have designed a product) to then go on and fully implement it. This then diverges you from the creative side and you tend to have to fight your way back into design.

    Initially I believed that understanding the technology would make you a better designer but it turns out even companies are reluctant to hire you as purely a designer due to the fact you think too much like an engineer.

    I believe, however the two aren’t necessarily mutually exclusive and a bit of overlap is a good thing. :)

    • Good point — and one, I suspect, that crops up a lot when hiring managers have some distance from the “trenches.” Working with some talented front end devs has taught me a lot about the difference between making a design work in Chrome on a Mac (as a proof of concept), and implementing that same design in a clean, cross-browser compliant, and efficient codebase. For me this is the big gap between the kind of modeling I discuss here and the real work that dedicated front end developers accomplish. One possible remedy of the situation you describe may be to work on educating such folks about the actual work that goes into design and development respectively.

  2. I have a hard time seeing how a designer in this day and age could not know any code at all. That seems like willful ignorance, like a structural engineer that doesn’t know anything about metallurgy, or like a graphic designer that doesn’t use a computer at all, only Letraset.

  3. Sarah R August 13, 2013

    ‘interaction designers are in a unique position to break this cycle of derivative solutions by “keep[ing] a healthy suspicion of all assumptions about what cannot be done.’

    This is the very reason why I DO code — so my developers are not able to tell me my designs can’t be done. Hard to use that excuse if I’ve already proven it to be possible.

    • I agree with you Sarah.

      Coding is just another tool in the toolbox. Having the ability to code allows you to guide the final design that you came to after all of the activities you went through to get there. I find that in addition to proving things to developers who are lazy, at a large company you also have the ability to influence any brand changes since designers are closer to brand development. Just yesterday I had a development team request that I provide HTML prototypes for the 2nd phase of the project since the PDF design doc for the first didn’t meet their needs and left them with more questions than answers.

    • I’ve had the privilege of working with incredible coders (after being a decent coder myself for many years and then moving to UX/IA). I can tell you that both the Creative sides and Development sides appreciate having a mediator like an Interaction Designer or a UX Architect… though it does seem to take some time to get people to understand the value. Once they do, they don’t know how they worked without it.

      But knowing and keeping current in code does enable you to speak the developer’s language, and also call them out when you can tell them that something they said can’t be done truly can be done… “AND HERE’S HOW I WOULD DO IT”… :)

  4. Andy, thanks for the good article about design with code.

    IMO, the current responsive design trend has brought some limitations to designers creativity on web design.

  5. With the popularity of CMS on the rise, it’s easy to see why designers don’t always know how to code. In WordPress for example, there are thousands of plugins to extend functionality and replace what was once a coders side of the job.

    • Emu Hex August 21, 2013

      @ Opace Design
      I extremely agree with you. The importance of a coder is redused by CMSs, But the coder is still most essential part of any web thing. The CMSs are only for website or blogs and the codes are the major parts of any type of web app and etc. You can see how much coders are earns from http://themes-mart.com/page/submission to sell their works.

  6. Great article for web designers. Prototyping is just as important, if not more so, for designers working on native/installed mobile apps.

    It may be beyond some designers capacities (or bandwidth) to learn Objective C or Java, but just taking a project all the way through the production design cycle and working closely with the dev team is a huge eye opener (how many form factors, how many densities, what’s a 9 grid, etc…).

    • Thanks for the comment, Theresa — I totally agree. I have the privilege of working with both HTML devs and native devs (on both iOS and Android) and I’ve learned a ton from both camps. (Which isn’t to say I’ve learned any Objective C or Java — I wouldn’t even recognize their syntaxes).
      Even in the case of native development, I can see instances where HTML prototyping of the sort I describe here is useful. If the goal is to work out and vet IA and CS decisions, whether the text on-screen is being generated via markup or native code is largely moot.
      For navigation and IxD, there are Javascript solutions (many built on jQuery) that mimic just about all of the standard native interactions (more or less well, granted, but still). I think simple HTML prototyping makes even more sense for Android development, where native apps need to be essentially responsively designed anyway because of the incredibly wide variety of Android form factors.
      In both of these cases, prototyping isn’t about “crossing over” and doing rudimentary dev work, but is rather about taking a view of content, architecture and design that is informed by the context in which it will be consumed.

  7. You say “There’s no way around the fact that you will need to understand the basic elements of HTML and CSS.”

    But what if I have spent the last two weeks, for example, almost entirely designing for Android and iOS native apps? Do I need to know those also? Sure, but do I need to be able to write code in now four or five languages? That’s crazy. Find me a full on professional developer who is good at even two wildly different languages. There aren’t many.

    Femma’s comment is spot on. Knowledge and prototyping, in these articles and too many organizations, turns straight into “designers should build their products in code.”

    • Thanks for the comment, Steven. Yes, I did say “There’s no way around the fact that you will need to understand the basic elements of HTML and CSS.” To be clear, however, that sentence was under the section “How to get started” and in an article about HTML prototyping. So yeah, I stand by that statement: in order to do HTML prototyping the way I describe it here, yes, there is no way around that fact that you will need to know some CSS and HTML.
      That clarification made, I wholly agree with the points you and Femma are making. I also think education (i.e. of managers and PMs) and expectation setting can help patch up some of these misunderstandings. If I’m building a prototype to vet my content chunking decisions, or ferret out breakpoints, or present responsive navigation patterns to stakeholders, I do just enough to make that code work in the most current version of a single browser. And I make sure that everyone knows what the goals of the prototype are. I also make sure that everyone else on my team knows that the work of making that experience cross-browser compatible, robust, and efficient — not to mention integrating it with whatever back end is powering it — is a job that can only be done well by seasoned professionals.
      You and I are also on the same page with regards to learning a bunch of native development languages: that would be totally crazy. As I mention in my response to Theresa above, however, I believe that there are some cases there where even prototyping in HTML (with sundry jQuery support) can provide answers to particular UXD-focused questions (IA, CS, or IxD).
      Unlike some of the commenters above, I don’t ever plan (or hope) to be someone who can school the devs I work with on how to code (that would be a tall order — I work with some brilliant devs). Particularly when dealing with responsive web projects, however, I’ve found that the limitations of static wireframes are huge and that the little bit of markup knowledge it takes to overcome those limitations in the browser has proven to be a good use of my time.

  8. I am encouraging all my fellow designers to see html/css as a design tool. Just the same way they treat Photoshop as a design tool, or letterpress as a design tool 20 years ago. Designers should always be evolving and learning. Good designs happen when the designer understands the subject matter at hands. Photoshop or any traditional visual comping tools hinder the designer’s knowledge of how the web works. Designers can design, print, and bind a book, why can’t they design and present a website in the proper format? Just think of html/css coding as the equivalent of the printing stage. Once they get over that, we will all enjoy better web design in the future.

    • Letterpress was not a design tool. It was and is a printing process.
      You don’t say, “Why don’t you go into Letterpress and mock that up for the next meeting.”

  9. A lot of companies nowadays are looking for web designer/programmer. I have a friend who is a web designer and she’s having a hard time landing a job because of the demand of the companies. Doing both job can be stressful because there are times that you feel uninspired to design and also debugging your codes.

  10. What I have a hard time coming to terms with is that both designers and developers seem to throw the design part out the window when you get down to a phone-sized resolution. They seem to think that, “Hey, all people want is content at this size, so let’s throw EVERYTHING else out and just give them text on a flat color background.”
    Unfortunately, I have never seen a good looking responsive site because of this. If someone… anyone… can point me to a site that does not do this and has a beautiful looking mobile layout, please do.
    In fact, I challenge anyone to find one.
    Signed,
    Designer that hates flat square blocks of color.

  11. Design isn’t just about making beautiful things or making things beautiful, it have to be functional and enforceable from a technical standpoint.
    In my view a designer has to, at least, know the technical concepts, if not, isn’t design practice, is making drawings, because do not take into account the difficulties and technical implications.
    In a broad sense, draw a hyperspace engine for a cartoon isn’t the same thing that design a hyperspace engine.

Related Posts