Quick Summary: In this article I highlight a simple but important feature missing from many bank and financial websites. I also show an example of a bank that has the feature but implements it badly, and one that offers the same function but a much better experience.

The more a company relies on technology to serve its customers, the more it has to gain or lose by the quality of its online user experience.

Increasingly, companies have begun to get the message. However, I’ve noticed that financial service websites often lag behind in adopting user-centric features.  One in particular stands out as either missing or badly implemented.

Check, please

If you’ve ever written a paper check, you’ve doubtless noticed that every one includes a memo section – an area set aside to record freeform details about the transaction. And if you’ve ever reviewed past checks during tax season or had to dig up information on a long-ago purchase or payment, you’ve likely benefitted from the information stored on that humble memo line.

Surprisingly, few banks and brokerages enable users to associate memos with the individual transactions on their accounts. And of those who do, many have implemented it badly.

This is a mystifying oversight. There are compelling reasons to enable users to create transaction memos:

• It helps users identify and differentiate between transactions
• It mimics the “real world” experience of writing or receiving paper checks, where the use of memos is commonplace
• It provides similarity to the “checkbook register” paradigm used by Quicken and other popular finance applications
• It gives users greater control, a key usability principle

It’s worth mentioning that those who use Quicken or a similar product have the option of adding memos to their transactions once they’re imported into a central “register”. There’s no reason not to offer a robust memo capability within each financial sites’ web interface.

You’re doing it wrong

Let’s look at example of one website that falls into the category of “close but no cigar”. ING Direct’s website includes a memo function – but greatly limits its usefulness.

ING users can opt to include a memo any time they initiate a funds transfer. This is good, but consider the limitations. For starters, the memo must be less than 25 allowed characters. Many symbols, including periods and percentage signs aren’t allowed.

Here’s an example of a memo that’s not allowed by ING’s memo restrictions:

“Repayment of 25% of John Smith’s loan from June, 2011.”

This is too many characters for ING Direct, and the percentage sign and period are disallowed. (It’s slightly amusing that a financial website disallows the use of common numeric and accounting symbols.)

ING’s memo function forces users to conform to its limitations rather than adapting to the way its customers might wish or expect to use the website. That’s a big user experience no-no; users should not be forced to conform to seemingly arbitrary system limitations.

There are other problems with the way ING implements its memo function. For example, users can’t add a memo to a transaction after the fact – only when initiating a transfer from the ING Direct website. Why not give users the freedom to create a memo after the fact?

The prescription here is simple:  ING Direct’s website should handle freeform memo entry without restricting “special” characters, and should allow longer entries – at least enough for a complete sentence. And make it easy for users to see and add memos after the fact, not just at the time of the transaction.

There, fixed it for you

By contrast, Chase mostly gets it right by enabling users to add memos to their account transactions with far fewer restrictions.

Chase’s memo function is relatively flexible, enabling users to add a 50-character memo to a transaction at any time. Unfortunately Chase makes a variety of other UX mistakes in its online accounts. But that’s a topic for another day. Compared to ING and others, they’re ahead of the curve for memo functionality.

For all their desire to create a paperless financial system, the big banks and brokerage houses would do well to consider how their customers operate in the real world, and design their user experience around customer behaviors and needs.

Photo by Miss Mass. Creative Commons Licensed.

No related posts.

Quick summary: User experience problems tend to be cumulative. Enough small problems can have the same effect as a few large ones – namely, causing users frustration and sometimes causing them to give up on your application or website. Crafting a good user experience requires finding and eliminating major usability issues, but less severe problems deserve attention too.

It’s usually the case that for each “big” usability problem with an application or website there are many smaller and less severe issues. Naturally the big problems get the most attention (“What do you mean customers can’t figure out how to enter their credit card number?”). What’s sometimes overlooked is that smaller problems, taken as a whole, can be similarly harmful to user experience.

It’s easy to dismiss the importance of small usability problems. After all, the fact that it takes a customer a few extra tries to complete a form, or a few moments longer than needed to locate a button doesn’t seem like much of an issue.

Yet these and similar small usability problems matter more than many companies realize.

The lay of the land

To understand why, let’s consider a couple of points about the environment in which your website or software is used.

1. The bar to switching is lower online.

Online it’s much easier for customers to give up and go elsewhere than it is “in the real world”.

• If you should find yourself in Shamrock, Texas (population 2,000) in need of some devonshire cream, there’s probably just the one grocery store to visit. If it’s not there you’re out of luck. (It’s not there, I looked).
• On the other hand if you’re shopping online and having trouble buying a pair of headphones from the Circuit City website, there are plenty of other companies (Amazon, Best Buy, NewEgg and countless others) who will be glad to help you. And they’re just a mouse click away.

2. Some dimensions of customer service can’t be provided online.

• A customer at a bricks-and-mortar store with a complaint or problem can usually find a human being with whom they can communicate. The retail experience is designed to provide personal, face to face attention for customers who desire or need it.
• Online, however, your customers have no face-to-face interaction with you. In essence your application or website – and by extension its user experience – is the company representative.

User experience problems online and customer experience problems offline are both cumulative, but online you’re at a disadvantage when you need to address them.

The offline user experience: your hotel stay

Allow me to illustrate the point about how offline customer experience is cumulative. Let’s go on a quick virtual vacation (sorry, real vacations are expensive).

Now that you’re on vacation imagine you’ve just checked into your hotel. You’ve never been to this hotel before so everything here is a new experience.

You notice a few things while you’re settling into your room:

• There’s dust on the fixtures.
• There are a few stains on the carpet.
• The bathroom faucett is dripping.
• There aren’t enough towels in the bathroom.
• Your room is located next to a noisy ice machine.

None of these problems are enough to send you screaming from the hotel, but on the whole you find them annoying. They detract from your vacation experience. So you call the front desk to discuss the problems.

You call. And wait. And wait some more.

When you finally reach someone at the front desk they’re not apologetic about the wait or the condition of your room. They tell you that the maid has left for the day. They don’t offer to put you in another room.

You return home from vacation a few days later, feeling dissatisfied with the hotel and vowing to find a better place to stay next time.

The online user experience: your website or software

The way customers react to software and websites is similar.

A single small problem (navigation that’s hard to find, a display that’s difficult to read, instructions that aren’t clear) might not send a customer running from the room but it certainly detracts from the  experience. A confluence of small usability problems can result in abandonment (“death from 1,000 cuts”). And this is to say nothing of the larger usability issues that can stop your customer in their tracks (see my related article, “5 Shopping Cart Showstoppers“).

As with our fictional hotel stay, if you come away from a task having had a bad experience you’ll tend to avoid repeating it. A bad experience anywhere – in a hotel or on a website – is likely to leave a long lasting negative impression. In fact studies have shown that users who’ve had a bad experience with a product or service are very likely to tell friends and colleagues of their dissatisfaction.

The cost of small usability problems

So what do these small problems cost you and your company?

Customers who struggle with your software or website might be able to complete their transaction or task.  However, they’re much more likely to:

• Call for (expensive) customer service that could have been avoided.
• Give up before they complete a purchase or conversion and go straight to a competitor.
• Make a purchase or conversion but never come back because they were unhappy with the experience.

You can’t be there in person when a customer visits your website*. So ensuring that customers can find and do what they want – without great difficulty – means addressing both large and small usability problems.

The bottom line: prioritizing bigger usability problems is sensible, but don’t forget to “sweat the details” too.

Photo by zzzack. Creative Commons licensed.

Related posts:

1. Store locator usability: problems and best practices, part 3
2. Store locator usability: problems and best practices
3. Store locator usability: problems and best practices, part 2

Quick summary: In parts 1 and 2 of this article we examined the ways in which registration affects usability and conversion. In this final part I’ll suggest some things to consider as you define your registration strategy.

Naturally there’s no single approach to registration that works best for every situation. However, there is one overriding concept that should guide your decisions.

The best approach is the one that enables the most direct path between the user’s arrival at your website and completion of their conversion/purchase. This is the essence of a positive user experience, and it’s what makes users happy, keeps them coming back and causes them to recommend your website or application to others.

In deciding how to accomplish this, it’s often helpful to:

Acknowledge competing goals; strive for consensus. Many companies struggle with competing goals from technical, marketing and product management interests.

•    Marketing teams often want to collect as much user information as possible.
•    Technical teams often want to make passwords and user IDs strong (not necessarily a bad thing but there are limits).
•    Product management is often more user-centric and concerned with the user experience – though not always.

For these groups to reach consensus it’s important they all understand the tradeoffs between registration and conversion.

As I mentioned in part 1 and part 2 of this article, less or no registration often facilitates more conversion and increased sales. That doesn’t mean you should simply forego a registered user database. But it does mean that a smart approach is to enable at least some functionality for unregistered users. Then encourage them to register. In the case of an e-commerce website this means offering a guest checkout path or minimal upfront registration.

Define boundaries between required and desired user information. Part of choosing the right strategy is to consider carefully what information you really must collect, understanding that the amount of personal information required is usually inversely proportional to users’ tendency to give it. If you require some type of upfront registration it’s usually most effective to require only information that’s technically necessary to process a transaction.  Then ask for other details later – or not at all. For example, requesting users’ birthdates is often justified as a way to create a “personal touch” by automating emailed birthday greetings. But this marketing device is common and fairly tired in 2009. There’s a good chance that customers already receive and ignore many similar communications. So it’s better to skip this request.

Determine when to ask for information. Once you’ve decided what to collect, give careful thought to the best time to collect it. In most cases this should be after the user has been exposed to information or products on your website and has some stake in wishing to complete a transaction.

This is a key point: value first, registration later is often the best model. Partial value (e.g. – The forum example from part 2) is often a good strategy for giving users an incentive to register.

Part 2 of this article also includes an example of integrating a registration option into a form that users must complete anyway to make a purchase. This type of “inline” approach works well for e-commerce websites.

Keep registration simple; use appropriate security. As I mentioned before technical teams sometimes get carried away with requirements for user IDs and passwords. A very common theme I’ve noticed in user testing is the desire to avoid creating “yet another complicated ID and password”. For applications like online banking this may be unavoidable for security reasons. But if your website doesn’t truly need strong authentication, it’s best to keep it simple.  For example, email address for a user name and a relatively simple password.

Define the value proposition; ensure it’s stated clearly. I covered this in part 1 and part 2 of the article, but to reiterate: requiring registration without stating the value proposition is counterproductive and can lead to abandonment. When asking users to create an account state exactly what they stand to gain, and be sure it’s a compelling proposition.

Define privacy and security terms; state them clearly. It’s also important to clearly state how personal details will be used – and not used. Few things kill users’ interest in a website or product faster than the expectation that their personal data may be unsafe or might be sold to unrelated third parties. “I don’t want this to add to my junk mail” is a statement I’ve heard more times in user testing than I care to count.

Consider incentives.  An effective strategy for building a database of registered users is to require minimal information upfront, then create incentives for users to provide more details later. For web services or information-based websites this could mean offering greater access to information, or discounts of some type. For e-commerce sites it could be discounts offered only to fully registered users or other such promotions.

Building a well-crafted and realistic registration process can have a big impact on the quality of your user database and your user experience. It can also improve your bottom line and conversion rates. It’s worth the trouble and the time to get this right.

Image based on a photo by scragz. Creative Commons licensed.

Related posts:

1. Why require registration? Part 1
2. Why require registration? Part 2
3. Product image best practices, part 2

Quick summary: An increase in conversion is often better than an increase in user registrations, and the two can be at odds with each other. In the second part of this 3-part article we examine this idea and provide some suggestions for improving usability by simplifying registration.

In part 1 of this article we examined the problems that forced registration can cause. We also touched upon some of the reasons users shy away from websites that force them to register before accessing information or making a purchase.

Here we examine more usable alternatives. We’ll also look at the reasons reduced registration requirements can result in a better user experience, more conversions and more revenues.

We’ve looked at ways registration can be counterproductive to achieving conversion or sales goals. So what’s a better model? What’s the right balance between providing a simpler experience versus collecting useful information via registration?

There are a few approaches that seem to work well, but let’s start with one that usually doesn’t. Here’s an example of the type of barrier you don’t want to place between your users and completion of an e-commerce purchase:

Users have only two primary options here: they’ve already got an account or they’re forced to create one.

This limited set of choices slows new users down. On many websites registration forms take them away from the purchase process. Depending on how well the registration form is executed and how it handles errors the diversion may cause problems or even abandonment. This isn’t just speculation; I’ve seen it happen in countless user testing sessions.

Also note that in the example above there’s no messaging on the page that addresses why a user might wish to register – what tangible benefit it provides – and how the information will be used and safeguarded. As I mentioned in the first part of this article those are important issues to users. A lack of clear information at this point in a purchase process can cause unnecessary calls to customer service or result in abandonment. Here’s an example of a simple registration form that addresses benefits:

Let’s also consider the experience a consumer has when purchasing an item at a bricks-and-mortar retail store “in the real world”. They shop, take their purchases to the checkout, then pay. End of story. They’re generally not required to open a store account or divulge personal information. Even stores that ask for zip codes or telephone numbers will gladly complete the purchase if you decline to give it. Why should the online experience be substantially different from what your customers are already used to?

Think carefully whether an increase in conversion is better than an increase in user registrations, because often the two are at odds with each other. I’d argue that in most cases revenue is more important than building a database of customers who shopped but didn’t purchase, or purchased but won’t be coming back because the registration process was a nuisance.

Increasing conversion by reducing requirements

As I’ve already stated there are alternatives to requiring registration upfront. Which approach makes the most sense depends on your particular situation, but here are some starting points:

1. Integrate optional registration into checkout. For e-commerce websites an excellent approach is to integrate registration into the purchase process rather than requiring it at the start of the checkout process. In order to process a credit card and ship a physical item websites must collect a great deal of users’ personal information. Why not use this to simplify the user experience? Consider this simple wireframe example:

2. Require registration upfront but streamline it. A different approach is to require only minimal registration to enable users to get started (e.g. – just just an email address and password). While I personally advocate approach #1 above for most e-commerce websites, there are cases where this is a sensible approach. Assuming your website collects only minimal information up front, it makes sense to incentivise users to provide additional information after conversion has taken place – such as on the confirmation page or via a link an email follow-up. This approach works well for social networking sites like LinkedIn where users can create an account with relatively little information but are reminded how much of their profile remains to be completed. They’re also exposed to messaging that addresses the benefits of completing their profile.

3. Offer partial functionality with little or no upfront registration. Offering the equivalent of a free sample in return for minimal registration is another good model (e.g. – email and password only, then limited access to the product or service.) This is then followed up with messaging like, “Want full access? Just fill out this simple form.” Some special interest forums use this model, enabling users to search and read messages with no upfront registration, but requiring registration in order to access some sub-forums or view image attachments. This is a “win-win” because it means the forum is constantly showing off its wares and attracting new potential members. When users decide to register there’s a good chance they’re truly interested in the forum. This means they’ll help create a high quality member database for potential advertisers. Consider what happens if forum operators require users to complete a full registration just to access the smallest amount of content (and some do). They very likely end up with a poor quality member database, because some will have registered simply to determine whether or not the information was useful to them – and then decided it wasn’t. This can only result in the creation of accounts belonging to users who won’t be coming back. It’s not exactly the kind of targeted audience that drives advertisers to spend money supporting the forum.

In part three of this article we’ll wrap things up by examining some best practices for integrating sensible registration choices into your planning and development process.

Image based on a photo by scragz. Creative Commons licensed.

Related posts:

1. Why require registration? Part 3
2. Why require registration? Part 1
3. 5 shopping cart showstoppers

Quick summary: Many websites require new users to register before they can access information and services, or complete a transaction. But upfront registration can be counterproductive and can have a negative impact on conversion. In part 1 of this 3-part article we’ll look at why registration sometimes causes abandonment.

These days many e-commerce websites require registration as part of the purchase process, and many web applications require full registration upfront before users can demo a product or service. Does this paradigm really make sense? Or is it perhaps counterproductive?

Certainly it’s fair for companies to request at least some user information when there’s an exchange of value. And in some cases collecting personal information is necessary to delivery of the goods or service (for example you can’t offer a service based on users’ locations without requesting it).

The problem is that many companies assume they’ve done an adequate job of presenting their value proposition, and that users will register with little or no reservation. Unfortunately this often this isn’t the case; in my experience companies often fail to convince users that they should register.

It should come as no surprise that most users are extremely skeptical about registration until they:

• Clearly understand upfront what they’re getting in return
• Have reason to believe it’s of significant value to them
• Have a good sense for how their personal information will be used and/or safeguarded

Because users are skeptical and because companies often fail to present a compelling value proposition, registration can be a significant barrier to conversion. It can even cause some users to abandon a process or website entirely.

There are a few ways to address this – but first let’s understand the problem at a deeper level.

One of the issues here is that companies often don’t recognize the disconnect between the way they see the world and the way their users see it.

How companies see registration

Many companies start from the understandable but flawed viewpoint that it’s in their best interest to gather as much personal data as possible, and sometimes they also feel it should be gathered as early as possible in the customer relationship. They see their product or service as a value to users and conclude that users will see things the same way. These companies are often puzzled when they find users abandoning their website or process at the point where personal information is requested. They feel they’re providing a useful service or product, and that users have every reason to want it and to trust that they’ll use registration information in an appropriate manner.

How users see registration

Most users see registration from a very different perspective.

I covered aspects of this problem in the previous articles “5 shopping cart showstoppers” and “Your users have baggage”, but to summarize:

• Users come to your website with expectations and biases created from previous experiences.
• They’re often very skeptical about giving out personal information, especially to companies with whom they don’t already have a trusted relationship.
• Users naturally avoid situations they feel might compromise their privacy.
• Many users also avoid anything they perceive as likely to result in “yet more junk email”.
• Many users have difficulty managing the numerous ID/password combinations they already use – and they’re disinclined to create more.

In this context it’s not surprising that many users will avoid registering at a website if they can reasonably avoid it.

Here’s an example. Recently at a coffee shop I overheard the following comment from a woman sitting nearby, using her laptop:

“I hate it when they ask for your information, but they don’t quite tell you why they want your information.”

Clearly there was a disconnect between the expectations of this woman and those of the company with whom she was considering doing business. She’s not alone; her statement is a good example of what I’ve heard countless times in user testing sessions. Look at it this way: how would you feel if a total stranger asked for your home address? Your phone number? Your credit card number?

Even if users already have a trusted relationship with a company or website they may still wonder what becomes of their personal information. Will it result in a barrage of spam? Will it be sold to other companies? Is it safe from hackers?

It should surprise no one that users often find registration processes off-putting, annoying – even offensive.

So what’s the solution? Obviously for some products and services some type of personal information must be collected. And for some services it’s logical that users must have some type of account.

Still, there are cases where registration might not be necessary at all – or it may make sense to ask for only minimal information during the initial registration process, then collect more information gradually as the relationship between customer and company matures.

Here are four questions to consider when evaluating how registration should work for a given website or process:

1. Is it necessary? Determine if you really need registration for your product or service, weighing the benefits of having more users versus having more information about fewer users.
2. What information should be required and when? If you determine that registration is necessary, determine when it should best be presented – and importantly how much information you need from users. As we’ll discuss in Part 2 often “less is more”.
3. Is the value proposition clear? Ensure that by the time users are asked to register they have a very strong sense for why they should, and what they’ll stand to gain from it.
4. Is security & privacy addressed? As I mentioned above users will often walk away from a registration form or process if they’re not convinced their personal information will be handled appropriately.

In part 2 of this article we’ll get into the nitty-gritty of each of these points and we’ll look at some good and bad examples of registration processes.

Image based on a photo by scragz. Creative Commons licensed.

Related posts:

1. Why require registration? Part 2
2. Why require registration? Part 3
3. 5 shopping cart showstoppers

Quick summary: Users come to every website or application with expectations, assumptions and biases that are forged from previous experiences. It’s important to understand your users’ biases – and address the ones that affect usability.

I hate to be the one to break it to you, but your users have baggage. Lots of it.

I’m not referring to carry-ons or checked luggage. And I don’t mean deep emotional problems (although they may have those too). I mean that everyone who visits your website or uses your application brings with them certain assumptions and expectations from previous experiences.

Why should you care? Unless you’re willing to understand and accommodate your users’ baggage you may be inadvertently creating a frightfully bad user experience for them. So it’s best to understand your users’ baggage and then determine what you can do about it.

User Expectations and biases

Everyone who uses technology – websites, applications, kiosks, products – walks away from each experience with certain impressions and memories. Sometimes the experience reinforces what we already believed. Other times the experience results in new opinions or assumptions, or changes existing ones. Good, bad or indifferent these memories get filed away and later become part of the filters through which we view the world.

This is important to usability because when someone begins to interact with your product they’re perceiving it through their own unique set of filters. In other words, their previous experiences have a big impact on how they interact with your product – and what they expect from it.

This type of “baggage” takes many forms, for example:

• Stories about others’ experiences. A user coming to your website might have recently read a story in the media about a big online privacy breech, and be wondering just how secure your website really is. Or he/she may have heard a story from a friend or family member about identity theft. This user is likely to be especially sensitive to privacy and security issues and messaging (or lack of it).

• Their own personal experiences. Perhaps your user recently ordered an item but found out a week later that it was out of stock for six months. This user may be wary of making a purchase if they don’t feel a strong sense that the order will be filled promptly.

User baggage isn’t limited to bad experiences. It also takes the form of assumptions and expectations about things like:

• Information architecture (“I expect to find silverware in the housewares section”)
• Data entry (“I expect to put parentheses around my area code”)
• Terminology (“I call them oyster forks, don’t you?”)
• Search syntax (“I expect to search by typing in sentences like ‘show me forks under $10’”)

… and so on. These assumptions and expectations cause users to interact with your website or application in a certain way. The problems often begin when the website or application works in a way that’s contrary to users’ expectations.

What should we do about user expectations and biases?

We need some ways to understand and then address this type of user baggage.

The best way I know to understand what baggage users carry with them is simply to ask. Well, maybe not directly (“Say, what baggage are you saddled with?”). But there are a number of ways to find out, and not surprisingly they’re all consistent with best practices for usability and user experience design. Three of my favorites are:

• User testing. So far there’s no substitute for sitting down with representative users and observing how they interact with your product. It’s an opportunity to uncover important assumptions and expectations, and it can enable you to address the most serious disconnects between what your users expect and what you’re giving them. I’ll cover user testing in considerably more detail in future articles. Naturally user testing isn’t the only way to inform improvements to usability and user experience – but it’s the most powerful.

• Online surveys. Collecting information via quick online surveys is another great way to gain insight into your users’ thoughts. Tools like Survey Monkey can be used to gather information on terminology preferences, for example by displaying a product image and asking users to choose which category it belongs to. The disadvantage to surveys is that you get “what” users think but not “why”. In other words you may be able to determine that most of your users expect to find speakers in a section labeled “studio monitors”, but you won’t necessarily know why they feel that “studio monitors” is a better choice than “speakers” or “sound reinforcement”.

• Remote observation tools. Tools like ClickTale and Userfly enable you to record users’ interactions with your website. You can then play back the recordings later to see exactly what users clicked and typed, and when. These tools can be very helpful in uncovering user baggage. Their primary limitation is that – just like surveys – they don’t address the “why” of user behavior as effectively as user testing. Still, they can be a good starting point for learning where user behaviors and expectations differ from what a website or application delivers.

Regardless of how we gather information from users, once we begin to see what baggage they bring with them we can address it. Again there are a number of ways this can be done, but the two most important are:

• Revising the site or application to more closely match user expectations; or,
• Setting expectations more clearly.

Revising the site or application generally involves things like:

• Using terminology that users expect. If most of your users think that product #218 is an oyster fork, then call it that. Or use more than one name (“Oyster fork/3-pronged fork”).

• Matching information architecture to user expectations. Similarly if users expect to find their oyster forks in a section called “housewares” but you’ve got them in a section called “silver” or “other” then there’s a problem.

• Adding or revising functionality to match expectations. Using the example from above, if users tend to use parentheses when entering phone numbers the ideal solution is for the website or application to simply accommodate parentheses.

Of course there are situations where it may be unfeasible (or undesirable) to change aspects of a website or application to match user expectations. The next best alternative is to set expectations more effectively. This can be done in a variety of ways such as:

• Adding text hints and contextual help. If users tend to make mistakes with data entry (like the earlier example of parentheses around an area code) then it makes sense to either modify your site or application so that it can handle such input, or help set expectations that it can’t. Text hints such as “(numbers only)” or “xxx-xxx-xxxx” can help guide users towards entering data in the format it’s needed.

• Ensuring important messaging is easy to see and clearly written. I’ve touched upon this in several previous articles but to recap: if you want to ensure that customers with privacy and security concerns (and that’s most of them) feel comfortable, it’s important to address these points very clearly. It’s also important to make sure users can actually see and notice these messages. They need to be large enough and presented in places where users will naturally look.

In conclusion

• Users’ previous experiences create filters through which they see and interact with your application or website.
• It’s important to understand your users’ biases and expectations because they can play a big role in ease of use.
• User testing, online surveys, and remote observation are three tools that can help uncover and understand user expectations and biases.
• Once you understand your users’ biases you can work around them; in many cases this involves simple changes like terminology. Sometimes the necessary changes are more complex and involve site structure or information architecture.
• It’s wise to gather information about expectations and biases periodically because they tend to change over time.

Yes, your users have plenty of baggage. But it needn’t result in frightfully bad user experiences.

