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.

“In most people’s vocabularies, design means veneer. It’s interior decorating. It’s the fabric of the curtains or the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product or service.”

No related posts.

I’ve written an article for UX Booth entitled ‘Meet the Respondents: Understanding User Personalities’. The article goes into some of the common personality types you’re likely to meet when conducting user testing.

Related posts:

1. 5 reasons to love remote user testing
2. 7 reasons to avoid remote user testing

Quick Summary: In part 1 of this article we covered what I call the user interface “snow plow principle” – the notion that displaying too much information and offering too many options is akin to driving a snow plow to the corner store to get your groceries. Here in part 2 we look at some solutions to the problem.

Packing too much into an interface results in user confusion, information overload, and a poor user experience. Sounds like an outcome worth avoiding, doesn’t it?

Solving this problem doesn’t require rocket science (or snow plow science for that matter), but it does require thinking in ways that you or your team may not be used to. Here are some strategies and tactics to consider.

1. Make simplicity a stated project goal. For some organizations this goes without saying, but many simply pay lip service to user-centered design. User-centered design requires a commitment to research and planning, and it requires that you make the effort to learn what your users want. This knowledge enables you to deliver upon their needs and expectations. A good starting point is to ensure that documents describing your project include simplicity and ease of use as critical design requirements.

2. Learn about your users’ goals and needs. Many organizations and teams base design decisions on assumptions about user needs. This is only marginally better than ignoring users altogether. Even the most knowledgeable members of your team aren’t the customers who actually use the product. In other words, guessing about user needs and goals is a shortcut to building the wrong interface. It’s dangerous to assume you know what your users want; instead, ask them (I’ll cover how to ask in other articles).

You should research and document:

• Who your users are (their demographics, skill sets, work environments)
• What they need from your application or website, and
• How your product fits in to their workflow.

This baseline knowledge enables you to design for simplicity by focusing on:

• What’s most needed
• by the greatest number of users
• in the greatest number of high probability use cases.

Armed with this knowledge, you can move or remove elements and functions that are less important, for example those of little relevance to most users, or those that aren’t needed most of the time.

3. Establish a purpose and goal(s) for each key screen. You should associate a set of user goals and business objectives to every screen of your application or website. For example:

• What should users accomplish or get out of a given screen/page?
• What is the desired user outcome for the screen?
• How does this benefit the user?
• How does it benefit your company?

Understanding the answers to these questions enables you to measure each element of a screen/page against its purpose and its contribution to overall user and company goals.

4. Prioritize interface elements accordingly. Once you have a sense for what’s important to your users and what isn’t, you can adjust the interface to emphasize key functions and information, making these items easy to notice and understand. Remember, these must be the attributes, elements, and functions that are most important to your users in fulfilling their goals, not those most important to the development, design, or marketing team.

5. Supress or move low-probability information and options. This is the “less” aspect of “less is more”. When an interface element isn’t needed often, it should be suppressed or eliminated. This doesn’t necessarily mean hiding less-used options many levels deep. It can mean in essence “hiding them in plain sight” by making them less prominent within a layout. One example of this is replacing a block of disclaimer or explanatory text with a brief overview and a link to “learn more”. Another small example is displaying the most popular/likely items in a list first, for example placing “United States” first in a list of countries on a shipping form if the great majority of your customers are in the United States (also see this related article).

6. Edit what’s left; err on the side of brevity. Once you’ve reduced an interface to its most essential elements, it’s time to ensure that your language is clear and concise, and that your layout enables users to find and understand the key information and options. Whenever possible, disclaimers, instructions, and other text should be brief while still remaining clear and compelling. Writing for the web and for software is an art in itself, and is beyond the scope of this article. I’ll cover more on that at a later time.

7. Test your user experience. The quality of a user experience can be measured. If you’re not measuring yours then you’re “flying blind” and merely guessing at the effectiveness of your product. Test your website or application periodically, even if it’s meeting your business objectives. There are many ways to do this, for example formal or informal user testing, or online surveys. Regardless of the methods, the goal is to ensure that the application or website stays aligned with user needs. When the two diverge, it’s time to make improvements. On a related note, remember that user needs are not static; they change over time. If you haven’t spoken to your users about their needs lately you might be overlooking an important opportunity for improvement.

Paradoxically, there’s much more to say about simplicity; this article only scratches the surface. I plan to cover more on this important topic in the coming weeks and months. In the meantime I hope it provides some food for thought and a starting point for discussion and positive change.

