UX A PROJECT GUIDE TO
DESIGN
FOR USER EXPERIENCE DESIGNERS IN PRACTICE OR CREATION
RUSS KIDS A CAROLYN CHANDLER
PEACH KEY PRESS
A Project Guide to UX Design: For User Experience Designers on Site or in Development, Russ Unger and Carolyn Chandler
New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (fax) Find us on the web at: www.newriders.com Send a message to[emailprotected]New Riders is an offshoot of Peachpit, a division of Pearson Education. Copyright © 2009 Russ Unger and Carolyn Chandler Acquisition Editor: Michael J. Nolan Project Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laflamme Editor: Leslie Tilley Proofreader: Suzie Nasol Writer: Danielle Foster Indexer: Valerie Perry Cover Design: Mimi Heft Cover Producer: Andreas deDanaan Interior design: Mimi Heft
Notice of Rights All rights reserved. No part of this book may be reproduced or transmitted in any form, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information about permission to reprint and excerpts, please contact[emailprotected].
Disclaimer: The information in this book is passed on without warranty and without warranty. While every precaution has been taken in the preparation of the book, neither the authors nor Peachpit shall be liable to any person or entity for 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 applications described herein and hardware products.
Trademarks Many of the terms manufacturers and sellers use to distinguish their products are claimed as trademarks. If those terms appear in this book and Peachpit was aware of a trademark claim, the terms appear as desired by the trademark owner. All other product names and services mentioned in this book are used only for editorial purposes and for the benefit of these companies, without intent to infringe any trademarks. Such use, or use of a trade name, is not intended to convey an endorsement or any other association with this book. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 Printed and bound in the United States of America
Praise for a UX Design Project Guide If Russ Unger and Carolyn Chandler were magicians, the Alliance would be after them for leaking their best secrets. Fortunately, that is not the case. Russ and Carolyn have collected wisdom previously known only to the most seasoned UX project leaders and codified it for all to see. Now you can learn the secrets needed to run great user experience projects. Jared M. Spool, CEO and founder of User Interface Engineering
Is there a book that can tell you everything you need to know about user experience design? No. Is there one book that gets you there the most? There is now. Carolyn and Russ have laid a solid foundation for planning and managing design projects. This is an essential guide for anyone struggling with the competitive methodologies, the endless meetings, and all the important aspects of user experience design. Dan Brown, author of Communicating Design
This book is a fantastic introduction to making great products for real people. But it is about much more than just design - it also encompasses everything related to design: managing projects, working with people and communicating ideas. A great all-rounder. Donna Spencer, author of Card Sorting: Designing Usable Category
This is a practical, accessible, and very human guide to a very human activity: collaborating with people to create great things for other people. Steve Portigal, Portigal Consulting
If you've heard of author Wil Wheaton, you'll understand why I admire Russ Unger so much. Russ's experience and guidance were fundamental to the construction and design of Monolith Press, and he was one of the most valuable employees 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 been nearly completed without the support of my family, friends, colleagues, and a host of people who were completely unknown to me before I typed the first few keystrokes. My beautiful wife Nicolle, who knowingly married a nerd with a hot-tempered fever, managed to double her parental responsibilities for most of the writing of this book. Our daughters Sydney and Avery would often nudge and revive their near-comatose father to dance, sing, and play Spore. I couldn't help thinking that writing a book with a newborn in the house wouldn't be such a big challenge. I quickly learned the opposite. And Nicolle kept coming to my rescue and giving me the focus I needed to complete this project. She is the heroine I trust the most. She keeps our house in order in the chaos. She is the center of our world here and gets us all out of trouble far too easily. Nicolle, along with Sydney and Avery, make me look like a pretty good dad and I'm thankful for that. I live in a house with three girls and I can't imagine loving any of them with less than all I have to give. Carolyn kept me informed. There were times when it seemed like this project would never begin or end. She always kept things moving, explored ideas and pointed us in the right direction. The collaboration was great and I learned a lot from it! She is definitely a great UX yin to my UX yang. Michael Nolan was our acquisitions editor and he was the perfect guide. Michael is honest and friendly and really helped make everything run smoothly. Rebecca Freed was the juggler, covering every aspect of the book, keeping us informed and often emailing us late into the night. Unfortunately, she often got an answer from me almost immediately! Linda Laflamme was our development editor, and once I got used to her Red Pen of Doom, it was pretty clear to me that no matter how hard I tried to drown her in incomplete thoughts and corollaries, she was pointing me in the right direction. Leslie Tilley put the finishing touches to the words; Tracey Croom brought production, layout and graphics together; and a real book came out. Steve "Doc" Baty read every chapter before birth in the Peachpit offices. I often sent Steve chapters around 2am, and he iv
THANK YOU
would send his feedback before 5am which is no mean feat. However, Steve is in Australia, but it's still impressive. Without Steve's constant willingness to help and his quick fixes, it would be hard to imagine this book making its way onto the shelf. Brad Simpson (www.i-rradiate.com) took all the images 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. Brad could easily walk away at any time, but he is a true friend who was interested in the project and willing to support me. I'm not sure there will be enough steak dinners to pay off that effort, but I'll work hard to get there. Thank you Brad for sacrificing many of your days off and late nights to support this. Mark Brooks freaked me out a few times when I tried to convey messages that required a visual component beyond my time and/or skills. Mark stepped in more than once and saved the day and for that I owe a huge debt of gratitude. Mark is talented and dedicated and the type of person I want to be. Jonathan Ashton wrote the entire chapter on search engine optimization for us. After talking to Jonathan for five minutes, I knew he was the right person for the job. His chapter alone is a good reason to buy this book and it was great to have him on board. Jono Kane spontaneously jumped in at the last minute. Jono is a web developer, interaction designer, and prototyper at Yahoo and was invaluable in his support and help writing Chapter 12. Lou Rosenfeld really helped get the ball rolling. Lou is not only a co-author of the famous "Polar Bear Book" (O'Reilly's information architecture for the World Wide Web), but is also brilliant, friendly, approachable and always willing to help others in our field. You'll be hard-pressed to find many people as generous as Lou. Christina Wodtke helped me socialize and socialize. Without Christina I wouldn't know where we would be today, but it probably wouldn't be "in press". In addition to being an "author to read," she is also someone who was always there to offer advice and insight. Many in the UX design field owe much of their knowledge to Christina's relentless efforts to broaden our horizons through constant innovation. THANK YOU
v
Will Evans and Todd Zaki Warfel generously provided high-quality results that you can use as templates for your own results. True brothers, they gave their time and talents without question or concern, often on a whim. They are great members of our UX community - the ones you want to meet and work with - and I'm lucky enough to be friends with them. There is no way I can do justice to the gratitude I owe these two. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING gang), and Wil Wheaton have served me well as good friends and true supporters and believers. I'm lucky enough to be able to type these names together as a list of people I know and I'm a huge fan of everything they do. Your support has been invaluable to me in everything I do. These wonderful people went out of their way to help me by generously providing input, anecdotes, and access to their resources, and I thank them from the bottom of my heart: Tonia M. Bartz (www.toniambartz.com), Chapter 7; Steve "Doc" Baty, (www.meld.com.au), Chapters 3, 11, 14 and "A Brief Guide to Meetings"; Mark Brooks (www.markpbrooks.com), chapters 3 and 11; Leah Buley (www.adaptivepath.com), chapter 11; Dave Carlson (www.deech.com), Chapter 11; Will Evans (www.semanticfoundry.com), chapters 7, 10 and 11; Christopher Fahey (www.behaviordesign.com), Chapter 14; Nick Finck (www.nickfinck.com), Chapter 10; Jesse James Garrett (www.adaptivepath.com), Chapter 10; Austin Govella (www.grafofini.com), Chapter 11; Jon Hadden (www.jonhadden.com), Chapter 12; Whitney Hess (www.whitneyhess.com), Chapter 11; Andrew Hinton (www.inkblurt.com), Chapter 10; Gabby Hon (www.staywiththegroup.com), Chapters 3 and 11; Kaleem Khan (www.uxjournal.com), "A Quick Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), chapter 14; Livia Labate (www.livlab.com), Chapter 7; Michael Leis (www.michaelleis.com), Chapter 11; Troy Air (www.ascendrealtysolutions.com), Chapter 14; James Melzer (www.jamesmelzer.com), chapter 10; Matthew Milan (www.normativethinking.com), Chapter 7; Chris Miller (www.hundredfathom.com/blog), “A Quick Guide to Meetings”; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), chapter 11; Stephanie Sansoucie (www.linkedin.com/in/smsansoucie), Chapter 11; Kit Seeborg (www.seeborg.com), Chapters 3, 11, and "A Quick Guide to Meetings"; Josh Seiden (www.joshuaseiden.com), chapter 7; Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and "A Brief Guide to Meetings"; Samantha Soma (www.sisoma.com), “A Quick Guide to
vi
THANK YOU
Meet"; Donna Spencer (www.maadmob.net), Chapter 7; Jared M. Spool (www.uie.com), Chapter 7; Keith Tatum (www.slingthought.com), Chapter 12; Todd Zaki Warfel (www. messagefirst.com), Chapters 7, 12 and 14. I would also like Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau and Hugh Forrest SXSW, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton - as well as the folks at Manifest Digital and everyone at Draftfcb. Inevitably I'll miss someone, and I hope it's not taken personally. There's a plethora of people in the "crowd" that have been found and I have tried to keep track of everyone. If I have missed you, let me know and I will find a way to make it up! Finally, it is important to note that without organizations if the Information Architecture Institute, the Interaction Design Association and others, it would have been impossible for me to make contact with many of the persons mentioned. If you're interested in the field of UX design, explore these organizations, join them and get involved!
Carolyn Chandler Many of us dream of writing a book someday in our lives. I don't know if without Russ I would have ever had the motivation to jump in and do it. His energy and enthusiasm helped us find the right people at the right time, from the Peachpit team to UX industry executives, all of whom have had a huge impact on what you see on these pages. He is truly one of the greatest facilitators in our field and he thrives on bringing people together day and night. I also think he tweets more than me in one day since I joined Twitter! Russ thanked many people who helped both of us a lot. I won't repeat all those names, except for Steve Baty, who read all our chapters in every rough form we could give him and who at 2am (his time) still managed to sound enthusiastic. John Geletka also provided thoughtful feedback and interesting discussions with a spark and perspective that spans multiple disciplines. And of course the Peachpit team; I will never forget getting my first chapter back from Linda Laflamme. It wasn't pretty (although she made the suggestions with great delicacy). you patient
THANK YOU
vii
guided me through the changes and helped improve my workflow, which was originally more suited to writing one-off white papers than writing a full book. I now even add transitions to my casual conversations with colleagues! Speaking of which… Christine Mortensen, aka Morty, was my accomplice when it came to the visuals. The icons and charts you see in my chapters are the result of her hard work - and I know how hard, because she and I worked on many of the same client projects as we tried to meet chapter deadlines. Morty is one of those visual designers who has a solid foundation in both visual design and interaction design, enjoys collaborating with anyone on a project and bringing concepts to life. Her integrity and focus on quality make her a pleasure to work with and I am honored to have her as a partner. Thanks also to everyone at Manifest Digital who has been so supportive of us over the past few months. Jim Jacoby brought a special blend of business acumen and UX perspective, with his signature zen-like calmness helping me through stressful moments. Jason Ulaszek is one of the most enthusiastic people I know in the UX space and he has an endless knowledge of tools and techniques; I have no idea where he makes room for all this! In addition, Brett Gilbert and Jen O'Brien provided valuable input on some of the many roles that work with UX designers. I also want to thank the members of the Manifest UX team who have inspired me and been so patient with my constant hints about the progress of "the book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne and Santiago Ruiz. Working with you is always a pleasure. Every day I appreciate your humor and insight. Thank you to my colleagues at the Interaction Design Association for sharing your experience and for being active members of the UX community, which I love. In particular, I would like to thank Janna Hicks DeVylder and Nick Iozzo, who have been instrumental in the development of the Chicago chapter and continue to find new ways to build a vibrant network of intelligent people. Finally, I would like to thank my family, friends and Anthony who all patiently endured my disappearance and continued to check that I am still alive. You have plenty of rain checks to cash and I look forward to spending them with you!
viii
THANK YOU
Contents INTRODUCTION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
CHAPTER 1: The
Tao by UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is user experience design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The general definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Ecommerce Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-Learning Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 social network applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Choose your hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Information Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 User researcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 other roles you can play or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Setting up a network to represent the interests of users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Understand the corporate culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Constrict. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CHAPTER 3: Suggestions
for consultants and freelancers. . . . . . . . . . . . . . . . . . 39 suggestions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Creation of the offer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CONTENTS
ix
title page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 achievements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ownership and rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional costs and fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 project awards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Confirmation and release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
service descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 CHAPTER 4: Project
Goals and approach. . . . . . . . . . . . . . . . . . . . . . . . . . 56 Consolidating Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
How can a UX designer help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Understand the project approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 waterfall approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 modified approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 What are the consequences of the approach for me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 CHAPTER 5: Business
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Understand the current status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Collect ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Summary of Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Collect the right stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Make a plan for the meetings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Requirements Eilicitation Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Effective meetings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Coalescing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
X
CONTENTS
CHAPTER 6: Users
Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 basic user research steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating a list of attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 set and define priorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Selection of research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How many research activities can I include? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 User interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 surveys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 focus groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Sort cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
After research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 CHAPTER 7: Personas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 What are personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Why should I create personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finding Information for Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Creating Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Minimum Content Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Optional Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Advanced personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 final thoughts on personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 CHAPTER 8: Users
Experience design and search engine optimization. . . . 126 Introduction to SEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Why is SEO important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Main 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 are all important. . . . . . . . . . . . . . . . . . . . . . . . 134
Contents: The once (and present) and future king. . . . . . . . . . . . . . . 135 Naming conventions and the fight against jargon. . . . . . . . . . . . . . . . . . . . . 136 metadata, headers and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
CONTENTS
xi
Separate the hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Using Sitemaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep the content up to date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other substantive problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Link popularity explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical link popularity distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 links in the footer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Cross-linking in-content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Play the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat vs. Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Spamming with Meta Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Cloning and Doorway Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Link spamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Some final thoughts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 CHAPTER 9: Transition:
From definition to design. . . . . . . . . . . . . . . . . . . . 144 Developing and Visualizing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
The basic process of storyboarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Facilitate the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Make sure you have good tension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The development lawyer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Prioritizing Conflict Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Plan your activities and documentation. . . . . . . . . . . . . . . . . . . . . . . . 162 CHAPTER 10: Website
Maps and job flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is a task flow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Hand Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 basic elements of sitemaps and job flows. . . . . . . . . . . . . . . . . . . . . 168 page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stack of 168 pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 decision point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Connectors and Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Common Mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 sloppy connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
xiii
CONTENTS
Misaligned and unevenly distributed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Badly placed text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Missing page numbering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 The simple sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Advanced Site Maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Breaking the sitemap form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Job flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 take task flows to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Swim lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 CHAPTER 11: Wireframes
and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What are annotations?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who uses wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Create wireframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 tools of the trade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Start simple: design a simple wireframe. . . . . . . . . . . . . . . . . . . . . . . . . .191 First steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 The wireframes and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
An exercise: design a wireframe for the homepage. . . . . . . . . . . . . . . . . . . 195 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The results: design a wireframe for the home page. . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When wireframes mature and find their own way in the world. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 design exercises - continued: which design is good? . . . . . . . . . . . . . . . . . . . . . . 201
A final note on wireframe presentation. . . . . . . . . . . . . . . . . . . . . . . . . 202 CHAPTER 12: Prototyping .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What is Prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How many prototypes do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Paper Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe vs Realistic Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML vs. WYSIWYG Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional Prototyping Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
CONTENTS
xiii
Collaboration with a developer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
prototype examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 What Happens After Prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 CHAPTER 13: Design
Testing with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 concept reconnaissance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 tips for exploring visual design models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Choosing an Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Research Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 discussion writing guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analyzing and presenting results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . make 243 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 tests with users (again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 … Start! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Post-launch activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post Launch Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Postlaunch design tests with users (again) . . . . . . . . . . . . . . . . . . . . . 255
All done, right? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Like a fresh start... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INDEX 255
xiv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
CONTENTS
Introduction Why We Wrote This Book Welcome to a guide to UX design projects. Somewhere, a user experience design student doesn't sleep because he doesn't know what it will be like to work on a real project at his new company. On the other side of town, a visual designer with a lot of project experience is eager to take on new responsibilities in defining the user experience of her website. These are two people at different points in their lives, but with a similar need: to understand how to integrate user experience practices into the context of a living, breathing project. Our goal with this book is to give you the basic tools and context to help you use UX tools and techniques in work teams. As you'll see in many of these chapters, we don't try to be everything to everyone, but rather try to give you the core information and knowledge you need to fulfill many of your roles as a UX designer. In addition to our own examples, we provide examples to help you find ways to use the basic materials and allow you to combine the information and create something new, better or even more suitable for your own purposes. We hope we've indicated well that this is a pretty good approach to UX design projects. We are nothing but constantly learning and improving with every iteration (which we do). Therefore, we are active in this field to some extent. A word from Russ As a mentor at the Information Architecture Institute (www.iainstitute.org), I've noticed a pattern in the people I've worked with: Most had difficulty finding jobs or fell short of their expectations. the expectations of potential employers. Some had excellent training, but were not always able to put their UX design skills into practice in a project-based environment. The same themes recurred in many of the conversations I had at the 2008 Information Architecture Summit (www.iasummit.org).
INTRODUCTION
xv
The idea for this book, which addresses many of these common problems, took shape. I don't remember whether Carolyn or I sent the first email, but I do know that I found in her a willing and able co-author who helped me develop the idea that ultimately led to this book, to refine. A word from Carolyn For years I have been fortunate enough to build and lead UX teams. I say lucky because I think UX designers generally have a great balance of traits that are just plain fun to work with, combining right brain intuition with left brain logic. When conducting interviews to build these teams, one thing really struck me: having a relevant educational background, such as human factors or communication design, is a good indicator that someone is committed to UX design, but it is not the number that is an indicator of whether someone fits well in the team or in a project. Equally important - if not more important - is the person's ability to adopt an advisor's mindset. This means a positive attitude, a drive to understand and involve others in a project, and - most importantly - a focus on making a real impact on users and customers. This mindset involves taking the time to understand the perspectives of other roles in the project, making arguments and making compromises where necessary. It takes experience and effort to really get this mindset firmly in place, but an open mind, a strong foundation, and a good set of questions (and the courage to ask them) will go a long way. This book may not provide all the "answers," but it does provide the questions you need to ask to find them.
Who should read this book? A UX design project guide provides a comprehensive, introductory overview of UX design in the context of a project. Anyone interested in UX design should find something useful here. We specifically targeted the following groups: Students taking UX design courses (e.g. Human-Computer Interaction or Interaction Design) who want to supplement their courses with information on how to apply what they learn to real-world situations where communication and cooperation are essential.
xvi
INTRODUCTION
Practitioners who want to deepen their knowledge of the basic tools and techniques of UX design and improve team communication across the roles involved. Chapter 3 is mainly aimed at freelancers who need to make their own proposals. UX design group leaders looking for a book to help their teams incorporate project best practices into UX design activities. Leaders of all project teams who want to know more about how UX design is incorporated into their projects, its value and what to expect from UX designers. IF YOU MUST...
THEN YOU MUST READ...
Define user experience design and understand what draws people to this field
Chapter 1: The Tao of UXD
Ask the questions that are important to answer before the project begins (or at least before you start working on it).
Chapter 2: The project ecosystem Chapter 3: Suggestions for consultants and freelancers
Get off to a good start with efficient meetings, clear goals, and well-understood approval points
Online Chapter: A Brief Guide to Meetings. Chapter 4: Project goals and approach
Define project requirements that are clear, easy to prioritize, and sourced from business stakeholders and users
Chapter 5: Business requirements Chapter 6: User research Chapter 9: Transition: from definition to design
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 use the tools and techniques to quickly communicate visual ideas to your project team
Chapter 10: Sitemaps and job flows. Chapter 11: Wireframes and Annotations. Chapter 12: Prototyping
Make sure your website is easy to find and searchable for users and search engines
Chapter 8: User Experience Design and Search Engine Optimization
Communicate and develop your design with the project team as soon as development begins
Chapter 14: Transition: from design to development and beyond
Be sure to visit www.projectuxd.com to read the bonus chapter “A Quick Guide to Meetings” and download other bonus materials such as templates.
INTRODUCTION
xvii
A note on methodology There are several approaches and methods. We are not in favor of one approach over the other. Our goal for this book is to focus on the steps common to most projects: defining the project requirements, designing the experience, and building and deploying the solution. The amount of overlap between these steps varies greatly depending on the project approach you use (see Chapter 4 for more details). For the most part, our framework is a loose, linear approach where the definition step is paramount, but at each step we use facilitation and design techniques where they are most useful.
What this book is not: An encyclopedia of all techniques. There is a huge number of creative people in the UX field who are constantly trying new approaches to design problems. Incorporating all of these approaches would result in a much larger book — and one that would quickly become obsolete. What we have included here are the most commonly used techniques, anything and everything of UX design. We have tried to provide enough information to engage you and allow you to share the activities with other project members - including the basic process for each technique and additional references to books or websites to help you implement them once you have your path determined. A guide to becoming a project manager. Good project management (including setting and following project goals, timelines and budgets) is key to the success of any project. We are not covering the details of how to be a project manager or how to choose a specific project methodology. We discuss the skills a UX designer brings to a project to enable an effective process, such as facilitation and communication, as well as the ability to clarify and focus on project goals. These skills will help you become a project management partner. The only or perfect process or method to follow. We don't have all the answers - nobody knows today. The field of UX design is relatively young and we are all working to improve. You will likely encounter trial and error, additions and improvements, and feedback
xviii
INTRODUCTION
Information from others helps you tailor a process to your needs. If you find something that works for you, share it! Let us know!
How to use this book: There are many excellent resources for UX designers. We cover the topics in depth here, but refer you to references that will allow you to explore topics at a deeper level, depending on how much time you want to spend on them. To help you understand how much time is generally required for each reference, we've divided them into three main categories:
Surfing Surfboard references are shorter messages (usually online) that take 5 to 30 minutes to read.
Snorkel Those addressed by the snorkel are longer online articles, white papers, or short books that take an hour to a weekend to read.
Deep diving Those called with the diving helmet are long books that will probably take more than a weekend to read; They provide you with in-depth coverage of the subject.
INTRODUCTION
xix
This page has been intentionally left blank
1
The Tao of UXD Curiosity meets passion meets empathy The most important thing is not to stop asking questions. Curiosity has its own raison d'être. One cannot help but be in awe as one contemplates the mysteries of eternity, life and the wondrous fabric of reality. It is enough if every day you try to understand a little of this mystery. Albert Einstein
Curiosity is nature's original method of education. Smiley Blaton
Passion and determination go hand in hand. When you discover your purpose, you will usually find that it is something you are passionate about. Steve Pavlina
The great gift of man is that we have the power of empathy. Mary Streep
1
Q
Basically, this chapter is about you and others interested in user experience design (or UX design for short).
If you are reading this sentence, you are a curious person. You want to know how things work - from doorknobs to airplanes to that thing stuck in your throat. You especially want to know what moves people. You don't see things in black and white; There are countless shades of gray to discover! Sure, you can sometimes drive your colleagues a little crazy by always agreeing to play devil's advocate, but you can't help but look at the other side of the coin. Lucky you! The field of user experience design attracts curious people who like to work with many shades of gray. We look for patterns and strive for organization and structure. We connect the dots. We tirelessly strive for the next piece of the puzzle, and when the puzzle is solved, we look for ways to improve it! We can be analog or digital. We are at home with pencil and paper, whiteboards and erasable markers, sticky notes and Sharpie pens. We talk in terms of Visio and "Graffle" and live in a world full of boxes and arrows connected on the myriad screens of our computers. We're not just curious. We are passionate! We are passionate about brainstorming ideas and facilitating discussions. We're passionate about creating things that make a difference to those who use them - and those who make them. Oddly enough, we are most proud when something we make is so good that people don't even realize how good it is! And of course we have empathy. We can feel it deep within our being when we have a bad experience. Even worse, we try to find solutions to the problems right away. We know what it's like to get an unexpected answer to a seemingly simple request - and we don't like that! We don't want users - people like us - to have to endure the confusion and sense of inadequacy that often comes with a bad experience. 2
CHAPTER 1: THE TAO OF UXD
When you combine that near-constant, childlike curiosity with an unparalleled passion for "doing what we do" and a sense of how others feel, you create a vibrant community of professionals who enjoy speaking up, asking questions, providing solutions. to share and to be wrong - all in the name of finding what is right. Welcome to the UX design community.
What is user experience design? There are many definitions of user experience design. After all, it's a field that thrives on defining things. Granted, sometimes we're not very good at defining "the damn thing" when it comes to the different parts of the whole, but at least we know what the whole is. In this book, we will mainly focus on two definitions: the broadest meaning of the term UX design and the definition that we will use in the context of this book.
The broad definition of user experience design is to create and synchronize the elements that influence users' experience with a particular company, with the intention of influencing their perceptions and behavior.
These elements include the things a user can touch (for example, tangible products and packaging), hear (commercials and sound signatures), and even smell (the smell of freshly baked bread in a deli). This includes the things users can interact with in ways beyond the physical, such as digital interfaces (websites and mobile phone applications) and of course people (customer service representatives, sales reps, and friends and family). One of the most exciting developments in recent years is the ability to merge the elements that influence these different senses into a more comprehensive, integrated experience. Smell-o-Vision is still a long way off, but beyond that, products continue to blur traditional boundaries.
Was het User Experience Design?
3
Don't Forget the Tangible While we focus on the digital aspects of the user experience, these kinds of interactions don't happen in a vacuum. When designing your digital products, consider the impact of the tangible experience. The environment your users work in matters, as do the physical products (screens, keyboards, and other input devices) that affect how your users interact with your design. Chapter 6 provides techniques to help you understand the implications of context. Also, don't forget about the other points of contact a product or company has with those who interact with it. Because the company's brand is influenced by many things and the brand experience does not stop on the screen of a computer or mobile phone. The best possible website design cannot make up for a reputation for poor customer service or provide the satisfaction of well-designed packaging when a product is delivered.
Figure 1.1 A modern classroom experience combines analog and digital.
4
CHAPTER 1: THE TAO OF UXD
Tactile experiences, such as learning in the classroom, are increasingly influenced by digital applications. Similarly, experiences that were previously individual, such as the decision to buy a karaoke machine at home, are increasingly enriched by social interaction.
Figure 1.2 Online reviews are an important influencer for consumers.
Our focus As you can see, the scope of UX design is vast and growing. In this book, we focus on projects aimed at creating digital experiences, especially on interactive media such as websites and software applications. To be successful, the user experience design of these products must address the business objectives of the project, the needs of the product users, and any constraints that affect the feasibility of the product functionality (e.g., technical constraints or project budget constraints). or time frame).
Was het User Experience Design?
5
Free samples of a new nutrition bar given out during a marathon
A door handle
Packing for a pair of shoes
Figure 1.3 This book focuses on the digital aspects of user experience design.
Tactile SMS functions for mobile phones
Call customer service
Individual
social
Our focus: read online product reviews, search online archives, show targeted ads
Live chat with digital customer service
About UX Designers While curiosity, passion and empathy are traits shared by user experience designers, there is also a desire to strike a balance. We look for a balance, especially between logic and emotions, like Spock and Kirk of Data and Data in the episode where his emotion chip overloaded his positron relay. you have the idea To create truly memorable and satisfying experiences, a UX designer must understand how to create a logical and viable structure for the experience, and understand the elements that are important in building an emotional connection with the users of the product. The exact balance may vary per product. An advertising campaign for children's toys has a different balance than a patient tracking application in a hospital. A product developed without understanding both is likely to miss out on the opportunity for an unforgettable experience - and the resulting benefits to the company behind the product. Note For more information on emotional design, see Donald Norman's Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).
6
CHAPTER 1: THE TAO OF UXD
Achieving this balance requires more empathy: the ability to dive into the world of potential product users to understand their needs and motivations. User experience designers research this understanding (see Chapter 6) and create tools such as personas (see Chapter 7) to help the rest of the project team focus their efforts. Remember that emotions are only part of the bigger picture. Use the logical side to come back from the edge and focus on the task at hand. In most cases, you will work with a budget based on the time and materials required to complete the project. You must understand that sometimes you have to fish or cut bait.
Where UX Designers Live You're not alone. Look around and you will find a number of organizations and communities that can support your development as a user experience designer. Many of these organizations not only provide mailing lists, online resources, and tons of really smart people, but also sponsor events or conferences that can help broaden your horizons while narrowing your professional focus. A number of companies host educational events, including User Interface Engineering's Web App Summit and User Interface Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. There are also a growing number of "unconferences" in various cities; These are created by a group of motivated people independent of any particular company or association.
WHERE UX DESIGNERS LIVE
7
Several professional organizations also sponsor annual conferences. Table 1.1 provides a brief list of some of the more well-known organizations, their websites, and the events they host. TABLE 1.1
A selection of UX organizations
ORGANIZATION
WEBSITE
GRAND CONFERENCE (USUALLY)
Association Interaction Design (IxDA)
www.ixda.org
Interaction (early February)
The Institute for Information Architecture (IAI)
www.iainstitute.org
IDEA Conference (September/October)
American Society for Information Science and Technology (ASIS&T)
www.asis.org
IA summit (March)
ACM Special Interest Group ComputerHuman Interaction (SIGCHI)
www.sigchi.org
CHI (begin april)
Association of Usability Professionals
www.usabilityprofessionals.org
UPA (June)
Let's start! You've come this far. It's time to figure out why you picked up this book in the first place. Turn the page and dive into how user experience design works in the project space. But it doesn't stop there - this book is a guide to get you started. It contains many examples that can help you accomplish many of the tasks you need to do. We've also tried to provide additional examples to help you find your own best approach to creating deliverables that are useful to your team and clients. Keep your curiosity, passion and empathy alive! Challenge yourself to find new ways to inspire others to create the ideal user experience. That is, of course, before you get started on improving it.
8
CHAPTER 1: THE TAO OF UXD
2
The Project Ecosystem Planning for Project Requirements, Roles and Culture Ready to launch a brand new project? Or are you in the middle of it right now? In any case, take a moment to think about the dynamics and context of the project, the issues that will affect you and the rest of the project team. What kind of websites or applications are they? What roles and skills are required? What is the corporate culture like? Answering these questions will help you define the project and ultimately determine the tools and skills you need to be successful. Caroline Chandler
9
E
Each project has its own unique challenges. When designing websites or applications, many of these challenges relate to specific features and functionality, such as developing a way for a user to share photos online with friends and family, or restructuring the information on an intranet so that the content more comprehensive, easier to find and share. However, around these specific design goals, all projects have a larger context that you need to understand and include in your planning. This context is the "ecosystem" of the project and includes the environment you will be working in (the corporate culture), the general type of work you will all be involved in (e.g. the type of website you are designing), and the people you will interact with (including their roles and responsibilities). Taking the time to understand the project ecosystem will give you knowledge that will help you throughout the project. You can communicate your responsibilities and ideas more effectively and help others on the team anticipate project needs that they may not have considered. To help you, this chapter identifies different types of projects you can work on, as well as the roles you can play, the people you can count on, and how their involvement will vary depending on the type of website you're designing or the application. Finally, the chapter discusses some elements of the corporate culture that may affect the way you work on the project. Note Depending on how your client company structures its projects, a given project may involve the design of more than one site or application. For simplicity, this book assumes that a project is the design of a single type of site. If you have more than one location, consider each location individually to ensure the project team has the correct roles.
Identify the site type. While there is no black and white distinction between one site type and another, there are some relative differences in site focus and features. Once you understand these similarities and differences, you can set design goals for yourself. Those are the general issues that must exist
be resolved (e.g., "Explain the company's business model") or the attributes to be reflected in the visual design and interaction design of the website (e.g., "Demonstrate the company's responsiveness to its customers").
10
CHAPTER 2: THE PROJECT ECOSYSTEM
Consolidate the main goals of the project (see Chapter 4). Understand which departments or business units it can (or should) be.
You will be involved in gathering business requirements (see Chapter 5). Determine best practices for incorporating user research (see Chapter 6). Ask questions about what systems and technologies may be involved.
Your website is likely strongly associated 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 website or application aimed at eliciting a specific and measurable response from a specific audience or other general audience over a limited period of time. Content source – a store of information that can consist of multiple types of media (articles, documents, videos, photos, tutorials) and is designed to inform, engage, or entertain users. Task-based application – a tool or collection of tools designed to enable users to perform a series of important tasks or workflows
In the following sections, we take a closer look at each of these types, discussing their characteristics and the impact they have on the design challenges of your website or application. We'll also discuss the most common crossover projects - e-commerce, e-learning, and social - that have features of more than one type.
Brand Presence What do you think of when someone says the word brand? Often the first thing that comes to mind is a company's logo, such as the Nike Swoosh or the Coca-Cola lettering. However, a company's brand is much more than just its logo; It is the set of impressions a particular person has about the company.
Identify the type of site
11
Dirk Knemeyer gives some excellent definitions of brand in his article "Brand Experience and the Web": Brand represents the intellectual and emotional associations people make with a company, product or person... That is, brand is something that actually their Within is each of us. The science of branding is about designing for people and influencing their minds – in other words, building the brand.
For more information on the differences between a customer's experience with a company's brand and a company's efforts to build its brand, see Dirk Knemeyer's explanation in Brand Experience and the Web: www.digital-web. com/articles/brand_experience_and_the_web. For an excellent discussion of how a website's UX design can influence a person's brand experience, read Steve Baty's article "Brand Experience in User Experience Design": www.uxmatters.com/MT/archives/000111.php.
There is much a company can do to influence associations with its brand, from running memorable ad campaigns to expressing brand attributes (such as "responsiveness" or "value") through the features and design of its websites. All websites within a company are likely to have some influence on a company's brand, either directly (by presenting a website for customers to visit) or indirectly (by providing an important service that customers depend on, such as customer support). However, brand presence pages are most focused on showcasing the company's brand messages and values. They provide channels that connect directly with customers and serve as a broad online funnel for those who want to learn more about the company or what it has to offer. A brand presence website is often the company's primary .com or .org website. e.g. GE.com, or for larger and more distributed companies around the primary websites for companies of different sizes, e.g. B. GEhealthcare.com. Different product lines often have their own unique brand presence online as well. For example, Pepsico.com has a brand presence, while Pepsi.com has its own distinctive presence.
12
CHAPTER 2: THE PROJECT ECOSYSTEM
If you're working on a brand presence website, you're likely designing for a variety of audiences, including current and potential clients, investors, partners, the media (for example, news organizations and authors of well-known blogs), and job seekers.
Common Brand Presence Sites A company's main page (company.com, company.org, company.net, etc.) A site for a primary business unit of the company (often a unique site for a
(specific industry, region or large assortment) Websites for prominent sub-brands within a company
Brand Presence Design Goals The design goals that are often most important in a brand presence project are: To communicate the company's brand values and messages,
either explicitly (perhaps a statement of how important it is to respond to customer needs) or through the overall experience of visiting the site (for example, ensuring that it works properly and includes prominent features that customers should communicate to encourage the business). Provide quick and easy access to company information. you want
Answer the questions "What does the company do?" and "How can I contact someone for more information?" Present or explain the company's business model and value proposition:
“What can the company do for me?” and “How is the company doing?” Engage different primary user groups and guide them to relevant interactions.
features, functionality or content. Help the company achieve goals using key metrics such as:
the number of unique visitors. Often this is part of an overall marketing strategy. Later, in the Pick Your Hats section, you will learn about the different roles that can be involved in designing a brand presence website. Let's see first
Identify the type of site
13
on the other types of websites you may work on, including one that has a close relationship with brand presence websites: the marketing campaign website.
Marketing campaign sites are similar to brand awareness sites in that both focus on providing users with an experience that impacts their perception of the company's brand. However, marketing campaign websites are often judged by their ability to take very specific actions within a particular focus (for example, within a specific time frame or audience). Rather than serving as a channel for channeling interest, they are meant to serve as engines of interest generation. From an online standpoint, this generally means that they are aligned with an overall marketing strategy and can be run in conjunction with other marketing efforts across various channels, such as TV or radio advertising, print advertising, and other promotions.
General marketing campaign sites A landing page that promotes a specific offer. The page can be reached via a
Banner ads from another site. A small website (or microsite) that promotes a specific event. A game or tool designed to create excitement
or traffic.
The main goal of a marketing campaign website is to create a narrowly targeted campaign, usually targeting a specific set of metrics. The focus is often limited by one or more of the following factors: Time - for example, a campaign around an event (eg.
conference) or a season (e.g. the Christmas season) User group - e.g. B. A campaign targeting teens or teachers Product, product suite and/or a specific use for this product – for
For example, a website that highlights kitchen appliances by showing virtual kitchens with matching ovens, dishwashers and stoves
14
CHAPTER 2: THE PROJECT ECOSYSTEM
A campaign with a mix of these strategies would be a spring campaign focused on patio equipment sales, combining time and assortment. See Figure 2.1 for an example of a mix of product suite and user group. A marketing campaign website can be as simple as a banner ad that leads to a landing page on the company's .com website, or it can be a microsite, a small website that often differs from the recognizable branding on the .com website . a tailor-made experience according to one or more focus areas. "Small" is relative here - some microsites have only one page and others many, but in any case, the microsite is smaller and more focused than the main page for the company's brand presence.
Figure 2.1 Texas Instruments uses this educational microsite, http://timathrocks.com/index.php, to present information about the company's graphing calculators. The range of products is mainly used by high school and algebra students. The microsite generally remains associated with the Texas Instruments brand, but is deliberately different to appeal to a younger audience and organize content and features according to their needs.
Design Goals for Marketing Campaigns For the person or team responsible for the design and implementation of a website for a marketing campaign, the following design goals are often the most important: To generate interest and enthusiasm, often by presenting clear and immediate content.
This can be a value proposition (the value a product or service provides to the user, such as the ability to quickly qualify for a loan) or some form of incentive (a special offer, entry into a contest, or entertainment, such as a online game).
Identify the type of site
15
Enable a range of primary user groups to ban a specific action.
For example, clicking through to a specific location on a branded website, signing up for a newsletter, or applying for a loan. When this action is performed by a user, it is called a conversion. Help the company achieve goals by setting key metrics such as quantity.
Number of unique visitors. Often this is part of an overall marketing strategy.
For more information on designing pages to support marketing campaigns, see Tim Ash's Landing Page Optimization: The Definitive Guide for Testing and Tuning for Conversion (Sybex, 2008).
Content source A content source page contains a store of information, possibly in different media types (articles, documents, videos, photos, tutorials) and is intended to inform, engage and/or entertain users.
Common content resource sites A company's intranet An online library or information center for members of an organization Sites or portions of sites that focus on providing news or are common
updated posts (large commercial blogs may fall into this category) customer support centers
Of course, all websites and applications have content, but some websites pay special attention to the presentation and structure of their content. The focus may be because the site has such a large amount of content that it poses its own challenge, or because certain types of content have a high level of importance. For example, they can support important decisions or bring users back to the website regularly.
16
CHAPTER 2: THE PROJECT ECOSYSTEM
The main purpose of a content source site is to increase the knowledge and independence of the user by providing relevant content (such as an intranet). Often they also encourage action, such as exchanging information or buying a product after reading the description. Design Goals of a Content Source A website with a content source often needs to do one or more of the following: Present content that will be the main attraction for first and repeat visits to the site. For example, demonstrate a company's knowledge leadership skills by
through access to the ideas and perspectives of the CEO or other subject matter experts in the company. Support important decisions within the user base. Expand a company's business knowledge by generating ideas
may be buried within separate wards. This may be part of a larger goal to identify more opportunities for innovation. Support users who search for information in different ways. For example,
Some don't yet know what specific product they need (and are more likely to browse), while others may know exactly what they're looking for (and are more likely to use a search box).
For more information on the different ways users search for information, see Donna Spencer's Four Modes of Seeking Information and How to Design for Them: http://boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them
In terms of UX design, the most common tasks in a content source project include: Creating a categorization structure that fits your users' mental models. Determine how to integrate an organic content growth system
(eg functions such as tagging and filtering) Design an effective search function Identify the type of website
17
Task-based applications Task-based applications can range from a simple calculator embedded in a mortgage website to a complete system that handles multiple critical workflows. If your project includes the latter, more roles are involved and most likely there is an extensive requirements gathering process (see Chapter 5 for more information on this process).
Generic Task-Based Applications A software application that supports creating a specific type of computer
Item (such as a spreadsheet or printed piece) A web tool or application that supports a critical workflow within an organization.
Business (e.g., a ticket management application for an IT support group or a customer tracking application for a call center) A website that provides access to and management of personal information
(like Flickr)
The primary purpose of a task-based application is to enable users to perform a series of tasks that are tailored to their needs and ultimately to the customer's business goals. Goals of Task-Based Application Design Most task-based applications should enable users to do something they can't do elsewhere - or, if they can,
to do better ("better" can mean more efficiently, effectively, with a higher degree of satisfaction, or more conveniently) Help novice users with easy-to-access instructions and visual priorities.
Assignment of important tasks. Support intermediate and advanced users with access to shortcut functions
and deeper functionality Reduce user load and maximize system resources
(e.g. data reuse instead of double entry)
18
CHAPTER 2: THE PROJECT ECOSYSTEM
During the concept and implementation, attention should be paid to the degree of change that is required
the user of the application – ideally with a design that facilitates learning and a communication plan that demonstrates value to the user. One of the biggest challenges when designing a task-based application is controlling feature creep. During the development of a project, it is normal for great ideas to arise later in the design or even during development. User Experience Design is good at protecting against feature creep because user models such as personas can be used to identify high value features and maintain focus throughout the project. If a really great idea pops up later in the process that meets the needs of a high-priority user group and aligns with the site's business goals, your team might be able to make a case for a change of direction. If an idea doesn't come through, it may not be worth the delay and expense.
Ecommerce Sites Ecommerce sites can include elements of all four project types, because a site primarily dedicated to ecommerce must have its own branding, provide content (usually product specifications or product usage descriptions). Facilitate tasks (search, compare, write reviews, pay). . Marketing campaigns are also often closely associated with these websites and may involve multiple marketing groups within the organization. General additional design goals for ecommerce websites are: Explain the website mockup if it is non-standard. as online marketplaces
being constantly reconsidered, this explanation helps set expectations (for example: eBay, Amazon, and Craigslist have very different models). Support decision making as the user transitions from learning to thinking.
from comparison to purchase, with useful content and features. Leverage points in the experience where cross-selling and upselling occur
and post these suggestions in a way that is eye-catching without distracting. Create a communication flow from the point of purchase to
place of delivery. Communication should not only take place within the website, but also through other channels, for example through integration with delivery tracking systems and e-mail communication about the status of orders. Identify the type of site
19
E-learning applications E-learning applications are interfaces between a content source and a task-based application. Content must be generated for the classroom, which often requires the team to add the roles of a learning specialist and a subject matter expert (SME) for the topic being covered. The product is task-based, so the user usually follows a flow of the lesson and may also need to track progress or explore related topics. Some practical lessons may also contain assignments. General design goals are: To provide an understanding of the basic knowledge needed to start a course
and to whom it is addressed. Deliver content in manageable, on-demand chunks
Concept. Engage the student in activities that simulate hands-on learning. Communicate achievements and progress and make suggestions where appropriate
next steps to continue the educational process, such as B. further courses.
Social Networking Applications A social networking application is primarily a task-based application because users need to be able to find and add friends, manage their profile, socialize, post and search. However, they also pose content source challenges, particularly the need for an organic framework that can handle a potentially very large amount of user-generated content. Essentially, when the site gets its own identity, it also exhibits the characteristics of a brand presence site.
Snorkeling If you're working on a social networking application or trying to integrate social functionality into another type of website, this book will help: Designing for the Social Web by Joshua Porter (New Riders, 2008).
20
CHAPTER 2: THE PROJECT ECOSYSTEM
Common design goals for social networking applications are to keep potential users focused on the purpose and values of the network. Enable meaningful interactions between users who support and assist
supported by the recommended features (e.g. image sharing, video sharing and discussions). Protect the site's integrity by ensuring that those on the network are below
know how to manage their information and respond to inappropriate behavior. Harness the power of the community and showcase it to drive features.
Features available only to active members, such as popular features and reviews. Identifying the type of website or application you are working on during a project is just the first step. Next, consider the different roles that are often required and how their involvement can vary depending on the type of project.
Choose your duties: When you become a UX designer for a project, you often have to take on multiple roles. Whether or not they are formally defined within your client organization, the roles you play depend on the nature of the project and the makeup of the rest of the team, as well as the client's experience with each role. It is good to know which roles you already enjoy and which you think you can learn on the job. It is also helpful to find out what expectations others may have of the responsibilities of these roles. With this insight you can present yourself more clearly from the start of the project. What roles are most expected of a UX designer? Each client company you work for may have different titles for these roles (or no name at all if it's not a formal position in the organization). In general, you can expect the big three: information architect, interaction designer, and user researcher. Note: Few companies have the size or budget to divide these common roles among several people. Keep the role names in mind when defining a project, but talk to the client about their needs and responsibilities - otherwise they might think you're building a really big team! This focus on responsibilities rather than titles also helps you maintain your sanity: filling several of these roles doesn't necessarily mean doing many people's jobs, as responsibilities vary and fluctuate in different parts of the project.
CHOOSE YOUR HATS
21
Information Architect An information architect is responsible for creating information structure models and using them to design user-friendly navigation and content categorization. Common tasks in website and application design include creating detailed sitemaps (see Chapter 10) and making sure that categories and subcategories of information are clear and easy to use. Understanding expectations UX distinguishes between the roles of information architect and interaction designer (discussed next). However, in any given organization 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 might end up on a team titled "Information Architect" because that's the historical term for the role, whether or not it fits your responsibilities. Do you have to correct the project team if the title you get doesn't match the lead role you take on? If the project has a shorter duration (e.g. four months or less) and the title you hold is widely accepted within the organization and responsibilities are clearly defined, it may not be worth trying to change it due to the potential confusion you would cause. However, if there is no generally accepted title and you feel there is a chance that both roles will need to be represented - possibly by different people - it is worth making a distinction at the beginning of the project when considering your involvement and your communication plan. responsibilities. Essentially, for more task-based applications it makes sense to emphasize the role of the interaction designer, and for more content-based projects it makes sense to emphasize the role of the information architect. However, it may be best to use the term familiar to the client organization and ensure the team understands how you define the role in terms of the responsibilities you assume. You should clarify this definition in the service description (see chapter 3). The responsibilities of an information architect can also be blurred with those of a content strategist (see Other Roles below). If these roles are
22
CHAPTER 2: THE PROJECT ECOSYSTEM
If your project team is represented by different people, be sure to discuss how you will work together at the beginning of the project.
Interaction Designer An interaction designer is responsible for defining the behavior of a site or application based on user actions. This includes the flow of the site across multiple views and interactivity within a given view. Common activities when designing a website or application are creating task flows that represent the interaction between pages or components within the website (see Chapter 10) and creating wireframes that represent interactions within the page, such as: B. dynamic menus and expandable content areas (see chapter). 11). Understand Expectations If you're working in a small team or on a project that isn't heavily focused on creating new task-based features (for example, if you're working on a branded website that mainly contains a few categories of content, a contact form, and an opt-in form for a newsletter) The interaction designer may be the main task responsible for gathering project requirements (see Chapter 5). As an interaction designer, if you are working on a project with a high content of new features, there is likely to be a separate person on the team who is responsible is for describing the detailed requirements (e.g. a business analyst or a product manager) The process of capturing and detailing functional requirements can be greatly aided by the skills of a UX designer and documents such as functional specifications and use cases are enhanced by Experience design influenced. Be sure to sit down with the person responsible for gathering requirements to discuss how best to work together.
User Researcher A user researcher is responsible for providing an understanding of end-user needs based on information generated from or validated by research that person conducts with users. There are many types of activities that can fall under the category of user research and they can occur at multiple points in the project schedule. (See Chapter 6 for a description of common techniques such as user interviews, surveys, and usability testing.)
CHOOSE YOUR HATS
23
Understand Expectations The client organization's need for user research can vary widely depending on how important it is to the project team or project sponsor. The fact that you speak to a project sponsor about UX design before a project begins shows that someone on the client team knows that making sure users' needs are met is a top priority. But as those who have worked on numerous computational projects know, the introduction of research can also cause fear among project team members - fueled by concerns that user research could become a bottleneck and increase risk (which happens when we find something wrong and need? ). make major changes to solve the problem?) or contradict the value of a particular idea that has gained much popularity. User research expectations can vary between the business stakeholders and the project team. It is therefore essential to clarify the expectations of 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 usage patterns on the site, such as: B. Frequently visited pages and frequent points at which users leave the site. Some of the most popular analytics tools come from Google (www.google.com/analytics), WebTrends (www.webtrends.com), and Omniture (www.omniture.com/en/products/web_analytics). You can fill all three of these roles: information architect, interaction designer, and user researcher. Can you juggle all three, or will you bite off more than you can chew? This depends in part on the size and time frame of the project, but the nature of the project also affects how involved each role is likely to be. Table 2.1 describes how UX design roles can vary by project type.
Browse Should you become a UX design champion? These articles offer approaches that may 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://www .hesketh.com/publications/user_experience.pdf louisrosenfeld.com/home/bloug_archive/000131.html
24
CHAPTER 2: THE PROJECT ECOSYSTEM
TABLE 2.1
Overall responsibilities of the UX design role
information architect
BRAND PRESENCE
MARKETING CAMPAIGN
CONTENTS SOURCE
TASK-ORIENTED APPLICATION
Average bet.
Low engagement for smaller sites (for example, a single landing page). Medium engagement when working with larger microsites.
Very high stakes. Content resources require an information architecture with an appropriate balance of structure and flexibility to provide users with a solid foundation and allow for planned growth.
Medium to high involvement, mainly focused on creating the navigation framework, unless there are larger areas of content that need to be referenced during some workflows.
Low engagement for smaller sites, medium to high engagement for larger microsites or advergames (sponsored online games designed to create play and excitement).
Medium to high involvement.
Very high stakes. This type of project often requires the heaviest work, as the outcomes of the interaction design (e.g., user process flows and wireframes) are critical to communicating requirements visually.
Due to the often temporary nature of campaigns, user involvement is often low. More permanent solutions can use similar research as brand presence websites. It's also common to use analytics tools to map two or more variations of a given page to see which one leads to the most conversions. This is known as A/B testing.
Field research, such as contextual research, can help the team understand how different users currently interact with information.
The greater the content challenge, the more likely it is that the project will become a content resource.
Interaction design
Average bet. The greater the number of tasks, the more the project resembles a task-based application.
User researcher involvement depends on budget and access to users. Here are common techniques for each project type. See Chapter 6 for more information on each of these techniques.
Research efforts can focus on understanding the needs of priority user groups (through surveys or interviews) or through design research that tests the effectiveness of a particular visual design in conveying the right brand message.
Search, tagging, and filtering capabilities cross the line between information architecture and interaction design. Content sources can also have workflows where content is created and managed.
Card sorting is a great way to understand how your users group information and share common patterns and mental models.
Field research, such as contextual research, can be performed to understand tasks as users complete them. However, the most widely used and best understood technique for involving users in the design of a task-based application is usability testing.
Once a framework has been established, the structure can be validated through usability testing.
CHOOSE YOUR HATS
25
Other roles you may play or need. Multiple roles are not typically covered by the UX Designer role, but their responsibilities often overlap with the UX Designer role - especially if you're working on a project where no one officially has that role and you have skills to bring to the table. The most common overlapping roles are: brand strategist or manager, business analyst, content strategist, copywriter, visual designer, front-end developer
The following sections describe each of these roles and how they can vary depending on the type of website being designed. Brand Strategist and Brand Manager A brand strategist is responsible for building a relationship with key markets by defining and consistently presenting the company's brand elements, which can include anything from brand values (for example, "responsiveness") to text and message specification guidelines for logo treatments , colors and layout. This role often includes creating or presenting brand guidelines and understanding how they apply to different projects. It can also be about knowing or defining the audiences that are important to the project you are working on. Most of the time, you probably work with a brand strategist, but don't take responsibility. The brand manager does not necessarily set the guidelines, but is responsible for ensuring that they are followed correctly throughout the project. This responsibility can be given to the UX designer or visual designer of a project. If the company's brand attributes, values and guidelines are already well defined and the website is expected to follow them, your role as the project's brand steward is primarily to ensure that the outcome is in line with those guidelines. Your point of contact outside the project is most likely one
26
CHAPTER 2: THE PROJECT ECOSYSTEM
Member of the marketing department available on a consulting or assessment basis, but not full time on the team. The role of the brand manager can be more active if the site needs to expand the brand in some way, such as targeting a new market. It's most difficult when creating an entirely new brand presence or when the company is making significant changes to its brand and effectively rebranding itself. For example, CellularOne completely rebranded itself as Cingular, a major effort for an established company. In this situation, you either need to be very experienced in brand development or build a clear and close relationship with the person in the company who has this experience. Key questions to help you understand the expectations of a brand role are these: Are there existing brand guidelines? If so, how exactly should they be observed in this project? Who is responsible for establishing or maintaining the brand message or brand?
Content look and feel and tone (e.g. casual or professional)? Are new target groups being addressed that were previously not addressed?
brand definitions? If so, who is responsible for ensuring that the brand guidelines remain appropriate for these target groups? Will there be any naming or renaming activity? If yes, how should I proceed?
concerned? (An example is coming up with a name for a new tool that is highly advertised.) For projects that do not have a major potential impact on customer brand perception, such as B. developing an internal application, involving the brand manager , can only be an occasional check-in to ensure the brand is well represented. Business Analyst A business analyst (also known 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. Act. He or she is also the primary owner of the detailed requirements documentation, such as B. Functional Specifications and Use Cases.
CHOOSE YOUR HATS
27
The Business Analyst or Product Manager role may not exist in your project at all, or it may be one of the most important roles in the design process. Task-based applications and content sources often play such a role; Brand awareness projects and marketing campaigns may not. A task-based application will most likely need this role. The more functions and the more complex the project, the greater the need for a dedicated person and for the documentation of the functionality. While a business analyst is not typically considered a member of the UX team, small UX teams are often asked to fill the role. Therefore, it is important to understand where these responsibilities lie. Business analysts capture business requirements and act as a liaison between the technology team and key business stakeholders. When a business analyst is involved in a project, that person and the interaction designer are often aware. When it comes to the same role, the responsible person may have a lot of documentation to manage! To understand expectations in this area, ask who is responsible for outlining the scope of the project, facilitating discussion of requirements, and documenting requirements throughout the project. For small or featureless projects, the project manager sometimes takes on this responsibility. Either way, even if you're not, you still know who to stick around to make sure your results are in sync. Content Strategist A content strategist is responsible for understanding the business and user needs of content across media (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating the workflow and development of new content. Content efforts are often underestimated. A client may have a large amount of content that is great in a medium (print brochures or videos, for example), but that content may not be right for the project you are working on. Also, there are sometimes unspoken expectations that people within the customer organization will generate content - expectations that may come as a surprise to these people when it comes time to fill your product with descriptions, news, and help topics! When it comes to high quality content
28
CHAPTER 2: THE PROJECT ECOSYSTEM
To determine the main business driver in your project, make sure you know who is responsible for: setting content policies for the new product (content type,
sound, amount). Based on that, assess the suitability of existing content
guidelines. Development of new content. This varies depending on the general project type. For
For task-based applications, it may contain instructional text, error messages, and help topics. Content sources can be articles, news, and blog posts. Act as a liaison between stakeholders and the technical team to communicate this
Limits and possibilities of the content management system. Defining different content types and their respective metadata (the
information that ultimately makes searching and cross-referencing more effective). Content migration planning, including template creation
for different content types and ensure that content is properly tagged and loaded when pushed into the website's content management system. (Again, the amount of effort required is often underestimated.) Copywriter A copywriter is responsible for writing the text on the website that shapes the overall experience. In some cases, this instance remains fairly unchanged from day to day. It usually contains site and page introductions or on-page instructions. A copywriter may also be involved in the ongoing creation of dynamic content, such as news or copy for marketing campaigns. Copywriting is one of those gray areas often reserved for a UX designer, especially when creating wireframes (see Chapter 11). You can start by inserting sample text as copy placeholders, such as a site description or on-page instructions, but at some point someone will have to fill it in with final text that users will see — and because many projects don't, that is not the case, if you are a dedicated copywriter this job may fall to you by default. You are less likely to be asked to fill the copywriter role for high profile areas of brand awareness websites or marketing campaigns. in such situations
CHOOSE YOUR HATS
29
Every word can be scrutinized. However, 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 area, you can inherit (or do) write command. are owned by the developer by default). Ask ahead of time if a copywriter is available, and come back with the wireframing if none is found. If the task falls to you, make sure you factor that effort into planning your activities throughout the project. And be warned: this is a responsibility that is often overlooked or underestimated. Visual Designer A visual designer is responsible for the elements of the website or application that the user sees. This includes creating a look and feel that creates an emotional connection with the user and is in line with brand guidelines. For example, a banking site must often appear stable, reliable and accessible. The visual design can convey this certainty through visual elements such as colors and images. This promise is then fulfilled (or broken) by the interaction design of the website and other points of contact with the company (for example, a call center). Let's face it: many people call themselves visual designers, web designers, or graphic designers, and many websites have poor or passable visual design. There is a big difference between creating an effective, compelling and emotional visual design and just getting through it. Sometimes just making ends meet is enough to meet project goals, and sometimes it leads to project frustration and delays when the project sponsor is dissatisfied or early adopters are not engaged in the design. On the other hand, it is also easy to focus too much on the visual design, compromising the usability of the design. If you are being asked to fill this role and you have doubts about your ability to create the right impact for the customer, take a look at the company's current website and the websites or products that visually support the adoring customers to assess how they are satisfied with it. Visual designers often play a very central role in brand presence projects and marketing campaigns and are primarily responsible for effectively communicating the company's brand.
30
CHAPTER 2: THE PROJECT ECOSYSTEM
For content source projects, they can focus on creating content templates that can be applied to many pages (for example, a template for an article). For task-based applications, they can provide a style guide that can be applied to common interaction elements such as navigation panels and tools (which require a high degree of collaboration with the interaction designer). Front-end developer A front-end developer is responsible for building the technical structure behind the page designs and flows, as well as interactive elements within the website such as B. Rollover menus, expandable content areas, and interactions with multimedia elements such as videos . Technologies such as XHTML, CSS, Flash, JavaScript, Ajax, and Silverlight are commonly used in this work. Front-end development focuses on the elements of the website that directly reference what the user sees, as opposed to the back-end systems that provide the underlying platform (for example, databases, content management systems, and the code needed to run the website to make). functionality behind complex functions). When you or members of your team take on the role of a front-end developer, it's important to work closely with the rest of the development team to understand expectations and responsibilities. Other important questions include what back-end systems to integrate with, what method to use to generate HTML, what flexibility in page structure is needed to accommodate custom "skins", and what are the expectations for technologies such as Flash. If a prototype is planned (see Chapter 12), ask who is responsible for developing the prototype and what functionality is expected. A prototype designed only to convey capabilities can be created quickly in an application like Flash, but a fully functional prototype that needs to retrieve real data (for example, the account information a user just entered into a form) should be in the near future. be made in the future working with members of the back-end development team. Are you afraid to take on all these roles? Unless you're working on a very small project - or in a very small company - you most likely won't be taking on all the tasks. The key is to understand which of the roles you can and want to fill, if necessary, for the specific project you are working on. Incidentally, you can get the support you need in the project team by building a network within the client's company or by referring additional people to meet the need. Let's take a moment to talk about how you can do this.
CHOOSE YOUR HATS
31
Building a user advocacy network For those areas you're not sure you can or want to address, it's time to get help. You can achieve this in three ways: Recommend adding additional team members when needed
clear enough. Learn about the key areas where there are gaps - when the new responsibility
The tasks are manageable and you have the time to dedicate yourself to them. Build a support network within the company that will support you in critical situations.
Let's take a closer look at how to build a support network. Most likely, there are some key resources in other departments of the company that can help you succeed. You need to estimate how much time you can expect from these people, because on projects that are mainly in the hands of one department, it can be difficult to ask for time from the outside. If you don't want to demand a lot of time from them from the start, just ask if you can work with them (or consult with them) to get the best outcome for the key responsibilities of this role. Once you're a partner, you'll have a better understanding of how much interaction you need and whether you need to make a more formal request for his or her time. Every company has a different structure and different names for their divisions, but here are some common places to look for partners: For the brand strategist role, ask if anyone is in marketing
Department that can serve as your point of contact. This can also be a resource for visual designers and content strategists. Visual design and content strategy partners can also be found
B. in program or product management or in the research and development, operations or corporate strategy department, where you will often find business analysts and product managers. The IT or engineering department is often the best choice for the frontend
Developers and others who can help you access and understand website analytics tools.
32
CHAPTER 2: THE PROJECT ECOSYSTEM
If you have recently been hired by a new company and expect to work in different departments, it is best to identify key people who are potential partners from the start and schedule an interview with them to understand their roles and experience. It opens up a network that you can often rely on for a long time and gives you the opportunity to explain your tasks (and user experience design in general). You can also ask a nice question at the end of the interview: "Who else do you think I should talk to?" The answer can help you find people who may not be recognizable to your main project manager or customer contact. Even if you've been with a company for a while, you can still create an interview schedule like this. In this situation, it's best to tie it to a specific milestone (such as starting a new project) or business goal that has some urgency to ensure high engagement. Make sure your manager knows what you're doing so it doesn't seem like you're passing him or her by. Good communication is key to understanding role expectations and building trust. Another key to building trust within the company is understanding the culture, the often unspoken expectations about how a company operates, created for example by previous project experiences (positive or negative), the etiquette related to organizational hierarchy, and an acceptable work logistics (e.g. working from home).
Understand the corporate culture. Culture is a bit like dropping an Alka-Seltzer in a glass - you can't see it, but somehow it makes a difference. —Hans Magnus Enzensberger
A company's culture may not be consistent across regions, divisions, or departments, but you can usually identify key characteristics that impact you and the project or projects you undertake. Below are some aspects to consider when planning projects and dealing with potentially difficult political situations.
UNDERSTAND THE BUSINESS CULTURE
33
History We all know the quote that those who can't remember the past are doomed to repeat it, and project work is no exception. Understanding how a project or team ended up in its current state of emergency can help you better understand the challenges you may face during the project. Let's discuss some questions you can ask to understand the flow that can affect a project. While some of the answers to these questions may seem unclear, remember that something has created the need to involve you in the project so that a project can have a troubled history and still be successful. You may be an important part of this success! However, if many of the issues discussed below apply to you and you feel you can't fix them, that could be a red flag. If so, consider an overall assessment of whether this project has a chance of success. What is an example of a previous project that seems to have been considered?
It was a success, and what seems to have contributed to it? What previous project seems to have failed (or been particularly painful) and why did it fail? Asking these questions (either directly or in a more subtle, conversational way) can help you understand a number of things: how the person answering defines success, potential risks to your project, and any biases or expectations that affect that project , as well as approaches that have worked well. Did the company work with and release a designer?
project or team? If so, try to find out what didn't work and to what extent the customer expects a different approach than your approach. Being able to ask this question to more than one person in the company will help you understand unspoken expectations. If you get two very different answers, it could mean that the designer's responsibilities are not well defined and you need to make sure that your responsibilities are communicated a lot throughout the project. Did the project team work on the project (or related materials)?
It seems to be taking an unusually long time to finish?
34
CHAPTER 2: THE PROJECT ECOSYSTEM
If so, it could be a sign that key customer stakeholders are not on the same wavelength or are not included at the right time, which can lead to multiple delays, course changes, or wasted time due to multiple iterations. It can also mean that there is no clear leader, someone who can say "no" (or at least prioritize effectively) to keep the focus on business goals. If you can influence communication about the project, it may be helpful to create participation guidelines to help move the project forward. Did the company create designs without prior input?
a UX designer? That can be a mixed blessing. On the one hand, you are dealing with a team that understands the need for design and has tried to bridge the gap. On the other hand, you may be presented with a design that you believe doesn't meet the project's user experience goals. This can be a tricky situation. It is often best to approach the creator of these themes in the tone of a respectful mentor or helpful advisor, highlighting the good aspects of the design first, then discussing the user experience goals and discussing how this could be improved with a different approach are being reached. The creator is likely a valuable member of your support network. So it's important not to burn down the bridge here, but to redefine your roles in a collaborative way to keep the buzz alive. Does the main sponsor or project manager seem particularly concerned?
about the project? There are many reasons for this, especially when some of the above factors come into play. Fears can also stem from market pressures, which you should understand. For example, has the company's share price fallen? Has a particular competitor made alarming progress lately? Is the company in the red? Again, these situations don't necessarily mean you shouldn't take on the project. After all, in such situations a project is often financed in the first place. However, if you are very concerned about the company not being able to pay its bills, you should consider this risk.
UNDERSTAND THE BUSINESS CULTURE
35
Hierarchy Geert Hofstede has an excellent model describing cultural differences, which he calls 'cultural dimensions', which often influence the way people interact and communicate with each other. One is the concept of power distance. It is about the extent to which members of a society (in our case a company) understand and accept the distance between people at 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 high power distance and its employees may be more hierarchically focused. If the company encourages the democratic exchange of ideas and the challenge of vision, there can be relatively little power distance.
Power distance is "...the degree to which the less powerful members of organizations and institutions (such as the family) accept and expect power to be distributed unequally." This represents inequality (more versus less) but is managed from the bottom up, not defined from above. It suggests that the level of inequality in a society is endorsed by supporters and leaders alike.” Geert Hofstede Cultural Dimensions www.geert-hofstede.com
Neither extreme can be considered good or bad in itself, although in the United States in general most workers seem to prefer the appearance of low power distance in their workplace. Interestingly, this is not necessarily an indicator of how successful a company is. Apple has a relatively large power distance (given the aura around Steve Jobs) and Google has a relatively small power distance as part of their culture, but both companies are known as innovation leaders. It is important to note that the power distance within the client organization affects how you successfully navigate the political waters during the project. This aspect becomes especially important at key moments in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as release times (discussed in Chapter 4). When you work at a company with a high power distance, bring something extra
36
CHAPTER 2: THE PROJECT ECOSYSTEM
Take the time to understand reporting relationships before scheduling meetings such as interviews and stakeholder reviews, and consider involving more middle management in your communications.
Logistics In addition to the broader aspects of culture above, it is also helpful to understand some elements that are more logistical in nature so that you can better integrate with current practices or make thoughtful changes. For example, it is helpful to understand the general pace expected within the organization, including major release dates or deadlines that affect the project (building a software application on an annual release schedule would likely be at a different pace than a microsite that has a seasonal campaign). For example). Is your team expected to work long hours to meet looming deadlines? It's also easy to understand the expectations of working remotely compared to working on location. If a lot of time on site is expected, plan travel and make resources available on site. If remote working is acceptable (or encouraged, which is common when working with global companies), it is important to understand the methods and tools of communication. For example, is the use of instant messaging applications acceptable? Which web conferencing tools are used? Are there methods of involving international stakeholders that have proven successful in the past? It is also interesting to understand the "paper culture" in a company. Some companies prefer electronic media for most things. In this case, a good projector and a consistent Ethernet connection are important. Others are very paper-oriented. In this case, make sure you bring enough copies to a meeting to make it productive. You may want to change the culture of the project if you think another way is more effective. But it's good to know that you're encouraging people to change so you can make the transition smooth and possibly understand why a particular approach isn't working as expected.
UNDERSTAND THE BUSINESS CULTURE
37
Putting It All Together Now that you've explored the project's terrain, it's time to better understand the project ecosystem: the environment you'll be working in (the organizational culture), the general type of work you'll all be involved in (e.g. the types of websites you design) and the people you interact with (including their roles and responsibilities). This information will be helpful as you outline your role in the project and prepare to get down to business in earnest. If you work as a freelancer or subcontractor, this provides a basis for writing a proposal that covers your work on the project (see next chapter on UX proposals). If you work as a member of a larger team and are not directly involved in the proposal preparation, you can bring your new knowledge to the project launch - your team's first meeting. See the online chapter A Quick Guide to Meetings for basic guidelines for running a good meeting. If you want to jump right into the questions to ask at the beginning of the project, see Chapter 4, Project Goals. and rapprochement.”
38
CHAPTER 2: THE PROJECT ECOSYSTEM
3
Suggestions for Consultants and Freelancers A guide for professionals who also run their own businesses Managing projects and client expectations can be hard enough, but if you don't have an agreement, you can incur losses on every project you take on. Proposals and SOWs are important to protect your business - and yourself - from financial and legal trouble. After accepting a project and shaking hands with them, make sure you take the right amount of time to draft an agreement that spells out the terms of your relationship and the payment schedule for your client. Russ Unger
39
Suggestions There's an old saying, "No good deed goes unpunished," and the same goes for winning a project in general - the high-fives and feel-good moments are quickly replaced by "Oh crap!" It's time to write the proposal!" The biggest proposal writing challenge is writing your very first proposal. It's almost impossible to know where to start if you've never had to write one yourself, and that's where this chapter should help you. Each type of project you come across has different flavors that will keep you on your toes when it comes time to create the proposal. Fortunately, there is something of a core that all proposals have in common and can be reused from project to project. (See Chapter 2 for a detailed discussion of project types.) When should you write a proposal? Always. Why should you write a proposal? In the history of working on projects, people have always found themselves in the most uncomfortable situations when there was no agreement between the client and the provider. You might be tempted to skip this step when you're making the first connection with a prospect and everything seems to be going well. Even if you clearly understand the customer's needs and can articulate them in a way they understand, you're not quite ready to get started. In fact, this is exactly the point where you need to slow down and take a deep breath. Instead of going straight to work, take the time to define your professional relationship and the rules for working with your new client. Jean Marc Favreau of the Washington D.C. law firm of Peer, Gan & Gisler, LLP says: “Too often, contractors and their clients think there is a disagreement early in their relationship, when in reality ambiguities are lurking. While it's nearly impossible to prepare for every possible eventuality, a comprehensive written contract is your best defense and the smartest way to make sure you don't end up in court arguing over the terms of your relationship later. The more clearly you define the terms and parameters of your relationship with a client in advance in a written contract, the less likely you are to argue about the obligations of both parties later on.
40
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
New projects and new people are exciting. There is often a desire not to ruin the deal by proposing marriage, but as with any relationship, the honeymoon feeling can eventually wear off. Promises can be broken on either side of the relationship. A customer may not provide you with timely access to content. (I know this stuff is almost unheard of, but believe it or not, it happens! That's sarcasm in case you missed it.) Funds that were once available for the project can be shifted elsewhere - and then to you, whoever If someone is busy with work, maybe he is holding the bag. Organizations are also aware of the risks they take when working with third-party vendors, especially if they are very small businesses or independent contractors. Well-written suggestions give customers a sense of stability and protection, which can help alleviate many of the problems that may arise. A suggestion also allows you to define conditions that protect both parties in case something changes. If the client doesn't give you timely access to their resources, your schedule may falter. You must make them aware of their obligations to the success of the project. If a client loses money and leaves the project - and you don't have a quote or other form of contract - you risk not getting paid for work that has already been completed. The point should be crystal clear: always write a proposal.
Creating the Proposal After you receive the project, it's time to finalize the proposal. The faster a proposal is approved and signed, the faster you can get to work and, most importantly, the faster you can get paid for the work. The core parts of a good proposal are: title page, revision history, project overview, project approach
MAKE THE PROPOSAL
41
Scope of work Assumptions Deliverables Ownership and rights Additional costs and fees Project prices Payment schedule Confirmation and release
Let's take a closer look at each part of the proposal.
Title Page The title page is the simple page that introduces your document. Front pages are interesting: there are a number of ways to design them stylistically and informatively. How you do it is up to you. A typical front page consists of the following elements: Name of the client's company Company logo of the client (if you have permission to use it) Title of the project Document type (proposal) Version of the proposal Submission date Your company name Authors of the proposal Project reference number Cost confidentiality
Include everything in your initial quote except the client's company logo, cost, and (possibly) the project reference number. Why not put these elements on the front page?
42
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
Your customer knows who he is. It probably isn't worth investing the time and effort to get permission to use the company logo, nor is it worth it if you accidentally misuse it. Costs are best placed after you have identified the different parts of the project in the text and the cost information has been properly incorporated into the payment schedule. The project reference number is something to keep in mind. Many companies will not use it at all; However, some government agencies are known to rely on this particular point. If it's not on your front page, your proposal may be rejected.
Figure 3.1 Example title page of a proposal
The (fictitious) customer logo is used in figure 3.1. In the event that permission has not been granted or a relationship has not been established, it is best not to display the logo of the client company.
MAKE THE PROPOSAL
43
Revision history Revision history is a separate section of the proposal and is used to track how many times you've updated the proposal since it was originally created. In general, it is best to include the version number, date, author, and any comments related to the version, e.g. B. What has changed to give the reader context about the changes (Table 3.1). TABLE 3.1 REVISION
Sample revision history table SECTION
DESCRIPTION
EDITOR
FACTS
The real document
REG
January 8, 2009
assumptions
Updated to reflect software requirements
REG
11.01.09
1,0 1,1
Occasionally, customers sign an offer and then ask you for further revisions. If you decide to continue with the client and make these changes, you should take the opportunity to upgrade your document from version 1.x to 2.0. When a customer agrees to an offer and both parties agree on the terms, you're essentially ready to go. So if additional changes are requested, please consider them very carefully. This ensures that your costs remain correct and that there is a clear understanding on both sides of what changes will be implemented and at what stage the project will be restarted (if necessary). In the revision history, always provide a reason why the revision is an entirely new version.
Project Overview In the Overview section, you will find a description in your own words of the project you will be working on. This description should give your customer a clear idea of what you think their product entails, as well as an explanation of what to expect in the rest of the offering. Here's an example of starting a statement: [Client Company Name] wants to create a new online presence on the web. This web presence allows customers of [customer company name] to research and purchase products online, as well as other services and benefits available through the company. The goals of the online website are…
44
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
You should be able to give a good overview in a paragraph or two and explain in detail what the client can expect from you. It is a good idea to conclude the overview with a reasoned explanation of your recommendations and proposed approach to completing the project: This proposal outlines [your company name]'s recommendations and [name of company's] design and development approach customer company] described in detail. s online website. Given the deadline of [deadline date], it is suggested that…
Project approach The project approach depends on the type of project you are carrying out. This is your chance to let your client know how you want to work with them on the project. You can define your rules of engagement and set expectations for the work ahead. Many individuals and companies operate in very similar ways but use different names or clever acronyms to fit their overall branding. A mythological methodology was developed long ago to show it to (potential) customers and has found its way into many proposals. The process is called "The PURITE Process™" (pronounced "purity") and as we tell you this a mythological being has just died a little inside, so please read this as fiction. The name of the process is a bit cheesy and obviously the process is a bit incomplete. Post-launch analysis is omitted from this methodology (an omission), but should of course be included for all customers. Without further ado, here's the PURITE approach: [your company name] has identified a standard process for project success with our clients. While each of these phases may not apply to [Project Title], the general process is defined as follows: The PURITE Process™ is [your company name]'s internal methodology to ensure the success of all initiatives across the board. By using PURITE, [your company name] has a proven policy of working closely with customers and users/target groups to reliably meet and exceed delivery expectations. P - Get ready. We dedicate part of each initiative to understanding your industry and your competitors and their business processes to be as informed as possible before setting requirements. You see, we work closely with your subject matter experts and/or users to define the requirements for correctly building the project.
MAKE THE PROPOSAL
45
R - Render. In the rendering phase we create and develop all parts of the project/product. In our experience, each development phase requires a lot of concentrated and focused work, but also timely, open communication with your team(s). It also requires that we... I - Repeat. The iteration phase is repeated throughout the life cycle of the project. We act as quickly as possible to bring the project to life, and this often requires creating multiple iterations on short timescales. This requires immediate and timely involvement from you and your dedicated resources. The end result is the product you specified and helped create. T-Test. We test every project during our rendering phase; However, we also need extra eyes - from our own testing team and from your specific user group/target group for targeted testing. This extra round of testing helps ensure that as few bricks as possible are left over to deliver a project that has been thoroughly evaluated on multiple levels. E - Activate. After successful completion of the five previous phases and your signed agreement, we activate the solution and put it into operation. The PURITE Process™ does not end here. After the completion of the project, we regularly communicate with our customers. We continue to measure your satisfaction, understand your changing goals or project improvements and support you in determining the best approach for the future development of your project.
Feel free to use as little or as much as is appropriate or helpful to you. Also, the mythological author who created the process doesn't mind if you don't credit the source. The definition of your process can be as detailed as above or as simple as: plan, define, develop, expand. Plan the overall strategy. Define the detailed project requirements. Develop, test, refine and launch the work product. Improve the project by recommending improvements based on information gathered during development, testing, and post-launch
Once you've defined your process, you'll have the opportunity to detail the different efforts that go into each stage of your approach and explain what each of those efforts means to you and your client. The length of the approach portion of your proposal depends on the project, your process, and the activities that take place at each step of your process. However, try to limit the scope to a maximum of two or three pages
46
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
Make sure you only provide the deliverables you can deliver to your client - to avoid further document updates or re-checking of the project price.
Scope of Work In the "Scope of Work" section, you define the division of labor for the project. That is, you determine which parts of the project you are responsible for and which the customer is responsible for. Read that again. Think about it for a second. Let it sink in. Here we go. That's right. This is the part of the offer where you tell the customer in writing that we will do this and you will. When the client later signs your proposal, he agrees to this agreement and you have written documentation to help you in case of misunderstandings. The point here is to clearly establish who is responsible for which aspects of the project and which aspects of the project are included in your proposal and at the price you estimate. If you can't find another really compelling reason to write a proposal, this should be reason enough. Here is a very brief example of a scope of work: We have been asked by [Client Company Name] to provide all services necessary to create [Project Type]. [your company name] focuses exclusively on the [aspects of user experience design] of [customer company name]. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] according to the project plan. [Customer Company Name] provides all necessary resources to use in the project, including fonts, color schemes, branding standards, etc.
Assumptions The Assumptions section of the proposal is a good place to state what your client needs to ensure your success, without room for discussion. That is, you assume that you have access to these things and will communicate them to the client, or make them available to make the project a success.
MAKE THE PROPOSAL
47
What you call assumptions in this section are actually expectations. It's just much more polite to accept. You can create as many project plans as you want. However, if neither you nor the client commits to meeting milestones and goals, then both parties assume that the project is bound to fail. The general assumption is that resources and assets and timely (translation: fast, immediate) access to both are expected. Here is an example of writing assumptions: Assumptions It is necessary that [customer company name] provide the following assets and resources. The inability to deliver these assets and resources in a timely and complete manner may contribute to the failure or delay of this project. The following assets and resources are expected: Timely access to all required personnel of [customer company name]. Timely access to all required [project] assets as-is, including all source files when available. Content as needed and including but not limited to copies, images, audio, etc. for any aspect of [Project].
Deliverables are the work products you create and hand over to the customer. In this section you have the opportunity to explain in detail to the client what kind of work product he can expect from you during the course of the project. It is recommended that you treat the status reports separately, closer to the end of the project, but feel free to add them to this part of the project. Provide descriptions of each work product you include, even if the work product has not been created. That may seem like overkill or have the potential to open the "I've read about [available type] offer, but I don't see it here" worms, but a little word might suffice. Deliverables [your company name] offers a variety of deliverables over the course of a project. For [customer company name] we have identified the following services:
48
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
Creative briefing The creative briefing is the first step of the project. This document helps us to quickly and properly make a general overview of the project. The purpose of the creative brief is to clarify the goals and needs of the users and to define any special resources and/or constraints related to the project. And so forth…
Ownership and rights It is important to consider the extent to which you allow your client to use the work product you create. These rights can be defined in many different ways, but most of your work falls into two categories: agency work, licensed work
Projects involving contingent labor (called "indentured labor" in the legal world) are assumed to be created and copyrighted by the party paying for the work, rather than the party doing the work and responsible for the performance of the actual work. This means that when you work on a commissioned project, you have no rights whatsoever to the work and anything you create in connection with the project is the property of the client. This situation is difficult for many companies and individuals to deal with: it often means that there is no downstream "maintenance" (with additional income) as clients can choose to maintain the project themselves once it is completed. Don't be put off by a project where a client enforces the condition; It's not unusual. Placing procurement processes in the context of full-time employment at a company is quite normal for an employer-employee relationship. It's also an opportunity to look at your pricing model - many projects are billed at a slightly higher rate to make up for potentially lost revenue in the future. Keep in mind that it all depends on the relationship you have with your customer and how you choose to do business. Time and experience will help you make the right decision for the type of work you do and the pricing models you choose. Licensed work projects allow you to retain copyright in the work, but grant other parties the right to copy and/or distribute it. You can include as many terms as you want in the license agreement. You most likely make the proposal
49
Benefit from licensing your work by retaining ownership of all source material for your work and providing your clients with only limited-use work products (e.g., PDFs instead of original, editable Word, Visio, Axure, OmniGraffle, or other documents). ). You can license your work in many different ways, including licensing work for unmodified, non-commercial use, or any number of other ways that are appropriate for your situation. Creative Commons (http://creativecommons.org/about/licenses) provides easy-to-understand explanations of the different types of licenses you might use, but this is only a small part of the licensing world. If you find yourself in a situation where you encounter very detailed and specific needs, it is always best to contact a copyright attorney to help you develop the best possible solution.
Additional costs and fees It is important for your client to understand whether the project prices you offer them take into account external resources (or not). For example, some projects may require you to purchase stock photos from a supplier. You can purchase the artwork (with appropriate usage rights) and charge it as part of your fee, or you can clearly identify the purchase of the artwork as an additional cost that will be passed on to your customer. You can also offer services that you want your customers to know about - this is a good opportunity to promote those services. Here is an example of how additional charges and fees are handled: Additional Charges and Fees If external resources are required (such as content, images, fonts, etc.), they must be identified, approved by, and billed. In addition, [your company name] can offer hosting services to our customers with little effort. We offer hosting services, including configurable, web-based email, from just $25 per month, plus a $25 setup fee. In the event that [name of customer's company] wishes to purchase a "maintenance package", [name of your company] will work to put together a package that is acceptable and beneficial to both parties.
50
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
Project Pricing: Once you've documented the details of how you'll perform the work on the project, it's a good idea to communicate the cost to the client. How you arrive at the price is largely up to you, but here's a tip: Estimate how long you think the project will take to complete - including a certain number of revisions, and estimate a reasonable amount of time for that project management about 25 percent; Then determine the hourly rate you want to charge and calculate everything. There are several formulas to help you with this, such as: B. Applying difficulty levels to each part of the project to help you determine a range of costs to offer to your client. In most cases, experience is the key to properly estimating your projects – from a time and material perspective. How do you determine your billing rate? To compare, research what others are charging by looking up contractor salary surveys and rates. For example, organizations such as the Information Architecture Institute (www.iainstitute.org), AIGA (www.aiga.com), Coroflot (www.coroflot.com), and talent agency Aquent (www.aquent.com) conduct payroll and valuation surveys of contractors. You can get a good idea of the rates you might charge by considering your experience, the rates of others in your market, and what you think is fair. Remember that you can lower your rate at any time. It's a lot harder to ask your customer for more money when they've seen numbers on a page! There are many different ways to structure pricing for your project. Depending on the nature of your project, you may want or need to provide multiple estimates that allow for different pricing options. For example, suppose you offer a customer two options: a static HTML website and one with a content management system (CMS) that enables dynamic content (which the customer could then manage without special resources). You can formulate the project estimates as follows: Project Estimate [name of your company] has proposed multiple cost estimates for [customer/company name] to provide the best possible options for your immediate and/or future needs. [your company name] assumes that all content is provided by [customer company name]. In the event that [your company name] is hired to provide content services, the estimates will need to be redefined.
MAKE THE PROPOSAL
51
[Your company name] estimates provide flexibility in terms of costs and needs. The estimates are as follows: Estimate 1 [your company name] estimates that the [project] for [customer company name] without interactive content…
Remember there is no wrong way to put together your project estimate unless you end up in a negative cash flow position!
Payment Schedule There is a myth that all freelance projects are paid 50 percent upfront before work begins and 50 percent upon completion when the project ends. This myth must be dispelled - now! This is not a way of doing business and it is not a way to guarantee a timely and steady income while the work gets done. You don't want to put yourself in a position to make change after change for one client just because you want to complete the project and get paid instead of completing a change order process. You can rate projects in a variety of ways, from submitting invoices within a specific time frame to milestone-based payments. A more sensible approach is to base your projects on a recurring payment schedule with regular, detailed invoices. This approach should also give clients a clear insight into what has already been achieved and what work is still in the project. The following example is one way to structure payments for your work: Payment Plan [name of your company] A typical payment plan requires an upfront payment of XX% of the project's estimated total price to be made before it begins. [your company name] must submit invoices on the 1st and 15th of each month; Payment must be made in full within 14 days. After completion of the project, [your company name] will deliver all work products to [client company name]. If the materials are satisfactorily approved, [your company name] will reimburse the overpayment from the advance, or [your company name] will provide a final statement for amounts not covered by the advance. Note: If [Project] is suspended for a period of more than 14 days and no progress is made, [your company name] must submit a final invoice for all fees not covered by the reservation and will be entitled plus initial refusal in the event of a reopening of the project.
52
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
While not required, it is helpful to include a note on how the project will be handled if it is suspended for an extended period of time. This determination can help keep your project on track and moving forward - and it will give you a talking point with your clients. If you don't have any extra work for them to do for a long time, you want to be able to look ahead for work to fill the gap.
Recognition and approval While it is very important to ensure that a proposal has been submitted, that alone is not enough. The proposal doesn't really mean much until the right person at your client company approves and signs it. It is important to ensure that everyone has a clear understanding of what is to come and how much is expected from both sides. Equally important, you protect yourself from the "iteration highway" and reduce the risk of a customer engaging you in "feature creep". H. Constantly asking for "one more thing" to include. Unsubscribing is quite simple and straightforward. After you create the proposal document, you give your client a receipt and approval that approves the agreement between your two companies. Always prepare two copies - one for each party - and make sure both copies are signed. Here is an example of an acknowledgment you can use: acknowledgment This offer has been fully confirmed and accepted by [customer company name]. This offer must be signed and dated by an authorized representative of [customer company name] to be valid. Alternatively, in lieu of such signed document, a signed purchase order relating to this offering shall be deemed acceptance (provided, however, that any pre-printed terms on such purchase order shall be deemed 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 summarizes and supersedes all prior agreements, discussions, negotiations, commitments, writings or understandings, whether oral or written. This includes, but is not limited to, any representations in sales literature, brochures or other written descriptions or promotional materials and constitutes the complete and exclusive representation of the terms of the agreement between the parties. Each party acknowledges and agrees that in the performance of this Proposal it has not relied upon, and expressly disclaims any reliance upon, any representation or statement not contained herein or in the Agreement.
MAKE THE PROPOSAL
53
Accepted by the Authorized Representatives of: [your company name]
[customer company name]
Von: ________________________________
Von: ________________________________
Name: _____________________________
Name:_____________________________
Title: ________________________________
Title: _____________________________
Datum: ____________________________
Datum: ____________________________
Make all checks payable to: [your company name]
Statement of Work (SOW) is a general definition of your project goals, which you should be able to summarize in a 2-3 page document (no cover page). The statement of work is usually written before delving into the detailed requirements. However, depending on your client's needs and your project, you may choose to create a hybrid document that best suits your needs. In general, SOWs should be used to build consensus early on between your team and your client's stakeholders. The SOW defines the project's inputs and outputs, as well as its assumptions and constraints. At this point, it's not uncommon for clients to ask you to provide an estimate of the work you'll be doing for them. It can be a bit risky to answer at this point. It is recommended that you do your best to avoid details or obligations without defining the details. It is simply not possible to know how much a project will cost until you have written the proposal and/or requirements document. However, you need to make a judgment call at this point. If you are working on a project, such as a simple website and you have already successfully completed several similar projects and/or previously worked with the same client, you have some wiggle room. Remember that caution is always better than an awkward situation later in the project. A job summary should be approximately two to three pages long and contain at least the following:
54
CHAPTER 3: PROPOSALS FOR CONSULTANTS AND FREELANCE CONSULTANTS
Front page Revision history Project reference number Project summary Start date End date Rate/Price Project overview Activities and deliverables Specified costs and payment schedule Confirmation and release
Do the elements look familiar to you? They should - you can create a work summary with a slimmed down version of the proposal. You have now learned how to collect two types of documentation that you can use to identify the work you are doing for a client. These documents should form the basis of any project work you perform for a client and provide you and your clients with clearly defined instructions for your projects.
VACANCIES
55
4
Project goals and approach: Knowing which star to orient yourself towards. One of the keys to a good project is for the team to start with clear project goals and a well-understood approach. Ideally, project management has set this up for you - but how do you know if it hasn't? This chapter is about setting project goals and asking some questions to help you solidify those goals. We'll also discuss some common project approaches (or methodologies) and how they can impact the way you work. Caroline Chandler
67
Y
You are in the kickoff of the project, for the first time with the whole team. The project manager hands out some material and gives you an overview of the project. At the end of the conversation, you should ideally have the following information:
Why is the project important to the company? How will stakeholders determine whether the project was a success? What approach or methodology will the project follow? What are the key dates or milestones for key points e.g. B. receipt?
Approval of the business outlook? All of these questions are about stakeholder expectations of the project: what will the project achieve and how will they be involved? The first two questions relate to the project goals and the last two to the project approach. A project goal is the specification of a measurable goal for the project. Let's discuss the goals in more detail.
Reinforcing Project Goals Goals are an important focus lens that you will use throughout the project. They must stem from the overall business strategy of the client company, so the project goals must align with the strategic initiatives within the company. For example, if there is a strategic initiative to engage a new group of potential customers (called a market), the website or application you create could be an attempt to provide that market with online access to products and services relevant to them are. The aim of this project would then be to reach and develop this market. A clear purpose resonates throughout the project. It helps you ask the right questions while collecting ideas from business prospects. Plan research with users and focus your analysis on the results. Detail and implement ideas collected from stakeholders and users
in a consolidated list of project requirements. Prioritize these project needs based on their value to the business
consolidate project goals
57
Create effective interaction designs. Manage design change requests as soon as development begins. Concentrate efforts during implementation activities (e.g. training and communication).
(Notifications to users about the new website or application before and during launch) Determine whether you have met the needs of the client company
The project is started. When you start a new project, you probably have project goals from the project sponsor (the business stakeholder directly responsible for the success of the project) and a number of project-related requests from business stakeholders and clients, but they can all get a little blurry (Figure 4.1). Your goal is to translate these into well-founded statements that you can use as a measure of project success.
Project related questions
Fuzzy target of business strategy
User Question Stakeholder Idea
vague target
Idea of a user complaint advocate
Figure 4.1 Vague goals, ideas and needs
A solid goal is easy to understand. Avoid insider terminology. Distinctive. Avoid vague statements; Instead, use phrases that sound like you
will be helpful in prioritizing requirements. Measurable. Make specific statements that you can determine on your own
Use this to measure your success. When you define a vague goal and make it clear and measurable, it becomes a solid goal to base your decisions on.
58
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
Figure 4.2 Targets have solidified
Goals of the business strategy project
You will hear many statements that can be considered goals. Analyzing vague goals like the ones below will help you solidify your goals and communicate more effectively within the project team. Corporate attorney
B
"Our goal is to become the market leader in industry X."
This is a company-wide objective, but too broad for a specific project. To achieve this, various initiatives within the company must work together. A single site or application can help with this, but will most likely not be able to handle the entire load unless the entire organization takes care of that one site or application and it eventually becomes extremely successful. Corporate attorney
B
"Our goal is to create excitement in our customer base."
This is better because a website or application can influence it, but it is still too vague. Why is it important to generate enthusiasm? How does that enthusiasm translate into meeting a business need? And how do you know if you passed? Corporate attorney
B
"Our goal is to increase traffic to our website."
Now we get there. This is easy to measure, but focuses too much on an intermediate step. Assuming you're getting more traffic, it might not help you if people there aren't taking the actions you want them to.
consolidate project goals
59
Vague goals can give you an idea of a customer's needs and bigger goals. From this you can formulate more concrete project goals, such as B. Increased turnover from online sales by 10 percent. Increase online advertising revenue by 20 percent. Increase the number of current and potential customers in our customer base
Database to at least 20,000. Provide our most important users with highly rated and frequently consulted content.
(Note that deciding how to measure "highly appreciated" and "highly referenced" takes some work, but the elements are there to build upon.)
Each of these factors can be measured and influenced by your project. They can also pretty much match your designs and the features offered. For example, it is very common to offer an online newsletter to achieve the goal of expanding the customer base: to send the newsletter, you need to collect the email addresses of the customers that will be added to the database. Goals can also bring new requirements. For example, if you measure success by the average rating of articles on your site, you need a feature that allows users to post reviews. This way, goals help you focus on gathering ideas for the site, which can later become project requirements. If there are multiple goals, make sure you create a priority list with your corporate sponsor and project team. There are sometimes conflicting goals during design and the team needs to know which takes precedence. The final prioritized list of goals should come from your project sponsor, but you can be an important part of the discussion. Let's talk about how.
How can a UX designer help? If you realize at the start of a project that the project goals are unclear, you can call in your facility skills. Help the project team understand the business context of the project by holding a workshop with key stakeholders (see the next chapter for more information on identifying the right stakeholders). Your goal in this session, which typically lasts two to four hours, is to provide information about the company's strengths and weaknesses.
60
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
Opportunities and risks. Known as SWOT analysis, this is a common business analysis technique and a way to discuss a company's position in the market. You can also use this time to talk about the company's competition. Understanding Strengths and Weaknesses The SW in a SWOT analysis is the company's current strengths and weaknesses related to the project. Strengths and weaknesses can include internal processes as well as external perceptions - and often they influence each other. For example, a company with a large research and development (R&D) department may have access to a large source of original published research (a strength), but there may be no one to help make that content more accessible to the average user, making perception leads the company to be "too academic" (a weakness). Map opportunities and risks. The OT is the forward-looking half of the SWOT. Given the things that differentiate the company from its competitors, what future initiatives might the company take to create a new niche or strengthen an existing one? What situations could jeopardize these plans? For example, our R&D company may choose to hire writers to publish more accessible editorials related to their original research (an opportunity), but if the site's current toolset lacks robust content management capabilities, the publishing process may be extraordinarily slow. This allows competitors to react more quickly (a threat). Compare competitors. What is the company's main competitor? Who are the competitors for the website to be developed? They may be different especially for big companies or brand new websites. Are there any sites that are not direct competitors but represent interesting models to consider? You can learn a lot by checking out other ecommerce sites to see if and how they sell what you sell. Pull It Together The SWOT and competition discussions are good topics to discuss at the same time because they interact. It's hard to talk about it
consolidate project goals
61
You identify 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 of the company's competitors and the SWOT here, your project goals - as well as the overall fit of your project within the company's strategy - should be easier to define and the priorities between them should become clear. Defining the project goals will help you understand the expectations of the project results. Next, let's talk about the expectations for completing the project. 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 to get involved and how to involve others, such as your project team and business stakeholders. Sometimes there seem to be as many project approaches as there are projects. Choosing the right approach for a project is a big topic in itself. The methodology you choose can depend on many factors, including the structure and location of the project team, the technologies used in the project, and the extent to which collaboration is part of the organizational culture. For the purposes of this book, we will assume that you have joined a project whose action is largely determined by those responsible for the project's success, such as the project sponsor and project manager. In this situation, your main goal is to understand the approach and make it effective for the business prospects and your users. Here we focus on two of the most common types of approaches, as well as a third that shows possible variations you may encounter in a project. It is important to note that most approaches involve the same steps: plan the overall strategy, approach and team structure. Define the project requirements. Design interaction and visual concepts and develop them into detailed concepts
Specifications. Develop, test and refine the solution.
62
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
Deliver the solution through news, training, and a planned rollout. Expand the project by making suggestions for improvement.
The names of these steps can vary, as can the extent to which they overlap and how information is documented. However, the general activities in each step are the same for most projects and all three models presented here.
Waterfall Approach The waterfall approach treats the steps of a project as separate, separate phases, requiring the approval of one phase before the next phase begins. For example, the design phase does not really begin until the requirements are approved by the business stakeholders, who sign one or more requirements documents at the end of the definition phase. permit
The plan
permit
permit
Define, develop, implement, expand design
Figure 4.3 Example of a waterfall approach where each phase flows into the next.
The problem with a pure waterfall approach is that it assumes that each stage can be completed with minimal changes to the previous stage. So when you come up with new requirements in the design phase, which is often the case, you have to propose changes to documents that are approved at the end of the definition phase, which can mess up the plan and schedule.
Agile Approaches Because change is constant, project teams are constantly looking for more flexible approaches than the waterfall model. Many methods have a more fluid approach, with some steps occurring side by side. For example, versions of the website can be released on a fast, iterative schedule using an agile or rapid development approach. An agile approach generally puts more focus on fast collaboration and less focus on detailed documentation and formal approval. UNDERSTAND THE PROJECT APPROACH
63
Iteration 1
To develop
Iteration 2
To develop
Iteration 3
To develop
Implement design Implement design Define implement design
To define
Define approval
The plan
Provide release extension
Figure 4.4 Example of an agile approach
A true Agile approach (for example, following best practices developed by members of the Agile Alliance) requires small teams, with members physically seated next to each other, with little emphasis on defining formal roles between team members. This way of working enables a very high level of collaboration, reducing the need for extensive documentation between the design, development and testing phases. A team member can ask a question, team up with other team members in a quick whiteboard session, and implement a solution, all without waiting for detailed documentation and approval. In a fully operational system, stakeholder reviews occur when one of many iterations is released, and the resulting input is considered when planning the next iteration. (Iterations are draft versions of a particular website or application.) When an agile approach works as designed, that's great. However, in most companies and most consulting engagements, teams rarely opt for a purely agile approach. This is partly because organizations are increasingly using distributed teams and remote workers, making it difficult to maintain the high level of collaboration required to get the most out of the pure Agile approach.
Changed Approaches Most projects try to take an approach that combines the best of both worlds: with enough structure and documentation to reduce the risks of distributed teams and team member turnover, but also with enough collaboration and iteration to be relatively flexible. respond to changes. For example, a project might follow a waterfall model but overlap in stages, so there are key points for team-to-team collaboration. This makes it possible
64
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
Possible changes appear earlier in each stage. This can also be an early release (for example, a beta version for a specific user group) with a shorter iteration cycle. Feedback from this release can then be incorporated before the new site is fully deployed. Plan
To define
develop design
Design
To define
Develop and deploy beta
Provide release extension
Figure 4.5 Changed waterfall with beta version
Note the smaller iterations during the design phase in Figure 4-5. This is 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 rapid iterations of ideas before significant development time is invested. One of the most common is a modified waterfall approach like the one in Figure 4-5. These are commonly used methods, so it is the approach that forms the scope of this book. However, many of the topics covered here will apply to your project regardless of the specifics of your approach, as the underlying activities - such as definition and design - are still required.
Dive Deep If your project uses an Agile approach, you will have unique requirements to collect needs, such as writing "user stories" as a way to collect requirements. We recommend User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley Professional, 2004).
UNDERSTAND THE PROJECT APPROACH
65
What effect does the approach have on me? Knowing your approach helps you understand a few things: what questions to ask and when. For example if it's you
If you are working with a pure waterfall approach, you need to make an extra effort to ensure that the requirements laid down in the definition phase contain all the information you need for the design phase. (We'll discuss the requirements in the next chapter.) Expectations for how the project team members will work together and how
close that cooperation will be. For example, an agile approach requires very close collaboration. A waterfall approach can usually involve one-on-one work, with touchpoints once or several times a week. The required level of detail in your documentation and the level of
Formality. Documents submitted to the collection points must be formal, almost like legal contracts. Usually you need more formal documents in a waterfall approach that requires approval before moving on to the next stage. However, you can also have some formal release documents when using an agile approach, for example to capture information at key decision points, such as preparing a particular iteration for full release and deployment. Key milestones requiring stakeholder approval and
Facilities for different groups. The approach defines what different audiences should provide at different points in the project, including stakeholder approval at release points and feedback from potential users during a beta release. Now that you have established your project goals and gained an understanding of the project approach, in the next chapter we will start with the most important work in the definition phase: gathering requirements.
66
CHAPTER 4: OBJECTIVES AND APPROACH OF THE PROJECT
5
Business Needs: Know the problem before you create the solution. By the time the project team comes together, you've probably heard or thought of a lot of ideas about what needs to be done. There may already be lists of features provided by some of the prominent members of the company (your business prospects) along with their views on which features are most important. These are elements of the business requirements for the project and are a good place to start. To ensure you have a complete solution at the end of the project, you need to generate and clarify requirements from multiple angles. In this chapter, we focus on gathering and mapping the needs of your business prospects. Caroline Chandler
67
C
Chapter 4 discussed vague goals and some ways to clarify them for yourself and the project team. In the early stages of a project, you probably have a set of requirements that are relatively vague. These can be stakeholder ideas, user complaints, or user requests. To create these useful and trackable components of your project, encapsulate these ideas into requirements. Requirements are guidelines that define what the site or application should do. Ideally, a business requirement provides insight into the general need to be met. It represents and consolidates the requirements of different interest groups. It sets a direction for the design without being too specific about how it will look
completed Serves as a self-contained unit of work for prioritization and tracking purposes
Here's an example idea for a feature on an e-commerce site. The same idea may be conveyed to you by several business prospects early in the definition phase: "Customers can track their orders online." This is a good basis for a requirement, but it's unclear. Ask questions that go into the details of the requirement, e.g. B. Why is it important to the company that customers can follow their requirements?
Order online? For example, is it about reducing the number of calls to customer service? Does the company currently have the ability to track packages online?
If not, new requirements for tracking capabilities must be collected or the company may need to work with a third party. How accurate should the tracking be? What kind of information
should be included in the tracking data? For example, should the website provide an updated delivery time estimate? By asking these kinds of questions, you can turn vague ideas into concrete requirements. It also becomes clear that the same statement can have different meanings for different people.
68
SECTION 5: BUSINESS REQUIREMENTS
For example, a stakeholder might think that package tracking means receiving a confirmation email with a tracking number that can be entered on UPS.com or another website so that the interested customer can see when the package was last stopped. Idea Another stakeholder may think that the company should take parcel tracking to a new level and invest in developing the ability for customers to track parcels via GPS and see their exact real-time location using an online card. As you can imagine, there is a significant difference in user experience and scope here! It is important to outline these differences at the beginning of the project. Otherwise, you end up developing a solution that ignores the intentions of the business stakeholders - and possibly the project goals. This leads to dissatisfied stakeholders and, if the function has to be redesigned, to a loss of time and money. Clear and detailed requirements are therefore an essential part of your overall project. To arrive at a consolidated list of project requirements, the following steps are required: 1. Understand the current state of the site or its competitors. 2. Collect needs and ideas from business prospects and current and potential users. (See Chapter 6 for details on working with users.) 3. Consolidate ideas into requirements. 4. Prioritize requirements based on project goals. (See Chapter 9 for prioritization suggestions.)
Requirements for business and user projects Business strategy requirements
Figure 5.1 Bringing together ideas from business stakeholders about business needs and ideas from user research about user needs. Then use the project goals to prioritize and create a consolidated list of project requirements.
BUSINESS REQUIREMENTS
69
First, let's talk about understanding the current state of your site so you have context for the ideas that come to mind when you gather requirements.
Understand the current state When delving into the ins and outs of the website or application you're designing, it's important to put your mind at ease by understanding the current state of the site (if you're redesigning an existing site ) or by understanding the main competitors more. thoroughly (when designing a new website or application). You can learn a lot about the current status through stakeholder interviews (more on this in a few pages). You can also gain a lot of insight yourself, and this can serve as a solid foundation for stakeholder interviews and user research. A good way to get background information and generate ideas that can become requirements is to perform heuristic analysis.
By another name... The word heuristic means a rule of thumb or best practice. A heuristic analysis is now understood as an assessment of a product against a set of rules (heuristics) for usable design, usually performed by a UX designer. User-friendly websites follow most or all of the heuristics you use in your analysis. You may also hear this technique referred to as heuristic scoring, expert scoring, or a combination of these terms.
Heuristic analysis Heuristic analysis is a technique you can use to evaluate the usability of an existing theme based on user experience best practices. You can perform such analysis on the current website at the start of a redesign project, or analyze competing websites to identify opportunities to provide a better user experience than other companies. The result is a document that describes the strengths and weaknesses of the site and contains recommendations for improvement. When it's done, you'll get a deeper look
70
SECTION 5: BUSINESS REQUIREMENTS
An understanding of the site being analyzed and a list of ideas that could contribute to the needs of the new site. For example, a commonly used heuristic is this one from Jakob Nielsen's list of ten usability heuristics (see Jakob Nielsen's website for the full list at www.useit.com/papers/heuristic/heuristic_list.html):
Visibility of system status. The system should always keep users informed of what is happening by providing appropriate feedback within a reasonable timeframe.
There are many situations on a website where this heuristic is not followed. Suppose the user clicks the Download button and is not notified that their file is being downloaded. The system has not informed the user that the file is being downloaded, although the download has started. So the user may click the button again, thinking they missed the button the first time... and then click it again... This can lead to multiple downloads and potential problems for both site and user performance who is doing this now. several downloads in progress without realizing it. Heuristic analysis allows you to identify this as a problem area, describe it and assess its impact. You can also share an idea to solve the problem that could be added to the requirement list. Why perform a heistic analysis? Performing such an analysis is a relatively quick and inexpensive way to get feedback on a design. Heuristic analysis can provide a general understanding of design quality and help identify potential design problems. Please note that this activity does not directly concern end users and should not be a substitute for genuine user research. For example, only 50 percent of your heuristic insights may actually be validated by subsequent research. However, the analysis gives the team a good overview of likely problem areas. If you're working on a redesign of an existing product or website, this can also be useful for identifying obvious quick fixes that can lead to immediate improvements while the redesign efforts continue behind the scenes.
UNDERSTAND THE CURRENT STATUS
71
How do I do it? The specific heuristics you use may vary from project to project, but the process for performing the analysis generally remains the same: 1. Gather product and project background knowledge. Make sure you have the goals of the site, a list of the main user groups that need support, information about the type of environment users are likely to work in, and a basic understanding of any special skills your users are likely to have. (For example, your analysis will be different for a site made for general consumers than for a site made for, say, pharmacists.) If you need help with the latter, visiting different competitor sites or applications can help you determine the most common terminology to understand areas of interest. 2. Choose the heuristic to use. There are many heuristics to refer to. In addition to Jakob Nielsen's list, many UX designers refer to Bruce Tognazzini's list of design principles: www.asktog.com/basics/firstPrinciples.html. Once you are familiar with the topic of the site, you may want to add your own topics, especially if you are analyzing more than one site. Make sure your list is a manageable size (e.g. 8 to 12); Too many heuristics can make the technique unmanageable for you and your readers. 3. Go through prioritized areas of the site and identify areas where the heuristics are followed or missed. Each observation you make should include the following information: The general observation. A short summary of the result. Ideally, these should be numbered for quick reference when reviewing the report. A brief description. A few paragraphs 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 indicate a positive result if you share something that the site did well. In general, high-impact issues are issues that you believe will cause many users to fail or fail to complete a specific task
72
SECTION 5: BUSINESS REQUIREMENTS
The permanent loss of information (for example, an issue where a user loses changes to a document they were working on). Medium impact problems are problems that cause frustration and errors, but do not cause irreversible problems. Low impact issues are minor issues that can be confusing, but usually don't cause wasted time or frustration. Recommendations. These are the next steps or ideas that you share that can serve as a solution to the problem you're running into. Figure 5.2 shows an example of these elements together as they might appear in your heuristic analysis. Observation #4: The search function doesn't seem to return all possible results.
Great care
A sample test of the search function produced mixed results. Searches for a name in a relatively recent post on a less-covered topic occasionally yielded no results. It also seems that the primary search only returns links to new stories and not videos. Recommendations 1. Ensure newly added content is indexed and searchable before or very shortly after it is publicly available. 2. Consider displaying related content when displaying search results, for example, stories in similar categories or with similar tags, so that explorers can follow more threads. 3. Consider a universal search that displays results by category. 4. Use search term logs to understand commonly used items. This can also shed light on items that users can't find.
Figure 5.2 An example observation in a heuristic analysis report
4. Present your findings to the project team and key stakeholders. Review your observations and recommendations. Discuss why you left the reviews you gave. (This is also a good time to develop a recommendation for validating your results using one of the techniques discussed in Chapter 6.) How does heuristic analysis help gather requirements? Once you've completed your heuristic analysis, you'll have a better understanding of the current state of the site (or its competitors) and a list of ideas that can help capture requirements. You will also get some ideas for structuring the topics to cover in the requirements gathering sessions - which leads us to the next step in this process.
UNDERSTAND THE CURRENT STATUS
73
Collect 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 different expectations between stakeholders. that of our friend who wants packages to be tracked via GPS. One of the most common mistakes in a project is choosing a feature and calling it a requirement without first understanding the problem and what is expected of a solution. Why is the requirements gathering process shortened so often? Collecting ideas - and compiling them into requirements - can take quite some time. The number of questions you need to ask to formulate requirements so that they can be prioritized is easily underestimated. And if the process is not well-structured or participation is incomplete, high turnover can result that can persist throughout the project. (Chrout is wasted time in extra meetings and work iterations caused by a lack of communication and engagement. These are distinct from the more productive work iterations that are part of designing and testing valid solutions to find the best solution.) So how? Are you promoting a balanced requirements process that focuses on business needs but doesn't waste time? Here are some steps for an efficient process: 1. Outline roles and responsibilities. Ensure project team members understand the roles they need to fulfill in requirements gathering. 2. Gather the right stakeholders in the right groups to ensure the best use of time during a needs-based interview or meeting. 3. Create a meeting plan, including topics to be covered and questions to be asked during the meeting. 4. Meeting efficiently, capturing ideas and providing clarification. Explore ideas to determine underlying needs. Once your meetings are complete, don't forget to thank the stakeholders involved and update them on progress once you move to a consolidated list of priorities. Let's look at each of these steps in more detail.
74
SECTION 5: BUSINESS REQUIREMENTS
Overview of Responsibilities Collecting business requirements generally involves interviewing project team members with key business stakeholders to gather ideas. Business stakeholders are those within the organization who have a business-oriented interest in the success of the project, or expertise to contribute, or both. These people are not involved on the project full-time, but they need to be involved at key points in the process, and gathering requirements is one of those points. Keep in mind that they also have day jobs (sort of), so their time is precious and often hard to come by unless you plan ahead. The project sponsor (or sponsors) is the business stakeholder who is also directly responsible for the success of the project, often at a relatively high level in the company, such as a director. He or she will not be involved in the project on a day-to-day basis throughout the project lifecycle, but will likely be actively involved in gathering requirements and ensuring a high level of engagement from the business stakeholders. The sponsor may also attend some or all of the meetings. The project team consists of people who are officially assigned to the project as ongoing resources. You can be involved as a project manager, UX designer, business analyst, technical lead, visual designer, quality assurance lead, etc. Depending on the size of the project, this may be their main task. Within the project team itself, the responsibilities for gathering requirements are often unclear. Taking the time to define responsibilities early on can help ensure an efficient merger process. Here are some questions to ask as you determine the specific responsibilities each team member will have in requirements gathering: Who will have primary responsibility for gathering and planning the appropriate business requirements?
Which stakeholders are among the most productive groups? These can be both internal and external stakeholders (e.g. partners, suppliers, etc.). Who creates the theme and question structure for the business participation?
owners meetings? Time permitting, this is a great joint exercise for the team. The lead moderator can then organize them into a structure that fits well in a meeting. Who moderates the meetings? Who takes notes and how are they shared?
COLLECT IDEAS FROM Stakeholders
75
Who then contacts whom? Is someone from the technology team present at all meetings?
If so, how is this person involved (listening, contributing, or otherwise)? Whether or not you are primarily responsible for one or more of these areas, as a UX designer you have important skills to bring to the process. Creating a structure for topics and questions requires a sense of clear categorization (which sounds like a good overlap with information architecture), and of course facilitation skills are important to keep the meeting on-topic and all participants engaged.
Collect the right stakeholders. The main purpose of stakeholder surveys is to gain insight into relevant project-related ideas, needs, knowledge and frustrations from different angles, which can then be incorporated into the project requirements. There is also the sometimes unspoken benefit of involving many different groups so that everyone feels they have a say in the project - and will therefore support the final solution. While it may seem more political than practical to get people involved to get their approval, it is often an important step that connects you with a network that will support you throughout the project. It can also help you avoid 11th-hour changes that can occur when someone you haven't spoken to raises an issue late in the process. So it's often a good idea to include a wide variety of people. On the other hand, schedules and budgets must be taken into account. Engaging a large number of people takes time, both from their perspective and yours, just for the meetings — not to mention the time it takes to go through the notes to spot trends and consolidate layoffs . For the sake of efficiency and your own health, it makes sense to prioritize the groups you want to speak to and select key individuals from those groups to act as thought leaders for their team. Which stakeholders could you involve? These groups are often good sources of ideas: groups with initiatives that depend on the website (for example, those with
Marketing campaigns that require information to be presented on the website)
76
SECTION 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 directly to collected information. First-line customer service, such as B. Phone or online support or
Anyone who deals personally with customers (e.g. in a store or through deliveries), sales, product management or consulting services to represent them
Products and services presented. Human resources to achieve hiring goals. Public relations to present information to investors and the media. All groups responsible for other relationships to be developed
When choosing the people to include, get help from your project sponsor and any project team members who are familiar with the groups involved to help you choose the right people. Create groups that spark good discussion. There is no one right way to do this, but a common way is to group stakeholders by department, like this: marketing (five people), product management (four people), customer support (two people), sales (four people).
On a smaller project, one person from each of these groups may be involved in a series of two or more collaborative work sessions where everyone comes together. Once you have your stakeholders in mind and have an overall structure for the meetings (see the next section), you can start planning the meetings. Try to start planning at least a few weeks in advance. It can be difficult to get everyone in one room.
COLLECT IDEAS FROM Stakeholders
77
Make a plan for the meetings. In addition to your efforts to select the right stakeholders, make a list of topics to cover and questions to ask (this will also help you narrow down your list of stakeholders). You should have a different plan for each group you meet with, although some of your questions may be the same from group to group. You also need to determine the level of detail you want in the meetings. If you're meeting with a large number of people just once (e.g., members of different departments, as suggested above), you're eager to brainstorm ideas, but you probably don't want to spend too much time on stark details. during the meeting. In this case, if one of your stakeholders gives you the idea, "Customers can track their orders online," you might just want to ask why this feature is important and if the stakeholder can think of a website that does this well. These questions should help highlight the major differences in stakeholder expectations for the position, without devoting the entire meeting to a single statement. You can then work with the project team to work out the specific details of the idea and then work with the stakeholder to ensure that the requirements you generate still reflect their original idea. Let's say you're redesigning an e-commerce website and you're meeting with different stakeholders, organizing a meeting with each group. Here is a sample plan for a meeting with a sales department group.
Sales: requirements gathering. Inside Service Contestants: Jenny Bee, Tracy Kim, Joseph Arnold. Directed by: Kevin Abernathy, Cat Parnell. Duration: 2 hours. Objective: Understand the current sales process and identify issues and ways the Internet can better support this process. Background: We watched a PowerPoint presentation on the buying process, which provided a good background on how buying decisions are made. We also plan to talk to customer service.
78
SECTION 5: BUSINESS REQUIREMENTS
Sales: Requirements Elicitation Meeting continued Questions Sales Process: How does the sales process differ for different product lines? Are there regional differences? Are there differences based on customer size (e.g. small businesses versus large businesses)? How has this process developed over the past two years and how is it likely to develop over the next three to five years? How does a potential customer understand all the things that need to be bought and how they work together?
General impression: Who do you think are the most important visitors to the current website? Why? How is it What do you want to achieve with the website? How does the internet contribute to the sales process and/or sales conversion rate these days? What information do customers need to make a purchasing decision? Is this information available on the website today? Is it easy to find? Is it right? How difficult is it to maintain content on the website these days? What stats do you get from the site? What additional metrics would you find valuable? Why?
Imagine the future: what can we do to better support the sales process when you think about a future website? What current functions and features on the site are critical to sales? What is not necessary? What's missing?
Summary: Are there any other thoughts, suggestions, or concerns that we haven't covered? What websites do you think are great for driving sales? What is the most important thing the company can do to improve customer satisfaction?
COLLECT IDEAS FROM Stakeholders
79
Meeting effectively. Here are some ways to help you collect requirements. Make sure a common vocabulary is used. Much confusion can be avoided if the requirements gathering team agrees on a common list of terms and definitions. For example, are the people using the system called users, customers, or clients? Are the terms interaction designer or information architect better known? To avoid confusion, take a moment at the beginning of each meeting to explain which term is being used and what it means. It may also be helpful to create some visual elements that help explain the relationships between different terms or roles (see Figure 5-3). category
Categories
Categories
subcategory
subcategory
subcategory
Theme
Theme
Theme
Article
Article
Article
Figure 5.3 Scheme with project conditions and relationships
A common vocabulary for the deliverables used in the project also helps stakeholders understand the process and the type of deliverables to be expected. This can increase confidence that their time and effort is not wasted in a black hole of ideas. In general, if you find yourself defining the same words more than once or twice (particularly if you find that the definitions change slightly each time), you should consider putting them in a project glossary and sharing it with the team members of the project. Other examples of terminology that should be clarified at the start of the project include:
80
SECTION 5: BUSINESS REQUIREMENTS
Roles that interact (e.g. job seeker versus client or consultant)
tent manufacturer versus publisher) Main findings that are often referred to (functional specifications)
emailing, wireframes, sitemap) and a short description of their differences. Distinction between different levels of information (e.g. our category).
Information in figure 5.3) Distinction between needs and expectations
Listen to ideas and respond to needs. Stakeholders may make statements that appear to be needs. Consider an example. Corporate attorney
"We need a blog on the site."
B
This is really an idea, not a necessity. Then, when the blogging functionality is fully designed and implemented, it becomes a solution, but it is not necessarily the solution that best meets the core needs of the stakeholders who demand it. If you ask why a blog is important, you may get a wide range of demands, such as "We need to be relevant and have reach." We need a way to get people to visit the site again to generate more ad revenue, and blogs ensure that newly posted content has a following. way to show our expertise.” “We need a better way to communicate and innovate with our customers, and blogs bring us comments so we can hear their views.” Each of these statements describes valid needs. By releasing them, you'll learn more about the drivers behind requests for specific features. This will help you build consensus as you consolidate and prioritize requirements.
COLLECT IDEAS FROM Stakeholders
81
Consolidate Requirements When the meetings are over, take the ideas you've collected and organize them into broad functional areas. You see a lot of overlap. This is a good sign that a particular idea is getting a lot of support from your stakeholders. Eliminate redundancies and try to consolidate an idea list that efficiently represents your stakeholders' intent. To turn the ideas you collect into actionable and actionable components of your project, you need to consolidate those ideas into requirements. Imagine raindrops forming from a cloud: from a large and undefined cloud to a larger number of well-defined raindrops. So if you get a cloud of ideas like "customers can track their orders online", you need to turn that into clear instructions that tell the system what to do. The resulting requirements should provide insight into the overall needs to be met. Identify and consolidate the needs of the different stakeholders. Give direction to the design without being too specific about how it will look
completed Serve as a self-contained work unit for prioritization and follow-up
As you begin to move from ideas to requirements, be sure to involve your technical lead (or someone else who can represent the development team on your project) to ask questions that will help you manage the required effort estimation when you prioritize later. If you have a dedicated member of the quality assurance team, that person can also ask some detailed questions to help bring the requirements together. To turn the tracking idea into detailed requirements, ask questions like, "How accurate should the tracking be?" What information should be included in the tracking details? for
For example, should we provide an updated delivery time estimate? You can ask these kinds of questions at length and discuss them with the stakeholders who gave you the first idea if they spend a lot of time on the project. If you don't have much access to these stakeholders, you can work out the details yourself through project team discussions
82
SECTION 5: BUSINESS REQUIREMENTS
You then discuss the requirements with your project sponsor to ensure your decisions make sense for the company. Table 5.1 lists the types of requirements that can arise from the tracking idea and how to capture them. TABLE 5.1
An example of business needs
ID card
AREA
1
Track shipment
2
3
Track shipment
Track shipment
REQUIREMENT
BUSINESS REQUIREMENTS
Orders can be tracked by
Encourage self-service
Enter a tracking code
during childbirth (support
online
To use)
Users can track their package.
Show innovation in efficiency
Age by GPS tracking vehicles
Fast delivery (competitive
or airplanes
To use)
Users can view all previous orders from the last 365 days. Encourage re-ordering
Self-service (sales, support services)
Note that in some cases the requirements overlap, as in the case of the first two requirements in the table - both are trace methods. You can live together in the same system as you can enter a code to locate your package through the GPS view. However, they are separated because the GPS-related requirements are likely to be a greater overhead and should be prioritized independently of the other functions. When consolidating statements, consider business needs that you believe may conflict with user needs. For example, a business need may be to collect personally identifiable information from potential customers, such as their email addresses. However, customers may have reservations about the provision of information. After all, filling out forms takes time, security and privacy are an issue, and this step can interrupt the larger task they are trying to accomplish. Identifying such conflicts will give you ideas that can help you meet the needs of both your business and your users. For the tracking example, you can suggest using the Send to a Friend function to capture the email address and provide a useful function for the user. This means that "send to a friend" can become a requirement that you include in the mix to prioritize. these kinds of ideas
COLLECT IDEAS FROM Stakeholders
83
You can help meet both business and user needs, making them great for capturing. You also live in the overlap between the definition and design phases (see Chapter 4) as you begin to think about design solutions to business problems.
Defining and Developing a Design Potential conflicts between business and user needs are excellent things to explore in user research, and we'll discuss them in the next chapter. Through user research, you can also expand Table 5.1 to include a full set of potential requirements that are prioritized in a list of project requirements (shown in Figure 5.1 and discussed further in Chapter 9). Keep in mind that gathering business needs is typically done in parallel with exploring technical capabilities and gathering user needs. Next: time to talk about users!
84
SECTION 5: BUSINESS REQUIREMENTS
6
User research Get to know the guests you are inviting to the party. There are many user research techniques that can be used throughout the project lifecycle to better understand your users or test their behavior on versions of a site. This chapter focuses on some of the most commonly used methods in the early stages of the project. These techniques help you define the user groups that should be given the highest priority during the project, put their needs and frustrations into context, and evaluate the performance of the current website (if any) using best practices for designing user experiences. Caroline Chandler
Basic User Research Steps 1. Define your primary user groups. This includes creating a framework that describes the main types of users you are designing for. This allows you to focus on recruiting users for research. 2. Schedule user onboarding. This includes choosing one or more techniques to engage user groups based on the needs of your project. 3. Conduct the survey. Here we cover the basic techniques such as interviews and surveys and give tips on how to use them. 4. Validate your user group definitions. You can use the research insights to solidify your user group model. This model then serves as a platform for the development of more detailed tools, such as B. Personas (see Chapter 7). 5. Generate user requirements. These are statements about the features and functions that the website may contain. You add these statements to your business needs (see Chapter 5) and prioritize them to become project requirements (see Chapter 9). This chapter covers the first three steps, starting with the first: defining your user groups.
Define your user groups. Planning user research at the beginning of a project can feel like a chicken-and-egg dilemma (which comes first?). How do you make sure you're talking to the right people if you don't already know who those people should be? One way to get started is to create an initial or preliminary definition of the users you want to design for. This describes the primary user groups of your website. This can help you focus your research efforts on the right roles, demographics, or other variables that can affect how users experience your site. Audience definitions can be high-level (a list that defines each of your audiences) or detailed and visual (a chart that shows multiple user types and how they interact with each other).
86
CHAPTER 6: USER RESEARCH
A general definition for a company's primary .com website might include the following user groups: potential buyers, current buyers, partners, and job seekers. When you start defining groups for user research, you will prioritize user groups in more detail. Their initial definitions are based on the collective knowledge of business stakeholders and project team members about the possible types of users who might interact with the site. These definitions can be made by defining some goals and attributes that different user groups may have. Here are the basic steps for defining your user groups: 1. Make a list of attributes that will help you define your site's different users (the following section covers some of the most common). 2. Discuss the attributes with those in the organization who interact with relevant user types (e.g. customers). 3. Prioritize the features that seem to have the most impact on why and how a potential user would use your website or application. 4. Define the user groups you want to focus your research and design on. In the following sections, we'll dive deeper into some brainstorming techniques to help you collect, prioritize, and model these attributes (making representations of the different user types that help you focus your research efforts).
Create a list of attributes. A good place to start for your attribute list is to collect and process research or other documentation from the organization that can help users. Here are some possible resources: Documents explaining business strategies, such as B. Business goals,
Petition information, marketing strategies and business plans, market segmentation of current customers and other demographics
Collected by Marketing Department Previous user research (see table 6.1 for some examples)
DEFINE YOUR USER GROUPS
87
Surveys such as user satisfaction surveys and feedback forms. Customer service reports on common issues
Next, identify people within the organization who have insight into current or potential users. The number and variety of people to involve will depend on the type of project and its scope and schedule. If you know that the initial definition of your audiences can be short-lived (for example, if it will only be used for a month or two while user research is planned), you can only include two or three participants. If you think the initial definition should guide you through much of the design process (for example, if you can only work with this definition until you run a usability test after part of the design is done), get more participants. you have a cross-section of all perspectives. Potential participants are marketing staff responsible for branding, segmentation and campaigns; sales personnel; Product manager; customer service or support staff; and trainers. It is also a good idea to involve the project team leader and other business stakeholders in this exercise. Ask the group to think about the different types of potential users they often interact with. Then ask them to list some of the common features they have come across. Here are some examples of what can vary: Primary objectives, as they relate to your site's theme. Why be
Users come up with it and what are they trying to achieve? Common goals might be buying an item, trading stocks, or answering a specific question. Roll. This can be defined in many ways, but one way is to associate roles with it
Main purpose of the user: job seeker, support seeker, prospect, etc. Once you have more user information, the roles can be divided according to different needs or styles; For example, on an e-commerce site, customers can be bargain hunters and connoisseurs. Demographic information, including age, gender, household (single, married, children),
income level and region. Experience, including level of education, degree of familiarity with relevant
Technologies (often referred to as technical knowledge), level of expertise and frequency of use (one-time, incidental, frequent). 88
CHAPTER 6: USER RESEARCH
Organizational characteristics, including the size of the company where users work
B. for their department, type of job (entry level, freelance, middle management, executive), employment (long term or high turnover?) and work patterns (remote work, travel). Once you have a list of some of the characteristics that are most common when stakeholders describe potential users, you can prioritize them based on their importance level and then use this hierarchy to begin defining and modeling user groups.
Prioritize and define Which of the above characteristics do you think have the greatest influence on how and why different user groups might use the website? Focus on the ones you think will have the greatest impact on a user's goals or behavior. Prioritize these traits and remember the goals you set in Chapter 4 - they too will help you make decisions. An example best illustrates how attributes are prioritized. Let's say you work with a company that provides tools for online trading of stocks, options, and futures. This particular company has decided that part of its strategy will be to engage non-professionals who trade stocks independently and online, and encourage them to trade new types of products such as options and futures. The company intends to achieve this by providing user-friendly trading tools aimed at those who want hands-on learning in a safe environment. When discussing characteristics with business stakeholders, you may notice that the following seem to have the greatest influence on how individuals might use these tools: Current trading frequency, especially the frequency of direct online trading.
(e.g. once a quarter, once a day, several times a day). Those who are only into trading (e.g. once a month) may not be serious about trying something new, while those who are already trading full time may not find much value in tools aimed at newer traders. But those who work part-time as a trader may also take a keen interest in the company's tools. Number of product types traded: stocks only or stocks, options, etc
Futures Those who already trade all types of products may already prefer their own tools, but those who trade only one type may be willing to switch to others. DEFINE YOUR USER GROUPS
89
Level of professional competence (e.g. familiarity with the trade).
Conditions). Tutorials and glossaries help you determine how much help you need along the way. Level of technical understanding (e.g. familiarity with making purchases).
online and online banking and trading). This affects how much security they need in terms of privacy and how advanced or simple the online interface needs to be. You can prioritize these attributes as they can affect the type of users you target with your research. If traders' location doesn't seem to have any real impact on how or why they trade, the region attribute can be removed from the list as a consideration for research participants. On the other hand, if the importance of a certain attribute sparks a lot of discussion, it might be a good topic for a poll or interview question (we'll talk about polls later in this chapter).
Hoch
Comparing two or more attributes can also help you prioritize. For example, if you create a chart with two attributes for online retailers, you can see how groups fall into some ranges. Figure 6.1 is an example of a high-level user model that you can create using the two attributes frequency of instant transactions and number of product types traded. It also shows the resulting user groups that can emerge from the discussion.
Fulltime productspecialisten
Experienced full-time generalists
Frequency of direct trading
Second job dealer
Additional income trader
Active explorers
Long-term investors
Low
amateurs
Low
Hoch
Number of product types traded (stocks, options, futures)
90
CHAPTER 6: USER RESEARCH
Figure 6.1 A two-attribute diagram depicting a high-level user model. By making this model together, possible differences in user motivation and experience can be discussed.
This user model provides a general way to discuss different user types. It is not intended to be a definitive model and no exclusive user groups are identified (a user may be a long-term investor in stocks and also actively explore other opportunities in options or futures). But it expresses how you understand the different user groups and how they can be motivated to use your website. This discussion of important attributes will also help you figure out which attributes to focus on when recruiting users for research. If you determine that trading frequency is important and that the priority is to target those who currently have moderate frequency, you should define what "moderate frequency" means (e.g. one to three times per week) and recruit your research participants accordingly. Speaking of research, let's talk about techniques you can use to engage users in your project.
Can you only design from user models? In the user experience space, there is a discussion about building user models before doing research, as this can affect your thinking before you have real user data, and because your project team or project sponsor may see the model as a substitute for user research. Using a non-validated model puts you at greater risk that your assumptions are wrong. However, for projects where you don't interact with users at all, a well-designed model (verified with sources outside the project team, such as a customer service group or a training group) is better than not using a model during design.
Choosing Research Techniques Now that you have a rough idea of the user groups you want to engage, it's time to plan the next step: your recommendations for the amount and type of user research to be conducted during the project. Table 6.1 provides some information on the most commonly used research techniques and when they are often most useful. Use this chart as a reference to choose which are best for your project. The following section describes each technique in more detail.
SELECTION OF RESEARCH TECHNIQUES
91
TABLE 6.1
Common research techniques for users
ACTIVITY
WHAT IS IT
IF IT IS USEFUL
CHALLENGES
TYPICAL TIME SCHEDULE *
interviews with users
A one-on-one conversation with a participant who belongs to one of the site's main user groups.
There is user access, but the type of access (personal, phone, etc.) varies.
Get clear opinions. Gathering information about attitudes and context can be difficult, especially when interviews are conducted remotely.
2-4 weeks for 12 interviews: Up to 1 week for planning, 1-2 weeks for the interview and up to 1 week for collecting the results.
Contextual research
A site visit with participants to observe and learn how they work in their normal everyday environment.
The "Get Access" project team has only a few information participants. Reach out to the audience. Adapting to the user's environment can provide safety and mental health benefits for users who work in a unique environment (for example, in a hospital). Property and intruders work siveness. For companies with relatively complex applications, tasks or workflows. maybe easier to visit on a working day.
3-4 weeks for 12 requests: 1 week to plan, 1-2 weeks to observe, 1 week to analyze and report the results.
Questionnaire
A series of questions consisting mainly of closed answers (multiple choice) designed to identify patterns in a large number of people.
You want to be more quantitative about the results (e.g. "80% of the target audience said they never buy cars online").
3-4 weeks for a short-term study: 1 week to plan and write the study, 1-2 weeks to conduct the study, 1 week to analyze and report the results.
You want to get context, but you can't reach the user.
They are more interested in gathering information about preferences than actual performance.
92
CHAPTER 6: USER RESEARCH
Obtaining a suitable sample. Make sure the questions are well worded so you get accurate answers without giving respondents a specific answer.
TABLE 6.1
Common User Investigation Techniques (Continued)
ACTIVITY
WHAT IS IT
IF IT IS USEFUL
CHALLENGES
TYPICAL TIME SCHEDULE *
focus groups
A group discussion in which a moderator guides participants through questions about a specific topic. Focuses on uncovering participants' feelings, attitudes, and ideas about the topic.
The team expects that users' attitudes will have a major impact on how they use the solution (for example, if it has had issues with it in the past).
Understand how to target your questions to get the right information.
3-4 weeks: 1 week to plan and write questions, 1-2 weeks to lead focus groups, 1-2 weeks to analyze and report results.
sort cards
Participants are presented with items (for example, themes) on cards and asked to sort them into groups that are meaningful to them.
You are working on a content source page with many items and want an effective structure for your user groups.
Decide which subjects are best for shooting.
3-4 weeks: 1 week for planning and preparation, 1 week for conducting research, 1-2 weeks for analysis and reporting of results.
Usability testing
Users try to perform typical tasks on a website or application, while a moderator observes users' behavior and in some cases asks questions to understand them.
An existing solution is being improved.
Choose the right tasks to focus on.
3-4 weeks for 10 users and medium formality: 1 week to plan and write the assignments, 1 week to do the tests, 1-2 weeks to analyze and report the results.
Competitive solutions are available for testing. You have a prototype that users can use to perform (or simulate) tasks.
Moderate the group effectively.
Determine how formal the test should be administered.
* The typical time frame represents the time often required from the time of user scheduling. Two groups of six to eight users are assumed (except for surveys where the number of users should be larger). This does not include the time required for recruitment, which can take one to two weeks after the screening questionnaire has been prepared.
How many research activities can I include? Before deciding on any of the activities, ask yourself how much money and time the team can spend on user research. Consider the following situations to understand how interested your client company is in user research. If the project management and project sponsors are familiar with user research and are interested in using it for known purposes, such as ensuring the website meets specific project goals, then they likely have more leeway in choosing research techniques
93
when planning two or more activities, or for an activity that you will perform multiple times (for example, test a design, change it based on your results, and test the new design again). If no one in the organization is familiar with user research and there is some resistance to it, it may be better to propose a round of research and select the technique that you think will provide the greatest benefit to you, the project team, and the business stakeholders. Once you have the research results, the project team will have a better idea of what the project is about and what benefits the project can bring. You then have good arguments to include any further investigation at a later date. If you have room for at least two rounds of research, it is a good approach to include one round during the definition phase or early in the design phase to better understand users. Then, before starting development, add another round to validate the design. For example, with a task-based application, you can conduct user interviews before design and run usability tests on a prototype later in the process. At a content source, you can also start with contextual investigation and then include a card sorting exercise.
Considerations for planning research When planning research techniques, consider the following: Why you are doing the research: What you want to learn from it Who you will involve: The primary user groups you described above How you will attract participants: Recruit people to participate and screen them (i.e. ask questions to make sure they fall into the user groups you're targeting). How to reward participants. What space and equipment you need. What you cover: the main topics How you collect information: the number of people involved and the tools they use. Chapter 13 addresses all of these considerations as part of an in-depth look at one of the techniques most used by UX designers: usability testing.
94
CHAPTER 6: USER RESEARCH
Note See Chapter 2 for more information on task-based applications and content sources.
Browsing Steve Baty has written an article describing different methods and how to choose between them depending on your stage of development, your information needs and the flexibility you have in integrating user research. It is 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 are commonly used.
User Interviews User interviews are structured conversations with current or potential users of your website. These can be conducted over the phone, in person at a neutral location (e.g. a meeting room) or ideally in the environment in which the user expects to use the website. (The latter situation is also ideal for conducting contextual research, which is discussed below.) Interviews help you understand participants' preferences and attitudes, but they should not be used to make formal statements about actual performance. If you're looking for specific information about how people interact with a website, you can better watch them use it (for example, in contextual research) or ask them to perform tasks on the website (in usability testing). Site analytics can also give you insight into certain performance information that can be particularly useful when combined with interviews or questions that provide context for the data. The basic process For user interviews, the UX designer creates a list of questions aimed at obtaining information such as: Relevant experiences with the site or topic
SELECTION OF RESEARCH TECHNIQUES
95
The brand of the company perceived by the participant. settings e.g. B. to the subject categories covered (for a
source), the process to be designed (for a task-based application), or marketing methods (for a marketing campaign) Common goals or needs that drive users to your or another website
Competitors Common next steps users take after visiting the company's website Other people involved in the experience. For example, do one
Users tend to collaborate with someone else as part of the larger goal they want to achieve? Will they pass on information along the way or ask others for their opinion? Any other information to help you validate your assumptions
So far we've looked at user groups, such as whether the variables you discussed when creating a preliminary user model actually seem to affect how users experience your site. If more than one person is conducting interviews, it's a good idea to have a list of questions and a scripted introduction that can be used to maintain consistency between interviews. Determine in advance how structured the interviews should be. If you choose a formal report, you probably want a high degree of structure, where the order of questions does not vary widely and each question is asked with few additions. If richness of data is more important than consistency, you can opt for semi-structured interviews, where you start with a list of questions but let the conversation flow naturally, with the interviewer asking questions to further explore points of interest (so- called probing). ). The length of your interview may vary; 45 to 60 minutes is often the best recording range. It gives you enough time to build rapport and answer a wide variety of questions without tiring out your participant. User interviews provide a rich dataset that you can use to write the personas discussed in Chapter 7.
96
CHAPTER 6: USER RESEARCH
Interview Tips The quality of the information you get out of an interview is highly dependent on the quality of the questions you ask. Focus on the personal experiences of the participants. Don't ask them to speculate about what they might do in the future or what others might do. This kind of information rarely predicts what they will actually do. Do not ask questions that imply a specific answer or lead a participant in a positive or negative direction. Ideally, the questions should be simple, neutral and open-ended. Some examples of leading questions are: What do you like about PseudoCorporation.com?
This assumes that the user enjoys using the website. Only use this question if you also ask what you don't like about it. Does PseudoCorporation.com live up to your expectations?
This can be answered with a simple yes or no, which doesn't give you much detail to help you with your design efforts. Do you prefer to use PseudoCorporation.com or CompetitorVille.com?
And if the latter, why do you think they are better than pseudo? This poses some problems: two questions are asked in one statement and an implicit opinion is forced upon the participant. Better questions are these: Tell me about your last visit to PseudoCorporation.com. why did you go there What do you remember of your visit?
If you're conducting large, more formal interviews, you may want to include some multiple choice questions. However, in most cases you will not get very comprehensive information. They can be difficult for participants to follow when asked verbally, and they don't allow users to elaborate. In general, save these types of questions for screeners or polls. Take a test drive with someone, for example someone within the organization who is not part of the core team. This will help you discover questions that may not be obvious and also help you fine-tune the schedule and flow. If possible and the participant agrees, record the interview so that others can benefit from hearing the answers directly from the participant's mouth.
SELECTION OF RESEARCH TECHNIQUES
97
Contextual research Contextual research combines user observation with interview techniques. The UX designer goes to the participants, ideally to the environments where they are likely to use the site. For example, a contextual study in an office application requires the participant to sit at a desk. This method provides you with comprehensive information about the context in which a participant is working, including the real issues users face, the type of equipment they are working with, the room they are working in - especially the size of the room they are working with
have, how much (or little) privacy they have, how often they are disturbed, and how they use phones and paper (pay particular attention to any printouts they've posted or notes they have on hand). Your preference for using a mouse over a keyboard. This can have a big impact
Your design decisions, especially when designing a tool that requires a lot of data input. How they collaborate with others, both in terms of collaboration and sharing.
resources to use. For example, if more than one person uses the same computer, it affects how you design login and security features. Other tools they use, both online and offline. How people use paper
Particularly interesting - for some tasks it can be difficult to design an online solution that competes with paper! Observation time and interview time are combined for questions. They can last from a few hours to several days. If participants cannot spare at least two hours, consider simply conducting an interview. During an observation, the participant needs some time to get used to your presence and behave reasonably naturally, and that does not happen after 15 minutes. The basic process Prepare a 10-15 minute introduction to use with each participant. This contains the purpose of the examination, a general description of what you will do together (the observation and the hearing) and how the 98th
CHAPTER 6: USER RESEARCH
information is used. This is also a good time to get consent form signatures and to reassure participants that what they share will be kept confidential. Start with some general questions about the participant's typical processes, especially those relevant to the design of the website. Let the participant know when you are ready to stop talking and start observing. Observation can range from active to passive. In active observation, it is common for the participant to take on the role of master and you the role of student. The master explains what he is doing as if he is teaching you his process. Active observation often gives you more background information about why the participant is behaving, but it can affect how the participant works. With passive observation you encourage the participant to pretend you are not there. Your goal is to observe behavior that is as natural as possible. For example, if a participant is talking to you, they are less likely to answer a call or ask someone a question about a problem they are trying to solve. However, if you observe passively, you are more likely to notice. Then, during the interview portion, you can ask about the reasons behind some of the behaviors you observed. Both approaches can work well. In general, if you don't have a lot of time with the participants (e.g. only 2 to 4 hours each), you can opt for active observation to ensure you get the depth of information you need. If you have a full day or more to spare, passive observation strikes a good balance between natural behavior and discussion. Once you have information from your searches, you can search a lot of rich data! How do you recognize patterns or trends in your results? A useful method is the so-called affinity diagram construction. There are many great resources on this topic, but here's a brief description. A Quick Guide to Creating Affinity Charts Affinity charts are a technique in which a number of disparate and individual elements (such as user statements or researcher observations) are grouped together to form patterns and trends. Here are the steps of a simple affinity diagram session: 1. Gather the research team and their notes.
SELECTION OF RESEARCH TECHNIQUES
99
2. Give each person a packet of sticky notes and ask them to write a statement on it, along with a short code that allows you to associate that statement with a participant, e.g. B. his initials. Focus on statements that seem relevant to the design of the site, either specific (a statement about a specific topic) or more general (a statement that reflects the participant's attitude toward the company or topic). 3. Have everyone hang their sticky notes on the wall. If you're working on a large study, you'll need a large, blank wall. Try to get one that you can access for at least a few days. 4. Once all the notes are ready, start grouping similar statements side by side. This part of the exercise may involve the larger team. It's a great way to start sharing results. 5. As groups begin to form naturally, begin labeling the groups to provide further structure. If some sticky notes belong to more than one group, you can write duplicates and place them in any suitable group. Note: This method works well for contextual investigation, but it can also be applied in many other situations. For example, it's a great way to create categories together for unsorted topics, so you can push the results of card sorting into additional levels of structure.
Patterns can arise in many ways, so it's best to let them form naturally. However, here are examples of the types of categories you might see, including the type of statement you'd find in them: Goals: "I'm trying to resolve any unresolved issues here before I leave for today." Mental models (including statements that show how users are doing
Linking external experience to internal thinking): "I use this online tool as my suitcase for things I often refer to but don't want to carry with me." Ideas and Feature Requests: "I wish this would allow me to undo it. I like
I accidentally moved the entire folder and it takes forever to cancel.” Frustrations: "I'd ask the help desk, but half the time they don't."
also know where the problem lies.”
100
CHAPTER 6: USER RESEARCH
Solutions: "This is taking so long that I end up just printing it out."
read the list and work with it all day. At the end of the day I log the results.” Value Propositions: “This tool right here saves me a lot of time, so if you
changes don't take it away!”
Deep diving The core of contextual research is 'Contextual Design' by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also provides detailed information on how to interpret the results using techniques such as affinity diagrams. For more information on mental models and how to understand them, see Mental Models: Aligning Design Strategy with User Behavior by Indi Young (Rosenfeld Media, 2008). This is especially useful when working on the information architecture for a content source.
Polls are a series of well-defined questions that are distributed to a large audience. They usually consist of closed questions (e.g. multiple choice questions) that can be easily collected with a tool that can show patterns between the answers. Surveys are good tools when you want to report results in a more quantitative way (e.g., "82 percent of respondents who work from home say they have a high-speed internet connection") than you might think Be clear with the open-ended questions used in job interviews. However, they can also provide you with qualitative information about user habits and preferences. In the field of user experience, surveys are often used to measure user satisfaction (with existing websites or applications) or to create or validate user models such as segmentations or personas.
SELECTION OF RESEARCH TECHNIQUES
101
The Basic Process As with user interviews, you don't want to ask questions that force users to speculate. Don't ask, "If you had function X, would you use it?" Unlike interviews, multiple choice or yes/no questions are best and easiest to analyze afterwards. Participants can also respond faster. Use surveys when you have questions that are factual demographic requests, such as: Which of the following devices do you personally own? Choose all that apply. Computer game system for mobile phones, such as Xbox, Playstation or Wii
or for attitude questions with a range of different choices: Read the following statements and choose how much you agree or disagree. Pseudo Corporation customer service is responsive to my needs. Totally agree. Not agree, not disagree. I do not agree with it. Totally disagree
In particular, questions like the second example are often used in addition to usability testing tasks. You can use this type as a follow-up question to find out if participants were frustrated when completing a task. Participants do not always like to express a negative opinion, but are often willing to express one when faced with a rating system. This illustrates another point: surveys are an excellent complement to other forms of research you may conduct, such as B. User interviews or contextual research. The combination of two research methods provides a more complete picture of the user than either method alone can provide.
102
CHAPTER 6: USER RESEARCH
Browsing If you want a high degree of confidence in your results and have the budget to do so, there are formal user satisfaction metrics available in terms of user experience. These tools contain questions that have been tested to ensure they do not mislead or confuse a wide audience. Among the most commonly used are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and MeasureMent Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi.ucc. i.e
When planning a survey, keep the following in mind: Who are you targeting?
Use your preliminary model for this. How you answer the rest of the questions here will make a difference. Which way of distributing the survey gives you the best results?
If your primary user groups tend to congregate in a specific location, you may get better results if you go there and set up a table for people to take the paper survey. If your target audience is active internet users, an online survey for a large number of participants may be the best choice. Or you may decide that the best way to find your target audience is through phone polls of a list of current customers. How much time do participants expect to spend completing the form?
the research? If you provide some kind of compensation, or if the person gets some other benefit from completing it, you can usually create a longer questionnaire - one that can take half an hour to complete. If not, you need to keep it short to get people to fill it out - think 5 to 10 minutes. In any case, be sure to give participants an estimate of how long it will take and let them know their progress as they work on it (use page numbers such as "2 of 4" or indicate the percentage of work completed).
SELECTION OF RESEARCH TECHNIQUES
103
How do you know when to start analyzing the data?
You can run the survey until you reach a certain number of respondents or a certain deadline, depending on what the priority is. Which tool will you use to collect and analyze the data?
If you are conducting the survey online, the tool you are using to collect the data may have options for viewing and analyzing the results. If not, you need a method to enter the data into your tool of choice. For paper surveys, this means a lot of data entry, so be sure to plan for that time.
Focus groups Focus groups are about bringing different people within a target group together and having them talk to them. Common goals are gathering opinions on issues 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 reasons: Listening to different user stories. An open discussion is a great way to get things moving
Bring out the storyteller in all of us. When a focus group goes well, participants build on each other's stories and ideas, remembering situations they might not have in a more structured one-on-one interview. The grouping and energy can give people the time they need to remember and share these stories. Understand relevant experience differences. Most people are natural
ural information exchange and favorite tools to compare with others in their interest group. You often learn more about competitor sites or services, or get tips on workarounds, resources, and support. generating ideas. Even if you don't want to create the group yourself
As a designer, you often get great ideas for new features or designs either directly from the group or by hearing about their workflows or frustrations. As with stakeholder ideas, be sure to reduce them to the core need (see Chapter 4) to ensure that it is addressed. Understand different points of a collaborative process. If you are
When designing a process that involves multiple related roles and collaboration, groups can be a good way for you to fill in the gaps in your understanding
104
CHAPTER 6: USER RESEARCH
of how people interact with each other. For example, if you are working with a content source such as an intranet, it can be helpful to gather a mix of people who create, edit and use the content to identify areas where the process can be improved. There is a lot of discussion about using focus groups in UX research. It's not a good technique for usability testing (since users tend to work individually rather than in groups), and sometimes the group environment can have undue influence on what participants say. However, if focus groups are properly planned and moderated, they can yield many insights that are valuable to you as you design. Chapter 13 elaborates on this in the context of concept testing. The Basic Process When writing focus group questions, remember the same tips you would use when writing user interview questions (see above). Start with some of the simpler questions, such as "Tell me about your last visit to PseudoCorporation.com. Why did you go there?" Keep any questions aimed at generating ideas in the middle part of the group, when the participants are comfortable with you, the others, and the topic. Allocate blocks of time to each topic and stick to it; The discussions really get going and the time flies! If you are concerned about time, place your most important questions in the middle of the list of topics after participants become familiar with the activity, but before potential time constraints arise towards the end. Much of the logistics for focus groups will be the same as for usability testing. (Chapter 13 includes suggestions for screening, recruiting, and scheduling.) The main difference with focus groups is that you need a larger room with a table where participants can easily interact with each other. Shoot for six to eight people per 1-2 hour group session. Give each person a name tag or place card by their seat so everyone can address each other by name. The format of the discussion itself should include an introduction that often covers the following main points: your role as a facilitator and what you expect from the discussion.
Discussion (e.g. some of the above points).
SELECTION OF RESEARCH TECHNIQUES
105
Why participants were selected to participate (e.g. "You are all
current users of the Pseudo Corporation website, and we've brought you together to hear about your experience"). How that information is used - both in the design and in the
confidentiality position. That you as a moderator are there to hear their views and opinions
Experiences. They want them to feel like they can share fairly. So ask individuals to be straightforward, but also respectful of others in the group. That there are many topics that need to be covered, so that at some point you
Discussion on a topic to ensure you can cover all topics. This can then result in an introduction round for the group members, often with a kind of icebreaker question. Your goal is to get everyone talking about the first question, even if they're just telling a short story. You can start with one person and work around the table, or let people answer naturally and then name the people who didn't answer. Often you sit around the table for the first few questions, and when you feel the group is ready, you can use body language to make the questions clear to everyone.
Snorkeling: Body Language A good understanding of body language can be a great tool when facilitating focus groups or personal user research. It can help you understand when someone is feeling frustrated, upset, angry, or threatened so you can determine when to try to put someone more at ease or follow up on a particular comment. It may take more than a weekend to fully read the following book on this topic, but it is designed to be easy to flip through: The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).
If you call someone who hasn't answered yet, make sure to repeat the question if they didn't understand or weren't listening
106
CHAPTER 6: USER RESEARCH
few statements in the discussion. Also, make sure that a disagreement doesn't look like a disagreement between two people. Don't say, "Bob, we haven't heard from you. What do you think of what Chris just said?" but instead (looking at Bob): "What about you, Bob? What is your experience with the Pseudo Corporation's customer service?" As a moderator, you control the course of the discussion and pass the virtual microphone. You maintain control over eye contact, speaking volume, arm movements, and body position. Most people are very aware of their body language, and these cues can be useful signals when someone is taking over the conversation. If an overly vocal participant doesn't understand these cues, use a gentle but firm statement such as, "Okay, great, I'd like to share that thought with others." Has anyone else had the same problems as Theresa? larger topic, verbally announces that the previous discussion is over and a new one begins, so that participants can clear their minds for the next topic Finally, as the activity nears its end, a simple glance at the clock and a change indicate in your demeanor that the conversation should be ended. As with any other activity, thank the group for their time. Sharing findings with your team is usually done in two ways: findings are broken down by the main topics covered, or grouped in relevant categories, similar to contextual research. Affinity diagrams can be another effective way to bring together and illustrate different trends and attitudes to the project team.
Card sorting In a card sorting activity, participants (working individually or in small groups) are given items printed on cards and asked to divide them into groups that make sense to them. They group them into previously specified categories (called closed sort), or they form their own groups and name each group themselves (called open sort). At the end of the card sorting round, you should be able to identify common patterns in the way people sort items, as well as common areas of confusion or disagreement.
SELECTION OF RESEARCH TECHNIQUES
107
A common reason for this is to create a sitemap for a website or create a hierarchy of content, categories, and subcategories with items such as articles, documents, videos, or photos. This makes card sorting a great technique when working on a content source. Note See Chapter 2 for more information about content sources.
Let's say you're working on a common type of content source: the corporate intranet. Many intranets tend to categorize their information by the department that owns it, with navigation to Human Resources, Operations, Legal, Marketing, etc. For long-time employees, this may not present an obvious problem , as they have probably learned the responsibilities of each department and developed a good understanding of where to find information. But for new hires, or those who need information they don't normally refer to, it can be difficult to find information that belongs (or appears to belong) to more than one department. For example, where can you find guidelines for signing contracts with newly hired employees? It could fall into the legal department or the human resources department. Card sorting helps you find common patterns in how potential users would categorize information, regardless of department lineage. The basic process Gather the items you want to include in the card sort. 40 to 60 is usually a good range. You need enough to potentially create a large number of sets of cards, but not so many that participants become overwhelmed with options (or overwhelmed when you need to analyze the results). Choose items that you think are easy to understand and don't contain unnecessary jargon. You can include some technical terms that you think your user groups are likely to know, but avoid using too many "insider" terms. Using too many company-specific terms or acronyms (for example, "the SUCCEED campaign" to increase sales) tests the effectiveness of the company's marketing and communications rather than building a common hierarchy of information. For the intranet example, you can include the vacation policy, 401(k) plan information, a rental agreement, a vendor agreement, a non-disclosure agreement, and so on.
108
CHAPTER 6: USER RESEARCH
New hire orientation, health insurance information, and computer security guidelines. This list is a mix of well-worded items that can be categorized in a number of ways. You may have one participant who lumps new employee onboarding and holiday policies under Human Resources, and you may have another participant who lumps new employee onboarding and new employment contract together and calls it Employee Onboarding. Once you have your list of items, place them on cards that are easy to group and ungroup. You can print labels and stick them on index cards, or print directly on perforated card sheets to separate them into individual cards. Do a trial run by asking someone to sort the cards into groups and name the groups, such as putting a post-it on top of the deck and writing the name on it with a pen. Ideally, your test taker is someone unfamiliar with the objects and activity. This gives you a rough idea of how long the activity might take. If the test run takes longer than an hour, you may need to cut out some cards! Once you have a complete deck, bring in a real participant and give the following basic instructions: 1. Arrange these cards into groups that make sense to you. 2. Try to have at least two cards in a group. If a card doesn't seem to belong to a group, you can set it aside. 3. You can choose a name for a group at any time during sorting. At the end of the activity, name as many groups as possible. Some trends are already visible when observing the sessions. Others may need a little more analysis to bring them up. There are several tools for entering and analyzing card sort results; Many of them have tools that allow you to perform remote card sorts (see the Card Sort Variations section below for more on this). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) offer both remote sorting options and useful analysis tools. Or, if you want to do your own manual sorting, check out Donna Spencer's excellent table complete
SELECTION OF RESEARCH TECHNIQUES
109
with instructions, available at www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet. Card Sort Variations Until now, the discussion has focused on a card sort performed face-to-face with a person, where the participant was asked to name the categories they had created. This is an open sort, which means that the main categories are not communicated to the participant, but can be named. This is a good approach when setting up a new navigation structure or making significant changes to an existing one. For other situations, consider these common card sort variations: Closed sorts. In a closed sort, you specify the parent categories
and the participants contribute to it. The results are relatively easy to analyze because you only have a small selection of possible categories and you can focus on understanding which items most often fall into which categories. If you're adding large amounts of content to an existing information architecture or validating an existing sitemap, closed sorting can provide quick and actionable information to help you with your categorization decisions. group types. Instead of sorting the items into groups individually, you can do this
Make card sorting part of a focus group activity where participants work together to sort items. While the results don't necessarily match how a single person would group the items, you can gain a lot of insight into how people feel about the items and their organization by listening to how they share the activity work and discussing the reasons for each placement. remote species. Especially sorting with physical cards can be a fun activity
for group sorting. However, there are many great tools for doing sorts with individuals online. This also allows you to reach a larger number of participants or specific participants with whom you are physically difficult to reach. The OptimalSort and WebSort tools mentioned above are two of the tools that simplify this kind of online sorting.
Usability testing In usability testing, participants are asked to perform specific tests on a website or application (or a prototype thereof) to identify potential usability problems and come up with ideas to solve them.
110
CHAPTER 6: USER RESEARCH
You can run usability tests during the definition phase if you want to gather information on how to improve the current site. Or you can do it on similar websites (eg competitors' websites) to understand some of the possible possibilities for a more user-friendly solution. Typically, usability testing is performed as part of the design phase, ideally in iterative rounds (where a design is created, tested, refined, and tested again). We'll discuss usability testing again in detail in Chapter 13, "Design Testing with Users." This chapter provides recruiting and planning tips that can also help you accomplish the activities discussed earlier in this chapter.
After the research After you've completed one or more of these user research activities, it's time to rethink the assumptions you originally made about your user groups. Put those assumptions aside for a moment and ask yourself what user groups you would create now that you have more information. If some of your previous assumptions were not true, consider any gaps in your user research because a key group was not included. If this gap is identified early enough in your research activity, you may have time to adjust and add another group of participants to the ongoing research to ensure you get a complete picture. With your new knowledge, you can revise your custom definitions to more accurately reflect the groups that should be the focus. This allows you to create more detailed tools such as personas (see Chapter 7) and create user requirements for the requirements list we started with in Chapter 5. With users, you follow a similar process: your work doesn't stop when you commit the idea or request. Figure out the basic needs and goals to make sure you understand them. Ultimately, this will help you design a solution that best meets this need for all relevant user groups. In the next chapter, you'll learn how to use the insights you gain from conducting user research to create tools that put your user groups at the center of design and development: personas.
AFTER RESEARCH
111
7
Personas find the best way to put your team – or your client – in the shoes of your users. Personas are often a topic of discussion among user experience practitioners. Opinions vary on how much content is needed, how much research is needed, and whether they add value to projects. Some people wonder whether they belong to the process or not. Regardless of where you position yourself, personas can be used to help your project team and your client empathize with their users. Personas can provide a gut feeling for many parts of your project - business needs, visual design, or quality assurance - by providing insight into your audience's identity and their expectations and behaviors. Russ Unger
67
What are Personas? Personas are documents that describe typical target users. They can be useful for your project team, your stakeholders and your customers. With proper research and descriptions, personas can paint a very clear picture of who is using the website or application and possibly even how they are using it. User experience designers often consider creating personas a great exercise in empathy. Well-crafted personas are often used as a focal point when questions or concerns arise about how aspects of the project should be designed. You can pull out your personas and ask, "How would that go?"
This chapter focuses on interactive personas.
Why should I create personas? In the user experience design process, personas help you focus on representative users. By providing insight into the "real" behavior of "real" users, personas can help resolve conflicts that arise around design and development decisions, so you and your team can continue to move forward. How real should personas be? The answer is very different. A single persona document can be enough for a team, while another can create entire "living spaces" for the user personas to allow them to deeply understand how they "live". You can even go to the extreme and create custom online presences that you can interact with to gain insight into online behavior. How you expand your personas is up to you. Personas can be a constant reminder to your users. A helpful technique is for your team members to keep personas in their workspaces. That's how they are
WHY SHOULD I CREATE PERSONAS?
113
are constantly reminded who their users are. Sharing a cube with "Nicolle," the 34-year-old board-certified hand therapist from West Chicago, Illinois, for a while, you feel the need to provide her with an experience that's right for her. If it helps you, you can also carry the printed copies with you while you sleep and allow the osmosis fairy to enter your slumbering subconscious from the sides through the pillow. The purpose of personas is to help you, your team and/or your clients take away some of the confusion that can arise when you are at a decision-making crossroads.
Finding information for personas Effective personas should accurately represent a set of specific users of your product or website. To achieve this goal, personas need to be supported by research. Chapter 6 introduces techniques for researching and modeling your potential users to create a solid foundation for your personas. Don't look for a single method as an answer, though; It is best to find as much data as possible and combine it with a combination of observational and interview data - this may include the use of online surveys and analysis of social media behavior. It's a common theme when creating personas: keep real data, but make the personas real people on the pages. To learn how one company achieves this, see the Case Study: Messagefirst Personas sidebar.
Creating Personas Once you've identified your audience and gathered data to support your personas, your next step is to put pen to paper and bring them to life. How many personas you need to create varies. In general, the minimum is three, but more than seven is not uncommon. Rather than aiming for a specific number, consider how many target segments you have and how best to represent them.
114
CHAPTER 7: PEOPLE
Case Study: Messagefirst Personas To create effective, data-driven personas, Messagefirst (www.messagefirst.com) uses no fewer than three different data entry sources, relying on the following: Stakeholders. We interview them to find out who they think the personas are and what they think their behavior is. This is always included. Client's lawyer. We interview people in the company who speak directly to customers, usually sales/marketing and customer service. Each of these has its bias, which we take into account when documenting our findings. For example, the most common people to contact customer service are those who have too much time on their hands (often retired or unemployed) or someone who is so angry about a product or service that they actually take the time to contact you . Customers. We speak directly to the actual people who will use or are currently using the product or service. This will be included where possible. Customer data sources. We review all available blog traffic, polls and emails available to us. someone we know We choose someone we know who fits the initial profile of the persona. This helps us keep our feet on the ground, ensures that the persona is believable and realistic, and provides a real person to turn to if we have any questions. This is very important for validation and is always included. Because each data input source we use has some bias, we use multiple sources to normalize the data. With data-driven personas, it is important not to expect how many personas you will have, but to show the data how many personas there should be. When analyzing the data, I look for gaps in behaviors and activities. These gaps reveal the individual personas. Todd Zaki Warfel, Chairman, Messagefirst
The sample person for this chapter is Nicolle, a 34-year-old certified hand therapist from West Chicago, Illinois. She happens to be an unguided commuter who commutes two to three hours a day to and from work. The fictional customer is a company called ACMEblue, a maker of Bluetooth headsets for Apple's not-so-fictional iPhone.
CREATE PEOPLE
115
This short paragraph tells you a lot about Nicolle, but as you can see in Figure 7-1, the actual persona contains a much more detailed story about Nicolle. Note that the content is written about Nicolle, not "by" Nicolle. It's best to write your personas from other people's perspectives and don't bother writing with their different voices, especially if you're just starting out. Of course, as you expand your experience, you'll need to explore and find the style that best suits you and offers the most benefit.
Figure 7.1 Persona for the fictional customer ACMEblue
What information goes into personas? The kind of information that your audience finds relevant and credible is what matters. The research data you collect should help you determine what's important to the client, the brand, and the project. Most personas you create will have a common set of required content mixed in with an amount of data, statistics, and other relevant information that can be considered optional as it varies from client to client, if not project to project.
116
CHAPTER 7: PEOPLE
Minimum Content Requirements When creating personas, you need to provide enough information to grab people's attention and connect them to the person they're reading about on the page. To help your audience understand how your persona behaves and thinks, include six key pieces of information: photo, name, age, location, occupation, and biography. The next few sections explain how to fill in the details for each item. Photo A photo is the first (and the real) step to putting a face to your personality. When choosing a photo for your personality, make sure the image doesn't look exaggerated or polished. Photos that look posed won't have the same effect as photos taken in a more natural setting. Personas seem to be more effective with photos taken in a more natural environment, such as the one on the right in Figure 7-2, where the person is standing outside in their winter coat, possibly on their way to work. Make sure the photo fits the person's lifestyle! Posted
Natural image 7.2 Natural looking photos are more effective.
There are several photo sources online. Better options are iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com), and Stock.XCHNG (www.sxc.hu).
CREATE PEOPLE
117
Finding the right photo can be a real waste of time if you're not careful. If all else fails (or if you have the time and budget), make your own! Name Simply put, you need to name the face. The photo you use will humanize the mix of research data and personality traits, and the name will serve as how everyone relates to you in discussions. Not only does Nicolle sound better than "Mid-30s Blonde Professional Mom," but it's also a lot easier to remember and relate to a specific person. Try not to make the names you use for different people in a project too similar. Nicolle and Noelle, for example, can be easily confused, so keep an eye out for different names. While it may be tempting to use the names of colleagues or clients, you shouldn't. If you use names that are similar or identical to those of the people involved in the project, they can easily try to identify themselves in your personas. Choosing different names prevents awkward situations or hurt feelings. If you're having trouble choosing names, a few online resources can help: Baby Naming Websites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Popular Social Security baby names: www.ssa.gov/
OACT/baby names generator for random names: www.kleimo.com/random/name.cfm
One last thing about names: make sure your name is believable to the person. Nicolle works well for a Midwestern mom, but Nicola or Natalia might be a much better name for an Italian mom. Nor are names that seem a bit funnier or livelier, like Bob the Builder. They tend to make your personas look silly and can detract from their value. Age While your research should identify the age range of your consumers, providing a specific age for your persona will help add authenticity to the biography you write. The behavior of a 21-year-old student and a 34-year-old working mother is clearly different!
118
CHAPTER 7: PEOPLE
Location Location doesn't seem like important information at first glance; However, it is important to remember that cultural and behavioral changes can occur from place to place. For example, in Italy, different dialects are spoken in different regions of the country. In the United States, a person living in Chicago will most likely have a different cost of living than a person living in Savannah, Georgia. Occupation If you know your person's occupation, you can identify with them by relating to the patterns of their daily lives. Someone who works in therapy may encounter many people on a daily basis, while a drawbridge operator may not interact with others much. Biography The biography is the compelling story that makes the person real. This is where you provide details you pull from your research data and fill them in with a few "real people." That is, the dates are very important to the persona, but you don't want to just quote that information in jerky sentences. Instead, you want to tie data, anecdotes, and observations into a story your audience can relate to. It may seem a little strange, but the biography should be believable and it's definitely not cheating to incorporate aspects of a real person into your character. Nicolle, for example, is based on both statistical data and the very real behavior of a person who shares similar activities, beliefs, and desires. Depending on your project, you may need to dig pretty deep into the biography - sometimes the more detail you have, the better. You don't feel like you have to squeeze your personality onto one piece of paper. Decide what works best to make your persona as realistic and meaningful as possible for the project you're working on.
Optional Content As you work with personas, you will find that different projects require different sets of information to make the personas more applicable. The minimum content requirements can also be considered the least common
CREATE PEOPLE
119
Denominator of most personas you will create. In most cases, you will fuse some of these optional pieces of content into the core of your personas. One of the optional content that can add value to your personas is education level. Knowing how educated a person is can go a long way
more insight into some of their habits. A person with a high school diploma may have significantly different buying habits and brand perceptions than a person with a master's degree, and this information can affect how you are perceived. salary or salary scale. It's all about money and in many cases quantity
A person's income has a significant impact on their standard of living and disposable income. This information can provide important insights in the pursuit of certain levels of wealth. personal quote. What motto would your persona claim?
than their own? Sometimes this can provide a quick overview of the core mindset of your persona. online activities. This can get difficult; There are many ways people spend money
their time online. Some people pay their bills, others are heavily involved in blogging and social networking, and still others simply use their computers as a device that turns on when they need to get a job done. Since so many projects have an online component, this element is a judgment of sorts. You have to base your research to draw the picture. off-line activities. Does your person have a hobby? Are there additional
Information about what your life looks like when you're not online? This element can be just as tricky as online activities and can be just as important in influencing your personality. Key entry or trigger point for the customer, brand or project. Often it is important
to understand how a persona interacts with the customer, brand or project. Does the person find out about it through word of mouth, online reviews, a billboard, on TV or radio, or through an online pop-up ad? Is your persona looking for the solution to a problem that can be addressed by the customer, brand or project? Using your stats to understand this point and incorporate it into your persona can help inform your approach to engaging users.
120
CHAPTER 7: PEOPLE
Technical comfort. Does your persona use a PC or a Mac? Is she
Do you even have a computer? Does she use instant messaging, flickr or blog? Is she very comfortable with this activity or is she confused by it? Would a very simple solution aimed at a beginner help her? Does she have an MP3 player or other portable device? Does she use a DVR or AppleTV or an on-demand program to watch TV? The list can be continued endlessly. And further. Depending on your client, your brand or your project, it can be important to identify these and many other terms. social comfort. Given the growth of social media and social networks
At work, it can be important to establish exactly how your persona engages in that particular area. Does she have a twitter account? If yes, 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. As the use of mobile devices continues to increase
In general, it's important to think about how your personas position themselves in the mobile space, if at all. Motivations to use customer, brand or project. In some cases you may want to
to indicate the reasons why the persona wants to use the client, brand or project. If the cord on her headphones keeps getting caught in her coat and pulls it off her head, that could be a good reason for her to think about a new pair of headphones. Real-world scenarios based on research data can help uncover key drivers to include in your personas. user goals. You may also want to know what the persona is trying to achieve
achieved through the use of the customer, brand or project. This can help to understand 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 endless ways. If you're interested in delving deep into the world of personas, a good 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).
CREATE PEOPLE
121
Advanced personas Once you understand the basics of creating personas, there are endless ways to improve your documents. A simple persona can often meet most of your needs, especially if your project team is just trying to get an empathetic understanding of your users. It usually gets more interesting when you present personas to your customers. In such cases, you will often find that you need to provide much more than the information you have collected for the base person. Figures 7.3 through 7.7 illustrate some ways you can expand personas. Feel free to borrow, remix, and mix these samples to create something even better for your project!
brand name
Meet the brand consumers
PERSONS 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 but realistic stories that describe why these personas might visit the brand's website and what they would do there.
Joan, 32 Consumer insights help us understand users - their motivations, goals and desires. To apply these insights to website design, we develop user personas and scenarios based on real-world contexts. This design approach helps create rich experiences based on understanding customers, their motivations, desired outcomes, and behaviors. In particular, scenarios answer three fundamental questions that must be answered before a website can be properly organized:
Pleasure Seeking Lovers "I'm Really Enjoying This" "Young Sophisticate"
BEGIN
START EXPLORING
BUILD EXPERIENCE
"Incoming Freshmen"
"$)*&7&-&7&- COMFORT
"Activate answering machine"
FEEL 5)&365
DISCOVER IT AGAIN
"Established Explorer"
OPTIMIZATION AND SIMPLIFICATION
"Growing Up in a Groove"
Practical get-things-done "It just has to work"
Alice, 26
Rachel, 42
Erik, 47
Greet, 59
Figure 7.3 Persona overview master sheet (landscape). Provides an aggregated view of multiple personas along with the segments they represent in the context of an overall organizational strategy. Thanks to Will Evans.
122
CHAPTER 7: PEOPLE
brand name
PEOPLE AND SCENARIOS (based on ethnographic studies) Alice is a budding chef who wants to explore the world of food.
GOALS
especially kid-friendly eating, with friends, and by searching for new recipes online and in magazines. Their exploration is about more
She can support her family without much thought or effort
fantasy as reality. She is still intimidated and does not
Find quick, easy recipes with basic ingredients
Trying too many new recipes. Her mother didn't teach her much cooking and her friends didn't have much experience
Prepare (often) two types of meals: for adults and for children
also cooks. Alice is a busy mother of a daughter in Chicago. Both she and her husband work outside the home - she runs the office of a small insurance company.
Married to Alice, 26 "Aspiring Novice" Gen x
1 daughter, 5 tired, ambitious
income
Course
She is busy, practical and does not spend much time cooking. Alice just wants to get it done quickly and easily - although she often has to cook several meals for herself and her husband since she started exercising two years ago after giving birth to Sophie and is trying to get back into marathon shape. She works with a small number of successful recipes that she feels comfortable with and many of the meals she prepares are packaged and prepared food-based.
SCENARIO Alice is having breakfast while Sophie is watching Cartoon Network. A brand commercial appears here with a brand name. Alice uses a brand and thinks Sophie would choose this dish. She decides to check out the site from work. Alice visits the site for a free half hour before a meeting. The homepage is clear and well-arranged. She sees the most important parts of the site and links to interesting things, such as a recipe of the day.
internet use
Health consciousness
cost sensitivity
She clicks on the recipe of the day. She loves the tips in it - they make her feel like she can handle this recipe. She enjoys the clear navigation, unlike other sites where she tends to get lost. She likes the useful features beyond what she sees in cookbooks, like the ability to find recipes based on what's in her pantry and tips on how to use the products. Alice discovers she can receive recipe newsletters and clicks subscribe. Registration is so easy! She fills in some basic information and selects the Food Your Kids Will Love newsletter.
She wants to put her own spin on it even more and recreate dishes she likes to eat in restaurants, like her all-time favorite, jerk chicken. She would also like to add more fresh vegetables to her meals because she knows they are healthier. She prides herself on being a thorough planner and able to run her household on a budget. Her refrigerator and pantry are always stocked. She plans her purchases to take advantage of special offers and coupons.
Find kid-friendly recipes and mealtime activities. Find ways to spice up their favorite ready meals. PROJECTS & INITIATIVES. Improved navigation and information architecture. Improved login
A week later, at lunch, Alice finds her first brand newsletter: "Pizza, easy as 1, 2, 3." Perfect - her kids love pizza and she usually buys them frozen pizzas. There is a link to Pizza for Beginners that inspires her to see if she can make pizza herself. The link will take you to a recipe for pepperoni pizza on something called "Pizza Wizard". She scans the recipe and realizes 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 replacing them with things she has in her well-stocked kitchen: sausage and tomato sauce. And ideal! There is a link to a coupon. Neena prints out the recipe's shopping list, adds a few things she also needs, and heads to the store. Alice comes back from the shop and goes to work. She sees step-by-step instructions for rolling out the dough and adding the ingredients. There are pictures at every step. It is easy to understand and follow. She wonders if she should cook the toppings first, but the pizza FAQ answers that for her.
Contextualized peripheral information, more targeted newsletters, recipe assistant, better coupon integration, MEAL PLANNING. The "Ready" setting relies heavily on ready meals, with relatively few fresh fruits and vegetables. Spends more time browsing recipes than cooking them
Figure 7.4 Audience personality (landscape). This detailed view of an individual encompasses a broader spectrum of data and provides a more comprehensive perspective on users' goals, needs, and behaviors, all within a larger ecosystem. Thanks to Will Evans.
Figure 7.5 Audience overview and audience personality (portrait). The goals card on the left provides high-level summary information that shows the brands the three personas interact with and interact with. The detailed description on the right provides an overview and biography of a person, along with information about their behaviors and motivations.
ADVANCED PEOPLE
123
Paul and Helen “I think we can put everything there. I just don't know how much fits in it."
5 4
Helen's mother passed away a few weeks ago and they are cleaning up the house. They plan to sell the house, but there are still some things they need to clear up first. The house also needs some renovation in the main bathroom.
3
- or en The basement is full of things that Helen's mother has collected over the decades. She never threw anything away. She owns newspapers and Time magazines for the past 20 years. There are a few things Helen wants to keep. Most of the clothing, clothing and furniture is donated to Goodwill. Unfortunately, most of her mother's lectables have been damaged by water and mold. She also has cans of paint, but Paul and Helen don't know if the paint contains lead or not.
2 1
D
An
ain
Know Ex led pe rie nce C on Pric ve e Senior tunc pe sp Re e M pu e d ult type Timtion C on eline t Main ss ajo er r L Sizes D E ecven lutte t Year R ing pe Waste Rate in Buars dsine Prijs en O Recam nlin ycline ac g count
This is the first time Paul and Helen have experienced something like this. They don't even know where to start. You just want it to be as simple as possible. They know they need a dumpster, but don't know how much is in it. And they assume almost everything belongs in the dumpster unless someone tells them otherwise. Their only other concern is that dumpsters are often ugly. They hope to find a company that won't make the front yard look like a construction site or ruin the yard when the dumpster is delivered or picked up.
Range: 24-65
Life cycle Jan
July
Dez
Month
1.0 life event
Main features Ŕ Ŕ
One-time event, such as the acquisition of family property or a minor renovation (e.g. bathroom). Little or no experience with purchasing a waste container.
tore
Quickly get a dumpster. Get rid of anything they don't keep or donate. Avoid destroying property in the process. Avoid an ugly dumpster. Dispose of the waste container quickly once it is full.
Frustration and pain points Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ
Fragen Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ
oh
Available if desired. Price. The seller leaves the property as he found it. He has the required container size available. Fast installation and collection after contact. Online account access for scheduling and payment. Quality and cleanliness of equipment. Famous brand
Ŕ ŕ ŕ ŕ
First sticker shock. Unfamiliar with the process. I don't know what they don't know. An apples-to-apples comparison is made between the providers
Is something not listed? How fast can you deliver and pick up? Will the house be left in its original state? How does this work? Is a permit required? How much is it? How easily can I reach someone if necessary?
Figure 7.6 Target group persona. This persona represents an age target derived from research data. The information it contains is broad and appeals to a target audience, not specific individuals. This approach can be useful when making a business proposal or when the client's budget allows detailed exploration of the personas. Courtesy of Todd Zaki Warfel.
The all-rounder
Amanda Steen
5
"I need to manage multiple programs for my clients."
4
3
AMANDA SHARE RESPONSIBILITY OF THE INCENTIVE PROGRAM WITH SOME OTHER COLLEAGUES. They share access and manage multiple programs for clients. Making sure she pays the right people for the right program can be extremely difficult. She must be able to switch between the different programs and always know where she is.
2
1
life cycle
Key Features
Manages multiple programs. Medium to large company. Average volume (50-2,000 orders at a time). Several people share one role Heavy Excel programs use a custom internal system as an interface
Tore Ŕ Ŕ Ŕ Ŕ
Integration with the current system. Ability to pay employees quickly and easily. cost (mainly time). guided assistance.
Other applications - Excel - PowerPoint How do I run reports in all my programs? Ŕ Internet Explorer Is there a way to get my credentials without calling Ecount? Is there a way we can integrate ClientZone so that we don't have to switch back and forth between different applications so often? Am I doing this right?
Ac FT N c ew ou P n Cart Zo d Re ne quest t E Ad asys m Pain y C he c R Cu ep ks of rr en rting tB al Pe an ce Cu opl e st om Soft Sy Stamm em Ex ce ik
nc e
jan
Influencer
Pay employees quickly and easily. Ŕ Avoid duplication. Ŕ Check their checking account balance to know if they need to transfer money. Ŕ Track transactions weekly, bimonthly, monthly, quarterly and yearly.
rie
in one go
Au
Die
dg
dg an ow Kn
Kn y
etc.
An
hn
D
She uses Account Zone fairly regularly, several days a week. And since she runs multiple programs, she's pretty active all year round.
activities and interests
Te c
Range: 28-55
e
e
Know
ain
Account Zone really helps her issue new cards and make sure program participants get paid quickly. The only thing missing is the ability to look at each individual program, as well as all the programs that are running, to see how it's going. Your customers want to track how the programs are performing. At the moment she keeps track of this in Excel. In the end, she sends the Excel file to her clients or sometimes she exports it and sends a PowerPoint file with some nice charts in it. If Account Zone had a way to enable it to run reports on individual programs as well as across multiple programs, that would be really great.
July
Ŕ ŕ ŕ ŕ ŕ
R
R
R
R
Month
frustrations and pain points
To ask -
Dez
It is not possible to display several programs at the same time. Reports cannot run for multiple programs at the same time. Correct errors in the receipt file "stinks". It is not clear where exactly the problem is and how to solve it. Multiple steps with multiple applications is not efficient and makes it easy to "get lost" where it is. Multiple confirmation screens. Another username and password to remember. I am looking for an email with their login details.
Figure 7.7 Individual persona of the target group. This persona is a strongly data-driven model. While the mundane story is narrative, the rest is listed in bullet points to serve as a design checklist. The diagram is used to communicate a large amount of information in a small space. Courtesy of Todd Zaki Warfel.
124
CHAPTER 7: PEOPLE
As you can see, you can combine data in many different ways to present and adapt personas to different situations. Start with the basic persona and expand it according to your needs.
Final Thoughts on Personas Many practitioners in the world of user experience design don't believe that personas are good at articulating users' needs, goals, and attitudes. They believe that personas can hinder creativity, innovation or good design for many reasons. Other practitioners believe that when personas are based on solid research data and mixed with a dose of personalized reality, they fulfill a specific need that very positively influences the design process. Which side of the coin you end up on is entirely up to you. This chapter is not intended to influence your decision in any way. There are countless articles available online on the subject and plenty of professionals are ready to give you their opinion. All of these resources can help you figure out how personas work best for your projects. So look for it. Jared Spool, CEO and founder of User Interface Engineering (www.uie.com), also offers some insight into the topic: This value is created when the team visits and observes their audience, absorbs and discusses their observations, and reduces the chaos into patterns, which then become the personas. What the team has in mind when designing will make all the difference in the final design. The persona descriptions are just there to remind everyone what happened.
Jared's point is simple: by observing your audience, augmenting what you've learned with research data, and breaking it all down into segments, you should be able to create personas that elicit the kind of empathy that will keep your team on track and the best possible application, website or product. Ultimately, though, your personas will be like Santa Claus: they're only valuable as long as people believe in them.
FINAL THOUGHTS ON PERSONAS
125
8
User Experience Design and Search Engine Optimization The Fundamental Role of User Experience Design in Successful SEO Search engines are the cornerstone of the interactive economy. Everything we do as "interactivists" ultimately connects to the rest of the world through Google, Yahoo, MSN, Ask, and the myriad smaller search engines that provide the infrastructure for online search. Information architecture is a crucial part of how websites are interpreted by search engines. This chapter aims to give you a basic understanding of why UX design is crucial to search engine optimization and what you need to consider to ensure that the environments you create stand a chance on Google. Jonathan Aston
67
Introduction to SEO Simply put, Search Engine Optimization is the process of developing and maintaining a web asset to achieve and maintain top rankings in public search engines for targeted keyword phrases. Search engine optimization (SEO) is like a martial art, a never-ending process of learning and doing. Even a master can progress through observed behavior or learned methods. As long as there are search engines and websites interested in selling something to searchers, search engine optimization will matter. SEO is based on three fundamental areas of improvement and influence: The critical set of things that the professional user experience designer considers
may affect the infrastructure, technology and organizational principles of the website. Content and any keyword issues related to optimized words that
The search engines can see links or link popularity - the quantity and quality of links pointing to you
Site of other sites and the organizational structure of links within the site. We'll take each of these three areas apart and examine them from the UX designer's perspective to better arm you for the optimization challenges ahead.
Why is SEO important? It is interesting that even today we still need to explain the relevance of search engine optimization. Customers tend to understand to some extent the importance of their websites attracting targeted visitors from the natural search results of the major search engines. However, beyond that, it is difficult for most interactive marketers to understand the implications of SEO. Global search volume data is available from a variety of sources. However, the most important thing is to understand that regardless of the source, the numbers are simply huge and the year-over-year increases are always in the double digits. Typically, global search volume increases every quarter. When Google first launched in 1998, 10,000 searches per day was a huge volume and put incredible strain on the beta version of the system.
INTRODUCTION TO SEO
127
Hitwise (www.hitwise.com) reports that Google and its subsidiaries (including AOL and YouTube) account for the lion's share of searches worldwide, with nearly 72 percent of searches in the US in November 2008. Yahoo is a distant second with almost 18 percent, followed by MSN and Ask.com with 4 and 3 percent, respectively. Internationally, Google is even more dominant: its market share is more than 80 percent in many markets. Note For more background on Google's beginnings, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), more than 60 billion searches were performed monthly by 750 million people worldwide in 2008, including more than 18 billion in the United States alone. In other words, 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 those remarkable volume numbers, what does this mean on a practical level for interactive marketers? Simply put, if you don't reach your target customers when they are looking for your products or services, your competition will have an opportunity to sell to them. Look at your website analytics and picture the problem like this: How much more revenue would the website generate if strategically targeted traffic increased by 10 percent? What about a 100 percent raise? Or 1000 percent? If your website isn't generating meaningful traffic from natural searches, then SEO is a must. A small investment in SEO can pay off big time, especially when previous interactive marketing efforts focused on buying clicks through sponsorship listings. We've seen websites earn a 35 to 1 return on monthly SEO spend. If you pay the search engine companies for sponsored listing traffic, but don't invest in natural traffic, you're actually limited to about 10 percent of the chance. Think about your own search behavior: when was the last time you clicked through more than one or two of the paid sponsorship listings in a search result? Any discussion of why SEO is important and why it persists can take several chapters. Suffice to say, Google is only on the rise and effective interactive marketing should include search engine optimization as a core component of competent implementation.
128
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
Important basic resource skills come from extensive training. The professional who concentrates only on his field loses sight of everything else. Therefore, it is imperative that every interactive person spend at least a few minutes learning about SEO. While there are no official guidelines, Google has been kind enough to provide some very important resources. If you're interested in getting better search engine performance from your efforts, check out these links: Help for Webmasters/Site Owners: Search Engine Optimization:
www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35291 Webmaster/Site Owner Help: Webmaster Guidelines: Quality Guidelines:
www.google.com/support/webmasters/bin/answer.py?hl=de&answer=35769 Search engine optimization starter guide:
www.google.com/webmasters/docs/ search-engine-optimization-starter-guide.pdf If that's not enough, drown yourself in newsletters and blogs. Start at SEOmoz.org and browse. Remember, as with everything else in life, if it sounds too good to be true, it probably is.
Website technology, design and infrastructure Search engines are essentially Web 1.0.5 technology, firmly established in the Web 2.0+ world. The basic idea of the search engine has changed little since the World Wide Web Wanderer was founded in 1993 to search the Internet and build the first web search engine. Essentially, every search engine has an application, variously called a crawler, spider, or bot, that finds and follows links and sends a copy of the asset back to the database for it to see. The database is then analyzed using the search engine's proprietary algorithm. These rules are used to index and then rank a web item based on how well it performs on that search engine's respective scorecard. This fairly simple process harbors a large number of pitfalls for the UX designer.
SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE
129
Understanding these core relationships will help you see your website through the eyes of search engines. An optimized website is based on a structure and technology that facilitates the movement of search engine spiders. Similarly, many content handling decisions determine how well search engines judge the resulting efforts. As such, much of this is dictated by the decisions made in wireframes and in the discussions of how content should be designed and managed.
Flash, Ajax, JavaScript and Other Script-Based Content Today's dynamic and interactive web design is based on technologies that don't meet the needs of search engines at all. There is an ever widening gap between what search engines can see and what designers can do. It is up to the UX designer to ensure that the strategic plans for dynamic websites with a lot of design are implemented so that both search engines and users have the best possible experience. Once you have a basic understanding of how search engines handle this type of content, you can decide when to use them and where to compensate for their weaknesses. It is quite possible to create an optimized website that relies heavily on scripted content if the right offsets are put in place early in the process. It's much more difficult to create static or indexable content once the site is built and live. So, for ease of use and in the interest of search engine crawlers, you should strongly advocate for static content. 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 search engines' ability to drill into Flash files to find the text and links embedded in those elements. Even though this content is indexed, have you ever seen a flash-only item get to the top of search results? That's probably not the case, since it's risky for search engines to open themselves up to full Flash compatibility. Let's assume that the search engines can fully see all the links and text content embedded in the SWF object. This prevents an unethical (or "black hat") optimizer from placing apples in the object's text layers when viewed
130
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
Oranges for the human user viewing the fully compiled assets through a browser? How can you deep link to a Flash asset without it being fully compiled? These fundamental vulnerabilities will persist until the search engines reach a level of artificial intelligence that can recognize that an image is an image of a horse without an accompanying text that says "This is an image of a horse" is available. To create a search engine compatible Flash website, you need to add a static content layer that duplicates the Flash content. Aside from search engine requirements, a static content layer is key to meeting usage requirements. Think of the search engine as the person viewing web content over a dial-up connection or using a screen reader browser. These people may be the lowest common denominator and it is possible that the strategy behind your web development is ignoring this very small percentage of human users. But by ignoring this handful of people, you also exclude GoogleBot and Yahoo Slurp – the two most important visitors to your website, as they are the crawlers that the major search engines use to index your website. If text words or spider links are not visible to search engines, your content is probably not discoverable through meaningful search results. A static layer can be created in a number of ways. To meet search engine requirements, the static content layer must reflect the Flash content. This is not an opportunity to show search engines anything other than what is offered in Flash; If you do, you're going against the spirit of the game and going straight to the dark side. The ideal way to enclose Flash content in a static layer is to use SWFobject so that both the Flash content and the static content can be stored under the same URL. This allows the search engine to find the static content and allows the Flash browser to display the animation instead of the static content. Avoid redirects if possible to maintain the popularity of the link pointing to the Flash content. Google Code provides a simple guide to implementing this simple JavaScript element at http://code.google.com/p/swfobject. There is another option that runs on the gray side of SEO. Cloaking may be a dirty word to SEO purists, but if you approach the following challenges from the right side, you might as well eat some pie.
SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE
131
Cloaking uses user agent detection and detects search engine crawlers when they visit a website and redirects them to static pages for indexing. However, when a human visitor sees the same page in the search results and clicks the link, the website recognizes that the user agent is a human with a Flash browser and serves that human for the dynamic experience at an entirely separate URL. The core of the problem remains the same as with the SWFobject method: you need to show search engines exactly the same things in your stealth content as you do in your Flash content. Ajax, JavaScript, and Other Script-Based Content Ajax is a powerful driver for Web 2.0 content and allows web developers to create pageless content. However, the problems search engines have with Ajax are numerous and require good planning to avoid major mistakes. Ajax stands for Asynchronous JavaScript And XML, which indicates the difficulties search engines have with this technology. In principle, search engines cannot handle JavaScript; The efficiency that JavaScript provides to developers is the problem search engines have with dynamic content. Another problem search engines have with Ajax is the asynchronous nature of the technology. A search engine can only see the content of the first page it loads, and any content loaded through a script that takes place after the first shell loads is not visible for indexing. Because Google cannot extend a session after the first page loads and has no mouse or external agent to trigger a script, user-activated pageless content is invisible unless the text content is included in the pre-installed shell. It is up to the UX designer to ensure that the three-dimensional modeling required to structure a pageless design includes the requirement that all text and links be preloaded in the page shell. Everything else and your cool design is invisible. Script-Based Navigation One of the most common problems getting in the way of optimization is the use of JavaScript at the core of site navigation. This is a common condition and the result of how many website development and content management tools work. Scripted navigation looks cooler, so people are often interested in using it. However, when JavaScript is the technology that controls website navigation, it results in search engines not being able to model the link correctly
132
CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION
Relationships within the site: You just can't see the link structure of the site. And if the search engines can't model the link relationships on the site, then deep content will be invisible or not get the right link popularity.
Content management systems Content management systems are designed for human convenience, but many of these systems make it difficult for search engines to process their results. The following are some typical issues that should be avoided by using workarounds or choosing a content management system that makes searching easier: Dynamic URLs. Search engines don't understand a "page" of content; It
understands the way to this content. Changing the path or URL that leads to that content will cause the search engines to accidentally clone the content multiple times. This condition has a significant impact on the performance of a website. If the content management system has a system that creates session IDs in URLs, you could be in real trouble. Track with advanced analytics, not session IDs. Multiple URL paths. A typical problem when managing e-commerce content
The problem is that a product accumulates multiple URLs over the course of its lifecycle. Since, in turn, the search engine can only understand a content page based on the URL where it finds the content, whether a product appears in a category and is part of a gift basket and is a weekly special (and so on, and so on). on), the search crawlers pretty quickly followed a series of different links to find the same content. Make every effort to ensure that each piece of content only exists on a single URL, and that multiple paths are actually based on a single URL, regardless of where the links are provided. Rely on advanced analytics systems for channel analysis. Accidental cloning. When you realize that a lot
While content should only be accessible through a single URL path, other conditions can be easily detected in content management systems that lead to content being inadvertently cloned. Suffice to say, the architecture should only have a single URL path to a single piece of content. endless loops. A consequence of the problem of accidental cloning is the lack of it
finite loop. Make sure you don't use search engine spiders
SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE
133
a potentially endless task of following "next" links in a calendar or similar situation. If the search engine spider can lead a next link to the next day of a calendar where it can find another next link, it will follow that link to the next page, and so on. Avoid such a situation by using a scripted link that the search engines can't follow, so that the crawlers can spend their time on the content you want to index. Old URL structures. The first in many rehabilitation projects
The task is to replace the old URL structure. The problem is that the search engines have probably already indexed the content of those old URLs, and once you change them all, you essentially reset your indexing to zero. In addition, all the deep links that have accumulated on the site over time refer to the old URL structure. Be sure to keep as many of the old URLs as possible. It is likely that replacing the content management system will require you to change all URLs. If this is unavoidable, we strongly recommend giving the old URLs a 301 Moved Permanently status code and doing a one-to-one redirect - a base from the old URLs to the new URLs. The 301 redirect is the only acceptable redirect for search engine purposes.
It depends on domains, directory and URL structure. If you're starting from scratch and branding constraints allow, try choosing a domain that contains one or two keywords. Nowadays it is difficult to find a .com domain with quality keywords. If you do, separate those keywords with hyphens. An important part of how UX affects SEO lies in a website's directory structure. It has a crucial impact on how link popularity is distributed across the site. Simple is better. It is essential to avoid unnecessary files in the folder structure. Some content management systems automatically add a subdirectory; Avoid this if possible. This condition weakens the relevance of the entire site. The search engines understand the hierarchy of the site from the structure of the sitemaps. Therefore, make sure that the most important folders are at the top of the architecture. If your environment allows, 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
Do not use too many keywords in a file name. Go for something like this: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure that redirects are set up for http://site-in-question. com to 301 Moved Permanent redirection to http://www.site-in-question.com. If a website can be resolved with and without www, search engines (especially Yahoo) will index the content of both URLs, opening up the entire website to accidental duplicates. This condition may spread if a non-WWW third party links to the website and the website contains a dynamic link structure.
Content: The Once (and Present) and Future King While content generation is someone else's problem, the foundation laid in a website's architecture has a lot to do with making the right content available to search engines. As with all forms of keyword-based search, you need to understand the actual search behavior of the people you want to show an item to. Search engines are still very "primitive" because they rely on users typing in keywords to associate them with items more or less relevant to those words. Choosing the right wording is critical to determining whether your site is relevant in the right context. Ideally, your SEO partner will provide you with a set of keyword phrases before you begin and work with you through the wireframing process. If your process doesn't include such a competent partner, learn more about the Google AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) and research the actual search behavior of users of your category. Then spend some time on that input to find out the phrases potential customers are searching for and use those phrases appropriately throughout the site. Search engines look for keywords in several places when analyzing a website. Optimization is all about making sure the right words are in the right places. Understanding the role of keywords in the UX design process will create the necessary framework for future success.
CONTENTS: THE ONCE (AND PRESENT) AND FUTURE KING
135
Why is content king? It is the essence of what a website should deliver. Search engines need text content that they can see and index. Website visitors need compelling content that deserves their attention. Bloggers and webmasters need linkable content. Without the right content in the right places, search engines cannot direct the right visitors to your website.
Naming Conventions and Fighting Jargon It's important that keyword goals are reflected in the taxonomy developed for a website. Using keywords in the main structure of the website makes the entire website more relevant to the products you sell. If you sell widgets, refer to the online product listing as a widget catalog instead of a catalog. Also, use your keyword research to make decisions against technical jargon. For example, use the words "laptops" instead of "notebooks" in your structure because people search for laptops over 10,000 percent more often than notebooks.
Metadata, Headers, and Keywords It's quite remarkable that we got this far in this chapter before returning to basic metadata issues. There are tons of meta tags out there, but only a handful really make a big impact, as all the others are prone to spam. Relevant tags are these: page title. Please note that this is not the-Day is, but about the
Actually