book

Designing for the Digital Age: How to Create Human-Centered Products and Services

Name: Designing for the Digital Age: How to Create Human-Centered Products and Services
Author: Kim Goodwin
ISBN: 9780470229101

by Kim Goodwin

March 2009

Intermediate to advanced

767 pages

24h 33m

English

Wiley

Read now

Unlock full access

Copyright
About the Author
Credits
Acknowledgments
Foreword
Introduction
Why an Explicit Method?Why This Book
1. Goal-Directed Product and Service Design
1.1. Digital Product and Service Design1.2. Goal-Directed Design1.2.1. Origins of Goal-Directed Design1.2.2. Components of Goal-Directed Design1.2.2.1. PRINCIPLES1.2.2.2. PATTERNS1.2.2.3. PROCESS1.2.2.4. Project planning1.2.2.5. Research1.2.2.6. Modeling1.2.2.7. Requirements definition1.2.2.8. Framework definition1.2.2.9. Detailed design1.2.2.10. Implementation support1.2.2.11. PRACTICES1.3. Summary
2. Assembling the Team
2.1. The Design Team2.1.1. Interaction designers2.1.1.1. SHARED SKILLS AND RESPONSIBILITIES2.1.1.2. INTERACTION DESIGNER (GENERATOR)2.1.1.3. INTERACTION DESIGNER (SYNTHESIZER)2.1.2. Visual interface designer2.1.3. Industrial designer2.1.4. Design team lead2.2. Close Collaborators2.2.1. Project owner2.2.2. Design engineer2.2.3. Business or systems analyst2.2.4. Subject matter expert2.2.5. Usability tester2.3. Other Product Team Members2.4. When You Don't Have the Ideal Team2.4.1. Understaffed design team2.4.2. No design engineers or subject matter experts2.4.3. No clear project owner2.4.4. Too many people in working meetings2.5. Summary
3. Project Planning
3.1. The Ideal Project Starting Point3.2. Determining Your Project's Parameters3.2.1. Revenue or cost focus3.2.2. Desire to innovate3.2.3. Length of time horizon3.2.4. Understanding the problem before solving it3.2.5. Willingness to invest3.2.6. Risk factors3.3. Developing the Project Plan3.3.1. Research3.3.2. Modeling and requirements definition3.3.3. Framework definition3.3.4. Detailed design3.3.5. Ongoing support3.4. Summary
4. Research Fundamentals
4.1. Benefits of Doing Research4.2. Barriers to Doing Design Research4.2.1. "It will cost too much and take too long."4.2.2. "We already did market research."4.2.3. "Our subject matter experts know the users."4.3. Components of Design Research4.4. User Research Methods4.4.1. Usability testing4.4.2. Focus groups4.4.3. Individual interviews4.4.4. Direct observation4.4.5. Combining observation and interviews4.5. The Research Team4.6. Essential Research Skills4.6.1. Active listening4.6.1.1. LISTEN WITHOUT THE MOTOR RUNNING4.6.1.2. USE PRIMARILY OPEN-ENDED QUESTIONS4.6.1.3. USE MINIMAL ENCOURAGERS4.6.1.4. LOOK LIKE YOU'RE INTERESTED4.6.1.5. PARAPHRASE WHAT YOU'RE HEARING4.6.1.6. PRACTICE4.6.2. Capturing the data4.6.2.1. TAKING NOTES4.6.2.2. AUDIO AND VIDEO RECORDING4.6.2.3. PHOTOS4.7. Summary

