Understand tasks & processes

 Introduction

When we are implementing a process in software, the closer we can mimic the way the user thinks about that process, or prefers to execute it, the more intuitive it will appear to the user. The requirements gathering process often focuses on high level objectives and tasks, which can result in 'thin' design specifications. The problem with this is that programmers fill in the gaps in the design specification as they write the code, according to their own preferences and not the user's.

 Understand EVERYTHING

Things we look to understand about tasks or processes, so we can account for them in our design, include:

Understand and document EVERY detailed step of a process

Understand the different ways a process can be executed, and why

 Why bother?

Our objective is to enable users to concentrate on their job and not on the interface of the systems they use, allowing them to complete tasks quickly and easily, with as few errors and little effort as possible.

We therefore need to understand the different scenarios relating to the use of tasks and processes at a detailed level, so we can accurately plan and specify the interactions we want to take place between the user and the system.

A simple example:

Consider the redesign of a simple form with 25 objects, a mixture of text entry boxes, dropdowns, radio buttons, etc.

How could a better understanding of its use help us redesign it for improved usability?

If we know that users typically fill-in just 8 of the 25 form objects, we could cluster those 8 objects together. The user would then not need to tab through them, or move their mouse around so much. This makes the form faster and easier to complete, also reducing potential errors.

Are there commonly selected values? These can be set as a default. The user then does not need to change them, saving time and effort, and further reducing the potential for errors.