Aside from a number of fixes, the most notable features of this version are:

• Sketch Effects – Sketch Effects enable you to give your wireframes a more sketchy, grayscale look and feel to allow the audience to focus on the information architecture, interactions, and functions of the prototype more than the “finished” look
• New Wireframing Tools – wireframes are now faster to build and easier to maintain by adding Global and Page Guides, a Location and Size tooltip, Format Painter, ability to Copy and Paste. Annotations, and a new Custom Style engine where custom styles can be applied to rollovers.
• Improved Text Editing – Axure RP was upgraded to use WPF in the Microsoft .Net Framework 4.0.  The new text engine allows information architects to add text editing at zoomed levels, line spacing, and Open Type Fonts. There is also some text padding in shape widgets.
• Page Styles – you can finally center pages, apply background colours and background images without having to do it manually!
• Richer Prototypes – Axure RP6 now has animations for moving and fading, Math and String functions, Drag and Drop interactions, and new Dynamic Panel Events to respond to moving, changes in visibility, and changes in state.
• More Specification Control – You are now able to organize the content, optionally include headers, filter widget tables by annotation values, generate a master usage report, generate all of the widget text, configure column widths for two column layout, and configure the screenshot size. And you can also format the page notes and annotate master instances.
• AxShare integration – You can now manage an account of up to 10 active prototypes. It supports RP files (up to 10 MB) created in version 6 or earlier and all generated prototypes will have the version 6 skin. You now also have access to a new Discuss tab next to the sitemap in the prototype (which you can disable), as well as a page for viewing the discussion topics in your AxShare account.

Axure RP 6 is available for both PC and MAC here.

Good times!

That is until the time comes where a new project is being started or requirements are being updated. Usually then some sort of “rivalry” will ensue, and in 90% of the cases it will be between a designer or information architect and a developer or development coordinator. Scope was not fully explained or defined, the design is too complicated to build, or data is not coming from the sources it was meant to.

In those times frustration can quickly result in stress and lack of commitment to a project. Let’s see what we would do to remedy that…

1) Information Architects: Start off on the right foot and plan ahead

At the beginning of a project make sure that you define scope and requirements clearly. Nothing is worse than a badly set up and planned out sitemap or wireframe without annotations or data specifications. To create a clearer mindset it is always best to let a lead developer for the project to have a look at the sitemap/wireframe before it goes to the client to ensure all requirements are met, what the developers will need to consider and where data needs to come from. It is also good practise to let developers come up with a timeframe of how long the development will take based on the wireframe.

2) Designers: Plan your designs

This is very self-explanatory, but you would not believe how many designers (especially freelancers I worked with) are getting it wrong: make sure you understand the intention of the site and its requirements. A simple brochure-style site has and entirely different look from a travel booking website or an online shopping website.Make sure you look at the sitemap and wireframe and if unsure about functionality or what development tricks (AJAX, Flash, JS) will be used then ask questions!

3) Designers: Form follows function – or: practical design

Websites are here to wow us – but will a Flash and graphics heavy website really do the trick when all a user wants to do is log in and find out if his holiday booking went through? A stunning design is great, but you also need to take the purpose of the site, its users and their habits or actions while on the site into consideration. Visitors or users of the website need to feel comfortable being and interacting with the website.

Additionally, avoid Flash-heavy pages or content: aside from not everyone being on fast broadband, Flash intros are a thing of the past, and Flash content still cannot be indexed properly and disallows users from bookmarking important or relevant pages properly.

4) Information Architects / Designers: Understand the tools of the trade

Keep bookmarks for development tools handy!

While you may not do any hands-on coding it makes sense to at least understand what certain development tools, what their limitations are, and most of all what other developers manage to do with them. Brush up on developer tools such as AJAX, MooTools, jQuery, CSS, Flash and xml-integration. Keep a list of development bookmarks not only for that reason, but also to then find a solution together with the development team to make a certain effect or part of functionality working – and it gives you a good idea what other developers are doing to stay on the forefront of development techniques.

5) Designers: define interaction

Following on from the previous point, make sure and be clear about how certain tools are going to be used on the site. More and more opportunities arise where certain functionality can be used, interactive login-panels, auto-updating shopping baskets, interactive flight-checks, Flash-driven maps… anything is possible! But make sure you understand that these interactive development stages can take up a lot of time, so it is best to check with the project manager / development leader to see how much of the budget has been alloted to this stage and if you may need to cut back for this phase.

6) Designers: define and share responsibilities

For a designer a project is not finished once the PSDs are sent to the development team – be sure to stick your nose into the development process occasionally to make sure your designs are implemented correctly and that they developers have all they need. It may be that you need to rethink / redesign certain panels or call to actions or that you will need to resupply certain pages, panels or button styles.

Following on from point #4, it might even make sense helping at the CSS / HTML cutup to not only help the developers, but to get an understanding how your design is looked at and what needs to be done. Knowing CSS / HTML cutup (even in parts) is a really valuable asset these days!

7) Information Architects: capture information, the right way!

The buzz-word for years is “data-capture” – getting visitors to a website is one thing, but making sure they come back and leave their details is another. Make sure your forms are easy to understand and not pages and pages long if you don’t want to scare them away, and only ask for data necessary to the task – why should I give you my date of birth or post code if all I want is a newsletter??

Also, do make sure you have a tick box to opt in and out of marketing materials such as direct mail or newsletters, and have a clear call to action to your privacy policy.

.

I hope the tips help keep you and the development team working successfully on all your projects!

I was asked by a couple of fellow twitter users to divulge my plugin list, and since I keep track of them myself at times I thought this post would come in handy for everyone.

.

Starting with the basics – the toolkit

With a setup of IE5, IE6, IE7, FF2, FF3, Safari, Opera 8.5, Opera 9.6, Google Chrome and Lynx (on 4 different operating systems) I prefer to keep things in order and easy to maintain and distinguish. That is why I tend to set up my FireFox browsers with Mr Tech’s Toolkit. This toolkit is pretty much a Swiss Army knife, allowing you to install a multitude of extensions (even allowing you to make some older / newer ones compatible with your version!) and editing your Firefox version including the title bar. It is also quite useful when you are installing a number of extensions at once (say when reinstalling your browser from scratch) as it can disable the waiting times and automatically download / install updated versions.

Download MR Tech’s Toolkit

.

…and the usual suspects

Here are three tools you should never work without:

.

Web Developer Toolbar

The Web Developer Toolbar - click to enlarge

The Web Developer Toolbar plugin enables you to check your website’s content with and without styles, scripts or images, it can outline all form and layout elements, you can resize your browser window to any resolution, and – and that is what I use it for mostly – it enables you to validate the website’s HTML and links as well as against Section 508, and the Web Accessibility Initiative’s guidelines.

Download the Web Developer Toolbar

.

Firebug

Firebug in action - click to enlarge

Everyone knows it, everyone loves it. In a nutshell, you can edit live pages on the fly (temporarily and only in your browser of course), be it its html, css or even javascript. A wonderful tool for every developer, and for accessibility purposes it has a lot of options for you to check if scripts cause any problems or if other items can be done in CSS rather than graphically, or if the website you are browsing loads quickly or if any elements cause slow-downs or break.

Downside of the addon is that it is quite resource-hungry, and if the page you are on is using a lot of scripts you can expect either intermittent stand-stills or complete crashes. Then again, this is most likely because of that site being developed really badly in the first place

Download Firebug

N.B. If you are looking for similar fuctionality in Internet Explorer, why not download the Internet Explorer development toolbar from here?

.

ySlow!

ySlow in action - click to enlarge

ySlow is a Firebug addon developed by Yahoo based on its best-practice web performace guidelines. It adds a new tab to Firebug and enables you to see how well the website is performing based on a grade system, followed by suggestions on how you could improve loading times and scripts.

In addition, it also calculates the total size of your web page (for both empty cache and primed cache) and is able to list all the components of that page including load time, size and HTTP response headers.

Download ySlow (requires Firebug to be installed)

.

Usability and Accessibility extensions for Firefox

These are the main tools I am using almost daily. Please note that some plugins may be doing the job of others, however I am used to the way I use certain tools, so I am happy to ignore that fact.

.

Fangs

Screenshot of Fangs - click to enlarge

I was working on a project a couple of years ago where I was helping a charity to make their website accessible for their blind users. Seeing (or rather not seeing) a website in a completely different light made me realise that we take a lot of things for granted these days, and ever since then I wanted to make a difference, pushing website accessibility in every project I am working on. And Fangs helped me a lot.

Fangs creates a textual representation of a web page similar to how the page would be read by a modern screen reader. Fang generates a text-output of your website (saves you listening to a screen reader and having to rewind or forward it), showing you – literally – how your website will be displayed / read using a screen reader. Fangs also displays all headers and links on that page, enabling you to see which links will still require rewording or if some links are clearly not easily to be found.

Download Fangs

.

Firefox Accessibility Extension

Reporting feature - click to enlarge

One of the usual suspects when talking about “web accessibility” over the last couple of years, and the guys over at the Illinois Center for Information Technology Accessibility have done really good work with this one. Be it a quick report of your site (see screenshot to the right), showing up where forms lack labelling or listing all objects and their problems – this extension does quite a bit. Add the ability to validate your site against a number of W3C specifications and you are good to go!

It even has a bit of SEO value as it can list all headings and links (including alt  tags and title tags) at the click of a button, and it allows designers to check their website design for contrast and background imagery.

Download the Firefox Accessibility Extension

.

Wave toolbar

WAVE's error reporting in action - click to enlarge

Next to Fangs I feel that the WAVE toolbar is probably one of the most useful plugins for checking for accessibility issues or omissions. What makes it unique in a way is it can display the website you are testing in a number of different ways:

• Display any errors on your site (such as missing alt-tags, missing labels, incorrect heading orders or hidden content (see screenshot on the right)
• Display structure or order of your div’s, tables and headers
• Easily switch between outline or text-only versions of the site

Especially when working with sites that require DDA ‘A’ or DDA ‘AA’ standards this plugin will come in very handy.

Download the WAVE toolbar

.

SEO extensions for FireFox

I must admit, I am fairly new to search marketing, I have only started really looking into it about 15 months ago, and I am still trying to get my head around a couple of things here and there. Here are a couple of plugins I find very valuable in my day-to-day SEO activity. Again, some of the plugins probably do the same job, so feel free to experiment.

.

SEO for FireFox

SEO for Firefox XRay feature - click to enlarge

SEO for FireFox is a very handy plugin, it was designed to enable search engine marketers to evaluate the value and competitive nature of a market much easier at the press of a few buttons. SEO for Firefox pulls out a lot of data for your site at the click of a button: Page rank, domain age, page links, .edu links, Alexa rating, DMOZ information, whois, links from sites such as del.icio.us or Technorati…all in one quick screen. Sadly, it doesn’t export that data in a handy file, but hopefully a future version will.

Enabling SEO for Firefox enables you to see additional information for each search result in Google, such as PR, Age, links, Alexa rating, DMOZ, etc, which can be quite handy when it comes down to quickly checking your competition for a search phrase.

A few versions ago the guys at SEObook added an XRay (see screenshot to the right) to the extension which displays a lot of useful information such as header links, incoming and outgoing links, meta information, keyword density and the ability to export all links into one csv file.

Download SEO for Firefox

.

Search Status

Search Status and its functions - click to enlarge

Search Status is a tiny plugin at the bottom of your status bar that allows you to see Pager ank, Alexa rank and Compete rank in a handy little progress-bar format. Obviously that is not all, you can check Alexa incoming links, Alexa related links and back links from Google, Yahoo! and MSN. A handy combination!

Additionally, you can check out the robots.txt and sitemap.xml of the site you are looking at. Again, if some of the reporting features such as the Link Report could be exported somehow then the plugin would have even more value, we’ll see what the future holds.

Download Search Status (if that link doesn’t work – like it did for me – here is the direct link to the author’s site)

.

Alexa Sparky

Sparky: traffic trend of a website in a small graph in the status bar

This is a plugin that was only recently recommended to me by my good friend Matt Lewis. Alexa has provided a FireFox plugin that enables you to view the traffic trend of a website you visit in a handy graph format, together with the actual Alexa rank.

Additionally, Alexa Sparky allows you to view related links to this site (where do most users go after visiting this page?) and enables you to search the web for your site and find all links linking to it (though this seems a bit broken on occasion).

Download Alexa Sparky

.

Raven’s SEO Toolbar

The Design Analyzer in action - click to enlarge

One of my latest additions to FireFox is the Raven SEO toolbar. The guys behind Raven SEO Tools have done a great job at integrating a functional toolbar to tie in with their SEO tools suite. The toolbar allows you to analyze a website for backlinks, top keywords based on subject, and a cool ‘Design Analyzer’ (see screenshot to the right). What this does is it checks your site for a semantic structure, for page content, depreciated HTML, inline styling, outgoing links and – my personal favourite – it checks your site in the Lynx browser.

The toolbar also enables you to add link details to the website you are on, meaning you can easily keep track of which links you requested, which ones are active, inactive or declined, and it keeps track of the contact details and original page ranks of the domains you requested or exchanging links with. Handy? Definetly, saves my keeping track of that in Excel!

The two minor downsides of the toolbar I found are that you will need to insert a new Google Analytics tracking code (you cannot take over your own analytics account it seems) and you are unable to check for analytics or scheduled reports through the toolbar itself. Nontheless, the toolbar’s analyze tools are great and work very well, and the link details tool is working exceptionally well.

Download Raven’s SEO toolbar (read more about Raven SEO Tools)

.

Are you using an accessibility, usability or SEO extension that has not been mentioned here? Please share it with us!

.

Related reading:

• On information architecture and user testing – accessibility and usability testing
• On usability and accessibility – please display PDF links properly!
• 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!

As a designer you have probably faced a similar situation before – can I or can I not change the link colours on certain pages to keep a consistent look and feel?

Yes, you can, but you shouldn’t ever. Here is why…

.

Where are they now? – Where can they go?

The simple truth is: links are the way to navgiate around your site. Every user of your site will always ask 3 main questions: “Where am I?“, “What can I do?“, “Where can I go?“. Findability is a key to converting your visitors to customers or returning users of your website.

The importance is to make users not work their way through your site, but to give them a pleasant experience when browsing through your site and its products to then make an informed decision wether or not to make a purchase or enquiry – or to return at a later date again to see what is new.

.

“Where am I now? What can I click on?”

Say for example you change all links, all clickable product headlines and all “read more” links on your site to orange, the main section colour. Since all your links are now a different colour from the rest of the site your users will in all cases spend a lot of time trying to figure out what is clickable and what isn’t, usually ending up in trial-and-error (especially if pages following this page are in another colour again) or giving up trying to figure out how to use your site. Colour differences are often used to indicate different areas of a web page, provide feedback and highlight headings and selected areas of text. With all these uses, care needs to be taken so that colours are chosen to make it easy for any user – no matter how experienced or inexperienced with using websites – can distinguish between what is text, what is a headline and what is a link. As such, changing link-colours throughout the site will result in confusion, as call to actions change or may not even be visible as ones.

Case study

Case in point, I performed a study with 23 individuals (aged 25 – 35) asking them to have a play with a website prototype and perform a couple of simple tasks (“Find information about product x”, “make an enquiry about product y”). On the prototype itself I changed a couple of pages’s links and buttons entirely, still the same sizes, but entirely different colours.

We began the test by giving each user an introduction to the project and what we expect from them today. We gave them a brief outline about the project and what tasks we would need them to perform. The test was monitored by sitting at a distance to the user, making shorthand notes. All 23 of the audience hesitated at these different pages, 18 out of 23 (78%) stopped the test, asking if this page was un-finished or if there was something wrong with the system.  14 out of 23 (60%) began randomly clicking items “to see what they did”, while 5 (21%) clicked the “back” button, trying to find another – “more comfortable” – way to the information.

This is obviously just one quick study, but it is already giving you a clear picture what to look out for.

.

A best-practice approach

When it comes down to links and call to actions, it is always best to follow a couple of guide lines:

• Don’t make non-link text within copy the same colour as link-text
• Make links change colour or display-value (bolder, underline) when hovering and another colour when visited.
• Graphic-based links (buttons, panels, etc) should be clearly distinguishable from the area / graphics surrounding them, should have a label and have text embedded in them
• A graphic referring to and adjacent to a text-based link (such as a hotel picture above the hotel title on a search results page) should be a link too (and have an alt-tag)
• Tabs should at the very least have a “normal”, “hover”, “selected” and “pressed” state

.

Related reading:

Derek Powazek – Where am I? (A List Apart)
Jakob Nielsen – Visualizing Links and Change the Color of Visited Links (both Useit)
Nick Usborne – Helping Your Visitors: a State of Mind (A List Apart)
Roger Hudson – Navigation Accessibility: Menus and Links (Web Usability) (Web Usability)

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