Design Shneiderman et al. Chapter 4. Last time …

Design Shneiderman et al. Chapter 4

Last time …

Theories, Principles, Guidelines (quick overview) Guidelines (most specific) –E.g., navigating interface, organizing display, graphic conventions - saw Apple, Microsoft Principles (less specific “rules of thumb”): –“Rules that distill out the principles of effective user interfaces” E.g., identify tasks, determine users’ skill level, select interaction style –E.g., Shneiderman’s “Golden rules of interface design” E.g., prevent errors, reversibility, simplicity, aesthetic design Theories and models (later …): –Longer term goal of HCI –E.g., stages-of-action models, levels of analysis theories - Maybe next week Theories Guidelines Principles

Guidelines, Principles, and Theories Some details Guidelines –Specific and practical Cure for design problems, caution dangers, shared language and terminology –Accumulates (and encapsulates) past experience and best practices “blinking is bad, never use it” –Often enforces common procedures –May be: too specific, incomplete, hard to apply, and sometimes wrong –Lowest level Principles –Mid-level –Help analyze and compare design alternatives, e.g., heuristic evaluation High level theories and models –Goal is to describe objects and actions with consistent terminology Allowing comprehensible explanations to support communication and teaching –Other theories are predictive E.g., reading, pointing, and typing times Theories Guidelines Principles

Guidelines, Principles, and Theories Guidelines –Specific and practical Cure for design problems, caution dangers, shared language and terminology –Accumulates (and encapsulates) past experience and best practices “blinking is bad, never use it” –Often enforces common procedures –May be: too specific, incomplete, hard to apply, and sometimes wrong –Lowest level Principles –Mid-level –Help analyze and compare design alternatives, e.g., heuristic evaluation High level theories and models –Goal is to describe objects and actions with consistent terminology Allowing comprehensible explanations to support communication and teaching –Other theories are predictive E.g., reading, pointing, and typing times Theories Guidelines Principles

Principles – Overview, 1 Term “principles” somewhat arbitrarily chosen … Use term “guidelines”, as in “platform specific guidelines” Use term “principles”, as in “ higher-level usability principles” –Or, “usability guidelines or heuristics” –More fundamental, widely applicable, and enduring than guidelines Help designers choose design alternatives Help evaluators find problems in interfaces –“heuristic evaluation”

Principles – Overview, 2 Plenty to choose from: –Shneiderman’s Eight Golden Rules of Interface Design –Nielsen’s 10 principles One version in his book A more recent version on his website –Tognazzini’s 16 principles, cf. article - >16 –Norman’s rules from Design of Everyday Things –Mac, Windows, Gnome, etc. “guidelines” include principles, as well First, will look at Shneiderman’s overarching design issues: –Fundamental principles: Determine user’s skill levels Identify the tasks –Five primary interaction styles –Prevent errors Later, Nielsen’s principles in detail –And a quick look at Shneiderman’s 8 Golden and Togazzini’s 16 First Principles

Overarching Design Issues: 1. Determine user’s skill levels, 2. Identify the tasks 1. Determine user’s skill level –… or, “Know thy user”, Hansen (1971) –Perhaps the earliest explicitly stated design issue –Design begins with understanding of user Age, gender, physical and cognitive abilities, education, cultural or ethnic background, training, motivation, goals and personality, … –Also, seen these days as “universal usability” –Design goals in part based on user skill level 2. Identify the tasks –Seems obvious to perform task identification before begin design, but... –But, in fact design often begins and task analysis continues concurrently! –… yet, iterative design – more

Overarching Design Issue: 3. Choose an Interaction Style Interaction style - a basic element of design – –By what method, or style, does user interact with system 5 main interaction styles –Each with advantages and disadvantages – and … such tradeoffs are what design is all about! –Direct Manipulation –Menu selection –Form fillin –Command language –Natural language Usually blend, especially when users are diverse

