A Project Guide to UX Design - PDF Free Download (2023)

UX A PROJECT GUIDE TO

DESIGN

FOR USER EXPERIENCE DESIGNERS IN THE FIELD OR IN THE MAKING

RUSS UNGER AND CAROLYN CHANDLER

PEACHPIT PRESS

A Project Guide to UX Design: For user experience designers in the ﬁeld or in the making 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 To report errors, please send a note to [emailprotected] New Riders is an imprint of Peachpit, a division of Pearson Education. Copyright © 2009 by Russ Unger and Carolyn Chandler Acquisition Editor: Michael J. Nolan Project Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laﬂamme Copyeditor: Leslie Tilley Proofreader: Suzie Nasol Compositor: Danielle Foster Indexer: Valerie Perry Cover design: Mimi Heft Cover production: Andreas deDanaan Interior design: Mimi Heft

Notice of Rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on getting permission for reprints and excerpts, contact [emailprotected]

Notice of Liability The information in this book is distributed on an “As Is” basis without warranty. While every precaution has been taken in the preparation of the book, neither the authors nor Peachpit shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it.

Trademarks Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Peachpit was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identiﬁed throughout this book are used in editorial fashion only and for the beneﬁt of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation 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 Project Guide to UX Design If Russ Unger and Carolyn Chandler were magicians, the Alliance would be after them for revealing their best secrets. Fortunately for you, they’re not. Russ and Carolyn have collected up sage wisdom previously only known to the most experienced UX project leaders and codiﬁed it for all to see. Now you can learn the secrets necessary to running great user experience projects. Jared M. Spool, CEO and founding principal of User Interface Engineering

Is there one book that can tell you everything you need to know about designing user experiences? No. Is there a book that get you most of the way there? There is now. Carolyn and Russ have laid a solid foundation for planning and managing design projects. This is an essential handbook for anyone mired in the competing methodologies, the endless meetings, and all the moving parts of user experience design. Dan Brown, author of Communicating Design

This book is a fantastic introduction to how to design great products for real people. But it covers much more than just design—it also includes all the things around design: managing projects, working with people, and communicating ideas. A great all-rounder. Donna Spencer, author of “Card Sorting: Designing Usable Categories”

This is a practical, accessible, and very human guide to a very human activity: working together with people to make great things for other people. Steve Portigal, Portigal Consulting

If you’ve heard of Wil Wheaton the author, you understand why I hold Russ Unger in such high regard. Russ’s experience and guidance was fundamental to the construction and design of Monolith Press, and he’s been one of the most valuable collaborators I’ve 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 come close to being completed without the support of my family, friends, colleagues, and a host of people who were completely unknown to me prior to typing the ﬁrst few keystrokes. My beautiful wife, Nicolle, who willingly and knowingly married a geek with an overachiever bug, managed to double up on parenting duties throughout most of the writing of this book. Our daughters, Sydney and Avery, often poked and prodded their near-comatose father to life to get him to dance, sing, and play Spore. I unwittingly thought that writing a book with a newborn in the house would not be that big a challenge. I quickly learned otherwise. And Nicolle stepped up to bat, time and time again, to rescue me and allow me to have the focus that I needed to complete this project. She’s the hero I rely upon the most; she keeps our house in order amid the chaos. She’s the center of our world here, and she lets us all off the hook entirely too easily. Nicolle, along with Sydney and Avery, manage to make me look like a pretty good father, and I’m grateful for that. I live in a house with three girls, and I couldn’t imagine loving any of them with anything less than all I have to give. Carolyn kept me on track. There were times when it seemed that this project would never begin or end. She always kept things moving, explored ideas, and moved us in the right direction. The collaboration has been great, and I’ve learned a lot through this! She’s deﬁnitely a great UX yin to my UX yang. Michael Nolan was our acquisition editor, and he has been the perfect guide. Michael is honest and kind, and he has really helped to keep things moving smoothly. Rebecca Freed has been the juggler, managing every aspect of the book, keeping us on task, and often sending e-mails to us late, late at night. Sadly, she often got near-immediate responses from me! Linda Laﬂamme was our development editor and once I got used to her Red Pen of Doom, it was pretty clear that was she steering me in the right direction, no matter how hard I tried to drown her in incomplete thoughts and run-on sentences. Leslie Tilley gave the words a ﬁnal polish; Tracey Croom brought production, layout, and graphic elements together; and a real book appeared. Steve “Doc” Baty read every chapter before it ever saw light of day in the Peachpit offices. I would often send Steve chapters around 2 a.m., and he iv

ACKNOWLEDGMENTS

would send his feedback by 5 a.m., which is no small feat. Mind you, Steve’s in Australia, but it’s impressive nonetheless. Without Steve’s constant willingness to help and his quick turnarounds, it’s hard to believe that this book would have found its way to a shelf. Brad Simpson (www.i-rradiate.com) took all the graphics I threw at him and turned them into beautiful, print-ready images, often while juggling his own life with two teenage sons and a busy work schedule. It would have been easy for Brad to walk away at any time, but he’s a true friend who had interest in the project and wanted to support me. I’m not sure there will be enough steak dinners to pay back this effort, but I’m going to work hard to get there. Thank you, Brad, for giving up many of your days off and late nights to supporting this. Mark Brooks found me in panic mode a few times as I was trying to convey messages that required a visual component beyond my time and/or capabilities. Mark jumped in and saved the day on more than one occasion and I’m indebted for this. Talented and giving of himself to a fault, Mark is the type of person I aspire to be. Jonathan Ashton wrote the entire chapter on search engine optimization for us. After 5 minutes of talking to Jonathan, I knew he was the right person for the job. His chapter alone is a great reason to buy this book, and it’s been great to have him on board. Jono Kane jumped in at the last minute and on a moment’s notice. Jono is a Web developer, interaction designer, and prototyper at Yahoo and was invaluable in his support and assistance in authoring Chapter 12. Lou Rosenfeld really helped get this ball rolling. Besides coauthoring the famous “Polar Bear Book,” (O’Reilly’s Information Architecture for the World Wide Web), Lou is brilliant, kind, approachable, and always willing to help others in our ﬁeld. You’ll be hard pressed to ﬁnd many folks as generous of self as Lou is. Christina Wodtke helped make introductions and connections for me. Without Christina, I’m not sure where we’d be today, but it probably would not be “in print.” Besides being an “author that you should read,” she’s someone who has always been available to give advice and provide insight. Many in the UX design ﬁeld owe a lot of what they know to Christina’s tireless efforts to expand our horizons by constantly innovating. ACKNOWLEDGMENTS

Will Evans and Todd Zaki Warfel generously supplied high-quality deliverables that you can use as templates for your own deliverables. They were true bro’s, and gave of their time and talents without question or concern, often at a moment’s notice. They are great members of our UX community— ones you want to know and work with—and I’m blessed to be friends with them. I certainly cannot do justice to the debt of 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 gang at crowdSPRING), and Wil Wheaton served me well as good friends and true supporters and believers. I’m fortunate just to be able to type those names together as a list of people I know, and I’m a big fan of everything that they do. Their support has been an immeasurable beneﬁt to me in all that I do. These ﬁne folks went out of their way to help me, generously contributing input, anecdotes, and access to their resources, and I wholeheartedly thank them: 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.nickﬁnck. com), chapter 10; Jesse James Garrett (www.adaptivepath.com), chapter 10; Austin Govella (www.grafoﬁni.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 Brief 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 Lucht (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 Brief 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 Brief Guide to

ACKNOWLEDGMENTS

Meetings”; 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.messageﬁrst.com), chapters 7, 12, and 14. I also would like to thank Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest of SXSW, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw, and Paula Thornton—as well as the Manifest Digital folks and everyone at Draftfcb. It is inevitable that I’ve missed someone, and I hope it is not taken personally. There are an abundance of folks in the “crowd” that were sourced, and I have tried to keep track of everyone. If I’ve missed you, let me know and I’ll ﬁnd a way to make it right! Finally, it is important to note that without organizations like the Information Architecture Institute, Interaction Design Association, and others, it would have been impossible for me to make the connections with many of the people mentioned. If you’re at all curious about the ﬁeld of UX design, go explore these organizations, join them, and get involved!

Carolyn Chandler A lot of us dream of writing a book at some point in our lives. Without Russ, I don’t know if I ever would have gotten the motivation to jump in and do it. His energy and enthusiasm helped us ﬁnd the right people at the right time, from the Peachpit team to leaders in the UX industry, all of whom have had a huge impact on what you see in these pages. He’s truly one of the great connectors in our ﬁeld, and he thrives on bringing people together day and night. Plus, I think he posts more tweets in a single day than I have since I joined Twitter! Russ has thanked many of the people who helped us both immensely. I won’t repeat all those names other than that of Steve Baty, who read all of our chapters in whatever raw form we could throw at him and still managed to sound enthusiastic at 2 a.m. (his time). John Geletka also provided thoughtful feedback and intriguing discussions with a spark and a perspective that crosses several disciplines. And of course, the Peachpit team; I’ll never forget getting my ﬁrst chapter back from Linda Laﬂamme. It wasn’t pretty (though she delivered the suggestions with great tact). She patiently

ACKNOWLEDGMENTS

vii

took me through the edits and helped me improve my ﬂow, which was originally more suited to writing one-off white papers than a full-length book. Now, I even ﬁnd myself adding transitions into my casual conversations with colleagues! Speaking of which … Christine Mortensen, a.k.a. Morty, was my partner in crime when it came to the visual elements. The icons and diagrams you see in my chapters are a result of her hard work—and I know how hard, because she and I were working on many of the same client projects at the same time that we were trying to meet chapter deadlines. Morty is one of those visual designers who can plant her feet solidly in both visual and interaction design, cheerfully collaborating with everyone on the project and bringing concepts to vivid life. She has an integrity and a focus on quality that make her a pleasure to work with, and it’s been an honor to have her as a partner on this. Many thanks also go to all of the folks at Manifest Digital, who have been so supportive during the past few months. Jim Jacoby brought a special blend of business savvy and UX perspective, with his trademark zenlike calm, which got me through some stressful moments. Jason Ulaszek is one of the most enthusiastic people I know in the UX ﬁeld, and he has an endless knowledge of tools and techniques; I have no idea where he makes room for it all! Also, Brett Gilbert and Jen O’Brien provided valuable input into some of the many roles that collaborate with UX designers. I’d also like to thank the members of the Manifest UX team, who have provided inspiration and who have been so patient with my constant references to progress on “the book”: Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. You are a constant joy to work with. Every day I appreciate your humor and insight. To my fellow members of the Interaction Design Association, thank you for sharing your experiences and for being active members of the UX community that I love. In particular, I’d like to acknowledge Janna Hicks DeVylder and Nick Iozzo, who were key in the development of the Chicago chapter and who continue to ﬁnd new ways to grow a vibrant network of smart people. Last but not least, I want to thank my family, my friends, and Anthony, who have all borne with my disappearing act patiently and kept checking in to make sure I was still alive. You have a lot of rain checks to cash in, and I look forward to spending them with you!

viii

ACKNOWLEDGMENTS

Contents INTRODUCTION

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

CHAPTER 1: The

Tao of UXD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What Is User Experience Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The Broad Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Don’t Forget the Tangible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brand Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Marketing Campaign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Content Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Task-Based Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 E-Commerce Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-Learning Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Social Networking Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Choose Your Hats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Information Architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 User Researcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other Roles You May Play or May Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Building a Network of User Advocacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Understand the Company Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Pulling It Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CHAPTER 3: Proposals

for Consultants and Freelancers . . . . . . . . . . . . . . . . . . 39 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Creating the Proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CONTENTS

Title Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Deliverables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ownership and Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional Costs and Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Project Pricing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Acknowledgment and Sign-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Statements of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 CHAPTER 4: Project

Objectives and Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Solidify Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

How Can a UX Designer Help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Understand the Project Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Waterfall Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Modiﬁed Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 How Does the Approach Affect Me?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 CHAPTER 5: Business

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Understand the Current State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Gather Ideas from Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Outline Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Gather the Right Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Create a Plan for the Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Requirements-Gathering Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Run the Meetings Effectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Coalescing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

CONTENTS

CHAPTER 6: User

Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic Steps of User Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Deﬁne Your User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Create a List of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Prioritize and Deﬁne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Choosing Research Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How Many Research Activities Can I Include? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 User Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual Inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Surveys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Focus Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Card Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

After the Research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 CHAPTER 7: Personas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 What Are Personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Why Would I Create Personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finding Information for Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Creating Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Minimum Content Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Optional Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Advanced Personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Final Thoughts on Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 CHAPTER 8: User

Experience Design and Search Engine Optimization . . . . 126 Introduction to SEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Why Is SEO Important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Important Basic Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Site Technology, Design, and Infrastructure . . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and Other Scripted Content . . . . . . . . . . . . . . . . . . . . . . 130 Content Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, Directory, and URL Structure All Matter. . . . . . . . . . . . . . . . . . . . . . . . 134

Content: The Once (and Current) and Future King . . . . . . . . . . . . . . . 135 Naming Conventions and the Battle Against Jargon . . . . . . . . . . . . . . . . . . . . . 136 Metadata, Headers, and Keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

CONTENTS

Split the Hairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Use Site Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep Content Fresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other Content Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Link Popularity Explained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical Link Popularity Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Footer Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 In-Content Cross-Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

Gaming the System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat Versus Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Spamming with Meta Keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Cloning and Doorway Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Link Spamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Some Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 CHAPTER 9: Transition:

From Deﬁning to Designing . . . . . . . . . . . . . . . . . . . . 144 Ideate and Visualize Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

The Basic Process of Storyboarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitate the Prioritization Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Maintain a Good Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The Development Advocate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Managing Conﬂict During Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Plan Your Activities and Documentation . . . . . . . . . . . . . . . . . . . . . . . . 162 CHAPTER 10: Site

Maps and Task Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What Is a Site Map? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What Is a Task Flow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Tools of the Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Basic Elements of Site Maps and Task Flows. . . . . . . . . . . . . . . . . . . . . 168 Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Pagestack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Decision Point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Connectors and Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common Mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Sloppy Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

xii

CONTENTS

Misaligned and Unevenly Spaced Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Poorly Placed Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Lack of Page Numbering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 The Simple Site Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Advanced Site Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Breaking the Site Map Mold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Task Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Taking Task Flows to the Next Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Swimlanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 CHAPTER 11: Wireframes

and Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What Is a Wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What Are Annotations?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who Uses Wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Creating Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Tools of the Trade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Start Simply: Design a Basic Wireframe . . . . . . . . . . . . . . . . . . . . . . . . . .191 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 The Wireframes and Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

An Exercise: Design a Home Page Wireframe . . . . . . . . . . . . . . . . . . . 195 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The Results: Design a Home Page Wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When Wireframes Grow Up and Find Their Own Way in the World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Design Exercise Follow-up: Which Design Is Right? . . . . . . . . . . . . . . . . . . . . . . 201

A Final Note on Presenting Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . 202 CHAPTER 12: Prototyping.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What Is Prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How Much Prototype Do I Need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Paper Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe vs. Realistic Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML vs. WYSIWYG Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional Tools for Prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

CONTENTS

xiii

Working with a Developer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Prototype Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 What Happens After Prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 CHAPTER 13: Design

Testing with Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Concept Exploration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Tips on Exploring Visual Design Mock-Ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Usability Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Choosing an Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Planning the Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruiting and Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Writing Discussion Guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Facilitating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analyzing and Presenting Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Creating Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 CHAPTER 14: Transition:

From Design to Development and Beyond . . . . . . 247 This Is the End…. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual Design, Development, and Quality Assurance . . . . . . . . . . . . . 248 Design Testing with Users (Again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … Launch! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal Advantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Postlaunch Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Postlaunch Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Postlaunch Design Testing with Users (Again, Again) . . . . . . . . . . . . . . . . . . . . . 255

All Done, Right? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Just Like Starting Over… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 INDEX

xiv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

CONTENTS

Introduction Why We Wrote This Book Welcome to A Project Guide to UX Design. Somewhere there’s a student in user experience design losing sleep because he doesn’t know what it will be like to work on a real project at his new company. Across town, there’s a visual designer with plenty of project experience who yearns to take on new responsibilities in deﬁning her site’s user experience. These are two people at different points in their lives but with a similar need: to understand how to integrate user experience practices within the context of a living, breathing project. Our goal with this book is to give you the basic tools and context that will help you use UX tools and techniques with working teams. As you’ll see in many of these chapters, we’re not trying to be everything to all people, but we’re trying to provide you with the core information and knowledge that you should have to perform many of the duties you’ll be assigned as a UX designer. Beyond our own examples, we provide you with examples that help you identify ways to jumpstart the basic materials and allow you to mash up the information and create something newer, better, or even more suited to your own purposes. We hope we’ve done a decent job of articulating that this is a pretty good approach to UX design projects. We’re nothing if not constantly trying to learn and improve (whatever we do) with each iteration. That’s why, to a degree, we’re in this ﬁeld. A Word from Russ As a mentor for the Information Architecture Institute (www.iainstitute.org) I’ve noticed a pattern among the people I have worked with: Most were either having difficulty landing jobs or were not aligned with the expectations of prospective employers. Some had outstanding education but not always enough practical application of their UX design skills in a project-based setting. The same themes resonated in many of the conversations I had at Information Architecture Summit (www.iasummit.org) in 2008. It was then that the

INTRODUCTION

idea for this book—which addresses many of these common issues—began to take shape. I don’t remember whether Carolyn or I sent the ﬁrst e-mail, but I do know that in her I found a willing and capable co-author who helped me sand the corners off the idea that eventually became this book. A Word from Carolyn For many years now, I’ve been in the lucky position of building and managing UX teams. I say “lucky” because I ﬁnd that UX designers in general have a great balance of characteristics that make them plain fun to work with, mixing right-brain intuition and left-brain logic. As I’ve conducted interviews to build these teams, one thing has really stuck out: A related educational background, like human factors or communication design, is a great indicator that someone is committed to the ﬁeld of UX design, but it’s not the number one indicator of whether someone would be a good ﬁt within the team or on a project. Just as important—if not more so—is the person’s ability to have a consultant’s mind-set. This means a positive attitude, a drive to understand and include others throughout a project, and—above all—a focus on making a real impact for users and clients. This mind-set means taking the time to understand the perspectives of other roles on the project, making cases, and making compromises where necessary. It takes experience and effort to get this mind-set down really well, but having an open mind, a strong foundation, and a good set of questions (with the courage to ask them) can take you a long way. This book may not supply all “the answers,” but it will give you the questions to ask to help you ﬁnd them.

Who Should Read This Book A Project Guide to UX Design provides a broad, introductory overview to UX design within the context of a project. Anyone with an interest in UX design should ﬁnd something useful here. We focused on the following groups in particular: Students taking UX design courses (such as human-computer interaction or interaction design) who want to supplement their coursework with information on how to apply their learning to real-life situations, where communication and collaboration are vital.

xvi

INTRODUCTION

Practitioners who would like to deepen their knowledge of the basic tools and techniques of UX design and improve team communication about the roles involved. Chapter 3 is also particularly geared toward freelancers who need to create their own proposals. Leaders of UX design groups who are looking for a book that will help their teams integrate project best practices with UX design activities. Leaders of any project teams who are interested in learning more about how UX design integrates into their projects, what the value is, and what to expect from UX designers. IF YOU NEED TO…

THEN YOU SHOULD READ…

Deﬁne user experience design and understand what draws people to the ﬁeld

Chapter 1: The Tao of UXD

Ask the questions that are important to have answered before the project begins (or at least before you start to work on it)

Chapter 2: The Project Ecosystem Chapter 3: Proposals for Consultants and Freelancers

Start things off right with efficient meetings, clear objectives, and well-understood approval points

Online chapter: A Brief Guide to Meetings Chapter 4: Project Objectives and Approach

Deﬁne project requirements that are unambiguous and easy to prioritize, drawn from business stakeholders and users

Chapter 5: Business Requirements Chapter 6: User Research Chapter 9: Transition: From Deﬁning to Designing

Learn about your users and represent their needs throughout the project

Chapter 6: User Research Chapter 7: Personas Chapter 13: Design Testing with Users

Choose and utilize the tools and techniques that enable you to bring visual ideas to your project team quickly

Chapter 10: Site Maps and Task Flows Chapter 11: Wireframes and Annotations Chapter 12: Prototyping

Ensure your site is easily found and searched by users and by search engines

Chapter 8: User Experience Design and Search Engine Optimization

Communicate and evolve your design with the project team once development begins

Chapter 14: Transition: From Design to Development and Beyond

Be sure to visit www.projectuxd.com to read the bonus chapter “A Brief Guide to Meetings” and to download other bonus materials such as templates.

INTRODUCTION

xvii

A Note on Methodology There are a variety of approaches and methodologies out there. We aren’t proponents of one approach over another. Our goal for this book is to focus on the steps that are common to most projects: deﬁning the project needs, designing the experience, and developing and deploying the solution. The amount of overlap between these steps will vary greatly depending on the project approach you use (see Chapter 4 for more detail). For the most part, our framework is a loose, linear approach, where the deﬁnition step comes ﬁrst—but in each step we take advantage of facilitation and design techniques where they’re most helpful.

What This Book Is Not An encyclopedia of all techniques. The UX ﬁeld has an enormous number of creative people, and they’re always trying new approaches to design problems. Including all of those approaches here would make a much larger book—and one that would quickly be outdated. What we’ve included here are the most commonly used techniques, the nuts and bolts of UX design. We’ve tried to provide enough information to both intrigue you and allow you to communicate the activities to other project members—including the basic process for each technique and additional references to books or sites that will help you implement it once you choose your path. A guide to being a project manager. Good project management (including setting and tracking project objectives, timelines, and budgets) is key to any project’s success. We don’t cover speciﬁcs on how to be a project manager or how to choose a particular project methodology. We do discuss the skills that a UX designer brings to a project that allow it to run effectively, such as facilitation and communication, as well as the ability to clarify and maintain focus on project objectives. These skills will help you become a partner in project management. The only or the perfect process or methodology for you to follow. We don’t have all the answers—no one does, today. The UX design ﬁeld is relatively young, and we’re all working to improve upon where we are. You will probably ﬁnd that trial and error, enhancements and improvements, and feedback

xviii

INTRODUCTION

from others will help you tailor a process to ﬁt your needs. When you ﬁnd something that works for you—share it! Let us know!

How to Use This Book There are many excellent resources out there for UX designers. We cover topics broadly here but point you to references that will allow you to explore topics at a deeper level depending on how much time you want to dedicate to them. To help you understand the amount of time generally needed for each reference, we’ve split them out into three major categories:

Surﬁng References called out with the surfboard are shorter features (usually online) that will take 5 to 30 minutes to read.

Snorkeling Those called out with the snorkel are longer online articles, white papers, or short books that take anywhere from an hour to a weekend to read.

Deep Diving Those called out with the diver’s helmet are longer books that will probably take more than one weekend to read; they give you in-depth coverage of the topic.

INTRODUCTION

xix

This page intentionally left blank

The Tao of UXD Curiosity Meets Passion Meets Empathy The important thing is not to stop questioning. Curiosity has its own reason for existing. One cannot help but be in awe when he contemplates the mysteries of eternity, of life, of the marvelous structure of reality. It is enough if one tries merely to comprehend a little of this mystery every day. Albert Einstein

A sense of curiosity is nature’s original school of education. Smiley Blanton

Passion and purpose go hand-in-hand. When you discover your purpose, you will normally ﬁnd it’s something you’re tremendously passionate about. Steve Pavlina

The great gift of human beings is that we have the power of empathy. Meryl Streep

uite simply, this chapter is about you—and about others who are drawn to the ﬁeld of user experience design (or UX design, for short).

If you’re reading this sentence, you’re a curious person. You want to know how things work—anything from doorknobs to airplanes to that thing in the back of your throat. Most of all, you want to know what makes people tick. You don’t see things as black and white; there are a whole lot of shades of gray to explore! Sure, sometimes you may drive your peers a little crazy by always volunteering to play the devil’s advocate, but it’s not like you can stop yourself from trying to look at the other side of the coin. Lucky you! The user experience design ﬁeld attracts curious folk who are comfortable working with many shades of gray. We seek out patterns and thrive for organization and structure. We connect the dots. We relentlessly pursue the next piece of the puzzle, and when the puzzle is solved, we look for ways to improve it! We can be analog or digital. We are at home with pencil and paper, whiteboards and dry erase markers, Post-it notes, and Sharpie pens. We talk in terms of Visio and ‘Graffle, and we live in a world of boxes and arrows connected on the multiple screens of our computers. We are not only curious. We are passionate! We have passion for brainstorming ideas and facilitating discussions. We have a passion for creating things that make a difference for those who use them—and those who create them. Oddly enough, we’re most proud when something we create is so good that people don’t realize how good it is! And, of course, we have empathy. We can feel it deep within the core of the fabric of our being when we encounter a bad experience. Even worse, we instantly try to ﬁnd solutions to solve the problems. We know what it’s like to have an unexpected response to what seems like a simple request—and we don’t like it! We don’t want users—people just like us—to have to endure the confusion and feelings of inadequacy that often go hand-in-hand with a poor experience. 2

CHAPTER 1: THE TAO OF UXD

When you combine that almost constant, childlike curiosity with an unrivaled passion for “doing what we do” and a sense for how others feel, you end up with a lively community of professionals who are comfortable speaking their minds, asking questions, sharing solutions, and being wrong—all in the name of getting to what is right. Welcome to the UX design community.

What Is User Experience Design? There are many deﬁnitions for user experience design. After all, it’s a ﬁeld that thrives on deﬁning things. Admittedly, sometimes we don’t do such a good job of “deﬁning the damn thing” when it comes to the various parts of the whole, but we at least know what the whole is. In this book we’ll be focusing on two deﬁnitions in particular: the broadest sense of the term UX design and the deﬁnition we will use in the context of this book.

The Broad Deﬁnition User experience design is The creation and synchronization of the elements that affect users’ experience with a particular company, with the intent of inﬂuencing their perceptions and behavior.

These elements include the things a user can touch (such as tangible products and packaging), hear (commercials and audio signatures), and even smell (the aroma of freshly baked bread in a sandwich shop). It includes the things that users can interact with in ways beyond the physical, such as digital interfaces (Web sites and mobile phone applications), and, of course, people (customer service representatives, salespeople, and friends and family). One of the most exciting developments of the past few years has been the ability to merge the elements affecting these different senses into a richer, integrated experience. Smell-o-vision is still far in the future, but otherwise products continue to blur the traditional lines.

WHAT IS USER EXPERIENCE DESIGN?

Don’t Forget the Tangible Although we’re focusing on the digital aspects of the user experience, these types of interactions don’t occur in a vacuum. Be sure to consider the effects of the tangible experience when designing your digital products. The environment your users are working within matters, as do the physical products (screens, keyboards, and other input devices) that affect the way your users will interact with your design. Chapter 6 offers techniques to help you understand the impact of context. Also, don’t forget the other touchpoints a product or company has with those who interact with it. After all, the brand of the company is affected by many things, and the brand experience doesn’t end at the screen of a computer or a mobile phone. The best Web site design possible can’t make up for a reputation for poor customer service or provide the satisfaction of well-designed packaging when a product gets delivered.

Figure 1.1 A modern classroom experience blends the analog and the digital.

CHAPTER 1: THE TAO OF UXD

Tangible experiences, such as learning in a classroom, are increasingly being inﬂuenced by digital applications. Likewise, experiences that used to be individual, such as choosing which at-home karaoke machine to buy, are increasingly becoming enhanced through social interaction.

Figure 1.2 Online reviews are a major inﬂuencer of consumers.

Our Focus As you can see, the scope of UX design is large, and growing. For the purposes of this book, we’ll be focusing on projects centered on the design of digital experiences—in particular, such interactive media as Web sites and software applications. To be successful, the user experience design of these products must take into account the business objectives of the project, the needs of the product’s users, and any limitations that will affect the viability of product features (such as technical limitations or constraints around project budget or time frame).

WHAT IS USER EXPERIENCE DESIGN?

Free samples of a new nutrition bar handed out at a marathon

A door handle

Packaging for a pair of shoes

Figure 1.3 This book focuses on the digital aspects of user experience design.

Tangible Mobile phone texting features

Customer service phone call

Individual

Social

Our focus Reading online product reviews Searching an online archive Viewing targeted advertising

Digital Customer service live chat

About UX Designers Although curiosity, passion, and empathy are traits that user experience designers share, there is also a desire to achieve balance. We seek out a balance, most notably between logic and emotion, like Spock and Kirk or Data and Data in that episode where his emotion chip overloaded his positronic relays. You get the idea. To create truly memorable and satisfying experiences, a UX designer needs to understand how to create a logical and viable structure for the experience and needs to understand the elements that are important to creating an emotional connection with the product’s users. The exact balance may shift according to the product. An ad campaign for a child’s toy will have a different balance than an application for tracking patient information at a hospital. A product designed without understanding the need for both is likely to miss opportunities for a truly memorable experience— and the resulting beneﬁts to the company behind the product. Note For additional information about emotional design, check out Donald Norman’s Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).

CHAPTER 1: THE TAO OF UXD

Achieving that balance requires a heightened sense of empathy: the ability to immerse yourself in the worlds of potential product users to understand their needs and motivations. User experience designers perform research to reach this understanding (see Chapter 6) and create such tools as personas (see Chapter 7) to help the rest of the project team focus their efforts. Remember, emotion is just a part of the overall picture. Use the logical side to bring you back from the edge and keep your mind on the tasks at hand. In most cases, you will be working against a budget that is based on the time and materials required to complete the project. You’ll need to understand that sometimes you need to ﬁsh or cut bait.

Where UX Designers Live You’re not alone in this. Look around and you’ll ﬁnd a number of organizations and communities that can foster your development as a user experience designer. In addition to offering mailing lists, online resources, and a whole slew of really smart people, many of these organizations sponsor events or conferences that can help you broaden your horizons and narrow your career focus all at the same time. A number of companies host events geared to providing continuing education, including User Interface Engineering’s Web App Summit and User Interface Conference, Adaptive Path’s UX Intensive, and the Nielsen Norman Group’s Usability Week. There’s also a growing number of “unconferences” in different cities; these are created by a collection of motivated individuals independent from any particular company or association.

WHERE UX DESIGNERS LIVE

Several professional organizations sponsor yearly conferences, as well. Table 1.1 provides a short list of some of the more well-known organizations, their Web sites, and events that they host. TABLE 1.1

A Sampling of UX Organizations

ORGANIZATION

WEB SITE

MAJOR CONFERENCE (TYPICALLY HELD)

Interaction Design Association (IxDA)

www.ixda.org

Interaction (early February)

The Information Architecture Institute (IAI)

www.iainstitute.org

IDEA Conference (September/October)

American Society for Information Science and Technology (ASIS&T)

www.asis.org

IA Summit (March)

ACM Special Interest Group on ComputerHuman Interaction (SIGCHI)

www.sigchi.org

CHI (early April)

The Usability Professionals’ Association

www.usabilityprofessionals.org

UPA (June)

Let’s Get Started! You’ve made it this far. It’s time to get into the reason you picked up this book in the ﬁrst place. Turn the page and take a dive into how user experience design exists within the realm of projects. But don’t stop there—this book is a guide to get you started. It has a lot of examples that can help you deliver on many of the activities you will be tasked with. We’ve also tried to provide additional examples to help you expand and ﬁnd your own best approach for creating deliverables that are useful to your team and your clients. Keep your curiosity, passion, and empathy alive! Challenge yourself to ﬁnd new ways to inspire others to build that ideal user experience. That is, of course, before you set out to improve upon it.

CHAPTER 1: THE TAO OF UXD

The Project Ecosystem Planning for Project Needs, Roles, and Culture Are you about to start a brand new project? Or are you in the middle of one? Either way, take a moment to consider the dynamics and context of the project— the issues that will affect you and the rest of the project team. What type of sites or applications are involved? Which roles and skills are needed? What is the company culture? Answering these questions will help you deﬁne the project and ultimately determine the tools and skills you need to bring to the table to be successful. Carolyn Chandler

ach project has its own unique challenges. If you’re designing Web sites or applications, many of those challenges will involve speciﬁc features and functionality, such as building a method for a user to share photos with friends and family online or restructuring the information in an intranet so that content can be more easily found and shared. Around those speciﬁc design goals, however, all projects have a larger context that you need to understand and integrate into your planning. This context is the project’s “ecosystem,” and it includes the environment you’re working within (the company culture), the general type of work you will all be engaged in (such as the type of site you’re designing), and the people you’ll be interacting with (including their roles and responsibilities). If you take the time to understand the project ecosystem you’ll have knowledge that will help you throughout the project. You can communicate your responsibilities and ideas more effectively, and you can help others on the team anticipate project needs they may not have considered. To help you, this chapter identiﬁes different types of projects you may work on, as well as the roles you may play, the people you may depend on and how their involvement tends to vary by the type of site or application being designed. Finally, the chapter discusses some elements of company culture that may affect how you work during the project. Note Depending on how your client company structures its projects, a particular project may involve the design of more than one site or application. For the sake of simplicity, this book assumes that a project involves the design of a single type of site. If you have more than one site, consider each separately to make sure you have the right roles represented on the project team.

Identify the Type of Site Although no black-and-white distinctions exist between one type of site and another, some relative differences in site focus and characteristics are identiﬁable. Understanding these similarities and differences can help you Set design goals for yourself. These are the general problems that need to be

solved (such as “explain the company’s business model”) or the attributes that need to represented (such as “demonstrate the company’s responsiveness to its customers”) within the site’s visual design and interaction design.

CHAPTER 2: THE PROJECT ECOSYSTEM

Solidify the primary objectives of the project (see Chapter 4). Understand which departments or business units may (or should) be

involved as you gather business requirements (see Chapter 5). Determine the best methods for incorporating user research (see Chapter 6). Ask questions about which systems and technologies may be involved.

Your site will probably associate strongly with one of four types:

Brand presence—a constantly present online platform that facilitates the relationship between the company and a general audience (anyone interested in its products or services) Marketing campaign—a targeted site or application meant to illicit a speciﬁc and measurable response from a particular audience or from a general audience over a limited period of time Content source—a store of information, potentially composed of several types of media (articles, documents, video, photos, tutorials) meant to inform, engage, or entertain users Task-based application—a tool or collection of tools meant to allow users to accomplish a set of key tasks or workﬂows

The next sections take a closer look at each of these types, discussing their characteristics and the impact they’ll have on your challenges during the design of the site or application. We’ll also discuss the most common crossover projects—e-commerce, e-learning, and social networking—which have characteristics of more than one type.

Brand Presence What do you think of when someone says the word brand? Often the ﬁrst thing that comes to mind is a company’s logo, such as the Nike Swoosh or the Coca-Cola script emblem. A company’s brand is much more than their logo, however; it’s the entire series of impressions that a particular person has about the company.

IDENTIFY THE TYPE OF SITE

Dirk Knemeyer presents some excellent deﬁnitions 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…That is to say, brand is something that actually lies inside each of us. The science of branding is about designing for and inﬂuencing the minds of people—in other words, building the brand.

Surﬁng For more information on the distinctions between a customer’s experience of a company’s brand and a company’s efforts to build their brand, read Dirk Knemeyer’s explanation in “Brand Experience and the Web”: www.digital-web.com/articles/brand_experience_and_the_web. For an excellent discussion of how a site’s UX design can inﬂuence an individual’s brand experience, read Steve Baty’s article “Brand Experience in User Experience Design”: www.uxmatters.com/MT/archives/000111.php.

A company can do a lot to inﬂuence the associations made with its brand, from running memorable advertising campaigns to expressing brand traits (such as “responsiveness” or “value”) through the features and design of its Web sites. All sites within a company are likely to have some impact on a company’s brand, either directly (by presenting a site that customers can visit) or indirectly (by enabling a key service that customers rely on, such as customer support). Brand presence sites, however, are the most focused on presenting the company’s brand messages and values. They provide channels that interface directly with customers and serve as a broad online funnel for those interested in ﬁnding out more about the company or its offerings. A brand presence site is often the company’s primary .com or .org site, such as GE.com, or for larger and more distributed companies, are the primary sites for business units of varying sizes, such as GEhealthcare.com. Distinct product lines also often have their own unique brand presence online. For instance Pepsico.com has one brand presence, while Pepsi.com has its own distinct presence.

CHAPTER 2: THE PROJECT ECOSYSTEM

If you’re working on a brand presence site, you’ll probably be designing for a variety of user groups, including current and potential customers, investors, partners, the media (such as news organizations and authors of prominent blogs), and job seekers.

Common Brand Presence Sites A company’s main home site (company.com, company.org, company.net, etc.) A site for a primary business unit of the company (often a unique site for a

particular industry, region, or large suite of products) Sites for prominent sub-brands within a company

Brand Presence Design Goals The design goals that are often of most importance in a brand presence project are these: Communicate the brand values and brand messages of the company,

either explicitly (perhaps a statement about the importance placed on being responsive to customer needs) or through the overall experience upon entering the site (such as ensuring it performs well and prominently offers features that encourage customers to communicate with the company). Provide quick and easy access to company information. You want to

answer the questions “What does the company do?” and “How do 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 it?” Engage a set of primary user groups and guide them to relevant interac-

tions, functionality, or content. Help the company attain goals being set against key metrics, such as

the number of unique visitors. Often this is one part of an overall marketing strategy. Later, in the section “Choose Your Hats,” you’ll learn the various roles that may be involved in designing a brand presence site. For now, let’s take a look

IDENTIFY THE TYPE OF SITE

at the other types of sites you may work on, including one that has a close relationship with brand presence sites: the marketing campaign site.

Marketing Campaign Marketing campaign sites are similar to brand presence sites, as both are focused on engaging users with an experience that inﬂuences their perception of the company’s brand. Marketing campaign sites, however, tend to be evaluated on their ability to achieve very speciﬁc actions within a set focus (such as within particular time frame or with a targeted audience). Rather than serving as a funnel for channeling interest, they are meant to be the engines that generate interest. From an online standpoint this generally means they are aligned with an overall marketing strategy and may be run in conjunction with other marketing efforts using different channels, such as TV or radio commercials, print ads, and other promotions.

Common Marketing Campaign Sites A landing page that promotes a speciﬁc offer. The page is reached via a

banner ad from another page. A small site (or microsite) promoting a particular event. A game or tool that has been created for the purpose of generating buzz

or traffic.

The primary purpose of a marketing campaign site is to create a narrowly focused campaign usually targeting a speciﬁc set of metrics. The focus is often narrowed by one or more of the following: Time—for example, a campaign centered around an event (such as a

conference) or a season (such as the Christmas shopping season) User group—such as a campaign targeted to teenagers or teachers Product, product suite, and/or a speciﬁc use for that product—for

example, a site that highlights kitchen appliances by showing virtual kitchens with matching ovens, dishwashers, and stoves

CHAPTER 2: THE PROJECT ECOSYSTEM

A campaign using a mix of these strategies would be a spring campaign targeted to selling patio equipment, combining time and product suite. See Figure 2.1 for an example showing a mix of product suite and user group. A marketing campaign site may be as simple as a banner ad leading to a landing page in the company’s .com site, or it could be a microsite, a small site that often veers away from the branding apparent on the .com site to provide a tailored experience according to one or more of the areas of focus. “Small” is relative here—some microsites are only 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-focused microsite, http://timathrocks.com/ index.php, to present information on the company’s graphing calculators. The product suite is used primarily by high school and college students in algebra classes. The microsite maintains general ties to the Texas Instruments brand but is intentionally distinct in order to attract a younger audience and organize content and features according to their needs.

Marketing Campaign Design Goals For the person or team responsible for designing and implementing a marketing campaign site, the design goals that are often of most importance are these: Generate interest and excitement, often by presenting a clear and imme-

diate value proposition (the value that a product or service brings to the user, such as the possibility of quick loan qualiﬁcation) or some kind of incentive (a special offer, entry in a contest, or entertainment such as an online game).

IDENTIFY THE TYPE OF SITE

Engage a set of primary user groups in order to illicit a particular action,

such as clicking through to a speciﬁc location on a brand presence site, signing up for a newsletter, or applying for a loan. When this action is performed by a user it’s called a conversion. Help the company attain goals being set against key metrics, such as num-

ber of unique visitors. Often this is one part of an overall marketing strategy.

Deep Diving For more on designing pages to support marketing campaigns, see Landing Page Optimization: The Deﬁnitive Guide for Testing and Tuning for Conversion, by Tim Ash (Sybex, 2008).

Content Source A content source site contains a store of information, potentially in several types of media (articles, documents, video, photos, tutorials), and is meant to inform, engage, and/or entertain users.

Common Content Source Sites A company’s intranet An online library or resource center for members of an organization Sites or areas of sites that are focused on providing news or frequently

updated posts (large commercial blogs may fall into this category) Customer support centers

All sites and applications have some content, of course, but some sites place a particular emphasis on the presentation and structure of their content. The emphasis may come about because the site has such a large amount of content that it poses its own challenge or because speciﬁc types of content carry a high degree of importance; they might, for instance, support critical decisions or draw users back to the site frequently.

CHAPTER 2: THE PROJECT ECOSYSTEM

The primary purpose of a content source site is to increase user knowledge and self-sufficiency by providing relevant content (an intranet, for example). They often also encourage some kind of action, such as sharing information or purchasing a product after reviewing its description. Content Source Design Goals A content source site often has to do one or more of the following: Present content that is the primary draw for ﬁrst and repeat visits to the site. Demonstrate a company’s thought leadership capabilities, for example,

by providing access to ideas and perspectives held by the CEO or other subject matter experts within the company. Support critical decisions among the user base. Increase a company’s enterprise knowledge, by bringing out ideas that

may be buried within individual departments. This may be part of a larger goal to identify more opportunities for innovation. Support users who are seeking information in different ways. For example,

some don't know what speciﬁc product they need yet (and are more likely to browse), while others may know exactly what they're looking for (and are more likely to use a search ﬁeld).

Surﬁng For more information on the different ways users tend to seek information, read “Four Modes 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

With regard to UX design, some of the tasks that are most common in a content source project are: Creating a categorization structure that ﬁts the mental models of your users Determining how to incorporate a system for organic growth of content

(for example, functions such as tagging and ﬁltering) Designing an effective search tool IDENTIFY THE TYPE OF SITE

Task-Based Applications Task-based applications can vary from a simple calculator embedded in a mortgage site to a full system handling multiple critical workﬂows. If your project involves the latter, there will be more roles involved and, most likely, a substantial requirements-gathering process (for more on this process, see Chapter 5).

Common Task-Based Applications A software application that supports the creation of a particular type of

item (such as a spreadsheet or print piece) A Web tool or application that supports a critical workﬂow within a com-

pany (such as a ticket-management application for an IT support group or a customer tracking application for a call center) A Web site that allows for access to, and management of, personal data

(such as Flickr)

The primary objective of a task-based application is to allow users to perform a set of tasks that are aligned with their needs and, ultimately, with the client’s business goals. Task-Based Application Design Goals Most task-based applications need to Enable users to do something they couldn’t do elsewhere—or if they can,

to do it better (“better” can mean more efficiently, more effectively, with a higher degree of satisfaction, or more conveniently) Support novice users with easy-to-access instructions and visual prioriti-

zation of key tasks Support intermediate and advanced users with access to shortcut features

and deeper functionality Reduce the load on the user and make the best use of system resources

(for example, reusing data versus requiring duplicate entries)

CHAPTER 2: THE PROJECT ECOSYSTEM

Be designed and deployed with attention to the degree of change required

of the application's users—ideally, with a design that facilitates learning and a communication plan that demonstrates the value to the user One of the biggest challenges of designing a task-based application is to keep “feature creep” under control. As a project is being developed it’s very common for great ideas to come up at later stages of the design, or even during development. User experience design is well suited to guarding against feature creep because user models such as personas can be used to identify high-value features and to keep focus throughout the project. If a truly great idea does come up later in the process, and it meets the needs of a high-priority user group, and it aligns with the business goals of the site, your team may be able to build a case for changing direction. If an idea can’t make it through that wringer, it may not be worth the delay and cost.

E-Commerce Sites E-commerce sites can include elements of all four project types, because a site that is primarily intended for e-commerce needs to have its own brand presence, provide content (usually product specs or descriptions of product usage), and facilitate tasks (searching, comparing, writing reviews, checkout). Marketing campaigns are often closely tied into these sites as well and may involve multiple marketing groups within the organization. Common additional design goals for e-commerce sites are Explain the model for the site, if it's nonstandard. As online marketplaces

are constantly being reconceived, this explanation will help set expectations (for example, eBay, Amazon, and Craigslist have very different models). Support decision making as the user moves from learning to consider-

ation to comparison to purchase, with helpful content and features. Make use of points in the experience where cross-selling and upselling is

possible, and place those suggestions in a way that is eye-catching without being disruptive. Create a communication ﬂow from the point of purchase through the

point of delivery. Communication needs to happen not just within the site but also with other channels, such as integration with delivery tracking systems and e-mailed communications about order status. IDENTIFY THE TYPE OF SITE

E-Learning Applications E-learning applications are crossovers between a content source and a task-based application. Content for lessons must be generated, which often requires that the team add the roles of learning specialist and subject matter expert (SME) for the topic being covered. The product is task-based in that the user usually follows a ﬂow through the lesson and may also need to track progress or explore related topics. Some hands-on lessons may also require tasks to be completed. Common design goals are Set an understanding of the baseline knowledge needed to start a course

and who it is targeted to. Provide content in manageable chunks that are paced for

comprehension. Engage the learner in activities that simulate hands-on learning. Communicate performance and progress and, if applicable, suggest

next steps for continuing the educational process, such as more advanced courses.

Social Networking Applications A social networking application is primarily a task-based application, because users need to be able to ﬁnd and add friends, manage their proﬁle, connect, post, and search. They also contain challenges associated with content sources, however, especially the need for an organic framework that can handle a potentially very large amount of user-generated content. If the site is essentially given its own identity, it will also have the characteristics of a brand presence site.

Snorkeling If you’re working on a social networking application or trying to integrate social features into another type of site, this book will help you on your way: Designing for the Social Web, by Joshua Porter (New Riders, 2008).

CHAPTER 2: THE PROJECT ECOSYSTEM

Common design goals for social networking applications are Focus potential users on the purpose and the values of the network. Facilitate meaningful interactions between users that support, and are

supported by, the features presented (such as image sharing, video sharing, and discussions). Protect the integrity of the site by ensuring those within the network under-

stand how to control their information and respond to inappropriate behavior. Harness and display the power of the community to bring forward fea-

tures that are only possible with active members, such as popular features and reviews. Identifying the type of site or application you may be working on during a project is only the ﬁrst step. Next, you should consider the different roles that are often needed and how their involvement may vary based on the type of project.

Choose Your Hats When you become the UX designer on a project, you often end up having to play several roles. Whether they’re formally deﬁned within your client organization or not, the roles you will play depend on the type of project and the makeup of the rest of the team, as well as a client’s experience with each. It’s good to know which roles you’re already comfortable taking on and which you think you can learn on the job. It’s also helpful to ﬁnd out what expectations others may have about the responsibilities covered by these roles. With this understanding, you can represent yourself more clearly from the beginning 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 those roles (or no name at all, if it’s not a formal job in the organization). In general, you can expect to encounter the big three: information architect, interaction designer, and user researcher. Note Few companies have the size or budget to split these common roles among different individuals. Keep the role names in your mind when deﬁning a project, but speak in terms of needs and responsibilities when talking to the client—otherwise they may think you’re building a very large team! This focus on responsibilities rather than titles will also help keep you sane: If you’re performing several of these roles, it doesn’t necessarily mean you’re doing the job of many people, because responsibilities ebb and ﬂow through different parts of the project.

CHOOSE YOUR HATS

Information Architect An information architect is responsible for creating models for information structure and using them to design user-friendly navigation and content categorization. During the design of sites and applications, common responsibilities include creating detailed site maps (discussed in Chapter 10) and ensuring that categories and subcategories of information are distinct and user-friendly. Understanding Expectations Within the UX ﬁeld, distinctions are made between the roles of the information architect and the interaction designer (discussed next). At a particular company, however, there is seldom a common distinction between the two roles, at least when it comes to what is stated as a need for a particular project. For example, you may end up on a team with the title of information architect because that’s the historical term for the role, whether or not that truly ﬁts your responsibilities. Should you correct the project team if the title you’re given doesn’t match the main role you’re taking on? If this is a shorter term project (say, four months or less) and the title you have is widely accepted within the organization, with clear responsibilities outlined, it may not be worth the potential confusion you’d be introducing to try to change it. If there is no widely accepted title, however, and you think there’s a chance you’ll need both roles to be represented—potentially by different people—then it’s worth making a distinction early in the project when you’re planning your involvement and communicating your responsibilities. Essentially, for more task-based applications it makes sense to emphasize the role of interaction designer, and for more content-based projects it makes sense to emphasize the role of information architect. But what may make the most sense of all is to use the term familiar to the client organization and ensure the team understands how you’re deﬁning the role with regard to the responsibilities you’re taking on. This deﬁnition is something you’ll want to make clear in the statement of work (see Chapter 3). The responsibilities of an information architect can also blur with those of a content strategist (see below, under “Other Roles”). If these roles are

CHAPTER 2: THE PROJECT ECOSYSTEM

represented by different people on the project team, be sure to discuss how you’ll be collaborating at the beginning of the project.

Interaction Designer An interaction designer is responsible for deﬁning the behavior of a site or application in accordance with user actions. This includes ﬂows in the site across multiple views and interactivity within a particular view. During the design of sites or applications, common activities are to create task ﬂows showing interaction across pages or components within the site (see Chapter 10) and to create wireframes showing in-page interactions such as dynamic menus and expandable areas of content (see Chapter 11). Understanding Expectations If you’re working on a small team or on a project that isn’t highly focused on creating new task-based functionality (for example, if you’re working on a brand presence site that mainly includes some content categories, a contact form, and a sign-up form for a newsletter) interaction designer may be the main role responsible for capturing the project requirements (see Chapter 5). If you’re working as the interaction designer on a project with a high level of new functionality, most likely you’ll have a separate person on the team in charge of outlining detailed requirements (for example, a business analyst or product manager). The process of gathering and detailing functional requirements can be helped greatly by the skills of a UX designer, and documents such as functional speciﬁcations and use cases are affected by experience design. Be sure to sit down with the person in charge of gathering requirements to discuss how you can best work together.

User Researcher A user researcher is responsible for providing insights regarding the needs of end users, based on information that is generated from, or validated with, the research that person conducts with users. There are many types of activities that can fall into the category of user research, and they can occur at several 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

Understanding Expectations The client company’s appetite for user research can vary immensely, based on the importance placed on it by the project team or the project sponsor. The fact that you’re talking to a project sponsor about UX design before a project starts shows that someone on the client team knows it’s a priority to ensure that user needs are represented. But as those who have worked on their share of computer-based projects know, introducing research can also introduce anxiety among project team members—sparked by concerns that user research will create a bottleneck, increase risk (What if we ﬁnd something wrong, and need to make big changes to ﬁx it?), or disprove the value of a particular idea that has gained a lot of momentum. The expectations for user research can vary between business stakeholders and the project team, so be sure to clarify expectations for the role with both groups. The client may also expect the user researcher to provide insights based on site analytics—tools and reports that communicate patterns of use on the site, such as frequently visited pages and common points where users leave the site. Some of the most common analytics tools are from Google (www. google.com/analytics), WebTrends (www.webtrends.com), and Omniture (www.omniture.com/en/products/web_analytics). You may ﬁnd yourself taking on all three of these roles: information architect, interaction designer, and user researcher. Can you balance all three, or are you biting off more than you can chew? In part that depends on the size and timeline of the project, but the type of project also has an impact on how much involvement each role is likely to have. Table 2.1 describes how UX design roles can vary by project type.

Surﬁng Need to make the case for UX design? These articles offer approaches that can help: “User Experience as 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

CHAPTER 2: THE PROJECT ECOSYSTEM

TABLE 2.1

Common Responsibilities of the UX Design Role

Information Architect

BRAND PRESENCE

MARKETING CAMPAIGN

CONTENT SOURCE

TASK-BASED APPLICATION

Medium involvement.

Low involvement for smaller sites (like a single landing page). Medium involvement if working with larger microsites.

Very high involvement. Content sources require an information architecture that has an appropriate balance of structure and ﬂexibility, to give users a solid base to stand on and allow for planned growth.

Medium to high involvement, mainly focused on creating the navigational framework, unless there are larger content areas that need to be referenced during some workﬂows.

Low involvement for smaller sites, medium to high involvement for larger microsites or advergames (sponsored online games meant to generate play and buzz).

Medium to high involvement.

Very high involvement. This kind of project often requires the heaviest lifting, as interaction design deliverables (such as user process ﬂows and wireframes) are key to communicating requirements visually.

Due to the often temporary nature of campaigns, user involvement is often light. More permanent solutions may use research similar to brand presence sites. It’s also common to use analytics tools to present two or more variations of a particular page to see which one leads to the most conversions. This is called A/B testing.

Field research such as contextual inquiry can help the team understand how different users currently work with information.

The greater the content challenge, the more like a content source the project will become.

Interaction Design

Medium involvement. The greater the number of tasks, the more like a task-based application the project will become.

User Researcher Involvement will vary based on budget and access to users. Listed here are common techniques for each project type. For more on each of these techniques, see Chapter 6.

Research efforts may focus on understanding needs of priority user groups (through surveys or interviews) or design research testing the effectiveness of a particular visual design in conveying the right brand message.

Search, tagging, and ﬁltering features cross the line between information architecture and interaction design. Content sources may also have workﬂows involving content creation and management.

Card sorting is an excellent way to understand how your users may group information and common patterns and mental models.

Field research such as contextual inquiry can be done to understand tasks as users are currently completing them. The most frequently used and best understood technique for involving users in the design of a task-based application, however, is usability testing.

Once a framework has been set, usability testing can validate the structure.

CHOOSE YOUR HATS

Other Roles You May Play or May Need Several roles don’t typically fall under the role of UX designer, but their responsibilities often overlap with the UX design role—especially if you’re working on a project where no one is officially playing the role and you have skills to bring to the table. Some of the more common overlapping roles include: Brand strategist or steward Business analyst Content strategist Copywriter Visual designer Front-end developer

The following sections look at each of these roles in more detail and discuss how they may vary depending on the type of site being designed. Brand Strategist and Brand Steward A brand strategist is responsible for building a relationship with key markets through the deﬁnition and consistent representation of the company’s branding elements, which can include anything from brand values (such as “responsiveness”) to guidelines for copy and messaging to speciﬁcations for logo treatments, colors, and layout. This role often entails creating or representing branding guidelines and understanding how they apply to different projects. It may also involve knowing or deﬁning the target audiences of importance on the project you’re working on. For the most part, you’ll probably work with a brand strategist but won’t be taking the responsibility on yourself. The brand steward doesn’t necessarily set the guidelines but is responsible for ensuring that they are followed appropriately during the project. This responsibility may be given to the UX designer or visual designer on a project. If the company’s brand attributes, values, and guidelines have already been well deﬁned and the site is expected to follow them, your role as the project’s brand steward will mainly be to ensure the result is in line with those guidelines. Your touchpoint outside the project would most likely be a

CHAPTER 2: THE PROJECT ECOSYSTEM

member of the marketing department who is available on a consultative or review basis but is not on the team full time. The brand steward role may be more active if the site is meant to extend the brand somehow—targeting a new market, for example. It’s most involved when a completely new brand presence is being created or when the company is making a dramatic change in its brand, effectively rebranding itself. For example, CellularOne rebranded itself completely to become Cingular, a major effort for an established company. In that situation you should either be very experienced in brand development or establish a clear and close relationship with the person at the company who is. Key questions that will help you understand expectations around a brandrelated role are these: Do brand guidelines exist already? If so, how closely do they need to be adhered to for this project? Who is responsible for setting or maintaining brand messaging, brand

look-and-feel, and tone of content (such as casual or professional)? Are new audiences going to be targeted that aren’t covered by previous

brand deﬁnitions? If so, who is responsible for ensuring the brand guidelines are still appropriate to those audiences? Will there be naming or renaming activities? If so, how should I plan to be

involved? (An example would be creating a name for a new tool that will be heavily promoted.) For projects that don't have a large potential impact on customers’ perception of the brand, such as the development of an internal application, brand steward involvement may be as light as an occasional check-in to ensure the brand is being well represented. Business Analyst A business analyst (sometimes referred to as a business systems analyst on IT projects) is responsible for identifying key business stakeholders, driving the requirements-gathering process (see Chapter 5), and serving as the primary liaison between business stakeholders and the technology team. He or she is also the primary owner of detailed requirements documentation, such as functional speciﬁcations and use cases, if needed.

CHOOSE YOUR HATS

The role of business analyst or product manager may not exist on your project at all or it may be one of the most important roles through the design process. Task-based applications and content sources often have this kind of role; brand presence projects and marketing campaigns may not. A taskbased application is most likely to need this role. The more features and the greater the complexity of the project, the greater the needs will be for a dedicated person and for documentation of functionality. Although a business analyst is not typically considered a member of the UX team, small UX teams are often asked to ﬁll the role, so it’s important to understand where these responsibilities lie. Business analysts drive the capture of business requirements, serving as the liaison between the technology team and the key business stakeholders. If there is a business analyst on a project, that person and the interaction designer are often joined at the hip. If it’s the same role, the person responsible may have a lot of documentation to keep up with! To understand expectations in this area, ask who will be responsible for outlining the scope of the project, facilitating the discussions around requirements, and documenting requirements throughout the project. For small projects or those that are not heavy in functionality, the project manager sometimes will take on these responsibilities. Either way, if it’s not you, you’ll still know who you need to stay close to in order to ensure your deliverables are in sync. Content Strategist A content strategist is responsible for understanding business and user requirements for content in various media (articles, documents, photos, and video), identifying gaps in existing content, and facilitating the workﬂow and development of new content. Content-related efforts are often underestimated. A client may have a large amount of content that’s wonderful in one medium (such as print brochures or videos), but that content may not be appropriate for the project you’re working on. Also, there are sometimes unspoken expectations that people within the client organization will generate content—expectations that may come as a surprise to those people when the time comes to populate your product with descriptions, news, and help topics! If high-quality content is a

CHAPTER 2: THE PROJECT ECOSYSTEM

key business driver in your project, make sure you know who is responsible for the following: Setting content guidelines for the new product (type of content,

tone, amount). Assessing the appropriateness of existing content against those

guidelines. Developing new content. This will vary based on general project type. For

task-based applications, it may include instructional copy, error messages, and help topics. For content sources, it may include articles, news items, and blog posts. Serving as the stakeholder–technical team liaison to communicate the

limitations and possibilities of the content management system. Deﬁning different content types as well as each one’s metadata (the

information that ultimately makes searching and cross-referencing more effective). Planning for the migration of content, which involves creating templates

for different content types and making sure content is tagged and loaded properly when it’s moved into 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 text on the site that frames the overall experience. In some cases, this copy remains fairly unchanged from day to day. It typically includes site and page introductions or in-page instructions. A copywriter may also be involved in the ongoing creation of dynamic content, such as news stories or copy for marketing campaigns. Copywriting is one of those gray areas that often falls to a UX designer, especially if wireframes are being created (see Chapter 11). You may initially put in sample text to serve as placeholder for copy such as a site description or in-page instructions, but someone eventually needs to populate it with the ﬁnal text that will be seen by users—and because many projects don’t have a dedicated copywriter, this task may default to you. You’re less likely to be asked to take on the copywriter role for high-proﬁle areas of brand presence sites or marketing campaigns; in those situations

CHOOSE YOUR HATS

each word may be given close scrutiny. But if you're working on a task-based application that needs short instructional messages, error messages, or other types of information that don’t necessarily fall into a clear content bucket, you may end up inheriting that writing task (or it will fall to the developer by default). Ask upfront if a copywriter will be available, and ask again when you’re wireframing if one hasn’t been found. If the job does fall to you, be sure to include that effort when you’re planning your activities during the project. And be forewarned: This is a responsibility that's often left out or underestimated. 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 and feel that creates an emotional connection with the user that’s in line with the brand guidelines. For example, a banking site often needs to appear stable, trustworthy, and accessible. The visual design can give this assurance through visual elements such as colors and imagery. That promise will then be kept (or broken) by the interaction design of the site and other touchpoints with the company (such as a call center). Let’s be frank: A lot of people out there call themselves visual designers, Web designers, or graphic designers, and a lot of sites have poor or only passable visual designs. There is a big difference between creating an effective, immersive, and emotional visual design and just getting by. Sometimes getting by is enough to meet the project objectives, and sometimes it leads to project frustrations and delays when the project sponsor is unhappy, or early users are not engaged with the design. On the other hand, it can also be easy to focus too strongly on creating an impact with the visual design, allowing the usability of the design to suffer. If you’re being asked to take on this role and are unsure of your abilities to create the right impact for the client, take a look at the company’s current site and the sites or products the clients admire from a visual standpoint to assess your comfort level. Visual designers often take a very central role in brand presence projects and marketing campaigns, having the primary role responsible for communicating the company's brand effectively.

CHAPTER 2: THE PROJECT ECOSYSTEM

For content source projects, they may focus on creating content templates that can be applied to many pages (for example, a template for an article). For task-based applications, they may provide a style guide that can be applied to common interaction elements, such as navigation areas and tools (which calls for a high degree of collaboration with the interaction designer). Front-End Developer A front-end developer is responsible for building the technical structure behind the page designs and ﬂows, as well as interactive elements within the site, such as rollover menus, expandable areas of content, interactions with multimedia elements like 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 tie directly to what the user sees, as opposed to the systems on the back end that provide the underlying platform (such as databases, content management systems, and the code needed to build the functionality behind complex features). If you or members of your team are taking on the role of front-end developer, close collaboration with the rest of development team is important to understanding expectations and responsibilities. Other important questions include which back-end systems will need to be integrated with, the method used for generating HTML, the need for ﬂexibility in page structure to accommodate customized “skins,” and the expectations concerning technologies such as Flash. If a prototype is being 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 possibilities can be created quickly in an application such as Flash, but a fully functioning prototype that needs to pull real data (for example the account information a user just entered in a form) will need to be done in close collaboration with members of the back-end development team. Worried about taking on all these roles? Unless you’re working on a very small project—or at a very small company—you most likely won’t be taking them all on yourself. The key is to understand which of the roles you are able and willing to take on, as needed, for the particular project you’re working on. For the rest, you can get the support you need on the project team by building a network within the client company or by recommending additional people to ﬁll the needs. Let’s take a moment to talk about ways you can do this.

CHOOSE YOUR HATS

Building a Network of User Advocacy For those areas that you’re not sure you can or want to take on, it’s time to start looking for help. There are three main ways you can go about doing this: Recommend additional team members be added, if the need is

apparent enough. Educate yourself in key areas where there are gaps—if the new responsi-

bilities are manageable and you have the time to dedicate to them. Build a support network within the company to help you at key junctures.

Let’s take a closer look at how you can build a support network. There are most likely some key resources in other departments within the company that can help you be successful. You’ll need to gauge how much time you can rely on from these people, because requesting outsiders’ time can be a tricky request with projects that are primarily owned by one department. If you don’t want to ask for a large amount of their time out of the gate, just ask if you can partner with (or consult with) them to ensure the best result for the major responsibilities for that role. Once you’ve done some partnering you’ll have a better understanding of the amount of interaction you may need and whether you need to make a more formal request for his or her time. Each company will have a different structure and different names for its departments, but here are some common places to look for partners: For the brand strategist role, ask if there’s anyone within the marketing

department who can serve as your touchpoint. This may also be a source for visual designers and content strategists. Visual design and content strategy partners may be also be found in

program or product management or in the research and development, operations, or corporate strategy department, where you can often ﬁnd business analysts and product managers. The IT or engineering department is often your best bet for front-end

developers and others who can help you get access to and insight into tools for site analytics.

CHAPTER 2: THE PROJECT ECOSYSTEM

If you have recently been hired by a new company and expect to be working across departments, one of the best things you can do out of the gate is to identify key people who could be partners and schedule some interview time with them to understand their roles and experience. It starts you off with a network that you can often rely on for a long time and gives you the opportunity to explain your responsibilities (and user experience design in general). You can also ask a great question at the end of the interview: “Who else do you think I should talk to?” The answer can help you ﬁnd people who may not be apparent to your main project manager or client contact. If you’ve been at a company for a while, you can still initiate an interview schedule like this. In that situation it’s best to tie it to a particular milestone (such as the start of a new project) or a corporate objective that has some urgency behind it, to ensure high participation. Make sure that your manager knows what you’re doing to avoid looking like you’re going around him or her. Good communication is key to understanding expectations about roles and building trust. Another key to gaining trust within the company is to understand its culture, the often unspoken expectations of how a company works, such as those created by past project experiences (positive or negative), etiquette regarding organizational hierarchy, and acceptable work logistics (such as working from home).

Understand the Company Culture Culture is a little like dropping an 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 all of its regions, business units, or departments, but you can usually identify key characteristics that will affect you and the project or projects you’re undertaking. The following are some aspects that are good to keep in mind as you scope projects and navigate potentially tricky political situations.

UNDERSTAND THE COMPANY CULTURE

History We all know the quote that those who cannot remember the past are condemned to repeat it, and project work is no exception. Understanding how a project or team has gotten to its current state of need can help you understand the challenges you may face during the project. Let’s cover some of the questions you can ask to understand the history that may affect a project. Although some of the answers to these questions may seem dire, keep in mind that something has triggered the need to bring you in on the project, so a project can have a rocky history and still be successful. Perhaps you’ll be a key component of that success! However, if many of the problems discussed below seem to apply, and you don’t feel you’ll be able to help address them, it may be a red ﬂag. In that case, consider an overall evaluation of whether this project is positioned to succeed. What is an example of a past project that seems to have been consid-

ered a success, and what seems to have made it so? What is a past 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, conversational manner) can help you understand a couple of things: how the person answering deﬁnes success, potential risks to your project, and any biases or expectations that will be carried through to this project, as well as approaches that worked well. Has the company worked with and released a designer on the same

project or team? If so, try to ﬁnd out what didn’t seem to be working and how the client expects your approach to be different. If you can ask more than one person at the company this question, it will help you understand a lot about unspoken expectations. If you get two very different answers, it could mean the designer’s responsibilities weren’t well deﬁned and you may need to ensure there’s a lot of communication about your responsibilities throughout the project. Has the project team been working on the project (or related materials)

for what seems like an unusually long time without ﬁnishing?

CHAPTER 2: THE PROJECT ECOSYSTEM

If so, this could be a sign that key client stakeholders are not on the same page or are not being involved at appropriate times, causing multiple stalls, direction changes, or lost time due to multiple iterations. It may also mean there is not a clear leader, someone who can say no (or at least effectively prioritize) to keep the focus on business objectives. If you’re in a position to inﬂuence the communication on the project, it may help to create guidelines for participation to help move the project forward. Has the company created designs without the previous participation of

a UX designer? This can be a mixed blessing. On one hand, you’re dealing with a team that understands the need for design and has attempted to ﬁll the gap. On the other, you may be given a design that you feel does not meet the project goals for the user experience. This can be a delicate situation to navigate. It’s often best to approach the creator of those designs with the tone of a respectful mentor or helpful consultant, pointing out the good aspects of the design ﬁrst, then discussing user experience goals and how they may be better achieved with a different approach. The creator is likely to be a valuable member of your support network, so it’s important not to burn the bridge here, but to redeﬁne your roles in a collaborative way to keep the enthusiasm alive. Does the main sponsor or project manager seem particularly anxious

about the project? There are many reasons this could occur, especially if some of the factors above are in play. Anxiety could also be due to market pressures that it would be helpful for you to understand. For example, has the company stock price been dropping? Has a particular competitor made recent alarming strides? Is the business operating in the red? Again, these situations do not necessarily mean you shouldn’t take the project on; after all, they’re the kind of situations that often get a project funded in the ﬁrst place. But if you have a signiﬁcant concern that the company won’t be able to pay its invoices, that’s a risk you’ll want to weigh.

UNDERSTAND THE COMPANY CULTURE

Hierarchy Geert Hofstede has an excellent model outlining differences in culture, what he calls “cultural dimensions,” that often affect the way people interact and communicate. One of them is the concept of power distance, which is the extent to which members of a society (in our case, a company) understand and accept the distance between people of different levels of power. For example, if members of a company’s executive team are viewed as particularly powerful and potentially unapproachable, a company may have a large power distance and its employees may be more focused on the hierarchy. If the company encourages a democratic sharing of ideas and questioning of vision, it may have a relatively small power distance.

Power Distance Is “… the extent to which the less powerful members of organizations and institutions (like the family) accept and expect that power is distributed unequally. This represents inequality (more versus less), but deﬁned from below, not from above. It suggests that a society’s level of inequality is endorsed by the followers as much as by the leaders.” Geert Hofstede Cultural Dimensions www.geert-hofstede.com

Neither extreme can be considered good or bad in itself, although generally in the United States most employees seem to prefer the appearance of a small power distance in their workplace. What’s interesting to note is that this isn’t necessarily an indicator of how successful a company is. Apple has a relatively large power distance (if you consider the aura around Steve Jobs), and Google has a relatively small power distance as part of its culture, but both companies are known for being innovative leaders. What is important to note is that the power distance within the client company will have an impact on how you successfully navigate the political waters during the project. This aspect will become particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as sign-off points (discussed in Chapter 4). If you’re working at a company with a large power distance, take some extra

CHAPTER 2: THE PROJECT ECOSYSTEM

time to understand reporting relationships before scheduling meetings such as stakeholder interviews and reviews, and consider involving more people at intermediate levels during your communications.

Logistics In addition to the larger aspects of culture mentioned above, it’s also helpful to understand some of the elements that are more logistical in nature, so you can better integrate with current work methods or introduce change in a thoughtful way. For example, it’s helpful to understand the general pace expected within the company, including key release dates or deadlines that will affect the project (creating a software application on a yearly release schedule would probably have a different pace than a microsite supporting a seasonal campaign, for instance). Will your team be expected to work late hours to meet looming deadlines? Expectations regarding remote work versus on-site work are good to understand as well. If heavy on-site time is expected, you’ll need to plan for travel and resource setup there. If remote work is acceptable (or encouraged, which is common when working with global companies), it’s important to understand methods and tools of communication. For example, is use of instant messaging applications acceptable? What Web conferencing tools are in use? Are there methods of including international stakeholders that have proven effective in the past? It’s also interesting to understand the “paper culture” at a company. Some companies favor electronic media for most things, in which case a good projector and a consistent Ethernet connection is important. Others are very paper-centric, in which case you’ll need to make sure you bring enough copies to a meeting to make it productive. You may be able to change the culture of the project if you think another way is more effective. But it’s good to know that you’re asking people to change so that you can smooth the transition—and potentially understand why a particular approach isn’t working as you expected.

UNDERSTAND THE COMPANY CULTURE

Pulling It Together Now that you’ve explored the terrain of the project, you should have a better understanding of the project ecosystem: the environment you’re working within (the company culture), the general type of work you will all be engaged in (such as the types of sites you’re designing), and the people who you’ll be interacting with (including their roles and responsibilities). This information will be valuable as you outline your role in the project and get ready to begin in earnest. If you’re working as a freelancer or subcontractor, it will provide a base for writing a proposal covering your work on the project (see the next chapter, which discusses UX proposals). If you’re working as a member of a larger team and are not directly involved in writing the proposal, you can take your new knowledge into the project kickoff—the ﬁrst meeting of your team. For a basic guide to running a good meeting, see the online chapter, “A Brief Guide to Meetings,” or if you want to get straight into the kinds of questions to ask when the project gets started, see Chapter 4, “Project Objectives and Approach.”

CHAPTER 2: THE PROJECT ECOSYSTEM

Proposals for Consultants and Freelancers A Guide for Those in the Business Who Also Manage Their Own Business It can be challenging enough to manage projects and client expectations, but if you don’t have an appropriate agreement in place, you can ﬁnd yourself on the losing end of any project you take on. Proposals and statements of work are essential to protecting your business—and yourself—from ﬁnancial and legal troubles. After you accept a project and shake hands, make sure you spend the right amount of time composing an agreement that details the terms of your relationship and the payment schedule for your client. Russ Unger

Proposals There is an old saying that “no good deed goes unpunished,” and the same generally goes for landing any project—the high-ﬁves and feel-good moments are quickly replaced with “Oh, crap! It’s time to write the proposal!” The biggest challenge in writing the proposal is writing your very ﬁrst one. It’s nearly impossible to know where to begin if you’ve never had to author one yourself, and that’s where this chapter should come in handy. Every type of project you encounter will have varying ﬂavors that will keep you on your toes when it comes time to author the proposal. Fortunately, there’s something of a core that is common to all proposals and can be reused from project to project. (For a detailed discussion of project types, see Chapter 2.) When should you write a proposal? Always. Why should you write a proposal? Throughout the history of working on projects, the ones that have put people in the most uncomfortable situations have been those where there was no agreement in place between the client and the vendor. You may be very tempted to skip this step when you make the ﬁrst connection with a potential client and things seem to click. Even though you have an apparent understanding about the client’s needs and are able to articulate it in way that they understand, you really are not quite yet ready to start working. In fact, this is exactly the point where you need to slow down and take a breath. Instead of getting right to work, take the time to deﬁne your professional relationship and the rules of engagement with your new client. Jean Marc Favreau of the law ﬁrm Peer, Gan & Gisler, LLP, in Washington D.C., says, All too often contractors and their clients believe there is a meeting of the minds at the beginning of their relationship, when in fact ambiguities are just lying in wait. While it is almost impossible to prepare for all possible contingencies, a comprehensive written contract is your best defense and the smartest way to ensure that you do not later ﬁnd yourself in a courtroom arguing about the terms of your relationship. The more clearly you deﬁne the terms and parameters of your relationship with a client in a written contract up front, the less likely you will end up ﬁghting over each party’s obligations down the line.

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

New projects and new people are exciting. There is often a desire not to “kill the deal” by throwing a proposal into the mix, but, as in any relationship, the honeymoon feeling can eventually subside. Promises can be broken on both sides of the relationship. A client can fail to provide you with timely access to content. (I know that this is almost unheard of, but believe it or not, it happens! That’s sarcasm, in case you missed it.) Funding that was once available for the project may be shifted elsewhere—and then you, the one who is engaged in the work, may be left holding the bag. Companies also realize that they are taking risks working with external vendors—especially those who are very small businesses or independent contractors. Well-written proposals provide clients with a sense of stability and protection, which can help alleviate many of the concerns that might arise. A proposal also allows you to deﬁne terms that protect both sides in the event that something changes. If the client does not provide you with timely access to their resources, your timeline may slip; you need to make them aware of their obligations to the project’s success. If a client loses funding and kills the project—and you do not have a proposal or other form of contract in place—then you may run the risk of not getting paid for work you have already completed. The point should be crystal clear: Always write a proposal.

Creating the Proposal After you land the project, it’s time to get the proposal done. The sooner a proposal is approved and signed, the sooner you can begin work and—most importantly—begin to get paid for the work. The core components of a good proposal are Title page Revision history Project overview Project approach

CREATING THE PROPOSAL

Scope of work Assumptions Deliverables Ownership and rights Additional costs and fees Project pricing Payment schedule Acknowledgement and sign-off

Let’s take a deeper dive into each part of the proposal.

Title Page The title page is the simple page that introduces your document. Title pages are an interesting beast: there are a number of ways you can create them from a style and information perspective. How you do it 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) Version of proposal Submission date Your company name Proposal authors Project reference number Cost Conﬁdentiality

For your ﬁrst proposal include everything—except the client’s company logo, the cost, and (potentially) the project reference number. Why not include these elements on the title page?

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

Your client knows who they are. It’s probably not worth the time and effort to request permission to use the company logo, nor is it worth the possible unpleasantness if you inadvertently misuse it. The cost is best placed after you have identiﬁed the various components of the project in the body, and the cost information leads nicely into the payment schedule. The project reference number is something to be aware of. A lot of companies will not use one at all; however, some government agencies are known to rely upon this particular item, and if it is not found on your title page, your proposal may be rejected.

Figure 3.1 Sample proposal title page

In Figure 3.1, the (ﬁctional) client logo was used. In the event that permission was not given or a relationship was not established, it is best not to display the logo of the client company.

CREATING THE PROPOSAL

Revision History The revision history is its own section of the proposal and is used to identify how many times you have updated the proposal since the original version. In general, it is best to provide the version number, date, author, and any comments associated with the version, such as what was modiﬁed, in order to provide the reader with context as to the modiﬁcations (Table 3.1). TABLE 3.1 REVISION

Sample Revision History Table SECTION

DESCRIPTION

EDITOR

DATE

Original Document

REU

8-Jan-09

Assumptions

Updated to reﬂect software requirements

REU

11-Jan-09

1.0 1.1

Occasionally, clients will sign off on a proposal and then ask you for further revisions. If you choose to move forward with the client and make these changes, you should take the opportunity to update your document from version 1.x to 2.0. In essence, when a client approves a proposal and both parties agree upon the terms, you are ready to begin working. So when additional modiﬁcations are requested, you need to review them very carefully. This ensures your costs still make sense and that there is a clear understanding on both sides about the modiﬁcations and at what stage the project is restarting (if necessary). You should also always provide an appropriate explanation of why the revision constitutes a full 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 provide your client with a clear picture of what you envision their product will entail, as well as an explanation of what they can expect to ﬁnd in the rest of the proposal. Here is an example of the beginning of an overview: [Client Company Name] is seeking to create a new online Web presence. This Web presence provides [Client Company Name] customers with an ability to research and purchase products online, as well as other services and beneﬁts available through the company. The goals of the online Web presence are to…

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

You should be able to give a solid overview in one or two paragraphs, providing a very high-level amount of detail as to what the client should expect from you. It is a good idea to conclude the overview with a sound explanation of your recommendations and proposed approach to completing the project: This proposal will detail [Your Company Name]’s recommendations and approach for the design and development of [Client Company Name]’s online Web presence. Given the deadline of [deadline date], it is proposed that…

Project Approach The approach to the project will vary depending on what type of project you are undertaking. This is your opportunity identify to your client how you plan on working on the project with them. You get to deﬁne your rules of engagement and set expectations for the work that is ahead of you. Many individuals and companies operate with very similar methodologies— but use different names or clever acronyms that dovetail with their overall branding. Once upon a time, a mythological methodology was created to show to (potential) clients, and it found its way into many proposals. The process was called The PURITE Process™ (pronounced “purity”), and in sharing this with you, a mythological being has just died a little on the inside, so please take care to read this as a piece of ﬁction. The name of the process is slightly cheesy, and the process is clearly somewhat incomplete. Postlaunch analysis was omitted from this methodology (an oversight), but it should be included for all clients, of course. Without further delay, here’s the PURITE approach: [Your Company Name] has identiﬁed a standard process for project success with our clients. Although each of these phases may not be applicable to [Project Title], the entire process is deﬁned as follows: The PURITE Process™ is [Your Company Name]’s in-house methodology for ensuring success across the board for all initiatives. By utilizing PURITE, [Your Company Name] has a proven set of guidelines for working closely with clients and users/audiences to reliably maintain and exceed delivery expectations. P – Prepare. We dedicate a portion of every initiative to understanding your industry and your competitors and how they do business in order to be as informed as possible prior to beginning requirements gathering. U – Understand. We work closely with your subject matter experts and/or users to deﬁne the requirements for building the project correctly.

CREATING THE PROPOSAL

