In 2005 there was a huge wave of online shops reworking their ordering processes to make them more usable and accessible to people, which was a sounding success for many companies. These days however more offline stores are trying to expand to the web and are asking for advice. Here are ten ways to improve the usability of your e-commerce site to maximise your conversion rate and help convert ‘browsing your wares’ into ‘placing an order’:

1. Make your products stand out

One of the most important factors of an e-commerce site is the products – people come to your site because of them, so make sure you display them properly. Each product requires an image, a description, technical information (if applicable) and ideally more than one image to show the customer what it is and what it does. Some e-commerce websites are still trying to get away with showing as little as possible – well, those are the ones with the low number of online sales.

2. Relate to the products

Aside from the usual product information highlighted above, it makes sense to give the customer additional information before he / she can make a decision and buy a product. Information such as “Other products you may like” or “People who ordered this item also ordered…” are very helpful. If you want to add even more value, why not allow users to rate or review products?

3. Break up the ordering process

Depending on your website and what requirements you have to order, the ordering process can be quite complex. Typically, users enter a delivery address, a delivery method, enter payment details and confirm the order. I have seen a couple of new e-commerce websites that try to put everything into one screen. This will look daunting, and error recovery (as mentioned here) can become a big problem for users.

Breaking the ordering process up into smaller chunks allows users to go through every required task one step at a time. They will have less to think about and more chance of making sure everything is right.

Your standard ordering process may look like this:

1. Login
2. Choose a delivery method
3. Choose a delivery address
4. Enter payment details
5. Review and confirm the order

.

4. Where are they? Where do they go? – show progress

One of the 10 usability heuristics is: “user control” -> a user should always know where they are and how many steps are still required to complete a process.

Users wanting to purchase an item online would need to know how long they are likely to spend on a website still. Let your users know where they are in the ordering / booking process, and what steps they still need to go through. A simple process as illustrated below may do the trick:

Sample booking steps

.

5. Simplify the ordering process (if possible)

Some e-commerce websites tend to overcomplicate the buying process slightly by asking users to enter their credit card details with dashes (i.e. “1234-5678-9012-3456” instead of “1234567890123456”) or having to enter each batch of 4 digits into their own little box, or having to enter the month in the expiry date (i.e. “Mar 10” instead of “03 / 10”).

It may not sound that different, but it requires a user to think about what they are doing, having to pause for a moment, having to check the fields and – if they made a mistake – having to go back and click on another box to change an entry.

If a customer is already planning to spend money with you, then at least think about how the step could be simplified.

6. Provide help

Throughout the ordering / booking process users may have questions:

Why is that there? What do I need to enter here? Why do I need to enter that piece of information?

Think about the ordering process, does it make sense to you? Can you make certain steps easier by adding a line of text or a notes-field next to it? This is where usability testing does definetly come in handy – let someone other than those working on the site to have a go at it, observe where they stumble, ask a question or are entering the wrong information. If you are asking for a contact number for a person not going on holiday then why not tell them that this is purely for the worst-case scenario if anything happens.

7. Highlight requirements

As with every form we have to fill out, we ask yourselves “Do we need to enter all that??” There is nothing more annoying than having filled out a form, pressing “next” or “submit”, just to find out we didn’t enter a certain field and the form is not validating.

Please highlight required fields, be it through the use of a red asterisk or changing the colour of the text field to a different colour (both ways are very common).

8. Be flexible

One thing that comes always back during user-testing of booking forms is the “post code lookup” section of a form. Some prefer to just enter the details right there and then, others are happy with entering the post code and entering “look up”. I encountered one user who had a post code that did not list her house number for her post code, meaning she could not continue with the booking process, meaning loss of a £360 booking for the website.

Make sure your ordering or booking process is as flexible as possible, potentially even allow users only to enter the bare minimum to complete an order (as in name, address, card details, that’s it).

9. Provide security

Online shopping has been shaken up a couple of years ago with more and more e-commerce sites pretending to be “legit” or having bad security measures in place to ensure your contact and (more importantly) your payment details are safe and secure between you and the company.

It is important that you put users’ security concerns at ease. Make sure you tell users that the ordering process is secure, don’t only tell them that in your privacy policy, but why not also display that piece of information right next to the “payment details” section?