Theories, Principles, Guidelines (quick overview) Guidelines (most specific) –E.g., navigating interface, organizing display, graphic conventions Principles (less specific “rules of thumb”): –“Rules that distill out the principles of effective user interfaces” E.g., identify tasks, determine users’ skill level, select interaction style –E.g., Shneiderman’s “Golden rules of interface design” E.g., prevent errors, reversibility, simplicity, aesthetic design Theories and models (explanation): –Longer term goal of HCI –E.g., stages-of-action models, levels of analysis theories - Maybe next week Theories Guidelines Principles

Plenty to choose from: –Shneiderman’s Eight Golden Rules of Interface Design –Nielsen’s 10 principles One version in his book A more recent version on his website –Tognazzini’s 16 principles, cf. article - >16 –Norman’s rules from Design of Everyday Things –Mac, Windows, Gnome, etc. “guidelines” include principles, as well. :

“8 Golden Rules of Interface Design” Shneiderman – from text In general, sets of principles are in close agreement –E.g., Shneiderman, Nielsen, and Togazzini Schneiderman’s 8 rules (principles): … and a brief description now, with Neilsen in detail, and a bit of Toggazinni for depth 1.Strive for consistency 2.Cater to universal usability 3.Offer informative feedback 4.Design dialogs to yield closure 5.Prevent errors 6.Permit easy reversal of actions 7.Support internal locus of control 8.Reduce short term memory

Again, “8 Golden Rules of Interface Design” Shneiderman In general, sets of principles are in close agreement –E.g., Shneiderman, Nielsen, and Togazzini Schneiderman’s 8 rules (principles): 1.Strive for consistency 2.Cater to universal usability 3.Offer informative feedback 4.Design dialogs to yield closure 5.Prevent errors 6.Permit easy reversal of actions 7.Support internal locus of control 8.Reduce short term memory

Nielsen’s Guidelines (for us, Principles) for Usable Design - Overview Meet expectations –1. Match between system and the real world –2. Consistency and standards –3. Help and documentation User is the boss –4. User control and freedom –5. Visibility of system status –6. Flexibility and efficiency of use Handle errors –7. Error prevention –8. Recognition, rather than recall –9. Help users recognize, diagnose, and recover from errors Keep it simple –10. Aesthetic and minimalist design

Tognazzini March, 2014 1. Aesthetics 2. Anticipation 3. Autonomy 4. Color 5. Consistency 7. Discoverability 8. Efficiency of the User The great efficiency breakthroughs in software are to be found in the fundamental architecture of the system, not in the surface design of the interface. 9. Explorable Interfaces 10. Fitts’s Law 11. Human Interface Objects 12. Latency Reduction 13. Learnability 14. Metaphors, Use of 15. Protect Users’ Work 16. Readability 17. Simplicity 18. State 19. Visible Navigation

Tonight … Overview Organizational design to support usability –Shneiderman - both “design” and the organizational context in which it occurs Carroll and Rosson’s characterization of design –“radically transformational” Iterative design and its relation to software engineering –Spiral model Shneiderman’s “four pillars of design” –User interface requirements –Guidelines documents and processes –User interface software tools –Expert reviews and usability Development methodologies –IBM: Ease of Use, Lucid

Introduction Recall that early on programmers designed for programmers –That was fine then, and even has its place now … However, usability engineering has become the norm –E.g., low fidelity prototypes, revisions based on feedback from users, incremental refinement, testing, observation, etc. –Usability engineering as a part of design process Interspersed with implementation The usability profession: –Formerly, Usability Professionals Association –Now, User Experience Professionals Association

(used to be) Usability Professionals Association http://www.upassoc.org/

User Experience Professionals Association http://uxpamagazine.org/

About Design David Kelley  David Kelley  Ideo –  TED talk on human centered design http://www.ted.com/talks/david_kelley_on_human_centered_design?language=en  About  Not just problem solving – Creative leap  Messy – No right answer  Takes a point of view – or many  Calls for vision and multiple minds  Open attitude – many solutions  Learned from experience with reflection  Requires a feel for the materials  Starts with broadening, followed by narrowing  Requires ongoing mindfulness

Carroll and Rosson’s Characterization of Design What is design? – a thoughtful, realistic, well-know characterization