R – Render. Through the Render phase we create and develop all the pieces of the project/product. In our experience, any development phase requires a lot of heads-down, focused work effort but also timely, open communication with your team(s). It also requires that we... I – Iterate. The Iterate phase is repeated throughout the entire lifecycle of the project. We move as quickly as possible to bring the project to life, and this often requires creating multiple iterations in rapid timelines. This requires direct and timely involvement from you and your dedicated resources. The end result is the product you’ve speciﬁed—and helped to create. T – Test. We test every project throughout the course of our Render phase; however, we also require an extra set of eyes—from our own testing team and from your designated user group/audience group to perform goal-based testing. This additional round of testing helps ensure that as few stones as possible are left unturned in order to deliver a project that has been rigorously evaluated from multiple levels. E – Enable. Upon successful completion of the ﬁve previous phases and your signed approval, we will enable the solution and take it live. The PURITE Process™ doesn’t end there. After project completion, we regularly communicate with our clients. We will continue to gauge your satisfaction levels, understand your changing goals or project enhancements, and assist you in deﬁning the best approach for the future development of your project.

You are welcome to use as little or as much of this as is applicable or useful to you. The mythological author who created the process does not mind if you do not credit the source, either. Deﬁning your process can be as detailed as above or as simple as the following: Plan, Deﬁne, Develop, Extend Plan the overall strategy Deﬁne the detailed project requirements Develop, test, reﬁne, and launch the work product Extend the project by recommending enhancements and improvements based on information learned during development, testing, and post-launch

After you deﬁne your process, you have the opportunity to detail the various efforts that will take place in each phase of your approach, as well as what each of those efforts means to you and your client. The approach section of your proposal will vary in length depending upon the project, your process, and the activities that take place within each step of your process. Try to keep it to two to three pages maximum, though, and

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

ensure that you include only the outputs that you will be able to deliver to your client—to prevent further updating of the document or revisiting the project pricing.

Scope of Work The scope of work section is where you identify the division of labor for the project. That is, you identify which components of the project you are responsible for and which the client is responsible for. Reread that. Think about it for a moment. Let it sink in. There we go. That’s right. 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. Then later, when the client signs your proposal, they are agreeing to this arrangement, and you have a paper trail to back you up in the event of any misunderstandings. The intention here is to clearly identify who is going to be handling what aspects of the project, as well as what aspects of the project are included within your proposal and for the price that you have estimated. If you can ﬁnd no other really compelling reason to write a proposal, this should be reason enough. Here is a very brief example of a scope of work: We were approached by [Client Company Name] to provide all services required to build [Project Type]. [Your Company Name] will focus solely on the [User Experience Design Aspect(s)] of the [Client Company Name]’s website. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] in accordance to the Project Plan. [Client Company Name] will provide any required assets for use in the project, including fonts, color schemes, brand standards, etc.

Assumptions The assumptions section of the proposal is a good place to spell out, without leaving room for debate, what is needed from your client to ensure your success. That is, these are the things that you are assuming—and communicating to the client—that you will have access to or that will be delivered to you to make the project a success.

CREATING THE PROPOSAL

What you’re calling assumptions in this section are really expectations. It’s just a lot more polite to assume. You can create as many project plans as you would like, but if neither you nor the client commit to meeting milestones and objectives, both sides are committing to certain project failure. In general, the assumptions are an expectation of resources and assets, as well as timely (translation: prompt, immediate) access to both of these. Here is an example of how to write assumptions: Assumptions It is necessary that [Client Company Name] provide the following assets and resources. An inability to provide these assets and resources in a timely and complete manner may contribute to the unsuccessful or delayed delivery of this project. The following assets and resources are expected: Timely access to all required [Client Company Name] employees. Timely access to all required assets of the [Project] in current state, including any source ﬁles, if available. Content, as required and including but not limited to copy, imagery, audio, etc. for any aspect of [Project].

Deliverables Deliverables are the work product that you will create and turn over to the client. This section is your opportunity to detail to the client what type of work product they can expect from you during the course of the project. It is recommended that you handle status reporting separately, closer to the end of the project, but feel free to add it to this part of the project. Do provide descriptions of any work product that you might include, even if the work product does not get produced. This might seem as if it could be overkill or has the potential to open the “I read about [deliverable type] in the proposal, but I don’t see it here” can of worms, but one little word, may, can make the difference. Deliverables [Your Company Name] provides a variety of deliverables throughout the course of a project. For [Client Company Name], we have identiﬁed the following deliverables:

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

Creative Brief The Creative Brief is the ﬁrst step of the project. This document will help us to create a quick and effective, high-level overview of the project. The purpose of the Creative Brief is to clarify the goals and needs of the users and to deﬁne any of the special resources and/or constraints related to the project. And so on…

Ownership and Rights It is important to consider the extent to which you will allow your client to use the work product that you produce. These rights can be deﬁned in many different ways, but the majority of your work will fall into two categories: Work for hire Licensed work

Work for hire (known in the legal world as “work made for hire”) projects are considered to be created by and under copyright by the party who pays for the work—not the party responsible for doing the actual work. This means that when performing work on a project that is work for hire, you have absolutely no rights to the work and everything you create related to the project is owned by the client. This situation is difficult for many companies and individuals to contend with: It often means there is no downstream “maintenance” work (with its additional revenue), as clients may decide to maintain the project on their own once it has been completed. Do not be swayed from a project where a client forces the stipulation; it is not uncommon. When you put work for hire projects in the context of full-time employment with a company, this is pretty standard for an employer-employee relationship. It is also an opportunity to visit your pricing model—many projects are billed at a somewhat increased rate to compensate for the potentially lost revenue in the future. Remember, this all depends upon the relationship you have with your client and how you choose to do business. Time and experience will help you make the right determination for the types of work you do and the pricing models you choose. Licensed work projects enable you to retain the copyright to the work but grant other parties the right to copy and/or distribute it. You can build any number of stipulations into the licensing agreement. You will most likely CREATING THE PROPOSAL