Photo by Joost J. Bakker. Creative Commons licensed.

Related posts:

1. Simple user interfaces: the snow plow principle
2. Streamlining user interfaces, part 1
3. Reduce costs and improve usability with visual standards, part 2

Quick Summary: A key goal of user experience design is to keep things simple. Unfortunately websites and applications create problems for users by employing interfaces that are too complex. In this article we’ll explore a way to think about what interface elements are truly necessary for your users, and which can be reconsidered or eliminated.

Simple and intuitive interfaces are all about balance. To identify the truly essential elements of an interface, it’s helpful to look at the problem in a different context. In part 1 of this multi-part article I’ll cover an admittedly unusual way to view the problem of simplification. In part 2, I’ll describe some ways to apply this approach.

The user interface “snow plow principle”

Let’s take a moment to ponder the humble snow plow. It’s a device of unquestionable value. It keeps roads safe and can be called upon in snowstorms and blizzards to clear paths to otherwise unreachable locations. In many areas around the world it’s an essential public safety tool.

But if you owned a snow plow, would you drive it to the corner grocery store? Or to work every day? Probably not, unless you lived in Antarctica. Most of us live in climates that require the use of snowplows only periodically, during the worst weather conditions – if at all. In fact, many people have never benefitted from a snow plow. But where they’re needed, they’re indispensible.

So what does this have to do with user experience and interface design? Think of building an interface with a great deal of unnecessary information and capabilities as the metaphoric equivalent of using a snowplow for one’s daily commute. Sure, it gets you there – but what portion of the capabilities are actually needed? Would a smaller, more efficient vehicle work just as well? Is it possible to achieve the goal without firing up the heavy equipment?

Designing user interfaces for blizzard conditions

Websites and applications often employ interfaces and information displays that are designed to cover all of the possible uses, rather than those with the highest probability. Let’s go back to the snow plow. If you had a snow plow at your disposal, it’s sensible that before starting it up you’d first consider the context, for example:

• Current and expected weather conditions
• Road conditions and known road hazards
• Goals and requirements for the trip
• Skill and experience of the driver

But web pages and software interfaces are often built with a “more is more” approach, and consequently the interface is designed to accommodates most or all of the possible use cases in its default state. This is the equivalent of offering users the keys to your snow plow for a trip to the corner store on a snow-free, sunny day. You’re getting them from point A to B, but via a cumbersome interface that displays too much information and/or offers too many options for the majority of users and use cases.

One example of this phenomenon can be found in older versions of Microsoft Word. Those who have used Word for years will recall that until recently it presented a huge number of options by default, making it difficult – especially for beginners – to find a desired option among the bevy of choices. The interface gave equal visual weight to its myriad functions even if they were rarely or never needed by typical users.

With Word, Microsoft was in essence offering keys to its snow plow for users’ daily commute. (To Microsoft’s credit, while the newer “ribbon” Office interface isn’t perfect, it’s considerably more customizable and does a much better job of emphasizing high probability functions.)

Other examples are easily found. Web and software interfaces are often designed to display information and options for all users under all circumstances, rather than the most likely choices for the highest probability customers and scenarios.

Simplification – a.k.a. parking the snow plow

Now that we’ve defined the problem we can begin to examine solutions. How do we ensure that a diverse set of users can access the information and options they need while preventing “snow plow interfaces” from slowing down and confusing everyone?

In part 2 of this article I’ll cover some specific ways to keep the snow plow parked while still meeting your user and business needs.

Photo by Joost J. Bakker. Creative Commons licensed.

Related posts:

1. Simple user interfaces: the snow plow principle, part 2
2. Streamlining user interfaces, part 1
3. Reduce costs and improve usability with visual standards, part 2

Related posts:

1. 5 reasons to love remote user testing

Related posts:

1. 7 reasons to avoid remote user testing

Quick Summary: In part 1 and part 2 of this article we looked at the ways in which store locators leave users frustrated, and we explored ways to address the problems.  In the third part of this article we look at some additional best practices and touch upon a few special considerations.

Continuing on with our look at store locator best practices, it’s also sensible to:

Prioritize the information customers are most likely to need. In most situations, customers looking for a store will need one or more of the following:

• Street address (including city and state)
• Telephone numbers
• Hours of operation
• Any important differentiators (e.g. – retail store versus a warehouse, a location with special services, etc.)

