I’ve been thinking recently about the relationship between clients and designers. And about how we get clients to the point of saying yes. Yes to what, you might ask? Well, that might be yes to the design, that might be yes to your wireframe, some feature or just your approach. But it’s the way that we present ourselves to clients and the way that we interact with them that I want to look at.

Let me first introduce you to the ‘man from Del Monte’. For those of you who don’t know, the man from Del Monte appeared in an advertising campaign in the UK for Del Monte, makers of fruit juice. The advert consisted of a man dressed in an immaculate white suit and a trilby. He had a very colonial look about him and would visit various fruit farms around South America. Each time there would be a groveling peasant farmer who would present his oranges with fear and trepidation to the man in the white suit. And then there would be this moment of hush. And the man from Del Monte would pronounce judgement on the quality of the oranges that were being presented to him. Then when the answer came – ‘the man from Del Monte, he says yes!’ – there would be immense celebration, cheering and dancing. The farmer was very happy that his oranges were good enough quality to be included in the Del Monte range.

Apart from the fact that it’s impractical to be wearing a white suit in an orchard, the point that I took away from the advert is this; That in the web industry our relationships with our clients are sometimes like that. We present something to them and then we wait on tenterhooks for their answer.

Wrong Relationship

At the heart of all of this is a wrong relationship between designer and client that is fundamentally flawed. It’s not something that we talk about very much but a big part of our job is our relationship with our client. So I want to concentrate on fixing that relationship.

In many ways we treat our clients like they are royalty. They’re the people who you have to bow and scrape to. Often we can blindly follow the client’s lead and we can end up being quite submissive in the relationship. We’re afraid to express our opinions, nor do we effectively communicate our opinion when we try to. What happens is we get so frustrated that we give up on projects and effectively kill them. We get to the, ‘yeah, yeah you can have whatever you want,’ stage and we give up.

Or, we swing to the other extreme and we become the person is constantly saying no to everything. We turn into the difficult and argumentative person.

Time to Change

It’s time for a revolution in the designer / client relationship. It’s time to go from a master / servant relationship to a peer / peer relationship. It’s time to change the relationship so that we, as designers, are the experts, providing an expert service and the client perceives us in that way.

How do we change it? Designers need to become the expert in the relationship. Designers also need to be more positive and move away from that negative mentality that ruins so many projects. Negativity can rear its head when we say no to clients but also in the way that we view our clients.

Become the Expert

1. Have a methodology. It puts you in control. It enables you to set expectations with your clients and let them know what’s coming. Nobody likes uncertainty and they certainly don’t like uncertainty when they’re paying a lot of money for something. Clients like to have a sense of what’s coming next and what they can expect from the project. Sit your client down at the beginning of the project and tell them what’s going to happen. Show them the stages that you’re going to work through before you end up at your final deliverable. Maybe even beyond that if you plan to evolve their site over time. By doing this you’re setting yourself up as the person who is in control of the relationship. You’re also reassuring the client and setting their expectations at a reasonable level.
2. Gather information. Everyone works differently and so your methodology may be different to mine. But whatever yours is like, make sure to include a big section on ‘information gathering’. So we’re talking about things like; success criteria, business objectives, competitive analysis, priorities, mood boards, user personas and user expectations. The reason why this information is so important is not only so that you can deliver a better solution but it’s immensely important when it comes to justifying why you have done something a certain way. This is a really important part of the process. It’s unfair of you to expect a client to accept it because you’re the expert. You need to prove that you’re the expert by justifying your decisions in a way that they can understand and associate with.
3. Use third party data. You don’t necessarily need to use the information that you gathered from the client to justify your decisions, you can use data from third parties if you like, such as research institutes etc.
4. Write down anything that’s agreed. Whatever you’re discussing with a client, either over the phone, on e-mail or IM, if something is agreed upon then you need to record that.

Be Positive

We need to take a leaf out of President Obama’s book and live by the mantra, ‘yes we can’. We need to stop blocking ideas that our clients have and stop being negative in our communication with them.

1. Say yes. As part of my quest to have my clients see me as the expert I try to say yes to them as much as possible. However, as part of saying yes I also explain the consequences to them at the same time. “Of course we can do that, but if we do then this, this and this will happen.”
2. Suggest an alternative. Instead of leaving the discussion on a negative note try to suggest an alternative. You can still say yes, present the consequences and when the consequences are not desirable then suggest an alternative.
3. Be enthusiastic and caring. When you suggest an alternative do it with enthusiasm for the project. Give the impression that you give a shit. Obviously, this has to be sincere.
4. Be positive about your relationship with your client. Clients are not stupid. I hear designers talking like their clients are stupid all the time and it annoys me so much. “They just don’t get it”, is a favorite phrase a lot of people use. Clients aren’t stupid, they’re clever, intelligent people. They just happen to be good at something other than design. And just because they don’t understand the Web doesn’t mean they’re not clever. There’s more to life than the Web. Your client will pick up your condescending, patronizing attitude and so we need to be very careful to keep that under control.
5. Give your clients credit for what they’re good at. They know their target audience, they know their business, they know their strategy. They might have trouble communicating that in a way that you can understand but they do have a lot of knowledge. Don’t forget that they have to live with the sites we build. So listen to them when they give you information.
6. Show your work little and often. As designers we don’t like to include clients in the design process if we can avoid it. We don’t like to show work that isn’t finished. Whether it be wireframes, sketches or designs you need to show it to the client as you work on it. By getting them involved they are becoming committed to the process. They’re a part of it and they feel valued. They’re much more likely to approve a design if they have seen it early on and been part of producing it.