Photo: striatic. Creative Commons licensed.

Related posts:

1. Why require registration? Part 1
2. Improved error handling, part 1: helping users notice errors
3. Communicating status

Quick summary: it’s important to let users know when a hidden process will take more than a few seconds. This article looks at the “when”, “why”, and “how” of communicating system status.

A key principle of good interface design is that it’s important to communicate system status to users, especially when the system requires them to wait for a process “under the hood” that’s not visible. Examples include file operations (copying, moving, deleting) or communication between systems (verifying a credit card or checking available inventory). Messages that communicate status can vary widely – from simple (“Please wait – this will take a moment”) to more complex (animated graphics indicating a percentage of the process completed). Let’s examine the when, how and why of communicating system status.

Say something… say anything.

We’ll start with the most basic level, the “when” and “why” of communicating system status. In general it makes sense to give users a sense for what the system is doing any time there’s a wait of any consequence. How long is that? Various studies have shown that users begin to feel like something’s wrong if they’re forced to wait more than a few seconds between the time they perform an action (like clicking a button) and when they perceive a change in status. Note that it’s not “when a change occurs” or even “when a change is indicated” but when the user actually perceives it. That’s an important distinction that we’ll come back to in a moment.

Part of delivering a good user experience involves keeping users informed and in control as much as possible, so if your system ever requires a user to wait for a process to take place it’s beneficial to clearly communicate what’s happening. This prevents the frustration that typically occurs if a user believes  the system has stopped responding and/or is “broken”. But remember, users have to perceive that something’s happening. So how do we ensure that?

Speak up.

Just as important as delivering some type of system status message is ensuring that it’s visible and easily noticed. I’ve seen countless examples of system status messages that are buried below the fold of a scrolling page, displayed using small or low-contrast type, or placed in an obscure location where they’re very easy to overlook. If you’re going to the trouble of telling users that something important is happening you need to be sure they actually notice and read the message. Using eye-catching colors and/or images can help. Here’s a simple wireframe example of a text status display that employs a yellow background for visibility:

Naturally status displays don’t need to be text – here’s an animated display that Orbitz uses to indicate it’s searching for fares (the dots are  animated):

Another travel website – Kayak – also uses an animation to show users it’s comparing fares:

There are many ways to show status, and in the case of simple processes the status messages can also be fairly simple. But they must be clearly visible.

Speak clearly.

Now that you’ve got the user’s attention, if you’re going to explain what’s happening the clarity of your language is important. It’s wise to avoid jargon and instead use simple, descriptive language. For example, “SQL query initiated” might be technically accurate in certain situations but it’s cryptic and doesn’t mean much to the average person. “Please wait – we’re searching for your information” is much clearer and can be understood by just about anyone. In general unless your audience is comprised only of technical experts it’s wise to keep things very simple. (as a side note, even if you’re convinced your audience is comprised of technical experts there are probably exceptions – see below).

Try this: put all of your messaging to a “grandma test” – if you were to read the message to your grandmother would she have any idea what it means? If not then consider re-writing it so that it’s understandable to a broad audience.

Seriously, speak clearly.

Speaking of a broad audience, it’s common for software and web teams to make bad assumptions about their use of language. I’ve encountered many development teams in which the prevailing notion was “our audience understands industry terms and abbreviations, so there’s no need to dumb down the language”. But in my experience this is almost always a bad assumption, and is quickly debunked in user testing.

Here’s an example: suppose you’re building a medical billing application. You might be tempted to assume that the people who use the application are mostly medical billing professionals who have plenty of training and already know all the special terms and abbreviations. But what about:

• A new hire? He or she might not yet be up to speed on all the abbreviations.
• The employee who normally doesn’t handle billing but is asked to help out in an especially busy week? He or she doesn’t have exposure to arcane billing jargon.

The point is that it’s easy to make excuses about the clarity of your status messages – but if you’re striving for usability then you need to ensure that all your language is clear and concise and stays away from jargon and excessive abbreviations. Believe me, it’s worth the effort.

Be friendly and polite.

This isn’t as critical as the previous points, but it’s also beneficial to create status messages that are friendly and conversational in tone. Consider this metaphor: you walk into a bookstore and ask a clerk if they have the #12 New York Times bestseller. You might find it a little puzzling and offputting if the clerk simply says “Stand by” in a robotic tone and disappears behind a stack of books. In the real world if the clerk is a human being, he or she is more likely to respond to you conversationally, along the lines of “Let me see if we have that, just a moment.” There’s no reason status messages can’t be similarly conversational. Employing a conversational tone helps put users at ease and reinforces the impression that you care about them as a human beings.

