On Information Architecture and user-testing – Part 2

Following my previous article about Information Architecture and user-testing you we came to the point where we have researched quite a bit into the client’s company: we know the brand, we know the product(s) and its userbase, and we have acquired demographics of the target market. It is now up to us to design and develop the client’s website.

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?

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]

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.

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!