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

Many of the designers I worked with in the past have then gone and worked on first mock-ups of the home page and a product page – nicely designed and with a bit of flash here or there – which they then sent to the client to get feedback and develop a new or final draft of these pages. And then they went off and started developing the website, without much (or any at all!) time spent on the information architecture or usability (and accessibility) of the client’s website. In today’s article I want to go through a couple of best practice approaches to information architecture and usability for Business-to-customers (B2C) websites.
To start off, I would like to let you – the reader – know that I will not quote Jakob Nielsen’s Usability Heuristics. I am writing about how to apply them to the industry I have been working for over the last couple of years, and I feel that it is necessary to step away from these ‘heuristics’ and use your own head and apply them based on the industry you are working for.Right, let us get right to it.

-

Creating a sitemap – the foundation to development, design and costing

A sitemap is a very holistic and flat version of a website that can show the client how you would like to approach the different browsing routes to a project. The idea here is to plan out exactly what pages you will need to then build the whole website. How does the destination route working? How does a user get from reading a news article on the website to a related product? Where to search results lead the user to, and where do they come from?

A sample sitemap - click to enlarge

On the right (click on the image to enlarge) you will see a snippet of a sample sitemap that I have prepared for a recent client of mine. These “multi-coloured squares” represent different sections within a website (in this example the purple section defines a destinations-route, from a country page down to the product, its detail pages and lastly a link to the booking process). Each page links to another one (or different ones), to describe possible routes of a user to get from one page to the next.

Obviously you do not have to create a sitemap in Photoshop, if you have Excel you can do the same, not as pretty, but it does the job. Colouring different sections makes sense simply because it makes it easier for a client (and yourself!) to make sense of each section – and ultimately it makes sense for quoting and pricing as well later on, for example if a client wants you to add more information, or if you need to put costs down.

A sitemap does not necessarily mean that you will be needing all these pages: you might for example have set up the product to be displayed on a number of pages, overview, gallery, technical features and prices for example. However, during later stages it could be that there is just not enough information for that many pages, and it could just be that most (or all) of the information is on one page!

-

Creating a website prototype – specifying page content, look and feel

After a sitemap you can always go and work on the designs already. However, when it comes down to working on corporate B2C or B2B sites it makes sense to step into the shoes of an information architect and specify the pages prior to designing and developing the website.
So what does Information Architecture mean? I tend to explain it to students in with the following sentence:

And information architect’s role is to go and specify the pages of a website following both the research carried out onto the target market and the products and the competitors of the client as well as the best practice approach to allow the user to get to the product of the website with all of the information he / she requires to make a sophisticated decision whether or not to buy the product.
As the information architect you are now in the unique (but difficult) position to specify a best practice approach to selling a client’s products. Effectively, you are going to be working on a blueprint of a website. Similar to the architect’s role of drawing out a blueprint of a house his client will be living in you are working on a blueprint of a website your client will be expecting to sell to his users.

The reasons you want to work on a prototype or blueprint are to:

• Ensure all requirements are met
• Create an accurate simulation of the website’s functionality and navigational flow
• Eliminate inconsistencies throughout the project
• Define the product structure of the website and how to get there from what stage / page
• Eliminate having to go back to do last-minute changes to either pages or the whole product structure
• Provide the best user experience for this new website and prepare scenarios of what the user will be looking for and how
• Provide a means of reference to the developers and is unambiguous in its definition
• Allow user-testing at a very early stage in the process before developing the full website

The tools for making a blueprint depend entirely how accurate you want to make it. I have seen prototypes done in Excel , Powerpoint or Visio for example. I prefer using a program called Axure RP4. It helps me create annotated wireframes, navigational flow charts and even generates an HTML prototype to be viewed and tested by the client.

[N.B. I prefer using Axure RP4 as I am used to it, alternatives are iRise Studio, LucidSpec or Serene Composer for example]

A sample wireframe - click to enlarge

On the right (click on the image to enlarge) you can see a thumbnail of a recent blueprint I made. Don’t be worried by the colour, I tend to use a uniform colour scheme to highlight the fact that this is in no way final graphic design and that it shows just a proposed approach to the functionality and navigational flow for the client’s website. To begin such a prototype it is best to have the sitemap in front of you, as this is the base of the number of pages you need to set up (see the left hand column of the screenshot) and to give you a clearer picture of how to get to where and which pages will require cross-links to each other.

