image by emmerrrrrrr (flicker)

What can often frustrate users online is when these questions are not addressed until too late in the purchase process; when the user has already made some sort of a commitment to the product, only to find out it’s either not available, cannot be delivered in the expected time frame/location or delivery costs are too high. Had the user known these factors upfront during their browsing phase the frustration levels would be a lot lower and the chances of that user staying a customer much higher.

It is important to inform the users of the following before they arrive at the checkout. It  may be just enough for users to stay a customer rather than go straight to a competitors site. A few small changes can have a great impact on a user’s shopping experience

• If a product is out of stock provide this on the product listing page
• Offer an email alert when the product become available
• If, for whatever reason, a product cannot be delivered in the company’s standard time frame (next day delivery for example), provide this detail upfront on the product listing page, before users have committed to the order

Reducing user frustration leads to a much more happy and satisfied customer. And satisfied customers are more likely to return. Empowering users by giving them information before arriving at the checkout process of factors such as product availability, delivery time frames and costs is one simple method to do this.

One area of project preparation where the expectation is that time can be saved is in recruitment. We aim to have a two week window to recruit participants for a study as a general rule, but sometimes we are asked to turn things around quicker. In some instances, such as when the target is quite general or broad, asking our recruiter to turn around a list of participants faster isn’t as much of a problem, but in other instances, such as when the recruitment specifications call for a very specific target such as “Alaskan Malamute dog breeders based in Parramatta who are looking to purchase a new car in the next three months” (okay, I’m exaggerating here, but you get the picture), recruitment at short notice is not as easy.

In situations where timing becomes critical, we inevitably will have to compromise on at least some aspect of the recruitment to meet the deadline. We may have to agree to a broader age target than we would have wanted to test with, or a different mix of genders than is ideal.  These impacts can sometimes be significant on the end result of our projects, because the profiles of the users we test with do not replicate the target closely enough.  This could skew our results, or have the effect of masking significant issues that may have come to light had we tested with the appropriate target.

When we think about all of the factors that are at play in a usability project, the participants we test with are critical to the process. The most carefully crafted research plan will not deliver the insights we need about a target if the participants we test with are just too far off the target of interest. Garbage in, garbage out.

1. Use language that is appropriate for the local audience. It is important that the website speaks to the user in familiar language and not only in terms of product names but throughout detailed content such as terms and conditions.
2. Use images that are appropriate for the local audience. The imagery used is an important branding tool,  used to differentiate categories of content and often are navigable items. The use of inappropriate imagery can be disconcerting and create mistrust. It is important that the images used depict scenes that will resonate with the local audience.
3. Ensure that the iconography and symbols used, are appropriate for the local audience. Icons and symbols that are instantly recognisable to a European audience may not be relevant to an Australian one.
4. Where strict adherence to international guidelines creates serious difficulties for your users, be prepared to bend the rules to ensure the best user experience is provided.

For some further reading, see Christian Arno’s post on Inspect Element.

Although I had no hope of remembering this password, I didn’t bother writing it down because I had already decided out of sheer annoyance to never to use this online process again. Why was my generic password sufficient for online banking but not for this relatively risk-free task? And come to think of it, why should they get to dictate how strong my password should be? As a customer, this should be my prerogative!

Requiring complex password policies not only frustrates customers; it results in higher costs for organisations. Customers will generally either stop using the online process and revert back to more costly customer service processes (increasing call centre demand with their multitude of forgotten password requests) or  write the password down, thereby defeating the purpose of this security measure altogether.

When security policies have such a negative impact on usability, it’s time to rethink priorities. What’s more important to your customers: an impenetrable password or easy access? Incorporate this into your research to find out, or let the user decide for themselves.

Card Sorting exercises are one of the methodologies that fill the standard “toolbox” of most user experience designers. Here at UsabilityOne we use them frequently. to assist with developing site IAs.The concept of using card sorts to observe how users group, arrange and label content gives amazing insight into how users view your content and what relationships they see between items.

Considering how successful a card sort can be, it logically follows that a website that can dynamically support users sorting, grouping and labeling content would successfully evolve into the perfect IA, right?

Not really.

Recently, UsabilityOne has helped with development of several sites that have offered such a feature. These sites included areas where users could upload varying types of content, from business case studies to new inventions. During the upload process, users would give each item a category, sometimes making their own category, whilst other sites had several predefined categories.

The issue that we saw across all of these sites was that users’ perceptions of where content belonged, differed. An item that the uploading user felt belonged in one category would be sought in a different category by other users. Frequently we heard users complain that content was not where they expected it to be, and that they felt they were wasting their time trawling through multiple categories.

What had been overlooked is that a successful card sorting exercise also includes a very large amount of analysis. Labeling trends are isolated, card placement across multiple categories is calculated to see which placement was the strongest, outliers are isolated. Most importantly, the data arising from a sort is used to alongside the context of known user behavior and attitudes, as well as business goals and requirements.

The recommended inclusion of a SOMETHING search tool, as well as user generated tags for each item went some way to resolving the issue. However, the question still remains; is it appropriate to have users decide where content will be placed on your site? In these days of Youtube, Flickr, Etsy and a thousand other sites that adopt this process, it may be tempting to jump on board the user generated content bandwagon. However, these successful sites have been built from the ground up to support this sort of behaviour; their very strategies are based around user generated content and dynamic, loosely defined architectures.

