Blog:

Many designers don’t think about the code behind the sites they design. This is a huge problem because it slows web projects down, which costs money. The good news is designers don’t need to learn code; they just need to change the way they think.

Stopping the Chinese Whispers

Whether you’re building the latest, greatest web app or the next big online magazine, there’s nothing more important than clear communication between all your teams members – from the content authors to the developers.

It’s good business practice to make sure everyone is kept up to date with meeting minutes, the correct specs etc. One thing which is missing though, is a clear understanding of semantic document structure across the development team. This simple concept, if understood by the entire team, can save a lot of time on a project.

The way designers think

You may think, especially if you are a designer, that semantic document structure doesn’t matter – “It’s something the developers need to know about, not me”. This isn’t the case. You do need to know, but you don’t need to learn the in’s and out’s of HTML to do it. You just need to alter your thought processes ever so slightly. Unfortunately, this can sometimes seem like teaching an old dog new tricks.

Designers are a funny bunch. Most designers have two halves to them: the analytical, problem solving half and the artistic half. Sometimes, although rarely, these two halves combine to create some very special work. A lot of times though, a designer’s mind is one in turmoil.

Throughout design school, Designers are taught to solve problems, visual problems, in a very touchy-feely kind of way. Sure, we are taught to examine a brief, do preparatory work and research, and generally think (and rationalize) a lot about solving the visual problem, but when it comes down to actually producing the work, it’s a different story and the right half of the brain kicks in. We begin to think in visual terms and act very much on instinct. I’m not saying this is a bad thing, it’s just different to the way many people approach their work. If fact, in a world where it is expected to explain your decision making, it can be quite difficult for a designer. You see, turmoil.

As building in Web Standards has almost become commonplace, the use of semantically rich markup is extremely important. Not only to allow the use of CSS for presentation but also to ensure the structure of the content is presented in the way the author intended. This is where I think designers are tripping up, especially if they are new to the industry. We’re just not interested in delving into code. Wading into the latest tome on AJAX just doesn’t yank our chains – we’ve got enough on our plates trying to keep up with the shifts in graphic design culture throughout the world. Why the hell should do we need to learn code as well?

Well, the good news is. I don’t think we do.

Designers need to go back to the very roots of the content and engage the left side of the brain.

It’s not about code – it’s about meaning

Now you’ve had an insight into the dark place that is a designer’s mind, you may have an understanding why the graphic designer you’ve just commissioned to design the UI on your latest web app gives you a blank look when you mention semantically rich document structure. Don’t worry. Designers already understand semantically rich document structure, just in a slightly different way.

As we all know, in most documents there is a structure and a hierarchy of elements, from letters up to chapters.

Here’s a list, which is by no means complete, that explains what I’m talking about:

• Words – Sentences
• Sentences – Paragraphs
• Paragraphs – Sections
• Sections – Chapters
• Chapters – Document

You could of course go more granular than this, but I think it illustrates the point.

From this you can see how, by looking closely at the content, that the language can be broken up into chunks, into bits of semantically functional elements. So, you could say that documents have a conceptual structure
.

This won’t come as a surprise to you. An implied structure in a document is something taught very early on in school but you’d be amazed at how many designers forget this when they are given something to design. Sometimes the structure goes out of the window for the sake of something that looks good.
Most designers don’t think of content in these terms, they think of written content in terms of visual hierarchy – of visual importance. In the designer’s eyes, that is an essentially what semantically rich content is, it is visual hierarchy. Once a designer becomes used to thinking in this way, the whole semantic content thing becomes so much easier to swallow.

Matching models

Earlier on I mentioned how this can save your development team time and money. The key to this is matching models. You need to match models throughout the process, and there are four of them:

1. The author’s model of the content
2. The designer’s model
3. The developer’s
4. The reader’s

For a product to be successful, or for your team to work cost-effectively, these models all have to match up. The designer should understand where the author is coming from, as should the developer and the reader. If the reader understands, and likes it, then you’ve done your job well.

The common concept throughout is meaning. Understanding of the content and its presentation. Otherwise known as semantics.

It’s not just designers

Yes, that’s right. Just because you’re a journalist or a developer doesn’t mean you get off lightly.

Most journalists I’ve worked with over the years understand little of document structure. Or rather, they sometimes do but can’t communicate it effectively.

The same can be said for Information Architects (IA). Many IA’s are focused on user and functional requirements (and rightly so), but this can mean they are less focused on the semantic meaning of page elements at a granular level. In practice, that can mean a designer receives wireframes which may not match the author’s mental model.

Many developers understand semantics. In fact, many of them understand it so well they go round and round in circles trying to analyze every bit of content under a semantic microscope. This can also kill your project dead. So, lighten up developers, the meaning of content elements isn’t always black and white.

Change the way you think, and engage your (left) brain

I’m going to pick on the designers again.

Next time you hear the word semantics, or semantically rich tags, ignore them and think visual hierarchy. Or typographic hierarchy. Don’t get turned off by these phrases. It just means hierarchy.

I know I was turned off initially by the concept of semantic document structure, but once I got my head around what it meant in visual terms, this Web Standards thing everyone was talking about suddenly seemed to make sense.

Like this article? Digg it!