Understanding user interface design rules - Part 1: Task analysis and conceptual model

Describing in detail how to analyze users' goals and tasks is beyond the scope of this book. Entire chapters - even whole books - have been written about it (Beyer & Holtzblatt, 1997; Hackos & Redish, 1998; Johnson, 2007). For now, it is enough to say that a good task analysis answers these questions:

• What goals do users want to achieve by using the application?
• What set of human tasks is the application intended to support?
• Which tasks are common, and which ones are rare?
• Which tasks are most important, and which ones are least important?
• What are the steps of each task?
• What are the result and output of each task?
• Where does the information for each task come from?
• How is the information that results from each task used?
• Which people do which tasks?
• What tools are used to do each task?
• What problems do people have performing each task? What sorts of mistakes are common? What causes them? How damaging are mistakes?
• What terminology do people who do these tasks use?
• What communication with other people is required to do the tasks?
• How are different tasks related?

Once these questions are answered (by observing and/or interviewing people who do the tasks that the tool will support), the next step is not to start sketching possible user interfaces. The next step is to design a conceptual model for the tool that focuses on the users' tasks and goals (Johnson & Henderson, 2002).

A conceptual model explains the function of the software and what concepts people need to be aware of in order to use it. Ideally, the concepts should be those that came out of the task analysis. The more direct the mapping between the tool's concepts and those of the tasks it is intended to support, the less translating users will have to do, and the easier the tool will be to learn.

After you have designed a conceptual model that is task-focused, as simple as possible, and as consistent as possible, you can design a user interface for it that minimizes the time and experience required for using the application to become an automatic process.

Objects/actions analysis
The most important component of a conceptual model is an objects/actions analysis. This specifies all of the conceptual objects that an application will expose to users, the actions that users can perform on each object, the attributes (user-visible settings) of each type of object, and the relationships between objects (Card, 1996; Johnson & Henderson, 2002).

The software's implementation may include objects other than those listed in the conceptual model, but, if so, those extra objects should be invisible to users. Objects and actions that are related purely to implementation - such as a text buffer, a hash table, or a database record - do not belong in a conceptual model.

The objects/actions analysis, then, is a declaration of the concepts that are exposed to users. Follow this rule: "If it isn't in the objects/actions analysis, users shouldn't know about it."

If we were designing software for managing checking accounts, a task-based objects/actions analysis would include objects like transaction, check, and account. It would exclude non-task-related objects like buffer, dialog box, mode, database, table, and text string.

A task-based conceptual model would include actions like writing and voiding checks, depositing and withdrawing funds, and balancing accounts, while excluding non-task-related actions like clicking buttons, loading databases, editing table rows, flushing buffers, and switching modes.

In a task-focused conceptual model, the attributes might be as follows:

• Checks have a payee, a number, an amount, memo text, and a date
• Accounts have an owner and a balance
• Transactions (deposits and withdrawals) have an amount and a date

If the model included attributes from computer technology, such as transaction record format, it would not be task-focused. Users wouldn't care what internal format the application used for storing transaction records. Forcing them to care would detract from the learnability and usability of the software, no matter how much effort went into designing the user interface.

The objects, actions, and attributes for checkbook management may seem obvious, so let's consider a task for which the objects/actions analysis may seem less clear-cut: customers posting comments about products at an online store.

Suitable objects for a conceptual model might include customers, products, customer comments, and responses to comments. Unsuitable objects would include databases, tables, and persistent cookies.

Actions on products would include viewing and adding comments. Actions on comments would include viewing and responding, and, for a user's own comments, editing. The attributes of a comment might include the title, the customer's name, and the posting date.

Notice that for both the checkbook management application and the customer commenting system, important conceptual design issues can be decided before the user interface is designed, or even before we know whether the user interface is presented on a personal computer screen or via voice menus on a telephone.