Carroll and Rosson’s Characterization of Design What is design? – a thoughtful, realistic, well-know characterization Design is a process, not a state –This precludes a static characterization The design process is nonhierarchical –Neither strictly top down or bottom up –Simple understanding of design as “top down” is in part pedagogic and with experience is abandoned The design process is radically transformational –Partial and interim solutions may play no role in final design –You throw designs away Design intrinsically involves (even) the discovery of new goals –I.e., reconceptualizing the problem, and its goals –Hence, can’t be top down Nonetheless, as in any creative domain, there can be discipline, refined techniques, right and wrong methods, and measures of success

Organizational Design to Support Usability Human factors laboratories – in large organizations Organizationally, usability engineering included here –Business case has been often made: Software projects do fail E.g., correction of 20 easiest to correct faults increase success rates from 19% to as much as 80% –Projects have “user interface architect” and “usability engineer” “Usability group in a human factors laboratory”

Organizational Design to Support Usability Human factors laboratories – in large organizations Organizationally, usability engineering included here –Business case has been often made: Software projects do fail E.g., correction of 20 easiest to correct faults increase success rates from 19% to as much as 80% –Projects have “user interface architect” and “usability engineer” “Usability group in a human factors laboratory” Big idea about why hard to design good user interfaces: –Part of the challenge of interface design, implementation, testing, etc., is that it is embedded in a design process of the (application) software itself, as well as entailing its own design process (more next slide) And for that matter, in all cases design is complex –Design is inherently creative and unpredictable. “Interactive system designers must blend knowledge of technical feasibility with a mystical esthetic sense of what attracts users”, Shneiderman –As does all design

Organizational Design to Support Usability Big idea about why hard to design good user interfaces: –Part of the challenge of interface design, implementation, testing, etc., is that it is embedded in a design process of the (application) software itself, as well as entailing its own design process –Leads to “iterative”, or “user-centered” design – much more later Design EvaluateImplement

Organizational Design to Support Usability Wide variety of design situations precludes comprehensive design strategy –Depends on time, budget, organization, personnell, … –Will see different variations, e.g., IBM’s: Ease of Use works for that (large) organization Shneiderman says “each project should have its own user interface architect” –That would be nice … and why not a usability engineer or two … Everyone should understand a bit about design –Carroll and Rosson’s account well known in user interface community –Another take on why design is “iterative” (in an extreme sense) –“Radically transformational”

Overall, We’ll look at: Iterative design –Current “best practice” –Specialization of Boehm’s spiral model Task analysis –How the ui (and software) design process starts –Process of discovering characteristics of users and what problems they need to solve More about evaluation next hour First, “conventional” software engineering models … –With which many in class familiar Design EvaluateImplement

Software Lifecycle Models Will relate design to software engineering ideas Show how activities are related to each other Lifecycle models are: —Management tools —Simplified versions of reality Many lifecycle models exist, for example: —From software engineering: —Waterfall, iterative/incremental, evolutionary prototyping, “agile development, spiral, …

Software Engineering: ‘Waterfall’ Lifecycle Requirements analysis Design Code Test Maintenance Quick look:

Software Engineering: Evolutionary Prototyping

Software Engineering: Incremental Prototyping Final product is built as separate prototypes At end separate prototypes are merged in an overall design

Traditional SE: Waterfall Model (again) One of earliest design processes –Does enforce “think first, code second” –Absolutely, is better than nothing! “Validation” at each stage –E.g., design against requirement Milestones with products at each stage –… which is good

Feedback in Waterfall Model Validation alone not always sufficient –Sometimes problems missed until next stage –Hence, feedback between stages Oops.. Problem when mistake in early stage –E.g., missing requirement discovered in acceptance stage –Rework of intervening stages needed

Waterfall not at all Good for UI Design! UI design hard / “risky” –May well get it wrong … just a fact Users are not involved in validation until acceptance testing! –So don’t find out until end! –Only other place users involved is requirements UI flaws often cause changes in requirements and design –Have to recode written and tested code –And this need for change seems natural, given what we have seen about design in general and ui design in particular

Iterative Design Iterative design offers a way to manage risk inherent in user interface design –Because it is, well, design –But, there needs to be some sort of system to test – hence, build Software design is refined by iterations of cycle But, isn’t this just like waterfall, where went from design to acceptance then back? –We’ll see it’s not Design EvaluateImplement

BTW, Iterative Design - Wrong Way Every iteration corresponds to a release! Complaints are the evaluation that feeds back into next version’s design Using paying customers to evaluate usability not good! –They won’t like it –They won’t buy version 2 Design EvaluateImplement

Iterative Design, 0 Better, would be a model that explicitly takes into account: Repeated cycles of: –Design –Implement –Evaluate … and the spiral model does Further, it allows for efficiency in resource allocation in the design’s evolution Design EvaluateImplement

Iterative Design, 1 Repeated cycles of: –Design –Implement –Evaluate –(size of circle reflects effort/cost) Design cost decreases with iterations Build cost increases –(in radial dimension) –As approach release Cost contained by early build iterations as cheap as possible

Iterative Design, 2 Early iterations use cheap prototypes Parallel design is feasible: –Build & test multiple prototypes to explore design alternatives Later iterations use richer implementations, after UI risk mitigated More iterations generally means better UI

Often called “User-Centered Design” (Term is worth a separate slide!) User-centered As noted, –Iterative design –Early focus on users and tasks –User analysis: who the users are –Task analysis: what they need to do –Involving users as evaluators, consultants, and sometimes designers Constant evaluation –Users are involved in every iteration –Every prototype is evaluated somehow

User Centered Design Example 1. Task analysis –Collecting requirements 2. Design sketches –E.g., paper sketches of UI design 3. Paper prototype –Interactive prototype made of paper and other cheap physical materials 4. User testing 5. Computer prototype –plan to throw away 6. Heuristic evaluation –Usability experts 7. Implementation 8. User testing –Any final refinement Design EvaluateImplement

About “Low Cost Prototypes” and other design methods Idea is that “production” software is very expensive to produce –Maybe … but, e.g., qt is quick, easy, and cross-platform So, ppt, vBasic, etc., very early in design “Exploring design ideas”, more generally Sketches, storyboards, flipbooks, …

Exploring Design Ideas Sketches –See what people think Klemmer, 2007

Storyboards Klemmer, 2007

Flow Diagrams From a previous cs147 project… Klemmer, 2007

Flipbook Klemmer, 2007

Low Fidelity Examples Paper Klemmer, 2007

Low Fidelity Examples Klemmer, 2007

User Centered Design Example 1. Task analysis –Collecting requirements 2. Design sketches –E.g., paper sketches of UI design 3. Paper prototype –Interactive prototype made of paper and other cheap physical materials 4. User testing 5. Computer prototype –plan to throw away 6. Heuristic evaluation –Usability experts 7. Implementation 8. User testing –Any final refinement Design EvaluateImplement

User & Task Analysis – Again …

First step of user-centered design User analysis: –Who is the user? Task analysis: –What does the user need to do?

User Analysis: Know Thy User(s) For beginning designer, helps remind that users not like us Identify characteristics of target user population – cf., universal usability –Age, gender, ethnicity –Education –Physical abilities –General computer experience –Skills (typing? reading?) –Domain experience –Application experience –Work environment and other social context –Relationships and communication patterns As noted, most applications have several kinds of users

User Analysis Techniques –Questionnaires –Interviews –Observation Obstacles –Developers and users may be systematically isolated from each other E.g., Tech support shields developers from users E.g., Marketing shields users from developers –Some users are expensive to talk to Doctors, executives, …

Task Analysis, … again “Overarching Design Principle” Recall, last week, “Overarching Design Principle”: identify tasks –Earlier example of hospital database system Identify individual problems/tasks program might solve/perform Each task is a goal (what, not how) Often helps to start with overall goal of system and then decompose it hierarchically into tasks –E.g., Overall goal: shoppers pay for their own groceries –Tasks: Enter groceries into register Bag groceries Pay

Essential Parts of Task Analysis What needs to be done? –Goal,.e.g., send an email message What must be done first to make it possible? –Preconditions Tasks on which this task depends Information that must be known to the user What steps are involved in doing the task? –Subtasks –Subtasks may be decomposed

Other Elements of a Task Where is the task performed? – consider automated checkout –Front of supermarket, standing up How often is the task performed? –At most a few times a week What are its time or resource constraints? –A minute or two How is the task learned? –By trying it, watching others, shown how by store personnel What can go wrong? (Exceptions, errors, emergencies) –Barcode is missing or smudged –Shopper wants to buy alcohol or cigarettes Who else is involved in the task?

Task Analysis How to do a task analysis –Interviews with users –Direct observation of users performing tasks Pitfalls of task analysis –Duplicating a bad existing procedure in software E.g., sequential search –Failing to capture good aspects of existing procedure E.g., notes on paper forms

User and Task Analyses Techniques Questions to ask –Why do you do this? (goal) –How do you do it? (subtasks) Look for weaknesses in current situation –Goal failures, wasted time, user irritation Contextual inquiry Participatory design

Contextual Inquiry, Participatory Design Observe users doing real work in the real work environment –Combines interview and observation Be concrete Establish a master-apprentice relationship –User shows how and talks about it –Interviewer watches and asks questions Challenge assumptions and probe surprises Participatory Design –Include representative users directly in design team

Contextual Inquiry  Users and stakeholders  Context  At the interviewee’s workplace  Partnership  Designer is apprentice to Interviewee  Can be guided by interviewee  Interpretation and elicitation of needs  Observations must be interpreted by observer and interviewee  Focus  Short  Inquire about work behaviors  Intention is to design a new system  Focus on design goals

So, What is Interaction Design? (Preece - supplementary)

Recall, Preece et al. are concerned with more general interaction design (includes door knobs) Have looked at Shneiderman’s (and a couple of others’) take on interface design Will look at what Preece et al. say, quickly – the essential ideas are the same Terminology differs somewhat, and the applications are more general

So, What is Interaction Design? (Preece - supplementary) Quick overview … Preece’s take … the basic ideas…rather more general than Shneiderman’s two methodologies … “a rose by any color …” What? –Four basic activities –Three key characteristics Some practical issues –Who are the users? –What are ‘needs’? –Where do alternatives come from? –How do you choose among alternatives? Will see: –Lifecycle models from software engineering –Lifecycle models from HCI 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 It is a representation: – a plan for development – a set of alternatives and successive elaborations

What is interaction design? (supplementary) Four basic activities in Interaction Design: –1. Identifying needs and establishing requirements –2. Developing alternative designs –3. Building interactive versions of the designs –4. Evaluating designs Three key characteristics permeate these four activities: –1. Focus on users early in design and evaluation of artefact –2. Identify, document and agree specific usability and user experience goals –3. Iteration is inevitable. Designers never get it right first time Some practical issues –Who are the users? –What are ‘needs’? –Where do alternatives come from? –How do you choose among alternatives?

Who are users and “stakeholders”? (supplementary) I.e., for whom is the product designed? Picture next Not as obvious as might seem: – 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 Three categories of user (Eason, 1987): – primary: frequent hands-on – secondary: occasional or via someone else – tertiary: affected by its introduction, or will influence its purchase

Who are users and stakeholders? (supplementary) Example: Shopping Market Check-out operators Customers Suppliers Local shop owners Managers O wners - Shoppers - interact directly with product - direct users - receive output from the product - make the purchasing decision - use competitor’s products -primary: frequent hands-on -secondary: occasional or via someone else -tertiary: affected by its introduction, or will influence its purchase

Design Consideration: Users & Needs (as in “know thy user” and what they need) Who are the users? –E.g., physical: 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) What are ‘needs’? –Users rarely know what is possible –Users can’t tell you what they ‘need’ to help them achieve their goals –Instead, look at existing tasks: their context what information do 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

