Managing Design Processes Shneiderman and Plaisant Chapter 3 (from slides at http://wps.aw.com/aw_shneider_dtui_4/, Preece publisher, Ch. 6, 12) Overview • Organizational design to support usability – Shneiderman talks about both ―design‖ and the organizational context in which it occurs • Carroll and Rosson‘s characterization of design – ―radically transformational‖ • Shneiderman‘s ―three pillars of design‖ – Guidelines documents and processes – User interface software tools – Expert reviews and usability • Development methodologies – IBM: Ease of Use, Lucid • ―Ethnographic‖ user observation • Participatory design • Scenario development • Social impact statement for early design review • Legal Issues Introduction • Note and recall that early on programmers designed for programmers – That was fine then, and 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 the design process • Interspersed with implementation • Usability Professionals Association Usability Professionals Association • http://www.upassoc.org/ Organizational Design to Support Usability, 1 • Human factors laboratories • 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 • 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, 2 • Variety of design situations precludes comprehensive design strategy – Depends on time, budget, organization, personell, … – Will see different variations, e.g., IBM‘s: Ease of Use works for that (large) organization • Shneiderman says “each of project should have its own user interface architect” – That would be nice … and why not a usability engineer or two … • All should understand a bit about design – Carroll and Rosson‘s account well known in user interface community Carroll and Rosson‘s Design Characterization • 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 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, can be discipline, refined techniques, right and wrong methods, and measures of success So, What is Interaction Design? (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) - interact directly with the product - manage direct users - receive output from the product Check-out operators - 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 • Suppliers • Local shop owners • Managers • Owners Customers 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 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) Software Lifecycle Models • Real quickly … • Briefly relate design to software engineering ideas – Familiar to most • 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, spiral, JAD/RAD, Microsoft — from HCI: — Star, usability engineering A Simple Interaction Design Model Identify needs/ establish requirements (Re)Design Evaluate Build an interactive version •Note (Re)Design, cf Carroll and Rosson Final product •Exemplifies a user-centered design approach Software Engineering: ‗Waterfall‘ Lifecycle Requirements analysis Design Code Test Maintenance Software Engineering: Lifecycle, RAD (Rapid Applications Development) Project set-up JAD workshops Iterative design and build Engineer and test final prototype Implementation review Shneiderman‘s ―Three Pillars of Design‖ • Structuring projects in this way leads to efficiencies • Means to go from ideas to systems: • Guidelines documents and processes • User interface software tools • Expert reviews and usability testing • First, guidelines documents and processes – Each project has different needs, but guidelines should be considered for: – Way to create shared language and common techniques – Etc., as on next slide Guidelines Documents and Processes • 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 • 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 Guidelines Documents and Processes (supplementary) • Guidelines for • Words, icons, and graphics – Words, icons, and graphics – Terminology (objects and actions), abbreviations, and capitalization – Screen-layout issues – Character set, fonts, font sizes, and styles (bold, italic, – Input and output devices underline) – Action sequences – Icons, graphics, line thickness, and – Training – 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 • 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 Guidelines Documents and Processes • To summarize utility of guidelines, again: • ―Four E‘s‖ ….of guideline creation and utilization – Education • User‘s of guidelines need training and chance to discuss guidelines – Enforcement • Timely and clear process necessary to verify that an interface adheres to guidelines – Exemption • When creative ideas or new technologies are used, rapid process for gaining exemption is needed – Enhancement • Predictable process for review to keep guidelines up to date UI Tools and Reviews and Testing • UI tools – As we‘ll see in programming, tools are available … – Recall, windowing system essentially enforces guidelines and standards • Expert reviews and usability testing – Again, part of design process • Next chapters 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 – But, recall role of iteration in interface design – I.e., user testing (perhaps only relatively late) may suggest/require ―transformational‖ redisign • Which is not what managers, and others concerned with budgets/costs, like to hear • Dozens of development methodology • Will briefly look at two representative project management plans – IBM‘s ―Ease of Use Methodology‖ – The Logical User-Centered Interactive Design Methodology (LUCID) IBM‘s Ease of Use Methodology: Business oriented, Deliverables • Imagine a really big organization … with lots of departments … Developmental Methodologies LUCID: Stages (supplementary) • 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 7. Functionality Service provided to users High Concept for managers and marketers 2. Business Case 8. Prototype Pricing, expected revenue, ... Early paper prototypes, key screens, running prototypes – Resources 9. Usability Duration effort, team members, … Set measurable goals, conduct tests – Physical Environment 10. Design Guidelines Ergonomic design, communcations, … Modify existing guidelines, implement review process – Technical Environment Hardware and software for development and deployment 11. Content Materials Identify and acquire copyrighted text, audio – Users Multiple communities for interviewing and 12. Documentation, Training, and Help testing Specify develop and test, paper video and online versions User Observation in Design: Ethnographic Observation of Users • Ethnography: – Branch of anthropology that deals with scientific description of specific human cultures – The study and systematic recording of human cultures • 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. • 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, & 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) • Robinson (1993) framework – Who is present? – Space. What is physical space like? – What is their role? – Actors. Who is involved? – What is happening? – Activities. What are they doing? – When does activity occur? – Objects. What objects are present? – Where is it happening? – Acts. What are individuals doing? – Why is it happening? – Events. What kind of event is it? – How is the activity organized? – 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 & still camera – Audio & 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 Controversial – cases for and against • 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 • 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 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: • Describe the new system and its benefits – Convey the high level goals of the new system. – Identify the stakeholders. – Identify specific benefits • 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. • 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 • .