Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design rules and usability requirements

2,967 views

Published on

Week 7 lecture, CN5111 Usability Engineering (2014-15)

Published in: Education
  • Be the first to comment

Design rules and usability requirements

  1. 1. Cn5109 – Week 7: Design rules and usability requirements Dr. Andres Baravalle 1
  2. 2. Interaction design • The next slides are based on "Interaction Design – Measuring the user interaction" • By the end of this week, you should have studied all chapters of the textbook up to chapter 8! 2
  3. 3. Outline • Design rules • Interaction design • Requirements: introduction • Requirements elicitation • Requirements specification • Hierarchical Task Analysis 3
  4. 4. Design rules 4
  5. 5. Design rules: principles, standards and guidelines 5
  6. 6. Design rules: principles, standards and guidelines • Design rules are mechanism to restrict the domain of design options – Usability-related principles, standards and guidelines support the developer • Principles – General understanding of design as a subject area • Standards and guidelines – Direction for design • Design patterns – Capture and reuse design knowledge
  7. 7. Types of design rules • Design rules differ in generality and authority • Principles – Abstract design rules – Low authority – High generality • Standards – Specific design rules – High authority – Limited application • Heuristics and guidelines – Lower authority – More general application increasing authority increasinggenerality Standards Guidelines increasing authority increasinggenerality
  8. 8. Principles to support usability • Learnability – The ease with which new users can begin effective interaction and achieve maximal performance • Flexibility – The multiplicity of ways the user and system exchange information • Robustness – The level of support provided the user in determining successful achievement and assessment of goal- directed behaviour
  9. 9. Principles of learnability (2) • Predictability – Determining effect of future actions based on past interaction history • Synthesizability – Assessing the effect of past actions – Immediate vs. eventual honesty
  10. 10. Principles of learnability (3) • Familiarity – How prior knowledge applies to new system • Generalizability – Extending specific interaction knowledge to new situations • Consistency – Likeness in input/output behaviour arising from similar situations or task objectives
  11. 11. Principles of flexibility • Dialogue initiative – Freedom from system imposed constraints on input dialogue • Multithreading – Ability of system to support user interaction for more than one task at a time – Concurrent vs. interleaving; multimodality • Task migrability – Passing responsibility for task execution between user and system
  12. 12. Principles of flexibility (2) • Substitutivity – Allowing equivalent values of input and output to be substituted for each other (e.g. text and audio) – Representation multiplicity • Customizability – Modifiability of the user interface by user (adaptability) or system (adaptativity)
  13. 13. Principles of robustness • Observability – Ability of user to evaluate the internal state of the system from its perceivable representation • Recoverability – Ability of user to take corrective action once an error has been recognized – Reachability; forward/backward recovery; commensurate effort
  14. 14. Principles of robustness (2) • Responsiveness – How the user perceives the rate of communication with the system • Task conformance – Degree to which system services support all of the user's tasks – Task completeness; task adequacy
  15. 15. Standards • Set by national or international bodies to ensure compliance by a large community of designers standards require sound underlying theory and slowly changing technology • Examples include: – W3C HTML and CSS standards – ISO 6385:2004: Ergonomic principles in the design of work systems
  16. 16. Guidelines and heuristics • Guidelines are detailed rules for design, often platform or task-specific • (Usability) heuristics are principles and rules of thumb that govern the overall design approach – Many textbooks and reports are full of guidelines and heuristics – Understanding justification for guidelines aids in resolving conflicts
  17. 17. Heuristic collection • Nielsen’s 10 Heuristics (see Chapter 9 of Dix et al) • Shneiderman’s 8 Golden Rules • Norman’s 7 Principles
  18. 18. Nielsen’s heuristics • Developed by Jacob Nielsen in the early 1990s. – Based on heuristics distilled from an empirical analysis of 249 usability problems. – The heuristics have been revised for current technology 18
  19. 19. Neilsen’s heuristics • Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. • Match between system and the real world: The system should speak the user's language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. • User control and freedom: Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. • Consistency and standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  20. 20. Neilsen’s heuristics (2) • Error prevention: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. • Recognition rather than recall: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. • Flexibility and efficiency of use: Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
  21. 21. Neilsen’s heuristics (3) • Aesthetic and minimalist design: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. • Help users recognize, diagnose, and recover from errors: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. • Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
  22. 22. Shneiderman’s 8 Golden Rules 1. Strive for consistency 2. Enable frequent users to use shortcuts 3. Offer informative feedback 4. Design dialogs to yield closure 5. Offer error prevention and simple error handling 6. Permit easy reversal of actions 7. Support internal locus of control 8. Reduce short-term memory load
  23. 23. Norman’s 7 Principles 1. Use both knowledge in the world and knowledge in the head 2. Simplify the structure of tasks 3. Make things visible 4. Get the mappings right 5. Exploit the power of constraints, both natural and artificial 6. Design for error 7. When all else fails, standardise
  24. 24. Interaction design 24
  25. 25. 25 What is Interaction Design? • It is a process: – A goal-directed problem solving activity informed by intended use, target domain, materials, cost, and feasibility – A creative activity – A decision-making activity to balance trade- offs • Four approaches: user-centered design, activity-centered design, systems design, and genius design
  26. 26. What is a user-centered approach? • User-centered approach is based on: – Early focus on users and tasks: directly studying user characteristics (cognitive, behavioural, anthropomorphic & attitudinal) and the task for which we are designing a system – Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analysed – Iterative design: when problems are found in user testing, fix them and carry out more tests 26
  27. 27. 27 Importance of involving users • Expectation management – Realistic expectations – No surprises, no disappointments – Timely training – Communication, but no hype • Ownership – Make the users active stakeholders – More likely to forgive or accept problems – Can make a big difference to acceptance and success of product
  28. 28. 28 Degrees of user involvement • Member of the design team – Full time: constant input, but lose touch with users – Part time: patchy input, and very stressful – Short term: inconsistent across project life – Long term: consistent, but lose touch with users • Dissemination devices, as newsletters – Reach wider selection of users – Need communication both ways • User involvement after product is released • Combination of these approaches
  29. 29. Interaction design activities • Interaction design activities should be iterative: – Establishing requirements – Prototyping – Evaluating the prototypes 29
  30. 30. Used-centered design questions • Who are the users? • What do we mean by ‘needs’? • How to generate alternatives? • How to choose among alternatives? • How to integrate interaction design activities with other models? 30
  31. 31. Who are the stakeholders? • Not as obvious as you think: – Those who interact directly with the product – Those who manage direct users – Those who receive output from the product – Those who make the purchasing decision – Those who use competitor’s products should be also considered! 31
  32. 32. Who are the stakeholders? (2) • Three categories of stakeholders (Eason, 1987): – Primary users: frequent hands-on – Secondary users: occasional or via someone else – Tertiary users: affected by its introduction, or will influence its purchase 32
  33. 33. What do we mean by ‘needs’? • Users rarely know what is possible • Users (typically) can’t tell you what they ‘need’ to help them achieve their goals • Instead, look at existing tasks: – Their context – What information they require – Who collaborates to achieve the task – Why is the task achieved the way it is • Envisioned tasks: – Can be rooted in existing behaviour – Can be described as future scenarios 33
  34. 34. How to generate alternatives? • Humans stick to what they know works – Considering alternatives is important to ‘break out of the box’ • Designers are trained to consider alternatives, software developers generally are not • How do you generate alternatives? – ‘Flair and creativity’: research and synthesis – Seek inspiration: look at similar products or look at very different products 34
  35. 35. How to choose among alternatives? • Evaluation with users or with peers, e.g. prototypes • Technical feasibility: some are not possible • Quality thresholds: usability goals lead to usability criteria set early on and check regularly – e.g.: – Utility: which functions are superfluous? – Effectiveness: appropriate support? task coverage, information available – Efficiency: performance measurements 35
  36. 36. 36 How to choose among alternatives Test the alternatives!
  37. 37. How to integrate interaction design in other models? • Agile software development is one option: – Have development and design running in separate tracks – Maintain a coherent vision of the interface architecture 37
  38. 38. Requirements: introduction 38
  39. 39. Requirements: what? 39 1. Understand as much as possible about users, task, context 2. Produce a stable set of requirements
  40. 40. Requirements: how? • Requirements are often collected in an iterative way: – Elicitation (also known as gathering or collection) – Specification – Analysis & negotiation • Prioritization • Selection • Validation (are the req. correct, are these the correct requirements) 40
  41. 41. Requirements: why? • Getting requirements right is crucial – Requirement definition is the stage where most failures are rooted 41
  42. 42. 42
  43. 43. Software Requirements Specification • According to IEEE 830-1998, a software requirement specification (SRS) is a specification for a particular software product, program, or set of programs that performs certain functions in a specific environment. 43
  44. 44. Requirement types • IEEE 830-1998 organises requirements in the following categories: – Functional – External interfaces – Performance – Attributes – Design constraints 44
  45. 45. Functional requirements • Functional – What is the software supposed to do? 45
  46. 46. Non functional requirements • External interfaces – How does the software interact with people, the system os hardware, other hardware, and other software? • Performance – What is the speed, availability, response time etc.? • Attributes – What are the portability, correctness, maintainability, security, etc. considerations? • Design constraints imposed on an implementation. – e.g. by standards or legislation 46
  47. 47. Functional vs non functional requirements • Usability engineering focuses on non- functional requirements 47
  48. 48. 48 An extreme example
  49. 49. Requirements elicitation 49
  50. 50. Requirements elicitation • “…the process of discovering the requirements for a system by communication with customers, system users and other who have a stake in the system development.” (Ian Sommerville) 50
  51. 51. Elicitation techniques • In the next slides we are going to look at the most common requirements elicitation techniques that are used in usability engineering: – Interviews – Group interviews – Observation – Task demonstrations – Questionnaires – Brainstorming – Studying documentation – Researching similar products 51
  52. 52. Elicitation techniques (2) • The techniques used are not dissimilar from the data collection techniques that we have seen for the past weeks • We are just going to focus on their suitability for requirements collection 52
  53. 53. Interviews and observation • Interviews – + Getting to know the present (domain, problems) and ideas for future systems – - Hard to see the goals and critical issues, subjective – - Time consuming and may be infeasible to visit everyone • Observation – Look at how people actually perform a task (or a combination of tasks) – record and review – + Map current work, practices, processes – - Critical issues seldom captured (e.g. you have to be observing when something goes wrong), usability issues seldom captured, time consuming 53
  54. 54. Group interviews and brainstorming • Group interviews and focus groups – + Stimulate each other, complete each other – + Good at gaining a consensus view and/or highlighting areas of conflict – - Censorship, domination (some people may not get attention) • Brainstorming – Gathering of stakeholders and the exchange/gathering of ideas in an open atmosphere where no one risks being ridiculed for their ideas and no ideas are rejected/criticized – + Many ideas (none are rejected) – - Many ideas (have to be sorted and prioritized), hard to create a good atmosphere, hard to get everybody involved, small groups, time consuming 54
  55. 55. Task demonstrations and prototyping • Task demonstrations – Ask a user to perform a task and observe and study what is done, asking questions – + Clarify what is done and how, current work – - Your presence and questions may influence the user, critical issues seldom captured, usability problems hard to capture • Prototyping – + Visualization, stimulate ideas, usability centered, (can be combined with e.g. use cases) – - Solution oriented (premature design), “is it already done?!” 55
  56. 56. Questionnaires • Often used in conjunction with other techniques • Can give quantitative or qualitative data • + Gather information from many users (statistical indications, views, opinions) • - Difficult to construct good questionnaires, questions often interpreted differently, hard to classify answers in open questions and closed questions may be to narrow… 56
  57. 57. Use cases and scenarios • Description of a particular interaction between the (proposed) system and one or more users (or other terminators, e.g. another system). A user is walked through the selected operations and the way in which they would like to interact with the system is recorded. – + Concentration on the specific (rather than the general) which can give greater accuracy – - Solution oriented (rather than problem oriented), can result in a premature design of the interface 57
  58. 58. Studying documentation 58 •Procedures and rules are often written down in manuals •+ Good source of data about the steps involved in an activity, and any regulations governing a task •+ Good for understanding legislation, and getting background information •+ No stakeholder time, which is a limiting factor on the other techniques •- Not to be used in isolation
  59. 59. Researching similar products 59 • Good for prompting requirements
  60. 60. Problems with requirements elicitation (1) • Identifying and involving stakeholders – Availability of key people • Getting ‘real’ users, not managers: traditionally a problem in software engineering 60
  61. 61. Problems with requirements elicitation (2) • Requirements management: version control, ownership • Communication between parties: – Within development team – With customer/user – Between users… different parts of an organisation use different terminology • Domain knowledge distributed and implicit: – Difficult to dig up and understand – Knowledge articulation: how do you walk? 61
  62. 62. Problems with requirements elicitation (3) • Political problems within the organisation • Dominance of certain stakeholders • Economic and business environment changes • Balancing functional and usability demands 62
  63. 63. Some basic guidelines 63 • Focus on identifying the stakeholders’ needs • Involve all the stakeholder groups • Involve more than one representative from each stakeholder group • Use a combination of data gathering techniques
  64. 64. Some basic guidelines (2) 64 • Support the process with props such as prototypes and task descriptions • Run a pilot session! • You will need to compromise on the data you collect and the analysis to be done, but before you can make sensible compromises, you need to know what you’d really like • Consider carefully how to record the data
  65. 65. Data interpretation and analysis 65 • Start soon after data gathering session • Initial interpretation before deeper analysis • Different approaches emphasize different elements e.g. class diagrams for object- oriented systems, entity-relationship diagrams for data intensive systems
  66. 66. Requirements specification 66
  67. 67. Establishing requirements • Requirements typically need clarification, refinement, completion, re-scoping – Input: requirements document – Output: stable requirements 67
  68. 68. Level of detail • The level of detail can vary: – One sentence – One paragraph – A figure – Unstructured or structured – A table or matrix – A legal document – A design document – A formal specification 68
  69. 69. Requirement specification techniques • A number of requirement specification techniques are in use • We are going to see Volere shells, user stories and personas 69
  70. 70. Requirements specification: Volere shells and user stories • The Volere shells provide "template […] sections for each of the requirements types appropriate to today's software systems" 70
  71. 71. 71 Volere shell
  72. 72. Volere requirements template 72
  73. 73. User stories • A user story is a short description of a feature that has a clear value to a user. • User stories represent the requirements from the point of view of the user, not the developer. – They don’t fully describe design details. 73
  74. 74. User stories: template • User stories follow a template determined together by the team and stakeholders. • User stories are typically written with the following template : – As <an actor> I would like to <action> so that <achievement> 74
  75. 75. User stories: template (2) • Actor: A customer type who benefits from this story • Action: The goal of the story. This is a feature or function • Achievement: The benefit to the customer or user when this feature or function is used. – This is optional ant it’s typically left out when the reason is apparent. 75
  76. 76. Personas (stereotypes) • Capture user characteristics – Not real people, but synthesised from real user characteristics – Should not be idealised – Bring them to life with a name, characteristics, goals, personal background • Develop multiple personas 76
  77. 77. Personas 77
  78. 78. Developing personas: who are your users? 78 • Characteristics: – Ability, background, attitude to computers • System use: novice, expert, casual, frequent – Novice: step-by-step (prompted), constrained, clear information – Expert: flexibility, access/power – Frequent: short cuts – Casual/infrequent: clear instructions, e.g. menu paths
  79. 79. Developing personas: what are the users’ capabilities? • Humans vary in many dimensions: – Size of hands may affect the size and positioning of input buttons – Motor abilities may affect the suitability of certain input and output devices – Height, if designing a physical kiosk – Strength - a child’s toy requires little strength to operate, but greater strength to change batteries – Disabilities (e.g. sight, hearing, dexterity) 79
  80. 80. More on personas? • Read this article in the MSDN web site: – Kreitzberg, C. B. and Little, A. (2009) The Power of Personas. Available from: http://msdn.microsoft.com/en-us/magazine/dd5697 80
  81. 81. Hierarchical Task Analysis 81
  82. 82. Working with UI designers • User interface designers need to have enough data to work • Requirements tell the UI designer what the application will do – How are the tasks organised? • You can use different notations, including scenarios 82
  83. 83. Task descriptions 83 • Scenarios ― An informal narrative story, simple, ‘natural’, personal, not generalisable • Use cases — Assume interaction with a system — Assume detailed understanding of the interaction • Essential use cases — Abstract away from the details — Does not have the same assumptions as use cases
  84. 84. Task analysis • Task descriptions are often used to envision new systems or devices • Task analysis is used to investigate an existing situation or to specify the requirements for a software • It is important not to focus on superficial activities – What are people trying to achieve? – Why are they trying to achieve it? – How are they going about it? • Many techniques, the most popular is Hierarchical Task Analysis (HTA) 84
  85. 85. Hierarchical Task Analysis • Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice – HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device – Start with a user goal which is examined and the main tasks for achieving it are identified – Tasks are sub-divided into sub-tasks 85
  86. 86. Breakdown of tasks and plan • Your HTA must include both a breakdown of tasks and a plan. • There are alternative techniques to represent HTAs (textual and graphical; see the textbook for more) 86
  87. 87. HTA examples • We are now going to look at 3 HTA examples: – Example 1: Buying a DVD from a shop – Example 2: Withdrawing cash from an ATM – Example 3: Using Outlook Web Access to send an email 87
  88. 88. 88 Example 1: buying a DVD 0. In order to buy a DVD 1. locate DVD 2. add DVD to shopping basket 3. enter payment details 4. complete address 5. confirm order plan 0: If regular user do 1-2-5. If new user do 1-2-3-4-5.
  89. 89. 89 Example 1: graphical notation
  90. 90. Example 2: withdrawing cash from an ATM • Withdrawing cash from an ATM requires tasks from the user... • What are those tasks? 90
  91. 91. Breakdown of tasks 0 Withdraw cash 1. Check machine will work 1. 1.1 Look at status indicator 2. 1.2 Look for card logo 2. Insert card 3. Enter PIN number 4. Initiate withdrawal transaction 1. 4.1 Select withdraw cash 2. 4.2 Enter amount 5. Complete transaction 1. 5.1 Take card 2. 5.2 Take cash 91
  92. 92. Adding plans • Hierarchical diagram / text specifies what subtasks are part of a task – Does not specify how the subtasks are carried out • Plans are used to describe – Order of subtasks – Conditional or optional subtasks – Repetition – etc. 92
  93. 93. Plans • A plan is needed for each decomposed task – Plan 0: do 1; if possible do 2; repeat 3 until PIN correctly entered; do 4; do 5. – Plan 1: do 1.1, 1.2 in any order – Plan 4: do 4.1; do 4.2 – Plan 5: wait until card available; do 5.1; wait until cash available; do 5.2 93
  94. 94. Example 3: filing cabinet • You probably act differently if you have a lot of documents to file rather than a few... – 0. Store documents in filing cabinet – 1. File lots of documents – 2. File one or two documents – Plan 0: Do 1 or 2 94
  95. 95. Filing one or two things • Simply find the appropriate folder and put the documents in... – 2. File one or two documents – 2.1. Open cabinet – 2.2. File each document – 2.3. Close cabinet – Plan 2: Do 2.1., (2.2. repeatedly) then 2.3. 95
  96. 96. Filing each document • 2.2. File each document • 2.2.1. Find appropriate file • 2.2.2. Open file • 2.2.3. Place document in file • 2.2.4. Close file • Plan 2.2: Do 2.2.1, 2.2.2., 2.2.3., then 2.2.4. 96
  97. 97. Filing lots of documents • Sort the documents into order first • Then split the sorted documents up into ‘categories’ (ie all the documents whose author begins with ‘A’) • Then work through the filing cabinet, putting each category into the right file 97
  98. 98. Filing lots of documents • 1. File lots of documents – 1.1. Choose criteria on which documents are sorted – 1.2. Sort all documents to be filed into order – 1.3. Split documents up into categories – 1.4. Open cabinet – 1.5. Place each category of document into file – 1.6. Close cabinet • Plan 1: Do 1.1., 1.2., 1.3., 1.4., (1.5.98
  99. 99. Choosing sorting criteria • 1.1. Choose criteria on which documents are sorted – 1.1.1.Choose alphabetical by title of document – 1.1.2.Choose alphabetical by author of document – 1.1.3.Choose date order • Plan 1.1: Do any one of 1.1.1., 1.1.2., or 1.1.3. 99
  100. 100. Placing categories in files • 1.5. Place each category of document into file – 1.5.1.Open file – 1.5.2.Place each document in file – 1.5.3.Close file • Plan 1.5: Do 1.5.1., (1.5.2. repeatedly) then 1.5.3. 100

×