Where do alternatives come from? “Humans stick to what they know works” –Past designs, best practice, … –But recall, “if all you have is a hammer, everything looks like a nail” Considering alternatives is important to ‘break out of the box’ To oversimplify: –Designers are specifically trained to consider alternatives –Software people generally are not –Like, divergent and convergent How do you generate alternatives? —‘Flair and creativity’ —research and synthesis —Seek inspiration (next slide): —look at similar products or look at very different products —Whether software or other things

IDEO TechBox – Fostering Design (supplementary) Library, database, website - gizmos for inspiration From: www.ideo.com/

How to choose among Design alternatives? (supplementary) Evaluation with users or with peers, e.g. prototypes Technical feasibility: some not possible Quality thresholds: Usability goals lead to usability criteria set early on and check regularly —safety: how safe? —utility: which functions are superfluous? —effectiveness: appropriate support? task coverage, information available —efficiency: performance measurements

Testing prototypes to choose among alternatives (supplementary)

Shneiderman’s Elements of Design To go back to “middle of the road” interface design … … or, yet another take on … A means, or methodology, to go from ideas to systems

UI Requirements & Observation User Interface Requirements –Soliciting and clearly specifying user requirements is a major key to success in any development activity –Laying out user-interface requirements is part of overall requirements development and management process Often ~all focus on task functionality, e.g., database retrieval –User interface requirements describe system behavior for user “The interface is the system” … for the user Ethnographic Observation –Or, contextual Inquiry –Identifying and observing the user community in action –Discussed earlier and more later

Guidelines Documents & Processes Looked at guidelines last time – more this time –Recall: Specify fairly detailed elements Helps ensure consistency – look and feel, etc. Use has advantages and disadvantages Shneiderman and many others provide detail about use of guidelines for: –Words, icons, and graphics –Screen-layout issues –Input and output devices –Action sequences –Training

Guidelines Detail …, 1 (recall … here, briefly) Words, icons, and graphics –Terminology (objects and actions), abbreviations, and capitalization –Character set, fonts, font sizes, and styles (bold, italic, underline) –Icons, graphics, line thickness, and –Use of color, backgrounds, highlighting, and blinking Screen-layout issues –Menu selection, form fill-in, and dialog-box formats –Wording of prompts, feedback, and error messages –Justification, white space, and margins –Data entry and display formats for items and lists –Use and contents of headers and footers

Guidelines Detail …, 2 (recall … here, briefly) Input and output devices –Keyboard, display, cursor control, and pointing devices –Audible sounds, voice feedback, touch input, and other special devices –Response time for a variety of tasks Action sequences –Direct-manipulation clicking, dragging, dropping, and gestures –Command syntax, semantics, and sequences –Programmed function keys –Error handling and recovery procedures Training –Online help and tutorials –Training and reference materials –Command syntax, semantics, and sequences

Developmental Methodologies Not a pleasant fact, but software projects fail –Often due to poor communication between developers and 1) clients or 2) users

Developmental Methodologies Not a pleasant fact, but software projects fail –Often due to poor communication between developers and 1) clients or 2) users UI development intertwined with general software development methodologies –A principle point of tonight’s talk –Recall role of iteration in interface design –I.e., user testing (perhaps only relatively late) may suggest/require “transformational” redesign Which is not what managers, and others concerned with costs, like to hear! Dozens of development methodologies Will briefly look at two representative project management plans –IBM’s “Ease of Use Methodology” –The Logical User-Centered Interactive Design Methodology (LUCID) Note how each entails same essential elements discussed so far …

IBM’s Ease of Use Methodology: Business oriented, Deliverables Imagine a really big organization … with lots of departments … and ponder … Role by phase:

Developmental Methodologies LUCID, and its Stages, yet another … The Logical User-Centered Interactive Design Methodology –(Kreitzberg, 1996) Stage 1: Envision –Align agendas of all stakeholders with organizational strategy and the need for “extreme usability” –Develop a clear, shared product vision embodied in a concept sketch Stage 2: Discovery Study users to determine high-level requirements, terminology and mental models Stage 3: Design Foundation Develop a conceptual design and create a key screen prototype to convey the visual style Usability test the design, revise, and repeat Stage 4: Design Detail Flesh out the high-level design into complete specifications Stage 5: Build Support the production process through review and late-stage change management Stage 6: Release Develop a roll-out plan to support the users’ transition to the new product Conduct a final usability test Document the lessons learned

