Intranet Journal
The online resource for intranet professionals
Increasing Portal Adoption with User Scenarios
Low user adoption of company portals -- a common complaint these days as many companies upgrade their extranets and intranets -- is often a result of focusing on technical requirements rather than the real-life context of the system. User scenarios can help bridge the gap.
Inadequate user adoption of new technology has surfaced as a major reason why implementations fail to achieve expected results. A June 20, 2005, article in ComputerWorld reported that, "Badly designed software is costing businesses millions of dollars annually because it's difficult to use, requires extensive training and support, and is so frustrating that many end users under-utilize applications."
After conducting field research in a number of America's largest corporations, I am convinced that the root cause for disappointing rates of user adoption is that portals and other high-traffic systems are not designed according to the way that people think and work. Instead, the design process focuses on the table of requirements that is the basis for selecting the hardware and software components.
One method for shifting the focus from requirements to real-life system context is to incorporate user scenarios into the design process. User scenarios are realistic stories that describe how a person who is representative of an important user segment would go about using the system to accomplish specific goals.
User scenarios should not be confused with use cases. User scenarios describe how someone who is representative of a large or important segment of the user population will accomplish high-frequency or high-value tasks, using features of a system that will become available at a future time. Use cases are scripts for testing every facet of a system's functionality after it has been developed.
This article describes how to create user scenarios that can be used to guide the UI design of a portal or other complex system with many optional paths.
Identify meaningful user segments
To begin, the design team needs to divide the overall user population into distinct user segments. User segments are groups of people who have attributes in common that are likely to cause them to interact with an information system in more or less similar ways. For example, in terms of a portal, user segmentation could be based on job role and work context, such as "administrative assistants who work in offices other than corporate headquarters." Segments can be prioritized according to the size of the population they represent, or the influence they are likely to have on the portal's ultimate success. For example, store managers for a top retailer are not necessarily the largest group of employees, but they will have a conclusive impact on the adoption of the portal as a working tool. Therefore, they should be mapped in as a high-priority segment.
Create user profiles
For each user segment that has been identified, create a profile that describes the attributes that distinguish the segment from other segments. Profiles may include such attributes as: access to a computer, authorization to view executive-level reporting, Internet experience, mobility, etc. Semantic-differential scales, developed long ago for marketing research purposes, can be used to assess and represent attributes consistently across all the profiles.
Identify key tasks
Identify the most significant tasks for each profile. The tasks may have a direct revenue or cost savings impact. Or they may be simple tasks repeated by thousands of people each day, adding up to a substantial organizational impact. For the purpose of generating scenarios, the tasks should be tied to realistic goals that users would have for undertaking the task.
Conduct background research
For user scenarios to be meaningful, user profiles and key tasks need to be based on facts. The design team needs to understand the real-life context in which the portal will be used, and the kinds of steps that real users will take to accomplish their goals. It may be necessary to do some field research to fill in any gaps of understanding. Typical methods for gathering this kind of data include: surveys, web analytics, participant observation, and in-depth interviews with individuals who are representative of the segments.
Create user scenarios
Create at least one "day in the life" scenario for each user segment. The scenario should incorporate as many of the profile attributes and key tasks as possible. Start with a personal description. For example: "Leoni is a flight attendant who lives in New Orleans, and works primarily out of Atlanta. She is 34 years old, married, with children in grade school. She became a flight attendant because she loves to travel, loves a flexible work schedule, and loves people. She doesn't love computers."
Then describe situations that call for using the new system. Be as specific about goals and steps to achieve them as possible. For example: "Leoni sees a table that lists operational changes that have occurred over the last two weeks. There is a black uniform that has just been approved for domestic flights. She starts reading the rest of the page. She sees a small box with internal communications. She scans the titles and notices one is about fuel costs. She has a couple of minutes before her flight briefing, so she reads that item quickly."
Review scenarios with stakeholders and users
Unlike tables of technical requirements, user scenarios make it easy for stakeholders and users to envision what your team proposes to do for them. In my experience, stakeholders and users become very engaged with the scenarios, and are eager to make them as representative of real life priorities as possible.
Once user scenarios receive final approval, the team translates them into a user interface specification. The tasks in the scenarios should have very short click paths, since they represent the high-traffic or high-value interactions. The navigation access points for the tasks described in the scenarios should have much more prominence than the myriad other tasks that can be performed on a system as all-inclusive as a portal, and they should be easily noticed and understood by the segments that they are associated with. The organizational structure of content and applications should make it easy for each of the segments to complete their key tasks, at the expense of other tasks that are not likely to be as frequent or as important.
Refine the approach and iterate
The user model that this paper describes will improve dramatically over time if the team is committed to developing it with new information. Members of the team will become familiar with the key user types, and will be able to continually refine the profiles and scenarios based on real-life behavior they are now prepared to assimilate. Many web analytics packages provide the kind of statistics needed to enhance the realism of the scenarios. When new features are proposed, the user profiles become the "virtual panel" that evaluates the utility the features promise in day to day work activities. The result will be a system that is organically designed for the people using it.
About the Author
Paul Bryan is a web strategy consultant with the design strategy firm Usography, based near Atlanta. You can reach him by email at: paul@usography.com.
About Usography
Usography is an Intranet design strategy firm that has completed projects for clients in both the U.S. and in countries throughout Europe. Usography services include: user interface (UI) design requirements gathering; development of user scenarios and personas; information architecture (wireframes, site maps, interaction design, process maps); and usability assessments (heuristic evaluations, expert reviews, user testing) of prototypes and existing design work.
Intranet Journal's Tutorials |
|
Managing Editor |
The Network for Technology Professionals
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers