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






A Project Guide to UX Design: For User Experience Designers in the Field or in Production Russ Unger and Carolyn Chandler

New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (fax) Find us on the web at: www.newriders.com To report errors, send a message to[email protected]New Riders is an imprint of Peachpit, a division of Pearson Education. Copyright © 2009 by Russ Unger and Carolyn Chandler Acquisitions Editor: Michael J. Nolan Projects Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laamme Lyrics Editor: Leslie Tilley Proofreader: Suzie Nasol Composer: Danielle Fostereriry Peredex Featurette Heft Cover Production: Andreas deDanaan Interior Designer: Mimi Heft

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

Disclaimer The information in this book is distributed "as is" without warranty. While every precaution has been taken in the preparation of the book, neither the authors nor Peachpit accept any liability to any person or entity in respect of any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or any of the instructions contained therein, computer software and hardware products described.

Trademarks Many of the names used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where these names appear in this book and Peachpit was aware of a trademark claim, the names appear at the request of the trademark owner. All other product and service names mentioned in this book are used solely for editorial purposes and for the benefit of those companies, with no trademark infringement intended. Such use or use of a trade name is not intended to convey endorsement or any other affiliation with this book. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 Printed and bound in the United States of America

Praise for a UX Design Project Guide If Russ Unger and Carolyn Chandler were wizards, the Alliance would hunt them down for revealing their best-kept secrets. Lucky for you, that's not the case. Russ and Carolyn have collected insights previously known only to the most experienced UX project leaders and coded them for all to see. Now you can learn the secrets needed to run great UX projects. Jared M. Spool, CEO and founder of User Interface Engineering;

Is there a book that can tell you everything you need to know about user experience design? No. Is there a book that excites you more? It exists now. Carolyn and Russ have laid a solid foundation for project planning and management. This is an essential primer for anyone immersed in competitive methodologies, endless meetings, and all the moving parts of user experience design. Dan Brown, author of Communicative Design

This book is a fantastic introduction to designing great products for real people. But it encompasses much more than design: it also encompasses everything related to design: managing projects, collaborating with people and communicating ideas. A great SUV. Donna Spencer, author of "Card Sorting: Designing Actionable Categories"

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

If you've heard of the author Wil Wheaton, you'll understand why I hold Russ Unger in such high regard. Russ' experience and guidance were instrumental in the construction and design of Monolith Press, and he has been one of the most valued partners I have ever worked with. Wil Wheaton, author of Dancing Barefoot, Just a Geek, and The Happiest Days of Our Lives


Acknowledgments Russ Unger This book would never have been near completion without the support of my family, friends, colleagues, and many people who were complete strangers to me before I struck the first keys. My beautiful wife, Nicolle, who knowingly married a bug-ridden nerd over the top, managed to double down on parenting while she was writing this book. Our daughters, Sydney and Avery, often revived their nearly comatose father to dance, sing, and play Spore. It occurred to me that writing a book with a newborn at home would not be much of a challenge. I quickly learned otherwise. And Nicolle stepped up time and time again to rescue me and give me the focus that she needed to complete this project. She is the hero I trust the most. she keeps our house in order in the midst of chaos. He is the center of our world here and he lets us go far too easily. Nicolle, along with Sydney and Avery, make me see myself as a good father and I'm thankful for that. I live in a house with three girls and I can't imagine loving any of them with less than I have to give. Carolyn kept me on track. There were times when it seemed like this project would never start or end. She always kept things moving, exploring ideas and pushing us in the right direction. The collaboration has been great and I have learned a lot from it! It's definitely a big UX yin to my UX yang. Michael Nolan was our acquisitions editor and he was the perfect guide. Michael is honest and kind and he really helped make everything go smoothly. Rebecca Freed was the giant, managing all aspects of the book, keeping us informed and emailing us often late at night. Unfortunately, she would often get a reply from me almost immediately! Linda Laflamme was the development editor, and once I got used to the Red Pen of Doom of hers, it was clear that she was leading me in the right direction, no matter how hard I tried to drown her in unfinished thoughts and careful sentences. Leslie Tilley put a final touch on the words. Tracey Croom brought together production, design, and graphics. and a real book appeared. Steve "Doc" Baty read each chapter before it saw the light of day in the Peachpit offices. He would often send Steve chapters around 2am.


he was posting his comments at 5 am, which is no small feat. Mind you, Steve is in Australia, but he's still awesome. Without Steve's constant willingness to help and his quick response times, it's hard to believe this book would have made it onto a shelf. Brad Simpson (www.i-rradiate.com) took all the images I threw at him and turned them into beautiful, print-ready images, often as he juggled his life with two teenage children and a busy work schedule. It would have been easy for Brad to leave 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 for that effort, but I'll work hard for it. Thank you Brad for giving so many days and nights off to support this. Mark Brooks would sometimes scare me when he tried to convey messages that required a visual element beyond my time and/or capabilities. Mark stepped in and saved the day more than once and I owe him that. Talented and committed to a fault, Mark is the kind of person I want to be. Jonathan Ashton wrote the entire chapter on search engine optimization for us. After speaking with Jonathan for 5 minutes, I knew he was the right person for the job. His chapter alone is a good reason to buy this book and it was great to have him on board. Jono Kane jumped in at the last minute and in an instant. Jono is a web developer, prototyping and interaction designer at Yahoo and was invaluable in helping him write Chapter 12. Lou Rosenfeld really helped get this ball rolling. In addition to being the author of the acclaimed "Polar Bear Book" (O'Reilly's Information Architecture for the World Wide Web), Lou is bright, friendly, approachable, and always willing to help others in our field. It would be hard to find many people as generous as Lou. Christina Wodtke helped me make introductions and connections. Without Christina, I'm not sure where we'd be today, but I probably wouldn't be "in print." In addition to being a "must read" author, she is someone who was always on hand to offer advice and information. Many in the field of UX design owe much of what they know to Christina's tireless efforts to broaden our horizons through constant innovation. THANK YOU


Will Evans and Todd Zaki Warfel have generously provided high-quality products that you can use as templates for your own products. They were true brothers and gave their time and talent without hesitation or concern, often in the blink of an eye. They're great members of our UX community, people you want to meet and work with, and I'm lucky to be friends with them. I certainly cannot do justice to the gratitude I owe these two. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING gang) and Wil Wheaton have served me well as good friends and true fans and loyalists. I am lucky to be able to write these names together as a list of people I know and am a huge fan of all they do. Your support has been an invaluable benefit to me in everything I do. These wonderful people went above and beyond to help me by generously contributing facts, anecdotes, and access to their resources, and I thank them wholeheartedly: 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.nicknck.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 Brief Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), chapter 14; Livia Labate (www.livlab.com), Chapter 7. Michael Leis (www.michaelleis.com), Chapter 11; Troy Lucht (www.ascendrealtysolutions.com), Chapter 14, James Melzer (www.jamesmelzer.com), Chapter 10; Matthew Milan (www.normativethinking.com), chapter 7; Chris Miller (www.hundredfathom.com/blog), “A Brief Guide to Meetings,” Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), Chapter 11; Stephanie Sansoucie (www.linkedin.com/in/smsansoucie), Chapter 11; Kit Seeborg (www.seeborg.com), Chapters 3, 11, and “A Brief Guide to Meetings”; Josh Seiden (www.joshuaseiden.com), Chapter 7. Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and "A Brief Guide to Meetings"; Samantha Soma (www.sisoma.com), "A Brief Guide to



Meetings"; Donna Spencer (www.maadmob.net), Chapter 7. Jared M. Spool (www.uie.com), Chapter 7; Keith Tatum (www.slingthought.com), Chapter 12; Todd Zaki Warfel (www. messagefirst.com), Chapters 7, 12 and 14. I also love Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, SXSW's Hugh Forrest, Peter Ina, Alec Kalner, Jonathan Knoll , Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton, as well as the folks at Manifest Digital and everyone at Draftfcb. I have inevitably missed someone and I hope it doesn't take it personally. There are a lot of people who they come in the "crowd" and I tried to keep up with everyone. If I missed you, let me know and I'll find a way to fix it! Finally, it's important to note that without organizations like the Institute for Information Architecture, the Association for Information Design, Interaction and others It would have been impossible to contact many of the people mentioned. If you're curious about the field of UX design, explore these organizations, join, and get involved!

Carolyn Chandler Many of us dream of writing a book one day in our lives. Without Russ, I don't know if he 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 leaders, all of whom have had a huge impact on what you see on these pages. He truly is one of the great connectors in our field and strives to bring people together day and night. Also, I think she posts more tweets in a day than me since I joined Twitter. Russ thanked many people who helped us a lot. I won't repeat all of these names, except for Steve Baty, who read all of our chapters in every rough way we could throw at him and managed to sound excited at 2am (his his time). John Geletka also provided thoughtful commentary and engaging discussion with a spark and perspective that cuts across many disciplines. And of course the Peachpit team. I will never forget to return my first chapter of Linda Laflamme. He wasn't pretty (although he delivered the lines tactfully). she patient



he guided me through the edits and helped me improve my flow, which was initially better suited to writing single technical papers than an entire book. Now I even find myself adding transitions to my casual conversations with colleagues! Speaking of... Christine Mortensen, aka Morty, was my partner in crime when it came to pictures. The icons and diagrams she sees in my chapters are the result of her hard work, and I know how hard she worked because she and I worked on many of the same client projects while trying to meet chapter deadlines. . Morty is one of those visual designers who can plant her feet firmly in both visual design and interaction design, she enjoys collaborating with everyone on the project and bringing the concepts to life. From Her She has an integrity and focus on quality that makes her a joy to work with, and it was an honor to have her as a partner on this. Thanks also to all the people at Manifest Digital, who have given me great support over the last few months. Jim Jacoby brought a special blend of business insight and UX perspective, with his trademark zen calm, that got me through some stressful moments. Jason Ulaszek is one of the most enthusiastic people I know about UX and has endless knowledge of tools and techniques. I have no idea where he makes room for all of this! Brett Gilbert and Jen O'Brien have also provided valuable input in some of the many roles in which they work with UX designers. I'd also like to thank the Manifest UX team members who provided me with inspiration and were so patient with my constant reports on the progress of the "book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. . It is a constant pleasure working with you. Every day I appreciate your humor and insight. To my colleagues at the Interaction Design Association, thank you for sharing your experience and being an active member of the UX community that I love. In particular, I want to thank Janna Hicks DeVylder and Nick Iozzo, who have been instrumental in the growth of the Chicago chapter and who continue to find new ways to grow a vibrant network of smart people. Last but not least, I would like to thank my family, friends, and Anthony, who patiently tolerated my disappearance and continued to check that I was still alive. You have a lot of rain checks to cash and I can't wait to go over them with you!




. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV


Tao of UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is user experience design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The general definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Do not forget the tangible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

About UX designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Where UX designers live. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Let's get started! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 CHAPTER 2: The

project ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Determine the location type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brand presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Marketing campaign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Content Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Task-Based Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 e-commerce sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-Learning Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Social Networking Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . twenty

Choose your hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Information Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 User Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you may play or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Establish a network of user interests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Understand the corporate culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Squeeze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CHAPTER 3: Proposals

for consultants and freelancers. . . . . . . . . . . . . . . . . . 39 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Preparation of the proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41



Page title. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 deliveries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ownership and Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional Costs and Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Project Awards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Acknowledge and Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

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

Objectives and focus. . . . . . . . . . . . . . . . . . . . . . . . . . 56 Consolidation of project objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

How can a UX designer help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Understand the focus of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Cascade approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Approaches changed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 How does focus affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 CHAPTER 5: Business

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Understand the current situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Collect ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Description of responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Gather the right stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Make a meeting plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sale: collection meeting of defaulters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Conduct meetings effectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Fusion Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82




Investigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic Steps of User Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating a feature list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Prioritization and Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Selection of research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How many research activities can I include? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 User interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 studies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Focus groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Sorting cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

After the survey. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 CHAPTER 7: People

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 What are people? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Why create Personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finding information about People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Creation of Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Minimum content requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Optional Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Advanced people. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Final Thoughts on People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 CHAPTER 8: User

Experience in design and search engine optimization. . . . 126 Introduction to SEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Why is SEO important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Important Key Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Technology, design and infrastructure of the site. . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and Other Scripted Content . . . . . . . . . . . . . . . . . . . . . . 130 Content Management Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, directory and URL structure are important. . . . . . . . . . . . . . . . . . . . . . . . 134

Content: The former (and present) and future king. . . . . . . . . . . . . . . 135 Naming Conventions and Fighting Jargon . . . . . . . . . . . . . . . . . . . . . 136 Metadata, headings and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136



Divide the hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Using sitemaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keeping content up to date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other substantive problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Explanation of link popularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Normal Distribution of Link Popularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 footer links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Content Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

Play the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat vs. Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Spamming with meta keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Cloning and Gate Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Spam Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Some final thoughts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 CHAPTER 9: Transition:

From definition to design. . . . . . . . . . . . . . . . . . . . 144 Conceptualization and visualization of functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

The basic storyboard process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitate the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Make sure you have a good tension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The Development Advocate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Conflict management in prioritization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Plan your activities and documentation. . . . . . . . . . . . . . . . . . . . . . . . 162 CHAPTER 10: Location

Cards and workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Tools of the Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Sitemap Basics and Workflows. . . . . . . . . . . . . . . . . . . . . 168 page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stack of 168 pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Decision point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Links and Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 messy connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171



Misaligned and unevenly distributed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Misplaced Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Missing pagination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 The simple sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Advanced sitemaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Breaking the sitemap mold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Taking workflows to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Swimming 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 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Wireframes and Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

An exercise: design a wireframe home page. . . . . . . . . . . . . . . . . . . 195 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The Results: Designing a Wireframe Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual design: when wireframes mature and find their way into the world. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Design Exercise Continued: Which Design Is Right? . . . . . . . . . . . . . . . . . . . . . . 201

One final note on the presentation of Wireframes. . . . . . . . . . . . . . . . . . . . . . . . . 202 CHAPTER 12: Normalization.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What is prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How original do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Standardization of paper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe vs. Realistic Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML Versus WYSIWYG Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional Prototyping Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214



Collaborate with a developer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Examples of prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 What happens after prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 CHAPTER 13: Planning

Test with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Concept exploration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Tips for Exploring Visual Design Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Usability tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Focus Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Writing Discussion Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Facilitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and presentation of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Make sentences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 CHAPTER 14: Transition:

From design to development and beyond. . . . . . 247 This is the end... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual design, development and quality assurance. . . . . . . . . . . . . 248 User Test Design (again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1… Launch! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Post-launch activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post-Launch Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Post-launch design testing with users (again, again) . . . . . . . . . . . . . . . . . . . . . 255

It's all done, right? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 How to start again... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INDEX 255


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


Introduction Why We Wrote This Book Welcome to the Project Guide to UX Design. Somewhere there is a user experience design student who is sleeping because he doesn't know what it will be like to work on a real project at his new company. Across Town is a visual designer with extensive project experience eager to take on new responsibilities in defining the user experience for her website. These are two people at different times in their lives, but with a similar need: to understand how to integrate user experience practices into the context of a live project. Our goal with this book is to give you the basic tools and framework to help you use UX tools and techniques with workgroups. As you'll see in many of these chapters, we're not trying to be everything to everyone, but trying to give her the basic information and knowledge she needs to do many of the tasks she needs. I will be appointed as a UX designer. In addition to our own examples, we provide examples to help you find ways to start with the basic materials and combine the information to create something new, better, or even more suitable for your own purposes. We hope we have expressed well that this is a very good approach for UX design projects. We are nothing if we don't constantly try to learn and improve (what we do) with each iteration. That is why we are in this field to some extent. A Word From Russ As a mentor at the Institute for Information Architecture (www.iainstitute.org), I've noticed a pattern among the people I've worked with: most had difficulty finding work or didn't meet expectations of futures. employers. . Some were highly educated, but not always enough practical application of UX design skills in a project-based environment. The same themes resonated in many of the conversations I had at the Information Architecture Summit (www.iasummit.org) in 2008. That's when the



The idea for this book, which addresses many of these common problems, began to take shape. I don't remember if Carolyn or I sent the first email, but I do know that I found in her a willing and able co-author who helped me develop the idea that ultimately became this book. A word from Carolyn For many years I have been fortunate enough to build and manage UX teams. I say "lucky" because I think UX designers generally have a good balance of traits that make them fun to work with, a mix of right-brain intuition and left-brain logic. When I conducted interviews to create these teams, one thing really stood out to me: a relevant educational background, such as human factors or communication design, is a good indication that someone is committed to the field of UX design, but it's not the right one. number an indication of whether someone is right for the team or a project. Equally important, if not more important, is the ability to have a counselor mindset. This means a positive attitude, a drive to understand and involve others in a project, and above all, a focus on making a real impact on users and customers. This mindset involves taking the time to understand the perspectives of other roles on the project, making assumptions and compromises where necessary. It takes experience and effort to master this mindset, but an open mind, a solid foundation, and a good set of questions (with the courage to ask them) will go a long way. This book may not give you all the "answers," but it will give you the questions you need to ask to find them.

Who is this book for? A UX design project guide provides a broad introductory overview of UX design in the context of a project. Anyone interested in UX design should find something useful here. We specifically target the following groups: Students taking courses in UX design (such as human-computer interaction or interaction design) who want to supplement their courses with information on how to apply their learning in real-world situations where communication and collaboration are essential.



Professionals who want to deepen their knowledge of basic UX design tools and techniques and improve team communication between the roles involved. Chapter 3 is also especially aimed at freelancers who need to create their own proposals. UX design team leaders looking for a book to help their teams integrate project best practices into their UX design activities. Leaders of any project team who want to learn more about how UX design integrates into their projects, its value, and what to expect from UX designers. IF YOU MUST…


Define user experience design and understand what draws people to the domain

Chapter 1: The Tao of UXD

Ask the questions that are important to answer before the project starts (or at least before you start working on it)

Chapter 2: The project ecosystem Chapter 3: Tips for consultants and freelancers

Get off to a good start with effective meetings, clear objectives, and well-understood pass points.

eChapter: A Quick Guide to Meetings Chapter 4: Project Goals and Approach

Define project requirements that are clear and easy to prioritize, derived from stakeholders and business users.

Chapter 5: Business Requirements Chapter 6: User Research Chapter 9: Transition: From Definition to Design

Know your users and represent their needs throughout the project

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

Choose and use the tools and techniques to quickly bring visual ideas to your project team

Chapter 10: Sitemaps and Workflows Chapter 11: Wireframes and Annotations Chapter 12: Prototyping

Make sure your website is easily found and crawled by users and search engines

Chapter 8: User Experience Design and Search Engine Optimization

Communicate and evolve your design with the project team as soon as development begins

Chapter 14: Transition: From Design to Development and Beyond

Be sure to visit www.projectuxd.com to read the additional chapter "Quick Guide for Meetings" and to download additional materials such as templates.



A note on methodology There are several approaches and methodologies. We are not advocating one approach over the other. Our goal for this book is to focus on the steps common to most projects: define the needs of the project, design the experience, and develop and implement the solution. The amount of overlap between these steps will vary greatly depending on the project approach you use (see Chapter 4 for more details). Our framework is very much a flexible and linear approach in which the definition step comes first, but in each step we use facilitation and design techniques where they are most useful.

This book is not an encyclopedia of all techniques. The UX field has a large number of creative people, and they are always trying new approaches to design problems. To include all of these approaches here would be a much longer book, and one that would quickly become outdated. What we have included here are the most commonly used techniques, the practical aspects of UX design. We have tried to provide enough information to keep you involved and allow you to share the activities with other members of the project, including the basic process for each technique and additional book or website references to help you implement them once you have moved on. They have chosen. A guide to being a project manager. Good project management (including setting and tracking goals, schedules, and budgets) is key to the success of any project. We are not covering the details of how to become a project manager or how to choose a specific project methodology. We discuss the skills that a UX designer brings to a project that allow it to function effectively, such as facilitation and communication, as well as the ability to clarify and maintain 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, no one today. The field of UX design is relatively new and we are all working to improve where we are. You will probably find these trials and errors, tweaks and improvements, and feedback



from others help you tailor a process to your needs. If you find something that works for you, share it! Let us know!

How to use this book There are many great resources for UX designers. We cover topics extensively here, but we'll point out references that will allow you to explore topics at a deeper level, depending on how much time you're willing to spend on them. To help you understand how long each report typically takes, we've divided them into three broad categories:

Browse Surfboard References are shorter articles (usually online) that take 5-30 minutes to complete.

Snorkeling Snorkeling consists of longer online articles, white papers, or short books that take anywhere from an hour to a weekend to read.

Deep Dives Helmet Calls are longer books that will probably take more than a weekend to read. give you detailed coverage of the topic.



This page has been intentionally left blank


The Tao of UXD Curiosity meets passion and empathy The most important thing is to never stop asking questions. Curiosity has its own reason for being. You can only be amazed by contemplating the mysteries of eternity, of life, of the marvelous structure of reality. It is enough to try to understand a little of this mystery every day. Albert Einstein

The sense of curiosity is the original school of nature. smiling blaton

Passion and purpose go hand in hand. When you discover your purpose, you will usually find that it is something you are incredibly passionate about. steve pavlina

The great gift of humans is that we have empathy. Mary Streep



In a nutshell, this chapter is for you and others who are drawn to user experience design (or UX design for short).

If you are reading this sentence, you are a rare person. You want to know how things work, from doorknobs to airplanes to something on your neck. You especially want to know what sets people apart. You don't see things in black and white. There are many shades of gray to discover! Sure, you can sometimes drive your colleagues a little crazy if you always willingly play devil's advocate, but it's not like you can stop looking at the other side of the coin. Happy! The field of user experience design attracts curious people who are comfortable working with many shades of gray. We look for patterns and thrive on organization and structure. We connect the dots. We're always looking for the next puzzle piece, and when the puzzle is solved, we look for ways to make it better! We can be analog or digital. We are at home with pencil and paper, whiteboards and erasable markers, post-its and Sharpie markers. We speak in terms of Visio and 'Graffle' and we live in a world of boxes and arrows connected to our multiple computer screens. We are not just curious. We are passionate! We are passionate about sharing ideas and facilitating conversation. We are passionate about creating things that make a difference to those who use them and those who make them. Surprisingly, we take great pride when something we make is so good that people don't realize how good it is! And of course we have empathy. We can feel it deep within when we are faced with a bad experience. Worse, we immediately try to find solutions to solve the problems. We know what it's like to receive an unexpected response to what seems like a simple request, and we don't like that! We don't want users, people like us, to have to put up with the confusion and feelings of inadequacy that often come with a bad experience. 2


When you combine this almost constant, childish curiosity with an unmatched passion for "doing what we do" and insight into how others feel, you get a vibrant community of professionals who are comfortable speaking their minds, asking questions, raising, share solutions. . and being wrong, all in the name of being right. Welcome to the UX design community.

What is user experience design? There are many definitions of user experience design. After all, it is 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 focus primarily on two definitions: the broader meaning of the term UX design, and the definition we will use in the context of this book.

High definition user experience design is the creation and synchronization of the elements that influence the experience of users with a particular company, with the goal of influencing their perceptions and behavior.

These elements include the things a user can touch (like tangible products and packaging), hear (merchandise and audio signatures), and even smell (the smell of freshly baked bread in a deli). It includes the things that users can interact with beyond the physical, such as digital interfaces (websites and mobile phone apps) and, of course, people (customer service representatives, vendors, 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 richer, more integrated experience. Smell-o-vision is still far in the future, but otherwise the products continue to blur the traditional lines.



Don't forget the tangible While we focus on the digital aspects of the user experience, these kinds of interactions don't happen in a vacuum. Consider the effects of the touch experience when designing your digital products. The environment your users work in matters, as do the physical products—monitors, keyboards, and other input devices—that affect how your users interact with your design. Chapter 6 provides techniques to help you understand the impact of context. Also, don't forget about the other touch points that a product or company has with those who interact with it. After all, a company's brand is influenced by many things, and the brand experience doesn't stop at a computer or mobile phone screen. The best website design cannot make up for a reputation for poor customer service or the satisfaction of well-designed packaging when a product is delivered.

Figure 1.1 A modern classroom experience combines analog and digital.



Tactile experiences, like learning in a classroom, are increasingly influenced by digital applications. Similarly, experiences that were once individual, like choosing a home karaoke machine to buy, are becoming better through social interaction.

Figure 1.2 Online reviews are a major influence on consumers.

Our Approach As you can see, the scope of UX design is wide and growing. For the purposes of this book, we will focus on projects that focus on the design of digital experiences, especially interactive media such as websites and software applications. To be successful, the design of the user experience of these products must take into account the business goals of the project, the needs of the users of the product, and any constraints that affect the feasibility of product features (such as technical limitations or restrictions on around budget or project time). frame).



Free samples of a new nutrition bar given away at a marathon

a door handle

Package for a pair of shoes

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

Touch SMS functions for mobile phones

call customer service



Our Approach Read Product Reviews Online Search Archive Online View Targeted Ads

Live chat with digital customer service

About UX Designers While curiosity, passion, and empathy are traits that UX designers share, there is also a desire to find a balance. We're looking for a balance, usually between logic and emotion, like Spock and Kirk from Data and Data in that episode where their emotion chip overloaded their positronic relay. You get the idea. To create truly memorable and fulfilling experiences, a UX designer must understand how to create a logical and sustainable structure for the experience and understand the elements that are important to creating an emotional connection with the users of the product. Exact balance may vary by product. An ad campaign for children's toys will have a different balance than a hospital patient registration app. A product designed without understanding the need for both is likely to miss out on opportunities for a memorable 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).



Achieving this balance requires a greater sense of empathy: the ability to immerse yourself in the world of potential product users to understand their needs and motivations. User experience designers investigate this understanding (see Chapter 6) and create tools such as personas (see Chapter 7) to help the rest of the project team focus their efforts. Remember that emotion is only one part of the big picture. Use the logical side to get off the edge and keep your mind on tasks. In most cases, you'll work with a budget based on the time and materials needed to complete the project. You must understand that sometimes you have to fish or cut bait.

Where UX designers live You're not alone in this. Look around you and you'll find a number of organizations and communities that can support your growth as a user experience designer. In addition to offering mailing lists, online resources, and a host of really smart people, many of these organizations sponsor events or conferences that can help you broaden your horizons and narrow your professional focus. Some companies host continuing education events, such as User Interface Engineering's Web App Summit and User Interface Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. There is also a growing number of "no conferences" in various cities. These are created by a collection of motivated individuals, independent of any particular company or association.



Several professional organizations also sponsor annual conferences. Table 1.1 provides a short list of some of the better-known organizations, their websites, and the events they host. TABLE 1.1

A selection of UX organizations




Association Interaction Design (IxDA)


Interaction (beginning of February)

Information Architecture Institute (IAI)


IDEA Conference (September/October)

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


IA summit (March)

ACM Special Interest Group on Human-Computer Interaction (SIGCHI)


CHI (beginning of April)

The Association of Convenience Professionals


EPS (June)

Let us begin! You have come this far. It's time to understand why you chose this book in the first place. Turn the page and dive into how UX design exists at the project level. But don't stop there: this book is a guide to get you started. It contains many examples that can help you perform many of the activities assigned to you. We have also tried to provide additional examples to help you expand and find your 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 that ideal user experience. Of course, that's before you start improving it.




Project Ecosystem Planning for Project Needs, Roles, and Culture Are you about to launch a new project? Or are you in the middle? Either way, take some time to consider the dynamics and context of the project – the issues that will affect you and the rest of the project team. What kind of sites or apps are they? What roles and skills are needed? What is corporate culture? Answering these questions will help you define the project and ultimately identify the tools and skills you need to succeed. carolina chandler



each project has its own unique challenges. If you're designing websites or apps, many of these challenges relate to specific functions and features, such as creating a method for the user to share photos online with friends and family, or restructuring information on an intranet to make it easier to access to content. Find them. 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 in which you work (the company culture), the general type of work that everyone will be doing (such as the type of website you are designing), and the people with whom you will work. interacts. with (including their roles and responsibilities). Taking the time to understand the project ecosystem will provide you with insights that will help you throughout the project. You can communicate your responsibilities and ideas more effectively, and you can help other team members anticipate project needs they may not have considered. To help you, this chapter identifies different types of projects you can work on, as well as the roles you can play, the people you can trust, and how your involvement varies depending on the type of site or application you use. worked on. It is planned. Finally, the chapter discusses some elements of the corporate culture that can 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 involves designing only one type of site. If you have more than one location, review them individually to make sure you are playing the correct roles on the project team.

Identify Your Type of Site While there is no black and white distinction between one type of site and another, there are some relative differences in site focus and features. Understanding these similarities and differences will help you set design goals for yourself. These are the general problems that should be present

resolved (such as "explain the business model of the company") or the attributes to be displayed (such as "demonstrate that the company is responsive to its customers") in the visual and interactive design of the website.



Establish the main objectives of the project (see Chapter 4). Understand which departments or business units can (or should) be

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

Your site is likely to be strongly associated with one of these four types:

Brand Presence: An ever-present online platform that facilitates a relationship between the company and a general audience (anyone interested in its products or services). Marketing Campaign: A specific website or app intended to generate a specific and measurable response from a specific audience or from a general audience for a limited time. Content Source: A repository of information, possibly consisting of various types of media (articles, documents, videos). , photos, tutorials) intended to inform, engage or entertain users. Task-Based Application: A tool or set of tools intended to allow users to perform a series of basic tasks or workflows.

The following sections take a closer look at each of these types, discussing their characteristics and the impact they will have on your challenges when designing a website or app. We'll also look at the most common crossover projects (eCommerce, eLearning, and Social Networking) that have features of more than one type.

Brand presence What do you think when someone says the word brand? Often the first thing that comes to mind is a company logo, like the Nike Swoosh or the Coca-Cola script. However, a company brand is much more than its logo. It is the entire set of impressions that a certain person has about the company.



Dirk Knemeyer presents some excellent definitions of brand in his article "Brand Experience and the Web": A brand represents the mental and emotional associations that people make with a company, product, or person... In other words, a brand is something in which reality exists. each one of us. Brand science is about designing and influencing people's minds; in other words, brand building.

Browse To learn more about the distinction between a customer's experience with a company's brand and a company's branding efforts, read Dirk Knemeyer's explanation of "Brand Experience and the Web": www .digital-web .com/articles/brand_experience_and_the_web. For a great discussion on how the UX design of a website 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.

A business can do a lot to influence its brand associations, from running memorable ad campaigns to expressing brand attributes (such as "responsiveness" or "value") through the features and design of its websites. . . All of a company's websites are likely to have some influence on a company's brand, either directly (introducing a website for customers to visit) or indirectly (enabling an important service that customers trust, such as customer service). However, branded websites are more focused on displaying the company's brand messages and values. They provide channels that communicate directly with customers and serve as a broad online funnel for those who want to learn more about the company or its offerings. A brand presence website is typically the company's main .com or .org site, such as GE.com, or for larger, more distributed companies, it is the main site for business units of various sizes, such as GEhealthcare.com . Different product lines also often have their own unique online presence. For example, Pepsico.com has a brand presence, while Pepsi.com has its own separate presence.



If you're working on a branded website, you're likely designing for a variety of user groups, including existing and potential customers, investors, partners, the media (such as well-known news organizations and bloggers), and search engines. employment. .

Common Brand Presence Sites A company's main website (company.com, company.org, company.net, etc.) A website for a major business unit of the company (often a single website for

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

Brand presence design objectives The design objectives that are usually most important in a brand presence project are: Communicate the company's brand values ​​and messages;

either explicitly (perhaps a statement of the importance placed on meeting customer needs) or through the overall experience of visiting the website (such as ensuring good performance and differentiators that encourage customers to contact you). the company). Provide quick and easy access to company information. Want

answer the questions "What does the company do?" and "How can I contact someone for more information?" Present or explain the business model and value proposition of the company:

"What can the company do for me?" and "How's business?" Engage multiple main user groups and guide them through relevant interactions

elements, functionality or content. Help the company achieve the objectives established by 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'll learn the different roles that can be involved in designing a brand presence website. let's see for now



to the other types of sites you can work on, including one closely related to brand presence sites: the marketing campaigns site.

Marketing Campaign Marketing campaign websites are similar to brand presence websites in that both focus on engaging users with an experience that influences their perception of the company's brand. However, marketing campaign sites are often judged on their ability to perform very specific actions within a particular focus (such as within a specific time frame or with a target audience). Instead of serving as a funnel to channel interest, they are meant to be interest-generating engines. From an online perspective, this typically means they are aligned with an overall marketing strategy and can be run alongside other cross-channel marketing efforts, such as radio or television ads, print ads, and other promotions.

General Marketing Campaign Sites A landing page that promotes a specific offer. The page can be accessed through a

banner ad from another page. A small website (or microsite) that promotes a specific event. A game or tool created to generate buzz

the circulation

The primary purpose of a marketing campaign website is to create a campaign with a specific objective that typically targets a specific set of metrics. Focus is often constrained by one or more of the following: Time: For example, a campaign around an event (such as

conference) or a season (such as the holiday shopping season) User group, such as a campaign aimed at teens or teachers Product, set of products, and/or a specific use for that product, to

for example, a website that highlights kitchen appliances by displaying virtual kitchens with matching ovens, dishwashers, and hobs



A campaign that uses a combination of these strategies would be a spring campaign focused on yard equipment sales, combining time and product range. See Figure 2.1 for an example of a product set and user group combination. A marketing campaign site can be as simple as a banner ad that links to a landing page on the company's .com site, or it can be a microsite, a small site that often differs from the brand being sample on the .com site to customize it. experience gained according to one or more of the focus areas. "Small" is relevant here: some microsites are just one page and others have many, but at least the microsite is smaller and more focused than the company's main presence site.

Figure 2.1 Texas Instruments uses this education-oriented microsite, http://timathrocks.com/index.php, to present information about the company's graphics computers. The product suite is mainly used by high school students and students in algebra classes. The microsite maintains general ties to the Texas Instruments brand, but is intentionally differentiated to appeal to a younger audience and to organize content and features around their needs.

Design Goals for Marketing Campaigns For the person or team responsible for designing and implementing a marketing campaign on the site, the design goals that are often most important are: Generate interest and excitement, often through clear communication and direct.

another value proposition (the value that a product or service provides to the user, such as the ability to quickly qualify for a loan) or some type of incentive (a special offer, participation in a contest, or entertainment such as an online game).



Enable a variety of main user groups to fake a specific action,

like clicking a specific location on a brand website, signing up for a newsletter, or applying for a loan. When this action is performed by a user, it is called a conversion. Help the company achieve the objectives established by key metrics such as no.

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

Going Deeper To learn more about designing pages to support marketing campaigns, see Landing Page Optimization: The Definitive Guide to Conversion Testing and Tuning, by Tim Ash (Sybex, 2008).

Content Feed A content feed website contains a repository of information, possibly in different types of media (articles, documents, videos, photos, tutorials) and is intended to inform, engage and/or entertain users.

Common content resource sites A company's internal network An online library or resource center for members of an organization Sites or sections of sites dedicated to providing news or information

up-to-date posts (major business blogs can fall into this category) Customer Service Centers

All websites and apps have some content, of course, but some websites place special emphasis on the presentation and structure of their content. The emphasis may be because the site has such a large amount of content that it is a challenge in itself, or because certain types of content are of great importance. for example, they can support crucial decisions or direct users to the site on a regular basis.



The main goal of a content feed site is to increase the awareness and self-sufficiency of users by providing relevant content (for example, an intranet). They also tend to encourage some type of action, such as sharing information or buying a product after checking the description. Design Goals of a Content Feed A website with a content feed often needs to do one or more of the following: Present content that is the main draw for first and repeat visits to the site. Demonstrate a company's thought leadership capabilities, for example

Provide access to ideas and perspectives from the CEO or other subject matter experts within the company. Support critical decisions among the user base. Increase a company's business knowledge by highlighting ideas that

it can be buried in separate sections. This can be part of a broader objective to identify more opportunities for innovation. Support users who are looking for information in different ways. For example,

some don't yet know what specific product they need (and are more likely to shop around), while others may know exactly what they're looking for (and are more likely to use a search field).

Navigation To learn more about the different ways people tend to seek information, read "Four Ways of Seeking Information and How to Design for Them" by Donna Spencer: http://boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them

When it comes to UX design, some of the most common tasks in a content feed project are: Create a categorization structure that fits your users' mental models. Decide how to incorporate an organic content development system.

(for example, features such as tagging and filtering) Designing an effective search function DETERMINING THE TYPE OF WEBSITE


Task-Based Applications Task-based applications can range from a simple calculator built into a mortgage site to a complete system that handles multiple critical workflows. If your project includes the latter, there will be more roles and likely a substantial requirements-gathering process (see Chapter 5 for more on this process).

Task-based generic applications A software application that supports the creation of a specific type

component (such as a spreadsheet or piece of paper) A tool or web application that supports a critical workflow within a

company (such as a ticket management application for an IT support team or a customer tracking application for a call center) A website that allows access and management of personal information

(as Flickr)

The main goal of a task-based application is to allow users to perform a series of tasks that align with their needs and ultimately the customer's business goals. Goals for Designing Task-Based Applications Most task-based applications should allow users to do something they can't do elsewhere, or if they can,

to do better ("better" can mean more efficient, more efficient, with a higher level of satisfaction, or more convenient) Support novice users with easy-to-access instructions and visual priority-

Create basic tasks Support intermediate and advanced users with access to shortcut functions

and deeper functionality Reduce user load and maximize system resources

(for example, data reuse vs. requiring duplicate entries)



They are designed and developed with attention to the degree of change required

of application users, ideally with a design that facilitates learning and a communication design that demonstrates value to the user. One of the biggest challenges when designing a task-based application is controlling the advancement of features. As a project develops, it's all too common for great ideas to emerge at later stages of design or even during development. UX design lends itself well to guarding against feature augmentation 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 comes along later in the process that meets the needs of a high-priority user group and aligns with the site's business goals, your team may justify a change in direction. If an idea doesn't go through this wringer, it may not be worth the delay and expense.

E-commerce sites E-commerce sites can include elements of all four project types, because a site primarily dedicated to e-commerce must have its own brand presence, provide content (usually product specifications or product usage descriptions), and facilitate tasks (search, compare, write reviews, verify). Marketing campaigns are often closely associated with these sites and can involve multiple marketing teams within the organization. Additional common design goals for e-commerce sites are to Explain the site model if it is non-standard. how to buy online

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

market comparison, with useful content and features. Take advantage of experience points where there is cross-selling and up-selling

possible and place these sentences in a way that is attention-grabbing without being obtrusive. Create a communication flow from the point of purchase to

delivery point. Communication should not only take place within the website, but also through other channels, such as integration with delivery tracking systems and email communication about order status. DETERMINE THE TYPE OF WEBSITE


E-learning applications E-learning applications are crosses between a content source and a task-based application. Content must be created for courses, often requiring the team to add Learning Expert and Subject Matter Expert (SME) roles for the topic being covered. The product is task based in the sense that the user generally follows a flow in the lesson and may also need to track progress or explore related topics. Some practical courses may also require the completion of tasks. Common design goals are to understand the basic knowledge needed to start a course.

and to whom it is addressed. Deliver content in manageable, paced chunks

concept. Engage the student in activities that simulate hands-on learning. Communicate performance and progress and, where appropriate, recommend

next steps to continue the educational process, such as more advanced courses.

Social Media Apps A social media app is primarily a task-based app, as users need to be able to find and add friends, manage their profile, connect, post, and search. However, they also contain content source challenges, particularly the need for an organic framework that can handle a potentially very large amount of user-generated content. Essentially, if the site has its own identity, it also has the characteristics of a brand presence site.

Snorkeling Whether you're working on a social networking application or trying to integrate social networking features into another type of website, this book will help you get started: Designing for the Social Web, by Joshua Porter (New Riders, 2008).



Common design goals for social media apps are to orient potential users toward the purpose and values ​​of the network. Facilitate meaningful interactions between users who support and support

Supports featured features (such as image sharing, video sharing, and discussion). Protect the integrity of the site by ensuring that those within the network

how to handle your information and respond to inappropriate behavior. Leverage and demonstrate the power of the community to advance the cause

programs that are only available to active members, such as popular features and reviews. Recognizing the type of site or app you're working on during a project is just the first step. Next, you need to consider the different roles that are often required, and how your involvement may vary depending on the type of project.

Pick Your Hats When you become a UX designer for a project, you often play multiple roles. Whether formally defined within your client's organization or not, the roles you fill will depend on the type of project and the composition of the rest of the team, as well as the client's experience with each. It's good to know which roles you are already comfortable in and which ones you think you can learn on the job. It is also helpful to know what expectations others may have of the responsibilities covered by these roles. With this information, you can represent yourself more clearly from the start of the project. What are the most common roles expected of a UX designer? Each client company you work for may have different titles for these roles (or no name at all, if it's not an official job with 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 split these common roles among multiple people. Keep role names in mind when defining a project, but talk in terms of needs and responsibilities when talking to the client; otherwise, they might think you're building too big a team! This focus on responsibilities rather than titles will also help you stay sane: if you're playing multiple of these roles, you're not necessarily doing the work of many people, as responsibilities come and go in different parts of the project.



Information Architect An information architect is responsible for modeling the structure of information and using it to design user-friendly navigation and content categorization. When designing sites and applications, common responsibilities include creating detailed plans (discussed in Chapter 10) and ensuring that categories and subcategories of information are clear and easy to use. Understanding expectations Within the field of UX, a distinction is made between the roles of information architect and interaction designer (discussed below). However, in any given company there is rarely a common distinction between the two roles, at least when it comes to what is called 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 fix the project team if the title you get doesn't match the lead role you take on? If it's a short-term project (say, four months or less) and the title you hold is widely accepted in the organization, with clear responsibilities, it may not be worth the potential confusion it would create to try to change it. However, if there is no commonly accepted title and you think there is a possibility that both roles may need to be played, possibly by different people, then it is worth making a distinction early in the project when planning your involvement and communicating your responsibilities. . Essentially, for more task-based applications, it makes sense to emphasize the role of the interaction designer, and for more project-based projects, it makes sense to emphasize the role of the information architect. But perhaps what makes the most sense is to use a term familiar to the client organization and make sure the team understands how you define your role in relation to the responsibilities you take on. This definition is something you'll want to make clear in your job description (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see below, in the Other roles section). If these roles are



represented by different people on the project team, 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 website or application based on user actions. This includes website flows in multiple views and interactivity in a specific view. When designing sites or apps, common activities include creating workflows that display interactions between pages or elements within the site (see Chapter 10) and creating threads that display on-page interactions, such as dynamic menus and widget areas. expandable content (see chapter 11). Understanding expectations If you're working in a small team or on a project that doesn't specifically focus on creating new task-based features (for example, if you're working on a brand website that contains mostly a few categories of content , a contact form , and a lead registration form), the interaction designer is primarily responsible for capturing the project requirements (see Chapter 5). As an interaction designer, if you're working on a project with a lot of new features, you probably have a separate person on your team who is responsible for describing the detailed requirements (for example, a business analyst or product manager). The process of collecting and detailing functional requirements can be greatly aided by the skills of a UX designer, and documents like functional specifications and use cases are influenced by experience design. Be sure to sit down with the person responsible for qualifying to discuss the best way to work together.

User Researcher A user researcher is responsible for providing information about the needs of end users, based on information generated or validated by the individual's research with users. There are many types of activities that can fall into the category of user research, and they can occur at different points in the project timeline. (See Chapter 6 for a description of common techniques such as user interviews, surveys, and usability testing.)



Understanding Expectations The client company's need for user research can vary widely depending on the importance placed on it by the project team or project sponsor. The fact that you talk to a project sponsor about UX design before a project begins shows that someone on the client team knows that making sure user needs are represented is a priority. But as those who have worked on their share of computer-based projects know, the introduction of research can also create fear among project team members, caused by concerns that user research will be an obstacle, will increase risk (what if we find something wrong and have to make big changes to fix it?), or disprove the value of a particular idea that has gained a lot of popularity. User research expectations may differ between business stakeholders and the project team, so be sure to clarify role expectations with both groups. The client may also expect the user researcher to provide information based on website analytics: tools and reports that communicate usage patterns on the website, such as frequently visited pages and common points where users leave the website. Some of the most widely used analytics tools are from Google (www.google.com/analytics), WebTrends (www.webtrends.com) and Omniture (www.omniture.com/en/products/web_analytics). You can take on these three roles: information architect, interaction designer, and user researcher. Can you balance all three or will you bite off more than you can chew? This depends in part on the size and timing of the project, but the type of project also influences the extent to which each role is likely to be involved. Table 2.1 outlines how UX designer roles can vary by project type.

Surf Do you want to support UX design? These articles offer insights that can help: "User Experience as a Business Imperative" by Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Evangelizing User Experience Design at Ten Dollars a Day" by Louis Rosenfeld: http: http://louisrosenfeld.com/home/bloug_archive/000131.html




Common UX Design Role Responsibilities

information architect





Average participation.

Low commitment for smaller sites (such as a single landing page). Moderate participation if you work with larger micro positions.

Very high participation. Content resources require an information architecture with the right balance of structure and flexibility to provide users with a solid foundation to stand on and allow for planned growth.

Moderate to high engagement, generally focused on building the navigation box, unless there are larger areas of content that need to be referenced during certain workflows.

Low engagement for smaller sites, medium to high engagement for larger microsites or advergames (sponsored online games designed to generate play and excitement).

Moderate to high participation.

Very high participation. This type of project often requires the most heavy lifting, as interaction design outputs (such as user workflows and schematics) are critical to visually communicating requirements.

Due to the often temporary nature of the campaigns, user engagement is often low. More permanent solutions may use research similar to brand presence sites. It's also common to use analytics tools to run two or more variations of a given page to see which one drives the most conversions. This is called A/B testing.

Field research, like contextual research, can help the team understand how different users currently work with the information.

The bigger the content challenge, the more the project will become a source of content.

interaction design

Average participation. The higher the number of tasks, the more the project will resemble a task-based application.

The participation of user researchers will vary depending on budget and access to users. Here you will find general techniques for each type of project. See Chapter 6 for more information on each of these techniques.

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

Search, tagging, and filtering functions straddle the boundary between information architecture and interaction design. Content sources can also have workflows for creating and managing content.

Card sorting is a great way to understand how users group information and common mental patterns and models.

Field research, like contextual research, can be performed to gain insight into tasks as users are currently performing them. However, the most used and best understood technique to involve users in the design of a task-based application is usability testing.

Once a framework is set up, usability testing can validate the structure.



Other Roles You May Play or Need Various roles are typically not 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 is officially playing the role. role, and you have the skills to bring to the table. Some of the more common overlapping roles include: Brand Manager/Strategist Business Analyst Content Strategist Copywriter Visual Designer Front-end Developer

The following sections examine each of these roles in more detail and discuss how they might differ depending on the type of site being designed. Brand Strategist and Brand Manager A brand strategist is responsible for building a relationship with key markets by defining and consistently representing the company's brand elements, which can include anything from brand values ​​(such as "responsive" ) to guidelines for copying and sending messages. .messages according to specifications for editing logos, colors and design. This role often includes creating or representing brand guidelines and understanding how to apply them to different projects. It can also be about knowing or defining the target audience that is important to the project you are working on. For the most part, 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 properly followed throughout the project. This responsibility can be assigned to the UX designer or the visual designer of a project. If the company's characteristics, values ​​and guidelines are already well defined and the website is expected to follow them, your role as the brand manager of the project will mainly be to ensure that the result is in line with these guidelines. Your point of contact outside of the project is likely to be a



a member of the marketing department who is available for advice or review, but is not a full-time part of the team. The role of the brand manager can be more active if the site is intended to expand the brand in some way, such as targeting a new market. It gets more involved when creating an entirely new brand presence or when the company makes a drastic change to its brand, essentially rebranding itself. For example, CellularOne was completely rebranded as Cingular, a major company for an established company. In this case, you must have a lot of experience in branding or establish a clear and close relationship with the person in the company. Key questions to help you understand the expectations of a brand-related role are: Are the brand guidelines already in place? If so, how strictly must they be adhered to for this project? Who is responsible for establishing or maintaining brand messages,

appearance and tone of the content (such as business or casual)? New target groups that were previously not covered will be addressed

brand definitions? If so, who is responsible for ensuring that the brand guidelines remain appropriate for these audiences? Will naming or name change activities take place? If so, what should you plan to be like?

concerned? (An example is coming up with a name for a new tool that will be widely promoted.) For projects that don't have a major potential impact on customer brand perception, such as developing an internal app, involving a brand manager can be as simple as an occasional check-in to ensure the brand is in place. represented. Business analyst A business analyst (sometimes called a business systems analyst in IT projects) is responsible for identifying key business stakeholders, leading the requirements gathering process (see Chapter 5), and serving as liaison between business stakeholders and the technology team. . She is also the primary owner of detailed documentation requirements such as functional specifications and use cases as needed.



The Business Analyst or Product Manager role may not exist in your project, or it may be one of the most important roles in the design process. Task-based apps and content sources often have this feature. Brand presence projects and marketing campaigns may not be. A task-based application will most likely need this role. The more features and the greater the complexity of the project, the greater the need for a dedicated person and documentation of functionality. While a business analyst is not typically considered a UX team member, small UX teams are often asked to fill the role, so it's important to understand where these responsibilities lie. Business analysts drive compliance with business requirements and act as a liaison between the technology team and key business stakeholders. If there's a business analyst on a project, that person and the interaction designer are often on the same page. When it comes to the same role, the person in charge may have a lot of documents to keep track of. To understand the expectations in this area, ask who is responsible for describing the scope of the project, facilitating discussion of the requirements, and documenting the requirements throughout the project. For small projects or projects that do not have many roles, the project manager sometimes assumes these responsibilities. Either way, if it's not you, you still know who to stay with to make sure your deliveries are in sync. Content Strategist A content strategist is responsible for understanding business and user requirements for content across all media (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating workflow and content. development of new content Substantive efforts are often underestimated. A client might have a lot of content that's great in one medium (like print brochures or videos), but that content might not be a good fit for the project she's working on. Also, there are sometimes unspoken expectations that people within the customer organization will create content—expectations that can surprise those people when it comes time to populate your product with descriptions, news, and help topics! If high-quality content is a



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

tons, amount). Assess the suitability of existing content against them

Guidelines. Development of new content. This depends on the general type of project. For

Task-based applications may contain tutorials, error messages, and help topics. For content sources, these can be articles, news, and blog posts. Acts as a liaison between stakeholders and the technical team for communication.

Limitations and possibilities of the content management system. Specify different types of content and the metadata for each (the

information that ultimately makes searching and cross referencing more efficient). Planning for content migration, including templates

for different types of content and ensure that the content is properly tagged and uploaded when it is transferred to the site's content management system. (This is another area where the effort required is often underestimated.) Copywriter A copywriter is responsible for writing the copy on the website that frames the overall experience. In some cases, this instance remains relatively unchanged from day to day. It usually contains site and page introductions or on-page instructions. A copywriter may also be involved in the constant creation of dynamic content, such as news or copy for marketing campaigns. Copywriting is one of those gray areas that a UX designer often falls into, especially when creating threads (see Chapter 11). Initially, you can enter sample text to serve as a placeholder for text, such as a site description or on-page instructions, but eventually someone will need to fill it in with the final text that users will see, and because many projects they don't have a dedicated copywriter, this job might be standard for you. You are less likely to be asked to take on the role of copywriter in high-profile areas of brand websites or marketing campaigns. in this situations



each word can be checked carefully. However, if you are working on a task-based application that needs short tutorial messages, error messages, or other information that doesn't necessarily fall into a clear content container, you can inherit this writing task (or it falls to the developer for flaw). Ask ahead of time if a copywriter is available, and ask again when you're wireframing if you can't find one. If you own the work, be sure to include this effort when you plan your activities during the project. And be careful: 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 effort includes designing a look that creates an emotional connection with the wearer in accordance with brand guidelines. For example, a banking website often needs to look stable, reliable, and accessible. Visual design can provide this assurance through visual elements such as colors and images. This promise is fulfilled (or broken) by the interaction design of the website and other points of contact with the company (such as a call center). Let's face it: Many people call themselves visual designers, web designers, or graphic designers, and many websites have poor or passable visual design. There's a big difference between creating an effective, compelling, and emotive visual design and being successful. Sometimes success is enough to achieve project goals, and sometimes it leads to frustration and project delays when the project sponsor is dissatisfied or early adopters aren't involved in the design. On the other hand, it can also be easy to focus too much on creating impact with the visual design, which affects the usability of the design. If you're asked to take on this role and you're not sure you can create the right customer impact, take a look at the company's current website and the websites or products customers admire from a visual perspective to help you assess the comfort. level. Visual designers often play a very central role in brand awareness projects and marketing campaigns, as they are primarily responsible for effectively communicating the company's brand.



For content source projects, they can focus on creating content templates that can be applied to multiple 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 areas and tools (which require a high degree of collaboration with the interaction designer). Front-end developer A front-end developer is responsible for creating the technical structure behind the page layouts and flows, as well as the interactive elements within the website, such as update menus, expandable content areas, interactions with multimedia elements. like videos. This work often uses technologies such as XHTML, CSS, Flash, JavaScript, Ajax, and Silverlight. Front-end development focuses on the elements of the website that are directly related to what the user sees, as opposed to the back-end systems that provide the underlying platform (such as databases, content management systems, etc.). and the code needed to execute the functionality behind it). complex features). If you or members of your team are assuming the role of front-end developer, it's important to work closely with the rest of the development team to understand the expectations and responsibilities. Other important questions include which back-end systems to integrate with, the method used to generate HTML, the need for flexibility in the page structure to allow for custom skins, and the expectations around technologies like Flash. If a prototype is being designed (see Chapter 12), ask who is responsible for developing the prototype and what level of functionality is expected. A prototype that is simply intended to communicate capabilities can be created quickly in an application like Flash, but a fully functional prototype that needs to extract actual data (for example, the account information a user has just entered into a form) must be created on the fly. through close collaboration with members of the back-end development team. Worried about taking on all of these roles? Unless you're working on a very small project, or in a very small company, you probably won't take it all on. The key is to figure out which of the roles you can and want to play, if necessary, for the specific project you're working on. If not, you can get the support you need on the project team by building a network within the client's company or proposing additional people to fill the need. Let's take a moment to talk about the ways you can do this.



Create a User Support Network For those areas you're not sure you can or want to address, it's time to get help. There are three main ways to do this: Recommend adding additional team members as needed

pretty clear Train in key areas where there are gaps - like the new answer -

The skills are manageable and you have time to dedicate to them. Create a support network within the company to assist you in critical situations.

Let's take a closer look at how to build a support network. There are probably some key resources in other parts of the business that can help you succeed. You should measure how much time you can expect from these people, because requesting time from outsiders can be a difficult request on projects that are primarily within one department. If you don't want to demand too much of their time up front, simply ask if you can work (or consult) with them to ensure the best outcome for the core responsibilities of this role. Once you've worked together, you'll have a better understanding of how much interaction you need and whether you need to make a more formal request for your time. Every company has a different structure and different names for their departments, but here are some common places to look for partners: For the brand strategist role, ask if anyone is in marketing.

department that can serve as your point of contact. This can also be a resource for visual designers and content strategists. You can also find content strategy and visual design partners

program or product management, or in research and development, operations, or corporate strategy, where you can often find business analysts and product managers. IT or engineering department is usually the best choice for the front-end

developers and others who can help you access and learn about website analytics tools.



If you've recently been hired at a new company and expect to work across multiple departments, one of the best things you can do right away is to identify key people who could be partners and schedule an interview with them to discuss their roles and experience. . It starts with a network that you can often rely on for a long time, and gives you a chance to explain your responsibilities (and user experience design in general). You can also ask a good question at the end of the interview: "Who else do you think I should talk to?" The answer can help you find people who might not be obvious to the lead project manager or customer contact person. If you have been with a company for a while, you can still start such a talk show. In this case, it's best to tie it to a specific milestone (like the start of a new project) or a business goal that has some urgency to ensure high engagement. Make sure your manager knows what he's doing to avoid looking like he's hanging around. Good communication is key to understanding role expectations and building trust. Another key to gaining trust within the company is understanding the culture, the often unspoken expectations of how a company operates, created through previous project experiences (positive or negative), etiquette around organizational hierarchy, and organizational arrangements. acceptable work schedules (such as working from home).

Understand company culture Culture is a bit like pouring Alka-Seltzer into a glass: You can't see it, but somehow it does something. —Hans Magnus Enzensberger

A company's culture may not be consistent across regions, business units, or divisions, but you can generally identify the key characteristics that affect you and the project(s) you undertake. Here are some things to keep in mind as you focus on projects and navigate potentially difficult political situations.



History We all know the quote that those who don't remember the past are doomed to repeat it, and project work is no exception. Understanding how a project or team got to its current state of emergency can help you understand the challenges you may face during the project. Let's discuss some questions you can ask to understand the history that can affect a project. While some of the answers to these questions may seem overwhelming, keep in mind that something has triggered the need to get you involved, so a project can have a troubled history and still be successful. You are perhaps the most important ingredient in that success! However, if many of the issues below seem to apply and you don't think you can help fix them, this could be a red flag. In this case, consider a general evaluation of whether this project can be successful. What is an example of previous work that seems to have been considered?

succeeded, and what seems to have done this? What is a past project that seems to have failed (or 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 responding defines success, the potential risks to your project, and any biases or expectations involved in this game of project, as well as approaches that have worked well. The company has collaborated and released a designer for this

project or team? If so, try to find out what didn't seem to work and how the customer expects your approach to be different. Being able to ask this question of more than one person in the company will help you understand unspoken expectations. If you get two very different answers, it could mean that the designer's responsibilities are not well defined and you need to make sure that the designer's responsibilities are well communicated throughout the project. Did the project team work on the project (or related material)?

Why does it seem unusually long without end?



If so, it could be a sign that key customer stakeholders aren't on the same page or engaged at the right times, leading to multiple delays, redirections, 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. Being able to influence communication about the project can help you create patterns of engagement that move the project forward. Did the company make plans without prior involvement?

User experience designer? This can be a mixed blessing. On the one hand, you're dealing with a team that understands the need for the design and has tried to fill the void. On the other hand, you may end up with a design that you feel doesn't meet the user experience goals of the project. This can be a tricky situation to navigate. Often, it's best to approach the creator of these designs in the tone of a respected mentor or helpful consultant, first pointing out the good aspects of the design and then discussing the user experience goals and how they can best be achieved with another approach. The creator is likely to be a valued member of your support network, so it's important not to burn the bridge here, but to collaboratively redefine your roles to keep the excitement alive. The lead sponsor or project manager seems particularly concerned

about the project; There are many reasons why this can happen, especially if any of the above factors are involved. The stress could also be due to market pressures, which would be helpful to understand. For example, has the company's stock price fallen? Has any competitor in particular taken concerning actions recently? Is the company in the red? Again, these situations do not necessarily mean that you should not take on the project. After all, it's the kind of situation that often funds a project in the first place. But if you're deeply concerned that the company won't be able to pay its bills, that's a risk you'll want to weigh.



The Hierarchy Geert Hofstede has an excellent model that describes the differences in culture, what he calls "cultural dimensions," which often influence the way people interact and communicate with each other. One is the concept of power distance, the extent to which members of a society (in our case, a company) understand and accept the distance between people with different levels of power. For example, if members of a company's executive team are seen as particularly powerful and potentially unapproachable, a company may have a large power distance and its employees may be more hierarchically oriented. If the company encourages a democratic exchange of ideas and challenges the vision, it may have a relatively small power distance.

Power distance is “…the degree to which less powerful members of organizations and institutions (such as family) accept and expect power to be distributed unequally. This represents inequality (more versus less), but it is determined from the bottom up, not the top down. It suggests that the level of inequality in a society is supported by both followers and leaders." Geert Hofstede's Cultural Dimensions www.geert-hofstede.com

Neither extreme can be considered good or bad by itself, although in general in the United States most employees seem to prefer the appearance of a little power distance in their workplace. What is interesting to note is that this is not necessarily an indicator of how successful a company is. Apple has relatively high power distance (if you look at the aura surrounding Steve Jobs) and Google has relatively low power distance as part of their culture, but both companies are known as thought leaders. What is important to note is that the distance of power within the client company will affect how successfully you navigate political waters during the project. This aspect will be particularly important at key moments in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as closure points (discussed in Chapter 4). If you work in a company with a lot of power distance, take a little more



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

Logistics In addition to the broader aspects of culture mentioned above, it's also helpful to understand some elements that are more logistical in nature so you can better integrate with current work practices or make thoughtful changes. For example, it's helpful to understand the general pace expected within the company, including any major release dates or timelines that affect the project (creating a software application on an annual release schedule would likely have a different pace than from a microsite that has a seasonal release). supports). campaign, for example). Is your team expected to work late to meet impending deadlines? It's also good to understand the expectations related to remote work vs. on-site work. If a lot of time is expected at the site, plan the trip and set up resources there. If remote work is accepted (or encouraged), which is common when working with global companies, it's important to understand communication methods and tools. For example, is it acceptable to use instant messaging applications? What web conferencing tools are used? Are there methods for engaging international stakeholders that have proven effective in the past? It is also interesting to understand the "paper culture" in a company. Some businesses prefer electronic media for most things, so a good projector and a stable Ethernet connection are important. Others are very paper-oriented, so make sure you bring enough copies to a meeting to keep it productive. You may want to change the culture of the project if you think another way is more effective. But it's nice to know that you're asking people to change to make the transition smoother and possibly understand why a particular approach isn't working as expected.



Putting It Together Now that you've explored the project's terrain, you need to better understand the project's ecosystem: the environment you'll be working in (the company culture), the general type of work everyone will be doing (such as the types of websites you'll be designing) and the people with whom you interact (including your roles and responsibilities). This information is valuable as you describe your role in the project and prepare to get down to business in earnest. If you're working as a freelancer or subcontractor, this forms the basis for writing a proposal that covers your work on the project (see the next chapter, which discusses UX proposals). If you are part of a larger team and not directly involved in writing the proposal, you can use your new knowledge at the beginning of the project, your first team meeting. For a basic guide to running a good meeting, see the online chapter, "Quick Guide for Meetings," or if you want to know right away what questions to ask at the beginning of the project, see Chapter 4, "Project and Objectives." . Approach".




Advice for Consultants and Freelancers A Guide for Self-Owned Entrepreneurs It can be hard enough managing projects and client expectations, but if you don't get a good deal, you could end up losing every project you undertake. Proposals and statements of work are essential to protect your business, and yourself, from financial and legal trouble. After agreeing to and shaking hands with a project, be sure to take the time to draft an agreement that details the terms of your relationship and the payment schedule for your client. russ unger


Tips There's an old saying that "no good deed goes unpunished", and the same generally applies to winning any project: high tensions and happy moments are quickly replaced by 'Oh shit! It's time to write the sentence!" The biggest challenge in writing sentences is writing the first one. It's almost impossible to know where to start if you've never had to write one yourself, and this chapter should be useful for every type of project you encounter. has a variety of flavors that you'll keep in mind when it comes time to write your proposal. Fortunately, there is a core that all proposals have in common and that projects of projects can reuse (see Chapter 2 for a detailed discussion of types of proposals). projects.) When to write a proposal? Always. Why write a sentence? You might be tempted to skip this step when you first connect with a prospect and things seem to be clicking. Even if you clearly understand client's needs and can articulate them in a way that you understand, you're not really ready to get started.In fact, this is exactly where you need to slow down and catch your breath. Instead of getting down to business, take the time to define your business relationship and how to interact with your new customer. Jean Marc Favreau of the Washington law firm of Peer, Gan & Gisler, LLP, says: Too often, contractors and their clients think there is a relationship at the beginning of their relationship, when in reality the ambiguities are just lies. support. While it's nearly impossible to prepare for every eventuality, a fully written contract is your best defense and the smartest way to ensure you don't end up in court arguing the terms of your relationship later on. The more clearly you define the terms and parameters of your relationship with a client up front in a written contract, the less likely you are to argue about each party's obligations later.



New projects and new people are exciting. There's often a desire not to "break the deal" by throwing a proposal into the mix, but as in any relationship, the honeymoon feeling can eventually wear off. Promises can be broken on either side of the relationship. A client may not provide you with timely access to content. (I know this is almost unheard of, but believe it or not, it happens! That's sarcasm, in case you missed it.) Funds that were once available for the project can be diverted, and then you, the one who made it busy. with work, it can be left with the bag. Businesses also realize that they are taking risks by working with outside vendors, especially small businesses or independent contractors. Well-written proposals give clients a sense of stability and protection, which can help alleviate many concerns that may arise. A proposal also allows you to set conditions that protect both parties in case something changes. If the client doesn't give you timely access to their resources, your schedule may fail. You must inform them of their obligations for the success of the project. If a client loses funding and leaves the project, and you don't have a proposal or other form of contract, you risk not getting paid for the work you've already completed. The point should be clear: always write a sentence.

Writing the Proposal Once you have received the project, it is time to finalize the proposal. The faster a proposal is approved and signed, the faster you can get started and, more importantly, get paid for the work. The most important elements of a good proposal are: Title page Revision history Project overview Project focus



Scope of Work Commercial Deliveries Property and Rights Additional Costs and Fees Project Awards Payment Schedule Acknowledgment and Termination

Let's take a closer look at each part of the sentence.

Title Page The title page is the single page that introduces your document. Title pages are an interesting beast – there are a number of ways to create them in terms of style and information. How you do it is up to you. A typical title page consists of the following elements: Client company name Client company logo (if you have permission to use it) Project title Document type (proposal) Proposal version Date submitted Name of your company Authors of the proposal Project reference number Cost Confidentiality

For your initial proposal, include everything except the client's company logo, cost, and (if applicable) project reference number. Why not include these elements on the cover?



Your client knows who he is. It's probably not worth the time and effort to ask permission to use the company logo, and it's not worth the potential resentment if he accidentally uses it. Costing is best done after you have identified the various project elements in the body and the cost information clearly leads to the payment schedule. The project reference number is something you should know. Many companies will not use it at all. However, some government agencies are known to rely on this particular element and if it is not on your title page, your proposal may be rejected.

Figure 3.1 Example of cover proposal

The (fictitious) customer logo is used in Figure 3.1. In the event that consent has not been given or a relationship has not been established, it is preferable not to display the logo of the client company.



Revision history The revision history is a separate section of the proposal and is used to determine how many times you have updated the proposal since its original version. In general, it is best to include the version number, date, author, and any comments about the version, such as what has changed, to give the reader some context for the changes (Table 3.1). TABLE 3.1 SUMMARY

Example revision history table SECTION




authentic document


8 January 09


Updated to reflect software requirements



1,0 1,1

From time to time, clients sign off on a proposal and then ask you for further revisions. If you choose 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. Basically, once a client approves a proposal and both parties agree to the terms, you're good to go. Therefore, when additional changes are requested, consider them very carefully. This ensures that your costs remain correct and that there is a clear understanding on both sides of the adjustments and at what stage the project will be restarted (if necessary). Also, always give a good explanation why the revision is a brand new version in the revision history.

Project Overview The Overview section is a description of the project you will be working on, in your own words. This description should give your client a clear idea of ​​what you think your product entails, as well as an explanation of what to expect in the rest of the proposal. Here's an example of the beginning of a statement: [Client Company Name] is looking for a new online presence on the web. This web presence allows customers of [Client Company Name] to research and purchase online products, as well as other services and benefits available through the company. The objectives of the online presence are…



You need to be able to provide a solid overview in a few paragraphs, detailing at a very high level what the client should expect from you. It's a good idea to end the overview with a good explanation of the recommendations and proposed approach to completing the project: This proposal describes [your company name]'s recommendations and approach for the design and development of [company name the client's] ' . online presence on the internet. Given the deadline of [deadline], it is proposed...

Project Focus The focus of your project depends on the type of project you are undertaking. This is your opportunity to specify to your client how you intend to work with him on the project. You can set your rules of engagement and set expectations for the work ahead. Many individuals and companies work with very similar methodologies, but use different names or clever acronyms to fit their overall brand. Once upon a time there was a mythological method of showing off to (potential) customers and it found its way into many proposals. The process was called The PURITE Process™ (pronounced "purity") and while sharing it with you, a mythological creature simply died inside, so definitely read this as fiction. The name of the process is somewhat corny and the process is clearly somewhat incomplete. Post-launch analysis was omitted from this methodology (overlooked), but should of course be included for all customers. Without further ado, here is 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 entire process is defined as follows: The PURITE™ Process is [Your Company Name]'s internal methodology for ensuring the success of all initiatives. By using PURITE, [your company name] has a proven set of guidelines for working closely with customers and users/public to reliably maintain and exceed delivery expectations. P- Get ready. We spend part of each initiative understanding your industry and competitors and how they operate so you're as informed as possible before you start gathering requirements. You understand. We work closely with subject matter experts and/or users to define the requirements for the project to succeed.



R - Yield. During the Render phase, we create and develop all parts of the project/product. Our experience is that each phase of development requires a lot of attention, focused work effort, but also early and open communication with your team. It also requires… I – Iterate. The iteration phase is repeated throughout the project life cycle. We work as quickly as possible to deliver the project and this often requires building multiple iterations on short deadlines. This requires immediate and timely involvement from you and your specialized resources. The end result is the product you specified and helped create. Test T. We test each project during the Render phase. However, we also need an extra set of eyes: from our own testing team and from the user group/target group designated for specific testing. This additional round of testing helps ensure that as few bricks as possible go untested to deliver work that has been rigorously tested on multiple levels. E - Activation. After successful completion of the five phases above and your signed approval, we will activate the solution and go live. The PURITE™ process does not stop there. Once the project is complete, we regularly communicate with our clients. We continue to measure your satisfaction levels, understand your project's changing objectives or improvements, and help you define the best approach for the future development of your project.

You are welcome to use as little or as much as possible or useful to you. The mythical scribe who created the judgment also doesn't care if you don't credit the source. Your process definition can be as detailed as above or as simple as: Plan, Define, Develop, Expand Plan the overall strategy Define detailed project requirements Develop, test, refine, and release the work product Expand the project by proposing enhancements and enhancements based on information obtained during development, testing, and post-release

Once you've defined your process, you'll have an opportunity to detail the different efforts that will go into each stage of your approach, as well as what each of those efforts means to you and your client. The length of the focus portion of your proposal depends on your project, your process, and the activities that take place at each step of your process. However, try to keep it to a maximum of two or three pages, and



be sure to include only the results that you can provide to your client, to avoid further document updates or repricing of the project.

Scope of Work In the Scope of Work section, specify the work specification for the project. That is, you identify which parts of the project you are responsible for and which are the client's responsibility. Read it again. Think about that for a second. Let it sink in Come on. Correct. This is the part of the proposal where you tell the client in writing that we will do this and you will do it. Later, when the client signs your proposal, he agrees to that agreement and you have a document to back you up in case of any misunderstanding. The intent here is to clearly identify who will cover what aspects of the project, as well as what aspects of the project are included in your proposal and for the price you have estimated. If you can't find another really compelling reason to write a proposal, this should be reason enough. Here is a very brief example of a scope of work: [Client Company Name] approached us to provide all the services required for the construction of [Project Type]. [Your company name] focuses exclusively on the [user experience design aspects] of the [client company name] website. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] in accordance with the project plan. [Client's Company Name] will provide all necessary elements for use in the project, including fonts, colors, branding templates, etc.

Assumptions The Assumptions section of the proposal is a good place to explain, without leaving room for discussion, what your client needs to ensure their success. That is, these are the things that you take on, and communicate with the client, that they will have access to or be provided to complete the project.



What you call assumptions in this section are actually expectations. It's much kinder to assume. You can create as many project plans as you like, but if neither you nor the client commit to meeting milestones and objectives, both parties are committing themselves to failure on any given project. In general, the assumptions are an expectation of resources and assets, as well as timely access (translation: direct, immediate) to both. Here is an example of how to write cases: Cases [Client's company name] is required to provide the following assets and resources. Failure to provide these assets and resources in a timely and complete manner may contribute to the failed or late delivery of this project. The following assets and resources are expected: Timely access to all required employees of [Client Company Name]. Timely access to all required components of [Project] in their current state, including source files, if available. Content, as necessary and including, but not limited to, copy, images, audio, etc. for any aspect of the [project].

Deliverables Deliverables are the work product that you create and deliver to the customer. This section is your opportunity to detail to the client what kind of work product they can expect from you during the project. It is recommended that you treat the status report closer to the end of the project separately, but feel free to add it to this part of the project. Provide descriptions of each work product that you include, even if the work product has not been produced. This may seem overkill or has the potential to open up the "I've read about [available type] in the sentence, but I don't see it here," but one little word, can, can make all the difference. Deliverables [Your company name] delivers a variety of deliverables throughout a project. For [Client company name] we have identified the following deliverables:



Creative Brief The Creative Brief is the first step of the project. This document helps us create a high-level project overview quickly and efficiently. The purpose of the creative brief is to clarify the goals and needs of the users and to identify any special resources and/or limitations associated with the project. Etc…

Ownership and Rights It is important to consider the extent to which you allow your client to use the work product you produce. These rights can be defined in many different ways, but most of your work falls into two categories: Paid employment Licensed work

Work for hire (known in the legal world as "work done for hire") is considered created and copyrighted by the party paying for the work, not by the party responsible for the actual work. This means that when you do work on a work-for-hire project, you have absolutely no rights to the project and anything you believe related to the project belongs to the client. This situation is difficult for many companies and individuals to manage: it often means no "maintenance" work (with additional income) as clients can decide to maintain the project themselves once it is complete. Do not get carried away by a project where the client imposes an obligation on you. It is not unusual. When you post work-for-hire projects as part of a full-time job with a company, it's pretty typical of an employer-employee relationship. It's also an opportunity to rethink your pricing model: many projects charge a rather high fee to offset the potential loss of revenue down the road. Remember, 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. With licensed works, you retain the copyright in the work, but grant other parties the right to copy and/or distribute it. You can include an unlimited number of terms in your license agreement. YOU WILL PROBABLY MAKE THE SENTENCE


Benefit from licensing your work when you retain ownership of all source material for your work and provide only limited-use work products to your clients (such as PDF files rather than original editable Word, Visio, Axure, OmniGraffle or others). There are many ways to license your work, including licenses for works that can be used without modification, for non-commercial purposes, or in any other way appropriate to your situation. Creative Commons (http://creativecommons.org/about/licenses) provides easy-to-understand explanations of the different types of licenses you can use, but this is only a small subset of the licensing world. If you are in a situation where you have very detailed and specific needs, it is always best to contact a copyright attorney to help you find the best possible solution.

Additional Costs and Surcharges It is important for your client to understand whether or not the price of the work they will provide includes subcontracting. For example, some projects may require purchasing stock photos from a vendor. You can purchase the images (with the appropriate usage rights) and include them as part of your rate, or you can clearly state the purchase of images as an additional cost to be passed on to your customer. You can also offer services that you want to inform your customer about. This is a good opportunity to promote those services. Here is an example of how you can explain how additional costs and fees are handled: Additional Costs and Fees In the event external resources (such as content, images, fonts, etc.) are required, they will be identified, approved by, and billed to [Customer company name]. Additionally, [your company name] is able to provide hosting services to our customers at very low overhead costs. We offer hosting services, including configurable web-based email, starting at $25 per month, with a $25 setup fee. In the event [customer company name] wishes to purchase a "maintenance package", [your company name] will work on a package that is mutually acceptable and beneficial.



Project Price After you have documented the details of how the work will be done for the project, it is a very good idea to inform the client of the cost. How you arrive at the price is largely up to you, but here's some advice: estimate how long you think the project will take to complete, including a certain number of revisions, estimate a reasonable amount of time to complete the project, manage, which might be around 25 percent; Then enter the hourly rate you want to charge and calculate everything. There are several formulas to help you with this, such as applying difficulty levels to each part of the project to help you find a range of costs to provide your client. In most cases, experience will be key in helping you estimate your projects correctly, in terms of time and materials. How do you determine your billing rate? Research what others are charging to compare by finding contractor salary surveys and rates. For example, organizations such as the Institute for Information Architecture (www.iainstitute.org), AIGA (www.aiga.com), Coroot (www.coroot.com) and the talent agency Aquent (www.aquent.com) They conduct Payroll and Contractor Rate Surveys. You can get a good idea of ​​the prices you might charge by considering your experience, what others in your market are charging, and what you think is reasonable. Note: You can always lower your rate. It's much harder to ask your client to pay you more money once you see 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 give a customer two options: a static HTML site and a Content Management System (CMS) site that enables dynamic content (which the customer can manage without special resources). Here's how to formulate your project estimates: [Your Company Name] Project Estimate has suggested multiple estimates for [Client Company Name] to provide the best possible options for your immediate and/or future needs. [Your Company Name] assumes that all content is provided by [Client Company Name]. In the event that [your company name] needs to provide content services, it will be necessary to redefine the estimates.



Estimates from [your company name] provide flexibility in terms of costs and needs. The estimates are as follows: Estimate 1 [Your Company Name] estimates that [Project] for [Client Company Name], without any interactive content...

Remember that there is really no wrong way to put together your project estimate unless you are putting yourself in a negative cash flow position!

Payment Schedule There is a myth that all freelance projects are paid 50 percent up front, before work begins, and 50 percent on completion, when the project is complete. This myth must be dispelled, right now! That is not the way to do business, nor is it a way to ensure consistent and timely income while you are at work. You don't want to put yourself in a position where you have to make change after change for a client simply because you want to complete the project and get paid, rather than go through a job change process. You can invoice projects in different ways, from invoices sent within a predetermined time frame to payments based on milestones. A more sensible approach is to submit your projects to a recurring payment schedule with regular, itemized invoices. This approach should also give clients a clear understanding of what has been achieved and what still needs to be done on the project. The following example is one way to structure payments for your work: Payment Schedule [your company name]'s default payment schedule is to receive an advance payment of XX% of the estimated total price of the project prior to commencement. [Your company name] will invoice on the 1st and 15th of each month. payment is completed within 14 days. Upon project completion, [your company name] will deliver all work products to [customer company name]. Upon satisfactory approval of the materials, [Your Company Name] will either refund the remaining commission amount or [Your Company Name] will submit a final invoice for amounts not covered by the commission. Note: If [Project] is suspended for a period of more than 14 days with no work progress, [Your Company Name] will submit a final invoice for all costs not covered by the commission and will be entitled to First Denial in case of that the project is restarted.



While not required, it's helpful to add a note about how the project will be handled if it's put on hold for a long time. This arrangement can help keep your project on track and moving forward, and gives you a talking point with your clients. If you're not going to be doing extra work for them for a long time, you'll want to be able to go ahead and look for work to fill the void.

Acknowledgment and Decoupling While making sure you have a proposal is very important, it alone is not enough. The proposal doesn't really mean much until it's approved and signed off by the right person at your client's company. It is essential to ensure that everyone has a clear understanding of what is to come and how much is expected from each side. It's just as important to guard against "boulevard repetition" and reduce the risk of being caught in "feature-shifting" by a customer: constantly asking for "one more thing" to include. The registrations are quite simple and straightforward. After creating the proposal document, you provide your client with an acknowledgment and a signature approving 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 a confirmation you can use: Confirmation This proposal has been fully confirmed and approved by [customer company name]. This proposal must be signed and dated by an authorized representative of [client's company name] to be effective. Alternatively, a signed purchase order referred to in this proposal shall constitute an acceptance in lieu of such signed document (provided, however, that the preprinted terms of such purchase order are deemed null and void). This proposal constitutes the entire agreement between the parties with respect to the subject matter of this proposal. This proposal merges and supersedes all prior oral or written agreements, discussions, negotiations, commitments, writings or understandings. This includes, without limitation, any statements in descriptive or promotional literature, brochures, or other written materials and constitutes the complete and exclusive statement of the terms of the agreement of the parties. Each party acknowledges and agrees that in making this proposal it has not relied on any representation or statement not contained herein or in the Agreement, and expressly waives any reliance thereon.



Accepted by authorized agents: [your company name]

[Client company name]

Meeting: ________________________________

Meeting: ________________________________

Name: _____________________________


Title: _____________________________

Title: _____________________________

Given: ________________________________

Given: ________________________________

Please make all checks payable to: [your company name]

Statements of Work A Statement of Work (SOW) is a high-level definition of your project goals that you should be able to summarize in a two to three page document (excluding the cover page). The SOW is usually written before detailed requirements are received, although depending on the needs of your client 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 inputs and outputs of the project, as well as the assumptions and constraints. At this point, it's not uncommon for clients to ask you to provide a "guess figure" for the work you'll do for them. It may be a bit risky to answer it at this point. It is recommended that you do your best to avoid details or obligations without specifying the details. It's simply not possible to know how much a project will cost if you haven't already written the proposal and/or requirements document. That being said, it is necessary for me to make a judgment on this point. If you are working on a project, such as a basic website, and have successfully completed several similar projects in the past and/or have worked for the same client in the past, you have some leeway. Remember that being careful is always better than a sticky situation later in the project. A job summary should be approximately two to three pages long and should include at a minimum:



Front Page Revision History Project Reference Number Project Summary Start Date Completion Date Price/Price Project Explanation Activities and Deliverables Detailed Costs and Payment Schedule Confirmation and Opt-Out

Do the figures look familiar to you? Should: You can create a SOW with a simplified version of the proposal. You have now learned how to compile two types of documentation that identify the work you perform for a client. These documents should form the basis of any project work you do for a client and will provide you and your clients with a well-defined set of roadmaps for your projects.




Project Goals and Focus Knowing which star to navigate One of the keys to a good project is starting the team with clear goals and a well-understood focus. Ideally, project management has defined this for you, but how do you know if they haven't? This chapter discusses formulating project goals and offers some questions to help you solidify those goals. We'll also discuss some common project approaches (or methodologies) and how they might affect the way you work. carolina chandler



you are at the beginning of the project, for the first time with the whole team. The project manager hands out material and gives you an overview of the project. Ideally, at the end of the meeting, he should have the following information:

Why is the project important to the company? How will stakeholders determine if the project was successful? What approach or methodology will the project follow? What are the key dates or milestones for milestones like the acquisition

approval by business stakeholders? All of these questions are about the expectations stakeholders have of the project: what the project will achieve and how they will get involved. The first two questions are related to the objectives of the project and the last two to the focus of the project. The project objective is a statement of a measurable goal for the project. Let's talk about goals in more detail.

Reinforce Project Objectives Project objectives are an important focus that you will use throughout the project. They must arise from the overall business strategy of the client company, so the objectives of the project must be aligned with the strategic initiatives within the company. For example, if there is a strategic initiative to reach a new group of potential customers (called a market), the website or app you create could be an attempt to provide that market with online access to related products and services. The objective of this project would then be aimed at reaching and involving this market. A clear purpose resonates throughout the work. Helps you ask the right questions while gathering input from industry stakeholders. Design user research and focus your analysis on the results. Drill down and convert insights collected from stakeholders and users.

to a consolidated list of project requirements Prioritize these project requirements based on their value to the business



Create effective interaction designs. Manage design change requests as soon as development begins. Focus efforts during development activities (such as training and collaboration).

announcements to users about the new website or app before and during launch) Determine if you have met the needs of the client company

the project begins When you start a new project, you probably have project goals from the project sponsor (the business stakeholder who has direct responsibility for the success of the project), as well as a number of project-related requests from business stakeholders and customers. , but they may all have a slightly blurry appearance (Figure 4.1). Your goal is to articulate these into strong statements that you can use as a measure of project success.

Project related requests

Unclear goal of business strategy.

User Need Stakeholder Idea

unclear purpose

User Complaint Stakeholder Idea

Figure 4.1 Unclear goals, ideas and needs

A fixed goal is easy to understand. Avoid internal jargon. Discreet. Avoid vague statements. Instead, use wording that makes sense to you.

It will be helpful in prioritizing requirements. counted Make specific statements that you can define independently

measure to determine your success. If you define a vague objective, make it clear and measurable, it becomes a solid objective on which to base decisions.



Figure 4.2 Goals that solidify

Objectives of the business strategy project

You will hear many statements that can be considered goals. By analyzing ambiguities like the following, you can solidify your goals and communicate more effectively within the project team. corporate lawyer


"Our goal is to become the market leader in industry x."

This is a company-wide goal, but too broad for a specific project. Many initiatives in the company must come together for this to be possible. Any website or app can help with this, but it's highly unlikely to handle the full weight unless the entire company is involved with that website or app and it's hugely successful. corporate lawyer


"Our goal is to create excitement in our customer base."

This is better because a website or app can influence it, but it's still very vague. Why is it important to generate enthusiasm? How does this enthusiasm translate into meeting a business need? And how do you know if you passed? corporate lawyer


"Our goal is to increase traffic to our website."

Now we get there. This is easy to measure, but it is very focused on an intermediate step. Let's say you're driving traffic – it might not help if people don't take the actions they want once they get there.



Vague goals can give you an idea of ​​a client's needs and larger goals. From this, you can create stronger project goals, such as increasing online sales revenue by 10 percent. Increase your online advertising revenue by 20 percent. Increase the number of existing and potential customers in our client.

database to at least 20,000. Provide highly rated and highly regarded content to our core users.

(Keep in mind that it will take some work to decide how to measure "high rating" and "high referral," but the data is there to build on.)

Each of these can be measured and influenced by your project. They can also be tailored quite well to your designs and the features on offer. For example, it's very common to offer an online newsletter as a way to achieve a goal for customer database growth: to deliver the newsletter, you need to capture customers' email addresses, which are added to the database. Goals can also emphasize new requirements. For example, if you measure success by the average rating given to articles on your site, you need a feature that allows users to provide ratings. In this way, objectives help you focus as you gather ideas for the site, and they can become project requirements later. If there are multiple goals, be sure to create a priority list with your corporate sponsor and project team. Goals sometimes conflict during planning and the team needs to know what has priority. The final list of priority goals should come from your project sponsor, but you can be an important part of the conversation. Let's talk about how.

How can a UX designer help? If you find that the project objectives are not clear at the beginning of a project, you can use your facilitation skills. Help the project team understand the business context of the project by organizing a workshop with key stakeholders (see the next chapter for more information on how to identify the right stakeholders). Your goal in this session, which typically lasts two to four hours, is to gain insight into the company's strengths and weaknesses,



opportunities and threats. This is called a SWOT analysis and is a common business analysis technique and a way of analyzing a company's position in the market. You can also use this time to discuss the company's competition. Understanding Strengths and Weaknesses The SW in a SWOT analysis is the company's current strengths and weaknesses in relation to the project. Strengths and weaknesses can include internal processes as well as external perceptions, and they often influence each other. For example, a company with a large research and development (R&D) department may have access to a great source of originally published research (a great asset), but there may be no one to help make that content more accessible to the average user. to the perception that the company is "too academic" (weakness). Identifying OT opportunities and threats is the forward-looking half of SWOT. Given the things that set the company apart from its competitors, what future initiatives could you take to open up a new niche or strengthen an existing one? What situations could threaten these plans? For example, the R&D company may decide to hire writers to publish more accessible articles about their original research (an opportunity), but if their current website toolset lacks powerful content management capabilities, the process of Posting can be extremely slow. This allows competitors to react faster (threat). Compare Competitors Who is the company's main competitor? Who are the competitors of the site being developed? It can be different, especially for large companies or new locations. Are there sites that are not direct competitors but represent interesting models that should be considered? You can learn a lot by checking out other ecommerce sites to see if and how they sell what you sell. Bring SWOT and competitor discussions together are good topics to discuss at the same time because they communicate with each other. it's hard to talk



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 complete picture of the company's competitors and SWOT here, your project objectives, as well as the overall alignment of your project with the business strategy, should be easier to define and prioritize. Setting project objectives helps you understand the expectations of what the project will accomplish. Next, let's talk about expectations for how the project will go. Understanding the project approach will help you collaborate effectively and involve the right people at the right time.

Understanding the Project Approach Knowing the general approach or methodology of a project is an important part of understanding when and how it will and should involve others, such as the project team and business stakeholders. Sometimes there seem to be as many project approaches as there are projects. Choosing the right approach to a project is a big topic in itself. The methodology you choose can depend on many things, including the structure and location of the project team, the technologies used in the project, and the degree to which collaboration is part of the corporate culture. For the purposes of this book, we assume that you are involved in a project where the focus is largely determined by those responsible for the success of the project, such as the sponsor and the project manager. In this case, your primary goal is to understand the approach and help make it effective for your business stakeholders and users. Here we'll focus on two of the most common types of approaches, as well as a third that shows a possible variation you might see in a project. The important thing to keep in mind is that most approaches involve the same steps: planning the overall strategy, approach, and team structure. Define the project requirements. Design interaction and visual concepts and develop them into detailed concepts

Specifications. Develop, test and refine the solution.



Build the solution through messaging, training, and planned deployments. Expand the project making recommendations for improvements.

The names of these steps can vary, as can the extent to which they overlap and how the information is documented. But the general activities in each step are common to most projects and the three models presented here.

Waterfall Approach In a waterfall approach, the steps of a project are treated as separate, separate phases, requiring approval from one phase before the next phase can begin. For example, the design phase doesn't really begin until the requirements are approved by business stakeholders, who sign one or more requirements documents at the end of the definition phase. Approval




Define Design Develop Develop Extension

Figure 4.3 Example of a cascading approach, where each stage "drops" into the next.

The problem with a pure waterfall approach is that it assumes that each stage can be completed with minimal changes to the previous stage. Therefore, if you present new requirements in the design phase, which is common practice, you must propose changes to the documents that are approved at the end of the Define phase, which can mess up the design and schedule.

Flexible Approaches Because change is constant, project teams are constantly looking for more flexible approaches than the waterfall model. Many methodologies have a more fluid approach, where certain steps occur side by side. For example, website versions can be published on a rapid, iterative schedule using a flexible or rapid development approach. An agile approach typically focuses more on quick collaboration and less on detailed documentation and formal signing off. UNDERSTAND THE PROJECT APPROACH


repeat 1


repeat 2


repeat 3


Implement Design Implement Design Define Implement Design


approval provision


build version extension

Figure 4.4 Example of a flexible approach

A true agile approach (following best practices developed by Agile Alliance members, for example) requires small teams whose members naturally sit next to each other, with little regard for defining formal roles among team members. Working this way ensures a high degree of collaboration, reducing the need for extensive documentation between the design, development, and test phases. A team member can ask a question, collaborate with other team members in a quick whiteboard session, and implement a solution without the delay of detailed documentation and approval. Stakeholder reviews are conducted with a fully functional system when one of many iterations is released, and the resulting input is taken into account when designing the next iteration. (Iterations are approximate versions of a particular website or app.) If an agile approach works as designed, great. However, in most companies and most consulting engagements, teams rarely go for a purely agile approach. In part, this is because companies are increasingly using distributed teams and remote workers, making it difficult to maintain the high levels of collaboration needed to take full advantage of the pure agile approach.

Modified Approaches Most projects try to take a best-of-both-worlds approach, with enough structure and documentation to mitigate the risks of distributed teams and team member turnover, but with enough collaboration and iteration to do so in a relatively flexible way. . changes. For example, a project might follow a waterfall model, but overlap in stages so that there are key points for team-to-team collaboration. This makes it possible



possible changes that appear earlier in each stage. This can also be an early release (such as a beta release for a specific group of users) with a shorter iteration cycle. Feedback for this version may be processed before the new site is fully developed. Plan


design development



Deploy the deployment beta

build version extension

Figure 4.5 Modified cascade of beta versions

Consider the smaller iterations in the design phase in Figure 4-5. This is one of the greatest values ​​that you bring to your team as a UX designer. Tools like wireframes (Chapter 11) and prototypes (Chapter 12) allow you to gather feedback on rapid iterations of ideas before significant development time is spent. A modified waterfall approach like the one in Figure 4-5 is one of the most widely used methodologies, so it is the approach that forms the framework of this book. However, many of the topics discussed here will apply to your project, regardless of the specifics of your approach, because the core activities that underpin it, such as definition and planning, are still required.

Go Deeper If your project uses an agile approach, you will have a need to collect unique requirements, such as writing "user stories" as a way to capture the requirements. We recommend Mike Cohn's Applied User Stories: For Agile Software Development (Addison-Wesley Professional, 2004).



What effect does focus have on me? Knowing your approach will help you understand many things: what questions to ask and when. For example, if you are

When working with a pure waterfall approach, you'll need to go the extra mile to ensure that the requirements established in the Define phase contain all the information you need for the Design phase. (We discuss the requirements in the next chapter.) Expectations of how project team members will work together and how

this cooperation will be close. For example, an agile approach requires very close collaboration. A waterfall approach can typically involve one-on-one work, with touchpoints once or multiple times per week. The level of detail required in your documentation and the level

phraseology. Documents presented at signing points should be formal, almost like legal contracts. You usually need more formal documents in a waterfall approach, where a signature is required before moving to the next stage. However, you may also have some formal signature documents when you use an agile approach, for example, to gain insight at key decision points, such as when preparing a particular iteration for full release and deployment. Key milestones related to stakeholder approval and

develop in different groups. The approach will determine what different audiences need to provide at different points in the project, including stakeholder approval at decoupling points and feedback from potential users during a beta release. Now that you've established your project goals and understand the project approach, in the next chapter we'll begin the most important work in the Define phase: gathering the requirements.




Business Requirements Know the problem before you create the solution By the time the project team is together, you will probably have heard or presented many ideas about what needs to be done. There may already be lists of features provided by some prominent members of the company (your business stakeholders) along with their views on which features are most important. These are elements of the business requirements for the project and are a good starting point. To ensure that you have a complete solution at the end of the project, you must create and clarify the requirements from different perspectives. In this chapter, we will focus on gathering and elaborating the requirements of your business stakeholders. carolina chandler



Chapter 4 dealt with vague objectives and discussed some ways you can clarify them for yourself and the project team. In the early stages of a project, you probably also have a set of requirements that are relatively vague. These may include stakeholder ideas, user complaints, or user requests. To create these useful and traceable elements of your project, combine these ideas into requirements. Requirements are statements that specify what the website or application must do. Ideally, a business requirement Provides insight into the overall need to be addressed Represents and unifies the needs of different stakeholders Gives direction to the design without being too specific about what it will look like

completed Serves as a separate unit of work for prioritization and tracking purposes

Here's a sample idea for a feature on an ecommerce site. You might have the same idea early in the Define phase from a few different business owners: "Customers can track their orders online." This is a good basis for a claim, but it is vague. Start asking questions about the details of the requirement, such as why it's important to the business for customers to follow through.

online orders? For example, is it to reduce the number of calls to customer service? Does the company have the ability to track packages online?

If not, new monitoring requirements must be documented or the company may need to work with a third party. How accurate does the tracking need to be? What type of information

Should it be included in the monitoring data? For example, should the website provide a current estimate of delivery time? Asking these kinds of questions helps you turn vague ideas into strict requirements. It will also make it clear that the same statement can mean different things to different people.



For example, a stakeholder may think that tracking a package means receiving a confirmation email from a stakeholder idea with a tracking number, which can be entered on UPS.com or another website for the stakeholder to track. can see where the packet last arrived. Idea Another stakeholder may believe that the company should promote package tracking and invest in developing the ability for customers to track packages via GPS, where they can see the exact location in real time using an online map. As you can imagine, there is a significant difference in user experience and reach here! It is important to identify these differences early in the project. Otherwise, you end up developing a solution that ignores the intent of the business stakeholder and you may miss the goals of the project. This leads to dissatisfied stakeholders and, if the feature needs to be redesigned, wasted time and money. Therefore, clear and detailed requirements are an essential part of your overall project. Accessing a consolidated list of project requirements involves the following steps: 1. Understand the current state of the site or its competitors. 2. Gather needs and ideas from business stakeholders and current and potential users. (See Chapter 6 for details on working with users.) 3. Consolidate ideas into requirements. 4. Prioritize the requirements based on the objectives of the project. (See Chapter 9 for prioritization tips.)

Business and user requirements Project requirements Business strategy

Figure 5.1 Combining insights from business stakeholders into business requirements and insights from user research into user requirements. Then use the project objectives to focus your priority efforts and create a unified list of project requirements.



First, let's talk about understanding the current state of your site so that you have a framework for the ideas that come your way during requirements gathering.

Understanding Your Current State When considering the details of the website or app you're designing, it's important to start with an understanding of the current state of the site (if you're redesigning an existing site) or a better understanding of the main competitors (if you're designing a new one). new website or app). You can learn a lot about the current situation through stakeholder interviews (more on this in a few pages). You can also gather a lot of information yourself, and this can serve as a solid foundation for stakeholder interviews and user research. A great way to get background information and generate ideas that can become requirements is to do heuristic analysis.

By another name... The word heuristic means rule of thumb or best practice. A heuristic analysis now means an evaluation of a product against a set of rules (heuristics) for a usable design, usually done by a UX designer. User-friendly sites follow most or all of the heuristics you use in your analysis. You may also hear this technique for heuristic evaluation, expert judgment, or a combination of these terms.

Heuristic analysis Heuristic analysis is a technique you can use to assess the usability of an existing design based on user experience best practices. You can perform such an analysis on your current website at the beginning of a redesign project or analyze competitor sites to understand the potential to provide a better user experience than other companies. The result is a document that describes the strengths and weaknesses of the site, including recommendations for improvement. After it's done, you'll have a deeper one.



understanding of the site being analyzed and a list of ideas that will contribute to the requirements for the new site. For example, a commonly used heuristic is this, from Jakob Nielsen's list of ten heuristics (see the full list on Jakob Nielsen's website at www.useit.com/papers/heuristic/heuristic_list.html):

Visibility of system status. The system should always inform users of what is happening, through adequate feedback in a reasonable amount of time.

There are many cases on a website where this heuristic cannot be followed. Let's say the user clicks a download button and isn't notified that their file is being downloaded. The system has not informed the user that the file is being downloaded, even though the download has started. So the user may click the button again, thinking they missed it the first time... and then click it again... This can lead to multiple downloads, which could cause problems both for the performance of the site and for the user, who now has multiple downloads without you noticing. During the heuristic analysis, you can mark it as a problem area, describe it, and assess its impact. You can also share an idea that could solve the problem, which could be added to the list of requirements. Why heuristic analysis? Performing this type of analysis is a relatively quick and inexpensive way to get feedback on a design. Heuristic analysis can provide a general understanding of design quality and help identify potential design problems. Please note that this activity is not directly related to end users and should not replace actual user research. For example, it is likely that only 50 percent of your heuristic findings can be validated by follow-up research. However, the analysis gives the team a good idea of ​​possible points of attention. If you're in the process of redesigning an existing product or website, it can also be useful for identifying obvious quick fixes that can lead to immediate improvements while redesign efforts continue in the background.



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 knowledge about the product and project history. Make sure you have the goals of the site, a list of the main user groups to support, information about the type of environment your users are likely to work in, and a basic understanding of any specialized knowledge your users may have. (For example, your analysis will be different for a site created for general consumers than for a site created for pharmacists.) If you need help with the latter, visiting several competing sites or apps can help you identify common terminology and areas of understanding. of interest . 2. Choose the heuristics 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/irstPrinciples.html. Once you're familiar with the site's theme, you may want to add some of your own, especially if you're looking at more than one site. Be sure to keep your list organized (for example, 8 to 12). too many heuristics can make the technique cumbersome for you and your readers. 3. Walk through the priority areas of the site and identify areas where heuristics are followed or overlooked. Each observation you make should include the following information: The general observation. A brief statement summarizing the finding. Ideally, these are numbered so that you can refer to them quickly as you review the people in the report. A short description. One or two paragraphs describing the context of the observation, for example, the point in a particular process where you noticed a problem. Impact Rating. This rating can be high, medium, or low for problem observations, or it can be a positive finding if you share something the site did well. In general, high-impact issues are those that you believe will prevent many users from completing a particular task or task.



you lose information permanently (for example, a problem that causes a user to lose changes to a document they are editing); Medium-impact issues are issues that cause frustration and errors, but do not cause irreversible problems. Low-impact issues are minor issues that may cause some confusion, but generally don't lead to wasted time or frustration. recommendations These are the next steps or ideas that you share that can serve as a solution to the problem you encountered. Figure 5.2 shows an example of these elements together as they might appear in your heuristic analysis. Observation #4 The search function does not seem to return all possible results.

high anxiety

A sample test of the search function produced mixed results. Named searches on a relatively new post on a less covered topic occasionally returned no results. It also seems that the main search only returns links to new stories, not videos. Recommendations 1. Make sure that newly added content is indexed and searchable before, or very shortly after, it is made publicly available. 2. Consider showing related content when search results return, for example, stories in similar categories or with similar tags, so that users who are browsing can follow more threads. 3. Browse the global search that displays results by category. 4. Use search term logs to understand commonly used items. This can also provide information about items that users are having difficulty finding.

Figure 5.2 Example of observation in a heuristic analysis report

4. Present your findings to the project team and key stakeholders. Scroll through their comments and recommendations. Discuss why you gave the grades you did. (This is also a good time to have tips ready on how to validate your findings, using one of the techniques discussed in Chapter 6.) How does heuristic analysis help you 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 you qualify. You'll also have some ideas about how to structure the topics to cover in your requirements gathering sessions, which brings us to the next step in this process.



Gathering Ideas from Stakeholders As we saw in our example at the beginning of this chapter, you run the risk of experiencing differences in expectations among stakeholders, such as our friends who want packages to be tracked by GPS. One of the most common mistakes made in a project is to take a feature and call it a requirement without first understanding the problem and the expectations surrounding a solution. So why is the collection process aborted so often? Gathering ideas, and compiling them into requirements, can take a long time. It's easy to underestimate the number of questions you need to ask to describe your requirements so they can be prioritized. And if the process is not well structured or participation is lacking, there can be many interruptions throughout the project. (Rotation is a waste of time in additional meetings and work iterations caused by a lack of communication and participation. These are different from the more productive work iterations that are part of designing and testing valid solutions in an effort to find the best). Do you encourage a balanced requirements process that focuses on business needs but avoids being insensitive? Here are some steps to an effective process: 1. Summarize roles and responsibilities. Make sure project team members understand their roles when requirements are collected. 2. Gather the right stakeholders, in the right groups, to ensure the best use of time during interviews or meetings. 3. Make a plan for the meetings, including the topics that will be discussed and the questions that will be asked during the meetings. 4. Lead meetings effectively, capture ideas and get clarification. Explore ideas to determine the needs behind each idea. When your meetings are over, don't forget to thank stakeholders 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.



Description of Responsibilities Gathering business requirements typically involves interviews with key business stakeholders by project team members to gather ideas. Commercial stakeholders are those within the company who have a commercial interest in the success of the project or have subject matter expertise to contribute, or both. These people are not involved in the project full time, but they need to be involved at key points in the process, and requirements gathering is one of those points. Keep in mind that they also receive daily wages (so to speak), so their time is valuable and often hard to come by unless you plan ahead. The project sponsor(s) is the business stakeholder who is also directly responsible for the success of the project, often at a relatively high level in the company, such as the manager. He or she will not be involved on a day-to-day basis throughout the project life cycle, but will likely be actively involved in gathering requirements and ensuring a high level of buy-in from business stakeholders. The sponsor may also participate in some or all of the sessions. The project team is made up of people who are formally assigned to the project as ongoing resources. They can participate as a project manager, UX designer, business analyst, technical lead, visual designer, QA lead, etc. Depending on the size of the project, this may be your primary task. Within the project team itself, responsibilities during requirements gathering are often unclear. By taking the time to define responsibilities early on, you can ensure an efficient assembly process. Here are some questions to ask as you determine the specific responsibilities each team member will have during requirements gathering: Who is primarily responsible for collecting and scheduling the right work?

Interested in the most productive groups? These can be both internal and external stakeholders (such as partners, suppliers, etc.). Who creates the structure of topics and questions for business interest

owners meetings? This is a great team building exercise for the team, weather permitting. The lead facilitator can then organize them into a structure that flows well in a meeting. Who facilitates the meetings? Who takes notes and how are they shared?



Who's following who now? Is someone from the technology team present at all meetings?

If so, how is this person involved (listening, reporting, or something else)? As a UX designer, whether or not you are primarily responsible for one or more of these areas, you have important skills to bring to the process. Creating a structure for topics and questions requires the ability to categorize clearly (which sounds like a good cross with information architecture) and of course facilitation skills are important to keep the meeting on topic and get everyone involved. the assistants.

Gather the Right Stakeholders The primary goal of interviewing stakeholders is to understand relevant project-related ideas, needs, knowledge, and frustrations from different perspectives, which can then be incorporated into 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 as a result will be involved in the final solution. While it may seem more political than practical to engage people to gain their support, 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 last-minute changes, which can happen when someone you haven't talked to raises an issue late in the process. Therefore, it is often a good idea to involve a wide variety of people. On the other hand, schedules and budgets must be taken into account. It takes time to onboard a large number of people, both from their perspective and yours, just for meetings, not to mention the time it takes to review notes to spot trends and consolidate layoffs. For efficiency and your own sanity, it makes sense to prioritize the groups you will be speaking to and select key people from those groups to act as thought leaders for your group. Who are the potential stakeholders you could involve? These groups are often good sources of ideas: Groups with location-based initiatives (for example, those with

marketing campaigns that must have information on the website)



Teams that have to support the processes directly behind the website or

application, such as providing content, entering and managing data, and responding quickly to information collected Front-line customer service, such as telephone or online support or

anyone who interacts with customers face-to-face (for example, in a store or through delivery) Sales, product management, or consulting, for

products and services presented Human resources, to meet recruitment objectives Public relations, to present information to investors and media All teams responsible for other relationships to be developed

as part of the project and will affect the design, such as relationships with partners or suppliers. When selecting the people to include, enlist the help of your project sponsor and any project team members who are familiar with the groups involved in choosing the most appropriate one. . Create groups that will have a good discussion. There is no one correct way to do this, but a common way is to group stakeholders by department as follows: Marketing (five people) Product Management (four people) Customer Service (two people) Sales (four people)

A smaller project might involve one person from each of these groups, in a series of two or more collaborative work sessions where everyone comes together. Once you have the stakeholders in mind, as well as a general structure for the meetings (discussed in the next section), you can start planning the meetings. Try to start planning at least a few weeks in advance. it can be difficult to get everyone in one room.



Make a plan for the meetings In addition to selecting the right stakeholders, make a list of topics to be covered and questions you want 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 many of your questions may be the same from group to group. You should also decide the level of detail you aim for in meetings. If you meet a large number of people only once (for example, members of different departments, as suggested above), you'll be eager for ideas, but you probably don't want to spend a lot of time delving into the details during the meeting. In this case, if a potential customer gives you the idea that "customers can track their orders online", you might want to ask why this feature is important and if the potential customer is wrongly thinking of a site that they are doing well These questions will help highlight key differences between stakeholder expectations of the position without spending the entire meeting on one statement. You can then work out the specifics of the idea with the project team and consult with the stakeholder to ensure that the requirements you set still represent your original idea. Let's say you're redesigning an e-commerce website and you meet with a wide variety of stakeholders, holding one meeting with each group. Here is an example of a meeting plan with a team from the sales department.

Sales: Qualify Gather Inside Sales Participants: Jenny Bee, Tracy Kim, Joseph Arnold Management Leads: Kevin Abernathy, Cat Parnell Timeline: 2 hours Objective: Understand the current sales process and identify issues and opportunities for how the Internet can support this process. Background: We watched a PowerPoint presentation on the buying process that provided a good background on how buying decisions are made. We also plan to talk to customer service.



Sales: Request-Collect Continued Questions Sales Process: How does the sales process differ for different product lines? Are there regional differences? Are there differences based on the size of the client (for example, small companies versus large companies)? How has this process evolved in the last two years and how is it expected to evolve in the next three to five years? How does a potential customer understand all the things that need to be purchased and how they work together?

Overall impression: who do you think are the most important visitors to the current website? Because; How is it exactly? What are they trying to achieve on the site? How does the Internet contribute to the sales process and/or sales closing rate these days? What information do customers need to make a buying decision? Is this information available on the website today? Is it easy to find? Is it accurate? How hard is it to keep content on the website these days? What statistics do you get from the site? What additional metrics would you find valuable? Because;

A vision of the future: If you have a future site in mind, what can we do to better support the sales process? What current site functions and features are critical to sales? It is not necessary? Missing?

Summary: Are there any other ideas, suggestions, or concerns that we haven't addressed? What sites do you think are good at supporting sales? What is the most important thing the company could do to improve customer satisfaction?



Run meetings effectively Here are some tips to help you qualify. Make sure a common vocabulary is used Much confusion can be avoided if the group meeting requirements agree to a common list of terms and definitions. For example, are the people who use the system called users, customers, or customers? Are people more familiar with the term interaction designer or information architect? To avoid confusion, take a moment at the beginning of each meeting to identify the term being used and what it means. You may also benefit from creating some visual elements that help explain the relationships between different terms or functions (see Figure 5-3). Category












Figure 5.3 Scheme with project conditions and relationships

A common vocabulary for the deliverables to be used in the project will also help stakeholders understand the process and the type of results they can expect. This can inspire confidence that your time and effort aren't going down a black hole of ideas. If you find yourself defining the same words more than once or twice (especially if you notice that the definitions change subtly each time), consider including them in a project glossary and sharing it with the project team. Other examples of terminology that it is good to clarify at the beginning of the project are;



Interacting roles (for example, job seeker vs. client or

theater producer vs. editor) Primary deliverables to be widely referenced (functional specifications

structure, wireframes, sitemap) and a brief description of how they differ. Differentiation between different levels of information (such as our category

information in figure 5.3) Distinction between needs and ideas

Listen to Ideas and Respond to Needs Stakeholders may make claims that appear to be needs. Consider an example. corporate lawyer

"We need a blog on the site."


This is really an idea, not a necessity. Then, when the blogging functionality is fully designed and implemented, it becomes a solution, but not necessarily the one that best meets the basic needs of the stakeholders that demand it. If you ask why a blog is important, you might get a wide variety of need statements, such as "We need to appear relevant and connected." Everyone is talking about blogs and I feel like we would be behind the times if we didn't include them with a following. "We need to position ourselves as opinion leaders, and blogs are a more personal way to show our expertise." "We need to have a better way to communicate and innovate with our customers, and our blogs get feedback so we can hear your views." Each of these statements describes valid needs. Citing them will help you learn more about the drivers behind specific feature requests, which will help build consensus as you consolidate and prioritize requirements.



Fusion Requirements When the meetings are over, take the ideas you've collected and categorize them into broad areas of functionality. You will notice a lot of overlap. This is a good sign that a particular idea has a lot of interest from stakeholders. Eliminate redundancies and try to consolidate a list of ideas that effectively represents the intent of your stakeholders. To turn the ideas you've collected into actionable, trackable elements of your project, you need to combine those ideas into requirements. Consider raindrops emerging from a cloud: it goes from a large, indefinite cloud to a larger number of well-defined raindrops. So when you get a cloud of ideas like "Customers can track their orders online," you need to turn them into unobtrusive statements that dictate what the system should do. The resulting requirements should provide an idea of ​​the overall need that must be met. Represent and unify the needs of different stakeholders Direct the design without being too specific about what it will look like

integrated Serves as a separate unit of work for prioritization and tracking purposes

As you begin to move from ideas to requirements, make sure your technical lead (or someone else who can represent the development team on your project) is on board to ask the questions that will help you estimate the effort required to set priorities. . If you have a dedicated QA team member, that person can also ask some very detailed questions to qualify. To break down your tracking idea into requirements, ask questions like How accurate should the tracking be? What kind of information should be included in the monitoring data? For

For example, do we need to provide an updated estimate of delivery time? These types of questions can be asked in detail and discussed 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 by having discussions with the project team.



and then discuss the requirements with your project sponsor to make sure your choices make sense for the company. Table 5.1 provides an overview of the types of requirements that can be combined with the monitoring concept and how to capture them. TABLE 5.1

Business Requirements Example

ID card



track order



track order

track order



Orders can be tracked by

encourage self-care

entering a tracking code

upon delivery (Support



Users can track their package-

Show efficiency innovation

age with gps truck tracking

accurate delivery (competitive

or planes


Users can see all previous Encourage Reorder and orders made in the last 365 days

self-service (sales, support benefit)

Note that in some cases the requirements overlap, such as the first two requirements in the table: both are tracking methods. They can live together in the same system because you can enter a code to find your package through the GPS view. However, they are separated as the GPS related requirement probably requires more effort and should be prioritized independently of the other features. As you consolidate the statements, consider any business requirements that you think may conflict with user needs. For example, a business requirement may be to collect personal information from potential customers, such as their email addresses. But customers may have reservations about providing information. After all, forms take time to fill out, security and privacy are a concern, and this step can interrupt the larger work they're trying to get done. As you identify such conflicts, they begin to provide you with information that can help you meet business and user needs. For the tracking example, you might suggest using the "Send to a Friend" feature to capture the email address to make it easier for the user. This means that sending a friend can become a requirement that you add to the mix for prioritization. this kind of ideas



one can help meet business and user requirements, so they are perfect for capturing. They also live in this overlapping area between the Define and Design phases (see Chapter 4), as you begin to think about design solutions to business problems.

Design Definition Development Potential conflicts between business and user needs are great things to explore during user research, which we'll discuss in the next chapter. User inquiry also allows you to extend Table 5.1 to a full set of potential requirements, to be prioritized into a list of project requirements (shown in Figure 5.1 and discussed further in Chapter 9). Please note that business requirements gathering generally occurs in parallel with exploring technical possibilities and gathering user requirements. Next up: time to talk about users!




User Research Get to know the guests you are inviting to the party There are many user research techniques that can be used throughout the project lifecycle, either to better understand your users or to track their behavior across versions. from a website to test. This chapter discusses some of the most commonly used methods in the early stages of a project. These techniques help you determine which user groups should be given the highest priority during the project, put their needs and frustrations in context, and assess current site performance (if any) using site management best practices. carolina chandler

Basic User Research Steps 1. Define your main user groups. This includes creating a framework that describes the main types of users you're designing for, so you can focus your efforts on recruiting users for research. 2. Schedule user participation. This includes choosing one or more techniques for engaging user groups in research, depending on the needs of your project. 3. Take the survey. Here we cover the basic techniques, such as interviews and surveys, and give advice on how to apply them. 4. Validate your user group definitions. By using what you have learned from your research, you can solidify your user group model. This model will then serve as a platform for developing more detailed tools, such as faces (discussed in Chapter 7). 5. Establish user requirements. These are statements about the features and functionality that the Website may contain. Add these statements to your business requirements (discussed in Chapter 5) and prioritize them to become project requirements (discussed in Chapter 9). This chapter covers the first three steps, starting with the first: defining your user groups.

Define your user groups Planning for user research at the start of a project can seem like a chicken-and-egg dilemma (what 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 start is to create an initial or preliminary definition of the users you will be designing for. This describes the main groups of users on your site, which can help you focus your research efforts on the right roles, demographics, or other variables that may affect how users will experience your site. User group definitions can be high-level (a list defining each of the intended user groups) or detailed and visual (a diagram showing many types of users and how they interact with each other).



A high-level definition for a company's main .com site might include the following user groups: potential buyers, current buyers, partners, and job seekers. As you begin to define groups for user research, you will begin to 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 that might interact with the site. These definitions can be made by collecting some objectives and characteristics that different user groups may have. Here are the basic steps to define your user groups: 1. Make a list of attributes that will help you define the different users of your site (the next section covers some of the more common ones). 2. Discuss the features with those in the company who interact with the relevant types of users (eg, customers). 3. Prioritize the features that seem to have the biggest impact on why and how a potential user would use your website or app. 4. Determine the user groups to which the research and design should be directed. The following sections take a closer look at some brainstorming techniques to help you collect these features and how to prioritize and model them (make representations of different types of users to help you focus your research efforts).

Create a Feature List A good place to start with your feature list is to collect and incorporate research or other documentation your organization has that can help users. Here are some possible resources: Documents that explain business strategies, such as business goals,

trivia, marketing strategies and business plans Current customer market segments and other demographics

Compiled by Marketing Research from Past Users (see Table 6.1 for some examples)



Surveys, such as user satisfaction surveys and feedback forms Customer service reports on common issues

Next, identify people within the organization who have some insight into current or future users. The number and variety of people to include will depend on the type, scope, and schedule of the project. If you know that your first set of user groups may be short-lived (for example, only used for a month or two while user research is designed), then you may only include two or three participants. If you think the first definition should slow you down through much of the design process (for example, if you can only work with it until you do a usability test after you design), include more participants. and provide a cross section of perspectives. Some potential participants include marketing staff responsible for brand representation, segmentation, and campaigns. sales staff? product managers, customer service or support representatives, and trainers. It is also good to involve project team leaders and other business stakeholders in this exercise. Ask the team to think about the different types of potential users they typically interact with. Then ask them to list some of the common traits they found. Here are some examples of what might differ: Main goals related to the theme of your site. Because it is

users come and what are they trying to achieve? For example, buying an item, trading a stock, or answering a specific question are common goals. Clock. This can be defined in many ways, but one way is to associate the roles with the

the main purpose of the user: job applicant, help applicant, potential client, etc. Once you have more user information, roles can be divided based on different needs or styles. For example, on an e-commerce site, shoppers might be bargain hunters and savvy. Demographic data, including age, gender, household (single, married, children);

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

technologies (often referred to as technical knowledge), level of expertise, and frequency of use (one-off, incidental, frequent). 88


Organizational characteristics, including the scope of work of the users of the company.

for your department, job type (entry level, freelance, middle management, executive), employment (long term or high turnover?), and work patterns (remote work, amount of 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 level of importance, and then use this hierarchy to begin defining and modeling user groups.

Prioritize and define Which of the features listed above do you think would have the greatest impact on how and why different user groups might use the site? Focus on the ones that you think will have the biggest impact on a user's goals or behavior. Prioritize these traits and remember the goals you set in Chapter 4; they also help you make decisions. An example better illustrates how to prioritize features. Let's say you work with a company that provides tools for trading stocks, options, and futures online. This particular company has determined that part of its strategy will be to attract non-professionals who trade stocks online and encourage them to trade new types of products, such as options and futures. The company intends to do this by providing trading tools that are easy to use and aimed at those who want hands-on learning in a safe environment. When discussing the features with business stakeholders, you may find that the following things seem to have the biggest influence on how people can use these tools: Current frequency of transactions, especially the frequency of instant online transactions.

(for example, once a quarter, once a day, several times a day). Those who only trade (for example, once a month) may not be serious enough to try something new, while those who already trade full time may not find much value in tools aimed at newer traders. But those who are active part-time traders might get very interested in the company's tools. Number of types of products traded: only shares or shares, options and

term contracts. Those who already market all types of products may prefer their own tools, but those who only market one type may be ready to expand to others. DEFINE YOUR USER GROUPS


Level of professional knowledge (for example, familiarity with trade

conditions). This will help you determine how much help they will need along the way, with tutorials and glossaries. Level of technical knowledge (for example, familiarity with making purchases

online and online banking and transactions). This affects how much security they need about data privacy and how advanced or simple the online interface needs to be. You can prioritize these attributes because they can affect the type of users you target for research. If where traders live doesn't seem to have any real impact on how or why they trade, the Region attribute can be removed from the list as a consideration for survey participants. On the other hand, if the importance of a particular feature generates a lot of debate, it might be a good topic for a survey or interview question (more on surveys later in this chapter).


Comparing two or more features can also help you prioritize. For example, if you create a chart with two attributes for online sellers, you can start to see how the groups rank in some areas. Figure 6.1 is an example of a global user model that you can create using the two attributes Instant Transaction Frequency and Number of Product Types Traded. It also shows the resulting user groups that can be formed from the discussion.

Full Time Product Specialist

Full time I understand General

Instant transaction frequency

"Second job" merchants.

Supplemental Income Marketers

active explorers

long term investors





Number of types of products traded (stocks, options, futures)



Figure 6.1 A diagram with two features, representing a global user model. By building this model together, discussion about possible differences in user motivation and experience can be facilitated.

This user model provides a way to discuss different types of users at a high level. It is not intended to be the definitive model and does not solely specify user groups (a user may be a long-term investor in stocks and also actively explore other options or futures opportunities). But it begins to express your understanding of the different groups of users and how they can be motivated to use your site. This discussion of key features will also help you figure out which ones to focus on when recruiting users for research. If you determine that trading frequency is important and your priority will be to engage those who currently have a medium frequency level, you'll want to define what medium frequency means (for example, one to three times a week) and recruit participants to do your trading. investigation. respectively. Speaking of research, let's talk about techniques you can use to engage users in your project.

Can you design yourself from user models? There is some debate in the user experience field about building user models before doing research, because it may change your thinking before you have actual user data, and because your project team or project sponsor project may see the model as a replacement for user research. Using an unvalidated model increases the risk that your assumptions are incorrect. However, in projects where you don't have any user interaction, a well-thought-out model (verified with sources outside the project team, such as a customer service or training team) is better than no model to use. during design.

Choosing Research Techniques Now that you have a rough idea of ​​the user groups you want to include, it's time to plan the next step: your recommendations for the amount and type of user research activities to be carried out during the project. . Table 6.1 provides information on the most commonly used investigative techniques and when they tend to be most useful. Use this table as a reference to help you choose which one is best for your project. The following section describes each technique in more detail.



BOX 6.1

Common Research Techniques for Users






User interviews

A one-on-one chat with a participant who belongs to one of the main user groups on the site.

There is user access, but the type of access (personal, telephone, etc.) varies.

Get clear opinions. Gathering information on attitudes and context can be difficult, especially if interviews are conducted remotely.

2-4 weeks for 12 interviews: up to a week to plan, 1-2 weeks to interview, and up to a week to collect results.

contextual research

On-site visit with the participants to observe and learn how they work in their habitual and daily environment.

The project team Accessing the project has little information about the participants. Pass to target users. In the user environment, users working in a single environment may raise intellectual security issues (for example, a hospital). property and attackers proceed with caution. For companies with fairly complex applications, perform tasks or workflows. it might be easier to visit on a weekday.

3–4 weeks for 12 surveys: 1 week for planning, 1–2 weeks for observation, 1 week for analysis and reporting of results.

To the investigation

A series of questions consisting primarily of closed-ended (multiple-choice) answers that are used to detect patterns in large numbers of people.

You want to express the results in more quantitative terms (for example, "80% of the target audience say they never buy cars online").

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

You want to get content, but you can't reach the user.

You are more interested in collecting information about preferences than actual performance.



Obtaining an adequate sample. Make sure questions are well worded to get accurate answers without leading respondents to a particular answer.

BOX 6.1

Common User Research Techniques (continued)






Focus groups

A group discussion where a moderator guides participants through questions on a specific topic. It focuses on revealing the feelings, attitudes and ideas of the participants on the topic.

The team believes that user behavior will greatly influence how you use the solution (for example, if you have had problems with it in the past).

Understand how to target your questions to get the right information.

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

sort cards

Participants are given objects (as themes) on cards and are asked to sort them into groups that are meaningful to them.

You are working on a content feed site with many components and want an efficient structure for your user groups.

Determine the best subjects to photograph.

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

usability testing

Users attempt to perform standard tasks on a website or app while a moderator watches and, in some cases, asks questions to understand user behavior.

An existing solution is being improved.

Choose the right tasks to focus on.

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

Competitive solutions are available for testing. You have a prototype that allows users to complete (or simulate) tasks.

Effective team guidance.

Determine how formal the test will be.

* Typical time frame represents the time often required from where users are scheduled. Two groups of six to eight users are considered (except surveys, where the number of users must be higher). This does not include recruitment time, which can take a week or two after the recruitment questionnaire is created.

How many research activities can I include? Before choosing between activities, ask yourself how much money and time the team can spend on user research. Consider the following scenarios to understand how eager your client company is for user research. If project management and project sponsors are comfortable with user research and are interested in using it for known purposes, such as making sure the site meets specific project goals, then you probably have more CHOICE OF TECHNIQUES. RESEARCH


when you schedule two or more activities, or for an activity that you perform multiple times (for example, try a plan, change it based on your results, and try the new plan again). If no one in the organization is familiar with user research and there is some resistance to it in general, it might be best to propose a round of research and choose the technique that you think will bring the most value to you, the project team, and parties. business stakeholders. Once you have the survey results, the project team will have a better idea of ​​what is involved and how it can benefit the project. So you have a strong argument to include more research later if necessary. If you have room for at least two rounds of research, it's a good approach to include one round during the Define phase or early in the Design phase to better understand your users. Then add another round before deployment begins to validate the design. For example, for a task-based application, you might interview users before designing and run usability tests on a prototype later in the process. Or for a content source, you can start with contextual research and then add a card sorting exercise.

Research planning considerations When planning a research technique, consider the following: Why you are doing the research: what you want to learn from it Who you will involve: the main user groups you described above How you will get participants: recruit people to participate and assess them (i.e. ask questions to make sure they belong to the user groups you are targeting) How you will compensate participants What space and equipment you will need What you will cover: the key topics How you will record the information: the number of people They Participate and the Tools They Use Chapter 13 addresses each of these considerations as part of a detailed look at one of the most widely used techniques by UX designers: usability testing.



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

Surfer Steve Baty wrote an article describing different methods and how to choose between them based on their stage of development, your information needs, and the flexibility you have to incorporate 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 take place over the phone, in person in a neutral location (such as a conference room), or ideally in the environment in which the user is likely to use the website. (The latter situation is also ideal for contextual research, which is discussed below.) Interviews help you understand the preferences and attitudes of the participants, but should not be used to make formal statements about actual performance. If you're looking for specific information about how people interact with a website, it's best to observe them (for example, in a contextual survey) or ask them to perform tasks on the website (during usability testing). Site analytics can also give you insight into certain performance insights that can be particularly powerful when combined with interviews or surveys that provide context for the data. The Basic Process For user interviews, the UX designer creates a list of questions aimed at eliciting information such as: Relevant experience with the website or topic.



The brand of the company, as perceived by the participant. For example, attitude towards the thematic categories treated (for con-

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

competitor Common next steps users take after visiting the company's website Other people involved in the experience. For example, does a

Does the user tend to collaborate with another person as part of the larger goal they are trying to achieve? Are they likely to share information or seek input from others along the way? Any other information that helps you validate your assumptions

about user groups so far, for example, whether the variables you discussed when creating a temporary user model seem to actually affect how users experience your site. If more than one person is conducting interviews, it's a good idea to have a set list of questions and a scripted introduction that can be used to keep interviews consistent. Choose in advance how structured you want the interviews to be. If it's a formal report, you probably want a high degree of structure, where the order of the questions doesn't vary too much and each question is asked with few additions. If richness of data is more important than consistency, you may decide to go for semi-structured interviews, where you start with a list of questions but allow the conversation to follow a natural path, with the interviewer asking questions to explore more points of interest. (called detection). The length of your interview may vary. 45 to 60 minutes is usually the best range to shoot. It gives you plenty of time to build rapport and answer a wide variety of questions without boring your participant. User interviews provide a rich data set that you can use to write characters, which are covered in Chapter 7.



Interview Tips The quality of the information you get from an interview has a lot to do with the quality of the questions you ask. Focus on the personal experiences of the participants. Don't ask them to speculate about what they might do in the future or what others might do. This type of information rarely predicts what they will actually do. Do not ask questions that imply a certain answer or that lead a participant in a positive or negative direction. Ideally, the questions are simple, neutral, and open-ended. Some examples of key questions are What do you like about PseudoCorporation.com?

This assumes that the user enjoys using the website. Only use this question if you are also asking what they don't like. Does PseudoCorporation.com live up to your expectations?

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

and, if it's the latter, why do you think it's better than Pseudo? This has some problems: it asks two questions in one statement and imposes an implicit opinion on the participant. The best questions to ask are: Tell me about your last visit to PseudoCorporation.com. Why did you go there? What do you remember of your visit?

If you are conducting a large-scale, more formal series of interviews, you may want to include some multiple-choice questions. However, for the most part, these do not give you very rich information. It can be difficult for participants to follow when they are asked verbally and do not allow users to provide explanations. In general, save these types of questions for leaks or surveys. Take a test drive with someone, perhaps someone within the organization who is not a member of the core team. This will help you uncover questions that may not be obvious, and will also help you improve your timing and flow. If possible, and the participant agrees, record the interview so that others can benefit by hearing the answers directly from the participant's mouth.



Contextual research Contextual research combines user observation with interview techniques. The UX designer speaks to the participants, ideally in the context in which they are likely to use the website. For example, for an office application, contextual research would involve sitting at the participant's desk. This method provides you with extensive information about the context in which a participant works, including problems users face in real life. The type of team they work on. The room in which they work, especially the size of the room in which they work.

they have, how much (or little) privacy they have, how often they are disturbed, and how they use the phone and paper (pay special attention to the impressions they have posted or the notes they have on hand). Your preference for using a mouse over a keyboard. This can affect a lot

your design choices, especially if you're designing a tool that requires a lot of data input. How they collaborate with others, both in terms of collaboration and sharing.

sources. For example, if more than one person uses the same computer, the way connection and security features are designed will be affected. 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. Surveys combine observation time and interview time. They can last from a few hours to several days. If participants cannot commit to a minimum of 2 hours, consider just doing an interview. During an observation, the participant needs time to get used to her presence and act naturally, and this does not happen after only 15 minutes. The Basic Process Prepare a 10-15 minute introduction to use with each participant. It should contain the purpose of the study, a general description of what you will do together (the observation and the interview) and how the


the information will be used. This is also a good time to get signatures on consent forms to reassure participants that what they share will remain confidential. Start with some high-level questions about standard participant processes, especially those related to website design. Inform the participant when you are ready to stop talking and start observing. Observation can range from active to passive. In active observation, a common approach is to have the participant assume the role of teacher and you assume the role of learner. The teacher explains what he is doing as if he is teaching you his process. Active observation often gives you more background information about the reasons for the participant's behavior, but it can affect how the participant proceeds. In passive observation, you encourage the participant to pretend you're not even there. Your goal is to observe behavior 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 you are trying to solve, but if they are passively observing, they are more likely to see it happen. You can then follow up during the interview portion to ask about the reasons behind some of the behaviors you observed. Both approaches can work well. In general, if you don't spend a lot of time with the participants (for example, only 2-4 hours each), you may choose to use active observation to ensure you get the information you need. If you have a full day or more to spare, passive observation provides a good balance between physical behavior and conversation. Once you have the information from your searches, you'll have a wealth of rich data to sort through. So how do you recognize patterns or trends in your results? One way that is useful is a technique called affinity diagramming. There are many resources available on this topic, but here is a brief overview. A Quick Guide to Creating Correlation Plots Correlation plots are the technique of taking several different and separate items (such as user statements or researcher observations) and grouping them together to form patterns and trends. Here are the steps for a simple relationship graphing session: 1. Assemble the research team, with your notes.



2. Give each person a packet of Post-it notes and ask them to write a statement on each note, along with a short code that traces that statement back to a participant, such as their initials. Focus on statements that appear to be related to the design of the website, either specifically (a feature statement) or more generally (a statement describing the participant's attitude toward the company or item). 3. Have everyone hang their Post-its on the wall. You need a big blank wall if you are working in a large studio. try to get one that you can access for at least a few days. 4. Once you have completed all the notes, start grouping similar statements next to each other. This part of the exercise can involve the larger group. It's a great way to start sharing results. 5. Once the groups start to form naturally, start labeling them to provide more structure. If some Post-its belong to more than one group, you can write duplicates and place them in any suitable group. Note This method works well for contextual investigation, but it can be applied in many other situations. For example, it's a great way to collectively create categories for unclassified topics to help you move your map's classification results to additional levels of structure.

Patterns can arise in many ways, so it's best to let them form on their own. However, here are examples of the type of categories you might encounter, including the type of statement you'll find in them: Goals: "I'm trying to clear all pending items here before I'm done for the day." Mental models (including explanations that show how users

linking external experiences to internal thinking): "I use this online tool as my briefcase, for things I refer to frequently but don't want to take with me." Top Ideas and Requests: “I wish I could undo this. Delay

accidentally moves the whole folder and takes forever to undo." Frustrations: "I'd ask the help desk, but half the time they don't.

Do you know what is the problem".



Solutions: “This is taking so long here that I finally print

the list and work with it throughout the day. Then I'll get into the results at the end of the day." Value Statements: "This tool here saves me a lot of time, so if you want to

Changes don't take it away from you!"

Diving Deep The main resource for contextual research is Contextual Design, by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also contains detailed information on the interpretation of the results through techniques such as the affinity plot. 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.

Surveys Surveys consist of a series of well-defined questions that are distributed to a wide audience. They often consist of closed questions (such as multiple choice questions) that can be easily collected with a tool that can show patterns among answers. Surveys are good tools when you want to present results in a more quantitative way (for example, "Among respondents, 82 percent of those who work from home have some type of high-speed Internet connection") than when you want to understand the results. types of open questions used in interviews. However, you can also collect quality information about user habits and attitudes. In the field of user experience, surveys are often used to measure user satisfaction (with existing websites or apps) or to create or validate user models such as segmentations or personas.



The Basic Process As with user interviews, you don't want to ask questions that require users to guess. Don't ask "If you had feature X, would you use it?" Unlike interviews, in multiple choice or yes/no surveys, true/false questions are the best and easiest to analyze afterwards. They are also faster for participants to respond. Use surveys when you have questions that are genuine requests for demographic data, such as these: Which of the following devices do you personally own? Select all that apply. Computer Mobile phone Gaming system such as Xbox, Playstation, or Wii

o For multiple choice questions: read the following statements and choose how much you agree or disagree with each statement. Customer service at Pseudo Corporation meets my needs. Strongly agree Agree Neither agree nor disagree Agree Strongly disagree

In particular, questions like the one in the second example are often used in addition to usability testing tasks. You can use this formula as a follow-up question to find out if participants were disappointed when they completed a task. Participants don't always like to express a negative opinion out loud, but they are often willing to express one when faced with a rating system. This brings up another point: surveys are a great addition to other forms of research you may be doing, such as user interviews or contextual research. Combining two research methods provides a more complete picture of the user than either method alone can provide.



Navigation If you want a high degree of confidence in your results and have the budget for it, there are official tools available to measure user satisfaction with ease of use. These tools contain questions that have been tested to ensure that they do not lead or confuse a general audience. Some of the most used are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and Measurement Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory) : http://sumi.ucc ie

When designing a survey, keep the following in mind: Who is it for?

Use your temporal model to determine this. It will make a difference how you answer the rest of the questions here. Which survey distribution method gives you the best results?

If your main user groups tend to congregate in a particular location, you may get more results by going there and creating a table for people to take the survey on paper. If your user groups are active Internet users, conducting an online survey may be the best option for a large number of participants. Or you may decide that your user base is better served by phone surveys using a list of current customers. How much time participants are likely to spend completing the survey

the investigation? If you offer some kind of compensation or if they get some other benefit from completing it, you can usually create a longer questionnaire, one that can take half an hour to complete. Otherwise, keep it short to ensure users complete it; think 5 to 10 minutes. Either way, make sure participants get an estimate of how long it will take, and let them know their progress as they go (use page numbers like "2 of 4," for example, or show percentage complete).



How do you know when to start analyzing the data?

You can choose to run the survey until you reach a certain number of participants or until you reach a certain deadline date, whichever comes first. What tool will you use to collect and analyze the data?

If you are taking the survey online, the tool you are using to collect the data may have options for viewing and analyzing the results. If not, you need a method to import the data into the tool of your choice. For paper surveys, this means a lot of data entry, so be sure to plan for that time.

Focus groups Focus groups bring together different people into a target group and facilitate a conversation with them. Common goals are to get feedback on issues related to the organization or its brand, such as past experiences, related needs, feelings, attitudes, and ideas for improvement. A focus group is a good technique for several purposes: Listen to different user stories. Open discussion is a great way to communicate.

bring out the storyteller in all of us. When a focus group is going well, people build on each other's stories and ideas and recall situations that they might not have in a more structured one-on-one interview. The size and energy of the group can give people the time they need to remember and share these stories. Understand the relative differences in experiences. Most people are natural.

who share ural information and want to compare their favorite tools with others in their interest group. Often, you can learn more about competing websites or services, or hear advice on solutions, resources, and support. Generate 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 team or by listening to their work processes or frustrations. As with stakeholder ideas, be sure to narrow them down to the main need (see Chapter 4) to ensure it is addressed. Understand many aspects of a collaborative process. If you are

By designing a process that involves multiple relevant roles and collaboration, teams can be a great way to fill in gaps in your understanding.



about how people interact with each other. For example, if you are working with a content source such as an intranet, it may be helpful to bring together a mix of content creators, content editors, and content users to identify where the process can be improved. There is a lot of discussion about the use of focus groups in UX research. It is not a good technique for usability testing (since users often work individually rather than in groups), and sometimes the group situation can unduly influence the statements of the participants. However, if well planned and facilitated, focus groups can provide many insights that will be of value to you as you plan. Chapter 13 elaborates on this in the context of proof of concept. The Basic Process When writing focus group questions, remember the same tips you would use for writing user interview questions (discussed above). Start with a few simpler questions, such as "Tell me about your last visit to PseudoCorporation.com." Why did you go there?" Save the brainstorming questions for the middle of the group, when participants are comfortable with you, each other, and the topic. Assign blocks of time to each topic and stick with it. Pass on! If you are concerned about time, place your most important questions in the middle of the topic list after people are enthusiastic about the activity, but before potential time conflicts arise towards the end. these will be the same as for usability testing (Chapter 13 provides tips for selection, recruiting, and scheduling.) The main difference with focus groups is that you need a larger space with a table for participants to interact easily with each other Shoot six to eight people per breakout session lasting 1 to 2 hours each person has a name tag or place card so everyone can address others by name The format of the The discussion itself should include an introduction, often covering the following key points: Your role as moderator and what I hope to gain from the interruption

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



Why the participants were chosen to participate (for example, "All of you

current users of the Pseudo Corporation website and brought it together to learn more about their experience"). How will this information be used, both in the design and by

confidentiality position. That you are there as a moderator to listen to their opinion and

experiences. You want them to feel that they can share fairly, so ask people to be fair but also respectful of others in the group. That there are many topics to cover, so at some point you finish one

discuss a topic to make sure you can cover everything. This can be a round of introductions to team members, often with some sort 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 respond naturally and then call people who haven't responded by name. You often sit around the table for the first few questions and when you feel the group is ready you can use body language to open up the questions to everyone.

Snorkeling: Body Language A good understanding of body language can be a great tool when facilitating focus groups or personal user research. It can help you understand when someone is feeling frustrated, agitated, angry, or threatened so you can determine when to try to reassure someone or investigate a particular comment. The following book on this topic may take more than a weekend to read through, but it is designed to be easy to flip through: The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).

If you're calling someone who hasn't answered yet, repeat the question in case they didn't understand or heard the last one.



some statements in the discussion. Also, make sure that the disagreement does not seem like a disagreement between two people. Don't say, “Bob, we haven't heard from you yet. What do you think of what Chris just said? but rather (looking at Bob): 'What do you say, Bob? What experience do you have with Pseudo Corporation customer service? As the moderator, you determine the flow of the conversation and pass the virtual microphone. Maintain control through eye contact, volume of speech, hand movements, and body orientation. Most people will be very aware of their body language, and these cues can be helpful signals if someone is dominating the conversation. If a very loud participant doesn't understand these tips, use a soft but firm statement like, “Okay, great, I'd like to open this thought up to others. Has anyone else had the same problems as Teresa?" When you move on to a new, larger topic, verbally inform that the previous discussion is over and a new one is starting so people can clear up for the next topic. Finally, when the activity is coming to an end, a simple glance at your watch and a change in your body orientation can indicate that the call should end. As with any activity, thank the team for their time. There are usually two ways to Share results with your team – Findings are shared based on major topics covered or grouped into related categories, like in contextual research.The affinity diagram can be another effective way to collect different trends and behaviors for visualization on the project team.

Card Sorting In a card sorting activity, participants (working individually or in small groups) are given objects printed on cards and asked to put them into groups that make sense to them. They group them into predefined categories (called a closed taxonomy) or create their own groups and name each group themselves (called an open taxonomy). By the end of the card sorting round, you should start to see common patterns in the way people sort items, as well as common points of confusion or disagreement.



A common reason for this is to create a sitemap for a website or create a hierarchy of content, categories, and subcategories that contain items such as articles, documents, videos, or photos. This makes card sorting a great technique if you're working on a content feed. Note See Chapter 2 for more information on content sources.

Let's say you're working on a common type of content source: the corporate intranet. Many intranets tend to categorize their information by the department that owns it, with navigation to human resources, operations, legal, marketing, etc. For long-time employees, this may not be an obvious lie problem, because they probably have learned the responsibilities of each department and know where to find information. But for new employees or those who need information that's not typically reported, it can be difficult to find information that can fit in more than one section (or doesn't seem to fit in any section). For example, where would you find a policy on signing contracts with newly hired employees? It could fall under legal, or it could fall under human resources. Card sorting allows you to find general patterns in how potential users would categorize information, regardless of departmental lines. The Basic Process Gather the items you want to include in your card sorting. 40 to 60 is usually a good range. You need enough to allow for a potentially large number of card games, but not so much that you overwhelm the participants with options (or overwhelm you when you have to analyze the results). Choose items that you think are easy to understand and don't contain unnecessary jargon. You can include some subject terms that you think your user groups are likely to know, but avoid using too many "internal" terms. By including too many company-specific terms or acronyms (such as "the SUCCEED campaign" to increase sales), you test the effectiveness of your company's marketing and communications, rather than creating a common hierarchy of information. For the intranet example, you might see your vacation policy, 401(k) plan information, new lease, vendor agreement, confidentiality agreement,



Orientation for new employees, health insurance information and information security policies. This list represents a clearly worded combination of items that can be categorized in a number of ways. You might have a participant that bundles new hire orientation and vacation policies under Human Resources, and you might have another that bundles new hire orientation and new lease and calls it "employee onboarding." Once you have your list of items, place them on cards that are easy to group and ungroup. You can print labels and stick them on index cards, or print directly on perforated sheets of paper to separate them into individual cards. Test drive by asking someone to sort the cards into groups and name the groups, for example, by placing a Post-it on the platform and writing the name with a pen. Ideally, your test participant will be someone unfamiliar with the objects and activity. This will help you get a general idea of ​​how long the activity may take. If your test drive is longer than an hour, you may need to cut up some cards! Once you have a complete deck, you can bring in a real player and give them these basic instructions: 1. Arrange these cards in groups that make sense to you. 2. Try to have at least two cards in a group. If a card does not appear to belong to any group, you may discard it. 3. You can name a group at any time during sorting. At the end of the activity, name as many groups as possible. Some trends are already evident when observing the sessions. Others may need a bit more analysis to bring it out. There are many tools for entering and analyzing the results of card types. many of them come with tools that allow you to perform card sorting remotely (see the "Card Sorting Variations" section below for more on this). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) offer remote sorting options and useful analysis tools. Or, if you want to do your own ranking in a more manual way, check out Donna Spencer's excellent spreadsheet, fill in



with instructions, available at www.rosenfeldmedia.com/books/cardssorting/blog/card_sort_analysis_spreadsheet. Card Sorting Variations So far, the discussion has focused on card sorting with one person, in person, where the participant is asked to name the categories that they have created. This is an open classification, which means that the main categories are not given to the participant, but can be named. This is a good approach when specifying a new navigation structure or making major changes to an existing structure. For other situations, consider these common card rank variations: Closed ranks. In a closed taxonomy, specify the top-level categories

and the participants add to it. The results are relatively easy to analyze because you have a small number of possible categories, and you can focus on understanding which items fall under which categories most often. Whether you're adding large amounts of content to an existing information architecture or validating an existing sitemap, a closed taxonomy can provide quick and actionable information to help make categorization decisions. group expenses. Instead of classifying individual objects into groups, you can also do

Card sorting can be part of a focus group activity where participants work together to sort items. While the results don't necessarily reflect how someone would group the items, you can gain a lot of insight into how people feel about the items and their organization by listening to them work together on the activity and discussing their reasoning for each location. distant species. Sorting with physical cards can be a fun activity, especially

for group categories. But there are a lot of great tools out there for doing things with people online. This also allows you to reach a larger number of participants or specific participants who can be difficult to meet in person. OptimalSort and WebSort, mentioned above, are two of the tools that allow this type of sorting online.

Usability Testing In usability testing, participants are asked to perform specific tests on a site or app (or a prototype thereof) to identify potential usability issues and gather ideas for fixing them.



You can run usability tests during the Define phase to gather information on how to improve the current site. Or you can run it against similar sites (such as competitor sites) to understand some of the potential opportunities for a more user-friendly solution. Usability testing is typically performed as part of the design phase, ideally in iterative cycles (where a design is created, tested, refined, and retested). We'll discuss usability testing in more detail in Chapter 13, "Testing Design with Users." This chapter provides recruiting and planning tips that can help you carry out the activities discussed earlier in this chapter.

After the Research After you've completed one or more of these user research activities, it's time to review your original assumptions 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 valid, consider any gaps in your user research because no core group was included. If this gap is identified early enough in your research activity, you may have time to adjust and add another set of participants to the ongoing research to ensure you have the full picture. With your new knowledge, you can revise your user definitions to more accurately reflect the groups that should be the focus. This will help you create more granular tools such as personas (discussed in Chapter 7) and creating user requirements for the list we started with in Chapter 5. In this chapter, we discuss the process of getting input from your stakeholders. the company and its refinement of requirements You follow a similar process with users: your work does not stop when you capture the idea or request. Explore the needs and goals to make sure you understand them. Ultimately, this will help you design a solution that best meets that need for all relevant user groups. In the next chapter, you'll learn how to use the knowledge you gain from conducting user research to create tools that can target your user groups during design and development: people.




Find the best way to put your team, or your customer, in the shoes of your users People are often a topic of discussion among user experience professionals. Opinions range from how much content is needed to how much research is needed to whether they add any value to the projects. Some people question whether or not they belong in the process. Wherever you are, personas can be used to help your project team and your client empathize with their users. People can check many parts of your project—business requirements, visual design, or QA—by providing insight into who your audience is, their expectations, and behaviors. russ unger


What are Personas? Personas are documents that describe typical target users. They can be useful to the project team, stakeholders, and customers. With the right research and descriptions, people can paint a very clear picture of who is using the site or app, and possibly even how they are using it. User experience designers often see creating personas as a great exercise in empathy. Well-designed personas are often used as a point of contact when a question or concern arises about how aspects of the project should be designed. You can pull out your characters and ask: How would they do? or what are you looking for? While this process may not be as accurate as design and functionality testing with real users, it can help you move your project forward until you can do more extensive testing. Josh Seiden (www.joshuaseiden.com) points out that there are two different types of personas: marketing-oriented personas that shape purchase motivations interactive characters that model usage behavior

This chapter focuses on interactive personalities.

Why create people? In the user experience design process, personas help you focus on representative users. By providing insight into "real" user behavior, people can help resolve conflicts that arise in design and development decisions, so you and your team can move forward. How real do people have to be? The answer varies widely. A one-person document might be enough for a team, while another might create entire "living spaces" for user personas to deeply understand how they "live." You can even go so far as to create individual web presentations that you can interact with to gain insight into online behavior. However, it is up to you if you choose to expand your personality. People can be a constant reminder to your users. One useful technique is to have your team members keep faces in their workspaces. That's how it is



they constantly remember who their users are. When he shares a cube with "Nicolle", the 34-year-old certified manual therapist from West Chicago, Illinois, for a while, he begins to feel compelled to provide her with an experience that works well for her. If she helps you, feel free to carry printouts with you while you sleep and let the osmosis fairy transfer the empathy from the pages through your pillow into your sleeping subconscious. The purpose of personas is to help you, your team, and/or your clients remove some of the confusion that can arise when you're at a crossroads.

Finding information about personas Effective personas need to provide an accurate picture of some specific users of your product or website. To achieve this goal, people must be backed by research. Chapter 6 presents techniques for researching and modeling your potential users to build a strong foundation for your personas. However, don't look for a method that is the answer. it is best to find as much data as possible and combine it with a mix of observation and interview data. This may also include the use of online surveys and analysis of behavior on social networks. It's a common theme for creating personas: get real data, but change the faces to real people on the pages. See the “Case Study: Messagefirst Personas” sidebar for more information on how one company does this.

Building Personas Once you've identified your audience and collected data to support your personas, your next step is to put pen to paper and bring them to life. The number of people you need to create varies. In general, the minimum is three, but more than seven is not uncommon. Rather than aiming for a specific metric, consider how many target segments you have and what you think is the best way to get a fair representation of them.



Case Study: Messagefirst Personas To create effective data-driven personas, Messagefirst (www.messagefirst.com) uses at least three different data input sources, based on the following: Stakeholders. We interview them to find out what they think the faces are and what they think their behavior is. This is always included. Client's attorney. We interview people in the company who speak directly to customers, typically sales/marketing and customer service. Each of these has its bias, which we will be sure to account for when documenting our findings. For example, the people who contact customer service most often are those with a lot of time on their hands (often retired or unemployed) or someone who is so angry about a product or service that they actually take the trouble. time to contact him. 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 blog traffic, surveys, and emails available to us. Someone we know. We choose someone we know and who fits the initial profile of the person. This helps ground us, makes sure the persona is believable and realistic, and provides a real person to contact if we have any questions. This is very important for validation and is always included. Because every data input source we use has some bias, we use multiple sources to normalize the data. The most important thing about data-driven people is not to go into the expectation of how many people you will have, but to let the data reveal how many people there should be. When I analyze data, I look for gaps in behaviors and activities. These spaces reveal individual persons. Todd Zaki Warfel, President, First Message

The sample person in this chapter is Nicolle, a 34-year-old certified manual therapist from West Chicago, Illinois. It turns out that she is a commuter who doesn't drive and commutes 2-3 hours a day to and from work. The fictional customer is a company called ACMEblue, maker of Bluetooth headsets for Apple's not-so-fictional iPhone.



This short paragraph tells you a lot about Nicolle, but as you can see in Figure 7-1, the real person contains a much deeper story about Nicolle. Please note that the content is written for Nicolle, not "by" Nicolle. It's best to write your characters from the perspective of a third party and not have a problem writing with their different voices, especially if you're just starting out. Of course, as you broaden your experience, you should explore and find the style that best suits you and provides the most value.

Figure 7.1 Persona for fictional ACMEblue customer

What kind of information goes to people? The type of information that your audience finds relevant and credible, that's the type. Based on the research data you've collected, you should be able to determine what's important to the client, the brand, and the project. Most of the personas you create share a common set of required content, mixed with any amount of data, statistics, and other relevant information that can be considered optional as it will vary from client to client, if not project to project.



Minimum Content Requirements When creating personas, you need to provide enough information to draw people in and make them engage with the person they're reading about on the page. To help your audience understand how your persona behaves and thinks, include six key pieces of information: photo, name, age, location, occupation, and bio. The following sections take a closer look at filling in the details for each item. Photo A photo is the first (and true) step to give a face to your personality. When choosing a photo for your persona, make sure the image doesn't look too posed or polished. The photos shown do not have the same effect as those in more natural settings. People seem to be most effective in photographs taken in more natural settings, like the one on the right in Figure 7-2, where the subject is outside in their winter coat, probably on a daily commute. Make sure the photo fits the person's lifestyle! drink everything

Natural Image 7.2 Natural looking photos are more effective.

There are various sources of photos online. Some of the best options are iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com), and Stock.XCHNG (www.sxc.hu).



Finding the right photo can be a total disaster if you're not careful. If all else fails (or you have the time and budget), get yours! Name Simply put, you have to give the person a name. The photo you use will humanize the combination of research data and personality traits, and the name will be how everyone refers to your personality during conversations. Nicolle not only sounds better than "Mid-30s Blonde Career Mom," but she's also much easier to remember and relate to in her personality. Try not to make the names she uses for different personalities on a project seem too similar. For example, Nicolle and Noelle can be easily confused, so look for separate names. And while it may be tempting to use the names of colleagues or clients, don't. When you use names that are similar or the same as the people involved in the project, it's easy for them to try to identify with their personalities. Choosing different names will help you avoid awkward situations or hurt feelings. If you're having trouble choosing names, some online resources can help: Baby Naming Sites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Popular Social Security Administration Baby Names: www.ssa.gov/

OACT/baby name 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. Neither do names that seem more fun or lively, like Bob the Builder. They tend to make your people look silly and can devalue them. Age While your research should determine the age range of your consumers, specifying a specific age for your persona helps add authenticity to the bio you're writing. The attitudes of a 21-year-old student and a 34-year-old professional mother are significantly different!



Location At first glance, location may not seem like essential information. However, it is important to remember that cultural and behavioral changes can occur from one place to another. For example, in Italy different dialects are spoken in different regions of the country. In the United States, a person living in Chicago is likely to have a different cost of living than a person living in Savannah, Georgia. Occupation If you know what your personality does, you can identify with it by relating to its daily life patterns. Someone who works in therapy encounters a lot of people on a daily basis, whereas a drawbridge operator may not interact much with others. Biography Biography is the compelling story that makes a person real. Here you provide details of your research data and elaborate on it with some 'real people'. That is, the data is very important to the person, but you don't want to just list that information in rambling sentences. Instead, you want to combine facts, anecdotes, and observations into a story that your audience can relate to. It may seem a bit strange, but the bio needs to be believable and it's certainly not a scam to bring aspects of a real person into your personality. For example, Nicolle relies on both statistical data and the very real behavior of a person who shares similar activities, beliefs, and desires. Depending on your project, you may need to dig a bit into the bio; sometimes the more detail you have the better. Don't feel like you have to cram your personality onto a single sheet of paper. Stick with what works best to make your personality realistic and as relevant as possible to the project you're working on.

Optional Content As you work with faces, you will find that different projects require different sets of information to make faces more manageable. Minimum content requirements can also be considered the least common.



denominators of most of the faces you will make. In most cases, you combine some of these optional content elements with your main personas. Optional content that can add value to your personas includes education level. Knowing how educated someone is can pay off

more knowledge about some of their habits. Someone with a high school diploma may have significantly different buying habits and brand perceptions than someone with a master's degree, and this information can affect how her personality is perceived. Salary or salary scale. Money talks, and in many cases the quantity

The income someone has has a great influence on their standard of living and disposable income. This information can provide important information when focusing on specific levels of wealth. Personal appointment. What would be the motto that your person would claim

like theirs? Sometimes this can provide a quick overview of your character's core mindset. Online activities. This can be difficult; there are many ways people spend money

your time online. Some people pay their bills, some people are heavily involved in blogging and social media activities, and some people just use their computers as a device that turns on when they have work to do. Since so many projects have an online component, this component is a bit critical. You must rely on your research to paint the picture. Offline activities. Does your personality have hobbies? there is additional

information about what life is like for you when you are not online? This element can be just as difficult as online activities and can be just as important in influencing your personality. Enter a key or trigger point on a client, brand, or project. It is often important

to understand how a person interacts with the client, the brand or the project. Does the person find out about it through word of mouth, online reviews, billboards, TV or radio, or through an online pop-up ad? Does your persona want to solve a problem that can be addressed through the client, the brand or the project? Using your statistics to understand this point and writing it on your persona can help you attract users.



Technical comfort level. Does your person use a PC or Mac? She does

You have a computer? Do you use instant messaging, Flickr or write a blog? Are you very comfortable with this activity or are you confused by it? Would a very simple solution aimed at a beginner help her? Have an MP3 player or other portable device? Do you use a DVR or AppleTV or on-demand programs to watch TV? The list can go on and on. And up. Depending on your client, brand, or project, these concepts, and several others, may be important to define. Social comfort level. Given the growth of social media and social networking

work, it may be important to identify very specifically how your personality interacts with that particular space. Do you have a Twitter account? If yes, how many followers do you have? How active are they? He's a leader? Do you use MySpace, Facebook, LinkedIn, or other aggregators or online communities? Mobile comfort level. As the use of mobile devices becomes more and more

is widespread, it's important to consider how your people are doing in the mobile space, if at all. Incentives for using a client, brand or project. In some cases, you may want

indicate the reasons why the person would want to use the client, the brand or the project. If you constantly get your headphone cord caught in your coat and pulled off your head, that might be a good reason to consider a new pair of headphones. Real-world scenarios based on research data can help uncover key motivations to include in your personas. User goals. You may also want to determine what the person expects

succeed with the help of the client, the brand or the project. This can help provide information about individual drivers to use. These are just data points to get you started. You can structure your characters and present them in endless ways. If you're interested in a deep dive into the world of personas, The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web, by Steve Mulder with Ziv Yaar (New Riders, 2006).



Advanced Personas Once you understand the basics of creating personas, there are endless ways to enhance your documents. A simple person can often meet most of your needs, especially when your project team is just trying to empathize with your users. Usually, things get more interesting when you present faces to your customers. In these cases, you will often find that you need to provide much more than the information you collect about the base person. Figures 7.3 through 7.7 illustrate some ways to expand faces. Feel free to borrow these examples, mix and shred them to create something even better for your project!


Familiarize the consumer with the brand.

PERSONAS AND SETTINGS (based on ethnographic studies) Personas are composite personas based on data about your target audience: in this case, ethnography, existing segmentations, and data from your customer database.

The scenarios are hypothetical but realistic stories that describe why these people might visit the brand's website and what they would do there.

Joan, 32 Consumer insights help us understand users: their motivations, goals, and desires. To apply this information to website design, we develop personas and user scenarios based on real-world conditions. This design approach helps create integrated experiences based on understanding customers, their motivations, desired outcomes, and behaviors. The scripts specifically answer three fundamental questions that must be answered before a website can be properly organized: Your website

Pleasure Seeking Lovers "I Really Like This" "Young Sophistication"





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

"Active Correspondent"

FEEL 5)&365


"Established Scout"


“Grow in a rhythm”

Practical tasks "It just has to work"

Alicia, 26

Rachel, 42

Erik, 47

greeting, 59

Figure 7.3 Person main summary sheet (landscape orientation). It provides an aggregate view of various people, along with the departments they represent, within a high-level organizational strategy. Thanks to Will Evans.




PEOPLE AND SETTINGS (based on ethnographic studies) Alice is a budding chef who aspires to explore the world of food,


especially for eating with children, with friends and looking for new recipes online and in magazines. Your search is about more

she feeds her family without much thought or effort

fantasy instead of reality. She's still afraid and she won't.

Find quick and easy recipes with basic ingredients

try many new recipes. His mother didn't pass on many culinary skills to him, and his friends don't have much experience.

(often) you make two types of meals: for adults, for children

he doesn't cook either. Alice is a busy mother of a daughter in Chicago. Both she and her husband work outside the home: he manages the office of a small insurance company.

Alice, 26 gen x married "wannabe newbie"

1 daughter, 5 tired, ambitious



She's busy, practical, and doesn't spend a lot of time cooking. Alice just wants it to be quick and easy, even though she often has to prepare various meals for her and her husband since he started his exercise program after having Sophie two years ago and is trying to get back into shape. She works with a small set of hit recipes that she is comfortable with, and many of the meals she prepares are based on packaged and prepared foods.

SCENARIO Alice watches Cartoon Network with Sophie over breakfast. A brand ad with a brand name appears here. Alice uses brandy and thinks Sophie prefers this dish. She decides to view the site from work. Alice visits the site for a free half hour before a meeting. The home page is clean and organized. She sees the main sections of the site and links to interesting things like a recipe of the day.

Internet use

health awareness

cost sensitivity

Click on the recipe of the day. She loves the tips that come with it, it makes her feel like she can handle this recipe. She is satisfied with the clear navigation, unlike other sites where she often gets 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 for using produce. Alice discovers that she can receive recipe newsletters and clicks "Subscribe". Signing up is very easy! He fills in some basic information and selects the "Food Your Kids Will" newsletter.

You'd like to add more of your own twist and recreate dishes you like to eat at restaurants, like your all-time favorite chicken. You would also like to add more fresh vegetables to your meals because you know they are healthier. She prides herself on being a detailed planner and capable of managing her household on a shoestring budget. Her refrigerator and pantry are always stocked. She plans her purchases to take advantage of sales and coupons.

Find kid-friendly recipes and food activities Find ways to dress up your favorite foods PROJECTS AND INITIATIVES Improved navigation and information architecture Improved registration

A week later, at noon, Alice finds her first branded ezine: "Pizza, easy as 1, 2, 3." Perfect: her kids love pizza and she usually buys them frozen pizzas. There's a link to "Pizza for Beginners" that inspires her to see if she can make her own pizza. Her link takes her to a pepperoni pizza recipe on something called "Pizza Wizard". She scans the recipe and sees that it is quite simple. only 25 minutes and 4 ingredients. She checks her kitchen to see what she has. She doesn't have pepperoni or pizza sauce, but "Pizza Wizard" suggests replacing them with things she has in her well-stocked kitchen: sausage and ketchup. And ideals! There is a link to a coupon. Neena prints out the shopping list for the recipe, adds a few things she needs too, and heads to the store. Alice returns from the store and begins. She sees the step-by-step instructions for rolling out the dough and adding the ingredients. There are photos at every step. It is easy to understand and follow. She wonders if she should cook the ingredients first, but her pizza FAQ answers that.

regional contextual information more specific newsletters recipe guide better coupon integration MEAL PLANNING Positive attitude relies heavily on prepared meals, with relatively few added fresh fruits and vegetables spends more time looking up recipes than cooking them

Figure 7.4 Target faces (horizontal orientation). This detailed view of a person contains a broader range of data and provides a more complete perspective on user goals, needs and behaviors, all within a larger ecosystem. Thanks to Will Evans.

Figure 7.5 Overview of the objective and character of the target group (vertical orientation). The destination view on the left provides high-level summary information and shows the brands that the three people interact with. The detailed description to the right provides a general description and biography of an individual person, along with information about their behaviors and motivations.



Paul and Helen 'I think we can put our all into it. I'm just not sure how much will fit."

5 4

Helen's mother passed away a few weeks ago and now they are preparing to leave the house. They plan to sell the house, but they need to clean up first. The house also needs some renovation work in the main bathroom.


- by the The basement is full of things that Helen's mother has collected for the last twenty years. She never threw anything. She has newspapers and Time magazines from the last 20 years. There are some things that Helen wants to keep. Most of the clothing, neckwear, and furniture will be donated to Goodwill. Unfortunately, most of her mother's words have been destroyed 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




Know Ex led pe ge rie nce C on Pricve e Senior tunc pe sp Re e M Pue d ult type Time C on eline t Principal Owner L Size ifees D E ecven lu tte t Year Waste Report Rate in Buars dsine Prijs en O Rec soy nlin ycli ne cuenta

This is the first time that Pavlos and Eleni have experienced something like this. They don't even know where to start. They just want this to be as easy as possible. They know they need a trash can, but they're not sure how much it can hold. And they assume that almost anything can go to waste unless someone says otherwise. Your only other concern is that trash cans are often ugly. They hope to find a company that won't make the front yard look like a construction site or destroy the yard when they deliver or pick up the dumpster.

Age: 24-65

lifetime january




1.0 Reality of life

Main features Ŕ Ŕ

One-time event, such as the purchase of a family property or a minor renovation (for example, bathroom). Little to no prior experience purchasing a dumpster.

Objectives Ŕ Ŕ Ŕ Ŕ Ŕ

Quickly get a trash can. Get rid of all the things that don't stay or donate. Avoid property damage in the process. Avoid an ugly litter box. Quickly empty the trash can when it is full.

Points of frustration and pain Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Vragen Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ


Available when needed Price Seller leaves property as found Required container size available Speed ​​of setup and pickup once contacted Online account access for scheduling and payment Equipment quality and cleanliness Reputable brand name

Ŕ ŕ ŕ ŕ

First surprise sticker I don't know the process I don't know what they don't know Apples to apples comparison between vendors

Is there something I can't get in? How fast can you deliver and receive? Will you leave the property in its original state? How does this work? Is a permit required? How much does it cost? How easily can I contact someone if I need to?

Figure 7.6 Faces of the target group. This face presents a target age range, derived from survey data. The information it contains is broad and is directed at audience groups, not specific individuals. This approach can be useful when running a trade promotion or when the client's budget allows for detailed persona scanning. Courtesy of Todd Zaki Warfel.

The Jill of all walks of life

amanda steen


"I have to manage a lot of programs for my clients."



AMANDA SHARES THE RESPONSIBILITIES OF THE INCENTIVE PROGRAM WITH SOME COLLEAGUES. They share access and manage multiple programs for clients. This can be especially difficult to make sure the right people are paid in the right program. You should be able to switch between the different programs and always know where you are.



circle of life

Key Features Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Handles multiple programs Medium to Large Businesses Moderate volume (50-2000+ orders at a time) Multiple people share a 70/30 role On-time payment and administrative checks Weekly to bi-monthly, year-round Highly interested in reporting Wants to work on reports Intensive Excel programs use a custom internal system for the interface

Objectives Ŕ Ŕ Ŕ Ŕ

Integration with the current system. Ability to pay employees quickly and easily. Cost (mainly time). Guided assistance.

Other applications Ŕ Excel Ŕ PowerPoint How can I run reports in all my programs? Ŕ Internet Explorer Is there a way to get my credentials without calling Ecount? Somehow we can integrate with ClientZone so we don't have to switch between different apps as often. I am doing it right?

Ac FT N c ew ou P n C ar t Zo d Re ne q es t E Ad asy s m Pijn C he c R Cu ep ks o rr en rting tB al Pe an ce Cu opl e st om S o f t Sy st em Excell

nc e



Pay employees quickly and easily. Ŕ Avoid duplicate attempts. Ŕ Check their current balance to find out if they need money from the bank. Ŕ Track weekly, bi-monthly, monthly, quarterly and yearly transactions.


in, for example




dg un ow Kn

he knows





He uses Account Zone quite regularly, several days a week. And since he manages many programs, he is quite active throughout the year.

Activities and Interests


Age: 28-55





Account Zone really helps you issue new cards and make sure program participants get paid quickly. The only thing missing is the ability to view all programs, as well as all programs that are running to see how things are going. Their clients like to monitor the performance of the programs. You currently track in Excel. At the end, you send the excel file to your clients or sometimes you export and send a PowerPoint with some nice graphics. If Account Zone had a way to run reports on individual programs, as well as across multiple programs, that would be really cool.


Ŕ ŕ ŕ ŕ ŕ






Frustrations and pain points

Ask -


You cannot watch multiple programs at the same time. Reports cannot be run in multiple programs at the same time. The debugging of the download "sucks". It is not clear what the exact problem is and how to solve it. Multiple steps with multiple applications are inefficient and make it easy to "get lost" where you are. Multiple confirmation screens. Another username and password to remember. Find the email with your credentials.

Figure 7.7 Target people. This face is a strongly data-driven model. While the daily story is a story, the rest are bullet points that serve as a planning checklist. The diagram is used to communicate a significant amount of information in a small space. Courtesy of Todd Zaki Warfel.



As you can see, you can combine data in many different ways to present faces and adapt them to different situations. Start with the basic personality and expand it to fit your needs.

Final Thoughts on Personas Many professionals in the world of user experience design do not believe that personas accurately articulate the needs, goals, and attitudes of users. They believe that people can hinder creativity, innovation, or good design for many reasons. Other practitioners believe that people fulfilling a specific need influences the design process in a very positive way, when based on solid research data and mixed with a dose of personalized reality. Which side of the coin you end up on is completely up to you. This chapter is not intended to influence your decision in any way. There are many articles available online on this topic and many professionals are ready to give you their opinion. All of these resources can help you figure out how people work best for your projects, so look them up. Jared Spool, CEO and founder of User Interface Engineering (www.uie.com), also offers insight into the theme: this value is created when the team visits and observes their audience, absorbs and discusses the observations, and reduces chaos to patterns. , which then become faces. What's on the team's mind as they design will make all the difference in the final design. The face descriptions are there to remind everyone of what happened.

Jared's point is simple: By tracking your audience, combining what you learn with research data, and putting it all together into segments, you should be able to create personas who generate the kind of empathy that will keep your team on track. building the best app, website or product possible. But in the end, your characters will be a lot like Santa: they're only valuable as long as people believe in them.




User Experience Design and Search Engine Optimization The Critical Role of User Experience Design in Successful SEO Search engines are the cornerstone of the interactive economy. Everything we do as "interactives" is ultimately connected to the world at large through Google, Yahoo, MSN, Ask, and the myriad of sub-engines that make up the infrastructure for finding things online. Information architecture is a crucial part of how search engines interpret websites. This chapter is intended to give you a basic understanding of why UX design is critical to search engine optimization and what you need to consider so that the environments you create stand a chance with Google. jonathan aston


Introduction to SEO Simply put, search engine optimization is the process of developing and maintaining a web component with the goal of obtaining and maintaining the top rankings on public search engines for specific key phrases. Search Engine Optimization (SEO) is like a martial art, a process of learning and doing that never ends. Even a teacher can continue the observed behavior or teaching method. As long as there are search engines and websites interested in selling something to search engines, search engine optimization will play a role. SEO is based on three fundamental areas of improvement and influence: The critical group of things that the professional user experience designer has.

may affect: the infrastructure of the site, the technology and the organizational principles The content and all the keyword problems related to the optimized words that

search engines can see links or link popularity – the quantity and quality of links pointing to you

site of other sites, as well as the organizational structure of the links within the site. We break down each of these three areas and look at them from the perspective of a UX designer, to better equip you for the optimization challenges ahead.

Why is SEO important? It is interesting that even today we have to explain the importance of search engine optimization. Clients tend to understand at some level that it's important for their websites to attract specific visitors from the physical search results of major search engines, but beyond that, it's hard for most interactive marketers to understand the impact it can have. Global search volume data is available from a variety of sources, but the important thing to understand is that regardless of the source, the numbers are simply huge and year-over-year increases are always in double digits. For the most part, global search volume increases every quarter. When Google first launched in 1998, 10,000 searches per day was a huge number and put incredible pressure on the beta version of the system.



Hitwise (www.hitwise.com) reports that Google and its affiliates (including AOL and YouTube) control the most searches worldwide, with nearly 72 percent of US searches conducted in November 2008. Yahoo is a distant second, with nearly 18 percent. , and MSN and Ask.com posted 4 percent and 3 percent, respectively. Internationally, Google is even more dominant: its market share reaches more than 80 percent in many markets. Note For more information on the early days of Google, see The Google Story, by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), in 2008 there were easily more than 60 billion searches per month worldwide by 750 million people, with more than 18 billion searches 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 these remarkable volume numbers, what does this mean on a practical level for interactive marketers? Simply put, if you don't reach your target customers when they are searching for your products or services, your competition has an opportunity to sell to them. Look at your website analytics and think of it this way: how much more revenue would the website generate if strategically targeted traffic increased by 10 percent? How about a 100 percent increase? Or 1000 percent? If your website does not generate significant traffic from natural searches, then SEO is a must. A small investment in SEO can pay off, especially if your interactive marketing efforts have so far focused on buying clicks through sponsored listings. We have seen websites achieve a 35 to 1 ROI on their monthly SEO investment. If you pay search engine companies for sponsored listing traffic, but don't invest in organic traffic, you're really limited to about 10 percent of the chances. Think about your own search behavior: when was the last time you clicked on more than one or two paid sponsored listings in a search result? Any discussion of why SEO is important and why it is here to stay could go on for several chapters. Suffice to say that Google isn't going anywhere else and effective interactive marketing must include search engine optimization as a key part of competent execution.



Key Core Resources Experience comes from extensive training. The professional who only focuses on his specialty loses sight of everything that surrounds him. Therefore, it is imperative that every blogger spends at least a few minutes learning about SEO. While there are no official guidelines, Google has been kind enough to provide some very important resources. If you'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 Help for Webmasters/Site Owners: Webmaster Guidelines: Quality Guidelines:

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

www.google.com/webmasters/docs/ search-engine-optimization-starter-guide.pdf If that's not enough, dive into newsletters and blogs. Start at SEOmoz.org and dig deeper. Just remember, as with everything else in life, if it sounds too good to be true, it probably is.

Site technology, design and infrastructure Search engines are essentially Web 1.0.5 technology firmly embedded in the Web 2.0+ world. The search engine premise has changed little since World Wide Web Wanderer was launched in 1993 to search the web and create the first web search engine. Just about every search engine has an application known as a crawler, spider, or bot that finds and follows links and returns a copy to the database of what it can see. The database is then analyzed according to the search engine's own algorithm. Using these rules, a web part is indexed and then ranked based on its ranking in that specific search engine's scorecard. In this rather simple process, there are many pitfalls for the UX designer.



Understanding these important relationships will help you see your website through the eyes of search engines. An optimized website is based on a structure and technology that makes it easy for search engine spiders to move. Similarly, many content management decisions determine how well search engines judge the resulting efforts. As a result, much of it is predetermined by the decisions that are made in the wireframes and the discussions that take place about how the content is structured and managed.

Flash, Ajax, JavaScript and other scripted content Today's dynamic and interactive web design is based on technologies that are far from being search engine friendly. There is a growing gap between what search engines can see and what designers can do. It is up to the UX designer to ensure that strategic plans for design-intensive and dynamic websites are developed so that both search engines and users have the best possible experience. Having a fundamental understanding of how search engines interact with this type of content will help you decide when to develop it and where to compensate for its weaknesses. It is quite possible to create an optimized website that relies heavily on scripted content if the right trade-offs are made from the start. It is much more difficult to create static or indexable content once the site is up and running. So make a strong case for static content, based on ease of use and interest to search engine crawlers. It may seem like extra work at first, but the return on investment is exponential. Flash Flash content is technically "indexable." There have been some recent advances in the ability of search engines to look at Flash files to find the text and links embedded in those elements. Although this content is indexed, have you ever seen a Flash element reach the top of search results? Probably not, because it's dangerous for search engines to open up to full Flash support. Let's assume that search engines can fully see all the links and textual content embedded in the SWF object. What prevents an unethical optimizer (or "black hat") from placing apples on the object's text layers during rendering



oranges for the human user viewing fully compiled components through a browser? How can you deep link to a Flash component without it being fully compiled? These fundamental vulnerabilities will persist until search engines can reach a certain level of artificial intelligence that can tell an image is an image of a horse without any accompanying text that says "this is an image of a horse." To create a Flash website that is search engine friendly, you must add a static content layer that duplicates the Flash content. Aside from search engine needs for now, a static content layer is key to meeting usage requirements. Think of the search engine as the person viewing web content through a dial-up connection or using a screen reader browser. These people may be the lowest common denominator and your web development strategy may be ignoring this very small percentage of human users. But if you ignore those handful of people, you're also not doing justice to the GoogleBot and Yahoo Slurp, the top two visitors to your site, since they're the crawlers the major search engines use to index your site. If there are no text words or spider links visible to search engines, your content will inevitably not be found via meaningful search results. A static layer can be achieved in a number of ways. To meet search engine requirements, the static content layer must reflect the Flash content. It's not an opportunity to show search engines anything other than what's being developed in Flash. Doing so breaks the spirit of the game and explicitly turns to the dark side. The ideal way to enclose Flash content in a static layer is to use SWFobject so that both Flash and static content can be on the same URL. This allows the search engine to find the static content and allows the Flash-enabled browser to display the animation instead of the static content. If possible, do not use the redirect so that you can maintain the popularity of the link leading to the Flash content. Google Code provides a simple set of instructions for implementing this simple piece of JavaScript at http://code.google.com/p/swfobject. There is another option that works on the gray side of SEO. Cloaking might be a dirty word for SEO purists, but if you approach the challenges below from the right angle, you can have your cake and eat it.



Cloaking uses user agent detection, detects search engine crawlers when they visit a website, and directs them to static pages for indexing. But when a human visitor sees the same page in the search results and clicks the link, the website detects that the user agent is a human with a Flash browser and presents that person with the dynamic experience in a fully fledged URL. separated. 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 masked content as you do in your Flash content. Ajax, JavaScript and other scripted content Ajax is a powerful controller for web 2.0 content and allows web developers to create content without a page. However, the problems search engines have with Ajax are numerous and require good planning to avoid major mistakes. Ajax stands for Asynchronous JavaScript And XML, indicating the difficulties search engines have with this technology. In principle, search engines cannot handle JavaScript. the efficiencies JavaScript provides for developers are the problems search engines have with dynamic content. An additional problem search engines have with Ajax is the asynchronous nature of the technology. A search engine can only see the content on the first load of the page, and any content loaded via script that occurs after the shell loads for the first time is not visible for indexing. Because Google can't extend a session after the first page loads and doesn't have a mouse or external agent to trigger a script, all user-activated content outside of the page is invisible unless the user clicks on it. text content is contained in a preloaded shell. It is up to the UX designer to ensure that the 3D modeling required to structure the pageless design includes the requirement to pre-load text and links on the page shell. Everything else, and your beautiful design is invisible. Scripted Navigation One of the most common problems that gets in the way of optimization is the use of JavaScript in the core of site navigation. This is a common situation and is a result of the way many website development and content management tools work. Scripted browsing looks better, so people are often interested in using it. But if JavaScript is the technology that drives site navigation, the result is that search engines can't correctly model the link.



relationships within the site: they simply cannot see the link structure of the site. And if the search engines can't model the link relationships on the site, the deep content will be invisible or won't get adequate link popularity.

Content Management Systems Content management systems are designed to make people's lives easier, but many of these systems make it difficult for search engines to interact with their results. Here are some of the typical problems you can avoid by using workarounds or by choosing a more searchable content management system: dynamic URLs. Search engines do not understand a "page" of content. he

understands the path to that content. A change in the path or URL pointing to this content causes search engines to accidentally clone the content multiple times. This situation significantly reduces the ability of a site to perform well. If your content management system has one that generates session IDs in URLs, you could be in real trouble. Follow up with adult analysis, not session ID. Multiple URL paths. A typical problem in e-commerce content management

Age is that as a product progresses through its life cycle, it accumulates multiple URLs. Again, since the search engine can only understand a page of content based on the URL where it finds the content, when a product appears in a category and is part of a gift basket and is (and still is) a weekly special ). followed a bunch of different links to find the same content. Do your best to ensure that each piece of content exists in a single URL, and that multipathing is actually based on one URL, regardless of where the links grow. Rely on mature analytics systems for channel analysis. accidental cloning. If you understand that part of

Content must only be accessible via a unique URL path. It's easy to see other conditions in content management systems that cause content to be cloned inadvertently. Suffice to say that the architecture should have only one URL path to a single piece of content. infinite loops. A corollary to the accidental cloning issue is information

finite loop. Make sure you don't install search engine spiders



a potentially endless task of following the "next" links in a calendar or similar situation. If the search spider can cross a next link on 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 these types of situations by using a reserved link that search engines can't follow, so that crawlers can spend their time on the content you want to index. Old URL structures. The first thing that many site redevelopment projects-

What we do is replace the old URL structure. The problem is that search engines have probably already indexed the content of those old URLs, and once you change them all, you're basically sending your indexing back to the first one. Also, all the deep links that the site has accumulated over time refer to the old URL structure. Whatever the cost, keep as many old URLs as possible. It is likely that when you replace your content management system you will need to change all URLs, so if that is unavoidable, we recommend that you give old URLs a status code of "301 Permanently Moved" and redirect them to a -one based on the old URLs to the new URLs. A 301 redirect is the only redirect acceptable to search engines.

Domains, Directory, and URL Structure Matter If you're starting from scratch and brand limitations allow, try choosing a domain that contains one or two keywords. It's hard to get a .com domain with quality keywords these days, but if you do, separate those keywords with hyphens. An important part of how UX affects SEO is the directory structure of a site. It has a crucial impact on how link popularity is distributed on the site. Simple is better. Avoid external files in your folder structure at all costs. Some content management systems automatically insert a subdirectory. avoid this if possible. This condition reduces the relevance of the entire site. Search engines understand the site hierarchy based on how sitemaps are structured, so make sure the most important directories are at the top of the architecture. If your environment allows it, use keywords in the URL structure that are related to the part of the site. Separate keywords with a hyphen and



don't use too many keywords in a file name. Look for something like this: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also, be sure to set up redirects for http://site-in-question. com to 301 Redirect permanently moved to http://www.site-in-question.com. If a site with and without a www is resolved, search engines (particularly Yahoo) will index the content at both URLs, allowing random copying of the entire site. This condition tends to spread when a third party connects to the site without www and the site contains a dynamic link structure.

Content: The Old (and Present) and Future King While content production is someone else's business, the foundation laid in website 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 link to items more or less related to those words. Picking the right phrases is all about whether your site is relevant in the right context. In a perfect world, your SEO partner will give you a set of keyword phrases before you start and work with you through the process of creating schematics. If there isn't a competent partner involved in your process, read the Google AdWords Keyword Search Tool (https://adwords.google.com/select/KeywordToolExternal) and do some research on people's actual search behavior. exploring your category. Then spend some time with this introduction to understand the phrases potential customers are searching for and use those phrases throughout your site. Search engines look for keywords at various points during the analysis of 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 to enable future success.



So why is content king? It is the core of what a website should offer. Search engines need textual content that they can see and index. Website visitors need compelling content that deserves their attention. Bloggers and webmasters need content that is reliable to link to. Without the right content in the right places, search engines can't direct the right visitors to your site.

Naming Conventions and Fighting Jargon It is important that keyword objectives are reflected in the taxonomy developed for a website. Using keywords in the main structure of the site makes the entire site more relevant to the things you sell. If you sell widgets, don't call your online product listing a catalog, call it a widget catalog. Similarly, use your keyword research to make anti-jargon decisions. For example, use the words laptops instead of laptops in your structure because people search for laptops 10,000% more often than laptops.

Metadata, Headings, and Keywords It's quite remarkable that we've gotten this far into the chapter before getting into the basics of metadata. There are many meta tags available, but only a few are truly influential, as all the others are susceptible to spam. The relevant tags are: Page Title. Please note that this is not the label, but it is the

actual page header tag. This tag contains the actual title of the page and consists of the most important 65 characters of the page. Think of the title like the little tab stuck to your old-fashioned library card catalog that says "Clements, Samuel" and indicates that all the cards behind that tab are Mark Twain books. Every web page should have a unique page title. Do not put keywords in the title and preload the title with the most important words. Meta keywords. This tag has essentially no effect on the query.

engines because it is very vulnerable to spam. The exceptions seem to be that the Google AdSense consortium analyzes the meta keyword tag and Yahoo is heavily affected by it. meta keywords



it should match the content of the page, and this tag is actually a good place to introduce possible misspellings. It must be different for each page. Meta description. As with your page title and meta keywords, make sure

that the meta description is unique for each page. This description is just that: a summary of what's on that page. Say it, don't sell it, in about 150 to 160 characters. This content is critical because search engines are likely to display it below the link to your page. If the page does not contain a meta description, the search engine looks for a piece of text or other content that contains the searched keywords and displays it in the results. The meta description is more about usability than SEO, so make sure each page is tagged correctly. "Noindex" meta tag. If you have pages you don't want to include

in search engine results, use the noindex meta tag. Make sure the pages you want to index don't accidentally contain this tag. Headers. Search engines recognize headers etc.

as influential factors, as long as you don't send them as spam. Be sure to allow section headers that are descriptive and contain the relevant keywords for that page. Anchor text link. Link anchor text is an important factor influencing what

Search engines think of the page on the other side of the link. This is the factor that creates the "GoogleBomb". If multiple links point to a page with the same anchor text, Google interprets the destination as relevant to the phrase in the anchor text. For example, if you search for "click here" on Google, Adobe's website appears in the first results. There are hundreds of thousands of links pointing to Adobe that say "click here to download Adobe Reader" or something similar. Take advantage of this. The anchor text cannot be "More" or "Click here". Instead, it should contain keywords that are relevant to the landing page.

Split Hairs It is to your advantage to have separate indexed pages for both left and right handed wavy widgets. This level of granularity gives your pages a better chance of exactly matching legendary long search queries. A page about one thing has a



you're more likely to win for that one thing than a page about many things (all other factors being equal, of course). And who cares to read a page of hundreds of words?

Using Sitemaps In recent years, it has become popular to skip the classic sitemap page. This is a usability bug and an SEO bug. Find your way to the fact that every website needs a sitemap. It may not be great, but it is necessary. Also include the sitemap files in /sitemap.xml and /sitemap.txt. While this structure doesn't help the site rank higher, it does help search engines understand the directory structure and find new and updated content.

Keeping Your Content Fresh An important element of getting and maintaining a top position in search results is to constantly update the content on your website. This does not mean that you should always edit all the content on the site. it means that the site has to grow constantly. Structure the directory so that adding content is easy and intuitive, and anticipate that the site will grow over time.

Other Content Issues A big challenge when it comes to the UX of a content-rich website is preventing content from being cloned or copied. Be sure to duplicate pages with seemingly innocuous conveniences, such as "printable" content that is an exact copy of a page in a PDF or similar document type. Protect these types of pages with linked links or use the rel=”nofollow” link attribute. Don't rule out optimizing for the wide range of digital assets that search engines can index. This topic would be almost another chapter in itself, but suffice it to say that PDFs, videos, images, and other non-web content are clearly part of natural search results. The structure of the wrappers around these elements is critical because search engines need indexes for this type of content. For example, search engines cannot tell that an asset is a horse racing video unless there is a link to the video with an anchor text that says "horse racing video" next to the text about horse racing videos. in the code page.



Using alt attributes is another way to identify non-text elements in search engines and is always a good idea for usability reasons. Don't create dead-end content pages. Make sure even the bottom of the structure links to the main site so that search engine spiders don't get trapped. Breadcrumb links are an easy way to accomplish this if a page type does not include the main site navigation.

Link Popularity Explained If there's one holy grail for SEO, it's link popularity. It's the cornerstone of why Google so outperformed other search engines when it hit the market. Link popularity is a measure of the quality and quantity of links pointing to a web component from other websites. Google uses the term PageRank and it is the über factor that can overcome many other shortcomings. Links are essentially votes for a web component, and it is commonly believed that something of interest or value to others has links pointing to it from other trusted web components. Over time, this concept has proven invaluable in defeating spam efforts and is at the core of the founding principle of high-quality search results. This principle is critical for the UX designer to understand because of how link popularity is distributed in the structure of a website.

Typical Link Popularity Distribution Similar to the Richter scale used to measure the strength of seismic activity, Google's PageRank system (named after Larry Page himself) is a logarithmic scale from 0 to 10. This means (in general terms ) that if one page has a PR of 4 and another has a PR of 5, the page with PR of 5 has 10 times the link popularity of the page with 4. This is important to understand because PageRank is distributed through a website based on link hierarchy and directory structure. In general, if your home page has a PageRank of 5, your main section pages should have PR 4, child pages PR 3, tertiary pages PR 2, etc.



Pages with the most internal links typically have the highest link popularity. The most important pages to win should have the most internal links pointing to them. This includes links in the main site navigation, sitemap, footer, and embed links that are embedded in the text. Since link popularity is critical to ranking well in search results, you should be as conscious as possible to attract as many people as possible to the pages that contain the "buy offer." Each page has a finite amount of link popularity that can contribute to the other pages on the site. A page with a link pointing to another page sends 100 percent of the available value to the recipient. A page with a hundred links to another hundred pages sends 1 percent of its value to each of those hundred pages. The home page typically has the highest link popularity because a website's home page has the most links pointing to it from third-party websites. This means that the home page has the most value in contributing to other pages on the site. If there is a critical page that is part of the "selling proposition", place a direct link from the home page so that search engines understand the importance of that particular page compared to the rest of the site. If possible, create a function that can rotate links to deep content from the home page.

Footer Links When looking for ways to customize and control the spread of link popularity throughout your site, keep in mind that text links in the footer of each page are both a blessing and a curse and will some effect on spreading link popularity throughout the site. the place. place. The default footer links point to the privacy policy and other non-transactional pages, so if these links should be in the footer, hide them behind some kind of script, or better yet, "nofollow" those links. with rel="nofollow" link attribute This prevents the link popularity of each page from leaking to pages that don't really need to be in the search results. It is also better to avoid link popularity migration than to completely block pages that use robots.txt.



Links within the content Search engines use links embedded in the text. Just don't overdo it. Some schools of thought claim that search engines no longer give favorable weighting after the first few links in a block of text. Place your most important links at the beginning of the text and use link anchor text that contains keywords relevant to the landing page.

Gaming the system Who says search engine optimization is all work and no fun? Search engines can contribute real dollars to website owners, and in some settings, there is a real no-holds-barred approach to getting top rankings at any cost. Not a few search engine optimizers have taken advantage of their clients by charging big money for bogus techniques that may have positive results in the short term, but have disastrous impact over time. Over the years, webmasters have used various optimization techniques in search of the best results. One of the most important advances in search engine technology has been the work to find clever ways to cheat the system. From a search engine perspective, the interests of your users are served by having clean, highly relevant results at the top of every query. From the point of view of many SEOs, all is fair in love and SEO.

White Hat vs. Black Hat It's easy and fun to label SEO methods "white hat" or "black hat," but it's much harder to say which is which. Many white hat optimizers are purists and say in strong, declarative terms that certain management techniques, content and link manipulation, and other approaches are simply off limits. The black hats treat the issue as a contest that has nothing to do with cheating: how can something cheat if there is no specific written rule or court? His approach is more akin to a game of cat and mouse where the cat holds all the cards and the mouse can hold out to win a lot of money: take a chance, win, and the rewards are great. But once the search engines reach you (and almost



always do) be prepared for your site to crash or at least not be able to run when the methods are called.

Spamming meta keywords Many of the "cheating" techniques are based on UX principles. One of the first methods of cheating the system was meta keyword stuffing: basically stuffing the meta keyword tag with hundreds of instances of apples when the site's content is all about oranges. In its most basic form, the meta keyword approach was created to aid in early web rankings. Due to all the keyword spam, this part of a website has virtually no effect on search rankings these days. Search engines easily saw this technique and were able to quickly edit it. The next generation of spam was a bit more difficult to untangle and also stemmed from UX issues.

Cloning and Door Pages Both cloning and door pages are methods used to make a website appear larger or different to search engines. By cloning a page over and over again, webmasters can essentially produce targeted content that you can quickly master for a specific search term. Due to this practice, it is important to ensure that your architecture prevents accidental cloning, as search engines are sensitive to duplication, whether intentional or not. Door pages are another method of influencing search results that straddles the gray space between the white hat and black hat methods. For one, Google's quality guidelines for webmasters say that "login pages violate our webmaster guidelines" (www.google.com/support/webmasters/bin/answer.py?answer=66355). The guidelines define landing pages as poor quality pages that are specifically optimized for a set of keywords that may not be relevant to the actual website or may be spam. On the other hand, how do you help search engines access content that is trapped in a database that cannot be spied on or hidden by technology that search engines don't like? In its positive definition, a landing page is high-quality static content that search engines can see and understand, while the visitor accesses the dynamic content. The current content management systems improve in the most important points that



This approach is required, but it can be very useful to create additional pages for the express purpose of showing search engines a static representation of content that they would not otherwise be able to process.

Link Spamming Recent methods of gaming the system have focused on manipulating link popularity, a central idea of ​​how modern web search engines work. As discussed above, search engines determine the relevance of a particular web element by analyzing the quantity and quality of links from other parties to that page. Search engine optimizers have worked to manipulate this part of the puzzle through sneaky redirects, excessive use of subdomains, making every page on a site "/index.html" and a variety of other subtle mechanisms.

Some Final Thoughts It's doubtful that this is your first exploration of search engine optimization issues. It is now clear to what extent a website's architecture and related issues affect search engine performance. The current search environment is a big step up from simple classification or structure. Careful search engine optimization starts with high-quality UX. A website's architecture is the critical point in its life cycle where it can be destined for search engine success or primed for imminent failure. Search engine optimization is a strategy that never really ends, but quality SEO will never really start without the careful attention of a UX designer. Jonathan Ashton is Vice President of SEO and Web Analytics at Agency.com and leads the SEO Center of Excellence. His team provides SEO services throughout the company and ensures that the process of designing and creating rich interactive experiences results in websites that can be found in search engines. His monthly column, "Industrial Strength SEO," can be found at http://searchengineland.com/lands/columns/industrial-strength.php.




Go: From Time to Planning to Visualize, Prioritize, and Plan Now you have a good list of business and user requirements. And you have information from your users to focus your conversations. And now? Unless you're in the Shangri-la of projects, you have a (tight) budget, (specific) schedule, or both that tell you that you need to focus and somehow manage this list. This chapter describes some ways you can move from definition to design, including tactics to help your team envision the solution to be designed, prioritize features to create a single set of requirements, and design planning activities to include. in the next phase. of the project. carolina chandler



Chapter 4 discussed different project approaches or methodologies and how they affect the way you collaborate with the project team and business stakeholders. Compare a waterfall approach, which has definition and design stages separated by an approval step, with a custom waterfall approach, which has some overlapping stages. This chapter discusses the activities that can take place in the overlap between the Define and Design phases.

Define the development of the design.

This point in the process is a good time to brainstorm and visualize features that did not occur to the stakeholder during

interviews or user research. Working with the project team before prioritizing allows you to consider and design innovative features that meet both business and user needs. Prioritize project requirements. This includes downloading the built-in list

business requirements, user requirements, and project team ideas and determine their relative importance to achieving the project objectives. At this point, you'll work with the development team to understand the general level of effort required to meet each requirement. Plan the activities and documentation that you will use during planning. This

The schedule determines how you will collaborate with other team members and what types of tools or documents they will receive from you, such as site maps and schematics (discussed in Chapters 10 and 11). This chapter covers each of these three areas, beginning with an ideation and visualization method that a UX designer can easily use in collaboration with project team members.



A common scenario The requirements are defined and approved and you are designing the site features in the project. In the middle of the design process you realize that providing a specific tool will be very useful for your users. It's an interesting idea, but there are no requirements describing this new tool, so its inclusion requires a change in priority requirements. You should be a strong advocate for changing the list of requirements, especially if it means removing something else from the list (it will take time to decide which one), or if the project schedule might change. There is a possibility that the idea was not included simply because it came into play too late. While new ideas can emerge at any point in the project, taking time to brainstorm after requirements gathering is complete, but before priorities are set, helps to generate those ideas sooner and increases the likelihood that they will be included. It also ensures that you take a moment to consider innovative features that your business stakeholders or users may not have thought of.

Inventing and Visualizing Features UX designers have a unique set of skills that help bridge the mental gap between words (like requirements) and images (like sitemaps and wireframes). As much as people talk about requirements and discuss language, they often don't get along until they see the concept envisioned. On the other hand, if you jump into specific visual details too quickly, you risk turning the conversation to smaller details (such as whether an option on a form should be a radio button or a drop-down list) before resolving the big questions. (as if your users were supposed to fill out that form in the first place). There are many conceptual design techniques you can use throughout the process to visualize context, flow, and story in a way that will appeal to others before detailed design begins in earnest. Also these techniques



emphasize the need for features that can be added to your requirements document prior to prioritization. One such technique is collaborative scenario creation – visualizations of specific user scenarios that are sketched out on paper or on a whiteboard during a brainstorming session. The UX designer then works from these sketches to add details.

The Basic Storyboarding Process Prepare for your storyboarding session by making a list of scenarios to explore. To create the scenario, consider the following questions and bring the answers back to the session: Who is the main user in this scenario? What role does it play? This is

where your user model or personas will be useful. If you have them, bring them to the meeting; both will drive discussion and ensure that your project team has a better understanding of how to use user modeling tools during the design phase. Is the featured user a new user to the site? If not, it's sporadic.

user or use it often? This will affect the level of functions that are analyzed. a new user may feel overwhelmed by the number of options that a frequent user may like. You may want to go through the script twice to discover the different features that each group may need, such as in-box help for new users or customization features for frequent users. What immediate need brought this user to the site? What is she trying to do?

succeed and why? You can think about this by looking at high-level tasks covered by your company or user requirements, such as "find product recommendations." Perhaps the user wants to find product recommendations because they need a pair of snow boots and want to make sure they don't leak or get their feet wet. Gather your team to brainstorm for the session. This group can be just you and one other person, or it can be a small group of three or four other people. (More is possible, but it can be difficult to get everyone around a table effectively and keep them focused on the task at hand.)



Ideally, at least one person on the team is responsible for representing the user's point of view. Another must represent the business point of view (for example, a business stakeholder or business analyst if that role is represented on the project). That doesn't mean you can't change your perspective. you can and should take user and business needs into account as much as possible during the discussion. For more information on how to balance the needs of users and the needs of the business, see "Maintaining good volume." Once you've assembled your team, tell them the goals of the activity: to understand some of the capabilities that may be needed to meet business and user needs, and to focus future design efforts. Present the answers to the questions above and the list of scenarios to discuss. Then go to the whiteboard (or put your pen to paper) and ask the team questions about the scenario, such as How is this user likely to get to the site? View web searches, banner

advertising, word of mouth and other means. If online searches come to mind, please state precisely the requirements

What types of features or activities (such as tagging for SEO needs) to support this search? Once on the site, what does the user see that is relevant to their needs? What path does the user take to complete the task? draw this with

high level details. Are there other people involved in the project? If so, how can they participate?

(phone, email, co-location capabilities) and how might they influence the decisions or behavior of the primary user? Where is a user likely to need help? How will she get it? What happens when the user completes their task? A common design flaw

it will be over when the user is done, but this is a good time to encourage the user to explore other areas of the site or purchase related products. Take an example of a common business scenario: the need to post a new job posting on the company's .com website. For this scenario, assume that you interviewed stakeholders and found that the hiring process is primarily done by a person named Jeff in Human Resources who works with those who need to be hired. 148


Jeff is quite familiar with current job descriptions. If he needs a new one, he usually finds out when the potential manager for the new position asks him to post a job. Then it's a collaborative process between Jeff and the manager (let's call her Emily) to write and post the job description. Figure 9-1 shows what the script might look like for this scenario. The image shows only a part of the scenery that you can create here. You may want to start earlier in the script to show the approval process Emily had to go through, or you may want to continue the script to show how a job seeker searches and applies for work. The important thing to note here is that a script like this allows you and your project team to think of the workflow as more than just a series of pages. It brings the human element and context. And without the human element of person (Jeff), your team might not have thought to include the ability to retrieve an existing job description at first, but we did all of this to save time and make sure we included everything we needed.

Figure 9.1 A storyboard, first created on a whiteboard, then drawn and detailed in Microsoft Visio using a Wacom tablet



One thing to keep in mind when using storyboards and other types of sketches (such as user flows and draft lines) is that they are primarily intended as brainstorming tools. While some great ideas come from the exercise, these sketches are not meant to be detailed drawings. This fact may be obvious from your sketch format (as opposed to the prototype format), but it is still an important point for business stakeholders, as seeing features, even in a sketch, can sometimes raise expectations of that they will be present. be in the final product. Another danger here is that participants get involved in discussions about UI elements, like whether something should be on the page or in a popup window. It's very easy to get into these detailed discussions because these types of problems are often easier (or more familiar) to solve than the larger problems that scripts are meant to address. To keep things simple and use time efficiently, ask participants to save these types of discussions for places you plan for based on your prioritized list of requirements. And that brings us to the next step in the process: the often lively, sometimes tedious process of prioritizing those beautiful requirements you've spent so much time on.

Make the prioritization process easy You've integrated all your business requirements with features based on user requirements and insights. Now comes one of the hardest parts: narrowing it all down to a prioritized list of high-level requirements. As you work through the requirements that need to be prioritized, you have the project goals and your user model to help you focus the discussion on your audiences. In addition to you, in your role as user advocate, the prioritization process should also include: Someone who represents the point of view of the company (the company

proponent). Someone who represents the point of view of the development team (the

development attorney).



Someone who represents the needs of the project (such as the project

director). This person may not be required to attend prioritization meetings, but will set any constraints that affect prioritization (such as timelines or budget) and ensure the final list adheres to them.

The UX Designer's Role in Prioritization It can be tempting to think of prioritization as a shared responsibility between the project sponsor, project manager, and development team leader, rather than as a problem for a UX designer. There is nothing but the truth. Prioritization discussions are where successful solutions are made or broken. User experience designers have a responsibility to apply their skills in these important conversations. If you are already part of the prioritization process, this section provides tips on how to get involved. If you're not, do what you can to get involved. This means informing the project team about the skills you bring, such as facilitation, and the balanced perspective you can bring. It is important to demonstrate that you can understand the points of view of different team members and work together to achieve a common understanding. See the "Maintaining Good Volume" section for more information on how to achieve this balance.

The prioritization team looks at each requirement to answer the following questions: How important is it to the business? How important is the

requirement to achieve one or more project objectives? What is the impact if this requirement is omitted? What is its importance to the user? The requirement has been met

a common user need (or high impact needs for priority user groups)? How will it affect the user experience if this is omitted? Are there other requirements that are very similar and potentially competing with each other? On this last question, keep in mind that multiple solutions to the same problem can compete with each other and confuse users (as well as require more support). For example, The New York Times has enough development staff to support all sharing features.



on nytimes.com (in blue in Figure 9-2), but some users may not know whether to click Recommend, Email, or Share to send the article to a friend. If your users might not be familiar with all the sharing options that have exploded in recent years, you should probably start with a smaller set of features. What is the technical feasibility of developing the requirement? That

Does it take time to develop? If you are working with relatively new technology, the estimated time will be longer here. What is the viability of the resources for its development? does the job

Does the team need the people, skills, and money to develop the position? (Consider the cost of acquiring and learning new technology tools.)

Figure 9.2 A photograph from www.nytimes.com, highlighting the newspaper's many sharing opportunities online



Create a worksheet with your decisions for each requirement. This could be a low, medium, or high score based on the questions above, or you could use a number scale so you can add the numbers for ranking purposes. As you build the list, you may need to consolidate similar requirements or break one large requirement into several smaller requirements that may represent separate units of work. Please note that this system is only intended to help with sorting and prioritization. it is not based on a scientific analysis of the feasibility of the requirement. However, it is very useful for managing a long list, inspiring discussion, and capturing relevance. Figure 9-3 shows an example of a prioritization worksheet that uses high-level feasibility and importance categories (low, medium, and high) to assign relative values ​​to each requirement. Priorities Worksheet



commercial interest

Interest of the user



)()$+)*'(&,! &%**!%&($*!&% &()!%#!)*& !)*(!+*&()














(()% *("/%*(!% *("!%&!,% &%%&(( ) )!''




)()%*("* !( '"/ #&-!%*(+")&( !('#%)

$!# &%2($*!&%


%$!#!))%**& &%2($%&(( ) %$


+#2##$%* ,!-)

)()%( &* (+)*&$()1 (,!-)&* &$'%/0)+#2##$%* '(&))


+#2##$%* *

)()% *-!* &* (+)()&+* * !(&((+#2##$%* .'(!%

Technical viability

resource viability
















Figure 9.3 Sample Requirements Prioritization Worksheet



Assigning values ​​to each of the categories will generate a lot of discussion within the prioritization team. How does it facilitate discussion and decision-making? Two of the most important things you can do is understand (and sometimes represent) the different viewpoints that are essential to defining a balanced solution and help resolve areas of conflict within the project team. First, let's talk about representing the correct viewpoints when prioritizing. This includes creating and maintaining tension between user advocacy, corporate advocacy, and development advocacy; a good kind of tension because it creates a balanced solution that delivers a good user experience, meets project constraints, and aligns with business goals.

Maintaining Tension During requirements gathering and throughout the rest of the project, you may notice three roles during group discussions:





Business Champion – The team member who represents business needs and requirements and ensures that they are captured and met as faithfully as possible. The main concerns of the corporate lawyer include achieving strategic objectives for the company and the department, ensuring that the corporate vision is not lost during the project, and establishing and maintaining focus on the project objectives. User Advocate: The team member who represents the needs and perspectives of the key users who will experience the site. Key concerns for the user advocate include ensuring the site meets usability expectations, providing a satisfying and engaging experience, and encouraging behavior that supports the goals of the project. Development Lead: The team member who represents the needs and constraints of the technology and QA teams. Key concerns include ensuring that the development team is efficient, within scope, and delivers a product that meets the quality standards expected by users and business stakeholders.


Think of it as a tug of war between supporters in three directions. If the tension between the three is maintained in a respectful manner (ie, no advocate dominates), all three parties can work toward a balanced solution that meets the project goals. Each team member must know that he has an interest in maintaining balance throughout the project. If one party dominates, the other functions lose ground and the project risks missing its objectives, or achieving them at much higher cost than anticipated. See Figure 9-4 for examples of what can happen if the voltage is unbalanced.

Figure 9.4 Consequences if proper tension is not maintained



Can you play more than one of these roles in a play? Absolute! Ideally, multiple team members have primary responsibility for each role, but that doesn't mean you can't switch roles from time to time. You can even switch from one conversation to another, or even from one topic to another. As a UX designer, you're most likely to play the role of user advocate, but you need to understand the viewpoints of all three roles and make sure they're consistently represented to create successful designs. While it's healthy to switch roles from time to time, make sure you don't designate yourself as the primary person responsible for more than one of these roles. You can start making unquestionable commitments as the project progresses because you won't have an ever-present "devil's advocate" asking you these awkward but important questions. If you need to fill more than one role, try to find a part-time employee who can occasionally fill the other roles to keep the tension going. So far, we have largely focused on the role of the business advocate (especially in Chapters 4 and 5) and the user advocate (especially in Chapters 1 and 6). Let's take a moment to discuss the third major role in our prioritization discussions: the development advocate.

The Development Advocate If you're a UX designer at heart, it's best to put yourself in someone else's shoes to understand their needs and goals. This skill is invaluable both in fulfilling your role as a user advocate and in ensuring that you communicate and collaborate effectively with people within your organization. Let's take a moment to use this skill to describe the goals of the development advocate. One of the great design debates is about the extent to which the developer proponent should participate in and influence the requirements gathering process, and what is their role in it. If the development proponent presents the technical possibilities and limitations too early, this can limit some of the brainstorming that could lead to highly innovative solutions. After all, today's blue sky concept might be possible with some additional engineering exploration. Even if the idea isn't viable, discussing it may reveal an underlying need that you can address. (Mapping feature requests to needs is discussed later in this chapter.)



These are the goals and associated responsibilities of the development lawyer: Deliver requirements on time and within budget Ensure team effectiveness (avoid unnecessary work, ensure good

communication) Make better use of available tools and platforms Choose cost-effective add-on tools Make sure future changes don't require too much additional work Make the solution scalable to accommodate growth Make the solution modular so individual components can be changed easily Make the solution as standardized as possible: as few adjustments as possible

on a purchased system, less redevelopment work will be needed later Ensure the development team works well Reduce turnover by providing relatively interesting and rewarding work Reduce burnout that can occur with last-minute pressure


Work with legacy requirements Step 4

Paso 1

Review the requirements and highlight those with unclear needs or questionable user value.

Inherit the requirements from the stack or and do the first revision.


Step 2 Gather information that provides context to potential users.

"Users are..."

Step 5 Review the identified requirements with the team to investigate needs and conflicts. "This is why."




Step 3 Create a temporary user model.

Step 6 Prioritize any changes you think need to be made. Advocate for them and introduce them to the project team. Be clear and realistic.




"Correct observation!"







However, if the development lawyer is not involved early enough, the team may go too far with a particular option and find it too expensive to include, or the development lawyer ends up losing one or more of their own options. goals. Last but not least, Development Advocate is a great resource for highlighting some of the technology opportunities that can really make your solution sing, like new technologies or underused functionality. An effective approach is to schedule key reviews with the development attorney once brainstorming is complete, high-level requirements are established, and the prioritization process is about to begin. This allows the developer to spend the first part of the process exploring the chosen tools to get more details about what is and is not possible, and then to be more involved in the requirements process when certain topics and ideas catch on. gravity. If you feel that certain requirements-gathering sessions are essential for the development attorney to participate in, make sure you are both on the same page about your role in the meeting and how to understand the advocate's potential concerns. belong. You can also record these types of sessions to discuss later with your development attorney. You may need them yourself when you are busy planning! This kind of clear communication and follow through on information gathering is crucial to building strong relationships among team members, which can make a big difference in the flow of the prioritization step later in the process. But sometimes, despite your best efforts, conflicts arise when you try to prioritize requirements. Let's talk about how you can help the project team manage this conflict.

Dealing with conflict in prioritization When there is major disagreement, prioritization can be a lengthy process. And if these disagreements are not resolved, they will continue to arise during design and development. These conflicts can have many different root causes. Here are some of the most common:



The team disagrees with the objectives of the project or

incorrect business strategies (either misunderstandings, forgetfulness or disagreements); Members of the opposite group are closely associated with a particular set of characteristics.

(Perhaps they are excited about the features, or they may have promised them to a variety of customers or key stakeholders.) There are conflicts between business needs and user needs that are not

easily solved The technologies used are relatively new to the development team,

so they feel uncomfortable making estimates. Let's look at some of the situations above and discuss how you, as a user experience designer, can help solve them.

Picking Your Battles During the prioritization process, some of your favorite features may be on the chopping block. It's easy to get upset about this, especially when it seems like user requirements are more often checked off the list. If you passionately defend each claim, you risk making the decisions a priority for you. Here are some questions to ask yourself as you decide when to pursue a particular requirement and when to give in: How does the requirement support the goals of the project? Does it significantly reduce a particular risk? For example, does it reduce user exposure to spam by reducing negative site views? Are the other suggested location requirements dependent on it for proper operation? What is the impact if the attribute is not included? Is the feature worth the value of the effort it takes to develop it (even at the cost of other features you find valuable)? If you have solid answers to all of these questions, please bring them to the priority table to support your case. If not, consider leaving, but be sure to share your reasons so others can see that you're committing yourself for the good of the project. This demonstrates your ability to consider the broader business context and increase your engagement in future priority discussions and change requests.



Lack of alignment in project direction The team does not agree on the objectives of the project or the underlying business strategies. Let's separate this source of conflict into two areas: communication and consent. When it comes to communicating project goals or business strategies, ask yourself how you can personally help improve communication. Is it about posting the goals or strategies where all team members can see them (like in a war room or online collaboration area or at the top of every meeting agenda)? Or maybe a visual representation of the goals or strategies is needed to grab the attention of the team and get team members excited about the vision they are working towards. Remember the visualization skills discussed at the beginning of this chapter? Use them to create an image that can be easily printed and posted or quickly drawn on a whiteboard to help focus conversations. If consensus is the problem, ask yourself how you can help bring everyone together. Is the conflict caused by concerns about the risk of releasing an entirely different feature to users? There may be research you can do to resolve some disagreements, such as surveys, interviews, or contextual questions (see Chapter 6). Or perhaps you can use your facilitation skills to have a structured discussion about disagreements, going through the issues point by point until they are resolved. Conflicts Over Favored Traits Members of the opposing team are associated with their own set of traits. Suppose the manager of the training department wants extensive topic-based courses and wants to send the head of sales an interesting demo to generate interest. Meanwhile, she has ten other business stakeholders in different roles, all of whom have pressing needs. How do you help reach a consensus? One method is to implement a variation of the one you read about in Chapter 6: Affinity Graphs. In this approach, you can work from an existing set of requirements or ask stakeholders to define their own requirements (especially useful if the requirements gathering process is still in its early stages). If you are working from existing requirements, you can print them



separate the pages and tape them all to the wall. If not, ask stakeholders to write down their key requirements on a set of Post-it notes. What you need: A space large enough for your stakeholder group to come and go

that has one or more large blank walls, you can place Post-it notes on a pad of large Post-it notes, at least one for each stakeholder

colors), a set of ten bullet points per stakeholder. Gather the key stakeholders in a room and ask each one to take a moment to write down the key requirements on a note. Give them 15-20 minutes to do this. (Don't look!) Ask everyone to make their demands on the wall. Then have everyone walk around and describe what they posted. As you move around the room, start grouping similar requirements together (if stakeholders agree they are similar). Once the requirements have been explained and grouped, distribute the sticky dots. Tell stakeholders that they can indicate which requirements are of highest priority to them by distributing their points on Post-it notes. They can choose to put all ten points on one requirement, for example, if it is very important to them, or they can choose to put one point on ten different requirements. You start to see clear favorites as people place their points. When you have finished placing the dots, review the results together. When forced to choose this path, stakeholders will present their own internal priorities, and discussion is likely to become much easier.

Browse For more information on a variation of this technique to use for prioritization, see this article "The KJ Technique: A Group Prioritization Process" by Jared M. Spool: www.uie.com/articles/kj_technique.



This type of technique can help you kick start the prioritization process or restart a process that is blocked due to discord. Once you have momentum and a common understanding, completing the prioritization document (as we saw in Figure 9-3) becomes much easier. Along with your priorities, you need to prepare for the full design effort that will soon follow. Having a plan for your work allows you to estimate the effort it will take to create detailed plans, integrate your work with that of others on your project team, and coordinate efforts to align with project milestones. The following section discusses some considerations that can help you plan.

Plan Your Activities and Documentation Once you have a prioritized list of requirements, and ideally have completed some initial conceptual work (such as the scenarios presented earlier in the chapter), your project manager will likely start asking you for details about what you are doing. doing. do. doing. do what you propose. There are different types of design activities, and each has a different impact on the way you design, the time it takes, and the type of document you end up with. This is a "document" in a general sense. it can range from a whiteboard sketch to a wireframe or prototype. In the next three chapters we will cover some interaction design activities. When planning which activities to use, consider the following questions: How iterative will the overall process be? Ideally you can start from

quickly explore different concepts (eg through sketches) and then agree to develop them further. This approach can also include one or more design concepts that reach users (see Chapter 13 for more information on design testing). How do you collaborate during design? If you work closely

with a team in the same location, you can record more collaborative whiteboard sessions. If the team is spread out, consider web conferencing sessions with tools that enable high levels of collaboration despite the distance.



How are design documents shared with the larger team? Is

Do you email them to a small group or post them to an online collaboration site? What does this mean in terms of size limits and the version tracking process? How much detail your designs should include later in development

edit, process; If your documents are part of a formal quality assurance (QA) process, you'll want to make sure you involve someone from the QA team early on so they understand what kind of details they'll be getting from you. How long should your documents 'live'? For complex projects

the minute you stop updating a document, like a frameset, it starts to "die" - the details get more inaccurate as time goes on. (This isn't always a bad thing, as long as you participate in the discussion of those changes.) Documents that focus on providing general guidelines, such as a brand guidelines document or a library of interaction design patterns, tend to last longer. go. Who are the main users of each type of documentation? This answer

may differ in different parts of the project. The primary users of your conceptual design documents are typically business stakeholders and the design team, who use them to communicate and share ideas. The detailed design documents are primarily intended for developers who need to implement the designs. these documents provide a specific address. What other types of documentation should yours align with? I will

You should provide some sort of relationship between the priority feature list you created earlier and the layouts you create. You may also need to keep track of various other types of documents to make sure everyone is on the same page. These documents can include brand guidelines, content development plans, functional specifications, or use cases (see Chapter 2 for an overview of the different roles and types of documentation they can produce). How is the effort required for each type of document calculated? This

One is difficult, because there are so many variables in a project that can affect timing. However, by establishing a baseline for a rough estimate, you have a starting point and can validate the numbers as you get more information. For example, you can set a basic estimate that it will take around 6 hours to create each detailed structure. If you calculate a specific attribute



will take about five pages (for example, based on the results of the storyboarding sessions described earlier in this chapter), you have an initial estimate of 30 hours for this feature. If you end up taking up eight pages per structure, try to figure out why. If it's something you think will continue, you should revise your assessment and possibly re-prioritize. What additional factors affect document time? Total

Timing includes review time with the team and stakeholders, as well as time for the number of reviews you think you need. For detailed sites, you can also include the time it takes to reconcile design documents with other documents, such as detailed functional requirements (such as use cases). Write down these assumptions yourself so that you can check them later. Will you be working with many designers, and if so, how are things going?

Are you going to divide the work? Working in parallel but different parts of the site allows you to work fairly independently on the documents you create. If you divide your work in a highly interdependent way, you'll need to schedule time to coordinate your plans, and you may also need a way to track and merge different versions of documents. Save yourself a lot of headache later by working out a process from the ground up and creating some design guidelines early on so you're on the same page when it comes to basics like navigation. Now that we've talked about some of the things to consider when choosing your design activities, let's explore those activities. In the next three chapters, we'll look at various documents, such as sitemaps, workflows, mockups, wireframes, and prototypes.




Sitemaps and Workflows Build your project from here to there and back Sitemaps help define the structure of websites and applications. They can show hierarchies and connections that help your audience understand where users can find content. Workflows take sitemaps a step further by identifying the different actions that a user can perform on a part of the site. Workflows also map error states, content, or page views based on decision points throughout the process. When used together, sitemaps and workflows can give your audience a clear understanding of your content structures and how users can navigate through them. russ unger


What is a sitemap? 1.0

1.0.1 Terms and Conditions

At home

2.0 – 2.x


the blog






Figure 10.1 Sitemap for a basic website with blogging functionality

Starting with the most basic definitions, a sitemap is simply a visual way of displaying representative pages of a website (Figure 10-1). A simple sitemap usually fits on a piece of paper and looks similar to an employer's organizational chart. However, sitemaps are not just for websites. you can use them for any type of application that benefits from recognizing pages, views, states, and instances of what is displayed. In most cases, you use a sitemap to show teammates and clients how the content of a website is organized. It summarizes the navigation of the site and in some cases it shows all the links that each page can have.

What is the workflow? Figure 10.2 A basic workflow showing a user's path based on login status

At home

Is the user logged in? Page not linked



linked page

Workflows specify paths or processes that users (and sometimes a system) will follow as they navigate your website or application (Figure 10-2). While sitemaps and workflows may appear similar at first glance, the two types of diagrams serve different purposes: a sitemap tells you the visual hierarchy of a website or app's design, while a flow Workflow gives you details about users' options and the paths they can take. . take. 166


Tools of the Trade If you are new to user experience design and need a tool to create work products, you have several options: Microsoft Visio (http://office.microsoft.com/visio) Axure RP Pro (www . axure .com) OmniGraffle (www.omnigroup.com/applications/OmniGraffle) Adobe InDesign (www.adobe.com/products/indesign) Adobe Illustrator (www.adobe.com/products/illustrator) Microsoft PowerPoint (http: // office .microsoft.com/powerpoint) OpenOffice Draw (www.openoffice.org) HTML Blueprint CSS (www.blueprintcss.org)

So how do you choose? You can ask other designers. everyone has a favorite and they usually like to name it. Don't be surprised if, like your writers, they reply "good pen and paper." You can also try free trials online or choose a free solution like OpenOffice Draw, which is part of the OpenOffice.org suite of tools and exports the same formats as popular office suites. What do we use besides pencil and paper? Many of the examples in this book were created with Microsoft Visio 2003, using templates created by Nick Finck, Director of User Experience at Blue Flavor (www.blueavor.com) and Editor of Digital Web Magazine (www.digital-web.com ) . . Nick's excellent stencils can be downloaded from www.nicknck.com/stencils.html. These ready-to-use templates, forms, and samples are invaluable for both young and seasoned professionals. In addition to Nick's, check out the offerings from the Information Architecture Institute, which hosts many of these tools, on its AI Learning page: http://iainstitute.org/en/learn/tools.php. Note Microsoft currently offers a 2007 version of Visio. However, many companies have not yet updated the product, and to avoid version differences, we currently recommend Microsoft Visio 2003.



Regardless of the tools you decide to use, there are countless examples online of other professionals willing to share and help you in your career. These are largely free and can provide you with the framework you need to create, at the very least, very professional looking documentation. Unfortunately, many people do not use these resources. Don't be like these people!

Sitemap Basics and Workflows The most basic elements of your design program are more than enough to get you started creating sitemaps and workflows. However, to ensure that your creations can be easily interpreted by a wide audience, it's best to use a standard set of shapes. The Visual Vocabulary for Information Architecture is one such standard and is used in this book. It was created by Jesse James Garrett, one of the founders of Adaptive Path (www.adaptivepath.com) and is available online at www.jjg.net/ia/visvocab. The site offers many elements to help you articulate your sitemaps and workflows, which are available with detailed descriptions and as downloadable templates for many of the popular design and drafting programs (more on that later). To help you get started and familiarize yourself with the basics, the following sections look at the basic set of sight vocabulary items and what they represent. Figure 10.3 Page item from Jesse James Garrett's Visual Vocabulary

Figure 10.4 Page stack item from Jesse James Garrett's Visual Vocabulary

Page According to Jesse James Garrett, a page is "the basic unit of user experience on the Internet." Content "events" or "views" may be more realistic these days, but a page still makes a lot of sense. There are several ways to design these pages, but the simplest and most widely used format is the simplest.



rectangle (Figure 10.3). As you progress through your sitemap and workflow creation, you'll want to find the style that best suits your tags and page numbering.

Page Stack A page stack represents multiple pages of similar content (Figure 10-4). An easy way to understand page stacks is to think of dynamic content, such as a shared blog page created with a posting system. These pages are designed once and are in a layout template, but you can click through many different pages of content without leaving the original template layout.

Decision Point Figure 10.5 Decision Point Item from Jesse James Garrett's Visual Vocabulary


(10 a)


member's house

A decision point is used to represent the path a user can take depending on the answer to a question (Figure 10-5). Decision point 10a could be "Are the user's credentials correct?" The answer to this question would determine which page (or content view) would be displayed. A failed connection results in an error message, while a successful connection takes the user to the site's members' home page. Take the time to mark the correct decision points. You'll be glad you did, especially when you share the product of your work with teammates or clients.



Links and Arrows Figure 10.6 Link and Arrow Items from Jesse James Garrett's Visual Vocabulary

Links and arrows are used to show movement or progress between pages, page stacks, decision points, etc. Links generally appear where there is a call to action from one page to another. For example, a link to the About Us page from the home page could be the link between the two pages. The arrows (above Figure 10-6) indicate "downstream" movement toward task completion. Crossbar links (at the bottom of Figure 10-6) can be used to indicate when returning to the page you came from is no longer available ("up" traffic). For example, when a user logs into a website, the content of the home page can now be customized for the user and the generic or login page is no longer available to the user via the path just to follow.

Conditions a


Figure 10.7 Condition element from Jesse James Garrett's Visual Vocabulary

A dotted line is a fairly common way to represent a condition. It can appear in sitemaps, workflows, and other work products that you create or invent. You can use a dotted line as a link (as in Figure 10-7) or as a box around an area to indicate that a link to a page, or an entire section of pages, is subject to conditions based on another action or event. .



Common Mistakes You don't go into a presentation with a piece of peanut butter on your chin or a coffee-stained shirt. Such a mistake would not only undermine all your hard work, but could also prevent you from landing a good project. A sloppy sitemap or a workflow that looks unprofessional can do just as much damage. To help you spot these small mistakes with big consequences, the following sections take a closer look at some bad designs. Learn to recognize these common mistakes, and then avoid them.

Out of order connections Figure 10.8 A broken connection between two pages

Sloppy dating is just that: shameless. They are badly drawn. They look very amateurish and give you, the writer, the impression that he doesn't pay much attention to detail in his work, to say the least. Most tools have a method to help you connect your lines to your boxes. Use it to your advantage. Don't be lazy, no matter what time constraints and pressures you may be under. In most applications, you can use a combination of Shift and other keys to drag items from a starting point in 45-degree increments. Take advantage of this built-in feature and make sure your connections are well connected. If you're showing pencil sketches, keep an eraser handy just in case. Make it a rule: always make sure that all lines that touch another object are exactly connected.



Misaligned and unevenly distributed objects

Figure 10.9 Pages not aligned and unevenly spaced

Depending on the tool you use, it can be difficult to ensure that your objects are precisely aligned or evenly spaced from each other in your sitemap or workflow. There are some pretty easy ways to make sure you're breaking this basic rule. To get started, enable the grid in whatever app you're using. That way, whether or not the tool offers options that ensure well-aligned and evenly spaced objects, you can always count the number of meshes between your objects. Fortunately, when you use pencil and paper, you can use graph paper and apply the same basic principle. It's so easy to make your documents look professional. Unfortunately, it's also very easy to make your writing look like you don't really care about the quality of your work.

Badly positioned text Figure 10.10 Disjointed text

Step 1 Step 2

Careless text placement (as in Figure 10-10) seems easy to avoid, but it's another common mistake. Find a way to make your text fit nicely in the shape you've created, and make sure that any labels placed outside your elements have the correct binding (Figure 10-11). 1.0 Home page


1.0.1 Terms and Conditions


Figure 10.11 Well placed text

It may seem simple, but proper placement of your text, along with proper font size and usage, will make your documents easier to read and use.

No Page Numbering It's time for another rule of thumb: number every page of every sitemap you create. Don't make a fuzzy, uncountable map like the one in Figure 10-12. Conditions &

At home

the blog





Figure 10.12 Floor plan without numerical structure

Each page you identify in your sitemap should be numbered, and your numbering system should allow for subsequent changes as new iterations and versions of your project are created. You can use different approaches to page numbering. The most common is to specify your home page as 1.0 or (Figure 10.13). Over time, you'll be able to determine which works best for you, but until you're comfortable and understand the pros and cons of both approaches, start by specifying your home page as 1.0. Using this method, you can count as 0.X all decisions and pages that might precede your home page, such as a Flash preloader, login or registration screen, or other types of pages. A numbering system in your sitemaps allows you to sync other documentation with it. The numbering system can be transferred to other documents, such as the content matrix. Content creators can match their copy and other content

specific pages (and on a specific element in a wireframe, more on that later). Workflows. Workflows can use the same numbering system to show how

a user will proceed to the pages of a particular job. Wireframes (see Chapter 11). Your cable pages need to be shared

the same numbering system as your sitemap pages to provide a clear link between the two documents.



Visual design. Visual designers can synchronize pages and design elements.

specific pages in your sitemap. This allows them to segment their inventory when it's time to deliver their designs to developers. Quality assurance documents. Quality control teams can

write scripts dedicated to a specific page or pages in the sitemap. Your attention to detail and structure at this point will help keep everyone else involved in the project up to date and structure their tasks. 1.0

1.0.1 Terms and Conditions

At home

blog 2.0 – 2.x

3.0 Related

4.0 Work

5.0 Communication

Figure 10.13 A sitemap that links pages correctly, with elements aligned, evenly spaced, and numbered correctly

In short, numbering the pages in your sitemap makes everyone else's life easier, and that means your life becomes easier too.

The simple sitemap in Figure 10.13 not only contains page numbers, but is also a good template for creating a basic website map that has limited dynamic functionality and is mostly static in nature. The pages identified for this site were Home Blog Related work Examples Contact

As you can see, this simple sitemap contains the most important elements of the visual vocabulary while maintaining a professional look and feel. More importantly, it provides a very clear view of the navigation, pages, and terms available to users of the website.



Advanced Sitemaps A simple sitemap will usually fit on a single sheet of paper and probably resembles an employer's organizational chart. However, more advanced sitemaps can span multiple pages. Home 1.0 Lorem Ipsum Pain

May the pain be very good

February 9, 2008

page 3/9

Figure 10.14 Advanced Sitemap Home Page View

When creating sitemaps that are more advanced or for larger websites and apps, one approach is to use your home page to identify the steps required to get to the site's home page. (That's right, we recommend using a workflow as part of your advanced sitemap.) In addition, you'll need to identify all top-level pages, global navigation elements, and footer elements. This allows you to see a very high overview of the site and gives your team and clients a clear view of the project. The first page is also a good place to add a legend or key to help you read your sitemap (see Figure 10-14). Your team and your clients need one. Don't skip this step!



May the pain be very good

February 19, 2008

page 4/9

Figure 10.15 Advanced View section of the site map

Essentially, any pages you create after your first page must reference it. For each top-level page, you must crawl at least one page that identifies all pages, page stacks, and external content required by the website or application (Figure 10.15). If necessary, don't be afraid to link to subpages. Sitemaps can be made more elaborate than any standard piece of paper allows. This is not a concern as long as your sitemap is well organized and the links are clearly documented for your audience. These examples are more than enough to get you started in the world of sitemap creation. As you begin to progress through a variety of projects and find your skills (and often the needs of your team or clients) grow, you'll discover that there are many different approaches and methods you can use to deliver sitemaps. .



Breaking the sitemap mold Now that you've seen solid examples of sitemaps that should meet most of your needs to accomplish your core tasks. Don't let these models stop you from exploring ways that work best for you, and share them with us! Different approaches can highlight information beyond the basic architecture of the site. For example, consider the site map in Figure 10-16, provided by Andrew Hinton, a senior information architect at Vanguard. Follow new research

to register

Support bc.org


Updating profile

Find similar people

"Academic" interest (medical, student, general)


Chat Get Print Mtrls

Learn more about bc.org

new concern

hazard management

worried loved one


Expert Conf. Join the learning

New Diag New Scenario / Sit.

Figure 10.16 Advanced map. Thanks to Andrew Hinton.

This site map not only shows the different pages of the site, but also serves to provide information about the routes and priorities of the users. Andrew (www.inkblurt.com) says he created the sitemap after seeing an example by Wolf Noeding that ignited his creative fire. Andrew uses this sitemap to represent different user scenarios and mental models related to the site. The larger circles on the map have an additional function: they mark the top-level areas of the site that receive the most traffic. Like all good UX professionals, Andrew borrowed, but he also gave credit. There are limitless ways to expand his sitemaps as he becomes familiar with using the tools and identifying the needs of his work product and his clients. Get inspired where you find it! Don't be afraid to try something new, but take the time to make sure the time you spend is useful and valuable.



Workflows Using many of the same basic elements as sitemaps, workflows are diagrams that identify a path or process that users (and sometimes a system) will follow as they navigate through your website or app. You can use the workflows in different ways. When used in conjunction with a sitemap, they can show how a user gets to a page that displays a specific set of information. They are sometimes used to show how a certain type of user (a person) would expect to visit a website and what that person would expect to see based on that person's personal mental model. You can also use workflows to define complex processes that must be clearly understood before submitting the project to the development team. You may not use workflows for every project you work on, and they may not always end up as a work product that you present to your clients, but it's always a good idea to use them to your advantage, even in pen and ink. paper. Format. A little clarity goes a long way. To create a workflow, you need to understand the purpose of the user. In some cases you will receive a requirements document and in other cases you will receive (or write) a use case. While a use case consists of just a few sentences that summarize tasks and goals, it allows you to summarize the user's point of view on the experience. The use case for the scenario in Figure 10-17 might look like this: The system displays the list of projects. The user selects a project. The system displays basic project information in record mode. The user changes the status of the project to Closed. System checks for running tasks. If there are pending jobs, the system will display an error. If there are no open tasks...



Pending payment control system. If there are pending payments, the system will display an error message. If there are no outstanding payments... The system displays the summary page.

Home [My Claims List] Select Claim

Information [Record Mode]

Claim Status Changed: Closed

Pending tasks?


Error message


[Show open tasks and requests] Yes

Pending payment request?


Information [Read Only Mode]

Figure 10.17 This workflow specifies how a system displays information to a user based on responses to multiple conditions.

The workflow in the figure illustrates the order of information presented to a user based on whether different use case conditions are met. If a question in the center ("Pending tasks?" or "Pending payment request?") is answered in the affirmative, the system displays an error message, which can provide additional information to help the user complete the required tasks sooner. to continue. If the answer is no in either case, the system will present the user with a success screen. The workflow in Figure 10-18 shows the paths a user can take from a calendar application to a travel shopping site. The workflow is very sophisticated, identifying three very different paths that the user must test to ensure that the detailed flow for each path meets the needs of the users.



S100 Calendar Hazard Finder Calendar Winkelen

S10 Detailed Fee Finder

look for

Search by price (show rates matrix)

Search by schedule

flexible appointments

select R20 Search results (by price) - Show itineraries - Edit search

P30 seat selector


Search Results for R60 Flexible Dates (by price)

R10 Search results (by hours) Show Sections -Edit search

Q10 Itinerary Overview/Passenger Details - Selected Seats


P20 Payment and billing information



multiple pages

to confirm

confirmation Q50

decision point link

conditional binding

Figure 10.18 Workflow used to demonstrate a user's journey through the stages of a purchasing process

Users of this app can enter a range of dates for their trip and then shop based on their own priorities. Once users set their travel search dates, they can prioritize their results based on what matters most to them: price, travel date flexibility, or travel times (schedule). The workflow identifies high-level paths that a user can take to provide instructions to the people facilitating the test. Detailed workflows can be created for each of the routes in the groups and then provided to the development team to build the pages needed for testing.



Taking Workflows to the Next Level As with all the topics in this book, don't feel like what you're looking at here is the beginning and end of the workflow universe. Discover new applications and extend the use of the basic elements described here as much as possible, as long as there is a good purpose for it. As your workflow creation skills continue to grow, you may find yourself creating a work product that is a bit more colorful, has more options, has custom or enhanced language rules, etc.

Process Flow Figure 10-19 shows a workflow that Will Evans (www.semanticfoundry.com) took to the next level and turned into a process flow diagram. The process flow is very high level and flexible and is used here to show that in the many steps of a project process, the first stage of the project appears to be just one step, but in this particular case it is important to understand that it is not. So. consist of a single event. Instead, the first phase of the project, in this case, actually consists of several activities: User research Market research Ethnography and contextual research Usability testing Competitive analysis Market analysis Cultural analysis Record analysis



Figure 10.19 This process flow diagram takes workflows to the next level to articulate complex scenarios. Thanks to Will Evans.

Reports are created for each of these activities and incorporated into various other documents before the project begins, where the necessary stakeholders meet to determine scope, priority, and dates. All of this is shown in the process flowchart. As you can see in this example, the sky is the limit when it comes to creating workflows. Look at the example above and think of ways to take your products to the next level. It might take some practice, but with a little finesse you can create workflows that will blow your mind.

Swimlanes James Melzer (www.jamesmelzer.com), Principal Information Architect at SRA International Inc. (www.sra.com), has created a series of diagrams that go far beyond basic workflows. The diagram in Figure 10-20 shows a workflow that has been extended to show "swimmers" of actions, notifications, and so on. in a process in which many events occurred simultaneously. With this project, a traditional approach to workflows could have been a nightmare. !



Instead, James explored expanding the basic workflow to include all the different steps and actions that take place in a much easier to understand form.

Figure 10.20 This swimmer diagram is an example of extended workflows to illustrate complex scenarios with multiple actions at multiple points. Thanks to James Melzer.

James described the project and the swimmers as follows: The system allows people to manage information about the buildings they own. This enhancement allows building service partners to provide system-to-system data on behalf of their clients, reducing the amount of data owners must enter. The project consisted of three parts: partners configuring the presentation and operation of their data services, customers registering and using partner data services, and ongoing partner data management and troubleshooting. from backend. We had plans for a major expansion of an existing system. We knew from the beginning that almost all service scenarios involved multiple users and multiple systems. There were many reports and many of the processes were asynchronous. This diagram helped us identify, design, and explain the service scenarios needed for the project. In the full version of this work product, we actually had detailed wireframes laid out below the flows in this diagram. The set covered one wall. Once we're confident enough in the design concept, we pare it down to a more traditional multi-page spec.



The most important thing to remember here is not to be limited to using workflows or sitemaps. Push the boundaries of the basic concepts you have learned in this chapter. If you really need something to test your skill, spend some time creating a shoelace tying workflow. Good luck!




Design and direction of wireframes and annotations: Before visual design begins Wireframes and annotations are ways of specifying the proposed content and structure, as well as the functional behavior, of the rendering of a web page or application. Combined with sitemaps and workflows, these documents are also extremely helpful in identifying prototyping scenarios and testing concepts. Threads are usually displayed in grayscale, with no images or final content. Instead, they use placeholder content to highlight representative locations that can be used as a guide for visual layout. russ unger

What is a wireframe? Basically a low-fidelity prototype of a web page or application screen, a wireframe is used to identify elements that will appear on the page or screen, such as sections Content navigation Images and/or media need shape elements Callouts to action (CTA)

Wires are typically created in black and white or grayscale, use image placeholders, and are not within font specifications (although many fonts use font size to convey type separations). They come in all shapes and sizes, from very simple to so advanced that they mimic almost full screen design. The cables are in development. They are no longer provided to designers and developers simply as sketches of their tasks. Wireframes are now used to represent the website or app to clients, designers, developers, and all other team members who have a core interest in it. It is common practice to show them to clients for "design thinking" validation before the development and visual design phases begin. Often the people who make the cables work hand-in-hand with the people who create the business requirements (in some cases the same people). It should also be noted that some of the best wireframes and annotations are the result of direct interaction and collaboration among various contributors, from business analysts to developers and other designers. Some companies use their leads and callouts instead of business requirement documents (BRDs). While the world is far from claiming that BRDs are extinct, the start of this change is enough to show how important it is to be very careful when doing your cables and annotations. In many cases, users are presented with schemas for feedback that can validate page elements or request changes. wires that



placed for users usually have another name: prototypes. (For more information on prototyping, see Chapter 12.) To help you determine which approach works best for you, this chapter covers the basics of creating wireframes and provides examples from designers in the field. Like the rest of this book, these examples are just the beginning—don't be afraid to explore and innovate on your own.

What are annotations? Annotations are simply explanations and notes about an element or interaction in a wireframe. They typically contain information such as content identification or labeling Content Source(s) Display Rules Interaction Rules Interaction Destinations Processing Rules Content/Message Error

It is best to write comments in a very direct tone if not concise and clear explanations. Don't leave anything to chance in a comment. there is a very big difference between should and should. Incorrect: "Activating this call-to-action (CTA) should bring up the home page." Good: "Triggering this call-to-action (CTA) will show the home page." Okay, to be fair, the first example isn't exactly terrible, but the word can confuse a developer in the process, who may not have the luxury of having their favorite UX designer around to answer questions. Make sure your annotation style is concise and leaves no ambiguity for anyone who should read and rely on your instructions.



Who uses wireframes? With their clear and concise annotations, the wireframes are all very good, but who is the audience for these results? Unfortunately, there is no easy answer to this. From project to project, your audience can range from one person to a combination of several groups. Table 11.1 describes the possible target groups for your cables. TABLE 11.1


common wireframe



Project management

Project managers can use wireframes as talking points within the team to emphasize strategy, technology needs, and a very high-quality user experience.

Business Analysts

Business analysts can use sub-processes to ensure that their requirements are met and to validate that they have not missed any requirements that need to be included.

visual designers

Optical designers can use the cables as a model for their production. Wireframes give them an overview of page elements and the behaviors to include.

content creators

Writers, content strategists, editors, and others in charge of copy can use wireframes to map out a content matrix and identify the content needs of a project.

Specialists in search engine optimization (SEO).

SEO experts can use schemes to help identify appropriate naming schemes, copy needs, and improvements to your overall SEO strategy. (For more on SEO, see Chapter 8.)


Developers often use wireframes in conjunction with (and sometimes instead of) business requirements to understand the expected functionality and behavior of the design. In some cases, the cables can be used as the basis for a proof of concept.

Quality assurance

A QA team can use wireframes as the basis for writing their test scripts. Once the cables are approved by the customer, the variance should be minimal and this allows the QA team to start work sooner.


Users can view threads at very early stages, sometimes in the form of "paper prototypes", as a mechanism to determine design direction. (See Chapter 12.)


Customers are increasingly involved in reviewing frameworks to validate if business requirements, goals and objectives are being met and to provide approval to move to the visual design stage.


Creating a Wireframe In order to create a wireframe, some prerequisites are usually needed. These can take the form of a formal document detailing a client's business requirements, a creative or project letter, meeting notes, a well-crafted site or workflow map, or even napkin notes with instructions. Either way, you need an understanding of what you're trying to create for a user, what the connections are, and a general understanding of the limitations and expectations of the technology. Note See Chapters 4 and 5 for more information on defining business requirements. For tips on effective meeting minutes, see the additional online chapter "A Quick Guide to Meetings" at www.projectuxd.com.

Once you've gathered the necessary information, taken the time to read all the requirements carefully, ask questions, and review the answers for clarity, you're ready to start building your cables!

Tools in the Box The Tools in the Box section of Chapter 10 listed the many design tools you can use to create sitemaps and workflows. The good news is that you can basically use the same apps for cables and annotations. The bad news is that if this is your first experience creating wireframes, you might feel a bit lost about where to start. But wait, there's more good news. Almost all seasoned UX professionals start with pen and paper, so you shouldn't feel like you have to pick a tech solution right away (although you may well need to translate from sketch to digital pretty quickly). Leah Buley, Experience Designer at Adaptive Path, emphasizes the importance of using pen and paper (just like writers) in her presentation "How to Be a UX Team of One." Leah says: When you start sketching ideas for a wireframe, it often happens: you have one or two good ideas and then you hit a wall. These ideas probably come from something you've seen and liked or something you've designed in the past. This is not an end point. It is a good starting point.



The mind tends to focus on what is known, but the familiar may not always be the best solution to the problem. When you force yourself to search for more varied ideas, often with idea 4 or 5, you have come up with something new and interesting. I don't know why it happens like this. It just does. Templates can be helpful in guiding yourself through this process. In Adaptive Path we use a template of six, which simply provides space to make six small thumbnail sketches. The number of sketches is not that important. The important thing is to force yourself to go beyond the first obvious ideas. Six is ​​(for me) a magic number because the template six above, with its six little squares, encourages me to continue until all the thumbnails are filled.

Afbeelding 11.1 Adaptive Path six-person model

These are good words to live by, especially if you're just getting started with the work you're doing in the world of UX design. As time goes on, you'll find an approach that works best for you, but there isn't much better advice than Leah's. To learn more about his approach, the full "How to Be a UX Team of One" presentation is available online at www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one. Don't be afraid to start with pencil and paper, but make sure you have plenty of erasers with you. Mistakes are part of the process, and even after you've done a pencil sketch, you should expect to make adjustments as you go digital.



Few professions are as frequently and consistently iterative as UX designers. Very rarely, if ever, is the design accepted on the first pass, and sometimes you can only hope to make a "mistake in the right direction". So start small: take a single page or a small portion of a project section, review it first with your internal team and then with your client team to make sure you're on the right track. Aligning your plans up front with how the customer feels about your business goals saves you a lot of work down the road. The same approach can be applied to user design testing: look for validation early!

Start Simple: Design a Basic Wireframe This section shows you how to create a wireframe at a very basic level. It often starts with nothing more than a simple sitemap and a few additional requirements, but this will help you create a structure for a website's home page. Remember the basic sitemap from Chapter 10, which showed how to structure a very simple website? Figure 11.2 shows an update: as you can see, some degree of navigation hierarchy appears. Any X.0 page identified is likely to be a master page or parent page. You can use this as a starting point to define some business requirements and a lead. 1.0

1.0.1 Terms and Conditions

At home

blog 2.0 – 2.x

3.0 Related

4.0 Work

5.0 Communication

Figure 11.2 Sitemap for a basic website with blogging functionality



Getting started It's not uncommon to author your own business requirements document, and this can be both a blessing and a curse. If you are the writer of the requirements, you essentially only have yourself, or your customer, with whom to discuss the meaning of something vague or relatively undefined. It can often feel like you're making it up as you go along, but don't let that discourage you. In many cases, your potential customers will help you identify gaps in the information you work with. This can help you create the best solution, ultimately. Remember, UX professionals work to suggest the best possible solution for users, and early versions of any project will always be used to solicit feedback and influence the next design iteration. Your design doesn't have to be perfect, but you want to make sure it looks clean and professional, and at worst, you're headed in the right direction. The requirements for the design of this home page are limited and very brief. Fortunately, the sitemap in Figure 11-2 provides enough information to configure the navigation that can be used for the website: The home page (numbered 1.0) is the top level of navigation. Conditions

&Terms (1.0.1) is probably a generic footer element, or at least it shouldn't be considered part of the main navigation. The other main navigation items are About (3.0), Work (4.0), Contact

tact (5.0) and Blog (2.0–2.x), which displays as a stack of pages to ensure it looks like multiple dynamic pages and allows for a "previous" and "next" navigation layout. These main navigation elements give you enough information to get started, but not enough to effectively create a home page for a website. So, to advise, the client provided additional information: The company is a boutique UX design company that has gained visibility through its blogs and the variety of projects it has worked on. It is important that website visitors can quickly learn what the business/website is about through limited text and strong, evocative images that work in conjunction with user experience design. Also, it's important that the navigation is clear (I prefer a reusable header and footer if possible) and



that our latest blog posts include a call to action so that visitors can quickly read a summary of our latest take on current issues in the world of user experience. If possible, it would be nice to be able to highlight recent work on the home page, but this is secondary as much of our work is often in progress or held in strict confidence.

Wireframes and Annotations There are several ways to interpret these requirements, and the initial presentation of the wireframe to the customer might look very similar to Figure 11-3. WIRE FRAME WITH COMMENTS Home Comments 1

emblem 2

At home


the blog


We work


about plugins



1 logo image. The logo acts as a link to the home page

the Site from anywhere within the Site. 2 Home navigation. Must link to the home page of the website

from anywhere within the site. 3 Blog browsing. You must link to the landing page of the blog from every page

location within the site. 4 · Our Labor Navigation. · It must link to the landing page of Our Work

from anywhere within the site. 5 · About Us Navigation. Must link to About Us landing page 6 7

7 8 9 10 11

welcome title goes here


Lorem Ipsum Pain Sit Amet, Consectetuer Adipiscing Elite, Sed Diam Nonummy Nibh Euismod Tincidunt Out Laoreet 9 Pain Magna Aliquam Erat Volutpat.




Lorem ipsum pain sit amet, consectetuer adipiscing elite, 15 sed diam nonummy nibh euismod tincidunt out laoreet pain magna aliquam erat volutpat.




Zoals ik heb gezien, zal ik tot het minimo komen, wat niet de fysieke bestraffing van de spelers zoals sommigen van hen sverkeitt. Lorem ipsum dolor sit amet, consectetuer adipiscing elite, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

I feel a lot of the pain, consectetuer adipiscing 12

13 More > 17

article number


15 16 17 18 19

© User Glue | Terms and Conditions | Contact


Zoals ik heb gezien, zal ik tot het minimo komen, wat niet de fysieke bestraffing van de spelers zoals sommigen van hen sverkeitt. Lorem ipsum dolor sit amet, consectetuer adipiscing elite, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. But


from anywhere within the site. · Contact navigation. · You must link to the contact page from anywhere on the site. · Rotating hero icons. Rotate images through multiple images that are aesthetically pleasing and consistent with the brand. · Welcome title. · Title for the general description text of the site. · Welcome content. · Overview of the site's content. · · Title · Title of the random example shown from the portfolio of work. · Image link. · Image of the random example shown from the portfolio of work. You must be logged in to view the details of the random portfolio sample displayed. · Resume. · Brief text summary of the random example shown from the portfolio of work (maximum 1-2 lines of text recommended). · More link. · You must be logged in to see the details of the random portfolio sample. · · Qualification. · Title of the most recent live blog post. · · Insert content. · The first 200 characters of the most recent live blog post. · More link. · You must be logged in to view the full blog post or the latest live blog post. Copyright Content. · Copyright and current year along with company name. · Terms · Link and · Terms · You must link to the Terms · and · Terms page from anywhere on the site. · Contact link. · You must link to the contact page from anywhere on the site.

8 Welcome title. · Title for the general description text of the site. 9 Welcome content. · Overview of the site's content. 10 · · Title · Title of the random sample

displayed from the task bundle. 11 Image link. Random Image

nt blog title>


Cuando llegue, conciba un incident de 15 ummy nibh Euismod aliquam erat volutpat.


I'll let you know who we are.



15 16 17 18

comment 19

Example shown from portfolio of work. You must be logged in to view the details of the random portfolio sample displayed. · Resume. · Brief text summary of the random example shown from the portfolio of work (maximum 1-2 lines of text recommended). · More link. · You must be logged in to see the details of the random portfolio sample. · · Qualification. · Title of the most recent live blog post. · · Insert content. · The first 200 characters of the most recent live blog post. · More link. · You must be logged in to view the full blog post or the latest live blog post. Copyright Content. · Copyright and current year along with company name. · Terms · Link and · Terms · You must link to the Terms · and · Terms page from anywhere on the site. · Contact link. · You must link to the contact page from anywhere on the site.

Figure 11.3 Annotated Wireframes Submitted for Home Page Layout



The annotated schema describes each element of the page, as well as the expected action calls and the results of the action (such as loading a specific page). This particular example works very well due to the limited number of elements and the limited amount of detail required.

Figure 11.4 Design of an active home page for www.userglue.com

As Figure 11-4 shows, the current version of this home page differs slightly from the original layout in Figure 11-3. For example, because time and content became issues, the Portfolio Samples section was removed. Also note the difference in naming conventions for navigation and call to action: the wireframe served as a guide, not the last word. Your end result will also often include a variety of minor changes and updates compared to your wireframe content.



An Exercise: Design a Wireframe Home Page You've seen an example, now it's time to dive in and create your own wireframe. Your mission is to redesign the home page of Global Cruises, a fictional international cruise line. Global Cruises wants its home page to be more effective as a sales tool and information source for returning guests, who often appear to be those who have already booked a cruise and are interested in learning more about other offers and extras, updates on travel conditions, etc. The exercise is to use the requirements below to create an annotated home page wireframe in the document or in a separate document (your choice). Nothing else.

Prerequisites The most important requirement that you must have is that the global header and footer (Figure 11.5) remain the same, absolutely unchanged. GLOBAL HEADER Destinations with logo

Current travel experience with the campaign logo

plan a trip

look for

for your trip

world cruises




My world cruises

Welcome back,N (of?) | XX days until your next cruise – Manage Booking | ReserveTravel extras| Online Billing

PIE PIE GLOBAL Sign up for emails from Global Cruises | Not From? Click Here About Global Cruises | Contact us | FAQ | Find a travel agency | Sitemap | Legal Information | Price conditions | Privacy Policy © Global Cruises

Figure 11.5 Existing Global Cruise Global Header and Footer

The header/navigation should be Destinations | your travel experience | Plan a trip | For your trip | Global Cruise VIP Club | Offers | My Global Cruises Welcome back(No?) XX days until your trip | Reservation management | Book travel extras | Online Billing



Footer should be Sign up for emails from Global Cruises About Global Cruises | Contact us | FAQ | Find a travel agency | Sitemap | Legal Information | Price conditions | Privacy Policy Copyright Information In addition, the site should have the ability to display multiple promotions Ability to display headlines/news CTA for customer service CTA for Travel Agent Finder CTA for exploring popular routes

The "nice ones" are Ability to display newer, most popular and/or discounted routes Ability to display geographic locations and travel points Ability to view your route of travel, if you are logged in (MY ITINERARY) Ability to view upsell items , p. as additional stops (for example, if you go

in Hawaii, book an island tour), onboard dining experiences, etc. Anything else you can think of to add that might be helpful for

World Cruises And now the work begins. Start designing your cable, and don't forget to respond accordingly! When you've completed your outline, turn to the next page to see examples of other featured professionals who received the same set of requirements.



The Results: Designing a Wireframe for the Home Page Will Evans, a User Experience Architect at Semantic Foundry (www.semanticfoundry.com), kindly created wireframes based on the requirements of the Global Cruise exercise. He compares his own work with his designs in Figures 11-6 and 11-7 to see how his approach compares with yours. Here is an explanation of how he put together the wireframe and his annotations. 990px ​​wide travel alerts









new itineraries



annotated notes

popular routes

11 1


| travel experience


plan a trip


for your trip


Global Cruises VIP Club

Welcome back, W iMMŔLog out







route view | My world

15 days until your next cruise -

9,0 13


Travel Alerts: Connect via


Merk/Logo Links Home


Search with predictive suggestion User-defined scenario 3.X



New routes with link dropdown menu: show Itinerary with link to section 4.x Popular routes: dropdown menu with the 5 most popular routes Destination link: goes to section X.0


Travel Experience Link: Goes to section X.0


Schedule a travel link: goes to section X.0


Before your trip Link: go to section X.0


Global Cruises VIP Club Link: Goes to section X.0 Specials Link: Goes to section X.0

my world 12




Media/flash/hedonic image


Hero Shot Title 17 Global Headlines | Create your own Starring


Need help planning your cruise?



Header Consectetut Adipisicing Clarity is the very string of the Body or the pain in the rebuke in the pleasure will be it in the pain of e.e.





Section Consequence Adipiscism

Section Consequence Adipiscism

Don't get angry in pain in rebuke in pleasure that wants to be a hair of pain in the hope that there is no breeding ground.

Don't get angry in pain in rebuke in pleasure that wants to be a hair of pain in the hope that there is no breeding ground.

Heading idea number 1

Heading idea number 1

main idea number 3

Heading idea number 2

Heading idea number 2

Headline idea number 4

Clarity is the reins of the Lord himself, or the anger of pain in rebuke, in the pleasure that wants to be a feather in pain

main idea number 3


October 8, 2008 18:46

brand promotion

But so that you can see where all this inborn error of those who censure pleasure and praise pain comes from, I will open the whole matter, and the same things that this inventor

post yours

I am very sorry for the loss of the nonummy lorenzino connector. Sometimes the common man sees, that's where he makes a mistake.

25 Sign up to receive emails from around the world.

Do not give? Click here

My Global Cruises Link – Goes to section X.0 Logout Link – Logs out user


See itinerary link: go to "My Worlds/See My Itineraries" page. My global link: goes to the custom Carousel page of deals/packages images


Moment Starring You Crowdsource Link


Book deals link linked to the image in the Big Hero photo.


Need help planning your cruise?


CT Promotional Offers as/Partner


Starring Your Moments Invitation, Member Profile Post your Starring Your Moments link on the crowdsourcing page.


But so that you can see where all this inborn error of those who censure pleasure and praise pain comes from, I will open the whole matter and explain to you precisely the things that that discoverer of truth said and, as it were, the architect of a happy life. .











Moments starring you

Then book this Special Package

Your Moment Now! Go


Sign up to receive emails


change country link


Global footer links


About Global Cruises | Brochure | FAQ | Find a travel agency | Sitemap | Legal Information | Price conditions | Privacy Policy

Page 2

Figure 11.6 Global Cruises homepage wireframe by Will Evans



990px ​​wide travel alerts










new itineraries


OK, Will "Bahamas" | Travel experience | to plan a trip about us| found for your trip


annotated notes

Popular Routes 1

Global Cruise VIP Club 6.0




Cruise Deals

Welcome back, W iMMŔLog out


$ 279

bahamas and florida

$ 279

bahamas and florida

$ 279

bahamas and florida

$ 279

bahamas and florida

charleston free port

charleston free port

15 days until your next cruise -

7 nights

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston


Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston


Media/flash/hedonic image

Filter global headlines | Create your own protagonist Need help planning your cruise

charleston free port

charleston free port

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston



Quick Tip: Saved Results Show a Matching String


Cruise Billet with the following metadata: 1. Price 2. Average Rating 3. Title: Cruise Title 4. Duration 5. Ports of Call 6. Details Link 7. Book This Cruise Link 8. Remembered/Favorite Cruise


Faceted Navigation allows the user to dynamically change port, voyage month, ship or price range and dynamically sort/filter the corresponding result set. Any of these can be reversed once the user sees the full results on the search results screen


After the user adjusts the predictive search filters, they can click to view all search results which will use Ajax to load the full results into a JavaScript table for quick sorting.


Starring Your Moments Invitation, Member Profile Post your Starring Your Moments link on the crowdsourcing page.


Title for Shot FridayHero Saturday

Then book this Special Package


-All boat offers/news

$190 a $1650

It will follow Cephala Adipisisik Duis, or pain will be rejected in pleasure, it will be a hair of pain, and there will be no birth.

Clarity is the reins of the Lord himself, or the anger of pain in rebuke, in the pleasure that wants to be a feather in pain

Moments starring you



Clarity is the reins of the Lord himself, or the anger of pain in rebuke, in the pleasure that wants to be a feather in pain

New itineraries dropdown with link: show itinerary with link to section 4.x Popular Itineraries: dropdown with 5 most popular itineraries




-Each month -


Section Consequence Adipiscism

Search with predictive suggestion User-defined scenario 3.X



Your You Y Moment results now! Go


Merk/Logo Links Home


Friday Saturday 7 Nights

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston

Base Port/City: Promotion/News Washington, D.C. 8.0


route view | My world

Friday Saturday 7 Nights

Travel Alerts: Connect via



Friday Saturday 7 Nights


My world

HEDONIC IMAGE 9.0 See all search results

It will follow Cephala Adipisisik Duis, or pain will be rejected in pleasure, it will be a hair of pain, and there will be no birth.

Heading idea number 1

Heading idea number 1

main idea number 3

Heading idea number 2

Heading idea number 2

Headline idea number 4

main idea number 3


October 8, 2008 18:46

brand promotion

But so that you can see where all this innate error of those who censure pleasure and exalt pain comes from, I will open the whole matter and explain exactly the things that that discoverer of the truth said, and, as you say, the architect of a happy life . But so that you can see where all this inborn error of those who censure pleasure and praise pain comes from, I will open the whole matter, and the same things that this inventor

post yours

11 1 12

Sign up to receive emails


change country link


Global footer links

I am very sorry for the loss of the nonummy lorenzino connector. Sometimes the common man sees, that's where he makes a mistake.

13 12

Sign up to receive emails from around the world.

Do not give? Click here


About Global Cruises | Brochure | FAQ | Find a travel agency | Sitemap | Legal Information | Price conditions | Privacy Policy

Page 3

Figure 11.7 Will Evans Global Cruises home page wireframe with search enabled

Wireframing in the words of Will For me, wireframing acts as a form of "thinking tool" to shape and explore a particular problem space; in this example, the home page of a cruise line. Designing using wireframes is a search in a troubled space for alternatives. it's as much a problem-setting process as it is a problem-solving process, which means I always start from the context. In this case, the general public wants to easily find the best cruise, at the right time and at the right price. To keep it simple, I choose my primary audience and the one activity that allows them to solve a goal quickly, effortlessly, and elegantly. By pulling a few cords, I am able to explore alternatives and ideas both impossible and conceivable are presented, tested, and in many cases rejected. I already knew that I wanted to design the best cruise line search interface possible, and I wanted this activity to be central to the design. Here I outlined the idea of ​​offering instantly recommended cruises, even before the user commits to searching.



a full screen of search results. I wanted the user to start a conversation and get involved in the search for a great cruise ship. FIND CRUISES


Ok, Will for the "Bahamas" we found


18 cruise deals

$ 279

bahamas and florida

$ 279

bahamas and florida

$ 279

bahamas and florida

$ 279

bahamas and florida

charleston free port

charleston free port

charleston free port

charleston free port

7 nights

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston


7 nights

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston





Friday Saturday 7 Nights

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston


Friday Saturday 7 Nights

Great Stirrup Cay (ons private-eiland) Canaveral Harbor Charleston


Friday Saturday


Friday Saturday

Filter your results J Port/City: Month:



-Each month -


-Any ship

$190 a $1650

See all search results

Figure 11.8 Will Evans home page contains cruise search results

In the case of the cruise line, I described the header, footer, static content, and the need to block out areas in the design for content modules like CTAs and promotions. I share the output of this phase with key stakeholders, but also involve the visual designer and development lead, as well as QA, so they can contribute to the process, come up with more ideas, and spot obstacles and limitations. Ultimately, as a designer, I had to make the decision to implement the design in the specs. I created two or three candidates for final consideration and, through the use of annotations, allowed the wireframe to make its case for stakeholders and targeted reviewers. The cables you see in Figures 11.6 and 11.7 are now at this stage, where design changes are minor and details are being polished.



Compare and Contrast It is important to note that the example in Figure 11-3 and the work of Will Evans are quite similar but different styles of thread construction. Now it's easy to look at both and proudly announce, "Those are cables!" Both have elements of their own style and approach, but the core is very similar. The examples in this chapter are a good starting point for finding the style of wireframing that best suits your needs.

La foto se reunió con Dank aan Maciej Piwowarczyk

Visual design: when wireframes grow and find their way into the world

Figure 11.9 Visual design of the Global Cruises home page by Mark Brooks



Based on Will Evans' requirements and wireframe, Mark Brooks (www .markpbrooks.com) created a home page design for the fictional Global Cruise Lines. As he reviews the visual layout in Figure 11-9, he notices how the layout and content of the page have been taken into account. Once the design is in process and development, the interaction models begin to come to life.

Design Exercise Follow Up: Which Design Is Right? There is no right or wrong design as long as the requirements are met. Sometimes you feel compelled to create multiple wireframes for one page to explore different approaches, work out the details, and present them to your potential users, teammates, and possibly clients. This is perfectly acceptable. Remember that this is a repetition exercise. The work you submit to a client is almost always guaranteed not to be deemed "correct" or "complete" on the first try. Typically, you'll find yourself working through at least one round of iterations and updates. Unfortunately this can sometimes stretch out over multiple rounds, but that is the nature of projects and should ultimately lead to less scouting for your downstream partners. When comparing your wireframe and annotations to the two examples provided, note the difference in approach and style of presentation. Compare them with the example on the home page earlier in the chapter and with the work you have done. Find the similarities and differences and create the approach that works best for you, unless there is already a pattern set for you. In many cases, the hardest part of making a cable is getting pencil to paper for the first time. Take Leah Buley's advice and start sketching out lots of ideas: doodle and draw, explore different approaches, and test your designs with peers, peers, and family members until you're sure you can make a case for your design (without getting defensive). ) and you will find yourself moving in the right direction.



One final note on wireframing presentations Once you start creating wireframes and become familiar with the work product, and understand how valuable they are to your workflow, it's easy to forget that not everyone understands the amount of thought and time that goes into creating wireframes. is needed to create. them. Clients and co-workers are often exposed to cables of a completely different level of quality and complexity, or with a different annotation style. In fact, many of your partners and customers may never have seen a wireframe (even if they say they have). It's also not uncommon for clients and business partners to get confused about the differences between sitemaps and wireframes, and the purpose of each. In other words, your first schematic could potentially be your client's first schematic! Therefore, it is very important to accurately form the basis of what you are going to present. Before presenting the cables, clearly explain what they are, how they will look in comparison to a final visual design, and what their purpose is. Here are some additional tips for filing cases: If possible, involve your client's team in discovery. try to catch them

actively participate in drawing on a blackboard. Explain that they contribute to the framing process and that the end result will be similar but will be produced electronically. It is very important to explain that this is an activity that will result in cables that may look completely different when you explore the design options. Find powerful metaphors to convey the differences between your cables

frameworks and the final design of the project. A popular metaphor is "Wireframes are to apps/websites what blueprints/blueprints are to a house." Wireframes make changes easier and more efficient to implement, and at a stage where changes are generally less expensive (before build teams get involved and groundwork is laid). Tell your meeting participants that wireframes are not final representations

the graphic treatment of the website. Threads are presented to consider content, overall layout, and interaction.



page elements. Once the cables have been approved, construction can begin. (Oh, and subtle changes can still happen!) Ask your visual designers, if they have the time and budget, to provide

Design mockups to show the differences between your wiring and a final design. If possible, show the client examples from other projects that show how the cables and the final design are similar and different at the same time. Explain how other members of your project team will use the cable

Wireframes – It never hurts for a client to understand the importance of reviewing and passing this milestone, and how the wireframes inform the rest of the project. Once your clients and partners begin to understand and appreciate the value of wireframes and where they are in the design process, it will be easier to move your projects forward. Because; Because cables help create visual clarity and direction in the rest of the project. In many cases, partners and clients can even promote the utility of the schemes on your behalf. This allows you to spend more time designing the user experience and less time selling it!




Prototyping Brings (More or Less) Life to Your Designs Prototyping is an effective way to test and validate proposed designs and features before investing in development. You can use a variety of prototyping tools and approaches, from quick and dirty (but we prefer quick and clean) to interactive and robust. The method you use is largely determined by two factors: the time and materials you have available to spend prototyping. Russ Unger and Jono Kane


What is prototyping? In the context of user experience design, prototyping is the act (and in many cases the art) of creating and testing all or part of an app's or website's functionality with users. Prototypes can be created using analog tools (such as whiteboards or pen and paper) or digitally using PowerPoint, Acrobat, Visio, OmniGraffle, HTML, or other technology-based tools. Prototyping can be an iterative process, as prototypes are typically built to identify or validate user experience issues. Once you've collected feedback, you can make changes to the prototype for further testing. In other cases, a successful (reasonable) prototype can move a project through other stages of the development life cycle. Remember that prototyping is a process, not an artifact. You could eventually create screens and (sometimes fake) functionality that you call a prototype, but that's part of prototyping, not the end result. The result of the prototyping process is active feedback of concepts that can be used to refine and improve the design. However, this chapter only focuses on prototyping and leaves testing details for Chapter 13.

How original do I need? Any user experience design process must include some degree of prototyping: formal or informal, interactive or static. No need to create prototypes for an entire website or app. In fact, prototyping can be very efficient if only a representative sample of a system is used; in other words, you don't need to simulate the whole system, just the most important parts. In most cases, you want to test a handful of concepts, and your prototype should include those concepts and more. You can create a prototype using a number of available methods: whiteboard, pencil and paper sketches, storyboards, cardboard cutouts, etc. Additionally, there are several digital tools available that allow you to create interactive prototypes and engage your test users in a more realistic environment.



Which prototyping method you choose depends largely on the time and materials you have available. Here are some of the more popular methods available to meet many of your prototyping needs.

Paper Prototyping Few activities can take you back to your early years quite like the hands-on, art, and craft of paper prototyping. The only tools needed are pencils and pens, paper, scissors, and whatever else you can pick up in the art department or buy at a local stationery store. Paper prototyping is flexible. As long as you have a draft or more materials, you can create as many scenarios as you need. You can also quickly review from one test to the next, meaning if a potential user sees an obvious flaw in something you've built, it's not a complicated process to update the design before showing it to the next potential user. It's also cheap. Aside from the time spent prototyping on paper, you can usually create any script for much less than the cost of a few elite lattes. Paper, post-it notes, index cards, pencils, and the like should already be on hand, and if they're not, you won't break the bank by stocking up. The process is simple: design the part of the functionality that you want to test. Introduce functionality to users. Document the comments (it's paper, so turn the original over and start writing). Then move on to the next user or make updates and start over. Simple. Pleasure. Effective. Paper prototyping is used early in the process and can help identify design-related issues before major investments are made. Changes at this stage can be made quickly and efficiently, reducing risk. This allows you to effectively make changes before investing too much in the design. Each tab in Figure 12-1 was drawn with three different colored sheets of paper as it would appear on the website and stacked on top of each other. The Global Now tab has been moved to the top to display its content as if the user had just visited the home page for the first time. Each tab displays the navigation available to users and allows them to select a different view option.



Figure 12.1 Paper model of a tab-based vertical navigation

Figure 12.2 Paper template of a vertical tabbed navigation with the My Itinerary tab enabled

When a user selects a different tab, that specific tab is moved to the front of the stack to display the most recently active tab view of the content area, like the My Itinerary tab in Figure 12.2. Paper prototyping is about as cheap as you can get and can be as simple as the exercise above. When you start exploring complete systems, the hours invested can become significant (although your material costs increase only slightly). If you need to change the main navigation on a hundred original paper pages, this method becomes expensive. While paper prototyping is essentially cheap, it doesn't scale well for reuse when parts need updating. At this point, you should consider whether switching to digital tools would be more beneficial.

Digital Prototyping If your prototyping needs are larger than paper can handle, a technology-based solution may work better for you and your audience. With these tools, you can show exactly how interactive parts of your website or app look to users. Digital prototyping builds on many other aspects of the design process. You can reference their faces when rendering or testing your digital prototype, their threads to visually lock and render the prototype, and visual design elements (if available at this point in the process) for a realistic fit and finish on your prototype.

Wireframe vs. Realistic Prototyping As with paper prototyping methods, mileage can vary with digital prototyping. Depending on the tools, resources and skills you have at your disposal



rejection and the requirements you face, making your prototype look like wires may be good enough for your project. In fact, it may be preferable. Wireframes can show the public that the project is still in progress and not the final site ready for production. On the other hand, as you test the design with users, you will sometimes find that the most important aspect of the prototype is how realistically it represents the final system. The result of your digital prototype is based on three factors: What is your timeline like?

Do you have time to assemble a team and build a great near-production prototype that shows the users sitting in front of it a crystal clear view of the production-ready location? Do you have a few hours to export your wireframes as HTML or create a very simple Flash project to show just the page flow and basic interactive elements within the project? Both types of digital prototypes can be very useful. But as with any real project with a deadline, it's important to set expectations based on the time and materials available. Who are you building this prototype for and why?

It is critical to the success of your prototype that you know what you are doing with it before you go too deep into the project. Are you building a prototype to test the design with users? If so, what is important to consider before the test? Does it matter if the prototype is a black and white wireframe or if it should look like a live website? Test the ability to find buttons and links? Are you prototyping a business pitch for adoption by a group of executives, managers, investors, or others who can sign your check at the end of the day? If so, what are you trying to communicate to them? What should be functional and what should just look functional? These questions can help determine the requirements for your digital prototype.



What kind of resources, tools and skills do you have at your disposal?

If you're not an HTML or Flash expert and don't have the budget to hire someone who is, you can create a highly functional prototype using a simple presentation tool like PowerPoint or Keynote, or a wiring tool like Visio or OmniGraffle. Even a simple PDF can do it.

HTML editors vs. WYSIWYG HTML is the digital equivalent of a paper prototype. It's (sometimes) free and (somewhat) easy. If you're not an HTML wizard or front-end code expert, you can still be an HTML prototyping wizard with some basic HTML knowledge. Basically, there are two ways to create an HTML prototype: by hand coding the HTML or by using a WYSIWYG editor such as Adobe Dreamweaver, Realmac's RapidWeaver, or Microsoft Visual Studio. These tools have a code view and a design view that allow you to visualize your coding efforts without opening a browser. Prototyping with a WYSIWYG Editor The beauty of using Design view in a WYSIWYG HTML editor is that you can create a page layout with about the same effort as it would take to format a page in Microsoft PowerPoint, Apple Keynote, or any other web application. Basic layout (more on that later). And it's just as easy to add interactivity, such as links, mouse events, etc. One of the most impressive aspects of Dreamweaver CS4 (Figure 12-3) is that it features what Adobe calls Live View, which is based on the open source WebKit rendering engine. What does this mean? It just means that what you see in Live View is exactly what you get in Apple's Chrome and Google's Safari browsers, assuming you've been meticulous with your prototype details. Dreamweaver CS4 is a very powerful prototyping tool, especially when combined with Adobe Fireworks CS4.



Figure 12.3 A simple example of a prototype created in Dreamweaver CS4

Creating a Simple HTML Prototype Possibly the cheapest way to create a simple, quick and dirty HTML prototype is to do it "by hand": manually writing the code in a text editor. One of the most common reasons for transitioning from a wireframe design to a prototype is the requirement to render or test the flow and navigation of the proposed site. By taking blocks of elements or even entire pages of your wireframe (or layout model) and setting them up as clickable images in your HTML prototype, you can create a working prototype very quickly and easily. A very simple prototype that allows you to click full page images in a browser and then load different pages is pretty straightforward. In the exercise below, you should have a home page and search results wireframe available, or you can download sample images from www.projectuxd.com. Note Typos are the most common errors in HTML coding, so be very careful about typing accuracy.



1. Export your homepage wireframe from your favorite tool (such as Visio or OmniGraffle) or a rough layout from your visual design tool. You should save the entire page as a GIF image called homepage.gif. create a new folder called Prototype and save the homepage.gif file there. Note The JPEG format works well for raster and photo-like images. GIF works best for threads and line art.

2. In your WYSIWYG HTML editor or a simple text editor like Notepad (Windows) or TextEdit (Mac), create a new document and save it as homepage.html in the same Prototype folder. If you use TextEdit, be sure to select HTML as the file format. 3. In your new document, insert the following HTML code: 1]iba3 1]ZVY3


1$]ZVY3 1WdYn3 1$WdYn3 1$]iba3

4. Save the document, and then open the file in your web browser. You should see a blank page, but pay attention to the title bar in the browser. It should say "Start". 5. In your text editor, change the homepage.html code. Between the and tags, enter the following HTML code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

This code turns the entire homepage.gif image into a clickable button that loads the searchresults.html page (which you must create to see if the functionality works correctly). 6. Save your document and reload the page in your browser. You should see the new home page you just created in your browser in all its glory (Figure 12-4). When you click on the image in the browser, the browser tries to load the searchresults.html page (which doesn't exist yet).



7. Repeat step 1 for the wireframe content of the search results. Save this page as a GIF image, name it searchresults.gif, and save it in the Prototype folder. Save a new copy of the current homepage.html document as searchresults.html. Select "Save As" for the current page "homepage.html" and save it as "searchresults.html". Then update your HTML to reflect this and link back to the homepage (homepage.html). You should replace this line of code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

Tipo: 1V]gZ[2]dbZeV\Z#]iba31^b\hgX2hZVgX]gZhjaih#\^[WdgYZg2%31$V3

8. Once this page is created, you will have a very simple HTML prototype that shows how two pages can be linked to each other.

Figure 12.4 Prototype HTML home page as seen in a web browser



Code Analysis Now that you've created a basic prototype with a very limited amount of HTML, let's take a look at the code or HTML tags you used to better understand what you just did. The HTML, head and title tags 1]iba3 1]ZVY3



are basic tags required in any HTML document. The most important thing to note here is the title tag, which allows you to specify the name of the page. An image tag 1^b\hgX2]dbZeV\Z#\^[3

it is also a simple tag; it's all you need to view an image in a browser. Anchor tags, like this, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

they are used to set up links in your HTML document. For simplicity, the example anchor tag uses a relative path - "relative" because the tutorial is in the same folder. An absolute path looks like this: 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

While this HTML isn't stylized or standards-compliant (don't show it to a developer, they may be asked to give you a hard lesson in coding development!), it's more than enough to show off your prototype. to a program. . Remember, this prototype doesn't have to be perfect – the goal is simply to get your ideas across to your audience. This simple layout example created linked HTML files that allow for page-to-page navigation, but what if you want more detail with the clickable parts of the layout? The answer: image maps. Imagemaps allow you to define parts of an image to link to and display different pages when clicked. The easiest way to create image maps is to use a WYSIWYG tool like Dreamweaver to map parts of a linkable image without any real knowledge of creating HTML code. For more information on creating image maps, see How do I create an image map?



my web page' by Dave Taylor at: www.askdavetaylor.com/how_do_i_create_an_image_map_for_my_web_page.html. HTML prototyping is just one approach to digital prototyping. Many different frameworks and dynamic coding languages ​​can be used to create very powerful prototypes that meet almost any need. If HTML prototyping is an area you want to explore and expand, you may want to look into tutorials and other resources to go deeper into this area. To get started, you might want to investigate JavaScript, PHP (or other dynamic programming languages), jQuery (http://jquery.com), or Yahoo! Interface Library (http://developer.yahoo.com/yu). Note For a more in-depth exploration of HTML, see HTML Dog: The Best-Practice Guide to XHTML and CSS, by Patrick Griffiths (New Riders, 2006).

Additional Prototyping Tools You've now explored practical options that can help you prototype in both the analog and digital space. In addition to these methods, there are a number of other software tools you can use for prototyping, ranging from simply "getting the job done" to tools that are more robust and full of interaction and intelligence. The list below is far from complete, but it does give you a variety of options to create the right prototype for your situation. PowerPoint and Keynote A PowerPoint or Keynote template falls under the "quick and dirty" category, and sometimes that's all you need. You can create your PowerPoint or Keynote prototype as if you were making a basic presentation, with simple interactions. Both tools allow you to create interactions to simulate clicking on a flow that you want to validate with your users. If you're an advanced PowerPoint or Keynote user, you can include animations and other elements to make your prototype a bit more interactive. Adobe Acrobat PDF Exporting wireframes or visual design elements as a multi-page PDF may be all you need to show how your product would look and feel in a linear page-by-page format. Remember that many applications use 214


export to PDF, and if you're on a Mac, you can select Print to PDF for almost any document or file in any application that supports a print feature. Many applications, including Visio and OmniGraffle, allow you to specify access points and actions, such as connection location, for interactivity. Visio and OmniGraffle Both Microsoft Visio and Omni Group's OmniGraffle are well-known tools for creating wireframes. Both allow you to create prototypes with clicks through their ability to export to HTML and PDF formats. In OmniGraffle, you can easily assign actions and specify a jump point to a PDF or URL when exporting as HTML. Visio has prototyping kits available for download on the web that allow you to easily export to HTML or PDF with clickable areas to navigate from page to page. Visio and OmniGraffle can also export popular raster and vector formats, such as EPS, GIF, and JPEG, so you can easily import your images into Flash, use them as images for HTML prototypes, and more. Axure RP The "RP" in Axure RP stands for rapid prototyping, which makes the tool popular with many UX designers. The tool offers similar design capabilities to Visio and OmniGraffle, but adds a relatively easy-to-learn toolset that lets you create a variety of navigation styles, forms, popups, and other standard page-based interactivity. In addition, the flexible integration of specifications, comments, commands, and progress indicators allows you to produce document-based specifications directly from the prototype. However, Axure is a Windows-only tool, which can be challenging if you're working on a Mac and don't use apps that let you start Windows. Fireworks CS4 Adobe's Fireworks CS4 has become more popular recently as a tool for creating everything from wireframes to visual designs. It has a standard set of Windows and Mac form elements and controls that allow for simply defined interactions that can emphasize functionality without the need for an outside developer. The shared library stores assets that can be added and shared across multiple documents for reuse



Fireworks Components also has a Pages feature that allows you to create sequences of elements that are common to all pages of a given document, similar to how developers use "Includes" or how some documentation systems allow you to create backgrounds to reuse them. on document pages. This feature is useful for identifying repetitive content areas at the page level, such as the header, footer, and navigation, while preserving unique content areas on each page. Balsamiq Mockups Balsamiq Studios Mockups is a wiring and prototyping tool that provides an experience similar to drawing wires with pencil and paper, just using a computer. A variety of pre-built common UI controls (more than 60 at the time of this writing) are available that you can drag and drop onto a screen and customize for your project. Their mockups are designed as if they were hand-painted, which lends a bit more organic feel to digitally created displays, but the digital platform allows you to quickly tweak designs for quick iterations. Prototyping with Flash and Flash Catalyst with Adobe Flash is a great way to communicate interactive concepts beyond a simple clickable prototype. Flash makes it easy to create clickable prototypes, but you can also add other interaction elements to it, such as hover or hover events, click events, videos, and animations. If you can explore Flash in more detail, it also has a basic set of user interface elements that can be programmed to respond to user interactions and display the desired effect. For a protocol for prototyping in Flash, see Alexa Andrzejeski's article "Quick and Easy Flash Prototyping" on Boxes and Arrows: www.boxesandarrows.com/view/quick-and-easy-flash. As this book was about to be published, Adobe announced a new prototyping tool called Flash Catalyst. Flash Catalyst is a development environment that interfaces with other applications in the Adobe CS4 suite and acts as a conduit between the design and development process. This allows you to export your designs in a browser-ready format with little effort. For more information, visit www. adobe. com.



Work with a developer If you have the resources, you may want to hire a developer to make a prototype based on your schematics or designs. Keep in mind that the developer needs to have a good understanding of what they are trying to achieve, so this approach may also require you to create development specifications and requirements for the process to be efficient and effective. If your prototype will be used for iterative testing, be sure to communicate which parts of the prototype you are focusing on testing and therefore need to implement changes quickly. It is recommended that you spend time with the developer during the development process and identify the key parts of the code that need to be marked (with code comments) as subject to change. Be sure to stay in touch with your developer throughout prototype development to keep the lines of communication open and ensure your results are accurate. Note For more details on various prototyping approaches, see the upcoming book, A Practitioner's Guide to Prototyping, by Todd Zaki Warfel (Rosenfeld Media, 2009 release: www.rosenfeldmedia.com/books/prototyping).

Prototyping Examples The simple and easy-to-use prototyping examples in this chapter are far from a complete set of approaches that you should use for every situation. To highlight some real-world applications of prototyping, Keith Tatum and Jon Hadden generously shared their experiences. Keith Tatum, Senior User Experience Strategist at Slingthought (www .slingthought.com), created the original article in Figure 12-5 to explain left-hand navigation links and identify navigation hierarchies and categorizations for his partners at Align Interactive (www.alignin.com). In addition, the paper prototyping process allowed him to skip the wireframe phase and move into visual design and layout (Figure 12-6).



Figure 12.5 Prototype document used to explain navigation concepts to the development team

Figure 12.6 Design of a live website based on the paper prototype

Keith leveraged his team's shared design and development knowledge to quickly create a design in two business days. This allowed the team to move quickly with development once the visual design concept was approved.

Figure 12.7 Working prototype of the calendar tool, mockup with high-fidelity XHTML, CSS, and JavaScript. courtesy of Jon Hadden



Jon Hadden (www.jonhadden.com), a senior visual designer at Yahoo, prototyped calendar functionality for a tool he creates called Project Manager. Project Manager is a web-based collaborative project management application. It started as OmniGraffle wireframes and was then built as a high-fidelity XHTML prototype to help determine if the functionality was usable and affordable. Affordability is an important point: in some cases, parts of an application or project can be tested as prototypes to see if the functionality is profitable. If the cost of building functionality becomes a concern and prototyping exceeds time and hardware expectations, you may need to assess the feasibility of your project.

What happens after prototyping? Once you've completed the prototyping process, you need to synthesize your results and turn them into something that can work. If you were prototyping on paper, you may need to start creating digital wireframes based on the feedback you've received. If you are already in digital wireframe mode, you may need to update your wireframes and move on with your project process. You may also need to use your feedback and update your prototype for another round of review. Todd Zaki Warfel, President of Messagefirst (www.messageirst.com), shared: Prototyping is a way to accomplish one or more of the following goals: Work your way through a design Create a common communication platform Sell your ideas internally (eg, for your boss, other designers, etc.) Technical feasibility testing Design concept testing with end users/customers Prototyping serves as a feedback mechanism. Prototyping allows you to determine whether to continue with one design direction or explore another before moving on to the next phases of your project.

Remember, wherever you are in the process, prototyping is only one part of the process, and like any other part, you need to know when you've reached the point of maximum efficiency and are ready to move on to the next one. phase of the user experience process. WHAT HAPPENS AFTER THE PROTOTYPE?



Test design with users beyond what you think you know and learn how they think In Chapter 6, we covered several UX design techniques that can help you understand your user groups: their needs, attitudes, and preferences regarding the topic General represented by Your site. This chapter discusses techniques for collecting user information about specific layouts or layout elements. We'll focus on exploratory techniques, which are often used early in the design phase, and usability testing, which can be used at many points in your project. First, let's talk about exploring design concepts with your users. carolina chandler


Concept Exploration Concept is generally the word used to describe an abstract idea such as happiness, cooperation, or efficiency. In the field of UX design, the term is also used to refer to design elements that are intended to represent one or more abstract ideas to the project team or a potential user. In this sense, a conceptual design element can be visual (for example, a picture of a machine showing the concept of efficiency) or it can be text-based (for example, a short collection of written sentences to express the objectives of the organization). company). . to press). focus on efficiency, with words like timely and responsive). The concept may also include exploring frameworks, visual design models, or rough prototypes intended to express the overall message on the site (see Chapter 12 for more information on prototypes). Concept exploration typically occurs early in the design process, after user groups have been defined, but before going into the details of each page or screen. Research can inspire designers and partially reduce the risk of bringing a new product to market because you can listen to (and then plan for) the kind of responses you might get from potential users.

The main objective of the concept exploration is to understand the types of reactions and ideas that arise from user groups when they encounter a variety of design elements.

Concept exploration may consist of one-on-one discussions or it may take place in a group, but it does involve some individual activities aimed at bringing together and discussing different viewpoints. The latter can be set up as a focus group, spending some time on concept testing activities, followed by a group discussion (see Chapter 6 for more on focus groups). Let's look at an example of a concept exploration conducted for a nonprofit microfinance organization.



Potential Pitfalls of Exploring Concepts Henry Ford once said, "If I had asked my customers what they wanted, they would have asked for a faster horse." While you can get great ideas by brainstorming with potential users, you don't want to rely on them to support designers. After all, the most memorable designs are often very different from those created before, and research participants may not be comfortable with a large number of changes. Participants' responses will be based on their current understanding. What you collect are responses, not predictions of what they will or will not want in the future. Also keep in mind that many other factors beyond the plan itself will influence future behavior (such as positive word of mouth). Do not ask participants to make direct choices (such as "Which concept is better, A or B?"). Instead, listen to how they use their own words to describe the concepts presented. The results should be seen as input to the design process, not as a mandate to designers. For an excellent overview of the potential pitfalls of proof-of-concept design, and recommendations for using the technique well, check out this article on the AIGA website: "Design Meets Research" by Debbie Millman and Mike Bainbridge: http://www. aiga.org/content.cfm/design-meets-research

Microfinance is the financing of very small loans for entrepreneurs in poor countries. These loans can enable borrowers to build businesses and thereby improve the lives of their families and communities. Loan funds come from people coming together to borrow or donate small amounts to cover a larger loan (for example, $25 each to finance an $800 loan needed by a shop owner in Kenya). Entrepreneurs repay the loan as the business grows. The funding model is very powerful, but the organization sometimes found it difficult to explain the concept in simple terms. In addition to the challenge of describing microfinance, the agency was also unsure how to approach reporting and design in relation to religion. This particular microfinance organization is inspired by the faith of its founders and employees. Many in the organization wanted to do that.



That inspiration was evident in the site's design, but they weren't sure how to strike the right balance: if the presentation of religious messages was too strong, it could turn off potential donors who weren't members of that faith. Too thin and the organization wouldn't really represent your values. The project's UX designers decided to explore possible ways in which images and text could be used to explain the microfinance model and showcase the organization's religious inspiration without alienating potential donors. To do this, they selected images and words that could be used to explain concepts related to the model (such as self-reliance and investment) and words that represented varying degrees of religious messages (for example, faith and spirituality). Focus groups were then designed with participants who were within the target user groups of the site. Two groups of users were included: those who reported donating as an expression of their religious beliefs and those who did not. For each group, the facilitator explained the donation model (without saying anything about religion). Each participant was then given a sheet of construction paper, a set of pictures, and a set of words to use, as well as additional blank cards to fill in their own words if they wished. They were asked to create a collage of images and words that they would use to explain the model to their friends and family. When they were done, the participants came back together to present their collages, explaining why they chose certain images and text and why they chose not to include others. Figure 13.1 shows an example of a collage created in this exercise. Figure 13.1 Example of a collage made by a participant during the proof of concept

The project team gained valuable information from these collages and from the discussion that followed. Information was included Participants avoided images depicting success in the 'Western

ern' (for example, business suits and briefcases). They wanted to improve the lives of entrepreneurs without changing their culture.



All user groups agreed that the focus of the site should be on purpose.

of the organization (providing entrepreneurs with the funds to grow and prosper) rather than the motivation behind it (religious inspiration). Participants believed that it was important for the organization to stay true to what it was, but that these messages could be provided in an area dedicated to describing the organization itself (such as an About Us section). The attitudes and interests that emerged helped the team determine the direction of the posts on the site, and provided a great example of the value of proofs of concept!

Tips for Exploring Visual Layout Templates At some point in your project, you may have templates that represent the possible layout of your website pages. If you decide to explore designs with the participants, it is best to have two or more variations available to compare and contrast. With just one, you're more likely to get the "nice" preference: people don't want to sound too critical of the mockup, because they don't want to hurt the designer's feelings. However, with two or more mockups, they will generally feel more comfortable being critical because they are more focused on comparing designs than directly criticizing them. You can give participants each design individually (on screen or on paper) and ask them a series of questions. For example, you might ask participants to look at each design for one minute and then choose at least three terms from a list that best describe the design. They could circle their choices on a 20-word sheet, such as boring, trendy, conservative, strong, confident, etc. in any order. Answers to open questions can also be collected. For example, you could give participants five blank lines to write their overall impression of the design. Some of the information you may collect includes common brand associations made by your participants:

"Pseudo Corporation is the Rolls Royce of gadget makers: looks great, but you probably can't afford it."



Lifestyle design and implementation:

“I don't think I would let my son go to this site. He is only 8 years old and these images seem very mature to him. ” Effectiveness of a particular model to explain a new concept:

"Oh I see, this site is like a marriage registry, but you sign up for charitable donations instead of dishes." Ways participants define some of the key terms you use:

"When I see the word solution on this site, I think I'll find all the products and services I need to track my shipments." Questions or concerns about using a particular set of tools

or the impact of its introduction (the following section illustrates several examples of participants' concerns). Designers can use these responses to assess whether the responses they get are in line with what they intended, or whether they may need to try a different approach. Note that participants (and project stakeholders, for that matter) often choose different elements of different designs: "I like this part of idea A, and I like this part of idea B." This is a natural reaction, but it should not be taken too literally. You don't want an unnatural fusion of two different design directions. If the visual designer thinks the popular elements work well together, then go ahead. But leave room for her to tell you that it's less "chocolate and peanut butter" than "chocolate and pickles." In general, there are no hard and fast rules for the activities that are part of proofs of concept or the types of items you can test. Instead, it's important to make sure you set the right expectations with the project team about what kind of information will emerge from testing and how that information will be used to inform design decisions without stifling creativity.

Usability Testing Usability testing is one of the most widely used methods for UX design testing. It's also better known among those who aren't UX designers, so your business stakeholders and project team may already be familiar with it. The idea itself is elegantly simple: create a set of priorities

usability test


tasks for your site, ask a few users to do them and note where they have hits and misses.

Usability Testing vs. User Acceptance Testing Some people in your organization may be under the misconception that usability testing only happens at the end of development or early development, when there is a working version of the website or app, maybe something in beta mode. This impression may also be related to the common practice of performing User Acceptance Testing (UAT) at this later date. The similarity of the names can cause confusion between the two. For applications that go through a formal QA process, UAT is one of the last stages of testing and is rarely performed by actual users. The main purpose of the UAT is usually to serve as a final verification that the application meets the functional requirements defined by the interested parties. it can also detect bugs or errors reported by participants. While UAT can highlight usability issues, it should not be relied on as the only method of capturing them in a project. Because it happens so late in the process, changes based on UAT feedback are much more expensive. It's much better to catch the important stuff earlier in the process, before too much time is spent on development. Usability testing is designed to provide better performance information earlier in the process.

The following sections discuss common steps involved in usability testing, such as Selecting an approach Designing the survey Recruiting and logistics Writing discussion guides Facilitating Analyzing and presenting results Generating proposals



Before you begin, consider the goals of your project. They help you stay focused all the time, but are especially helpful in the early stages when choosing an approach and designing the test.

Choosing an approach Research approaches are often described as either quantitative or qualitative. Quantitative research focuses on numerical data and aims to provide reliable and repeatable results with your target audience. It relies on including a large enough group of users in that group (called the sample size) so that you can take the findings from that smaller group and draw conclusions about how the user group as a whole will respond within a certain range of time. mistake. In general, it is a more scientific approach to research, with formality in the design and analysis of the tests. The focus is on evaluating the current design, especially against other iterations of the site, against the competition, or against a number of benchmarks. Doing quantitative research means engaging a larger number of participants to account for variations you'll find from person to person, such as typing speed, familiarity with similar websites, etc. Surveys are an example of an information-gathering method that can be extended to a broader audience, resulting in quantitative data, if you ask the right questions (see Chapter 6 for more information on surveys). Qualitative research, on the other hand, focuses less on confidence levels and repeatability than on gaining context and information about user behavior. It is based on the interpretation of the findings, the intuition and common sense of the designer. (Contextual research, discussed in Chapter 6, is an example of qualitative research.) A qualitative approach creates an openness to testing that promotes the exploration of ideas and the acquisition of knowledge. the conversation with the user is just as important as its execution, if not more. The focus is on improving the current design: getting feedback and reactions to what is presented to generate ideas. So is usability testing a quantitative or a qualitative method? This is one of the oldest debates in UX design. Either approach is possible and can produce useful results. Proponents of a more quantitative approach say:

usability test


This allows measurable benchmarks to be defined against which they can be tested.

In subsequent iterations, show progress toward a goal (for example, reduce checkout time by 20 percent or address 80 percent of usability issues on a website). This also makes it a good approach when you want to do a formal comparison of two sites or evaluate a particular site. Produces results that can be statistically validated, that can be significant

it is not required when endorsing recommendations to stakeholders who rely on data-based decisions. Reduces the chance of being affected by an individual UX designer's bias

Results. Gives a greater degree of confidence that the resulting results will be

reflected in the results for the entire user base. Provides a clear numerical method to validate a finding (for example,

how many users experienced the same problem). Defenders of qualitative usability testing say: Qualitative research builds expertise and empathy for the designer,

promote creative user-oriented solutions. It relies heavily on the UX designer's intuition to make reasonable recommendations.

fixes, which is a big part of why he's on the team. Especially with usability testing, a qualitative approach is often less

more expensive than quantitative, both because fewer users are needed and because qualitative research does not require formal scientific design knowledge and analysis (such as statistics). It is very easy to misanalyze the results of quantitative studies by lying

(albeit unintentionally) with data, so a quantitative approach can carry even more risks than a qualitative test if not done correctly. Although the findings have not been numerically validated, they can be validated by

a designer, who will call out the potential impact of the problem using their considered reasoning and build the case with user stories. Qualitative usability testing is the most accessible approach for those untrained in formal scientific methods and provides a rich source of data to inform design. For these reasons, we will focus on qualitative test design in the remainder of this chapter.



How many users is "enough"? Question "How many users is enough?" in a group of UX designers it's like bringing up religion at a political rally: it's a hotly debated topic. It is also a question that cannot be avoided as you need a framework on which to base your research. It depends on the approach you use: quantitative or qualitative. To give a short answer, here are the guidelines that seem to have reached the most consensus in the UX field, provided by Jakob Nielsen: For a quantitative test, plan for a larger number of participants: 20 participants per survey round (see . http ://www.useit.com/alertbox/quantitative_testing.html). For a qualitative test, five to eight users per group are usually sufficient per survey round. Ideally, more than one round of investigation is conducted to discover issues that may be "hidden" among other issues or inadvertently introduced into the new design (see http://www.useit.com/alertbox/20000319.html).

Research Design When designing a usability test, there are some questions you need to answer early on to provide focus and scope. This can be delivered as a written document and discussed with the project team and key stakeholders, often referred to as a user research plan. The plan should describe your approach as chosen above. Why are you testing? Write a clear statement describing the goals of the test, based on one or more of the goals of the overall project. See Chapter 2 for examples of design goals and how they vary by project type. Who are you testing? Once you've created your user model (see Chapters 6 and 7), you can use it as the basis for your decisions about which users to test. If you haven't already done so, meet with the project team and relevant stakeholders to prioritize user groups. This information is passed to your controller (discussed in the Recruitment and Delivery section). usability test


At this point, you must also select the user groups to represent and the number of users to include in each group. What are you trying? Asking what you're testing involves two interrelated questions: What method are you using to render the website or app? And what functions do you plan to assume? If you need to redesign an existing application, you can choose to first run the full test on the current version to find the main usability issues that need to be addressed. If you're working on a new design, you can use paper sketches or prototypes (for example, a printed cable package) to represent new interface elements, such as pages. These low-fidelity representations of the user interface allow you to quickly generate and discuss ideas within the project team and quickly iterate with participants (see Chapters 10 and 11 for more information on sketching and wireframes). When working with a new design that contains highly interactive elements, it may be best to create a prototype that realistically simulates the navigation flow of the design, but can still be created quickly before full development begins (see Chapter 12). for more information on prototyping) . The pages you include are closely related to the tasks you select. If you plan to use prototypes for user testing, you should plan for your main working pages, as well as intermediate pages and fallback paths. You may not need to describe all of them in detail, but you should design a response if a user decides to go that route. Sometimes this can be as simple as a page stating that a particular route is not available and asking the user to return to the previous page to try again. The details of your tasks will be discussed in the discussion guide (discussed below), but because the scope can vary greatly depending on the type of tasks you include, it's helpful to summarize the list when planning.



Dive In To learn more about iterative design and sketch testing, and for some really inspiring insights into creativity in the design process, read Sketching User Experiences: Getting the Design Right and the Right Design by Bill Buxton (Morgan Kaufmann, 2007). For more information on paper prototyping techniques, see Paper Prototyping: The Quick and Easy Way to Design and Refine User Interfaces, by Carolyn Snyder (Morgan Kaufmann, 2003).

If the list is too long and you're not sure how to prioritize, here are some possible priorities to consider: Areas where the design conflicts with certain established conventions. Are

calling it a "goodie bag" instead of a "shopping cart"? It's probably a good idea to see if this is clear to your users. Areas where planning decisions are politically charged. maybe you have one

strong feeling that a certain design direction is the right one, but knows that there is a lot of disagreement among stakeholders or other members of the project team. Seeing is believing. Areas where usability issues can have critical consequences, such as loss

sales or, in the worst case, lives lost (medicine dosing healthcare applications are a good example of this). Then, you specify the information you want to collect as a user attempts to perform each task. What information is collected? We focus on qualitative usability testing, which typically has a smaller set of metrics. For the most part, you want to understand the problems users may encounter, the different levels of frustration they may experience, and the severity of any given problem. For example, there may be an occasional issue (not experienced by all users) that causes a published story to be irretrievably lost. This should definitely be a big deal on your report!

usability test


To gain insight into the users you're testing or running test rounds, there are a few metrics you should consider as part of your test. Again, if you're running a qualitative test with a smaller number of users, don't go too far with these numbers (calculating an average number won't make much sense if you're only testing five users), but the following measures can help you mitigate severity. . Understand some of the problems users face. Success: The degree to which a user was able to complete a task. If you look at all users, you can also look at the "success rate" - the number of users who can successfully complete the task. Sounds simple, but that means you have to define success! For less formal tests, you can say that a job is successful when the user reaches the final state (for example, an editor approves a story). You can track success more formally by noting the different levels of intervention required by the facilitator: Request Level 1: The test facilitator answers a participant's question, but does not provide additional details. For example, a participant asks, "I think it would be this button, should I click on it?" and the moderator replies, "Go ahead and try it." A Level 1 indicator does not in itself mean that a task has failed, but it is worth noting as the participant is likely to experience some uncertainty at this point. (Though if this is your first job, you might as well be unfamiliar with usability testing.) If a user doesn't need a prompt to complete the task, or only needs one or two Level 1 prompts, consider this step a success unless you think the time it took the user was much longer than the patience level that users probably have. . Level 2 Hints: The quiz facilitator sees that a participant is having difficulty and gives a hint in response to a question. This level does not include the direct response, but the response may influence the user's approach. For example, the moderator might say, "Is there anything else on this page that you think might be relevant to this assignment?" Here you can set a limit on the number of level 2 prompts that can be given before the assignment is marked as failed (for example, on the second question) or "passed with difficulty".



Level 3 Warning: The participant gave up out of frustration or struggled to the point that they probably would have given up if faced with the task in real life. In this case, the moderator immediately responds to part of the work, for example, by saying, "To approve this story, click the Submit button." If a participant needs a level 3 indicator, the task is usually marked as failed. User Satisfaction: Of course she successfully completed the task, but what did she think? It can be helpful to include a few follow-up questions (with the timer off) after each task to understand how happy or disappointed your users are afterwards. If you find someone who doesn't like to talk, this could be the most important window you have into their soul. Table 13.1 shows examples of some questions you can ask after the task. TABLE 13.1: 13.1 User TABLE

Satisfaction questions NOT EVEN AT ALL





The job took longer than I expected.






The task was easy to complete.






I got frustrated trying to complete this project.






User Satisfaction Questions User Testimonials – This is not a statistic, but what users do voluntarily is an important set of details for us to collect. Adding user input to a report is a powerful way to bring the human element to the results, so that stakeholders don't just interpret the data, but understand the insights that lead to understanding. During the test, you can easily mark statements as a question or a comment. we break them down in the report (see the "Information Generation" section below).

Recruiting and Sourcing Now that you have the survey overview and know how many participants you need from each group, it's time to plan some tests!

usability test


Creating a list When you created your survey design, you outlined the types of users you wanted to include. You can use this overview as a focus for creating a list of potential participants. Ideally, search for names, email addresses, and phone numbers. Here are some sources you can consult to compile this list: Registered users of a related company's website Customer contact information Responses to investigative messages sent to related websites or groups

about your research topic. This can be broad, such as posts on Craigslist, or specific, such as newsgroups focused on your company's industry. Email acquaintances with a connection to the subject of the test.

You'll want to ask them to forward the invitation to other people who might be interested, as using topics you know personally can skew the results. This type of word of mouth is a great way to find the pockets of potential entrants, but keep in mind that these candidates haven't been vetted yet. (If you or others in the group know the people well, it can be tempting to let them out.) Prompts in the form of short surveys that assess participants,

advertising space on relevant websites or company website placements or pre-screening questionnaires where possible in public places

Participants can be found. For sites with a strong association with a physical location, you can also do most of your testing and programming on-site. Third-party recruitment companies who can also perform the assessment for you

and help with planning. This can be an expensive option, but if you are looking for a specific type of participant that is difficult to recruit or you need to recruit a lot of people, you can save a lot of time by outsourcing this part of the process. Some companies also specialize in certain areas (such as medicine) and can give you advice on how to encourage high participation.



Get ready to get creative here. Use your empathy skills to think like your target users: where can you find them and what might motivate them to participate? This last question leads us to the next topic. Choice of compensation What motivates the members of your user group to participate in the study? It may or may not be money, but the participants want something valuable for their time. If you work on a site for internal users, you must demonstrate this value to managers, who must approve the use of company time for research participation. In this case, you can focus on how a better system directly relates to the benefits for your team. If you're working with potential external users, here are some variables to consider when determining compensation: How general or how specific is the audience? For a high-traffic eCommerce site, your audience is likely to be general, and you can often offer a lower percentage back in the form of a check or gift card. For an app used by lawyers, your fee should be of great value, and it's often better to use something other than money as compensation (for example, access to a premium service). In these cases, a check can actually seem like an insult—someone asking for $250 an hour would probably disagree. If you work with large clients, treat them as a specific audience and compensate them well. How interesting is the likely topic? Some participants join because they want to see what's going on in the area they're testing. If it's an area of ​​high interest, you may not have to pay any additional fees - the reward is gaining access to something that no one else can see yet. But be realistic: you may be very excited about the theme, but will your users be too? Will people participate mainly because they want to contribute something to a good cause? Some groups will be motivated by altruistic motives and may be prohibited from offering money to join. If you try something that improves the community (online or offline), you may get higher engagement, and happier participants, if the experience is more about collecting

usability test


instead of charging. In this case, you can show your appreciation with a public acknowledgment and, once the site is complete, let them know the contribution they were able to make by participating. How uncomfortable will it be to participate? If participants need to travel to your location, be prepared to offer more compensation. If they are participating in remote trials from the comfort of their home or office, less is needed. Of course, time also enters into this equation, and people will expect to be compensated more for 2 hours than 30 minutes.

Possible forms of compensation Your situation may vary, but here are some things you can offer: $50 for a half-hour remote trial with a general user group $80 - $120 for an hour in-person trial with a general user group $180 - $250 for a one-hour trial with a specific group of users that you determine will respond well to monetary compensation Free service for three months, free company-produced products (ideally those not yet available to everyone), group membership exclusive for six months and beyond to a certain group of users who are unlikely to be impressed with a check, say lawyers, doctors and sales associates. Again, it helps to be creative and focus on your people. What will motivate your user group?

Evaluation An evaluation is a type of questionnaire that you can use with potential participants before scheduling them. It ensures that they match your definition of a representative user. The questions are designed to ensure that the respondent is a current user of the features you are testing.

or a potential future user Determine if they fit into one or more of your user groups Have a good mix of participants in that user group



Exclude specific respondents who may have a biased experience

your results Gather important details you need to know before a participant arrives

(optional) Your screener should include an introductory script for your recruiter to read over the phone, along with instructions on when to qualify the participant (if there is a match) or end the interview (if not). The end users of your recruitment program are the people who recruit your participants, or potential participants if you use an online form for recruitment. Both can work, but it's usually better to collect a list of interested parties via a form or email and then evaluate them over the phone. Because; Because, unfortunately, it's usually easier for people to misrepresent themselves on paper than to respond to someone directly, and it's not uncommon for someone to try to take a survey even if they don't qualify. Especially when it comes to compensation! Your auditor should also eliminate those with knowledge who could affect your results. For example, a common question is whether the respondent works in market research, since the respondent is likely to be very familiar with research in general and therefore less likely to give candid answers. You can also contact those who work for the competition if you are concerned about sharing design information. Here are some sample questions you might see in a B2B web ordering app filter. In this case, we are targeting a group of users who are comfortable using and buying on the Internet and are likely to do so themselves. Note that some questions are designed to filter participants in or out, while others (such as question 4) are more focused on placing qualified participants in the correct user group. 1. What age group do you belong to? [mixed ages over 18] a. Under 18 years


Yeah. 18–24 c. AD 25–34 35-44 to 45-54 to 55 or more

usability test


2. How often do you use the Internet at home? A. Never


Yeah. Less than once a month


Doing. A few times a month d At least once a week p Several times a week f. Once a day or more often 3. When was the last time you personally purchased a product online? A. In the last month b. 1 to 3 months ago c. 3-6 months ago d. 6-12 months ago


M. More than 12 months ago


food I have never made a personal purchase online


4. When was the last time you visited pseudocorporation.com? [Group A are rare or non-users. Group B is frequent users]


A. I have never visited the site


Yeah. In the last month


Doing. 1-3 months ago


Hello. 3-6 months ago


M. 6-12 months ago

CHECK for A or B

food more than 12 months ago



You're fired. Termination is a harsh word. It means that the interview should be terminated because the respondent does not pass the test. He doesn't want the interviewee to feel bad about it, but he also shouldn't waste time asking follow-up questions if he knows it's inappropriate. There are many ways to deal with this. A favorite is to simply say that the pool she qualifies for is complete and ask her if you can contact her in the future if there's another test she'd be interested in.

Room and equipment planning At this point, you know if you are testing remotely or in person and how much time you need for each participant. Here are some of the other decisions you need to make: Where are you testing: in a rented space with an observation room, in a meeting room on company premises, or somewhere where potential users will be? Plan a quiet place that can easily accommodate two or three people, along with the configuration of the computer you will be testing. What staff do you need besides the moderator? You can save time and increase accuracy, for example, by having note log information during the test. Other features include a greeter (to meet incoming participants, hand out questionnaires while people wait, and escort participants in and out of the test room) and someone to provide IT support in case something comes up during the test. How to record your test: You can use a variety of methods, but software like TechSmith's Morae and Camtasia Studio make screen recording easy, and Morae has additional features for embedding video and audio via a webcam.

Writing Discussion Guides Finally, you need to gather the materials you need for the test itself. Their general duties are listed in the research plan. now you need to fill in the actual text and instructions for the task. Here are at least two packs: one for the test moderator and one for the participant (with enough copies for each test to include one of each).

usability test


Start with an introductory script that the facilitator can read to the participant. Many good examples are available at http://usability.gov/templates.

Surfing Usability.gov is a website developed by the United States Department of Health and Human Services as part of an initiative to encourage the development of sites accessible to a broad audience. Has an excellent set of reference materials to aid in user-centered design, including a sample video consent form (in Microsoft Word format), which participants must sign before recording: http://www. usability. gov/templates/docs/release.doc

Your instructions must include all the specific information the participant needs to successfully complete the task or tasks you are testing. If your tasks require a lot of data entry and customization, pre-define some information and give your participants pre-defined data to use. For example, if it is a login, it is likely that all participants use the same set of login credentials. Make sure the job instructions clearly state all of this information so that it is easy to complete. Here's an example of how a content editor job gets more specific in the discussion guide. The initial task in the plan is "Find an item ready to process." The discussion guide reads like this: INTRODUCTION Your manager has asked you to take on a new role: editing and approving articles posted by contributing writers on the company website. Once you approve an article, it will be posted on the site in the News section. You and three other editors approve the items to make sure they align with the company's message. You have been provided with the following publisher login details: Username: grobertson Password: come2gether



Read each task aloud and then complete it using the editor. Task 1 Log in to the tool and open an article ready to edit.

As you can see above, we slightly modified the task to end up with a clear end state: an open article. This kind of tuning will be common when you get to this level of detail and think about how you're going to measure success. You can also keep track of each job with the user satisfaction questions discussed in the scheduling section. In general, it's best to give each task its own page so the user isn't tempted to look ahead. In summary, your evidence material should include the following: Video Recording Consent Form (see Navigation sidebar above

for more information) Discussion guide for moderators, with introductory script Discussion guide for participants, with detailed tasks and user satisfaction

ask A note-taking format if you have someone dedicated to this. This is possible

they range from a logging tool built into the trial software to a spreadsheet for writing responses on a printed template to verify important information (such as the types of messages required). Taking a little more time to set this up before testing will help you get consistent results and save a lot of time checking logs. Optional quiz. Sometimes the participants arrive early and ask them

some waiting time - this is a great opportunity to gather additional information. If you've designed a survey before, you can reuse it here. The compensation method, which will be delivered to the participant at the end of it.

proof (money in an envelope, a commonly accepted gift card such as a Visa gift card, etc.); If you have opted for a fee, such as free services, where nothing is shared after the test, reassure the participant that they will receive a follow-up no later than the next day. If you use paper prototypes during your test, you also have these materials to work with. Be sure to prepare the kits for easy handling before starting your first test.

usability test


Facilitation The facilitator's job is to involve the participant in the process, answer their initial questions, and then collect as many ideas as possible, while trying to make the participant act as naturally as possible. Be sure to ask users to think aloud during the test, as if they were talking to themselves (and gently remind them to do this when they start working in silence). The "think aloud" technique gives you the greatest insight into user behavior. You learn a lot about their thought processes and problem solving by listening to them during the task itself, rather than asking participants to re-enact them later when their memory isn't as accurate. Also be careful not to give the participant the 'correct' answer too quickly! One of the hardest parts of conducting a usability test is watching a handpicked participant struggle with a task and just letting them struggle. After all, you are probably in this field because you are an empath. You want to help people. So it can seem a little sadistic to watch someone get more and more frustrated, ask them for help, and then say, "What would you do if you tried it yourself?" When a participant asks you a question while you are working, pause before answering. Test takers are likely to ask questions right at the beginning of the test, especially if they don't feel comfortable working with you next to them. Once they realize that you are there more to observe than to talk, they will often begin to focus more on the job than on your presence. Here are some sample questions and suggested answers from participants: Participant: "It looks like it could be this tab, should it go here?" mediator:

"Go ahead and try it."

Contestant: "Should I go here?" mediator:

"Is that what you think you'd be doing right now?"

Participant: "Is this the way to give feedback?" mediator:

Silence. She has a friendly, relaxed look on her face as she smiles at the contestant and then looks expectantly at her screen.

So when do you step in?



If the user has already put in more effort than they think they really would on their own, and you think they've learned why they went the wrong way, it's time to move on, especially if they have more work to do and don't want to be moved. your frustration to the rest of the test. In Chapter 6, we mentioned the importance of avoiding leading questions in user interviews. The same applies here. If you feel you are too close to the plan and that criticism may make you react defensive, consider having someone else guide you while you take notes.

Analysis and Presentation of Results You have completed all the tests and now have a mountain of data to filter. But there are some key findings that he already believes are relevant, and his project team is dying to know how it turned out. She may want to schedule an occasional verbal review of her great food for the group. It can help you articulate some of the trends she's noticed and help lay the groundwork for your later reference. Be sure to let them know that these are first impressions and that you need time to analyze your data in more detail. You don't necessarily want to go into recommendations here until you have a complete picture of where the problems might be. Once you have time to sit down with the data, look at it with a few things in mind: The time you have for analysis. It's easy to get lost in the details and take it all in. As always, keep an eye on the test and its objectives as you discuss important findings. If you have ten hours of test recording and five days to write the entire report, you probably don't want to take the time to watch the video of each test. Trust the note taker and, above all, go back to the videos to make sure the most important passages you remember have been captured correctly. How your results will be used. This is an important detail that can often be underestimated. You can create a great 20-page report, but only one of those pages is likely to get a lot of mileage: the executive summary.

usability test


If your business stakeholders want to see the details, the report itself can be the primary way to communicate the results. If you feel you need two levels of detail, one for stakeholders and one for the project team, consider also creating a presentation version of the report, which will affect key findings in a more visible, digestible, and prioritized way. Those interested in more details can check out the full report. Prioritize issues By the end of your test, you may have a long list of usability issues that you need to understand and prioritize. Here are some characteristics that will help you determine the severity of an error: Consequences. The negative effects of addressing the problem. For example, if a participant loses data due to a usability issue, they score high. Let's say you spend ten minutes filling out a complicated form and accidentally click a link that takes you to another page. If you press the back button of a browser, is your data lost? recoverability. The extent to which the participant can recover after experiencing the problem; for example, can you easily return by an alternate route? Appearance frequency. Since you are not working with a large number of people, this in itself is not a sign of seriousness. But if five people make the same mistake and it leads them down a less-than-optimal path, that's a good sign that you should consider giving it a higher priority. reasonable cause. If the issue occurs infrequently, but was caused by someone who fits your user group, did so for a reasonable reason, and there was a clear cause for the error, this issue should be considered when making your recommendations. Generate insights In addition to the issues you've collected, you have a large number of user submissions that can provide valuable insights to the project team. As described in Chapter 6, an affinity diagram exercise is a great way to put these statements together and identify common patterns.



Here are some ways you can categorize user statements (see the "Exploring Context" section in Chapter 6 for more information): Goals Mental Models Ideas and Feature Requests Frustrations Alternatives Value Statements Enjoy (don't skip them) , does not want the (well, do not miss anything!) Expectations (especially if they are missed)

Be sure to include positive findings in both ideas and recommendations. Usability test reports are often perceived as too negative, mainly because the researcher considers that discussing what needs to be fixed is more important than what is going well. Taking the time to discuss the good stuff improves the overall reporting experience for everyone. It also helps the design team to commit to the results and get excited about further improving the design.

Generating Suggestions Even before you begin testing, you probably already have some good ideas in mind for solving problems that arose during testing. Sketch them out along the way as you identify problems and ideas so you don't lose them. Be careful not to let one idea get over you too quickly and influence your view of other possible approaches that might solve more problems. A good recommendation should address more than one issue if possible. You may want to group issues

together under one larger recommendation, depending on how detailed and specific you are with your problem descriptions. Be practical and simple: avoid premature detailed plans.

usability test


Use verbal words that are clear but not patronizing. Reception

Criticism is a difficult thing, especially for those directly involved in the time-tested project. Don't minimize problems, but remember that your words should sound constructive and respectful. Remember that recommendations should be directed at your end users, just like the system. As you complete your report, go back and ask yourself whether the original goals were met and how best to deliver your results to the different people who will use them: stakeholders, designers, and developers. Speaking of developers, it's time to put them back in the spotlight. In the next chapter, we'll discuss things to consider as you move from design to development and beyond.




Transition: from design to development and beyond Where do we go from here? The definition and design phase of your project is over. And now? A design process for a good user experience never ends. After so much defining and designing, how do you stay committed to ensuring that the end result is the user experience you designed, and how do you go from there? russ unger


This is the end... ...of the book. This is the last chapter. However, it is not the end of the user experience design process, although it may seem so at first glance. After you've gone through all the previous stages of a project, you may think your job is done and you have nothing more to contribute. In many cases, UX design efforts end up as tasks somewhere in someone's project plan, and after their work product is delivered to the rest of the team, it always moves on to another project. Time to close that door and start something new, right? Very badly! There is still a lot you can do to ensure that you produce the best possible UX design.

Visual Design, Development, and QA In some cases, working with a design or development team that receives your project-based work product works just fine. Sometimes subsequent coworkers rely on you to answer questions, provide feedback, and help them with some of the design ideas they're working on. (That might sound too prototype-like to you!) In these environments, UX design has already been adopted, and the team probably had the foresight to give you time to complete these consulting tasks. However, in many organizations, the roles of user experience designers, information architects, interaction designers, etc., are still very new. It may be unclear how to manage these roles and the decision on how engaged to be with someone who doesn't fully understand user experience design. It may be up to you to find ways to consistently stay engaged.



Here are some suggestions: 1. Please buy them a copy of this book. 2. Don't be shy. 3. Read the rest of this chapter and look for opportunities in which you can participate and be useful. 4. Ask to compromise and be prepared to defend your request. There are other cases where you find that the visual design or development team is the king of the company and its projects, and it can be difficult for you to stay involved. You may be trying to break down walls so you can inspect the work and ensure compliance. This doesn't always happen, but it does happen. Christopher Fahey, founder of Behavior (www.behaviordesign.com), is no stranger to overcoming this challenge. He gives this advice: Some organizations are highly segregated. To remain engaged with the development of the project after the initial design phases are complete, be proactive and ask for the opportunity to provide feedback and fixes to the development and visual design teams. Often they don't even think to ask you to be there. Ideally, you should do this during the planning and budgeting phase of the project. Otherwise, you may have to literally offer your services to make sure the design doesn't deteriorate during further development. One trick is to simply request to be added, even informally, to the QA team (assuming you have one - if not, be sure to ask the visual designers and developers!) and get access and passwords for all sites development and debugging tools. ; You can then add your ratings and anomalies to the same bug fix queue that developers review every day.

Of course, many projects will not have the luxury of a quality assurance team. In a perfect world, every project would have such a team. However, in reality, quality control is not always available. Sometimes developers do QA themselves while developing. In addition to making you cringe, knowing this will make you work even harder to work with developers.



The Art of the Deal The art of the deal can become a fundamental aspect of your role as a user experience designer. Downstream collaborators, such as visual designers and developers, can make changes to your work without realizing how they affect important parts of the user experience. In the event that someone tells you that something "can't be done," be prepared to come up with a plan B. Good negotiation skills will help you defend your design decision (which should be based on the research you have completed). ) and convince others that the user experience can be done. Alternatively, these skills can help you work with your partners to create a successful Plan B approach that meets as many of everyone's needs as possible. For more information on negotiation, see Getting to Yes: Negotiating Agreement Without Giving In, by Roger Fisher, William L. Ury, and Bruce Patton (Penguin, 1991) and Selling to the VP of No, by Dave Gray (XPLANE Corp, 2003). ). ) . ).

This is especially true of many small businesses: quality control is a luxury. QA "is done by everybody, but mostly by the developer," says Troy Lucht, president and chief development officer at Ascend Realty Solutions (www.ascendrealtysolutions.com). Everyone tries and wants to, but without the resources to write test scripts, it can be impossible for people to know what to test when development often runs until the last possible moment. In many cases, our in-house designer is the person who knows the app as well as I do, so they can provide more informed feedback. Adding a UX designer to the mix would really round things out for our small team.

While your UX design work product may not include test scripts, in some cases you can test the schemas and annotations you've created to ensure that all elements are accounted for and that all Defined calls to action work correctly. This situation is not perfect, but it is an approach that can be useful in the absence of quality control. The main takeaway here is that user experience design doesn't end just because you've delivered your work product and transferred knowledge. His role may temporarily be more advisory in nature, but it's not over yet.



Design testing with users (again) Haven't we already done user tests? Hopefully you can answer yes to this question, but that's not always the case. Unfortunately, neither does this particular testing step, which is meant to test the final, designed and developed website with real users before launch. This will give you one last look at the website and find any last minute bugs and bugs that you may have missed during QA testing. Once you've identified your target audience, you can test the website for scenarios that seem high-risk or may have had issues in previous iterations of the site. This round of testing can give you the information you need to determine if your site is ready to use. If significant issues are discovered during this round of testing, it may be important to update and retest.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1… Launch! "If you build it, they will come. …" This theory is mentioned often, and debunked almost as often. You can create the most beautiful, satisfying, and usable app, release it to the world, and find out two months later that almost no one is using it. adopting. What it gives? User adoption is the degree to which your intended user base ultimately uses the website or app. Some adoption issues can be avoided by following good search engine optimization practices (Chapter 8 ) to make sure your users can find the new site. User adoption also means that good user experience design doesn't stop when the project ends or is limited to the project you're working on. You can help your Marketing, customer service, public relations, and education teams help ensure smooth growth and a user base that is excited about the site or project by helping them with three factors that often influence user adoption: Personal benefit

10, 9, 8, 7, 6, 5, 4, 3, 2, 1… GO!


Tips for having a support network

Let's take a closer look at them one by one.

Personal benefit One of the most important questions users have to answer is "What do I like?" No matter how good your website is, if you can't quickly explain your unique benefit to a particular type of user (or one of the people you've identified), you may have a hard time attracting users. Some benefits are immediate: "This camera feature allows you to post photos to your online account with the click of a button." Some are indirect: "Using this time tracking tool makes it easier for the company to keep track of how much time you spend on each project." You have spent valuable time gathering information about your users. Now use that knowledge to help your marketing department tailor your messages.

Support If your users need help with the site, how do they get it? In addition to the contextual help that great UX design efforts will try to provide, answering this question also involves training and customer support. Do you think that your users respond better to face-to-face training than to online training? Will some of your users skip the training and expect to have everything they need on the site? Is live chat an important customer support option for your users, or will they be happy with phone and email support? Support efforts are difficult and by understanding your users you can help your customer service and education departments effectively.



Red Opinion Word of mouth is the main factor of influence. What reputation does your client's company and current website have within your target user groups? Even if the answer here is yes, that doesn't mean there isn't any effort involved: maintenance is always important when it comes to reputation. Don't use a positive answer as an excuse to move on to the next section: the effort required to maintain may not be significant, but the effort required to recover from a reputation disaster can be overwhelming. A little TLC can go a long way, so read on. If the answer is no, then a serious effort must be made to improve perception. You may need to reach out to the user community and identify who the influencers are, how they prefer to communicate, and how they influence their audience, and then engage them. There are many ways to engage your users through social media and influence their opinion of your customer, your business, and your website. Help your client identify opportunities to engage these communities and try to steer them in a positive direction. If all three apply and you're still seeing low usage, think about how and what your competitors are doing to meet user needs. How can you differentiate the product or website?

Post-launch activities These are exciting times we live in: many companies are launching themselves, or their products, in "beta" mode. A beta release usually means that actual, unfiltered users are the audience for live testing of the website to help identify bugs, bugs, bugs, or other issues. Once upon a time, beta versions were usually only offered to developers, but now it has become common practice to open beta versions to the general user community. During a beta phase, it is imperative that communication methods are set up to capture and report any user issues. Any form of system failure that occurs should be recorded and made available to the project.



club. There should also be a mechanism for users to report any problems they find to the appropriate members of the project team. If this kind of communication doesn't happen, if UX designers, visual designers, and developers don't know what's going on during the often tight and fast-paced beta phase, the site can be updated and redistributed to users without much strategy. that was implemented.

Post-launch analytics After launching your website, one of the first things you should do is start collecting data about website usage. The best source for this is your website's log file. Unfortunately, UX designers are probably not at the top of the list for getting or seeing this information, so find the person who hosts the site and apply your negotiation skills. Website analytics can give you insight into your website visitors. Among other things, you can get information about who are the new visitors to the site. Who are recurring visitors to the site. Number of page views Duration of page view Page depth Where visitors leave the site (which pages) Session duration Ad impressions Search terms used, results and research

This information can help you understand where users are having trouble by identifying problem areas on the site. While the analytics may seem dry and the numbers heavy, the data and insights will help you ask the right questions as you test post-launch. Note For more information on website analytics, Avinash Kaushik's Web Analytics: An Hour a Day (Sybex, 2007) is a good place to start.



Post-Launch Design Testing with Users (Again, Again) After collecting data from your site analytics and gathering information from customer service or other departments that interact with users, you can start building a list of questions that you can use in a next round of design testing with users. In other words, use the data you've collected to create a new set of questions to ask your website users, using the skills you learned in Chapter 13. One of the benefits of this round of testing is that you have the opportunity to to assess the same group of users you previously worked with to determine if their opinion has changed since the launch and increased usage of the website. This can be very useful: if you test the same user group (or part of it) again, you can re-ask some of the original questions (feelings on functionality, ability to perform certain tasks, etc.) and variation in answers parse after a while. This fluctuation feature can help you discover new areas for improvement on the site and get an idea of ​​the user's learning curve, based on previous rounds. As a bonus, analyzing the differences in responses can also help you identify new questions that haven't been considered before.

It's all done, right? No.

Just like starting from scratch... By gathering analytics and testing the design with research data, you can begin to build a list of enhancements and enhancements that would benefit the site. Once you've collected them all, you can create a new proposal (Chapter 3) based on their recommendations. This proposal could lead you to an entirely new project, which could lead you to define a new set of project objectives (Chapter 4) and business requirements (Chapter 5). Can



then move on to further research (Chapter 6), building personas (Chapter 7) for new goals, boosting your SEO (Chapter 8), updating or creating new sitemaps and workflows (Chapter 10), upgrading or creating new clients leads and annotations (Chapter 11), initiating additional rounds of prototyping (Chapter 12), and more design testing with users (Chapter 13)…you get the idea. Projects should not die. They should be the springboard for new projects aimed at continually improving user experience design.



Table of Contents An absolute path, used in original HTML 213 login and logout, also in proposals 53–54 ACSI (American Customer Satisfaction Index) 103 activities, planning 162–164 Adaptive pen and paper path on website 189– 198 16 additional costs and cost, including proposals 50 Adobe Acrobat PDF prototyping tool, features 214–215 Adobe Illustrator website 167 Adobe InDesign website 167 advocates, priority 150–151, 154 affinity diagrams applied for 61 steps 99–100 use in usability testing 244 agile approaches summary of resources 63 – 64 for 65 AIGA website 51 Ajax issues with 132 Align interactive website 217 alternative attributes, usage 139 American Customer Satisfaction Index (ACSI) ) 103 General information on the availability of tools 254 General annotations 187 Tools for 189-190 and Wireframes 186-187, 193-194, 201 Aquent Talent Website Service 51 Arrows and Links, .com, searches carried out with 128 cases, including sentences 47- 48

compare attributes 90 prioritize and define attributes from the Axure RP prototyping tool from 215 website 167


B Babyhold website 118 BabyNames website 118 Balancing, realizing UX design 6–7 Balsamiq Mockups prototyping tool, features 216 Baty, Steve 12, 95 Behavioral website 249 beta release, drift rate identified from 253–254 black load, 253–254 defined 130 –131 vs. white hat 141–142 blog functionality, sitemap for 166, 191 Blue Flavor site 167 Site Blueprint CSS 167 body language, focus group interpretation 106 bots, explained 129 brand presence sites described 11 examples 13 characteristics of 12–13 goals for 13–14 role strategist/brand partner 26–27 Brooks, Mark 200–201 building owner, system for 183 Buley, Leah 189–190 , 201 advocate for corporate interests 154 versus advocates for developers and users 155 role of business use analysis 27–28 wireframes in 188 business requirements 73 See also requirements gathering clarify 68–69 merge 82–84 perform heuristic analysis for 70–73 planning meetings 78–79



business requirements (continued) create worksheets for 153 defined 68 example 83 responsibility pack for 75–76 stakeholder pack for 76–77 for Global Cruises home page 195–196 supporter development legacy 157 listen to ideas among 48 – 81 prioritize 151– 152 actual meetings 80 –81 wireframes 189 business stakeholder, defined 75 Buxton, Bill 231

Calendar tool C, working prototype 217, 219 campaigns. See marketing campaign sites card classification closed categories 110 explanation 93 group classifications 110 overview 107–108 test execution 109 process 108–110 instruct 109 categories remotely 110 clients, using wireframes for 188 cloaking, explanation 1 –11321 overview 142 prevention 138 accidental 133 collage, use in, for example, microfinance 223–224 communication, importance for prioritization 160 companies apply SWOT analysis to 61–62 compare competitors 61 corporate culture hierarchy 36–37 history 34–3 34 -3



compensation, identify for user groups 235, 241 competitors, compare 61 concept exploration. See also examples of visual designs 222–224 potential pitfalls 222 goal 221 conditions, definition 170 conflict, manage prioritization 158–162 sloppy links, links and arrows 171 defined conflict 170 in 170 consumer priorities, complete 5 content best practices for 138 – 139 importance of 135–136 staying current 138 content creators using leads 188 content management systems, 133–134 content matrix overview, numbering system applied to 173 content source sites described 11 features of 16 –17 objectives for 17 tasks related to 17 business use analysts for 28 classification of use maps in 108 content strategist, role of 28-29 contextual planning, source for 101 contextual research explanation 92 information obtained from 98 process of 98-99 using relevance diagrams in 99- 101 copywriter, role 29-30 Coroot website 51 (additional) costs and fees, included in proposals 50 Tracking capabilities 131 Discovery via hide hide 132 Explanation 129 Creative Commons website fifty

Dotted line D, representing conditions with 170 decision points, 169 definition and planning stages, overlap between 145 deliverables, including proposals 48-49. See Also Product Design Goals for Brand Sites 13 for Content Resource Sites 17 for Ecommerce Sites 19 for E-Learning Apps 20 for Marketing Campaign Sites 15–16 Design 10 for Social Media Apps 21 for Apps task-based 18–19 design flaws lack of page numbering 173–174 misaligned objects 172 misaligned placed text 172–173 sloppy connections 171 unevenly distributed objects 172 plan, improve 227 developers prototyping 217 use of wireframing 188 defender and 188 monitoring and business development 5 to 158 concerns of 154 objectives and responsibilities 157 inheritance of requirements 157–158 participation 158 traits 156 development team providing feedback to 249 digital assets optimizing for 138 digital experiences designing 5–6 digital prototypes. See also public prototype for 208 HTML vs. 209–214 WYSIWYG resources needed for the 209 timeline for 208 vs. wireframes. realistic prototypes 207–209 Digital Web Magazine website 167

directory structure importance of 134 writing discussion guides for usability testing 239-241 designing documentation 162-164 domains including keywords in 134 door pages overview 142 using bullets in relevance charts 161 feature Dreamweaver CS4 Live View in 209 210 prevent duplicate content 138 avoid dynamic URLs in content management systems 133

Ecommerce Sites, Design Goals for 19 Educational Microsites, Example 15 E-Learning Apps, Design Goals for 20 Emotion Versus Logic 7 Enable the PURITE Process 46 Team Module, Designs for Usability Testing 239 Evans, Will 122, 123 , 181 , 197 – 201 experience, tangible vs. digital 4–5

F Fahey, Christopher 249 Favreau, Jean Marc 40 presenting idealism and visualization 146–147, conflict management related to feedback mechanism 160–162 prototyping 219 (additional) fees and charges, included in proposals 50 Finck, Nick 167 CS4 Prototyping Tools Flash Features 215 –216, Flash Prototyping and Flash Catalyst Features 130–132 Flash Content Features 216 Embedding in Static Layers 131 Focus Group Discussion Format for 105–106 Explanation 93 Body Language Interpretation in 106 Guide 107 process of 105 –107 use in microfinance Example 223 use of footnotes 104–105 design 196



footer links, link popularity 140 front-end developer, role 31 funding model, application to microfinance 222

G Garrett, Jesse James 168 Global Cruises, home page design for 195-201 Google Analytics Tools 24 PageRank system 139 quality guidelines for webmasters 142 searches performed by grid 128, use in applications 172 group discussion format for 105- 106 body language explained 93 in 106 mitigation 107 process of 105-107 use in microfinance example 223 use of 104-105

H Hadden, Jon 217–219 header/navigation, 195 design of header meta tags, allowing 137 heuristics to exploit requirements when collecting 73 overview of 70–71 logic for 71 steps involved in 72–73 hierarchy, impact on business projects 36 – 37 Hinton, Andrew 177 Hofstede, Geert 36 home page design 192 design for Global Cruises 195–201 wireframe design for 197–200 example 194 HTML prototypes 212 link popularity 140 HTML prototypes analyze code for 21413 – check HTML21413 – create 210– 212



I ideas, combining 82–84 ideas and display features 145–147 Illustrator website 167 image maps, use in HTML prototype 213 image tags, use in HTML prototype 213 InDesign website 167 Indexed pages, separate websites 137 -138 lofisni13, avoid in content management systems 133–134 information, search 17 information architects balance with other roles 248–249 role of 22–23, 25 Information Architecture Institute website 51, 167 guidelines, completion for usability testing 239–241 equilibrium design other roles 248–249 role 23, 25 job interviews. View user interviews iStockphoto website 117 Iterative section of the PURITE process 46 iterations, wireframes as an iterative design exercise 201, resource for 231 iterative tests, use of prototypes for 217

J JavaScript, Problems with jQuery website 214


K Keynote prototyping tool includes 214 keywords included in sitemaps 175 keyword research tool availability of 135 keyword searches, behavior of 135 keywords included in domains 134 naming conventions to use in the structure of URL 134–135 Knemeyer, Dirk 12

Launched sites, post-launch analysis 254 prototype left navigation links for 217-218 legends, including sitemaps 175

work with license defined 49–50 link anchor text metatag explained 137 distribution of link popularity 139–140 explained 139 footer links 140 links within content 141 manipulation 143 link spam 143 list of participating users, create 35 Live 23 , use in Dreamweaver CS4 209 logic versus emotion 7 logistics, impact on corporate projects 37 logistical step usability tests 233–239 Lucht, Troy 250

M marketing campaign websites described 11 examples 14 features 14 objectives for 15–16 buy, build relationships with 26–27 Melzer, James 182 Messageirst case study person 115 Website 219 meta description tag explained 137 meta keywords explained 111376 spam with 142 meta tags, 136 –137 availability of methodology, importance of 62 microfinance, defined 222 microsite, defined 15 Microsoft PowerPoint website 167 Microsoft Visio website 167 missing pagination errors 173-27 incorrect objects 173 sloppy links 171 unevenly distributed objects 172 approaches changed, after 64 –65 moves, with 170 MSN, searches performed by 128

N names, person negotiation 118, art 250 network views, impact on user adoption 253 Nicolle person, described 115–116 Nielsen, Jakob 71 nofollow link attribute, using meta tag 140 noindex, explained 137

Objectives OR apply SWOT analysis to 61–62 imprecise vs. concrete importance 58–60 of input 57–58 of UX designers to 60–62 with measurement 58, 60 connecting objects correctly 171 measurement grids between 172 misalignment 172 uneven observation 172 for heuristic analysis 72–73 OmniGraffle authoring tool prototypes site attributes 215 Web 167 OpenOffice Draw site 167 OptimalSor Website overview 109, including proposals 44–45 Ownership and rights, including proposals 49–50

P age numbering, missing metatag of page title 173–174, 136 Explanation of PageRank system, explanation of pages 139–140. See also 142–143 cloning sites defined 168 individual indexing 137–138 page stack, defined 169 paper and pencil, use for threads 189–190, 201 paper culture, understanding 37



paper prototype 206–207 example 217–218 HTML as 209 for navigation concepts 218 passive observation, define routes 99, identify in workflows 180 payment schedule, including proposals 52–53 pencil and paper, use for 8–29101, age of people 118 years biography 119 case study 115 defined 113 level of education 120 access or activation points for clients 120 find information about 114 information included in 116 location for 119 maximum use of 125 level of mobile comfort, 121 motivation to use clients or projects 121 naming 118 occupation 119 offline activities 120 online activities 120 overview sheet for 122 personal offer 120 photos 117–118 justification for 113–114 salary or salary scale 120 social comfort level for 121 people group common goal for 124 individual target group 124 technical comfort level 121 types 113 user goals 121 photo sources, face capture 117 post-it notes, use in affinity diagrams 161 post-launch design tests 255. See also test. usability test steps power distance defined 36 powerpoint prototyping tool features of 214;



Website PowerPoint 167 PR (PageRank), explained 139–140 Preparing the pricing section PURITE process 45, structure for projects 51–52 Prioritization process applied to usability testing 244–245 Balancing roles in 154 Facilitating the importance of communication 150–15 Conflict during process flow 158–162 example of 181–182 product success 5. See also deliverables flexible project approaches 63–64 significance of 66 included in proposals 45–47 modified 64–65 steps for 62– 63 project management 63 misalignment in project management 160, using wireframes in 188 project objectives Applying SWOT analysis in 61-62 vague vs. firm importance 58-60 of 57-58 input from UX designers in measurement 60-62 58, 60 project overview, included in proposals 44-45 project pricing, including proposals 51–52 project requirements, steps involved in 69 project sponsors, 75 project teams defined, 75 project terms defined, 80 project diagram best practices for 191 business history impact on 34–35 process flow 181 –182 proposal elements acknowledgment and signature 53 –54 costs and additional charges 50 assumptions 47–48 deliverables 48–49 property and rights 49–50 payment schedule 52–53

project focus 45–47 project overview 44–45 project pricing 51–52 revision history 44 scope of work 47 statements of work 54–55 cover page 42–43 proposals, importance 40–41 prototypes accessibility 219 requests for 219 calendar tool 217, 219 changing wireframes for 210 completion 219 creating with WYSIWYG editors 209–214 examples 217–219 as a feedback mechanism 219 goals of 219 for iterative testing 217 download by developers 217 wireframes 207– realistic prototypes9. Also see digital prototyping best practices for 205–206 overview of 205 paper prototyping tools 206–207 Adobe Acrobat PDF 214–215 Axure RP 215 Balsamiq Mockups 216 Fireworks CS4 215–216 21Power Key216 Power Key216 and Flash Catalyst 214 Visio 215 PURITE Process 45 – 46

Q qualitative research, application to usability testing 227-229 qualitative usability testing, information gathering for 231-232 quality assurance documents, application numbering system to 174 alternative quality assurance teams to 250 participation in 249

quality assurance, use of frameworks for 188 quantitative research, application in usability testing 227–229 questionnaires, for example, in discussion guides 241 questions. Also see Activity Planning Highlights 162–164 for User Group Compensation 235–236 for Documentation Planning 162–164 for Focus Groups 105 for Stories 148 for Surveys 102 for Usability Testing 242 for interviews with users 97 for user satisfaction 233

R Random Name Generator Website 118 recommendations, build for usability testing 245–246 usability test intake step 233–239 redirects, set 135 relative path, use in prototype HTML 213 PURITE Process Performance Module 46 requirements, define requirements6, collect requirements6 , shortcut 74 See also business requirements requirements process promotion 74 research planning for usability testing 229–233 research techniques card sorting 93, 107–110 contextual research 92, 98–101 focus groups 93, 104–107 people 121 surveys 92, 104 usability tests 93, 110– 111 user interviews 92, 95-97 sources. See also website resource relevance charts 161 Flexible approaches 65 Analytics 254 Body language 106 Contextual design 101 Google 128 HTML (Hypertext Markup Language) 214



resources (continued) iterative design 231 negotiation 250 prototyping approaches 217 social media applications 20 tools 167 usability testing 231 responsibilities, sketches 75-76 review history, including in proposals 44 balancing roles in the prioritization process 154 switching between collaborators 154

Sample size S, defined work size 227, including suggestions from 47 testers, using usability tests 236-239. See Also Script Navigation Questions, Search Behavior Issues 132–133, Understanding 135 Search Engine Optimization Starter Guide 129 Search Engines, Evolution 129 Search Results, Affecting 142 Searches Per Month, Related Statistics with 128 section headings, empowerment 137 Josh Seiden, 113 SEO (search engine optimization) defined 127 UX impact on 134 resource importance 127–128 for 129 SEO methods, white hat vs. black hat 141–142 SEO specialists, using signature and recognition 188 wireframes, including suggestions 53–54 site analytics tools for 24 sitemaps advanced examples 175–176 for blog functionality 166, 191 particular template 177 166



skip number structure of 173 simple example 174 vs. workflow 166 use 138 use card sort for 108 use workflows with location type 178 11 specify locations. See also indexed pages 131 text written in 29-30 six-page templates, using 190 Sling Thought websites 217 social media apps described 20 design goals for 21 popular Social Security Administration baby names 118 Measurement Inventory 103 SOW (state of work), site content 54–55, design for usability testing 239 meta-keyword spam 142 Spencer, Donna 17, 109 spider, explained 129 Spool, Jared 125 SRA International Inc. Website 182 Defined Stakeholders 76-7 Listen7 81 Static Layers, Embedding Flash Content in Bullets 131, Use in Affinity Diagrams 161 Storyboarding Stock.XCHNG 117 Website, Process 147–150 Strengths and Weaknesses, Understanding 61 SUMI ( Software Usability Measurement Network) 103 support 33. See also exploration of UX design roles explained 92 overview 101 process of 102–104 vs. user interviews 102

SWF object, with lane 131, SWOT analysis sample 182–184, applicable to project objectives 61–62

T-tags. See meta tags directed at users, descriptive 113. See also user workflows that apply the numbering system to 173 creating examples 178–180 overview 166 process flow 181–182 versus sitemaps 166 swimming 182- 18 182-18 described application of site developers 11 roles and objectives for 18-19 using business analysts for 28 Tatum, Keith 217-218 Taylor, Dave 214 technical structure, 31 template builder, use with wireframes 190 intensity, balance defenders 154-162 Termination Use, Usability Testing 239 Testing Material, Writing for Usability Testing 241 PURITE Process Testing Section 46 Testing, Usability vs. user acceptance 226. See also post-launch design testing. usability testing steps completion of text for usability testing 239–241 misplacement 172–173 writing on websites 29–30 title page including title tag in sentences 42–43 use of tools in prototype HTML 213 availability 167–168

UAT (User Acceptance Testing), Objective 226 Understand the PURITE Process Module 45

Avoiding URL Paths in Content Management Systems 133 Avoiding URL Structures in Content Management Systems 134 Using Keywords in Usability Testing 134–135 Choosing an Approach for 227–228 Explained 93 Steps Overview usability test 110–111 236–239. Also check out the post-launch design test. test analysis and presentation of results 243–245 selection approach 227–228 proposal generation 245–246 evaluation 250 facilitation 242–243 research design 229–233 recruitment and logistics 233–239 writing discussion guides 239–242 opinions on 253 influences in 251–252 personal benefit of 252 support for 252 user advocacy role for 150–151 networking 32–33 vs. promotion and business development 155 against 154 compare user attributes 90 – 90 – 99 set priorities and 8 , get context for 227 user experience (UX). View user groups that define UX (user experience) 87 Site listing attributes 87-89 User interface engineering 125 User interviews explained 92 Interview tips 97 Process 95-96 vs. surveys 102



user models, plans 91 complete user research activities 93–94 111 plan 94 steps to perform 86 techniques 92 design, develop user research 229–233 user researcher, role 23–25 determine user satisfaction 233 tools measuring 103 testing the categorization of user statements with us 245 evaluating success 233 identifying users 232 -233 users. See also target users choose number for usability testing 229 identify types 88-89 using UX (user experience) structures 188 digital aspects 6 impact on SEO 134 UX design, 3 UX design roles defined. See also support network strategist/brand assistant 26–27 business analyst 27–28 recruiter 31 content strategist 28–29 copywriter 29–30 front-end developer 31 information architect 22–23 interaction designer 23 responsibilities 25 researcher users 23–24 30–31 balancing UX designers other roles 248-249 empathy 156 input to project goals 60-62 organizations for 7-8 role in prioritization 151 features of 6-7

Validation V, early search for value propositions 191, presentation 15



Visio Prototyping Tool The visual design team has 215 Visio 167 websites providing feedback to 249 visual designers involved in creating wireframes 203 functions 30-31 of using wireframes from 188 visual drawings. See also exploring concepts that apply numbering to 174 mockups 224 wires 200–201 visual vocabulary definition terms 170 links and arrows 170 decision point 169 page 168–169 page stack 169 visualization and ideation requirements for businesses 5–1 of ideas 074–81

WAMMI (Website Analytics and Metrics Inventory) 103 Warfel, Todd Zaki 115, 124, 217, 219 cascading approach changed 65 phases of 63 webmasters, quality guidelines for 142 webmasters/site owners Help for Webmasters AMW30 WebAn30 and 129. resources of the site 28. See also sources ACSI (American Customer Satisfaction Index) 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent talent Agency 51 Ascend Reality Solutions 174 Baby 18 250 18 Behavior 249

Blue Flavor 167 Blueprint CSS 167 "Brand Experience and the Web," 12 Brooks, Mark 201 Map Classification Spreadsheet 109–110 Coroot 51 Creative Commons 50 Digital Web Magazine 167 Doorway Pages 142 Evans, Will 1811 Google Content Code 1811 , Jon 219 heuristic analysis 71 HTML prototyping 214 Illustrator 167 image maps 213–214 InDesign 167 Information Architecture Institute 51, 167 information search 17 jQuery 214 keyword research tool 135 marketing campaign sites 16Point 16Point 7 names for People 118 OmniGraffle 167 OpenOffice Draw 167 OptimalSort 109 Face Types 113 Photography Fonts 117 PowerPoint 167 Random Name Generator 118 Search Engine Optimization Starter Guide 129 SEO (Search Engine Optimization) 143 Slingthought 217 Social Security Manager 143 Census) 103 Tools 167 Usability Test Scripts 240 Usability.gov 240

User Interface Engineering 125 User Satisfaction Measurement Tools 103 UX Design Approaches 24 UX Organizations 8 UX Research 95 Visio 167 WAMMI (Website Analytics and Measurement Inventory) 103 Help for Webmasters/Site Owners 129 WebSort 102 WebSort 102 WebSort 104 WebSort! Interface Library website 214 WebSort website 109 WebTrends website 24 white hat vs. black hat 141–142 whiteboarding, storyboarding in 149 wireframes and annotations 186–187, 193–194, 201 implementing the numbering system in 173 prototypes201 approaches that change through comparison and contrast 200 creating 189, 198–199 designs for the home page 197–200 as exercises in iterations 201 getting customer input for an overview 192–193 of 186–187 present 202–203 against realistic prototypes 2019391, 20191, 2017–200 201 as a “thinking device”, 198 tools for 189–190 users, 188 visual design, 200 –201 work for defined contract work 49 workflow, create stories 149 worksheets, create for business requirements 153 WYSIWYG editors with 409–prototyping

And Yahoo, searches performed by 128 Yahoo! interface library website 214



Get free online access to this book for 45 days! And access thousands of other books by signing up for a free trial of Safari Books Online! Purchasing this book gives you instant online and searchable access to Safari Books Online for 45 days! And while you're there, be sure to check out Safari Books Online's on-demand digital library and its free trial offer (a separate sign-up process). Safari Books Online subscribers have access to thousands of technical, creative, and business books, educational videos, and articles from the world's leading publishers.

Go to www.peachpit.com/safarienabled and enter the code FJGSLZG to try it today.


How to learn UX Design by myself? ›

How to become a self‑taught UI/UX designer
  1. Step 1: Learn the fundamentals of UX design.
  2. Step 2: Develop an eye for good design.
  3. Step 3: Invest in the right design software.
  4. Step 4: Build a portfolio of work.
  5. Step 5: Ask for feedback (and learn from it)
  6. Step 6: Get real-world work experience.

How can I practice UX Design? ›

7 Tips to Improve Your UX Design Practice
  1. Prune Your Vocabulary. Most people don't use the technical terms that we use in UX Design. ...
  2. Don't Follow the Yellow Brick Road. ...
  3. Recycle Your Creations. ...
  4. Break Out of the Box. ...
  5. Conduct a UX Review/Audit. ...
  6. Try Some New Tools. ...
  7. Set Time Aside to Read.
Sep 14, 2020

How to learn UX Design without a bootcamp? ›

  1. 10 tips to get into UX without a bootcamp. How I changed careers at 39. ...
  2. Have a plan. Work out the steps you need to take to get your first UX job, and by when. ...
  3. Take a UX course. ...
  4. Read read read. ...
  5. Do some UX work at your current company. ...
  6. Learn the tools. ...
  7. Create a portfolio. ...
  8. Online presence.

Is Google UX certification worth it? ›

Our Verdict: The Google UX Design Certification program gets A LOT of things right! The design certificate offers a reputable, high-quality UX curriculum that builds applicable, real-world professional skills that students can use to build a portfolio and immediately make a difference in the tech industry.

Can I get into UX with no experience? ›

Can You Become a UX Designer With No Experience? Yes! Organizations embracing digital transformation are building their UX capabilities, and are hiring entry-level UX designer jobs. This has also given birth to boutique UX design agencies that recruit entry-level professionals to build products for their clients.

How long does it take to self learn UX design? ›

On average, it takes between two to six years to become a UX designer, but it can take as little as three months. Since there are no formal requirements mandating a certain degree, certification, or license to become a UX designer, the timeline can range dramatically.

What do I need to study UX design? ›

The exact skills covered will vary from program to program, but a typical UX course should cover:
  • Design thinking.
  • User-centered design.
  • UX research.
  • Empathy maps, personas, and user stories.
  • Wireframing and prototyping.
  • Visual design elements.
  • Information architecture.
  • Design patterns.
May 17, 2023

Can you self teach UX design? ›

Luckily, it's not impossible to teach yourself UX design. After all, the original UX designers that pioneered the field did something very similar to the self-taught designers of today, but with even less resources than are available now.

Can a self-taught UX designer get a job? ›

UX is a relatively new field with only a few specialized degree programs available. Some of the best UX/UI designers started their careers either in a related field or through experience. Fortunately, this also means that a lack of formal education probably won't stop you from landing your first UX/UI designer job.

Can I be a UX designer if I'm shy? ›

Summary. Introverts and shy people can most definitely become UX designers. They can even thrive at the job and have a great time while doing it. That's because UX is so much more than just social activities, talking to users, and facilitating workshops.

How do I start my first UX project? ›

Starting a UX project? Use this checklist
  1. Align buyer personas to reader personas. ...
  2. Make sure the journey makes sense from every angle. ...
  3. Have a productive brainstorm. ...
  4. Make wireframing effortless with a flawless inventory list. ...
  5. Ensure all UI elements are authentic and accessible. ...
  6. Find and fix any red routes.
Jul 25, 2018

Can I learn UX design without coding? ›

No, most UX Designers are not required to code (at least, not at an advanced level). However, it's still to their advantage to develop an understanding and appreciation for what Developers do.

How much do entry level UX designers make? ›

Entry Level Ux Designer Salary. $52,500 is the 25th percentile. Salaries below this are outliers. $101,000 is the 75th percentile.

How much does a UX design Google certificate pay? ›

How much does a Google Ux Design make? As of May 22, 2023, the average annual pay for a Google Ux Design in the United States is $120,551 a year. Just in case you need a simple salary calculator, that works out to be approximately $57.96 an hour.

Can I get a job with just the Google UX certificate? ›

By the end of the certificate program, you will have a professional UX portfolio that includes three end-to-end projects, so that you're ready to apply for jobs. Upon completion, you can directly apply for jobs with Google and over 150 U.S. employers, including Deloitte, Target, Verizon, and of course, Google.

Is 40 too old to become a UX designer? ›

There are challenges, of course, but you're never too old to become a UX designer. Let's walk through some relevant discussions on how to become a UX designer with no experience even if you're in your 50s right now. The playing field for UX is wide open, and the opportunity is there if you want it.

Why is it so hard to get a job in UX? ›

Lack of UX maturity in many companies

That's what you'll hear a lot. The result? Companies don't want to spend money to build a dedicated UX team. It means that there are fewer UX jobs available than there could be, which makes it harder for you to get a UX job.

Why can't i get a UX job? ›

You might not have enough commercial experience

Commercial experience shows employers that you have been battle tested in the world of UX. Look for volunteer opportunities. See if you can work part-time or even a full-time job and then do volunteer opportunities while you're off work.

Can you become a UX designer in 2 months? ›

A quick google search of “UX design bootcamps” will yield dozens of options—no two bootcamps are exactly alike. UX Bootcamps can take anywhere between 2 to 10 months to complete. In general, UX bootcamps introduce students to basic UX concepts and guide them through projects so they can begin building a portfolio.

What is the fastest way to become a UX designer? ›

How to become a UX Designer in five steps:
  1. Learn UX design fundamentals.
  2. Learn key design tools.
  3. Work on your own projects to develop your UX design skills.
  4. Develop a portfolio to showcase your UX design work.
  5. Apply to relevant UX design jobs.

Which degree is best for UX design? ›

Let's look at ten of the most helpful university degrees or majors you should consider pursuing a career as a UX Design professional.
  • Computer Science or Computer Programming. ...
  • Human-Computer Interaction (HCI) ...
  • English. ...
  • Information Technology (IT) ...
  • Psychology. ...
  • Graphic Design. ...
  • Industrial Design. ...
  • Anthropology.

What should an entry level UX designer know? ›

General Requirements. Interpersonal skills in collaboration, documentation, consensus building, and project management are critical for a product designer. They need at least a basic understanding of the entire spectrum of UX design, including research, information architecture, prototyping, design, and testing.

How long does it take to get your first UX job? ›

Bootcamps include around 30 hours of instruction, while certificate courses are longer. You should be able to complete the courses and be looking for your first job in UX/UI Design in a few months to a year.

How many hours a week does a UX designer work? ›

While there is no set number of hours a week UX designers should be working, it is typically suggested that they put in around 40 -45 hours a week. This leaves plenty of time for design research, user testing, and other related tasks. Many companies are now realising the importance of UX Designers.

What was the most difficult thing to learn in UX design? ›

Understanding how to use data and qualitative feedback to help underline the importance of user experience problems and how to then use this information to tell a great story that convinces stakeholders is an art. And like any art it is hard.

How much do UX designers make? ›

Senior UX Designer Salary: $142,721

From his own working experience, Juan estimates an entry level UX design salary at around $75,000 for entry level positions, $90,000 per year for mid-level positions, and $110,000 for senior jobs.

Should I become a UX designer 2023? ›

In conclusion, 2023 may not be the best year to start a career in UI/UX design, due to the increasing prevalence of machine learning and the saturation of the field.

Can you be a UX designer without being creative? ›

If you're going into UX design, you're probably wondering how many creative aspects you need to invest in. For one, it certainly helps to be creative. However, a common question is whether a prospective UX designer needs to know how to draw. The answer, succinctly put, is no.

Can a non technical person learn UX design? ›

1 Answer. Yes anyone can switch their career from non-IT to UI UX design. There are plenty of institutions available in the market for UI UX design technology.

Can UX design be a side hustle? ›

As a UI/UX designer, freelancing can be a great way to work on exciting projects, gain experience, and build a portfolio. Here are some tips to help you succeed as a freelance UI/UX designer: Build a strong portfolio.

Should I learn UI or UX first? ›

If you're interested in making sure your products look good and are appealing to users, then you should focus on learning UI design first. If you're more interested in making sure your products are effective and easy to use, then you should focus on learning UX design first.

Can I be a UI designer without being a UX designer? ›

In a word: Yes. As is the case with many tech professions, you don't need a background in design—or UI design qualifications—to forge a successful career in UI. Employers are much more concerned about whether or not you have the in-demand skills and mastery of the tools to do the job of a UI designer.

How stressful is UX design? ›

Key Takeaways. UX/UI design is among the top 30% of careers in terms of happiness, but it can also be a source of stress due to lack of company awareness about UX, imposter syndrome, long hours and tight deadlines, challenging problem-solving and constant learning.

What is the downside of being a UX designer? ›

Cons of a UX UI Career: * Some companies look at you as a “unicorn-designer” who can do anything… which means they might assign you tasks outside your skill set. * Since “Design” and “research” don't usually co-exist, some organizations will take your other skills for granted and assign you just design works.

What type of personality is a UX designer? ›

UX designers tend to be predominantly investigative individuals, which means that they are quite inquisitive and curious people that often like to spend time alone with their thoughts. They also tend to be artistic, meaning that they are creative and original and work well in a setting that allows for self-expression.

Is Google UX certificate free? ›

How much does it cost? The Google UX Design Certificate costs as much as a Coursera subscription: $39 per month.

Can you become a UX designer on your own? ›

Can You Become a UI/UX Designer on Your Own? Yes! Self-taught UX/UI designers exist, but learning user experience or user interface design on your own can be difficult. You'll need to create your own learning path, which can be a fraught process without any prior design knowledge.

Is Google UX design course on Coursera free? ›

Enroll for free. - Offered by Google. Start the UX design process: Empathize, Define, Ideate is the second course in a certificate program that will equip you ... Enroll for free.

How much does a UX designer earn with Google certificate? ›

How much does a Google Ux Design make? As of May 22, 2023, the average annual pay for a Google Ux Design in the United States is $120,551 a year. Just in case you need a simple salary calculator, that works out to be approximately $57.96 an hour. This is the equivalent of $2,318/week or $10,045/month.

Is 50 too old to become a UX designer? ›

There are challenges, of course, but you're never too old to become a UX designer. Let's walk through some relevant discussions on how to become a UX designer with no experience even if you're in your 50s right now. The playing field for UX is wide open, and the opportunity is there if you want it.

Can I be a UX designer if I can't draw? ›

Contrary to popular belief, if you want to become a UX designer, you don't need to learn how to draw. Typically, when people see the word 'designer,' they automatically think about the arts, and therefore drawing can come to mind. The only thing that UX designers draw is usually sketches.

Can a self taught UX designer get a job? ›

UX is a relatively new field with only a few specialized degree programs available. Some of the best UX/UI designers started their careers either in a related field or through experience. Fortunately, this also means that a lack of formal education probably won't stop you from landing your first UX/UI designer job.

Do UX designers get paid well? ›

Working as a user experience designer typically involves leveraging a wide range of technical and soft skills. And UX designers are often compensated well for their expertise.

Does UX involve coding? ›

Do UX designers need to know how to code? User experience design does not require coding. However, understanding the basics of coding can help you as a UX designer. Understanding how software development works gives you a better understanding of what's possible, allowing for more efficient work and better designs.

Can I become a UX designer in 3 months? ›

A quick google search of “UX design bootcamps” will yield dozens of options—no two bootcamps are exactly alike. UX Bootcamps can take anywhere between 2 to 10 months to complete. In general, UX bootcamps introduce students to basic UX concepts and guide them through projects so they can begin building a portfolio.

Do Google certificates actually help? ›

The simple answer: Yes. These certificates are a great way to boost your resume and give you the tangible skills required for entry-level positions in these competitive fields. Google Certificates are a great choice to add skills to your resume, as: They are designed for beginners.

How much of Coursera is free? ›

The Coursera Courses Option provides 1,800+ free courses. Courses help you gain new knowledge and give you completely free access to all the class materials. Full Course, No Certificate allows you to access all course materials but not gain a certificate. Purchase Course allows you to earn a Certificate.


Top Articles
Latest Posts
Article information

Author: Velia Krajcik

Last Updated: 12/08/2023

Views: 5986

Rating: 4.3 / 5 (74 voted)

Reviews: 81% of readers found this page helpful

Author information

Name: Velia Krajcik

Birthday: 1996-07-27

Address: 520 Balistreri Mount, South Armand, OR 60528

Phone: +466880739437

Job: Future Retail Associate

Hobby: Polo, Scouting, Worldbuilding, Cosplaying, Photography, Rowing, Nordic skating

Introduction: My name is Velia Krajcik, I am a handsome, clean, lucky, gleaming, magnificent, proud, glorious person who loves writing and wants to share my knowledge and understanding with you.