Developmental Methodologies LUCID Components (supplementary) The Twelve Components of the LUCID Management Strategy 1.Product Definition High Concept for managers and marketers 2.Business Case Pricing, expected revenue,... 3. Resources Duration effort, team members, … 4. Physical Environment Ergonomic design, communcations, … 5. Technical Environment Hardware and software for development and deployment 6. Users Multiple communities for interviewing and testing 7.Functionality Service provided to users 8.Prototype Early paper prototypes, key screens, running prototypes 9.Usability Set measurable goals, conduct tests 10.Design Guidelines Modify existing guidelines, implement review process 11.Content Materials Identify and acquire copyrighted text, audio 12.Documentation, Training, and Help Specify develop and test, paper video and online versions

End?. Ethnographic observation details Participatory design details

User Observation in Design: Ethnographic Observation of Users Ethnography: –Branch of anthropology that deals with scientific description of human cultures –The study and systematic recording of human cultures Preparation –Understand organization policies and work culture … Field Study –Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data … Analysis –Quantify data and compile statistics … Reporting –Consider multiple audiences and goals …

User Observation in Design: Ethnographic Observation of Users Preparation –Understand organization policies and work culture. –Familiarize yourself with the system and its history. –Set initial goals and prepare questions. –Gain access and permission to observe/interview. Field Study –Establish rapport with managers and users. –Observe/interview users in their workplace and collect subjective/objective quantitative/qualitative data. –Follow any leads that emerge from the visits.

User Observation in Design: Ethnographic Observation of Users Analysis –Compile the collected data in numerical, textual, and multimedia databases. –Quantify data and compile statistics. –Reduce and interpret the data. –Refine the goals and the process used. Reporting –Consider multiple audiences and goals. –Prepare a report and present the findings.

Observing Users: The aims (supplementary)  Benefits & challenges of different types of observation  How to observe as an on-looker, a participant, and an ethnographer  How to collect, analyze & present observational data  Examine think-aloud, diary studies & logging

Observing Users: What and When to Observe (supplementary) Goals & questions determine the paradigms and techniques used Observation is valuable any time during design Quick & dirty observations early in design Observation can be done in the field (i.e., field studies) and in controlled environments (i.e., usability studies) Observers can be: - Outsiders looking on - Participants, i.e., participant observers - Ethnographers

Observing Users: Frameworks to Guide Observation (supplementary) - The person. Who? - The place. Where? - The thing. What? Goetz and LeCompte (1984) –Who is present? –What is their role? –What is happening? –When does activity occur? –Where is it happening? –Why is it happening? –How is the activity organized? Robinson (1993) framework –Space. What is physical space like? –Actors. Who is involved? –Activities. What are they doing? –Objects. What objects are present? –Acts. What are individuals doing? –Events. What kind of event is it? –Goals. What do they to accomplish? –Feelings. What is the mood of the group and of individuals?

Observing Users: Need to Consider (supplementary) Goals & questions Which framework & techniques How to collect data Which equipment to use How to gain acceptance How to handle sensitive issues Whether and how to involve informants How to analyze the data

Observing Users: Observing as an Outsider (supplementary) As in usability testing More objective than participant observation In usability lab equipment is in place Recording is continuous Analysis & observation almost simultaneous Care needed to avoid drowning in data Analysis can be coarse or fine grained Video clips can be powerful for telling story

Observing Users: Participant Observation & Ethnography (supplementary) Debate about differences Participant observation is key component of ethnography Must get co-operation of people observed Informants are useful Data analysis is continuous Interpretivist technique Questions get refined as understanding grows Reports usually contain examples