Shape the Role of the Client

1. Explain what’s required of the client. At the kick-off meeting you need to set out and explain what’s required of the client. You may have designed hundreds of websites, one after another, but they haven’t. This may be the first time for them. So it’s really important for them to know what their roll is not only to help them but to constrain them as well.
2. Focus the client on the problem, not the solution. If a client comes to you and says, ‘I really hate that blue, I want it be pink.’ You don’t know why he or she wants that, or what the background to the request is. If you just do it then you’re just a pixel pusher. What you need to do is to refocus them on the problem. Why do they dislike that blue? In this situation a more useful statement would be, ‘I’m unsure that the blue will appeal to my teenage girl demographic.’ Now, you know what the problem is and you can work on it.
3. Focus the client on the business. Try to get them to concentrate on the business objectives of the new site. So often clients get caught up with the detail. They worry about the names of sections or the white space on the design. What they should be concentrating on is the question, ‘does the new design help achieve their call to action?’. ‘Does the design communicate the unique selling points of this particular organization?’.
4. Focus the client on users. It’s no use to you if your client tells you what they don’t like and what they do like. What’s important is what the users like and don’t like. Never, never ask a client, ‘what do you think?’. Ask them, ‘how do you think your users will react to this?’.

Managing Feedback

Everything is fine when the designer is talking but once our clients start to give us feedback, that’s when the issues start. So we need to manage the way in which our clients give us feedback.

1. Talk to everyone involved in the decision. Clients consult other people. Even if you’re working with a very small business and your point of contact is the business owner himself, you can bet he’ll show his wife the design (or vice versa). If you’re dealing with a bigger client then there could be a whole group of people who will see your design. Try to talk directly to those people too if possible. If you can make them feel wanted and listened to then they are more likely to come on board.
2. Meet with people individually. Have you ever been in a meeting where one person says, ‘I think the blue is too dark.’ And someone else says, ‘I think the blue should be light.’ And what you end up with is a lighter shade of the existing blue. That’s design-on-the-fly. This can be avoided by meeting with each person separately. If needed, issue a questionnaire in order to really control the kind of feedback you’re getting.

So to recap. You need to turn your relationship with your client into a peer / peer relationship. You need to become the expert and be more positive. You also need to mould the roll of your client and manage feedback carefully.

Listen or Watch

You can listen to the audio of the talk, or subscribe to the podcast.

Like this article?

If you enjoyed, this article, feel free to re-tweet it to let others know. Thanks, we appreciate it! :)

Photo credit: flickr.com/photos/jonchristopher

Here are the major takeaway points from the interview:

1. We’re approaching the “demise of the website”. Your website is no longer your only route to your customers. You should be publishing your content and entering conversations in as many channels as possible including: AudioBoo, Twitter, FaceBook and FriendFeed.
2. Biggest tip for web designers: Learn how to “sell yourself”. This means you need to be comfortable selling your skills and ideas to potential customers. A large part of this is healthy self-promotion.
3. It’s important to never fool your customers, even if the end-game is honorable. A great example is IE6update.com. It essentially uses JavaScript to trick users into upgrading from IE6 to the latest version of Internet Explorer. In general that’s a great thing, but tricking people to do it is deceitful. This lesson applies to sales and marketing – never try to fool people – they’ll always find you out.

If selling yourself and healthy self-promotion are key to being a successful web designer, what’s the best way to do it? Please give us your thoughts in the comments.

Photo credit: flickr.com/photos/kurafire

The Perceived Losses of User Testing

There is a wide-spread perception that user testing is time-consuming and expensive, and to some extent with good reason. Traditionally user testing cost millions and took weeks to complete. It was held in expensive usability labs with two way mirrors, computer suites, and video surveillance. Large numbers of test subjects were required to provide statistically relevant data. Each had to conform to a specific demographic profile and so was hard to recruit.

A usability consultant, testing in a lab, with carefully selected subjects is effective. However, it is beyond the budgets and time frames of most organizations. User testing does not need to be like this. In-fact, it can be lightweight and inexpensive. It is also something you can do yourself. Although not the most effective approach, it is better than not testing at all. However, even the most lightweight user testing will require some time and budget. Do then the benefits outweigh this cost?

The Real Profit of User Testing
The benefits provided by user testing cannot be understated. Even the most lightweight approach will have a profound affect on your web presence.

