The problem is the stigma attached to the term “accessibility”. Now we know that web accessibility achieves more than simply facilitating access to web content. But a lot of government organizations and businesses don’t see the need to even try and conform to accessibility guidelines.

As part of a group of organizations (the advisory group for the Dutch Web Accessibility/Quality Guidelines) concerned with changing this way of thinking, several of us are trying to compile a list of themes/categories/factors which can be considered building blocks of really good websites, or less-obvious benefits of accessible websites. I’m aware of many, but lots of people in this industry are so incredibly smart; it would be such a pity not to ask.

So I’m asking! The idea is to create a list of things like “interoperable”, “search-engine friendly/findability”, “archivable” etc. to help convince government organizations and businesses that there are lots of non-obvious benefits in conforming to web accessibility guidelines. “Cuts down on bandwidth usage” is fine. I’ll parse the list and try to group like-minded suggestions together to come up with some high-level themes. I will post the results and link to any known follow-up usage or derivative of the resulting list.

Even if you can only think up one thing, please add it to the comments! Ask your friends (but don’t spam :) ). Don’t worry too much about accessibility, just quickly note whatever you think makes a great website.

Care to chip in? What constitutes a good website?

On content

Content is important. After all, it’s content people who come up with job titles like Content Strategist, which pretty much means One Who Thinks About Content. Which content, for whom, when, where, why, how… It’s absolutely necessary, because clients don’t do it. Not at the level that it should be done.

Paul Rand, one of the most well-respected designers this world has seen, called design “a method of putting form and content together”. If you would agree with this statement (as I do), you can infer the role of the designer as the one who must successfully combine two components: form and content (the designer will first busy herself with the form component). These two are not mutually exclusive. They are separate components which share a common goal and should be developed on a parallel track to one another. This, however, does not mean that they should be reviewed by the client together at every stage.

On clients

Two quick facts about clients:

1. Many don’t know what they want, and when they do, they don’t know how to communicate it
2. Many lack the imagination to “see through” design sketches

These are the reasons we are hired in the first place. But these two facts have paved a dangerous path across the lawn of the creative process. An alarming number of web professionals today seem to advocate making preliminary deliverables mimic the finished product– the more accurate, the better.

This is, well, stupid.

It’s not stupid if don’t track your hours. It’s not stupid if you don’t care if or how much you are paid for your work. It isn’t stupid if you don’t mind doing twice as much work for nothing. Your clients will love you for it, and you’ll be doomed to continue doing it for the rest of your career.

On designing in the browser

When Andy Clarke first started talking about “designing in the browser”, I thought it was a great idea. Then people started misinterpreting this to mean “executing the creative process in the browser”. If Andy really designed in the browser, his designs would be shit. What he was of course referring to was the execution of a design idea in the browser as opposed to a tool like Photoshop, which doesn’t communicate Web Things the way a browser does. He strives for more realism in his deliverables. He’s simply working based on the two Client Truths listed above. And if you’ve ever done designs in Photoshop, you’ll know that applying client changes to those documents is akin to cutting off your own fingers one knuckle at at time. HTML is much easier.

That said, there is certainly a place for Photoshop sketches. It’s possible to put together a quick visual impression of a website in far less time than it would take to work out in HTML. I’m referring to the basic idea of a website, an impression of the design language, intended to gauge if we are on the write track before spending many more hours mocking things up in HTML, which is, in fact, templating. I am not referring to creating finished static design visuals. These are the bane of the web designer’s existence, and should be avoided at all costs. If you really understand your client’s needs, that means you’ve done your homework, and you’ve actually designed before the browser. Otherwise: baby steps.

On communication

Imagine that your job was to drive your client somewhere. They aren’t quite sure where they want to go, but a lot of sun would be nice. And perhaps water. You could drive them to California, but once they hear about Florida, they might prefer that and demand that you drive them there (at your cost, because you’re the one who chose to go ahead and drive to California).

A better way would be to communicate with the client, asking them if they prefer dry heat or humidity, surfing or Spring Break parties, earthquakes or hurricanes. Based on this information, you could show and tell about both places, help them weigh the pros and cons, and help them in their decision. Then drive. Only then.

Making websites is a process. Creativity is a process. Pacing and leading clients is a process. You’re not going to eliminate frustration by trying to come up with real content, a polished design and working browser functionality on the first go. You will lose money, though, and perhaps your sanity.

There’s a reason for storyboards. But wait, shouldn’t Pixar just go ahead and build and render the complete movie so that the studio execs can see how it will really look?. Then, if they like it, it’s done! Yeah, right. Good luck with that.

There’s a reason that advertising teams consist of an art director and a copywriter: design and content. They’re bed buddies. But these teams pitch ideas, and then work them out. That’s why we have wireframes. That’s why we have Photoshop. That’s why we have Lorem Ipsum. And that’s why we have, most importantly, good old pencil and paper.

On balance

Here’s what I think: some web professionals want to focus more on deliverables than on people. But guess what: it’s all about people. We need to help our clients along and communicate with them. If you want good deliverables the first time around, the answer is not to use “real” content and a design which is in fact finished HTML/CSS/Javascript in a real browser. The answer is to ask focused questions, discover the pressing problems, to introduce your client to your potential solutions to those problems. Give them tidbits: here’s an impression of how the site could look visually. Here are some things you might want to consider concerning your content. Work your way up to real content in a real browser. When done right, that point can come quickly.

It’s too much to show a client all these things at once in the very beginning. There are too many factors, and it’s impossible to tell which factors will influence their opinions at that moment, which makes revision a nightmare at best. Of course content and form should each be developed with the other in mind. But consider presenting separately at first. Yes, that could mean that Lorem Ipsum is an option. That could mean that Photoshop is an option. That could mean that a sketch on a napkin, with a good, old-fashioned explanation of how things work, is an option. When you know enough, put form and content together.

On bed buddies

And forget the content versus design war. They need each other. In the words of Paul Rand, “when form predominates, meaning is blunted. but when content predominates, interest lags.”

It’s for this reason that Eend and Cinnamon have spent a lot of time putting together a workshop which we feel will help clients, their project leads and/or managers to get the best out of the web shops they hire. The two-day workshop has been designed to expose clients to the potential success factors and pitfalls on their side of the project, and to give them the tools to use this knowledge to their advantage. The entire project process from bidding to post-launch evaluation will be examined. We’ve got great speakers with very high-level, client-side web project (management) expertise, as well as a few on the development side for a well-rounded whole.

Grip—or rather Grip2009, as this first workshop is called—will be held on November 17 and 18, 2009, at the very posh (no, not that POSH) Grand Hotel Karel V in Utrecht, The Netherlands.

While there are plenty of workshops and conferences for developers on building better sites, there is little practical information for clients on how to ensure a successful web project. We’re excited about Grip2009. We hope it will give clients the tools they need to engage with their web contractors like never before.

Unfortunately, this first edition of Grip will be completely in Dutch. We haven’t ruled out an international (English) event for the near future.

For any Dutch readers, here’s the press release (feel free to distribute):

BEGIN PERSBERICHT —

Grip2009 – Tweedaagse workshop voor webprojectleiders

Op 17 en 18 november 2009 wordt in Grand Hotel Karel V te Utrecht een tweedaagse workshop voor opdrachtgevers van webprojecten gegeven: Grip2009. Het programma is samengesteld door ervaren internetprofessionals en levert, naast nuttige tips, bruikbare kennis en vaardigheden uit de praktijk om grip te krijgen op webprojecten. De nieuwe workshop, die dit jaar voor het eerst wordt gegeven, richt zich op opdrachtgevers die hun internetprojecten beter willen begeleiden.

Voor opdrachtgevers van webprojecten bij het bedrijfsleven, not-for-profit-organisaties en de overheid is er momenteel weinig concrete en in de praktijk bewezen informatie beschikbaar hoe deze projecten tot een succes zijn te maken. Dat verandert met de komst van Grip2009. De workshop is bij uitstek geschikt voor mensen die aan klantzijde betrokken zijn bij de inkoop, de ontwikkeling en het beheer van internetprojecten, of mensen die een carrièrestap overwegen in deze richting.

Er zijn maximaal 60 plaatsen beschikbaar voor dit unieke evenement. Snelle beslissers kunnen tot 16 oktober profiteren van een flinke korting. Meer informatie vindt u op: www.grip2009.nl

EINDE PERSBERICHT —

• personal taste of the client
• personal taste of the spouse of the client (oh, yes, it’s true) or other stakeholders
• body language
• use of language and tone-of-voice (whether written or spoken)
• etc. (I’m sure you can think of quite a few)

Use of language