Observing Users: Data Collection & Analysis (supplementary)  Data Collection Techniques –Notes, audio, video, still camera –Video Data Analysis –Tracking users: - diaries - interaction logging Qualitative data - interpreted & used to tell the ‘story’ about what was observed.  Qualitative data - categorized using techniques such as content analysis.  Quantitative data - collected from interaction & video logs. Presented as values, tables, charts, graphs and treated statistically.

Observing Users: Data analysis (supplementary)  Look for key events that drive the group’s activity  Look for patterns of behavior  Test data sources against each other - triangulate  Report findings in a convincing and honest way  Produce ‘rich’ or ‘thick descriptions’  Include quotes, pictures, and anecdotes  Software tools can be useful e.g., NUDIST, Ethnograph (see URL resource list for examples)  Observing Users: Looking for patterns –Critical incident analysis –Content analysis –Discourse analysis –Quantitative analysis - i.e., statistics

Observing Users: Summary Points  Observe from outside or as a participant  Analyzing video and data logs can be time-consuming  In participant observation collections of comments, incidents, and artifacts are made.  Ethnography is a philosophy with a set of techniques that include participant observation and interviews  Ethnographers immerse themselves in the culture that they study.

Participatory Design, 1 (supplementary) Users are designer, too Controversial – cases for and against Yes, more user involvement brings: –More accurate information about tasks –More opportunity for users to influence design decisions –A sense of participation that builds users' ego investment in successful implementation –Potential for increased user acceptance of final system

Participatory Design, 2 (supplementary) However, negative side, extensive user involvement may –Be more costly –Lengthen the implementation period –Build antagonism with people not involved or whose suggestions rejected –Force designers to compromise their design to satisfy incompetent participants –Build opposition to implementation –Exacerbate personality conflicts between design- team members and users –Show that organizational politics and preferences of certain individuals are more important than technical issues

Design by Scenario Development (supplementary) Day-in-the-life scenarios: Characterize what happens when users perform typical tasks Can be acted out as a form of walkthrough May be used as basis for videotape Useful tools –table of user communities across top, tasks listed down the side –table of task sequences –flowchart or transition diagram

Social Impact Statement for Early Design Review (supplementary) New systems can (and do) have large impact on individuals and organizations Seek to facilitate change: 1. Describe the new system and its benefits –Convey the high level goals of the new system. –Identify the stakeholders. –Identify specific benefits 2. Address concerns and potential barriers 3. Outline the development process

Social Impact Statement for Early Design Review (supplementary) 2. Address concerns and potential barriers –Anticipate changes in job functions and potential layoffs. –Address security and privacy issues. –Discuss accountability and responsibility for system misuse and failure. –Avoid potential biases. –Weigh individual rights vs. societal benefits. –Assess trade-offs between centralization and decentralization. –Preserve democratic principles. –Ensure diverse access. –promote simplicity and preserve what works. 3. Outline the development process –Present and estimated project schedule. –Propose process for making decisions. –Discuss expectations of how stakeholders will be involved. –Recognize needs for more staff, training, and hardware. –Propose plan for backups of data and equipment. –Outline plan for migrating to the new system.

Legal Issues of Design Potential Controversies –What material is eligible for copyright? –Are copyrights or patents more appropriate for user interfaces? –What constitutes copyright infringement? –Should user interfaces be copyrighted?

End Materials from: –Shneiderman publisher site: http://wps.aw.com/aw_shneider_dtui_4/ –Preece et. publisher, Ch. 6, 12 –John Klemmer’s Intro. to HCI Design course http://hci.stanford.edu/courses/cs147/ –MIT OpenCourseware, Robert Miller’s User Interface Design and Implementation http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall- 2004/CourseHome/index.htmhttp://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall- 2004/CourseHome/index.htm

Design Shneiderman et al. Chapter 4. Last time …

Similar presentations

Presentation on theme: "Design Shneiderman et al. Chapter 4. Last time …"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Design Shneiderman et al. Chapter 4. Last time …

Similar presentations

Presentation on theme: "Design Shneiderman et al. Chapter 4. Last time …"— Presentation transcript:

Similar presentations

About project

Feedback