The benefits of user testing include:

• Fast problem detection
• Increase user satisfaction
• Reduced support costs
• Increased efficiency

Bargain Basement Usability

The bargain basement approach to usability testing was pioneered by usability experts Steve Krug and Jakob Nielsen. Although they differ on the details, they agree on three key principles:

• Test a little but often
• Use a limited number of testers
• Don’t become too concerned with who you test

If you want to user test while delivering on time and in budget, then these principles are important.

Test a Little but Often
Key to this approach is the principle of “little but often.” Testing should occur throughout a web project’s life-cycle and that means keeping testing lightweight.

At the most basic level this is what Steve Krug calls “cubicle testing”, where any new development is shown to colleagues to see if they can make sense of it. This simple form of testing is remarkably effective.
If however, you choose to be more sophisticated in who and how you test, never let that be at the expense of quantity.

Why ‘often’ matters?
Multiple rounds of testing identify more problems. When initially testing many users get stuck at the first hurdle. A second round provides the opportunity to fix initial problems, allowing users to progress further and uncover new issues. The number of rounds is largely dictated by budget and time. However, the more rounds, the more issues you will uncover. This is true even with a limited number of testers.

When to test?
Before the project commences, test your existing site or that of your competition. These sites act as a free prototype which help identify potential usability issues.

Test sketches and design concepts.
Your designer may resist showing users unfinished work. However, this is a chance to identify issues before too much time has been invested. When testing a design for usability focus on whether the user ‘gets it.’ Do they understand what the site is about and how it works? Did the user understand the terminology used and were they paying attention to the right screen elements?

Before beginning production consider testing against a wireframe. This is preferable to testing against a finished site, which cannot easily be changed. There are a number of tools that can reduce the time spent building wireframes. However, I think, the best time saver is to use a content management system (CMS) to construct your wireframe. If done well, this CMS driven wireframe can be reused as the basis of your final site. The wireframe is therefore no longer wasted.

User testing should not end with the wireframe. As you build the site itself, test that too. It is perfectly possible to test a half finished site. Select tasks for users to complete that focus on finished sections of the site and avoid the unfinished. Finally, do a round of testing pre-launch. By this stage the majority of issues will have been discovered. However, a last check will uncover minor problems that can be corrected.

You do not need to test at every stage. What I do recommend is that user testing should be an ongoing exercise even after launch. Periodically run test sessions both in development and post launch. Always seek new ways to make your site easier to use. Now I have told you when to test the next question becomes; who to test?

Beware of Decreasing Returns

Many website owners believe that usability testing is worthless if you do not test a large groups of people, who all fall within the target demographic. They are therefore discouraged from testing. However, this belief is not true. Statistical testing (as outlined above) is expensive and time consuming. It does not provide significant benefits over the bargain basement approach. In 2000 Jakob Nielsen wrote:
“Elaborate usability tests are a waste of resources. The best results come from testing no more than five users and running as many small tests as you can afford. ”

The reason is that the majority of users encounter the same problems when testing. The more users tested, the more overlap he found in the problems. Eventually the level of overlap is so high that the likelihood of discovering more issues is remote. As I said earlier and Nielsen reinforces above, multiple rounds of testing are more effective.

Steve Krug takes the logic further suggesting that you should only test three or four people. This catches the majority of serious issues, although admittedly some minor issues could slip through. He believes that this is a price worth paying as testing only three or four people allows testing and debrief in a single day. In short, the more people you test the lower your return on investment. ROI is also an issue for recruitment of testers.

Beggars Can’t be Choosers
It is easy to waste time and money recruiting the perfect user who matches the personas we created earlier. This is fine if you have limitless resources. However, it cannot be allowed to reduce the number of rounds of testing.
Although having the right users is good, it is not as important as you may think. Most users encounter the same problems when using a website, no matter who they are. While it’s good practice to design a site that is usable by all, not just your exact target audience, there are exceptions.

It is unwise to test with users who have radically different experiences of the web. You should also be aware of any accessibility needs your audience have that could affect how they use your site. A good example of this is a website aimed at the elderly. This audience have physical conditions that may affect their use of a site and generally don’t have as much experience using the web. You would therefore probably not want to test exclusively with 20 something technology geeks!

Running an Effective Test Session

Running your first usability session can be intimidating, especially if you have never even seen one. You probably have questions about where to run the session, what you are supposed to do and what kind of things to cover.
In actual fact running a test session is remarkably straightforward and can be done by almost anyone.

There are three simple principles you can use:

• Be prepared
• Understand the role of the facilitator
• Work from a script

Be Prepared
It is possible to do usability testing with no preparation whatsoever using the cubicle test I mentioned earlier. However, if you want to run something more formal a little preparation goes a long way. Before you can begin recruiting answer two basic questions. Where and when are you going to test?

