Avoid internal/technical language

Think carefully about the language you’re using on your form. You should adopt your user’s vocabulary instead of using any technical or industry terms. Here’s an example below from FreeAgent (a web-based accounting application).

When asking for your payment details, FreeAgent asks for your Card Verification Value. This means nothing to a lot of people. In banking it’s called a Card Verification Value or CVV number. To us normal people, it’s that 3-digit code on the back of our credit or debit card. This label might be a little clearer if it were called “3-digit security code”.

In this instance there are a couple of things that FreeAgent does to remedy the situation. By sizing the text field appropriately, many people will know what’s being asked for. They are now used to providing a 3-digit security number. Some will be happy to assume that this is what the text field is for.

We’ll talk about the other remedy a little later.

Intelligent reformatting

Your internal systems may insist on the strict formatting of some data, but this shouldn’t impact the customer. It’s your job to deal with that, not theirs.

I’ll use an example to demonstrate. When booking a flight with EasyJet, I’m asked for the payment details below. No formatting rules are specified for the card number.

Like many other people, I type in my card number as it appears on the card. The number on my card has spaces that separate the number into groups of four digits. But if I type in my number in this way, EasyJet doesn’t like it.

This is lazy programming. If the spaces can be detected by the form, then they can also be removed by the form. EasyJet should just remove the spaces for me, instead of asking me to go back and fix the problem. Don’t they want my money?

Also, see my post on validating web forms and read why JavaScript alerts are a poor mechanism for form validation.

Only ask for the information you need

Every question you ask on a form is an opportunity for something to go wrong. This is just one of the reasons to only ask for the information you need. You don’t want users dwelling on questions that don’t matter. So don’t ask them in the first place.

I recently wrote a blog post about asking people marketing questions that is related to this point.

Asking inappropriate questions can also create issues with trust. If you ask for information that users don’t want to give you, they may begin to mistrust your motives. When they begin to get suspicious of you they may abort the form completely.

Optional and required fields.

Don’t use the word ‘mandatory’ when talking to users. We say ‘mandatory fields’ because we’re geeky web types. Real people don’t. Use the word ‘required’ if you want them to know what you’re talking about.

There are 2 approaches you can take to displaying required fields.

• All fields are required unless marked as optional
• All required fields are indicated (often with a red star)

If you choose the 2nd option, the placing of the red star is very important. When people fill out web forms, they tend to look only at the questions and then the form fields. So if your star is not in the path of that eye movement, it could easily be ignored.

The three examples pictured below show a red star that is positioned in the path the user’s eye will take when reading and completing the form. So it is likely that users will notice its presence.

Good examples

The example below shows an approach where the red star is more likely to be overlooked than in previous examples. This is because the user has no reason to look there.

Bad example

Think before validating optional fields

In most cases, it’s better not to bother adding validation to optional fields. But sometimes you’ll find that it’s necessary.

It’s often better to accept that the data from optional fields will be more prone to errors. The alternative is to validate these fields and introduce the possibility of added friction to the process of completing the form.

If you’re prepared to accept no response to a question then consider also accepting an incorrect response.

Providing hints

It’s often helpful to provide little hints with some questions in order to ease understanding. Let’s go back to FreeAgent’s ‘Card Verification Value’  and see how they manage to resolve the problems that may arise from their choice of labelling.

Despite the fact that Card Verification Value means nothing to the average person, FreeAgent helps to resolve  problems by providing some additional info.

Notice that this hint isn’t hidden behind a question mark link. The advice is short, so there’s no need to hide it. Strictly speaking, this solution would be unnecessary if they’d chosen better labelling in the first place. When using this type of approach, it’s important to consider the flow of the form.

Inline validation

Validating the form while the user enters information is called ‘inline validation’. It can be a good way of helping users through a form in a less obstructive way than validating all of the answers at the end (when the user clicks submit).

However, you usually don’t need to use inline validation on every question. Inline validation can be troublesome if it isn’t implemented well. Luckily Luke Wroblewski wrote an interesting article about inline validation that saves me the bother of having to do it here.

Was this blog post useful?

If you found this useful, here’s a few things you can do:

• Read more posts on my blog
• Donate to my chosen charity
• Hire me to help you improve your website
• Follow me on Twitter
• Join the discussion by commenting below

In this post I’m going to tell you about a time when I got it wrong because I didn’t consider the flow properly.

Once upon a time…

Several years ago I was testing a web form for an event management system. Employees would use the form to confirm their attendance and notify the organisers of any dietary requirements they had and stuff like that.

There were many problems with the form but one of them was to do with reference numbers. An optional field for a reference number (referred to as the invite number I think) was causing  some problems. I can’t remember the exact details, but the question was something like the one I’ve mocked up below.

People who didn’t have an invite stalled here. Without an invite, they didn’t yet have an invite number. They could have left the field blank but many people felt uncomfortable doing so. It seemed that because the question was being asked, they thought they should have a number.

The solution

The solution the team arrived at was to put a checkbox directly below the field as shown below. It’s wasn’t my suggested approach, but it worked well in usability testing. The proximity of the checkbox to the textbox created an association that resolved the problem. Users felt happy to leave the textbox blank because they’d checked the box. They were typically delayed for less than a second while they worked this out.

I was impressed with how well this solution worked and have remembered it ever since. What I didn’t really consider was how it flowed. I just remembered that its presence gave the user permission to leave the textbox blank.

Until a few months ago…

I remembered this approach when I was advising a client a few months ago and suggested they incorporate it into one of their forms. They had two mandatory fields on one of their form. One for daytime phone number and one for an evening number (see below).

I was concerned that some people wouldn’t realise that they could put the same number in twice. So I suggested adding a check box under the evening phone number, in order to give them permission to do so. (see below).

As well as allowing permission to use the same number twice, the checkbox was supposed to save the effort of typing it a second time. If they checked the box, it would populate the evening number field with the daytime number.

In testing, nobody had a problem entering the same number twice. But everyone who did so, typed the number twice (or copied and pasted it) before noticing the check box. The form didn’t flow properly. The check box became noticeable only after it would have been useful. It didn’t cause a major problem but people realised they could’ve saved themselves some effort.

How are the two solutions different?

So why did the solution work so well for invite reference numbers, but not for phone numbers? It’s to do with the way the forms flow.

People complete forms one question at a time and their gaze doesn’t stray far from the questions and the left-hand side of the text box.

When the answer to a question is easy, they’ll just type in the answer without considering anything else on the form. This is what was happening with the field for evening phone number. They are only likely to notice things underneath the text box after they’ve finished typing a response.

But when the form asks a difficult question, they need to stop and think. The smooth flow is interrupted and they are more likely to notice things that are placed after the text box. This is what happened when people were asked for an invite number they didn’t have.

Improving both examples

Invite number

The original solution for the invite number worked very well in usability testing. So in practice I wouldn’t change it (If it ain’t broke…). However in theory the flow can be improved by adding to the question. You probably realised this yourself.

In this example, the fact that not everyone needs and invite number is communicated alongside the field label.  There’s no need to interrupt the flow. People without an invite number will simply leave it blank and go to the next question.

Evening phone number

The pictured example below shows how the user can be given ‘permission’ to enter the same number twice whilst only typing it once. Instead of placing a checkbox underneath the field for evening number, it is placed underneath the one for daytime phone number. The label on the checkbox has changed to ‘This is also my evening number’. Checking the box pre-populates the field for the evening number.

The checkbox now works in harmony with the flow of the form. Users type their daytime phone number before they see the checkbox. If their daytime number is also their evening number, then they simply check it in order to prepopulate the following textbox.

Conversation

The flow of your form is part of what Caroline Jarrett refers to as the ‘conversation’ your form has with the user. When you have a conversation with someone, that conversation has a flow. When you ask someone a question you tend to pause and wait for an answer. Think of a form field as that pause in the conversation.

When you ask someone an easy question, they will probably start answering before you’ve even finished asking. But when the question is more difficult, you can follow the question up with clarification if it’s needed.

Was this blog post useful?

If you found this useful, here’s a few things you can do:

• Read more posts on my blog
• Donate to my chosen charity
• Hire me to help you improve your website
• Follow me on Twitter
• Join the discussion by commenting below

But asking this will cost you in lost conversions and the data you gather is probably inaccurate. In this post I explain why you should avoid asking people how they heard about you on your web forms.

Added friction

It might seem like a harmless question. But there’s no such thing as a harmless question when you want people to complete your form.

The fewer questions you ask on a form, the greater the number of people will complete it. So each question you ask has a cost that it must justify. That cost is the number of people who drop out because of its inclusion.

This isn’t because your users say “Oh, I’m not answering that” and leave. Instead adding friction to a process increases the likelihood that users don’t get to the end of it.

We are are so often distracted by something else when using the internet. We’re also quite often limited by time, so it’s easy to decide to postpone the form until later when we think we don’t have time to complete it now.

