UX project guidelines
Design
For UX designers on site or in production
RUSS KIDS Caroline Chandler
Taokeng-Leute
UX Design Project Guide: For UX Designers Live or In Production Russ Unger and Carolyn Chandler
New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (fax) Find us online: www.newriders.com To report bugs, send a message to[email protected]New Riders is a division of Peachpit, part of Pearson Education. Copyright © 2009 Russ Unger and Carolyn Chandler Procurement Editor: Michael J. Nolan Project Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laflamme Text Editor: Leslie Tilley Proofreader: Suzie Nasol Editor: Danielle Foster Indexer: Valerie Perry Cover Design: Mimi Heft Production Cover: Andreas deDanaan Interior design: Mimi Heft
Notice of Rights All rights reserved. No part of this book may be reproduced or transmitted in any form, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on obtaining permission to reprint and excerpts, please contact[email protected]
Disclaimer The information in this book is provided "as is" without warranty of any kind. While every precaution has been taken in the preparation of this book, neither the author nor Peachpit shall be liable to any person or entity for any loss or damage caused or alleged to be caused, directly or indirectly, by the instructions contained in this book. or the computer software and hardware products described therein.
Trademarks Many names that manufacturers and sellers use to differentiate their products claim to be trademarks. Where these names appear in this book and Peachpit is aware of a trademark claim, they appear at the trademark owner's request. All other product names and services mentioned in this book are used for editorial purposes and benefit of these companies only and no trademark infringement is intended. Such use or use of a trade name is not intended to convey an endorsement or any other association with this book. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 Printed and bound in USA
Kudos to the UX design project guidelines. If Russ Unger and Carolyn Chandler were wizards, the league would be hunting them for revealing their best kept secrets. Luckily they aren't. Russ and Carolyn have collected wisdom previously known only to the most seasoned UX project leaders and codified it for all to see. Now you can learn the secrets you need to run great UX projects. Jared M. Spool, CEO and Founder, User Interface Engineering
Is there a book that tells you everything you need to know about UX design? NO. Is there a book that will best get you there? There are. Carolyn and Russ provide a solid foundation for planning and managing design projects. This is an essential guide for anyone dealing with competing methodologies, endless meetings, and all the changing aspects of UX design. Dan Brown, author of Communication Design
This book is a great introduction to building great products for real people. But it's not just about design, it's about everything design-related: managing projects, collaborating with people and exchanging ideas. A great all-rounder. Donna Spencer, author of Card Sorting: Designing Actionable Category
This is a practical, accessible, and deeply human guide to a very human activity: working with people to do great things for others. Steve Portigal, Portigal Consulting
If you've heard of author Wil Wheaton, you'll understand why I admire Russ Unger so much. Russ's experience and guidance formed the basis of the building and design of Monolith Press and he is one of the most valuable associates I have ever worked with. Wil Wheaton, author of Dancing Barefoot, Just Geeks and Happiest Days of Our Lives
three
Acknowledgments Russ Unger This book would not have been possible without the support of my family, friends, co-workers, and many people I never would have known before my first keystrokes. My beautiful wife Nicolle, who was intentionally married to a geek and superstar, has managed to double down on her parenting responsibilities for most of this article. Our daughters Sydney and Avery constantly stimulated and stimulated their nearly comatose father, getting him to dance, sing and play spore. I subconsciously thought that writing a book at home with a newborn wouldn't be much of a challenge. I figured it out pretty quickly. Nicolle kept coming to my rescue and keeping my focus on completing this project. She is my most trusted heroine; in the midst of chaos, she brings order to our house. It's the center of our world here, and it makes it all too easy for us all to get out of it. Nicolle, Sydney and Avery made me look like a good father and I'm grateful for that. I live in a house with three girls and I can't imagine loving any of them with less than I can give. Caroline kept me informed. Sometimes the project never seems to start or end. She always kept things moving, exploring ideas and pushing us in the right direction. The cooperation was great and I learned a lot! She is definitely a great UX yin to my UX yang. Michael Nolan, our acquisitions editor, is the perfect guide. Michael was honest and friendly and he really helped make everything run smoothly. Rebecca Freed was the sorceress who managed every aspect of the book, keeping us on our toes and often emailing us late into the night. Unfortunately, she often gets replies from me almost immediately! Linda Laflamme was our development editor, and once I got used to her Red Pen of Doom, I realized that no matter how hard I tried to drown her in incomplete thoughts and running sentences, she was leading me in the right direction. Leslie Tilley puts the finishing touches to the sentence; Tracey Croom brings together production, layout and graphics; a real book emerges. Steve "Doc" Baty read each chapter before it reached the Peachpit office. I often send Steve chapters around 2am and he iv
Thanks
I'll send his feedback by 5am, not an easy task. However, Steve is in Australia but still impressive. It's hard to believe that this book would have gotten off the ground without Steve's consistent helpfulness and quick turnaround time. Brad Simpson (www.i-rradiate.com) takes every photo I throw at him and turns them into beautiful, printable prints. It's often about his life, his two teenage-year-old son and a busy work schedule. Brad could walk away anytime, but he was a true friend, interested in the project and willing to support me. I'm not sure there will be enough steak dinners to reward my efforts, but I'll work hard to make it happen. Kudos to Brad for sacrificing many days off and late nights to support this. Mark Brooks found me panicking a few times when trying to convey a message on a visual component that was beyond my time and/or skills. Mark stepped in more than once and saved the day for which I can't thank you enough. Mark was brilliant, made mistakes and was the guy I wanted to be. Jonathan Ashton wrote a whole chapter on SEO for us. After speaking to Jonathan for five minutes, I knew he was the right person for the job. His chapters themselves are a very good reason to buy the book, nice to have on board. Jono Kane stepped in at the very last moment. Jono, a web developer, interaction designer, and prototyper at Yahoo, provided invaluable guidance and support in writing Chapter 12. Lou Rosenfeld really helped push that forward. In addition to being the co-author of the famous The Polar Bear Book (O'Reilly's information architecture for the World Wide Web), Lou is brilliant, friendly, approachable, and always willing to help others in our fields. It will be hard to find someone as generous as Lou is. Christina Wodtke helped me with the introduction and the contacts. I'm not sure where we would be today without Christina, but it probably wouldn't be "in print." Not only is she a must-read author, but she's always available for advice and insight. Many in the field of UX design attribute much of their knowledge to Christina's relentless efforts to broaden their horizons through constant innovation. Thanks
v
Will Evans and Todd Zaki Warfel have generously provided high quality results for you to use as templates for your own. They were true brothers who gave their time and talents without question or concern, and often on the fly. They're great members of our UX community - people to meet and collaborate with - and I'm lucky to be friends with them. I certainly cannot do justice to my gratitude to these two men. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING gang) and Wil Wheaton have given me great friends and true supporters and believers. I'm lucky to have those names on a list of people I know and I'm a huge fan of everything they do. Your support has been an invaluable asset to me in everything I do. I am grateful to these wonderful people who went out of their way to help me by generously contributing opinions, anecdotes, and access to their resources: Tonia M. Bartz (www.toniambartz.com), Chapter 7; Steve "Doc" Baty, (www.meld.com.au), Chapters 3, 11, 14 and "A Brief Guide to Meetings"; Mark Brooks (www.markpbrooks.com), Chapters 3 and 11; Leah Buley (www.adaptivepath.com), Chapter 11; Dave Carlson (www.deech.com), Chapter 11; Will Evans (www.semanticfoundry.com), chapters 7, 10 and 11; Christopher Fahey (www.behaviordesign.com), Chapter 14 Chapter 10; Nick Finck (www.nickfinck.com), Chapter 10; Jesse James Garrett (www.adaptivepath.com), Chapter 10; Austin Govella (www.grafini.com), Chapter 11; Jon Harden (www.jonhadden.com), Chapter 12; Whitney Hess (www.whitneyhess.com), Chapter 11; Andrew Hinton (www.inkblurt.com), Chapter 10; Gabby Hon (www.staywiththegroup.com), Chapters 3 and 11; Kaleem Khan (www.uxjournal.com), "Quick Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), Chapter 14; Livia Labate (www.livlab.com), Chapter 7; Michael Leis (www.michaelleis.com), Chapter 11; Troy Air (www.ascendrealtysolutions.com), Chapter 14; James Melzer (www.jamesmelzer.com), Chapter 10; Matthew Milan (www.normativethinking.com), Chapter 7; Chris Miller (www.hundredfathom.com/blog), "A Quick Guide to Meetings"; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), page 11, chapter 11; Stephanie Sansoucie (www.linkedin.com/in/smsansoucie), Chapter 11; Kit Seeborg (www.seeborg.com), Chapters 3, 11 and “A Quick Guide to Meetings”; Josh Seiden (www.joshuaseiden.com), chapter 7; Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and "A Quick Guide to Meetings"; Samantha Soma (www.sisoma.com), “Quick Start Guide”.
six
Thanks
Conference"; Donna Spencer (www.maadmob.net), Chapter 7; Jared M. Spool (www.uie.com), Chapter 7; Keith Tatum (www.slingthought.com), Chapter 12; Todd Zaki Warfel (www.messagefirst.com) Chapters 7, 12 and 14. I would also like Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest at SXSW, Peter Ina , Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton and all at Manifest Digital and Draftfcb. I inevitably miss someone and I hope it's not about me. The Crowd There are a lot of people in , and I'm trying to keep track of everyone. If I miss you, let me know and I'll make up for it! Finally, it's important to note that without organizations like the Institute for Information Architecture, the Interaction Design Society, etc., it's impossible to get in touch with many of the people mentioned. If you're even a little curious about the field of UX design, explore, join, and get involved with these organizations!
Carolyn Chandler Many of us dream of one day writing a book. Without Russ, I don't know if I would have been motivated to do it. His energy and enthusiasm helped us find the right people at the right time, from the Peachpit team to UX industry executives, all of whom have had a huge impact on what you see on these pages. He truly is one of the best people in our field, with a passion for bringing people together day and night. Also, I think he tweets more than me in a day since I joined twitter! Russ is grateful to the many people who have helped us tremendously. I won't repeat all of those names, except for Steve Baty, who read all of our chapters in every rough form we could get him and still managed to sound enthusiastic at 2am (his time). John Geletka also provided thoughtful feedback and interesting discussions with a spark and perspective that transcended disciplines. And of course the Peachpit team; I will never forget that I got my first chapter back from Linda Laflamme. It's not pretty (despite her very witty suggestion). she is patient
Thanks
Seven
Guided me through the revision and helped me improve my process, which would have been more appropriate for writing a one-off white paper than writing a full book. I now even add transitions to casual conversations with co-workers! Speaking of which... Christine Mortensen, aka Morty, is visually my partner in crime. The charts and diagrams you see in my chapters are the result of her hard work - I know how hard she works because she and I work on many of the same client projects while trying to meet chapter deadlines. Morty is one of those visual designers who can break into visual design and interaction design and enjoys working with everyone on projects and bringing concepts to life. Her integrity and focus on quality make her a pleasure to work with and an honor to work with. A big thank you also goes to everyone at Manifest Digital for their support over the last few months. Jim Jacoby brings a special blend of business acumen and UX perspective, as well as his signature Zen-like calm to help me through some stressful moments. Jason Ulaszek is one of the most passionate UX people I know and his knowledge of tools and technology is endless; I don't know what he's doing with this room! Brett Gilbert and Jen O'Brien also provided valuable input in their various roles working with UX designers. I would also like to thank the members of the Manifest UX team for their inspiration and patience with my constant references to the progress of "the book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. And it is always a pleasure to work with you. Thank you every day for your humor and insight. To the rest of the Interaction Design Society: Thank you for sharing your experiences and being an active member of my beloved UX community. Special thanks to Janna Hicks DeVylder and Nick Iozzo who have played key roles in the growth of the Chicago Chapter and continue to find new ways to build a vibrant network of intelligent people. Finally, I would like to thank my family, friends and Anthony for patiently enduring my disappearance and making sure I am alive. You have a lot of checks to cash and I look forward to spending time with you!
act
Thanks
short introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . fifteen
Chapter 1:
Tao by UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is user experience design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 General Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Do not forget the tangible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
About UX designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Where UX Designers Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Let's begin! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Chapter 2:
project ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 . Determine the type of location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 brand image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Marketing Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Content Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 task-based applications. ...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 e-learning apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 application for social networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Choose your hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 information architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 interaction designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 users researchers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you may play or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Learn more about corporate culture. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 story. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
shrink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Chapter 3: Suggestions
Suitable for consultants and freelancers. . . . . . . . . . . . . . . . . 39 suggestions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 make recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Contents
Neun
Cover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 project approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 working area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 deliveries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Titles and Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional Costs and Fees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 project prizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Confirmation and logout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Chapter 4: Projects
goals and methods. . . . . . . . . . . . . . . . . . . . . . . . 56 Strengthen project goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
How can UX designers help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Learn more about project methods. . . . . . . . . . . . . . . . . . . . . . . . . . . 62 The waterfall approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 modification methods. . ... Which approach influences me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 5: Business
require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Know the current status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Collect ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Summary of Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Call the right stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Make a meeting plan. . . . . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Conduct meetings effectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Consolidation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
X
Contents
Chapter 6: Users
Research . 。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . 86 Create a property list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Setting and defining priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Choose a research technique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How many research activities can I include? . . . . . . . . . . . . . . . . . . . . . . . . 93 user interviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 background checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 survey. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 focus groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 sorting cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 usability tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
After investigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Chapter 7: Roles
. . . . . . . . . . . . . . . . . . . 112 What is role? ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Why should I create a role? . . . . . . . . . . . . . . . . . . . . 113 Finding Role Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Create a role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Minimum Content Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Optional content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
leading role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Final Thoughts on Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Chapter 8: Users
Experience design and SEO. . . 126 Introduction to SEO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Why is SEO important? . . . . . . . . . . . . . . . . . . . . . . . . . 127 Key Basic Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Site technology, design and infrastructure. . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript and other scripted content. . . . . . . . . . . . . . . . . . . . . . 130 content management system. . . . . . . . 133 Domains, directories, and URL structures are all important. . . . . . . . . . . . . . . . . . . . . 134
Contents: Kings who were (and are) and will be. . . . . . . . . . . . . . . 135 naming conventions and counter jargon. . . . . . . . . . . . . . . . . . . 136 metadata, headers and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Contents
habit
Part your hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Use a sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep content up to date. . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Link popularity explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical link popularity distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 footer links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 networking content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Play with the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 White hats and black hats. ....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 clones and door sides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 link spam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Some final thoughts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Chapter 9: Transition:
From definition to design. . . . . . . . . . . . . . . . . . . 144 invention and visualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
The basic process of storyboarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Facilitate the prioritization process. ....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 development lawyers. . . . . . . . . . . . . . . . . . . . . 156 Handling conflicts in prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Plan your events and documents. . . . . . . . . . . . . . . . . . . . . . 162 Chapter 10: Location
Maps and Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . 166 What is a task flow? . . . . . . . . . . . . . . . . . . . . . . . . . 166 tools of the trade. . . . . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . . . . 168 pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 pages stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 decision points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 connectors and arrows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Sloppy Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
twelve
Contents
Misaligned and unevenly distributed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Misplaced text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Missing page numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Simple sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Advanced sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Break the sitemap pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 workflow. ... to a new level. . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 lanes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Chapter 11: Wireframes
and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What are annotations? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who Uses Wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Create wireframes. . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Start simple: design a simple wireframe. . . . . . . . . . . . . . . . . . . . . . . . . . 191 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 wireframes and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Exercise: Design a wireframe for the home page. . . . . . . . . . . . . . . . . . . 195 requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Result: Designing a wireframe for the home page. . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When wireframes mature and find their way into the world. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Follow-up to the design exercise: Which design is correct? . . . . . . . . . . . . . . . . . . . . 201
One final note on rendering wireframes. . . . . . . . . . . . . . . . . . . . . . 202 Chapter 12: Prototyping.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 What is prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How many prototypes do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 paper prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital Prototype. . . . . . . . 207 wireframes and real prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML and WYSIWYG editors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional prototyping resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Contents
Thirteen
Collaborate with developers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
prototype example. . . . . . . . . . . . . . . . . . . . 217 What happens after prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Chapter 13: Design
Test with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 concept exploration. . . . . . . . . . . . . . . . . . . . . . . . . . 221 tips for exploring visual design models. . . . . . . . . . . . . . . . . . . . . . . . . . 224
usability tests. . . . . . . . . . . . . . . . . . . . 225 Choose a method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 planning reviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and logistics . . . . . . . . . . . . . . . . . : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Ph.D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analyzing and presenting results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 make recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Chapter 14: Transition: Transition
From design to development and more. . . . . . 247 And so it ends… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual design, development and quality assurance. . . . . . . . . . . . . 248 Test the design (again) with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … emission! . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal interests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Internet Opinion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
post-publishing activity. . . . . . . . . . . . . . . . . . . . . 253 Post-publication analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 post with users - start design tests (again). . . . . . . . . . . . . . . . . . . 255
Are you ready? ... . . . . . . . . . . . . . . . . . . . . . . . . . . Index 255
fourteen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Contents
Introduction Why We Wrote This Book Welcome to a guide to user experience design projects. A UX design student lies awake in bed not knowing what it's like to work on a real project at his new company. Across town, a visual designer with extensive project experience was keen to take on new roles and define the user experience for her website. They are two people at different stages of life, but with a similar need: to understand how to integrate UX practices into a living project environment. The goal of this book is to give you the essential tools and context for using UX tools and techniques in your workforce. As you will see in many of these chapters, we do not claim to be exhaustive, but have tried to give you the most important information and knowledge that you need to complete many tasks. do. Appointed User Experience Designer. In addition to our own examples, we provide you with examples to help you get started quickly with the basic material and allow you to put information together and create something new, better or even more suitable for your own purposes. We hope we made it clear that this is a very good approach for UX design projects. We just keep trying to learn and improve (which we do) with each iteration. That is why we are active in this area to a certain extent. Quote from Russ As a mentor at the Information Architecture Institute (www.iainstitute.org), I've noticed a pattern in the people I work with: Most have difficulty finding employment or fall short of potential employers' expectations . Some people are well educated, but their UX design skills aren't always good enough to be practical in a project-based environment. The same theme was reflected in many of the conversations I had at the 2008 Information Architecture Summit (www.iasummit.org).
introduce
fifteen
The idea for this book, which addresses many of these common problems, took shape. I can't remember if Caroline or I sent the first email, but I know that in her I found a helpful and capable co-author who helped me flesh out what eventually became the book idea should be. A quote from Carolyn: I've been fortunate to build and manage UX teams over the years. I say happy because I find that UX designers typically have a good balance of qualities that make their job easy and fun, a mix of right-brain intuition and left-brain logic. As I conducted interviews to form these teams, one thing really struck me: Having a relevant educational background, such as human factors or communication design, is a good sign of someone being involved in UX design, but it's not the most Quantity that indicates whether someone fits well into a team or project. Equally important, if not more so, is that person's ability to demonstrate a consultant mentality. This means a positive attitude, a drive to understand and involve others in projects, and most importantly, a focus on making a real impact on users and customers. This mindset means taking the time to understand the perspectives of other roles on the project, making arguments, and making compromises where necessary. Getting this mindset really right takes experience and hard work, but an open mind, solid foundations, and a good set of questions (and the courage to ask them) can go a long way. This book may not give you all the "answers," but it will ask you the questions to find them.
Who is this book for? The UX Design Project Guide provides a comprehensive introductory overview of UX design in the context of a project. Anyone interested in UX design should find something useful here. We specifically target students who are taking UX design courses such as Human-Computer Interaction or Interaction Design and who want to complement their courses with information on how to apply what they have learned in real-world situations where communication and collaboration are key.
sixteen
introduce
Practitioners who want to deepen their knowledge of the basic tools and techniques of UX design and improve team communication between the roles involved. Chapter 3 is also aimed specifically at freelancers who need to create their own proposals. A leader of a UX design team was looking for a book to help his team incorporate project best practices into UX design activities. Project team leaders who want to learn more about how UX design fits into their projects, its value and what to expect from a UX designer. if you have to...
then you have to read...
Define UX design and understand what attracts people in this field
Chapter 1: The Tao of UXD
Ask important questions before a project begins (or at least before you start working on it).
Chapter 2: The project ecosystem Chapter 3: Advice for consultants and freelancers
Get off to a good start with productive meetings, clear goals, and easy-to-understand approval points
Online Chapter: Meeting Quick Start Guide Chapter 4: Project Goals and Approach
Clearly defined and easily prioritized project needs from business stakeholders and users
Chapter 5: Business Requirements Chapter 6: User Research Chapter 9: Transition: From Definition to Design
Understand your users and represent their needs throughout your project
Chapter 6: User Research, Chapter 7: Personas, Chapter 13: User Design Testing
Choose and use tools and techniques to quickly convey visual ideas to your project team
Chapter 10: Sitemap and Workflow. Chapter 11: Wireframing and Annotation. Chapter 12: Prototyping
Make sure your website is easily found and crawled by users and search engines
Chapter 8: User Experience Design and Search Engine Optimization
Communicate with project teams and improve your designs from the start of development
Chapter 14: Transition: From Design to Development and Beyond
Be sure to visit www.projectuxd.com to read the additional chapter “A Brief Guide to the Meeting” and to download other additional materials such as templates.
introduce
seventeen
Notes on the method There are different approaches and methods. We do not favor one method over another. The goal of this book is to focus on the steps that are common to most projects: defining project requirements, designing experiences, and developing and deploying solutions. The degree of overlap between these steps varies greatly depending on the project approach you are using (see Chapter 4 for details). For the most part, our framework is a loosely linear approach that puts the definition steps first. However, at each step we use lightening and design techniques where they are most useful.
This book is not an encyclopedia of all technologies. The UX space is full of creative people who are always trying new ways to solve design problems. If we included all of these methods here, the book would be a much larger one—and one that would quickly become obsolete. What we've included here are the most commonly used techniques and the specifics of UX design. We have tried to provide enough information to pique your interest and enable you to communicate these activities with other project members, including basic procedures for each technique and additional book or website references to help you implement once you get your way have found. You decide. Your guide to becoming a project manager. Good project management, including setting and tracking project goals, timelines, and budgets, is key to the success of any project. We won't go into detail about how to become a project manager or how to take a specific project approach. We've discussed the skills that UX designers bring to projects to execute projects effectively, such as facilitation and communication, and the ability to articulate and adhere to project goals. These skills will help you become a project management partner. A or perfect process or method that you can follow. We don't have all the answers - not today. The field of UX design is relatively young and we are all trying to improve where we are today. You may encounter trial and error, refinement and improvement, and feedback
eighteen
introduce
Others will help you customize the process to suit your needs. If you find something that works for you, please share! Let us know!
How to use this book: There are many excellent resources for user experience designers. We cover a wide range of topics here, but refer you to references that will allow you to delve deeper into the topics, depending on how much time you choose to spend. To help you understand how long each reference typically takes, we've broken them down into three broad categories:
Surfing testimonials accessed with a surfboard are shorter features (usually online) that take 5 to 30 minutes to read.
Snorkeling Snorkeling requires lengthy online articles, white papers, or short books that take an hour to a weekend to read.
The deep diver helmet books are longer titles that may take more than a weekend to read; they provide you with in-depth coverage of the topic.
introduce
nineteen
This page is intentionally left blank
1
The UXD way Curiosity meets passion meets empathy The most important thing is to keep asking questions. Curiosity has its right to exist. One cannot help but be in awe as one contemplates the mysteries of eternity, life, and the wondrous fabric of reality. It is enough if you try to understand a little bit of this mystery every day. Albert Einstein
Curiosity is the primal school of nature. Smiley Bratton
Passion and determination go hand in hand. When you discover your goal, you usually find that it's something you're passionate about. Steve Pavlina
A great human gift is that we have empathy. Mary Streep
1
questions
In short, this chapter is about you—and others interested in user experience design (or UX design for short).
If you are reading this sentence, you are a curious person. You want to know how things work - from doorknobs to airplanes to that thing in your throat. Above all, you want to know what moves people. You see things are not black and white; there are tons of shades of gray to discover! Of course, there are times when you're always ready to play the naysayer, which can drive your co-workers a bit insane, but that doesn't mean you can't stop yourself from looking at the other side of the coin. Lucky you! The field of UX design attracts curious people who like to use multiple shades of gray. We look for patterns and live from organization and structure. We connect the dots. We tirelessly strive for the next piece of the puzzle, and when the puzzle is solved, we look for ways to improve it! We can be analogue or digital. We have pencils and paper, whiteboards and erasable markers, sticky notes and markers at home. We talk about Visio and "Graffle" and we live in a world full of boxes and arrows attached to the various screens of our computers. We're not just curious. We are full of passion! We have a passion for brainstorming and moderating discussions. We are passionate about creating things that have an impact on the people who use them and the people who make them. Weirdly, we're proudest when we make something so good that people don't even realize how good it is! Of course we have empathy. When we have a bad experience, we can feel it deep inside. Worse still, we immediately try to find a solution to the problem. We know what it's like to get an unexpected response to a seemingly simple request, and we don't like it! We don't want users - people like us - to have to live with the confusion and sense of inadequacy that usually accompanies a bad experience. 2
Chapter 1: The Tao of UXD
When you combine that near-constant, child-like curiosity with an unmatched passion for “doing what we do” and a sense of what others are feeling, you create a vibrant community of professionals. They enjoy speaking up, asking questions, sharing solutions, and developing bugs—all under the pretense of doing the right thing. Welcome to the user experience design community.
What is user experience design? There are many definitions of UX design. After all, this is an area of defining things. Granted, sometimes we're not very good at defining "the damn thing" when it comes to the different parts of the whole, but at least we know what the whole is. In this book we will pay particular attention to two definitions: the broadest meaning of the term user experience design and the definition that we will use in the context of this book.
UX design in its broadest sense is the creation and synchronization of elements that influence the user experience at a given company with the goal of influencing their perception and behavior.
These elements include things that users can touch (such as physical products and packaging), hear (advertisements and audio signatures), and even smell (the smell of freshly baked bread in a deli). This includes things that users interact with in ways other than physical, such as digital interfaces (websites and mobile phone apps) and, of course, people (customer service reps, sales reps, and friends and family). One of the most exciting developments in recent years has been the ability to merge elements that affect these different senses into richer, more integrated experiences. Smell and sight are still a long way off, but products beyond continue to blur traditional boundaries.
Was ist User Experience Design?
3
Don't forget the tangible. Although we focus on the digital aspects of the user experience, these types of interactions don't just happen in a vacuum. When designing digital products, consider the impact of tactile experiences. The user's work environment is just as important as the physical product (screen, keyboard, and other input devices), which affects the way the user interacts with the design. Chapter 6 provides techniques to help you understand the effects of context. Also, don't forget the other touchpoints for a product or company and the people it interacts with. Because a company's brand is influenced by many factors and the brand experience does not only end on the computer or mobile screen. The best website design cannot make up for a reputation for poor customer service or provide the satisfaction that well-designed packaging brings when your product is delivered.
Figure 1.1 The modern teaching experience combines analogue and digital.
4
Chapter 1: The Tao of UXD
Tactile experiences, such as learning in the classroom, are increasingly influenced by digital applications. Likewise, previously personal experiences, such as choosing a karaoke machine for home use, gain strength through social interaction.
Figure 1.2 Online reviews are the main influencer for consumers.
Our Focus As you can see, the scope of UX design is huge and growing. For the purposes of this book, we will focus on projects that focus on designing digital experiences, particularly interactive media such as websites and software applications. To be successful, the UX design for these products must consider the business goals of the project, the needs of the product users, and any constraints that affect the feasibility of the product functionality (e.g., technical limitations or project budget constraints). Or time window).
Was ist User Experience Design?
5
Give away free samples of the new nutrient bar at the marathon
a doorknob
Packing for a pair of shoes
Figure 1.3 This book focuses on the digital aspects of user experience design.
Tactile text messaging for mobile phones
Call customer service
personal
social
Our focus: Read product reviews online. Search the online archive. Watch targeted ads
Live chat with digital customer service
About UX Designers While curiosity, enthusiasm and empathy are traits shared by UX designers, they also crave balance. We're looking for a balance, especially between logic and emotions, like Spock and Kirk in "Data and Data" in the episode where his emotion chip overloads his positron relay. you understood. To create truly memorable and satisfying experiences, UX designers need to understand how to create a logical and workable structure for the experience and understand the elements that are important in building an emotional connection with the users of the product. The exact amount may vary depending on the product. An advertising campaign for a children's toy has a different balance than a medical record application for a hospital. Products that are designed without understanding the needs of both companies risk missing opportunities for memorable experiences, and the company behind the product can benefit. NOTE For more information on emotional design, see Donald Norman's Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).
6
Chapter 1: The Tao of UXD
Achieving this balance requires a high level of empathy: the ability to delve into the world of potential product users to understand their needs and motivations. UX designers work on this understanding (see Chapter 6) and create tools like personas (see Chapter 7) to help other members of the project team focus. Remember that emotions are only part of the bigger picture. Use the logical side to break free from the abyss and stay focused on the task. In most cases, base your budget on the time and materials required to complete the project. You have to understand that sometimes you need to fish or cut bait.
Where UX designers live You are not alone. Look around and you will find many organizations and communities where you can grow as a UX designer. Many of these organizations not only provide mailing lists, online resources, and tons of really smart people, but also sponsor events or conferences that can help broaden your horizons while narrowing your professional focus. Many companies host educational events, including User Interface Engineering's Web Application Summit and User Interface Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. In various cities there is also a growing number of 'unconventionals', set up by a group of motivated individuals independent of any particular company or association.
Where UX designers live
7
Some professional organizations also sponsor annual conferences. Table 1.1 briefly lists some of the better-known organizations, their websites, and the events they host. Table 1.1
Example of a user experience organization
organize
website
big meeting (usually held)
Contextual Interaction Design (IxDA)
www.ixda.org
Interactive (early February)
Institute for Information Architecture (IAI)
www.iainstitute.org
IDEA Conference (September/October)
American Society for Information Science and Technology (ASIS&T)
www.asis.org
IA Summit (March)
ACM Special Interest Group for Human-Computer Interaction (SIGCHI)
www.sigchi.org
CHI (ab April)
Association of Usability Experts
www.usabilityprofessionals.org
UPA (June)
Let us begin! You've come this far It's time to dig deeper into why you picked up this book in the first place. Turn the page for an in-depth look at how UX design works in the project space. But that's not all: this book is your guide to getting started. It contains many examples to help you carry out many of the activities for which you are responsible. We also try to provide more examples to help you find your own best practices for creating results that are useful for your team and customers. Keep your curiosity, your enthusiasm and your empathy! Challenge yourself to find new ways to inspire others to create the ideal user experience. That, of course, is before you set about improving it.
8
Chapter 1: The Tao of UXD
2
Project ecosystem planning for project requirements, roles and culture Starting a brand new project? or are you in the middle? In any case, take a moment to reflect on the dynamics and context of the project—issues that affect you and the rest of the project team. Which websites or applications are involved? What roles and skills are required? What is corporate culture? Answering these questions will help you define your project and ultimately identify the tools and skills you need to succeed. Caroline Chandler
9
Second
Every project has its unique challenges. When designing a website or application, many of these challenges relate to specific features and functionality, such as: For example, developing a way for users to share photos online with friends and family, or reorganizing information on an intranet to improve content. manageable. It's easy to find and share. However, all projects have a larger context around these specific design goals that you need to understand and incorporate into your planning. This context is the "ecosystem" of the project, including the environment you will be working in (company culture), the general types of work you will be involved in (e.g. the type of website you are designing), and the people you employ, who you will work with and who you will interact with (including their roles and responsibilities). Taking the time to understand the project ecosystem gives you knowledge that will help you throughout the project. You can communicate your responsibilities and ideas more effectively, and help others on the team anticipate project needs that they may not have considered. To help you, this chapter identifies the different types of projects you can work on, as well as the roles you can play, the people you can count on, and how their involvement varies depending on the type of site or Application you design makes a difference. Finally, the chapter discusses some elements of corporate culture that can affect the way you approach projects. Note Depending on how your client company structures its projects, a given project may involve the design of more than one site or application. For the sake of simplicity, this book assumes that a project involves the design of one type of site. If you have multiple locations, consider each location individually to ensure you have the correct roles on the project team.
Identifying Site Types Although there is no black and white between the various site types, there are some relative differences in site focus and functionality. Knowing these similarities and differences can help you set design goals for yourself. Those are the general questions that should be there
Attributes to be included in the visual and interactive design of the website (e.g., "Explain the company's business model") or displayed (e.g., "Demonstrate the company's responsiveness to its customers").
10
Chapter 2: Project ecosystem
Consolidate the main goals of the project (see Chapter 4). Knowing which departments or business units can (or should)
Participate in gathering business needs (see Chapter 5). Identify best practices for incorporating user research (see Chapter 6). Ask questions about what systems and technologies might be involved.
Your website may be closely related to one of four types:
Brand Identity – A persistent online platform that facilitates the relationship between a business and its general audience (anyone interested in its products or services). Marketing Campaign – a targeted website or application designed to generate a specific and measurable response from a specific or general audience within a limited period of time. Content Source: Information store, can consist of different types of media (articles, documents), videos, photos , tutorials) designed to inform, engage or entertain users. Task-based applications: A tool or collection of tools that enable users to perform a set of important tasks or workflows
In the following sections, we'll take a closer look at each of these types, discussing their characteristics and how they impact your website or application design challenges. We also discuss the most common crossover projects—ecommerce, e-learning, and social—that span more than one type.
Brand Image What do you think of when someone says the word brand? Often the first thing that comes to mind is a company logo, such as the Nike Swoosh or the Coca-Cola logo. However, a company's brand is more than just its logo. It is the overall impression that a given person has of a company.
Determine the type of site
11
Dirk Knemeyer gives some great definitions about brands in his article "Brand Experience and Networks": A brand represents the intellectual and emotional connection that people make with a company, a product or a person... each of us. The science of branding is about designing for and influencing people's minds, i.e. building brands.
For more information on the difference between a customer's experience of a company's brand and a company's efforts to build it, see Dirk Knemeyer's explanation in Brand Experience and the Web: www.digital-web.com/articles/ brand_experience_and_the_web. For an excellent discussion of how a website's UX design can impact a person's brand experience, read Steve Baty's article, "Brand Experience in UX Design": www.uxmatters.com/MT/archives/000111.php.
Companies can do many things to influence associations with their brand, from running memorable advertising campaigns to expressing brand attributes (like "responsiveness" or "value") through their website's functionality and design. All websites within a company can have some impact on the company's brand, either directly (by presenting the website for customers to visit) or indirectly (by providing important services that customers depend on, such as customer support) . However, the main focus of the branding website is to present the company's branding information and brand equity. They offer direct communication with customers and extensive online channels for those who want to learn more about a company or its products. A brand presence website is usually the company's primary .com or .org website, e.g. B. GE.com, or for larger and more widespread companies around the primary websites of business units of all sizes, e.g. B. GEhealthcare.com. Different product lines often have their own unique brand images online as well. For example, Pepsico.com has a branded image, while Pepsi.com has its own unique image.
12
Chapter 2: Project ecosystem
If you're working on a brand presence page, you're likely designing for a variety of audiences, including current and potential customers, investors, partners, media (e.g., news outlets and writers from well-known bloggers), and job seekers.
Common Brand Pages The company's main website (company.com, company.org, company.net, etc.) The website of the company's main business unit (usually a unique website)
(specific industry, region or broad product websites) of well-known sub-brands within the company
Brand Image Design Goals Typically, the most important design goals in a brand image project are: to convey the company's brand values and message,
Either explicitly (perhaps a statement of how important it is to be responsive to customer needs) or by addressing the overall experience of the site (e.g. by ensuring that the site works well and offers outstanding features that customers need to interact and interact with encourage communication with the company). Provides quick and easy access to company information. you want to
Answer the questions "What does the company do?" and "How can I contact someone for more information?" Present or explain the company's business model and value proposition:
“What can the company do for me?” and “What about the company?” to target key user segments and guide them to relevant interactions
features, functionality or content. Help the company achieve the set goals through key indicators e.g
The number of unique visitors. This is often part of an overall marketing strategy. Later, in the Pick Your Hat section, you'll learn about the different roles that can be involved in designing a brand presence website. Let's see
Determine the type of site
13
The other types of websites you may work on also include those that are closely related to brand presence websites: campaign websites.
Campaign sites are similar to brand showcase sites in that both focus on engaging users by influencing their experience of how your company's brand is perceived. However, marketing campaign sites are often judged on their ability to take very specific actions within a specific focus, such as within a specific time frame or target audience. They do not serve as a channel for generating interest, but rather as an engine for generating interest. From an online perspective, this usually means that they are aligned with the overall marketing strategy and can run alongside other marketing efforts across different channels, such as TV or radio ads, print ads, and other promotions.
General campaign page A landing page that promotes a specific offer. This page can be accessed via
A banner ad from another site. A small website (or microsite) promoting a specific event. A game or tool designed to make a splash
or traffic.
The main purpose of a campaign website is to create a targeted campaign, usually focusing on a specific set of metrics. Focus is usually narrowed by one or more of the following factors: Timing - for example around an event (e.g
conferences) or seasons (e.g. the Christmas season) user groups – such as B. Youth or teacher events, products, product suites and/or specific uses of the product –
For example, one website highlights kitchen appliances by showing a virtual kitchen with a matching oven, dishwasher, and stove
14
Chapter 2: Project ecosystem
A marketing campaign that combines these tactics would be a spring marketing campaign focused on selling gardening tools, combining timing and product range. See Figure 2.1 for an example of product suite and user group combinations. A campaign page can be as simple as a banner ad that leads to the landing page of a company's .com site, or it can be a microsite, a small page that is often distinct from the branding visible on the .com site, to create an experience on one or more focus areas. “Small” is relative here: some microsites only have one page while others have many, but in any case, a microsite is smaller and more focused than the main page for a company's brand presence.
Figure 2.1 Texas Instruments uses this educational microsite http://timathrocks.com/index.php to present information about the company's graphing calculators. This suite of products is primarily intended for use by high school and algebra students. The microsite maintains a general connection to the Texas Instruments brand, but is intentionally differentiated to appeal to a younger audience and to organize content and features according to their needs.
Campaign Design Goals For the person or team responsible for the design and implementation of a campaign website, the most important design goals are usually the following: Generate interest and excitement, usually by providing a clear and straightforward presentation.
Another value proposition (the value that the product or service provides to the user, e.g. the ability to quickly qualify for a loan) or some type of incentive (special offers, entertainment such as entering contests or online games) .
Determine the type of site
15
Involving a number of key user groups to perform certain unauthorized actions,
Examples include clicking somewhere on a website to access a brand image, signing up for a newsletter, or applying for credit. When a user does this, it's called a transition. Help companies achieve goals set by key metrics like numbers
The number of unique visitors. This is often part of an overall marketing strategy.
For more detailed information on designing pages to support marketing campaigns, see Tim Ash's "Landing Page Optimization: The Definitive Guide to Testing and Tuning Conversions" (Sybex, 2008).
Content sources Content source pages contain stores of information, possibly in various media types (articles, documents, videos, photos, tutorials), designed to inform, engage and/or entertain users.
A public content source site. A company's intranet. An online library or resource center for members of an organization. A site or area of a site devoted to news or general information
Updated Posts (Big company blogs may fall into this category) Customer Support Center
Of course, all websites and applications have content, but some websites put a lot of emphasis on the presentation and structure of their content. The focus may be because the site has so much content that it brings its own challenges, or because certain types of content are important; for example, they can support important decisions or lure users back to the website on a regular basis.
16
Chapter 2: Project ecosystem
The main purpose of content resource sites is to increase user knowledge and autonomy by providing relevant content (e.g. an intranet). They also often encourage some action, such as sharing information or purchasing a product, after looking at a description. Content Feed Design Goals A content feed website typically needs to do one or more of the following: Present content that is the primary content that will drive first-time visitors and returning visitors to the site. Demonstrate the intellectual leadership skills of the company e.g
By providing access to the thoughts and perspectives of the CEO or other subject matter experts in the company. Support important decisions in user groups. Expand your company's business knowledge by coming up with the following ideas
Believed to be buried in another department. This could be part of a larger goal to identify more opportunities for innovation. Support users searching for information in different ways. For example,
Some people don't yet know what specific product they need (and are more likely to look around), while others may know exactly what they are looking for (and are more likely to use the search box).
Browsing For more information on the different ways users search for information, see Donna Spencer's Four Modes of Seeking Information and How to Design for Them: http://boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them
In terms of UX design, the most common tasks in content source projects include: Creating taxonomy structures that fit users' mental models. Decide how to integrate organic content growth systems
(Functions like tagging and filtering) Design effective search tools to identify site types
17
Task-based applications Task-based applications can range from a simple calculator embedded in a mortgage website to a complete system that handles several important workflows. If your project involves the latter, many more stakeholders will be involved and an extensive requirements gathering process will likely be required (see Chapter 5 for more information on this process).
Common task-based applications support the creation of software applications for specific types of computers
Item (such as a spreadsheet or printout) A web tool or application that facilitates essential workflows on a computer
Websites where the business (e.g. a ticket management app for an IT support group or a customer tracking app for a call center) allows access and management of personal data
(z. B. Flickr)
The main purpose of task-based applications is to allow users to perform a set of tasks tailored to their needs and ultimately achieve the customer's business goals. Objectives for Designing Task-Based Applications Most task-based applications should enable users to do something they cannot do elsewhere, or, if they can,
Do better (“better” can mean more efficient, effective, satisfying, or convenient). Support novice users with easily accessible instructions and visual prioritization
The main task section supports intermediate and advanced users in accessing shortcut functions
and richer features Reduce user load and maximize system resources
(e.g. data reuse required instead of duplicate entries)
18
Chapter 2: Project ecosystem
Designed and implemented keeping in mind the degree of change required
Application users – ideally with a design that facilitates learning and a communication plan that provides value to users. One of the biggest challenges in designing task-based applications is controlling function propagation. When developing a project, it's common for great ideas to emerge late in the design or even during development. UX design is great for preventing feature creep, as user models (e.g. personas) can be used to identify high value features and keep them in focus throughout the project. If a really good idea emerges late in the process that meets the needs of a high-priority user group and aligns with the site's business goals, your team may make the case for a change of direction. If an idea doesn't resonate with the person struggling with it, it probably isn't worth the delay and expense.
Ecommerce Websites An ecommerce website can contain elements from all four article types, as a website primarily dedicated to ecommerce will have its own brand identity, provide content (usually product specifications or product instructions), and missions must facilitate (search). , compare, write a review, watch). Marketing activities are also often closely related to these websites and may span multiple marketing groups within the organization. A common additional design goal for ecommerce websites is to explain the model of the website (if it is non-standard). as an online marketplace
This interpretation is constantly being rethought and helps raise expectations (e.g. eBay, Amazon and Craigslist have very different models). Support decision making as users transition from learning to thinking
From compare to buy, with helpful content and features. Benefit from experience points through cross-selling and up-selling
as well as possible and post these suggestions in a way that catches the eye without being distracting. Create from point of purchase to
place of delivery. Communication should not only take place within the website, but also through other channels, such as integration with delivery tracking systems and communication of order status via email. Determine the type of site
19
E-learning apps E-learning apps are a mix of content sources and task-based apps. Course content needs to be generated, which often requires teams to add Learning Expert and Subject Matter Expert (SMB) roles for the topics covered. The product is task based as users typically need to follow the flow of a course and may also need to track progress or explore related topics. Some practical courses may also require homework to be completed. General design goals include understanding the fundamentals required to begin the course
and its target audience. Provides rhythmic content in manageable sections
Concept. Engage students in activities that simulate hands-on learning. Communicate performance and progress and make recommendations where appropriate
Next steps in the training process, such as additional courses.
Social Networking Applications Social networking applications are primarily task-based applications because users need to be able to find and add friends, manage their profiles, socialize, post, and search. However, they also present challenges related to content sources, notably the need for an organic framework to be able to handle potentially very large volumes of user-generated content. Essentially, when a website is given its own identity, it also takes on the characteristics of a branded showcase website.
Snorkeling If you're developing a social networking application or trying to integrate social functionality into another type of website, this book will help you get started: Designing for Social Networking by Joshua Porter (New Riders, 2008).
20
Chapter 2: Project ecosystem
A common design goal for social networking applications is to make potential users aware of the purpose and value of the network. Enable meaningful interactions between support and supported users
Supported by provided features like image sharing, video sharing and discussions. Protect the integrity of websites by securing websites within the network
Knowing how to manage your messages and respond to inappropriate behavior. Harness and demonstrate the power of community to drive success
Features only available to active members such as B. Popular features and reviews. Determining the type of website or application you will be using during your project is only the first step. Next, you need to consider the different roles that are typically required and how their involvement differs depending on the type of project.
Pick your hat: When you become a UX designer for a project, you often have to fill multiple roles. Whether or not you are formally defined within your client organization, the roles you play will depend on the nature of the project and the makeup of the rest of the team, as well as the client's experience with each role. It's good to know which roles you're already comfortable with and which ones you think you can learn on the job. It's also helpful to find out what others expect from the duties of these roles. With this knowledge, you can present yourself more clearly at the beginning of your project. What is the most common role of a UX designer? Each client company you work for may have a different title for these roles (or no name at all if it is not an official position in the organization). In general, you can expect the big three: information architects, interaction designers, and user researchers. Note Few companies have the size or budget to spread these shared roles among multiple people. When defining projects, remember the role names, but talk about requirements and responsibilities when talking to clients – otherwise they might think you're building a very large team! This focus on responsibilities rather than titles also helps keep sanity: Having a few of these roles doesn't necessarily mean you'll be doing lots of other people's work, as responsibilities fluctuate and fluctuate in different parts of the team. Project.
choose your hat
21
Information Architect An information architect is responsible for creating information structure models and using them to design user-friendly navigation and content categorization. Common responsibilities in site and application design include creating detailed floor plans (see Chapter 10) and ensuring that categories and subcategories of information are clear and accessible. Understanding Expectations In the UX world, the roles of information architects and interaction designers are differentiated (see below). In any organization, however, there are few common differences between the two roles, at least when it comes to the requirements of a particular project. For example, you might end up on a team called "Information Architects" because that's the historical name for the role, regardless of whether it's a really good fit for your job or not. Did you have to correct the project team when the title you were given didn't match the leadership role you assumed? If the project is short-lived (e.g. four months or less) and the title you hold is well-received within the organization and responsibilities are clear, it may not be worth attempting the to change any confusion that may arise. However, if there is no commonly accepted title and you feel there is a potential need to represent both roles (perhaps through different people), it is worth making the distinction early in the project when you are evaluating your involvement and communication define. Attachment. your responsibility. Essentially, for more task-based applications, it makes sense to emphasize the role of the interaction designer, and for more content-based projects, it makes sense to emphasize the role of the information architect. But perhaps it makes the most sense to use terminology that is familiar to the client organization and to ensure the team understands how you define the role in relation to the responsibilities you assume. You must formulate this definition in your job description (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see “Other Roles” below). If these roles are
22
Chapter 2: Project ecosystem
Have several people represent you in the project team and be sure to discuss how you will work together at the beginning of the project.
Interaction Designers Interaction designers are responsible for defining the behavior of a website or application based on user actions. This includes flow across multiple views on the site and interactions within specific views. Common activities during site or application design include creating task flows that show interactions between pages or components within a site (see Chapter 10) and creating wireframes that show page interactions, such as B. dynamic menus and expandable content areas (see Chapter 11). Know What to expect if you're working in a small team or on a project that doesn't heavily focus on creating new task-based features (e.g. working on a registry). The interaction designer is the main role responsible for defining the project's requirements (see Chapter 5). If you are an interaction designer working on a project with a high level of new functionality, there will most likely be a single person on the team responsible for creating detailed requirements (e.g. a business analyst or product manager). A UX designer's skills can be of great help in capturing and detailing functional requirements, while documents such as functional specifications and use cases are influenced by experience design. Be sure to sit down with the person responsible for gathering requirements and discuss how best to work together.
User Researcher A user researcher is responsible for providing insights into end user needs based on information generated or validated by the person's user research. There are many types of activities that fall under the user research umbrella, and they can occur at different points in the project schedule. (See Chapter 6 for descriptions of common techniques such as user interviews, surveys, and usability testing.)
choose your hat
23
Knowing Expectations A client company's desire for user research can vary greatly, depending on how seriously the project team or project sponsor takes it. The fact that the UX design is discussed with the project sponsor before the project begins shows that someone on the client team knows that ensuring user needs are addressed is a priority. But, as those who have worked on computational projects know, incorporating research can also instill anxiety among project team members - fears that user research will create bottlenecks and increase risk (what if we make a mistake? Make big changes), to solve the problem? ) or to refute the value of a particular idea that has gained popularity. Business prospects and project teams may have different expectations for user research. So make sure you clarify what these two groups want from the role. Customers should also expect user researchers to provide insights based on website analytics - tools and reports that provide patterns in website usage, such as B. Frequently visited pages and frequent points at which users leave the website. Some of the most commonly used analytics tools come from Google (www.google.com/analytics), WebTrends (www.webtrends.com) and Omniture (www.omniture.com/en/products/web_analytics). You can assume all three roles: information architect, interaction designer, and user researcher. Can you balance all three factors or will you chew more than you can chew? This depends in part on the size and schedule of the project, but the nature of the project also affects the extent to which each role can be involved. Table 2.1 describes how UX design roles differ by project type.
Browse Do you want to promote UX design? Here are some articles that might be helpful: "User Experience Is a Business Imperative" by Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Advertising UX Design for Ten Dollars a Day" by Louis Rosenfeld: http:/ /louisrosenfeld.com/home/bloug_archive/000131.html
24
Chapter 2: Project ecosystem
Table 2.1
Shared responsibilities of UX design roles
information architect
Marke
marketing activities
content source
task-oriented application
Moderate commitment.
Smaller sites, such as a single landing page, have low engagement. Moderate interaction with larger microsites.
Commitment is high. Content assets require an information architecture that strikes the right balance of structure and flexibility, providing users with a solid foundation to support and enable program growth.
Moderate to high engagement, primarily focused on creating navigation boxes, unless some workflows require references to larger contexts.
Small sites have low engagement, while large microsites or promo games (sponsored online games designed to generate play and excitement) have moderate to high engagement.
Moderate to high commitment.
Commitment is high. These types of projects typically require the most work, as the results of the interaction design, such as B. user flows and wireframes, for which visual communication of requirements is crucial.
Because campaigns are often temporary, user engagement is often low. A more permanent solution could use research similar to a brand showcase website. It's also common to use analytics tools to render two or more variations of a given page to see which leads to the most conversions. This is known as A/B testing.
Field research, such as background research, can help teams understand how different users are currently using information.
The greater the content challenge, the more the project acts as a source of content.
Interactive design
Moderate commitment. The higher the number of tasks, the more the project behaves like a task-based application.
User research engagement varies based on budget and user access. Here you will find common techniques for each project type. See Chapter 6 for more information on each technique.
Research efforts can focus on understanding the needs of priority user groups (through surveys or interviews) or on design studies that test the effectiveness of specific visual designs in conveying the right brand message.
Search, tagging and filtering capabilities cross the boundaries between information architecture and interaction design. Content sources can also have workflows for creating and managing content.
Card sorting is a great way to understand how users group information, as well as common patterns and mental models.
On-site research, such as background research, can be performed to understand what users are currently doing. However, the most widely used and well-understood technique for engaging users in task-based application design is usability testing.
Once the framework is established, the structure can be validated through usability testing.
choose your hat
25
Other roles you may play or need. Some roles aren't typically covered by the UX Designer role, but their responsibilities often overlap with the UX Designer role, especially if you're working on a project where no one officially fills the role and you have the skills bring along. Some of the most common overlapping roles include: brand strategist or steward, business analyst, content strategist, copywriter, visual designer, front-end developer
The following sections explain each of these roles in more detail and explain how they vary depending on the type of website you are designing. Brand strategists and brand stewards are responsible for building relationships with key markets through the definition and consistent presentation of a company's brand elements, which can include everything from brand values (e.g., "responsiveness") to text and message guidelines, logo treatments, specifications for color and layout. This role often includes creating or representing brand guidelines and understanding how they apply to different projects. It can also be about understanding or defining a target audience that is important to the project you are working on. In most cases, you might be working with a brand strategist, but you're not taking sole responsibility. Brand Stewards are not required to create policies but are responsible for ensuring that they are properly followed throughout the project. This responsibility can be delegated to the UX designer or visual designer of the project. When the company's brand attributes, values, and guidelines are clearly defined, and the website is expected to conform to those principles, your role as brand steward of a project is primarily to ensure that the deliverables conform to those guidelines. Your contacts outside of the project should be
26
Chapter 2: Project ecosystem
A member of the marketing department who can offer advice or provide reviews, but is not a full-time team member. If the website is designed to expand the brand in some way (e.g. by entering a new market), the role of brand manager can be more active. This is particularly relevant when creating an entirely new brand identity or when a company makes drastic changes to its brand, thereby transforming itself. For example, CellularOne completely rebranded itself to Cingular, a major effort by an established company. In this case you must either be very experienced in brand development or have a clear and close relationship with the people in the company. These key questions will help you understand what to expect from your branded personas: Do you already have brand guidelines? If so, how strictly does the project have to comply with them? Who is responsible for establishing or maintaining the brand message, the brand?
The look and tone of the content (e.g. informal or professional)? Does it appeal to a new audience that hasn't been reached before?
brand definition? If so, who is responsible for keeping brand guidelines relevant to these audiences? Will there be a naming or renaming event? If yes, how should I plan?
concerned? (An example would be naming a new tool that is heavily promoted.) For projects that do not have a significant potential impact on a client's brand perception, such as B. developing an internal app, enlisting a brand manager can be as simple as checking in occasionally to ensure the brand is well received. Good performance. Business Analyst The business analyst (also known as the business systems analyst in IT projects) is responsible for identifying key business stakeholders, driving the requirements gathering process (see Chapter 5), and acting as the interface between the business stakeholders and the technology. primarily contact for . Team. He or she is also the primary owner of detailed requirements documents such as functional specifications and use cases when required.
choose your hat
27
The business analyst or product manager role may not exist at all in your project, or it may be one of the most important roles in the design process. This is often the case for mission-based applications and content sources, but it may not be the case for branding projects and marketing campaigns. For task-based applications, this role is most likely required. The more functions and the more complex the project, the greater the need for dedicated staff and functional documentation. While business analysts are not typically considered members of UX teams, small UX teams are often asked to fill the role. Therefore, it is important to understand where these responsibilities lie. Business analysts drive the capture of business needs and act as a liaison between technical teams and key business stakeholders. If there is a business analyst for the project, that person and the interaction designer usually agree. If it is the same role, the responsible person can track many documents! To understand what is expected in this area, ask who is responsible for outlining the scope of the project, facilitating discussion of requirements, and documenting requirements throughout the project. On small or non-feature-rich projects, project managers sometimes take on this responsibility. Either way, if not yourself, you still know who to work with to ensure your results are in sync. Content Strategists Content strategists are responsible for understanding the business and user needs of cross-media content (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating workflow and new content development. Significant efforts are often underestimated. A client may have a lot of content that resonates well in one medium (e.g. a printed brochure or a video), but that content may not be appropriate for the project you are working on. Also, people within a customer organization sometimes have unspoken expectations of content—and those expectations can surprise those people when it comes time to fill your product with descriptions, news, and help topics! If quality content
28
Chapter 2: Project ecosystem
Key business drivers for the project: Make sure you know who is responsible for: Establishing content policies for new products (content type,
sound, quantity). Assessing the suitability of existing content
guidelines. Develop new content. This depends on the general project type. for
A task-based application that may contain explanatory text, error messages, and help topics. For content sources, this can be articles, news, and blog posts. Act as a liaison between stakeholders and technical teams,
Limits and possibilities of content management systems. Define the different content types and the metadata for each (
information that ultimately makes searching and cross-referencing more efficient). Planning content migration, creating templates
Target different content types and ensure content is properly tagged and loaded when pushed into the site's content management system. (Again, the amount of effort required is often underestimated.) Copywriters Copywriters are responsible for writing the text that makes up the overall experience on a website. In some cases, this value remains fairly constant from day to day. It usually contains a website and a page introduction or page description. Contributors can also be involved in the ongoing creation of dynamic content, such as writing copy for news or marketing campaigns. Copywriting is one of the gray areas that UX designers often face, especially when creating wireframes (see Chapter 11). You can start by typing sample text as placeholder text, like a site or page description, but eventually someone will need to fill it in with the final text before it's visible to users—and since many projects don't require special writing, that's the case The task can be left to you by default. In these cases, you're unlikely to be asked to write for a prominent part of a brand's website or marketing campaign
choose your hat
29
Every word can be questioned. However, if you're developing a task-based application that requires short explanatory messages, error messages, or other types of information that don't necessarily belong in an explicit content library, you might (or will) inherit this writing task. file with developer by default). Ask ahead of time if a copywriter is available, and if you can't find one, check back with the wireframe. If the task works for you, be sure to include this work in planning your activities during the project. Be warned: this is a responsibility that is often overlooked or underestimated. Visual Designers Visual designers are responsible for the elements of a website or application that users see. This work includes designing the look and feel and creating an emotional connection with users based on brand guidelines. For example, a banking website often needs to appear stable, reliable, and accessible. Visual design can provide this certainty through visual elements such as color and imagery. This promise is then fulfilled (or broken) through the interaction design of the website and other touchpoints with the company, such as the call center. Let's face it: many people call themselves visual designers, web designers, or graphic designers, and many websites have poor or passable visual design. There's a big difference between creating an effective, compelling, and emotional visual design and just getting through it. Sometimes breaking even is enough to meet project goals, other times it causes project frustration and delays when project sponsors are dissatisfied or first-time adopters are not included in the design. On the other hand, it's also easy to focus too much on the impact of the visual design, thereby compromising the usability of the design. If you've been asked to fill this role and aren't sure you can make the right impact with a customer, take a look at the company's current website and the website or product that the customer appreciates from a visual perspective to assess your comfort level. Visual designers often play a very important role in brand identity projects and marketing campaigns, and are primarily responsible for effectively communicating a company's brand.
30
Chapter 2: Project ecosystem
For content source projects, they can focus on creating content templates (such as article templates) that can be applied to many pages. For task-based applications, they can provide style guides that can be applied to common interaction elements such as navigation panels and tools (requiring a high degree of collaboration with the interaction designer). Front-end developers Front-end developers are responsible for building the technical structure behind the page design and flow, as well as interactive elements within the website, e.g. B. Scrolling menus, expandable content areas and interaction with multimedia elements such as videos. Technologies such as XHTML, CSS, Flash, JavaScript, Ajax and Silverlight are often used in this work. Front-end development focuses on site elements that are directly related to what users see and not on the back-end systems that provide the underlying platform (e.g. databases, content management systems and code required to operate the site). function behind the complication). When you or a member of your team take on the role of a front-end developer, it's important to work closely with the rest of the development team to understand expectations and responsibilities. Other important issues are which backend systems to integrate with, what method to use to generate HTML, the need for flexible page structure to accommodate custom skins, and expectations for technologies like Flash. If a prototype is planned (see Chapter 12), ask who will be responsible for developing the prototype and what functionality is expected. Prototypes intended simply to convey functionality can be quickly created in applications like Flash, but full-featured prototypes that need to retrieve real data (e.g. the account information a user just entered into a form) need to be in be created in a fraction of the time. Collaborate with members of the backend development team. Are you afraid to take on all these roles? Unless you're working on a very small project - or in a very small company - you probably won't be taking on any of this. The key is to understand what roles you can and want to fill, if needed, for the specific project you are working on. Otherwise, you can get the support you need within the project team by building your network within the client company or by referring additional people to fill the need. Let's take a moment to talk about how to do this.
choose your hat
31
Build a user interest network. For those areas you're not sure you can or want to address, it's time to ask for help. You can do this in three main ways: It is recommended to add more team members as needed
Sure enough. Advance in key areas where gaps exist – as new responsibilities
The opportunities are manageable and you have the time to invest in them. Build a support network within the company to help you in critical moments.
Let's take a closer look at how to build a support network. Chances are there are some key resources elsewhere in your organization that can help you succeed. You need to estimate how much time these people will need, since on a project that is primarily department-led, it can be difficult to ask outsiders for time. If you don't want to take up too much time right from the start, just ask if you can work with them (or consult with them) to get the best possible outcome for the key tasks of the role. Once you've partnered, you'll have a better understanding of how much interaction you need and whether you need to make a more formal request for his or her time. Every company has a different structure and different department names, but here are some common places to look for partners: For a brand strategist position, ask if someone works in the marketing department
Departments that can act as contact points. This can also be a resource for visual designers and content strategists. Visual design and content strategy partners are also available at
Program or product management or R&D, operations, or corporate strategy departments, where you'll often find business analysts and product managers. IT or technical departments are often the best choice in the frontend
Developers and others who can help you access and understand web analytics tools.
32
Chapter 2: Project ecosystem
If you've recently been hired by a new company and want to work in a different department, it's best to identify key individuals who are potential partners and schedule an interview with them to learn about their roles. learn and experience . It starts with a network that you can usually count on for the long term and gives you a chance to explain your responsibilities (and UX design in general). You can also ask a good question at the end of the interview: "Who else do you think I should talk to?" The answer can help you find people who may not be obvious to your key project managers or client contacts. If you have been with a company for some time, you can always start planning such interviews. In this case, it's best to tie it to a specific milestone (eg, starting a new project) or business goal with some urgency to ensure high engagement. Make sure your manager knows what you're doing so it doesn't seem like you're bypassing him or her. Good communication is key to understanding role expectations and building trust. Another key to building trust within an organization is understanding the culture, the often unspoken expectations of how the organization works, which are driven by previous project experiences (positive or negative), etiquette related to organizational hierarchies, and acceptable logistical workspaces (eg. working from home).
Understanding Company Culture Culture is a bit like putting an Alka-Seltzer in a jar: you can't see it, but it works in a certain way. — Hans Magnus Enzensberger
A company's culture may not be consistent across all regions, divisions, or departments, but you can often identify key characteristics that impact you and the project or projects you undertake. Here are some aspects to consider when researching your project and dealing with potentially difficult political situations.
understand corporate culture
33
History We all know that those who cannot remember the past are doomed to repeat it, and project work is no exception. Knowing how the project or team got into the current state of emergency can help you understand the challenges you might face during the project. Let's discuss some questions you can ask to understand the history that can affect your project. While some of the answers to these questions may seem scary, remember that something triggered the need to involve you in the project, so a project may have a rocky history and still succeed. They could be a big part of your success! However, if many of the issues discussed below are true and you feel like you can't fix them, this could be a red flag. If so, consider an overall assessment of the project's chances of success. What examples of previous projects seem to have been taken into account?
is successful, what does it seem to be doing? Which projects seem to have failed (or been particularly painful) in the past and why? Asking these questions (either directly or in a more subtle conversational style) can help you understand many things: how respondents define success, the potential risks of the project, and what preconceived notions or expectations are brought to the project. and effective methods. Has the company worked with the same company and hired a designer?
project or team? If so, try to figure out what doesn't seem to be working and which customers would like a different approach. If you can ask this question to more than one person in the company, you can better understand unspoken expectations. If you get two completely different answers, it probably means that the designer's responsibilities are not clearly defined and you need to ensure that your responsibilities are communicated appropriately throughout the project. Is the project team involved in the project (or related materials)?
Does it seem like it hasn't been made for a long time?
34
Chapter 2: Project ecosystem
If so, it could indicate that the client's key stakeholders weren't on the same page or didn't engage at the right time, resulting in multiple delays, changes in direction, or wasted time due to multiple iterations. It can also mean there's no clear leader, someone who can say "no" (or at least prioritize effectively) to stay focused on organizational goals. If you can influence communication about the project, it can be helpful to develop engagement guidelines to move the project forward. Whether the company creates the design without prior involvement
User Experience Designer? That can be a mixed blessing. On the one hand, you're dealing with a team that understands the design requirements and tries to fill in the gaps. On the other hand, you may end up with a design that you feel doesn't fit the goals of your UX project. This can be a tricky situation. It's often best to approach the creators of these designs with the tone of a respectful mentor or helpful advisor, first highlighting the strengths of the design and then discussing the goals of the UX and how it can be improved in various ways. YouTubers are likely important members of your support network. So it's important not to burn bridges here, but to redefine your role in a collaborative way to keep the excitement going. Does the lead sponsor or project manager seem particularly concerned?
About the project? This can be for a variety of reasons, especially if some of the factors above come into play. Anxiety can also stem from market stress, which will help you understand. For example, has the company's share price fallen? Has a particular competitor made an alarming move recently? Is the company losing money? Again, these circumstances do not necessarily mean that you should not take on the project; after all, projects in such cases are usually financed first. However, if you're seriously concerned that the company won't be able to pay its bills, you need to weigh that risk.
understand corporate culture
35
Hierarchy Geert Hofstede has a great model for describing cultural differences, which he calls 'cultural dimensions', which often affect the way people communicate and interact with each other. One is the concept of power distance, the extent to which members of society (in our case a corporation) understand and accept the distance between people at different levels of power. For example, if members of a company's leadership team are seen as particularly powerful and potentially difficult to access, there may be greater power distance within the company and employees may be more hierarchical. If the company encourages the democratic exchange of ideas and the challenge of opinions, the power distance can be relatively small.
Power distance is “…the extent to which less powerful members of organizations and institutions (e.g. families) accept and expect an unequal distribution of power. This represents inequality (more vs. less), but is defined bottom-up, not top-down. It shows that the level of inequality in a society is recognized by followers and leaders.” Geert Hofstede Cultural Dimensions www.geert-hofstede.com
Neither of these extremes can be considered good or bad in and of themselves, although most US workers generally seem to prefer lower power distance in the workplace. It's worth noting that this isn't necessarily an indicator of a company's success. Apple has a relatively large power gap (if you look at the aura around Steve Jobs), Google has a relatively small power gap as part of its culture, but both companies are considered innovation leaders. It's important to note that the power distance within the client organization affects how successfully you navigate the political waters during the project. This aspect becomes particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at important milestones such as signoff points (discussed in Chapter 4). If you work for a high power distance company, bring extra
36
Chapter 2: Project ecosystem
Take the time to understand reporting relationships such as For example, understand stakeholder surveys and assessments before scheduling meetings and consider involving more middle-level people in your communications.
Logistics In addition to the larger cultural aspects mentioned above, it can also be helpful to understand some elements of a more logistical nature so that you can better integrate into current workflows or make thoughtful changes. For example, it is helpful to know the overall progress expected in the company, including any important release dates or deadlines affecting the project (the progress of building a software application on an annual release schedule may differ from that of a microsite with seasonal activity, e.g Example). Does your team want to work overtime to meet an upcoming deadline? Remote work vs. on-site work expectations are also easy to understand. If a lot of time on site is expected, plan a trip and allocate resources there. If remote work is acceptable (or encouraged, which is common when working with multinational corporations), it is important to understand the tools and means of communication. For example, is it acceptable to use instant messaging apps? Which web conferencing tool do you use? Are there methods of engaging international stakeholders that have proven effective in the past? It is also interesting to learn something about the "paper culture" in the company. Some companies prefer predominantly electronic media. In this case, a good projector and a consistent Ethernet connection are important. Others are very paper conscious. In this case, you should ensure that you bring enough copies to the meeting to make the meeting more efficient. You may want to change the culture of your project if you think another way is more effective. But it's good to know that you're asking people to make a change so you can make the transition smooth and potentially understand why a particular approach isn't working the way you expected.
understand corporate culture
37
Putting it all together Now that you've explored the terrain of the project, you should better understand the project ecosystem: the environment you will be working in (organizational culture), the general type of work you will be doing (e.g. the type of website ) and the people you interact with (including their roles and responsibilities). This information is valuable once you have outlined your role in the project and are ready to get started in earnest. If you are a freelancer or subcontractor, this will give you the basis for writing a project work proposal (see next chapter, Discussion of UX Proposals). If you work in a larger team and are not directly involved in preparing the offer, you can contribute your new knowledge at the project kickoff, the first meeting of your team. For basic guidance on how to run a good meeting, check out the online chapter, “A Quick Guide to Meetings,” or Chapter 4, “Project Goals” if you want to know right away what questions to ask at the start of your project. and methods.
38
Chapter 2: Project ecosystem
3
Advice for consultants and freelancers. A guide for those in the industry who also run their own business. Managing projects and client expectations can be challenging enough, but if you don't have the right offer, you could end up on the losing end of the day. , every project you undertake. Proposals and job descriptions are vital to protecting your business and yourself from financial and legal problems. After accepting the project and shaking hands, be sure to take the time needed to draft an agreement that outlines the terms of your relationship and the client's payment schedule. Lars Unger
39
There's an old saying, "Nothing's as bad as it gets," and the same goes for winning a project - the high fives and feel-good moments are quickly replaced by "Oh crap! Time to write the proposal! The biggest challenge in writing” replaces A proposal is writing your first proposal. If you've never written one yourself, it's almost impossible to know where to start, and that's where this chapter should come in handy. Each type of project you come across will have a different set of these styles. Be vigilant when drafting proposals. Fortunately, all proposals have a common core that can be reused across projects (see Chapter 2 for a detailed discussion of project types). When to Write a Proposal Anytime Why Write a Proposal In the entire history of project work, the projects that put people in the most embarrassing situations are the ones where there is no agreement between the customer and the supplier. If this is your first time connecting with a prospect and they click on it, you might be tempted to skip this step. Even if you know exactly what your customer wants and can articulate it in a way they understand, you're not really ready to get started. In fact, you need to slow down and take a deep breath here. Rather than committing to it, instead take the time to define your professional relationship and define how you will interact with new clients. Jean Marc Favreau of the law firm of Peer, Gan & Gisler, LLP in Washington, D.C.: Contractors and their clients often think they have a deal to do right at the beginning of the relationship. Consensus, while in reality ambiguity lurks. While it's almost impossible to prepare for every possible eventuality, a comprehensive written contract is your best defense and one way to ensure you don't end up in a situation where you have the opportunity to fight the terms of your relationship in court. The more clearly you can predefine the terms and parameters of your relationship with your client in a written contract, the less likely you are to end up fighting over the obligations of both parties.
40
Chapter 3: Advice for Consultants and ZZPs
New projects and new people are exciting. Normally, you don't want to close a deal by proposing, but as with any relationship, that honeymoon feeling will eventually wear off. Either party in the relationship can break the promise. The customer may not provide you with access to the content in a timely manner. (I know this is almost unheard of, but believe it or not, it's happening! Here's the irony in case you missed it.) Funds once available for the project could be diverted elsewhere -- and then for you, the busy people If you have a job, you can keep your bag in your hand. Businesses are also aware that they take risks when working with third parties, especially small businesses or independent contractors. A well-written proposal can provide the client with a sense of stability and protection, which can help alleviate many of the concerns that may arise. Suggestions also allow you to define terms and conditions to protect both parties in case of changes. If the customer does not provide you with timely access to their resources, your schedule may change; You need to make him aware of his commitment to the success of the project. If the client loses money and abandons the project - and you don't have a quote or any other form of contract - you risk not getting paid for the work you've already done. The essence should be clear: always write a proposal.
Creating a Proposal Once you've started your project, it's time to finalize your proposal. The sooner a proposal is approved and signed, the sooner you can start work and—most importantly—the sooner you can get paid for your work. A key part of a good proposal is the title page, revision history, project overview, and project methodology
make a suggestion
41
Scope of Work Assumptions Deliverables Title and Title Additional Costs and Fees Project Price Payment Schedule Confirmation and Signature
Let's take a closer look at each part of the proposal.
Front Page A front page is a simple page that introduces a document. Front pages are an interesting thing: you can design them in different ways from a stylistic and informative point of view. How you do it is up to you. A typical cover page contains the following elements: Client company name Client company logo (if you have access to it) Project title Document type (proposal) Proposal version Submission date Your company name Proposal author Project reference number Fee confidentiality
In your initial quote please include everything except the client's company logo, cost and (possibly) the project reference number. Why not put these elements on the front page?
42
Chapter 3: Advice for Consultants and ZZPs
Your customers know who they are. Obtaining permission to use a company logo is probably not worth the time and effort, nor is it worth the inconvenience that can result if you accidentally misuse it. It is best to place the costs after you have identified the different parts of the project in the body and the cost information leads well to the payment schedule. Make a note of the project reference number. Many companies will not use it at all; however, some government agencies are known to rely on this particular element and if it is not on your front page your proposal may be rejected.
Figure 3.1 Sample title page proposal
A (fictitious) customer logo is used in Figure 3.1. It's best not to show a client company's logo without getting permission or building a relationship.
make a suggestion
43
Revision history Revision history is a separate section of a proposal that shows the number of times you've updated a proposal since the original version. In general, it's a good idea to include the version number, date, author, and any comments about the version, e.g. B. What has changed to provide readers with context for the change (Table 3.1). Table 3.1 Revision
Example Revision History Table SECTION
describe
edit
Benchmark
original file
to register
8. Jan. 09
assume
Updated to meet software requirements
to register
11 January 2009
1,0 1,1
Sometimes a client will approve an offer and then ask you for further revisions. If you continue to use the client and want to make these changes, you should take this opportunity to update your documentation from version 1.x to version 2.0. Essentially, you start with the customer agreeing to the offer and both parties agreeing to the terms. So if additional adjustments are required, consider them carefully. This ensures that your costs are still reasonable and that you have a clear understanding of both sides of the customization and at what stage the project will restart (if necessary). Always adequately explain why a revision is an entirely new version in the revision history.
Project Overview The Overview section is a description, in your own words, of the project you will be working on. This description should give your customer a clear idea of what you want in their product and also tell them what to expect from the rest of the offering. Here is an example of a statement beginning: [Name of client company] is attempting to create a new online presence on the web. This website enables customers of [customer company name] to research and purchase products and other services and benefits offered by the company online. The goal of an online presence is...
44
Chapter 3: Advice for Consultants and ZZPs
You should be able to give a solid overview in a paragraph or two and go into great detail about what your client expects of you. Ideally, you end the overview with a detailed explanation of your proposal and proposed approach to completing the project: The proposal contains [your company name]'s proposal and approach to [customer]'s design and development and describes in detail the online Offer. Given the deadline of [Deadline Date], it is recommended that...
Project Approach The project approach depends on the type of project you are undertaking. This is your chance to let the client know how you would like to work with them on the project. They set the rules for the job and set expectations for future jobs. Many individuals and companies take a very similar approach, but use different names or clever acronyms to fit their overall branding. There was once a wonderful way to present (potential) customers and it was used in many proposals. This process is called the PURITE Process™ (pronounced "purity") and a mythical creature dies in the process as I share it with you. So be sure to read it as if it were fiction. The name of the process is a bit cheesy and the process is obviously a bit incomplete. With this method, the post-publish analysis (errors) is omitted, but of course all clients should be included. Without further ado, here is the PURITE approach: [YOUR COMPANY NAME] has established a standard process for successful projects with our clients. Although each of these phases may not apply to [Project Name], the overall process is defined as follows: The PURITE Process™ is [Your Company Name]'s internal methodology for ensuring the overall success of all programs. With PURITE, [YOUR COMPANY NAME] has proven policies to reliably meet and exceed delivery expectations while working closely with customers and users/the public. P - get ready. We devote a portion of each program to understanding your industry and your competitors and how they do business, in order to obtain as much information as possible before we start gathering requirements. You understand. We work closely with your subject matter experts and/or users to define the requirements to properly build your project.
make a suggestion
45
R - Render. During the rendering phase we create and develop all parts of the project/product. Our experience is that each phase of development requires a lot of attention and focus, but also timely, open communication with your team. It also requires that we... I - I repeat. The iterative phase is repeated throughout the project life cycle. We work as quickly as possible to bring projects to life, which often requires the creation of multiple iterations in tight schedules. This requires the immediate and timely involvement of you and your dedicated resources. The end result is a product that you specify and help create. T test. We test each project during the rendering phase; however, we also need an extra pair of eyes - from our own testing team and your designated user group/audience for targeted testing. This extra round of testing helps leave as few building blocks untested as possible to deliver a project that has been rigorously evaluated at multiple levels. E - Enabled. After successfully completing the first five phases and receiving your approval, we will activate and implement the solution. PURITE Process™ doesn't stop there. After completing the project, we communicate regularly with the customer. We continue to measure your satisfaction, understand your changing goals or program improvements, and help you find the best path for your program.
You can use as little as you need or whatever is best for you. The author of the myth of the creation judgment does not mind if he is not given credit. The definition of your process can be as detailed as above or as simple as: plan, define, develop, expand. Planning. overall strategy. Identify detailed project requirements. Develop, test, improve and initiate work products and post-release information for improvement
Once you have defined your process, you have the opportunity to detail the different tasks that go into each phase of your approach and explain what each task means for you and your client. The length of the methods section of a proposal depends on the project, the process, and the activities that take place at each step of the process. However, try to limit the scope to a maximum of two or three pages
46
Chapter 3: Advice for Consultants and ZZPs
Make sure you only include deliverables that you can deliver to your client – to avoid further file updates or project pricing reconsideration.
Scope of Work In the Scope of Work section, you define the division of labor for the project. That is, you determine which parts of the project you are responsible for and which parts the customer is responsible for. Read that again. Think about it. Let it sink in. Here we go. Is correct. It's the part of the proposal where you say to the customer in writing: We'll do this, you'll do that. If the customer later signs your proposal, they agree to this agreement, and you have a written record of that agreement provide evidence in case of misunderstandings. The point here is to clarify who is responsible for which aspects of the project and which aspects of the project are included in your bid and estimated price. This should be reason enough if you can't find another really compelling reason to write a proposal. Here is a very brief example of the scope of work: [Client Company Name] contacts us to provide all the services required to create [Project Type]. [YOUR COMPANY NAME] specializes in the [UX design aspect] of [CUSTOMER COMPANY NAME]'s website. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] compared to the project plan. [Client company name] provides all the necessary resources to use in the project, including fonts, color schemes, branding standards, etc.
Assumptions The Assumptions section of a proposal is a great place to clarify what your client needs to ensure your success without room for discussion. That is, these are the things you anticipate—and communicate to the client—that you will have access to or will make available to you to make the project a success.
make a suggestion
47
The assumptions you make in this section are actually expectations. It's much more polite to just accept. You can create as many project plans as you like, but if neither you nor the client is committed to meeting milestones and goals, then both are committed to failing a given project. Generally, these assumptions are expectations of resources and assets and timely (translation: quick, immediate) access to both. The following is an example of writing an assumption: Assume that [customer company name] needs to provide the following assets and resources. Failure to provide these assets and resources in full and in a timely manner may result in the failure or delay in the implementation of this project. The following assets and resources are required: Timely access to all necessary [name of client company] personnel. Instant access to all required assets of [Project] in its current state, including all source files if available. Content including, but not limited to, text, images, audio, etc. of all aspects of [Project] as required.
Deliverables are work products that you create and deliver to the customer. In this section you have the opportunity to explain to the customer in detail what work results he expects from you in the course of the project. It's recommended that you tackle the status report separately toward the end of the project, but feel free to include it in that part of the project as well. Include a description of any work product that you may have included, even if the work product has not yet been created. This may seem like an exaggeration, or possibly come across as an open statement, "I've read the [available types] in the proposal, but I don't see them here," but one sentence can change everything. Deliverables [YOUR COMPANY NAME] will provide various deliverables throughout the project. For [name of client company] we have identified the following services:
48 years old
Chapter 3: Advice for Consultants and ZZPs
Creative Brief The creative brief is the first step in the project. This document helps us to create a general overview of the project quickly and efficiently. The purpose of the creative brief is to clarify the user's goals and needs, and to define any special resources and/or constraints associated with the project. etc…
Ownership and Rights It is important to consider the extent to which you allow clients to use the work product you create. These rights can be defined in many different ways, but most of your work falls into two categories: paid work, licensed work
Rental works (referred to in legal circles as “loans”) are deemed to have been created and copyrighted by the party paying for the work, and not the party responsible for the actual work. This means that if you work on a commissioned project, you have no rights whatsoever in that work and any content you create in connection with that project is owned by the client. This situation is difficult for many companies and individuals to cope with: it often means that there is no downstream "maintenance" (with additional revenue) since the customer can choose to have the maintenance done after the project is completed. Don't be distracted by customers enforcing prescribed things; that's not unusual. This is quite normal in employer-employee relations when one puts the issue of employment for work in the context of full-time employment in the company. This is also an opportunity to review your pricing model - many items charge a little more to cover potential future sales losses. Remember that everything depends on your relationship with your customers and the way you do business. Time and experience will help you make the right decisions about the nature of your work and the pricing model you choose. With a licensed work item, you retain copyright in the work but grant other parties the right to copy and/or distribute the work. You can include as many clauses in your license agreement as you like. You will probably create a proposal
49
If you retain ownership of all work source materials and only provide limited-use work products (e.g., PDFs instead of original, editable Word, Visio, Axure, OmniGraffle, or other documents) to your clients, you can use your work benefit. There are many ways to license your work, including licensed works for use without modification, non-commercial use, or any other way that suits your situation. Creative Commons (http://creativecommons.org/about/licenses) provides an easy-to-understand explanation of the different types of licenses available to you. However, this is only a small part of the licensing landscape. If you are faced with very detailed and specific requirements, it is best to consult a copyright attorney to find the best solution.
Additional Costs and Fees It is important for your clients to understand if you charge them for projects that take into account external sources. For example, some projects require purchasing stock photos from suppliers. You can purchase the film (with appropriate usage rights) and include it in the fee, or you can make it clear that buying the film is an additional cost that is passed on to the customer. You can also offer services that you want customers to know about - this is a great opportunity to promote them. The following is an example of how additional costs and fees are handled: Additional costs and fees When external resources (such as content, images, fonts, etc.) are required, they are identified, approved and reported to [customer company name]. In addition, [YOUR COMPANY NAME] can provide hosting services to our customers with minimal effort. We offer hosting services, including configurable web-based email, starting at $25 per month, plus $25 for setup. If [customer company name] wishes to purchase a maintenance package, [company name] will endeavor to put together a mutually beneficial package.
50
Chapter 3: Advice for Consultants and ZZPs
Project Pricing After you've documented the details of the project work, it's a good idea to communicate the cost to the client. How you come up with a price is largely up to you, but here's a tip: Estimate how long you think the project will take — including a certain number of revisions. Estimate a reasonable amount of time spent on project management, this could be around 25%. ; Then decide what billable hourly rate you want to charge and go all out. There are several formulas that can help you with this, such as applying a difficulty level to each part of the project to help you determine the range of costs you can offer your client. In most cases, experience is the key to correctly assessing your project from a time and material point of view. How do you determine your billing rate? To compare, research what others are charging by looking at contractor salary surveys and rates. For example, organizations such as the Information Architecture Institute (www.iainstitute.org), AIGA (www.aiga.com), Coroflot (www.coroflot.com), and talent agency Aquent (www.aquent.com) conduct contractor fee rate surveys. You can get a good idea of what rates you might be charged by considering your own experience, what others in the market are charging, and what you think is reasonable. Note: You can lower your tariff at any time. Once customers see the numbers on the page, it's difficult to ask for more from them! There are many different ways to price your project build. Depending on the nature of your project, you may want or need to provide multiple estimates to allow for different pricing options. Suppose you offer a customer two options: a static HTML website and a website with a content management system (CMS) that supports dynamic content that the customer does not need special resources to manage. How to create a Project Estimate: Project Estimates [your company name] has proposed several estimates for [customer company name] to provide the best option for your current and/or future needs. [your company name] assumes that all content is provided by [customer company name]. If [your company name] is hired to provide content services, the estimates will need to be redefined.
make a suggestion
51
Estimates for [YOUR COMPANY NAME] provide flexibility in terms of cost and demand. The estimates are as follows: Estimate 1 [YOUR COMPANY NAME] estimates [PROJECT] for [CUSTOMER COMPANY NAME] with no interactive content...
Remember: there really is no wrong way to put your project estimates together unless you are in a negative cash flow situation!
Payment Schedule There is a myth that all freelance projects are paid 50% upfront before work begins and 50% at the end of the project. This myth needs to be busted - now! It's not a way to do business or ensure a timely, steady stream of income while you get the job done. Instead of going through a change workflow, you don't want to have to make change after change for one client just because you want to complete the project and get paid for it. You can price projects in a variety of ways, from submitting invoices within a predetermined timeframe to making milestone-based payments. A smarter approach is to ship your items on a recurring payment plan with regular, detailed invoices. This approach should also provide the client with a clear understanding of what the project has achieved and what still needs to be done. The following example is one way to arrange payment for your work: Payment Plan [YOUR COMPANY NAME] A typical payment plan is to receive an upfront payment of XX% of the estimated total price of the project before it begins. [YOUR COMPANY NAME] will be billed on the 1st and 15th of each month; full payment is made within 14 days. Upon completion of the project, [your company name] will deliver all work products to [client company name]. Once the materials have been approved to your satisfaction, [your company name] will refund the remaining commission amount or [your company name] will issue a final invoice for the amount not included in the commission. NOTE: If [Project] is put on hold for more than 14 days and no work is carried out, [Your Company Name] will provide a final invoice for all costs not included in the commission and you will be entitled to one upon reopening priority purchase project.
52
Chapter 3: Advice for Consultants and ZZPs
While not required, it's helpful to add a note about what to do with the project if it hasn't been used for a long time. This determination can help keep your project on track and moving forward, and it can provide you with talking points with your client. If you don't have to do extra work for them for a long time, you want to be able to go ahead and find work to fill the gap.
Confirmation and Signature While it's important to make sure you have a proposal, it's not enough. The proposal doesn't mean much until the right people at your client company approve and sign off on it. It must be ensured that everyone has a clear idea of what is to come and how much is expected of each party. It's also important to protect yourself from the "iteration superhighway" and reduce the risk of customers catching you in "feature creep": constant demands for "one more thing to add". Signing is very simple and straightforward. After you create the proposal document, you provide the customer with confirmation and signatures to approve the agreement between the two companies. Always prepare two copies - one for each party - and make sure both copies are signed. Here is an example of an acknowledgment you could use: Acknowledgment This offer has been fully acknowledged and approved by [customer company name]. This offer must be signed and dated by an authorized representative of [customer company name] to be effective. Alternatively, a signed order with reference to this offer shall be deemed acceptance in lieu of such signed document (provided that any pre-printed terms in such order are deemed invalid). This offer constitutes the entire agreement between the parties with respect to the subject matter of this offer. This proposal constitutes and supersedes all prior agreements, discussions, negotiations, commitments, writings or understandings, whether oral or written. This includes, but is not limited to, any statement contained in any sales literature, brochure or other written descriptive or promotional material and constitutes the full and exclusive statement of the terms of the contract between the parties. Each party acknowledges and agrees that in implementing this Proposal it will not rely on any statement or has made and expressly disclaims any representations not contained herein or in the Agreement.
make a suggestion
53
Accepted by an authorized representative: [your company name]
[customer company name]
Type:__________________________________
Type:__________________________________
Name: _____________________________
Name:_____________________________
Title: _____________________________
Title: _____________________________
Benchmark: ________________________________
Benchmark: ________________________________
Make all checks payable to: [your company name]
Statement of Work The Statement of Work (SOW) is a general definition of the project goals, which you should be able to summarize in a two to three page document (without a cover page). Statements of Work are usually written before detailed requirements are addressed. However, depending on your client and project needs, you may choose to create a hybrid document that best suits your needs. In general, the SOW should be used to build consensus between your team and the customer's stakeholders as early as possible. The SOW defines the inputs and outputs of the project, as well as its assumptions and limitations. At this point, it's not uncommon for clients to ask you to provide a "budget number" for the work you'll be doing for them. It might be a bit risky to answer that question now. It is recommended that you try to avoid details or commitments without defining them. If you haven't written a proposal and/or requirements document, it's simply impossible to know how much a project will cost. However, you must make a judgment on this. If you are working on a project, say a simple website, and have already successfully completed several similar projects and/or previously worked with the same client, then you have some wiggle room. Remember: It's better to be cautious than get into embarrassing situations later in the project. The work summary should be about two to three pages long and contain at least the following:
54
Chapter 3: Advice for Consultants and ZZPs
Title Page Revision History Project Reference Number Project Overview Start Date End Date Rates/Prices Project Description Activities and Deliverables Specify costs and payment schedule. confirmation and signature
Are these elements known? They should - you can compose the ToR with an abbreviated version of the proposal. You have now seen how to develop two types of documentation to identify the work you perform for a client. These documents should form the basis of any project work you undertake for your client and provide you and your client with a clearly defined set of instructions for the project flow.
job description
55
4
Project Goals and Approach: Knowing Which Star to Navigate One of the keys to a good project is to start the team with clear project goals and an easy-to-understand methodology. Ideally, project management will have this defined for you, but if not, how do you know? This chapter is about setting project goals and asking questions that help strengthen those goals. We also discuss some common project approaches (or methodologies) and how they impact the way you work. Caroline Chandler
67
And
We are in the kickoff phase of the project and this is the first time with the whole team. The project manager distributes some materials and gives you an overview of the project. Ideally, by the end of the meeting, you should have the following information:
Why is this project important to the company? How do stakeholders determine whether the project is successful? What approach or methodology will the project follow? What are the key dates or milestones for important points, such as B. procurement?
Approval of the business prospects? All these questions are related to what the stakeholders expect from the project: what the project will achieve and how they will participate. The first two questions relate to the project goals and the last two to the project method. A project goal is a statement about the measurable goals of the project. Let's discuss these goals in more detail.
Strengthen Project Goals Goals are the important focusing lens you use throughout your project. They must flow from the client company's overall business strategy, so the project objectives must align with the strategic initiatives within the company. For example, if there is a strategic move to attract a new group of potential customers (called a marketplace), the website or application you create may be an attempt to provide that marketplace with online access to related products and services. The aim of the project will then be to enter this market and win it over. A clear goal resonates throughout the project. It helps you ask the right questions while gathering ideas from business prospects. Plan research with users and analyze the results in one place. Detail and translate ideas collected from stakeholders and users
Prioritize project requirements based on their value to the business within a consolidated list of project requirements
Strengthen project goals
57
Create effective interaction designs. Manage design change requests once development begins. Focus on implementation activities (e.g. training and communication).
Communicating with users about a new website or application before and during launch) Determine if you have ever met the needs of a client company
Project Initiation When you start a new project, you likely have project goals from the project sponsor (the business partner directly responsible for the project's success) and a series of project-related requests from business partners and customers. but they can all be a bit blurry (Figure 4.1). Your goal is to translate these into factual statements that you can use as a measure of your project's success.
Project-Related Requirements
Business strategy with vague goals
User needs stakeholder concept
blurred target
User Complaints What stakeholders think
Figure 4.1 Vague goals, ideas and needs
A solid goal is easy to understand. Avoid internal jargon. different. Avoid ambiguous statements; use phrases like
Helps prioritize requirements. measurable. Make a concrete statement that you can make on your own
Measure your success. When you define a vague goal and make it clear and measurable, it becomes a solid goal to base decisions on.
58
Chapter 4: Project Goals and Approach
Figure 4.2 Goal verification
Goals of the business strategy project
You will hear many statements that could qualify as goals. Analyzing ambiguous objects like the following will help you solidify your goals and communicate more effectively across the project team. company representative
Second
"Our goal is to be the market leader in industry X."
This is a company-wide goal, but too broad for a specific project. To achieve this, multiple initiatives within the organization must work together; any site or application can help, but it's unlikely to be able to handle the full load unless the entire business is committed to the site or application and it ended up being a big hit. company representative
Second
"Our goal is to inspire passion in our customer base."
This is better as websites or apps can affect it, but it's still too vague. Why is it important to generate enthusiasm? How does that enthusiasm translate into meeting business needs? How do you know if you are successful? company representative
Second
"Our goal is to increase traffic to our website."
Now we are there. This is easy to measure, but focuses too much on intermediate steps. Let's say you're driving traffic: if people there aren't taking the action you want, it probably won't help you.
Strengthen project goals
59
Vague goals allow you to understand the client's needs and larger goals. From this, you can set more specific project goals, such as increasing online sales revenue by 10%. Increase online advertising revenue by 20%. Increase the number of existing and potential customers among our customers
Database to at least 20,000. Provide highly rated and referenced content to our key users.
(Note that deciding how to measure "highly appreciated" and "highly cited" took some work, but these elements are valid.)
Each of these factors can be measured and influenced by your project. They can also be a great match for your design and the functionality you provide. For example, it's common to offer an online newsletter to achieve the goal of growing your customer database: to send out a newsletter, you need to collect your customers' email addresses and add them to your database. Goals can also bring new requirements with them. For example, if you measure success by the average rating of items on your site, you need a feature that allows users to post reviews. This way, goals help you focus on collecting ideas for your website, and they can later become project requirements. If there are multiple goals, be sure to create a priority list with the corporate sponsor and project team. There are sometimes conflicting goals during the design process, and the team needs to know which goals take precedence. The final list of prioritized goals should come from your project sponsor, but you can be an important part of the discussion. Let's talk about how.
How can UX designers help? You can use your facilitation skills if you find that the project goals are not clear at the beginning of the project. Help the project team understand the business context of the project by holding workshops with key stakeholders (see the next chapter for more information on identifying the right stakeholders). This meeting usually lasts two to four hours. Your goal is to present information about your company's strengths and weaknesses.
60
Chapter 4: Project Goals and Approach
Chances and risks. This is known as SWOT analysis and is a common business analysis technique and a way to discuss a company's position in the market. You can also use this time to talk about the company's competition. Understanding Strengths and Weaknesses SWOT Analysis The SWOT Analysis is about the current strengths and weaknesses of the company in relation to the project. Strengths and weaknesses can be both internal processes and external perceptions - and they often influence each other. For example, a company with a large research and development (R&D) department may have access to a large source of original published research (an advantage), but may have no one to make that content more accessible to ordinary users, leading to a perception that the company " too academic” (weakness). OT is the forward looking part of SWOT. Given the factors that differentiate the company from its competitors, what are possible future initiatives to develop new niches or strengthen existing ones? What circumstances jeopardize these plans? For example, our research and development company may choose to hire writers to publish more understandable editorials around the original research (an opportunity), but if the site's current tools do not have robust content curation capabilities, the publishing process can be very slow . This can give competitors the ability to respond to threats more quickly. Competitor Comparison What are the company's main competitors? Who are the competitors of the website to be developed? They can be different, especially for larger companies or brand new locations. Are there any sites that are not direct competitors but represent interesting models worth considering? You can learn a lot by looking at other ecommerce sites to see if and how they sell what you are selling. When collaborating, SWOT and competition discussions are good simultaneous topics of discussion because they interact. Hard to say
Strengthen project goals
61
Address future threats without knowing who your competitors are – Once you start talking about future opportunities, new competitors may come to mind. Once you have a solid understanding of your competitors and your company's SWOT, your project goals - and the overall fit of your project into your company's strategy - should be easier to define and the priorities between them should become clear. Consolidating project goals helps you understand what the project will achieve. Next, let's talk about project flow expectations. Knowing the project methodology will help you collaborate effectively and get the right people on board at the right time.
Knowing the Project Approach Knowing the overall approach or approach to the project is an important part of knowing when and how to get involved and how to involve others such as your project team and business stakeholders. Sometimes it seems that there are as many project methods as there are projects. Choosing the right approach to a project is a big subject in itself. Which approach you choose depends on many factors, including the structure and location of the project team, the technology used in the project, and the extent to which collaboration is part of the organizational culture. For the purposes of this book, we assume that you are joining a project where the approach is largely determined by those responsible for the project's success, such as the project sponsor and the project manager. In this case, your main goal is to understand the approach and help make it work for business prospects and your users. Here we focus on two of the most common methods and a third showing possible variations you might see in your project. It's important to note that most approaches involve the same steps: planning the overall strategy, approach, and team structure. Define project requirements. Design interaction and visual concepts and refine them into details
Specification. Develop, test and improve solutions.
62
Chapter 4: Project Goals and Approach
Deliver the solution through messaging, training, and planned adoption. Extend the project by suggesting improvements.
The names of these steps can vary, as can the degree to which they overlap and how information is documented. However, the general activities in each step are the same for most projects and all three models presented here.
Waterfall Approach In the waterfall approach, project steps are treated as separate phases, requiring approval for one phase before the next phase can begin. For example, the design phase does not actually begin until the requirements have been approved by the business stakeholders, who sign off on one or more requirements documents at the end of the definition phase. in agreement with
the plan
in agreement with
in agreement with
Definition, Design, Development, Implementation, Deployment
Figure 4.3 Example of a waterfall approach where each stage "flows" into the next stage.
The problem with the pure waterfall approach is that it assumes that each stage can be completed with minimal changes from the previous stages. So when you come up with new requirements during the design phase (which is quite common), you have to propose changes to the document that were approved at the end of the definition phase, which can disrupt plans and schedules.
Agile methodologies Because change is continuous, project teams are always looking for ways to be more agile than the waterfall model. Many methods take a more fluid approach, with some steps happening side by side. For example, versions of a website can be released on a rapid, iterative schedule using agile or rapid development methods. Agile methods often place more emphasis on rapid collaboration and less on detailed documentation and formal approvals. Learn more about the project approach
63
Iteration 1
develop
Iteration 2
develop
Iteration 3
develop
Implementation design, implementation design, implementation design, definition
Definition
define consent
the plan
The implementer publishes the extension
Figure 4.4 Example of an agile method
A true Agile approach (for example, following best practices developed by members of the Agile Alliance) requires small teams, whose members sit together with little regard for defining formal roles between team members. This way of working enables a very high degree of collaboration and reduces the need for extensive documentation between the design, development and test phases. Team members can ask questions, collaborate with other team members in short whiteboard sessions, and implement solutions without delaying detailed documentation and approvals. When one of several iterations is released, the fully operational system is reviewed by stakeholders and the resulting input is considered when planning the next iteration. (An iteration is a draft version of a specific website or application.) When agile practices work as designed, that's great. However, teams in most organizations and most consultancies rarely take a purely agile approach. This is in part because organizations are increasingly using distributed teams and remote workers, making it difficult to maintain the high levels of collaboration needed to take full advantage of purely agile methods.
Approaches to Change Most projects attempt to adopt an approach that combines the best of both worlds: with enough structure and documentation to mitigate the risks of distributed teams and team member turnover, but also with enough collaboration and iteration to to manage change in a relatively agile way. answer. .For example, a project may follow the waterfall model, but the phases overlap, so there are important points of collaboration between teams. that makes it possible
64
Chapter 4: Project Goals and Approach
Underlying changes are more likely to surface at each stage. It can also be an early release with a shorter iteration cycle (e.g. a beta version for a specific user group). Feedback from this release can then be incorporated before the new site is fully deployed. to plan
Definition
development and design
Design
Definition
Development Deployment Beta
The implementer publishes the extension
Figure 4.5 Waterfall chart of changes vs. beta
Notice the minor iterations in the design phase in Figure 4-5. This is one of the greatest values you bring to the team as a UX designer. Tools like wireframes (Chapter 11) and prototypes (Chapter 12) allow you to gather feedback on quick iterations of ideas before investing a lot of development time. The modified waterfall approach shown in Figure 4-5 is one of the most commonly used and is therefore the framework for this book. Regardless of your approach, however, many of the topics discussed here apply to your project, as the underlying activities, such as definition and design, are still required.
Dive deep If your project uses agile methods, you have specific requirements during requirements gathering, such as: B. writing “user stories” to capture requirements. We recommend User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley Professional, 2004).
Learn more about the project approach
65
How does this approach affect me? Knowing your approach can help you better understand a few things: what questions to ask and when to ask them. For example if it is you
With a pure waterfall approach, you need to put in extra effort to ensure that the requirements set in the definition phase contain all the information needed during the design phase. (We discuss these requirements in the next chapter.) Expectations for how project team members will work together
The conclusion is a cooperation meeting. For example, agile methods require very close cooperation. The waterfall approach usually involves individual work with touchpoints one or more times a week. The level of detail required in the documentation and
Formalities. Documents submitted to the control point must be formal, almost like a legal contract. Often you need more formal documentation with a waterfall approach that requires approval before moving on to the next phase. However, if you use agile methods, you can also have formal release documentation that captures information at key decision points, such as preparing a particular iteration for full release and deployment. Key milestones that require stakeholder approval and
transferred to different groups. The approach defines what different audiences should deliver at different points in the project, including stakeholder approval at checkpoints and potential user feedback during beta launches. Now that you have identified the project goals and understood the project methodology, in the next chapter we start with the main work of the definition phase: the gathering of requirements.
66
Chapter 4: Project Goals and Approach
5
Business Needs Know the problem before you find a solution. When the project team came together, you probably heard or presented many ideas about what needs to be done. There may already be a list of features provided by some key members of the company (your business prospects) along with their views on which features are most important. These are the elements of the project's business requirements and are a good place to start. To ensure you have a complete solution at the end of the project, you need to generate and clarify requirements from multiple perspectives. In this chapter, we focus on capturing and detailing the requirements of the business prospects. Caroline Chandler
67
C
Chapter 4 looks at ambiguous goals and discusses some ways you can help yourself and your project team figure them out. In the early stages of the project, you may also have some vague requirements. These can be ideas from stakeholders, user complaints, or user requests. To enable these actionable and traceable components of a project, you need to incorporate these ideas into requirements. Requirements are directives that define what a site or application must do. Ideally, it is a business requirement. Provides insight into the overall requirements that must be met. Represents and integrates the needs of different stakeholders. Provides direction for the design without being overly specific
Prioritized and tracked as a single unit of work
Below are sample ecommerce website feature ideas. Early in the definition phase, you might get the same idea from many different business stakeholders: "Customers can track their orders online." That's a good basis for a requirement, but it's vague. Start by asking questions related to the specifics of the requirement, such as why it is important to the business that customers have their customers
Order online? For example, is it about reducing the number of calls to customer support? Does the company currently have the ability to track packages online?
If this is not the case, new requirements for the tracking functions must be determined or the company may have to work with a third party. How accurate should the tracking be? what kind of information
Should it be included in the tracking data? For example, should the website provide updated delivery time estimates? Asking these types of questions can help you turn vague ideas into concrete requirements. It also becomes clear that the same statement can have different meanings for different people.
68
Part 5: Business Requirements
For example, a stakeholder might think that tracking a package means receiving an email confirmation from the stakeholder idea with a tracking number that can be entered on UPS.com or another website so the customer's stakeholder can see when the package last arrived. Idea Another stakeholder might think that companies should push the boundaries of package tracking and invest in developing the ability for customers to track packages via GPS, where they can see their exact location in real time using an online map. As you can imagine, there is a significant difference in user experience and scope here! It is important to explain these differences at the beginning of the project. Otherwise, you end up developing a solution that deviates from the intent of the business stakeholders and possibly from the project goals. This leads to dissatisfied stakeholders and wastes time and money when the function needs to be redesigned. Therefore, clear and detailed requirements are an important part of the overall project. To arrive at a comprehensive list of project requirements, the following steps should be followed: 1. Know the current status of the site or its competitors. 2. Gather needs and ideas from business prospects and current and potential users. (See Chapter 6 for more information on working with users.) 3. Incorporate ideas into requirements. 4. Prioritize requirements based on project goals. (See Chapter 9 for recommendations on prioritization.)
Business and User Project Requirements. business strategy
Figure 5.1 brings together business prospect ideas about business needs and user research ideas about user needs. Then use the project goals to prioritize and create a comprehensive list of project requirements.
business needs
69
First, let's talk about understanding the current state of your website so that you can understand the context of the ideas that emerged during the requirements gathering process.
Understanding the Current State When delving into the details of the website or app you are designing, it's important to lay the groundwork by understanding the current state of the site (if you're redesigning an existing site) or one provide a better overview understanding of the most important competitors. Base. (if you are designing a new website or application). You can learn a lot about the current situation through stakeholder interviews (more on this in a few pages). You can also unearth many insights of your own that can serve as a solid foundation for stakeholder interviews and user research. A good way to get context and generate ideas that could become requirements is to perform heuristic analysis.
Another name... the word heuristic means rule of thumb or best practice. Heuristic analysis today means evaluating a product against a set of rules (heuristics) for available designs, usually performed by UX designers. A user-friendly website follows most or all of the heuristics you use in your analysis. You may also hear this technique referred to as heuristic scoring, expert judgment, or a combination of these terms.
Heuristic Analysis Heuristic analysis is a technique used to evaluate the usability of an existing theme against user experience best practices. You can perform this type of analysis at the beginning of a redesign project on your current website, or you can analyze competing websites to see if they are able to offer a better user experience than other companies. The result is a document that describes the strengths and weaknesses of the site and includes suggestions for improvement. When you're done, you'll have a deeper insight
70
Part 5: Business Requirements
Get a detailed look at the website being analyzed and a list of ideas to help meet new website needs. For example, a common heuristic from Jakob Nielsen's list of ten usability heuristics (see Jakob Nielsen's website for the full list at www.useit.com/papers/heuristic/heuristic_list.html):
System status visibility. The system should always keep the user informed of what is happening by providing appropriate feedback within a reasonable time.
There are many situations on the website where this heuristic cannot be followed. Let's say the user clicks the download button but doesn't get a notification that their file is being downloaded. The user is not informed that the file is being downloaded even though the download has already started. So the user could click the button again, thinking they missed it the first time... and then click it again... which could result in multiple downloads, which could potentially cause performance issues on the site, since a user who is now unknowingly performed multiple downloads made clicking the button again. With heuristic analysis, you can identify this as a problem area, describe it, and assess the impact. You can also share an idea that can solve a problem and add it to the needs list. Why Heuristic Analysis? Performing this analysis is a relatively quick and inexpensive way to get design feedback. Heuristic analysis can provide a general understanding of design quality and help identify potential design problems. Note that this activity is not directly related to end users and does not replace real user research. For example, only 50% of heuristic results can actually be validated through follow-up research. However, the analysis gave the team good insight into points that may need attention. If you're redesigning an existing product or website, it's also helpful to identify obvious quick fixes that can enable immediate improvements while the redesign work continues behind the scenes.
Find out about the current status
71
what should I do? The specific heuristics you use may vary from project to project, but the process for performing the analysis generally remains the same: 1. Gather product and project background knowledge. Make sure you understand the goals of your site, a list of the key user groups to support, information about the types of environments your users can work in, and a basic understanding of what expertise your users might have. (For example, your analysis will be different for a general consumer site than for a pharmacist site.) If you need help with the latter, you can visit some of the competing sites or apps for the most common terms and subject areas. 2. Choose the heuristic to use. Many heuristics are available. In addition to Jakob Nielsen's list, many UX designers refer to Bruce Tognazzini's list of design principles: www.asktog.com/basics/firstPrinciples.html. Once you are familiar with your site's themes, you may want to add some of your own, especially if you are analyzing multiple sites. Be sure to keep your list organized (e.g. 8 to 12); too many heuristics can make the technique difficult to use for you and your readers. 3. Go through the priority areas of the website and identify areas that follow or miss the heuristic. Each observation you make should include the following information: General observations. A brief statement summarizing the findings. Ideally, number these for quick reference as you guide people through the report. A short description. A paragraph or two that describes the context of the observation, such as the point in a particular process where you noticed the problem. affect the ranking. This rating can be high, medium, or low for problematic observations, or it can be a comment on a positive finding when sharing something that the site does well. Usually, it is a serious problem that you believe will cause many users to drop out or not be able to perform a specific task
72
Part 5: Business Requirements
Permanent loss of information (for example, an issue that causes a user to lose changes to a document they were working on). Medium-impact problems are problems that cause frustration and errors, but are not irreversible problems. Low-impact issues are small issues that can cause confusion, but usually don't result in wasted time or frustration. excitation. These are the next steps or ideas you share as a solution to your problems. Figure 5.2 shows an example of these elements together as they might appear in your heuristic analysis. Observation #4: The search function doesn't seem to return all possible results.
Take good care
A sample test of the search function yielded mixed results. Named searches in a relatively recent post that cover only a few topics and occasionally return no results. The main search also only seems to return links to new stories and not videos. Recommendation 1: Make sure that newly added content is indexed and searchable before or shortly after it becomes publicly available. 2. Consider displaying related content such as stories from similar categories or similar tags when displaying search results to help explorers focus on more topics. 3. Consider a generic search that displays results by category. 4. Use the search term log to learn more about common items. This can also provide insight into items that are difficult for users to find.
Figure 5.2 Sample observations in a heuristic analysis report
4. Present your findings to the project team and key stakeholders. Guide them with your observations and suggestions. Discuss the reasons for your rating. (This is also a good time to suggest ways to validate your results using one of the techniques discussed in Chapter 6.) How does heuristic analysis help capture requirements? Once you've completed your heuristic analysis, you'll have a better understanding of the current state of your site (or its competitors) and a list of ideas to help you capture requirements. You also have some ideas on how to organize the topics to be covered during the requirements gathering meeting, which leads us to the next step in the process.
Find out about the current status
73
Collect ideas from stakeholders. As we saw in the example at the beginning of this chapter, if you don't understand the context of an idea, such as "Customers can track their orders online," you run the risk of ignoring stakeholder expectations of the difference. ". Our friend wants to track the package via GPS. One of the most common mistakes in projects is to grab a feature and call it a requirement without first understanding the problem and the expectations of the solution. Why is the requirement capture process often Gathering ideas - and merging them into requirements - can take quite a while. It's easy to underestimate the number of questions you need to ask to outline requirements and prioritize them. When processes are poorly structured or If onboarding is incomplete, there can be significant churn throughout the project (churn is wasted time in extra meetings and work iterations due to a lack of communication and commitment. This is different from more productive work iterations, which are part of designing and testing effective solutions to get the job done to find the best solution.) So how? you do it? Do you encourage a balanced requirements process that focuses on business needs but avoids wasting time? Here are some steps for an efficient process: 1. Outline roles and responsibilities. Ensure that project team members understand their role in gathering requirements. 2. Put the right stakeholders in the right groups to ensure the best use of time is at the right interview or meeting. 3. Create a meeting plan, including the topics that will be discussed and the questions that will be asked during the meeting. 4. Conduct meetings efficiently to capture ideas and create clarity. Research ideas to find out the need behind each idea. As your meeting draws to a close, don't forget to thank the stakeholders involved and update them on the progress once you've reached the consolidated priority list. Let's take a closer look at each of these steps.
74
Part 5: Business Requirements
Describe the responsibilities. When gathering business requirements, project team members typically interview key business stakeholders to gather ideas. Business stakeholders are those within the organization who have a business interest in the project's success, or have expertise to contribute, or both. These people are not full-time involved with the project, but need to be involved at key points in the process, including gathering requirements. Keep in mind that they also have day jobs (sort of) so their time is precious and often hard to find unless you plan ahead. A project sponsor (or sponsor) is a business stakeholder who is also directly responsible for the success of the project, usually at a relatively high level in the organization, such as a director. He or she will not be present on a daily basis throughout the project lifecycle but may be actively involved in gathering requirements and ensuring a high level of engagement from business stakeholders. The sponsor may also attend some or all of the meetings. The project team consists of people officially assigned to the project as ongoing resources. They can be involved as project managers, UX designers, business analysts, technical leads, visual designers, quality assurance leads, etc. Depending on the size of the project, this could be their main task. Within the project team, the responsibilities for the requirements gathering process are often unclear. If you take the time to define responsibilities early on, you can ensure an efficient debt collection process. Here are some questions to ask as you determine each team member's specific responsibilities during the requirements gathering process: Who is primarily responsible for gathering and planning the right things?
Stakeholders are among the most productive groups? These can be internal and external stakeholders (e.g. partners, suppliers, etc.). Who creates the topic and problem structure for business actors?
owners meeting? If time permits, this is a great collaborative exercise for the team. The main moderator can then organize them into a structure that allows the meeting to flow smoothly. Who chairs the session? Who takes notes and how are they shared?
Collect ideas from stakeholders
75
Who follows who afterwards? Is someone from the technical team present at all meetings?
If so, how was this person involved (listening, offering input, or something else)? Whether or not you, as a UX designer, are primarily responsible for one or more of these areas, you have important skills to bring to the process. Creating a structure for topics and questions requires a sense of clear categorization (which sounds like a good interface with information architecture), and of course facilitation skills are important to keep a meeting informed for all participants.
Gather the right stakeholders. The main purpose of stakeholder interviews is to gain insights into project-related ideas, needs, knowledge and frustrations from different perspectives and then feed these into the project requirements. There is also sometimes an unspoken benefit of involving many different groups so that everyone feels they have a say in the project - and therefore accept the final solution. While it may seem more political than practical to get people on board to gain their support, connecting you to a network that will support you throughout your project is often an important step. It also helps you avoid 11-hour edits, which can happen if someone you haven't spoken to asks a question late in the process. So it's usually a good idea to involve different people. On the other hand, schedules and budgets must be taken into account. From her point of view and yours, bringing a lot of people in just for a meeting takes time—not to mention the time it takes to take notes, identify trends, and integrate layoffs. For the sake of efficiency and your own health, it makes sense to prioritize the groups you want to speak to and select key people from those groups to act as thought leaders for their teams. Which potential stakeholders can you involve? These groups are often great sources of ideas:
Marketing campaigns that require information to be displayed on the website)
76
Part 5: Business Requirements
Groups that need to directly support the processes behind the website or
Applications such as content delivery, data entry and management, and immediate response to collected information. First-line customer service, such as telephone or online support or
Any sales, product management, or consulting service that interacts with customers in person (e.g., in a retail store or via delivery).
Products and Services Offered. Human resources to achieve recruitment goals. Public relations work to inform investors and the media. All teams are responsible for building other relationships
This will have an impact on the design of the project, for example in relation to partners or suppliers. When choosing who to get involved, consult with your project sponsor and any project team members who are familiar with the groups that will involve the right people. Create groups where good discussions can begin. There is no one right way to do this, but a common way is to group stakeholders by department as follows: Marketing (five people), Product Management (four people), Customer Support (two people), Sales (four people ).
On a smaller project, one person from each group could take part in a series of two or more collaborative work sessions, bringing everyone together. Once you have considered your stakeholders and the general structure of the meeting (discussed in the next section), you can start planning the meeting. Try to start planning at least a few weeks in advance; it can be difficult to get everyone around the table.
Collect ideas from stakeholders
77
Create a meeting plan. When choosing the right stakeholders, make a list of topics to cover and questions to ask (this will also help you round out your stakeholder list). You should have a different plan for each group you meet, although some of your questions may be the same across groups. You also need to decide how detailed you want the meeting to be. If you're just meeting up with a lot of people once (e.g., members of different departments, like above), you'll be hungry for ideas, but you probably don't want to spend too much time delving into the spooky details at that meeting . In this case, when one of your stakeholders comes to you with the idea that "customers can track their orders online," you might want to ask why this feature is important and if the stakeholder can think of a well-functioning website that does just that. These questions should help highlight key differences between stakeholder expectations of positions without spending the entire meeting on a single statement. You can then work with the project team to work out the details of the idea and contact the stakeholder to ensure the requirements you generate still reflect their original ideas. Let's say you're redesigning an e-commerce website and meeting with different interest groups, with each group holding a meeting. Below is an example of a group meeting schedule for the sales department.
Sales: Requirements Gathering Session Participants Inside Sales: Jenny Bee, Tracy Kim, Joseph Arnold Key Executives: Kevin Abernathy, Cat Parnell Time Frame: 2 hours Goal: Understand the current sales process and determine how the Web can better support that process. problem and opportunity procedure. Background: We watched a PowerPoint presentation on the buying process, which provided a good background on how buying decisions are made. We also plan to speak to the customer service team.
78
Part 5: Business Requirements
Sales: Requirements Gathering Meeting (continued) Questions Sales Process: How does the sales process differ for different product lines? Are there regional differences? Are some of the differences based on customer size (e.g. small business vs. large enterprise)? How has this process evolved over the past two years and is it likely to evolve over the next three to five years? How does a potential customer understand all the things that need to be bought and how they all work together?
Overall Impression: Who do you think are the most important visitors to your current website? Why? Who are you? What do you want to achieve with the website? How is the Internet contributing to the sales process and/or sales conversion rate today? What information do customers need to make a purchasing decision? Is this information available on the website today? Is it easy to find? Is it correct? How difficult is it to maintain website content? What statistics do you get from the website? What other metrics would you find valuable? Why?
Future Vision: If you are thinking about a future website, what can we do to better support the sales process? Which current functions and features on the website are sales-critical? What is unnecessary? What is missing?
Summary: Are there any other thoughts, suggestions, or concerns that we haven't addressed? What websites do you think are great for sales support? What is the most important thing a company can do to improve customer satisfaction?
Collect ideas from stakeholders
79
Conduct Meetings Effectively Here are some practices that can help you gather requirements. Make sure you use a common vocabulary. Much confusion can be avoided if the requirements engineering team agrees on a common list of terms and definitions. Are people using the system named, for example, users, customers, or clients? Are the terms interaction designer or information architect better known? To avoid confusion, at the beginning of each meeting, take a moment to identify the terms used and their meaning. You may also benefit from creating some visuals to help explain the relationship between different terms or roles (see Figure 5-3). category
Category
Category
subcategory
subcategory
subcategory
Theme
Theme
Theme
Article
Article
Article
Figure 5.3 Item conditions and relationships scenario
A common vocabulary of deliverables used in the project also helps stakeholders understand the process and the types of deliverables they can expect. This can inspire confidence that their time and energy isn't wasting a black hole of ideas. In general, if you find yourself using the same words more than once or twice (especially if you notice slight changes in the definition each time) you should consider adding them to the project glossary and sharing them with the project team. Other examples of terminology that can help clarify at the beginning of a project include:
80
Part 5: Business Requirements
Interacting roles (e.g. applicant and customer or interlocutor)
Tent producer and publisher) is widely referred to as the main result (functional specification).
structure, wireframe, sitemap) and briefly explain how they differ. distinguish between different levels of information (e.g. our category).
Information in Figure 5.3) the difference between needs and ideas
Listen for ideas and research needs. Stakeholders can make statements that appear necessary. Consider an example. company representative
"We need a blog on the site."
Second
It's really an idea, not a necessity. Then, when the blogging functionality is fully designed and implemented, it becomes a solution, but it may not best meet the stakeholder's core needs. If you ask why blogging is important, you can get all sorts of demand statements, like, "We need to look relevant and connected." Everyone's talking about blogging, and I feel like we're falling behind them when we're not engage "We needed a way to give people the ability to bounce back and forth on the site to generate more ad revenue, and blogging meant having freshly posted content with a following." "We needed to position ourselves as thought leaders, and blogging was a way to get more personal.' A way to showcase our expertise.' 'We need better ways to communicate and innovate with our customers, and blogs provide commentary so we can hear from them.' Any of these statements describes the actual demand. By having them there, you'll learn more about the drivers of feature requests, which will help you achieve consensus on integrating and prioritizing requests.
Collect ideas from stakeholders
81
Consolidate requirements: After the meeting, organize the collected ideas into common functional areas. You will find that there is a lot of overlap. This is a good sign that a particular idea is gaining strong support from stakeholders. Remove redundancies and try to incorporate lists of ideas that effectively reflect stakeholder intent. In order to turn the ideas you collect into actionable and trackable components of your project, you need to consolidate those ideas into requirements. Imagine raindrops emerging from a cloud: you change from a large, undefined cloud to a mass of well-defined raindrops. So if you have a bunch of ideas, like "Customers can track their orders online," you need to translate them into clear statements about what you want the system to do. The resulting requirements should provide an indication of the overall needs that need to be met. Review and integrate the needs of different stakeholders. Give direction to the design without being too specific about how it will look.
Prioritized and tracked as a single unit of work
As you move from ideas to requirements, make sure your technical lead (or someone else who can represent your project's development team) participates in asking questions that will help you estimate the effort required if you prioritize later. If you have a dedicated QA team member, that person can also ask some very detailed questions to summarize the requirements. To turn tracking ideas into requirements, ask the following questions: How accurate should the tracking be? What information should be included in the tracking data; e.g
For example, should we provide updated delivery time estimates? If you spend a lot of time on the project, you can discuss these issues with the stakeholders who gave you the original idea. If you don't have much access to these stakeholders, you can work out the details yourself by talking to the project team
82
Part 5: Business Requirements
Then discuss these requirements with your project sponsor to ensure your options make sense for the business. Table 5.1 lists the types of requirements that can arise from idea tracking and how these are captured. Table 5.1
Examples of business needs
ID
Area
1
track order
2
3
track order
track order
Require
business needs
Orders can be placed via
Encourage self-service
Enter the tracking code
During labor (support
online
To use)
Users can track their packages
Demonstrate innovation in terms of efficiency
GPS age, track truck
Delivery (competitive
or plane
To use)
Users can view all previous orders. Encourage backorders and orders from the last 365 days
Self-service (sales, support services)
Note that in some cases requirements overlap, e.g. B. For the first two requirements in the table - both are followed methods. They can coexist on the same system as you can enter a code to find your package via GPS view. However, they are separate because GPS-related requirements may require more effort and should be prioritized independently of other functions. When merging reports, consider business needs that you think may conflict with user needs. For example, a business need might be to collect personally identifiable information from potential customers, such as their email addresses. However, customers may have reservations about the provision of information. After all, form filling takes time, security and privacy are an issue, and this step could interrupt the larger task they are trying to do. Recognizing these types of conflicts gives you ideas that can help you meet business and user needs. As a tracking example, you could suggest the Send to a Friend feature to collect email addresses and make things easier for users. That means sending to a friend can be a requirement for you to be included in your priority mix. these thoughts
Collect ideas from stakeholders
83
They can help with business and user needs, so they're great for capture. They also exist at the intersection between the definition and design phases when you start designing solutions to business problems (see Chapter 4).
Defining potential conflicts between design development business and user requirements is an excellent subject to explore as part of the user research that we will discuss in the next chapter. With user research, you can also expand Table 5.1 to a full set of potential requirements that are prioritized in the project requirements list (shown in Figure 5.1 and discussed further in Chapter 9). Keep in mind that gathering business needs often occurs in parallel with exploring technical possibilities and gathering user needs. Next post: Time to talk about users!
84
Part 5: Business Requirements
6
User Research Meeting Guests You Invite to the Party There are many user research techniques that can be used throughout the project lifecycle to better understand your users or to test their behavior on versions of your site. This chapter focuses on some of the most commonly used methods in the early stages of a project. These techniques will help you define the user groups that should be given the highest priority during a project, contextualize their needs and frustrations, and leverage site administration best practices to evaluate the performance of your current site (if any). and shape the user experience. .Carolyn Chandler
Basic User Research Steps 1. Define your core user groups. This includes creating a framework to describe the key user types you are designing for so you can focus your efforts on recruiting users for research. 2. User Involvement Program. This includes selecting one or more technologies to engage user groups in research based on project needs. 3. Conduct an investigation. Here we cover basic techniques like interviews and surveys and provide tips on how to approach them. 4. Check your user group definitions. By using the insights from your research, you can strengthen your user group model. This model is then used as a platform for developing more detailed tools such as roles (see Chapter 7). 5. Generate user requirements. These are explanations of the features and functions that the website may contain. You add these statements to your business needs (see Chapter 5) and prioritize them to make them project requirements (see Chapter 9). This chapter covers the first three steps, starting with step one: defining your user groups.
Define your user group. Planning user research at the beginning of a project can feel like a chicken and egg dilemma (chicken or egg?). How do you make sure you're talking to the right people if you don't already know who those people are supposed to be? One way to get started is to create an initial or preliminary definition of the users you are designing for. The main user groups of your website are described here. This can help you focus your research efforts on the right personas, demographics, or other variables that may impact the way users experience your site. User group definitions can be high-level (defining a list of each target user group) or detailed and visual (diagrams showing multiple user types and how they interact with each other).
86
Chapter 6: User Research
A general definition of a company's primary .com website might include the following user groups: prospective buyers, current buyers, partners, and job seekers. As you begin defining groups for user research, you will prioritize user groups in more detail. Your initial definition is based on the collective knowledge of business stakeholders and project team members about the types of users likely to interact with the site. These definitions can be created by capturing some of the goals and characteristics of different user groups. Here are the basic steps for defining user groups: 1. List the attributes that help define the different users of your site (the following sections describe some of the most common). 2. Discuss attributes with those in your organization who interact with the relevant user type (e.g. customer). 3. Prioritize the features that seem to have the biggest impact on why and how potential users use your website or app. 4. Define the user groups you will focus your research and design on. The following sections describe some brainstorming techniques to help you capture these attributes and prioritize and model them (representing different user types to better target your research efforts).
Make a real estate listing. A good starting point for creating a real estate listing is to gather and integrate research or other documents your organization has that users can use as a guide. Here are some possible resources:
Petition information, marketing strategies and business plans. Market segmentation of existing customers and other demographics
Collected from previous user research by marketing department (see Table 6.1 for some examples)
Define your user group
87
Surveys, such as user satisfaction surveys and feedback forms. Customer Service Report on Frequently Asked Questions
Next, identify people in your organization who have visibility into current or prospective users. The number and type of people to be involved depends on the nature of the project, as well as its scope and schedule. If you know that the initial definition of your user group may have a short lifespan (for example, it will only be used for a month or two when planning user research), you can only include two or three participants. If you feel that the initial definition should guide you through most of the design process (for example, you can only use that definition until you do usability testing after part of the design is complete), involve more participants and make sure you have a cross-sectional view. Potential participants include marketers responsible for branding, segments and campaigns, sales reps, product managers, customer service or support reps, and trainers. It is also useful to involve project team leaders and other business stakeholders in this exercise. Have the group think about the different types of potential users they interact with on a regular basis. Then have them list some common traits they come across. Here are some examples, which may vary: Primary goals related to your site's theme. Why
What do users want to achieve when they come? For example, common goals include buying an item, trading a stock, or answering a specific question. roll. This can be defined in a number of ways, but one way is to combine roles with
The user's main purpose: job seeker, support seeker, potential client, etc. Once you have more information about your users, you can subdivide personas according to different needs or styles; for example, on an e-commerce site, customers may be bargain hunters and connoisseurs. Demographic information, including age, gender, family (single, married, children),
income level and region. Experience, including education, familiarity with relevant fields
Technology (often referred to as technical competency), expertise and frequency of use (once, occasional, frequent). 88
Chapter 6: User Research
Organizational characteristics, including the size of the company where the user works
Your department, job type (entry-level, freelance, middle management, executive), tenure (long-term or high-turnover?), and work patterns (remote work, number of business trips). Once you have a list of some characteristics that stakeholders most often refer to as potential users, you can prioritize them according to their importance and then use this hierarchy to start defining and modeling user groups.
Prioritize and define which of the above characteristics you think have the greatest impact on how and why different user groups use the website? Focus on those that you feel will have the greatest impact on the user's goals or behavior. Prioritize these traits and remember the goals you set in Chapter 4—they will also guide you in your choices. An example best illustrates how attributes are prioritized. Let's say you work with a company that offers online tools for trading stocks, options, and futures. This particular company has decided that part of its strategy will be to hire non-professionals to trade stocks online and encourage them to trade new types of products such as options and futures. The company intends to achieve this by offering user-friendly trading tools and targeting those looking for hands-on learning in a safe and secure environment. When you discuss traits with prospects, you'll find that the following traits seem to have the greatest impact on how individuals use these tools: Recent transaction frequency, particularly direct online.
(e.g. quarterly, daily, several times a day). Those who only trade a few times (e.g. once a month) may not be serious about trying new things, and those who are already trading full-time may not find much value in tools aimed at new traders. But these active part-time traders might have a keen interest in the company's tools. Number of product types traded: stocks only or stocks, options, etc
futures Those who already trade all types of products may already prefer their instruments, but those who only trade one type may be ready to expand to others. Define your user group
89
Extensive specialist knowledge (e.g. familiarity with the trade).
Situation). This helps identify how much help they need with the process, including tutorials and glossaries. Technical knowledge level (e.g. procurement familiarity).
online banking and online transactions). This affects the extent to which they need data protection guarantees and how complex or simple the online interface needs to be. You can prioritize these attributes as they impact the types of users you are targeting for your research. If traders' location doesn't seem to have any real impact on how or why they trade, the regional attribute could be dropped from the list as a consideration for study participants. On the other hand, if the importance of a particular attribute generates a lot of discussion, it might be a good topic for a poll or interview question (we'll talk about polls later in this chapter).
Hoch
Comparing two or more attributes will also help you prioritize. For example, if you create a chart for online retailers with two attributes, you can see how groups fall within certain ranges. Figure 6.1 is an example of a global user model that you could create using two attributes, frequency of direct transactions and number of product types traded. It also shows the end-user groups that could result from discussions.
Full-time Product Specialist
Full-time smart generalist
Direct Transaction Frequency
Second Career Vendor
Extra Income Trader
active explorer
long-term investor
low
Lover
low
Hoch
Number of traded product types (stocks, options, futures)
Post 90's
Chapter 6: User Research
Figure 6.1 shows a diagram of two properties of the global user model. Building this model together can facilitate discussion of possible differences in user motivation and experience.
This user model provides a way to discuss different types of users at a high level. It is not intended to be a definitive model, nor does it specifically identify user groups (who may be long-term investors in stocks or who are actively exploring other opportunities in options or futures). But it expresses how you understand the different user groups and how they might be motivated to use your website. This discussion of key attributes will also help you figure out which attributes to focus on when recruiting users for research. If you determine that trading frequency is important and prioritize those who are currently trading at a moderate level, you need to define what moderate frequency means (e.g., one to three times a week) and recruit your study participants accordingly. Speaking of research, let's talk about techniques you can use to engage users in your projects.
Can you design based only on user models? In the UX space, there is a debate about creating user mockups before research because it can sway your thinking before you have real user data and because your project team or project sponsor may see mockups as a substitute for user research. Using an unvalidated model carries a higher risk that your assumptions are wrong. However, for projects where you don't interact with users at all, a well-designed model (validated by a source outside the project team, such as a customer service group or a training group) is better than not using a model during design.
Choosing Research Techniques Now that you have a general idea of which user groups to include, it's time to plan the next step: your recommendations for the amount and type of user research to be conducted during the project. Table 6.1 provides some information about the most commonly used research techniques and when they are typically most useful. Use this table as a reference to choose the best solution for your project. Each technique is described in more detail in the following sections.
Choose a research technique
91
Table 6.1
Common user research techniques
activity
What is that
when does it make sense
Challenge
Typical schedule *
user interview
One-on-one conversations with participants belonging to one of the main user groups of the site.
There is user access, but the type of access (in person, by phone, etc.) varies.
Get clear opinions. Gathering information about attitudes and context can be difficult, especially when interviewing remotely.
2-4 weeks for 12 interviews: maximum 1 week planning, 1-2 weeks interviewing, maximum 1 week collecting the results.
context study
Go on field trips with the participants to observe and understand how they function in normal everyday life.
The Get Access to project team has very few information participants. target user. The impact on the user's environment may raise concerns about the safety and intelligence of users working in certain environments (e.g. hospitals). property, and intruUsers is working hard. For companies with relatively complex applications, these are tasks or workflows. Easier to access on weekdays.
12 studies required 3-4 weeks: 1 week for planning, 1-2 weeks for observation, 1 week for analysis and reporting of results.
Investigation
A series of questions, mostly closed-ended (multiple choice), designed to identify patterns among a large number of people.
You want to express the results more quantitatively (e.g. "80% of the target group said they never buy a car online").
3-4 week short survey: 1 week to plan and write the survey, 1-2 weeks to conduct the survey, 1 week to analyze and report the results.
You want to get the context but can't get the user.
They're more interested in gathering information about preferences than actual performance.
92
Chapter 6: User Research
Obtain a suitable sample. Make sure the questions are well worded so that you get concise answers without leading the interviewee into a specific answer.
Table 6.1
General User Research Techniques (continued)
activity
What is that
when does it make sense
Challenge
Typical schedule *
special group
A group discussion in which the moderator guides the participants in solving questions on a specific topic. The focus is on revealing participants' feelings, attitudes and thoughts on the topic.
The team anticipates that user attitudes will have a major impact on how the solution is used (e.g. whether there have been any problems in the past).
Learn how to get the right information for your question.
3-4 weeks: 1 week planning and writing questions, 1-2 weeks leading focus groups, 1-2 weeks analyzing and reporting results.
sorting card
Participants are presented with items (e.g., themes) on cards and are asked to place them into groups that are meaningful to them.
You are working on a content source site with many projects and want to provide an efficient structure for your audience.
Determine the best subject to photograph.
3-4 weeks: 1 week for planning and preparation, 1 week for research, and 1-2 weeks for analysis and reporting of results.
Usability-Tests
Users try to perform typical tasks on a website or application, while a coordinator observes user behavior and, in some cases, asks questions to understand it.
Existing solutions are improved.
Choose the right task to focus on.
3-4 weeks for 10 users and medium form: 1 week to plan and write assignments, 1 week to conduct tests, 1-2 weeks to analyze and report the results.
Competitive solutions are available for testing. You have a prototype that allows users to perform (or simulate) tasks.
Moderate groups effectively.
Determine the level of formality of the test.
*Typical time frames represent times that typically start at the user scheduled time. Assume there are two groups of 6 to 8 users (except for surveys where the number of users should be larger). This does not include the recruitment time, which may take one to two weeks after completing the screening questionnaire.
How much research activity can I include? Before choosing an activity, ask yourself how much money and time your team can devote to user research. Consider the following scenarios to understand how hungry your client company is for user research. If project managers and project sponsors are familiar with user research and are interested in using it for a known purpose, such as ensuring that the site meets specific project goals, you may have more leeway.
93
When you plan two or more activities, or for one activity that you do multiple times (e.g. test a design, change the design based on the results, and then test the new design again). If no one in the organization is familiar with user research and there is resistance, it is wise to conduct a round of research and select the techniques that you believe will bring the greatest benefit to you, the project team, and the business stakeholders. Once the results are in, the project team will have a better understanding of what the project was about and what benefits the project would bring. Then you'll have a good reason to do more research later if needed. If you have room for at least two rounds of research, it's best to include one round early in the definition or design phase to get a better understanding of your users. Then add another round before development starts validating the design. For example, for a task-based application, you can conduct user interviews before design and test the prototype for usability later in the process. Or you can start with contextual research on content sources and then add card sorting exercises.
Considerations when planning your research When planning your research technique, consider the following: Why you are doing the research: What you want to learn from it Who you will involve: The key user groups described above How to attract participants: Recruit and screen people for participation ( i.e. ask questions to ensure they belong to your target user base). How do you reward participants? What space and equipment do you need? What do you cover: The most important topics. How is information collected: How many people participated and the tools they used Chapter 13 It describes one of the techniques most used by UX designers: usability testing and all the considerations that go into it.
94
Chapter 6: User Research
Note For more information about task-based applications and content sources, see Chapter 2.
Surfing Steve Baty has written an article detailing the different approaches and how you can choose from them depending on your level of development, your information needs, and the flexibility to incorporate user research. The title is "Bite-Sized UX Research" by Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.
Let's take a closer look at each of these techniques and how they're commonly used.
User Interviews User interviews are structured conversations with current or potential users of your website. These can be conducted over the phone, in person in a neutral location such as a conference room, or preferably in an environment where users are most likely to use the site. (The latter case also lends itself well to the background research described below.) Interviews can help you understand participants' preferences and attitudes, but they should not be used to make formal statements about actual performance. If you are looking for specific information about how people interact with a website, the best way to do this is to observe how they use the website (e.g. in contextual research) or ask them to perform tasks on the website (in usability testing) . Site analytics can also give you insight into specific performance information, which is especially useful when combined with interviews or questions that provide context for the data. Basic Process For user interviews, a UX designer creates a list of questions designed to capture: Experiences related to the site or topic
Choose a research technique
95
Corporate brand perceived by the participants. settings, e.g. B. on the topic categories covered (for follow-up).
tent resource), the process to be designed (for mission-based applications), or the marketing approach (for marketing campaigns) A common goal or need that drives users to your or other websites
Competitors Common next steps users take after visiting a company website. Others participating in the experience. For example, make one
Users tend to collaborate with other people to achieve a greater goal? Are they likely to pass on information or seek inspiration from others along the way? Any additional information to help you verify your hypothesis
The work done so far on user groups, e.g. B. whether the variables you discussed when creating your first user model actually affect the way users experience your website. If more than one person is conducting the interview, it's a good idea to have a series of question lists and written introductions to ensure consistency between interviews. Decide in advance how your interview should be structured. If you want a formal report, you probably want a high level of structure, where the order of the questions doesn't change significantly, each question is asked, and little is added. If richness of data is more important than consistency, you can opt for a semi-structured interview, where you start with a series of questions, but allow the conversation to follow a natural flow and the interviewer continues to explore points of interest by asking questions (searching naming). ). The length of your interview may vary; 45 to 60 minutes is usually the best time for a photo shoot. You'll have ample time to build relationships and answer a variety of questions without overwhelming your attendees. User interviews provide a rich dataset that you can use to write personas, as discussed in Chapter 7.
96
Chapter 6: User Research
Interview Tips The quality of the information you receive at the interview depends heavily on the quality of the questions you ask. Focus on the personal experiences of the participants. Don't make them guess what they might do in the future or what other people might do. This type of information rarely predicts what they will actually do. Don't ask questions that imply a specific answer, and don't steer participants in a positive or negative direction. Ideally, the questions are simple, neutral, and open-ended. Some examples of guiding questions are: What do you like about PseudoCorporation.com?
This assumes that users enjoy using the site. Only use this question if you are also asking what you don't like. Did PseudoCorporation.com live up to your expectations?
This can be answered with a simple yes or no, which doesn't give you many details to help you with your design work. Would you rather use PseudoCorporation.com or CompetitorVille.com?
If the latter, why do you think they are better than pseudo? This poses many problems: it asks two questions in one statement and forces an implicit opinion on the participants. A better question: tell me when was the last time you visited PseudoCorporation.com. why did you go there Do you remember your visit?
If you are conducting a larger, more formal interview series, you may want to include some multiple choice questions. However, in most cases these are not very meaningful. When participants ask verbally, they can be difficult to understand and don't allow users to elaborate. In general, leave these types of questions to a screener or poll. Conduct the test run with someone, possibly someone in the organization who is not part of the core team. This allows you to spot problems that may not be obvious and optimize your timing and process. If possible and if the participants agree, record the interview so that others can benefit from hearing the answers directly from the participants.
Choose a research technique
97
Contextual research Contextual research combines user observation and interview techniques. A UX designer engages with the participants, ideally with the context in which they could use the website. For example, in an office application, the contextual study would require sitting at the participant's desk. This will give you comprehensive information about the working environment of the participants, including the practical problems that the users face, the type of equipment they work in, the rooms they work in and especially the size of theirs used space.
How much (or little) privacy there is, how often they are disturbed, and how they use phones and paper (pay particular attention to hard copies they post or notes they have handy). They prefer using a mouse to a keyboard. This could have a significant impact
Your design decisions, especially when designing a tool that requires a lot of data entry. How they work with others in terms of collaboration and sharing
The resource to use. For example, having more than one person using the same computer affects how you design sign-in and security features. They use other tools both online and offline. how people use paper
Particularly interesting: For some tasks it can be difficult to find an online solution that is comparable to paper documents! The study combined observation time and interview time. They can last hours to days. If the participant cannot commit to at least 2 hours, you can consider simply conducting the interview. During the observation, the participant needs some time to get used to your presence and to move naturally, which is no longer the case after 15 minutes. Basic Process Prepare a 10-15 minute presentation for each participant. It should include the purpose of the research and a general description of what you will do together (observations and interviews) and how
Chapter 6: User Research
information is used. This is also a good time to sign a consent form, assuring participants that what they are sharing will be kept confidential. Start with some general questions about the typical flow of attendees, especially those related to website design. Let participants know when you are ready to stop talking and start observing. Observation can range from active to passive. In active observation, a common approach is to have the participant take the role of the master and you the role of the student. The guru explains what he is doing as if teaching you his process. Active observation often gives you more context about attendee behavior, but can affect how attendees work. In passive observation, encourage participants to pretend you're not there. Your goal is to observe behavior that is as natural as possible. For example, when a participant is speaking to you, they are less likely to answer the phone or ask someone a question about a problem they are trying to solve. However, if you observe passively, there is a higher chance of it happening. You can then move on to the interview section and ask about the reasons for certain behaviors you've observed. Both methods work well. If you don't have a lot of time with the participants (e.g. only 2 to 4 hours at a time), you can generally opt for active observation to ensure you get the depth of information you want. If you have a full day or more, passive observation can be a great balance of natural behavior and discussion. Once you get the information from your questions, you have a lot of massive data to sift through! How do you spot patterns or trends in your results? A useful approach is a technique called affinity graph. There are many great resources on the subject, but here's a brief description. A Quick Guide to Creating Affinity Diagrams Affinity diagrams are a technique that take a large number of clear and unambiguous elements (such as user statements or researcher observations) and combine them to form patterns and trends. Here are the steps for a simple affinity map session: 1. Gather the research team and attach their notes.
Choose a research technique
99
2. Give each person a packet of sticky notes and ask them to write an explanation on each note, along with a short code that can be traced back to the participant, e.g. B. His initials. Focus on statements related to website design, either specific (functional statements) or more general (statements expressing attendee attitudes towards the company or topic). 3. Have everyone attach the sticky notes to the wall. If you're conducting a large study, you need a large, blank wall; try to find one that you can visit for at least a few days. 4. When you run out of notes, start grouping similar statements side by side. This part of the exercise can also involve larger teams. This is a great way to share results. 5. As groups begin to form naturally, begin labeling the groups to provide further structure. If some sticky notes belong to more than one group, you can duplicate them and place them in any appropriate group. NOTE This method is useful for contextual investigations, but can also be applied to many other situations. For example, this is a great way to create categories for uncategorized topics together, thus moving the results of card sorting to other levels of structure.
Patterns can appear in many ways, so it's best to let them develop naturally. However, here are some examples of categories you might come across, including the types of statements you might find within them: Goal: "I'm trying to clear up any unfinished business here before I leave today." like
Linking external experience to internal thinking): "I use this online tool as my briefcase for things I refer to often but don't want to take with me." Ideas and feature requests: "I wish I could undo that make. I like."
Accidentally moved an entire folder and it took a long time to undo the operation. Frustration: "I'll ask the helpdesk about it, but half the time they don't."
Know where the problem is. "
100
Chapter 6: User Research
Solution: "It took forever and I just printed it out in the end."
List it and use it throughout the day. At the end of the day, I type in the results. Value Statement: "This tool right here has saved me a lot of time, so if you
Change won't take it away! "
The primary resource for in-depth contextual research is Contextual Design by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also provides detailed information on how to interpret the results using techniques such as affinity diagrams. For more information on mental models and how to understand them, see Mental Models: Aligning Design Strategy with User Behavior by Indi Young (Rosenfeld Media, 2008). This is particularly useful when dealing with the information architecture of your content sources.
Polls consist of a fixed, well-defined set of questions that are distributed to a large audience. They often contain closed questions (e.g. multiple choice questions) that can be easily collected using tools that can reveal patterns between answers. Surveys are great when you want to present results quantitatively rather than by calculating data (e.g., "82% of respondents who work from home said they have some form of high-speed internet connection" ). Open-ended Questions Used in Tool Interviews. However, you can also use it to gain qualitative information about user habits and attitudes. In the field of user experience, surveys are often used to measure user satisfaction (satisfaction with an existing website or application) or to create or validate user models such as segments or personas.
Choose a research technique
101
Basic Process As with user interviews, you don't want to ask questions that will force users to guess. Don't ask, "If you feature, attendees also responded faster." Use surveys when you have factual questions about demographic information, such as: Which of the following devices do you personally own? Select all that apply. Computer, mobile phone, gaming system such as Xbox, Playstation or Wii
Or in the case of questions about attitudes with a fixed range of different choices: Read the following statements and for each point choose the extent to which you agree or disagree with it. The pseudo-corporate customer service is responsive to my needs. Totally agree about. Neither agree nor disagree. Disagree at all
In particular, questions like the second example are often used in addition to usability test tasks. You can use this type as a follow-up question to find out if participants were frustrated completing the task. Participants were not always comfortable voicing negative opinions, but were often willing to voice their opinions when confronted with a rating system. This brings up another point: surveys are a great complement to other forms of research you might be conducting, such as user interviews or background research. The combination of the two research methods can provide a more comprehensive user picture than either method alone.
102
Chapter 6: User Research
Browsing If you want a high level of security in your results and you have the budget to do so, there are formal tools that allow you to measure user satisfaction by ease of use. These tools contain tested questions to ensure they don't appeal to or confuse a wide audience. Among the most commonly used are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and Measurement Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi.ucc . Just now
When planning your survey, consider the following: Who is your target audience?
Use your preliminary model to determine this. This will affect how you answer the rest of the questions here. Which survey assignment method did you use to get the best results?
If your core user base tends to congregate in one particular location, you'll likely get more results by going there and setting up a form for people to take paper surveys. If your user base consists of active internet users, online polls may be the best option for high participation. Or you may choose to use your current customer list to determine your user base through phone surveys. How much time do participants expect to spend completing the questionnaire?
this investigation? If you're offering some form of compensation, or if the person gets some other benefit by completing it, you can often create a longer questionnaire that can take half an hour to complete. If not, keep it short so people can get through - think 5 to 10 minutes. In any case, make sure participants estimate how long it will take and update their progress when they're done (e.g. by providing page numbers like "2 of 4" or giving a percent complete) .
Choose a research technique
103
How do you know when to start analyzing data?
Depending on the priority, you can choose whether the survey should be carried out until a certain number of participants has been reached or until a certain deadline has been reached. What tools will you use to collect and analyze data?
If you conduct an online survey, the tool you use to collect the data may have options for viewing and analyzing the results. If not, you need a way to get data into your tool of choice. For paper surveys, this means a lot of data has to be entered. So make sure you plan this time.
Focus groups Focus groups bring different people from a target group together and enable dialogue with them. A common goal is to solicit input on issues related to the organization or its brand, such as past experiences, relevant needs, feelings, attitudes, and ideas for improvement. Focus groups are a great technique that can be used for multiple purposes: To hear different user stories. Open discussions are a great form of communication
Bring out the storytellers in all of us. When a focus group is going well, participants draw on each other's stories and ideas and recall situations that they might not have experienced in a more structured one-on-one interview. Grouping and energy gives people time to remember and share these stories. Know the relevant differences in experience. Most people are born
They want to compare culture information sharers and favorite tools with others in their interest group. Often you can learn more about a competing site or service, or get tips on workarounds, resources, and support. generate ideas. Even if you don't want the group itself
As a designer, you often get great ideas for new features or designs directly from your team or by learning about their workflows or frustrations. Like the stakeholder idea, reduce it to the core requirement (see Chapter 4) to ensure it is taken into account. Gain insight into several points of the collaboration process. if you
Groups can be a great way for you to fill in the knowledge gaps when designing processes that involve multiple related roles and collaboration
104
Chapter 6: User Research
How people interact with each other. For example, when working with content sources such as an intranet, it can be helpful to gather a mix of people who create, edit, and consume content to identify areas where the process can be improved. There is much debate about the use of focus groups in UX research. This is not a good technique for usability testing (because users usually work alone and not in groups) and sometimes the group situation can unduly influence what the participants say. However, when well planned and moderated, focus groups can provide a lot of valuable insight into your design. Chapter 13 goes into this in more detail as part of the concept check. Basic Process When writing focus group questions, use the same techniques you use when writing user interview questions (described earlier). Start with simpler questions like "Tell me when was the last time you visited PseudoCorporation.com." Why did you go there? “Once participants are familiar with you, the others, and the topic, post any questions designed to generate ideas in the center of the group. Assign time periods to each topic and stick to it; it's easy to actually start a discussion and just pass the time! If you are concerned about time, place your most important questions in the middle of the topic list and end with them after people have become familiar with the event but before the time limit. Focus groups share much of the same logistics as usability testing. (Chapter 13 covers recruiting and scheduling.) The main difference with focus groups is that you need a larger space and a table where participants can easily interact with each other. Photograph 6 to 8 people per 1 to 2 hour group session. Give each person a name tag or place cards next to their seats so everyone can address each other by name. The format of the discussion itself should include an introduction, typically covering the following points: Your role as facilitator and what you hope to gain from the discussion
Discussion (like some of the points above).
Choose a research technique
105
Why participants were selected to participate (e.g. “You are all
current users of the Pseudo Corporation website, we brought you together to understand your experience"). How this information is used to design and use it
confidentiality position. As a moderator, you can listen to them and
Experience. You want them to feel like they have their fair share. So ask everyone to be straightforward but also respect the rest of the team. There are many topics to cover, so eventually
Discuss a topic to make sure you can cover all the topics. This can then flow into an introductory session with the panelists, which usually involves some sort of icebreaker question. Your goal is to get everyone talking about the first question, even if they're just telling a little story. You can start with one person and work around the table, or have people answer naturally and then say the name of the person who hasn't already answered. Typically, you'll discuss the first few questions around the table, and when you feel the group is ready, you can use body language to ask everyone questions.
Snorkeling: Body Language A good understanding of body language is a great tool when hosting focus groups or doing user research yourself. It can help you understand when someone is frustrated, upset, angry, or threatened, so you can identify when to try to calm someone down or follow up on a specific comment. It may take more than a weekend to read through the following book on the subject, but it is designed for easy browsing: The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).
If you call someone who didn't answer, repeat the question in case they didn't understand or didn't hear the last question.
106
Chapter 6: User Research
Little intervention was made in the discussion. Also, make sure that the disagreement is not a disagreement between two people. Don't say, "Bob, we haven't heard from you. What do you think of what Chris just said?" Instead (looking at Bob): "Bob, what about you? What's wrong with Pseudo Corporation's customer service?” What experience? As a moderator, you can dictate the course of the discussion and hand over a virtual microphone. Eye contact, speaking volume, arm movement and body direction keep you in control. Most people are very conscious of their body language and when someone is dominating their speech, these cues can be useful signals. If the cues aren't understood by the overly open participant, use a gentle but firm statement like, "Okay, that's great, I want to take this idea to someone else." Has anyone else had the same problem as Theresa? When you move on to a new, larger topic, verbally announce that the previous discussion is over and a new one is beginning so that people can agree on ideas for the next topic. Finally, as an event When an activity draws to a close, a mere glance at the clock and a change in your body's direction can signal that you need to end the conversation. As with any other activity, you should thank the group for their time. Sharing results with your team usually ends in 2. This can be done in two ways: sharing results based on the main topics covered, or grouping results into relevant categories, similar to background research. Affinity diagrams can be another effective way to bring together different trends and attitudes to illustrate project teams.
Card Sorting In a card sorting activity, participants (individually or in small groups) are given items printed on cards and asked to sort them into groups that make sense to them. You either group them into predefined categories (called closed sorts) or create your own groups and name each group yourself (called open sorts). By the end of the round of card sorting, you should be able to identify common patterns in the way people sort items and common areas of confusion or disagreement.
Choose a research technique
107
A common reason for this is to create a sitemap for a website or to create a hierarchy of content, categories and subcategories with items such as articles, documents, videos or photos. This makes card sorting a great technique when working with content sources. Note For more information about content sources, see Chapter 2.
Let's say you're working with a common type of content source: a corporate intranet. Many intranets tend to categorize their information by the department that owns it, navigating to human resources, operations, legal, marketing, etc. For long-time employees, this may not pose an obvious problem as they may already know each department's area of responsibility and know where to find information. But for new hires or those who need information they don't normally access, finding information that may belong to multiple departments (or appear to belong to no department) can be difficult. For example, where can you find a policy on hiring new employees? It could fall under legal matters, or it could fall under human resources. Map sorting can help you find common patterns in how potential users categorize information, regardless of departmental boundaries. Basic Process: Gather the items you want to include in the card sorting; 40 to 60 is usually a good range. You'll need enough to potentially create huge decks, but not so many that you overwhelm participants (or overwhelm you if you need to analyze the results). Choose items that you feel are easy to understand and don't contain unnecessary jargon. You can include some jargon that you think your audience is familiar with, but avoid too many "insider" terms. If you're using too many company-specific terms or acronyms (e.g., "successful campaign" to increase sales), you're testing the effectiveness of your company's marketing and communications, rather than building a general message hierarchy. For example, for an intranet, you can review vacation policies, 401(k) plan information, new leases, vendor contracts, non-disclosure agreements, and so on.
108
Chapter 6: User Research
New hire orientation, health insurance information, and computer security guidelines. This list is a collection of well-formulated items that can be categorized in a number of ways. You could set up one participant group for new hire onboarding and exit policy and call it “Human Resources” and you could set up another participant group for new hire onboarding and new employment contracts and call it “employee orientation training.” Once you have a list of items, put them into cards that are easy to group and ungroup. You can print and stick labels onto index cards or directly onto perforated card stock to separate into individual cards. Try it out by asking someone to sort the cards and give the group a name, for example by placing sticky notes on the stack and writing names on them with a pen. Ideally, your test takers will be people who are new to the project and activities. This will give you an idea of how long the event is expected to last. If the practice run lasts longer than an hour, you may need to cut out some cards! Once you have your final deck, you can have a real participant provide the following basic instructions: 1. Arrange the cards into groups that make sense to you. 2. Try to form a group of at least two cards. If a card does not appear to belong to any group, it can be set aside. 3. You can always name groups while sorting. At the end of the event, name as many groups as possible. Some trends can be identified simply by observing meetings. Others may require further analysis. There are several tools for entering and analyzing map-like results; many of them have tools that allow you to perform remote card sorting (see the Card Sort Variants section below for more information). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) offer remote sorting options and useful analysis tools. Or, if you want to do your own sorting manually, check out Donna Spencer's excellent table in full
Choose a research technique
109
For instructions, see www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet. Card Sort Variations So far, the discussion has focused on personal card sorting, in which participants were asked to name the categories they created. It is an open sorting, which means that the main categories are not communicated to the participants, but they can name them. This is a great approach when defining a new navigation structure or making major changes to an existing one. For other cases, consider these common sort variations: closed sort. For closed sorting, specify the advanced category
and add participants. The results are relatively easy to analyze because there are only a small number of possible categories and you can focus on which items belong to which categories most often. If you're adding a lot of content to an existing information architecture or validating an existing sitemap, closed sorting can provide quick and actionable information to help you make taxonomy decisions. group sorting. You can also do this instead of having individual items categorized
Use card sorting as part of a focus group activity to have participants sort items together. While the results don't necessarily reflect how someone grouped items, you can gain insight into how users feel about the items and their organization by doing activities together and discussing the reasons for each placement. Sort by distance. Sorting can be a fun activity, especially with physical cards
Divide into groups. However, there are many great tools for taking care of personal matters online. This also allows you to reach more participants or some participants who are physically difficult to reach. The tools OptimalSort and WebSort mentioned above are two tools that simplify this type of online sorting.
Usability Testing Usability testing requires participants to perform specific tests on a website or application (or a prototype thereof) to identify potential usability problems and generate ideas for solving them.
110
Chapter 6: User Research
If you want to collect information to improve your current website, you can conduct usability tests during the definition phase. Alternatively, you can run it on similar websites (e.g. competing websites) to identify potential opportunities for a more user-friendly solution. Typically, usability testing is performed as part of the design phase, ideally in iterative rounds (where the design is created, tested, refined, and tested again). In Chapter 13, "Design Tests with Users," we again go into detail about usability testing. There you will find recruitment and planning tips to help you carry out the activities discussed earlier in this chapter.
Post Research After you have completed one or more user research activities, it is time to reconsider your initial assumptions about your user group. Put those assumptions aside for a moment and ask yourself what user groups you would create if you had more information. If some of your previous assumptions were invalid, consider any gaps in your user research as key groups were not considered. If this gap is identified early in your research activities, you may have time to adjust and add another group of participants to the ongoing study to ensure you get a complete picture. With your new knowledge, you can modify user definitions to more accurately reflect the groups that should be of interest. This allows you to create more detailed tools such as roles (see Chapter 7) and user requirements for the list we started in Chapter 5. Require. They follow a similar process as users: your work doesn't stop when you capture an idea or request. Dig deep into the underlying needs and goals to make sure you understand them. Ultimately, this will help you design a solution that best suits the needs of all relevant user groups. In the next chapter, you'll learn how to use user research insights to create a tool that can focus on user groups during the design and development process: personas.
after investigation
111
7
Personas Find the best way to put your team (or client) in the users' shoes. Personas are often a topic of discussion among UX practitioners. Opinions range from how much content is needed, how much research is required, and whether it adds value to the project. Some people wonder if they belong in the process. No matter where you position yourself, personas can be used to help your project team and clients resonate with their users. Personas offer comprehensive control over many parts of your project - business requirements, visual design or quality assurance - by gaining insights into the target group and their expectations and behaviors. Lars Unger
67
What is a role? Personas are documents that describe typical target users. They are useful for your project team, your stakeholders and customers. With the right research and description, personas can paint a very clear picture of who is using a website or application and possibly even how they are using it. UX designers often consider creating personas to be a great empathy exercise. Well-crafted personas are often used as a point of contact when questions or concerns arise about how aspects of the project should be designed. You can take out your character and ask:
This chapter focuses on interactive characters.
Why should I create a character? Personas help you focus on representative users during the UX design process. By providing insights into “real” user behavior, personas can help resolve conflicts that arise in design and development decisions, allowing you and your team to move forward. How real should the character be? The answers vary widely. A single persona document might be enough for one team, while another might create entire “habitats” for user personas to gain insight into their “life”. You can even take it to the extreme by creating a personal online presence that you can interact with to gain insights into your online behavior. It depends on how you want to expand your character. Roles can constantly remind your users. A useful technique is for your team members to maintain personas in their workspaces. They are too
Why should I create a character?
113
Constantly remind them who their users are. After spending a while sharing a cube with "Nicole," a 34-year-old licensed hand therapist from West Chicago, IL, you feel the need to give her an experience that works for her. If it helps, carry a printed copy with you to your sleep and let the penetration fairy transfer your empathy from the side through the pillow to your dormant subconscious. The purpose of personas is to help you, your team, and/or your clients clear the confusion you may have when you're at a crossroads.
Finding Information for Personas Effective personas should accurately describe specific users of your product or website. To achieve this, roles need to be supported by research. Chapter 6 covers techniques for researching and modeling potential users to create a solid foundation for your personas. But don't look for a way to solve the problem, rather collect as much data as possible and combine it with observational and interview data - this includes, for example, online surveys and analysis of behavior in social networks. This is a common theme when creating personas: preserve real data, but make personas real people on the page. For more information on how one company did this, see the "Case Study: The Messagefirst Role" sidebar.
Creating Personas Once you've identified your audience and gathered the data to support your personas, your next step is to put pen to paper and bring them to life. How many characters you need to create varies. Generally there are at least three, but more than seven are not uncommon. Rather than targeting specific numbers, think about how many target segments you have and how you think you can best represent those segments appropriately.
114
Chapter 7: People
Case Study: Messagefirst Personas To create effective, data-driven personas, Messagefirst (www.messagefirst.com) leverages no fewer than three different data input sources based on: Stakeholders. We interview her to find out who she thinks the character is and how she acts. This is always included. Client's attorney. We interview people in the company who speak directly to customers, so typically sales/marketing and customer service. Everyone has their own biases and we need to keep that in mind when documenting our findings. For example, the most common people who contact customer service are those who have too much time on their hands (often retired or unemployed) or are so upset about a product or service that they take the time to contact you. Customer. We speak directly to actual people who will use or use a product or service. This will be included where possible. Customer Data Sources. We review all available blog traffic, polls, and emails. people we know. We choose someone we know who fits the original image of the character. This helps us stay grounded, ensures the characters are believable and real, and provides a real way to reach out to us if we have additional questions. This is very important for validation and is always taken into account. Because each data input source we use has some bias, we use multiple sources to normalize the data. With data-driven personas, it's not about predicting how many you'll have, it's about having the data show how many there should be. When analyzing data, I look for behavioral and activity gaps. These gaps reveal individual roles. Todd Zaki Warfel, Chairman, Message First
The example person for this chapter is Nicole, a 34-year-old certified hand therapist from West Chicago, Illinois. She is a commuter who does not drive and commutes two to three hours a day to and from work. The fictional customer is a company called ACMEblue, a maker of Bluetooth headsets for Apple's non-fictional iPhone.
Create a role
115
You can learn a lot about Nicolle in this short paragraph, but as you can see in Figure 7-1, the actual character has a more detailed story about Nicolle. Note that the content is about Nicolle and was not "written" by Nicolle. It's better to write your characters from a third party's perspective than to write them in different voices, especially when you're just starting out. Of course, as you expand your experience, you should explore and find the style that suits you best and offers the most benefit.
Figure 7.1 The role of the fictional customer ACMEblue
What information goes into the role? The type of information that your audience finds relevant and credible is the type of information. The research data you collect should help you determine what is important to your client, your brand, and your project. Most of the roles you create share a common set of required content mixed with any amount of data, statistics and other relevant information that can be considered optional as it can vary from client to client and even project to project.
116
Chapter 7: People
Minimum Content Requirements When creating personas, you need to provide enough information to attract people and connect them to the people reading them on the page. To help your audience understand what your character is doing and thinking, include six key pieces of information: photo, name, age, location, occupation, and biography. The following sections explain the details of each item. Photos Photos are the first (and real) step in expressing who you are. When choosing a photo for your character, make sure it doesn't look too staged or sophisticated. Photos that appear posed will not look the same as photos taken in a more natural setting. The character looks more effective when the photo is taken in a more natural setting, such as the photo at right in Figure 7-2 where the subject is outside in winter clothing, perhaps on their way to and from work. Make sure the photo fits the character's lifestyle! Asked
Natural Image 7.2 Photos that look natural are more effective.
There are several photo resources online. Some better options are iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com), and Stock.XCHNG (www.sxc.hu).
Create a role
117
Finding the right photo can be tedious if you're not careful. When all else fails (or you have the time and budget), do it yourself! Name Put simply, it's all about writing the name on the face. The photo you use will humanize the combination of research data and personality traits, and the name will be what everyone calls your character in discussions. Not only does "Nicolle" sound better than "blonde working mom, 30's," it's also more memorable and associated with a certain personality. Avoid using overly similar names for different roles in your project. For example, Nicolle and Noelle are easy to confuse, so look for different names. While it may be tempting to use a colleague's or client's name, please do not. If you use similar or identical names for people involved in your project, they can easily try to identify themselves in your role. Choosing a different name can avoid awkward situations or hurt feelings. If you're having trouble choosing a name, a few online resources can help: Baby Naming Websites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Social Security Administration Popular Baby Names: www.ssa.gov/
OACT/Baby Name Random Name Generator: www.kleimo.com/random/name.cfm
One last thing about names: make sure your name is believable for the character. Nicolle is for a Midwestern mom, but Nicola or Natalia might be better for an Italian mom. Names that seem funnier or livelier, like Bob the Builder, don't count either. They tend to make your character look stupid and diminish their worth. Age While your research should determine the age range of your consumers, providing a specific age for your personas can help add authenticity to the bio you're writing. A 21-year-old student and a 34-year-old working mother behave very differently!
118
Chapter 7: People
Location At first glance, location does not appear to be essential information; however, it is important to remember that cultural and behavioral changes may vary from location to location. In Italy, for example, different dialects are spoken in different parts of the country. In the United States, someone living in Chicago will most likely have a different cost of living than someone living in Savannah, Georgia. Occupation If you know what your character's occupation is, you can identify with him by relating to his everyday patterns. A character working as a healer will encounter many people on a daily basis, while a drawbridge operator may not interact with others much. A biography is a compelling story that brings a character to life. Here you provide details from the research data and supplement them with some “real people”. However, dates are very important to a character, but you don't want to just quote that information in a stuttering sentence. Instead, you want to tie data, anecdotes, and observations into a story that resonates with your audience. This might seem a bit odd, but a bio should be believable, and if you include aspects of real people in your character, it's definitely not a scam. For example, Nicole is based on statistics and real-world behavior of a person with similar activities, beliefs, and aspirations. Depending on your project, you may need to dig deeper into the bio — sometimes, the more detail you have, the better. You don't feel like you have to squeeze your character onto a piece of paper. Choose the method that best brings your character to life and makes the most sense for the project you are working on.
Optional Content When using roles, you will find that different projects require different sets of information to make roles more applicable. Minimum content requirements are also considered to be the least common
Create a role
119
The denominator for most characters you will create. In most cases, you'll mix some of these optional content elements into the core of your character. Optional things that can add value to your character include education levels. Knowing how much education someone has can pay dividends
Learn about some of their habits. Someone with a high school degree may have very different buying habits and brand perceptions than someone with a master's degree. This information can affect how others perceive you as a person. Salary or salary table. Money is everything, and in many cases quantity matters
A person's income has a major impact on their standard of living and disposable income. This information can provide important insights if you are aiming for a certain level of wealth. Personal offer. what motto your character will proclaim
than their own? Sometimes this can give you a quick glimpse into a character's basic mindset. online activity. That can be difficult; there are many ways people spend money
their online time. Some pay the bills, some blog and socialize, and others simply use their computer as a device that they turn on when they have chores to do. Since many projects have online components, this element is more of a decision issue. You have to rely on your research to draw the picture. offline activity. Does your character have hobbies? Is there anything more?
Information about what life is like when your character is not online? This element can be just as challenging as online activity, but it can be just as important in influencing your personality. A key entry or trigger point for a client, brand, or project. often very important
Learn how personas interact with customers, brands, or projects. Was the persona heard through word of mouth, online reviews, billboards, TV or radio, or online pop-ups? Does your role want to solve a problem that can be solved with a client, brand or project? Understanding this through your stats and incorporating this into your personas can help reinforce your approach to attracting users.
120
Chapter 7: People
Technical comfort. Does your character use a PC or a Mac? she is
No computer at all? Does she use instant messaging, Flickr, or blog? Is the activity comfortable or confusing? Would a very simple solution for newbies help her? Does she have an MP3 player or other portable device? Is she watching TV on a DVR or AppleTV or on demand? The list could be continued endlessly. and go further. Depending on your client, your brand or your project, it can be important to know these and other terms. social comfort. Given the development of social media and social networks
As you work, it can be important to be very specific about how your character engages in that particular space. Does she have a twitter account? If yes, how many followers does she have? How active is she? Is she the leader? Does she use MySpace, Facebook, LinkedIn or other aggregators or online communities? Mobile comfort. With the increasing use of mobile devices
With that in mind, it's important to consider how your character behaves - if at all - in movement space. Motivation to use the customer, the brand or the project. In some cases you might want to
State why the character wants to use the client, brand, or project. If the cords from her headphones keep getting caught in her jacket and tearing them off her head, that's probably a good reason for her to think about getting a new pair of headphones. Real-world scenarios based on research data can help uncover key drivers to incorporate into your personas. user goals. You may also want to determine what the character desires
Do this by leveraging a client, brand or project. This helps to understand what makes a character use it. These are just data points to get you started. You can build your characters and present them in countless ways. If you're interested in delving into the world of personas, the user is always right: A Practical Guide to Creating and Using Web Personas by Steve Mulder and Ziv Yaar (New Riders, 2006) is a good place to start.
Create a role
121
Advanced Roles Once you understand the basics of role creation, there are countless ways to enhance your documents. A simple role can usually cover most of your needs, especially if your project team just wants an empathetic understanding of your users. It often becomes more interesting when you present the persona to the customer. In these cases you will often find that you have to provide far more information than you have gathered for the base staff. Figures 7.3 through 7.7 illustrate some of the ways roles can be expanded. Feel free to borrow, remix, and remix these samples to create something even better for your projects!
Marke
Know branded consumers
Personas and Scenarios (based on ethnographic research) Personas are composite personas based on target consumer data: in this case ethnography, existing segments and data from customer databases.
Scenarios are hypothetical but realistic stories that describe why these characters would visit a brand's website and what they would do there.
Joan, 32 Consumer insights help us to understand our users - their motivations, goals and desires. To apply these insights to website design, we develop user personas and scenarios based on real-world context. This design approach helps create rich experiences based on understanding customers, their motivations, desired outcomes, and behaviors. Scenarios specifically answer three fundamental questions that must be answered before a site can be properly organized: Ŕ8IPBSFZPVSSFQSFTFOUBUJWFVTFST Ŕ8IBUBSFUIFVTFSōTTQFDJţDHPBMT Ŕ)PXDBOVTFSTBDIJFWFUIFJSHPBMTBOEHeget a comprehensive experience on your website
Fun seeker "I really enjoy this" "Youth cultivated"
Start
begin to discover
build experience
"Beginner"
"$)*&7&-&7&- Comfort Van
„Positive Responder“
Feeling 5)&365
found again
"Veteran Researcher"
streamline and simplify
"Grown in a Ditch"
Handy for completing the It Must Work quest
Alice, 26 years old
Rachel, 42 years old
Eric, 47 years old
greetings, 59
Figure 7.3 Role overview main table (horizontal). Provides an aggregated view of the division of different roles and how they are presented in the context of the high-level organizational strategy. Thank you Will Evans.
122
Chapter 7: People
Marke
Characters and settings (based on ethnographic research) Alice is an aspiring chef who wants to explore the world of food.
Goal
Diet specially designed for children, with friends, finding new recipes online and in magazines. Her explorations are about more
Start a family without effort
Fantasy is bigger than reality. She's still intimidated and doesn't do it
Find quick and easy recipes with basic ingredients
I try too many new recipes. Her mother didn't teach her much cooking and her friends didn't have much experience
(often) cook two types of meals: adult meals and children's meals
Also don't cook. Alice is a mother to a busy daughter in Chicago. Both she and her husband work outside the home - she runs the offices of a small insurance company.
Alice, 26 „Aspiring Newbie“ x Generation Married
1 daughter, 5 tired, ambitious
income
raise
She is very busy and down to earth and doesn't spend much time cooking. Alice just wants to make it quick and easy, although since she started training after giving birth to Sophie two years ago, she often has to cook multiple meals for herself and her husband and try to get back into marathon shape. Based on a small selection of successful recipes that she is comfortable with, many of the meals she prepares are packaged and prepared food based.
SCENE Alice and Sophie watch Cartoon Network together over breakfast. A brand ad will appear with the brand name on it. Alice uses the trademark and thinks that Sophie will choose this dish. She decides to check the website after work. Alice has free access to the site half an hour before the meeting. The homepage is clear and concise. She sees the main section of the website and links it to interesting things, such as the recipe of the day.
internet usage
health awareness
cost sensitivity
She clicks on the recipe of the day. She loves the tips included - they make her feel like she can handle this recipe. She likes the clear navigation, unlike other websites where she often gets lost. In addition to what she sees in the cookbook, she loves the helpful features, like the ability to find recipes based on what she has in her pantry, as well as tips on how to use the products. Alice discovers that she can receive the cookbook newsletter and clicks subscribe. Registration is that easy! She filled out some basic information and selected the Food Your Kids Will Love newsletter.
She wanted to add more of her own twist and recreate dishes she loves to eat in restaurants, like her all-time favorite rotisserie chicken. She also wants to include more fresh vegetables in her meals because she knows they're healthier. She prides herself on being a thorough planner and being able to run the family within a budget. Her fridge and pantry are always stocked with groceries. She plans to shop to take advantage of special offers and coupons.
Find kid-friendly recipes and meal activities. Find ways to "spice up" their favorite ready meals. projects and initiatives. Improved navigation and information architecture. Improved login
A week later, at lunchtime, Alice found her first branded e-newsletter: "Pizza, as easy as 1, 2, 3." Perfect - her kids love pizza and she usually buys it frozen. A link to Pizza for Beginners inspired her to make her own pizza. The link took her to a pepperoni pizza recipe on something called "Pizza Wizard." She reviewed the recipe and found it easy: just 25 minutes and 4 ingredients. She checks her kitchen to see what she has. She didn't have any pepperoni or pizza sauce, but the "pizza wizard" suggested replacing them with something from her well-stocked kitchen: sausage and tomato sauce. and perfect! There is a link to the voucher. Neena prints out a recipe shopping list, adds a few more items she needs, and heads to the store. Back from the store, Alice gets to work. She saw step-by-step instructions for rolling out the dough and adding toppings. There are pictures for each step. It's easy to understand and follow. She wondered if she should cook the toppings first, but the Pizza FAQ answered her question.
Contextualized environment information. More targeted newsletters. Recipe Assistant. Better integration of coupons. meal plans. "Get it done" attitude. Rely heavily on convenience foods with relatively little addition of fresh fruit and vegetables. Take your time. Browse recipes instead of cooking them
Figure 7.4 Audience roles (horizontal). This granular view of personas includes richer data and provides a more holistic view of user goals, needs, and behaviors, all within a larger ecosystem. Thank you Will Evans.
Figure 7.5 Target group overview and target group characteristics (longitudinal). The target view on the left provides a high-level summary, showing the brands that the three personas engage and interact with. The detailed description on the right provides an overview and biography of an individual character, as well as information about their actions and motivations.
advanced people
123
Paul and Helen "I think we can throw anything in there." I just don't know how much fits in.
5 4
Helen's mother passed away a few weeks ago and they are only now starting to clean up the house. You are planning to sell the house, but there is still a lot that needs to be clarified first. The house also needs some renovations in the main bathroom.
3
– or the basement is full of things that Helen's mother has collected over the decades. She never throws anything away. She has run newspapers and Time Magazine for 20 years. Helen wants to keep something. Most of the clothing - turtlenecks and furniture - is donated to Goodwill. Unfortunately, most of her mother's "good stuff" was spoiled by water and mold. She still has a few cans of paint, but Paul and Helen don't know if the paint contains lead.
2 1
Mann
Exceed
Ain
了解 Ex led pe ge rie nce C on Pric ve e Senior tunc pe sp Re e M pu e d ult type Timtion C on eline t Main ss ajo er r L Siz ife es D E ecven lutte t Year Re rding pe Waste Tariff in Bu ar s dsine Pr ss og r O Recam nlin ycline ac g 计数
This is the first time Paul and Helen have experienced something like this. They don't even know where to start. You just want it to be as simple as possible. They know they need a litter box but aren't sure how much space is inside. They think almost anything can go in the trash unless someone tells them otherwise. Their only concern is that the litter box is mostly ugly. They want to find a company that doesn't make their front yard look like a construction site or destroy the yard when they make deliveries or pick up dumpsters.
Alter: 24-65
Life Cycle January
July
December
Mond
1.0 life events
Key Features Ŕ Ŕ
One-off events such as buying a home or making minor renovations (such as a bathroom). Little or no experience buying litter bins.
Ziel
Get a trash can now. Get rid of anything they don't keep or donate. Avoid damage to property. Avoid ugly litter boxes. When the waste bin is full, dispose of it immediately.
Frustrations and Pain Points Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ
Vragen Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ
Oh
AVAILABLE IF NEEDED PRICE SELLER WILL LEAVE PROPERTY IF SHE FIND IT CONTAINER SIZES DELIVERED SPEED OF POSTING AND COLLECTION ON CONTACT ONLINE ACCOUNT ACCESS SCHEDULE AND PAYMENT QUALITY AND CLEANLINESS OF UNIT BRAND DISPLAYED
Ŕ ŕ ŕ ŕ
Shock at the first sticker. I'm not familiar with the process. I don't know what they don't know. Make comparisons between suppliers
Is there something you can't get into? How fast do they deliver and collect? Will they keep the property as is? How does this work? Is a license required? How much? How easily can I reach someone if needed?
Figure 7.6 Audience roles. This role proposes an age target derived from survey data. The information it contains is broad and aimed at an audience rather than a specific individual. This approach is useful when creating a business proposal or client budget that allows for detailed exploration of the personas. Courtesy of Todd Zaki Warfel.
Jill from all walks of life
Amanda Steen
5
"I have to manage multiple projects for my clients."
4
3
AMANDA shares responsibility for the incentive program with a few other colleagues. They share access and manage multiple programs for clients. Making sure she's paying the right people for the right programs can be a particular challenge. She must be able to switch between different programs and always know where she is.
2
1
life cycle
Hauptmerkmale
Manage multiple projects. Medium to large companies. Medium volume (50-2,000+ orders at a time). Several people share a role. 70/30 admin. Fast payments and checks. Weekly to bi-monthly use all year round. Very interested in reporting. If you want to report on several cross-departmental reports, the Heavy Excel program uses a tailor-made in-house system
Ziel
Integration with current systems. Ability to pay employees quickly and easily. cost (usually time). guidance.
Other applications - Excel - PowerPoint How do I run reports in all my programs? Ŕ Is there a way for Internet Explorer to get my credentials without calling Ecount? Is there some way we can integrate ClientZone so we don't have to keep switching back and forth between different applications? Am I doing this right?
Ac FT N cew ou P n Cart Zod Re ne que est E Adasy s m Pijn C he c R Cu ep ks or rr enrting tB al Peace Cu ople st om Soft System Excell
friendliness
simply
Influencer
Pay your employees quickly and easily. Ŕ Avoid duplication of effort. Ŕ Check the current account balance to see if a transfer is required. Ŕ Track transactions on a weekly, bimonthly, monthly, quarterly and yearly basis.
Reason
For example
Oh
von
dg
dg a ow Kn
j
ETC.
Exceed
Ah
Mann
She uses Account Zone frequently—a few days a week. Leading several projects, she is very active throughout the year.
activities and interests
Technology
Alter: 28-55
electronic
electronic
To know
Ain
Account Zone has really helped her issue new cards and ensure program participants get paid quickly. The only thing she lacks is the ability to watch every show and every show she hosts to see how things are going. Your clients love to track the performance of the program. She is currently tracking this in Excel. She ends up sending Excel files to her clients, or sometimes she exports them and sends them PowerPoint with some nice charts. It would be nice if Account Zone had a way to run its reports for both a single program and multiple programs.
July
Ŕ ŕ ŕ ŕ ŕ
R
R
R
R
Mond
Setbacks and pain points
questions-
December
It is not possible to watch multiple programs at the same time. It is not possible to run reports from multiple programs at the same time. Correcting errors in receipt files sucks. It is unclear where exactly the problem lies and how to fix it. Multiple steps across multiple apps are inefficient and it's easy to lose track. Multiple confirmation screens. Another username and password to remember. Search emails with their credentials.
Figure 7.7 Target group-specific personas. This role is a heavily data-driven model. While the story of a day in life is a story, the rest is rendered in bullet points to serve as a design checklist. The chart is used to convey a large amount of information in a small space. Courtesy of Todd Zaki Warfel.
124
Chapter 7: People
As you can see, you can combine data in many different ways to represent personas and adapt them to different situations. Start with a basic character, then expand to suit your needs.
Final Thoughts on Personas Many UX design practitioners do not believe that personas adequately express user needs, goals, and attitudes. They believe roles can hinder creativity, innovation, or good design for a variety of reasons. Other practitioners believe that when based on solid research data and combined with some level of personalized reality, personas fill specific needs that influence the design process very positively. Which side of the coin you end up on is entirely up to you. This chapter is not intended to influence your decision in any way. There are many articles on the internet on this topic and many professionals who are happy to give you their opinion. All of these resources can help you figure out which role best suits your project. So check them out. Jared Spool, CEO and founder of User Interface Engineering (www.uie.com), also offers some insights on this topic: Value comes when teams visit and observe their audience, record and discuss their observations, and reduce confusion. The pattern then becomes the character. What the team has in mind when designing will have a big impact on the final design. The character descriptions are just there to remind everyone what happened.
Jared's point is simple: by observing your audience, combining what you've learned with research data, and breaking it down into segments, you should be able to create personas that generate empathy and set your team on the right path. Pursue and build your best self. Possible application, website or product. In the end, however, your characters will resemble Santa Claus: they are only valuable if people believe in them.
Final Thoughts on Characters
125
8
User Experience Design and Search Engine Optimization The Essential Role of User Experience Design for Successful SEO Search engines are the foundation of the interactive economy. As “interactionists,” everything we do is ultimately connected to the world at large through Google, Yahoo, MSN, Ask, and the myriad of smaller search engines that provide the infrastructure for finding content online. Information architecture is an important part of how search engines interpret websites. This chapter aims to give you a basic understanding of why UX design is crucial for SEO and what factors you need to consider to give the environment you create a chance to show up on Google. Jonathan Aston
67
Introduction to SEO Put simply, search engine optimization is the process of developing and maintaining web properties to achieve and maintain the highest rankings in public search engines for specific target keywords. Search Engine Optimization (SEO) is like a martial art, a never-ending process of learning and practice. Even a master can accomplish much through observed behavior or learned methods. Search engine optimization works as long as there are search engines and websites that are interested in selling something to searchers. SEO relies on three basic areas of improvement and impact:
Likely to affect: site infrastructure, technical and organizational principles, content, and any keyword issues related to optimized terms
Search engines can see links or link popularity - the quantity and quality of links pointing to you
Other websites' websites and the organization of links within the website. We'll break down each of these three areas and look at them from a UX designer's perspective to better prepare you for the optimization challenges ahead.
Why is search engine optimization important? Interestingly, even today we still need to explain the relevance of SEO. Customers tend to understand to some extent that it is important for their website to attract targeted visitors from the organic results of the major search engines. Beyond that, however, most interactive marketers find it difficult to understand the implications of SEO. Global search volume data is available from a variety of sources. What's important to understand, however, is that the numbers are huge regardless of the source, and year-over-year growth is always in the double digits. Global searches are mostly increasing on a quarterly basis. When Google first launched in 1998, 10,000 searches per day was a massive amount and an incredible burden for a beta version of the system.
Introduction to SEO
127
Hitwise (www.hitwise.com) reports that Google and its subsidiaries (including AOL and YouTube) account for the largest share of searches worldwide, accounting for nearly 72 percent of searches conducted in the United States as of November 2008. Yahoo followed with just under 18 percent, followed by MSN and Ask.com with 4 and 3 percent, respectively. Internationally, Google is even more dominant, reaching over 80% market share in many markets. NOTE For more background on Google's beginnings, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), in 2008, 750 million people worldwide performed more than 60 billion searches per month, with more than 18 billion in the US alone. In other words, 95% of internet users use a search engine at least once a month, with the global average being more than 80 searches per month.
Beyond these impressive sales figures, what does this mean on a practical level for interactive marketers? In short, if you don't reach your target customers when they search for your product or service, your competitors have a chance to sell to them. Look at your website analytics and think about it: how much revenue would the website generate if strategically targeted traffic increased by 10%? How about a 100% increase? Or 1000%? If your website isn't generating significant traffic from organic search, SEO is a must. A small investment in SEO can go a long way, especially when all previous engagement marketing efforts have focused on buying traffic through sponsored listings. We've seen a 35 to 1 website ROI on monthly SEO spend. If you pay a search engine company for sponsored listing traffic but don't invest in organic traffic, you're effectively limited to about a 10% chance. Think about your own search behavior: when was the last time you clicked on more than one or two paid sponsored listings in the search results? Any discussion of why SEO matters and why it persists can be continued across chapters. Suffice it to say that Google can only go up, and that effective interactive marketing should incorporate SEO as a core component of effective execution.
128
Chapter 8: User Experience Design and Search Engine Optimization
Important basic resources Specialist knowledge is the result of comprehensive training. A professional who only focuses on his field loses track of everything else around him. Therefore, every interactor needs to spend at least a few minutes learning SEO. While there is no official guide, Google has been kind enough to provide some very notable resources. If you are interested in working on better search engine performance, see this link: Help for Webmasters/Site Owners: Search Engine Optimization:
www.google.com/support/webmasters/bin/answer.py?hl=de&answer=35291 Help for webmasters/site owners: Webmaster guidelines: Quality guidelines:
www.google.com/support/webmasters/bin/answer.py?hl=de&answer=35769 An SEO guide for beginners:
www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf If that's not enough, dive into the newsletter and blog. Start with SEOmoz.org and go deeper. Remember, like anything else in life, if it sounds too good to be true, it probably is.
Website Technology, Design and Infrastructure Search engines are essentially Web 1.0.5 technologies, firmly anchored in the Web 2.0+ world. The premise of a search engine has changed little since WWW Wanderer launched in 1993 to search the web and create the first web search engine. Essentially, every search engine has an application called a crawler, spider, or robot that finds links, follows them, and sends a copy of the asset back to the database for inspection. The database is then analyzed according to the search engine's own algorithms. These rules are used to index a web element and then rank it according to its position on that search engine's specific scorecard. In this fairly simple process, UX designers encounter countless pitfalls.
Site technology, design and infrastructure
129
Understanding these core relationships will help you see your website through the eyes of search engines. An optimized website is based on structures and techniques that facilitate the movement of search engine spiders. Likewise, many content processing decisions determine how search engines rank the results of jobs. Much of this is preordained by wireframing decisions and discussions about content design and curating.
Flash, Ajax, JavaScript and other scripted content Today's dynamic and interactive web design is based on technologies that are completely unsuitable for the needs of search engines. There's a growing gap between what search engines can see and what designers can do. User Experience Designers ensure a strategic plan for delivering dynamic, design-intensive websites so that both search engines and users have the best possible experience. Once you have a basic understanding of how search engines interact with this type of content, you can decide when to use them and where to close their weaknesses. By setting the correct offset early in the process, it's entirely possible to create an optimized site that relies heavily on scripted content. Once a website is up and running, it becomes significantly more difficult to create static or indexable content. As such, there is strong support for static content based on usability and the interests of search engine crawlers. It may seem like extra groundwork, but the return on investment is exponential. Flash Flash content is technically "indexable." Search engines have recently made some advances in the ability to search Flash files for the text and links embedded in those files. Have you ever seen a Flash-only project rank at the top of search results when that content was indexed? Probably not, because it's risky for a search engine to open itself to be fully compatible with Flash. Let's assume that all links and text content embedded in SWF objects are fully visible to search engines. What's stopping a ruthless (or "black hat") optimizer from placing apples in a feature's text layer during rendering?
130
Chapter 8: User Experience Design and Search Engine Optimization
The oranges for a human user viewing fully compiled assets through a browser? How can you deeplink to a Flash asset without fully compiling it? These basic loopholes will remain until search engines can reach a level of artificial intelligence that can recognize that an image is a horse without the accompanying text "This is a picture of a horse". To design a Flash website that is compatible with search engines, you need to add a static content layer that replicates the Flash content. Regardless of the needs of search engines, the static content layer is currently the key to meeting usage needs. Think of a search engine as someone viewing web content over a dial-up connection or using a browser with a screen reader. These people may represent the lowest common denominator, and the policies behind your web development may reject this tiny percentage of human users. However, if you ignore this small group of people, you also ditch GoogleBot and Yahoo Slurp, two of the most important website visitors, as they are the crawlers that major search engines use to index your website. Without visible text or crawlable links to search engines, your content will inevitably remain undetectable in meaningful search results. Static layers can be built in different ways. To keep search engines happy, the static content layer needs to reflect the Flash content. This is not an opportunity to show search engines anything other than what is provided in Flash. If you do this, you will go against the spirit of the game and find yourself on the dark side. The ideal way to embed Flash content in a static layer is to use a SWF object so Flash and static content can reside on the same URL. This allows search engines to find static content and allows Flash browsers to display animations instead of static content. Avoid using redirects whenever possible to maintain the popularity of links to Flash content. Google Code provides a set of simple instructions for implementing this simple JavaScript snippet at http://code.google.com/p/swfobject. There is another option that operates on the gray end of search engine optimization. Cloaking might be a dirty word for SEO purists, but if you approach the following challenges from the right perspective, you can blow your mind.
Site technology, design and infrastructure
131
Cloaking uses user agent detection, which detects search engine crawlers when visiting websites and redirects them to static pages for indexing. However, when a human visitor sees the same page in search results and clicks a link, the website recognizes that the user-agent is a human with a Flash browser and presents that human with the dynamic experience on an entirely separate URL. The crux of the problem is the same as the SWFobject approach: you need to show search engines exactly the same content in your hidden content as in your Flash content. Ajax, JavaScript, and Other Scripted Content Ajax is a powerful Web 2.0 content driver that enables web developers to create pageless content. However, the problems that search engines encounter when using Ajax are many and require good planning to avoid making major mistakes. Ajax stands for Asynchronous JavaScript And XML and refers to the difficulties that search engines have with this technology. In principle, search engines cannot handle JavaScript; the efficiency that JavaScript offers developers is a problem for search engines when dealing with dynamic content. Another problem search engines have with Ajax is the asynchronous nature of the technology. Search engines can only see the content of the first page that loads, and any content that is scripted after the initial shell load is invisible to indexing. Because Google cannot extend the session after the first page loads, and there is no mouse or external proxy to trigger the script, all user-triggered no-page content is invisible unless the text content is converted to a preloaded one Shell included. It is up to the UX designer to ensure that the 3D modeling required to create a no-page design includes the requirement for both text and links to be preloaded into the page shell. Everything else your cool design is invisible. Script-Based Navigation One of the most common problems hindering optimization is the use of JavaScript as the heart of website navigation. This is a common situation and a result of how many website development and content management tools work. Scripted navigation looks cooler, so people are usually interested in using it. But when JavaScript is the technology that controls the navigation of the website, it results in search engines not being able to model good links
132
Chapter 8: User Experience Design and Search Engine Optimization
Relationships within the site: You just can't see the site's link structure. If search engines can't model the link relationships on a site, deep content won't show up or get the right link popularity.
Content Management Systems Content management systems are designed for human comfort, but many of them make it difficult for search engines to interact with their results. Here are some typical problems to avoid by using workarounds or choosing a more search-friendly content management system: Dynamic URLs. Search engines don't understand "pages" of content; she
Know the way to this content. Changing the path or URL to this content may cause search engines to unexpectedly clone the content multiple times. This situation significantly affects the website's ability to properly perform its task. If your content management system has a system for creating a session ID in the URL, you could be in real trouble. Use sophisticated analytics for tracking, not session IDs. Multiple URL paths. A typical problem in e-commerce content management
The problem is that the product builds multiple URLs throughout its life cycle. Also, since search engines only know content pages by the URL at which the content was found, it doesn't take long when a product appears in a category, is part of a gift basket, is a weekly sale (etc.). Look for search crawlers that follow multiple different links to find the same one. Do what you can to ensure that each piece of content only exists on a single URL, and that in fact multiple paths depend on a single URL, regardless of where the link is implemented. Rely on a sophisticated analysis system for channel analysis. Accidental Cloning. when you recognize a piece
Content should only be accessible through a single URL path, and other situations can easily occur in the content management system, resulting in content being cloned unintentionally. The scheme should, so to speak, only have a URL path to a single piece of content. infinite loop. A consequence of the accidental cloning problem is as follows
loop at night. Make sure you don't place search engine spiders
Site technology, design and infrastructure
133
Keeping track of "next" links in a calendar or similar can be an endless task. If the search engine spider can follow the next link to the next day of the calendar where it can find another next link, it will follow that link to the next page and so on. Avoid this by using scripted links that search engines can't follow, so crawlers can spend their time on the content you want to index. Old URL structure. First, many website redevelopment projects
What ects does is replace the old url structure. The problem is that search engines may already be indexing content on those old URLs, and once you change everything you're essentially sending the index back to where it was. In addition, all deep links that the website has created over time point to the old URL structure. Be sure to keep as many old URLs as possible. If you change your content management system, you will most likely need to change all URLs. So, if this is unavoidable, it is recommended to give the old URLs a 301 Permanently Moved status code and redirect them to the new URLs on a one-to-one based old URL. 301 redirects are the only redirects accepted by search engines.
Domains, directories, and URL structures are all important. If you're starting from scratch and branding concerns allow, try to pick a domain that contains a keyword or two. It's hard to get a .com domain with quality keywords these days, but if you do, separate them with a hyphen. An important part of how UX affects SEO is your website's directory structure. It has a crucial impact on how link popularity is distributed across the site. Simple is better. Be sure to avoid foreign files in your directory structure. Some content management systems automatically add a subdirectory; prevent this from happening. This situation weakens the relevance of the entire site. Search engines understand the hierarchy of your website based on the structure of your sitemap. So make sure your most important directories are at the top of the hierarchy. If your environment allows it, use keywords in the URL structure that relate to parts of your site. Separate keywords with hyphens and
134
Chapter 8: User Experience Design and Search Engine Optimization
Don't use too many keywords in a filename. Look for something like this: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure you have set up a redirect for http://site-in-question. com to 301 Moved Permanently redirects to http://www.site-in-question.com. When a site uses "www" and not, search engines (especially Yahoo) index the contents of both URLs, opening up the entire site to prevent accidental duplicates. This tends to spread when third parties link to a non-www website and that website contains a dynamic link structure.
Content: Was (is) and Will be King While content creation is someone else's problem, the basics of website architecture have a lot to do with making the right content available to search engines. As with all forms of keyword searches, you need to understand the actual search behavior of people looking to view your property. Search engines are still very "primitive" as they rely on users typing in keywords to link them to articles more or less related to those words. Choosing the right phrase depends entirely on whether your website is relevant to the right context. Ideally, your SEO partner will provide you with a set of keyword phrases before you start and will work with you throughout the wireframing process. If you don't have a competent partner involved in your process, use the Google AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) to research actual user search behavior Your category research. Then, take some time with that input to find out what phrases your prospects are searching for, and use those phrases on your website when needed. Search engines look for keywords in many places when analyzing a website. Optimization is all about making sure the right words appear in the right places. By understanding the role of keywords in the UX design process, you can create the framework necessary for future success.
Contents: Kings who were (and are) and will be
135
Why is Content King? It's at the heart of what a website should offer. Search engines need text content that they can see and index. Website visitors demand engaging content that deserves their attention. Bloggers and webmasters need content that is worth linking to. When the right content is in the right place, search engines can't bring the right visitors to your site.
Naming conventions and jargon issues It is critical that keyword targeting is reflected in the taxonomy developed for the site. Using keywords in the main structure of your site can make the entire site more relevant to what you are selling. If you sell widgets, don't refer to your online product offering as a catalog, but as a widget catalog. Also, use your keyword research to make decisions against technical jargon. For example, use laptops instead of laptops in the tree because people search for laptops more than 10,000% more than laptops.
Metadata, Titles, and Keywords Before we return to the basics of metadata, it's worth noting that we've gotten this far in this chapter. There are tons of meta tags, but only a few really make a big impact as all others are prone to spam. Related tags are: Page title. Note that this is not a tagYes but
actually