Designing and building an application that is simple for people to use is not simple. Why? Because there is usually an inverse relationship between what is simple for users and what is simple for software engineers.

It's like this: if an engineer does things 'simply' the result often proves to be hideously complex for end users. But for an engineer to make an application simple for end users, they typically have to do a lot more work to accommodate a wide variety of usage contexts and conditions. That's just a fact of life in software development.

But all is not lost. We can get higher usability in applications - if the interests of users are properly represented in the design and development phases of application building. The challenge here though is to carry those interests across the great divide between end users and engineers.

In this article I want to show you how to bridge this gap in a way that benefits both parties. It begins with a key question.

Who is the user?

If you are designing a user interface that will support the business goals of a web site or any other kind of application, you have to find a meaningful answer to this question. Arriving at that answer involves a detailed analysis of user requirements. The good news is that the information gleaned through this analysis can be directly applied to preparing the technical specifications for the application developer.

To illustrate this process, I'm going to refer to a project where we at TUAG worked with the Ottawa Public Library to design and build their new 'home' web site using the Drupal open source platform.

Naturally, the best place to start is by meeting with users. There is really no substitute for being directly in touch with real people who are part of, or representative of, the target group for the application. So early on in the project we interviewed representative users from various facets of the OPL patron community as well as a number of the library staff themselves.

Because we were focused on a complete redesign, we didn't just focus on issues with the legacy web site. We listened to patrons tell their stories about how they use the library in their daily lives. We spoke with senior citizens, parents, teenagers, and other interested parties who had expressed a desire to contribute to the redesign process.

One can never do too much of this kind of research. However in practice there is only so much time and budget for this research phase. In addition to in-person meetings and discussions, we were able to stretch the budget further by conducting phone interviews. In the end we were able to form a valuable representation of what people were trying to do with their library resources.

Perhaps what was most striking was the wide range of motivations and objectives for library usage and hence an equally wide range of reasons to use the web site. Another recurring issue that we heard about was the fact that patrons would get lost when using the legacy web site. Resolving the issues that arose from these two aspects - multi-purpose usage and general orientation around the site - became a key part of our design objectives.

Creating Personas, or not

Some user experience designers place a strong emphasis on developing 'Personas' to capture the salient details about users and their interests.

We did lightly touch on this method for the OPL project. The internal library web team had established a list of basic Personas that they wanted to be sure would be accommodated in the new UI design so we endeavoured to speak with users from as many of these groups as we could in the time available.

However, to be frank, developing Personas is not a major part of my method of conducting user requirements analysis. I'll tell you why.

As a user interface systems architect, Personas do not offer me enough substantial value to make deeper, architectural design decisions. In other words, creation of Personas does not fully bridge that gap from end users to engineers.

Personas in the orthodox sense, are elaborate portrayals of fictitious users. As interesting as they may be, there is still a lot of distance between these figurative representations and the nitty-gritty realities of back end systems design. This means there are a lot of questions to be answered along that path and Personas don't go the full distance.

The fact is that engineers cannot be provided with clear, actionable specifications on the basis of these descriptive stories alone. So how can we prepare functional and design specifications that take into account the interests of users?

I've adopted a practical solution to this problem. Because I divide my time fairly evenly between user oriented work and actual software development, my method is to focus on defining User Roles. Over the years, designing around User Roles has proven to be a highly effective way to bring the realities of usability requirements into the domain of software systems design and development.

Defining User Roles

We define a User Role as a set of Tasks. Tasks are the steps or actions required to achieve a certain goal. When we met with library patrons, we listened for clues about what their goals were and how they went about achieving them. Some of the Roles we derived were:

• Book finder
  
• Book borrower
  
• DVD borrower
• Branch finder
  
• Stay at home parent
  
• Working parent
  
• ESL student
  
• Job seeker
  
• Local entrepreneur looking to network
  
• High school student working on an assignment
  
• High school student looking for after school activities 

A Role is a Set of Tasks related to achieving a certain goal. Role definitions relate to the users real life. Role definitions  capture real life goals in the terms that are close to the way that the person will actually think about them.

When user requirements are examined through the lens of Roles it quickly becomes apparent that users change Roles rapidly and often. Taking on a Role is like 'wearing a hat'. Different 'hats' represent diverse task sets, perspectives and priorities. User interface design has to recognize this fundamental characteristic of user behaviour and it must adapt to the changing needs quickly and efficiently.

This need for rapid adaptation takes us into the realm of system architecture. If the architecture is not designed with this capability in mind, the user experience will be burdened by high interaction costs for little apparent value to the user. This kind of system will, at best, cause unwanted stress and at worst, will drive users away from an application.

Task sets are the gateway to system design

Defining Roles as sets of Tasks offers a powerful conceptual tool for user interface systems designers. There is a direct and natural connection between these artefacts of usability requirements analysis and the drafting of functional and design specifications that developers can understand and act upon when building an application (or when building an entire developement platform for that matter).

Each user Task requires certain tools to allow them to carry out the work. These 'tools' are the various user interface components that permit the user to view, create, retrieve and manipulate data. In order to not confuse the design of these elements with the important but separate job of graphic design, I refer to this aspect of the interface as 'screenware'.

A crucial aspect of a user interface design specification is the identification of and rationale for particular elements of screenware. This specification, often known as grey box design, can be reviewed and tested in terms of its effectiveness as an interaction system and then passed along to both graphic designers and software developers for further implementation.

Task Lists Required for Roxanne's Role     User Inteface Components Required for Roxanne's Tasks

Information Architecture Connects the Front and the Back Ends

By looking at the user's activity in terms of Task sets, we have eased directly into the domain of the software engineer whose job, in part, is to ensure that data is moved back forth between the front and back ends of the system properly, securely and accurately.

Designing a system to move the right data between the back end (e.g. a database) and the front end (e.g. the user's browser) is largely a question of Information Architecture. My working definition of Information Architecture (IA) is the meaningful organization and presentation of data as well as the attendant systems of accessing and controlling this data. In terms of user interface design, this is all done through screenware.

Information Architecture is the link between the front and back ends of an application. It is an important aspect of both user interface design and functional design. With this final link, the path from end user to enigneer is complete. We bridged the gap in these stages:

Users > Personas > Roles > Information Architecture > Functionality

Role Oriented Design Works

Bridging the gap between end users and engineers is a highly beneficial, if not essential, aspect of successful application design and development. The linkages described have proven highly effective in my experience as a user interface systems architect.

Roles are the key. They allow for accurate capturing of user requirements, agile flexibility for design and development, identification of tactical and strategic development plans and, perhaps most importantly, a means of bringing the business goals, as expressed through user experience, directly into the shaping of the entire system architecture.