After you have set up the number of pages you require and maybe made a note on each on where you need to link to from here or what information this page needs to hold you should continue working on the navigation: whether you are either top navigation or side navigation (or both!), you will need to consider how you want your users to interact with the website. Remember, in the Western world we are reading from left to right, top to bottom. Best practice is having navigational items (search functions, links) that affect the main content area on the left hand side (actually this blog would already be seen “bad practice” if it was a B2B or B2C website!) or the top part of the page.
Your next step will be laying out the content for the whole of the page. To make your job easier I would advise you begin with the homepage (obviously) followed by the product pages and the main browsing route (be it “destinations” or “products and services” to name two cases).

-

Considering screen resolutions when developing your prototype

If you are building a new website for your client it is best to speak about for what resolution you are going to build the site. According to the browser display statistics by W3Schools we can see that beginning of 2007 only 14% of all users were still using a display resolution of 800×600, with January 2008’s figures are probably around the 11% mark for that resolution I would think. This means for us though that if we specify a prototype for a website on a resolution higher than 800×600 we are effectively running the risk of 14% of our target user base not being able to see a part of our website without having to use horizontal scrolling.

Referring to the prototype screen shot above, I have built the website for a 1024×768 screen of above, but I made sure that the information on the right hand side can always be classed as additional information not necessarily required by the user to make an educated decision about whether or not to book a holiday with my client, with the same call to actions following both in the main area as well as the right hand side.

Screen resolutions for a website prototype - click to enlarge

Not only the right hand column may “suffer” on smaller displays, but so does the content of the whole website. Look at your browser window now, do you have any tool bars installed? Are you using your browser in full-screen or in a window? As a rule, try to put the most important information towards the top of the page.

Looking at the screen shot to the right (click on the image to enlarge), users with different screen sizes will inadvertently see more – or less – of your website. As such you need to make sure that the most important browsing routes and products/offers are geared towards the top. This doesn’t go for the homepage only either, this is an important point to think about for the whole website with all its pages. I as a user am not interested in a site that shows lots and lots of big photos, but requires me to “work” to get to the content or navigational items to even get there.

-

Finalising the first draft of the prototype

Once you have set up a concise first draft of all your pages of the prototype it is time to linking the pages and navigational items together. Again, your sitemap may prove a very useful first step to this. You will also notice where you can add additional features such as “related information” boxes or links. You can already unify the number of different image-sizes and you can annotate how certain aspects of the website work (for example “the search function will pre-populate the destination field depending on what country you are looking at right now”). I usually write a small checklist prior to the first draft which I can then work off and compare what you have done and what you still need to do. Here is a generic checklist of mine, feel free to use it:

• Does the homepage have all necessary items (search, featured slot, main browsing routes, and highlighted slots)?
• Do all items of the main navigation link to the relevant pages
• Does the browsing route (for example “Destinations route”) make sense? Is there enough information or featured items on each stage (country -> region -> city) to allow the user to make an informed decision if he / she hasn’t been to that country before?
• Do I know where I am and how I can get back to where I came from? Do I need breadcrumbs?
• Is there a clear call to action? Does it make sense?
• Does the search results page make sense? Can I filter it? How?
• Have I annotated all necessary items?

Once you have worked your way through your list and it makes sense to you, you can then begin generating the prototype for a first preview.

-

The first test of the prototype

It is best now to first of all test it yourself. You have had probably the most input into the project until now, you have probably been to the initial meeting with the client and you have gathered all possible resources from the client and through your own research. With the prototype in front of you, you should now approach it in the mindset of a new user, who hasn’t been to that website before. Depending on your target market, pretend you are one of the following types:

Business man, who has little time on his hands and needs to find a product quickly to see if it interests him at the first time of using the website, and who then later comes back to the website to read more about it.

Family father who in his lunch break is looking for a family holiday who wants to find something suitable for himself and his wife and maybe some activities for the kids

Retired person with a lot of free time, looking for a cottage or lodge to spend a week with the grandchildren in the country side to do some sightseeing, but still near to a town or village to go out in the evenings

Make notes, write down what you – the user – liked and where you struggled finding your way to the product, or the way back to where you came from. Note down what did not make sense to you, be critical and compare your prototype to competitors’ websites.

-

Conclusion of part 2

We have now finished with gathering information about the client, the brand, the products, the user base and the target market, and we have finished preparing and self-testing our first draft of the prototype. In part 3 I will discuss further user and usability testing as well as accessibility testing and how to deal with feedback from clients before we go to quoting, designing and development of the final website.

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.

If you did enjoy the article then please do let me know and leave a message. Thank you

[Update]: Part 3 of Information Architecture and User Testing is online!