Be specific (even if it’s a guess).

If you’re communicating status about a process that’s especially involved and will take more than a few seconds it’s usually beneficial to give users a sense for the magnitude of effort and/or the amount of time involved – even if there’s no precise answer. For example a simple message along the lines of “This usually takes about a minute” is informative and helpful. If the amount of time is variable then a graphical display of percentage completed and/or time remaining is good. This type of display is already commonplace in operating systems:

This is the status message for a file copy operation from Apple’s OS X. Note the mention of an approximate time (“less than a minute”) – it’s imprecise but still useful. Progress is indicated with a bar as well as a text display showing how much data has been copied so far and how much total data will be copied. This is a good convention because the user gains a sense for the status at a glance and can also choose to read the details.

In Windows (XP shown here) copy operations include an animation depicting what’s happening as well as an estimate of time remaining. In this example it’s less detailed information as the OS X display but still useful and a good convention.

In conclusion

There are many ways to display system status, but just a handful of underlying usability principles that apply:

• Keeping users informed about what’s happening “under the hood” prevents them from becoming confused or frustrated when a process takes more than a few seconds.
• It’s critical to ensure that users actually notice status messages, so be sure they’re bold and not hidden.
• Use clear and concise language to describe what’s happening,
• Avoid jargon or abbreviations if possible.
• If the operation will take more than a few seconds, consider estimating the amount of time needed and/or displaying progress.

Visible and clear status messages are just one facet of creating a positive user experience but I think you’ll find it can be a very important one.

Photo credit: Divemasterking2000. Creative Commons licensed.

Related posts:

1. 6 ways to improve confirmation pages
2. Improved error handling, part 2: writing effective error messages
3. Your users have baggage

Quick summary: This is the final part of a three-part article on improving the quality of online help.

In part 1 we discussed making help highly visible to users, and how to present it site-wide and in context. In part 2 we looked at ways to determine what types of help are most needed. In part 3 we’ll look briefly at the importance of good copy writing and the need for a feedback loop between you and your customers.

4. Pay attention to your writing

It should go without saying that help content needs to be clear and concise. Yet I’ve seen a lot of help content that takes far too long to get to the point, or presents information in a way that’s vague or inconsistent. It’s difficult to write really good help content, but it’s important. Good help content:

• Gets to the point quickly and is easily understood by your customers even if they’re new to your product or service.
• Avoids jargon, abbreviations, and anything that might cause confusion.
• Is presented in the order of a newspaper-style “inverted pyramid” where the simplest and most important statements come first, followed by successively greater detail.

There’s a lot more to say about writing help content – too much to cover quickly. So in this article I’ll be concise and will address this more thoroughly in a future segment. For now I’ll just add that there are professionals who specialize in writing online copy, and there are numerous resources online that explain the basics. Either (or both) of these are worth looking into if you have any doubts about the effectiveness of your help copy.

5. Create a feedback loop

This is important but often overlooked. Even if you’ve done your homework and crafted your help content to prioritize the most likely issues there’s a good chance you’ll miss something; Murphy’s Law dictates it’ll be something important. So it’s smart to enable users to rate your help and suggest new topics. This can be as simple as a link on the help page along the lines of “Didn’t find what you wanted? Let us know.” along with a form or mailto: link. Or it could be more involved such as the rating system seen on Microsoft’s support website:

Of course if you’re collecting this information you should  ensure that someone in your organization is tasked with reviewing and summarizing it so that it’s translated directly into improvements.

Hope that helps

One final thought – consider reviewing all your online help periodically to ensure that it’s effective in addressing the most common issues and resolving them quickly. Why? Because common issues and questions often change over time as your product and customer base evolves. What works well today might miss the mark 6 months or a year from now.

I hope these thoughts on help have been… helpful. And I hope you’ll agree that by paying attention to the quality of your online help you can enable your users to solve their own problems when and where they ecounter them – without them feeling a need to to escalate or give up.

Photo credit: romulusnr. Creative Commons licensed.

Related posts:

1. Shouldn’t your help be more helpful? Part 2
2. Shouldn’t your help be more helpful? Part 1
3. 5 shopping cart showstoppers