Where and when?
If can easily visit your testers, then you may wish to test where they normally access the web. This provides two advantages. First, they are more relaxed because they are in their own surroundings. Second, you are seeing them in their ‘native environment’ which is more realistic. However doing this is not always practical. The alternative is to ask your tester to come to a central location. This does not need to be anywhere sophisticated. It can be even be done at your own desk. The most important requirement of the test environment is that it is quiet and you will not be disturbed. Although a constantly ringing phone maybe realistic it does not aid successful user testing!

Once you know where you are going to test, draw up a schedule. Try to schedule all of your sessions on a single day. Each session should last a maximum of 40 minutes as people struggle to concentrate for longer. Place each session one hour apart. This give you opportunity for additional notes and preparing for the next session. It also allows time for users who have a lot to share or struggle with their tasks.

Always expect at least one person to drop out. In my experience somebody will always be too busy or sick to attend. Have a backup available to step in at the last minute. Even if this is a colleague who is not involved in the project. It is better than nothing.

Who Runs the Test?
The person responsible for running a usability test session is known as the facilitator. Unless you are using an expert, this role will probably fall to you. However, are you the best person to carry out the testing? Is there somebody you could use instead?

The problem may be that you are close to the project. You understand how the site works and could be tempted to guide users in the right direction. You are emotionally invested in the project and it is hard for you to remain impartial. A good facilitator should always remain calm. He or she needs to be patient and a good listener, capable of drawing opinions from others.

Unfortunately, not everybody is capable of that. I myself make a terrible facilitator. I talk far too much and get frustrated when users fail to ‘get it.’ Ask yourself, are you the right person for the job and if not who is?

The Facilitator’s Responsibilities
Whoever your facilitator is they need to understand the role. The position has three responsibilities.

1. To encourage the tester to communicate. Many users sit in silence struggling with a site unless encouraged to speak. The facilitator should challenge users to think aloud. Ask open ended questions that cannot be answered with yes or no. Constantly ask what they are thinking and question their choices. A facilitator should always be calm, patient and a
   good listener.
2. To Intervene When Necessary.
   There is a perception that the facilitator should never intervene to help a struggling tester. However, this is ultimately counter-productive. If a user becomes completely stuck, show them how to continue. This provides an opportunity to discuss why the way forward was not obvious and allows a chance to discover other issues deeper in the site.
3. To Lead the Tester Through the Usability Script.
   It always pays to prepare a usability script beforehand. This outlines what you intend to cover. It is the role of the facilitator to guide the tester through this script.

Work from a Script

The answer of what goes into a usability script largely depends on what you are testing. If it is a design concept then your testing will be limited to questions about the navigation and communication of core messages. You could also carry out some flash testing (as
discussed in chapter 4) but beyond that your options are limited. However, testing against a wireframe or early versions of the site allows users to complete key tasks. For example, users could be asked to find the price of a particular product or the
contact details for a key member of staff. The choice of task should be based on activities that your personas would wish to complete. Think back to the persona we created in chapter 2 (Stress free planning). Jane was considering a visit to a health spa. We established that the first two pieces of information Jane wanted was price and availability. Any user testing for the spa should therefore
include tasks to find this information. Although what is tested will vary depending on the project and stage of development, some information that should ways be included. Below are highlights from a fictional transcript demonstrating the information that should always be covered.

Example Script

“Hi Jane. My name is Paul and I am going to be
running our session today. Joining me is Pete. I have
asked him along to take some notes as we talk. I hope
that is okay.”

By introducing yourself and others in the room you help to put the user at ease. Offering coffee can help too! Be sure to explain any recording equipment as this can also be intimidating.

“We are here to improve a website that is currently under development. You are going to help us test the site. Its important you understand, we are testing the site and not you. So you can relax!”

By explaining to the user that you are testing the site and not them, they will behave more naturally.

“You do not need to worry about messing up. There are no right or wrong answers in a usability test. What we do need is complete honesty. If you are
struggling with something or do not like the way it works, say so. You aren’t going to offend anybody.”

If the user perceives the session as a test
with right and wrong answers, they will tell you what they think is correct rather than what they feel.

“The most important thing to remember is that we need you to explain what you are thinking. Think out loud and talk about the options you are considering. Before you click on a link explain what other options you considered and why you picked that one.”

Getting the user to articulate their thoughts is fundamental to the success of the session. This cannot be stressed enough. Even though you explain the need up front, you will still need to prompt the user throughout the session.

“Finally, if you have any questions please feel free to ask. I might not be able to answer them straight away as I could prejudice the testing. However, I will answer them at the end.”

It is important to explain before you begin why you may not answer their questions during the session. However, if they do ask questions be sure to address them at the end.

“Let’s start off with something easy. Can you tell me a bit about yourself? Tell me about your job? Begin a session with simple questions such as family status, age and job title.”

This helps build the users confidence and provides some useful background information.

“Tell me a bit about your computer experience. How confident do you feel using a PC? Do you use them for work? What about at home? How much do you use the internet? What kind of sites do you use most and find useful?”

