Collaborative techniques for developing usability requirements
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Collaborative techniques for developing usability requirements

on

  • 4,083 views

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 ...

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.

Statistics

Views

Total Views
4,083
Views on SlideShare
4,075
Embed Views
8

Actions

Likes
3
Downloads
62
Comments
0

2 Embeds 8

http://www.linkedin.com 5
https://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.

Collaborative techniques for developing usability requirements Presentation Transcript

  • 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. Session goals
    • Learn what usability requirements are and how they fit within the development life cycle, regardless of the development methodology used.
    • Learn how to guide collaborative requirement definition with users and business stakeholders.
    • Learn how to select collaboration approach.
    • Learn how to translate all input into meaningful, measurable, traceable usability requirements.
    @KarenBachmann #UXReqs #UPA2011
  • 3. Requirements in general
    • Provide a unifying context for a project that defines expectations for the end product
    • Are focused, measurable, and testable
    • Provide knowledge communicated to the entire project team throughout the project life cycle
    • Often address only functional specifications: Does the product work?
    @KarenBachmann #UXReqs #UPA2011
  • 4. Typical usability requirement in the wild
    • The system shall be easy for users to understand and use.
    @KarenBachmann #UXReqs #UPA2011
  • 5. Usability requirements, specifically
    • What they are : The expected and desired user reaction to a system
      • Define how well a product should work for the intended users
      • Define target user satisfaction goals
    • What they aren’t : Functional requirements, use cases (strictly speaking), marketing’s product “mission” statements, nebulous user wish lists
    • Address non-functional requirements and user satisfaction: Does the product work well for the intended users ?
    @KarenBachmann #UXReqs #UPA2011
  • 6. User goals vs. Usability requirements @KarenBachmann #UXReqs #UPA2011 Detailed design requirements High-level business requirements
  • 7. Expanding the usual practices
    • User Research
    Usability Requirements Functional Requirements Complete System Requirements User Goals & Tasks Functions & Workflow Business Drivers & Goals Business Analysis @KarenBachmann #UXReqs #UPA2011
  • 8. Why develop usability requirements?
    • Translate user research into non-functional requirements meaningful to development and QA teams
    • Provide a common, familiar language to focus on user needs
    • Include usability into a product foundation rather than add it as an afterthought or fix
    • Test design and development assumptions
    • Support usability testing
    • Serve as a rallying cry for user satisfaction
    @KarenBachmann #UXReqs #UPA2011
  • 9. A concept revisited: FURPS+
    • Functionality
    • Usability
    • Reliability
    • Performance
    • Security
    • Supportability
    • +…
    Grady and Caswell, 1987 @KarenBachmann #UXReqs #UPA2011
  • 10. F vs. U vs. RPS+
    • Functional
    • Core problem is often well-defined (What)
    • Stakeholders often include subject matter and domain experts
    • Generally have agreement about the core problem to be solved
    • Usability
    • User success metrics are more varied and less understood (How well)
    • Stakeholders often know less about users than they think they do (Who and Why)
    • Priorities are not agreed upon: Stakeholders need a common understanding of users
    • RPS+
    • Success metrics are usually clear and the costs of failure obvious and measurable
    • Experts are technical specialists
    • Need is often driven by regulation or by SLA, eliminating much discussion
    @KarenBachmann #UXReqs #UPA2011
  • 11. Benefits of collaboration
    • Engages and guides users and stakeholders in identifying non-functional usability requirements
    • Builds a shared understanding of who users are and how users define success
    • Guides prioritization of user goals requirements
    • Creates a partnership with requirements analysts to ensure that complete system requirements include the user perspective
    @KarenBachmann #UXReqs #UPA2011
  • 12. Example collaboration tools
    • Requirements workshops, incorporating techniques such as affinity diagramming, storyboarding, gamestorming, prioritization exercises
    • Focus groups with users
    • Conceptual design workshops (with emphasis on conceptual)
    @KarenBachmann #UXReqs #UPA2011
  • 13. Selecting a collaboration approach
    • Understand, when in the analysis phase, the effort is taking place.
    • Understand the nature of the product being developed.
    • Integrate existing research and communicate ongoing research efforts.
    • Confer with BAs whose primary responsibilities are requirements specification
    @KarenBachmann #UXReqs #UPA2011
  • 14. Collaborative workshops
    • Plan to balance the needs of the users and the business and the ultimate goals for the end product, including budget and time constraints.
    • Set clear goals for the workshop and each activity. Define success concretely.
    • Set reasonable time frames and other limits for the workshop.
    • Establish and communicate clear ground rules for participants, even as early as within the invitation to participate.
    @KarenBachmann #UXReqs #UPA2011
  • 15. Collaborative workshops (cont’d)
    • Prepare research findings in an easily digestible way, generally distributing information before hand.
    • Make sure the participants do any required homework and are ready to work when the workshop starts.
    • Make sure the collaboration techniques used fit the organization culture and support the goals of the project.
    @KarenBachmann #UXReqs #UPA2011
  • 16. Collaborative workshops (cont’d)
    • Ensure that each participant is able to participate freely without pressure from other participants (such as supervisors) or external stakeholders.
    • Facilitate productive conflict, but be prepared to intervene if the tone becomes argumentative or defensive.
    • Establish a parking lot and use it consistently as needed.
    @KarenBachmann #UXReqs #UPA2011
  • 17. Collaboration focus changes over time
    • Early phase – Discovery and definition:
      • Conduct activities to support open discovery of requirements
      • Review and analysis of raw user research findings
      • Review and alignment of business drivers
      • Prioritization of usability criteria and user types
    • Later phases – Distillation and prioritization:
      • Analyzing benchmark test data
      • Defining specific metrics
      • Prioritization usability requirements
    @KarenBachmann #UXReqs #UPA2011
  • 18. Writing usability requirements
    • Convert qualitative wants and needs to quantifiable goals
      • Absolute: A concrete measure of success
      • Relative: Compared to another criteria such as a previous release
    • Write them in terms of user tasks and goals
    • Prioritize needs of different user groups
    • Be realistic – success is rarely 100% of users
    @KarenBachmann #UXReqs #UPA2011
  • 19. Writing usability requirements (cont’d)
    • Define any pre-conditions that must exist for the product to successfully fulfill the requirements
    • Prioritize the usability requirements against priorities for the usability criteria
    • Test the requirements and report findings back to the group
    @KarenBachmann #UXReqs #UPA2011
  • 20. Format and “customers”
    • Usability requirements can be captured in any type of requirements format:
      • Traditional requirements
      • Use cases
      • User stories
      • Conceptual prototyping with notations
    • Construct the requirements to support “customers”
      • Developers
      • Usability testers
      • Acceptance test coordinators
      • System testers
      • Marketing and sales
    @KarenBachmann #UXReqs #UPA2011
  • 21. Wrapping Up
    • Know what usability requirements are.
    • Know ways to guide collaborative requirement definition with users and business stakeholders.
    • Know how to select collaboration approach.
    • Know how to translate all input into meaningful, measurable, traceable usability requirements.
    @KarenBachmann #UXReqs #UPA2011
  • 22. References
    • C. Courage, K. Baxter. Understanding Users: A Practical Guide to User Requirements - Methods, Tools, and Techniques .
    • E. Gottesdiener. Requirements by Collaboration: Workshops for Defining Needs .
    • R.B. Grady. Practical Software Metrics for Project Management and Process Improvement.
    • H. Istance. http://www.cms.dmu.ac.uk/~hoi/mult1003_2001_2002/week8/ lecture8_2.ppt
    • J. Jubner. http://www.deltamethod.net/hb_WR5_UsabilityReq.htm
    • NIST. Common Industry Specification for Usability - Requirements . http://zing.ncsl.nist.gov/iusr/documents/CISU-R-IR7432.pdf
    • Nokia. “Design and User Experience Library v2.0.” http://library.forum.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-024AF250-B54D-488D-8D54-C2D52E5C07B1.html
    • E. Smith, A. Siochi. http://www.acm.org/~perlman/hfeshci/Abstracts/88:264-266.html
    • W. Quesenbery. “5Es of Usability.” http://www.wqusability.com/
    • Wikipedia. “FURPS.” http://en.wikipedia.org/wiki/FURPS
    • Xerox Corporation. “How to Develop Usability Goals.” Usability SIG website: http://www.stcsig.org/usability/resources/toolkit/toolkit.html
    @KarenBachmann #UXReqs #UPA2011
  • 23. Image credits
    • Clock front: http://www.sxc.hu/photo/791088
    • Clock back: http://www.sxc.hu/photo/791089
    • City model: http://www.sxc.hu/photo/712776
    • House and plans (licensed): http://www.istockphoto.com/stock-photo-7921798-housing-project.php
    • Tree swing comic: http://www.businessballs.com/treeswing.htm
    • Note card: http://www.sxc.hu/photo/956985
    @KarenBachmann #UXReqs #UPA2011
  • 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. General usability criteria to consider
    • Learnability : How quickly do users come up to speed on the product?
    • Efficiency : How easy is the product to use and be productive?
    • Memorability : Do users remember how to use the product between uses?
    • Error tolerance : Do users make few errors? Are errors recoverable?
    • Relevance : Does the product meet users real needs?
    • Attitude/satisfaction : Do users enjoy using the product?
    • Accessibility : Does the product support the usage needs of all potential users including those with special physical requirements?
    @KarenBachmann #UXReqs #UPA2011
  • 26. Meaningful, measurable numbers
    • Benchmark usability tests of existing versions and competitive products
    • UCD best practices
    • Industry standards
    • Customer feedback and support calls
    • Sales goals
    • Business performance goals
    • Your best professional guess
    @KarenBachmann #UXReqs #UPA2011
  • 27. Constructing usability requirements
    • Determine what usability criteria to measure and the priority for each.
    • Determine how the criteria be measured. Create tangible measurements of intangible user satisfaction statements.
    • Set a realistic percentage of users that must achieve the goals. (100% of users will almost never accomplish 100% of all usability goals.)
    • Define the conditions that must exist for the product to successfully fulfill the requirements.
    @KarenBachmann #UXReqs #UPA2011
  • 28. Components of a usability requirement
    • What task should the user accomplish : Clearly define the specific, finite task that a user should perform and the goal to be achieved
    • Who will accomplish the task : Define which user type (novice? expert?) the requirement addresses
    • What conditions will the task be performed under : Amount of training, work environment, computer experience, etc.
    • How well should the task be performed : A concrete measure of success as a percentage of the right users under the right conditions
    @KarenBachmann #UXReqs #UPA2011
  • 29. Examples in traditional format
    • Relevant (solutions) and Efficient (fast)
    • The first CSR who interacts with a customer can complete identifying information within 3 actions.
    • Efficient (fast)
    • 90% of CSRs will find data on the main screen within 10 seconds.
    • 75% of CSRs will find detailed data on secondary screen with <2 actions.
    • Satisfying (no yelling) and Efficient (fast)
    • The caller will be asked for identification only by the first CSR spoken to.
    • The system will pass relevant caller data for the caller to each CSR the caller speaks to.
    Functional requirement: The CSR can locate caller information . Usability requirements against main usability criteria @KarenBachmann #UXReqs #UPA2011
  • 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. About the Presenter
    • Karen Bachmann, an user experience consultant with Perficient, Inc., designs usable user interfaces, bringing usability into the earliest stage of development to keep the project focused on the user. She also helps companies new to usability implement usability practices. Karen blogs at blogs . perficient .com/spark/ and can be reached at karen . [email_address] .com or @karenbachmann
    @KarenBachmann #UXReqs #UPA2011