By removing points of friction, you increase the likelihood that users will get through the form without interruption.

Inaccurate data

When people are completing your form, they’re happy to answer questions they feel are necessary to ask. When they’re buying something, they’ll tell you their address because you need to know it in order to make delivery. But when you ask a question that isn’t related to their request, you risk annoying them.

The accuracy of a customer’s response to this question has no impact on them personally. If they answer incorrectly, they still get what they came for. So if you’ve annoyed them, they may deliberately give you an incorrect response.  Even if you haven’t, they’ll often just pick an option at random.

You’re relying on goodwill in order to get a correct response. But you’re also testing their patience by asking the question in the first place. This puts goodwill in short supply.

Sometimes it’s just a silly question

When you have a strong brand in your industry, it’s a bit silly to ask people where they heard of you. It’s like me asking you where you heard about Coca-Cola before you bought it.

People often engage with companies having never heard of them. But most of the time they buy from or contact companies they’ve heard of through multiple channels. This makes the question very difficult to answer. When the question is difficult to answer, you’re making them think. And what does Steve Krug tell us about making users think?

You’re adding potential complications that are avoidable.

What are you doing with the answers?

When you ask this question, what are you doing with the answers? How valuable is this data to your organisation? I know several companies who ask this question and do nothing with the data they collect. They don’t realise that this data comes at a cost. If they could truly see the cost, they’d probably stop asking the question at all.

Even if you are looking at the data. How is it driving your decision making? Are you just looking at it and saying “Oh that’s interesting”? Interesting is good, but remember this question is costing you money. Is the information so interesting that you’re willing to pay for it in lost sales?

Conclusion

It’s useful to know which of your marketing efforts are leading to conversions and there are ways of obtaining this information. But asking your users when they’re trying to get through a web form isn’t the way to do it.

You can’t rely on the accuracy of the data and it’s costing you in lost conversions.

What do you think?

Do you agree? Or am I talking nonsense? Tell me what you think by adding a comment below. You can also read other articles from my blog. Here are a few suggestions:

• What difference does colour make?
• 10 tips for writing 10 tips articles
• Using address finders in web forms

I couldn’t tell a 16th century building from an 18th century one. The High Street in my home town is full of old buildings, so I couldn’t even guess.

After I’d recovered from laughing, she grudgingly explained that it was across the road from the Post Office. This was a little more helpful.

My mum often explains things in a way that only she sees them. She’s a historian, so this can include giving directions that you need an interest in period architecture to understand.

So what’s this got to do with websites?

Lots of organisations are like her. They are so engrossed in what they do, that they speak in a way that is confusing to others. Unfortunately this tends to include their customers.

Such organisations usually reflect this on their website. They tend to:

• use vocabulary that customers don’t understand
• organise information the way they see it and not how the customer does
• swamp their site with content that few people want or need
• fail to provide the content that people do need

These failings drastically affect how useful and easy-to-use the website will be.

An example – National Grid UK

Let’s use a scenario to explore this further.

Brendan is a local café owner who is losing business because of road works outside his premises being carried out by National Grid. This is a scenario a café owner told me about when I was buying lunch. I’ve changed the café owner’s name as well as the actual website involved.

Brendan wants to find out how long the works are going to take and whether he’s entitled to any compensation for loss of business. His options from the National Grid homepage are shown below.

The structure of this website is relatively organisation-centric rather than customer-centric. There isn’t a section for road works at the top level. Instead Brendan must first understand which department is carrying out the works. Brendan doesn’t care how the National Grid organises itself, he doesn’t care why they are digging up the road. He just wants to know when the work will be finished and whether he’ll be compensated for loss of business.

Road works for gas pipes are the same as road works for electricity as far as he is concerned. They both involve a big hole in the road and fewer people entering his café.

Let’s skip past a lot of Brendan’s pain and assume he eventually opts for the Gas section of the website. Here are his next options.

Again National Grid organises its content in an organisation-centric manner. This time the road works information is hidden under ‘Pipeline Projects’. National Grid sees its hole in the road as a pipeline project, the public (including Brendan) see it as road works.

This is like my mum saying “in the 16th century building” when I need her to say “across from the Post Office”. National Grid is talking from its own perspective rather than Brendan’s. As a result, Brendan can’t find what he’s looking for.

If Brendan eventually selects the links he needs, the next choice gets a little easier. Streetworks is a decent link title, but when he clicks it, he sees the page below.