take advantage of licensing your work when you retain ownership of all of the source material of your work and deliver only limited-use work product to your clients (such as PDFs instead of original, editable Word, Visio, Axure, OmniGraffle, or other documents). You can take many different approaches to licensing your work, including licensing work to be used without modiﬁcation, noncommercially, or a number of other ways that may ﬁt your situation. Creative Commons (http://creativecommons.org/about/licenses) provides easy-to-understand explanations of a variety of license types that you might make use of, but those are only a small subset of the licensing world. If you ﬁnd yourself in a situation where you are getting into very detailed and speciﬁc needs, it is always best to contact a copyright attorney to assist you in creating the best possible solution.

Additional Costs and Fees It is important that your client understand whether the project pricing you will provide for them does (or does not) account for external resources. For example, some projects may require the purchase of stock photography from a vendor. You can either purchase the imagery (with the appropriate usage rights) and include that as a part of your fee, or you can clearly identify the purchase of imagery as an additional cost that will be passed along to your client. You may also offer services that you want to make your client aware of—this is a good opportunity to promote those services. Here is an example of how to explain how additional costs and fees will be handled: Additional Costs and Fees In the event that outside resources are required (such as content, imagery, fonts, etc.), these shall be identiﬁed, approved by and billed to [Client Company Name]. In addition, [Your Company Name] can provide hosting services to our clients with very low overhead. We provide hosting services—including conﬁgurable, Web-based e-mail—starting as low as $25 per month, with a $25 setup fee. In the event that [Client Company Name] would like to purchase a “maintenance” package, [Your Company Name] will work to create a package that is mutually agreeable and beneﬁcial to both parties.

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

Project Pricing After you document the details of how you’re going to perform the work for the project, it’s a pretty good idea to let the client know the cost. How you arrive at the price is largely up to you, but here’s a tip: Estimate how long you think it will take you to do the project—including a speciﬁc number of revisions, estimate a reasonable amount of time for project management, which could be around 25 percent; then determine the hourly billable rate you want to charge, and calculate it all out. There are a variety of formulas to help you with this, such as applying degrees of difficulty to each portion of the project, to help you come up with a cost range to provide to your client. In most cases, experience is going to be the key to helping you appropriately estimate your projects—from a time-and-materials perspective. How do you determine your billing rate? Research what others are charging, for comparison, by locating salary surveys and contractor rates. For example, organizations such as the Information Architecture Institute (www.iainstitute. org), AIGA (www.aiga.com), Coroﬂot (www.coroﬂot.com), and the talent agency Aquent (www.aquent.com) perform salary and contractor rate surveys. You can get a decent idea of the rates you could charge by taking into account your experience, what others in your market are charging, and what you feel is somewhat fair. Remember: You can always lower your rate. It’s a lot more difficult to ask your client to pay you more money once they’ve seen numbers on a page! There are many different ways to structure the pricing for your project. Depending on the nature of your project, you may want or need to provide multiple estimates that allow for a variety of pricing options. Suppose, for example, you provide a client with two options: a static HTML Web site and a Web site with a content management system (CMS) that would allow for dynamic content (which the client could then administer without dedicated resources). Here’s how you could phrase the project estimates: Project Estimate [Your Company Name] has proposed multiple estimates for [Client Company Name], in order to provide the best possible options for your immediate and/or future needs. [Your Company Name] makes the assumption that all content will be provided by [Client Company Name]. In the event that [Your Company Name] is requested to provide content services, the estimates will need to be redeﬁned.

CREATING THE PROPOSAL

[Your Company Name]’s estimates allow for ﬂexibility from a cost and needs perspective. The estimates are as follows: Estimate 1 [Your Company Name] estimates that the [Project] for [Client Company Name], without any interactive content…

Remember, there is no real wrong way to put together your project estimate—unless you put yourself into a negative cash ﬂow position!

Payment Schedule There is a myth ﬂoating around that all freelance projects are paid 50 percent up front, before the work begins, and 50 percent upon completion, when the project ends. This myth needs to be dispelled—right now! This is no way to do business, and it is no way to ensure timely, consistent income while you perform the 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 get the project done and get paid, instead of working through a change order process. You can price projects a number of ways—from submitted invoices in a predetermined time frame to milestone-based payments. A wiser approach is to steer your projects to a recurring payment schedule with regular, detailed invoices. This approach should also provide clients with a clear understanding of what has been accomplished and what work is remaining on the project. The following example is one way to structure payments for your work: Payment Schedule [Your Company Name] typical payment schedule is to receive a retainer fee of XX% of the total estimated price of the project prior to commencement. [Your Company Name] shall submit invoices on the 1st and 15th of every month; payment is due in full within 14 days. Upon completion of the project, [Your Company Name] shall deliver all work product to [Client Company Name]. Once the materials are satisfactorily approved, [Your Company Name] shall refund any payment excess remaining from the retainer or [Your Company Name] shall submit a ﬁnal invoice for amounts not covered by the retainer. Note: If [Project] is placed on hold for a period of more than 14 days with no work progress made, [Your Company Name] shall submit a ﬁnal invoice for any fees not covered by the retainer and shall be provided with the right of ﬁrst refusal in the event that the project is reopened.

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

Although it’s not required, it is helpful to include a note about how the project will be handled if it is put on hold for an extensive period of time. This stipulation can help you keep your project on track and moving forward— and it gives you a discussion point with your clients. If you will not be doing additional work for them for a long time, you want to be able to move on and look for work to ﬁll the void.

Acknowledgment and Sign-Off While it is very important to ensure that you have a proposal in place, but by itself it’s not enough. The proposal really doesn’t mean much until the right person at your client company has approved and signed it. It’s vital to make sure that everyone has a clear understanding of what is going to be taking place and how much is expected from each side. It is equally important that you protect yourself from the “iteration superhighway” and reduce your risk of allowing a client to engage you in “feature creep”: continually requesting “just one more thing” that needs to be included. Sign-offs are pretty simple and clear. Once you have created the proposal document, you will provide your client with an acknowledgment and sign-off that will approve the agreement between your two companies. Always prepare two copies—one for each party—and ensure that both copies are signed. Here is an example of an acknowledgment you can use: Acknowledgment This proposal is acknowledged and agreed in its entirety by [Client Company Name]. This proposal must be signed and dated by an authorized representative of [Client Company Name] in order to be in effect. Alternately, a signed purchase order referencing this proposal will constitute acceptance in place of this signed document (provided, however, that any preprinted terms on such purchase order shall be considered null and void and of no effect). This proposal constitutes the entire agreement between the parties with respect to the subject matter of this proposal. This proposal merges and supersedes all prior oral or written agreements, discussions, negotiations, commitments, writings, or understandings. This includes without limitation any representations contained in any sales literature, brochures, or other written descriptive or advertising material and is the complete and exclusive statement of the terms of the parties’ agreement. Each of the parties acknowledges and agrees that in executing this proposal it has not relied upon, and it expressly disclaims any reliance upon, any representation or statement not set forth herein or in the Agreement.

CREATING THE PROPOSAL

Accepted by the authorized representatives of: [Your Company Name]

[Client Company Name]

By: ________________________________

Name: _____________________________

Name:_____________________________

Title: _______________________________

Title: ______________________________

Date: ______________________________

Make all checks payable to: [Your Company Name]

Statements of Work A statement of work (SOW) is a high-level deﬁnition of your project objectives that you should be able to put together in a two- to three-page document (not including cover). The SOW is typically written before you get into detailed requirements, although depending upon your client and your project needs, you may choose to create a hybrid document that best suits your needs. In general, SOWs should be used to build consensus between your team and your client’s stakeholders early on. The SOW will deﬁne the inputs and outputs of the project, as well as assumptions and limitations. At this point, it is not uncommon for clients to ask you to provide a “ballpark ﬁgure” for the work you will be doing for them. It can be a little risky to answer that at this point. It is recommended that you do your best to avoid speciﬁcs or commitments without deﬁning the details. It’s just not possible to know how much a project is going to cost when you haven’t yet written the proposal and/or requirements document. That said, you have to make a judgment call at this point. If you are working on a project such as a basic Web site, and you have successfully completed several similar projects before and/or have worked with the same client before, then you have some wiggle room. Remember, erring on the side of caution is always better than an uncomfortable situation later on in the project. A statement of work should be approximately two to three pages and, at minimum, contain the following:

CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCERS

Title page Revision history Project reference number Project summary Start date End date Rate/price Project explanation Activities and deliverables Itemized costs and payment schedule Acknowledgement and sign-off

Do the elements look familiar? They should—you can put together an SOW utilizing a trimmed-down version of the proposal. You have now learned how to put together two types of documentation that will allow you to identify the work you are performing for a client. These documents should be the foundation of any project work you do for any client and will give you and your clients a well-deﬁned set of marching orders for your projects.

STATEMENTS OF WORK

Project Objectives and Approach Know Which Star to Navigate By One of the keys to a good project is to start the team out with clear project objectives and a well-understood approach. Ideally, the project leadership will have this deﬁned for you—but how do you know if they don’t? This chapter talks about forming project objectives and offers some questions that will help you solidify those goals. We’ll also discuss some common project approaches (or methodologies) and how they may inﬂuence the way you work. Carolyn Chandler

ou’re in the project kickoff, with the full team for the ﬁrst time. The project manager hands out some materials and gives you an overview of the project. By the end of the meeting, ideally, you 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 the major dates or milestones for key points, such as getting

approval from business stakeholders? All of these questions concern the expectations that stakeholders have for the project: what the project will accomplish and how they will be involved in it. The ﬁrst two questions pertain to the project’s objectives and the last two to the project’s approach. A project objective is a statement of a measurable goal for the project. Let’s talk about objectives in more detail.

Solidify Project Objectives Objectives are an important focusing lens that you’ll use throughout the project. They should spring from the client company’s overall business strategy, so the project objectives should be in line with the strategic initiatives within the company. For example, if there is a strategic initiative to appeal to a new group of prospective customers (called a market), the site or application you’re creating may be an effort to provide that market with online access to products and services relevant to them. The objective for that project would then be focused on reaching and engaging that market. A clear objective resonates throughout a project. It helps you Ask the right questions as you gather ideas from business stakeholders Plan research with users and focus your analysis of the results Detail the ideas gathered from stakeholders and users and convert them

into a consolidated list of project requirements Prioritize those project requirements based on their value to the company

SOLIDIFY PROJECT OBJECTIVES

Create effective interaction designs Manage requests for changes to the design once development begins Focus efforts during deployment activities (such as training and com-

munications to users about the new site or application before and during its launch) Determine whether you’ve met the needs of the client company, once

the project is launched When you start a new project, you probably have project objectives from the project’s sponsor (the business stakeholder who has direct responsibility for the success of the project), as well as a set of project-related requests coming from business stakeholders and from customers, but they all may be a bit fuzzy (Figure 4.1). Your goal is to clarify these into solid statements that you can use as a yardstick for the project’s success.

Project-Related Requests

Company Strategy Fuzzy Objective

User Need Stakeholder Idea

Fuzzy Objective

User Complaint Stakeholder Idea

Figure 4.1 Fuzzy objectives, ideas, and needs

A solid objective is Easy to understand. Avoid insider terminology. Distinct. Avoid vague statements; instead, use wording that seems like it

will be useful when you’re prioritizing requirements. Measurable. Make concrete statements that you can set an independent

measurement against to determine your success. As you deﬁne a fuzzy objective, making it clear and measurable, it becomes a solid objective that you can base decisions on.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Figure 4.2 Objectives being solidiﬁed

Company Strategy Project Objectives

You’ll hear many statements that could be considered objectives. Analyzing fuzzy ones such as those below will help you solidify your objectives and communicate more effectively within the project team. Business Advocate

“Our objective is to become the market leader in industry x.”

This is an objective for the entire company, but is too broad for a speciﬁc project. Multiple initiatives at the company need to come together to make this happen; any one site or application may help with this but will be very unlikely to be able to handle the entire burden—unless the entire company is about this one site or application and it ends up being wildly successful. Business Advocate

“Our objective is to generate excitement among our customer base.”

This one is better, because a site or application could have an impact on this, but it’s still too vague. Why is it important to generate excitement? How does that excitement translate into meeting a business need? And how can you tell if you’ve been successful? Business Advocate

“Our objective is to increase the amount of traffic on our Web site.”

Now we’re getting there. This one is easy to measure, but it’s too focused on an intermediate step. Suppose you do generate more traffic: It may not help you if people don’t perform the actions you want once they get there.

SOLIDIFY PROJECT OBJECTIVES

Fuzzy objectives can give you a sense of a client’s desires and larger goals. From these you can craft more solid project objectives, such as Increase the revenue from online sales by 10 percent. Increase the revenue from online advertising by 20 percent. Increase the number of current and potential customers in our customer

database to at least 20,000. Deliver highly rated and highly referenced content to our primary users.

(Note that this one requires some work to decide how to measure “highly rated” and “highly referenced,” but the elements are there to build from.)

Each of these can be measured and affected by your project. They can also map pretty closely to your designs and the features offered. For example, it’s very common to offer an online newsletter as a way to meet an objective of growing the customer database: To deliver the newsletter you’ll need to capture customer e-mail addresses, which will be added to the database. Objectives may also bring out new requirements. For example, if you’re measuring success by the average rating given to articles on your site, you’ll need a feature that allows users to give ratings. In these ways, objectives help you focus as you gather ideas for the site, and these may later become project requirements. If there are multiple objectives, be sure to create a prioritized list with your business sponsor and project team. Objectives sometimes conﬂict with each other during design, and the team will need to know what takes precedence. The ﬁnal prioritized list of objectives should come from your project sponsor, but you can be a key part of the discussion. Let’s talk about how.

How Can a UX Designer Help? If you ﬁnd the project objectives are unclear at the beginning of a project, you can bring your facilitation skills to bear. Help the project team understand the business-related context of the project by holding a workshop with key stakeholders (see the next chapter for more on identifying the right stakeholders). Your goal in this session, which usually lasts two to four hours, is to bring out information on the company’s strengths, weaknesses,

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

opportunities, and threats. Called a SWOT analysis, this is a common business analysis technique and one way to discuss a company’s position in the market. You can also use this time to discuss the company’s competition. Understand Strengths and Weaknesses The SW in a SWOT analysis are the company’s current strengths and weaknesses as they pertain to the project. Strengths and weaknesses could include internal processes as well as external perceptions—and often they inﬂuence each other. For example, a company with a large research and development (R&D) department could have access to a large source of original research that is published (a strength), but there may be no one to help make that content more accessible to the average user, leading to the perception that the company is “too academic” (a weakness). Identify Opportunities and Threats The OT is the future-facing half of the SWOT. Considering the things that differentiate the company from its competitors, what future initiatives could it pursue that will open up a new niche or strengthen a current one? What situations could threaten those plans? For example, our R&D company may decide to hire writers to publish more accessible feature articles around its original research (an opportunity), but if the current site toolset doesn’t have robust content-management features, the publishing process may be prohibitively slow. That could give competitors a chance to respond more quickly (a threat). Compare Competitors What is the company’s main competition? Who are the competitors for the site being developed? They can be different, especially for large companies or brand new sites. Are there sites that aren’t direct competitors but that represent interesting models to consider? You can learn a lot from reviewing other e-commerce sites to see whether and how they sell what you’re selling. Pull It Together The SWOT and competitor discussions are good topics to discuss at the same time because they interact with each other. It’s hard to talk about

SOLIDIFY PROJECT OBJECTIVES

future threats without knowing who your competitors are—and once you start talking about future opportunities, new competitors may come to mind. Once you have a full picture here of the company’s competitors and SWOT, your project objectives—as well as the overall ﬁt of your project within the company strategy—should become easier to deﬁne, and the priorities among them should become clear. Solidifying project objectives helps you understand expectations of what the project is going to accomplish. Next, let’s talk about expectations concerning how the project will be run. Understanding the project approach will help you collaborate effectively and involve the right people at the right time.

Understand the Project Approach Knowing the overall approach, or methodology, of a project is an important part of understanding when and how you’ll be involved and how you should be involving others, such as your project team and business stakeholders. Sometimes there seem to be as many project approaches as there are projects. How to choose the right approach for a project is a large topic in itself. The methodology you choose can depend on many things, including the structure and location of the project team, the technologies being used on the project, and the degree to which collaboration is a part of the company’s culture. For the purposes of this book, we’re assuming that you’ve joined a project where the approach has largely been determined by those responsible for the project’s success, such as the project sponsor and project manager. In this situation, your main goal will be to understand the approach and help make it effective for the business stakeholders and your users. Here we’ll focus on two of the most common types of approach, as well as a third that shows a possible variation you might encounter on a project. The important thing to note is that most approaches involve the same steps: Plan the overall strategy, approach, and team structure. Deﬁne the project requirements. Design interaction and visual concepts and evolve them into detailed

speciﬁcations. Develop, test, and reﬁne the solution.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Deploy the solution via messaging, training, and a planned launch. Extend the project by making recommendations for improvements.

The names for these steps may vary, as may the degree to which they overlap and the way information is documented. But the general activities in each step are common to most projects and to all three models presented here.

Waterfall Approach A waterfall approach involves treating the steps of a project as separate, distinct phases, where approval of one phase is needed before the next phase begins. For example, the Design phase does not begin in earnest until requirements have been approved by business stakeholders, who sign off on one or more requirements documents at the end of the Deﬁne phase. Approval

Plan

Approval

Deﬁne Design Develop Deploy Extend

Figure 4.3 Example of a waterfall approach, where each phase “falls” into the next

The problem with a pure waterfall approach is that it assumes that each phase can be completed with minimal changes to the phase before it. So if you come up with new requirements in the Design phase, which is common, you must suggest changes to documents that were approved at the end of the Deﬁne phase, which can throw off the plan and the schedule.

Agile Approaches Because change is constant, project teams are continually looking for more ﬂexible approaches than the waterfall model. Many methodologies follow a more ﬂuid approach, with some steps happening alongside each other; for example, versions of the Web site could be released on a rapid, iterative schedule using an agile or rapid development approach. An agile approach generally has a greater focus on rapid collaboration and a reduced focus on detailed documentation and formal sign-off. UNDERSTAND THE PROJECT APPROACH

Iteration 1

Develop

Iteration 2

Develop

Iteration 3

Develop

Deploy Design Deploy Design Deploy Design Deﬁne

Deﬁne

Deﬁne Approval

Plan

Deploy Release Extend

Figure 4.4 Example of an agile approach

A true agile approach (following the best practices developed by members of the Agile Alliance, for example) calls for small teams whose members are located next to each other physically, with little focus on deﬁning formal roles between team members. Working this way allows a very high degree of collaboration, which reduces the need for heavy documentation between the stages of design, development, and testing. A team member can pose a question, come to the answer together with other team members during a quick whiteboarding session, and implement a solution without the delay of detailed documentation and approval. Stakeholder reviews occur with a fully functioning system when one of the many iterations is released, and the resulting input is taken into account as the next iteration is planned. (Iterations are draft versions of a particular site or application.) When an agile approach is working as it’s designed to, it’s a beautiful thing. At most companies and within most consulting engagements, however, teams rarely follow a pure agile approach. In part, this is because companies are increasingly using distributed teams and remote workers, which makes it difficult to maintain the high degree of collaboration needed to take best advantage of the pure agile approach.

Modiﬁed Approaches Most projects try to follow an approach that marries the best of both worlds, with enough structure and documentation to reduce the risks posed by distributed teams and turnover of team members, but enough collaboration and iteration to respond to changes in a relatively nimble way. For example, a project may follow a waterfall model but include an overlap in phases so that there are key collaboration points from team to team. This allows

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

potential changes to surface earlier in each phase. This may also include an early release (such as a beta release to a particular user group) with a shorter iteration cycle. Feedback from that release can then be incorporated before the full deployment of the new site. Plan

Deﬁne

Develop Design

Design

Deﬁne

Develop Deploy Beta

Deploy Release Extend

Figure 4.5 Modiﬁed waterfall with beta release

Notice the smaller iterations within the Design phase in the Figure 4.5. That’s one of the greatest values you bring to your team as a UX designer. Tools such as wireframes (Chapter 11) and prototypes (Chapter 12) allow you to gather feedback on quick iterations of ideas, before a lot of development time has been put in. A modiﬁed waterfall approach like the one in Figure 4.5 is among the most commonly used methodologies, so it’s the approach that forms the framework of this book. However, many of the topics covered here will apply to your project regardless of the speciﬁcs of your approach, because the basic activities behind them—deﬁning and designing, for example—are still necessary.

Deep Diving If your project is using an agile approach, you’ll have unique needs during requirements gathering, such as the writing of “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

How Does the Approach Affect Me? Knowing your approach helps you understand a number of things: What questions you should be asking, and when. For example, if you’re

working with a pure waterfall approach, you’ll need to put in extra effort to make sure the requirements captured in the Deﬁne phase contain all the information you need for the Design phase. (We’ll be discussing requirements in the next chapter.) Expectations on how project team members will collaborate and how

close that collaboration will be. For example, an agile approach requires very close collaboration. A waterfall approach may involve individual work most of the time, with touchpoints once or several times per week. The level of detail needed in your documentation and the level of

formality. Documents submitted at sign-off points need to be formal, almost like legal contracts. Typically, you’ll need more formal documents in a waterfall approach, where sign-off is required before you move on to the next phase. However, you may also have some formal sign-off documents when using an agile approach—for example, to capture information at major decision points, such as when a particular iteration is prepared for full release and deployment. Important milestones that involve approval from stakeholders and

deployment to different groups. The approach will determine what different audiences need to provide at various points in the project, including approvals from stakeholders at sign-off points and feedback from potential users during a beta release. Now that you’ve solidiﬁed your project objectives and gained an understanding of the project approach, in the next chapter we’ll start with the primary work in the Deﬁne phase: gathering requirements.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Business Requirements Know the Problem Before You Create the Solution By the time the project team gets together you’ll probably have heard, or have come up with, a lot of ideas about what needs to be done. There may already be lists of features provided by some prominent members of the company (your business stakeholders), along with their opinions about which features are most important. These are elements of the business requirements for the project, and they’re a good start. To make sure you have a complete solution at the end of the project, you’ll need to generate and clarify requirements from multiple viewpoints. In this chapter we’ll focus on gathering and detailing requirements from your business stakeholders. Carolyn Chandler

hapter 4 covered fuzzy objectives and discussed some ways you can help clarify them for yourself and the project team. In the early stages of a project, you’re also likely to have a set of requests that are relatively fuzzy. These may be ideas from stakeholders, user complaints, or user requests. To make these useful and trackable components of your project, you’ll need to coalesce these ideas into requirements. Requirements are statements deﬁning what the site or application needs to do. Ideally, a business requirement Provides insight into the overall need that must be addressed Represents and consolidates needs provided by different stakeholders Gives direction for design, without being too speciﬁc about how it will be

accomplished Serves as a distinct unit of work for purposes of prioritization and tracking

Here’s an example of an idea for a feature on an e-commerce Web site. You could receive this same idea from a couple of different business stakeholders early in the Deﬁne phase: “Customers can track their orders online.” This is a good base for a requirement, but it’s fuzzy. Start asking questions that get to the details of the requirement, such as Why is it important to the business that customers be able to track their

orders online? For example, is it to cut down on the number of calls to customer support? Does the company currently have the capability to track packages online?

If not, new requirements will need to be captured for the tracking features, or the company may need to partner with a third party. How accurate does the tracking have to be? What kind of information

should be included in the tracking details? For example, does the site have to provide an updated estimate for delivery time? Asking these sorts of questions will help you coalesce fuzzy ideas into solid requirements. It will also make it apparent that the same statement can mean different things to different people.

CHAPTER 5: BUSINESS REQUIREMENTS

For example, one stakeholder may think tracking packages involves receiving a conﬁrmation e-mail Stakeholder Idea with a tracking number, which can be entered on UPS.com or another site so that the customer Stakeholder can see the latest stop the package has reached. Idea Another stakeholder may think the company needs to push the envelope on package tracking and invest in developing the ability for customers to track packages via GPS, seeing the exact location in real time using an online map. As you can imagine, there’s a signiﬁcant difference here in user experience and scope! It’s important to outline these differences early in the project. Otherwise, you’ll end up developing a solution that misses the intent of the business stakeholder—and potentially misses the project objectives. That leads to unhappy stakeholders and, if the feature needs to be redesigned, lost time and money. So, clear and detailed requirements are a key part of your overall project. Getting to a consolidated list of project requirements involves the following steps: 1. Understand the current state of the site or its competitors. 2. Gather needs and ideas from business stakeholders as well as current and potential users. (See Chapter 6 for details on working with users.) 3. Coalesce ideas into requirements. 4. Prioritize requirements based on project objectives. (See Chapter 9 for suggestions on setting priorities.)

Business & User Project Requirements Requirements Company Strategy

Figure 5.1 Coalesce ideas from business stakeholders into business requirements, and ideas from research with users into user requirements. Then, use project objectives to focus prioritization efforts and create a consolidated list of project requirements.

BUSINESS REQUIREMENTS

First, let’s talk about gaining an understanding of the current state of your site so that you have a context for the ideas that will be coming your way during requirements gathering.

Understand the Current State When diving into the speciﬁcs of the site or application you’re designing, it’s important to ground yourself by understanding the current state of the site (if you’re redesigning one that already exists) or by understanding key competitors more thoroughly (if you’re designing a new site or application). You can learn a great deal about the current state through stakeholder interviews (more on this in a few pages). You can also gain a lot of understanding on your own, and this can serve as a strong base for stakeholder interviews and user research efforts. A great way to gain background information and generate ideas that could become requirements is to conduct a heuristic analysis.

By Any Other Name… The word heuristic means a rule of thumb or best practice. A heuristic analysis has come to mean a review of a product against a set of rules (heuristics) for usable design, usually conducted by a UX designer. User-friendly sites will follow most or all of the heuristics you use in your analysis. You may also hear this technique called a heuristic evaluation, expert review, or some combination of these terms.

Heuristic Analysis A heuristic analysis is a technique you can use to evaluate the usability of an existing design, based on best practices within the user experience ﬁeld. You can conduct such an analysis on the current site at the beginning of a redesign project or analyze competing sites to understand opportunities for offering a better user experience than other companies. The result is a document describing the strengths and weaknesses of the site, including recommendations for improvement. After it’s complete, you’ll have a deeper

CHAPTER 5: BUSINESS REQUIREMENTS

understanding of the site analyzed and a list of ideas to contribute to the requirements for the new site. For example, a commonly used heuristic is this one, from Jakob Nielsen’s list of ten usability heuristics (view the complete list on Jakob Nielsen's site, at www.useit.com/papers/heuristic/heuristic_list.html):

Visibility of system status. The system should always keep users informed about what’s happening, through appropriate feedback within reasonable time.

There are many situations on a site where this heuristic may not be followed. For example, let’s say the user clicks on a Download button and gets no message that his ﬁle is being downloaded. The system has not informed the user that the ﬁle is in the process of being downloaded, even though the download has started. So the user may click the button again, thinking that he missed the button the ﬁrst time…and then click again.... This can lead to multiple downloads—potentially causing problems for both the performance of the site and the user, who now has multiple downloads in progress without realizing it. During the heuristic analysis, you can note this as a problem area, describe it, and rate its impact. You may also share an idea that might address the problem, which could be added to the requirements list. Why Conduct a Heuristic Analysis? Conducting this kind of analysis is a relatively quick and inexpensive way of obtaining feedback on a design. A heuristic analysis can provide a general understanding of the design quality and help identify any potential design issues. Keep in mind that this activity does not directly involve end users and shouldn’t be a replacement for true user research. For example, it’s possible that only 50 percent of your heuristic ﬁndings may actually be validated by later research. The analysis does, however, give the team a good handle on likely areas of concern. If you’re working on redesigning an existing product or site, it can also be good for identifying obvious quick ﬁxes that can lead to immediate improvements as the redesign efforts continue behind the scenes.

UNDERSTAND THE CURRENT STATE

How Do I Do It? The speciﬁc heuristics you use may vary from project to project, but the process for conducting the analysis will generally remain the same: 1. Gather product and project background knowledge. Make sure you have the objectives of the site, a list of the main user groups that need to be supported, information on the kind of environment users are likely to be working in, and a basic understanding of any specialized knowledge your users are likely to have. (Your analysis will be different for a site built for general consumers than a site built for pharmacists, for example.) If you need help with the last one, visiting a variety of competitive sites or applications can help you understand the most common terminology and areas of interest. 2. Choose the heuristics to use. There are many heuristics out there to reference. In addition to Jakob Nielsen’s list, many UX designers refer to Bruce Tognazzini’s list of design principles: www.asktog.com/basics/ﬁrstPrinciples.html. Once you’re familiar with the subject matter of the site, you may want to add a few of your own—especially if you’re analyzing more than one site. Be sure to keep your list to a manageable size (say, 8 to 12); too many heuristics can make the technique unwieldy for you and your readers. 3. Walk through prioritized areas of the site, identifying areas where the heuristics are followed well or missed. Each observation you make should have the following information: The general observation. A short statement summing up the ﬁnding. Ideally these will be numbered so that you can reference them quickly as you walk people through the report. A short description. A paragraph or two describing the context of the observation—for example, the point in a particular process where you noticed a problem. An impact ranking. This rating can be high, medium, or low for observations of issues, or it can be a note of a positive ﬁnding if you’re sharing something that the site did well. In general, high-impact issues are those that you believe will cause many users to fail a particular task or

CHAPTER 5: BUSINESS REQUIREMENTS

permanently lose information (for example, an issue that causes a user to lose changes to a document she’s been working on). Medium-impact issues are those that cause frustration and errors but don’t cause irreversible issues. Low-impact issues are minor problems that may cause some confusion but don’t typically lead to lost time or frustration. Recommendations. These are next steps or ideas that you share, which may serve as a remedy 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 appear to be bringing back all possible results.

HIGH Concern

A sample test of the search function yielded mixed results. Searches using a name in a relatively new post, featuring a less commonly covered topic, occasionally returned no results. It also appears that primary search returns links to new stories only, not videos. Recommendations 1. Ensure newly added content is indexed and searchable before, or very shortly after, being publicly available. 2. Consider surfacing related content when search results are brought back—for example, stories in similar categories or with similar tags—so users who are exploring have more threads to follow. 3. Consider universal search that presents results organized by category. 4. Use search term logs to understand commonly searched items. This may also provide insight into items that users are having trouble ﬁnding.

Figure 5.2 A sample observation in a heuristic analysis report

4. Present your ﬁndings to the project team and primary stakeholders. Walk them through your observations and recommendations. Discuss why you gave the ratings you did. (This is also a great time to have a prepared recommendation on how to validate your ﬁndings, using one of the techniques discussed in Chapter 6.) How Does a Heuristic Analysis Help with Requirements Gathering? Once you’ve completed your heuristic analysis, you’ll have a deeper understanding of the current state of the site (or its competitors), and a list of ideas that can contribute to requirements gathering. You’ll also have some ideas on how to structure the topics you’ll need to cover during requirementsgathering sessions—which leads us to the next step of that process.

UNDERSTAND THE CURRENT STATE

Gather Ideas from Stakeholders As we saw in our example at the beginning of this chapter, if you don’t get context for an idea, such as “Customers can track their orders online,” you risk missing the differences in expectations between stakeholders, like those of our friend who wants packages to be tracked by GPS. One of the most common mistakes made on a project is to seize on a feature and call it a requirement without ﬁrst understanding the problem and the expectations around a solution. So why does the requirements-gathering process get shortened so often? Gathering ideas—and coalescing them into requirements—can take quite a bit of time. It’s easy to underestimate the number of questions you need to ask to outline requirements so that they can be prioritized. And if the process isn’t well structured or participation is incomplete, there can be a lot of churn that can last throughout the project. (Churn is time wasted in extra meetings and work iterations caused by lack of communication and involvement. These are different from the more productive work iterations that are part of designing and testing valid solutions in an effort to ﬁnd the best one.) So how do you encourage a well-balanced requirements process that’s focused on business needs but avoids being a churning time-suck? Here are some steps for an efficient process: 1. Outline roles and responsibilities. Make sure project team members understand the roles that they should be ﬁlling as requirements are gathered. 2. Gather the right stakeholders, in the right groups, to ensure time is used in the best way during requirements-focused interviews or meetings. 3. Create a plan for the meetings, including topics to be covered and questions to be asked during meetings. 4. Run the meetings efficiently, capturing ideas and getting clariﬁcation. Investigate ideas to dig down to the needs behind each one. When your meetings are ﬁnished, don’t forget to thank the stakeholders involved and keep them updated on progress once you move to a consolidated, prioritized list. Let’s examine each of these steps in more detail.

CHAPTER 5: BUSINESS REQUIREMENTS

Outline Responsibilities The act of gathering business requirements generally involves members of the project team interviewing key business stakeholders to gather ideas. Business stakeholders are those within the company who have a businessoriented stake in the success of the project or have subject matter expertise to contribute, or both. These folks aren’t on the project full time, but they need to 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 get, unless you plan ahead. The project sponsor (or sponsors) is the business stakeholder who also has direct responsibility for the success of the project, often at a relatively high level in the company, such as director. He or she won’t be on the project on a day-to-day basis for the whole project lifecycle but will likely be actively involved in requirements gathering and ensuring a high level of participation by business stakeholders. The sponsor may also sit in on some or all sessions. The project team includes people officially assigned to the project as ongoing resources. They may be involved as the project manager, UX designer, business analyst, technical lead, visual designer, quality assurance lead, and so on. Depending on the size of the project, this may be their primary job. Within the project team itself, responsibilities during requirements gathering are often unclear. Taking time to deﬁne responsibilities early on will help ensure an efficient gathering process. Here are some questions to ask as you determine the speciﬁc responsibilities each team member will shoulder during requirements gathering: Who is primarily responsible for gathering and scheduling the right busi-

ness stakeholders in the most productive groups? This could include both internal and external stakeholders (such as partners, vendors, and so on). Who creates the structure of topics and questions for the business stake-

holder meetings? This is a great collaborative exercise for the team, if time permits. The main facilitator can then arrange them in a structure that ﬂows well in a meeting. Who facilitates the meetings? Who takes notes, and how are they shared?

GATHER IDEAS FROM STAKEHOLDERS

Who follows up with whom afterwards? Will someone from the technology team be present at all the meetings?

If so, how is that person involved (are they listening, providing input, or something else)? As a UX designer, whether or not you’re primarily responsible for one or more of these areas, you have important skills to bring to the process. Creating a structure for topics and questions requires a knack for clear categorization (which sounds like a good crossover with information architecture), and of course facilitation skills are important for keeping the meeting on topic, with participation from all attendees.

Gather the Right Stakeholders The main purpose of interviewing stakeholders is to gain an understanding of relevant project-related ideas, needs, knowledge, and frustrations from various points of view, which can then feed into the project requirements. There’s also the sometimes-unstated beneﬁt of involving many different groups so that each one feels like it’s had its say in the project—and as a result will buy into the ﬁnal solution. Although involving people to get their buy-in may seem more political than practical, it’s often a key step that puts you in touch with a network that will support you throughout the project. It may also help you avoid eleventh-hour changes, which can occur when someone you didn’t talk to raises an issue late in the process. So involving a large variety of people is frequently a good idea. On the other hand, schedules and budgets must be kept in mind. Involving a large number of people takes time, from their standpoint and from yours, for the meetings alone—not to mention the time sorting through notes to identify trends and consolidate redundancies. For efficiency and your own sanity, it makes sense to prioritize the groups to talk to and to choose key people from those groups to serve as thought leaders for their team. Who are possible stakeholders you could involve? These groups are often good sources for ideas: Groups with initiatives that depend on the site (for example, those with

marketing campaigns that need to have information presented on the site)

CHAPTER 5: BUSINESS REQUIREMENTS

Groups that need to support the processes directly behind the site or

application, such as providing content, entering and managing data, and responding immediately to information gathered The front line of customer service, such as phone or online support or

anyone who deals with customers face-to-face (for example, at a retail location or via deliveries) Sales, product management, or consulting services, to represent the

products and services being presented Human resources, for meeting recruiting objectives Public relations, for presenting information to investors and the media Any groups responsible for other relationships that need to be developed

as part of the project and that will inﬂuence its design, such as relationships with partners or vendors When choosing the individuals who should be included, get help from your project sponsor and any project team members who are familiar with the groups involved to pick the right people. Create groups that will get a good discussion going. There’s no one right way to do this, but one common way is to group stakeholders by department, like this: Marketing (ﬁve people) Product management (four people) Customer support (two people) Sales (four people)

A smaller project might include one person from each of these groups, in a series of two or more collaborative work sessions where everyone meets together. Once you have your stakeholders in mind, as well as a general structure for the meetings (discussed in the next section), you can start scheduling the meetings. Try to start scheduling at least a couple of weeks beforehand; it can be hard to get everyone in a room together.

GATHER IDEAS FROM STAKEHOLDERS

Create a Plan for the Meetings In parallel with your effort to choose the right stakeholders, pull together a list of topics to cover and questions that need to be asked (this will also help you reﬁne your list of stakeholders). You should have a different plan for each group you meet with, although several of your questions may be the same from group to group. You’ll also need to decide on the level of detail you’re aiming for in the meetings. If you’re meeting with a large number of people only once (for example, members of various departments, as suggested above), you’ll want to gather ideas, but you probably don’t want to spend too much time diving into the gritty details during the meeting. In that case, if one of your stakeholders gives you the idea “Customers can track their orders online,” you may want to simply ask why this function is important and if the stakeholder can think offhand of a site that does this well. These questions should help bring up the major differences among stakeholder expectations of the feature without spending the whole meeting on one statement. You can then work out the speciﬁc details of the idea with the project team, circling back with the stakeholder to make sure the requirements that you generated still represent his or her original idea. Let’s say you’re redesigning an e-commerce site and you’re meeting with a large variety of stakeholders, holding one meeting with each group. Here’s an example of a plan for meeting with a group from a sales department.

Sales: Requirements-Gathering Meeting Participants Inside Sales: Jenny Bee, Tracy Kim, Joseph Arnold Lead Management: Kevin Abernathy, Cat Parnell Time frame: 2 hours Objective: Understand the current sales process and identify issues and opportunities for how the Web could better support that process. Background: We have reviewed a PowerPoint presentation on the purchasing process, which provided a good background on how purchasing decisions are made. We also plan to talk to the Customer Service team.

CHAPTER 5: BUSINESS REQUIREMENTS

Sales: Requirements-Gathering Meeting continued Questions Sales process: How is the sales process different for different product lines? Are there regional differences? Are some differences based on customer size (e.g., small companies versus large companies)? How has this process evolved over the last two years and how is it anticipated to evolve over the next three to ﬁve years? How does a potential customer understand all the things that need to be purchased and how they work together?

Overall impression: Who do you believe are the primary visitors to the current site? Why? What are they like? What are they trying to accomplish on the site? How does the Web contribute to the sales process and/or the sales closure rate today? What information do customers need to make a purchasing decision? Is that information available on the site today? Is it easy to ﬁnd? Is it accurate? How hard is it to maintain content on the site today? What metrics do you get from the site? What additional metrics would you ﬁnd valuable? Why?

Envisioning the future: As you think about a future Web site, what could we do to better support the sales process? What current functions and features on the site are critical for sales? What is not necessary? What is missing?

Summary: Are there any other thoughts, suggestions, or concerns that we haven’t addressed? What Web sites do you think do an excellent job of supporting sales? What is the number one thing the company could do to improve customer satisfaction?

GATHER IDEAS FROM STAKEHOLDERS

Run the Meetings Effectively Here are some practices that will help you with requirements-gathering meetings. Ensure a Shared Vocabulary Is Used A lot of confusion can be avoided if the team gathering requirements agrees on a common list of terms and deﬁnitions. For example, are the people using the system going to be called users, customers, or clients? Are people more familiar with the term interaction designer or information architect? To avoid confusion, take some time at the beginning of each meeting to state which term is being used and what it means. You may also beneﬁt from creating some visual elements that help explain relationships between different terms or roles (see Figure 5.3). Category

Category

Subcategory

Topic

Article

Figure 5.3 Diagram showing project terms and relationships

A common vocabulary for the deliverables that will be used in the project will also help stakeholders understand the process and the type of output they can expect to see. This can build trust that their time and effort isn’t going to go into a black hole of ideas. Generally, if you ﬁnd yourself deﬁning the same words more than once or twice (especially if you ﬁnd the deﬁnitions are changing subtly each time), consider putting them into a project glossary and sharing it with the project team. Other examples of terminology that is good to clear up at the beginning of the project include

CHAPTER 5: BUSINESS REQUIREMENTS

Roles that will be interacting (for example, job seeker versus client or con-

tent producer versus editor) Primary deliverables that will be widely referenced (functional speciﬁca-

tion, wireframes, site map) and a brief description of how they differ Distinctions between different levels of information (such as our category

information in Figure 5.3) Distinctions between needs and ideas

Listen to Ideas and Dig Down to Needs Stakeholders may make statements that appear to be needs. Consider an example. Business Advocate

“We need a blog on the site.”

This is really an idea, not a need. If blog functionality is then fully designed and implemented, it becomes a solution, but it is not necessarily the solution that best meets the core need of the stakeholders requesting it. By asking why a blog is important, you may get a wide range of need statements, such as “We need to appear relevant and in touch. Everyone is talking about blogs, and I feel like we’ll be behind the times if we don’t include them.” “We need a way to get people to come to the site repeatedly to generate more ad revenue, and blogs mean freshly posted content with a following.” “We need to position ourselves as thought leaders, and blogs are a more personal way to show our expertise.” “We need to have a better way to communicate and innovate with our customers, and blogs get us comments so we can hear their thoughts.” Each of these statements describes valid needs. By bringing them out, you’ll learn about the drivers behind requests for particular feature, which will help you build consensus as you consolidate and prioritize requirements.

GATHER IDEAS FROM STAKEHOLDERS

Coalescing Requirements When the meetings are over, take the ideas you’ve gathered and sort them into general areas of functionality. You’ll start noticing a lot of overlaps; this is a good sign that a particular idea has a lot of buy-in from your stakeholders. Remove redundancies and try to consolidate a list of ideas that efficiently captures the intent of your stakeholders. To turn the ideas you’ve gathered into useful and trackable components of your project, you’ll need to coalesce these ideas into requirements. Think of raindrops forming from a cloud: You’re moving from one large and undeﬁned cloud to a larger number of well-deﬁned raindrops. So when you get an idea cloud such as “Customers can track their orders online,” you’ll need to convert it into distinct statements deﬁning what the system needs to do. The resulting requirements should Provide insight into the overall need that must be addressed Represent and consolidate needs provided by different stakeholders Give direction for design, without being too speciﬁc about how it will be

accomplished Serve as a distinct unit of work for purposes of prioritization and tracking

As you start moving from ideas to requirements, make sure your technical lead (or another person who can represent the development team on your project) is involved to ask the questions that will help estimate the effort required when you’re prioritizing later. If you have a dedicated quality assurance team member, that person can also provide some great detailed questions to help coalesce requirements. To detail the tracking idea into requirements, ask questions such as How accurate does the tracking have to be? What kind of information should be included in the tracking details; for

example, do we have to provide an updated estimate for delivery time? These kinds of questions can be asked and detailed with the stakeholders who gave you the original idea, if they have a large amount of time dedicated to the project. If you don’t have that much access to those stakeholders, you can work out the details yourself by having project team discussions

CHAPTER 5: BUSINESS REQUIREMENTS

and then reviewing the requirements with your project sponsor to ensure that your choices make sense for the business. Table 5.1 lists the kinds of requirements that might coalesce from the tracking idea and how you could capture them. TABLE 5.1

An Example of Business Requirements

AREA

Order Tracking

REQUIREMENT

BUSINESS NEED

Orders can be tracked by

Encourage self-service

entering a tracking code

during delivery (Support

online

beneﬁt)

Users can track their pack-

Show innovation in effi-

age by GPS, following trucks

cient delivery (Competitive

or airplanes

beneﬁt)

Users can view all past orders Encourage reordering and made in the last 365 days

self-service (Sales, Support beneﬁt)

Notice that in some cases the requirements overlap with each other, as in the case of the ﬁrst two requirements in the table—both are methods of tracking. They can live together in the same system because you can enter a code to ﬁnd your package through the GPS view. They’re separated, however, because the GPS-related requirement is probably a larger effort and should be prioritized independently of the other features. As you consolidate the statements, note the business requirements that you think could come in conﬂict with user needs. For example, a business requirement could be to gather personal information from prospective customers, such as their e-mail addresses. But customers may have reservations about providing information. After all, it takes time to ﬁll in forms, security and privacy is a concern, and this step may be interrupting the larger task they’re trying to accomplish. As you identify conﬂicts like these, they’ll start to give you ideas that could help you meet both business and user needs. For the tracking example, you may suggest using a “Send to a Friend” feature to capture the e-mail address and provide a convenience to the user. This means Send to a Friend may become a requirement you put in the mix for prioritization. Ideas like this

GATHER IDEAS FROM STAKEHOLDERS

one can help meet both business and user requirements, so they’re great to capture. They also live in that overlapping area between the Deﬁne and Design phases (see Chapter 4), because you’re starting to think of design solutions to business problems.

Deﬁne Design Develop Potential conﬂicts between business and user needs are excellent things to explore during user research, which we’ll discuss in the next chapter. User research will also allow you to extend Table 5.1 into a full set of potential requirements, which will be prioritized into a list of project requirements (shown in Figure 5.1, and discussed further in Chapter 9). Remember, the gathering of business requirements usually occurs in parallel with the exploration of technical possibilities and the gathering of user requirements. Next up: time to talk about users!

CHAPTER 5: BUSINESS REQUIREMENTS

User Research Get to Know the Guests You’re 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 out their behavior on versions of a site. This chapter will focus on some of the methods that are most commonly used in the beginning stages of the project. These techniques will help you deﬁne the user groups that should be of highest priority during the project, put their needs and frustrations in context, and assess the performance of the current site (if one exists) using best practices in the ﬁeld of user experience design. Carolyn Chandler

Basic Steps of User Research 1. Deﬁne your primary user groups. This involves creating a framework that describes the main types of users you’re designing for—allowing you to focus your efforts in recruiting users for research. 2. Plan for user involvement. This includes choosing one or more techniques for involving user groups in research, based on the needs of your project. 3. Conduct the research. We’ll cover the basic techniques here, such as interviews and surveys, and provide tips on how to go about them. 4. Validate your user group deﬁnitions. Using what you learned from the research, you can solidify your user groups model. This model will then serve as a platform for the development of more detailed tools, such as personas (discussed in Chapter 7). 5. Generate user requirements. These are statements of the features and functions that the site may include. You’ll add these statements to your business requirements (discussed in Chapter 5) and prioritize them to become project requirements (discussed in Chapter 9). This chapter will cover the ﬁrst three steps, starting with the ﬁrst: deﬁning your user groups.

Deﬁne Your User Groups Planning for user research at the beginning of a project can feel like a chickenor-egg dilemma (which comes ﬁrst?). How do you make sure you’re talking to the right people, if you don’t know yet who those people need to be? One way to get started is to create an initial or provisional deﬁnition of the users you’ll be designing for. This describes your site’s primary user groups, which can help you focus your research efforts for the right roles, demographics, or other variables that may have an impact on how users will experience your site. User group deﬁnitions can be high level (a list deﬁning each of your target user groups) or detailed and visual (a diagram showing multiple types of users, as well as how they interact with each other).

CHAPTER 6: USER RESEARCH

A high-level deﬁnition for a company’s primary .com site might include the following user groups: potential purchasers, current purchasers, partners, and job seekers As you begin deﬁning groups for user research, you’ll start prioritizing user groups in more detail. Your initial deﬁnitions are based on the collective knowledge of business stakeholders and project team members regarding the potential types of users who may be interacting with the site. Those deﬁnitions can be built by collecting some of the goals and attributes that different user groups may have. Here are the basic steps for deﬁning your user groups: 1. Create a list of attributes that will help you deﬁne the different users of your site (the next section will cover some of the most common). 2. Discuss the attributes with those at the company who have contact with relevant types of users (for example, customers). 3. Prioritize the attributes that seem to have the largest impact on why and how a potential user would use your site or application. 4. Deﬁne the user groups that you will focus on in research and design. The next 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 the different user types that will help you focus your research efforts).

Create a List of Attributes A good start for your attribute list is to gather and absorb any research or other documentation the organization has that could provide direction with regard to users. Here are some potential sources: Documents explaining company strategies, such as company goals, com-

petitive information, marketing strategies, and business plans Market segmentations of current customers and other demographic data

gathered by the marketing department Previously conducted user research (see Table 6.1 for some examples)

DEFINE YOUR USER GROUPS

Surveys, such as user satisfaction surveys and feedback forms Customer service reports covering frequently occurring issues

Next, identify people within the organization who have some insight into current or prospective users. The number and variety of people you should include depends on the type of project and its scope and timeline. If you know the initial deﬁnition of your user groups may have a short lifespan (for example, it’s in use for only a month or two while user research is being planned), you may include just two or three participants. If you think the initial deﬁnition may need to hold you through a good portion of the design process (for example, if you only have this one to work with until you conduct usability testing, after some design has been done), include more participants and ensure you have a cross section of perspectives. Some possible participants include marketing staff who are responsible for brand representation, segmentation, and campaigns; sales staff; product managers; customer service or support representatives; and trainers. It’s also good to include project team leadership and other business stakeholders in this exercise. Ask the group to think of the different types of potential users they tend to interact with. Then ask them to list some of the common attributes they’ve encountered. Here are some examples of what could vary: Primary goals, as they relate to the subject matter of your site. Why are

users coming to it and what are they trying to accomplish? For example, purchasing an item, trading a stock, or getting a speciﬁc question answered are common goals. Roles. This can be deﬁned in many ways, but one way is to tie roles to the

user’s primary goal: job seeker, support seeker, potential client, and so on. Once you have more user information, roles can be subdivided by different needs or styles; for example, on an e-commerce site shoppers could include bargain-hunters and connoisseurs. Demographics, including age, sex, family (single, married, children),

income level, and region. Experience including level of education, level of familiarity with relevant

technologies (often referred to as technical savvy), level of subject matter expertise, and frequency of usage (one-off, occasional, frequent). 88

CHAPTER 6: USER RESEARCH

Organizational attributes, including the size of the company users work

for, their department, type of job (entry level, freelancer, middle management, executive), tenure (long-term or high turnover?), and work patterns (remote work, amount of travel). Once you have a list of some of the attributes that come up most often when stakeholders are describing potential users, you can start to prioritize them by their level of importance and then use that hierarchy to begin deﬁning and modeling user groups.

Prioritize and Deﬁne Which of the attributes listed above do you think have the greatest inﬂuence on how and why different user groups might use the site? Focus on the ones that you think will have the greatest impact on a user’s goals or behavior. Prioritize those attributes, and remember the objectives you created in Chapter 4—they will help drive your choices as well. An example best illustrates how to prioritize attributes. Say you’re working with a company that provides tools for online trading of stocks, options, and futures. This particular company has determined that part of its strategy will be to engage nonprofessionals who are trading stocks on their own, online, and to encourage them to try trading new types of products such as options and futures. The company plans to do this by providing trading tools that are easy to use and targeted to those who want hands-on learning in a safe environment. In discussing attributes with business stakeholders, you may ﬁnd that the following ones seem to have the biggest impact on how individuals might use these tools: Current frequency of trading, speciﬁcally, frequency of direct online trad-

ing (for example, once a quarter, once a day, several times a day). Those who just dabble in trading (say, once a month) may not be serious about trying something new, while those who are already trading full time may not ﬁnd much value in tools targeted to newer traders. But those who are active part-time traders could have a strong interest in the company’s tools. Number of product types traded: just stocks or stocks, options, and

futures. Those who are already trading all types of products may already have a preference for their own tools, but those who only trade one type may be ready to branch out to others. DEFINE YOUR USER GROUPS

Level of subject-matter expertise (for example, familiarity with trading

terms). This will help determine how much help they’ll need along the way, with tutorials and glossaries. Level of technical savvy (for example, familiarity with making purchases

online and online banking and trading). This will inﬂuence how much reassurance they’ll need about information privacy and how advanced or simple the online interface needs to be. You can prioritize these attributes because they may affect the user types you’ll be targeting for research. If where traders live doesn’t seem to have a real impact on how or why they trade, the Region attribute can drop off the list as a consideration for research participants. On the other hand, if the importance of a particular attribute sparks a lot of discussion it may be a good subject for a survey question or interview question (we’ll be discussing surveys later in this chapter).

High

Comparing two or more attributes can help you prioritize as well. For example, if you make a chart using two attributes for online traders, you can start to see how groups fall within some of the ranges. Figure 6.1 is an example of a rough user model you could make using the two attributes of Frequency of Direct Trading and Number of Product Types Traded; it also shows the resulting user groups that might form out of the discussion.

Full-Time Product Specialists

Full-Time Savvy Generalists

Frequency of Direct Trading

“Second-Job” Traders

Supplemental Income Traders

Active Explorers

Long-Term Investors

Low

Dabblers

Low

High

Number of Product Types Traded (Stocks, Options, Futures)

CHAPTER 6: USER RESEARCH

Figure 6.1 A chart of two attributes, representing a rough user model. Creating this model collaboratively can facilitate discussion about potential differences in user motivations and experience.

This user model provides a high-level way to discuss different user types. It’s not meant to be the ﬁnal model, and it doesn’t label user groups exclusively (a user could be a long-term investor in stocks and also be actively exploring other possibilities in options or futures). But it does begin to express your understanding of different user groups and how they may be motivated to use your site. This discussion concerning important attributes also helps you discover which ones that you’ll want to focus on when recruiting users for research. If you determine that Frequency of Trading is important, and that the priority will be to engage those who currently have a medium level of frequency, you’ll want to deﬁne what medium frequency means (one to three times a week, for example) and recruit your research participants accordingly. Speaking of research, let’s talk about techniques you can use to involve users in your project.

Can You Design from User Models Alone? There’s debate within the user experience ﬁeld about creating user models before research is conducted, because doing so can color your thinking before you have real user data, and because your project team or project sponsor may see the model as a replacement for user research. Using an unvalidated model does introduce more risk that your assumptions will be incorrect. In projects where you’ll have no contact with users at all, however, a well-thought-out model (veriﬁed with sources outside the project team, such as a customer service group or training group) is better than having no model to use during design.

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 activities to conduct during the project. Table 6.1 presents some information on the most commonly used research techniques and when they are often most useful. Use this table as a reference to help you choose which ones best apply to your project. The next section describes each technique in more detail.

CHOOSING RESEARCH TECHNIQUES

TABLE 6.1

Common User-Research Techniques

ACTIVITY

WHAT IT IS

WHEN IT’S USEFUL

CHALLENGES

TYPICAL TIME FRAME *

User Interviews

A one-on-one conversation with a participant who belongs to one of the site’s primary user groups.

There is access to users but type of access (in person, by phone, etc.) varies.

Getting straightforward opinions. It can be hard to gather information about attitudes and context, 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 compile results.

Contextual Inquiry

An on-site visit with participants to observe and learn about how they work in their normal, everyday environment.

The project team Gaining access to has little information participants. Going on target users. to users’ environment may raise Users work in a unique environment concerns about security, intellectual (e.g., a hospital). property, and intruUsers are working siveness. For busiwith fairly complex ness applications, it tasks or workﬂows. can be easier to visit on a workday.

3–4 weeks for 12 inquiries: 1 week to plan, 1–2 weeks to observe, 1 week to analyze and report results.

Surveys

A series of questions consisting of mainly closed-end answers (multiple choice) used to identify patterns among a large number of people.

You want to state results in more quantitative terms (e.g., “80% of the target user group said they never purchase cars online”).

3–4 weeks for a short-run survey: 1 week to plan and write the survey, 1–2 weeks to run the survey, 1 week to analyze and report results.

You want to gain context but can’t go to the user.

You’re more interested in gathering information about preference than actual performance.

CHAPTER 6: USER RESEARCH

Getting an appropriate sample. Making sure questions are wellwritten so that you get accurate answers without leading respondents to a particular answer.

TABLE 6.1

Common User-Research Techniques (continued)

ACTIVITY

WHAT IT IS

WHEN IT’S USEFUL

CHALLENGES

TYPICAL TIME FRAME *

Focus Groups

A group discussion where a moderator leads participants through questions on a speciﬁc topic. Focuses on uncovering participants’ feelings, attitudes, and ideas about the topic.

The team believes that users’ attitudes will strongly inﬂuence their use of the solution (e.g., if there have been problems with it historically).

Understanding how to target your questions to get the right information out.

3–4 weeks: 1 week to plan and write questions, 1–2 weeks to conduct focus groups, 1–2 weeks to analyze and report results.

Card Sorting

Participants are given items (such as topics) 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 items and want an effective structure for your user groups.

Determining which topics would be best to include.

3–4 weeks: 1 week to plan and prepare, 1 week to conduct research, 1–2 weeks to analyze and report results.

Usability Testing

Users try to perform typical tasks on a site or application while a facilitator observes and, in some cases, asks questions to understand users’ behavior.

An existing solution is being improved.

Choosing the appropriate tasks to focus on.

3–4 weeks for 10 users and medium formality: 1 week to plan and write the tasks, 1 week to run the tests, 1–2 weeks to analyze and report results.

Competitive solutions are available to test. You have a prototype that lets users complete (or simulate) tasks.

Facilitating the group effectively.

Determining how formal to make the test.

* Typical Time Frame represents the time often needed from the point users are scheduled. Two groups of six to eight users are assumed (except for surveys, where the number of users should be larger). This does not include time for recruiting, which can take one to two weeks after creation of the screening questionnaire.

How Many Research Activities Can I Include? Before you choose among the activities, ask yourself how much money and time the team can dedicate to user research. Consider the following situations to understand how much appetite your client company has for user research. If project leadership and the project sponsors are comfortable with user research and are interested in using it for known goals, such as ensuring the site meets speciﬁc project objectives, then you’re likely to have more leeway CHOOSING RESEARCH TECHNIQUES

in planning for two or more activities, or for one activity that you conduct multiple times (for example, testing a design, changing it based on your results, and retesting the new design). If no one at the organization is familiar with user research and there’s some resistance to it altogether, you may be better off proposing one round of research and picking the technique that you think will bring the most value to you, the project team, and the business stakeholders. Once you have the results of the research, the project team will have a better idea of what’s involved and how the project can beneﬁt. You’ll then have a strong case for including more research later, if needed. If you have room for at least two rounds of research, a good approach is to include one round during the Deﬁne phase, or early in the Design phase, to better understand the users. Then include one more round before development starts, to validate the design. For example, for a task-based application you might conduct user interviews before designing and then perform usability testing on a prototype later in the process. Or for a content source you might start with contextual inquiry and then include a card sorting exercise.

Considerations When Planning Research When planning for any research techniques, consider the following: Why you’re conducting the research: what you want to learn from it Who you’re including: the primary user groups you outlined above How you’ll get participants: recruiting people to participate and screening them (that is, asking questions to make sure they fall into the user groups you’re targeting) How you’ll compensate participants What space and equipment you’ll need What you’re covering: the primary topics How you’re capturing information: the number of people involved and the tools they’re using Chapter 13 will cover each of these considerations as part of a detailed look at one of the most common techniques used by UX designers: usability testing.

CHAPTER 6: USER RESEARCH

Note See Chapter 2 for more on task-based applications and content sources.

Surﬁng Steve Baty wrote an article describing different methods and how to choose among them based on the phase of development, your information needs, and the ﬂexibility you have to incorporate user research. It’s titled “Bite-Sized UX Research,” by Steve Baty, UXmatters: http://uxmatters.com/MT/ archives/000287.php.

Let’s take a closer look at each of these techniques and the ways they’re commonly used.

User Interviews User interviews are structured conversations with current or potential users of your site. These can be conducted 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. (This last situation is also great for conducting a contextual inquiry, covered below.) Interviews help you understand participant preferences and attitudes, but they should not be used to make formal statements about actual performance. If you’re looking for speciﬁc information on how people interact with a site, it’s better to observe them using it (for example, in a contextual inquiry) or ask them to perform tasks on the site (during usability testing). Site analytics can also give you some insights into some performance information that can be particularly strong when paired with interviews or inquiries that provide context for the data. The Basic Process For user interviews, the UX designer creates a list of questions aimed at eliciting information such as the following: Relevant experience with the site or with the subject matter

CHOOSING RESEARCH TECHNIQUES

The company’s brand, as experienced by the participant Attitudes, for example, toward the subject categories covered (for a con-

tent source), the process being designed (for a task-based application), or methods of marketing (for a marketing campaign) Common goals or needs that drive users to your site or that of a

competitor Common next steps users take after visiting the company’s site Other people who are involved in the experience. For example, does a

user tend to collaborate with someone else as part of the larger goal they’re trying to achieve? Are they likely to share information or ask opinions of others along the way? Any other information that will help you validate the assumptions you’ve

made about user groups up to this point—for example, whether the variables you discussed when creating a provisional user model really seem to inﬂuence the way users are experiencing your site If more than one person is conducting interviews, it’s a good idea to have a set list of questions and a scripted introduction that can be used to maintain consistency across interviews. Choose ahead of time how structured you want the interviews to be. If you’re going for a formal report, you’ll probably want a high degree of structure, where question order doesn’t vary much and every question is asked, with few additions. If richness of data is more important than consistency, you may decide to opt for semistructured interviews, where you start with a list of questions but allow the conversation to follow a natural path, with the interviewer asking questions to further explore interesting comments (called probing). The length of your interview can vary; 45 to 60 minutes is often the best range to shoot for. It gives you enough time to build a rapport and cover a wide range of questions without fatiguing your participant. User interviews provide a rich set of data that you can use to write personas, which are covered in Chapter 7.

CHAPTER 6: USER RESEARCH

Interviewing Tips The quality of the information you get out of an interview has a lot to do with the quality of the questions you ask. Focus on participants’ personal experiences. Don’t ask them to speculate on what they may do in the future or on what others may do. This kind of information rarely predicts what they actually will do. Don’t ask questions that imply a speciﬁc answer or lead a participant in a positive or negative direction. Ideally, questions are simple, neutral, and open ended. Some examples of leading questions are What do you like about PseudoCorporation.com?

This assumes the user likes using the site. Use this question only if you also ask what they dislike about it. Does PseudoCorporation.com meet your expectations?

This can be answered with a simple yes or no, which doesn’t give you much detail to help with your design efforts. Would you rather use PseudoCorporation.com or CompetitorVille.com

and, if the latter, why do you think they are better than Pseudo? This has a couple of problems: It’s asking two questions in one statement, and it forces an implied opinion on the participant. Better questions to ask are these: Tell me about your last visit to PseudoCorporation.com. Why did you go there? What do you remember about your visit?

If you’re doing a large-scale, more formal set of interviews, you may want to include some multiple-choice questions. For the most part though, these don’t give you very rich information. They can be hard for participants to follow when asked verbally, and they don’t allow users to elaborate. In general, save that type of question for screeners or for surveys. Perform a test run with someone, perhaps someone within the organization who isn’t a member of the core team. This will help you discover questions that may not be clear and will also help you reﬁne the timing and ﬂow. If it’s possible, and the participant consents to it, record the interview so that others can beneﬁt from hearing answers straight from the participant’s mouth.

CHOOSING RESEARCH TECHNIQUES

Contextual Inquiry Contextual inquiry combines user observation with interviewing techniques. The UX designer goes to participants, ideally to the environments in which they’re likely to use the site. For example, for an office application contextual inquiry would involve sitting at the participant’s desk. This method gives you rich information about the context a participant works within, including The real-life problems users are facing The kind of equipment they’re working with The space they’re working within—in particular, the amount of space they

have, how much (or little) privacy, how often they are interrupted, and how they use the phone and paper (pay special attention to printouts they’ve posted or notes they keep handy). Their preference in using a mouse versus keyboard. This can greatly affect

your design choices, especially if you’re designing a tool that requires a lot of data entry. How they’re working with others, in terms of both collaboration and shar-

ing resources. If more than one person is using the same computer, for example, it will affect how you design login and security features. Other tools they’re using, both online and off. How people use paper is

especially interesting—for some tasks, it can be hard to design an online solution that competes with paper! Inquiries combine observation time and interviewing time. They can last anywhere from a few hours to several days. If participants can’t dedicate at least 2 hours, you should consider just performing an interview. During an observation, it takes some time for the participant to adjust to your presence and act somewhat naturally, and this doesn’t happen after just 15 minutes. The Basic Process Prepare a 10- to 15-minute introduction you can use with each participant. It should include the purpose of the inquiry, a high-level description of what you’ll be doing together (the observation and interview), and how the 98

CHAPTER 6: USER RESEARCH

information will be used. This is also a good time to get signatures on consent forms and to assure participants that what they share will be kept conﬁdential. Begin with some high-level questions about the participant’s typical processes, especially ones that are relevant to the design of the site. Let the participant know when you’re ready to stop talking and start observing. Observation can range from active to passive. With active observing, a common approach is to have the participant take the role of the master while you take on the role of the apprentice. The master explains what he is doing as if teaching you his process. Active observing often gives you more background on the reasons for the participant’s behavior, but it may affect how the participant works. In passive observing, you encourage the participant to act as if you’re not even there. Your goal is to observe behavior that is as natural as possible. For example, if a participant is talking to you, she may be less likely to take a call or go ask someone a question on a problem she’s trying to solve, but if you’re observing passively, you’re more likely to see this happen. You can then follow up during the interview portion to ask about the reasons behind some of the behaviors you observed. Either approach can work well. Generally, if you don’t have a lot of time with participants (let’s say, only 2 to 4 hours each) you may decide to use active observation to ensure you get the depth of information you need. If you have a full day or more, passive observation offers a good balance of natural behavior and discussion. Once you have information from your inquiries, you’ll have a lot of rich data to sort through! So how do you identify patterns or trends in your results? One way that’s helpful is a technique called affinity diagramming. There are many great resources available on this topic, but here’s a short description. A Quick Guide to Affinity Diagramming Affinity diagramming is the technique of taking a number of distinct and separate items (like statements made by users or observations made by a researcher) and grouping them together to form patterns and trends. Here are the steps involved in a simple affinity diagramming session: 1. Gather the team that performed the inquiries, with their notes.

CHOOSING RESEARCH TECHNIQUES

2. Give each person a pack of Post-it notes and ask them to write a statement on each one, along with a short code that will allow you to track that statement back to a participant, such as their initials. Focus on statements that seem to have relevance to the site design, either speciﬁcally (a feature statement) or in a more general way (a statement that represents as participant’s attitude to the company or subject matter). 3. Have everyone put their Post-its up on the wall. You’ll need a big blank wall if you’re working on large study; try to get one that you’ll have access to for at least a few days. 4. Once all the notes are up, start grouping similar statements next to each other. This portion of the exercise can include the larger team. It’s a great way to start sharing results. 5. Once groups start to form naturally, start labeling the groups to provide further structure. If some Post-its belong to more than one group, you can write duplicates and place them in each appropriate group. Note This method works well for contextual inquiry but can be applied to many other situations. For example, it’s a great way to collaboratively create categories for unsorted topics, so it can help you move card-sorting results into additional levels of structure.

Patterns can emerge in many ways, so it’s best to let them form on their own. However, here are examples of the kinds of categories that you might see, including the kind of statement you’d ﬁnd in them: Goals: “I try to clear off all the open items here before I leave for the day.” Mental models (includes statements that demonstrate how users are

mapping external experiences to internal thinking): “I use this online tool as my briefcase, for things I reference a lot but don’t want to carry around with me.” Ideas and feature requests: “I wish this would allow me to undo. I keep

moving the whole folder accidentally and it takes me forever to cancel out of it.” Frustrations: “I’d ask the help desk about this, but half the time they don’t

know what the problem is either.”

100

CHAPTER 6: USER RESEARCH

Workarounds: “This takes so long to do here that I just end up printing out

the list and working with it throughout the day. Then at the end of the day I enter in the results.” Value statements: “This tool here saves me a lot of time, so if you’re mak-

ing changes don’t take it away!”

Deep Diving The quintessential resource on contextual inquiry is Contextual Design, by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also includes detailed information on interpreting results through techniques such as affinity diagramming. For more information on mental models and how to understand them, take a look at Mental Models: Aligning Design Strategy with User Behavior, by Indi Young (Rosenfeld Media, 2008). This is especially helpful when you’re working on the information architecture for a content source.

Surveys Surveys involve a set collection of well-deﬁned questions distributed to a large audience. They most often consist of closed-ended questions (such as multiple choice questions) that can be easily collected with a tool that can display patterns among responses. Surveys are good tools when you want to be able to state results in more quantitative ways (for example, “Of those surveyed, 82 percent of those who work from home state they have some form of high-speed Internet connection”) than you would get with the kinds of open-ended questions that are used in interviews. However, you can gather qualitative information from them as well, about user habits and attitudes. In the user experience ﬁeld, surveys are often used to measure user satisfaction (with existing sites or applications) or to build or validate user models like segmentations or personas.

CHOOSING RESEARCH TECHNIQUES

101

The Basic Process As with user interviews, you don’t want to ask questions that require users to speculate. Don’t ask “If you got Feature X, would you use it?” Unlike with interviews, in surveys multiple choice or Yes/No, True/False questions are best and easiest to analyze afterwards. They’re also quicker for participants to answer. Use surveys when you have questions that are factual requests for demographic data, such as these: Of the devices listed below, which do you personally own? Choose all that apply. Computer Mobile phone Game system, such as Xbox, Playstation, or Wii

or for questions that are attitudinal with a set range of distinct choices: Read the following statements and select the degree to which you agree or disagree with each of them. The Customer Service at Pseudo Corporation is responsive to my needs. Strongly Agree Agree Neither Agree nor Disagree Disagree Strongly Disagree

In particular, questions like the second example are often used to supplement usability testing tasks. You can use this type as a follow-up question to ﬁnd out if participants were frustrated when completing a task. Participants don’t always like to state a negative opinion out loud, but they are often willing to express one when faced with a ranking system. This brings out another point: Surveys are an excellent supplement to other forms of research you may be doing, such as user interviews or contextual inquiry. Combining two research methods provides a richer picture of the user than one method can provide on its own.

102

CHAPTER 6: USER RESEARCH

Surﬁng If you want a high degree of conﬁdence in your results and have the budget for it, there are formal tools available for measuring user satisfaction with regard to ease of use. These tools include questions that have been tested to ensure they are not leading or confusing to a broad audience. Some of the most commonly used are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and MeasureMent Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi.ucc.ie

When planning a survey, consider the following: Who are you targeting?

Use your provisional model to determine this. It’ll make a difference in how you answer the rest of the questions here. What method for distributing the survey will give you the best results?

If your primary user groups tend to congregate in a particular location, you may get more results if you go there and set up a table for people to ﬁll out the survey on paper. If your user groups are active Internet users, having an online survey could be the best choice for a large number of participants. Or you may decide your user group will be best found with phone surveys using a list of current customers. How much time will participants probably be willing to spend ﬁlling out

the survey? If you’re providing some kind of compensation or they get some other beneﬁt from ﬁlling it out, you can usually create a longer questionnaire— one that takes maybe a half-hour to complete. If not, you’ll need to keep it short to help ensure people complete it—think 5 to 10 minutes. Either way, make sure participants are given an estimate of how long it will take and update them on their progress as they go through it (use page numbers like “2 of 4,” for example, or show the percentage completed).

CHOOSING RESEARCH TECHNIQUES

103

How will you know when to start analyzing the data?

You may choose to run the survey until you reach a certain number of participants or until you hit a certain deadline, whichever takes priority. What tool will you use to collect and analyze the data?

If you’re running the survey online, the tool you use to collect the data may have options for viewing and analyzing the results. If not, you’ll need a method to enter the data into your tool of choice. For paper-based surveys this means a lot of data entry, so be sure you’re planning for that time.

Focus Groups Focus groups involve bringing together a variety of people within a target audience and facilitating a discussion with them. Common goals are to elicit opinions 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: Hearing a variety of user stories. Open discussion is a great way to bring

out the storyteller in all of us. When a focus group is going well, individuals build off each other’s stories and ideas and remember situations they might not in a more structured one-on-one interview. The group format and energy can give people the time they need to recall these stories and share them. Understanding relevant differences in experiences. Most people are nat-

ural information sharers and want to compare favorite tools with others in their interest group. Often you can learn of competitive sites or services, or you’ll hear tips for workarounds, resources, and support. Generating ideas. Although you don’t want to make the group itself the

designer, you often get some excellent ideas for new features or designs either directly from the group or from hearing about their work processes or frustrations. As with stakeholder ideas, be sure to trace these back to the core need (see Chapter 4) so you can be sure it’s being addressed. Understanding multiple points of a collaborative process. If you’re

designing a process that involves multiple related roles and collaboration, groups can be a great way for you to ﬁll in the gaps in your understanding

104

CHAPTER 6: USER RESEARCH

of how people are interacting. For example, if you’re working with a content source like an intranet, it can be helpful to gather a mix of those generating the content, editing the content, and consuming the content to identify the points where the process could be improved. There’s a lot of debate about the use of focus groups in UX research. It’s not a good technique for testing usability (since users most often work individually, rather than in groups), and sometimes the group setting can unduly inﬂuence participants’ statements. If planned and facilitated well, however, focus groups can bring out many insights that will be valuable to you as you’re designing. Chapter 13 discusses this further in the context of concept testing. The Basic Process When writing questions for focus groups consider the same tips you would use for writing user interview questions (covered earlier). Begin with some of the easier questions, such as “Tell me about your last visit to PseudoCorporation.com. Why did you go there?” Save any questions focused on idea generation to the middle part of the group, when participants are feeling comfortable with you, each other, and the topic. Assign time blocks to each topic and keep to them; it’s easy for discussions to really get going and for time to slip by! If you’re worried about time, put your most important questions in the middle of the topics list, after people have warmed to the activity but before any potential time crunch that could occur near the end. Many of the logistics for focus groups will be the same as those for usability testing. (Chapter 13 offers suggestions on screening, recruiting, and scheduling.) The primary difference with focus groups is that you’ll need a larger room with a table allowing participants to interact with each other easily. Shoot for six to eight people per 1- to 2-hour group session. Give each person a nametag or a place card at their seat, so everyone can address each other by name. The format of the discussion itself should include an introduction, which often hits these key points: Your role as moderator, and what you’re expecting to get out of the dis-

cussion (for example, some of the points above).

CHOOSING RESEARCH TECHNIQUES

105

Why attendees were chosen to participate (for example, “You are all

current users of the Pseudo Corporation site, and we’ve brought you together to ﬁnd out about your experiences"). How this information will be used—both in the design and from the

standpoint of conﬁdentiality. That as the moderator, you’re there to hear about their opinions and

experiences. You want them to feel they can share honestly, so ask individuals to be straightforward but also respectful of others in the group. That there are many topics to cover, so at some point you will end a dis-

cussion on one topic to be sure you can cover all of them. This can then go into a round of introductions for group members, often including some kind of icebreaker question. Your goal is to get everyone to talk on the ﬁrst question, even if they just tell a short story. You can either start with one person and work around the table or let people answer naturally and then call on the people who haven’t answered yet by name. Often you’ll end up going around the table for the ﬁrst few questions and then, when you feel the group is ready, with body language you can open up the questions to everyone.

Snorkeling: Body Language A good understanding of body language can be an amazing tool when moderating focus groups or any user research conducted in person. It can help you understand when someone is feeling frustrated, excited, angry, or threatened, so you can identify when you should try to make someone more comfortable or probe on a particular comment. The following book on the subject may take more than a weekend to read completely, but it’s designed to be easy to ﬂip through: The Deﬁnitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).

When you call on someone who hasn’t answered yet, be sure to repeat the question in case they didn’t understand it or weren’t listening to the last

106

CHAPTER 6: USER RESEARCH

few statements in the discussion. Also, avoid making a difference in opinion seem like a disagreement between two individuals. Don’t say, “Bob, we haven’t heard from you yet. What do you think about what Chris just said?” but rather (looking at Bob), “How about you, Bob? What kinds of experiences have you had with Pseudo Corporation’s customer service?” As moderator, you control the ﬂow of the discussion and you pass the virtual microphone around. You keep control using eye contact, volume of speech, arm movements, and orientation of your body. Most people will be very aware of your body language, and these cues can be useful signals if someone is dominating the conversation. If an overly vocal participant doesn’t get those hints, use a gentle but ﬁrm statement such as “OK, great, I’d like to open that thought up to others. Has anyone else encountered some of the same issues that Theresa has?” When moving on to a new larger topic, give verbal notice that the previous discussion has ﬁnished and that a new one is beginning, so that people can clear their minds for the next topic. Finally, when the activity is nearing its end, a simple look at your watch and shift in your body orientation can signal that the conversation should be wrapped up. As with any other activity, be sure to thank the group for their time. Sharing results with your team typically takes one of two forms: ﬁndings are either shared according to the main topics being covered or are grouped into relevant categories much as they are for contextual inquiry. Affinity diagramming can be another effective way to bring together various trends and attitudes for illustration to the project team.

Card Sorting In a card sorting activity, participants (working either individually or in small groups) are given items printed on cards and are asked to put them into groups that make sense to them. Either they group them into categories that are provided beforehand (called a closed sort) or they make their own groups and title each group themselves (called an open sort). At the end of the round of card sorting you should begin to see common patterns emerge in how people are sorting the items, as well as common areas of confusion or disagreement.

CHOOSING RESEARCH TECHNIQUES

107

A common reason for doing this is to create a site map for a Web site or to create a hierarchy of content, categories, and subcategories containing items such as articles, documents, videos, or photos. This makes card sorting an excellent technique if you’re working on a content source. Note See Chapter 2 for more on content sources.

Say you’re working on a common type of content source: the company intranet. Many intranets tend to categorize their information by the department that owns it, with navigation to human resources, operations, legal, marketing, and so on. For longtime employees this may not present an obvious problem, because they have probably learned the lines of responsibility of each department and built an understanding of where to ﬁnd information. But for new employees, or for those who need information that they don’t usually reference, it can be difficult to locate information that could fall within more than one department (or doesn’t seem to fall into any). For example, where would you go to ﬁnd a policy on signing of contracts with newly hired employees? It could fall under legal, or it could fall under human resources. With card sorting, you can ﬁnd common patterns in how potential users would categorize information, regardless of departmental lines. The Basic Process Collect the items you’d like to include in the card sort; 40 to 60 is usually a good range. You need enough to allow for a potentially large number of card groups to be created, but not so many as to overwhelm the participants with options (or to overwhelm you when you need to analyze the results). Choose items that you think will be easy to understand and free from unnecessary jargon. You can include some subject-matter terms that you believe your user groups are likely to know, but avoid including too many “insider” terms. If you include too many company-speciﬁc terms or acronyms (such as “the SUCCEED campaign” for growing sales), you’ll be testing the effectiveness of the company’s marketing and communications, rather than building a common information hierarchy. For the intranet example, you might include the vacation policy, 401(k) plan information, new-hire contract, vendor contract, nondisclosure agreement,

108

CHAPTER 6: USER RESEARCH

new-employee orientation, health insurance information, and computer security policy. This list represents a mix of clearly worded items that could be categorized in multiple ways. You could have one participant who groups new employee orientation and vacation policy together under human resources, and you could have another who groups new employee orientation and new hire contract together and names it “employee onboarding.” Once you have your list of items, put them onto cards that can be easily grouped and ungrouped. You can print labels and stick them onto index cards or print directly onto sheets of card stock that are perforated to separate into individual cards. Perform a test run by asking someone to sort the cards into groups and give the groups names—for example, by putting a Post-it on the stack and writing the name on it with a pen. Ideally, your test participant is someone unfamiliar with the items and the activity. This will help you get a rough idea of how long the activity might take. If the test run takes over an hour, you may need to cut out some cards! Once you have a ﬁnalized deck, you can bring in a real participant and give these basic instructions: 1. Arrange these cards in whatever groups make sense to you. 2. Try to have at least two cards in a group. If a card seems to belong to no group, you can place it to the side. 3. At any time as you’re sorting, you can name a group. By the end of the activity, please name as many groups as you can. Some trends will become obvious simply by observing the sessions. Others may take a little more analysis to bring out. There are several tools for entering and analyzing the results of card sorts; many of them come with tools that allow you to run card sorts remotely (see the “Variations on the Card Sort” section below for more on this). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) provide both remote sorting capabilities and helpful analysis tools. Or, if you want to do your own sorting in a more manual fashion, take a look at Donna Spencer’s excellent spreadsheet, complete

CHOOSING RESEARCH TECHNIQUES

109

with instructions, available at www.rosenfeldmedia.com/books/cardsorting/ blog/card_sort_analysis_spreadsheet. Variations on the Card Sort The discussion so far has focused on a card sort carried out with an individual, in person, where the participant is asked to name the categories he created. This is an open sort, meaning that the main categories have not been given to the participant—instead they are open to being named. This is a good approach when you’re determining a new navigational structure or making signiﬁcant changes to an existing one. For other situations, you might consider these common card sorting variations: Closed sorts. In a closed sort, you provide the high-level categories

and participants add to them. The results are relatively easy to analyze, because you have a small set of possible categories and can focus on understanding which items fell most often into which categories. If you’re adding large amounts of content to an existing information architecture or you’re validating an existing site map, a closed sort can provide quick and actionable information to help with your categorization decisions. Group sorts. Rather than having an individual sort items into groups, you can

have card sorting be a part of a focus group activity, where participants work together to sort items. Although the results don’t necessarily reﬂect how any one individual would group the items, you can get a lot of insight into how people think about the items and their organization by hearing them work through the activity together, debating the rationale for each placement. Remote sorts. Sorting with physical cards can be a fun activity, especially

for group sorts. But there are many great tools for performing sorts online with individuals. This also allows you to reach a greater number of participants or particular participants that may be difficult to meet with physically. OptimalSort and WebSort, mentioned above, are two of the tools that make this type of online sorting easy.

Usability Testing Usability testing involves asking participants to perform speciﬁc tests on a site or application (or a prototype of it) to uncover potential usability issues and gather ideas to address them.

110

CHAPTER 6: USER RESEARCH

You can perform usability testing during the Deﬁne phase if you want to gather information on how the current site can be improved. Or you can perform it on similar sites (such as competitive sites) to understand some of the potential opportunities for a more user-friendly solution. Most often, usability testing is conducted as part of the Design phase, ideally in iterative rounds (where a design is created, tested, reﬁned, and tested again). We’ll discuss usability testing again in full detail in Chapter 13, “Design Testing with Users”; that chapter includes tips for recruiting and planning that can help you conduct the activities discussed earlier in this chapter as well.

After the Research Once you’ve completed one or more of these user research activities, it’s time to revisit the assumptions you originally made about your user groups. Put those assumptions away for a moment, and ask yourself what user groups you would create now that you have more information. If some of your earlier assumptions weren’t valid, consider any gaps you may have in your user research because a key group wasn’t included. If this gap is identiﬁed early enough in your research activity, you may have time to adjust and add another set of participants to research in progress, to ensure you’re getting a full picture. With your new knowledge, you can revise your user deﬁnitions to more accurately reﬂect the groups that should be the focus. This will help you create more detailed tools like personas (discussed in Chapter 7) and will help you create user requirements for the list we began in Chapter 5. In that chapter, we discussed the process of taking statements from business stakeholders and reﬁning them into requirements. You’ll follow a similar process with users—your work doesn’t stop when you capture the idea or request. Dig down to root needs and goals to make sure you understand them. This will ultimately help you design a solution that best meets that need for all relevant user groups. In the next chapter, you’ll learn how to use the insight you gain in conducting user research to create tools that can bring focus to your user groups throughout design and development: personas.

AFTER THE RESEARCH

111

Personas Find the Best Way to Put Your Team— or Your Client—in Your Users’ Shoes Personas are often a topic of debate among user experience practitioners. Opinions range from how much content is needed to how much research is needed to whether they provide any value to projects. Some people question whether or not they belong in the process at all. Regardless of where you position yourself, personas may be used to help your project team and your client empathize with their users. Personas can deliver a gut check to many parts of your project—business requirements, visual design, or quality assurance—by providing insight into who your audience is and what their expectations and behaviors are. Russ Unger

What Are Personas? Personas are documents that describe typical target users. They can be useful to your project team, stakeholders, and clients. With appropriate research and descriptions, personas can paint a very clear picture of who is using the site or application, and potentially even how they are using it. User experience designers often see creating personas as a great exercise in empathy. Well-crafted personas are often used as a touch point whenever a question or concern arises about how aspects of the project should be designed. You can take out your personas and ask, How would

perform ? or What is going to look for in ? Although this process may not be as accurate as testing functionality and design with actual users, it can help move your project along until you are able perform more extensive tests. Josh Seiden (www.joshuaseiden.com) points out that there are two distinct types of personas: Marketing-targeted personas that model purchase motivations Interactive personas that are modeled toward usage behaviors

This chapter focuses on interactive personas.

Why Would I Create Personas? In the user experience design process, personas help you focus on representative users. By providing insights into “real” behaviors of “real” users, personas can help resolve conﬂicts that arise when making design and development decisions, so you and your team can continue to make progress. How real do personas need to be? The answer varies widely. A single persona document may be enough for one team, while another may create full “living spaces” for the user personas to deeply understand how they “live.” You could even go to the extreme of creating individual online presences that can be interacted with to provide insights into online behaviors. However you choose to extend your personas is up to you. Personas can be constant reminders of your users. A useful technique is for your team members to keep personas in their workspaces; this way they are

WHY WOULD I CREATE PERSONAS?

113

continually reminded of who their users are. When you share a cube with “Nicolle,” the 34-year-old certiﬁed hand therapist from West Chicago, Illinois, for a while, you begin to ﬁnd yourself compelled to provide an experience that works well for her. If it helps you, feel free to keep printed copies with you while you sleep and let the osmosis fairy impart empathy from the pages through the pillow and into your slumbering subconscious. The purpose of personas is to help you, your team, and/or your clients remove some of the confusion that can crop up when you reach a decision-making crossroads.

Finding Information for Personas Effective personas must accurately depict a number of speciﬁc users of your product or Web site. To achieve that goal, personas must be supported by research. Chapter 6 presents techniques for researching and modeling your potential users to provide a ﬁrm foundation for your personas. Don’t look for one method to be the answer, however; it’s best to ﬁnd as much data as you can and mix it with a blend of observational and interview data—this can also include utilizing online surveys and analyzing behaviors in social networks. It’s a common theme to creating personas: Get real data, but make the personas into real people on the pages. To learn how one company accomplishes this, see the sidebar “Case Study: Messageﬁrst Personas.”

Creating Personas Once you identify your audience and accumulate data to support your personas, your next step is to put pencil to paper and start to bring them to life. How many personas you need to create varies. In general, the minimum is three, but upwards of seven is not uncommon. Rather than aim for a speciﬁc count, consider the number of target segments you have and what you feel is the best way to get a fair representation of them.

114

CHAPTER 7: PERSONAS

Case Study: Messageﬁrst Personas To create effective, data-driven personas, Messageﬁrst (www.messageﬁrst.com) uses no less than three different data input sources, drawing from the following: Stakeholders. We interview them to ﬁnd out who they think the personas are and what they think their behaviors are. This is always included. Customer advocate. We interview people in the company who speak directly with customers, which typically means Sales/Marketing and Customer Service. Each of these has their bias, which we make sure we keep in mind as we document our ﬁndings. For example, the people who most commonly contact Customer Service are those with too much time on their hands (often retired or unemployed), or someone who’s so upset about a product or service that they’ll actually take time to contact you. Customers. We talk directly to the actual people who are going to use or currently use the product or service. This is included whenever possible. Customer data sources. We review any available Weblog traffic, surveys, and e-mails that are available to us. Someone we know. We pick someone we know who ﬁts the initial proﬁle of the persona. This helps keep us grounded, ensuring the persona is believable and realistic, and provides a real person to contact should we have additional questions. This is very important for validation, and always included. Because each data input source we use has a particular bias, we use multiple sources to normalize the data. What's important for data-driven personas is not to go in with an expectation of how many personas you will have, but to let the data reveal how many personas there should be. When analyzing the data, I look for gaps in the behaviors and activities. These gaps reveal the individual personas. Todd Zaki Warfel, President, Messageﬁrst

This chapter’s example persona is Nicolle, a 34-year-old Certiﬁed Hand Therapist from West Chicago, Illinois. She happens to be a nondriving commuter who spends 2 to 3 hours per day traveling to and from her job. The ﬁctional client is a company called ACMEblue, a manufacturer of Bluetooth headsets for Apple’s not-so-ﬁctional iPhone.

CREATING PERSONAS

115

That brief bit paragraph tells you a lot about Nicolle, but as you can see in Figure 7.1, the actual persona contains a much more thorough story about Nicolle. Note that the content is written about Nicolle, not “by” Nicolle. It’s best to write your personas from the third-party perspective and not contend with writing in their distinct voices, especially when you’re just getting started. As you expand your experience, you should naturally explore and ﬁnd the style that ﬁts you best and provides the most value.

Figure 7.1 Persona for ﬁctional client ACMEblue

What kind of information goes into personas? The kind of information that your audience will ﬁnd relevant and believable, that’s what kind. Based on the research data you’ve gathered, you should be able to ascertain what is important to the client, brand, and project. The majority of the personas you create will share a common set of required content mixed with any amount of data, statistics, and other relevant information that can be considered optional, because it will vary from client to client, if not project to project.

116

CHAPTER 7: PERSONAS

Minimum Content Requirements When creating personas, you need to provide enough information to draw people in and make them relate to the person they are reading about on the page. To help your audience understand how your persona behaves and thinks, be sure to include six key pieces of information: photo, name, age, location, occupation, and biography. The next sections take a closer look at ﬁlling in the details for each item. Photo A photo is the ﬁrst (and the real) step to putting a face to your persona. When choosing a photo for your persona, try to make sure that the picture doesn’t look too posed or polished. Photos that appear to be posed do not have the same effect as those that are in more natural settings. Personas seem to be more effective with photos taken in more natural settings, such as the photo on the right in Figure 7.2, where the subject is standing outside in her winter coat, conceivably during her commute. Make sure the photo ﬁts the lifestyle of the persona! Posed

Natural Figure 7.2 Natural-looking photos are more effective.

There are a variety of online photo resources. Some of the better options are iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com), and Stock.XCHNG (www.sxc.hu).

CREATING PERSONAS

117

Finding the right photo can be a complete time suck if you’re not careful. If all else fails (or you have the time and budget), take your own! Name Simply put, you’ve got to put a name to the face. The photo you use will humanize the mix of research data and personality traits, and the name will be how everyone refers to your persona during discussions. Not only does Nicolle sound better than “Mid-30s Blonde Professional Mom,” but it’s a lot easier to remember and associate with a speciﬁc persona. Try to keep the names you use for different personas on a project from sounding too similar. Nicolle and Noelle could be easily confused, for example, so look for distinct names. And, although it may be tempting to use the names of coworkers or clients, don’t. When you use names that are like or the same as those of people involved in the project, it is easy for them to try to identify themselves in your personas. Choosing different names avoids any uncomfortable situations or hurt feelings. If you ﬁnd yourself having difficulty choosing names, some online resources can help you with this: baby-naming Web sites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Social Security Administration’s Popular Baby Names: www.ssa.gov/

OACT/babynames Random Name Generator: www.kleimo.com/random/name.cfm

One last thing about names: Make sure your name is believable for the persona. Nicolle works just ﬁne for a Midwestern mother, but Nicola or Natalia may be a much better name for an Italian mother. Also, names that appear to be a little more fun or lively, such as Bob the Builder, aren’t. They tend to make your personas look silly and can detract from their value. Age Although your research should identify the age range of your consumers, providing a speciﬁc age for your persona helps to add authenticity to the biography that you write. Behaviors of a 21-year-old college student and a 34-year-old professional mother are signiﬁcantly different!

118

CHAPTER 7: PERSONAS

Location At ﬁrst, location may not appear to be vital information; however, it is important to remember that cultural and behavioral shifts can occur from location to location. In Italy, for example, different dialects are spoken in different regions of the country. In the United States, a person who lives in Chicago would most likely have a different cost of living than a person in Savannah, Georgia. Occupation Knowing what your persona does for a living helps you to identify with them by relating to the patterns of their day-to-day lives. A persona who works in therapy meets with many people on a daily basis, whereas a drawbridge operator may not interact much with others. Biography The biography is the compelling story that makes the persona real. This is where you provide details that you derive from your research data and infuse it with a bit of “real people.” That is, the data is very important to the persona, but you do not want to simply quote that information in choppy sentences. Instead, you want to weave data, anecdote, and observation into a story that your audience can relate to. It may seem a bit strange, but the biography needs to be believable, and it’s certainly not cheating to bring aspects of a real person into your persona. Nicolle, for example, is based upon both statistical data and the very real behaviors of a person who shares similar activities, beliefs, and desires. Depending upon your project, you may need to delve fairly deeply into the biography—sometimes the more details you have, the better. Don’t feel as if you have to squeeze your persona onto a single sheet of paper. Go with what works best to make your persona true to life and as meaningful as possible to the project you are working on.

Optional Content As you work with personas, you will ﬁnd that different projects will require different sets of information to make the personas more applicable. The minimum content requirements might also be considered the least common

CREATING PERSONAS

119

denominators from most of the personas you will create. In most cases, you will blend some of these optional content elements with the core of your personas. Optional content that may add value to your personas includes Education level. Knowing how educated a person is can provide a bit

more insight into some of their habits. A person with a high school diploma may have substantially different purchasing habits and brand perceptions than a person with a master’s degree, and this information can inﬂuence how your persona is perceived. Salary or salary range. Money talks, and in many cases, the amount of

income a person has substantially affects their standard of living and their disposable income. This information can provide signiﬁcant insight when you are targeting certain levels of affluence. Personal quote. What would be the motto that your persona would claim

as their own? Sometimes this can give a quick overview into the core of your persona’s way of thinking. Online activities. This can get tricky; there are a lot of ways people spend

their time online. Some people pay their bills, some people are heavily into blogging and social networking activities, and some people simply use their computer as an appliance that gets turned on when they need to perform a task. Given that so many projects have some online component, this element is a bit of a judgment call. You’ll need to lean on your research to help paint the picture. Offline activities. Does your persona have a hobby? Is there additional

information about what the life of your persona is like when they’re not online? This element can be every bit as tricky as online activities, and can be every bit as important in inﬂuencing your persona. Key entry or trigger point to client, brand, or project. Often it is important

to understand how a persona interacts with the client, brand, or project. Does the persona hear about it via word of mouth, online reviews, a billboard, television or radio, or from an online pop-up ad? Is your persona looking to solve a problem that can be addressed through the client, brand, or project? Using your statistical data to understand this point, and writing it into your persona, can help ground your approach to engaging users.

120

CHAPTER 7: PERSONAS

Technical comfort level. Does your persona use a PC or a Mac? Does she

own a computer at all? Does she use instant messaging, Flickr, or write a blog? Is she very comfortable with that activity, or is she confused by it? Would she be helped by a very simple solution directed toward a novice? Does she have an MP3 player or other portable device? Does she use a DVR or AppleTV or on-demand programming to watch television? The list can go on and on. And on. Depending upon your client, brand, or project, these notions—and a variety of others—may be important to identify. Social comfort level. Given the growth of social media and social net-

working, it may be important to identify very speciﬁcally how your persona engages in that particular space. Does she have a Twitter account? If so, how many followers does she have? How active is she? Is she a leader? Does she use MySpace, Facebook, LinkedIn, or other aggregators or online communities? Mobile comfort level. As the usage of mobile devices becomes more

prevalent, it is important to consider including how your personas ﬁnd themselves in the mobile space—if at all. Motivations to use client, brand, or project. In some cases you may want

to include the reasons the persona would want to use the client, brand, or project. If she is continually getting the wire for her headphones tangled in her coat and yanking them off her head, that may be a good reason for her to consider new headphones. Real scenarios based upon research data can help uncover key motivators to include in your personas. User goals. You may also want to identify what the persona is hoping to

accomplish by using the client, brand, or project. This can help provide insights into the persona’s drivers for using it. These are just data points to get you started. You can structure your personas and present them in an inﬁnite variety of ways. If you are interested in taking a deep dive into the world of personas, a great place to start is 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).

CREATING PERSONAS

121

Advanced Personas Once you have an understanding of the basics of creating personas, there are inﬁnitely many ways you can extend your documents. A simple persona often can meet most of your needs, especially when your project team is just trying to get an empathetic understanding of your users. Things tend to get more interesting when you present personas to your clients. In those cases, you’ll often ﬁnd that you need to provide much more than the information that you put together for the basic persona. Figures 7.3 through 7.7 illustrate some of the ways you can extend personas. Feel free to borrow from these examples, remix and mash them up to create something even better for your project!

Brand Name

Meet the Brand Name Consumers

PERSONAS AND SCENARIOS (based on ethnographic studies) Personas are composite characters based on data about your target consumers: in this case, ethnography, existing segmentations, and customer database data.

Scenarios are hypothetical yet realistic narratives that describe why these personas might visit the Brand 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 user personas and scenarios that are grounded in real-world contexts. This design approach helps craft comprehensive experiences based on an understanding of customers, their motivations, desired outcomes and behavior. Scenarios speciﬁcally answer three fundamental questions that must be addressed before a site can be properly organized: Ŕ8IPBSFZPVSSFQSFTFOUBUJWFVTFST Ŕ8IBUBSFUIFVTFSōTTQFDJţDHPBMT Ŕ)PXDBOVTFSTBDIJFWFUIFJSHPBMTBOE have a fullﬁlling experience on your website

Pleasure Seeking Afficionados “I really enjoy this” “Young Sophisticate”

START

BEGIN TO EXPLORE

BUILD EXPERIENCE

“Aspiring Novice”

"$)*&7&-&7&- OF COMFORT

“Active Responder”

FEEL 5)&365

EXPLORE AGAIN

“Established Explorer”

STREAMLINE AND SIMPLIFY

“Grown-up in a Groove”

Practical Get-things-done “It just has to work”

Alice, 26

Rachel, 42

Erica, 47

Greta, 59

Figure 7.3 Persona overview master sheet (landscape orientation). Provides an aggregated view of several personas, along with the segments they represent, in the context of a high-level organizational strategy. Courtesy of Will Evans.

122

CHAPTER 7: PERSONAS

Brand Name

PERSONAS AND SCENARIOS (based on ethnographic studies) Alice is a novice cook aspiring to explore the world of food,

GOALS

especially kid-friendly food, with friends and by looking for new recipes online and in magazines. Her exploration is more about

feed her family without a lot of thought or effort

fantasy than reality, though. She’s still intimidated and does not

ﬁnd quick, easy recipes using basic ingredients

try too many new recipes. Her mom didn’t pass on too many cooking skills to her, and her friends aren’t very experienced

(frequently) make two types of meals: for adults, for child

cooks either. Alice is a busy mom of one daughter in Chicago. Both she and her husband work outside the home—she manages the office of a small insurance company.

Alice, 26 “Aspiring Novice” gen x married

1 daughter, 5 weary, aspirational

income

education

She is busy, practical, and does not spend much time cooking. Alice just wants to get it done fast and easy—though she often has to prepare different meals for herself and her husband since she started her workout regime after having Sophie two years ago and is trying to get back into marathon shape. She works from a small set of successful recipes she feels comfortable with, and a lot of the meals she prepares are based on packaged and prepared food.

SCENARIO Alice is watching Cartoon Network with Sophie during breakfast. A Brand commercial comes on showing a Name of Brand here. Alice uses brand, and thinks Sophie would go for that dish. She decides to check out the site from work. Alice visits the site during a free half hour before a meeting. The homepage is clear and organized. She sees the main site sections and links to interesting stuff like a recipe of the day.

internet use

health consciousness

cost sensativity

She clicks the recipe of the day. She likes the tips that come with it—they make her feel that she could tackle this recipe. She is pleased by the clear navigation, unlike other sites where she tends to get lost. She likes the useful features that go beyond what she sees in cookbooks, like the ability to ﬁnd 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”. Registering is so easy! She ﬁlls out some basic information and selects the “Food Your Kids Will Love” newsletter.