5. Understanding the Business
5.1. Identifying Stakeholders and Scheduling Interviews5.2. Officially "Kicking Off" the Project5.3. Conducting Stakeholder Interviews5.3.1. Getting started5.3.2. Things to watch out for5.3.3. Topics applicable to most stakeholders5.3.3.1. What's your role with respect to this product?5.3.3.2. What did you do before this?5.3.3.3. What is this product or service supposed to be?5.3.3.4. Who is this product for?5.3.3.5. When is the version we're designing going to be released?5.3.3.6. What worries you about this project? What's the worst thing that could happen?5.3.3.7. What should this project accomplish for the business?5.3.3.8. How will you, personally, define success for this project?5.3.3.9. Is there anyone you think we need to speak with who isn't on our list? Who are those people?5.3.3.10. How would you like to be involved in the rest of the project, and what's the best way to reach you?5.3.4. Marketing stakeholders5.3.4.1. Who are your customers and users today, and how do you want that to be different in five years?5.3.4.2. How does this product fit into the overall product strategy?5.3.4.3. Who are the biggest competitors and what worries you about them? How do you expect to differentiate this product?5.3.4.4. What three or four qualities do you want people to attribute to your company and your product?5.3.4.5. What is the current state of the identity, and could we have a copy of the style guide (if there is one) and examples of it applied to materials?5.3.5. Engineering stakeholders5.3.5.1. What technology decisions have already been made? What's driving them?5.3.5.2. How large is the engineering team assigned to the project, and what are their skills?5.3.5.3. Could you draw a diagram and tell me in lay terms how the existing system works?5.3.6. Sales stakeholders5.3.6.1. Who is typically involved in the purchase decision?5.3.6.2. Why do customers buy a product like this one, and why this one over a competitor's?5.3.6.3. When you lose sales, what are the most common reasons?5.3.6.4. What things do customers complain about or ask for most often, and why?5.3.7. Senior executives5.3.7.1. What do we need to know that you don't think other members of your team have said?5.3.7.2. We know that both timeline and functionality are important, but if you had to choose one, which would it be?5.3.8. Subject matter experts5.3.8.1. What are the typical demographics and skills of potential users, and how much do these vary?5.3.8.2. What distinctions in user roles and tasks would you expect us to see?5.3.8.3. What sorts of workflows or practices do you think we'll be seeing in the field?5.3.9. Other product team members5.3.9.1. CHEAT SHEET5.3.9.2. Things to watch out for5.3.9.3. All stakeholders5.3.9.4. Marketing stakeholders5.3.9.5. Engineering stakeholders5.3.9.6. Sales stakeholders5.3.9.7. Senior executives5.3.9.8. Subject matter experts5.3.9.9. Other product team members5.4. Project Management for Stakeholder Interviews5.5. When You Can't Interview Stakeholders5.6. Summary
6. Planning User Research
6.1. Identifying the Number and Type of Interviewees6.1.1. Step 1: Identify likely roles6.1.2. Step 2: Determine the base number of interviewees per role6.1.3. Step 3: Multiply for important factors6.1.3.1. ENTERPRISE SETTINGS6.1.3.2. CONSUMER ENVIRONMENTS6.1.3.3. ACCOUNTING FOR OTHER FACTORS6.1.3.4. HOW ALL THIS TRANSLATES INTO NUMBERS6.1.4. Step 4: Trim the sample and incorporate other factors6.1.4.1. DIVIDING YOUR SAMPLE6.1.4.2. ACCOUMTING FOR ACCESIBILITY6.1.4.3. TRIMMING YOUR SAMPLE6.1.5. Step 5: Adjust for no-shows and poor interviews6.2. Introducing the Practice Design Problems6.2.1. Consumer device and service: LocalGuide6.2.2. Business application: Room Finder6.3. Recruiting and Scheduling6.3.1. Enterprise site visits6.3.1.1. SITE VISITS WITH EXISTING CUSTOMERS6.3.1.2. SITE VISITS WITH SOMEONE ELSE'S CUSTOMERS6.3.1.3. "UNOFFICIAL" SITE VISITS6.3.1.4. ALTERNATIVES TO SITE VISITS6.3.2. Recruiting individuals6.3.2.1. MARKET RESEARCH FIRMS6.3.2.2. Using a screener6.3.2.3. ADVERTISING6.3.2.4. CONFERENCES AND EVENTS6.3.2.5. DESPERATE MEASURES6.3.2.6. PREPARING PARTICIPANTS6.3.3. The interview schedule6.4. Dealing with Challenges6.5. Summary
7. Understanding Potential Users and Customers
7.1. Interviewing Customers in a Business Environment7.1.1. Useful questions for customers7.1.1.1. Could you please tell us a little bit about your background and your role here at (company)?7.1.1.2. How does (the function or process to be addressed by the product) work here at (company)?7.1.1.3. What are the different groups or roles involved in (whatever function or process the product will address) today? How do the various roles work together?7.1.1.4. How does this compare to your previous companies?7.1.1.5. What are the biggest problems or inefficiencies in this process/function today?7.1.1.6. What are the biggest problems with the product/system today?7.1.1.7. What are the best things about the product/system? Why did you choose it over other options?7.1.1.8. Could you tell us more about the other systems that work with this one?7.1.1.9. What issues have you been addressing with homegrown solutions?7.1.1.10. What do you expect a system for (process/function) should do for (company)?7.1.1.11. What other factors are/were most important to you in selecting a product for (process/function)?7.1.1.12. Other questions and wrap-up7.1.2. What not to do when interviewing customers7.2. Interviewing and Observing Prospective Users7.2.1. The interview setting7.2.2. Essential techniques7.2.2.1. MAKE IT A CONVERSATION, NOT AN INTERROGATION7.2.2.2. BE SYMPATHETIC AND NON-JUDGMENTAL7.2.2.3. BE THE LEARNER, NOT THE EXPERT7.2.2.4. ASK NAÏVE QUESTIONS7.2.2.5. ASK PEOPLE TO SHOW YOU7.2.2.6. ASK FOR SPECIFIC STORIES, ESPECIALLY ABOUT ANYTHING YOU CAN'T OBSERVE7.2.2.7. TAKE OPPORTUNITIES WHEN THEY'RE OFFERED7.2.2.8. WATCH FOR INCONSISTENCIES7.2.2.9. GO BEYOND THE PRODUCT, BUT NOT BEYOND THE DESIGN PROBLEM7.2.2.10. PAY ATTENTION TO NONVERBAL CUES7.2.2.11. THINK AHEAD A LITTLE (BUT NOT TOO MUCH)7.2.2.12. RELY ON YOUR TEAMMATE(S)7.2.3. What not to do in user interviews7.2.3.1. DON'T ASK LEADING QUESTIONS7.2.3.2. AVOID ASKING THE INTERVIEWEE FOR SOLUTIONS7.2.3.3. DON'T SOLVE PROBLEMS DURING THE INTERVIEW7.2.4. Structuring the user interview7.2.5. Getting started: introductions7.2.5.1. OVERVIEW QUESTIONS AND FOLLOW-UP7.2.5.2. BUSINESS SETTINGS7.2.5.3. CONSUMER OR OTHER BROAD DOMAINS7.2.6. Essential interview topics7.2.6.1. INFORMATION AND OBJECTS7.2.6.2. Mental model objects7.2.6.3. Details (attributes of the objects)7.2.6.4. Relationships7.2.6.5. Quantity7.2.6.6. Does every product involve "objects?"7.2.6.7. ACTIONS7.2.6.8. Reasons for each activity7.2.6.9. How tasks are performed and described7.2.6.10. Task frequency and priority7.2.6.11. The role of the current product7.2.6.12. Relationships with other people7.2.6.13. Workarounds7.2.6.14. FRUSTRATIONS7.2.6.15. SKILL7.2.6.16. GOALS7.2.7. Observation and the guided tour7.2.7.1. ERGONOMICS7.2.7.2. CONTENTS OF THE ENVIRONMENT7.2.7.3. UNUSUALLY HARSH CONDITIONS7.2.7.4. SIGNS OF DESIGN FAILURE OR UNMET NEEDS7.2.7.5. GETTING PHOTOS7.2.8. Wrapping up the interview7.2.9. Dealing with challenging interview circumstances7.2.9.1. LANGUAGE AND CULTURAL DIFFERENCES7.2.9.2. CHILDREN AND TEENAGERS7.2.9.3. REMOTE INTERVIEWS7.2.9.4. LITTLE OR NO ACCESS TO THE CONTEXT OF USE7.2.9.5. PERIPATETIC OR HARD-TO-INTERRUPT ACTIVITIES7.2.9.6. ACCESS TO SENSITIVE DATA7.2.9.7. GROUP INTERVIEWS7.2.9.8. INTERVIEWS IN THE HOME7.2.9.9. NO RAPPORT WITH THE INTERVIEWEE7.2.9.10. UPSET INTERVIEWEES7.2.9.11. "BAD" INTERVIEWS7.3. Project Management for Interviews7.3.1. Between interviews7.3.2. Staying sane7.3.3. Team roles and responsibilities7.3.4. Communicating outside the team7.4. Summary
8. Example Interview
8.1. Summary
9. Other Sources of Information and Inspiration
9.1. When You Have Less Time9.2. When You Have More Time9.3. Supplemental Research Methods9.3.1. Public-space observation9.3.2. Mystery shopper9.3.3. Diaries9.3.4. Surveys9.3.4.1. FINDING EXISTING SURVEY DATA9.3.4.2. DEVELOPING YOUR OWN SURVEY9.3.4.3. Step 1: Identify your audience and goals9.3.4.4. Step 2: Craft questions and instructions9.3.4.5. Step 3: Determine your sample size9.3.4.6. Step 4: Decide how to recruit participants9.3.4.7. Step 5: Decide when and for how long to conduct the survey9.3.5. Web analytics and customer support data9.3.6. Focus groups9.3.7. Card sorting9.3.8. Competitive products and services9.3.9. Literature and media9.4. Summary
10. Making Sense of Your Data: Modeling
10.1. Synthesizing Stakeholder Findings10.1.1. Topics to cover10.1.2. Handling controversy10.1.3. Preparing to communicate stakeholder findings10.2. Analyzing Customer and User Data10.2.1. Qualitative analysis10.2.1.1. TECHNIQUES COMMON TO SINGLE-CASE AND CROSSE-CASE AND ANALYSISIS10.2.1.2. SINGLE-CASE ANALYSIS10.2.1.3. Reducing and organizing your data (coding)10.2.1.4. Articulating models within a case10.2.1.5. CROSS-CASE ANALYSIS10.2.1.6. Affinity diagrams10.2.1.7. Composite models10.2.2. Quantitative analysis10.2.2.1. PREPARING YOUR QUALITATIVE DATA10.2.2.2. UNDERSTANDING QUANTITATIVE DATA10.2.2.3. GAINING INSIGHT QUANTITATIVELY10.2.2.4. Cross-tab analysis10.2.2.5. Graphs and charts10.2.2.6. When qualitative and quantitative findings conflict10.2.3. Explanations and relationships10.2.4. Risks and opportunities10.2.5. Preparing to communicate your user findings10.3. Project Management during Modeling10.4. Summary
11. Personas
11.1. Definition and Uses11.1.1. What personas are good for11.1.1.1. GENERATING AND ITERATING SOLUTIONS11.1.1.2. COMMUNICATING AND BUILDING CONSENSUS11.1.1.3. OTHER USES FOR PERSONAS11.1.2. Why personas work11.1.3. What personas are not11.1.3.1. PERSONAS VERSUS MARKET SEGMENTS11.1.3.2. PERSONAS VERSUS ROLES11.1.3.3. PERSONAS VERSUS "AVERAGE" PEOPLE11.1.4. How many personas do I need?11.1.5. How often do I need to create personas?11.1.6. Personas who aren't users11.1.6.1. CUSTOMER PERSONAS11.1.6.2. SERVED PERSONAS11.2. Creating Personas11.2.1. Step 1. Divide interviewees by role, if appropriate11.2.1.1. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.2. Step 2. Identify behavioral and demographic variables11.2.2.1. TYPICAL BEHAVIORAL VARIABLES11.2.2.2. Mental models11.2.2.3. Motivations and goals11.2.2.4. Frequency and duration of key tasks11.2.2.5. Quantity of data objects11.2.2.6. Attitude toward tasks11.2.2.7. Technology and domain skill11.2.2.8. Tasks people perform11.2.2.9. DEMOGRAPHIC AND OTHER VARIABLES11.2.2.10. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.3. Step 3. Map interviewees to variables11.2.3.1. APPROACHES TO MAPPING11.2.3.2. TRICKY MAPPING SITUATIONS11.2.3.3. Behavior that varied by circumstance11.2.3.4. Speculation about behavior11.2.3.5. Third-party behavior11.2.3.6. Missing data11.2.3.7. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.4. Step 4. Identify patterns11.2.4.1. SPOTTING POTENTIAL PATTERNS11.2.4.2. HANDLING OUTLIERS11.2.4.3. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.5. Step 5. Define goals11.2.5.1. GOAL TYPES11.2.5.2. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.6. Step 6. Clarify distinctions and add detail11.2.6.1. COMPONENTS OF A PERSONA11.2.6.2. Behaviors11.2.6.3. Frustrations11.2.6.4. Environment11.2.6.5. Skills and capabilities11.2.6.6. Feelings, attitudes, and aspirations11.2.6.7. Interactions with other people, products, and services11.2.6.8. Demographics11.2.6.9. Relationships among personas11.2.6.10. Organizational Archetypes11.2.6.11. Names11.2.6.12. What not to include11.2.6.13. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.7. Step 7. Fill in other persona types as needed11.2.7.1. SUPPLEMENTAL USER PERSONAS11.2.7.2. NEGATIVE USER PERSONAS11.2.7.3. NONEXISTENT PERSONAS11.2.7.4. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.8. Step 8. Group and prioritize user personas11.2.8.1. WHAT YOU SHOULD HAVE AT THE END OF THIS STEP11.2.9. Step 9. Develop the narrative and other communication11.2.9.1. DESCRIBING INDIVIDUAL PERSONAS11.2.9.2. Photos11.2.9.3. Narrative11.2.9.4. Carla Ramirez11.2.9.5. Diagrams11.2.9.6. HELPING PEOPLE UNDERSTAND THE PERSONAS AS A SET11.2.10. Validating your personas11.3. When Time Is Limited: Provisional Personas11.4. Persona Pitfalls11.5. Project Management for Creating Personas11.6. Summary
12. Defining Requirements
12.1. The Problems with Requirements12.1.1. Requirements cannot be "gathered"12.1.2. Requirements are not features12.1.3. Requirements are not specifications12.2. Generating Effective Requirements12.2.1. Sources of requirements12.2.2. Types of requirements12.2.2.1. DATA NEEDS12.2.2.2. FUNCTIONAL NEEDS12.2.2.3. PRODUCT OR SERVICE QUALITIES12.2.2.4. CONSTRAINTS12.2.3. The process for generating requirements12.3. Brainstorming12.4. Scenarios12.4.1. Why use scenarios?12.4.2. How Goal-Directed scenarios differ from similar tools12.4.2.1. A SCENARIO DESCRIBES THE FUTURE, NOT THE PRESENT12.4.2.2. A SCENARIO DESCRIBES A PERSONA'S POINT OF VIEW12.4.2.3. A SCENARIO IS A STORY WITH A BEGINNING AND AN END12.4.3. Crafting effective context scenarios12.4.3.1. STEP 1: IDENTIFY WHAT CONTEXT SCENARIOS YOU NEED12.4.3.2. STEP 2. DEVELOP EACH STORY12.4.3.3. Answer the right questions12.4.3.4. Use the right level of detail12.4.3.5. Start with an optimistic mind-set12.4.3.6. Stay true to the personas12.4.3.7. Apply important design principles12.4.3.8. Have someone review your scenarios12.4.3.9. STEP 3. PREPARE TO COMMUNICATE YOUR SCENARIOS12.4.4. Extracting requirements from scenarios12.5. Other Requirements from User Personas12.5.1. Mental models12.5.2. Environments12.5.3. Physical and cognitive characteristics12.5.4. Skills and knowledge12.5.5. Goals12.6. Requirements from Business and Other Needs12.6.1. Customer persona goals12.6.2. Stakeholders12.6.3. Lawyers and regulations12.6.4. Competitors and media12.6.5. Accessibility12.6.6. Sustainability12.7. Experience Attributes12.7.1. Step 1: Compile desirable qualities from research12.7.2. Step 2: Group related qualities into clusters12.7.3. Step 3: Refine and filter clusters12.7.4. Step 4: Optimize terms to guide visual decisions12.7.5. Step 5: Choose the best term from each cluster12.7.6. Step 6: Describe and optimize relationships12.7.7. Step 7: Develop additional communication tools12.8. Project Management for Developing Requirements12.9. Summary
13. Putting It All Together: The User and Domain Analysis
13.1. Typical Structure13.1.1. Introduction of the project parameters13.1.2. Research activities: what you did13.1.3. Research findings: what you learned13.1.3.1. WHAT YOU HEARD FROM STAKEHOLDERS13.1.3.2. WHAT YOU LEARNED ABOUT THE INDUSTRY13.1.3.3. WHAT YOU LEARNED ABOUT POTENTIAL CUSTOMERS AND USERS13.1.3.4. WHAT YOU LEARNED ABOUT THE CURRENT PRODUCT OR SERVICE13.1.4. Personas13.1.5. Context scenarios13.1.6. Requirements13.1.7. Next steps13.2. Developing an Effective Document13.3. Developing an Effective Presentation13.4. Conducting the Meeting13.4.1. Before the meeting13.4.2. Delivering the presentation and leading the discussion13.4.2.1. INTRODUCTION, RESEARCH ACTIVITIES, AND FINDINGS13.4.2.2. HANDLING QUESTIONS AND CHALLENGES13.4.2.3. PERSONAS13.4.2.4. How can one person represent all of our user needs?13.4.2.5. Why isn't [a particular sort of person] in the set?13.4.2.6. How do these relate to our market segments?13.4.2.7. How can you be sure these are the right personas?13.4.2.8. What if we pick the wrong primary?13.4.2.9. That persona is [someone the stakeholder knows].13.4.2.10. What if another Hugo down the hall is different?13.4.2.11. I don't think this persona should be [something].13.4.2.12. SCENARIOS13.4.2.13. REQUIREMENTS13.4.2.14. NEXT STEPS13.4.2.15. Developing your skills13.4.2.16. KNOW YOUR SLIDES.13.4.2.17. SCHEDULE DRESS REHEARSALS.13.4.2.18. ASK FOR CONSTRUCTICVE FEEDBACK.13.4.2.19. DRESS FOR SUCESS.13.4.2.20. PRACTICE ACTIVE LISTENING.13.4.2.21. GET HELP.13.5. Project Management for Developing the U&DA13.6. Summary
14. Framework Definition: Visualizing Solutions
14.1. Essential Principles of Framework Definition14.1.1. Consider the whole system at once14.1.2. Learn by sketching and failing14.1.3. Focus on structure, not details14.1.4. Design for the long term14.2. Process Overview for Framework Definition14.2.1. Process for design on a novel platform14.2.2. Process for design on a known platform14.2.3. Process for designing services14.3. Project Management for Framework Definition14.3.1. How many directions to explore14.3.2. Planning your time14.4. Essential Skills for Framework Definition14.4.1. Sketching and storyboarding14.4.1.1. THE ROLE OF DRAWING SKILLS IN INTERACTION DESIGN14.4.1.2. REPRESENTING INTERACTION IN SKETCHES: STORYBOARDING14.4.2. Collaboration14.4.2.1. TEAM ROLES14.4.2.2. RUNNING AN EFFECTIVE DESING MEETING14.4.2.3. Determine what you need to accomplish14.4.2.4. Let the best idea win14.4.2.5. Look down the rat hole, but don't go in14.4.2.6. Elicit and understand before assessing or suggesting14.4.2.7. "Park" questions and comments when necessary14.4.2.8. Have a reason for every decision14.4.2.9. Make decisions in the meeting, not at your desk14.4.2.10. Use the 15-minute rule14.4.3. Capturing what happens in meetings14.5. Summary
15. Principles and Patterns for Framework Design
15.1. The Importance of Context15.2. Principles for Form and Behavior15.2.1. Design values15.2.1.1. GOOD DESIGN IS ETHICAL15.2.1.2. GOOD DESIGN IS PURPOSEFUL15.2.1.3. GOOD DESIGN IS PRAGMATIC15.2.1.4. GOOD DESIGN IS ELEGANT15.2.2. Minimizing unnecessary work15.2.2.1. FOUR TYPES OF WORK15.2.2.2. Cognitive work15.2.2.3. Visual work15.2.2.4. Memory work15.2.2.5. Physical work15.2.2.6. IMPORTANT PRINCIPLES FOR FRAMEWORK DESIGN15.2.2.7. Give users all of what they need, but only what they need15.2.2.8. Don't force users to configure anything you can make a reasonable guess about15.2.2.9. Rely on mental models instead of metaphors or implementation models15.2.2.10. Have a compelling reason for inconsistency15.2.2.11. Design for the probable, provide for the possiblexy15.3. Patterns for Form and Behavior15.3.1. Organizing objects and activities15.3.1.1. COMMAND LINE15.3.1.2. ORGANIZER/WORKSPACE15.3.1.3. HUB-AND-SPOKE / HIERARCHICAL MENU15.3.1.4. PARALLEL WORKSPACES AND MODES15.3.1.5. WIZARDS AND TUNNELS15.3.1.6. MULTIPLE DOCUMENT INTERFACE15.3.1.7. FIRST-PERSON ENVIRONMENT15.3.1.8. THIRD-PERSON ENVIRONMENT15.3.2. Combinations of patterns15.3.3. Organizing by nouns or verbs15.3.4. Additional ways to manage real estate15.3.4.1. FLEXIBLE PALETTES AND DRAWERS15.3.4.2. PROGRESSIVE DISCLOSURE15.4. Summary
16. Designing the Form Factor and Interaction Framework
16.1. IxDG and IxDS: Define Data Object Types and Relationships16.2. Full Design Team: Define Possible Functional Elements16.2.1. Functional elements in product design16.2.2. Functional elements in service design16.2.3. Making decisions16.3. Full Design Team: Define Possible Platforms16.3.1. Input and output methods16.3.2. Other form factor considerations16.4. Full Team: Brainstorm with Sketches16.4.1. Brainstorming for software on a fixed platform16.4.2. Brainstorming for services and new platforms16.5. ID: Refine the Form Factor16.6. IxDG and IxDS: Define the Interaction Framework16.6.1. Develop a first draft of the framework16.6.1.1. DEVELOP KEY PATH SCENARIOS16.6.1.2. Example—a veterinary hospital management application16.6.1.3. GROUP FUNCTIONAL ELEMENTS16.6.1.4. START TO STORYBOARD SCREENS AND NAVIGATION16.6.1.5. ADD TO THE DESIGN AND ADJUST IT FOR ADDITIONAL SCENARIOS16.6.1.6. HOW THE SKETCH-FIRST APPROACH DIFFERS16.6.1.7. EVALUATE, ITERATE, AND REFINE THE FRAMEWORK16.6.2. How to approach specific design situations16.6.2.1. TIGHT CONSTRAINTS16.6.2.2. MULTIPLE INTERFACES16.6.2.3. WEB SITES16.6.2.4. Getting users to the right information16.6.2.5. Focusing on differing persona needs16.6.2.6. DEVICES16.6.2.7. New devices16.6.2.8. Existing platforms16.6.2.9. VEHICLE INTERFACES16.6.2.10. AUDIBLE INTERFACES16.6.2.11. GAMES16.7. Full Design Team: Iterate Form and Behavior Together16.8. Typical Challenges in Designing the Framework16.9. Project Management for Defining Platforms and Frameworks16.9.1. Internal design team check-ins16.9.2. Project owner, SME, and design engineer review16.9.2.1. DETERMINING WHOM TO INVITE16.9.2.2. SETTING EXPECTATIONS16.9.2.3. PREPARING YOUR AGENDA AND MATERIALS16.9.2.4. CONDUCTING THE MEETING16.9.3. User feedback16.10. Summary
17. Principles and Patterns in Design Language
17.1. General Principles17.1.1. Visual information + context = meaning17.1.2. Visually communicate what elements do17.1.3. Have a purpose for every element and a reason for every decision17.1.4. Repeat elements for unity17.1.5. Be decisive, but use the smallest effective difference17.2. Patterns and Principles for Specific Elements17.2.1. Color17.2.1.1. USING COLOR TO ENHANCE USABILITY17.2.1.2. A little color goes a long way17.2.1.3. Use warm, bright, saturated colors for emphasis17.2.1.4. Dominant brand identity colors may make poor dominant interface colors17.2.1.5. Use different values to minimize perceived device size17.2.1.6. Dont rely solely on hue to communicate17.2.1.7. PATTERNS FOR COMMUNICATING EMOTION WITH COLOR17.2.2. Size17.2.3. Shape17.2.4. Line weight and style17.2.5. Type17.2.6. Texture17.2.7. Images17.2.8. Materials and manufacturing17.2.8.1. AUTHENTICITY17.2.8.2. "TEMPERATURE"17.2.8.3. "SOFTNESS"17.2.8.4. "DURABILITY" AND SUITABILITY17.2.8.5. MANUFACTURING AND PART ASSEMBLY METHODS17.2.9. Signature elements17.3. Summary
18. Developing the Design Language
18.1. The Process of Developing the Design Language18.1.1. Look for inspiration18.1.2. Determine how many directions to share18.1.3. Determine what elements to represent18.1.4. Decide what choices best represent primary attributes18.1.5. Adjust for context as needed18.1.6. Begin to render the studies18.1.7. Adjust for secondary attributes as needed18.1.8. Review, iterate, and finalize options to present18.2. Example: NetApp18.3. Example: Executive Telephone18.4. Project Management for Design Language Exploration18.5. Summary
19. Communicating the Framework and Design Language
19.1. Preparing Stakeholders for the Meeting19.2. Crafting the Story19.2.1. Project summary and expectations19.2.2. Review key personas and requirements19.2.3. Introduce the big ideas and major anatomy19.2.3.1. EXPLAIN FORM FACTOR(S) AND RATIONALE19.2.3.2. INTRODUCE BASIC INTERACTION DESING ANATOMY19.2.3.3. Illustrating the interaction framework19.2.3.4. Why to separate functional explanation from scenarios19.2.4. Show how it works using scenario storyboards19.2.5. Revisit anatomy in more detail19.2.6. Describe how the design serves persona needs19.2.7. Introduce the design language(s)19.2.8. Discuss and get agreement on direction and next steps19.3. Managing Your Time and Preparing for the Meeting19.4. Conducting the Meeting19.4.1. Presenting the material19.4.2. Facilitating discussion and handling concerns19.4.2.1. SOME GENERAL PRINCIPLES19.4.2.2. COMMON QUESTIONS AND CONCERNS19.4.2.3. "How does __________________ work?"19.4.2.4. "This is a big change. Won't users be confused?"19.4.2.5. "How do you know this is right? Will you do a usability test?"19.4.2.6. "I don't like it" or "I wouldn't use it that way."19.4.2.7. "Why didn't you design it [like this]?"19.4.2.8. "Why didn't you give us multiple ideas to choose from?"19.4.2.9. "We can't build this. It's not technically feasible."19.5. Summary
20. Detailed Design: Making Your Ideas Real
20.1. Essential Principles of Detailed Design20.1.1. Collaborate, collaborate, collaborate20.1.2. Drive to complete detail, but maintain a systems view20.1.3. Touch everything a second time after it's documented20.1.4. Design for the appropriate time horizon20.1.5. Settle the big issues quickly20.1.6. Consider the cost-benefit equation20.1.7. Reinforce the experience attributes20.2. Process and Project Management for Detailed Design20.2.1. Expanding the team20.2.2. Integration with engineering methods20.2.2.1. WATERFALL METHODS20.2.2.2. AGILE METHODS20.2.3. Typical detailed design tasks by role20.2.3.1. INTERACTION DESIGNERS20.2.3.2. VISUAL INTERFACE DESIGNER(S)20.2.3.3. INDUSTRIAL DESIGNER20.2.3.4. DESIGN TEAM LEAD20.2.4. Drafting a work list and detailed project plan20.2.4.1. DEVELOP A TOPIC LIST AND TIME ESTIMATES20.2.4.2. OTHER ISSUES THAT WILL AFFECT YOUR TIME ESTIMATES20.2.4.3. Delivery approach20.2.4.4. Usability testing20.2.4.5. DISCUSS SCOPE AND PRIORITIES WITH STAKEHOLDERS20.2.4.6. CREATING THE PROJECT PLAN20.2.4.7. Know what everyone is working on every day20.2.4.8. Put the big rocks in first20.2.4.9. Insert check-ins where they make sense20.2.4.10. If you have a fixed deadline, work backward from it20.3. Summary
21. Detailed Design Principles and Patterns
21.1. Principles: a Bit of Science, a Bit of Common Sense21.2. Communicating Flow, Priority, and Relationships21.2.1. Map visual flow to workflow21.2.2. Align elements for readability and simplicity21.2.3. Use visual properties to establish a clear hierarchy21.2.4. Use visual properties to establish association21.3. Communicating Data: Information Design21.4. Using Icons to Communicate about Objects and Tools21.4.1. Making icons recognizable21.4.2. Making icons understandable21.4.3. A summary of useful icon guidelines21.5. Text and Type21.5.1. Type size21.5.2. Additional principles21.6. Widgets and Data Entry21.6.1. Use widgets appropriate to the task and input method21.6.2. Allow flexible input even in bounded widgets21.6.3. Use custom controls only with good reason21.6.4. Considerations for touch screens21.7. Managing Large Data Sets21.7.1. Search versus categories21.7.2. Detailed queries21.8. Audible and Speech Interfaces21.8.1. Personality, emotion, and anthropomorphism21.8.1.1. GENDER, PERSONALITY, AND THE SIMILAR-TO-ME EFFECT21.8.1.2. Gender21.8.1.3. Regional accents21.8.1.4. Personality21.8.1.5. Emotion21.8.1.6. BEING MORE HUMAN (BUT NOT TOO HUMAN)21.8.2. Minimizing frustration21.8.2.1. MINIMIZE SHORTCOMINGS BY MINIMIZING CONTRAST21.8.2.2. PLAN FOR ERRORS21.8.2.3. OTHER USEFUL SOLUTIONS21.9. Products Involving Safety Concerns21.10. Accessibility21.11. "That Little Extra Something"21.12. Summary
22. Detailed Design Process and Practices
22.1. Evolving the Interaction Design: Round One22.1.1. Supplemental research22.1.2. Detailed design meetings22.1.2.1. PROCESS DIFFERENCES FOR SPECIFIC DESIGN PROBLEMS22.1.2.2. Web sites22.1.2.3. Devices in general22.1.2.4. Mobile devices and in-vehicle applications22.1.2.5. Telephones22.1.2.6. Audible and speech interfaces22.1.2.7. Services22.1.3. Additional iteration through individual work22.1.3.1. THE IXD GENERATOR'S DESK WORK: DRAWING22.1.3.2. THE IXD SYNTHESIZER'S DESK WORK: DOCUMENTATION22.1.3.3. BEHAVIORAL PROTOTYPES22.2. Defining the Visual System: Round One22.2.1. Incorporating early stakeholder feedback22.2.2. The visual system first draft: archetype screens22.2.2.1. SELECTING SCREENS FOR ARCHETYPE DEVELOPMENT22.2.2.2. DEFINING A GRID22.2.2.3. Determine your canvas size22.2.2.4. Determine horizontal spacing22.2.2.5. Determine vertical spacing22.2.2.6. Lay out the first screen using guides22.2.2.7. Tweak if necessary, break by rare exception22.2.2.8. Dynamic versus fixed grids22.2.2.9. DEFINING THE BACKDROP: FRAMES, SURFACES, AND DIMENSIONALITY22.2.2.10. DEVELOPING A HIERARCHICAL LANGUAGE OF CONTENT AND CONTROLS22.2.2.11. DESIGNING A COHERENT SYSTEM OF VISUAL FEEDBACK22.2.2.12. REFINING AS YOU GO22.2.3. Continued expansion and evolution22.2.4. Personas, scenarios, and experience attributes22.3. Shared Image Files22.4. Evolving the Industrial Design22.4.1. Refining the form and materials22.4.2. Refining color and surface details22.4.3. Appearance models as design and communication tools22.5. Design Reviews and Collaboration22.5.1. Within the design team22.5.1.1. WHAT TO LOOK FOR22.5.1.2. HOW TO GIVE FEEDBACK22.5.1.3. HOW TO TAKE FEEDBACK22.5.2. With design engineers, SMEs, and business analysts22.5.3. With other stakeholders22.5.4. Remote collaboration22.6. Iteration After Feedback22.7. Common Challenges During Detailed Design22.7.1. Framework flaws22.7.2. Unavailable or unhelpful SMEs or engineers22.7.3. Shifting assumptions and constraints22.7.4. Team member time management22.7.5. Consistency within a brand or product family22.7.6. Uneven depth22.7.7. Using later work to improve earlier work22.8. Summary
23. Evaluating Your Design
23.1. Why, When, and What to Evaluate23.2. Types of Evaluation23.2.1. Focus groups23.2.2. Expert reviews23.2.3. Usability testing23.2.3.1. PLANNING A TEST23.2.3.2. Deciding what you need to learn23.2.3.3. Identifying participants23.2.3.4. Determining your focus23.2.3.5. Designing tasks23.2.3.6. Deciding what kind of prototype to use23.2.3.7. WHO SHOULD FACILITATE A TEST AND INTERPRET DATA?23.2.3.8. USABILITY TESTING RESOURCES23.2.4. Comparative evaluations23.3. Summary
24. Communicating Detailed Design
24.1. The Form and Behavior Specification24.1.1. Background24.1.2. Executive summary24.1.3. Personas and critical requirements24.1.4. Product or service overview24.1.5. Interaction framework overview24.1.6. Scenarios for each interface24.1.7. Overview and details for each screen or function24.1.7.1. OVERVIEW24.1.7.2. FULL SCREEN ANATOMY AND RELATIONSHIPS24.1.7.3. INDIVIDUAL COMPONENT OR FUNCTION DESCRIPTIONS24.1.7.4. EXACT MEASUREMENTS AND COLORS24.1.7.5. Visual system or style guide24.1.7.6. USE OF THE CORPORATE IDENTITY24.1.7.7. COLOR PALETTE24.1.7.8. TYPE SPECIFICATIONS24.1.7.9. PHOTOGRAPHY GUIDELINES24.1.7.10. ICONS24.1.7.11. WIDGETS24.1.7.12. LAYOUT24.1.7.13. SCREEN AND ELEMENT SPECIFICATIONS24.1.8. Ways to expand or cut back: the F&BS as a product roadmap24.2. Qualities of an Effective Spec24.2.1. Prescriptive, not suggestive24.2.2. Clear and professional, not pretentious24.2.3. Unsurprising24.2.4. Persona-focused24.2.5. Standardized24.2.6. Effectively formatted24.2.6.1. SIZE AND ORIENTATION24.2.6.2. LAYOUT AND WAYFINDING24.2.6.3. TEXT FORMATTING24.3. Documentation Process and Practices24.3.1. Documenting as you go24.3.2. Managing images24.3.3. Technical review and document QA24.3.4. Documentation tools24.4. Presenting Detailed Design24.4.1. Structuring and delivering a stakeholder presentation24.4.2. Comprehensive walkthroughs24.4.2.1. SOFTWARE REVIEW24.4.2.2. HARDWARE REVIEW24.5. Summary
25. Supporting Implementation and Launch
25.1. Supporting Software Construction25.1.1. Asset production25.1.2. Questions and reviews25.2. Supporting Hardware Manufacturing25.3. Common Challenges25.3.1. Specification as suggestion25.3.2. Insufficient engineering skills or resources25.4. Summary
26. Improving Design Capabilities in Individuals and Organizations
26.1. Realizing Your Own Design Potential26.1.1. Academic Programs26.1.2. Self-education26.1.3. Experience and mentoring26.2. Expanding Design's Role in an Organization26.2.1. Characteristics of successful change efforts26.2.1.1. INTEGRATING DESIGN IS A PROCESS, NOT AN EVENT26.2.1.2. ORGANIZATIONAL CHANGE DEPENDS ON INDIVIDUAL CHANGE26.2.1.3. REAL CHANGE TAKES EFFECTIVE (AND SENIOR) LEADERSHIP26.2.1.4. INDIVIDUALS MUST BELIEVE THEY'LL GAIN MORE THAN THEY LOSE26.2.2. Overcoming the sense of loss26.2.2.1. DENIAL26.2.2.2. ANGER26.2.2.3. BARGAINING26.2.2.4. DEPRESSION26.2.2.5. ACCEPTANCE (AND ACTION)26.2.3. Instigating change from the bottom (or the middle)26.2.3.1. ESTABLISHING A SENSE OF URGENCY26.2.3.2. BUILD A GUIDING COALITION26.2.3.3. DEVELOP A VISION AND HIGH-LEVEL PLAN26.2.3.4. COMMUNICATE THE VISION26.2.3.5. ENABLE ACTION26.2.3.6. GET SHORT-TERM WINS26.2.3.7. CELEBRATE SUCCESS AND THEN BULID ON IT26.2.3.8. LATHER, RINSE, REPEAT: DRIVE THE CHANGE INTO THE CULTURE26.3. Concluding Thoughts

Content preview from Designing for the Digital Age: How to Create Human-Centered Products and Services

Chapter 12. Defining Requirements

Once you have analyzed your data and represented your findings as models, you have finished the necessary description of the world as it is today. The next step is to begin thinking about the future: what the product or service must do in order to succeed. In the language of product development, these needs are expressed as requirements. Using this term tells all project participants that you're talking about product definition and not just hardware styling or the arrangement of widgets on the screen. Unfortunately, this little word carries a great deal of baggage with it.

The Problems with Requirements

Most requirements processes are fraught with problems. Marketers or product managers spend prodigious amounts of time developing requirements and are disappointed when a stellar product does not result. This is partly due to how requirements are generated, how they're communicated, and a problematic view of their role in the process.

Requirements cannot be "gathered"

Ask the average engineer how the marketing team develops requirements, and he'll probably say (only half facetiously) that the product managers lock themselves in a room with a bunch of competitive products and a lot of beer. Believe it or not, I have seen companies where this was the case, though most take requirements far more seriously. Even in the most structured process, many requirements ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9780470229101Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design