This page is full of information that consumers don’t care about. National Grid care about how they scored in the recent Transport Research Laboratory report, but Brendan doesn’t. He just wants people to come and buy their lunch in his café. This page should be a pathway page to the useful content that exists deeper within the section.

Imagine you pulled up in your car to ask a man for directions. Instead of just telling you where you need to go, the man starts a lengthy explanation of the history and culture of the town you’re in. Do you care? No, you just want him to shut up and tell you where you need to go. The page shown above is that man.

The site doesn’t actually have any information about the timescales of its projects, so Brendan is out of luck. National Grid are too busy harping on about the stuff they’re proud of to give Brendan the information he needs.

Frequently Asked Questions

However, information about compensation does exist. It’s relegated to the bottom of the Frequently Asked Questions page. Here is the relevant question from the FAQ page.

Once again National Grid bores Brendan with all the background information before telling him what he needs to know. This is information that National Grid wants to say, but Brendan just wants to know if he’s eligible and how he claims compensation. Much of the rest of this text is wasteful and rather self-indulgent.

Empathy is the key to a better user experience

Unless you’re like my mum, when you’re giving someone directions you tend to stick to the information that person can deal with. You don’t introduce local nuances and you don’t try to show off about your knowledge of the local architecture. In other words you empathise with the person you’re trying to help.

Websites are the same. Your users will enjoy a better experience if your site empathises with their circumstances, knowledge and vocabulary.

What do you think?

Do you agree with me, or am I wrong? Whatever your opinion, post a comment and let’s discuss it.

Good calls-to-action

I recently wrote an article for UX Booth about Good call-to-action buttons. In it I explain that call-to-action buttons are clicked more often when they are made more prominent. Multivariate and split A/B tests have shown this to be the case.

It makes sense too. If you make one button on your page very prominent, you make it easier to notice. When it’s easier to notice, there’s less friction in that user journey. So if that button leads to the next step in your key user journey, then your website should enjoy greater success.

Restrictive colour palettes

Many brands that do business on the web have colour palettes that are restricted to just 1 or 2 colours. Their branding guidelines state that no other colours can be used.

In this article, I’m going to discuss just one example of such a company – the AA.  However there is a long list of companies who have similarly restrictive branding guidelines.

I believe that the AA could achieve a better conversion rate if only it expanded its colour palette to allow the very occasional use of a contrasting colour. I carried out a little experiment to test my theory.

The AA prominence test

I ran a test (using the Five Second Test) to check the visual prominence of the ‘Get a car insurance quote’ button. I tested 3 very similar versions of the AA homepage.

Version 1

Version 1 was the current AA homepage without any tweaks. The ‘quote’ buttons on this page don’t stand out enough. They have been made yellow because no other colour appears to be available for the designer. The buttons blend into the overall design.

Version 1

Version 2

I was worried that the design of the quote buttons wasn’t as clear as it could be. So in Version 2 I made the buttons smaller. I felt they looked more like buttons and less like a border this way. As it happened it didn’t make a difference to the test, but I wanted to be sure.

Version 2

Version 3

Version 3 was similar to Version 2. However unlike the people at the AA, I wasn’t constrained by their branding guidelines. So I changed the colour of one of the buttons and made it a shocking blue colour.

I chose this button because ‘Car insurance’ is in the top-left section and is therefore probably the most important product for the website.

Version 3

How the test works

180 participants were shown 1 of the 3 designs for just 5 seconds. This meant that each version was shown to 60 people.

During the 5 second period, the participants clicked on the page to point out the areas of the design that caught their eye. This test allowed me to find out which areas were visually the most prominent.

The results

Participants in the test clicked on various parts of the page, but the bit I was interested in was the ‘get a quote’ button for car insurance. How much of a difference would a change of colour make? Well, the results were pretty interesting.

15% of participants who saw Version 1 pointed out the quote button for car insurance. As you can see on the image below, the picture of the car was pointed out more often than the button. The red circles on the images below indicate one click from a participant.

Version 1

13% of participants who saw Version 2 pointed out the button. A very similar result to version 1. So I needn’t have worried about the shape of the button as far as the test was concerned.

Version 2

On Version 3, 35% of participants pointed out the button. This is a lot more than Version 1 or 2. In fact, more people pointed out the button in Version 3 than in Version 1 and 2 put together.

Version 3

So what does this all mean?

This test only tells us about visual prominence. It doesn’t mean that the blue button will get twice as many click-throughs as the yellow one. Instead it means that the designers at the AA could make this important button more prominent, if only they had more colours to choose from. And prominence has been shown to have a direct effect on click-through rates.

