UX A DESIGN GUIDE FOR
PROJECT
FOR DESIGNER USERS WITH EXPERIENCE IN THE FIELD OR IN CREATION
RUSS NIÑOS A CAROLYN CHANDLER
PEACHPIT PERS
A Design Guide to UX Design: For UX Designers in the Field or Apprentice Russ Unger and Carolyn Chandler
New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (fax) Find us on the web at: www.newriders.com Send a message to[email protected]New Riders is a brand of Peachpit, a division of Pearson Education. Copyright © 2009 by Russ Unger and Carolyn Chandler Acquisition Editor: Michael J. Nolan Design Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laflamme Style Editor: Leslie Tilley Proofreader: Suzie Nasol Composer: Danielle Foster Indexer: Valerie Perry Cover Design: Mimi Heft Cover Production: Andreas deDanaan Interior Design: Mimi Heft
Disclaimer 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 for reprints and excerpts, contact[email protected].
Disclaimer The information in this book is distributed "as is" without warranty. While every precaution has been taken in the preparation of the book, neither the authors nor Peachpit shall be liable to any person or entity in respect of any loss or damage caused or alleged to be caused, directly or indirectly, by the instructions contained in this book. . or the computer hardware and software products described therein.
Trademarks Many of the designations used by manufacturers and sellers to distinguish their products would be trademarks. Where such designations appear in this book and Peachpit was aware of a trademark claim, the designations appear as requested by the trademark owner. All other product and service names mentioned in this book are used solely for editorial purposes and for the benefit of those companies, with no trademark infringement intended. Such use, or use of a trade name, is not intended to convey 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 the United States of America
Praise for a UX Design Project Guide If Russ Unger and Carolyn Chandler were wizards, the Alliance would hunt them down for revealing their best secrets. Lucky for you, they aren't. Russ and Carolyn have collected sage wisdom previously known only to the most seasoned UX project leaders and codified it for all to see. Now you can learn the secrets needed to run great UX projects. Jared M. Spool, CEO and founder of User Interface Engineering
Is there a book that can tell you everything you need to know about user experience design? No. Is there a book that will take you there? It exists now. Carolyn and Russ have laid a solid foundation for planning and managing design projects. This is an essential primer for anyone caught up in competing methodologies, endless meetings, and all the moving parts of user experience design. Dan Brown, author of Communicative Design
This book is a fantastic introduction to designing great products for real people. But it covers much more than design, it also covers everything related to design: managing projects, working with people and communicating ideas. A great handyman. Donna Spencer, author of "Card Sorting: Designing Actionable Categories"
This is a practical, accessible, and very human guide to a very human activity: collaborating with people to do great things for other people. Steve Portugal, Consulting Portugal
If you have heard of Wil Wheaton, the author, you will understand why I hold Russ Unger in such high regard. Russ' experience and guidance were instrumental in the construction and design of Monolith Press, and he has been one of the most valued employees I have ever worked with. Wil Wheaton, author of Dancing Barefoot, Just a Geek, and The Happiest Days of Our Lives
iii
Acknowledgments Russ Unger This book would never have been completed without the support of my family, friends, colleagues, and a host of people who were complete strangers to me before I typed the first few keys. My beautiful wife, Nicolle, who knowingly married a geek with a gifted pet, managed to double parental responsibilities for most of the writing of this book. Our daughters, Sydney and Avery, often prodded and prodded her nearly comatose father to dance, sing, and play Spore. I inadvertently thought that writing a book with a newborn at home would not be such a challenge. I quickly learned otherwise. And Nicolle went out of her way to fight back over and over again to save me and give me the focus she needed to complete this project. She is the hero I trust the most; she keeps our house in order in the midst of chaos. She is the center of our world here and she lets us go too easily. Nicolle, along with Sydney and Avery, manage to make me seem like a good parent and I'm thankful for that. I live in a house with three girls and I can't imagine loving any of them with less than I have to give. Carolyn kept me on track. There were times when I felt like this project would never start or end. She always kept things moving, explored ideas, and steered us in the right direction. The collaboration has been great and I have learned a lot from it! It's definitely a great UX yin to my UX yang. Michael Nolan was our acquisitions editor and he was the perfect guide. Michael is honest and kind and he really helped make everything go smoothly. Rebecca Freed was the juggler, she handled every aspect of the book, kept us on our toes and regularly emailed us late at night. Unfortunately, she often would get responses from me almost immediately! Linda Laflamme was our development editor, and once I got used to the Red Pen of Doom of hers, it was pretty clear that she was leading me in the right direction, no matter how hard I tried to drown her in half-hearted thoughts and running sentences. . Leslie Tilley put a finishing touch on the words; Tracey Croom collected production, design, and graphics; and a real book appeared. Steve "Doc" Baty read each chapter before it saw the light of day in the Peachpit offices. I sent Steve chapters around 2 am, and he
GRACIAS
he would submit his comments at 5 am, which is no small feat. Mind you, Steve is in Australia, but he's still impressive. Without Steve's constant willingness to help and quick responses from him, it's hard to believe this book would have made it onto the shelf. Brad Simpson (www.i-radiate.com) took all the images I threw at him and turned them into beautiful, print-ready images, often as he juggled his own life with two teenage children and a busy work schedule. . It would have been easy for Brad to drop out at any time, but he is a true friend who was interested in the project and wanted to support me. I'm not sure there are enough steaks to make up for that effort, but I'm going to work hard for it. Thank you Brad for giving up many of your days off and late nights to support this. Mark Brooks found me panicking several times when he was trying to deliver messages that required a visual component beyond my time and/or ability. Mark stepped in more than once and saved the day and I am indebted for that. Talented and giving it his all, Mark is the kind of person I want to be. Jonathan Ashton wrote the entire chapter on search engine optimization for us. After speaking with Jonathan for 5 minutes, I knew he was the right person for the job. His chapter alone is a good reason to buy this book, and it was great to have him there. Jono Kane entered the game at the last minute and last minute. Jono is a web developer, interaction designer, and prototyper at Yahoo and was invaluable in helping him write Chapter 12. Lou Rosenfeld really helped get the ball rolling. In addition to co-authoring the famous "Polar Bear Book" (O'Reilly's Information Architecture for the World Wide Web), Lou is smart, friendly, approachable, and always willing to help others in our field. You'll be hard-pressed to find many people as generous to themselves as Lou. Christina Wodtke helped me make introductions and contacts. Without Christina, I'm not sure where we'd be today, but I probably wouldn't be "in print." She is not only a "must read" author, but also a person who has always been available to advise and clarify. Many in the UX design space owe much of what they know to Christina's tireless efforts to broaden our horizons through constant innovation. THANK YOU
v
Will Evans and Todd Zaki Warfel have generously provided high-quality products that you can use as templates for your own products. They were true brothers and gave their time and talent without question or concern, often in the blink of an eye. They are great members of our UX community, the ones you want to meet and work with, and I am lucky to be their friend. I certainly cannot do justice to the gratitude I owe these two. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING crowd) and Wil Wheaton have all been close friends, true supporters and believers. I am lucky to be able to write these names together as a list of people I know and am a huge fan of all they do. Your support has been invaluable to me in everything I do. These wonderful people went above and beyond to help me by generously contributing information, stories, and access to their resources, and I thank them with all my heart: 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; Nick Finck (www.nickfinck.com), Chapter 10; Jesse James Garrett (www.adaptivepath.com), chapter 10; Austin Govella (www.grafofini.com), Chapter 11; Jon Hadden (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), "A 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 Brief Guide to Meetings”; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), 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 Brief Guide to Meetings”; Samantha Soma (www.sisoma.com), “A quick guide to
vi
GRACIAS
Encounters"; 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 to thank Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, SXSW's Hugh Forrest, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton as well as the folks at Manifest Digital and everyone at Draftfcb I have inevitably missed someone and I hope you don't take me personally I tried to keep up with everyone If I missed you, please let me know and I'll find a way to make it right Finally, it's important to note that without organizations like the Institute for Information Architecture, the Interaction Design Association, and others, it would have been impossible for me to connect with many of the people If you're curious about the field of UX design, explore these organizations, join them, and get involved.
Carolyn Chandler Many of us have dreamed of writing a book one day. Without Russ, I don't know if he would ever have the motivation to do this. His energy and enthusiasm helped us find the right people at the right time, from the Peachpit team to UX industry leaders, all of whom have had a huge impact on what you see on these pages. He truly is one of the great connectors in our profession and likes to bring people together day and night. I also think he posts more tweets in a day than me since I joined Twitter! Russ thanked many of the people who helped us tremendously. I won't repeat all those names, except Steve Baty, who read all of our chapters in whatever rough shape we could throw at him and still managed to sound excited at 2am (his time). John Geletka also provided thoughtful commentary and intriguing discussion with a spark and perspective that transcends multiple disciplines. And of course the Peachpit team; I will never forget receiving my first chapter of Linda Laflamme. It wasn't pretty (although she tactfully made her suggestions). they patiently
GRACIAS
viii
he guided me through the edits and helped me improve my fluency, which was originally better suited to writing a few articles than an entire book. Now I even add transitions in my informal conversations with colleagues! Speaking of which... Christine Mortensen, aka Morty, was my partner in crime when it came to the footage. The icons and diagrams you see in my chapters are the result of her hard work, and I know how much, because she and I worked on many of the same client projects while trying to meet chapter deadlines. Morty is one of those visual designers who can plant her feet firmly in visual and interactive design, she enjoys collaborating with everyone on the project and bringing concepts to life. She has a focus on integrity and quality that makes her a joy to work with, and it was an honor to have her as a partner on this. Thanks also to all the people at Manifest Digital, who have given me great support over the last few months. Jim Jacoby brought a special combination of business acumen and user experience, with his trademark zenlike calm, that got me through some stressful moments. Jason Ulaszek is one of the most enthusiastic people I know in the UX space and has endless knowledge of tools and techniques; I have no idea where he makes room for all of this! Additionally, Brett Gilbert and Jen O'Brien provided valuable insight into some of the many roles that UX designers work with. I also want to thank the Manifest UX team members who inspired me and were so patient with my constant references to the progress of the "book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. . It is a constant pleasure working with you. Every day I appreciate your humor and insight. To my fellow members of the Interaction Design Association, thank you for sharing your experience and being an active member of the UX community that I love. In particular, I'd like to thank Janna Hicks DeVylder and Nick Iozzo, who have been instrumental in the development of the Chicago chapter and continue to find new ways to develop a vibrant network of smart people. Last but not least, I would like to thank my family, friends, and Anthony, who patiently endured my disappearance and continued to check that I was still alive. You have plenty of rain checks to cash and I look forward to spending them on you!
viii
GRACIAS
Contents INTRODUCTION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV
CHAPTER 1: The
Tao of UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is user experience design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The Broad Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Do not forget the tangible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
About UX designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Where UX designers live. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Let's get started! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 CHAPTER 2: The
project ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Identify the type of location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brand presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Marketing campaign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Content Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Task-Based Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 e-commerce sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-Learning Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Social Networking Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . twenty
Choose your hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Information Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 User Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you may have or need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Building a network of user interests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Understand the corporate culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Squeeze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CHAPTER 3: Proposals
for consultants and freelancers. . . . . . . . . . . . . . . . . . 39 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Make the proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CONTENT
ix
Front page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 deliveries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ownership and Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional Costs and Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Price of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Acknowledgment and Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Statements of work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 CHAPTER 4: Project
Objectives and focus. . . . . . . . . . . . . . . . . . . . . . . . . . 56 Reinforce project objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
How can a UX designer help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Understand the focus of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Cascade approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 modified approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 How does focus affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 CHAPTER 5: Business
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Understanding the current state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Collect ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Describe responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Gather the right stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Create a meeting plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Requirements Taking Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Manage meetings effectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Fusion requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
X
CONTENT
CHAPTER 6: User
Look for . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic steps to find users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating an attribute list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Setting and Defining Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Choose research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How many research activities can I include? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 User interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 searches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Focus groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Sorting cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
After searching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 CHAPTER 7: People
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 What are people? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Why should I create characters? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finding Information for People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Creation of Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Minimum content requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Optional Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
advanced characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Final Thoughts on People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 CHAPTER 8: User
Experience in design and search engine optimization. . . . 126 Introduction to SEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Why is SEO important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Important basic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Technology, Design and Infrastructure Site. . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and Other Scripted Content . . . . . . . . . . . . . . . . . . . . . . 130 Content Management Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, Directories, and URL Structure It all matters. . . . . . . . . . . . . . . . . . . . . . . . 134
Content: The previous (and current) and future king. . . . . . . . . . . . . . . 135 Naming Conventions and the Battle with Jargon . . . . . . . . . . . . . . . . . . . . . 136 Metadata, headings and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
CONTENT
XI
Part the hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Using sitemaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep content up to date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other content issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Explanation on the popularity of links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical distribution of link popularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 footer links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Content crosslinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Game the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat versus Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Send spam with meta keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Cloning and landing pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Link Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Some final considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 CHAPTER 9: Transition:
From definition to design. . . . . . . . . . . . . . . . . . . . 144 Conceive and visualize resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
The basic storyboard process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Facilitate the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Keep a good tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The Advocate for Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Conflict management during prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Plan your activities and documentation. . . . . . . . . . . . . . . . . . . . . . . . 162 CHAPTER 10: Location
Maps and workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is a workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Tools of the Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Basic elements of sitemaps and workflows. . . . . . . . . . . . . . . . . . . . . 168 page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Stack of Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Decision point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Connectors and Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 careless connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
XIII
CONTENT
Misaligned and unevenly distributed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Badly positioned text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Missing page numbering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 The simple sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Advanced floor plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Breaking the sitemap mold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Taking task flows to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Rays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 CHAPTER 11: Wire structures
and notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What are annotations?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who uses wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Create wireframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Tools of the trade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Start simple: create a basic wireframe. . . . . . . . . . . . . . . . . . . . . . . . . .191 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Wireframes and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
An exercise: Design a home page wireframe. . . . . . . . . . . . . . . . . . . 195 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The Results: Designing a Wireframe Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual design: when wireframes grow and find their own way in the world. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Follow-Up Design Exercise: Which Design Is Good? . . . . . . . . . . . . . . . . . . . . . . 201
One final note on presenting wireframes. . . . . . . . . . . . . . . . . . . . . . . . . 202 CHAPTER 12: Prototyping .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What is prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How many prototypes do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Paper Prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe vs. Realistic prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML vs. WYSIWYG Editors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional Prototyping Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
CONTENT
XIII
Working with a developer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Examples of prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 What happens after prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 CHAPTER 13: Project
Test with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Concept exploration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Tips for Exploring Visual Design Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Usability test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Choosing an approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Scheduling the search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Writing Discussion Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Facilitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and presentation of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Make recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 CHAPTER 14: Transition:
From design to development and beyond. . . . . . 247 This is the end... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual design, development and quality assurance. . . . . . . . . . . . . 248 (Re)testing the design with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1… Launch! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Post-launch activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post-Launch Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Post-launch design testing with users (again, again) . . . . . . . . . . . . . . . . . . . . . 255
All set, right? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 How to start again... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 CONTENTS
xiv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
CONTENT
Introduction Why We Wrote This Book Welcome to a project guide to UX design. Somewhere, a user experience design student is awake because he doesn't know what it will be like to work on a real project at his new company. Across town, a visual designer with extensive project experience is eager to take on new responsibilities to shape the user experience on her website. They are two people at different times in their lives, but with a similar need: to understand how to integrate user experience practices into the context of a living, breathing project. Our goal with this book is to provide the basic tools and context that will help you use UX tools and techniques with work teams. As you'll see in many of these chapters, we don't try to be everything to everyone, but we try to give you the basic information and knowledge you need to complete many of the tasks you need. I will be assigned as a UX designer. In addition to our own examples, we provide examples that help identify ways to take advantage of raw materials and allow you to mix the information together and create something new, better, or even more suitable for your own purposes. We hope we have expressed well that this is a very good approach for UX design projects. We are nothing if we don't constantly try to learn and improve (what we do) with each iteration. That is why we are in this field to some extent. A word from Russ As a mentor at the Institute for Information Architecture (www.iainstitute.org), I noticed a pattern among the people I worked with: most were having difficulty finding work or not meeting expectations. Some have excellent training, but not always enough practical application of their UX design skills in a project-based environment. The same themes resonated in many of the conversations I had at the Information Architecture Summit (www.iasummit.org) in 2008.
INTRODUCTION
XV
The idea for this book, which addresses many of these common questions, began to take shape. I don't remember if Carolyn or I sent the first email, but I do know that I found in her a willing and able co-author who helped me develop the idea that ultimately became this book. A word from Carolyn For years I have been fortunate enough to build and manage UX teams. I say "lucky" because I think UX designers generally have a great balance of traits that make them fun to work with, a combination of right-brain intuition and left-brain logic. When I conducted interviews to build these teams, one thing really stood out: a related background, such as human factors or communication design, is a good indicator that someone is committed to the field of UX design, but it's not the most important indicator. . whether it exists or not. someone would be a good fit for the team or a project. Just as important, if not more important, is the person's ability to have the mindset of an advisor. That means a positive attitude, an effort to understand and involve others in a project, and above all, a focus on making a real impact for users and customers. This mindset involves taking the time to understand the perspectives of other roles on the project, discussing, and making compromises where necessary. It takes experience and effort to really capture this mindset, but an open mind, a solid foundation, and a good set of questions (with the courage to ask them) can go a long way. This book may not give you all the "answers," but it will give you the questions you need to ask to find them.
Who is this book for? A UX Design Project Guide provides a broad introductory look at UX design within the context of a project. Anyone interested in UX design should find something useful here. We specifically target the following groups: Students taking UX design courses (such as human-computer interaction or interaction design) who want to supplement their courses with information on how to apply their learning in real-world situations where communication and collaboration they are essential.
XVI
INTRODUCTION
Professionals who want to deepen their knowledge of basic UX design tools and techniques and improve team communication in all roles involved. Chapter 3 is also especially aimed at freelancers who need to create their own proposals. UX design group leaders looking for a book to help their teams integrate design best practices into UX design activities. Leaders of any project team who want to learn more about how UX design fits into their projects, its value, and what to expect from UX designers. IF YOU NEED…
THEN YOU MUST READ...
Define user experience design and understand what draws people into the field
Chapter 1: The Tao of UXD
Ask the questions that are important to answer before the project starts (or at least before you start working on it)
Chapter 2: The ecosystem of the project Chapter 3: Proposals for consultants and freelancers
Get off to a good start with efficient meetings, clear objectives, and well-understood approval points.
Online Chapter: A Quick Guide to Meetings Chapter 4: Project Goals and Approach
Define project requirements that are unambiguous and easy for stakeholders and business users to prioritize.
Chapter 5: Business Requirements Chapter 6: User Research Chapter 9: Transition: From Definition to Design
Know your users and represent their needs throughout the project
Chapter 6: User Research Chapter 7: People Chapter 13: Design Testing with Users
Choose and use the tools and techniques to quickly bring visual ideas to your project team
Chapter 10: Sitemaps and Workflows Chapter 11: Wireframes and Annotations Chapter 12: Prototyping
Make sure users and search engines can easily find and search your site.
Chapter 8: User Experience Design and Search Engine Optimization
Communicate and evolve your design with the project team as soon as development begins
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 Meetings" and to download additional materials such as templates.
INTRODUCTION
xvii
A note on methodology There are various approaches and methodologies available. We do not favor one approach over the other. Our goal for this book is to focus on the steps common to most projects: define the needs of the project, design the experience, and develop and implement the solution. The amount of overlap between these steps varies greatly depending on the design approach you use (see Chapter 4 for more details). Our framework is very much a flexible and linear approach in which the definition step comes first, but in each step we use facilitation and design techniques where they are most useful.
What this book is not An encyclopedia of all the techniques. The UX field has a large number of creative people, and they are always trying new approaches to design problems. Including all of these approaches here would make for a much larger book, and one that would quickly become outdated. What we have included here are the most commonly used techniques, the practical aspects of UX design. We have tried to provide enough information to keep you engaged and to enable you to communicate the activities to other members of the project, including the basic process for each technique and additional references to books or websites that will help you implement them once you choose your path. A guide to being a project manager. Good project management (including setting and tracking goals, schedules, and budgets) is the key to the success of any project. We won't go into detail about how to be a project manager or how to choose a specific project methodology. We discuss the skills that a UX designer brings to a project that allow it to be executed effectively, such as facilitation and communication, as well as the ability to clarify and stay focused on project goals. These skills will help you become a project management partner. The only perfect process or methodology to follow. We don't have all the answers, no one today. The field of UX design is relatively young and we are all working to improve where we are. You will probably find trial and error, tweaks and improvements, and feedback.
xviii
INTRODUCTION
from others help you tailor a process to your needs. If you find something that works for you, share it! Let us know!
How to use this book There are many great resources for UX designers. We've covered topics extensively here, but we've provided references that will allow you to explore topics at a deeper level, depending on how much time you're willing to spend on them. To help you understand the amount of time each referral typically takes, we've divided them into three main categories:
The surf references indicated with the surfboard are shorter (usually online) resources that take between 5 and 30 minutes to read.
Snorkeling Snorkeling talks are longer online articles, white papers, or short books that take anywhere from an hour to a weekend to complete.
Deep Diving The so-called diving helmets are longer books that will probably take more than a weekend to read; provide in-depth coverage of the topic.
INTRODUCTION
xix
This page was left blank internationally
1
The Tao of UXD Curiosity meets passion Meets empathy The most important thing is to never stop asking questions. Curiosity has its own reason for being. One cannot help but be amazed when contemplating the mysteries of eternity, of life, of the marvelous structure of reality. Just try to understand a little bit of this mystery every day. Albert Einstein
The sense of curiosity is the original school of nature. smiling blaton
Passion and purpose go hand in hand. When you discover your purpose, you will usually discover that it is something you are extremely passionate about. steve pavlina
The great gift of humans is that we have empathy. Mary Streep
1
q
In a nutshell, this chapter is about you, and about other people who are drawn to the field of 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 door handles to airplanes to that thing in the back of your throat. He especially wants to know what makes people tick. You don't see things in black and white; There are many shades of gray to discover! Sure, sometimes you can drive your colleagues a little crazy by offering to play devil's advocate, but it's not like you can stop trying to look at the other side of the coin. You're lucky! The field of user experience design attracts curious people who are comfortable working with many shades of gray. We look for patterns and thrive on organization and structure. We connect the dots. We relentlessly search for the next piece of the puzzle, and when it's solved, we look for ways to make it better! We can be analog or digital. We are at home with pencil and paper, whiteboards and erasable markers, sticky notes and Sharpie pens. We speak in terms of Visio and 'Graffle' and we live in a world of boxes and arrows connecting across the different screens of our computers. We are not just curious. We are passionate! We are passionate about generating ideas and facilitating discussions. We are passionate about creating things that make a difference to those who use them and those who make them. Interestingly, we take great pride when something we do is so good that people don't realize how good it is. And of course we keep our fingers crossed. We can feel it deep in the fabric of our being when we are faced with a bad experience. Worse, we immediately try to find solutions to solve the problems. We know what it's like to receive an unexpected response to what seems to be a simple request, and we don't like that! We don't want users, people like us, to have to put up with the confusion and feelings of inadequacy that often come with a bad experience. two
CHAPTER 1: THE TAO OF UXD
When you combine that almost constant, childlike curiosity with an unmatched passion for "doing what we do" and insight into how others feel, you get a vibrant community of professionals who are comfortable speaking their minds, asking questions, sharing solutions. and making a mistake - All in the name of being right. Welcome to the UX design community.
What is User Experience Design? There are many definitions for user experience design. After all, it is a field that thrives on defining things. Granted, sometimes we don't do a great job of "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 focus primarily on two definitions: the broader meaning of the term UX design, and the definition we will use in the context of this book.
Broadly defined user experience design is the creation and synchronization of elements that influence the experience of users with a particular company, with the intention of influencing their perceptions and behavior.
These elements include the things a user can touch (like tangible products and packaging), hear (commercials and sound signatures), and even smell (the smell of freshly baked bread in a restaurant). It includes things that users can interact with beyond the physical, such as digital interfaces (websites and mobile phone apps) and, of course, people (customer service reps, sales reps, friends and family). One of the most exciting developments in recent years is the ability to merge the elements that influence these different senses into a richer, more integrated experience. Smell-o-vision is still far in the future, but otherwise the products continue to blur the traditional lines.
WHAT IS USER EXPERIENCE DESIGN?
3
Don't forget the tangible While we focus on the digital aspects of the user experience, these kinds of interactions don't happen in a vacuum. Consider the effects of the tangible experience when designing your digital products. The environment in which your users work is important, as are the physical products—screens, keyboards, and other input devices—that affect how your users interact with your design. Chapter 6 provides techniques to help you understand the impact of context. Also, don't forget about the other touch points that a product or company has with those who interact with it. After all, a company's brand is influenced by many things, and the brand experience doesn't stop at the computer or mobile phone screen. The best possible website design cannot make up for a reputation for poor customer service or provide the satisfaction of well-designed packaging when a product is delivered.
Figure 1.1 A modern classroom experience combines analog and digital.
4
CHAPTER 1: THE TAO OF UXD
Tangible experiences, such as classroom learning, are increasingly influenced by digital applications. Similarly, experiences that used to be individual, like choosing a karaoke machine at home, are being enhanced through social interaction.
Figure 1.2 Online reviews are a big influence on the consumer.
Our Approach As you can see, the scope of UX design is wide and growing. For the purposes of this book, we will focus on projects that focus on the design of digital experiences, particularly in interactive media such as websites and software applications. To be successful, user experience design for these products must consider the business goals of the project, the needs of the product's users, and any constraints that affect the feasibility of product features (such as techniques, project budget, etc.). or the deadline).
WHAT IS USER EXPERIENCE DESIGN?
5
Free samples of a new nutrition bar given away at a marathon
a doorknob
Packing for a pair of shoes
Figure 1.3 This book focuses on the digital aspects of user experience design.
Tangible features for mobile text messaging
Customer service phone
Individual
Social
Our approach Read product reviews online Find an archive online View targeted ads
Live chat with digital customer service
About UX Designers While curiosity, passion, and empathy are traits shared by UX designers, there is also a desire to strike a balance. We're looking for a balance, usually between logic and emotion, like Spock and Kirk from Data and Data in that episode where their emotion chip overloaded their positronic relay. You get the idea. To create truly memorable and satisfying experiences, a UX designer must understand how to create a workable, logical structure for the experience and understand the elements that are important to creating an emotional connection with the users of the product. Exact balance may vary by product. An advertising campaign for children's toys will find a different balance than an application to keep track of patient data in a hospital. A product designed without understanding the need for both is likely to miss out on opportunities for an unforgettable experience and the resulting benefits for the company behind the product. Note For additional information on emotional design, see Donald Norman's book Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).
6
CHAPTER 1: THE TAO OF UXD
Achieving this balance requires a greater sense of empathy: the ability to immerse yourself in the world of potential product users to understand their needs and motivations. User experience designers investigate this understanding (see Chapter 6) and create tools such as personas (see Chapter 7) to help the rest of the project team focus their efforts. Remember that emotion is only one part of the big picture. Use the logical side to get off the edge and keep your mind on tasks. In most cases, you'll work with a budget based on the time and materials needed to complete the project. You have to understand that sometimes you have to fish or cut bait.
Where UX designers live You're not alone in this. Look around you and you will find many organizations and communities that can further your development as a user experience designer. In addition to offering mailing lists, online resources, and a host of really smart people, many of these organizations sponsor events or conferences that can help you broaden your horizons and narrow your professional focus. Several companies host events aimed at providing continuing education, including User Interface Engineering's Web Application Summit and UI Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. There is also a growing number of conferences in different cities; these are created by a collection of motivated individuals independent of any particular company or association.
WHERE UX DESIGNERS LIVE
7
Several professional organizations also sponsor annual conferences. Table 1.1 provides a short list of some of the better-known organizations, their websites, and the events they host. TABLE 1.1
An example of UX organizations
ORGANIZATION
WEBSITE
MAIN CONFERENCE (HELD THEMATICALLY)
Association Interaction Design (IxDA)
www.ixda.org
Interaction (beginning of February)
Information Architecture Institute (IAI)
www.iainstitute.org
IDEA Conference (September/October)
American Society for Information Science and Technology (ASIS&T)
www.asis.org
AI Summit (March)
ACM Special Interest Group on Human-Computer Interaction (SIGCHI)
www.sigchi.org
CHI (beginning of April)
The Association of Usability Professionals
www.usabilityprofessionals.org
EPS (June)
Let us begin! You have come this far. It's time to find out why you chose this book in the first place. Turn the page and dive into how UX design exists within projects. But don't stop there: this book is a guide to get you started. It contains many examples that can help you perform many of the activities assigned to you. We've also tried to provide additional examples to help you branch out and find your best approach to building products that are useful to your team and customers. Keep your curiosity, passion and empathy alive! Challenge yourself to find new ways to inspire others to create that ideal user experience. Of course, that's before you start improving it.
8
CHAPTER 1: THE TAO OF UXD
2
Project Ecosystem Planning for Project Needs, Roles, and Culture Are you about to start a new project? Or are you in the middle? Either way, take a moment to think about the dynamics and context of the project – the issues that will affect you and the rest of the project team. What kind of sites or apps are they? What roles and skills are required? What is corporate culture? Answering these questions will help you define the project and ultimately determine the tools and skills you need to succeed. carolina chandler
9
mi
Each project has its own challenges. If you're designing websites or web applications, many of these challenges have to do with specific features and functionality, such as creating a method for a user to share photos online with friends and family, or restructuring information on an intranet to make content easier. . share be saved found and shared. However, around these specific design goals, all projects have a larger context that you need to understand and integrate into your planning. This context is the "ecosystem" of the project and includes the environment in which you will be working (the company culture), the general type of work everyone will be involved in (such as the type of website you are designing), and the people. with whom you will work (including their roles and responsibilities). Taking the time to understand the project ecosystem will provide you with information that will help you throughout the project. You can communicate your responsibilities and ideas more effectively, and you can help other team members anticipate project needs they may not have considered. To help you, this chapter identifies different types of projects you can work on, as well as the roles you can play, the people you can trust, and how your involvement is likely to vary depending on the type of location or location application you are using. be designed. Finally, the chapter discusses some elements of the corporate culture that can affect the way you work on the project. Note Depending on how the client company structures its projects, a given project may involve the design of more than one site or application. For simplicity, this book assumes that a project involves the design of only one type of site. If you have more than one site, consider each site individually to ensure that you represent the correct roles on the project team.
Identifying the Type of Site While there is no absolute distinction between one type of site and another, there are some relative differences in site focus and features. Understanding these similarities and differences will help you set design goals for yourself. These are the general problems that should be there
resolved (such as "explain the company's business model") or attributes that will be displayed (such as "demonstrate that the company is responsive to its customers") in the visual and interaction design of the site.
10
CHAPTER 2: THE PROJECT ECOSYSTEM
Consolidate the main objectives of the project (see Chapter 4). Understand which departments or business units can (or should) be
involved in gathering business requirements (see Chapter 5). Determine best practices for incorporating user research (see Chapter 6). Ask questions about what systems and technologies may be involved.
Your site is likely to be strongly associated with one of the following four types:
Brand Presence: A constantly present online platform that facilitates relationships between the company and a general audience (anyone interested in its products or services). Marketing Campaign: A specific website or application designed to generate a specific and measurable response from a specific audience or general target group for a limited period of time. Content Source: A repository of information, possibly made up of different types of media (articles, documents, videos, photos, tutorials) intended to inform, engage, or entertain users Task-Based Application: A tool or collection of tools intended to enable users to perform a number of important tasks or workflows
The following sections take a closer look at each of these types, discussing their characteristics and the impact they will have on your challenges when designing a website or app. We'll also discuss the most common crossover projects: e-commerce, e-learning, and social media, which have features of more than one type.
Brand presence What do you think when someone says the word brand? Often the first thing that comes to mind is a company logo, like the Nike Swoosh or the Coca-Cola emblem. A company brand is much more than its logo; It is the entire set of impressions that a certain person has about the company.
IDENTIFY THE TYPE OF LOCATION
11
Dirk Knemeyer offers some excellent definitions of brand in his article "Brand Experience and the Web": Brand represents the intellectual and emotional associations that people make with a company, product, or person... each one of us. Brand science is all about projecting and influencing people's minds; in other words, build the brand.
Navigation To learn more about the distinction between a customer's experience with a company's brand and a company's branding efforts, read Dirk Knemeyer's explanation of "Brand Experience and the Web": www.digital -web .com/articles/brand_experience_and_the_web. For an excellent discussion of how the UX design of a website can influence an individual's brand experience, read Steve Baty's article "Brand Experience in User Experience Design": www.uxmatters.com/MT /archives/000111.php.
A business can do a lot to influence its brand associations, from running memorable ad campaigns to expressing brand attributes (such as "responsiveness" or "value") through its brand features and design. All of a company's websites are likely to have some influence on the company's brand, either directly (introducing a website for customers to visit) or indirectly (enabling an important service that customers trust, such as customer service). However, brand presence sites are more focused on displaying the company's brand messages and values. They provide channels that connect directly with customers and serve as a broad online funnel for those who want to learn more about the company or its offerings. A brand presence site is typically the company's main .com or .org site, such as GE.com, or for larger, more distributed companies, the main sites for business units of different sizes, such as GEhealthcare.com. Different product lines often have their own online brand presence as well. For example, Pepsico.com has a brand presence, while Pepsi.com has its own distinctive presence.
12
CHAPTER 2: THE PROJECT ECOSYSTEM
If you're working on a brand presence website, you're likely designing for a variety of user groups, including current and potential customers, investors, partners, media (such as news organizations and prominent bloggers), and job seekers.
Common Brand Presence Sites The main company site (company.com, company.org, company.net, etc.) A site for a main business unit of the company (usually a site dedicated to a
particular industry, region, or product mix) Sites for prominent sub-brands within a company
Brand presence design objectives The most important design objectives in a brand presence project are: Communicate the company's brand values and messages.
either explicitly (perhaps a statement about the importance of meeting customer needs) or through the overall experience upon entering the site (such as making sure the site works well and offers prominent features that encourage customers to interact and communicate with the company). Provide quick and easy access to company information. Want
answers the questions "What does the company do?" and "How can I contact someone for more information?" Present or explain the business model and value proposition of the company:
“What can the company do for me?” and "How does the company do this?" Engage a variety of core user groups and guide them to relevant interactions
features, functionality or content. Help the company achieve defined objectives based on key metrics such as
the number of unique visitors. This is often part of an overall marketing strategy. Later in the "Pick Your Hats" section, you'll learn the different roles that can be involved in designing a brand presence website. Let's see for now.
IDENTIFY THE TYPE OF LOCATION
13
on the other types of sites you can work with, including the one that is closely related to brand presence sites: the marketing campaigns site.
Marketing Campaign Marketing campaign sites are similar to brand presence sites in that both focus on engaging users with an experience that influences their perception of the company's brand. However, marketing campaign sites are often judged on their ability to perform very specific actions within a particular focus (such as within a given time period or with a target audience). Instead of serving as an interest funnel, they should be the engines that generate interest. From an online perspective, this typically means they align with an overall marketing strategy and can be executed alongside other cross-channel marketing efforts, such as radio or television commercials, print ads, and other promotions.
General Marketing Campaign Sites A landing page that promotes a specific offer. The page can be accessed through a
banner ad from another page. A small website (or microsite) that promotes a particular event. A game or tool created for the purpose of generating rumors.
the traffic.
The main goal of a marketing campaign website is to create a campaign with a specific objective, usually targeting a specific set of metrics. Focus is often constrained by one or more of the following: Time: For example, an event-focused campaign (such as a
conference) or a season (such as the holiday shopping season) User group, such as a campaign aimed at teens or teachers Product, set of products, and/or specific use for that product: for
For example, a site that highlights kitchen appliances and shows virtual kitchens with matching ovens, dishwashers, and stoves.
14
CHAPTER 2: THE PROJECT ECOSYSTEM
A campaign that uses a combination of these strategies would be a spring campaign targeting yard equipment sales, matching the time and product mix. See Figure 2.1 for an example of a product set and user group combination. A marketing campaign site can be as simple as a banner that leads to a landing page on the company's .com site, or it can be a microsite, a small site that often deviates from the brand name on the website. .com site to create an experience. tailored to one or more focus areas. "Small" is relative here: some microsites are just one page and others have many, but either way, the microsite is smaller and more focused than the company's main brand presence site.
Figure 2.1 Texas Instruments uses this education-oriented microsite, http://timathrocks.com/index.php, to present information about the company's graphing calculators. The product suite is mainly used by high school students and students in algebra classes. The microsite maintains general ties to the Texas Instruments brand, but is intentionally distinguished to appeal to a younger audience and to organize content and functionality according to their needs.
Design Goals for Marketing Campaigns For the person or team responsible for designing and implementing a website for a marketing campaign, the design goals that are often most important are: Generate interest and excitement, usually by presenting a clear vision and immediate.
current value proposition (the value that a product or service brings to the user, such as the ability to quickly activate a loan) or some type of incentive (a special offer, participation in a contest or entertainment, such as an online game).
IDENTIFY THE TYPE OF LOCATION
15
Engage a variety of core user groups to drive specific action,
like clicking a specific location on a brand website, signing up for a newsletter, or applying for a loan. When this action is performed by a user, it is called a conversion. Help the company achieve objectives defined based on key metrics such as the quantity
number of unique visitors. This is often part of an overall marketing strategy.
Digging In For more information on building pages to support marketing campaigns, check out Landing Page Optimization: The Definitive Guide to Conversion Testing and Tuning by Tim Ash (Sybex, 2008).
Content feed A content feed site contains a repository of information, possibly in different types of media (articles, documents, videos, photos, tutorials) and is intended to inform, engage and/or entertain users.
Resource sites with shared content A company intranet An online library or information center for members of an organization Sites or sections of sites dedicated to providing news or regular information
up-to-date posts (large business blogs may fall into this category) Customer Service Centers
All websites and apps have some content, of course, but some websites place special emphasis on the presentation and structure of their content. Emphasis can occur because the site has a large amount of content that poses its own challenge, or because specific types of content have a high level of importance; for example, they can support crucial decisions or keep users coming back to the site on a regular basis.
sixteen
CHAPTER 2: THE PROJECT ECOSYSTEM
The main goal of a content feed site is to increase user awareness and self-sufficiency by providing relevant content (for example, an intranet). They often also encourage some type of action, such as sharing information or purchasing a product after viewing the description. Content Feed Design Goals A content feed site should generally do one or more of the following: Present content that is the main attraction for first and repeat visits to the site. Demonstrate a company's knowledge leadership capabilities, for example
Provide access to ideas and perspectives from the CEO or other subject matter experts within the company. Support critical decisions among the user base. Increase knowledge of a company's business and provide ideas.
they can be buried in separate pavilions. This can be part of a broader objective to identify more opportunities for innovation. Support users who are looking for information in different ways. For example,
some still don't know what specific product they need (and are more likely to browse), while others may know exactly what they're looking for (and are more likely to use a search field).
Navigation To learn more about the different ways users seek information, read "Four ways of seeking information and how to design for them" by Donna Spencer: http://boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them
When it comes to UX design, some of the most common tasks in a content feed project are: Create a categorization framework that fits your users' mental models. Decide how to incorporate an organic content growth system.
(for example, features such as tagging and filtering) Design an effective search function IDENTIFY THE TYPE OF SITE
17
Task-Based Applications Task-based applications can range from a simple calculator built into a mortgage website to a complete system that handles multiple critical workflows. If your project includes the latter, it will involve more roles and likely a substantial requirements-gathering process (see Chapter 5 for more on this process).
Common task-based applications A software application that supports the creation of a specific type
item (such as a spreadsheet or printed part) A tool or web application that supports a critical workflow in a
business (such as a ticket management application for an IT support group or a customer tracking application for a call center) A website that allows access and management of personal information
(as Flickr)
The main goal of a task-based application is to allow users to perform a series of tasks that match their needs and ultimately the customer's business goals. Goals for Designing Task-Based Applications Most task-based applications should allow users to do something they can't do elsewhere or, if they can,
to do better ("better" can mean more efficiently, more effectively, more satisfyingly, or more conveniently) Support novice users with easy-to-access instructions and visual prioritization
main tasks Support for intermediate and advanced users with access to direct access functions
and deeper functionality Reduce user load and maximize system resources
(for example, reusing data vs. requiring double entry)
18
CHAPTER 2: THE PROJECT ECOSYSTEM
They are designed and implemented taking into account the degree of change required
of application users, ideally with a design that facilitates learning and a communication plan that demonstrates value to the user. One of the biggest challenges when designing a task-based application is controlling the advancement of features. As a project develops, it's all too common for great ideas to emerge at later stages of the project, or even during development. UX design is well-suited to combating feature advancement, as user models such as personas can be used to identify high-value features and maintain focus throughout the project. If a really great idea comes along later in the process and it meets the needs of a high-priority user base and aligns with the business goals of the site, your team can advocate in a different direction. If an idea doesn't go down that wringer, it may not be worth the delay and cost.
E-commerce sites E-commerce sites can include elements of all four types of design, because a primarily e-commerce site must have its own brand presence, provide content (usually product specifications or product usage descriptions), and facilitate tasks (searches). , compare, write reviews, pay). Marketing campaigns are also often closely associated with these sites and may involve different marketing groups within the organization. Additional general design goals for eCommerce sites are Explain what the site template is if it's not the default. How to market online
are constantly being redesigned, this explanation will help set expectations (for example, eBay, Amazon, and Craigslist all have very different models). Support decision making as the user transitions from learning to thinking
from compare to buy, with helpful content and resources. Take advantage of experience points where cross and upsells are made
possible and place these suggestions in a way that is attention-grabbing without distracting. Create a flow of communication from the point of purchase to the
delivery point. Communication should take place not only within the website, but also through other channels, such as integration with order tracking systems and email communication about order status. IDENTIFY THE TYPE OF LOCATION
19
E-learning applications E-learning applications are a cross between a content source and a task-based application. Lecture content must be generated, often requiring the team to add Learning Specialist and Subject Matter Expert (SME) roles for the topic being covered. The product is task based where the user generally follows a flow through the lesson and may also need to track progress or research related topics. Some practical lessons may also require you to complete assignments. Common design goals are to define an understanding of the foundational knowledge needed to start a course.
and to whom it is addressed. Deliver content in manageable, paced chunks
concept. Engage the student in activities that simulate hands-on learning. Communicate performance and progress and, where appropriate, make suggestions.
next steps to continue the educational process, such as more advanced courses.
Social Media Apps A social media app is primarily a task-based app, as users need to find and add friends, manage their profile, connect, post, and search. They also include content resource challenges, particularly the need for an organic structure that can handle a potentially very large amount of user-generated content. If the site essentially has its own identity, then it also has the characteristics of a brand presence site.
Snorkel Whether you're working on a social networking application or trying to integrate social features into another type of website, this book will get you started: Designing for the Social Web by Joshua Porter (New Riders, 2008).
20
CHAPTER 2: THE PROJECT ECOSYSTEM
Common design goals for social media applications include: Direct potential users to the purpose and values of the network. Facilitate meaningful interactions between users who support and are
backed by prominent features (such as image sharing, video sharing and discussions). Protect the integrity of the site by making sure that those on the network understand it.
Know how to handle your information and respond to inappropriate behavior. Leverage and showcase the power of the community to highlight resources
features that are only possible with active members, such as popular features and reviews. Identifying the type of website or app you're working on during a project is just the first step. Next, you need to consider the different roles that are often required, and how your involvement may vary depending on the type of project.
Pick Your Hats Becoming the UX designer on a project often requires you to play multiple roles. Regardless of whether they are formally defined within the client organization or not, the roles you play depend on the type of project and the composition of the rest of the team, as well as the client's experience with each. It's good to know which roles you are already comfortable in and which ones you think you can learn on the job. It is also helpful to find out what expectations others may have of the responsibilities covered by these roles. With this understanding, you can more clearly represent yourself from the start of the project. What are the most common roles expected of a UX designer? Each client company you work for may have different titles for these roles (or no name at all if it's not a formal job in the organization). In general, you can expect the big three: information architect, interaction designer, and user researcher. Note Few companies have the size or budget to divide these common roles among different people. Remember the names of the roles when you define a project, but talk in terms of needs and responsibilities when you talk to the client; otherwise, they might think you're building too big a team! This focus on responsibilities rather than titles will also help keep you sane: if you fill many of these roles, it doesn't necessarily mean you're doing the work of many people, as responsibilities come and go in different parts of the company. the world. . project.
CHOOSE YOUR HATS
21
Information Architect An information architect is responsible for creating information structure models and using them to design user-friendly navigation and content categorization. When designing websites and apps, common responsibilities include creating detailed plans (discussed in Chapter 10) and ensuring categories and subcategories of information are clear and easy to use. Understanding expectations Within the field of UX, a distinction is made between the roles of the information architect and the interaction designer (discussed below). However, in any given company, there is rarely a common distinction between the two roles, at least when it comes to what is established as a necessity for a particular project. For example, you might end up on a team titled information architect, since that's the historical term for the role, whether or not it fits your responsibilities. Do you have to correct the project team if the title you get doesn't match the lead role you take on? If it's a shorter project (for example, four months or less) and the position you hold is widely accepted within the organization, with clearly defined responsibilities, it may not be worth the potential confusion it would create to deal with. to change. He . However, if there is no commonly accepted title and you feel that both roles should be played, possibly by different people, then it is worth making a distinction early in the project when planning your engagement and communication. . Your responsibilities. 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 what makes the most sense is to use a term familiar to the client organization and make sure the team understands how you define the role in relation to the responsibilities you take on. You should make this definition clear in the job description (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see below under "Other roles"). if they are papers
22
CHAPTER 2: THE PROJECT ECOSYSTEM
represented by various people on the project team, be sure to discuss how you will work together early in the project.
Interaction designer An interaction designer is responsible for defining the behavior of a website or application based on user actions. This includes site flows across multiple views and interactivity within a specific view. When designing websites or apps, common activities include creating task flows that represent the interaction between pages or components within the website (see Chapter 10) and creating schematics that represent page interactions, such as menus. dynamic and extensible content areas (see Chapter 11). Understand expectations If you're working on a small team or on a project that isn't heavily focused on creating new task-based features (for example, if you're working on a branded showcase site that contains mostly a few categories of content, a contact form and a newsletter subscription form), the interaction designer may be primarily responsible for capturing the project requirements (see Chapter 5). As an interaction designer, if you're working on a project with a high level of new functionality, you probably have a separate person on your team in charge of defining the detailed requirements (for example, a business analyst or product manager). The process of collecting and detailing functional requirements can be greatly aided by the skills of a UX designer, and documents like functional specifications and use cases are influenced by experience design. Be sure to sit down with the person responsible for collecting the requirements to discuss the best way to work together.
User Researcher A user researcher is responsible for providing information about end-user needs based on information generated or validated through research that person conducts with users. There are many types of activities that can fall into the user search category, and they can occur at different points in the project timeline. (See Chapter 6 for a description of common techniques, such as user interviews, surveys, and usability testing.)
CHOOSE YOUR HATS
23
Understanding Expectations A client company's desire for user research can vary greatly depending on the importance placed on it by the project team or project sponsor. The fact that you talk to a project sponsor about UX design before a project begins shows that someone on the client team knows that making sure user needs are represented is a priority. But, as those who have worked on computer-based projects know, the introduction of search can also create fear among project team members, caused by concerns that user search will create a bottleneck, increase the risk (and if we run into something wrong and do Are major changes needed to solve the problem?), or disprove the value of a specific idea that has gained a lot of popularity. Expectations for user research can vary between business stakeholders and the project team, so be sure to clarify the expectations for the role with both groups. The client should also expect the user researcher to provide information based on site analytics: tools and reports that communicate usage patterns on the site, such as frequently visited pages and common points where users leave the site. Some of the most widely used analytics tools are from Google (www.google.com/analytics), WebTrends (www.webtrends.com) and Omniture (www.omniture.com/en/products/web_analytics). You might see yourself taking on all three roles: information architect, interaction designer, and user researcher. Can you balance all three or will you bite off more than you can chew? This depends in part on the size and schedule of the project, but the type of project also affects the extent to which each role is likely to be involved. Table 2.1 outlines how UX designer roles can vary by project type.
Navigation Do you need to become a champion of UX design? These articles offer insights that can help: "User Experience as a Corporate Imperative" by Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Evangelizing User Experience Design on Ten Dollars a Day" by Louis Rosenfeld: http:/ // louisrosenfeld.com/home/bloug_archive/000131.html
24
CHAPTER 2: THE PROJECT ECOSYSTEM
TABLA 2.1
Common UX Design Role Responsibilities
information architect
BRAND PRESENCE
MARKETING CAMPAIGN
SOURCE OF CONTENT
TASK-ORIENTED APPLICATION
Medium commitment.
Low commitment for smaller sites (such as a single landing page). Medium commitment when working with larger microsites.
Very high involvement. Content resources require an information architecture with the right balance of structure and flexibility to provide users with a solid foundation to build on and allow for planned growth.
Medium to high engagement, primarily focused on creating the navigation structure, unless there are larger areas of content that need to be referenced during some workflows.
Low participation for smaller sites, medium to high participation for larger microsites or advergames (sponsored online games designed to generate fun and excitement).
Medium to high participation.
Very high involvement. This type of project generally requires the most heavy lifting, as interaction design outputs (such as user workflows and schematics) are critical to visually communicating requirements.
Due to the often temporary nature of the campaigns, user engagement is often low. More permanent solutions may use site-like brand presence surveys. It's also common to use analytics tools to present two or more variations of a given page to see which converts the most. This is called A/B testing.
Field research, like contextual research, can help employees understand how different users currently work with information.
The greater the content challenge, the more the project becomes a source of content.
interaction design
Medium commitment. The higher the number of tasks, the more the project will resemble a task-based application.
The participation of user researchers varies according to budget and access to users. Here you will find general techniques for each type of project. See Chapter 6 for more information on each of these techniques.
Research efforts can focus on understanding the needs of priority user groups (through surveys or interviews) or design research that tests the effectiveness of a specific visual design in conveying the right brand message.
Search, tagging, and filtering capabilities cross the line 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 and common mental patterns and models.
Field research, like contextual research, can be done to understand tasks as users complete them. However, the most used and best understood technique to involve users in the design of a task-based application is usability testing.
Once a framework is defined, usability testing can validate the framework.
CHOOSE YOUR HATS
25
Other roles you may have or need Various roles do not typically fall under 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 fulfills the role. role and you have skills to bring to the table. Some of the most common overlapping roles include: Brand Strategist/Manager Business Analyst Content Strategist Copywriter Visual Designer Front End Developer
The following sections discuss each of these features in more detail and discuss how they can vary depending on the type of site being built. Brand Strategist and Brand Steward A brand strategist is responsible for building relationships with key markets through the definition and consistent representation of the company's brand elements, which can include anything from brand values (such as "ability to response") to texts and messages. guidelines according to the specifications for treatments of logos, colors and design. This role often includes creating or running brand guidelines and understanding how they apply to different projects. It can also be about knowing or defining the key audiences in the project you are working on. Most of the time, you're likely to work with a brand strategist, but don't take responsibility yourself. The Brand Steward does not necessarily set the guidelines, but is responsible for ensuring that they are followed correctly throughout the project. This responsibility can be assigned to the UX designer or the visual designer of a project. If the company's brand attributes, values and guidelines are already well defined and the site is expected to follow them, your role as project brand manager will primarily be to ensure that the outcome is in line with these guidelines. Your point of contact outside of the project is probably one
26
CHAPTER 2: THE PROJECT ECOSYSTEM
a member of the marketing department who is available for consultation or review, but who is not employed full-time. The brand manager role can be more active if the purpose of the site is to promote the brand in some way, for example by targeting a new market. It is more complicated when creating a completely new brand presence or when the company drastically changes its brand, effectively repositioning itself. For example, CellularOne was completely rebranded as Cingular, a big effort for an established company. In this situation, it is necessary to have a lot of experience in branding or have a clear and close relationship with the person in the company that does it. Key questions to help you understand the expectations of a brand-related role are: Are there brand guidelines already in place? If so, to what extent are they needed for this project? Who is responsible for defining or maintaining brand messages,
What does the content look and feel like (like casual or professional)? New target groups that are not covered by previous target groups will be addressed
brand definitions? If so, who is responsible for ensuring that the brand guidelines remain appropriate for these audiences? Will naming or name change activities take place? If so, what should you plan to be like?
concerned? (An example is coming up with a name for a new tool that will be heavily promoted.) For projects that do not have a major potential impact on client brand perception, such as developing an internal app, the involvement of a brand manager can be as light as possible, an occasional check-in to ensure that the brand is well represented. Business Analyst A business analyst (also known as a business systems analyst in IT projects) is responsible for identifying key business stakeholders, executing the requirements gathering process (see Chapter 5), and serving as liaison between business stakeholders and the technology team. He is also the primary owner of detailed requirements documentation such as functional specifications and use cases as needed.
CHOOSE YOUR HATS
27
The Business Analyst or Product Manager role may not exist in your project, or it may be one of the most important roles during the design process. Task-based apps and content sources often have these kinds of features; branding projects and marketing campaigns may not. A task-based application is more likely to need this feature. The more resources and the greater the complexity of the project, the greater the need for a dedicated person and documentation of functionality. While a business analyst is not typically considered a UX team member, small UX teams are often asked to fill the role, so it's important to understand where those responsibilities lie. Business analysts drive the capture of business requirements and serve as a liaison between the technology team and key business stakeholders. If there is a business analyst working on a project, that person and the interaction designer often work together. If it's the same role, the executive may have a lot of documentation to keep! To understand the expectations in this area, ask who is responsible for defining the scope of the project, facilitating the discussion of the requirements, and documenting the requirements throughout the project. For small projects or projects that don't have a lot of functionality, the project manager will sometimes take over these responsibilities. Either way, if it's not you, you still know who to stay with to make sure your deliveries are in sync. Content Strategist A Content Strategist is responsible for understanding business and user requirements for content across multiple media (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating workflow and content development. new content. Substantive efforts are often underestimated. A client may have a lot of great content in one medium (like print brochures or videos), but that content may not be a good fit for the project she's working on. Additionally, there are sometimes unspoken expectations that people within the client organization will generate content—expectations that may surprise these people when it comes time to populate your product with descriptions, news, and help topics! If high-quality content is a
28
CHAPTER 2: THE PROJECT ECOSYSTEM
As the main business driver for your project, make sure you know who is responsible for the following: Defining the content guidelines for the new product (content type,
tone, amount). Assess the adequacy of existing content against that
guidelines. Development of new content. This varies with the general type of project. For
Task-based applications can contain instructional texts, error messages, and help topics. For content sources, these can be articles, news, and blog posts. Serve as liaison between stakeholders and technical staff to
Limitations and possibilities of the content management system. Define different types of content, as well as the metadata for each (the
information that ultimately makes searching and cross referencing more effective). Content migration planning, where templates are created
for different types of content and make sure the content is properly tagged and uploaded when it is moved to the site's content management system. (This is another area where the effort required is often underestimated.) Copywriter A copywriter is responsible for writing the copy on the site that frames the overall experience. In some cases, this instance remains virtually unchanged overnight. It usually includes site and page introductions or on-page instructions. A copywriter may also be involved in the constant creation of dynamic content, such as news or copy for marketing campaigns. Copywriting is one of those gray areas that a UX designer often faces, especially when creating wireframes (see Chapter 11). Initially, you might include some sample text to serve as placeholder copy, such as a site description or on-page instructions, but eventually someone will need to fill it in with the final text users will see, and because many projects Don't If you don't have a dedicated copywriter, this job may be standard for you. You are less likely to be asked to take on a copywriting role for high-profile sections of branded websites or marketing campaigns; in this situations
CHOOSE YOUR HATS
29
each word can be examined. But if you're working on a task-based app that needs brief instructional messages, error messages, or other information that doesn't necessarily fall into a clear content container, you can inherit that write task (or, by default, The Developer ). Ask ahead of time if a copywriter is available, and ask again in plotting if you haven't found one. If the task falls to you, be sure to account for that effort in planning your activities during the project. And be warned: this is a responsibility that is often overlooked or overlooked. Visual designer A visual designer is responsible for the elements of the site or application that the user sees. This effort includes designing a look that creates an emotional connection with the wearer in accordance with brand guidelines. For example, a bank's website should generally look stable, reliable, and accessible. Visual design can provide this guarantee through visual elements such as colors and images. This promise is fulfilled (or broken) by the interaction design of the website and other points of contact with the company (such as a 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 emotive visual design and just trying. Sometimes survivability is enough to achieve project goals, and sometimes it leads to frustrations and project delays when the project sponsor is dissatisfied or early adopters aren't involved in the design. On the other hand, it can also be easy to focus too much on creating impact with the visual design, which affects the usability of the design. If you're asked to take on this role and you're not sure if you have the ability to create the right customer impact, take a look at the company's current website and any sites or products that customers visually admire. to identify your comfort level. Visual designers often play a very central role in brand awareness projects and marketing campaigns, being primarily responsible for effectively communicating the company's brand.
30
CHAPTER 2: THE PROJECT ECOSYSTEM
For content source projects, they can focus on creating content templates that can be applied to multiple pages (for example, an article template). For task-based applications, they can provide a style guide that can be applied to common interaction elements such as navigation areas and tools (which require a high degree of collaboration with the interaction designer). Front-end developer A front-end developer is responsible for building the technical framework behind page layouts and flows, as well as interactive elements within the site, such as dropdown menus, expandable content areas, interactions with multimedia elements such as video. This work often uses technologies such as XHTML, CSS, Flash, JavaScript, Ajax, and Silverlight. Front-end development focuses on the elements of the site that are directly related to what the user sees, as opposed to the back-end systems that provide the underlying platform (such as databases, content management systems, and code). . behind complex features). If you or members of your team are assuming the role of front-end developer, it's important to work closely with the rest of the development team to understand the expectations and responsibilities. Other important issues include which back-end systems to integrate, the method used to generate HTML, the need for flexibility in the page structure to accommodate custom "skins," and the expectations around technologies like Flash. If a prototype is planned (see Chapter 12), ask who is responsible for developing the prototype and what level of functionality is expected. A prototype meant to simply communicate capabilities can be built quickly in an application like Flash, but a fully functional prototype that needs to extract actual data (for example, the account information a user just entered into a form) must be done. close up. collaboration with members of the back-end development team. Worried about taking on all of these roles? Unless you're working on a very small project, or in a very small company, you probably won't take them all on yourself. The key is to understand what roles you can and want to play, if necessary, for the specific project you're working on. If not, you can get the support you need from the project team by building a network within the client's company or recommending others to meet the needs. Let's take a moment to talk about ways to do this.
CHOOSE YOUR HATS
31
Building a user advocacy network For those areas you're not sure you can or want to address, it's time to get help. There are three main ways to do this: Recommend that additional team members be added as needed
quite clear. Develop yourself in key areas where gaps exist, be it the new responsibility
The skills are manageable and you have time to dedicate to them. Create a support network within the company to help you at critical moments.
Let's take a look at how to build a support network. There are likely some key resources in other departments of the company that can help you succeed. You'll need to estimate how much time you can count on these people, because requesting time from outsiders can be difficult for projects that are primarily within one department. If you don't want to ask for too much time out of the gate, ask if you can work with them (or consult with them) to ensure the best outcome for the key responsibilities of this role. Once you've gotten a little associated, you'll have a better understanding of how much interaction you need, and whether you need to make a more formal request for your time. Every company has a different structure and different names for their departments, but here are some common places to look for partners: For the brand strategist role, ask if anyone is in marketing.
department that can serve as your point of contact. This can also be a resource for visual designers and content strategists. Visual design and content strategy partners can also be found at
program or product management or in research and development, operations, or corporate strategy, where you can often find business analysts and product managers. IT or engineering department is usually the best choice for the front-end
developers and others who can help you access and learn about website analytics tools.
32
CHAPTER 2: THE PROJECT ECOSYSTEM
If you've recently been hired by a new company and expect to work across multiple departments, one of the best things you can do is identify the key people you can work with and schedule a few interviews with them to understand their roles and experience. He starts with a network he can rely on for a long time, and gives you the opportunity to explain his responsibilities (and user experience 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 primary project manager or customer contact. If you've been at a company for a while, you can still start a talk show like this. In this situation, it's best to tie it to a specific milestone (like the start of a new project) or a business goal that has some urgency to ensure high engagement. Make sure your manager knows what he is doing to avoid overlooking it. Good communication is key to understanding role expectations and building trust. Another key to gaining trust within the company is understanding the culture, the often unspoken expectations for how a company operates, created through previous project experiences (both positive and negative), etiquette around the organizational hierarchy, and acceptable work logistics. working from home).
Understanding Company Culture Culture is a bit like dropping Alka-Seltzer into a glass: You don't see it, but somehow it does something. —Hans Magnus Enzensberger
A company's culture may not be consistent across regions, business units, or departments, but you can typically identify the key characteristics that affect you and the project(s) you undertake. The following are some points to keep in mind when exploring projects and navigating potentially sticky political situations.
UNDERSTAND THE BUSINESS CULTURE
33
History We all know the saying that those who can't remember the past are doomed to repeat it, and project work is no exception. Understanding how a project or team got to its current state of emergency can help you understand the challenges you may face during the project. Let's discuss some questions you can ask to understand the background that can affect a project. While some of the answers to these questions may seem dire, keep in mind that something motivated you to get involved, so a project can have a troubled history and still be successful. You can be an important part of that success! However, if many of the issues discussed below seem to apply and you feel like you can't help fix them, this could be a red flag. If so, consider a general evaluation of whether this project is in a good position. What is an example of a previous project that appears to have been considered?
past, and what does it seem to have done? What is a previous project that seems to have been a failure (or particularly painful) and why did it fail? Asking these questions (either directly or in a more subtle and conversational way) can help you understand a few things: how the person responding defines success, the potential risks to your project, and any preconceived notions or expectations that will be placed on this project. . brought. and approaches that worked well. The company has already worked with him and released a designer
project or team? If so, try to find out what doesn't seem to work and how the customer expects your approach to be different. Being able to ask this question of more than one person in the company will help you understand unspoken expectations. If you get two very different answers, it may mean that the designer's responsibilities are not well defined and you need to ensure that the designer's responsibilities are properly communicated throughout the project. The project team is working on the project (or related materials)
for what seems like an extraordinarily long time unfinished?
34
CHAPTER 2: THE PROJECT ECOSYSTEM
If so, it could be a sign that key customer stakeholders aren't on the same page or engaged at the right times, leading to multiple outages, redirections, or wasted time across multiple iterations. It can also mean that there is no clear leader, someone who can say no (or at least prioritize effectively) to stay focused on business goals. If you are in a position to influence project communications, it may be helpful to create engagement guidelines to help move the project forward. The company created projects without the prior participation of
a UX designer? This can be a mixed blessing. On the one hand, you're dealing with a team that understands the need for the design and tries to fill the void. On the other hand, you may receive a design that you feel doesn't meet your user experience design goals. This can be a difficult situation to navigate. Often, it's best to approach the creator of these designs in the tone of a respectful mentor or helpful advisor, first noting the positive aspects of the design and then discussing the user experience goals and how they can best be achieved with a different approach. . The creator is likely to be a valued member of your support network, so it's important not to burn the bridge here, but to redefine your roles together to keep the enthusiasm alive. The main sponsor or project manager seems particularly eager
About the project? There are many reasons why this can happen, especially if any of the above factors are involved. Anxiety can also be due to market pressures and it would be helpful for you to understand this. For example, is the company's stock price falling? Have competitors in particular made alarming progress of late? Is the company in the red? Again, these situations do not necessarily mean that you should not take on the project; after all, they are the kind of situations where a project is often funded in the first place. But if you're deeply concerned that the company won't be able to pay its bills, you need to weigh that risk.
UNDERSTAND THE BUSINESS CULTURE
35
Hierarchy Geert Hofstede has an excellent model for describing cultural differences, what he calls 'cultural dimensions', which often influence the way people interact and communicate with each other. One is the concept of power distance, the extent to which members of a society (in our case, a company) understand and accept the distance between people with different levels of power. For example, if members of a company's executive team are seen as particularly powerful and potentially unapproachable, a company may have a great deal of power distance and employees may be more focused on the hierarchy. If the company encourages the democratic exchange of ideas and the questioning of the vision, it may have a relatively small power distance.
Power distance is “…the extent to which less powerful members of organizations and institutions (such as the family) accept and expect power to be distributed unequally. This represents inequality (more versus less), but defined from the bottom up, not from the top. It suggests that the level of inequality in a society is supported by both followers and leaders. Geert Hofstede Cultural dimensions www.geert-hofstede.com
Neither extreme can be considered good or bad by itself, although in general in the United States most employees seem to prefer the appearance of a little power distance in their workplace. What is interesting to note is that this is not necessarily indicative of how successful a company is. Apple has a relatively large power distance (if you look at the aura surrounding Steve Jobs), and Google has a relatively small power distance as part of their culture, but both companies are known as thought leaders. What is important to keep in mind is that the distance of power within the client company will affect how successfully you navigate political waters during the project. This aspect will be particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as approval points (discussed in Chapter 4). If you work in a company with a large power distance, take extra precautions.
36
CHAPTER 2: THE PROJECT ECOSYSTEM
Take time to understand reporting relationships before scheduling meetings, such as stakeholder interviews and assessments, and consider involving more people at intermediate levels in your communications.
Logistics In addition to the broader aspects of culture mentioned above, it is also helpful to understand some elements of a more logistical nature so that you can better integrate into current practices or make thoughtful changes. For example, it's helpful to understand the overall expected pace within the company, including any major release dates or timelines that will affect the project (creating a software application on an annual release schedule would likely have a different pace than an annual release schedule). microsite that supports a seasonal program). campaign, for example). Is your team expected to work late to meet impending deadlines? The expectations around working remotely versus working on-site are also good to understand. If a lot of time is expected at the location, plan the trip there and set up resources. If remote work is acceptable (or recommended, which is common when working with global companies), it's important to understand communication methods and tools. For example, is the use of instant messaging applications acceptable? What web conferencing tools are used? Are there methods for engaging international stakeholders that have proven effective in the past? It is also interesting to understand the "paper culture" of a company. Some businesses prefer electronic media for most things, in which case a good projector and a constant Ethernet connection are important. Others are very paper oriented, in which case you need to make sure you bring enough copies to a meeting to make it productive. You can change the culture of the project if you think another way is more effective. But it's nice to know that you're asking people to change so you can make the transition smoothly and possibly understand why a particular approach isn't working the way you hoped.
UNDERSTAND THE BUSINESS CULTURE
37
Putting it all together Now that you've explored the project site, you should have a better understanding of the project ecosystem: the environment in which you'll be working (the company culture), the general type of work everyone will be involved in (such as types of websites you design) and the people you interact with (including their roles and responsibilities). This information is invaluable as you define your role in the project and prepare to get down to business in earnest. If you're working as a freelancer or subcontractor, this forms the basis for writing a proposal related to your work on the project (see the next chapter, which discusses UX proposals). If you work as part of a larger team and are not directly involved in proposal writing, you can bring your new insights to the beginning of the project—your first team meeting. For a basic guide to running a good meeting, see the online chapter "A Brief Guide to Meetings," or if you want to know right away what kinds of questions to ask when you start your project, see Chapter 4, "Project Goals." ". and approach".
38
CHAPTER 2: THE PROJECT ECOSYSTEM
3
Proposals for Consultants and Freelancers A Guide for People in Business Who Also Run Their Own Businesses It can be challenging to manage projects and client expectations, but if you don't have a good contract, you could end up missing every project you take on. Statements of Work are essential to protect your company, and yourself, from financial and legal trouble. After agreeing to and shaking hands with a project, be sure to spend the appropriate amount of time drafting a contract that details the terms of your relationship and the payment schedule for your client. russ unger
39
Proposals There's an old saying that "no good deed goes unpunished" and the same goes for launching a project: high fives and feel-good moments are quickly replaced by "Oh shit! It's time." writing the proposal! The biggest challenge in writing the proposal is writing your first one. It's almost impossible to know where to start if you've never had to do one before, and that's where this chapter should come in handy. Presenting has different flavors which will keep you on your toes when it comes time to create the proposal.Fortunately, all proposals have a common core that can be reused from project to project.(See Chapter 2 for a detailed discussion of types In the history of project work, the situations that have put people in the most uncomfortable situations are those where there was no agreement between the client and the supplier.You may be tempted to skip this step when establishing the first connection with a potential customer and it seems to work. Even if you have a clear understanding of the customer's needs and can articulate them in a way that the customer understands, you're not ready to get started. In fact, this is exactly the point where you need to slow down and breathe. Instead of going straight to the point, take the time to define your professional relationship and how to interact with your new client. Jean Marc Favreau of Peer, Gan & Gisler, LLP in Washington D.C. says: Too often, contractors and their clients think there is an agreement early in their relationship, when in reality the ambiguities are just lies. on hold. While it's nearly impossible to prepare for every possible contingency, a fully written contract is your best defense and the smartest way to ensure you don't end up in a court of law arguing the terms of your relationship later on. The more clearly you define the terms and parameters of your relationship with a client in a written contract, the less likely you are to argue about each party's obligations in the future.
40
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
New projects and new people are exciting. There's often a desire not to "break the deal" by throwing a proposal into the mix, but as with any relationship, the honeymoon feeling can eventually wear off. Promises can be broken on either side of the relationship. A client may not provide you with timely access to content. (I know this is almost unheard of, but believe it or not, it happens! That's sarcasm, in case you missed it.) Funds previously available for the project can be transferred elsewhere, and then you, the one at work, can hold the bag. Businesses also realize that they are at risk when working with third-party vendors, especially if they are very small businesses or independent contractors. Well-written proposals give clients a sense of stability and protection, which can help alleviate many concerns that may arise. A proposal also allows you to define terms that protect both parties in case something changes. If the client doesn't give you timely access to their resources, your timeline may fail; they need to be aware of their obligations for the success of the project. If a client loses money and walks away from the project, and you don't have a proposal or other form of contract, you risk not getting paid for the work you've already completed. The point is clear: always write a proposal.
Creating the Proposal When you have completed the design, it's time to create the proposal. The sooner a proposal is approved and signed off, the sooner you can get started and, more importantly, get paid for your work. The most important parts of a good proposal are: Title page Revision history Project overview Project focus
MAKE THE PROPOSAL
41
Scope of work Deliverables Assumptions Ownership and rights Additional costs and fees Project prices Payment schedule Acknowledgment and approval
Let's take a closer look at each part of the proposal.
Title Page The title page is the only page that presents your document. Title pages are an interesting beast - there are a number of ways to create them from a style and information perspective. How you do this is up to you. A typical title page consists of the following elements: Client company name Client company logo (if you have permission to use it) Project title Document type (proposal) Proposal version Submission date Your company name Authors of the proposal Reference number of the project Costs Confidentiality
For your initial proposal, include everything except the client's company logo, cost, and (possibly) the project reference number. Why not include these elements on the cover?
42
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
Your client knows who he is. It's probably not worth the time and effort to get permission to use the company logo, nor is it worth it if he accidentally misuses it. Cost accounting is best placed after you've identified the various project components in the body, and the cost information leads well to the payment schedule. The project reference number is something to pay attention to. Many companies won't use one; however, some government agencies have been known to rely on this particular article and if it is not on the front page, your proposal may be rejected.
Figure 3.1 Example of cover proposal
In figure 3.1 the (fictitious) logo of the client is used. If consent has not been given or no relationship has been established, it is better not to display the client's company logo.
MAKE THE PROPOSAL
43
Revision history The revision history is a separate section of the proposal and is used to determine how many times you have updated the proposal since its original version. In general, it is best to include the version number, date, author, and any comments about the version, such as what has changed, to give the reader some context for the changes (Table 3.1). TABLE 3.1 REVIEW
Example revision history table SECTION
DESCRIPTION
EDITOR
FACTS
Original document
RECORD
8-ene-09
Ground
Updated to reflect software requirements
RECORD
11-ene-09
1,0 1,1
Occasionally clients sign off on a proposal and then request further revisions. If you choose to continue with the client and make these changes, please take the opportunity to upgrade your document from version 1.x to version 2.0. Essentially, when a client approves a proposal and both parties agree to the terms, you're good to go. Therefore, when additional changes are requested, please review them very carefully. This ensures that your costs remain correct and that there is a clear understanding on both sides of the adjustments and at what stage the project will restart (if necessary). You should also always clearly explain why the revision constitutes a completely new version in the revision history.
Project Overview The Overview section is a description of the project you will be working on, in your own words. This description should give your client a clear understanding of what you think your product entails, as well as an explanation of what to expect in the rest of the proposal. Here's an example of the beginning of a statement: [Client Company Name] is trying to create a new online presence on the web. This web presence allows customers of [Client Company Name] to research and purchase online products, as well as other services and benefits available through the company. The goals of online web presence are…
44
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
You need to be able to provide a solid overview in a few paragraphs, with a high level of detail on what the client can expect from you. It's a good idea to close the overview with a detailed explanation of your recommendations and proposed approach to completing the project: This proposal will incorporate [your company name]'s recommendations and [company name]'s design and development approach. online. web presence. Given the deadline of [deadline], it is suggested that...
Project approach The project approach depends on the type of project you are carrying out. This is your opportunity to identify for your client how you plan to work with them on the project. You define your rules of engagement and set expectations for the work ahead. Many individuals and companies work with very similar methodologies, but use different names or clever acronyms to fit their overall brand. Once upon a time there was a mythological method that was created to show (potential) clients, and that found space in many proposals. The process was called The PURITE Process™ (pronounced "purity"), and as I share this with you, a mythological creature just died a little bit on the inside, so be careful not to read this as fiction. The name of the process is a bit corny and the process is clearly somewhat incomplete. Post-launch analysis has been omitted from this methodology (an oversight), but should of course be included for all clients. This is certainly the focus of PURITE: [your company name] identified a standard process for project success at our clients. While each of these stages may not apply to [Project Title], the entire process is defined as follows: The PURITE Process™ is [Your Company Name]'s internal methodology to ensure the overall success of all initiatives. By using PURITE, [your company name] has a proven set of guidelines for working closely with customers and users/public to reliably maintain and exceed delivery expectations. V - Get ready. We spend part of each initiative understanding your industry and competitors and how they do business, so you can be as informed as possible before you start gathering requirements. You understand. We work closely with your subject matter experts and/or users to define the requirements to successfully build the project.
MAKE THE PROPOSAL
45
R - Render. During the Render phase, we create and develop all parts of the project/product. Our experience is that each stage of development requires a lot of focused and concentrated work effort, as well as timely and open communication with your team(s). It also requires that we… Me – I repeat. The iteration phase is repeated throughout the project life cycle. We work as quickly as possible to bring the project to life, which often requires multiple iterations on rapid deadlines. This requires immediate and timely involvement from you and your dedicated resources. The end result is the product you specified and helped create. Test T. We test each project during our rendering phase; however, we also need an extra pair of eyes, from our own testing team and their designated audience/user group for objective testing. This additional round of testing helps ensure that as few bricks as possible are left untested to deliver a project that has been rigorously tested at multiple levels. E - Activate. Upon successful completion of the previous five phases and your signed approval, we enable the solution and go live. The PURITE™ Process does not stop there. After the completion of the project, we communicate regularly with our clients. We will continue to assess your satisfaction levels, understand changes to your project goals or improvements, and help you determine the best approach for the future development of your project.
You can use as much or as little as is appropriate or helpful to you. The mythological author who created the process also doesn't care if you don't credit the source. Your process definition can be as detailed as above or as simple as the following: Plan, Define, Develop, Expand Plan the overall strategy Define detailed project requirements Develop, test, refine, and release the work product Expand the project recommending enhancements and enhancements based on feedback gained during development, testing, and post-release
Once you've defined your process, you'll have an opportunity to detail the different efforts that will go into each stage of your approach, as well as what each of those efforts means to you and your client. The focus portion of your proposal varies in length depending on the project, your process, and the activities that take place at each step of your process. Try to keep it to a maximum of two or three pages, and
46
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
be sure to only include results that you can deliver to your client, to avoid future project document updates or price revisions.
Scope of Work In the Scope of Work section, identify the division of work for the project. That is, you identify which parts of the project are your responsibility and which are the responsibility of the client. Read it again. Think about it for a second. Let it sink in Here we go. That's how it is. This is the part of the proposal where you tell the client in writing: we are going to do this and you are going to do that. If the client then signs your proposal, you agree to this agreement and have a paper record to back you up in case of misunderstandings. The intent here is to clearly identify who will cover what aspects of the project, as well as what aspects of the project are included in your proposal and for the price you have estimated. If you can't find another really compelling reason to write a proposal, that should be reason enough. Here is a very brief example of a scope of work: [Client Company Name] approached us to provide all the services needed to build [Project Type]. [Your Company Name] focuses exclusively on the [User Experience Design Aspects] of the [Client Company Name] website. [Client Company Name] will provide detailed feedback on all aspects of the [project type] in accordance with the project plan. [Client Company Name] provides all necessary resources for use in the project, including fonts, color schemes, branding standards, etc.
Assumptions The Assumptions section of the proposal is a good place to explain, without leaving room for discussion, what is required of your client to ensure success. That is to say, they are the things that you assume -and communicate to the client- that you access or deliver to make the project a success.
MAKE THE PROPOSAL
47
What you call assumptions in this section are actually expectations. It is much more polite to assume. You can create as many project plans as you like, but if neither you nor the client commit to meeting milestones and objectives, both parties agree to let the project fail. Typically, the assumptions are an expectation of resources and assets, as well as timely access (translation: ready, immediate) to both. Here is an example of writing Assumptions: Assumptions [customer company name] must provide the following assets and resources. Failure to provide these assets and resources in a timely and complete manner may contribute to the failure or delay in delivery of this project. The following assets and capabilities are expected: Timely access to all required employees of [Client Company Name]. Timely access to all required [project] resources in their current state, including resource files, if available. Content, if required and includes, but is not limited to, copy, images, audio, etc. for any aspect of the [Project].
Deliverables Deliverables are the work product that you create and deliver to the customer. This section is your opportunity to find out for the client what kind of work product they can expect from you during the project. It is recommended to treat the status reports separately, closer to the end of the project, but feel free to add them to this part of the project. Provide descriptions of each work product that you include, even if the work product has not been produced. This may seem like overkill or has the potential to open up the "I read about [delivery type] in the proposal, but I don't see it here" can of worms, but one little word, can, can make all the difference. Deliverables [Your company name] offers a variety of deliverables throughout a project. For [Client company name] we have identified the following products:
48
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
Creative Brief The Creative Brief is the first phase of the project. This document helps us create a fast, effective and high-level project overview. The purpose of the creative brief is to clarify the goals and needs of the users and to define any special features and/or limitations related to the project. Etc…
Ownership and Rights It is important to consider the extent to which you allow your client to use the work product you produce. These rights can be defined in different ways, but most of your work falls into two categories: Hired Work Licensed Work
Projects of work for hire (known in the legal world as "work made for hire") are considered created and copyrighted by the party paying for the work, not the party responsible for the actual work. This means that when you do work on a contracted project, you have absolutely no rights to the work and anything you believe to be related to the project belongs to the client. This situation is difficult for many companies and individuals: it often means there is no "maintenance" work afterwards (with additional income), as clients can decide to keep the project only after it is complete. Don't be tempted by a project where a client enforces the stipulation; It's not uncommon. When you subcontract work on contract projects as part of a full-time job with a company, it's pretty standard for an employer-employee relationship. It's also an opportunity to check out their pricing model: many projects pay a slightly higher fee to offset potential lost revenue down the road. Remember that this all depends on the relationship you have with your customer and how you choose to do business. Time and experience will help you make the right decision for the type of work you do and the pricing models you choose. With Licensed Work Designs, you retain the copyright in the work, but grant other parties the right to copy and/or distribute it. You can include any number of terms in the license agreement. Most likely you BELIEVE THE PROPOSAL
49
Take advantage of licensing your work when you retain ownership of all source materials for your work and only provide limited-use work products to your clients (such as PDFs rather than editable Word, Visio, Axure, OmniGraffle, or other documents). ). You can take a number of different approaches to licensing your work, including licenses to use the work unmodified, non-commercial, or in other ways that are appropriate for your situation. Creative Commons (http://creativecommons.org/about/licenses) provides easy-to-understand explanations of the different types of licenses you can use, but this is only a small part of the licensing world. If you are in a situation where you are faced with very detailed and specific needs, it is always best to contact a copyright attorney to help you find the best possible solution.
Additional Costs and Fees It is important that your client understands whether or not the price of the project you are offering takes external resources into account. For example, some projects require you to purchase images from a vendor. You can purchase the images (with the appropriate usage rights) and include them as part of your rate, or you can clearly state the purchase of the image as an additional cost to be passed on to your customer. You can also offer services that you want your customer to know about – this is a good opportunity to promote these services. Here's an example of how to deal with additional costs and fees: Additional Costs and Fees If external resources (such as content, images, fonts, etc.) are required, they must be identified, approved, and billed to [Client's Company Name] . Additionally, [your company name] is able to provide hosting services to our customers at very low overhead costs. We offer hosting services, including configurable web-based email, starting at $25 per month, with a $25 setup fee. [Your company name] will work to create a package that is mutually acceptable and beneficial mutually.
50
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
Project Pricing After you have documented the details of how you will perform the work on the project, it is a good idea to communicate the cost to the client. A lot depends on how you arrive at the price, but here's a tip: Work out how long you think the project will take to get done, including a specific number of reviews, figure out a reasonable project management time, which might be around 25 percent. ; then determine the billable hourly rate you want to charge and figure it all out. There are several formulas to help you with this, such as applying difficulty levels to each part of the project to help you define a range of costs to provide your client. In most cases, experience will be key in helping you properly estimate your projects, from a time and material perspective. How do you determine your billing rate? Research what others are charging to compare by looking at contractor salary surveys and rates. For example, organizations such as the Institute for Information Architecture (www.iainstitute.org), AIGA (www.aiga.com), Coroflot (www.coroflot.com) and the talent agency Aquent (www.aquent.com) conduct contractor rate surveys. You can get a good idea of what you can charge by considering your experience, what others in your market are charging, and what you think is fair. Note: you can always lower your rate. It's much harder to ask your client to pay more money after seeing the numbers on a page! There are many different ways to structure the price of your project. Depending on the nature of your project, you may want or need to provide multiple estimates that allow for different pricing options. For example, suppose you offer a customer two options: a static HTML website and a website with a content management system (CMS) that enables dynamic content (which the customer could manage without any special resources). How to Formulate Project Estimates: Project Estimate [your company name] has suggested several estimates for [client's company name] to provide the best possible options for your immediate and/or future needs. [Your Company Name] assumes that all content is provided by [Client Company Name]. If [your company name] is asked to provide content services, estimates must be reset.
MAKE THE PROPOSAL
51
Estimates for [your company name] provide flexibility from a cost and needs perspective. The estimates are as follows: Estimate 1 [your company name] estimates that [project] for [client's company name], without any interactive content...
Remember, there's really no wrong way to put together your project estimate, unless you put yourself in a negative cash flow position!
Salary Schedule There is a myth that all freelance projects are paid 50% upfront, before the job starts, and 50% on completion, when the project is finished. This myth must be dispelled, right now! That's no way to do business, and it's no way to ensure consistent and timely income while you're at work. You don't want to put yourself in a position where you have to make change after change for a client simply because you want to complete the project and get paid, rather than go through a job change process. You can price projects in a number of ways, from invoices sent during a predetermined time period to payments based on milestones. A more sensible approach is to move your projects to a recurring payment schedule with regular, itemized invoices. This approach should also give clients a clear understanding of what has been accomplished and the work that remains to be done on the project. The following example is one way to structure payments for your work: Payment Schedule [Your Company Name] The typical payment schedule is to receive an advance payment of XX% of the estimated total project price before the project begins. [your company name] invoices on the 1st and 15th of each month; Payment must be made in full within 14 days. Upon completion of the project, [your company name] will deliver all work products to [customer company name]. Upon satisfactory approval of the materials, [Your Company Name] will refund the remaining overpayment on the advance or [Your Company Name] will send you a final invoice for amounts not covered by the advance. Note: If [Project] is suspended for a period of more than 14 days with no work progress, [your company name] will be required to submit a final invoice for any fees not covered by the advance and will be entitled to first refusal. if the project will be reopened.
52
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
While not required, it's helpful to add a note about how the project will be handled if it's put on hold for an extended period. This layout can help keep your project on track and moving forward, and provides a talking point with your clients. If you're not going to be doing extra work for them for a long time, you'll want to be able to move on and find work to fill the void.
Acknowledgment and Approval While making sure you have a proposal is very important, it alone is not enough. The proposal doesn't really mean much until the right person at your client company has approved and signed it off. It is essential to ensure that everyone has a clear understanding of what is to come and how much is expected from each side. It is equally important that you be wary of the "iteration highway" and reduce the risk of a client leading you to "feature redirection" - constantly asking to include "just one more thing". Approvals are pretty simple and straightforward. After creating the proposal document, you provide your client with an acknowledgment and a signature approving the contract between your two companies. Always prepare two copies, one for each party, and make sure both copies are signed. Here is an example of a confirmation you can use: Confirmation This proposal has been confirmed and accepted in its entirety by [customer name]. This proposal must be signed and dated by an authorized representative of [Client's Company Name] to be effective. Alternatively, a signed purchase order referencing this proposal shall constitute an acceptance in lieu of this signed document (provided, however, that the terms preprinted on such purchase order are deemed null and void). This proposal constitutes the entire agreement between the parties with respect to the subject matter of this proposal. This proposal combines and supersedes all prior oral or written agreements, discussions, negotiations, commitments, writings or understandings. This includes, without limitation, any statements in sales literature, brochures, or other descriptive or advertising written material and is the complete and exclusive statement of the terms of the parties' contract. Each party acknowledges and agrees that it has not relied on the performance of this Proposal and expressly disclaims any reliance on any representation or statement not contained herein or the Agreement.
MAKE THE PROPOSAL
53
Accepted by authorized representatives of: [your company name]
[Client company name]
Puerta: ________________________________
Puerta: ________________________________
Name: _____________________________
Name:_____________________________
Title: _____________________________
Title: _____________________________
Facts: ______________________________
Facts: ______________________________
Please make all checks payable to: [your company name]
Statements of Work A Statement of Work (SOW) is a high-level definition of project goals that you should be able to assemble into a two to three page document (not including the cover page). The SOW is usually written before going into the detailed requirements, although depending on the needs of the client and the project, you may choose to create a hybrid document that best suits your needs. In general, SOWs should be used to build consensus early on between your team and your client's stakeholders. The SOW defines the inputs and outputs of the project, as well as its assumptions and constraints. At this point, it's not uncommon for clients to ask you to provide a "rough picture" of the work you'll be doing for them. It may be a bit risky to answer at this point. It is recommended that you do your best to avoid specifications or compromises without defining the details. It's simply not possible to know how much a project will cost if you haven't already written the proposal and/or requirements document. That being said, it is necessary for me to make a judgment on this point. If you're working on a project, such as a basic website, and you've previously successfully completed several similar projects and/or previously worked with the same client, you have some leeway. Remember that being careful is always better than an awkward situation later in the project. A job summary should be approximately two to three pages long and contain at least the following:
54
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND INDIVIDUALS
Front Page Revision History Project Reference Number Project Summary Start Date Completion Date Fee/Price Explanation of Project Activities and Outputs Specified Costs and Payment Schedule Acknowledgment and Approval
Do the elements look familiar? They have to -- you can compile a SOW with an abbreviated version of the proposal. You have now learned how to collect two types of documentation that identify the work you perform for a client. These documents should form the basis of any design work you do for a client and will provide you and your clients with a well-defined set of roadmaps for your projects.
STATEMENTS OF WORK
55
4
Project Goals and Focus Knowing Which Star to Sail One of the keys to a good project is starting the team with clear goals and a well-understood focus. Ideally, project management will have this ready for you, but how do you know if they don't? This chapter is about formulating project goals and contains a series of questions that will help you solidify those goals. We'll also discuss some common design approaches (or methodologies) and how they might affect the way you work. carolina chandler
67
Y
You start the project, for the first time with the whole team. The project leader hands out material and gives an overview of the project. Ideally, at the end of the meeting, he should have the following information:
Why is the project important to the company? How will stakeholders determine if the project was a success? What approach or methodology will the project follow? What are important dates or milestones for important points, how to get there
approval from business stakeholders? All of these questions relate to stakeholder expectations of the project: what the project will achieve and how they will be involved. The first two questions are related to the objectives of the project and the last two to the focus of the project. A project objective is a statement of a measurable goal for the project. Let's discuss the goals in more detail.
Reinforce Project Objectives Objectives are an important focusing lens that you will use throughout the project. They must be derived from the overall business strategy of the client company, so the project goals must align with the company's strategic initiatives. For example, if there is a strategic initiative to attract a new group of potential customers (called a market), the website or app you create could be an attempt to provide that market with online access to products and services relevant to them. The objective of this project would then be aimed at reaching and involving this market. A clear purpose resonates throughout the project. Helps you ask the right questions by gathering insights from business stakeholders. Schedule user surveys and focus your analysis on the results.
on a consolidated list of project requirements Prioritize project requirements based on their value to the business
CONSOLIDATE THE OBJECTIVES OF THE PROJECT
57
Create effective interaction designs Manage design change requests as soon as development begins Focus efforts during implementation activities (such as training and education)
communication to users about the new site or application before and during the launch) Determine if you have satisfied the needs of the client company once
project is launched When you start a new project, you probably have the project goals of the project sponsor (the business stakeholder who has direct responsibility for the success of the project), as well as a number of project-related requests from stakeholders. industry and customers, but they can all be a bit confusing (Figure 4.1). Your goal is to clarify these into strong statements that you can use as a measure of project success.
Project related requests
Fuzzy objective of the company strategy
Stakeholders idea of user need
vague goal
Idea of stakeholders in user complaints
Figure 4.1 Confused goals, ideas, and needs
A solid goal is easy to understand. Avoid internal terminology. Different. Avoid vague statements; instead, use words that sound like
it will be helpful when prioritizing requirements. Measurable. Make concrete statements that you can define independently
measure to determine your success. If you define a vague objective, make it clear and measurable, it becomes a solid objective on which to base decisions.
58
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
Figure 4.2 The objectives are realized
Objectives of the company strategy project
You will hear many statements that can be considered factual. Seeing job opportunities like the following will help you solidify your goals and communicate more effectively within the project team. corporate lawyer
B
“Our goal is to become the market leader in industry x.”
This is a company-wide goal, but too broad for a specific project. Different business initiatives need to come together for this to happen; Any website or app can help with this, but it is highly unlikely that it will be able to handle the entire load, unless the entire company cares about that website or app and it proves to be highly successful. corporate lawyer
B
"Our goal is to generate excitement among our customer base."
This one is better because a website or app can influence it, but it's still pretty vague. Why is it important to generate enthusiasm? How does that enthusiasm translate into meeting a business need? And how do you know if you have been successful? corporate lawyer
B
“Our goal is to attract more visitors to our website.”
Now we get there. This is easy to measure, but too focused on an intermediate step. Let's just say it drives more traffic: it may not help if people don't take the actions they want when they get there.
CONSOLIDATE THE OBJECTIVES OF THE PROJECT
59
Vague goals can give you an idea of a client's larger desires and goals. From this, you can create stronger project goals, such as increasing online sales revenue by 10%. Increase online advertising revenue by 20%. Increase the number of current and potential customers in our client
database to at least 20,000. Provide highly rated and highly regarded content to our core users.
(Note that this one requires some work to decide how to measure "highly liked" and "highly referenced", but the elements are there to build on.)
Each of these can be measured and influenced by your project. They can also accurately map your designs and the features offered. For example, it is very common to offer an online newsletter as a way to achieve the goal of growing a customer database: to deliver the newsletter, customers' email addresses must be captured, which are added to the database. Goals can also bring new requirements. For example, if you measure success by the average rating given to articles on your site, you need a feature that allows users to assign ratings. In this way, objectives help you focus as you gather ideas for the site, and they can become project requirements later. If there are multiple goals, be sure to create a priority list with your corporate sponsor and project team. Sometimes the objectives conflict during the project and the team needs to know which one takes precedence. The final list of priority goals should come from the project sponsor, but you can be an important part of the discussion. Let's talk about how.
How can a UX designer help? If you find that the project objectives are not clear at the beginning of a project, you can use your facilitation skills. Help the project team understand the business context of the project by organizing a key stakeholder workshop (see the next chapter for more information on how to identify the right stakeholders). Your goal in this session, which typically lasts two to four hours, is to gain insight into strengths and weaknesses,
60
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
opportunities and threats. This is called a SWOT analysis and is a common business analysis technique and a way of analyzing a company's position in the market. You can also use this time to discuss the company's competition. Understanding Strengths and Weaknesses The SW in a SWOT analysis is the company's current strengths and weaknesses 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 (a strength), but there may be no one there to make that content more accessible. for the average user. to the perception that the company is "too academic" (a weakness). Identifying OT opportunities and threats is the forward-looking half of SWOT. Given the things that set the company apart from its competitors, what future initiatives could you take to create a new niche or strengthen an existing one? What situations could threaten these plans? For example, our R&D company may decide to hire writers to publish more accessible articles about their original research (an opportunity), but if the current site's toolset lacks robust content management features, the publishing process may be extremely difficult. This allows competitors to react faster (threat). Compare Competitors Who is the company's main competitor? Who are the competitors of the website being developed? They can be different, especially for large companies or new websites. Are there sites that are not direct competitors but represent interesting models to consider? You can learn a lot by looking at other eCommerce sites to see if and how they sell what you sell. SWOT together and discussions with competitors are good topics to discuss at the same time because they interact. it's hard to talk about it
CONSOLIDATE THE OBJECTIVES OF THE PROJECT
61
future threats without knowing who your competitors are, and when you start talking about future opportunities, new competitors may come to mind. Once you have a complete picture of the company's competitors and the SWOT, your project objectives, as well as the overall fit of your project with the company's strategy, should be easier to define and priorities should be clear. . Solidifying the project objectives helps to understand the expectations of what the project will achieve. Next, let's talk about expectations for how the project will go. Understanding the project approach will help you collaborate effectively and involve the right people at the right time.
Understanding the Project Approach Knowing the general approach or methodology of a project is an important part of understanding when and how you will get involved and how to involve others, such as the project team and business stakeholders. Sometimes there seem to be as many design approaches as there are projects. Choosing the right approach to a project is a big topic in itself. The methodology you choose can depend on many things, including the structure and location of the project team, the technologies used in the project, and the degree to which collaboration is part of the corporate culture. For the purposes of this book, we will assume that you have joined a project in which the focus has been largely dictated by those responsible for the success of the project, such as the sponsor and the project manager. In this situation, your primary goal is to understand the approach and help make it effective for business stakeholders and your users. Here we'll focus on two of the most common types of approaches, as well as a third that shows a possible variation you might see in a project. The important thing to keep in mind is that most approaches involve the same steps: planning the overall strategy, approach, and team structure. Define the project requirements. Design interaction and visual concepts and develop them in detail.
Specifications. Develop, test and refine the solution.
62
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
Implement the solution through messaging, training, and a planned deployment. Expand the project making recommendations for improvements.
The names of these steps can vary, as can the extent to which they overlap and the way in which the information is documented. But the general activities in each phase are common to most projects and the three models presented here.
Waterfall Approach In a waterfall approach, the steps of a project are treated as separate and separate phases, with approval of one phase required before the next phase can begin. For example, the design phase only really begins when the requirements have been approved by business stakeholders, who sign one or more requirements documents at the end of the definition phase. Approval
plano
approval
approval
Define Design Develop Implement Expand
Figure 4.3 Example of a waterfall approach, where each stage 'drops' into the next
The problem with a pure waterfall approach is that it assumes that each stage can be completed with minimal changes to the previous stage. Therefore, if you introduce new requirements at the design stage, which is common practice, you must propose changes to the approved documents at the end of the Define stage, which can upset the plan and schedule.
Agile Approaches Because change is constant, project teams are constantly looking for more flexible approaches than the waterfall model. Many methodologies follow a more fluid approach, with some steps occurring side by side; For example, website versions can be released on a rapid, iterative schedule using a flexible or rapid development approach. An agile approach typically focuses more on quick collaboration and less on detailed documentation and formal approval. UNDERSTAND THE PROJECT APPROACH
63
iteration 1
Develop
iteration 2
Develop
iteration 3
Develop
Implement Design Implement Design Define Implement Design
define
define approval
plano
Deploy version extension
Figure 4.4 Example of an agile approach
A true agile approach (following best practices developed by Agile Alliance members, for example) requires small teams whose members are physically close to each other, regardless of formal role definition among team members. Working this way allows for a high level of collaboration, reducing the need for cumbersome documentation between the design, development, and test phases. A team member can ask a question, collaborate with other team members during a quick whiteboard session, and implement a solution without delay for detailed documentation and approval. Stakeholder reviews are conducted with a fully functioning system when one of many iterations is released, and the resulting input is taken into account when planning the next iteration. (Iterations are preview versions of a particular website or app.) When an agile approach works as designed, that's great. However, in most companies and most consulting engagements, teams rarely follow a pure agile approach. In part, this is because businesses are increasingly using distributed teams and remote workers, making it difficult to maintain the high levels of collaboration needed to take full advantage of a pure agile approach.
Modified Approaches Most projects try to take a best-of-both-worlds approach, with enough structure and documentation to mitigate the risks of distributed teams and team member turnover, but with enough collaboration and iteration to respond to changes with relatively quickly. For example, a project might follow a waterfall model but have overlapping phases, so there are key points for team-to-team collaboration. This makes it possible
64
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
possible surface changes at the beginning of each phase. This can also be an early release (such as a beta release for a specific user group) with a shorter iteration cycle. Feedback from this version may be included before the new site is fully implemented. Good
define
develop project
project
define
Develop Deploy Beta
Deploy version extension
Figure 4.5 Modified waterfall with the beta version
Consider the smaller iterations within the design phase in Figure 4-5. This is one of the greatest values that you bring to your team as a UX designer. Tools like wireframes (Chapter 11) and prototypes (Chapter 12) allow you to gather feedback on rapid iterations of ideas before too much development time is spent. A modified waterfall approach like the one in Figure 4-5 is one of the most widely used methodologies, so it is the approach that forms the structure of this book. However, many of the topics covered here will apply to your project regardless of the specifics of your approach, as the basic activities behind them (definition and design, for example) are still required.
Deep Dive If your project uses an agile approach, you will have unique requirements gathering needs, such as writing "user stories" as a way to capture requirements. We recommend User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley Professional, 2004).
UNDERSTAND THE PROJECT APPROACH
Sixty-five
How does focus affect me? Knowing their approach will help you understand several things: what questions to ask and when. For example, if you are
If you are working with a pure waterfall approach, you will need to go the extra mile to ensure that the requirements defined in the Define phase contain all the information needed for the Design phase. (We discuss the requirements in the next chapter.) Expectations about how project team members will work together and how
conclude that cooperation will be. For example, an agile approach requires very close collaboration. A waterfall approach typically involves working one-on-one, with touchdowns one or more times per week. The level of detail required in your documentation and the level of
formality. Documents presented at signing points should be formal, almost like legal contracts. You typically need more formal documents in a waterfall approach, which require approval before moving to the next stage. However, you may also have some formal approval documents when you use an agile approach, for example to capture information at key decision points, such as when preparing a specific iteration for full release and deployment. Key milestones related to stakeholder approval and
performance in different groups. The focus will determine what different audiences need to deliver at different points in the project, including stakeholder approval at approval points and feedback from potential users during a beta release. Now that you've established the project goals and understood the project approach, in the next chapter we'll begin the most important work in the Define phase: gathering the requirements.
66
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
5
Business Requirements Know the problem before you create the solution By the time the project team meets, you've probably heard a lot or had ideas about what needs to be done. There may already be lists of features provided by some of the prominent members of the company (business stakeholders) along with their views on which features are most important. These are elements of the business requirements for the project and are a good starting point. To ensure you have a complete solution at the end of the project, you need to generate and clarify the requirements from multiple angles. In this chapter, we will focus on collecting and detailing the requirements of your business stakeholders. carolina chandler
67
C
Chapter 4 dealt with vague objectives and discussed some ways that you can help clarify them for yourself and the project team. In the early stages of a project, you probably have a relatively confusing set of requests. These may include stakeholder ideas, user complaints, or user requests. To make these components usable and traceable in your project, you need to add these ideas in requirements. Requirements are statements that define what the site or application must do. Ideally, a business requirement Provides insight into the overall need to be met Represents and consolidates the needs of various stakeholders Provides design guidelines without being too specific about what it will look like
performed Serves as a separate unit of work for prioritization and tracking purposes
Here's a sample idea for a feature on an ecommerce site. You may have the same idea early in the Define phase from various business stakeholders: "Customers can track their orders online." This is a good base for a requirement, but it's confusing. Start by asking questions that address the details of the requirement, such as Why is it important to the business that customers have their
online orders? For example, is it to reduce the number of customer service calls? Does the company currently have the ability to track packages online?
If not, new requirements must be set for tracking capabilities or the company may need to work with a third party. How accurate does the tracking need to be? what information
should be included in the monitoring data? For example, should the website provide a current estimate of delivery time? Asking these types of questions helps you fuse vague ideas into solid requirements. It will also make it clear that the same statement can mean different things to different people.
68
SECTION 5: BUSINESS REQUIREMENTS
For example, an interested party might think that tracking a package means receiving a confirmation email with a tracking number, which can then be entered into UPS.com or another website so the customer can see the last destination it arrived at. the package. Idea Another stakeholder may think that the company should innovate in package tracking and invest in building the ability for customers to track packages via GPS, seeing their exact location in real time using an online map. As you can imagine, there is a significant difference in user experience and reach here! It is important to emphasize these differences at the beginning of the project. Otherwise, you end up developing a solution that does not meet the intent of the business stakeholders and possibly the project objectives. This leads to dissatisfied stakeholders and, if the feature needs to be redesigned, wasted time and money. That's why clear and detailed requirements are an important part of your overall project. To arrive at a consolidated list of project requirements, the following steps should be taken: 1. Understand the current state of the site or its competitors. 2. Gather the needs and ideas of business stakeholders and current and potential users. (See Chapter 6 for details on working with users.) 3. Gather the ideas into the requirements. 4. Prioritize the requirements based on the objectives of the project. (See Chapter 9 for prioritization tips.)
Business project and user requirements Business strategy requirements
Figure 5.1 Collect ideas from business stakeholders for business requirements and research user ideas for user requirements. Then use the project goals to prioritize and create a consolidated list of project requirements.
BUSINESS REQUIREMENTS
69
First, let's talk about understanding the current state of your site so that you have context for the ideas that will come up during requirements gathering.
Understanding the Current State When discussing the details of the website or app you're building, it's important to understand the current state of the website (if you're redesigning an existing website or app) or better understand the main competitors (if they're building a new website or app). You can learn a lot about the current state of affairs through stakeholder interviews (more on this in a few pages). You can also gather a lot of information yourself, and this can serve as a solid foundation for stakeholder interviews and user research. A great way to get background information and generate ideas that can become requirements is to do heuristic analysis.
By another name... The word heuristic means rule of thumb or best practice. A heuristic analysis now means an evaluation of a product against a set of rules (heuristics) for a usable design, usually done by a UX designer. Friendly sites follow most or all of the heuristics you use in your analysis. You may also hear this technique for heuristic evaluation, expert judgment, or a combination of these terms.
Heuristic analysis Heuristic analysis is a technique you can use to assess the usability of an existing design based on user experience best practices. You can perform this analysis on your current site at the beginning of a redesign project or look at competitor sites to understand the potential to provide a better user experience than other companies. The result is a document that describes the strengths and weaknesses of the site, including recommendations for improvement. When you're done, you'll have a deeper understanding
70
SECTION 5: BUSINESS REQUIREMENTS
understanding of the site being analyzed and a list of ideas to contribute to the new site requirements. For example, a commonly used heuristic is this, from Jakob Nielsen's list of ten usability heuristics (see the complete list on Jakob Nielsen's website at www.useit.com/papers/heuristic/heuristic_list.html):
Visibility of system status. The system should always keep users informed of what is happening, through adequate feedback within a reasonable time frame.
There are many situations on a website where this heuristic is not followed. Let's say the user clicks a download button and isn't notified that their file is being downloaded. The system has not informed the user that the file is being downloaded, even though the download has started. So the user may click the button again, thinking they missed it the first time... and then click again... This can lead to multiple downloads, which can cause issues for both site performance as for the user, who now has multiple downloads in progress without realizing it. During heuristic analysis, you can view this as a problem area, describe it, and assess its impact. You can also share an idea that might solve the problem, which can be added to the list of requirements. Why perform a theft analysis? Performing this type of analysis is a relatively quick and inexpensive way to get feedback on a design. Heuristic analysis can provide a general understanding of design quality and help identify potential design problems. Please note that this activity is not directly related to end users and should not be a substitute for actual user research. For example, only 50% of your heuristic findings can be validated by further research. However, the analysis gives the team a good understanding of possible points of attention. If you're in the process of redesigning an existing product or website, it can also be good to identify obvious quick fixes that can lead to immediate improvements as redesign efforts continue behind the scenes.
UNDERSTAND THE CURRENT STATE
71
How do I do it? The specific heuristics you use may vary from project to project, but the process for performing the analysis generally remains the same: 1. Gather background knowledge about products and projects. Make sure you have the goals of the site, a list of key user groups that need support, information about the type of environment your users are likely to work in, and a basic understanding of any specialized knowledge your users may have. have. (For example, your analysis will be different for a site designed for general consumers than for a site designed for pharmacists.) If you need help with the latter, visiting several competing sites or apps can help you determine the most common terminology in the areas. of interest . 2. Choose the heuristic to use. Many heuristics are available for reference. 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're familiar with the site's theme, you can add a few of your own, especially if you're reviewing more than one site. Be sure to keep your list manageable (eg 8-12); too many heuristics can complicate the technique for you and your readers. 3. Review the priority areas of the site and identify the areas where the heuristics succeed or fail. Each observation you make should include the following information: The general observation. A brief summary of the conclusion. Ideally, these are numbered so that you can refer to them quickly when you guide people through the report. A short description. One or two paragraphs describing the context of the observation; for example, the point in a specific process where you noticed a problem. An impact score. This rating can be high, medium, or low for issue notes, or it can be a positive discovery score if you share something the site did well. In general, high-impact issues are those that you believe will prevent many users from completing a particular task or task.
72
SECTION 5: BUSINESS REQUIREMENTS
losing information permanently (for example, a problem that causes a user to lose changes to a document they are working on). Medium-impact issues are issues that cause frustration and errors, but do not cause irreversible problems. Low-impact issues are minor issues that may cause some confusion, but generally don't lead to wasted time or frustration. Recommendations These are the next steps or ideas that you share that can serve as a solution to the problem you encountered. Figure 5.2 shows an example of these elements together, as they might appear in your heuristic analysis. Observation #4 The search function does not seem to return all possible results.
Good care
A sample test of the search function produced mixed results. Named searches on a relatively new publication with a less frequently covered topic occasionally returned no results. It also seems that the main search only returns links to new stories, not videos. Recommendations 1. Make sure that newly added content is indexed and searchable before or soon after it is publicly available. 2. Consider showing related content when search results are retrieved, such as stories in similar categories or tags, so users exploring have more topics to follow. 3. Consider universal search with results organized by category. 4. Use search term logs to understand the most searched items. This can also provide information about items that users are having difficulty finding.
Figure 5.2 Example of observation in a heuristic analysis report
4. Present your findings to the project team and key stakeholders. Follow them through their observations and recommendations. Discuss why you gave the grades you did. (This is also a good time to get a recommendation on how to validate your findings, using one of the techniques discussed in Chapter 6.) How does heuristic analysis help to meet the requirements? After completing your heuristic analysis, you'll have a better understanding of the current state of the site (or that of your competitors) and a list of ideas that can help you qualify. You also have some ideas on how to structure the topics to be covered during your requirements gathering sessions, which brings us to the next step in this process.
UNDERSTAND THE CURRENT STATE
73
Gather information from stakeholders As we saw in our example at the beginning of this chapter, you risk missing out on differences in stakeholder expectations if you don't get context for an idea, such as "Customers can track their orders online ". , like that of our friend who wants the packages to be tracked by GPS. One of the most common mistakes in a project is to use a feature and call it a requirement without first understanding the problem and the expectations around a solution. So why is the requirements gathering process so often cut short? Gathering ideas and compiling them into requirements can take some time. It's easy to underestimate the number of questions you need to ask to define your requirements so they can be prioritized. And if the process is not well structured or participation is incomplete, there can be a lot of turnover throughout the project. (Rotation is time lost in additional meetings and work iterations caused by a lack of communication and commitment. These are different from the more productive work iterations that are part of designing and testing valid solutions in an effort to find the best one.) . So how do you encourage a balanced requirements process that focuses on business needs, but prevents it from becoming a hectic waste of time? Here are some steps to an efficient process: 1. Describe roles and responsibilities. Make sure project team members understand the roles they are expected to play when requirements are collected. 2. Gather the right stakeholders in the right groups to ensure time is optimally spent on needs-based interviews or meetings. 3. Create a meeting plan, including topics to be covered and questions to be asked during meetings. 4. Meet efficiently, capture ideas, and get clarification. Research ideas to discover the needs behind each idea. Once your meetings are over, don't forget to thank the stakeholders involved and update them on progress once you move to a consolidated, prioritized list. Let's look at each of these steps in more detail.
74
SECTION 5: BUSINESS REQUIREMENTS
Overview of Responsibilities Business requirements gathering often requires project team members to interview key business stakeholders to gather insights. Commercial stakeholders are those within the company who have a commercial interest in the success of the project or have subject matter expertise to contribute, or both. These people are not involved in the project full time, but they should be involved at key points in the process, and requirements gathering is one of those points. Keep in mind that they also have day jobs (so to speak) so their time is valuable and often hard to come by unless you plan ahead. The project sponsor(s) is the business stakeholder who is also directly responsible for the success of the project, often at a relatively high level in the company, such as the CEO. He or she will not be present on the project on a daily basis throughout the project life cycle, but will likely be actively involved in gathering requirements and ensuring a high level of involvement from business stakeholders. The sponsor may also attend some or all of the sessions. The project team is made up of people who are officially assigned to the project as ongoing resources. They can participate as a project manager, UX designer, business analyst, technical lead, visual designer, QA lead, etc. Depending on the size of the project, this could be your primary task. Within the project team itself, responsibilities during requirements gathering are often unclear. Taking the time to define responsibilities up front will help ensure an efficient collections process. Here are some questions to ask as you determine the specific responsibilities each team member will assume during requirements gathering: Who is primarily responsible for collecting and planning the right deals?
Interested in the most productive groups? These can be internal and external stakeholders (such as partners, suppliers, etc.). Who creates the overview and questions for business stakeholders
headline meetings? This is a great joint team exercise, weather permitting. The lead facilitator can then organize them into a structure that will flow well in a meeting. Who facilitates the meetings? Who takes notes and how are they shared?
GATHER IDEAS FROM STAKEHOLDERS
75
Who follows who after? Is someone from the technology team present at all meetings?
If so, how is this person involved (is he or she listening, providing information, or something else)? As a UX designer, whether or not he is primarily responsible for one or more of these areas, he has important skills. Creating a structure for topics and questions requires a clear categorization skill (which sounds like a good cross with information architecture) and of course facilitation skills are important to keep the meeting on topic with engagement. from all interested parties.
Gather the Right Stakeholders The main goal of interviewing stakeholders is to gain insight into relevant ideas, needs, knowledge, and frustrations related to the project from different angles, which can then be incorporated into the project requirements. There is also the sometimes unspoken benefit of involving many different groups so that everyone feels they have a say in the project and will agree on the final solution as a result. While it may seem more political than practical to get people involved, connecting you with a network that will support you throughout the project is often a crucial step. It can also help you avoid last-minute changes, which can happen when someone you haven't talked to raises an issue late in the process. That's why it's often a good idea to involve a wide variety of people. On the other hand, deadlines and budgets must be taken into account. Engaging a large number of people takes time, both from their point of view and from yours, just for meetings, not to mention the time it takes to analyze the notes to identify trends and consolidate layoffs. For efficiency and your own sanity, it makes sense to prioritize the groups to talk to and choose key people from those groups to serve as thought leaders for your team. Who are the potential stakeholders you could involve? These groups are often good sources of ideas: Groups with initiatives that are location-dependent (for example, those with
marketing campaigns that require information to be displayed on the website)
76
SECTION 5: BUSINESS REQUIREMENTS
Groups that need to support processes directly behind the site or
application, how it provides content, enters and manages data, and quickly responds to information collected Front-line customer service, such as online or phone support, or
anyone who interacts with customers personally (for example, in a retail store or through delivery) Sales, product management, or consulting services, to
featured products and services Human Resources, to meet recruitment goals Public Relations, to present information to investors and the media All groups responsible for other relationships to be developed
as part of the project and that will influence the design, such as relationships with partners or personal suppliers. Create groups that allow for good discussion. There is no right way to do this, but a common way is to group stakeholders by department, like this: Marketing (five people) Product Management (four people) Customer Service (two people) Sales (four people)
For a smaller project, one person from each of these groups can participate in a series of two or more collaborative sessions where everyone comes together. Once you have the stakeholders in mind, as well as a general structure for the meetings (discussed in the next section), you can start planning the meetings. Try to start planning at least a few weeks in advance; it can be difficult to get everyone in one room.
GATHER IDEAS FROM STAKEHOLDERS
77
Prepare a meeting plan In parallel with your efforts to select the right stakeholders, compile a list of topics to cover and questions to ask (this will also help you narrow down your stakeholder list). You should have a different plan for each group you meet with, although many of your questions may be the same from group to group. You also need to decide how much detail you want in your meetings. If you're meeting with a large number of people just once (for example, members of multiple departments, as suggested above), you may want to brainstorm ideas, but you probably don't want to spend too much time delving into the most important details during the meeting. meeting. meeting. If a stakeholder gives you the idea that "customers can track their orders online", you can simply ask why this feature is important and if the stakeholder can immediately find a website that does it well. These questions should help uncover key differences between stakeholder expectations of the position without spending the entire meeting on one statement. You can then work out the specifics of the idea with the project team and go back to the stakeholder to ensure that the generated requirements still represent your original idea. Let's say you're redesigning an e-commerce site and you meet with a wide variety of stakeholders, holding one meeting with each group. Here is a sample plan for a group meeting in a sales department.
Sales - Requirements Gathering Meetings Participants Inside Sales: Jenny Bee, Tracy Kim, Joseph Arnold Key Management: Kevin Abernathy, Cat Parnell Timeline: 2 hours Objective: Understand the current sales process and identify issues and opportunities as the web could support better this process. 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
SECTION 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 there differences based on the size of the client (for example, small companies vs. large companies)? How has this process evolved in the last two years and how is it expected to evolve in the next three to five years? How does a potential customer understand all the things that need to be purchased and how do they all work together?
Overall impression: who do you think are the best visitors to your current site? Because? As they are? What are they trying to achieve on the site? How does the web contribute to the sales process and/or sales closing rate these days? What information do customers need to make a buying decision? Is this information available on the website today? Is it easy to find? It is necessary? How difficult is it to maintain the content of a website these days? What statistics do you get from the website? What additional metrics would you find valuable? Because?
Predict the future: What can we do to better support the sales process when thinking about a future website? What current site functions and features are critical to sales? It is not necessary? Missing?
Summary: Are there any other ideas, suggestions, or concerns that we haven't addressed? What websites do you think are good at supporting sales? What is the most important thing the company can do to improve customer satisfaction?
GATHER IDEAS FROM STAKEHOLDERS
79
Lead meetings effectively Here are some practices to help you qualify. Make sure a shared vocabulary is used A lot of confusion can be avoided if the requirements gathering team agrees on a common list of terms and definitions. For example, are the people who use the system called users, customers, or customers? Are people more familiar with the term interaction designer or information architect? To avoid confusion, take a moment at the beginning of each meeting to identify the term being used and what it means. You may also benefit from creating some visual elements that help explain the relationships between different terms or functions (see Figure 5.3). Category
categories
categories
Subcategory
Subcategory
Subcategory
He
He
He
Article
Article
Article
Figure 5.3 Scheme with project conditions and relationships
A common vocabulary for the deliverables to be used in the project will also help stakeholders understand the process and the type of results they can expect. This can inspire confidence that your time and effort will not be wasted in a black hole of ideas. In general, if you find yourself defining the same words more than once or twice (particularly if you notice that the definitions change subtly each time), consider including them in a project glossary and sharing it with the project team. Other examples of terminology that it is good to clarify at the beginning of the project include
80
SECTION 5: BUSINESS REQUIREMENTS
Interacting roles (for example, job seeker vs. client or
tent manufacturer vs. publisher) Primary widely referenced products (functional specifications
structure, wireframes, sitemap) and a brief description of how they differ. Differentiation between different levels of information (such as our category
information in figure 5.3) Distinction between needs and ideas
Listen for ideas and research needs Stakeholders may make statements that sound like needs. Consider an example. corporate lawyer
"We need a blog on the website."
B
This is really an idea, not a necessity. Once the blogging functionality is fully designed and implemented, it becomes a solution, but it is not necessarily the solution that best meets the key need of the stakeholders requesting it. If you ask why a blog is important, you might get a wide variety of need statements, like "We need to feel relevant and connected." Everyone is talking about blogs and I feel like we are way behind if we don't include them." "We need a way to get people to visit the site again and again to generate more ad revenue, and blogging means freshly published content with a following." "We need to position ourselves as thought leaders, and blogging is a more personal way to showcase our expertise." "We need a better way to communicate and innovate with our customers, and blogs welcome feedback so we can hear your thoughts." Each of these statements describes valid needs. Bringing them in will help you learn more about the drivers behind applications for a particular position, helping you build consensus by consolidating and prioritizing requirements.
GATHER IDEAS FROM STAKEHOLDERS
81
Joining Requirements When the meetings are over, take the ideas you've collected and categorize them into common areas of functionality. You'll start to notice a lot of overlap; this is a good sign that a particular idea is getting a lot of buy-in from stakeholders. Eliminate redundancies and try to consolidate a list of ideas that effectively represents the intent of your stakeholders. To turn the collected ideas into actionable and trackable components of your project, you need to add these ideas into requirements. Think about raindrops emerging from a cloud: you go from a large, indefinite cloud to a larger number of well-defined raindrops. So if you get a cloud of ideas like "Customers can track their orders online" you need to turn them into separate statements dictating what the system should do. The resulting requirements should provide information about the general need that must be satisfied. Visualize and consolidate the needs of the different stakeholders. Push the design forward without being too specific about what it will look like.
performed Serve as a separate work unit for prioritization and tracking purposes
Make sure your technical lead (or someone else who can represent the development team on your project) is involved as you begin to move from ideas to requirements so that they can ask the questions that will help you estimate the effort required when set priorities later. If you have a dedicated QA team member, that person can also ask some detailed questions to help gather the requirements. To dig deeper into the idea of requirements traceability, ask yourself questions like How accurate must traceability be? What type of information should be included in the monitoring data; for
For example, do we have to provide an updated estimate of delivery time? These types of questions can be asked and elaborated with the stakeholders who gave you the original idea if they have spent a lot of time on the project. If you have little access to these stakeholders, you can work out the details yourself by talking to the project team.
82
SECTION 5: BUSINESS REQUIREMENTS
and then discuss the requirements with the project sponsor to make sure your choices make business sense. Table 5.1 summarizes the types of requirements that can arise from the idea of tracing and how you can capture them. TABLE 5.1
An example of business requirements
I WENT
AREA
1
track order
2
3
track order
track order
APPLICATION
BUSINESS NEEDS
Orders can be tracked by
encourage self-service
entering a tracking code
during childbirth (Support
online
benefit)
Users can track their packages.
Show efficiency innovation
age by gps, following trucks
efficient delivery (competitive
or planes
benefit)
Users can view all previous orders, encourage new orders, and orders placed in the last 365 days
self-service (sales, support benefit)
Note that in some cases the requirements overlap, such as the first two requirements in the table, both of which are traceability methods. They can live together in the same system because you can enter a code to find your package through the GPS view. However, they are separate as the GPS related requirement is likely to be more effort and should be prioritized independently of the other features. As you consolidate the statements, look for business requirements that you think may conflict with user needs. For example, a business requirement may be to collect personal information from potential customers, such as email addresses. But customers may have reservations about providing information. After all, it takes time to fill out the forms, security and privacy are a concern, and this step can interrupt the more important task they're trying to accomplish. When you identify such conflicts, they begin to give you ideas to meet business and user needs. For the tracking example, you may suggest using the "Send to a Friend" feature to capture the email address for user convenience. This means that Send to a Friend can become a requirement that you include in the mix for prioritization. this kind of ideas
GATHER IDEAS FROM STAKEHOLDERS
83
one can help meet business and user requirements, so they are great to capture. They also live in that area of overlap between the Define and Design phases (see Chapter 4), as you begin to think about design solutions to business problems.
Design Definition Developing potential conflicts between business and user needs are excellent things to explore during user research, which we'll discuss in the next chapter. User investigation also allows you to expand Table 5-1 into a complete set of potential requirements, which are prioritized into a list of project requirements (shown in Figure 5-1 and discussed later in Chapter 9). ). Remember that business requirements gathering often goes hand in hand with exploring technical possibilities and gathering user requirements. Next up: time to talk about users!
84
SECTION 5: BUSINESS REQUIREMENTS
6
User Research Get to know the guests you are inviting to the party There are many user research techniques that can be used throughout the project lifecycle, either to better understand your users or to test their behavior across different versions. from a site This chapter focuses on some of the most commonly used methods in the early stages of design. These techniques help you determine which user groups should be given the highest priority during the project, contextualize their needs and frustrations, and assess current site performance (if applicable) using user experience design best practices. . carolina chandler
Basic User Research Steps 1. Define your main user groups. This includes creating a framework that outlines the main types of users you're designing for, so you can focus your efforts on acquiring users for search. 2. Plan for user participation. This includes choosing one or more techniques for engaging user groups in research, depending on the needs of your project. 3. Run the search. We'll cover the basic techniques here, like interviews and surveys, and give you tips on how to implement them. 4. Validate your user group definitions. You can use what you have learned from the research to strengthen your user group model. This model will then serve as a platform for developing more detailed tools like characters (discussed in Chapter 7). 5. Generate user requirements. These are explanations of the features and functions that the site may contain. Add these statements to your business requirements (discussed in Chapter 5) and prioritize them to become project requirements (discussed in Chapter 9). This chapter covers the first three steps, starting with the first: defining your user groups.
Define your user groups Planning for user research at the start of a project can seem like a chicken or egg dilemma (which comes first?). How do you make sure you're talking to the right people if you don't already know who those people are? One way to start is to create an initial or preliminary definition of the users you will be designing for. This describes the main groups of users on your site, which can help you focus your research efforts on the right roles, demographics, or other variables that may affect how users will experience your site. User group definitions can be high-level (a list defining each of your audiences) or detailed and visual (a diagram showing different types of users and how they interact with each other).
86
CHAPTER 6: USER RESEARCH
A high-level definition for a company's main .com site might include the following user groups: potential buyers, current buyers, partners, and job seekers. Initial definitions are based on the collective knowledge of business stakeholders and project team members regarding the possible types of users that might interact with the site. These definitions can be put together by collecting some objectives and characteristics that different groups of users may have. Here are the basic steps to define your user groups: 1. Make a list of attributes that will help you define the different users of your site (the next section covers some of the more common ones). 2. Analyze the attributes with the people in the company who interact with relevant types of users (eg, customers). 3. Prioritize the attributes that seem to have the biggest impact on why and how a potential user would use your site or app. 4. Define the user groups you will focus on in your research and design. The following sections take a closer look at some brainstorming techniques to help you collect these attributes and how to prioritize and model them (creating representations of different types of users that will help you focus your research efforts).
Create an Attribute List A good start for your Attribute List is to collect and absorb any studies or other documentation your organization has that can provide guidance on users. Here are some possible resources: Documents that explain the company's strategies, such as business objectives,
Competitive intelligence, marketing strategies and business plans Current customer market segmentations and other demographic data
collected by the marketing department Prior user research (see table 6.1 for some examples)
DEFINE YOUR USER GROUPS
87
Surveys, such as user satisfaction surveys and feedback forms Customer service reports on common issues
Next, identify people within the organization who have some idea of current or potential users. The number and variety of people to include will depend on the type of project and its scope and schedule. If you know that the initial definition of your user groups may have a short lifespan (for example, it will only be in use for a month or two while user research is planned), you can only add two or three participants. If you feel that the first definition should cover a large part of the design process (for example, if you only need to work with this definition until usability testing is done after a design is done), include more participants and make sure you have a section cross. of perspectives. Some potential participants include the marketing team responsible for brand representation, targeting, and campaigns; sales team; product managers; customer service or support representatives; and trainers. It is also good to involve project team leaders and other stakeholders in this exercise. Ask the group to think about the different types of potential users with whom they often interact. Then ask them to list some of the common features they found. Here are some examples of what can vary: Main goals, as they relate to the theme of your site. Because they are
the users who come to it and what are they trying to achieve? For example, buying an item, exchanging shares, or getting an answer to a specific question are common goals. functions. This can be defined in different ways, but one way is to link the roles to the
Primary User Target: Job Applicant, Support Applicant, Prospect, etc. After getting more information from the user, the functions can be divided for different needs or styles; For example, on an e-commerce site, customers may be bargain hunters and savvy. Demographics, including age, gender, household (single, married, children),
income level and region. Experience, including level of education, familiarity with
technologies (often referred to as technical expertise), level of subject matter expertise, and frequency of use (one-off, incidental, frequent). 88
CHAPTER 6: USER RESEARCH
Organizational characteristics, including the size of the company the users work for
for your department, job type (starter, freelance, middle management, executive), stability (long-term or high turnover?), and work patterns (remote work, amount of travel). Once you have a list of some of the features that appear most frequently when stakeholders describe potential users, you can prioritize them based on their level of importance, and then use that hierarchy to begin defining and modeling user groups.
Prioritize and define Which of the above features do you think have the greatest impact on how and why different user groups might use the site? Focus on the ones that you think will have the biggest impact on a user's goals or behavior. Prioritize these traits and remember the goals you set in Chapter 4; they will also help you make decisions. An example further illustrates how to prioritize attributes. Let's say you work with a company that provides tools for trading stocks, options, and futures online. This particular company has determined that part of its strategy will be to engage non-professionals who trade stocks online and encourage them to trade new types of products, such as options and futures. The company intends to do this by providing easy-to-use business tools aimed at those who want hands-on learning in a secure environment. When discussing the features with business stakeholders, you'll find that the following seem to have the biggest impact on how people can use these tools: Current trading frequency, especially the frequency of instant online transactions.
(for example, once a quarter, once a day, several times a day). Those who are only interested in trading (for example, once a month) may not be serious about trying something new, while those who are already trading full time may not find much value in tools aimed at older traders. new. But those who are active part-time traders can get very interested in the company's tools. Number of types of products traded: only shares or shares, options and
futures. Those who already sell all types of products may have a preference for their own tools, but those who only sell one type may be ready to branch out into others. DEFINE YOUR USER GROUPS
89
Level of professional knowledge (for example, familiarity with negotiation
conditions). This will help determine how much help they will need along the way with tutorials and glossaries. Level of technical knowledge (for example, familiarity with purchasing
online and online banking and business services). This will affect how much security they need in terms of data privacy and how advanced or simple the online interface needs to be. You may want to prioritize these attributes, as they can affect the type of users you want to target searches for. If where traders live doesn't seem to have any real impact on how or why they trade, the Region attribute can be removed from the list as a consideration for respondents. On the other hand, if the importance of a certain attribute generates a lot of discussion, it might be a good topic for a survey or interview question (more on surveys later in this chapter).
alternative
Comparing two or more attributes can also help you prioritize. For example, if you create a chart with two attributes for online merchants, you can start to see how the groups fit into some ranges. Figure 6.1 is an example of a global user model that you can create using the two attributes Direct Trading Frequency and Number of Product Types Traded; it also shows the resulting user groups that may arise from the discussion.
Full Time Product Specialist
Full-time experienced generalists
Instant Trading Frequency
"Second Job" Traders
Supplemental Income Merchants
active explorers
long term investors
Low
lovers
Low
alternative
Number of types of products traded (stocks, options, futures)
90
CHAPTER 6: USER RESEARCH
Figure 6.1 A graph of two attributes, representing a rough user model. Co-creating this model can facilitate discussion about possible differences in user motivations and experiences.
This user model provides a way to discuss different types of users at a high level. It is not intended to be the definitive model and does not label only groups of users (a user may be a long-term investor in stocks and also actively explore other opportunities in options or futures). But it begins to express your understanding of the different groups of users and how they can be motivated to use your site. This discussion of key attributes will also help you determine which attributes you want to focus on when recruiting search users. If you determine that trading frequency is important and that the priority will be to engage those who currently have a medium frequency level, define what medium frequency means (for example, one to three times a week) and recruit the participants of your survey accordingly. Speaking of research, let's talk about techniques you can use to engage users in your project.
Can you only design from user models? There is debate in the user experience field about building user models before doing research, because it can influence your thinking before you have the actual user data, and because your project team or the project sponsor may see the model as a substitute for user research. Using an unvalidated model carries a higher risk that its assumptions are incorrect. However, for projects where you don't interact with users, a well-thought-out model (verified with sources outside the project team, such as a customer service group or training group) is better than no model at all. wear. During the project.
Choosing Research Techniques Now that you have a rough idea of the user groups you want 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 information on the most commonly used search techniques and when they are most useful. Use this table as a reference to help you choose which one is best for your project. The following section describes each technique in more detail.
CHOICE OF INVESTIGATION TECHNIQUES
91
BOX 6.1
Common Research Techniques for Users
ACTIVITY
WHAT'S THAT
WHEN IT IS USEFUL
STRAIGHT
TYPICAL TERM *
User interviews
A one-on-one conversation with a participant who belongs to one of the main user groups on the site.
There is user access, but the type of access (personal, telephone, etc.) varies.
Get instant feedback. Gathering information on attitudes and context can be difficult, especially if interviews are conducted remotely.
2-4 weeks for 12 interviews: up to a week to plan, 1-2 weeks to interview, and up to a week to collect results.
contextual research
A site visit with the participants to observe and learn how they work in their normal day-to-day environment.
The project team has access to little information about the participants. Enter the target users. because the environment of the users can pose security problems. Users work in a unique environment, intellectually (for example, a hospital). property and intruUsers work hard. For companies with fairly complex applications, perform tasks or workflows. it might be easier to visit on a weekday.
3 to 4 weeks for 12 appointments: 1 week to plan, 1 to 2 weeks to observe, 1 week to analyze and report results.
investiga
A series of questions consisting primarily of closed-ended (multiple-choice) answers that are used to identify patterns in large numbers of people.
You want to express the results in more quantitative terms (for example, "80% of the target audience say they never buy cars online").
3-4 weeks for a short-term study: 1 week to plan and write the study, 1-2 weeks to conduct the study, 1 week to analyze and report the results.
You want to get context, but you can't get to the user.
You are more interested in collecting information about preferences than actual performance.
92
CHAPTER 6: USER RESEARCH
Provide a suitable sample. Make sure questions are well written to get accurate answers without leading respondents to a specific answer.
BOX 6.1
Common User Research Techniques (continued)
ACTIVITY
WHAT'S THAT
WHEN IT IS USEFUL
STRAIGHT
TYPICAL TERM *
focus groups
A group discussion where a moderator guides participants through questions on a specific topic. It focuses on discovering the feelings, attitudes and ideas of the participants on the subject.
The team believes that user attitudes will greatly influence how the solution is used (for example, if you have had problems with it in the past).
Understand how to target your questions to get the right information.
3-4 weeks: 1 week to plan and write questions, 1-2 weeks to lead focus groups, 1-2 weeks to analyze and report results.
sort cards
Participants are given items (such as themes) on cards and are asked to sort them into groups that are meaningful to them.
You're working on a content source site with many elements, and you want an efficient structure for your user groups.
Decide which subjects are the best to photograph.
3-4 weeks: 1 week to plan and prepare, 1 week to conduct research, 1-2 weeks to analyze and report results.
usability test
Users try out typical tasks on a website or app while a facilitator watches and, in some cases, asks questions to understand user behavior.
An existing solution is being improved.
Choose the right tasks to focus on.
3-4 weeks for 10 users and medium formality: 1 week to plan and write tasks, 1 week to run tests, 1-2 weeks to analyze and report results.
Competitive solutions are available for testing. You have a prototype that allows users to complete (or simulate) tasks.
Facilitate the group effectively.
Determine how formal the test should be done.
*Typical time period represents the time generally required from the point users are scheduled. Two groups of six to eight users are assumed (except for surveys, where the number of users must be higher). This does not include recruitment time, which can take one to two weeks after completing the selection questionnaire.
How many research activities can I include? Before choosing between activities, ask yourself how much money and time the team can spend on user research. Consider the following scenarios to understand how eager your client company is for user research. If the project leaders and project sponsors are familiar with user research and are interested in using it for known purposes, such as ensuring that the site meets specific project goals, you will likely have more freedom CHOOSE TECHNIQUES OF INVESTIGATION
93
when planning two or more activities or one activity that you perform multiple times (for example, testing a design, changing it based on your results, and testing the new design again). If no one in the organization is familiar with user research and there is some resistance to it, it may be best to propose a round of research and choose the technique that you believe will bring the most value to you, the project team, and the project stakeholders. business. . After receiving the research results, the project team will have a better idea of what is involved and how the project can benefit from it. You will have a strong case to include more research later if necessary. If you have room for at least two rounds of research, it's a good approach to include one round in the Define phase, or early in the Design phase, to better understand your users. Then add another round before development begins to validate the design. For example, for a task-based application, you might conduct user interviews before designing and run usability tests on a prototype later in the process. Or you can start with a contextual search for a content source and then add a map classification exercise.
Survey planning considerations When planning a survey technique, consider the following: Why you are conducting the survey: what you want to learn from it Who you will involve: key user groups described above How to get participants: recruit people to participate and evaluate (ie ask questions to make sure they fit the user groups you want to target) How will you compensate participants? What space and equipment will you need? What will it address: the key issues? How will you provide data captures: the number of people? involved and the tools they use Chapter 13 addresses each of these considerations as part of a detailed look at one of the most widely used techniques by UX designers: usability testing.
94
CHAPTER 6: USER RESEARCH
Note See Chapter 2 for more information on task-based applications and content sources.
Navigating Steve Baty wrote an article describing different methods and how to choose between them based on the stage of development, your information needs, and the flexibility you have to include user research. It is titled "Bite-Sized UX Research", by Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.
Let's take a look at each of these techniques and the ways they are commonly used.
User Interviews User interviews are structured conversations with current or potential users of your site. These can take place over the phone, in person in a neutral location (such as a conference room), or ideally in the environment in which the user is likely to use the site. (The latter situation is also suitable for contextual research, discussed below.) Interviews help to understand the preferences and attitudes of the participants, but should not be used to make formal statements about actual performance. If you're looking for specific information about how people interact with a website, it's best to observe them (for example, in a contextual search) or ask them to perform tasks on the website (during usability testing). Website analytics can also provide insight into some performance information that can be particularly robust when combined with interviews or questions that provide context for the data. The Basic Process For user interviews, the UX designer creates a list of questions designed to elicit information, such as the following: Relevant experience with the site or topic.
CHOICE OF INVESTIGATION TECHNIQUES
95
The brand of the company, lived by the participant. Attitudes, for example, in relation to the thematic categories covered (for example,
origin of the tent), the process being designed (for a task-based application), or marketing methods (for a marketing campaign) Common goals or needs that drive users to your site or to that of a
competitor Common next steps users take after visiting the company's website Other people involved in the experience. For example, create one
Does the user tend to collaborate with another person as part of the larger goal they are trying to achieve? Are they likely to share information or seek the opinions of others along the way? Any other information that helps you validate the assumptions he makes
Done about user groups so far, for example, whether the variables you discussed when creating a provisional user model really seem to affect how users experience your site. If more than one person is conducting interviews, it's a good idea to have a defined list of questions and a scripted introduction that you can use to maintain consistency between interviews. Choose in advance how you want the interviews to unfold. If you're looking for a formal report, you probably want a high degree of structure, where the order of questions doesn't vary too much and all questions are asked, with few additions. If richness of data is more important than consistency, you can go for semi-structured interviews, where you start with a list of questions but let the conversation flow naturally, with the interviewer asking questions to explore points of interest (called a survey). ). The length of your interview may vary; 45 to 60 minutes is usually the best range to shoot. It gives you enough time to build rapport and answer a wide variety of questions without tiring the participant. User interviews provide a rich data set that you can use to write personas, which are covered in Chapter 7.
96
CHAPTER 6: USER RESEARCH
Interview Tips The quality of the information you get from an interview has a lot to do with the quality of the questions you ask. Focus on the personal experiences of the participants. Don't ask them to speculate about what they might do in the future or what others might do. That kind of information rarely predicts what they will actually do. Do not ask questions that require a specific answer or push a participant in a positive or negative direction. Ideally, the questions are simple, neutral, and open-ended. Some examples of important questions are: What do you like about PseudoCorporation.com?
This assumes that the user enjoys using the site. Only use this question if you are also asking them what they don't like. Does PseudoCorporation.com live up to your expectations?
This can be answered with a simple yes or no, which doesn't provide much detail to help your design efforts. Would you rather use PseudoCorporation.com or CompetitorVille.com?
and if it's the latter, why do you think they're better than Pseudo? This has some problems: it asks two questions in one statement and forces an implicit opinion on the participant. The best questions to ask are: Tell me about your last visit to PseudoCorporation.com. Why did you go there? What do you remember of your visit?
If you are conducting a large-scale, more formal series of interviews, you may want to include some multiple-choice questions. However, they generally do not provide very rich information. They can be difficult for participants to follow when asked verbally and users are unable to provide further details. In general, save these types of questions for trackers or surveys. Try someone, maybe someone within the organization who is not a member of the core team. This will help you uncover issues that may not be obvious and adjust your timing and flow. If possible and the participant agrees, record the interview so that others can benefit from hearing the answers directly from the participant's mouth.
CHOICE OF INVESTIGATION TECHNIQUES
97
Contextual research Contextual research combines user observation with interview techniques. The UX designer targets the participants, ideally for the environments in which they are likely to use the site. For example, for an office application, the contextual question would imply that you are sitting at the participant's desk. This method provides valuable information about the context in which a participant works, including the real-world problems users face The type of equipment they work with The room they work in, in particular, the amount of space they have
they have, how much (or little) privacy they have, how often they are disturbed, and how they use their phone and paper (pay special attention to the printouts they post or the notes they keep on hand). Your preference to use a mouse instead of a keyboard. This can affect a lot
your design choices, especially if you're designing a tool that requires a lot of data input. How they work with others, in terms of collaborating and sharing
sources. For example, if more than one person uses the same computer, it affects how you design login and security features. Other tools they use, both online and offline. How people use paper
especially interesting: for some tasks it can be difficult to design an online solution that competes with paper. Surveys combine observation time and interview time. They can last from several hours to several days. If participants cannot spare a minimum of 2 hours, consider simply conducting an interview. During an observation, the participant needs some time to get used to her presence and behave naturally, and that doesn't happen after only 15 minutes. The Basic Process Prepare a 10-15 minute introduction to use with each participant. It should contain the purpose of the investigation, a detailed description of what you will do together (observation and interview) and how the 98
CHAPTER 6: USER RESEARCH
the information will be used. This is also a good time to get signatures on consent forms to reassure participants that what they share will remain confidential. Start with some high-level questions about typical attendee processes, especially questions relevant to site design. Inform the participant 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 teacher and you take the role of learner. The teacher explains what he is doing as if he is learning his process. Active observation often provides more information about the reasons for the participant's behavior, but may affect the way the participant works. In passive observation, you encourage the participant to pretend you're not even there. Your goal is to observe behavior as naturally as possible. For example, if a participant is talking to you, they are less likely to call you or ask someone a question about a problem you are trying to solve, but if you are passively watching, they are more likely to see it happen. . You can look around during the interview portion to ask about the reasons behind some of the behaviors you observed. Both approaches can work well. In general, if you don't have a lot of time with the participants (for example, only 2-4 hours each), you may choose to use active observation to ensure you get the detailed information you need. If you have a full day or more to spare, passive observation provides a good balance between natural behavior and discussion. Once you've extracted the information from your searches, you'll have a lot of valuable data to sort through! So how do you recognize patterns or trends in your results? One useful way is a technique called affinity diagramming. There are many great resources available on this topic, but here is a brief overview. A quick guide to creating affinity graphs Affinity graphs are the technique of grouping a number of distinct and distinct items (such as user statements or researcher observations) to form patterns and trends. Here are the steps of a simple affinity diagram session: 1. Assemble the team that ran the queries with their notes.
CHOICE OF INVESTIGATION TECHNIQUES
99
2. Give everyone a pack of sticky notes and have them write a statement on each note, along with a short code that traces that statement back to a participant, such as their initials. Focus on statements that seem relevant to the design of the site, either specifically (a call) or more generally (a statement expressing the participant's attitude toward the company or topic). 3. Have everyone hang their Post-its on the wall. You need a big blank wall if you work in a big studio; try to get one that you can access for at least a few days. 4. Once all the notes are ready, start grouping similar statements next to each other. This part of the exercise can include the larger team. It's a great way to start sharing results. 5. Once the groups start to form naturally, you can label them to provide more structure. If some Post-its belong to more than one group, you can write duplicates and place them in any suitable group. Note This method works well for contextual search, but it can be applied to many other situations. For example, it's a great way to co-create categories for unclassified topics to help you move map classification results to additional levels of structure.
Patterns can arise in many ways, so it's best to let them form naturally. However, here are some examples of the types of categories you might encounter, including the types of statements you might find in them: Goals: "I'm trying to clear all open items here before I start the day." Mental models (including explanations that show how users are
linking external experiences with internal thought): "I use this online tool as my suitcase, for things that I consult a lot but that I don't want to take with me." Ideas and Feature Requests: “I wish I could undo this. I like
you accidentally move the whole folder and it takes forever to cancel it. Frustrations: "I would ask tech support about this, but half the time they don't."
know what the problem is."
100
CHAPTER 6: USER RESEARCH
Solutions: "This is taking so long here that I finally print
the list and work with it throughout the day. At the end of the day I enter the results”. Value Statements: "This tool here saves me a lot of time, so if you do
Drastic changes won't take it away!"
Deep Dive The resource of choice in contextual research is Contextual Design, by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also contains detailed information on how to interpret the results using techniques such as affinity diagrams. To learn more about mental models and how to understand them, see Mental Models: Aligning Design Strategy with User Behavior by Indi Young (Rosenfeld Media, 2008). This is especially useful when working on the information architecture of a content source.
Surveys Surveys consist of a series of well-defined questions that are distributed to a wide audience. They typically consist of closed questions (such as multiple choice questions) that can be easily collected with a tool that can show patterns among answers. Surveys are a good tool when you want to present results in more quantitative ways (for example, "82% of respondents who work from home say they have some type of high-speed Internet connection") than you would with surveys. surveys. finished questions used in interviews. However, it can also collect qualitative information about user habits and attitudes. In the field of user experience, surveys are often used to measure user satisfaction (with existing websites or apps) or to build or validate user models such as segmentations or personas.
CHOICE OF INVESTIGATION TECHNIQUES
101
The Basic Process As with user interviews, you don't want to ask questions that force users to speculate. Don't ask "If you had feature X, would you use it?" Unlike interviews, with multiple choice or yes/no surveys, true/false questions are better and easier to analyze later. They are also faster for participants to respond. Use surveys when you have questions that are factual requests for demographic data, such as the following: Which of the following devices do you personally own? Choose what applies. Computer Mobile phone Gaming system such as Xbox, Playstation, or Wii
or for questions related to attitudes with a range of different options: Read the following statements and select the degree to which you agree or disagree with each statement. Pseudo Corporation customer service meets my needs. Strongly agree Agree Neither agree nor disagree Agree Strongly disagree
In particular, questions like the one in the second example are often used in addition to usability testing tasks. You can use this type of follow-up question to find out if participants were frustrated completing a task. Participants don't always like to express a negative opinion out loud, but they are often willing to express it when faced with a rating system. This brings up another point: surveys are a great addition to other forms of research you may be doing, such as user interviews or contextual research. Combining two research methods provides a more complete picture of the user than either method alone can provide.
102
CHAPTER 6: USER RESEARCH
Navigation If you want a high degree of confidence in your results and have the budget, there are formal tools available to measure user satisfaction with ease of use. These tools contain questions that have been tested to ensure that they do not lead or confuse a wide audience. Some of the most 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.es
When planning a survey, keep the following in mind: Who is it for?
Use your preliminary model to determine this. This will make a difference in how you answer the rest of the questions here. Which survey distribution method gives you the best results?
If your main user groups tend to congregate in one particular location, you may get more results by going there and setting up a table for people to take the paper survey. If your user groups are active Internet users, completing an online survey may be the best option for a large number of participants. Or you may decide that your user base is best found with phone searches on a list of current customers. How much time are participants likely to spend completing the questionnaire?
The search? If you offer some kind of compensation or if they get some other benefit from completing it, you can usually create a longer questionnaire, one that can take half an hour to complete. If not, it should be short for people to complete; think 5 to 10 minutes. Either way, be sure to give participants an estimate of how long it will take and update them on your progress along the way (use page numbers like "2 of 4," for example, or show percentage complete).
CHOICE OF INVESTIGATION TECHNIQUES
103
How do you know when to start analyzing the data?
You can choose to run the survey until you reach a certain number of participants or until you reach a certain deadline date, whichever is the priority. What tool will you use to collect and analyze the data?
If you are taking the survey online, the tool you are using to collect the data may have options for viewing and analyzing the results. If not, you need a method to enter the data into the tool of your choice. For paper surveys, this means a lot of data entry, so be sure to plan for this period.
Focus groups Focus groups bring together a variety of people within a target group and facilitate conversation with them. Common goals are to get feedback on topics relevant to the organization or its brand, such as past experiences, related needs, feelings, attitudes, and ideas for improvement. A focus group is a good technique for several purposes: Listen to different user stories. Open discussion is a great way to communicate.
the storyteller in all of us. When a focus group is going well, people build on each other's stories and ideas and recall situations that might not come up in a more structured one-on-one interview. The size and energy of the group can give people the time they need to remember and share these stories. Understand relevant differences in experiences. Most people are natural.
they want to compare those who share cultural information and their favorite tools with others in their interest group. Often, you can learn more about competing sites or services, or hear tips on workarounds, resources, and support. Generate ideas. Even if you don't want the pool itself
As a designer, you often get great ideas for new features or designs directly from the group or by listening to their work processes or frustrations. As with stakeholder ideas, be sure to narrow them down to the main need (see Chapter 4) to ensure it is addressed. Understand different points of a collaborative process. if you are
When designing a process that involves multiple functions and related collaboration, groups can be a great way to fill in gaps in your understanding.
104
CHAPTER 6: USER RESEARCH
how people interact For example, if you are working with a content source such as an intranet, it may be helpful to bring together a mix of content creators, content editors, and content users to identify where the process can be improved. There is a lot of discussion about the use of focus groups in UX research. It is not a good technique for usability testing (since users often work individually rather than in groups), and sometimes the group situation can unduly influence the statements of the participants. However, if properly planned and facilitated, focus groups can generate many ideas that will be of value to you throughout the project. Chapter 13 discusses this in more detail in the context of proof of concept. The Basic Process When writing focus group questions, remember the same tips you would use for writing user interview questions (discussed above). Start with a few simpler questions, such as "Tell me about your last visit to PseudoCorporation.com." Why did you go there?" Keep all questions focused on brainstorming in the middle of the group when participants are comfortable with you, each other, and the topic. Assign blocks of time to each topic and stick with it. Go ahead and let it go! If you are concerned about time, put your most important questions in the middle of the list of topics, after people get used to the activity, but before time constraints may arise, it pops up towards the end. Logistics for focus groups will be the same as for usability testing (Chapter 13 provides suggestions for selection, recruitment, and scheduling.) Six to eight people per 1-2 hour breakout session Give each person a nametag or seat card next to your seat where everyone can address themselves by name The format of the discussion itself should include an introduction, usually covering these main points: your role as a facilitator and what you hope to get out of the speech .
discussion (for example, some of the points above).
CHOICE OF INVESTIGATION TECHNIQUES
105
Why the participants were chosen to participate (for example, "You are all
current users of the Pseudo Corporation website and we are bringing them together to learn more about their experience"). How this information will be used, both in the design and in the
confidentiality position. That you are there as a moderator to listen to their opinion and
experiences. You want them to feel that they can share fairly, so ask people to be direct but also respectful of others in the group. That there are too many issues to deal with, so that at some point
discuss one topic to make sure you can cover them all. This can lead to an introductory round for group members, often with an icebreaker question. Your goal is to get everyone talking about the first question, even if it's just a short story. You can start with one person and work around the table, or let people respond naturally and then name those who haven't responded. Often you go around the table for the first few questions, and when you feel the group is ready, you can use body language to open up the questions to everyone.
Snorkeling: Body Language A good understanding of body language can be an incredible tool when moderating focus groups or in-person user research. This can help you understand when someone is feeling frustrated, agitated, angry, or threatened so you can determine when to try to reassure someone or investigate a specific comment. The following book on this topic may take more than a weekend to read through, but it is designed to be easy to flip through: The Definitive Book of Body Language by Allan Pease and Barbara Pease (Bantam, 2006).
When calling someone who hasn't responded yet, remember to repeat the question if the person didn't understand or didn't hear the last one.
106
CHAPTER 6: USER RESEARCH
some statements in the discussion. Also, make sure that a disagreement doesn't seem like a disagreement between two people. Don't say, “Bob, we haven't heard from you yet. What do you think of what Chris just said? but rather (looking at Bob): “And you, Bob? What kind of experience has he had with Pseudo Corporation customer service?" As the moderator, you determine the course of the discussion and pass the virtual microphone to everyone. You maintain control through eye contact, volume of speech, arm movements, and body orientation. Most people will be very aware of their body language, and these tips can be helpful if someone else is dominating the conversation. If an overly talkative participant doesn't understand these clues, use a soft but firm statement, such as "Okay, great, I'd like to open this thought up to others." Has anyone else experienced the same issues as Theresa? If you move on to a new, larger topic, verbally let people know that the old discussion is over and a new one is starting so people can clear their minds for the next topic. Finally, when the activity comes to an end, a simple glance at the clock and a change in body orientation can indicate that the conversation needs to end. As with any other activity, thank the group for their time. Sharing results with your team typically happens in two ways: findings are shared based on major topics covered or grouped into relevant categories, and for contextual research. Affinity diagrams can be another effective way to bring together different tendencies and attitudes to illustrate the project team.
Card Sorting In a card sorting activity, participants (working individually or in small groups) are given items printed on cards and asked to put them into groups that make sense to them. They group them into predefined categories (called closed classification) or create their own groups and give each group a title (called open classification). By the end of the card sorting round, you should see common patterns emerging in the way people sort items, as well as common areas of confusion or disagreement.
CHOICE OF INVESTIGATION TECHNIQUES
107
A common reason to do this is to create a sitemap or create a hierarchy of content, categories, and subcategories with items like articles, documents, videos, or photos. This makes card sorting a great technique if you're working on a content feed. Note See Chapter 2 for more information on content sources.
Let's say you're working on a common type of content source: the corporate intranet. Many intranets tend to categorize their information by the department that owns it, with navigation to human resources, operations, legal, marketing, etc. For long-time employees, this may not present an obvious problem, since they will likely have learned the lines of responsibility for each department and know where to find information. But for new employees, or those who need information they don't normally access, it can be difficult to find information that is (or appears to be) in more than one department. For example, where would you find a policy for signing contracts with newly hired employees? It could be legal, or it could be human resources. Card sorting helps you find common patterns in how potential users would categorize information, regardless of departmental lines. The Basic Process Collect the items you want to include in the card ordering; 40 to 60 is generally a good range. You'll need enough to create a potentially large number of card groups, but not enough to overwhelm participants with options (or overwhelm you when you need to analyze the results). Choose items that you think are easy to understand and don't contain unnecessary jargon. You can include some subject terms that you think your user groups are likely to know, but avoid too many "internal" terms. Using too many company-specific terms or acronyms (such as "the SUCCESS campaign" to increase sales) strains the effectiveness of the company's marketing and communications rather than creating a common hierarchy of information. For example, for the intranet, you can view the vacation policy, 401(k) plan information, new lease, vendor agreement, confidentiality agreement,
108
CHAPTER 6: USER RESEARCH
orientation for new employees, information on health insurance and information security policies. This list represents a clearly worded combination of items that can be categorized in different ways. You might have one participant that bundles new employee orientation and staff vacation policy, and another that bundles new employee orientation and new lease and calls it "employee onboarding." Once you have your list of items, place them on cards that are easy to group and ungroup. You can print labels and stick them on index cards, or print directly on perforated cardstock to separate them into individual cards. Try it by asking someone to sort the cards into groups and name the groups; For example, place a sticky note in the deck and write the name in pen. Ideally, the examinee should be someone unfamiliar with the items and the activity. This will help you get a rough idea of how long the activity may take. If the test is longer than an hour, you may need to cut up some cards! Once you have a complete deck, you can bring in a real player and give them these basic instructions: 1. Arrange these cards in the group that makes sense to you. 2. Try to have at least two cards in a group. If a card doesn't appear to belong to any group, you can reserve it. 3. You can nominate a group at any time during the qualification. At the end of the activity, name as many groups as possible. Some trends become apparent just by looking at the sessions. Others may need a bit more analysis to reveal. There are several tools for entering and analyzing card sorting results; many of them come with tools that allow you to sort cards by distance (see the "Card Sorting Variations" section below for more on that). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) offer remote sorting options and useful analysis tools. Or, for a more manual classification, check out Donna Spencer's excellent worksheet, complete with
CHOICE OF INVESTIGATION TECHNIQUES
109
with instructions, available at www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet. Card Sorting Variations So far, the discussion has focused on a card sort performed with an individual, where the participant is asked to name the categories he or she has created. This is an open classification, which means that the main categories are not awarded to the contestant; they can be nominated instead. This is a good approach when designing a new navigation structure or making significant changes to an existing structure. For other situations, consider these common card rank variations: Closed ranks. In a closed classification, specifies the top-level categories
and the participants add to it. The results are relatively easy to analyze because you have a small number of possible categories, and you can focus on understanding which items fall under which categories most often. Whether you're adding large amounts of content to an existing information architecture or validating an existing sitemap, closed classification can provide fast, actionable information to help you with your categorization decisions. Group evaluations. Instead of classifying individual items into groups, you can
Make card sorting part of a focus group activity in which participants work together to sort items. While the results do not necessarily reflect how an individual would group the items, you can gain a lot of information about how people feel about the items and their organization by listening to how they collaborate on the activity and brainstorming the rationale for the items. each location. Remote evaluations. Especially sorting with physical cards can be a fun activity.
for group evaluations. But there are many great tools for online rankings of individuals. This also allows you to reach a larger number of participants or specific participants who are physically difficult to reach. OptimalSort and WebSort, mentioned above, are two of the tools that allow this type of sorting online.
Usability Testing In usability testing, participants are asked to perform specific tests on a website or app (or a prototype thereof) to identify potential usability issues and gather ideas for solving them.
110
CHAPTER 6: USER RESEARCH
You can run usability tests during the Define phase to gather information on how to improve the current site. Or you can compare it to similar sites (such as competing sites) to understand some of the potential opportunities for a more user-friendly solution. Usability testing is typically done as part of the design phase, ideally in iterative rounds (where a design is created, tested, refined, and retested). In Chapter 13, "Design Testing with Users," we'll discuss usability testing in more detail; This chapter provides recruiting and planning tips that can also help you carry out the activities discussed earlier in this chapter.
After the Research After you've completed one or more of these user research activities, it's time to review the assumptions you originally made about your user groups. Put those assumptions aside for a moment and ask yourself what user groups you would create now that you have more information. If some of your assumptions above are not valid, consider any gaps in your user research because a key group is not included. If this gap is identified early enough in your survey activity, you may have time to adjust and add another set of participants to your current survey to ensure you have a complete picture. With your new knowledge, you can revise your user definitions to more accurately reflect the groups you're targeting. This will help you create more detailed tools, such as personas (discussed in Chapter 7), and create user requirements for the list we started with in Chapter 5. In this chapter, we discuss the process of obtaining and refining representations of business stakeholders. them in the requirements. You follow a similar process with users: your work doesn't stop when you capture the idea or request. Dig into the underlying needs and goals to make sure you understand them. Ultimately, this helps you design a solution that best meets the needs of all relevant user groups. In the next chapter, you'll learn how to use the insights you gain from conducting user research to create tools that can target your user groups during design and development: people.
AFTER THE INVESTIGATION
111
7
People Find the best way to put your team, or your customer, in the shoes of your users People are often a topic of discussion among user experience professionals. Opinions vary on how much content is needed, how much research is needed, and whether they add any value to projects. Some people question whether or not they belong in the process. Regardless of where you position yourself, personas can be used to help your project team and your client empathize with their users. Personas can provide intuitive control over many parts of your project—business requirements, visual design, or QA—helping you understand who your target audience is, their expectations, and behaviors. russ unger
67
What are Personas? Personas are documents that describe typical target users. They can be useful to the project team, stakeholders, and customers. With proper research and descriptions, people can paint a very clear picture of who is using the site or app, and possibly even how they are using it. User experience designers often see creating personas as a great exercise in empathy. Well-designed personas are often used as a point of contact when a question or concern arises about how aspects of the project should be understood. You can take out your people and ask: how
This chapter focuses on interactive characters.
Why should I create personas? In the user experience design process, personas help you focus on representative users. By providing insight into "real" user behavior, people can help resolve conflicts that arise when making design and development decisions, helping you and your team move forward. How real do people have to be? The answer varies a lot. A one-person document might be enough for a team, while another might create entire "living spaces" for user personas to deeply understand how they "live." You can even take it to the extreme by creating individual online presences that you can interact with to gain insight into online behavior. However, he decides to expand his personas. People can be constant reminders to your users. One useful technique is for your team members to keep people in their workspaces; that's how they are
WHY DO PEOPLE BREED?
113
they constantly remember who their users are. When he shares a cube with "Nicolle", the 34-year-old certified manual therapist from West Chicago, Illinois, for a while, he begins to feel compelled to provide her with an experience that works well for her. If she helps you, feel free to carry footprints with you while you sleep and let the osmosis fairy empathize with the pages of your pillow and your sleeping subconscious. The purpose of personas is to help you, your team, and/or your clients remove some of the confusion that can arise when you reach a decision crossroads.
Information search for personas Effective personas need to accurately represent a specific number of users of your product or website. To achieve this goal, people must be backed by research. Chapter 6 presents techniques for researching and modeling your potential users to build a strong foundation for your personas. However, don't look for a method that is the answer; it is best to find as much data as possible and combine it with a mix of observational and interview data; this may include the use of online surveys and analysis of behavior on social networks. It's a common theme when creating personas: get real data, but turn personas into real people on the pages. Check out the “Case Study: First Message People” sidebar to see how one company accomplishes this.
Building Personas Once you've identified your audience and collected data to support your personas, your next step is to put pen to paper and bring them to life. The number of people you need to create varies. In general, the minimum is three, but more than seven is not uncommon. Instead of aiming for a specific number, consider how many target segments you have and what you think is the best way to get a fair representation of them.
114
CHAPTER 7: PEOPLE
Case Study: Messagefirst Personas To create effective data-driven personas, Messagefirst (www.messagefirst.com) uses no less than three different data input sources, drawn from: Stakeholders. We interview them to find out who they think people are and what they think their behavior is. This is always included. Client's attorney. We interview people in the company who speak directly to customers, which usually means Sales/Marketing and Customer Service. Each has its biases, which we accounted for when documenting our findings. For example, the people who contact customer service most often are people with a lot of time (often retired or unemployed) or someone who is so angry with a product or service that it takes a while for them to get back to you. Customers. We speak directly to real people who will use or are currently using the product or service. This will be included where possible. Customer data sources. We analyze all blog, search and email traffic available to us. Someone we know. We choose someone we know and who fits the initial profile of the person. This helps us stand our ground by ensuring the persona is believable and realistic, and provides a real person to contact if we have additional questions. This is very important for validation and is always included. Since each data input source we use has a specific bias, we use multiple sources to normalize the data. What is important for data-driven people is not an expectation of how many people you will have, but letting the data reveal how many people there should be. When analyzing the data, I look for gaps in behaviors and activities. These spaces reveal individual characters. Todd Zaki Warfel, President of Messagefirst
The example person for this chapter is Nicolle, a 34-year-old certified hand therapist from West Chicago, Illinois. Turns out she doesn't drive and commutes 2-3 hours a day to and from work. The fictional customer is a company called ACMEblue, which makes Bluetooth headsets for Apple's not-so-fictional iPhone.
PEOPLE CREATE
115
That short paragraph says a lot about Nicolle, but as you can see in Figure 7-1, the real person contains a much fuller story about Nicolle. Please note that the content is written about Nicolle, not "by" Nicolle. It's best to write your characters from other people's perspectives and not write in their different voices, especially if you're just starting out. Of course, as you broaden your experience, you'll need to explore and find the style that best suits you and adds the most value.
Figure 7.1 Person for fictitious client ACMEblue
What kind of information goes to people? The type of information that your audience finds relevant and credible, that's the type. Based on the research data you've collected, you should be able to determine what's important to the client, the brand, and the project. Most of the personas 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 they vary from client to client, if not project to project.
116
CHAPTER 7: PEOPLE
Minimum Content Requirements When creating personas, you need to provide enough information to draw people in and make them engage with the person they're reading about on the page. To help your audience understand how your persona behaves and thinks, include six key pieces of information: photo, name, age, location, occupation, and bio. The following sections take a closer look at filling in the details for each item. Photo A photo is the first (and true) step in giving your character a face. When choosing a photo for your persona, make sure the image doesn't look too posed or polished. Photos that look posed will not have the same effect as photos taken in more natural settings. People seem to be most effective in photos taken in more natural settings, like the one on the right in Figure 7-2, where the person is outside in their winter coat, possibly on their way to work. Make sure the photo fits the person's lifestyle! raised
Natural Figure 7.2 Natural-looking photos are most effective.
There are various sources of photos online. Some of the best options are iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com), and Stock.XCHNG (www.sxc.hu).
PEOPLE CREATE
117
Finding the right photo can be a complete waste of time if you're not careful. If all else fails (or you have the time and budget), make your own! Name Simply put, you have to put a name on the face. The photo you use will humanize the combination of research data and personality traits, and the name will be the way everyone refers to you during discussions. Nicolle not only sounds better than "Professional Blonde Mom of 30," but she's also much easier to remember and associate with a specific person. Try to avoid having names that are too similar for different people on a project. For example, Nicolle and Noelle can be easily confused, so look for distinctive names. And while it may be tempting to use the names of colleagues or clients, don't. When you use names that are the same as the people involved in the project, it's easy for them to identify themselves in your personas. Choosing different names avoids awkward or heartbreaking situations. If you're having trouble choosing names, some online resources can help: baby naming websites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Popular Baby Names from the Social Security Administration: www.ssa.gov/
OACT/Baby Names Random Name Generator: www.kleimo.com/random/name.cfm
One last thing about names: make sure your name is believable to the person. Nicolle works great for a Midwestern mom, but Nicola or Natalia might be a much better name for an Italian mom. Neither do the funniest or liveliest sounding names, like Bob the Builder. They tend to make your personas look silly and can lower your value. Age While your research should identify the age range of your consumers, specifying a specific age for your persona helps add authenticity to the bio you're writing. The behavior of a 21-year-old student and a 34-year-old professional mother is significantly different!
118
CHAPTER 7: PEOPLE
Location At first glance, location may not seem like essential information; however, it is important to remember that cultural and behavioral changes can occur from one place to another. For example, in Italy different dialects are spoken in different regions of the country. In the United States, a person living in Chicago is likely to have a different cost of living than a person living in Savannah, Georgia. Occupation If you know what your person does, you can identify with it by relating to the patterns of their daily life. A person who works in therapy encounters many people on a daily basis, while a drawbridge operator may not interact much with other people. Biography The biography is the compelling story that makes the person real. This is where you provide details derived from your research data and imbue it with a bit of "real people." That is, the data is very important to the person, but you don't want to quote this information in broken sentences. Instead, you want to combine data, anecdotes, and observations into a story that your audience can relate to. It may sound a bit strange, but the bio needs to be believable, and it's definitely not cheating to bring aspects of a real person into your character. For example, Nicolle relies on both statistical data and the very real behavior of a person who shares similar activities, beliefs, and desires. Depending on her project, you may need to dig into the bio a bit; sometimes the more detail you have the better. Don't feel like you have to squeeze your personality onto a piece of paper. Choose what works best to make your character realistic and as meaningful as possible to the project you're working on.
Optional Content When working with people, you'll find that different projects require different sets of information to make people more applicable. Minimum content requirements can also be considered the least common.
PEOPLE CREATE
119
denominators of most people you will create. In most cases, you combine some of these optional content elements with your core personas. Optional content that can add value to your personas includes education level. Knowing one's education level can help a bit.
more knowledge about some of their habits. A person with a high school education may have significantly different buying habits and brand perceptions than a person with a master's degree, and this information can affect how that person is perceived. Salary or salary scale. Money talks and, in many cases, the amount
A person's income has a substantial impact on their standard of living and their disposable income. This information can provide significant insight when targeting certain levels of wealth. Personal appointment. What motto would your person claim?
like yours? This can sometimes provide a quick overview of the core of your persona's mindset. Online activities. This can be tricky; there are many ways people spend money
your time online. Some people pay their bills, some people are on blogs and social media, and some people just use their computers as a device that they turn on when they need to do a task. Since so many projects have an online component, that element is a bit of a test. You must lean on your research to paint the picture. Offline activities. Does your person have a hobby? There is more?
information about what your person's life is like when they are not online? This element can be just as complicated as online activities and can be just as important in influencing your personality. Key entry or activation point for client, brand or project. It is often important
to understand how a person interacts with the client, the brand or the project. Does the person find out about it through word of mouth, online reviews, a billboard, TV or radio, or an online pop-up ad? Does your person want to solve a problem that can be solved through the client, the brand or the project? Using your statistics to understand this point and writing it on your persona can help inform your approach to engaging users.
120
CHAPTER 7: PEOPLE
Technical comfort level. Does your person use a PC or a Mac? She does
You have a computer? Do you use instant messaging, Flickr or write a blog? Are you very comfortable with this activity or are you confused by it? Would a very simple solution aimed at a newbie help you? Have an MP3 player or other portable device? Do you use a DVR or AppleTV or on-demand shows to watch TV? The list can go on and on. Etc. Depending on your client, brand, or project, these terms, and many others, may be important to identify. Social comfort level. Given the growth of social media and social networking
work, it may be important to identify very specifically how your character engages in that particular space. Do you have a Twitter account? If yes, how many followers do you have? How active is she? Is she a leader? Do you use MySpace, Facebook, LinkedIn, or other aggregators or online communities? Mobile comfort level. As the use of mobile devices becomes more
Keeping in mind, it's important to consider what your personas are like in the mobile space, if at all. Motivations to use client, brand or project. In some cases, you may want
to include the person's reasons for wanting to use the client, brand, or project. If you constantly get your headphone cord caught in your coat and pulled off your head, that might be a good reason to consider a new pair of headphones. Real-life scenarios based on research data can help you discover the key drivers to include in your personas. User goals. You may also want to identify what the person is expecting.
achieve with the help of the client, the brand or the project. This can help to understand the person's motivations for using it. These are just data points to get you started. You can structure your characters and present them in endless ways. If you're interested in delving into the world of personas, The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web by Steve Mulder with Ziv Yaar (New Riders, 2006) is a great place to read. to start.
PEOPLE CREATE
121
Advanced Personas Once you understand the basics of creating personas, there are endless ways to extend your documents. A simple person can usually meet most of your needs, especially when your project team is just trying to gain an empathic understanding of your users. Things usually get more interesting when you introduce people to your clients. In these cases, you will often find that you need to provide much more than the information collected for the base person. Figures 7.3 through 7.7 illustrate some ways that you can expand people. Feel free to use, remix, and remix these examples to create something even better for your project!
Brand
Know the brand Consumers
PERSONAS AND SCENARIOS (based on ethnographic studies) Personas are personas created from data about your target audience: in this case, ethnography, existing segmentations, and data from the customer database.
The scenarios are hypothetical but realistic stories that describe why these people might visit the brand's website and what they would do there.
Joan, 32 Consumer insights help us understand users: their motivations, goals, and desires. To apply these insights to website design, we develop personas and user scenarios based on real-world contexts. This design approach helps create rich experiences based on understanding customers, their motivations, desired outcomes, and behaviors. The scenarios specifically answer three fundamental questions that must be answered before a site can be properly organized: Ŕ8IPBSFZPVSSFQSFTFOUBUJWFVTFST Ŕ8IBUBSFUIFVTFSōTTQFDJţDHPBMT Ŕ)PXDBOVTFSTBDIJFWFUIFJSHPBMTBOE Have a complete experience on your site
Pleasure Seeking Lovers "I Like It Very Much" "Sophisticated Young"
TO START
START EXPLORING
BUILD EXPERIENCE
"Aspiring to Novato"
"$)*&7&-&7&- VAN COMFORT
"Actively Responsible"
FEEL 5)&365
DISCOVER AGAIN
"Established Scout"
OPTIMIZE AND SIMPLIFY
"Grown in a Groove"
Practical work "It has to work"
Alicia, 26
Rachel, 42
Erik, 47
greeting, 59
Figure 7.3 Persona Overview main sheet (landscape orientation). It provides an aggregate view of various people, along with the segments they represent, in the context of a high-level organizational strategy. Thanks to Will Evans.
122
CHAPTER 7: PEOPLE
Brand
PEOPLE AND SETTINGS (based on ethnographic studies) Alice is a budding chef who aspires to explore the world of food,
GOALS
especially children's food, with friends and looking for new recipes online and in magazines. Your exploration is more about
feed your family without thinking or trying too hard
fantasy than reality She's still intimidated and not
find quick and easy recipes with basic ingredients
try many new recipes. His mother didn't pass on many culinary skills to him, and his friends don't have much experience.
make (often) two types of meals: for adults, for children
kitchen too. Alice is a busy mother of a daughter in Chicago. Both she and her husband work outside the home: she runs the office of a small insurance company.
Alice, 26th generation "wannabe newbies" x married
1 daughter, 5 tired, ambitious
income
Education
She's busy, practical, and doesn't spend a lot of time cooking. Alice just wants it to be quick and easy, even though she often has to cook multiple meals for herself and her husband since she started her fitness regimen two years ago after having Sophie and is trying to get back in shape for the marathon. She works with a small set of hit recipes that she is comfortable with, and many of the meals she prepares are based on packaged and prepared foods.
SCENE Alice watches Cartoon Network with Sophie over breakfast. Here is a brand commercial with a brand name. Alice is scarred and thinks Sophie would eat that dish. She decides to check the website for job openings. Alice visits the site for a free half hour before a meeting. The home page is clear and well organized. She sees the most important parts of the site and links to interesting things, like a recipe of the day.
Internet use
health awareness
cost sensitivity
Click on the recipe of the day. She likes the included tips - they make her feel like she can handle this recipe. You like clear navigation, unlike other sites where you often get lost. She likes the useful features beyond what she sees in cookbooks, like the ability to find recipes based on what's in her pantry and tips on how to use the products. Alice discovers that she can receive recipe newsletters and clicks "Sign Up". Signing up is very easy! She fills out basic information and selects the "Foods Your Kids Will Love" newsletter.
You'd like to add more of your own twist and recreate the dishes you like to eat at restaurants, like your all-time favorite Jamaican chicken. You would also like to add more fresh vegetables to your meals because you know it is healthier. She prides herself on being a thorough planner and being able to run her household on a shoestring budget. Her refrigerator and pantry are always stocked. She plans her purchases to take advantage of promotions and coupons.
find kid-friendly recipes and cooking activities find ways to "dress up" your favorite ready meals PROJECTS AND INITIATIVES improved navigation and information architecture improved enrollment
A week later, over lunch, Alice finds her first brand e-newsletter: “Pizza, easy as 1, 2, 3”. Perfect: her kids love pizza and she usually buys them frozen pizzas. There's a link to "Pizza for Beginners" that inspires her to see if she can make pizza herself. Her link takes her to a recipe for a pepperoni pizza in something called "Pizza Wizard". She looks at the recipe and sees that it is quite simple; only 25 minutes and 4 ingredients. She checks her kitchen to see what she has. She doesn't have pepperoni or pizza sauce, but "Pizza Wizard" suggests replacing them with things she has in her well-stocked kitchen: sausage and ketchup. It is perfect! There is a link to a coupon. Neena prints out the shopping list for the recipe, adds a few things she needs too, and heads to the store. Back from the store, Alice begins. She sees step-by-step instructions for rolling out the dough and adding the ingredients. There are photos at every step. It is easy to understand and follow. She wonders if she should cook the ingredients first, but the pizza FAQ answers her.
contextualized fringe information more targeted newsletters recipe assistant better coupon integration MEAL PLANNING “make it” attitude relies heavily on prepared meals, with relatively little added fresh fruit and veg spends more time looking up recipes than actually cooking them
Figure 7.4 Audience character (horizontal orientation). This detailed view of a person contains a broader spectrum of data and provides a more complete perspective on user goals, needs, and behaviors, all defined within a larger ecosystem. Thanks to Will Evans.
Figure 7.5 Overview of audience objective and personality (vertical orientation). The destination view on the left provides high-level summary information and shows the brands that the three people are interacting with and engaging with. The detailed description to the right provides an overview and biography of a single person, along with information about their behaviors and motivations.
ADVANCED PEOPLE
123
Paul and Helen “I think we can put anything. I'm not sure how much will fit.
5 4
Helen's mother passed away a few weeks ago and now they are starting to clean up the house. They plan to sell the house, but first they need to clear up a few things. The house also needs a reform in the main bathroom.
3
- from The basement is full of things that Helen's mother has collected in the last two years. She never threw anything away. She has Time magazines and newspapers from the last 20 years. There are some things that Helen wants to keep. Most of the clothing - "necklace" and furniture will be donated to Goodwill. Unfortunately, most of her mother's edible dishes have been spoiled by water and mold. She also has cans of paint, but Paul and Helen don't know if the paint contains lead or not.
2 1
D
on
ain
Know 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 ifees D E ecven lu tte t Year Re rding pe Waste Taxa em Buars dsine Price en O Rec am nlin ycline ac g count
This is the first time Paul and Helen have experienced anything like this. They don't even know where to start. They just want this to be as easy as possible. They know they need a dumpster, but aren't sure how much it can hold. And they assume that almost anything can go to waste unless someone says otherwise. Your only other concern is that the containers are often ugly. They hope to find a company that won't make the front yard look like a construction site or ruin the backyard by dumping or picking up trash.
Age: 24-65
january life cycle
Julio
December
Mes
1.0 Life event
Main features Ŕ Ŕ
One-time event, such as the acquisition of a family property or a minor renovation (for example, bathroom). Little to no prior experience purchasing a trash can.
Throats Ŕ Ŕ Ŕ Ŕ Ŕ
Quickly get a trash can. Get rid of anything they don't keep or donate. Avoid property destruction in the process. Avoid an ugly disaster. Promptly dispose of trash once it is full.
Points of frustration and pain Ŕ Ŕ Ŕ Ŕ Ŕ
Questions Ŕ Ŕ Ŕ Ŕ Ŕ
Vaya
Available when needed Price Vendor leaves item as found Container size required Quick setup and pick up once contacted Online account access for booking and payment Equipment quality and cleanliness Family brand
Ŕ ŕ ŕ ŕ
First label impact I am not familiar with the process I don't know what they don't know Do an apples to apples comparison between vendors
Is there something you can't get into? How fast can you deliver and collect? Will they leave the property in the condition it was originally in? How does this work? Is a permit required? How much does it cost? How easily can I contact someone if necessary?
Figure 7.6 Person target group. This person presents a target age group, developed on the basis of research data. The information it contains is broad and is intended for audiences, not specific individuals. This approach can be useful when you are giving a business presentation or when the client's budget allows for detailed persona scanning. Courtesy of Todd Zaki Warfel.
The Jill of all companies
amanda steen
5
"I need to manage multiple programs for my clients."
4
3
AMANDA SHARES THE RESPONSIBILITIES OF THE INCENTIVE PROGRAM WITH SOME COLLEAGUES. They share access and manage multiple programs for clients. It can be especially difficult to make sure you're paying the right people in the right program. You need to be able to switch between different programs and always know where you are.
2
1
Life expectancy
Main characteristics Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ
Manages multiple programs Medium to large businesses Moderate volume (50+ up to 2,000 orders at a time) Multiple people sharing a 70/30 role Quick payout and admin checks Weekly or bi-monthly usage year-round Highly interested in reporting Wants to run reports Heavy Excel programs use a custom internal system to communicate with
Throats Ŕ Ŕ Ŕ Ŕ
Integration with the current system. Ability to pay employees quickly and easily. Cost (mainly time). Guided assistance.
Other applications Ŕ Excel Ŕ PowerPoint How do I run reports in all my programs? To Internet Explorer Is there a way to get my credentials without calling Ecount? Somehow we can integrate with ClientZone so we don't have to switch between different apps as often. Am I doing the right thing?
Ac FT N c ew o P n Cart Zo d Rene quest E Ad asy s m Pijny Che c R Cu eps of enrting tB al Pence Cu oplestom Soft System Excel
nc e
January
influential people
Pay employees quickly and easily. Ŕ Avoid duplication of efforts. Ŕ Check your current balance to see if you need to transfer money. Ŕ Track weekly, bi-monthly, monthly, quarterly and yearly transactions.
río
no ex
Hola
O
dg
dg e ow Kn
he knows
y etc.
on
hn
D
He uses Account Zone quite regularly, several days a week. And since she manages several shows, she's quite active year-round.
Activities and Interests
Te c
Age: 28-55
mi
mi
Knowledge
ain
Account Zone really helps you issue new cards and make sure program participants get paid quickly. The only thing missing is the ability to view each program as well as all the programs that are running to see how it is doing. Your clients like to monitor the performance of the program. Now she keeps track in Excel. At the end, he sends the excel file to his clients or sometimes exports it and sends a PowerPoint with some nice pictures. If Account Zone had a way to run its reports in individual programs and between programs that would be really cool.
Julio
Ŕ ŕ ŕ ŕ ŕ
R
R
R
R
Mes
Frustrations and pain points
Ask -
December
It is not possible to examine several programs at the same time. It is not possible to run reports in more than one program at the same time. The bug fix in the receipt file "sucks". It is not clear what the exact problem is and how to solve it. Multiple steps with multiple applications are inefficient and make it easy to "get lost" where you are. Multiple confirmation screens. Another username and password to remember. Search email with your credentials.
Figure 7.7 Person from individual target groups. This person is a strongly data-driven model. While the daily story is one story, the rest is listed in bullet points to serve as a design checklist. The diagram is used to communicate a significant 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 present characters and adapt them to different situations. Start with the basic persona and expand it to fit your needs.
Final Thoughts on Personas Many professionals in the world of user experience design do not believe that personas accurately articulate the needs, goals, and attitudes of users. They believe that people can get in the way of creativity, innovation, or good design for a variety of reasons. Other professionals believe that people fulfilling a specific need influences the design process in a very positive way, when based on solid research data and mixed with a dose of personalized reality. Which side of the coin you end up on is completely up to you. This chapter is not intended to influence your decision in any way. There are many articles available online on this subject, and many professionals are willing to give their opinion. All of these resources can help you figure out how people work best for your projects, so look them up. Jared Spool, CEO and Founding Director of User Interface Engineering (www.uie.com), also offers insight into the theme: That value arises when the team visits and observes its audience, absorbs and analyzes their observations, and reduces chaos. into patterns, which then become people. What the team thinks when designing is what will make the difference in the final project. The character descriptions are there to remind everyone of what happened.
Jared's point is simple: By looking at your audience, combining what you learn with research data, and synthesizing it all into segments, you should be able to create personas who generate the kind of empathy that will keep your team on track. the best app, website or product possible. Ultimately, though, his characters will be a lot like Santa Claus: they're only as valuable as people believe in them.
FINAL THINGS ABOUT PEOPLE
125
8
User Experience Design and Search Engine Optimization The Key Role of User Experience Design in Successful SEO Search engines are the cornerstone of the interactive economy. Everything we do as "interactivists" is connected to the world at large through Google, Yahoo, MSN, Ask, and the countless smaller search engines that provide the infrastructure for finding things online. Information architecture is a crucial part of how search engines interpret websites. This chapter is intended to give you a basic understanding of why UX design is critical to search engine optimization and what you need to consider so that the environments you create stand a good chance with Google. jonathan aston
67
Introduction to SEO Simply put, search engine optimization is the process of developing and maintaining a web resource with the intent of achieving and maintaining the top rankings on public search engines for specific key phrases. Search Engine Optimization (SEO) is like a martial art, a process of learning and doing that never ends. Even a teacher can go further with observed behavior or a learned method. As long as there are search engines and websites interested in selling something to search engines, search engine optimization will play a role. SEO relies on three key areas for improvement and influence: The Critical Group of Things The Professional User Experience Designer
may affect the infrastructure, technology and organizational principles of the content of the site and all keyword problems associated with the optimized words that
search engines can see links or link popularity – the quantity and quality of links pointing to your
site of other sites, as well as the organizational structure of the links within the site. Let's break each of these three areas apart and look at them from the UX designer's point of view, to better prepare you for the optimization challenges ahead.
Why is SEO important? It is interesting that even today we have to explain the relevance of search engine optimization. Clients tend to understand at some level that it's important for their websites to attract targeted visitors through the natural search results of major search engines, but beyond that, it's difficult for most interactive marketers. understand the impact that SEO can have. Global search volume data is available from a variety of sources, but the important thing to understand is that regardless of the source, the numbers are simply huge and the year-over-year increases are always in double digits. For the most part, global search volume increases every quarter. When Google first launched in 1998, 10,000 searches per day was a huge volume and an incredible burden on the beta version of the system.
INTRODUCTION TO SEO
127
Hitwise (www.hitwise.com) reports that Google and its affiliates (including AOL and YouTube) perform the most searches worldwide, with nearly 72 percent of US searches performed in November 2008. Yahoo is a distant second with nearly 18 percent, with MSN and Ask.com at 4 and 3 percent, respectively. Internationally, Google is even more dominant, with a market share of over 80% in many markets. Note For more information on the early days of Google, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), in 2008 easily more than 60 billion searches per month were made worldwide by 750 million people, with more than 18 billion searches in the United States alone. In other words, 95% of Internet users use a search engine at least once a month, with a global average of more than 80 searches per month.
Aside from these remarkable volume numbers, what does this mean on a practical level for interactive marketers? Simply put, if you don't reach your target customers when they are searching for your products or services, your competition will have an opportunity to sell to them. Look at your website analytics and think of the question this way: how much more revenue would the website generate if there was a 10% increase in strategically targeted traffic? How about a 100 percent increase? Or 1000 percent? If your site does not generate significant traffic from natural searches, then SEO is a must. A small investment in SEO can pay off, especially if your interactive marketing efforts thus far have focused on buying clicks through sponsored listings. We've seen websites get a 35-to-1 return on monthly SEO costs. If you're paying search engine companies for sponsored listing traffic, but not investing in natural traffic, you're actually limiting yourself to 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 a search result? Any discussion of why SEO is important and why it is here to stay could go on for several chapters. Suffice to say, Google is only going up, and effective interactive marketing must include search engine optimization as a core component of competent execution.
128
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
Specialization in the most important basic functions results from a complete education. The professional who only focuses on his specialty loses perspective of everything that surrounds him. Therefore, it is imperative that every interactivist spends at least a few minutes learning about SEO. While there are no official guidelines, Google has been kind enough to provide some very important resources. If you are interested in getting better search engine performance from your efforts, check out these links: Help for Webmasters/Site Owners: Search Engine Optimization:
www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35291 Help for Webmasters/Site Owners: Webmaster Guidelines: Quality Guidelines:
www.google.com/support/webmasters/bin/answer.py?hl=en-US&answer=35769 A Beginner's Guide to Search Engine Optimization:
www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf If that's not enough, dive into newsletters and blogs. Start at SEOmoz.org and dig deeper. Just remember, like anything else in life, if it sounds too good to be true, it probably is.
Site Technology, Design and Infrastructure Search engines are essentially Web 1.0.5 technology that is firmly established in the Web 2.0+ world. The search engine premise has changed little since World Wide Web Wanderer was launched in 1993 to search the web and build the web's first search engine. Essentially, every search engine has an application, known as a crawler, spider, or bot, that finds and follows links and sends a copy of the resources it sees to the database. The database is then analyzed according to the search engine's own algorithm. With these rules, a web part is indexed and ranked based on its score in the search engine's specific scorecard. In this rather simple process, there are numerous pitfalls for the UX designer.
SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE
129
Understanding these fundamental relationships will help you see your site through the eyes of search engines. An optimized website has a structure and technology that make it easy for search engine spiders to move. Similarly, many decisions about how to handle content determine how well search engines judge the resulting efforts. As a result, much of this is predetermined by wireframing decisions and the discussions that take place about how content should be designed and managed.
Flash, Ajax, JavaScript and other scripted content Today's dynamic and interactive web design is based on technologies that are far from being search engine friendly. There is a growing gap between what search engines can see and what designers can do. It is up to the UX designer to ensure that strategic plans are in place for design-intensive and dynamic websites so that both search engines and users have the best possible experiences. Having a fundamental understanding of how search engines interact with this type of content will help you decide when to implement it and where to compensate for its weaknesses. Creating an optimized website that relies heavily on scripted content is quite possible if the right trade-offs are made early in the process. It is significantly more difficult to create static or indexable content once the site is built and published. So make a strong case for static content based on usability and in favor of search engine crawlers. It may seem like extra work at first, but the return on investment is exponential. Flash Flash content is technically "indexable." There have been some recent advances in the ability for search engines to scan Flash files to find text and links embedded in these assets. Although this content is indexed, have you ever seen an all-flash resource at the top of search results? Probably not, because it's risky for search engines to open up to full Flash support. Let's assume that search engines can fully see all links and embedded text content in SWFobject. What prevents an unethical optimizer (or "black hat") from placing apples on object text layers during rendering
130
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
oranges for the human user viewing the fully compiled assets through a browser? How can you deep link to a Flash resource without it being fully compiled? These fundamental vulnerabilities will persist until search engines reach a certain level of artificial intelligence that can tell that an image is an image of a horse without accompanying text that says "this is an image of a horse." To design a search engine friendly Flash site, you must add a static content layer that duplicates the Flash content. In addition to the needs of search engines right now, a static content layer is key to meeting usage requirements. Think of the search engine as the person viewing web content through a dial-up connection or using a screen reader browser. These people are perhaps the lowest common denominator, and it is possible that the strategy behind web development is reducing this very small percentage of human users. But if you ignore those handful of people, you are also ignoring GoogleBot and Yahoo Slurp, the two most important visitors to your website, as they are the crawlers that major search engines use to index your website. If there are no text words or search links visible to search engines, your content inevitably cannot be found via meaningful search results. A static layer can be done in several ways. To meet search engine requirements, the static content layer must reflect the Flash content. This is not an opportunity to show search engines anything other than what is built into Flash; if you do, you violate the spirit of the game and are squarely on the dark side. The ideal way to enclose Flash content in a static layer is to use SWFobject so that Flash and static content can be on the same URL. This allows the search engine to find static content and allows the Flash browser to display animations instead of static content. If possible, do not retarget to maintain the popularity of links pointing to Flash content. Google Code provides a simple set of instructions for implementing this straightforward piece of JavaScript at http://code.google.com/p/swfobject. There is another option that works on the gray side of SEO. Cloaking might be a dirty word for SEO purists, but if you approach the following challenges from the right side, you might as well enjoy them.
SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE
131
Cloaking uses user agent detection, which detects search engine crawlers when they visit a website and directs them to static pages for indexing. But when a human visitor sees the same page in the search results and clicks the link, the site detects that the user agent is a human with a Flash browser and presents that person with the dynamic experience at a completely separate URL. . The end result is still the same as with the SWFobject method: you should show search engines exactly the same things in your hidden content that you see in your Flash content. Ajax, JavaScript, and other scripted content Ajax is a powerful controller for web 2.0 content and gives web developers the ability to create content without pages. However, the problems search engines have with Ajax are numerous and require good planning to avoid major mistakes. Ajax stands for Asynchronous JavaScript And XML, indicating the difficulties search engines have with this technology. In principle, search engines cannot handle JavaScript; the efficiencies JavaScript provides for developers are the problems search engines have with dynamic content. An additional problem search engines have with Ajax is the asynchronous nature of the technology. A search engine can only see the content on the first load of the page, and any content loaded via a script that occurs after the first shell load is not visible for indexing. Since Google can't extend a session after the first page loads and doesn't have a mouse or external agent to launch a script, all non-page content activated by the user is invisible unless the content text is included in pre-shell.load. It is up to the UX designer to ensure that the 3D modeling required to structure the pageless layout includes the requirement that text and links be pre-loaded into the page shell. Everything else, and the cool design is invisible. Scripted Navigation One of the most common problems that gets in the way of optimization is the use of JavaScript in the core of site navigation. This is a very common condition and is a result of the way many website development and content management tools work. Scripted browsing looks better, so people are often interested in using it. But if JavaScript is the technology that drives navigation on the website, the result is that search engines cannot build a good model of the link.
132
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
Links on the site: They simply can't see the link structure of the site. And if search engines can't model the link relationships on the site, the deep content will be invisible or won't get the right link popularity.
Content Management Systems Content management systems are designed for people's convenience, but many of these systems make it difficult for search engines to process their output. Here are some typical issues to avoid, whether you use workarounds or choose a more searchable content management system: dynamic URLs. Search engines do not understand a "page" of content; this
understands the path to that content. A change in the path or URL leading to that content causes search engines to accidentally clone the content multiple times. This condition significantly hampers a site's ability to do well. If your content management system has a system that creates session IDs in URLs, you could be in serious trouble. Track with mature analytics, not session ID. Multiple URL paths. A typical content management problem for eCommerce
The management is that as a product goes through its life cycle, it accumulates multiple URLs. Again, because the search engine can only understand a page of content based on the URL where the content was found, a product that appears in a category and is part of a gift basket and is a weekly special (and so on) soon you will find search crawlers following many different links to find the same content. Do what you can to ensure that each piece of content only exists at a single URL, and that multiple paths truly depend on a single URL, regardless of where the links are implemented. Count on mature analytical systems to analyze channels. accidental cloning. When you realize that many
content should only be accessible via a single URL path, it's easy to see other conditions in content management systems that cause content to be inadvertently cloned. Suffice to say that the architecture should only have a single URL path to a single piece of content. infinite loops. A corollary to the issue of accidental cloning is the
finite loop. Make sure you don't trigger search engine spiders
SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE
133
a potentially endless task of following "next" links in a calendar or similar situation. If the search engine spider can go through a next link to the next day on a calendar where it can find another next link, it will follow that link to the next page, and so on. Avoid this type of situation by using a scripted link that search engines can't follow, so that the crawlers can spend their time on the content you want to index. Old URL structures. The first thing that many website remodeling projects involve
ects to do is replace the old url structure. The problem is that search engines have probably already indexed the content at those old URLs, and once you change them all, you're essentially sending your indexing back to square one. Also, all the deep links that the site has accumulated over time refer to the old URL structure. Keep as many old URLs as possible at all costs. Replacing your content management system will likely require you to change all the URLs, so if this is unavoidable, I recommend giving the old URLs the status code "301 Permanently Moved" and redirecting them individually to the old URLs. to the new URLs. The 301 redirect is the only acceptable redirect for search engines.
Domains, Directory, and URL Structure Matter If you're starting from scratch and brand restrictions allow, try selecting a domain that contains one or two keywords. These days it's hard to get a .com domain with quality keywords, but if you do, separate those keywords with hyphens. An important part of how UX affects SEO is the directory structure of a website. It has a crucial impact on how link popularity is distributed on the site. Simple is better. Avoid foreign files in the directory structure at all costs. Some content management systems automatically insert a subdirectory; avoid this if possible. This condition weakens the relevance of the entire site. Search engines understand the site hierarchy based on how sitemaps are structured, so make sure the most important directories are at the top of the architecture. If your environment allows it, use keywords in the URL structure that are relevant to the part of the site. Separate keywords with a hyphen and
134
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
don't use too many keywords in a file name. Go to something like this: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure you have configured redirects to http://site-in-question. com to 301 Moved Permanent redirect to http://www.site-in-question.com. If a site resolves with and without www, search engines (especially Yahoo) will index the content at both URLs, opening the entire site up to accidental duplication. This condition tends to propagate when a third party connects to the site without www and the site contains a dynamic link structure.
Content: The King Past (and Present) and Future While content generation is someone else's problem, the foundation laid in site architecture has a lot to do with getting the content right for search engines. As with all forms of keyword-based research, you need to understand the actual search behavior of people looking to view an article. Search engines are still very "primitive" because they rely on users typing keywords in order to connect them with items more or less relevant to those words. Picking the right phrases is all about making your site relevant in the right context. In a perfect world, your SEO partner will provide you with a set of keyword objectives before you begin and work with you through the schematic creation process. If you don't have a competent partner involved in your process, read the AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) and do some research on the actual search behavior of people who They explore your category. Then spend some time on that element to discover the phrases potential customers are searching for, and use those phrases as needed throughout your site. Search engines look for keywords in many places when analyzing a website. Optimization depends on making sure the right words are in the right places. By understanding the role of keywords in the UX design process, you establish the necessary framework to enable future success.
CONTENT: THE ANCIENT (AND PRESENT) AND THE FUTURE KING
135
So why is content king? It is the core of what a website should offer. Search engines need text content that they can see and index. Website visitors need compelling content that deserves their attention. Bloggers and webmasters need link-worthy content. Without the right content in the right places, search engines can't bring the right visitors to your website.
Naming conventions and the battle with jargon It is essential that keyword objectives are reflected in the taxonomy that is developed for a website. Using keywords in the main structure of the site makes the entire site more relevant to the things you sell. If you sell widgets, don't call the online product listing Catalog, but Widget Catalog. Similarly, use your keyword research to make anti-jargon decisions. For example, use the words laptops instead of laptops in your structure, because people search for laptops 10,000% more often than laptops.
Metadata, Headings, and Keywords It's remarkable that we've gotten this far in the chapter before getting into basic metadata issues. There are tons of meta tags out there, but only a few of them really pack much of an impact, since all the others are prone to spam. The relevant tags are these: Page title. Please note that this is not the label, but it is the
Real