Building up an understanding of the users computer and web experience is useful context for the session. It also indicates how representative they are of the target audience.

“Lets talk about the site. It is for a health spa. Before I show it I want to ask about your expectations. What do you think a health spa website should look like and what information would it contain?”

It is often helpful before showing a site to users to ask them about their expectations. If the expectations do not meet the reality it can cause confusion. Also it provides the opportunity to find out more about what users want from the site.

After this generic introduction the session would become more specific. The choice of direction is dependent on the material available to test against and the type of site. However this specific testing should either fall into the category of ‘do they understand what they are seeing’ or task completion.

This extract is taken from Website Owner’s Manual, written by Paul Boag and published by Manning Publications.

Vitamin readers can enjoy 40% off the full price of the book until April 1st 2009. Just use the code ‘thivita40′.

Main image courtesy of (nz)dave.

Many think of a content management system as a magic bullet that solves all of their content woes. Unfortunately the cost of a CMS is greater than its price tag. Before making a decision about whether to adopt a CMS, or indeed which CMS to choose, you first need to be aware of the hidden costs. These include:

1. The cost of training
2. The cost to quality
3. The cost to functionality
4. The cost of redundancy and flexibility
5. The cost of commitment

It is important that you understand the impact of each beginning with the cost of training.

The cost of training

Probably the most obvious hidden cost is that of training. No matter how well designed the application or how good the documentation, some level of training is normally required. In my experience training is particularly important with free open source systems. These tend to have less documentation and the interface is often designed by programmers rather than user experience experts. The result is a great learning curve.

The more content production is delegated, the more people it is necessary to train. Whether this is done through onsite training or video tutorials it is still a considerable cost.

Although training maybe an obvious expense it is not without surprises. Organisations often fail to consider that training has an ongoing cost. The more people using a system the higher the likelihood somebody will need to be replaced. This carries with it a cost in both time and money.

This ongoing cost is not limited to training new CMS users. Existing content provider also require refresher courses if they are not using the CMS regularly. I have often provided training for an organisation only to receive a call six months later because people have forgotten how to login. This is because they used the system so infrequently.

Unfortunately the price of having a lot of people editing your site is the cost of increased training. However, that is not the only cost that grows with numbers. So does the cost to quality.

The cost to quality

In some ways, what a CMS gives with one hand it takes away with the other. Quality and control are classic examples of this. Enterprise level content management systems have complex workflow tools that prevent new content from going live until it has been checked and double checked. This is designed specifically to ensure the quality of content being posted online.

The problem with this is two fold. First, this kind of functionality is only normally found in more expensive systems. Second, few organisations implement this kind of quality control because it creates a bottleneck in the approval process. This bottleneck is precisely the kind of problem a CMS was supposed to solve.

I think this highlights a substantial problem with content management systems. They are often implemented in the hope they will solve what is an organizational rather than technical problem. Unfortunately technology cannot solve everything.

At one extreme you can open up your CMS to allow anybody to post to your site. This will lead to a decline in the quality of your content. On the other you can limit access and create a bottleneck where only one or two individuals can make content live. The technology can offer you lots of options along that sliding scale. What you need to do is find a happy medium.

Of course, at least a CMS offers this control. That is more than an HTML driven website can. However, a non CMS driven site does allow more flexibility when it comes to functionality.

The cost to functionality

When you have a website that is not built on a CMS the possibilities are endless. Because you have complete control over your code, it is possible to build any additional functionality you require. However, once you commit to a content management system things become more complex.

Although it is possible to build additional functionality that sits alongside your CMS there can be problems with integration. For example, if your CMS does not have a forum and you wish to add one, you may have to ask users to login twice. Once for the site and once for the forum. Equally you may find it hard to tie your CMS in with other systems that you later purchase.

Some content management systems provide plugins to add additional functionality. However, often you are forced to either compromise or wait until the next release of the CMS and hope it supports your requirements.

Although you may find yourself frustrated by a lack of functionality, it is equally possible to be frustrated by too much.

The cost of redundancy and complexity

Unless you have a bespoke content management system, developed to your exact requirements it will probably contain functionality you do not need. That is because off the shelf solutions are designed to appeal to a wide audience.

Not only does this mean you pay for unwanted functionality, it also adds complexity to the user interface. The more functionality, the more complexity, the more to learn.

It is a problem that applications such as Microsoft Word have suffered from for years. Word is very powerful and provides an enormous range of features. The problem is that the majority of people only use a fraction of what is available. The result is that most pay for functionality they do not use, and struggle to learn what is a complex application. This is the problem many content management systems are facing.

The reason people have not stopped using Word and move instead to something simpler, is that they are invested both financially and in time. This brings us to the final drawback of content management systems.

The cost of commitment

Content management systems demand a high level of commitment on many fronts. These include:

• The upfront financial investment in implementing the system
• The cost and time involved in training staff
• The substantial amount of data entered into the system