Sometimes it’s also helpful to include:

• A mention of nearby landmarks (“just 1 block East of the freeway”)
• Brief special instructions if applicable (“parking available in back”)

… and naturally some customers may also (or instead) wish to see a map. So the structure of store locator results should make it easy to see any of this information without unnecessary extra steps. The store locators from OfficeMax and Staples that I showed in Part 2 of this article do just that; they give users the basic information about each nearby store, then make it easy to see a map and/or get driving directions. This is a good balance.  Store locators that display giant maps and don’t include the other information listed above – or include it but make it hard to find – aren’t helping themselves or their customers.

Some companies also need to differentiate the services offered at each location. Websites like Home Depot list specialists who work at each store (e.g. – “John Smith, master plumber”); this is a great idea since it anticipates and addresses a possible customer question “Does anyone at that location know about plumbing?”.

Offer to email or text directions. Some users may wish to keep the directions and other information on their mobile device or in an email account. It may be beneficial for them to have an option to email or text the store information. This is still a relatively uncommon practice, but it’s growing in popularity. It’s a great idea. One place I’ve seen it is on bank store locator functions that use a third-party application called LocatorSearch. Here’s a screen shot from the LocatorSearch demo:

The option to send store information to a phone is an excellent convention.

As you see, each bank location includes an overview with the address and services available and a option to “Send to Phone”. What I don’t see here is a telephone number, but this is presumably something that can be added by the individual financial institutions that use the software.

Provide good error handling. It bears mention that applications and websites should always provide clear and specific feedback when users encounter an error. Yet, some store locators fail to deliver on this basic requirement. The PetSmart store locator, while generally very good, doesn’t have much to say when no stores are available in a particular ZIP code:

PetSmart's generally good store locator doesn't say enough when it can't find a nearby store.

Just as websites can be more helpful when an item is out of stock,  store locators can also provide helpful and usable feedback when a customer attempts to locate a store in an area that doesn’t have one. In the cases depicted above, a better solution would be to show an obvious and more conversational statement such as “Sorry, there are no stores within 20 miles of zip code xxx. Our nearest store is 35 miles from this zip code and is displayed below.”

Be sure the information is current. This is another suggestion that falls under the “obviously!” category, but it’s important to ensure that as company locations change the store locator database is kept current. More than once I’ve heard stories of people getting out of date addresses from a store locator and going on a wild goose chase. It’s easy to see why this would be an especially frustrating experience for customers.

A related problem: distributor/retailer locator

A different but related problem can be seen with companies that sell only through distributors and other channel partners, and don’t have their own retail locations.

Customers may come to these websites wondering “Where can I buy your products?”; naturally it makes sense to address this question. It’s a mistake for companies to assume that only trade professionals or large-scale retail buyers will encounter their website.

Here’s an example from a company that makes industrial lubricants. Some of their products are of interest to consumers (for example automotive and woodworking hobbyists), but their product lines are typically sold only through third party industrial supply companies such as WW Grainger.

The LPS “Distributor Locator” looks like this:

LPS' distributor map doesn't provide useful feedback when it can't find a distributor.

The large map isn’t clickable.  If the user enters a zip code where there’s no distributor, the page simply refreshes without displaying an error message. Oops. I think what they’re trying to say is “Sorry, we don’t know of a distributor near you where you can find our products.”

But as I mentioned above LPS sells many of its products through WW Grainger, which has a large e-commerce storefront. And even Amazon.com has merchants who sell LPS products. Even if there’s no “Distributor” nearby there are alternative ways to purchase LPS products. Since the website doesn’t mention this, they’re needlessly turning customers away.

Wrapping up: store locator usability

As we’ve seen from the examples in each part of this article there are many ways to make store locators more usable and generally more functional. The key requirements are:

• An easy to find locator function (preferably on the Home and other key pages)
• A simple and robust entry form that can accept a wide range of inputs
• An easy way to search a second time if needed
• Finding a good and usable balance between text information and maps
• A focus on prioritizing the information users are most likely to need and want
• The use of good, flexible third-party mapping applications
• Accurate and current information

Ensuring your store locator meets these criteria will make it easier and faster for customers to find your stores, and should enable them to arrive there in a mood to buy rather than curse your website.

Related posts:

1. Store locator usability: problems and best practices, part 2
2. Store locator usability: problems and best practices
3. Reduce costs and improve usability with visual standards, part 1