When designers are coders

In the ever-more-specialized web work world, UI (user interface) designers are frequently a “pure” career. They focus on the visual portion of UX, addressing issues such as branding and interaction design, but not taxonomy and coding. Design work can happen far in advance and apart from development, particularly in a waterfall development environment. It can happen in Agile, too, where a common solution to coordinating design and development is to have the creative work done a sprint or two ahead, a creative designer may find himself focused primarily on comps and web graphics, rather than prototyping or front-end coding. So long as both design and development are readily available to work through changes together once development kicks in, this can work quite well.

This specialization is a good work model, not least because it allows designers to be true experts in interaction, branding, etc. (Please note: I’m not arguing that either the specialist approach, or the shared roles—developer/UI/IA—approach, is better. Both have excellent advantages in different situations.) Such designers do not typically think of themselves as coders.

But they frequently are.

Many UI designers, particularly in the corporate world, work with a style guide. They frequently drive it, as style guides establish a visual language for the site. In the same way that someone flipping channels can frequently tell a CSI scene from a Law & Order scene without looking up the show title, the visual language of a site should set it apart as itself.

The style guide helps designers and coders do that. It’s a shared reference, in which the designers establish the visual and interaction requirements, and the developers create CSS styles to invoke those requirements on the page. This is where designers become coders.

Why does this matter? Because the tags a designer chooses become the code the developer uses, and the semantic impact of them goes beyond the visual interaction. Among other things, the semantic nature of code affects how it’s parsed by search bots, and how accessible it is to the visually impaired and other disabled users.

Designer-driven code happens in two ways:

specs

After designing interactions, creating comps, and obtaining buy-in from stakeholders or clients, there comes a point when a designer looks upon her work and knows that it is good. To ensure that it stays good when it gets translated into code, the designer then creates specs for the developers, frequently using a style guide to pick the appropriate tag or style for a given need.

It’s at this point that the designer becomes a de facto coder. Again, the tags a designer chooses become the code the developer uses. In this situation, designers must be careful to use the appropriate tag/style for the appropriate need. Header tags should be used for headers, and organized top to bottom—not used to create a visual distinction in non-header copy. If a designer chooses a header (H1-H6) tag for a visual style, the developer nests the copy within that tag, regardless of whether the content is a header or not.

So designers must be aware that when they use a header, or blockquote, or definition tag, they are telling the browser, bots, and other applications specific information about that content. Remembering this when creating specs helps considerably in producing semantic, searchable, accessible code. This should not be a burden to designers, particularly since organizational tags are limited but text styles are infinite.

creating the guide

Style guides are created in a variety of ways. Sometimes it’s a collaboration between development and design to create an entirely new brand from scratch, in which case it’s easy to develop a semantically sound guide. Sometimes it’s driven by design, and created by developers.

Sometimes it’s captured from an existing site, in which styles may or may not be semantically sound. For example, I worked in one place where header tags were viewed primarily as visual tools, and the same page might have five different H1 tags in five different styles, depending on the CSS-styled area of the page they were used. In such cases, developing a semantic style guide is more than simply changing a mindset, it’s a complex, large undertaking.

Semantically sound code makes sense. It’s easier to train new designers on it, easier to maintain as your site evolves, and sets your site apart to search bots as a more well-organized, user-friendly, likely-to-be-relevant source of content. Designers who are aware of the effect their styling instructions have on semantics will not only be better “coders,” they will be more valuable designers to their clients or employers—and most importantly, create better user experience for their audience.

Read More