10. Provide a means of confirmation prior to and after the booking / purchase

How often did you go through an online booking or ordering process, just to remember at the last minute that you also needed to buy something else or that you accidentally clicked on the wrong seat or entered the wrong return date?

Having a final confirmation step prior to submitting the order / booking should always be provided, so that users know what they ordered, what they are getting and when the order is coming / when they are going on holiday. This should include information such as:

• The products / services ordered
• The order number / booking reference number
• Confirmed travellers
• The travel dates and flight information
• Tracking information
• Payment information (end digits of the card, costs, vat, delivery charges, etc)

Once a user has placed their order or made a booking, a confirmation e-mail should be sent out to the email address provided. This email should contain all the information listed above and provide an email address and (preferably) a contact telephone number for any questions.

.

Related links:

• 5 steps for improving website usability
• Explaining Usability Heuristics – a quick guide
• On link usability – the art of keeping call to actions consistent

It is not news to anyone that I – like so many – enjoy video games, come on, it is a multi-million pounds industry. Game publishers have sought to expand their marketing influence in a number of new ways, some of them have started using social networking sites such as Facebook, MySpace, Digg, etc to promote their games either via their own channels, or via publicity stunts (Wii Fit girl anyone?). The message is clear – generate interest, generate sales. Since the company I work for has just signed a deal with a UK-based games publisher with Japanese roots and a European charm I have been looking more into the information architecture of this (still rapidly growing) market, which in turn has opened another door or two for additional potential clients.

As with pretty much every website, your website needs to captivate, generate interest, expect interaction from its visitors, and provide enough information for a visitor to make an informed decision and commit to buy (‘buy’ = a call to action to purchase or make an enquiry). You now need to ask yourself:

What are the important browsing routes for a game publisher’s website? Where does a visitor need to go? Who are the visitors? What do the visitors hope to achieve on this site? How do you sell a product? How do you show the publisher in the best way possible – to then show the published products in the best way possible?

For this purpose, let us look at the main focus points of the site we are specifying, looking both at the benefits and considerations.

Please note: while this article is focused on a games publisher’s website, most (if not all!) of the points mentioned here will be valid for pretty much any site.

.

A visitor’s first visit – What am I doing here? What do I want?

Let’s first think about an average user’s visit to a website. I – the user – am coming to the game publisher’s website to find out more about a game, maybe see if the game is suitable for me, if the graphics are nice, what the requirements are and if there are any comments, problems and solutions for the game….and if I want to ask questions about it or if I want to go and buy it.

As with every site, the visitor’s flow is usually the same:

Above: a typical user's navigation through a website, followed by the main 3 questions / reasons for the visit

The information architect’s role is – put bluntly – to facilitate the user’s navigation from the start of the journey (the home page) through the site in the best possible way, having provided the most amount of information for the user to make an informed decision to commit to use the final call to action (the product purchase or the enquiry page).

As I said before, this pretty much applies to every site you will be working on, in this example our user base or target market is the average gamer interested in a game, or the concerned parent to see if the game is suitable for their children.

.

Informing the user – I am here for a reason, inform me

UK Playstation displays a number of clear call to actions to allow visitors to delve deeper into the site

Right from the start an information architect needs to think about what the product or the information is, how the user will make use of it, how the user can find it, how it relates to other products / information on the site, and how to convert the visitor to a customer or (in the sense of user-generated content) a participant.

For the homepage, your main focus point is to show the most important browsing routes, namely:

• Main navigation
• Main featured item (game)
• Featured items (games)
• News
• Blog (if applicable)
• Shop (if applicable)
• Promotional slots (includes banners)
• Ancillary navigation (about us, site terms, etc.) – anything that is not necessarily required to convert a visitor to a customer

This already gives you quite a bit to play with, how much focus you are putting on what item is then considered depending on the actual product the website is selling (in this case games).

Sample screen resolutions on a website prototype (click to enlarge)

As a rule of thumb, your main browsing route to the product should pretty much cover 50% or more of any content above the fold. The ‘fold’ is still considered to be about 750px from the top of your screen (looking at the UK Playstation screenshot [or the live site here] the fold is going through the Little Big Planet image and just under the first news story), and is what should appear on the screen of a 1024×768 browser window without you having to scroll.

This is your main selling space, anything on this area will be seen – and will already influence your visitor in his / her 3 main reasons for being on the site. If the content is designed well, is accessible, usable and in a language the visitor understands then you are on the best way of converting your visitor to a customer.

Remember, only about 5% of all visitors will read the home page in full, so good imagery, striking headlines and easy to spot call to actions and links are key!

.

Coming up in part 2…

In part 2 of 4 I will talk about displaying information for both the existing and prospective consumers or customers and what considerations need to be made to “inform to commit to buy or enquire”. Stay tuned!

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!

We need to design and build as website for a small company offering guided tours for families or groups going to Wales. The idea is to sell the beauty of Wales as well as the services for either pre-set tours or tailor-made tours based on the client’s wishes.

So in effect he had a very good brief in front of him already. He is a very good designer, and he knows a lot about coding, so he was confident in producing a very good website. The first drafts he made are looking very promising, nice graphics and use of fonts. When I asked him how he was setting the site up and link products and information together he looked a bit stumped. “You know, I haven’t thought of that really, I wanted to come to that when times arises.”…So I told him a bit about Information Architecture and how I approach my client’s websites. I thought it might be handy for someone – especially considering that this is why I am writing this blog in the first place

[Some of the stuffhere may sound like stuff you'd know already, but its always good to hear / read it again]

Pre-requisites:

Know the client’s customers

Very obvious, but nontheless neglected at times: who are you actually developing a website for? It is certainly no use if you work on an image and flash heavy website with quirky navigation if the target audience is “45-60 years of age, with dialup and limited internet knowledge”.
At the very beginning of the project it is always good to get some sort of design brief over to your client asking the following (marketing) questions:

• Who is your target market?
• Do you wish to target a certain age range or gender?
• Do you wish to target a certain culture or area? (say for example the audience is the Far East, the colour theory tells us that different cultures / countries think differently of colours)
• And why? (this question may be obsolete depending on the answers)

So already we have a bit of a clearer picture of what we are trying to achieve in the speccing out, designing and developing of the website.

Know the client’s competitors

The most obvious question, who are the client’s competitors? Speak to the client about it, ask him to give you a list of websites in his/her field that he/she considers to be competitors. Most of the time you will get a clearer picture of what is actually expected of you, and you can also take inspiration from these sites. That doesn’t mean copying they already have, it means adding these sites to the list of sites you should research and look into in regards to flow, navigation, look and feel and usability.

[NB: it makes sense asking this question if you are being approached for work, it weeds out the prospective clients from those who haven't even thought about their own website / business]

Know the product – and its userbase

It really helps if you know anything about the product. Say for example the website was about a PDA. You may have one yourself, you use it for its calendar, for texting and as Sat-Nav. However that doesn’t make you part of the userbase yet. I use my PDA for its calendar, its email facilities, its extensive address-book capabilities, for jotting down notes during a call, as a dictaphone and occasionally to get me from A to B. Unless you know the capabilities and what its target userbase is planning to do with it you may well be missing the point (or at least some of them) when working on that website.

In the case of my friend’s project, we are talking about a product in form of a service for families or groups who have not been to Wales before and who are interested in learning a bit more about the country or location they are in. They would be expecting the guide to know the place, to show them around and most likely give them directions or answer questions like “where is the best place to eat” or “is there a shop for this and that somewhere”.

Know the client’s current website – and his expectations

If a client approaches you about a website redesign it is worth asking the client what he/she likes about the current website and what they feel does not work. Is it the colours? Is it the design in relation to the target market? Can users not find the information they are after? Is the way to a product too difficult or is it hidden somewhere among a lot of other content? Do pages not link properly to each other? Are there too many fields for the user to fill out to get somewhere? Or is there just not enough on the site to give the user a reason to buy your product?

Right about now you should have a good idea of what the client is expecting of you and what you need to look out for. In part 2 I will discuss information architecture and user-testing the prototype or blueprint of the site.

Update:

Part 2 and Part 3 are online