On Information Architecture and user-testing – Part 3 – Usability testing and Accessibility testing

Following my previous article we are now going to put our website prototype to a first test before we begin developing the website. While the functionality and navigation makes sense to us – after all, we just spent the last week(s) working on it – we need to ensure it works the same way for others as well. We understand how we get from a destination page to the product or trip we are after and finally to the enquiry page – but will anyone else do so as well?

Usability testing will reveal if the flow of the site works, and accessibility testing will ensure that our site complies to any relevant accessibility guidelines.

–

User testing – preparation

Before you begin testing your prototype or pre-live-website with other users you need to make sure
that you:

• Have finished all relevant pages according to the brief / scope discussed. Make sure nothing is missing still
• Have annotated relevant sections, panels or functions: “If you are coming from page X this drop-down will be pre-populated with Y”
• Have gone through the prototype on your own and have made notes and / or necessary amendments where you struggled or had omitted functionality

Once you have reached the point of a project where you would like to invite users for testing, it is time to look for a certain kind of users – the users you successfully identified as the target audience, but also a number of “general public” users who may or may not be part of your target audience. After all, a website can be viewed by anyone. A typical group of users consists of at least 5, preferably 10 users, and should take no more than an hour per user. I hope your / the client’s budget caters for that, as well as possible payment for the users and or refreshments / lunch during the test as well as equipment (such as PCs, desks or cameras).
User testing – preparing your users

Before you being testing your prototype, please make sure that you have given your users (friends, colleagues, students, spouse…) a brief overview of the client and what the client is going to do with the website (such as “The client you are testing the site for is a new company within the perfume industry. The main focus for this website is about informing potential customers about the range and the brand, as well as giving additional information and an order facility”).

What the users need to be aware of:

• The users need to be honest in their responses. If they cannot find a bit of information they are after then it may not be because they are not web-savvy enough, it could just be that you did not link it properly!
• The users will be asked to complete a small number of tasks (“Find a product”, “make an enquiry”, “make a booking”, “find section XYZ”)
• The users need to verbalise what they are doing and why they are doing it. This will help you later on to amend or improve the prototype
• Just like when browsing a website at home, users should take their time researching into the prototype’s offering. If they spend a lot of time reading text and looking at pictures, then let them, after all, this is what the users will do once the site is live
• Inform the users that you will be making notes and that you will answer any questions they may have during testing and that you will explain functionality.

It is important that you yourself take over the role of an observer, and that you let the user do the tasks you asked for without any hinderance / distraction from yourself.

Once your prototype is ready for user testing you can go through any or all of the following options:

–

1) 1-on-1 user testing

This is one of the quickest, easiest and cheapest options: you sit down with a user and let him use the website without any additional equipment other than a notepad and a PC.

After sitting down with the user you explain that you are going to show a prototype for a new client’s website and explain briefly what the company is about, what they intend to sell and what you hope to get out of this session: you want to see if the user understands the flow and navigation of the prototype and if the user finds it easy (or has problems with) finding a product or making a purchase / booking.

To start off with, let the user get a feel for the prototype and how it interacts, with a few explanatory notes (certain prototype creating applications create very rudimentary HTML and may require quick explanation of drop-downs or what items will be dynamic). Then let the user complete the tasks you set out. Stay quiet, answer questions, but do not interfere if a user does not take the route you would have taken.

–

2) Unmonitored user-testing

This type of testing requires you to put the prototype online somewhere (ideally in a private or password-protected network) and send out a questionnaire to your test audience.

What you need to make sure of is that your prototype is very self-explanatory, and that you have added notes on all pages with important functionality (such as changing menus depending on where on the site you came from).

The questionnaire should have a same introduction as you would give at the 1-on-1 testing, followed by listing the objectives of this test and the tasks you are asking the user to do. Each of the tasks should have a couple of questions associated with it, ideally each of them with a rating and an optional comment field. Here is a sample questionnaire, feel free to use and edit as appropriate:

Please download the file here: Whatwasithinking – usability-questionnaire.pdf

–

3) Monitored user-testing

Probably the most expensive test of the user-testing cycle: monitored user testing. In essence, it is the same test as the 1-on-1 test, but this time the user is being video-recorded. Video recording can be a bit unnerving to a user, as such it is very good practise of sitting down with the user and having a very informal chat about what is going to happen and what is expected. Have a chat with the user about anything, it doesn’t matter what, as long as you can get the user more comfortable in participating in the test.
Another way of testing is using two cameras, one for filming the user using the computer, and one for the eye-movement. This is a very expensive way, as it involves a special kind of camera (a normal web-cam would not suffice) and monitoring software, which will overlay the user’s eye movements to another monitor, showing what the user looked at when he clicked his way through the pages. This type of testing is usually undertaken for projects of big (and I mean BIG) clients or public sector / state-run websites.

–

User testing – analysis

After conducting your user testing you will probably have written down a couple of pages of notes. It is now time to prioritise these notes accordingly:

• Critical – usability issues preventing the user from completing a task
• High – usability problems causing frustration, misinterpreting information given or frequent
  attempts to get to a result
• Medium – usability problems causing minor delays or problems which are overcome once the user understands or is made aware of errors
• Low – cosmetic problems, wording problems

Once you have your findings and analysis completed you will want to write a report to the client as well as an action plan on the next steps of the prototype and consequently development.

–

Accessibility testing

These days it is becoming more and more important that websites (especially websites of bigger companies, public sectors and government-run) comply to certain accessibility rules.

Accessibility testing means to combine software tools with human use and judgment. Sadly, there is no
automated way to check if your website complies with the Section 508 provisions or the Web
Content Accessibility Guidelines.

–

Accessibility testing – the automatic / software tests

Automatic tests are fairly straightforward: does your website comply to certain standards? Does it validate successfully?
Tools to test are plenty, here is my suggested list:

• FireFox extensions: FireBug, Accessibility Extension, and the JAWS-emulation FANGs are vital!
• W3C validator
• W3C CSS validator
• A-Prompt’s Web Accessibility verifier

It is worth trying all of them, as errors can easily be checked and consequently amended in the development phase.

–

The manual tests

When doing manual accessibility testing (human accessibility testing) you need to assess:

• Whether the website complies with any government set guidelines
• How language and visual cues, tags and labels are used
• If the website is compatible with as many current browsers as possible (at the moment we usually test for IE6, IE7, latest version of Opera, Safari for PC and Mac, Firefox 1.5, Firefox 2 and Firefox 3)
• How easy the website is to read and scan over
• If common fonts are used or (if uncommon fonts are used) replaced
• Whether a style sheet has been used to control the site and whether the site is usable and accessible without stylesheets
• If the website uses any kind of scripts or Flash, and if it is still accessible without
• Whether the website sports efficient navigation

Once you went through the tests above, it is worth writing up another report to the client, again with an action plan on where to go from here.

–

Closing comments

User and accessibility testing comes in all kinds of forms and flavours, some cost money, others just time. My suggestions above are a small part of a best-practice approach that I have been using over the last couple of years, and so far it has been serving me well, with about all of our sites being fully accessible and adhering to all current web standards.

Disclaimer
Again, this was just a short run-down of this vast and complex subject. Some of the above may most likely be different from how you have learnt (or read up on) information architecture and accessibility and usability testing. To be honest with you, so have I when I first came into contact with the industry I am working for. You are working in an industry that is most likely not considered the “average website”, be it websites for the music industry or landing pages, B2B sites or what have you. The user base is sometimes entirely different, you can expect your users to be a lot more experiences in some industries, and maybe less savvy in others. Certain heuristics or standards may not necessarily apply. I am not telling you to go and use ‘my’ methods described above, this is just how I work, and it some of it may just not apply to you. At the end of the day, looking at your industry, your client’s requirements, the client’s competitors and its target market are what will give you the best ideas for approaching your project.

I hope you enjoyed reading the article and if you have any questions or suggestions, feel free to comment 🙂