Use of language is an interesting one. I’m an American working in Holland, so when I write proposals in Dutch, I might not be choosing the very best words to describe what I mean because there’s always a limit to my vocabulary compared to that of a native speaker. Even within my native American English, I’m sure my vocabulary is quite limited (although I’d love to attribute that fact to the 80/20 rule). But language barriers aside, when one’s vocabulary offers more than one word to describe something, the choice of word can say a lot about the way the person approaches a given subject. Choice of words, very much like choice of clothing or choice of music, can give tiny bits of insight into personal preference, corporate politics (in the form of resentment or rebellion), level of expertise on web-related issues and sometimes even hidden meaning.

This very simple process would involve determining which meaningful words a client uses, and how often they use them. By meaningful I mean giving little or no value to adjectives, conjunctions and the like. “The” is not going to tell us much.

How to do it

With the spoken word this is hard to do. You can’t get an exact count of specific words while talking to a client. And if you could, you’d look like an asshat. Personally, I tend to make mind maps during client meetings, which by definition means that I’m only writing down keywords in relation to each other. Mind mapping also minimizes writing time, which allows me to pay more attention.

When you get written material from a client, like an RFP or a project brief, there’s a cool way to do it: Wordle. Wordle is a fantastic little tool which examines a piece of text, counts the words and creates a treemap-like visualization of these words. The most-used word is largest, while the least-used is smallest. And with options for colors, fonts and placement, Wordle word clouds look nice as well.

Play around

Try it out. Take a document in which your client explains what she wants or expects of your current project (or any correspondence, for that matter) and throw it into Wordle. See if it tells you something you hadn’t noticed by simply reading. Oh: Don’t save your client’s stuff in the Wordle gallery. Thank you.

Please note that in dealing with clients it would be foolish to rely on word analysis alone, but it could be a nice addition to one’s toolbox. Since clients often expect us to read their minds, we might as well oblige as best we can.

This imbalance, as it turns out, reveals itself not only in money, but in virtually any situation where there exists a relationship between input and output or cause and effect. And that’s just about everything. The imbalance is not necessarily 80/20. It can be 70/30 or 90/10. The point is that there is a significant imbalance.

It’s logical, when you think about it. Not all of what you do can possibly have the same effect on an outcome. Not every design will get the same amount of attention. In a 10-slide presentation, perhaps two or three slides will have the most impact. A site we just finished has several nice features, but only one or two of these will set it apart from similar sites. We paid the most attention to these features.

As a web designer, developer, or whatever it is you do, it’s a good idea to go into 80/20 mode at several points during your project. What are you doing right now? Is it part of the important 20% or the trivial 80%? Is that button really a show-stopper? The 80% is not bad, it’s just not as important. Utilizing the 80/20 Principle can help you set the right priorities. Short on time? Do 20% stuff. It will have the most effect.

Think about it… How much of Microsoft Word do you really use, Or any app for that matter?

Recommended reading: The 80/20 Principle by Richard Koch. This book is a must have. Richard really goes geekily in-depth. The 80/20 Individual is also quite good, but you should really like the subject if you decide to read both.

One of the article’s comments brings up an interesting point. While I don’t own a large company, we do serve some very large clients. And one thing I’ve learned from them is something anyone who sells anything could probably tell you: if you want to sell something, whether it be a product, a service, or an idea, you’re best chance is to first speak the language of the person to whom you’re selling. Once you’ve done that, you need to show the buyer what’s in it for them. At big companies, it’ll usually come down to the subject of money.

Peter-Paul makes an interesting point. Developers at big companies speak the language of other big-company developers. They have different work environments, often high-stress and high-profile projects, and they often work on one aspect of a project (e.g. only HTML/CSS/JavaScript). While this could be a great first step, we need to remember that getting large companies to embrace web standards will not only involve convincing the developers, but also the management of these companies. What’s in it for them? How’s this stuff gonna make them money? Got your pitch ready? Sell it.

The idiocy peaks with the apparent lack of a decent search-and-replace job, as the name Cinnamon is to be found on the very first page.

These people can’t even do a decent job of copying a website, let alone build one. You can hire them, if you can even find their contact information.

Cursor Webdesign, if you want to run your own business, write your own copy.

If this client had informed me of any complaints which were heavy duty enough to withhold payment (there aren’t), I would have listened. If this client would have informed me of cashflow problems, I would have listened. But not paying, never being available by phone, never returning my many calls or responding to the many letters, and still enjoying the benefits of a new website? Uh, let me think. No. Delete.

We take pride in being flexible and providing clients with the best possible service, and we have some mighty important references who’ll back that up. I guess I’m a bit surprised about this because it’s never happened before. But maybe it comes with the territory.

Anyone have similar horror stories? How did you resolve? Please share.

Computers have changed the way designers work. Until you’ve hand-inked 25 variations of a logo with technical pens and india-ink-soaked brushes, you won’t fully appreciate how much time an application like Adobe Illustrator can save you compared to the way things were done in the past.

On the other hand, presentations were made quite quickly. I can draw quite well, but not very quickly. When I started work in branding and advertising, I was simply amazed at how quickly some artists could render some art director’s idea. They got a briefing, went back, drew for a few hours (mostly with markers), pasted the drawings on board, and boom. Presentation done. Okay, I’m exaggerating the process, but these people were fast.

After a while, I and many other designers started doing these analog/digital hybrid comps (many use the word mockup, you decide), a sort of glorified cut-and-paste, combining computer-set type and drawings or prints of actual photos. Type rendering was quicker, but the rest started slowing down. But, clients liked it because they had a clearer picture of what they were going to get.

Uh-oh. Now you feel it coming.

Photoshop. I don’t necessarily mean the Photoshop, just that type of application. Photoshop, Illustrator, and all these othher tools are wonderful. They help designers, absolutely. But something’s going on which is actually making clients (and even account managers) more demanding, and making things really hard on designers.

The problem with Photoshop comps is that they look too easy and they look too real. Some clients actually think you’re almost done with the work. The great thing about those old marker renderings, which are sometimes still presented to clients (only less often), is that they looked very impressive and hard to do, and they didn’t appear to be a completed product.

So wherein lies the danger? When we’re so good at making slick proposals, that the reality of the actual product causes the client to question the difference. This isn’t much of an issue with print work. It is with the Web. It’s tempting to use anti-aliasing in proposals, just to make them look good, sell better, and forget that not everyone is using a Mac; not everyone will see smooth type on-screen. Well-chosen and well-edited proposal imagery may not match what the client’s budget will allow. They may actually want that photo, and be dissatisfied with any alternatives.

Ambiguity can be important. It’s a tool. Think about the last time you read a book and then saw the movie. Most often, the on-screen movie will never beat the movie in your own head, which you made by reading the book. The ideas are there, but you fill in the details. When you present a super-comp to a client, they can’t fill in the details. Instead, they begin to focus on the details already in place. And no, Lorem Ipsum is not the answer (not completely ;-). So what is?

If you’re having no problems in this area, I salute you. Either you have a great account manager, a client who trusts you so completely that you’ve actually wasted your time showing them a preliminary design in the first place, or you’re lucky. The rest of us need to find ways to minimize the discrepancies between what we show and what the client gets, as well as ways to help us save time.

Here are some ideas (not a step-by-step!):

• Present polished rough sketches first, then move on to comps. This allows the client to comment during the phase which takes the least amount of time. The final comp is often seen by the client as a collaborative effort, in which the client has taken part.
• Use mood boards first. Mood boards have been around for a long time, specifically for the purpose of defining possible design directions before spending lots of valuable time on the execution of an idea which the client might not like in the first place. Don’t continue on until the mood boards have been approved.
• Use as much of the client’s material in your comps as you can, unless the material is to be developed from scratch. If I had a dollar for every time a client wanted that specific photo or illustration which I had simply ripped from a magazine or stock book for the presentation, I’d be blogging from my beach house in the Bahamas.
• Do use Lorem Ipsum for body text, but not for headers and navigational/functional elements. Try to be as realistic in these elements as possible. You don’t want the client to end up ignoring the design and start reading the text, but you do want to keep the difference between “Consectetuer” and “Other articles of interest” in mind.
• Explain. Always explain to your client in no uncertain terms that this is not a finished product.
• Don’t present digitally. Oooh. I’m going out on a limb here, but if you present to, say, five or less, try to avoid laptop or projector presentations and print and paste your comps on presentation board. This seems to somehow psychologically frame them as “conceptual”, as opposed to “almost done”.

These are just a few ideas. Please feel free to post your own methods as comments. I’m interested in how other designers approach this problem! Basically, and I’ll repeat this often enough in this blog: work gradually from loose ideas and concepts in the beginning to details in execution later on. Much time is often lost tweaking those icons, only to find that the client doesn’t like where you’ve gone with the whole. Eliminating discrepancies between comps and end results while maintaining a stunning proposal can save lots of time, and lots of money.

The book is published under a Creative Commons license. I’m not sure how people can get copies of the book; I’ll post it here when I find out.