The bedrock of a user focused site...

Information Architecture

  • When and Why

    Many websites have an Information Architecture (IA) based on an ‘organisational’ view of the site’s content that does not reflect how users go about achieving their goals. Having a user-centred structure for a site IA (i.e. how user goals are chunked into a hierarchy), and having labels that are understood by users, is key to getting users to their goals quickly and providing a good user experience. The best way to develop a usable IA is to involve users in its development.

    IA research is ideally done at an early stage of website development, after the user goals the site is to support have been established but before any work on site design and layout.However, existing sites with a poor IA also benefit from this type of research.

    Read More
  • Our Approach

    Web Usability adopts both qualitative and quantitative approaches to IA development and testing. During development, we may use qualitative research to gain insights into user behaviour and the language used, quantitative research to understand the closeness of the relationship between user goals, and expert card sorting to build an initial structure. However we go about developing the initial IA we then always test with real people: during testing, we undertake both one-to-one qualitative lab based testing and remote testing with larger numbers of testers to assess the effectiveness of the IA and refine the structure.

  • How we do it

    IA development is in two parts:

    • Developing a prototype – this involves understanding how users ‘chunk’ tasks and the labels users give to these chunks, so that a prototype IA can be drawn up
    • Testing a prototype – testing the prototype with users: we undertake both qualitative face-to-face research and remote testing


    Developing an IA Prototype

    In order to develop the prototype it is necessary to think about how users group tasks i.e. how they ‘chunk’ them and what labels they give to these groups. The starting point is to identify in detail the user goals the site is to support, often there are 50-100 or more supported user goals. This may require user research to identify these goals if they are not understood – and to identify the ‘top tasks’ that users want to achieve. It also requires a clear site strategy so the user goals to be supported (and not supported) are clear.

    Having identified the goals to be supported, these are then subjected to a card sorting exercise where all the various user goals are written onto individual cards and sorted  into groups. We tend to use open rather than closed card sorting (i.e. with open card sorting users choose the labels for categories rather than putting them under predefined headings) as this does not prejudge the groupings or labelling used.

    This card sorting can be conducted in one of three ways depending on the complexity of the IA and the budget available:

    • Expert card sorting – where a Web Usability consultant will sort the cards using our experience of how users are likely to look for content
    • Qualitatively with typical users – Respondents sort the goals into groups that make sense to them. During this sorting process, a Web Usability moderator probes to understand why the respondent is sorting the tasks in a particular way, and what labels they would attach to the various groups. An initial top level sort may be followed by sorting each group in turn into sub groups. The moderator also explores respondents’ confidence of the ‘fit’ of goals under these headings
    • Quantitatively with typical users – A more comprehensive approach to IA prototype development involves larger numbers of respondents so that the outputs of a card sorting exercise can be subject to cluster analysis to identify the closeness of the relationships of the groups into which respondents sort the goals: the advantage of the remote card sorting is that it gathers feedback from a larger number of respondents, the drawback is that there isn’t the opportunity to probe ‘why’ as in moderated research

    Following the card sorting, Web Usability then develops the prototype IA.

    Testing the IA Prototype

    The prototype is ideally tested and refined through a series of research sessions with representative target users

    Initially, Web Usability tends to undertake qualitative testing – ideally two or three iterations – in order to test the IA and be able to get user insight into ‘why’ certain links or chunks  don’t ‘work’ for the tester. The research is conducted as follows:

    • Each research session is typically conducted at our premises and takes place over one day. The session is attended by 2-3 client personnel.
    • The research is split into two parts: user testing in the morning and consideration of the results in the afternoon to refine the prototype IA
    • Prior to the test day, Web Usability agrees a set of user goals with the client to be used in the research – normally the same goals as used for the prototype development
    • Web Usability recruits the testers – profiles of which are agreed with the client
    • Web Usability prepares a simple HTML representation of the prototype IA to be used in the research session based on the outcomes of the prototype development research
    • Each tester tests the prototype for c.40 minutes individually.
    • The testers are asked ‘Where would they click’ to achieve each goal through as many levels as there are in the prototype IA. The results are recorded on a template.
    • On the same day, following the user testing, Web Usability facilitates and contributes to a discussion to produce a revised prototype information architecture for the next round of testing
    • A report is produced summarising the research, analysis and detailing the revised prototype IA

    Then Web Usability will test the prototype IA using a remote online IA testing tool – this enables a larger group of 20 to 30 representative users to test the prototype IA at a time and place to suit them:

    • Testers are recruited to match the required tester profile, and are approved by the client
    • They are then provided with a web link and login details to enable them to access the prototype under test
    • When they access the prototype on the remote tool, the testers are asked to tacle a series of tasks by clicking through the IA links on the prototype
    • Testers are typically asked to undertake 25 to 30 tasks, agreed in advance with the client and reflecting the goals as used for the prototype development, and the tool takes about 30 to 40 minutes to complete
    • The remote tool captures the paths followed by the testers and records the success rate, (defined as reaching the right destination after the first or second attempt) and identifies any problem areas, and the alternative paths that testers took
    • A report is produced summarising the research, analysis and detailing the revised prototype IA


    While we are happy to undertake as many iterations of testing of the prototype IA as may be required, we also offer a training service so that clients can undertake some of this research themselves. Typically, we run a single iteration and, during this, train a member of the client’s staff in the required facilitation skills and other techniques so they can undertake any additional research sessions.

    Read More
  • Outputs

    The output of the research is an information architecture for the site, which is detailed in a series of reports:

    • Following the development of the prototype
    • Following each iteration of qualitative prototype testing – including videos of each of the test sessions showing the screen being viewed, tester head shot, and the audio of the session
    • Following remote testing, a detailed analysis of the testing analysis