Restricting your colour palette isn’t just about conversions though. Colour is very useful for creating differentiation in a design. This can be used for creating things like:

• Headings with a clear sense of hierarchy (Heading 1,2,3 etc)
• Hyperlinks that actually look clickable
• Hyperlinked headings that look different from both normal hyperlinks and normal headings
• Bold text that isn’t mistaken for a hyperlink
• Creating clear differentiation between 2 or more page elements

Avoiding issues with these sorts of things helps to improve the overall usability of your website.

I intend to write a follow up post about the Five Second Test that discusses the benefits and limitations of this service.

What d’you think?

What’s your opinion of all this? Whether you agree or disagree, why not share your thoughts by leaving a comment.

If you liked this article, you might also enjoy:

• Let your hyperlinks shine
• Sub-headers are navigation
• Twitter, Tweetdeck and simplicity

Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.

Joel Spolsky

I agree, usability is not everything. But as Joel knows, if usability engineers designed a nightclub they wouldn’t just take their understanding of website usability and apply it to nightclubs.

Instead they would do field research to find out the various things that people do on an evening out. They would observe people in nightclubs and elsewhere to find their goals, behaviour and attitudes. They would try to understand what motivates people to choose night spots and what keeps them coming back.

When they had finished this research, they’d be able to design a nightclub that was a darn sight better than some cheesy chain of theme bars.

Still, it’s a funny quote nonetheless.

It’s not a complete list of advice, so feel free to add your own tips in the comments section.

Tell them something’s wrong

You need to begin by making it obvious that there has been a problem with the form. Often forms just reload with a small message beside the appropriate form field. On a large form this approach isn’t helpful.

If the message is far enough down the page, the user will need to scroll down in order to see it. So they end up staring at the top of the page wondering what has happened.

Don’t blame the user

Don’t accuse your users of having made an error. They may well have done so, but it could just as easily have been your fault.

Telling users they have made an error is like a waiter in an expensive restaurant tutting at the mess, whilst crumbing down your table. It doesn’t help and it doesn’t improve the experience.

Recovering from validation problems

Rather than pointing out the problems with what they did, tell the user what they need to do in order to proceed. For example ‘You didn’t enter a phone number’ should be ‘Please provide your phone number’. This approach is more helpful and focusses on recovering from the issues.

The example above shows a form that is inconsistent in its approach. In most cases it tells the user that they didn’t do something. However sometimes it offers the resolution to the problem instead.

Whilst not perfect, the example above still gives the user a good explanation of the problems.

A worse example is when forms speak to you like a robot. “Email Address is a mandatory field” is not the best way to tell someone that they need to enter an email address. Unfortunately, ‘explanations’ like this are very common.

Don’t use alert boxes

Javascript alert boxes aren’t good for delivering validation messages on forms. The image below illustrates the issue. In order to proceed, the user must click OK. When they do so, the message disappears. So they need to remember the problem or re-submit the form to read the message again.

When a form with JavaScript alert validation encounters multiple issues the experience gets worse. It either lists all of the issues on one alert (that then disappears). Or it pops up with a new alert after the previous issue has been resolved. Both of these approaches have the potential to infuriate people.

Don’t validate optional fields

If the form field is optional, then it’s often best not to add validation.

When the field is optional, you can presumably live without the information. If you can live without the information, then it’s not a good idea to be pedantic about its accuracy. Validating an optional field just increases the potential for complications to arise.

Having said this, there will be occasions when an optional field must be validated. So let’s use a couple of examples.

Phone number

If you’re giving someone the option of providing their phone number, don’t bother validating the field. The number is useful but not essential, so it won’t be a big problem if they type it incorrectly.

Choosing a user name

Let’s say your user is given the option to substitute their real name with a user name. This field would be optional, but you’ll probably need to validate it. You’d need to check that it follows whatever rules you’d created for user names. You’d also need to check that the user name isn’t already in use.

Validation and disabled users

When providing your validation, give a thought to people who perhaps don’t use a mouse or can’t see the page itself. Form validation is a major stumbling block for visually impaired and blind users. This is because some web designers rely solely on visual cues when providing it.

These visual cues are helpful but you can’t rely on visibility alone. The example below shows a good approach that could be made better for keyboard users.

Visually, this seems like a fairly straightforward and helpful approach to form validation. But what about those using a screen reader to read this page?

The descriptions will potentially be quite distant  from the form fields in question (in this example I kept them close in order to fit into the picture). A screen reader user has to navigate down the page using their keyboard and find the form field. They may then need to go back up the page to read the next problem.

This can create a lot of problems for the screen reader user.

How you should do it

OK, I’ve spent enough time complaining about what not to do. I’ll now explain my favoured approach to form validation. This approach helps users of all abilities to quickly diagnose and recover from validation problems.

1. List the problems at the top of the page

Without apportioning blame, explain (in red text) at the top of the page that there was a problem. Then list all of the things the user needs to do before he can proceed.

Make each list item a link to the appropriate form field. This will allow screen reader users to skip straight to the field they need.

2. Repeat the instruction in front of the form field

Put a red-bordered box around the form field and label concerned (or highlight it in some other way) and repeat the advice. Be sure to put the advice before the field (in your HTML) so that a screen reader will read the advice before arriving at the field. You can then use CSS to position it elsewhere if necessary.

What’s so good about this approach?

This approach makes it obvious that there are problems with the form. The user knows how many problems there are and what they need to do to fix them. It also provides features that make it easy for users of all abilities to quickly skip straight to the problem questions.

What about in-line validation?

I haven’t covered in-line validation on this post. I hope to write a second post helping you prevent errors on forms. This post should cover in-line validation.

What do you think?

Join the discussion by posting a comment below. If you’ve enjoyed this post, you might also enjoy:

• Using address finders in web forms
• Good call-to-action buttons
• Sub-headers are navigation

It’s cheaper when customers use the website

If you can replace a customer phone call with a visit to your website, you’re going to save money. In the UK, it’s on average 14 times more expensive to take a phone call compared to having your customer visit your website.

Having said that, your website is just one part of the overall customer experience. Providing a good customer experience involves giving your customers what they want. So when they want your phone number, just give it to them.

We’re getting wise to poor customer service

As customers, we’ve all experienced poor customer service from companies who are trying to keep costs down by ignoring us. So some of us will do a bit of digging before we buy from a company. It’s all very well having your sales number emblazoned on the homepage. But what about the customer service number? What’s it going to be like after I’ve decided to buy?

In usability tests, I’ve noticed some people go digging for the customer service number before buying. Some even say they call these numbers, just to see what the service is going to be like. They also want to know if it’s a freephone or a local rates number.

This behaviour is a reaction to past experiences of poor customer service. The approach you take to being contacted on your website will say a lot about you to prospective customers.

When these people encounter a website that hides its contact details, they know that the customer service will be practically non-existent. So they don’t buy.

Finding contact details

People tend to look for a link that says that ‘Contact us’ when they want to phone or email the company. They’ve become used to the the contact page having this name, so this is what they look for.

This has implications when you provide your telephone number at the top of the page. The example below shows how the Talk Talk website provides its phone number.

I’ve witnessed a lot of people overlooking numbers like this in their search for the word ‘contact’. Of course, other people will notice it quite quickly. So you should never rely on this approach alone. Make sure you also provide a contact page. Thankfully, this is exactly what Talk Talk do.

Avoid the ‘Don’t contact us’ page

The contact page below from Scottish Power is an example of what I call a ‘Don’t contact us’ page. Scottish Power clearly doesn’t want to speak to its customers. We’re shoved towards an online help instead.

This page tells us a lot about the company’s approach to customer service. The link to an email contact opens a 2-page contact form that asks for every possible scrap of information about you that they can think to ask.

Hiding the phone number

A less extreme version of the ‘Don’t contact us’ page is when the contact details are smothered by alternatives to contacting the organisation. Tiscali uses such a tactic, as you can see below.

The ‘Contact us’ page here is swamped with alternatives to calling. If you want to call them, you need to find the ‘Contact us’ link on this page. Despite already being on a page of the same name. There’s nothing wrong with providing a few alternatives but these should not prevent the user from finding the contact details.

BT handles this a little better as shown below. The way the frequently asked questions are provided here is good. Unfortunately, the user experience goes down hill rapidly after this page.

BT presents the top 3 questions to the right-hand-side of the contact options.  People who have exactly these questions, may read them and perhaps no longer need to call. Importantly, the alternatives don’t smother the main purpose of the page.

Positioning of contact options

On many websites, the phone number will be the preferred contact option for users. Some organisations however, prefer you to fill out a contact form. So they put this first and hide the number lower down the page.

When you put your contact form first, you’ll find that many people don’t get to see your phone number. We’re now very used to websites without phone numbers. So much so, that lots of people hit the Back button as soon as they see the dreaded contact form.

If you want your users to contact you at all, give their favoured options prominence on the contact page.

