6.8. User Interaction Design

This topic has a number of different titles, including Human-Computer Interaction (HCI) and User Centred Design (UCD); it also covers some aspects of information architecture. What we're concerned with generally is the aspect of system design that deals with how human beings work with systems.

6.8.1. Analysing tasks

Part of the requirements process for the MLE involves creating use-cases for the various users and stakeholders in a system; Task Analysis builds on this process to create a matrix of users and tasks.

By placing the set of tasks in the rows of a table, and the sets of user groups as columns, we can start quantifying the degree of importance each task has for a particular user group. For example:

In this table, the tasks are weighted by number for different user groups, with 0 meaning 'doesn't do this task' to 10 meaning 'frequently performs this task'.

By creating these weightings, it becomes possible to start grouping tasks together into sets, to become the basis of assessing the navigation and workflow needs of users. Tutors, for example, would prefer to have all the tasks they perform located together so they can be easily navigated.

Task analysis is a useful activity that can inform not only the system design but also the documentation and training strategy for the MLE, as it provides a way for deciding how many different sets of support documents to produce, and how to divide up the material between them.

6.8.2. User stories - Personas

In addition to the highly qualitative task-user matrix, another useful technique for informing the interaction design process is a more qualitative approach called 'Personas' or 'User Stories'. This involves making very specific and personal narratives of particular users' tasks - personas are a very vivid means of focussing design on user needs, and help ground the design work. However, if you use this approach make sure you get a fairly representative set or you can easily skew the focus of the design.

6.8.3. Workflow

Users don't just perform tasks as standalone units; instead, tasks often have a pattern of flow. This is important in looking at how the MLE needs to operate. If a particular sequence of tasks is a very common activity for a user, you need to consider how to facilitate that workflow within the MLE.

Workflows are often very specific to a particular user group or role, but can be so central to their interaction with systems that significant performance gains can be made by making special provision for it within the MLE.

Other workflows are common across all user groups, and so needs to be incorporated into the overall MLE design (authentication being a common example).

Workflows can be best expressed as process maps using the UML Activity diagram (or 'flowchart' as its also known).

6.8.4. Information architecture

Information architecture is a very broad subject, but there are some key IA considerations for developing an MLE:

Developing a consistent labelling scheme

Users are easily put off by inconsistencies in labels used in a user interface. If something is called 'Course Management' in one location, it needs to be called the same thing throughout. Labels must also make sense to users, and bear some relation to the tasks they need to perform.

Developing navigation schemes

The analysis of tasks and workflows should inform an easy to use navigation structure, tailored to the needs of core sets of users.

Blueprints for presentation logic

Blueprints define the structure of the user interface, with the links between web pages or GUI elements clearly defined. A blueprint shows how users can get from one task to another in a proposed user interface. There are a number of different ways of drawing blueprints, and there are some references to these in the resources section. Below is an example of a blueprint for part of an MLE:

Visual designs

To assist in the development of the MLE, a set of visual designs, incorporating the navigation and labelling decisions, should be created and critiqued. Visual designs are best worked on using 'low fidelity' models such as wireframes. A wireframe is a very basic approximation of a user interface that allows designers and users to assess whether a design works; here's an example:

6.8.5. Evaluating design choices

The interaction elements of a system are the parts of the MLE that staff and students work with day after day, and so they have a lot at stake here. So it is important to carefully evaluate interaction designs with users. This can be accomplished via focus groups and design critique sessions during early design phases, and with usability tests of prototype interfaces with the intended users.

Follow this link for key resources for this section (these open in a new window)