F27ID 24-25 Week 5 Interaction Design PDF

Users and User Requirements F27ID Introduction to Interaction Design 1 Don’t forget who is your user Overview Who are our users Human Cognition Mental Models Personas User requi...

Users and User Requirements F27ID Introduction to Interaction Design 1 Don’t forget who is your user Overview Who are our users Human Cognition Mental Models Personas User requirements Functional Non-functional 2 Why work with users? We, as developers are also humans and more than capable in using the systems we are building. So Why do we need to involve more people? Why work with users? Developers do not have the same characteristics as users: They tend to be (on average): Male Between 18-35 Able-bodied Very comfortable with technology. Have intimate knowledge of the systems they build. Why work with users? Focus only on development: Poor Communication Believing developers way is best Inevitably have more experience than the user Outcome: Systems that are not “user friendly” Systems that require lots of user training or work arounds Systems that may not be accepted by the user community YOU ARE NOT YOUR USERS! Why work with users? The demographics of users is usually very different to those of designers/developers. Differ in abilities Differ in needs Differ in places where technologies are needed/used. Not all users are the same Physical Characteristics Visual abilities Auditory abilities Mental Characteristics: Social Characteristics Tactile abilities general aptitudes (Skills) Educational level General health specific aptitudes (Skills) Racial or ethnic Fatigue background functional literacy (reading Age level and style) Culture Gender visual literacy (ability to Career perceive light) Relationships with peers computer literacy Socio-economic status learning styles Attitudes toward authority Attitudes toward Save Successful collaboration Save Successful Tendencies to co-operate or compete Don’t be ‘that’ designer Do not make assumptions. Understanding Users Cognition What is cognition? It is what goes on in our heads when we carry out our everyday activities Some core aspects of cognition 1. Attention: What to concentrate on, what we take in 2. Perception: How information is acquired from the world and transformed into experiences 3. Memory: What we can bring back to mind 4. Reading, speaking, listening: Understanding words and language 5. Problem-solving, planning, learning, reasoning, decision-making…. All have implications for design 1. Attention: What to concentrate on, what we take in Selecting things to concentrate on at a point in time from the mass of stimuli around us Allows us to focus on information that is relevant to what we are doing Involves audio and/or visual senses Focused and divided attention enables us to be selective in terms of the mass of competing stimuli but limits our ability to keep track of all events Activity: Find the price for a double room at the Quality Inn in Pennsylvania www.id-book.com Activity: Find the price of a double room at the Holiday Inn in Columbia www.id-book.com Activity Tullis (1987) found that the two screens produced quite different results 1st screen - took an average of 5.5 seconds to search 2nd screen - took 3.2 seconds to search Why, since both displays have the same density of information (31%)? Spacing In the 1st screen the information is bunched up together, making it hard to search for what their attention is focused on In the 2nd screen the characters are grouped into vertical categories of information making it easier 1. Attention Influenced by our own goals and interests how information is presented Implications for interaction design: Help direct the user’s attention Present (only) the information that is needed right now Highlight what is most relevant Use techniques that make things stand out like colour, ordering, spacing, underlining, sequencing and animation Leave out clutter Group related information together 2. Perception: How information is acquired from the world and transformed into experiences Which is easiest to read and why? What is the time? What is the time? What is the time? What is the time? What is the time? www.id-book.com 2. Perception It is important to present information in a way that can be readily perceived in the manner intended Design implications Help the user pick things up easily Use icons and graphics that are clear and easy to understand Use borders and spacing to indicate grouping Spoken words should be clear and audible Text and background should contrast, clear fonts, large enough, text legible 3. Memory Recalling various kinds of knowledge that allow us to act appropriately Recall vs recognition http://webdesign-review.blogspot.com Recall vs recognition Recognition See/hear something and know what it is See a picture and recognise the face; translate from a foreign language into your own Recall Bring something back to memory Remember a telephone number or a password Recognition is easier than recall http://webdesign-review.blogspot.com 3. Memory Design implications to support memory Help users quickly recall or recognise Keep procedures short and simple Menus and Icons use recognition, commands use recall Menus and icons are easier than commands Use common and familiar icons and commands, place consistently Small number of options especially for infrequent users Memory Design implications to support memory (cont’d) Offer hints to promote memory tooltips, autocomplete, questions Offer different ways for people to organise information – colour, time stamp, categories – so they can remember where things are Offer search facilities so we don’t have to remember where we put things! 4. Language: reading, speaking and listening It takes cognitive effort to processing words – written or spoken Reading takes more skill than listening quick easy to skip and review 4. Language: reading, speaking and listening Writing permanent, grammatical unless ‘messy’ speech Listening transient needs recall Different individuals vary and have different cognitive styles - some prefer verbal, visual (object/spatial) 4. Language: reading, speaking and listening Design implications – Only 3 items on a spoken menu – Multiple media possibilities 5. Problem solving, planning, decision making, reasoning… Problem solving 5. Problem solving, planning, decision making, reasoning… All involves reflective cognition e.g. thinking about what to do, what the options are, and the consequences www.id-book.com 5. Problem solving, planning, decision making, reasoning… Often involves conscious processes, discussion with others (or oneself), and the use of artefacts e.g. internet search, books, pen and paper www.id-book.com 5. Problem solving, planning, decision making, reasoning… Reasoning: May involve working through different scenarios and deciding which is best option www.id-book.com How do we make decisions Exhaustively go through all the possibilities (von Newmann and Morgenstern, 1944) or get by with just enough information using simple heuristics (Gigerenzer et al., 1999) Problem solving, planning, decision making, reasoning… Design implications Provide additional (hidden) information/functions for users who wish to understand more about how to carry out an activity more effectively (e.g. web searching) Use simple and memorable functions at the interface for computational aids to support rapid decision-making and planning, e.g. for users on the move. Mental Model Image from https://oleb.net/blog/2017/07/mental-models-in-api-design/ Mental Model What does it do??? (functionality) How does it work??? (structure) Johnson-Laird, 1989 Mental Model of a system can be over/under estimated initially Mental models How do we form mental models? Experience Training Exploration Metaphors Not based on facts. Users will act according to their mental model Designers need to keep that in mind. Mental v. Conceptual models Mental models are formed during interaction Represent the user’s understanding of how the system works and what it can do Influenced by the conceptual model Conceptual models (e.g. the desktop) help users learn/recall how to operate a system — can assist understanding of what it can do Mental model is the user’s perception on how they can do what they want to do (based on past experience etc). Personas https://thispersondoesnotexist.com/ 36 Personas A rich picture of an imaginary person who represents your core user group (Dix et al, p201) Capture user characteristics Imaginary people, but synthesised from real users Should be realistic – like the people who will use your system, not perfect people Bring them to life with a name, some characteristics not directly relevant to the product, goals, personal background Personas May have several personas to represent key stakeholder users Used to focus design on user needs Stops getting fixated on ‘general’ user Link to great story about how Personas were invented and how the software engineer involved used them: https://www.smashingmagazine.com/2014/08/a- closer-look-at-personas-part-1/#where-does-the-concept-of-personas-come- from Persona examples https://userguiding.com/blog/user-persona-examples/ Persona warning Do not be sexist / ageist / ablest when creating your personas (or ever!). Unfortunately, this is easy to do, but will be pointed out and not tolerated if repeated. We are trying to stop this way of thinking early on. After you have created a persona, stop and think. E.g. in the past we have seen a lot of “stay at home mothers”, “successful male businessmen”, people who “cannot use tech because of ” etc. User Requirements User Requirements Now that you’ve thought of who your users are What are their requirements? WHAT the system should do Not HOW the system should do it Requirements can include… Diagrams of how the system will operate or be used Scenarios or interview transcripts Humans respond well to narrative Show the sequence of events Descriptions designed for different readerships The basis for vendors’ bids => vague The basis for a contract => precise Types of Requirements Functional Requirements (F) Services provided ‘What’ NOT ‘How’ Non-Functional Requirements (NF) Constraints such as running on certain platforms, conforming to standards… Attributes such as appearance, usability ‘Quality Attributes’ Functional Requirement Example “The robot must be able to pick up a glass” “The robot must be able to climb stairs” “The user must be able to stop the robot” Non-Functional Requirements NOT concerned with specific system ‘functionality’ Rather they specify the system’s ‘quality characteristics’ or ‘quality attributes’ Applies constraints to what system should and shouldn’t do Non-Functional Requirements Often deal with emergent properties properties of the whole system (availability, security, performance) performance, organisational or external issues For instance: usability, reliability, security, standards to comply with, programming languages, legal issues, etc…  Functional/Non-Functional? F Website administrators should be able to add, alter or edit personal detail NF The system should run under the version of Linux that is currently installed in the lab NF The robot should respond in 2 seconds F The robot should be able to communicate with the user using speech The robot speech should be clear and understandable to the NF user NF Language used should be adapted to the user Requirements for Robots Functional Non-functional what it can sense in the have a personality environment avoid obstacles within 3 what actions it can seconds performs speak clearly modes of communication understand all necessary does it avoid obstacles commands Writing Requirements The services and functions expected of the system The user must/could/should be able to … The system should/could/must be able to do for the user Be as specific as possible Should be testable/measurable Avoid vague sayings E.g. the system should be usable (OF COURSE!) Rather: A customer service rep should be able to enter 3 issues in less than 15 minutes They should be complete and consistent This may be difficult w/r large systems with many stakeholders (e.g. different priorities) Talk to your users! Developers don’t have domain specific knowledge Data gathering for requirements Interviews Focus groups Participatory design Questionnaires Researching similar products and use for prompting Observing user doing a task Prioritising Requirements MoSCoW : 4 levels Must, Should, Could, Won’t High, Medium, Low (3 level) Avoid 1,2,3! Be consistent Requirements: Possible issues Requirements can change and lists grow Reading Chapters 4 & 11 Helen Sharp, Jennifer Preece, Yvonne Rogers, Interaction Design. Wiley. https://discovery.hw.ac.uk/permalink/f/ 1el5916/44hwa_alma21699500000032 06