Contextual phone numbers

On some websites, presenting the phone number at the right moment will make the difference between getting a sale and losing one. In such circumstances, it’s not enough to simply provide the ability to find contact details. Instead the phone number should be presented contextually.

A lot of people research products on the internet but prefer to buy over the phone. If you want their business, you shouldn’t make it difficult for them to find your phone number. Consider providing your contact details contextually at points when they are likely to be useful. See the example below from the Share Centre.

The Share Centre associates the phone number with the call-to-action button by positioning the number alongside it and making the text the same colour. So people who don’t want to open an account online are presented with an alternative without the need to go looking for a number. This should lead to more calls from new customers.

Did you find this useful?

If this article was useful for you, try reading a few more. Here are a few suggestions.

• FAQ usability
• Good pathway pages
• Good call-to-action buttons

Do you even need them?

All too often FAQs are used as an attempt to patch up flaws in bad content. Before you create an FAQ page, ask yourself why they should exist at all.

Your FAQs should support the site content, not repeat it. If your FAQ page is answering questions that the rest of the website should answer, then you have a problem with your site content. Sticking up an FAQ page is not an adequate solution.

People rarely go looking for the FAQs

The naming and positioning of your FAQs is what will make them findable. People rarely go looking for the FAQs (although some will), so they often need to stumble upon them instead.

Avoid saying FAQ

I use the term FAQ here because I assume that you are involved in making websites. You know what FAQ means, but normal people (who don’t spend their lives talking about websites) are a lot less likely to have encountered the term. Some have and some haven’t.

Avoid using the initialism FAQ on your site. Saying ‘Frequently asked questions’  or ‘Common questions’ is a lot clearer.

Exposing some questions

An even better way of making the FAQs findable is to expose a few of the most popular and link to the full set. The example below comes from the Eurosport Player.

The most common questions are revealed, so they act as triggers for users who have a question before subscribing to the service. The FAQs don’t support the content here. They are the content. All you can do is log-in, subscribe or read the FAQs. It’s an approach that works for this site. However the implementation beyond this screen is pretty gruesome.

Don’t hide them

If you hide your FAQs in some dark and dusty corner of your website, they may as well not be there. This isn’t to say that you need to prioritise them within your design. Just choose pertinent places to provide them where they will be helpful.

Your contact page is a good place to introduce the availability of your FAQs. If a user is looking for your phone number to ask a question, you can save money by answering it before they pick up the phone. Just don’t substitute your phone number with FAQs. By doing so, you’re telling your customers that you don’t want to talk to them.

They’re FAQs not QWWPTAs

A common problem with FAQs is that they are often not the most frequently asked questions. Instead they are the questions that the organisation would like you to ask (Questions We Want People To Ask). My advice is to actually track the questions that people are asking. So they truly are the ones most frequently asked.

If you have a customer service number, you should record the frequency of questions that people ask. If you can answer these questions clearly on your website then you’re likely to get less people calling you. This approach can also be applied to emailed questions.

When you are tracking these questions, you should also consider the best way to provide the answer on your website. Much of the time FAQs will not be the answer. If people are asking questions like ‘How much does it cost?’ then you have a problem with your website that FAQs are not the solution to. You may need to improve the rest of the content instead.

Writing the questions

You can help your users find the question they need by writing the questions the way your user would ask them. If you are tracking the questions that people ask then this is easy. If you aren’t, you should still write the questions in a way that the user would ask.

Here is an example. The FAQs page from the Eurosport Player includes the question ‘What is the required configuration?’ Unless they’re Mr Spock from Star Trek, nobody will ask the question like this. The answer may be the same, but their question is more likely to be ‘Will it work on my computer?’ So this is wording that should be used on the FAQ.

Writing the answers

It’s the brevity of FAQs that make them useful. People can access a straight answer to a simple question. Bare this in mind when writing the answers to your FAQs. Answer the question as quickly as possible before following up with any exceptions, conditions, or explanations. So if the answer to the question is yes, then the first word of the answer you write should be ‘yes’.

This example above from the National Galleries of Scotland website answers the question immediately. It then goes on to provide the reasons for the answer.

Finding questions quickly

Remember that your users will usually have only 1 question they need to answer. They don’t want to read through every question. Instead they want to quickly zone in on the one they need. You can help them to do this by presenting the questions in a way that makes them easy to find.

Hide the answers until they’re needed

One way of doing this is to hide the answers until the user has requested the one they want. It’s easier to choose from a list of questions than a list of questions with answers below them. There are a number of ways of handling this. But the most basic is to provide the questions as a list of bookmark links to answers lower down the page.