The third area can be particularly tricky. Once your content is in a content management system it is not always a simple matter to get it out.

With such an investment in both time and money it is important to make the right selection of system. Changing your mind later is expensive.

So am I suggesting you should avoid content management systems entirely? Not at all. The benefits they provide are real and cannot be ignored. However, I am saying that you should go into the process of selecting a content management system with your eyes wide open. A content management system is not a magic bullet that solves all your content woes. However, it can be a useful tool if selected carefully.

This desire to display everything on the homepage is born out of a perception that it is the most valuable real estate on a site. A perception perpetuated by the numerous design galleries, books and other media that always show screenshots of the homepage, rather than the numerous other pages on a site. This can lead to individuals and departments within an organization fighting to ensure their interests are represented on the homepage.

Unfortunately, in this fight for the spotlight, usability and design aesthetics are often the first causalities.

In this article I’ll explain 4 techniques which I have used to bring some sanity back to the process of homepage design. These techniques are not clever tricks to get the client to see things your way. Rather, they are about educating the client in order to allow him or her to make more informed decisions. They may still make choices you do not like but at least those choices will be made from a place of knowledge rather than ignorance and misconception.

The changing role of the homepage

The first step to homepage utopia is to help those with a vested interest to recognize its true value, rather than the current misconception they have of it.

The reality is that the role of the homepage is changing. It has long since ceased to be the primary point through which people enter a site.

Jakob Nielsen recently wrote the following in his book “Prioritizing Web Usability”:

Despite the importance of the homepage, however, interior pages accounted for 60 percent of the initial page views. A Web site is like a house with a thousand doors, and visitors can enter anywhere.

Users are relying increasingly on search engines to find the content that they are looking for. As a result they are much less likely to enter a site through the homepage.

I believe that the figure of 60 percent will continue to increase over the coming years. And it won’t just be search engines that cause this to happen, RSS feeds will have a significant impact too. As RSS becomes mainstream we will see an increase in users clicking directly through to relevant content, bypassing the homepage altogether.

That is not to say the homepage is unimportant. It continues to be a navigational tool enabling users to orientate themselves and helping them establish if a site has the content they are looking for. Every good web designer knows that the homepage should allow quick access to killer applications, search, site map and other relevant shortcuts. But it should also help the user orientate himself by confirming he is on the right site to meet his needs.

A good example of this approach is the current Apple website. Internal politics do not rule here. The homepage is not shared out among the various departments. Before last week it was completely dominated by the iPhone and now its all iMac. Apple knows that the majority of users currently coming to the site are after information on their latest announcement and so they make sure the latest “killer app” is front and center — literally. Users are left in no doubt that they have found what they are looking for and know exactly what to do next.

The perception that the majority of users never progress beyond the homepage is unfounded and the current competition for homepage space is unjustified. Just as many users will have searched for iMac on Google and come directly to the iMac section as will have entered via the homepage. That is why the iMac section stands very much on its own, making complete sense even without the broader context of the site.

Do not rush into the homepage

It seems to have become standard operating procedure for us as web designers to start look and feel development with the homepage. But starting with the homepage might not be the wisest move. Instead consider beginning the design process by developing lower level pages such as a standard text page. Not only do these account for 60 percent of initial page views they also make up the majority of pages on the site. And, more importantly, they don’t attract the same degree of opinions as the homepage.

By starting with a standard text page you have the opportunity to establish the design style, usability and accessibility of a site before it gets diluted by the land grab for homepage real estate.

If you work with the client to establish the look and feel of a site on a lower level page then they will be invested in the design. If they feel a sense of commitment to the design they will perceive it as more important and so are less likely to allow it to be railroaded by other content demands when the homepage is finally tackled.

Delaying the home page development isn’t just a “strategic” move — it is also the right thing to do. A home page should reflect the sites content at the highest level and signpost the user to key content deeper in the site. In my experience, the client often hasn’ t finalized all of the content in the initial design stage. It is hard to create an effective home page until you have a full understanding of what content it is meant to signpost and represent.

White space: The heart of the problem

When you do finally come to developing the homepage make sure you clearly communicate the importance and role of white space.

As designers we all know how important white space is and yet we are often extremely bad at explaining this in language that resonates with our clients. Comments like “it just looks better” or “everybody knows white space is important” do not help our cause.

So how do we explain white space to a client? I believe the answer is not in expounding its virtues, but rather in explaining the impact of too much being added to a page.

In his book “The Laws of Simplicity” John Maeda writes:

The opportunity lost by increasing the amount of blank space is gained back with enhanced attention on what remains.

Or to say it another way: the more you add, the more you detract from what is there. I think this should be the key to our approach when explaining white space to clients. Instead of selling white space on the fact that it looks better we should be selling it by pointing out that every element added to a page detracts from the rest.

To help the client grasp this concept I would like to propose an exercise you can complete with them.

