Nobody deliberately builds a product that's hard to use. Yet too often we encounter tools, equipment, and IT solutions that are confusing, annoying, and unusable. Why is that?
In many cases, IT solutions are hard to use because the designer has built the solution based on what the technology or gadget can do, instead of on the needs of the person using it. This is not an individual failing to do his or her job. Rather, software-development methods too often focus on the correct design only of system function and limit external design to visual issues such as color, terminology, interactivity, and screen layout.
Correct function and visual design are important, but designing IT solutions for the people who use them requires more than focusing on the look and feel of the user interfaces. User modeling goes deeper, affecting the fundamental aspects of the way the system behaves. If the user model is not correct from the start, the function will not be "right" even if it conforms exactly to its specification.
In this article, learn how to create a specification of a system from the user's point of view. User modeling complements other architectural modeling of system interfaces and components; the format is useful at the start of an iteration's design stage. It also supplies vital information for use cases. With this approach, each iteration delivers function that's both useful and easy to use. Useful, because it helps people achieve their goals, and easy to use because it matches the conceptual model.
A conceptual model defines how we expect something to work. It is built dynamically from our previous experiences. People use visible clues and controls, such as handles and switches, to manipulate the objects they see in order to achieve their goals. The conceptual model helps us understand new situations.
Consider what happens when you enter a building through an unfamiliar door. You don't need an instruction manual or an education course to walk through the door. Instead, you first look for a door handle to turn or a plate to push against. The positions of these features tell you where the hinges are and whether the door opens inward or outward. If none of these exists, you explore the possibility that it will detect your presence and open automatically. Through this process, you are conducting a series of experiments using the knowledge from your conceptual model. The feedback and results that you receive determine your next steps.
Through our conceptual models, we can handle many new situations with ease. However, when something behaves in a way we don't expect However, when something behaves in a way we don't expect—because the visible clues are either missing or misleading—we find it unsettling. How would you feel if the hinges were at the top of the door so it behaved like a cat flap, or if the door handle were next to the hinge?
When something doesn't work the way we expect, we often feel either embarrassed at our failure, or annoyed. Even after we've been shown how it works, it requires special concentration to use it in the future and we may keep making mistakes. Our perception is that it is "difficult to use," so we take steps to avoid using it.
Applying conceptual models to IT solutions
Conceptual models also apply to IT solutions. IT solutions display objects on a screen, such as documents and folders, and offer ways that people can manipulate the objects to achieve their goals.
IT objects are often similar to real-world objects. Just as with physical objects, IT objects in the solution must behave consistently with our conceptual model of how we think they should behave. When an IT object is mimicking a real-world object, it must be accurate. The IT solution must have visible actions that match the expectations that come from the conceptual model and provide clear, unambiguous feedback for each action.
For example, consider an online-document library. Users can create online documents and file them in electronic folders. The electronic versions of documents and folders need to behave in a similar way to their real-world counterparts. It is possible to add or extend features to the electronic version that could not be done in the real world (for example, the ability to file a document in multiple folders). However, the extensions have to be done with extreme care to avoid confusing the people who use the system.
Matching the external design elements of your solution with the conceptual model of the people using it is the key to success. Satisfied users are a solution's greatest sales force. Unsatisfied users can dissuade others from even trying it.
Understanding users as the first step in user modeling
To build a useful and usable solution you must understand the characteristics of the people using it in terms of:
- What their goals are
- How they translate their goals into actions
- How the relevant parts of their conceptual model operate
This information is captured in a user model.
A user model is a specialized UML model consisting of simple class diagrams that describe the user's goals and skills, the tasks you're asking them to perform, and the objects they'll work with in the IT solution. Each of these concepts is represented as its own stereotyped UML class, with UML associations describing the relationships among them.
Building a user model begins with identifying who will be using the solution.
Because conceptual models are built from our experiences, everyone's conceptual model is unique. That does not mean we need to model each individual user, though. Fortunately, we share common experiences with others who have similar backgrounds and education. It's possible to group together users who are likely to have similar conceptual models in the areas where the solution operates. These groups of users are called user roles.
A user role characterizes a group of users who have similar responsibilities and skills. One way to think of user roles is as job roles within an organization, such as buyer, marketing manager, systems administrator, and office clerk.
It is important to define user roles for all aspects of the solution — from business use to customization, administration, and operations. If an area of use is omitted, it's likely to be a place where unexpected cost and dissatisfaction arise when the solution is deployed.
For each user role, define the goals and skills you expect it to have. Each user role has at least one user goal. User goals describe an end state, or objective that the user role wishes to achieve. It should be both measurable and achievable by the user role. The relationship from the user role to the user goal is called the primary goal relationship, to emphasize that you're modeling only the most important goal of the user role.
Figure 1. User role with a primary goal
You can divide a user goal into subgoals by creating a hierarchy of user goals linked together by subgoal relationships, as shown in Figure 2.
Figure 2. Dividing primary goal into subgoals
In a typical organization, one user role might be dependent on another user role to complete one of its goals. For example, a tester cannot fulfill the goals related to testing software until a developer has written the code. If the code is late, the tester's ability to do a good job is affected.
You can show the dependency with a dotted arrow. Identifying dependencies is helpful in understanding where the tensions are in an organization (often an important place to focus during the system design).
Figure 3. Dependency between user goals of different user roles
A detailed analysis of the goals for your user roles provides insight to the motivations behind the people using the solution — as well as where collaboration and conflict are likely to occur. This analysis will help you target the functions of the solution to more directly support user needs.
Adding skill sets to the diagram
The skills that a user role is expected to have are grouped into sets of skills that users can acquire through a training course or qualification. These groups of skills are called skill sets.
When a user role has a skill set, it implies that the person in that role understands the terminology and concepts associated with that skill set. This understanding is shown in the user model using an assumed-skill relationship from the user role to the skill set.
Figure 4. Assumed-skill relationship
A user role can have more than one skill set. Some skill sets may represent existing knowledge, and others represent new knowledge that the user role must acquire to use the solution.
Figure 5. User role with primary goal and assumed skill sets
You can show relationships between skill sets using a nested skill-set relationship, indicating that the nested skill set is a prerequisite skill set. In Figure 6, a user role that is assumed to have Skill set A will also have Skill set C.
Figure 6. Nested skill-set relationship
Skill sets can also be grouped in disciplines, as shown in Figure 7. You can model disciplines hierarchically using the nested discipline relationship. Disciplines simply provide a means to organize the skill sets in your model.
Figure 7. Disciplines and skill sets defined in a hierarchy
Modeling skill-set relationships lets you compare the skills of different user roles, perhaps to understand a career path. Modeling these relationships also lets you determine whether a user role could stand in for another user role. In the example in Figure 8, User role A has all of the skill that User role B has. Someone qualified for User role A could stand in for User role B. Similarly, someone with the skills for User role B could grow to be able to perform User role A if they were trained in Skill set A and Skill set B.
Figure 8. Skill sets shared between user roles
Analyzing the skill sets associated with user roles helps identify which are the highly skilled user roles, and where training is required for a person to perform a user role. Skill set analysis can be beneficial for project managers to budget for resources that are needed on particular projects..
Each skill set also has a glossary of terms or concepts associated with it. These terms represent the vocabulary that a user role would be familiar with if they had the skill set. You can use user objects and user artifacts to model the glossary.
Modeling user objects and artifacts
A user object is a logical concept that the user works with, rather than an object on a programming interface. A user artifact is a physical object, such as a diskette or a file.
You can model relationships between user objects and user artifacts using the user-attribute relationship. This relationship implies that the target is an attribute or property of the source. For example, in Figure 9, User object A has a property or attribute of type User object B.
Figure 9. User-attribute relationship between user objects
Similarly, a user-attribute relationship can be used between a user artifact and a user object. Think of this user-attribute relationship as a definition of the contents of a user artifact. If the User artifact in Figure 10 were a log file, User object C could be the log records inside the log file.
Figure 10. User-attribute relationship modeling the contents of a user artifact
User objects and user artifacts define the concepts and terminology of a skill set. We represent this in a user model using a two-way relationship. In the direction from skill set to user object or user artifact, the relationship is called the glossary relationship. In the other direction, it is called the taught by relationship.
Figure 11. Two-way relationship between a skill set and a user object and between a skill set and a user artifact
Through these relationships you can define what terminology is understood by each of the user roles. Any user interface that the user roles will use should use only those terms from the appropriate skill sets. If additional terms are needed, you can either add them to one of the skill sets for the user role, or add them to a new skill set that is attached to the user role.
Figure 12. User objects and user artifacts associated with a skill set
Achieving goals through user tasks
User goals are achieved by performing user tasks, which may be manual tasks or supported by one or more IT solutions. The user task is shown in the user model as helping to achieve a user goal through the supporting-task relationship from the user goal to the user task.
Figure 13. Supporting-task relationship
Typically, a user goal is supported by a number of user tasks, as shown in Figure 14.
Figure 14. Relationships between a user goal and the user tasks required to achieve it
User tasks can be performed many times, in any order, to achieve a user goal. They can also be associated with more than one user goal. Therefore, a particular user task may be performed by more than one user role. A user task can be broken down into a hierarchy of subtasks either to show where a user task is complex, or to show where there are common subtasks in two or more user tasks.
You can use the subtask relationship to structure a complex user task into a hierarchy of simple user tasks.
Figure 15. Subtask relationship
In this type of model, there is no implied sequencing of the user tasks by the order in which you define the supporting task or subtask relationships. The person who uses the solution can use his or her skill to decide when it is appropriate to perform a task, such as send an e-mail. Alternatively, if there is a logical sequence, you can record it using the follow-on task relationship, which suggests the likely order in which the user tasks will be completed.
Figure 16. Follow-on task relationship
Where automated sequencing is required, the user tasks could be the steps in a business process model.
With the additional relationships, it's possible to show the structure of user tasks that support a user goal, as shown in Figure 17.
Figure 17. Structure of user tasks supporting a user goal
Models with many users can have many user tasks. You can group related user tasks into user domains, just as skill sets can be grouped into disciplines. User domains can be linked into a hierarchy using the nested-domain relationship, as shown in Figure 18.
Figure 18. Hierarchy of nested user domains and user tasks
Performing a user task requires specific skills. Each user task has a relationship with the skill sets that are required to perform it.
Figure 19. Required-skill relationship
The required-skill relationship allows a simple check to make sure that each user role required to perform a particular user task has the appropriate skills.
Figure 20. Relationships between a user role, user goal, skill set and user tasks
The required-skill relationship could be to a skill set directly associated with a user role or to one that is nested within it. Nested skill sets can provide the skills that are required by a user role's supporting tasks.
Figure 21. Nested skill sets
In Figure 22, User role B has the skills to perform User task 4. However, this user role will be motivated to perform User task 4 only if that task supports one or more of its primary goals.
Figure 22. User roles and skills
The relationships in the user model let you:
- Verify that the user goals for the user role can be achieved with ease.
- Validate the user tasks that the solution needs to support.
- Determine which user roles need to perform each of the user tasks.
- Confirm that the skills needed to perform a user task match the skills of the user roles that will perform them.
Modeling user actions to complete the task
For each task you can also model the user objects and user artifacts that the user works with to complete the task. You can model this using the action-target relationship from user task to user object, as shown in Figure 23. You can model the type of operation performed by using an action keyword on the relationship.
Figure 23. Action-target relationship
Figure 24 shows a user task with three action-target relationships. The person running the task first selects one or more instances of User object A, then updates them (including the nested instances of User object B). Finally, the user task creates one or more instance of User object C.
Figure 24. Relationship between user objects and a user task
The order in which the action-target relationships appear in the user task define the order in which they should be executed.
Because the user task is also associated with a skill set, you can verify that the user objects are understood by and are consistent with that skill set.
Figure 25. Verifying user object consistency
Benefits of creating a user model
When complete, the user model provides an inventory of the objects externalized by the IT solutions and the subsets of objects that each user role is exposed to by virtue of the tasks the user roles perform.
You need minimal UML knowledge to build a user model (creating class diagrams). The valuable insights you gain into how the solution will be used far outweigh the cost or time it takes to build the model. The model creates a precise definition of the user's interactions that can be checked for logical consistency. The level of abstraction (detail) in the model is the same level that the users will experience. If the model becomes unwieldy, or is "too complicated" to create, then that's a strong indication the resulting solution will also be too complicated.
The process of creating a user model exposes areas where the development team does not have good knowledge of the users' needs. Again, it highlights areas of risk and weakness in the project definition. Once complete, the user model drives use-case definition (from the user tasks) and provides useful metrics, such as the number of user tasks to be supported, for development and test sizing.
The user model provides a strong foundation for each iteration of the project, whether it is built completely up front or slightly before each development iteration is released.
Stay tuned for Part 2 of this series, which will show you how to build a user model of a simple component that supports secure access to Web resources.
Special thanks goes to our colleagues who reviewed and offered excellent comments on this article—in particular, Rebecca Schaller and Dan Wolfson.
Learn
-
"Building ease of
use into the IBM user experience" (IBM Systems Journal, Volume 42, Number 4, 2003)
provides an overview of the process and organizational transformation that IBM has
gone through in improving the user experience with its offerings.
-
"Delivering expected value to users and stakeholders with User Engineering" (IBM Systems Journal, Volume 42, Number 4, 2003) gives an overview of the fundamental concepts of the UE process, including an appreciation of the engineering-inspired rigor.
-
Design @ IBM delves into
User Engineering UML.
- Browse the
technology bookstore
for books on these and other technical topics.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
- Check out
developerWorks
blogs and
get involved in the
developerWorks community.
Mandy Chessell, FREng CEng FBCS has worked for IBM since 1987. She is an IBM Distinguished Engineer, Master Inventor and member of the IBM Academy of Technology. Currently, she is the lead architect of Information Solutions in the SWG Information Management division. In earlier roles she developed new features for the CICS, Encina, TxSeries, Component Broker and WebSphere products. She has filed 40 patents, 15 of which have been granted so far. In addition to her technical responsibilities, Mandy is involved in initiatives designed to enhance the technical vitality of the IBM technical population. These activities include mentoring, serving on technical career development and promotion boards, leading innovation projects and running Women in Technology events. Outside of IBM, Mandy is a Fellow of the Royal Academy of Engineering and a visiting professor at the University of Sheffield, U.K. In 2001 she was the first woman to be awarded a Silver Medal by the Royal Academy of Engineering, and in 2000 she was one of the "TR100" young innovators identified by MIT's Technology Review magazine. More recently she won a British Female Innovators and Inventors Network (BFIIN) "Building Capability" award for her work developing innovative people and the BlackBerry "2006 Best Woman in Technology - Corporate Sector" award.
Larry Yusuf is a solution architect with Software Group Strategy and Technology where he develops outside-in design techniques that bring organization context and user perspectives to the architecture and design of complex software solutions. He leads the development of integration add-on components that fill gaps in the software portfolio. In previous roles, he has worked on emerging technologies, solution development, and testing. He has experience in business integration solution, model-driven development, patterns-oriented software development, and event management. He has written and presented extensively on these topics and has filed seven patents.
Table of contents
- Introduction
- Defining conceptual models
- Applying conceptual models to IT solutions
- Understanding users as the first step in user modeling
- Adding skill sets to the diagram
- Modeling user objects and artifacts
- Achieving goals through user tasks
- Modeling user actions to complete the task
- Benefits of creating a user model
- Acknowledgments
- Resources
- About the authors
- Comments
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags