How are websites and web applications designed today?

The current design process is extremely flawed and yields unhappy customers and sub-optimal application and websites. By sub-optimal, I mean that they do not have the highest possible levels of successful metrics. These metrics differ from situation to situation but usually include:

• High Task Completion
• High Sales or Conversions to Leads
• Low Exit rates
• High Satisfaction Scores
• Few complaints

The role of design is to achieve these goals. If a designer is trusted and approves a design yet fails to achieve these goals then you must consider the possibility that you have a poor or untrained designer. The key concept here is that you must hold the designers feet to the fire by stipulating which metrics they must improve. Never allow personal opinion to judge a designers work. Only trust actual metrics against real world situations. As we shall see, the reality is that opinion and power rule the workplace.

1. Design by Committee

The famous saying is by Alec Issigonis. He states, “A camel is a horse designed by committee.”

Why is a committee so bad? Aren’t two heads better than one? And why not 10 heads? The problem with this approach is the basic rules of getting along. When faced with multiple options, it is easier for a group to compromise to gather consensus. Consensus is actually the designer’s enemy. For example, let’s say a design would look good in blue or yellow. One person on the committee favors blue, and the other favors yellow. An impasse occurs. An intelligent compromise is green. It is a mixture of yellow and blue. Unfortunately, green doesn’t make either party happy and the design suffers.

A perfect illustration of this phenomenon is from a weblog called Creating Passionate Users. (http://headrush.typepad.com/)

Great designs happen when a single vision is followed. In movies, there is a director. In books, there is an author. In websites, the designer should play that central role. Without a singular vision you end up with a mishmash of compromises.

Additionally, the committee has a negative effect on the designer for another reason. It blurs the line between expert and novice. In a committee, everyone’s opinion counts equally. Democracy, right? The problem with the democratic process is that not all opinions are created equally. The designer has training and experience that make their opinions based in the craft of design, while other opinions are based on “gut instinct” and personal preference. “Personal Preference” has never been the driver of brilliance or creative genius. It only serves to let non-designers get their fingerprints on the project. I also call this “Backseat Designing”.

This is how 95% of all projects are designed. It is a horrible process and yields watered down designs and sub-optimal metrics. It depresses the designers and makes the user unhappy. Unfortunately, I cannot think of a silver bullet to make this trend go away. Maybe I could start a committee to come up with recommendations.

Design by Micromanagement

The twin sister of Design by Committee is Micromanagement. This is where managers and other people in the process will look over the designer’s shoulder and give them detailed instructions. This turns designers into “Pixel Pushers”. Words like, “Make that purple and move it to the left” suck the life right out of a designer. Design requires time and iterations. This is why Designers usually hate to have someone look at an unfinished design.

Creating Passionate Users has another illustration to show this trend. They call it the Zombie Function. It defines a straight correlation between the level a designer uses his/her brain and the level of micromanagement.

A pixel pusher is someone who knows how to use an image editing tool like Photoshop. A designer is someone who knows how to achieve goals for users. When a designer is transformed into a Pixel Pusher, then everyone loses.

Again, I do not have a magic bullet for managers to suddenly trust their designers. This is the way it has been for some time on the web. I hope this book gives designers at least a sense of community, that they are not alone.

Design by Fear

It has been a widely used term since the 1920’s. FUD stands for Fear, Uncertainty and Doubt. FUD was first defined by Gene Amdahl after he left IBM to found his own company, Amdahl Corp.: “FUD is the fear, uncertainty, and doubt that IBM sales people instill in the minds of potential customers who might be considering Amdahl products.” The term has also been attributed to veteran Morgan Stanley computer analyst Ulrich Weil, though it had already been used in other contexts as far back as the 1920s.

Regardless of its origins, it is a powerful aspect to human psychology. Design suffers from FUD in almost every project I have ever witnessed. It usually shows up when the Designer attempts to introduce a new concept.

New concepts have been the driving force for the modern economy. New concepts have made billions for those rare companies who have the new and different idea. So why do most projects flatly refuse to attempt new things? The answer is FUD. People are afraid of failure more than they are desirous of success. Have you ever heard the expression, “No one ever got fired for going with IBM.” This was a saying invented by IBM!

The design corollary is “No one ever got fired for having a white background”. Many projects I have worked on suffered from this exact problem. When a designer tries to do something a little different, the immediate reaction is to look for other companies who have done the same thing. This is also called CYA (Covering Your Ass). If you can tell your superior, “But Microsoft does it, so it must be ok” then you have covered your hind quarters from attack. However, if no other project can be found, then it must be wrong. The people at [Insert Competitor Name Here] aren’t doing it, then it must be wrong. A great commercial showed this vicious cicle by alternating between companies where they all ask themselves, I wonder what [other company] would do in this situation.

Design can put you ahead of the pack, if you forget about the competition and focus on doing what is right for the user. Keeping up, or staying behind, with the Jones’ is a recipe for stagnation.

Once again, I have no silver bullet. This illustration by Creating Passionate Users should help illuminate the issue. But conquering fear may be a task too mighty for one book.

Fear manifests itself in another more complex way. In this book, I claim that iterations are good. That many improvements can come by working on polishing the existing design. Although, I firmly believe in this kind of iterations, I also believe sometimes you need to break new ground and start from scratch. Incremental improvements can take you only so far. Once again, a perfect illustration of the concept by Creating Passionate Users.

Fear and incremental improvements lead to lateral design changes. The colors change and things move around, but the needle does not go up. If the metrics, do not improve, then the design is failing.

Throwing JPEGS over the wall

The current execution process for most websites and other web projects goes something like this:

1. Designer iterates in static Photoshop/illustrator.
2. Designer throws flat JPEG over cubicle wall.
3. Web Developer/engineer render pixel-perfect (sometimes) html rendition.
4. Engineering plugs in server-side logic.
5. QA Tests
6. Launch
7. Analyze and go back to step 1

The problem with his method is that the designer is only involved in the static rendition of the project. They are doing little or no interaction design and can only watch while engineers attempt to add in interactivity on their own. The results are often a mishmash of inappropriate interactivity and unfortunate design mistakes.

JPEGS are inappropriate tools for communicating interaction design. They can only demonstrate visual design. To get to the next level, the process must change to include a new step to replace step 3. Step 3: Designer and Engineer iterate prototype together until interaction design is completed. I am advocating that designers make their own prototypes including html and CSS, but I also acknowledge that this is difficult for many designers.

If you know HTML and CSS, then the rest of this book will show you how to elevate your work and include real interactive components. It requires no knowledge of programming on any level.