Start by helping them list all of the elements they would like to see included on the homepage. Keep it simple and ignore standard navigations elements like the menu bar, site tools and search box. There is rarely debate about the importance of these elements so nothing is added by including them in the exercise.

Once you have completed the list, the next step is to assign values to each item. The value assigned equates to the amount of attention the client would like the user to pay to a particular item. Since a user only has a finite amount of attention to give we must therefore assign the client with a finite number of points to distribute among the items. Each item on the page has to be assigned at least 1 point — although if the client wishes to give more emphasis to a particular element they can assign it more points.

The number of points you give the client is entirely up to you — although I’ve found that 15 works well on average. If the client has specifically asked for a clean design then give him less. If he wants something busy and dynamic give him more.

What is important is what it teaches the client. He will quickly realize that the more elements he adds to the design the less he can emphasis any individual item and the less impact they have. Consequently, the fewer elements he adds the more impact they will have and so, indirectly, he will learn the value of white space.

There is no fold

The problem of white space is made worse by a client’s perception that users do not scroll. This misplaced belief means that they often insist that most, if not all, of the content on the homepage sits above this mythical line called the fold.

I refer to it as a mythical line because that is exactly what it is. It is a term borrowed from the newspaper industry and yet the analogy quickly breaks down. A newspaper fold comes at a specific point while on the web the point at which the user begins to scroll varies based on browser, resolution, window size and number of toolbars. But mythical or not, many clients are obsessed by it.

My final technique for bringing sanity to homepage design is to release the client from the constraints of the fold by convincing them that users do in fact scroll. In order to do this we need to understand where this myth originates.

It would seem that the idea comes from the very early days of the web, when users were unfamiliar with its conventions. I suspect this perception has primarily come from the early reports of Jakob Nielsen. However, this is unfair, because by 1997 he was already saying that things had changed. What is more, a recent report seems to indicate that over three quarters of users will scroll a page at least to some extent, with 22 percent scrolling all the way to the bottom. While 22 percent may seem low, the report actually suggests it is quite high. It argues that the results are distorted by repeat visitors who would have previously already scrolled all the way to the page bottom and be familiar with its content.

By demonstrating through up-to-date research that the scroll does not need to be feared, the homepage can both maintain its design aesthetics and handle additional content. Another area of conflict is resolved.

In conclusion

The bottom line is that we need to take the time to educate our clients. We need to explain how the role of the homepage is changing, demonstrate the value of white space and dispel the myths surrounding scrolling. We also need to pick our moment, knowing when best to tackle the subject of homepage design.

However education is not always easy because we need to be educating not just our point of contact, but also other stakeholders in the organization who are fighting over a place on the homepage. Getting access to these people can be more challenging.

How you decide to tackle this problem is entirely up to you. One approach I find very effective is the stakeholder workshops proposed by Shane Diffily in his recent A List Apart article “Educate Your Stakeholders”.

If you would like to learn more about effective homepage design I would recommend reading anything on the subject by Jakob Nielsen. His book “Homepage Usability” is excellent as well as various articles he has written. Finally, Derek Powazek has written an excellent article that mirrors much of my thinking on what every homepage should contain.

A Clash Of Culture

There is a very real divide between clients and web designers that seriously undermines many web projects. Moreover, the frustration is felt on both sides of the fence with many clients perceiving the web design community as “not living in the real world” and obsessed with technology for technology’s sake. They might also believe that they are being asked to pay for things that they don’t need.

At the heart of the problem lies a failure to communicate effectively. It is almost as if the two sides are speaking completely different languages. The aim of this article is to help you learn the language of clients and to be able to bridge that cultural divide, meaning a healthier working relationship and the business benefits that brings.

The Language Barrier

I am British and we Brits have a terrible reputation abroad. When we meet somebody who doesn’t speak English we tend to think they are stupid. We speak slower and louder in the hope they will understand us, when the reality is that they probably speak multiple languages and are far more intelligent than us.

We are often like this as web designers. Just because clients don’t know their XML from their CSS we presume they are stupid and start speaking slower and louder. The truth is they are often very savvy business people who have expertise of their own (just in very different areas).

The reason we find ourselves in conflict with our clients is because we make little or no effort to either understand their “culture” or “speak their language”. If we wish to convince them of the value of accessibility, standards or any other best practice technique, we need to learn to present it in a language they can relate to.

Return On Investment

Every culture has its defining characteristics. Understanding those characteristics and tapping into them is what allows you to really be accepted. Clients are no exception. At the core of their world view is return on investment (ROI). If we speak the language of ROI we will quickly find clients much more amenable.

Saying that the culture of clients is built on ROI does not mean they are solely concerned with making money. After all we know that not every website is directly about generating income. However, all clients desire to see some form of return on investment for splashing out the cash on their site. That return could come in many different forms depending on the type of site. While an ecommerce site is going to look for increased sales, a service-based company may focus on more enquiries. A charity website might want more volunteers while a government site might desire to educate or inform. Whatever the case the client will be constantly asking how any decision related to the site helps increase that return.

Let me give an example of where things can go wrong. If you read this website the chances are you are passionate about web standards. As web designers we are often put in the position of justifying our desire to implement web standards and it can be frustrating when clients fail to grasp the benefits. After all they seem so obvious to us:

• Separation of design from content makes a site easier to manage
• Semantic code makes it easier to read and interpret
• Standards make it easier to comply with accessibility guidelines.

The list could go on. However, unless properly presented, none of those reasons will resonate with a client. They are about making your life easier as a developer not about increasing ROI.

With a little “translation” the same arguments outlined above can be made more client friendly by focusing on their return for investment:

• Standards-based design will significantly reduce the ongoing development costs associated with your site.
• Web standards will make your site more search engine friendly so driving more potential customers to your site.
• A standards-based approach will ensure that as many people as possible have access to the products and services you offer.

When you are pitching to a prospective client, or even working with past customers, it will pay dividends to do as much homework about the client’s objectives, their target market and their business model. Then you can deliver the right solutions, framed in the right language that will really resonate with them. It also means of course, that the solution you put together is the best it can be, which will pay for itself when happy customers recommend you to their friends and associates.

Margin Of Return

Just because a technology or technique can provide a return on investment doesn’t mean it is justifiable from a client’s perspective. A client isn’t just concerned with whether it provides a return; they are also concerned with the margin of return.

A good example of the “margin mentality” is AJAX. The whole web design community is excited about AJAX at the moment. It can provide improved usability, a richer user experience and is basically damn sexy! From a client’s perspective AJAX offers return on investment in the form of increased customer satisfaction and repeat traffic. However, AJAX isn’t always quick to implement and that can damage the margins of return.

I was recently working on an ecommerce website aimed at an elderly audience. Although the site was generally very successful we were suffering from a significant dropout rate when registering address details. Usability testing revealed that users where confused by the address fields which required them to enter information onto multiple lines. Unfortunately we were unable to simplify the form and so decided to solve the problem using an AJAX postcode lookup. We then carried out a second round of testing and found that the new approach worked extremely well. Users found it much more intuitive and it successfully helped them complete the registration form. However, one user commented that an even easier approach would have been to simply add an example address next to each field showing what the user was expected to enter. Such an approach would have achieved the same aim as the AJAX solution but could have been implemented in a matter of minutes.

The problem is that, as developers, we are often drawn to complexity. We love technology and enjoy developing complex technical solutions. The downside of this is that complexity can be expensive. A client wants to achieve his aims for the smallest investment possible and so maximise his return. In the registration example above it was much more cost effective to implement the example text than it is to develop a sophisticated AJAX lookup system. So not only do we need to be considering return on investment when proposing a development solution, we also need to be looking for an approach that maximises the return.

Success Criteria

Even if we are thinking in terms of return on investment, that doesn’t automatically mean the client will see things the same way we do. As I said earlier it is important to understand what forms of return are important to an individual client. For some the cost of development might not be as important as speed of delivery. Others might be more interested in seeing increases in traffic even if conversion is low. That is why it is important to discuss what the client’s expectations are up front. The most common way of achieving this is to agree on success criteria for the project before work commences.

Clearly documenting a project’s success criteria right at the start not only improves communication between designer and client it also helps manage expectation and focuses the client’s mind on exactly what they want their site to do. Too many projects suffer from scope creep partly because the client doesn’t have a clear vision of what they are ultimately trying to achieve. Without that clear objective clients can often move the goalposts on a project as they gain a greater understanding of what is achievable.

The process of deciding on success criteria should be a joint venture between designer and client. This ensures that all parties are committed to the objectives and that they are realistic. Too often clients set unrealistic expectations on a project because they have no frame of reference as to what is possible. It is your job as the designer to provide that frame of reference to help them strike the right balance. Of course as with everything they will want to maximise their return and so you will need to clearly explaining the constraints you face in a language they can understand.

Not only should the success criteria be realistic, they should also be specific and where possible measurable. A desire to improve usability or increase sales does not constitute success criteria, rather these are broad objectives. The problem is that the designer’s perception of improved usability may well be different from that of the clients. Instead, try setting specific objectives such as a percentage increase in users reaching a certain call to action or key page. This will gives the client something tangible against which to judge the various development decisions being made. For example, if five hours of development work will be required to implement an approach that satisfies one of the success criteria, then the client can judge whether the return on investment is worthwhile.

It’s The Thought That Counts

Of course the reality of working on projects isn’t as black and white as I have outlined above. Sometimes it can be hard to quantify the return of a particular approach and even the best predictions can be wrong. However, it is the mindset that is important not the specifics of the implementation. We as designers and developers have to stop seeing our clients as the bane of our existence and start trying to understand what motivates them. We pride ourselves on being user centric designers however I would dare to argue that first and foremost we should be business centric designers. I believe that our primary role is to meet the needs of the businesses that commission us and that in order to achieve this we need to understand their aims and objectives.