TaskArchitect is not just a tool for task analysis. This article, by usability consultant Melanie Walls, records the experiences of a usability consultant using the software to design an Information Architecture.
We were facing the challenge of developing a navigational structure that would enable a large number of users with a variety of job roles to access hundreds of functions, without creating an excessively deep or wide hierarchy of system functions at each level. The user interface was browser based, sharing many of the characteristics of a website.
We also had to ensure it was:
- Free from duplicate functions
- Structured in a way that allowed infrequently used functions to be found easily
In order to be successful, any system must be structured in a way that users find easy to understand and use. In the context of websites, the structure is often termed the information architecture, but the principles can be applied to any system where users need to find their way around. A good structure enables novice users to guess where a particular function or piece of information might be found, and to get it right most of the time. Even experienced users benefit – they may learn where common functions are even if the structure is poor, but will often find themselves in the same situation as a novice when accessing functions or information that they use infrequently.
Two of the key design principles are to:
- Ensure all parts of the system are easy to find
- Ensure frequently used parts of the system can be accessed quickly
These apply to any system, irrespective of whether the user interface is a website, a menu bar, or physical buttons.
We decided to use TaskArchitect for several reasons. Firstly, it is very well suited to iterative design. In developing the structure we were expecting to make multiple changes, and TaskArchitect allows the analyst to move tasks around easily. Secondly, we wanted to be able to share the developing structure with the client, and TaskArchitect allows diagrams of the structure to be quickly exported to Visio for sharing.
We started with a spreadsheet provided to us by engineering colleagues. It contained literally hundreds of functions. The first step was to identify some high level functions, and enter them into TaskArchitect as level 1 tasks. After some rearranging and discussion (and this is the bit that no computer can do for you), we identified some candidate groupings. They were added to the analysis, and then tasks were moved under appropriate group titles. The iteration process began. We started to review the lower level functions, seeing if they fitted well with the group. In some cases groups were merged or split. We were influenced by the two key design principles listed above, and also the desire to:
- Avoid having all high frequency functions in one group
- Making sure all lower level functions had one (and only one) logical home
nother important aspect to consider when structuring an information architecture is that data should be split according to its logical structure. For example, if one customer has multiple records, it is better to structure them separately. An example from a veterinarian is given below:
Data items: Owner name, owner address, pet name, pet inoculations, pet breed, employee name, employee working hours, employee qualifications
Example information architecture:
Note that the structure shown is not based around tasks – this isn’t a task analysis. Pets and owners have been separated, following the logical structure of the data, as one owner can have multiple pets.
Mapping the structure
Having developed a structure, it can then be mapped back to tabs and high level functions, to drive website design. This can be done by editing a copy of the original diagram. This stage might move later in the process (after user feedback) if the page designs are not straightforward. A simplified example is shown below.
The first level corresponds to tabs on the website (or sections of the website, if an approach other than tabs is used for the top level navigation). When the tab is accessed, the second level shows either pages or links to pages. Pages are shown with a green line, using the TaskArchitect “Stopped Task” feature. The decision to provide links or pages depends both on the information architecture, and also on the task frequency and complexity of the pages themselves. For example, “Edit Treatment” is a high frequency task, and so might be promoted one level (or even given a tab of its own) based on user feedback. Depending on the complexity of the pages, “Edit Name” and “Edit Address” might be combined into a single page.
Having developed a logical structure, it was time to test it with the users. We had deliberately avoided including users in the early stages, although we had conducted observations, and were familiar with the work domain. This was to avoid generating a structure that was based on the current system – if users are very familiar with a particular system, any structure generated based on their mental model will tend to follow the existing system, which may not be the optimum structure. This was illustrated during a discussion with an individual with both operational and system design experience. Despite her system design experience, she was unable to imagine any possible structure other than that used by the current system. Having seen the new structure, she commented that it was more logical than the old structure.
We ran a test using preset tasks to assess ease of navigating the structure. Users were asked to identify where they would look for functions, and we recorded any errors. We also elicited realistic tasks and identified where they would go in the structure. This provided a ‘random check’ to give confidence that the structure worked for all functions. We elicited these tasks at the beginning of the session, which gave participants a chance to overcome any nerves, as they were able to start the session by talking about their own job. It also helped us to understand their job roles.
During design iteration we added new groupings, moved functions, or merged two groupings into one. Where we found ambiguity, we probed and found quite subtle differences. For example, one particular task kept appearing in two groups. During testing, we discovered that there were two aspects of the function – setting it up and performing it. When management and operational functions were separated, the errors decreased.
Problems with another group were resolved by renaming it. We noticed that long tenure staff were particularly sensitive to terminology, and found it difficult to understand grouping that used a different language to their current system.
As part of our data collection exercise we also used TaskArchitect to rate the frequency with which functions and data items were used, and to trim those which were low frequency tasks from the new structure. In our final design these tasks were still accessible, but via index pages whose sole purpose was to enable access to low use functions, rather than via the main structure.
The structure we had developed directly drove the user interface design – with groups mapping on to tabs, and functions mapping on to links within the tabs. Throughout, TaskArchitect allowed us to quickly and easily print out diagrams to share the developing information architecture with our client. It also provided a means to collect and visualize frequency data during testing. We saved individual versions of the TaskArchitect file for each participant, which meant we were able to change the structure on the fly during test sessions, then go back and review changes afterwards and decide which would make it into the master structure. We were impressed with the ease of use of TaskArchitect and its flexibility in supporting our different methods as we progressed from initial design, through user testing and finally to delivery.
Ready to try TaskArchitect?