Break up long lists of questions

The questions themselves can be difficult to skim through. This is because they tend to begin with the same words. So it becomes hard to quickly identify the one you need. Long lists of questions will be easier to skim if they are broken up into groups. You can do this by putting the groups on separate pages or just breaking them up with sub-headers.

When the question isn’t there

You won’t be able to cover every possible question. So remember to provide options for people who have questions that are still unanswered.

Was this post helpful?

If so you might also like to read:

• Short and simple sentences
• Don’t say ‘click here’ on link text
• Let your hyperlinks shine

I want to help you to identify pathway pages and explain some considerations you should make by discussing real examples.

So what’s a pathway page then?

Pathway pages are pages that your users experience on their way to finding the information they need. Let’s say I visit the website of the NatWest bank and I’m looking for car insurance. I select ‘Insurance’ from the menu and arrive at the page pictured below.

This is a pathway page. Its job is to be the parent page of the different insurance products (the child pages). The page should point me to the insurance product I want without fuss. In this example, it’s fairly obvious where I need to go to find car insurance. I don’t need to do a lot of reading in order to find it.

Pathway pages are navigation

Think of pathway pages as navigation. When we’re on a pathway page, we’re still on the journey to the content we need. We don’t want to read, we just want to find the link and move on.

Hyperlinks are the key to good pathway pages, not passages of text. Any text you use should help your users choose the correct link.

Good pathway pages are better than navigation menus

A good pathway page answers a simple question. “What’s in this section?“. This is as much about telling people they’re in the wrong section of the site as it is about telling them they are in the correct section.

In reality, navigation menus are often ignored in favour of links within the content area of the page. So the design of your pathway page can be very important to the effectiveness of your site.

In some cases, your pathway pages can actually replace a navigation menu altogether. Check out the example below from Transport for London.

This page doesn’t have a secondary menu at all. Instead it uses a pathway page to deliver links to child and grand-child pages. In this example, it allows the site to improve potentially complex user journeys by providing a simplified design.

Dealing with introductions

When you feel an introduction to the subject is required, consider creating a separate introduction page. This allows you to devote the pathway to navigation.

Such an approach is demonstrated by the Business Link website, as pictured above. This website gives people advice about starting-up and running businesses. The page above is the main page on Value Added Tax (VAT).

It has no introductory text on the subject. Instead it provides a link to an introduction for those who need it. This allows the page to fulfil its role as a pathway page, while still providing an introduction.

Linked headings

If you’re using linked headings on your pathway pages, make sure they look like links. Otherwise they might be ignored. The image below from the NatWest insurance page shows an example of such a problem. The heading ‘Essentials Contents Insurance’ is the same colour as normal text. It’s just bigger and bold. It looks like a heading, but not a link.

NatWest is obviously aware of this problem because they have repeated the link below the text. It has sacrificed a little simplicity in order to adhere to the site’s style guidelines.

The Business Link page does a better job of the same approach. There is no need to repeat links here. The headings are obviously links.

Dealing with lots of links

When your site is a little bigger, you often have pathway pages linking to more pathway pages. So instead of an explanation, you can provide some deeper links to important ‘grand-child’ pages. Here’s an example of how to do it badly, from the Scottish Government.

The design of this page lacks discipline and is difficult to read. It’s unnecessary to provide all of the links underneath each section.

Showing a selection of links

The example below from Direct.gov shows how the Scottish Government should be doing it. If you can’t feasibly show all of your lower-level links below each heading, then don’t try. Instead show just a few as an example and make it obvious there are more available.

Direct.gov gives priority to the heading links. Only 3 examples are provided below each heading and the dots indicate that the list is truncated.

These examples are hyperlinks, but  they look like normal text. This makes them more readable and also gives prominence to the headings. Their primary role is to act as examples, the fact that they are hyperlinks is a bonus.

When you can show all of your links

When you have only a few lower level links under each section, you can show them all on the same page. The example below is from the Barclays website. Barclays makes it obvious where the links are.

When you list the lower level links in this way, people assume that this is all of the available links under each section. So you should only take this approach when you can provide all of the links. When you can’t, the Direct.gov approach is more effective.

Did you find this useful?

If you found this article useful or if you want to tell me I’m wrong, please leave a comment using the form below. You might also be interested in the following posts:

• What is this site for?
• The increasing importance of usability in e-commerce
• Short and simple sentences

You can also subscribe to me RSS feed if you haven’t already.