If you are considering allowing users to develop content for your site, it pays to sit and consider some points before leaping in. Will it matter if some content is overlooked by users? Will your users be seeking specific items of content? Are your users likely to be invested enough to properly categorise and tag content? And the bigger question, is this really the right strategy for your site, or would your users prefer a more solid, reliable architecture that has been developed and validated by people who properly understand the content?

Our experience of observing user behaviour suggests that a significant number of users will fail to return to the home page when the site logo is the only means of doing so (aside from the browser “back” button of course). Using the logo as a link to the homepage is not a bad thing; we actually recommend it especially as it is optimal from an accessibility perspective. However, it should not provide the sole means of navigating back to home.

It is difficult to argue that reserving a permanent spot for “Home” in a website’s primary navigation takes up an unreasonable amount of real estate which could be used for other navigation options. After all it is only four characters and “Home” plays a crucial role in in-site navigation, with many users treating a website’s homepage as a base which they return to between tasks.

Take care when starting on a map at the country level as the only way to find locations. Maps like the one below typically rely on visitors zooming and panning controls of that particular mapping application, something not all users are familiar with. Forcing visitors to use the map to drill-down from a country to suburb level can also be time consuming and error prone. When testing the example below, participants who were experienced with using online maps took an average of 19 mouse movements to locate the South Melbourne store.

Users like to be given options so they can choose a means of interaction that suits them best. Some users prefer drilling down using a map, others do not. Displaying alternatives to the map, such as a postcode search or state selection, allows users to choose the option that best meets their needs.

Below is a good example where users are given flexible choices in locating their nearest store. They can enter their postcode for an exact match, drill-down by state or interact with the map. The state selector still gives users an overview of locations, but eliminates extensive zooming on the map from the country level.

As with all features of your site; design your mapping feature so that the user can use it as they wish. Offering multiple ways to interact with the feature means users will be able to find one that best suits them.

The process was slower than I had expected it to be, but the real crunch came at the point of making a payment; my credit card signature needed to be assessed by the self-serve assistant.  It was apparent after a moment or two of scratching my head and looking about like a idiot, that it was I (rather than the system) that was required to notify an assistant that they were required to complete this transaction.  As the assistant was busy attending other customers I had to wait, for what seemed a long time, for my turn.  This seemed completely counter-productive.

I have used my credit card in a number of other comparative self-serve systems recently including car park and public transport ticketing machines.  In these instances signature validation was not required.  Of course, Woollies level of security with signature assessment is a notch above these systems, however, this experience for a first time user will undoubtably put many off from self-serving again.

When you consider how vital credit cards are for self-serve transitional purchasing, surely some revision is required to aid consumer adoption of the service?  I would encourage Woollies to consider one of the following:

FAQs are an old feature of the web, that have somehow outlasted most of their peers. Whilst we have (mostly) done away with animated GIFs, embedded MIDIs and scrolling text, the FAQ section is still appearing on sites 26 years after they were first introduced.

Whilst age alone is not a reason to stop using something, there are many reasons that implementing FAQs on your site is detrimental to the user experience.

Frequently asked? Really?

Do you have an FAQ section on your site? If so, have a look at what is listed there right now.

Are these really the most frequently asked questions from your users? How did you collect them? How many times do your users ask a question before you classify it as ‘frequently asked’?

In our experience, FAQs are actually not Frequently Asked Questions. Instead, FAQs are used for a number of different purposes. Often sites use FAQs as somewhere to put the questions they want their users to ask. Other times it is a place for information architects to put any content that didn’t fit anywhere else on the site. Neither benefits users.

If the content is something that you want users to see, don’t wait for them to go looking for it. It is a big risk to put any important information under an FAQ label, as many user will never look there, preferring instead to look under more descriptive labels.

If the content you are placing within FAQ is content that didn’t have a home elsewhere, perhaps you need to question its place on the website at all. All site content should be developed around the goal of answering users questions before they knew they had something to ask. If any content does not fit into this process, then what purpose is it serving. Anything important enough to put on the site should be important enough to have its own place on the site.

Why do I have to ask you?

So perhaps the content in your FAQ is actually a list of frequent questions from your customers. The next question you have to ask yourself is: why are they asking?

Imagine you run a corner store. If every second customer asked you where the butter was, would you not move the butter to somewhere easier to find?

Or if you ran a cafe and customers frequently asked whether you had soy milk. Would you add soy milk to your menu?

Websites are not different. If you really are receiving frequent questions from your users, something is wrong. When designing a site structure and content, the focus should be on answering users’ questions before they knew they had something to ask. Imagine, for every user who bothered to look up your contact details and get in touch to ask something, many more would have taken the easier route of just going to your competitor.

FAQ. The internet equivalent of a lean-to

During user testing, we recieve constant feedback from users about their thoughts on FAQ. Many refuse to use them, citing past experiences of seeing a page of unrelated, unuseful information. Others prefer to follow more descriptive links and labels, thinking that the site design should put them on the right path. Some users, and a larger group than you may expect, simpy have no idea what FAQs are; it’s not uncommon to hear users say “Facks? What’s that?”.

Regardless of whether they are used or not, FAQs always have the look of tacked on content. Something that wasn’t part of the original design. User either choose to avoid them, sticking instead to the more polished original structure, or venture in and find themselves stepping on a rusty nail or falling through a broken floorboard.

So rather than seeing FAQs as somewhere to put questions and answer, try viewing your entire site as frequently answering questions.