Usability requirements are non-functional requirements that translate user research into meaningful guidance for design and into measures of success for testing. Learn about how to guide collaborative requirements definition and integrate user research and business analysis in defining usability requirements. Presented at UPA 2011.
IAC 2024 - IA Fast Track to Search Focused AI Solutions
Collaborative techniques for developing usability requirements
1. Collaborative techniques for developing usability requirements : E ngaging users and stakeholders in understanding usability goals Karen Bachmann Lead UX Consultant, Perficient @KarenBachmann #UXreqs #UPA2011
2.
3.
4.
5.
6. User goals vs. Usability requirements @KarenBachmann #UXReqs #UPA2011 Detailed design requirements High-level business requirements
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24. Appendix: Quick overview of writing usability requirements While the focus of this main presentation was developing the collaboration, here are a few quick slides showing tips on writing usability requirements and some simple examples.
25.
26.
27.
28.
29.
30. Example in Agile user story The CSR can review the complete call history for a caller. Note: Amanda says include the names of CSRs and duration of each interaction. Note: Ty suggested access in one action. @KarenBachmann #UXReqs #UPA2011
31.
Notes de l'éditeur
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. How many people have been developed requirements for their projects?
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Defining usability requirements at the beginning of any project increases the chances that the end product will meet the users’ goals, allow them to be successful, and create a satisfying user experience. They serve as a communication tool for team members and a road map that guides design decisions toward the goals of the users rather than those of the designer. Consequently, usability requirements define the key success criteria for usability testing. Unfortunately, such requirements are often not considered with the same priority as functional or other requirements. This presentation defines usability requirements, proposes guidelines for creating testable and measurable requirements, elaborates the components of a well-constructed usability requirement, and explains how to use the requirements created to develop usability test plans and scenarios.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Developing complete requirements for a product requires addressing six key areas: Functionality Usability Reliability Performance Supportability Security The areas may be defined as distinct product goals (a separate section or document for each area), but often they will be intermingled within a single set of goals. A general definition of how a product works and what it does. Success criteria for test cases. Functionality for system testing, usability for usability tests. Example: Mortgage calculator Functional requirement: Calculate monthly mortgage payment correctly . Test case: User submits the price, interest rate, and duration of loan. System inputs these values to calculate monthly mortgage payment correctly .
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Answers “how well” rather than “how” or “what.” Examples: User wish list : Maroon text on light mauve Usability requirement : High contrast (X shades) between text and background to support accessibility goals. Customizable colors to allow users to create the needed contrast for visibility and satisfaction.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Site visits = field studies; going out to watch the users work on tasks similar to those you are trying to address Observation is also about watching users perform tasks but may be out of context (sensitive/secured work areas) Interviews: Pros: Direct interaction with users and flexibility in questioning Cons: Relies on memory, risks social bias and other confounds, and potentially expensive Questionnaires: Pros: Relatively inexpensive, able to reach many users, can collect data anonymously Cons: Inflexible so questions need to be the right ones, still faces social bias, also relies on memory Focus Groups; derivative is Group Task Analysis (Courage and Baxter)
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Common language : Make sure that every stakeholder has the same understanding of what a “usable” end product will be. Again, this is a communication activity—perfect for tech communicators to take a large role. The language of requirements is (or should be) familiar to development teams. Product foundation : Companies who have no or minimal understanding about usability read articles that contain heuristic evaluations and test results of finished products by gurus such as Jakob Nielsen, Jared Spool, and Don Norman. They may be at risk to conclude that usability is an end of cycle activity. Usability requirements in particular are used throughout the lifecycle, as shown on the upcoming slide. Rally cry : E nsure that usability is considered throughout the product life cycle
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. The areas may be defined as distinct product goals (a separate section or document for each area), but often they will be intermingled within a single set of goals. Grady and Caswell developed concept at HP in the 1980s Non-functional specifications are often key to the success of the product. Usability is no exception.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
While ideally some user research and at least a project mission statement encapsulating key business goals should be available, some project may start from a blank slate. UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
(for example, don’t spend time on open brainstorming activities if the project is an application renovation that is not adding new functionality). UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
Select collaboration techniques used will depend on when in the analysis phase the workshop occurs and what additional information has already been gathered. In this case, more open collaborative techniques are preferable. If a considerable amount of research has been collected, the collaboration may focus on analysis and distillation of the information into measurable requirements and requirement prioritization. UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Defining usability requirements at the beginning of any project increases the chances that the end product will meet the users’ goals, allow them to be successful, and create a satisfying user experience. They serve as a communication tool for team members and a road map that guides design decisions toward the goals of the users rather than those of the designer. Consequently, usability requirements define the key success criteria for usability testing. Unfortunately, such requirements are often not considered with the same priority as functional or other requirements. This presentation defines usability requirements, proposes guidelines for creating testable and measurable requirements, elaborates the components of a well-constructed usability requirement, and explains how to use the requirements created to develop usability test plans and scenarios.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc. Whitney Quesenbery’s 5 E’s of Usability: Engaging Effective Easy to Learn Error Tolerant Efficient Attitude/Satisfaction: Some concrete measures are available (number of good things remembered example on slide 14), but probably the hardest to make concrete. Surveys and interviews from testing. Support calls are another source of validation, although in some ways too late. Fortress experience: When user access was limited, I used this list to prioritize the internal stakeholders goals prior to completing the design.
Select any usability criteria that won’t be covered. Rank included usability criteria. Realistic: “U% of a sample of the intended user population should accomplish T% of the benchmark tasks within M minutes and with no more than E errors.”
How well : Indicate acceptable number of errors for individuals and acceptable frequency of the same errors for sample, the speed (by time or number of actions) with which the task is completed, the ability to remember how to perform the same task after some duration, the ability to perform similar tasks with same or fewer errors. Correlation to Use Cases
Requirement: The caller will be able to review call history, including duration and representatives spoken with, by pressing one button.
UPA 2005 - Montreal 30 June 2005 Usability Requirements - Karen Bachmann, Seascape Consulting, Inc.