She would love to add more of her own touch, and recreate dishes she enjoys in restaurants, like her all-time favorite, jerk chicken. She’d also like to add more fresh vegetables to her meals, because she knows it’s healthier. She takes pride in the fact that she is a thorough planner and able to run her household on a tight budget. Her refrigerator and pantry are always stocked. She plans her shopping to take advantage of sales and coupons.

ﬁnd kid-friendly recipes and food activities ﬁnd ways to “dress up” her favorite convenience foods PROJECTS & INITIATIVES improved navigation and information architecture improved signup

A week later at lunchtime Alice ﬁnds her ﬁrst Brand e-newsletter: “Pizza, easy as 1, 2, 3.” Perfect—her kids love pizza, and she usually buys frozen pizzas for them. There’s a link to “Pizza for beginners” that inspires her to see if she can make pizza herself. The link takes her to a recipe for pepperoni pizza on something called the “Pizza Wizard”. She scans the recipe and sees it’s pretty 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 the “Pizza Wizard” suggests substituting them with things she does have in her well-stocked kitchen: sausage and tomato sauce. And perfect! There’s a link to a coupon. Neena prints the recipe’s grocery list, adds a couple of items she also needs and heads to the store. Back from the store, Alice gets started. She sees step-by-step instructions on how to unroll the dough and add the ingredients. There are images next to each step. It’s easy to understand and follow. She wonders whether she should cook the toppings ﬁrst, but the pizza FAQs answer that for her.

contextualized peripheral information more targeted newsletters recipe wizard better coupon integration MEAL PLANNING “get it done” attitude relies heavily on convenience foods, with relatively few added fresh fruits and vegetables spends more time browsing recipes than actually cooking them

Figure 7.4 Target audience persona (landscape orientation). This detailed view of a persona incorporates a broader spectrum of data and provides a more comprehensive perspective of users’ goals, needs, and behaviors—all set within a larger ecosystem. Courtesy of Will Evans.

Figure 7.5 Target overview and target audience persona (portrait orientation). The target overview at left provides high-level summary information and shows the brands the three personas interact with and relate to. The detailed description at right presents an overview and biography of a single persona, along with information about her behaviors and motivations.

ADVANCED PERSONAS

123

Paul and Helen “I guess we can put anything in there. I’m just not sure how much will ﬁt.”

5 4

Helen’s mother died a few weeks ago and they’re just now getting around to emptying the house. They plan on selling the house, but there’s quite a bit they’ll need to clean out ﬁrst. The house also needs some renovation work in the master bathroom.

- of de The basement is ﬁlled with stuff Helen’s mother collected over the past couple cades. She never threw anything away. She has newspapers and Time magazines from the past 20 years. There are a few things Helen wants to keep. Most of the clothing - “col and furniture will be donated to Goodwill. Unfortunately, most of her mother’s lectables” have been ruined from water and mildew. She also has paint cans, but Paul and Helen don’t know if the paint contains lead or not.

2 1

ain

Kn ow Ex led pe ge rie nc e C on Pric ve e Se nie tu nc p e sp Re e M pu e d ult ta ip le Tim tion C on elin e t M ain ss ajo er r L Siz ife es D E ec ve n lu tte t Ya r Re rd ing pe Wa st Re at e w Bu ar s ds ine Pr ss og r O Rec am nlin ycli n e ac g co un t

This is the ﬁrst time Paul and Helen have gone through something like this. They don’t even know where to begin. They just want this to be as easy as possible. They know they need a dumpster, but aren’t sure how much it will hold. And they assume just about anything can go in the dumpster, unless someone tells them otherwise. Their only other concern is that dumpsters tend to be unsightly. They’re hoping to ﬁnd a company who won’t make the front yard look like a construction zone or ruin the yard when they deliver or pick up the dumpster.

Age: 24-65

Lifecycle Jan

Jul

Dec

Month

1.0 Life Event

Key Characteristics Ŕ Ŕ

Single event like acquisition of a family estate or small remodeling job (e.g. bathroom). Little if any past experience with acquiring a dumpster.

Goals Ŕ Ŕ Ŕ Ŕ Ŕ

Get a dumpster quickly. Get rid of all the stuff they aren’t keeping or donating. Avoid destruction to the property during the process. Avoid an unsightly dumpster. Get rid of the dumpster quickly once it’s ﬁlled.

Frustrations & Pain Points Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Questions Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ Ŕ

Available when needed Price Vendor leaves the property how they found it Having the container size needed available Speed of setup and pickup once contacted On-line account access for scheduling and payment Quality and cleanliness of equipment Familiar brand

Ŕ Ŕ Ŕ Ŕ

Initial sticker shock Unfamiliar with the process Don’t know what they don’t know Making an apples to apples comparison between vendors

Is there anything that can’t go in? How quickly can they deliver and pick up? Will they leave the property in the condition it was originally? How does this work? Is there a permit required? How much will it cost? How easily can I get a hold of someone if I need to?

Figure 7.6 Target audience group persona. This persona presents an age-range target, drawn from research data. The information it contains is broad and speaks to audience grouping, not speciﬁc individuals. This approach can be useful when you are making a business pitch or when the client’s budget does permit detailed exploration of personas. Courtesy of Todd Zaki Warfel.

The Jill of All Trades

Amanda Stone

“I have to manage multiple programs for my clients.”

AMANDA SHARES THE INCENTIVE PROGRAM RESPONSIBILITIES WITH A FEW OTHER colleagues. They share access and manage multiple programs for clients. This can be particularly challenging to make sure she’s paying the right people on the right program. She needs to be able to switch between the different programs and know where she’s at at all times.

Lifecycle

Key Characteristics Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Manages multiple programs Medium to large company Moderate volume (50-2000+ orders at a time) Multiple people sharing a single role 70/30 Quick Pay and Admin Checks Weekly to bi-monthly usage Year round Very interested in reporting Wants to run reports across programs Heavy Excel use Custom internal system to interface with

Goals Ŕ Ŕ Ŕ Ŕ

Integration with current system. Ability to pay employees quickly and easily. Cost (mostly time). Guided help.

Other Applications Ŕ Excel Ŕ PowerPoint How do I run reports across all my programs? Ŕ Internet Explorer Is there a way to get my login info without having to call Ecount? Can we integrate with ClientZone some way so that we don’t have to go back and forth so much between differ ent applications. Am I doing it right?

Ac FT N c ew ou P n C ar t Zo d Re ne qu es t E Ad asy s m Pa in y C he c R Cu ep ks o rr en rtin g tB al Pe an ce Cu opl e st om S o f t Sy st em Ex ce l

nc e

Jan

Inﬂuencers

Pay employees quickly and easily. Ŕ Prevent duplicated efforts. Ŕ See what their current balance is to know if they need toŔ wire money. Ŕ Track transactions weekly, bi-monthly, month, quarter, and year.

rie

pe Ex

dg le ow Kn

Kn y

og ol

She uses Account Zone pretty regularly–several days a week. And since she’s managing multiple programs, she’s pretty active all year round.

Activities and Interest

Te c

Age: 28-55

Knowledge

ain

Account Zone really helps her issue new cards and make sure the program participants are paid quickly. The one thing she’s missing is the ability to look at each individual program as well as across all the programs she’s running to see how things are going. Her clients like to keep tabs on how the programs are performing. Right now she tracks that in Excel. She ends up either sending the Excel ﬁle to her clients, or sometimes exporting them and sending a PowerPoint with some nice charts in it. If Account Zone had a way to let her run reports on individual programs and across multiple programs that would - be really awesome.

Jul

Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Month

Frustrations & Pain Points

Questions Ŕ

Dec

Can’t look across multiple programs at once. Can’t run reports across multiple programs at once. Correcting errors in the eception ﬁle “stinks”. Knowing what the exact problem is and how to ﬁx it isn’t clear. Multiple steps with multiple applications isn’t efficient and makes it easy to “get lost” where she is. Multiple conﬁrmation screens. Another username and password to remember. Finding email with her login information.

Figure 7.7 Target audience individual persona. This persona is a heavily data-driven model. While the day-in-the-life story is a narrative, the rest is given in bullet points to serve as a design checklist. The diagram is used to communicate a signiﬁcant amount of information in a small space. Courtesy of Todd Zaki Warfel.

124

CHAPTER 7: PERSONAS

As you can see, you can combine data in many different ways to present personas, tailoring them to a variety of situations. Start with the basic persona and expand it to suit your needs.

Final Thoughts on Personas Many practitioners in the user experience design world do not believe that personas do a good job of articulating the needs, goals, and attitudes of users. They believe that personas can hinder creativity, innovation, or good design for any number of reasons. Other practitioners believe that personas meet a speciﬁc need that inﬂuences the design process in a very positive way—when they are based on solid research data and mixed with a dose of personalized reality. Which side of the coin you land on is entirely up to you. This chapter is not meant to inﬂuence your decision one way or the other. Plenty of articles on the topic are available online, and plenty of professionals are ready to give you their view. All of these resources can help you ﬁgure out how personas will work best for your projects, so seek them out. Jared Spool, CEO and founding principal of User Interface Engineering (www.uie. com), also offers some insight on the topic: That value comes when the team visits and observes their target audience, absorbs and discusses their observations, and reduces the chaos into patterns, which then become the personas. What’s in the team’s head, as they are designing, is what will make a difference in the ﬁnal design. The persona descriptions are just there to remind everyone what happened.

Jared’s point is simple: By watching your target audience, infusing what you learn with research data, and synthesizing all of this into segments, you should be able to create personas that trigger the kind of empathy that keeps your team on track and building the best possible application, Web site, or product. Ultimately, however, your personas are going to be a lot like Santa Claus: They’ll only be valuable as long as people believe in them.

FINAL THOUGHTS ON PERSONAS

125

User Experience Design and Search Engine Optimization User Experience Design’s Fundamental Role in Successful SEO Search engines are the cornerstone of the interactive economy. Everything that we do as “interactivists” is ultimately connected to the world at large through Google, Yahoo, MSN, Ask, and the myriad minor engines that make up the infrastructure for ﬁnding things online. Information architecture is a critical component of how Web sites are interpreted by search engines. This chapter is designed to give you some basic understanding of why UX design is critical to search engine optimization and what you must take into account so that the environments you create will have a ﬁghting chance on Google. Jonathan Ashton

Introduction to SEO Simply put, search engine optimization is the process of developing and maintaining a Web asset with the intention of gaining and keeping top placement on public search engines for speciﬁcally targeted keyword phrases. Search engine optimization (SEO) is like a martial art, a process of learning and doing that is never complete. Even a master can progress further using observed behavior or learned method. As long as there are search engines and Web sites interested in selling something to the people searching, there will be a role for search engine optimization. SEO relies on three fundamental areas for improvement and inﬂuence: The critical group of things that the professional user experience designer

can inﬂuence—site infrastructure, technology, and organizational principles Content and all the keyword issues that relate to optimized words which

the search engines can see Links, or link popularity—the quantity and quality of links that point at your

site from other sites, as well as the organizational structure of the links inside the site We will take apart each of these three areas and examine them from the UX designer’s perspective, to better equip you for the optimization challenges that lie ahead.

Why Is SEO Important? It is interesting that even today we need to explain the relevance of search engine optimization. Clients tend to understand on some level that it is important for their Web sites to attract targeted visitors from the natural search results of the main search engines, but beyond that it is difficult for most interactive marketers to understand the impact SEO can have. Data on global search volume is available from a variety of sources, but what is most important to understand is that, whatever the source, the numbers are simply huge, and the year-over-year increases are always in double digits. For the most part, every quarter the global volume of searches increases. When Google ﬁrst launched in 1998, 10,000 searches a day was a huge volume and placed 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) own the lion’s share of searches globally, with nearly 72 percent of U.S. searches performed in November 2008. Yahoo is a distant second, with nearly 18 percent, and MSN and Ask.com trail in at 4 percent and 3 percent, respectively. Internationally, Google is even more dominant: Its market share reaches more than 80 percent in many markets. Note For more background on Google’s early days, see The Google Story, by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), in 2008 there were easily more than 60 billion searches per month performed globally by 750 million people, with over 18 billion searches performed in the United States alone. To put it another way, 95 percent 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 really mean on a practical level to interactive marketers? Simply put, if you are not reaching your target customers when they are searching for your products or services, your competition is getting the opportunity to sell to them. Look at your site analytics and think of the issue this way: How much more revenue would the site generate if there was a 10 percent increase in strategically targeted traffic? What about a 100 percent increase? Or 1000 percent? If your site is not generating meaningful traffic through natural search, then SEO is a requirement. A little investment in SEO can go a very long way, particularly if the interactive marketing effort to date has focused on purchasing clicks through sponsor listings. We have seen sites achieve a return on investment of 35 to 1 on monthly SEO expenditures. If you are paying the search engine companies for traffic from sponsored listings but you are not investing in natural traffic, you are really limiting yourself to about 10 percent of the opportunity. Think of your own search behavior: When was the last time you clicked through more than one or two of the paid sponsor listings in a search result? Any discussion of why SEO is important and why it is here to stay could go on for chapters. Suffice it to say that Google is not going anywhere but up, and that 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

Important Basic Resources Expertise emerges from a well-rounded education. The professional who simply focuses on his or her specialty loses perspective on everything else around. That is why it is imperative that every interactivist spend at least a few minutes learning about SEO. Although there is no official set of guidelines, Google has been kind enough to provide some very salient resources. If you’re interested at all in getting better search engine performance from your efforts, check out these links: Webmasters/Site Owners Help: Search Engine Optimization:

www.google.com/support/webmasters/bin/ answer.py?hl=en&answer=35291 Webmasters/Site Owners Help: Webmaster Guidelines: Quality Guidelines:

www.google.com/support/webmasters/bin/ answer.py?hl=en&answer=35769 Search Engine Optimization Starter Guide:

www.google.com/webmasters/docs/ search-engine-optimization-starter-guide.pdf If that is not enough, drown yourself in newsletters and blogs. Start at SEOmoz.org and dig down. Just remember, as in all other things in life, if it sounds too good to be true, then it probably is.

Site Technology, Design, and Infrastructure Search engines are essentially Web 1.0.5 technology that is ﬁrmly implanted in the Web 2.0+ world. The basic premise of the search engine has changed little since the World Wide Web Wanderer was launched in 1993 to crawl the Web and build the ﬁrst Web search engine. Essentially every search engine has an application alternately called a crawler, spider, or bot that ﬁnds and follows links, sending back to the database a copy of the assets that it can see. The database is then analyzed according to the search engine’s proprietary algorithm. Using these rules, a Web asset is indexed and then ranked according to how well it scores on that search engine’s particular score card. In this rather straightforward process are a myriad of pitfalls for the UX designer.

SITE TECHNOLOGY, DESIGN, AND INFRASTRUCTURE

129

Understanding these core relationships will enable you to see your site through the eyes of the search engines. An optimized Web site relies on a structure and technology that facilitates the movement of the search engine spiders. Likewise, many decisions about handling content determine how well the search engines ranks the resulting efforts. As a result, much of this is predetermined by the decisions that are made in wireframes and in the discussions that take place around how to style and manage content.

Flash, Ajax, JavaScript, and Other Scripted Content Today’s dynamic and interactive Web design relies on technologies that are not at all friendly to the needs of the search engines. There is a widening gap between what search engines can see and what designers can do. It is up to the UX designer to be sure that the strategic plans for dynamic, designintensive sites are deployed so that both the search engines and the users get the best possible experiences. Having a fundamental understanding of how search engines interact with this kind of content will help you to decide when to deploy it and where to compensate for its weaknesses. It is entirely possible to build an optimized site that relies heavily on scripted content if the appropriate compensations are in place at the beginning of the process. It is substantially more difficult to build static or indexable content once the site is built and live. So make a forceful argument for static content, on the grounds of usability and for the sake of the search engines’ crawlers. It may seem like extra work up front, but the return on investment is exponential. Flash Flash content is technically “indexable.” There have been some recent advances in the ability of the search engines to see into Flash ﬁles to ﬁnd the text and links that are built into these assets. Although this content is indexed, have you ever seen an all-Flash asset win top placement in the search results? You probably haven’t because it’s risky for search engines to open themselves up to full compatibility with Flash. Let’s assume that the search engines could completely see all of the links and text content that is embedded inside the SWFobject. What prevents an unethical (or “black hat”) optimizer from putting apples in the text layers of the object while showing

130

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

oranges to the human user viewing the fully compiled assets through a browser? How can you deep link into a Flash asset without it being fully compiled? These fundamental vulnerabilities will remain until the search engines can reach some level of artiﬁcial intelligence that can tell that an image is a picture of a horse without some associated text that says “this is a picture of a horse.” To architect a Flash Web site that is compatible with search engines, you must add a static layer of content that duplicates the Flash content. Leaving aside the needs of search engines for the moment, a static layer of content is a key for compliance with usability requirements. Think of the search engine as the person who is viewing Web content over a dial-up connection or is using a screen reader browser. These people may be the lowest common denominator, and it is possible that the strategy behind your Web development discounts this very small percentage of human users. But when you discount this handful of people, you also discount GoogleBot and Yahoo Slurp—the two most important visitors to your site, since they are the crawlers that will enable the major search engines to index your site. If no text words or spiderable links are visible to the search engines, your content will inevitably not be ﬁndable through meaningful search results. A static layer can be accomplished in a number of ways. To comply with search engine requirements, the static layer of content needs to mirror the Flash content. This is not an opportunity to show the search engines something different than what is deployed in the Flash; if you do that you are violating the spirit of the game and standing squarely on the dark side. The ideal way to embed Flash content into a static layer is to use SWFobject so that both the Flash and static content can live on the same URL. This will allow the search engine to ﬁnd the static content and the Flash-enabled browser to display the animation instead of the static content. If at all possible, do not use redirecting so that you can conserve the popularity of the link that is pointing to the 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 runs on the gray side of SEO. Cloaking can be a dirty word to SEO purists, but if you approach the following challenges from the right side you can have some cake and eat it too.

SITE TECHNOLOGY, DESIGN, AND INFRASTRUCTURE

131

Cloaking takes advantage of user agent detection, detecting search engine crawlers as they visit a Web site and routing them to static pages to index. But when a human visitor sees the same page in search results and clicks the link, the Web site detects that the user agent is a human with a Flashenabled browser and shows that person the dynamic experience on a completely separate URL. The crux of the issue remains the same as with the SWFobject method: You have to show the search engines the exact same things in your cloaked content as you do in your Flash content. Ajax, JavaScript, and Other Scripted Content A powerful driver of Web 2.0 content, Ajax provides Web developers with the ability to build pageless content. However, the problems that search engines have with Ajax are multifold and require good planning to avoid big mistakes. Ajax stands for Asynchronous JavaScript And XML, which hints at the difficulties search engines have with this technology. Search engines essentially can’t deal with JavaScript; the efficiencies that JavaScript brings to developers are the problems that 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 contents of the initial page load, and any content that is loaded through a script that takes place after the initial shell loads will not be visible for indexing. Because Google can’t extend a session beyond the initial page load and doesn’t have a mouse or external agent to activate a script, any pageless content that is activated by the user will be invisible unless the text content is included in the preloaded shell. It is up to the UX designer to be certain that the three-dimensional modeling necessary to structure pageless design also includes the requirement that text and links all preload in the page shell. Anything else, and your cool design is invisible. Scripted Navigation One of the most common problems that will hamper optimization is the use of JavaScript in the core of site navigation. This is a very common condition and is the result of the way many site development and content management tools work. The scripted navigation looks cooler, so people tend to be interested in using it. But if JavaScript is the technology that drives the site navigation, the result is that search engines can’t properly build a model of the link

132

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

relationships within the site: They simply can’t see the link structure of the site. And if the search engines can’t model the link relationships in the site, deep content will be invisible or will not be assigned the right link popularity.

Content Management Systems Content management systems have been built for the convenience of humans—but many of these systems make it difficult for search engines to deal with their output. Following are some typical problems that need to be avoided, either by using work-arounds or choosing a content management system that is more search friendly: Dynamic URLs. Search engines don’t understand a “page” of content; it

understands the path to that content. A change in the path, or URL, leading to that content causes the search engines to accidentally clone the content multiple times. This condition substantially impairs the ability of a site to do well. If the content management system has a system that creates session IDs in URLs, you could be in real trouble. Track with mature analytics, not session IDs. Multiple URL paths. A typical problem with e-commerce content man-

agement is that as a product progresses through its lifecycle, it accrues multiple URLs. Again, since the search engine can only understand a page of content based on the URL where it ﬁnds the content, when a product appears in a category and is a part of a gift basket and is a weekly special (and on and on), pretty soon the search crawlers have followed a bunch of different links to ﬁnd the same piece of content. Do whatever you can to ensure that each piece of content exists only on one URL and that multiple paths actually rely on one URL, regardless of where the links are deployed. Rely on mature analytics systems to parse channels. Unintentional cloning. When you come to the realization that a piece of

content should only be accessible through a single URL path, it is easy to see other conditions in content management systems that cause content to be unintentionally cloned. Suffice it to say that the architecture must only have a single URL path to a single piece of content. Inﬁnite loops. A corollary to the unintentional cloning issue is the inﬁ-

nite loop. Make sure that you do not put the search engine spiders into

SITE TECHNOLOGY, DESIGN, AND INFRASTRUCTURE

133

a potentially endless task of following “next” links in a calendar or some similar situation. If the search engine spider can traverse a next link onto the next day of a calendar where it can ﬁnd another next link, it will follow that link to the next page, and on and on. Prevent this kind of situation by using a scripted link that the search engines can’t follow so that the crawlers can spend their time on the content that you want to have indexed. Old URL structures. The ﬁrst thing that many site redevelopment proj-

ects do is to replace the old URL structure. The trouble is that the search engines have probably already indexed the content at these old URLs, and as soon as you change all of them you are essentially sending your indexing back to square one. In addition, any deep links that the site has accrued over time are pointing at the old URL structure. At all costs, preserve as many of the old URLs as you can. It is probable that when you replace the content management system you will have to change all the URLs, so if this is inevitable, be sure to recommend that the old URLs are given a status code of “301 Moved Permanently” and redirected on a oneto-one basis from the old URLs to the new URLs. The 301 redirect is the only acceptable redirect for search engine purposes.

Domains, Directory, and URL Structure All Matter If you are starting from scratch, and if the restrictions of branding issues allow, try to select a domain that contains a keyword or two. It is difficult these days to get a .com domain that has quality keywords, but if you do, separate those keywords with hyphens. An important part of how UX affects SEO is in a site's directory structure. It has a critical inﬂuence on how link popularity is distributed throughout the site. Simple is better. Avoid having extraneous ﬁles in the directory structure at all costs. Some content management systems will automatically insert a subdirectory; prevent this if at all possible. This condition dilutes the relevance of the entire site. The search engines understand the hierarchy of the site based on the way the site directories are structured, so be sure that 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 section 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 one ﬁlename. Go for something like this: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. In addition, be sure that you have redirects set up for http://site-in-question. com to 301 Moved Permanently redirect to http://www.site-in-question.com. If a site will resolve with and without the www, search engines (particularly Yahoo) will index content at both URLs, opening the entire site up for accidental duplication. This condition tends to propagate when a third party links to the site without the www and the site contains a dynamic link structure.

Content: The Once (and Current) and Future King Although generating content is someone else’s problem, the groundwork that is laid in site architecture has a lot to do with making the right content available to search engines. As with all forms of keyword-driven search, you need to understand the actual search behavior of the people you want to view an asset. Search engines are still very “primitive,” in that they rely on users typing in keywords to connect them with assets that are more or less relevant for these words. Picking the right phrases has everything to do with whether your site is relevant in the right context. In a perfect world, your SEO partner will provide you with a set of keyword phrase targets before you begin and will collaborate with you throughout the wireframing process. If there is no such competent partner involved with your process, read up on the Google AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) and do a bit of investigation into the actual search behavior of people exploring your category. Then spend some time with this input to ﬁgure out the phrases that potential customers are searching, and use those phrases as appropriate throughout the site. Search engines look for keywords in a number of places throughout their analysis of a site. Optimization relies on making sure that the right words are in the right places. By understanding the role of keywords in the UX design process, you will establish the framework necessary to enable future success.

CONTENT: THE ONCE (AND CURRENT) AND FUTURE KING

135

So why is content king? It is the very core of what a Web site is designed to deliver. Search engines need text content that they can see and index. Site visitors need engaging content that is worthy of their attention. Bloggers and Webmasters need content that is linkworthy. Without the right content in the right places, search engines cannot connect the right visitors with your site.

Naming Conventions and the Battle Against Jargon It is essential that keyword targets are reﬂected in the taxonomy developed for a site. Using keyword phrases in the main site structure makes the whole site more relevant for the things that you are selling. If you’re selling widgets, don’t call the online product list the Catalog, call it the Widget Catalog. Likewise, use your keyword research to make decisions against jargon. For example, use the words laptops as opposed to notebooks in your structure because people search for laptops 10,000+ percent more frequently than they search for notebooks.

Metadata, Headers, and Keywords It is pretty remarkable that we have gotten this far into the chapter before digging back into basic issues of metadata. A myriad of meta tags are available, but only a handful really have much inﬂuence because all the others are susceptible to spamming. Relevant tags are these: Page title. Please note that this is not the <meta title> tag, but is the

actual

tag in the page header. This tag contains the page’s actual title, and it is the most important 65 characters on the page. Think of the title as the little tab sticking up in the old-fashioned library card catalog, which says “Clements, Samuel” and indicates that all the cards behind that tab are books by Mark Twain. Each page of the site must have a unique page title. Do not stuff keywords in the title, and be sure to front-load the title with the words that matter most. Meta keywords. This tag has virtually zero inﬂuence on the searchengines because it is so vulnerable to spamming. The exceptions appear to be that Google AdSense syndication looks at the meta keywords tag and that Yahoo is inﬂuenced in a very tertiary way by it. Meta keywords136CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION need to match the content of the page, and this tag is actually a good place to insert potential misspellings. It should be different for each page. Meta description. As with the page title and meta keywords, be certainthat the meta description is unique to each page. This description is just that: a summary of what is contained on the page in question. Tell it, don’t sell it, in about 150 to 160 characters. This content is critical because it is probably what search engines will display under the link to your page. If the page does not contain a meta description, the search engine will look for a snippet of text or other content that contains the keywords searched and display that in its results. The meta description is more about usability than SEO, so be certain that each page is properly tagged. “Noindex” meta tag. If you have any pages you do not want to includein search engine results, use the noindex meta tag. Just be certain that pages you do want to be indexed do not inadvertently contain this tag. Headers. Search engines recognize the headers