UX Design Project Guide - PDF Free Download (2023)

UX design guidelines


For UX designers on site or in production

Russa Unger and Caroline Chandler

Taokeng Publications

UX Design Project Guide: For Field or Plant UX Designers, Russ Unger and Carolyn Chandler

New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (fax) Find us online: www.newriders.com To report bugs, send an email to[email protected]New Riders is a division of Peachpit, part of Pearson Education. Copyright © 2009 Russ Unger and Carolyn Chandler Acquisition Editor: Michael J. Nolan Design Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laflamme Copy Editor: Leslie Tilley Proofreader: Suzie Nasol Typesetting: Danielle Foster Index: Design Analysis: Valerie Mimi Heft Cover Production: Andreas deDanaan Interior Design: Mimi Heft

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

Disclaimer The information in this book is provided "as is" without warranty of any kind. Although every precaution has been taken in the preparation of this book, neither the author nor Peachpit shall be liable to any person or entity for any loss or damage caused or alleged to be caused, directly or indirectly, by the instructions contained herein. book, or from any Description of the Computer Software and hardware products.

Trademarks Many of the names used by manufacturers and retailers to distinguish their products are considered trademarks. If these names appear in this book and Peachpit is aware of a trademark claim, these names will appear as requested by the trademark owner. All other product and service names mentioned in this book are used for editorial purposes only and for the benefit of their respective companies and are not intended to infringe on trademarks. Neither this use nor the use of any trademark is intended to convey endorsement or other affiliation with this book. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 Printed and bound in the USA.

Kudos to UX Design Guidelines If Russ Unger and Carolyn Chandler were wizards, the league would prosecute them for revealing their best-kept secrets. Luckily for you, it's not. Russ and Carolyn have gathered wisdom previously known only to the most experienced UX project leaders and codified it for all to see. Now you can learn the essential secrets to executing great UX projects. Jared M. Spool, CEO and founder of UI Engineering;

Is there a book that tells you everything you need to know about user experience design? No, is there a book that does most of the work for you? There are. Carolyn and Russ provide a solid foundation for project planning and management. It's an essential handbook for anyone dealing with competing methodologies, endless meetings, and all the moving parts of UX design. Dan Brown, author of Communication Design

This book is the perfect introduction to designing great products for real people. But it covers more than design - it covers everything to do with design: managing projects, collaborating with people and sharing ideas. Great all-rounder. Donna Spencer, author of Card Sorting: Designing Usage Categories

It is a practical, accessible and deeply human guide to very human action: working with people to do great things for others. Steve Portigal, Portigal Consulting

If you've heard of author Wil Wheaton, you'll understand why I admire Russ Unger so much. Russ' experience and guidance was the foundation upon which Monolith Press was built and designed, and he was one of the most valuable contributors I have ever worked with. Wil Wheaton, author of Dancing Barefoot, Just Geeks and Happiest Days of Our Lives


Acknowledgments Russ Unger This book would not have been possible without the support of my family, friends, colleagues, and many people I would never have met before hitting my first keys. My beautiful wife Nicolle, who willingly married a prominent geek, managed to parent through most of this book. Our daughters, Sydney and Avery, were constantly pushing and coaxing their comatose dad to dance, sing and play Spore. I subconsciously think that writing a book about a new born in the family is not much of a challenge. I figured it out pretty quickly. Nicolle has come to my aid many times, allowing me to focus on this project. He is the hero I rely on the most. in the midst of chaos, he keeps order in our house. He's the center of our world here, and he lets us go too easily. Nicolle, Sydney and Avery made me look like a good dad and I'm grateful for that. I live in a house with three girls and I can't imagine loving any of them for less than I can give. Carolina kept me going. Sometimes it feels like a project never starts or ends. He's always pushing things forward, exploring ideas and keeping us moving in the right direction. The collaboration was great and I learned a lot thanks to it! It's definitely a great UX yin to my UX yang. Michael Nolan is our shopping editor and is a great guide. Michael was honest and kind, really helped make things go smoothly. Rebecca Freed was juggling all the time, managing every aspect of the book, following up with us, and sending e-mails late at night. Unfortunately, he often gets almost immediate replies from me! Linda Laflamme was our development editor, and as I got used to her Red Feather of Doom, it became clear that no matter how much I tried to overwhelm her with unfinished thoughts and long sentences, she always steered me in the right direction. Leslie Tilley improves the sentence. Tracey Croom combines elements of production, layout and graphics. a true book is born. Steve "Doc" Baty read every chapter before it saw the light of day in the Peachpit office. I would often send funds to Steve around 2am and he iv


He will submit his comments by 5 am, which is not easy. Remember, Steve is in Australia, but he's still impressive. It's hard to believe this book would have made it to store shelves without Steve's consistent help and quick turnarounds. Brad Simpson (www.i-rradiate.com) takes whatever artwork I throw at him and turns it into beautiful printables all while juggling his life, two teenage sons, and a busy work schedule. Brad could have easily left at any time, but he was a true friend, interested in the project and willing to support me. I'm not sure if there will be enough steak dinners to reward my efforts, but I'll work hard to make it happen. Brad, thank you for giving many days off and late nights to support this. Mark Brooks made me panic a few times when I was trying to pass the information required for a visual that was beyond my time and/or capabilities. Mark stepped in and saved the day more than once, for which I cannot thank you enough. Mark was brilliant, made mistakes and was the guy I wanted to be. Jonathan Ashton wrote an entire SEO chapter for us. After speaking with Jonathan for 5 minutes, I knew he was the right person for the job. His chapters alone are a great reason to buy the book and it's nice to have him around. At the last minute, Jono Kane entered. Jono is a web developer, interaction designer and prototyper at Yahoo and his support and help during the development of Chapter 12 was invaluable. Lou Rosenfeld really helped push it. In addition to writing O'Reilly's Information Architecture for the World Wide Web, Lou is brilliant, kind, approachable, and always ready to help others in our field. You'd be hard-pressed to find someone as generous and generous as Lou. Christina Wodtke helped me introduce myself and make contacts. Without Christina, I'm not sure where we'd be today, but she probably wouldn't be "in print." In addition to being "the author to read," she is also someone who is always there to offer advice and insight. Many UX designers credit much of their expertise to Christina's tireless efforts to expand our horizons through constant innovation. Thanks


Will Evans and Todd Zaki Warfel have generously provided quality materials that you can use as templates for your own. They are truly brothers who give of their time and talents without question or concern, often in split seconds. They are great members of our UX community - you want to meet them and work with them - and I'm lucky to have them as friends. I certainly cannot do justice to the gratitude I owe to these two men. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING gang), and Wil Wheaton have provided me with wonderful friends , true fans and loyalists. I'm lucky enough to have these names on my list of people I know and I'm a big fan of everything they do. Their support has been an immeasurable benefit in everything I do. These wonderful people went out of their way to help me, and I am grateful for the generosity of their advice, anecdotes, and access to resources: Tonia M. Bartz (www.toniambartz.com), Chapter 7; Steve "Doc" Baty, (www.meld.com.au), Chapters 3, 11, 14 and "A Quick Guide to Meetings"; Mark Brooks (www.markpbrooks.com), chapters 3 and 11; Leah Buley (www.adaptivepath.com), Chapter 11; Dave Carlson (www.deech.com), Chapter 11; Will Evans (www.semanticfoundry.com), chapters 7, 10 and 11; Christopher Fahey (www.behaviordesign.com), Chapter 14; Nick Finck (www.nickfinck.com), Chapter 10; Jesse James Garrett (www.adaptivepath.com), Chapter 10; Austin Govella (www.grafini.com), Chapter 11; Jon Harden (www.jonhadden.com), Chapter 12; Whitney Hess (www.whitneyhess.com), Chapter 11; Andrew Hinton (www.inkblurt.com), Chapter 10; Gabby Hon (www.staywiththegroup.com), Chapters 3 and 11; Kaleem Khan (www.uxjournal.com), "A Quick Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), Chapter 14; Livia Labate (www.livlab.com), Chapter 7; Michael Leis (www.michaelleis.com), Chapter 11; Troy 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 Quick Guide to Meetings"; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), chapter 11; Stephanie Sansoutie (www.linkedin.com/in/smsansoutie), Chapter 11; Kit Seeborg (www.seeborg.com), Chapters 3, 11 and "A Quick Guide to Meetings"; Josh Seiden (www.joshuaseiden.com), Chapter 7; Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and "A Quick Guide to Meetings"; Samantha Soma (www.sisoma.com), "A Quick Guide to



Conference"; Donna Spencer (www.maadmob.net), Chapter 7; Jared M. Spool (www.uie.com), Chapter 7; Keith Tatum (www.slingthought.com), Chapter 12; Todd Zaki Warfel (www. messagefirst.com), Chapters 7, 12 and 14. I would also like to thank Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest SXSW , Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton - and everyone at Manifest Digital and everyone at Draftfcb. Inevitably I miss someone, and I hope it's not personal.", and I try to keep up with everyone. If I miss you, let me know and I'll catch up! Finally, it's important to remember that without organizations like the Institute for Information Architecture, the Interaction Design Society, etc. it would make it impossible to connect with many of the people mentioned. If you are interested in the field of UX design, check out these organizations, join and get involved!

Caroline Chandler Many of us have dreamed of writing a book at some point in our lives. Without Russ, I don't know if I would have been motivated to do it. His energy and passion helped us find the right people at the right time, from the Peachpit team to the UX industry leaders who had a huge impact on what you see on these pages. He is truly one of the biggest connectors in our field with a passion to connect people day and night. Also, I think he's sent more tweets in a day than I have since I've been on Twitter! Russ is grateful to the many people who have helped us tremendously. I won't repeat all those names, except for Steve Baty, who read all our chapters in whatever raw form we could throw at him, and at 2am (his time) Still managed to sound enthusiastic. John Geletka also provided thoughtful comments and interesting discussions, bringing sparks and perspectives to many disciplines. And of course the Peachpit team. I will never forget the first chapter by Linda Laflamme. It's not pretty (despite her very witty suggestion). she patiently



He guided me through the editing process and helped me refine the process to be more suited to a one-off white paper than a full book. Now I even add transitions to casual conversations with colleagues! Speaking of which… Kristen Mortensen aka Morty is my partner in crime when it comes to graphics. The diagrams and charts you see in my chapters are the result of her hard work - I know how hard she works as we work on many of the same projects for clients at the same time and we both try to meet chapter deadlines. Morty is one of those visual designers who is solid in visual and interactive design and it's a joy to work with everyone on designs and bringing concepts to life. Her integrity and focus on quality make working with her a pleasure and an honor to work with. A huge thank you also goes to all the staff at Manifest Digital for their amazing support over the last few months. Jim Jacoby brings a special combination of business acumen and UX perspective, along with his Zen-like calmness that helps me get through stressful times. Jason Ulaszek is one of the most passionate people I know in UX, with an endless knowledge of tools and techniques. I don't know where he makes room for all this! Additionally, Brett Gilbert and Jen O'Brien have made invaluable contributions in some of the many roles they have worked with UX designers. I would also like to thank the members of the Manifest UX team for their inspiration and patience as I addressed the progress of the "book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Rui. Always a pleasure to work with you. I thank you every day for your humor and insight. To the rest of the Interaction Design Society, thank you for sharing your experiences and being an active member of my beloved UX community. I would like to give a special thanks to Janna Hicks DeVylder and Nick Iozzo who have been instrumental in the growth of the Chicago Chapter as they continue to find new ways to grow a vibrant network of smart people. Finally, I would like to thank my family, friends and Anthony, who patiently endured my disappearance and checked to see if I was alive. You have a lot of checks to cash and I look forward to spending time with you!



short introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . fifteen

Chapter 1:

Dear UXD. . . . . . . . . . . . . . . . . . . . . . 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 General definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

About UX designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Let's get started! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Chapter 2:

Project ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Specify the location type. 10 Brand image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Marketing Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Source of content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Task applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 e-commerce sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 e-learning applications. 20 social networking apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Choose your hat. 21 Information Architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 researcher users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you may play or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Know the company culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

they cooperate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

For consultants and freelancers. . . . . . . . . . . . . . . . . . . . . . . . . . . 39 sentences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Create a request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41



cover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Version History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Design overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 The plan is coming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 field of work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Materials provided. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Title and Rights. 49 Additional costs and charges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Statement of work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Chapter 4: Projects

objectives and methods. 56 Reinforcement of project objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

How can UX designers help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Explore drawing methods. …………………… 63 Flexible methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 To How does this approach affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 5: Business

To require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Collect ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Create an agenda for the meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82



Chapter 6: Users

Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating a Property List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Choose a research technique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 user interviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Context Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 focus groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 kinds of cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

after research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

112 What is a role? 113 Why create a role? 113 Searching for Role Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Creating a role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

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

superior role. 122 Final Thoughts on the Character. 125 Chapter 8: Users

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

Site technology, planning and infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and other scripts . . . . . . . . . . . . . . . . . . . . . . . . . 130 Content management system. 133 Domains, directories, and URL structures are important. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Contents: Kings who were (and are) and will be. . . . . . . . . . . . . . . . 135 Naming conventions and combat terminology. . . . . . . . . . . . . . . . . . . . 136 Metadata, headings and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136



hair splitting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Use the location map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep your content up to date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

The popularity of the link is explained. 139 Normal distribution of link popularity. 139 Footer Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Links within content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

game layout. 141 White and black hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Maples and door sides. 142 Spam links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Some final thoughts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

From definition to design. . . . . . . . . . . . . . . . . . . . . . 144 Feature Conceptualization and Visualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Basic storyboarding process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitate the prioritization process. 150 Keep good volume. 154 Development Ombudsman. ... .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Plan your events and documents. 162 Chapter 10: Locations

Maps and mission progress. 165 What is a sitemap? 166 What is workflow? 166 Craft Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Basics of Sitemaps and Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 stack pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Decision Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Links and arrows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171



Misplaced and unevenly placed objects. 172 Incorrect text. 172 No pagination. 173 A simple sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Advanced Sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Workflow. 178 Complete Quest Fluency has been improved to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.181 strips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Chapter 11: Wireframe Models

and annotations. 185 What is a Wireframe Model? 186 What are annotations? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Create skeletons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Trading Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Start simple: design a basic wireframe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Getting Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Wireframes and Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Exercise: Draw a home page wireframe. . . . . . . . . . . . . . . . . . . . . . . . 195 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Result: Designing the skeleton of the home page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When Wireframes Grow Up and Find Their Way in the World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Design exercise continues: Which design is correct? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

One final note on wireframe rendering. 202 Chapter 12: Prototyping.

204 What is prototyping? 205 How many originals do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 paper originals. 206 Digital Prototyping. 207 Wireframes and real-world prototypes. 207 HTML and WYSIWYG editors. 209 Additional prototyping tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214



Work with developers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Prototype example. 217 What happens after a prototype is created? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Test with users. 220 Concept exploration. 221 tips for exploring visual design patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Choose a method. 227 Research design. 229 Recruitment and logistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and presentation of results. 243 Create an offer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

From design to development and beyond. ... 247 and so it ends... ... Design, development and quality assurance. 248 Testing the project with users (again). 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 ... issue! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 forces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Online opinion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Post-release activity. 253 Post-release analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 with users - run project test (again, again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Everything is ready, right? 255 It's like starting from the same… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Index


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


Introduction Why We Wrote This Book Welcome to the User Experience Design Guide. Somewhere there's a UX design student who can't sleep because he doesn't know what it's like to work on a real project at his new company. Across town, a visual designer with extensive design experience was eager to take on the new responsibilities of defining the user experience for their website. They are two people at different stages of life, but with a similar need: to understand how to integrate UX practices into the live context of the project. The purpose of this book is to provide the necessary tools and framework for using UX tools and techniques in your workforce. As you will see in many of these chapters, we are not trying to be all things to all people, but we are trying to give you the basic information and knowledge you need to have to perform the many tasks you will be called upon to do. Appointed as a user experience designer. In addition to our own examples, we provide examples to help you identify ways to speed up your core material and allow you to combine information and create newer, better, and even more tailored content for your own purposes. We hope we have explained well that this is a very good approach to UX design projects. We are nothing if we are not constantly trying to learn and improve (whatever we do) with each iteration. So, in a sense, we are in that space. Quote from Russ As a mentor at the Information Architecture Institute (www.iainstitute.org), I've noticed a pattern among the people I work with: most either struggle to find work or don't meet the expectations of future employers Some Well-educated, but their UX design skills are not always properly applied in a practical design environment. The same theme ran through many of the talks I had at the Information Architecture Summit 2008 (www.iasummit.org).

to insert


The idea for this book—which answers many of these common questions—began to take shape. I don't remember if it was Caroline or I who sent the first email, but I do know that in her I found a helpful and capable co-author who helped me refine what eventually became the book idea. Carolyn's Words Over the years I have been fortunate to build and manage UX teams. I say "lucky" because I've found that UX designers often have a good balance of traits that are fun to work with, a combination of right-brain intuition and left-brain logic. When I interviewed to form these teams, one thing really stood out: A related background like Human Factors or Communications Design is a good indicator that someone is involved in UX design, but not the number one person in Team Fit or the project. Equally important, if not more important, is one's ability to have a counselor mindset. This means having a positive attitude, trying to understand and include others throughout the project, and - most importantly - focusing on real impact on users and customers. This mindset means taking the time to understand the viewpoints of other project participants, making arguments, and compromising when necessary. It takes experience and hard work to establish this mindset, but an open mind, a solid foundation, and a good set of questions (with the courage to ask them) can take you far. This book may not have all the "answers", but it will ask you questions to help you find them.

Who should read this book The UX Design Project Guide provides a broad introduction to UX design in the context of a project. Anyone interested in UX design should find something for themselves here. We pay particular attention to the following groups: Students taking UX design courses such as human-computer interaction or interaction design who want to supplement their courses with information on how to apply what they have learned in real-world situations where communication and cooperation is essential. necessary.


to insert

Professionals who want to deepen their knowledge of key UX design tools and techniques and improve communication within the team about the roles involved. Chapter 3 is also particularly suitable for freelancers who need to create their own proposals. A UX design team leader was looking for a book to help his team incorporate design best practices into their UX design activities. Any project team leader wants to learn more about how UX design fits into their projects, what the value is, and what to expect from a UX designer. If you need…

Then you must read...

Define UX design and understand what attracts people to this area

Chapter 1: Tao UXD

Ask important questions before you start a project (or at least before you start working on it)

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

Start with productive meetings, clear goals, and easy-to-understand acceptance points

E-Chapters: A Quick Guide to Meetings Chapter 4: Project Objectives and Approach

Well-defined and easily prioritized design requirements of business stakeholders and 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: Personas Chapter 13: User Design Testing

Choose and use tools and techniques that allow you to quickly present visual ideas to your design teams

Chapter 10: Sitemap and Workflow Chapter 11: Skeleton and Annotations Chapter 12: Prototyping

Make sure your website is easy for users and search engines to find and search

Chapter 8: User Experience Design and Search Engine Optimization

Once development begins, communicate with the design team and refine your design

Chapter 14: Transition: From Design to Development and Beyond

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

to insert


Note on Methodology There are different approaches and approaches. We do not advocate the superiority of one method over another. The purpose of this book is to focus on the steps common to most projects: defining project requirements, designing experiences, and developing and deploying solutions. The degree of overlap between these steps will vary considerably depending on the design approach used (details in Chapter 4). For the most part, our framework takes a loosely linear approach starting with the definition stages - but at each stage we use facilitation and design techniques where they are most useful.

This book is not an encyclopedia of all technologies. The UX field is full of creative people who are always trying new ways to solve design problems. Including all of these methods here would make for a longer book - and one that would quickly become out of date. We have included here the most commonly used techniques, the specifics of UX design. We've tried to provide enough information to pique your interest and allow you to share these activities with other project members - including basic procedures for each technique and additional links to books or websites to help you implement them once you've chosen the path your. Your guide to becoming a project manager. Good project management, including setting and tracking project goals, schedules, and budgets, is key to the success of any project. We won't go into the details of how to become a project manager or how to choose a particular project approach. We discussed the skills UX designers bring to projects to execute effectively, such as facilitation and communication, as well as the ability to articulate and maintain focus on project goals. These skills will help you become a project management partner. The only or perfect process or method you can use. We don't have all the answers - nobody knows today. The field of UX design is relatively new and we are all trying to improve our status quo. You can find trials and errors, modifications and improvements, and feedback


to insert

Advice from others will help you tailor the process to your needs. When you find something that works for you - share it! Let us know!

How to use this book There are many excellent resources available to UX designers. We cover a wide range of topics here, but highlight resources that will allow you to explore these topics at a deeper level, depending on how much time you are willing to spend. To help you understand how long each appeal typically takes, we've broken them down into three broad categories:

Surf links retrieved with a surfboard are shorter articles (usually available online) that take 5 to 30 minutes to read.

Snorkeling Those who encourage snorkeling are longer online articles, white papers, or short books, ranging from an hour to a weekend of reading.

Deep Diving The ones called with the diver's helmet are longer books that can take more than a weekend to read. contain an in-depth coverage of the subject.

to insert


This page has been intentionally left blank


Tao UXD Curiosity meets passion meets empathy It's important not to stop questioning. Curiosity exists for a reason. When one contemplates the mysteries of eternity, life, and the wonderful structure of reality, one cannot help but be amazed. It is enough if every day you try to understand a little of this mystery. Albert Einstein

Curiosity is nature's first school of education. smiling Blanton

Passion and purpose go hand in hand. When you discover your goal, it usually turns out to be something you're very passionate about. Steve Pawlin

A great human gift is our ability to empathize. Meryl Streep


you are welcome

Simply put, this chapter is for you—and others interested in user experience design (or UX design for short).

If you're reading this sentence, you're a weird person. You want to know how things work, from doorknobs to airplanes to the things around your neck. First of all, you want to know what excites people. You see, things are not black and white. there are so many shades of gray to discover! Sure, you can drive your peers crazy at times by always willingly playing devil's advocate, but that doesn't mean you can avoid trying to see the other side of the coin. Lucky! The field of UX design attracts curious people who like to use many shades of gray. We look for patterns and thrive thanks to organization and structure. We connect the dots. We're constantly chasing the next piece of the puzzle, and when the puzzle is solved, we're looking for ways to make it better! We can be analog or digital. At home we have pencils and paper, whiteboards and dry markers, notes and markers. We talk about Visio and "Graffle" and we live in a world of boxes and arrows connected to multiple computer screens. We're not just curious. We are full of passion! We are passionate about brainstorming and facilitating conversations. Our passion is to create things that matter to both those who use them and those who create them. Surprisingly, we are most proud when we create something so good that people don't realize how good it is! Of course we have empathy. When we have bad experiences, we can feel them deep within our being. Even worse, we immediately try to find a solution to the problem. We know what it's like to get an unexpected response to a seemingly simple request - we don't like it! We don't want users - people like us - to have to endure the confusion and feeling of inadequacy that usually accompanies a bad experience. 2

Chapter 1: Tao UXD

When you combine this almost constant childish curiosity with an unparalleled passion for "doing what we do" and an awareness of how others feel, you get a vibrant community of professionals who love to talk, ask questions, share solutions and bugs - all in the name of doing the right thing. Welcome to the community of user experience designers.

What is user experience design? There are many definitions of UX design. After all, this is a field that thrives on defining things. Granted, sometimes we don't "get the damn thing right" when it comes to the parts of the whole, but at least we know what the whole is. In this book, we will pay particular attention to two definitions: the broad definition of user experience design and the definition we will use in the context of this book.

Broadly understood, user experience design is the creation and synchronization of elements that affect the user's experience with a particular company in order to influence its perception and behavior.

These elements include things users can touch (such as physical products and packaging), hear (advertisements and audio subtitles), and even smell (the smell of freshly baked bread in a sandwich shop). It includes things that users can interact with in ways other than physical ones, such as digital interfaces (websites and mobile phone apps) and physical people (customer service representatives, vendors, and friends and family). One of the most exciting developments in recent years is the ability to combine elements that appeal to these different senses into richer, more complete experiences. Smell and sight are still a long way off, but other products continue to blur traditional boundaries.

What is user experience design?


Don't Forget the Tangibles While we focus on the digital aspects of the user experience, these types of interactions don't happen in a vacuum. The impact of tangible experiences must be considered when designing digital products. The environment in which the user works is important, as is the physical product (screen, keyboard, and other input devices) that affects the user's interaction with the work. Chapter 6 contains techniques to help you understand the influence of context. Also, don't forget other touch points between the product or company and the people it interacts with. After all, a corporate brand is influenced by many factors, and the brand experience is not limited to a computer screen or a mobile phone. The best website design may not compensate for poor customer service or satisfaction with well-designed packaging after the product is delivered.

Figure 1.1 The modern classroom experience combines analog and digital.


Chapter 1: Tao UXD

Tangible experiences such as classroom learning are increasingly dependent on digital applications. Similarly, experiences that were once personal, such as choosing a karaoke system at home, are increasingly enriched by social interaction.

Figure 1.2 Online reviews are an important influencer for consumers.

Our Goal As you can see, the scope of UX design is wide and constantly evolving. For the purposes of this book, we will focus on projects that focus on designing digital experiences—particularly interactive media such as websites and apps. To be successful, UX design for these products must consider the project's business goals, the needs of the product's users, and any constraints that could affect the viability of the product's functionality (such as technical constraints, project budget constraints or schedules ).

What is user experience design?


Free samples of the new nutrition bars given out during the marathon


package for a pair of shoes

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

Tangible SMS function

customer service number



Our Attention Read Product Reviews Online Search the Online Archive View Targeted Ads

Live digital customer service chat

About UX Designers While curiosity, enthusiasm and empathy are common characteristics of UX designers, there is also a desire for balance. We're looking for a balance, especially between logic and emotion, like Spock and Kirk or Dane and Dane in this episode where his emotion chip overloads the positronic relay. did you understand. To create truly memorable and satisfying experiences, UX designers need to understand how to create a logical and workable experience structure, and they need to understand the elements that are important to creating an emotional connection with product users. The exact balance may vary by product. An ad campaign for children's toys has a different balance than an app that tracks information about patients in a hospital. Products designed without understanding the needs of both parties are likely to miss out on a truly memorable experience — and the interests of the companies behind their products. Note For more information on emotional design, see Donald Norman's book Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).


Chapter 1: Tao UXD

Achieving this balance requires a high degree of empathy: the ability to immerse yourself in the world of potential product users to understand their needs and motivations. UX designers conduct research to develop this understanding (see chapter 6) and create tools such as personas (see chapter 7) to help other members of the design team stay focused. Remember that emotions are only part of the big picture. Use the logical aspect to lead you out of the abyss and focus on the task at hand. In most cases, you will be working with a budget based on the time and materials required to complete the project. You have to understand that sometimes you have to fish or cut the bait.

Where UX Designers Live You are not alone. Look around and you will find many organizations and communities where you can grow as a UX designer. In addition to mailing lists, online resources, and communities of really smart people, many of these organizations sponsor events or conferences that can help you expand your horizons while narrowing your career scope. Many companies host events designed to provide lifelong learning, including the Web Applications Summit and User Interface Engineering by User Interface Engineering, Adaptive Path's UX Intensive Conference, and Nielsen Norman Group's Usability Week. In various cities, there are also more and more "No Meetings" created by groups of motivated individuals, independent of a specific company or association.

Where UX designers live


Some professional organizations also sponsor annual conferences. Table 1.1 contains a short list of some of the more well-known organizations, their websites and the events they host. Table 1.1

Sample UX organization



Main meeting (usually held)

Interaction Design Association (IxDA)


Interactive (early February)

Information Architecture Institute (IAI)


IDEA Conference (September/October)

American Society of Information and Technology (ASIS&T)


IA Summit (March)

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


CHI (early April)

Association of Usability Professionals


UPA (June)

let's start! You already did. It's time to understand why you picked up this book in the first place. Turn the page for an in-depth look at how UX design exists in the field of design. But don't stop there - this book is your guide to getting started. It's full of examples to help you with the many tasks you'll be performing. We also try to provide more examples to help you expand and find your own best ways to create results that will be useful for your team and customers. Stay curious, enthusiastic and empathetic! Challenge yourself to find new ways to inspire others to create the perfect user experience. Of course, that's before you start upgrading it.


Chapter 1: Tao UXD


Planning the project ecosystem in terms of project needs, roles and culture Starting a brand new project? you're in. Regardless, take some time to consider the dynamics and context of the project—issues that affect you and the rest of the project team. What types of websites or apps are involved? What roles and skills are required? What is the company culture? Answering these questions will help you define your 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 a website or app, many of these challenges will involve specific features and functions, such as creating a way to share photos online with friends and family or reorganizing information on your intranet so that content is more easy to find and share. However, all projects have a larger context around these specific design goals that must be understood and incorporated into the designs. This context is the "ecosystem" of the project, which includes the environment you'll be working in (company culture), the general type of work you'll be doing (such as the type of website you're designing), and the people you'll be interacting with ( including their roles and responsibilities). If you take the time to understand the project ecosystem, you will gain knowledge that will help you throughout the project. You can communicate your responsibilities and ideas more effectively and help other team members anticipate design needs they may not have considered. To help you, this chapter describes the different types of projects you can work on, the roles you can play, the people you can rely on, and the differences in their involvement depending on the type of website or application you're designing . Finally, the chapter discusses some elements of corporate culture that can affect how you work on a project. NOTE Depending on the project structure of the client company, a particular project may involve the design of more than one website or application. For simplicity, this book assumes that a project involves designing one type of website. If you have multiple departments, review each one individually to make sure you are playing the right role on the project team.

Identifying Site Types Although there is no black and white distinction between one type of site and another, some relative differences can be identified in the scope and nature of a site. Knowing these similarities and differences can help you set your own design goals. These are general issues that need to be addressed

Features included in the website's visual and interactive design (eg "explain the company's business model") or need to be represented (eg "show the company's responsiveness to customers").


Chapter 2: Project Ecosystem

Consolidation of the main objectives of the project (see Chapter 4). Find out which departments or business units can (or should)

Participate in business requirements gathering (see chapter 5). Determine how best to incorporate user research (see chapter 6). Ask questions about the systems and technologies that may be involved.

Your site may be closely related to one of four types:

Brand image - a durable online platform that facilitates the relationship between the company and the general public (anyone interested in its product or service) General public for a limited time Content source - an information store that can consist of many types Media composition (articles, documents, videos, photos, tutorials) designed to inform, engage or entertain users Task-based application - A tool or set of tools designed to enable users to complete a basic set of tasks or workflows

In the following sections, we'll take a closer look at each of these types, discussing their characteristics and how they affect the challenges faced during the website or app design process. We'll also cover the most common cross-cutting projects—e-commerce, online learning, and social networking—that involve more than one type.

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

Specify the location type


Dirk Knemeyer gives some excellent definitions of brand in his article "Brand Experience and the Web": Each of us. The science of branding is about designing and influencing people's minds - in other words, creating brands.

Browse For more information on the difference between a company's brand experience and a company's efforts to build it, 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 of how a website's UX design can affect a person's brand experience, read Steve Baty's Brand Experience in UX Design: www.uxmatters.com/MT/archives/000111 .php.

Businesses can do a lot to influence their brand associations, from running memorable advertising campaigns to expressing brand attributes (such as "responsiveness" or "value") through the functionality and design of their website. All of a company's websites can have some impact on a company's brand either directly (by showing which websites customers can visit) or indirectly (by providing key services that customers use, such as customer support). However, a branding website focuses primarily on displaying information about the company's brand and values. They provide channels for direct interaction with customers and extensive online channels for those interested in learning about the company or its products. The brand presence site is usually the company's main .com or .org site, such as GE.com, or for larger and more distributed companies, the main business unit sites of various sizes, such as GEhealthcare.com. Different product lines also often have their own unique brand images online. For example, Pepsico.com has a brand identity while Pepsi.com has its own unique identity.


Chapter 2: Project Ecosystem

If you work on a branded website, you likely design for a variety of user groups, including current and potential customers, investors, partners, media (such as news organizations and high-profile bloggers), and job seekers.

Generic Brand Site The company's main home page (company.com, company.org, company.net, etc.) The company's main business unit website (usually a single website)

specific industry, region or large number of products) pages of well-known company sub-brands

Brand Identity Design Goals Often the most important design goals in a brand identity design are: conveying the company's brand values ​​and messages;

Either directly (e.g. stating how important it is to meet customer needs) or through the overall website experience (e.g. ensuring the website works well and highlighting features that encourage customers to interact with company). Provides quick and easy access to company information. You want

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

"What can the company do for me?" and "How does the company do it?" Attract a core group of users and guide them to appropriate interactions

culture, function or content. Help companies achieve goals set for key metrics such as

Number of unique visitors. This is often part of an overall marketing strategy. Later, in the Choose Your Hat section, you'll learn about the different roles that can be involved in designing a brand website. Now let's see

Specify the location type


Among other types of sites you can work on, including those closely related to brand presence sites: campaign sites.

Campaigns Campaign sites are similar to brand exposure sites in that both focus on engaging users with experiences that influence their perception of the company's brand. However, campaign sites are often evaluated on their ability to perform very specific actions for a specific purpose, such as a specific time frame or targeting a targeted audience. They serve not as a funnel to generate interest, but as an engine to generate it. From an online perspective, this usually means that they are in line with your overall marketing strategy and can run alongside other marketing campaigns using different channels, such as TV or radio ads, print ads and other promotions.

Typical Campaign Sites A landing page that promotes a specific offer. This page was created by a

Banner ad from another site. A small website (or microsite) that promotes a specific event. A toy or tool made to take a dip

the movement.

The main purpose of a campaign site is to create a narrowly defined campaign, usually targeting a specific set of metrics. Focus is usually limited by one or more of the following activities: Time - For example, activities that focus on events (such as

conferences) or seasons (such as the holiday shopping season) user groups - such as event products for teenagers or teachers, product bundles and/or specific product uses -

For example, a website showcases kitchen appliances, showing a virtual kitchen with a matching oven, dishwasher and stove


Chapter 2: Project Ecosystem

A campaign that combines these strategies would be a spring campaign to sell garden equipment, combining time and product sets. See Figure 2.1 for an example showing combinations of product sets and user groups. A campaign site can be as simple as a banner ad that links to a .com landing page, or it can be a microsite, which is a small site that usually deviates from the obvious .com branding to deliver traffic based on one or more themed areas A personalized experience. "Small" is relative here - some microsites have only one page, while others have many, but in any case, a microsite is smaller and more focused than a large company brand site.

Figure 2.1 Texas Instruments uses the educational microsite http://timathrocks.com/index.php to present information about the company's graphing computers. This product bundle is intended primarily for use by high school and college students in algebra classes. The microsite maintains the overall Texas Instruments brand association, but is intentionally different to appeal to a younger audience and organize content and features around their needs.

Campaign Design Objectives For the individual or team responsible for designing and implementing a campaign website, the most important design objectives are usually:

Consider a value proposition (the value the product or service brings to the user, e.g. qualify for a quick loan) or some kind of incentive (special offers, contests or entertainment, e.g. online games).

Specify the location type


persuade a core group of users to perform certain actions against the law;

Examples include clicking on a specific point on a brand page, signing up for a newsletter or applying for a loan. When the user does this, it is called a transition. Help companies achieve goals for key metrics such as numbers

Number of unique visitors. This is often part of an overall marketing strategy.

For more details on designing pages to support marketing campaigns, see Landing Page Optimization: The Definitive Guide to Conversion Testing and Tuning by Tim Ash (Sybex, 2008).

Content Sources Content source websites contain repositories of information, possibly in various media types (articles, documents, videos, photos, tutorials), designed to inform, engage and/or entertain users.

Public content source site Corporate intranet An online library or resource center for organizational members A site or site area dedicated to or frequently sharing news

Updated posts (big business blogs may fall into this category) Customer Service Center

Of course, all websites and apps have some content, but some websites put a lot of emphasis on the presentation and structure of the content. Emphasis may be because the site has so much content that it is a challenge in itself, or because certain types of content are of great importance. for example, they can support key decisions or often drive users to the site.


Chapter 2: Project Ecosystem

The main purpose of a content source site is to increase user knowledge and self-sufficiency by providing relevant content, like an intranet. They also usually encourage some action, such as sharing information or buying a product after seeing the product description. Content Source Design Goals A content source site should typically do one or more of the following: Display content that primarily attracts first and subsequent visits to your site. Show company leadership, e.g.

Providing access to the thoughts and perspectives of the CEO or other subject matter experts in the company. Supporting key decisions in user groups. Increase corporate knowledge about the company by presenting ideas

It can be buried in individual sections. This may be part of a broader goal to identify more innovation opportunities. Support users seeking information in a variety of ways. For example,

Some people don't yet know what specific product they need (and are more likely to browse), while others may know exactly what they're looking for (and use the search box more often).

Browse For more information on the different ways users seek information, read The Four Modes of Information Searching 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 designing content sources are: Creating taxonomy structures that fit users' mental models Determining how to integrate systems for organic content development

(eg functions such as tagging and filtering) Design effective search tools to identify site types


Task Applications Task applications can range from a simple calculator integrated into a mortgage website to a full system supporting multiple core workflows. If your project is about the latter, there will be many more roles involved and possibly an extensive requirements gathering process (see Chapter 5 for more on this process).

Common task applications support applications that are specific types of applications

Items such as spreadsheets or printouts, web tools or applications that support basic workflows on your computer

Sites where companies (such as a ticket management application for an IT support team or a customer tracking application for a call center) allow you to access and manage personal information


The main purpose of a task application is to allow users to perform a set of tasks that suit their needs and ultimately the customer's business goals. Design Goals of Task Apps Most task apps need to allow users to do something they can't do elsewhere—or if they can,

Do better ("better" can mean more effective, more efficient, more satisfying or more convenient) Support first-time users with clear instructions and visual prioritization

Support for critical tasks Supports intermediate and advanced users to access quick functions

and deeper capabilities to reduce user load and make full use of system resources

(e.g. data reuse vs. duplicate import requirements)


Chapter 2: Project Ecosystem

Plan and implement considering the degree of change required

Application Users - Preferably with a design that facilitates learning and a communication design that presents value to users One of the biggest challenges in designing work applications is controlling "feature creep". As a project evolves, it's not uncommon for great ideas to come late in the design process or even development. UX design is great for avoiding feature creep because user models (like personas) can be used to identify high-value features and keep them focused throughout the design. If a really great idea comes along late in the process and meets the needs of a high-priority user group and aligns with your site's business goals, your team may be able to justify a change in direction. If the idea doesn't cut through the hype, it's probably not worth the delay and expense.

E-commerce sites An e-commerce site can contain elements of all four types of products because a site primarily used for e-commerce must have its own brand identity, provide content (usually product specifications or product manuals), and facilitate tasks ( search, compare, write a review, review ). Marketing efforts are often closely linked to these sites and may involve multiple marketing teams within an organization. A common secondary purpose of eCommerce website design is to clarify the layout of the website (if custom). as an online market

This interpretation, which is constantly changing, will help set expectations (for example, eBay, Amazon, and Craigslist have very different models). It supports decision making as users move from learning to thinking -

Compare shopping with useful content and features. Redeem points on cross-sell and up-sell experiences

possible, and present these proposals in a persuasive and tactful manner. Build from point of purchase to

delivery point. Communication should take place not only within the website, but also through other channels, such as integration with delivery tracking systems and email communication about order status. Specify the location type


E-learning applications E-learning applications are a cross between content sources and task applications. Course content must be created, which often requires teams to add learning specialist and content specialist (SME) roles for the topics covered. The product is task-based as users typically follow the course flow and may also need to track progress or explore related topics. Some practical courses may also require you to complete assignments. The common goal of the design is to understand the basic knowledge needed to start the course

and to whom it is addressed. Break content into manageable chunks

they understand. Engage students in activities that simulate hands-on learning. Communicate results and progress and make recommendations where appropriate

Next steps in the continuing education process, such as more advanced courses.

Social Networking Apps Social networking apps are primarily task apps because users need to be able to find and add friends, manage their profiles, connect, post, and search. However, they also contain challenges for content sourcing, notably the need to create an organizational structure to manage potentially very large amounts of user-generated content. If a site is essentially given its own identity, it will also have the characteristics of a brand site.

Snorkeling If you're building a social networking application or trying to integrate social functionality into another type of website, this book will help: Designing Social Networks, by Joshua Porter (New Riders, 2008).


Chapter 2: Project Ecosystem

The common goal of social networking app design is to bring potential users closer to the purpose and value of the network. Facilitate meaningful interactions between support and supported users

Features such as image sharing, video sharing and chat support are provided. Protect the integrity of your site by ensuring that people in your network are:

How websites monitor their information and respond to inappropriate behavior. Using and demonstrating community power to promote -

Content available only to active members, such as popular features and reviews. Identifying the types of websites or apps you're likely to use during your project is just the first step. Next, consider the different roles that are often required and how their involvement will vary depending on the type of project.

Choose a Hat When you become a UX designer on a project, you often have to play multiple roles. Whether or not they are formally defined in your client's organization, the roles you play 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've adapted to and which ones you can learn on the job. It's also a good idea to find out what others expect from the responsibilities of these roles. With this understanding, you can express yourself more clearly from the beginning of the project. What is the most common role of a UX designer? Each client company you work for may have a different title for these roles (or no name if it's not an official job for your organization). Typically, you'll encounter the big three: Information Architects, Interaction Designers, and User Researchers. Note Few companies have the size or budget to assign these shared roles to different people. Consider role names when defining projects, but talk to clients about requirements and responsibilities - otherwise they might think you're building too big a team! This focus on responsibilities rather than titles also helps maintain common sense: having many of these roles at once doesn't necessarily mean you're doing a lot of work for people, as responsibilities come and go in different departments. plan.

choose your hat


Information Architects Information architects are responsible for creating models of information structures and using them to design user-friendly navigation and content categorization. When designing websites and applications, common responsibilities include creating detailed site maps (discussed in Chapter 10) and ensuring that information categories and subcategories are clear and user-friendly. Understanding expectations In the field of user experience, the roles of information architects and interaction designers are different (discussed later). Within a given company, however, there are several common distinctions between the two roles, at least when it comes to the needs of a particular project. For example, you might join the team with the title of Information Architect, because that's the historical designation of the role, regardless of whether it actually meets your duties. Should you improve your project team if the title you've been given doesn't match your primary role? If it's a short-term project (eg, four months or less) and you have a position that is widely accepted in an organization with clearly defined responsibilities, trying to change it may not be worth the potential fuss you create. However, if there is no universally accepted title and you believe there is a chance that both roles will need to be represented - perhaps by different people - make the distinction early in the project when planning the engagement and communication you deserve. In general, for more task-oriented applications, it makes sense to emphasize the interaction designer role, and for more content-driven designs, it makes sense to emphasize the information architect role. But it can make a lot of sense to use terms familiar to the client's organization and make sure the team understands how you're defining roles for the responsibility you're taking on. This definition is what you should specify in your job description (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see "Other roles" below). If they are roles


Chapter 2: Project Ecosystem

Represented by different people on the project team, be sure to discuss at the beginning of the project how you will work together.

Interaction Designers Interaction designers are responsible for defining the behavior of a website or application based on user actions. This includes flows between multiple views on the site and interactions within specific views. Typical activities when designing a website or application include creating workflows to show interactions between pages or elements on a website (see chapter 10) 11. Know what to expect if you're working in a small team or on a project that not much focus on creating new task-based features (for example, if you are working on job presentations for brand content categories on a website, contact form and newsletter sign-up form) Interaction designers are likely to be the main players in capturing the design requirements (see Chapter 5). working as an interaction designer on a project with a high level of new features, you will likely have a separate person on your team responsible for drawing up detailed requirements (eg business analyst or product manager) UX designer skills can be very helpful in the gathering process and improving functional requirements, while design experience influences documents such as functional specifications and use cases. Be sure to sit down with the person responsible for gathering requirements and discuss how to best work together.

User Researcher The User Researcher is responsible for providing information about end-user needs based on information generated or verified based on research an individual conducts with users. There are many types of activities that fall under user research and can occur at various points in a project's timeline. (See Chapter 6 for descriptions of common techniques such as user interviews, surveys, and usability testing.)

choose your hat


Knowing what to expect A client company's interest in user research can vary greatly depending on how much importance the project team or project sponsor places on user research. The fact that you discuss the UX project with the project sponsor even before the project begins shows that someone on the client's team knows that representing user needs is a priority. However, those who have worked on computing projects know that introducing research can also cause stress among project team members—worrying that user research will create an obstacle, increasing risk (if we find a bug and have to make major changes to fix it? ) or the value of disproving a particular idea that has gained a lot of momentum. Business stakeholders and project teams may have different expectations of user research, so be clear about what these two groups expect from this role. Clients may also want user researchers to provide insights based on site analytics—tools and reports that show site usage patterns, such as frequently visited pages and common points where users leave the site. Some of the more popular analytics tools come from Google (www.google.com/analytics), WebTrends (www.webtrends.com), and Omniture (www.omniture.com/en/products/web_analytics). You can find yourself in all three roles: information architect, interaction designer, and user researcher. Can you balance all three or are you biting off more than you can chew? This depends in part on the size and timing of the project, but the type of project also affects the extent to which each role can be involved. Table 2.1 describes how UX design roles vary by project type.

Surfing Need a justification for UX design? These articles offer ways to help: "User Experience Is Imperative" by Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Preach User Experience Design for Ten Dollars a Day" by Louis Rosenfeld: http:/ /louisrosenfeld .com /home/bloug_archive/000131.html


Chapter 2: Project Ecosystem

Table 2.1

Shared Responsibilities of UX Design Roles

information architect


Marketing activities

content source

task application

Moderate participation.

Smaller sites have less engagement (like a single landing page). Moderate engagement with larger microsites.

Commitment is high. Content sources require an information architecture with the right balance of structure and flexibility to provide users with a solid foundation and enable planned growth.

Moderate to heavy involvement, with a primary focus on structuring the navigation, unless larger areas of content need to be referenced in some workflows.

Smaller sites have low engagement, and larger microsites or advergames (online advertising games designed to create fun and hype) have moderate to high engagement.

Moderate to high commitment.

Commitment is high. Such designs tend to require the most hard work, as interaction design elements such as user flows and wireframes are key to visually communicating needs.

Because campaigns are often temporary, user engagement is often low. A more permanent solution might use research similar to a brand page. It's also common to use analytics tools to render two or more variations of a given page to see which leads to the most conversions. This is called A/B testing.

Field research, such as background checks, can help teams understand how information is currently being used by different users.

The greater the content challenge, the more the project acts as a source of content.

Interactive project

Moderate participation. The higher the number of tasks, the more the project behaves like a task application.

Involvement of user researchers will vary depending on budget and user access. Typical techniques for each type of project are listed below. More information on these techniques can be found in Chapter 6.

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

Search, tag, and filter capabilities bridge the boundaries between information architecture and interaction design. Content sources can also have content creation and management workflows.

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

Field research, such as contextual queries, can be performed to understand what tasks users are currently performing. However, the most common and well-known technique for involving users in task-based application design is usability testing.

Once the structure is set, usability tests can validate the structure.

choose your hat


Other roles you may have or need Some roles don't usually fall within the scope of a UX designer role, but their responsibilities often overlap with those of a UX designer - especially if you're working on a project where no one else officially has the role and you have skills You can come to the table. Some of the most common overlapping roles are: Brand Strategist or Manager Business Analyst Content Strategist Copywriter Visual Designer Front-end Developer

The following sections describe each of these roles in more detail and discuss how they differ depending on the type of site you are designing. Brand Strategists and Brand Stewards Brand Strategists are responsible for building relationships with key markets by defining and consistently presenting a company's brand elements, which can include everything from brand values ​​(such as "response") to copy guidelines and messaging to editing logos. color specifications and layout. This role typically involves creating or representing brand guidelines and understanding how they relate to different projects. This may also include understanding or defining a target audience that is important to the project you are working on. In most cases, you'll likely work with a brand strategist, but you won't be taking on the responsibility alone. The brand manager does not necessarily set the guidelines, but is responsible for ensuring proper follow-through throughout the project. This responsibility may fall on the project's UX designer or visual designer. If your company's characteristics, values ​​and guidelines are well defined and the website is expected to adhere to them, your role as project brand manager will primarily be to ensure that your results meet these guidelines. Your point of contact outside the project will probably be


Chapter 2: Project Ecosystem

A member of the marketing department, available on a consulting or review basis, but not a full-time team member. If the site aims to expand the brand in some way - for example, to reach a new market - the role of the brand manager can be more active. It is most involved when a brand new brand identity is created or when a company makes significant changes to its brand for successful rebranding. For example, CellularOne completely changed its name to Cingular, which was a major effort from an established company. In this case, you either have a lot of experience in brand development, or you have a clear and close relationship with the head of the company. These key questions will help you understand what to expect from your brand people: Do you already have brand guidelines? If so, how strictly should the project follow them? Who is responsible for setting or maintaining the brand message, the brand

The look and tone of the content (eg casual or professional)? Will it appeal to a new audience it hasn't covered before?

brand definition? If so, who is responsible for ensuring that brand guidelines remain relevant to this audience? Will there be a naming or renaming event? If yes how to design it

involved? (For example, naming a new tool that will be heavily promoted.) For projects that do not have a significant potential impact on the customer's perception of the brand, such as developing an internal application, involving a brand manager can be as simple as as much as an occasional check-in to make sure the brand is well received. Business Analyst The business analyst (sometimes called a business systems analyst on IT projects) is responsible for identifying key business stakeholders, leading the requirements gathering process (see Chapter 5), and acting as the primary liaison between business stakeholders and technology . He is also the primary owner of detailed requirements documents, such as functional specifications and use cases, if required.

choose your hat


The business analyst or product manager role may not exist in your project at all, or it may be one of the most important roles in the entire project process. Mission-based apps and content sources often have this effect, while brand projects and marketing campaigns may not. Task applications will likely require this role. The more features and complexity of the project, the greater the need for dedicated staff and functional documentation. While business analysts aren't typically considered members of UX teams, small UX teams are often asked to fill this role, so it's important to understand what those responsibilities are. Business analysts direct the capture of business requirements, acting as a liaison between technical teams and key business stakeholders. If a business analyst is involved in the project, that person and the interaction designer usually go hand in hand. If it's the same role, the person in charge might be dealing with a lot of documents! To understand what to expect in this area, ask who will be responsible for defining the project scope, facilitating the requirements discussion, and documenting the requirements throughout the project. For small or non-feature-rich projects, project managers sometimes take on these responsibilities. Either way, if it's not you, you'll still know who you need to be in close contact with to ensure your results are in sync. Content strategists are responsible for understanding business and user needs for content across different media (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating workflows and developing new content. Content efforts are often underestimated. A client may have plenty of great content in a medium, such as a printed brochure or video, but that content may not be appropriate for the project you're working on. Also, sometimes people in your customer's organization aren't asked to create content - and they can be surprised when it comes time to populate your product with descriptions, messages, and help topics! If it is high quality content


Chapter 2: Project Ecosystem

key business players in your project, make sure you know who is responsible for: Setting content guidelines for new products (type of content,

tons, quantity). Evaluate the suitability of existing content against it

Guidelines. Develop new content. This will vary depending on the general type of project. Below

A task-based application that may contain copies of manuals, error messages, and help topics. For content sources, this can include articles, news and blog posts. Communicate as a liaison between stakeholders and the technical team

Limitations and capabilities of content management systems. Define different content types with metadata for each (

information that ultimately makes searching and logging more efficient). Content migration planning, including creating templates

Target different types of content and make sure your content is properly tagged and loaded when transferred to your site's content management system. (This is another area where the effort required is often underestimated.) Copywriters Copywriters are responsible for writing the text that makes up the overall experience of a website. In some cases, this copy remains fairly constant from day to day. It usually contains site and page descriptions or page instructions. Contributors may also be involved in the ongoing creation of dynamic content, such as writing content for news or marketing campaigns. Copywriting is one of the gray areas that UX designers often encounter, especially when creating wireframes (see Chapter 11). You can initially place sample text as a text placeholder, such as a website description or page instructions, but eventually someone will need to populate it with the final text that users will see - as many projects don't have a dedicated copywriter, this task can assigned to you by default. It is unlikely that you will be asked to take on a writer role in a well-known domain for brand sites or marketing campaigns. in these cases

choose your hat


Every word will likely be scrutinized. However, if you're developing a task-based application that requires short explanatory messages, error messages, or other types of information that don't necessarily fall within a clear scope of content, you may end up inheriting this writing task (or it will belong to the developer by default) . Ask in advance if a partner is available, and if you can't find one, ask again when you're designing the wireframe. If the work falls on your shoulders, be sure to include that effort when planning activities during the project. Caution: this is a responsibility that is often overlooked or underestimated. Visual Designers Visual designers are responsible for the elements of your website or app that users see. This job involves designing the look and feel to create an emotional connection with users in line with brand guidelines. For example, banking websites often need to appear stable, reliable and easily accessible. Visual design can provide this assurance with visual elements such as color and imagery. This promise is then kept (or broken) through website design and interactions with other company touchpoints, such as the call center. Let's be honest: many people call themselves visual designers, web designers or graphic designers, and there are many websites with poor or satisfactory visual design. There is a big difference between creating an effective, engaging and emotional visual design and surviving. Sometimes survival alone is enough to achieve project goals, and other times it leads to frustration and delays when project sponsors are unhappy or early adopters are not committed to the project. On the other hand, it's easy to focus so much on influencing the visual design that the usability of the design suffers. If you're asked to take on this role and aren't sure if you can make the right impact on the client, take a look at the company's current website and a site or product that the client values ​​to gauge their comfort level. Visual designers often play a very important role in brand identity designs and marketing campaigns and are primarily responsible for effectively communicating a company's brand.


Chapter 2: Project Ecosystem

For content source designs, they may focus on creating content templates (for example, article templates) that can be applied to multiple pages. For task applications, they can provide style guides that can be applied to common interaction elements such as navigation areas and tools (this requires a high degree of collaboration with the interaction designer). Front-End Developer Front-end developers are responsible for creating the technical structure behind the design and flow of the website, as well as the interactive elements of the website such as scrolling menus, expanding content areas, interacting with media elements such as Videos . This work often uses technologies such as XHTML, CSS, Flash, JavaScript, Ajax and Silverlight. Front-end development focuses on website elements directly related to what users see, rather than the support systems that provide the underlying platform (such as databases, content management systems, and the code needed to build the functionality behind the complex functionality ). If you or a member of your team takes on the role of front-end developer, it's important to work closely with other members of the development team to understand expectations and responsibilities. Other important considerations are which back-end systems to integrate with, the method used to generate the HTML code, the need for flexibility in page structure for custom skins, and the expectations of technologies such as Flash. If you are designing a prototype (see Chapter 12), ask who will develop it and what level of functionality you expect. Prototypes designed to simply convey functionality can be built quickly in applications like Flash, but fully functional prototypes that require retrieving actual data (such as the account information the user just entered into a form) must be done in a fraction of time. time and again Collaborate with members of the final development team. Worried about taking on all these roles? Unless you're working on a very small project—or a very small company—you probably won't be doing all of this yourself. The key is to understand what roles you can and are willing to take on depending on the needs of the particular project you are working on. For the rest, you can get the support your project team needs by building a network within the client's company or referring others to fill the need. Let's take a moment to talk about how to do this.

choose your hat


Build a user support network In those areas where you're not sure you can or don't want to tackle, it's time to start asking for help. There are three main ways to do this: It is recommended to add additional team members as needed

It's clear. Educate yourself in key areas where there are gaps - if new responses arise

Opportunities are manageable and you have time to spend on them. Create a support network in your company to help you in critical moments.

Let's take a closer look at how to build a support network. Chances are, there are key resources elsewhere in your business that can help you succeed. You need to measure how much time you can get from these people, as asking for time from an outsider can be a difficult request for a project that is primarily owned by one department. If you don't want to demand too much of their time at first, just ask if you can work (or consult) with them to ensure you get the most out of the main responsibilities of the role. Once you've established a partnership, you'll have a better idea of ​​how much interaction you're likely to need and whether you should make a more formal request to spend time with him. Each company has a different structure and different department names, but here are some common places to look for partners:

A section that can act as a contact point. It can also be a resource for visual designers and content strategists. Visual design and content strategy associates are also available at the address

Program or product management or R&D, business or corporate strategy departments where business analysts and product managers are often found. IT or engineering is usually the best choice for front-end

Developers and others who can help you access and obtain information about web analytics tools.


Chapter 2: Project Ecosystem

If you've recently been hired at a new company and want to work in different departments, one of the best things you can do is identify key people who could become partners and schedule an interview to learn their roles and experience. It starts with a network that you can usually rely on for the long term and gives you a chance to explain your responsibilities (and UX design in general). You can also ask a good question at the end of an interview: "Who else do you think I should talk to?" The answer may help you find someone who may not have been obvious to your primary project manager or customer contact. If you've been with the company for a while, you can still start interviews this way. In this case, it is better to tie it to a specific milestone (eg starting a new project) or company goal with some urgency to ensure high engagement. Make sure your boss knows what you're doing so you don't seem like you're running around. Good communication is key to understanding role expectations and building trust. Another key to gaining trust in a company is understanding its culture, often unspoken expectations about how the company operates, e.g.

Understanding culture culture is a bit like putting Alka-Seltzer in a glass - you can't see it, but it works in a certain way. — Hans Magnus Enzensberger

A company's culture may not be consistent across its geographies, business units, or divisions, but you can often identify key characteristics that affect you and the project or projects you work on. Here are some things to keep in mind when scoping your project and navigating potentially tricky political situations.

Understand the company culture


History We all know the saying that those who don't remember the past are doomed to repeat it, and design is no exception. Understanding how the project or team got to the current state of their requirements can help you understand the challenges you may face during the project. Let's look at some questions you can ask to understand the history that could affect your project. While some of the answers to these questions may seem daunting, remember that something triggered the need to get involved in the project so that the project has a checkered history and continues to be successful. Maybe you are the key to success! However, if many of the issues discussed below seem to apply to you and you don't think you can help them, it could be a red flag. In this case, consider an overall evaluation of the project's success. What are some examples of past projects that seem to be under consideration?

He was successful, what seems to make him so successful? What projects in the past seemed to fail (or were particularly painful) and why? Asking these questions (either directly or in a more nuanced conversational format) can help you understand a few things: how respondents define success, the potential risks of the project, and any biases or expectations it will create, and what works. Does the company collaborate and release the same designer?

Project or team? If so, try to find out what doesn't seem to be working and why customers expect a different approach. If you can ask this question to more than one person in the company, it will help you learn a lot about unspoken expectations. If you get two very different answers, this probably means that the designer's responsibilities are not clearly defined, and you may need to ensure that there is a lot of communication about your responsibilities throughout the project. Did the design team work on the project (or related material)

Don't you think it's been done for a long time?


Chapter 2: Project Ecosystem

If so, this may mean that the client's key stakeholders are not on the same page or engaged in a timely manner, leading to multiple interruptions, changes in direction, or lost time due to multiple iterations. It can also mean the lack of a clear leader, someone who can say no (or at least effectively prioritize) to focus on business goals. If you are able to influence project communication, developing engagement guidelines can help move the project forward. Did the company create the project without prior involvement?

User experience designer? It can be a mixed blessing. On the one hand, you have a team that understands the design needs and tries to fill the gaps. On the other hand, you might end up with a design that you don't think meets your UX design goals. This can be a delicate situation. It's often best to approach the creators of these projects in the tone of a respected mentor or advisor, first pointing out the strengths of the project and then discussing the UX goals and how best to achieve them through different approaches. Creators are likely to be valuable members of your support network, so it's important not to break bridges here, but to redefine your role in a collaborative way to maintain enthusiasm. Does the lead sponsor or project manager seem particularly anxious?

About the project? This can happen for a number of reasons, especially if some of the above factors are involved. Anxiety can also be caused by market anxiety, which will help you understand. For example, is the company's share price falling? Has a particular athlete made impressive progress recently? Is the company making losses? Again, these conditions don't necessarily mean you shouldn't accept the project. Besides, in such cases, the project will usually be funded first. However, if you are very worried that the company will not be able to pay the invoice, then you need to consider this risk.

Understand the company culture


Geert Hofstede's hierarchy has an excellent model for identifying cultural differences, which he calls "cultural dimensions" that often affect how people interact and communicate. One of them is the concept of power distance, that is, the extent to which members of society (in our case, the company) understand and accept the distance between people with different levels of power. For example, if members of a company's executive team are perceived as particularly powerful and potentially difficult to get along with, the company may have high power distance and its employees may be more concerned with hierarchy. If a company encourages the democratic exchange of ideas and challenging vision, its power distance may be relatively close.

Power distance is "... the degree to which less influential members of organizations and institutions (such as families) accept and expect an unequal distribution of power. This means inequality (more versus less), but it is defined from the bottom up, not from top down. how an unequal society is perceived by followers and leaders" Geert Hofstede The cultural dimension www.geert-hofstede.com

Neither of these extremes can be good or bad in itself, although in the United States most workers seem to prefer less power distance in the workplace. It is worth noting that this is not necessarily an indicator of a company's success. Apple has relatively high power distance (given the aura around Steve Jobs), while Google, as part of its culture, has relatively low power distance, but both companies are known to be leaders in innovation. The important thing to remember is that the power distance within the client company will affect how effectively you navigate the political waters during the project. This aspect will become particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as sign-off points (discussed in Chapter 4). If you work for a company with a high power distance, take more time


Chapter 2: Project Ecosystem

Before planning meetings such as stakeholder interviews and assessments, take the time to understand your relationships and consider including more mid-level people in the communication process.

Logistics In addition to the broader cultural aspects mentioned above, it can also be useful to understand some of the elements that are more logistical in nature so that they can be better integrated into current work methods or implemented in thoughtful ways. For example, it's useful to know the overall progress expected for your business, including key release dates or deadlines that will impact the project (the development progress of an app on an annual release schedule may differ from that of a microsite that supports seasonal campaigns, for example). Is your team working overtime to meet looming deadlines? Expectations for remote work vs. on site they are also easy to understand. If long hours are expected on site, you will need to plan your travel and resource arrangement. If remote work is accepted (or encouraged, which is common when working in multinational companies), it is important to understand communication methods and tools. For example, is instant messaging acceptable? What web conferencing tools do you use? Are there international stakeholder engagement methods that have proven successful in the past? It is also interesting to learn about the "paper culture" of the company. Some companies prefer mostly electronic media, so a good projector and a stable Ethernet connection are important. Others are very paper-centric, so you'll want to make sure you bring enough copies to the meeting to make it effective. You may be able to change the project culture if you believe a different approach is more effective. But it's nice to know that you're asking people to make changes so you can make a smooth transition—and maybe figure out why a certain approach isn't working the way you expected.

Understand the company culture


Now that you're familiar with the project domain, you should better understand the project ecosystem: the environment you'll be working in (company culture), the general type of work you'll be doing (eg type of site). design) and the people you will interact with (including their roles and responsibilities). This information will be valuable as you define your role in the project and get ready to get serious. If you're a freelancer or subcontractor, this will be the basis for writing a proposal that covers your work on the project (see the next chapter, discussing UX proposals). If you work in a larger team and are not directly involved in writing applications, you can use your new knowledge to start the project - your first team meeting. A basic guide to running a good meeting can be found in the online chapter "Quick Guide to Meetings" and if you want to jump straight to the types of questions to ask at the start of a project, see Chapter 4 "Project Objectives" and Methods.


Chapter 2: Project Ecosystem


Advice for consultants and freelancers A guide for industry people who also run their own business Managing projects and client expectations can be a challenge, but if you don't have the right contracts in place, you can fail. any project. Offers and statements of work are critical to protecting your company and you from financial and legal trouble. After accepting the project and shaking hands, be sure to take the time to write the contract, which details the terms of your relationship and the client's payment schedule. Lars Unger


There's an old saying about a proposal that "everything comes naturally" and the same goes for any project landing - a high five and a good feeling can quickly be replaced by "Oh shit! Time to write a proposal!" .Write a Proposal The biggest challenge is writing your first proposal. If you've never made one yourself, it's almost impossible to know where to start, and that's where this chapter should come in handy. Any kind of project that encounter will have a different style, allowing you to stay alert as you write your proposal. Fortunately, all proposals have a common core that can be reused in different projects. (For a detailed discussion of project types, see Chapter 2.) When to write a requisition? Always. Why write a requisition? Throughout the history of working on a project, people have been in the most awkward situations when there is no agreement between the client and the supplier. When you're first connecting with a prospect and everything seems to be going well, you might be tempted to skip this step. Even if you understand what your client wants and can express it in a way they understand, you're not really ready to start working. In fact, this is exactly the time to slow down and take a breath. Take time to define your professional relationships and how you work with new clients, rather than jumping right into the job. "Contractors and their clients often think they have a contract at the start of a relationship, when in reality being ambiguous is just lying and waiting. While it's nearly impossible to prepare for every eventuality, a comprehensive written contract is also the best your defense as assurance that you won't later dispute the terms of your relationship in court. The smartest way to do this. The more clearly you can define the terms and parameters of your relationship with a client in writing in advance contract, the less likely you'll end up fighting over both parties' obligations.


Chapter 3: Tips for Consultants and Freelancers

New projects and new people are exciting. People usually don't want to "kill the deal" by throwing a proposal into the mix, but as with any relationship, the honeymoon feeling will eventually wear off. Both partners in a relationship can break commitments. The customer may not be able to provide you with access to the content in a timely manner. (I know that's almost unheard of, but believe it or not, it happened! Here's the irony in case you missed it.) Funds that were once available for a project can be diverted elsewhere—and then you, that person, are busy with work and you can go out with a bag on your back. Companies also recognize that they take on risks when working with third-party vendors—especially those that are very small businesses or independent contractors. A well-written offer can provide the client with a sense of stability and protection, which can help alleviate many of the concerns that may arise. Proposals also allow you to set terms that protect both parties when certain conditions change. If a client does not provide you with timely access to their resources, your program may be delayed. you need to let him know that he is committed to the success of the project. If a client loses funding and terminates the project – and you don't have a proposal or other form of contract – you risk not getting paid for work already done. The bottom line should be pretty clear: always write a sentence.

Creating a Proposal Once the project has begun, it's time to finalize the proposal. The sooner your proposal is approved and signed, the sooner you can start working – and more importantly, start getting paid for your work. The key elements of a good proposal are Title Page Change History Project Overview Project Approach

create a sentence


Scope of Work Cases Scope Title and Title Additional Costs and Fees Project Valuation Payment Schedule Confirmation and Signature

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

Cover Page A cover page is a simple introduction page to a document. Covers are an interesting beast: they can be created stylistically and informatively in many ways. How you do it is up to you. A typical cover page includes the following: Client company name Client company logo (if you have access to it) Project title Document type (tender) Proposal version Date of submission Company name Proposer Project reference number Cost Confidentiality

Include everything in your first quote - except the client's company logo, the cost and (possibly) the project reference number. Why not put these elements on the cover?


Chapter 3: Tips for Consultants and Freelancers

Your customers know who they are. Applying for a license to use your company's logo probably isn't worth the time and effort or the embarrassment it might cause if you accidentally use it. Costs are best determined by identifying project components in the text, and cost information leads well to payment plans. Note the project reference number. Many companies don't use it at all, however, some government agencies rely on this program and if you can't find it on the cover, your proposal may be rejected.

Figure 3.1 Example of a proposal cover

Figure 3.1 uses a (fictitious) customer logo. It is best not to display the client's company logo without permission or without an established relationship.

create a sentence


Change history Change history is the part of the offer that shows how many times the offer has been updated since the original version. In general, it is a good idea to include the version number, date, author, and any version notes, such as what has been modified, to give the reader context about the modification (Table 3.1). Table 3.1 Version

Sample change history table module




original file

European Union

8 January 09

I assume

Updated to reflect software requirements

European Union

January 11, 2009

1,0 1,1

Sometimes the client will sign the proposal and then ask for further corrections. If you decide to continue using the client and make these changes, you should take this opportunity to update your documentation from version 1.x to version 2.0. Basically, once the client approves the proposal and the terms are agreed upon, you can start work. Therefore, when additional corrections are required, they should be considered very carefully. This ensures that your costs remain reasonable and that both parties have a good understanding of the modifications and the stage at which the project will proceed (if necessary). You should also always include a proper explanation of why the fix is ​​a completely new version in the version 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 customer a clear idea of ​​what you expect their product to contain, as well as an explanation of what they can expect from the rest of your offering. Here's an example of how the review starts: [Client Company Name] wants to create a new online presence on the Internet. This online presence provides customers of [customer company name] with the ability to search for and purchase products online, as well as other services and benefits offered by the company. The purpose of internet presence is…


Chapter 3: Tips for Consultants and Freelancers

You should be able to give a solid overview in a paragraph or two, giving very detailed information about what the client can expect from you. The discussion is best concluded with a clear explanation of your proposal and the proposed approach to the implementation of the project: [name of your company]'s proposal and approach to the design and development of the website of [name of client company] will are detailed in the application. Due to the expiration of [deadline], it is recommended that...

Project Approach Your project approach will vary depending on the type of project you are working on. This is your opportunity to identify with the client, how you plan to implement the project with them. You define the rules of engagement and set expectations for the work ahead. Many people and companies use a very similar approach - but with different names or clever acronyms that match their overall brand. Once upon a time, a wonderful method of presenting to (potential) clients was created and found its way into many proposals. This process is called The PURITE Process™ (pronounced "purity") and in sharing it with you, the mythical creature just died a little inside, so be careful reading this as fiction. The process has a somewhat cheesy name and is clearly incomplete. This approach omits post-launch analysis (oversight), but of course all customers should be included. Without further ado, here's the PURITE approach: [YOUR COMPANY NAME] has established a standard process for achieving project success with our clients. While each of these phases may not apply to [Project Name], the overall process is defined as follows: The PURITE™ Process is [Your Company Name]'s internal methodology for ensuring the overall success of all programs. With PURITE, [YOUR COMPANY NAME] has a proven set of guidelines for working closely with customers and users/consumers to reliably meet and exceed delivery expectations. W- it happened. We dedicate part of every initiative to understanding your industry and competition and how they operate to get as much information as possible before we start gathering requirements. You understand. We work closely with experts and/or users to define the requirements for proper project creation.

create a sentence


R - Performance. In the performance phase, we create and develop all parts of the project/product. In our experience, each phase of development requires very careful, focused work, but also early, open communication with the team. It also requires us to… I – Repetition. The iterative phase is repeated throughout the project. We work as quickly as possible to bring projects to life, often requiring multiple iterations to create in a short amount of time. This requires the direct and timely involvement of you and your specialist resources. The end result is a product that you define and help create. T-test. We test every project during the performance phase, but we also need an extra pair of eyes - from our own testing team and a specific user/audience group to test against goals. This extra round of testing helps ensure that there is as little unfinished work as possible to deliver a project that has gone through a rigorous, multi-level review. E - activation. Once the first five phases are successfully completed and signed off for approval, we will activate the solution and put it into production. The PURITE™ process doesn't stop there. After the project is completed, we regularly communicate with the client. We'll continue to measure your satisfaction, understand changing project goals or improvements, and help determine how best to develop your project going forward.

You can use as little or as much as is appropriate or useful for you. The author of the myth that created this process doesn't mind if you don't admit it. The process definition can be as detailed as above or as simple as: Design, Define, Develop, Plan Development General Strategy Define detailed project requirements Develop, test, improve, and launch work products Extend the project, proposing improvements and enhancements based on improvement information received after development, testing and release

Once the process is defined, you will have the opportunity to detail the various efforts that will be made at each stage of your approach and what each of those efforts will mean for you and your client. The length of the method portion of the proposal will vary depending on the design, process, and activities that take place at each stage of the process. However, try to limit it to two to three pages at most and


Chapter 3: Tips for Consultants and Freelancers

Make sure you only include deliverables that you will be able to deliver to the client - to prevent further documentation updates or project price revisions.

Scope of Work The Scope of Work section allows you to define the distribution of work in the project. This means identifying which elements of the project you are responsible for and which elements are the client's responsibility. Read it again. Think about it. Let it absorb. Well, here we go. Right. This is the part of the proposal where you tell the client in writing that we will do it and you will do it. Then, once the client signs your proposal, they agree to the agreement, and you have a written record to help you with any disputes. The goal here is to make it clear who will handle what aspects of the project and what aspects of the project are included in your bid and price estimate. This should be enough if you can't find any other really compelling reasons to write your application. Here is a very brief example of the scope of work: [Client Company Name] contact us to provide all the services required for the construction of [Project Type]. [YOUR COMPANY NAME] will focus exclusively on the [UX design aspects] of [CLIENT COMPANY NAME]. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] based on the project plan. [client company name] will provide all resources required for use on the project, including fonts, colors, branding templates, etc.

Assumptions The assumptions section of the proposal is a great place to express what the client needs to ensure your success, leaving no room for debate. That is, these are the things you assume and communicate with the client, have access to, or provide to make the project successful.

create a sentence


The assumptions made in this section are actually expectations. The case is much kinder. You can create as many project plans as you want, but if neither you nor the client commit to meeting milestones and goals, you both face a certain number of project failures. Broadly speaking, these assumptions are expectations of resources and assets and timely (translation: quick, immediate) access to both. Here is an example of how to write Assumptions: Assume that the company [Client Company Name] needs to provide the following assets and resources. Failure to deliver these assets and resources on time and in full may result in the failure or delay of this project. The following assets and resources are required: Timely access to all required employees of [Customer Company Name]. Immediate access to all required [project] resources in its current state, including any source files if available. Content, including but not limited to copy, images, audio, etc. of any aspect of [Item] as required.

Deliverables Deliverables are work products that you create and deliver to the customer. This section is an opportunity to tell the client in detail what kind of work product they expect from you during the project. It is recommended that you approach the status report separately at the end of the project, but you can add it to this part of the project. Be sure to include a description for any work product you may include, even if the work product has not yielded a result. This may seem like overkill or potentially opening a can of worms "I read about [delivery type] in the offer but I don't see it here", but maybe a little word can make all the difference. Deliverables [YOUR COMPANY NAME] provides various products throughout the project. For [customer company name], we have identified the following products:

48 lat

Chapter 3: Tips for Consultants and Freelancers

Creative brief The creative brief is the first step in the project. This document will help us create a quick and efficient overall project overview. The purpose of the Creative Brief is to explain the user's goals and needs 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 customers to use the work products you create. These rights can be defined in many different ways, but most of your work falls into two categories: Works for hire Works licensed

A work for hire (referred to in legal circles as a "work for hire") is considered to be created and copyrighted by the party paying for the work, not the party responsible for the actual work. This means that when you work on a project for which you have been hired, you have absolutely no rights to that project and anything you create for that project is the property of the client. This is an unbearable situation for many companies and individuals: it usually means no further "maintenance" work (with additional income), as the client can choose to simply keep the project after it is completed. Feel free to purchase items ordered by the customer. it is not unusual. This is fairly typical in an employer-employee relationship when you place work on a recruiting project as part of a full-time job at the company. This is also an opportunity to access the pricing model - many plans charge slightly higher fees to compensate for any lost revenue in the future. Remember, it all comes down to your relationship with your customers and how you do business. Time and experience will help you make the right decisions about the type of work you will undertake and the pricing model you will choose. A licensed work allows you to retain copyright in your work, but grants other parties the right to copy and/or distribute your work. You can include any number of terms in your license agreement. You will probably create an offer


If you retain ownership of all source material for your work and only provide your clients with limited-purpose work products (such as PDF files instead of raw, editable Word, Visio, Axure, OmniGraffle, or other documents), use a license. license your work in many different ways, including unmodified, non-commercial use of the licensed work, or any other ways that may be appropriate for your situation. Creative Commons (http://creativecommons.org/about/licenses) has easy-to-understand explanations of the different types of licenses you can use, but these are only a small subset of licenses. If you have very specific and specific needs, it is best to contact a copyright attorney to help you formulate the best solution.

Additional Costs and Charges It is important that the client understands whether you will outsource the work for them (or without). For example, some projects may require you to purchase image libraries from vendors. You can purchase images (with appropriate usage rights) and include them as part of your fee, or you can purchase images explicitly as an additional cost that will be passed on to your clients. You can also offer services that you want customers to know about – this is a great opportunity to promote them. Here is an example that explains how to manage additional costs and supplies: Additional Costs and Charges If external resources (such as content, images, fonts, etc.) are required, they must be charged to [client company name]. In addition, [YOUR COMPANY NAME] can provide hosting services to our customers with very low overheads. We offer hosting services - including customizable email on the web - starting at $25 per month plus $25 setup. If [customer company name] wishes to purchase a "maintenance" package, [your company name] will try to create a mutually acceptable and mutually beneficial package.


Chapter 3: Tips for Consultants and Freelancers

Project Pricing After you've documented the details of how you'll work on the project, it's a good idea to let the client know the cost. How you set the price is largely up to you, but here's a tip: Estimate how long it will take to complete the project - including a certain number of revisions Estimate a reasonable project management time, this might be approx. 25%, then set an hourly rate you want to charge and calculate it. There are several formulas that can help you with this, such as applying difficulty to each part of the project to help you determine the range of costs you can offer your client. In most cases, experience will be the key to correctly evaluating the project in terms of time and material. How to determine the charge rate? See what others are charging by finding salary surveys and contractor rates to compare. For example, organizations such as the Information Architecture Institute (www.iainstitute.org), AIGA (www.aiga.com), Coroflot (www.coroflot.com), and talent agency Aquent (www.aquent.com) charge salaries and study rates. Given your experience, the prices of others in the market, and what you think is fair, you can get a general idea of ​​what prices you can charge. Remember: You can reduce the interest rate at any time. Once customers see the numbers on the page, it will be hard to ask them for more! There are many different ways to value a project. Depending on the nature of your project, you may need or want to provide multiple estimates to allow for different pricing options. For example, let's say you offer a customer two options: a static HTML website and a website with a content management system (CMS) that allows dynamic content to be displayed (which the customer can manage without dedicated resources). Here's how to set up a project estimate: Project Estimates [YOUR COMPANY NAME] has submitted multiple estimates to [CLIENT COMPANY NAME] to ensure the best option for your current and/or future needs. [Your company name] expects all content to be provided by [client company name]. If [your company name] is asked to provide content services, you will need to redefine your estimates.

create a sentence


[YOUR COMPANY NAME]'s estimates allow for cost and demand flexibility. Estimates are as follows: Estimates 1 [YOUR COMPANY NAME] Estimates [PROJECT] FOR [CLIENT COMPANY NAME] NO INTERACTIVE CONTENT...

Remember, there's really no wrong way to gather project estimates - unless you're putting yourself in a negative cash flow situation!

Payment Schedule It is a myth that all freelancing projects are paid 50% up front and 50% at the end of the project. This myth must be dispelled - now! This is not the way to do business, nor does it provide a quick, steady income while you do your job. You don't want to make changes for a customer just because you want to get the project done and get paid, instead of working through the change order process. You can invoice projects in a number of ways, from sending invoices within a set time frame to payments based on milestones. A smarter approach is to put the project on a recurring payment schedule with regular, itemized invoices. This approach should also give the client a clear understanding of what has been done on the project and what remains to be done. The following example is one way to arrange payment for your work: [YOUR COMPANY NAME] Payment Schedule A typical payment schedule is to receive a maintenance fee of XX% of the total estimated price of the project prior to commencement. [Your Company Name] Invoices are payable on the 1st and 15th of each month. Full payment is due within 14 days. Upon completion of the project, [your company name] will deliver all work products to [client company name]. Once the material is successfully approved, [your company name] will refund any outstanding charges or [your company name] will issue a final invoice for the amount not included in the charge. Note: If [Project] is placed on hold for more than 14 days without progress, [Your Company Name] will issue a final invoice for any charges not covered by the Owner and reserves the right to first refuse if the Project is reopened .


Chapter 3: Tips for Consultants and Freelancers

Although not required, it is a good idea to include a note about what to do with the item if it is on hold for a long time. This resolution can help keep the project on track and moving forward - it provides a talking point with the client. If you won't be doing extra work for them for a long time, you want to be able to go ahead and find a job to fill the gap.

Acknowledgment and signature While making sure you have a proposal is very important, it is not enough on its own. The proposal has no meaning until it is approved and signed off by the appropriate people in your client's company. It is extremely important to ensure that everyone has a good understanding of what is going to happen and what is expected of each party. It's also important to protect yourself from the "repetition highway" and reduce the risk of customers getting bogged down in "feature creep": constant requests for "one more thing to do." The signature is very simple and straightforward. Once you create the quote document, you will provide your client with a receipt and a signature to approve the contract between the two companies. Always prepare two copies - one for each party - and make sure both copies are signed. Here's an example of an acknowledgment you can use: Acknowledgment [Customer Company Name] fully acknowledges and agrees with the offer. To be effective, the offer must be signed and dated by an authorized representative of [customer company name]. Alternatively, a signed purchase order associated with this proposal will constitute acceptance of this signed document (provided that any preprinted terms of this order are deemed void). This Offer constitutes the entire agreement between the parties regarding the subject matter of this Offer. This proposal includes and supersedes all prior agreements, discussions, negotiations, commitments, letters or understandings, whether oral or written. This includes, but is not limited to, any representations made in sales materials, brochures or other written descriptions or promotional materials and is the complete and exclusive statement of the terms of the agreement between the parties. Each party acknowledges and agrees that, in executing this proposal, it has not relied and expressly disclaims reliance on any representations or representations not contained herein or in the Agreement.

create a sentence


Accepted by authorized representative: [company name]

[Customer Company Name]

come in: ________________________________

come in: ________________________________

Name: _____________________________


Title: _______________________________

Title: ______________________________

details: ________________________________

details: ________________________________

Make all checks payable to: [your company name]

Statement of Work A Statement of Work (SOW) is a general definition of the project's objectives, which you should fit into a two- or three-page document (not counting the title page). SOWs are usually written before proceeding with the specific requirements, although depending on the needs of the client and the project, you can create a hybrid document that best suits your needs. In general, the SOW should be used to build consensus between your team and the customer's stakeholders as early as possible. The SOW will define project inputs and outputs as well as assumptions and constraints. At this point, the client will usually ask you for the "budget number" of the work you will do for them. Answering this question at this point can be a little dangerous. It is recommended that you avoid making specific statements or promises without specifying details. If you haven't written an application and/or requirements document, you can't know how much the project will cost. That being said, you need to make an assessment at this point. If you are working on a project, such as a basic website, and you have already successfully completed several similar projects and/or worked with the same client in the past, you have some leeway. Remember that it is better to play it safe than to have unpleasant situations later in the project. The job description should be approximately two to three pages long and contain at least the following:


Chapter 3: Tips for Consultants and Freelancers

Title Page Change History Project Reference Number Project Summary Start Date End Date Rates/Prices Project Description Activities and Deliverables Listed Costs and Payment Schedule Confirmation and Signature

Are these items known? You should -- you can use a stripped down version of the proposal to submit your SOW. You have already learned how to combine the two types of documentation that will allow you to identify the work you are doing for your client. These documents should form the basis of any design work you do for any client and will provide you and your client with a clear set of instructions for further project work.

Job description



Project Goals and Approach Knowing which stars to navigate One of the keys to a good project is starting your team with clear project goals and an understandable methodology. Ideally, your project manager will define this for you - but if they don't, how do you know? This chapter discusses how to formulate project goals and asks some questions to help strengthen those goals. We'll also discuss some common project approaches (or methodologies) and how they affect the way you work. Carolina Chandler



You are in the starting phase of the project and you are with the whole team for the first time. The project manager distributes materials and gives an overview of the project. Ideally, at the end of the meeting, you should have the following information:

Why is this project important to the company? How will stakeholders determine whether the project will be successful? What approach or approaches will be used in the project? What are the key dates or milestones for key points such as acquisition

Business stakeholder consent? All these questions are about what stakeholders expect from the project: what the project will achieve and how they will be involved in it. The first two questions relate to the objectives of the project and the last two relate to the project method. A project objective is a list of measurable project goals. Let's talk about goals in more detail.

Consolidate Project Goals Goals are an important lens of focus that you will use throughout your project. They should arise from the overall business strategy of the client company, so project objectives should be aligned with the company's strategic initiatives. For example, if there is a strategic plan to acquire a new potential customer base (the so-called market), the website or application created may be an attempt to provide this market with online access to products and services related to it. will focus on entering and participating in this market. A clear purpose resonates throughout the work. It helps you ask the right questions when gathering ideas from business stakeholders

Link to Design Requirements List Prioritize these design requirements based on their value to the business

Reinforcement of project objectives


Create effective interaction plans Manage plan change requests once development begins Focus efforts on implementation activities such as training and communication

Communicating with users about a new website or app before and during launch)

Project Initiation When you start a new project, you likely have project objectives from the project sponsor (the business stakeholder directly responsible for the project's success) and a set of project requests from business stakeholders and customers, but they can all be a bit indistinct (Figure 4.1). Your goal is to articulate them into solid statements that you can use as a measure of your project's success.

Requests about the project

Strategic goals of the company

Users need input from stakeholders

rozmyty cel

User complaints What stakeholders think

Figure 4.1 Unclear goals, ideas and needs

Fixed goals are easy to understand. Avoid internal jargon. Clearly. Avoid ambiguous statements. Use similar phrases instead

Useful when prioritizing requirements. counted. To make a specific statement, you can define a standalone

Measure to determine your success. When you set a vague goal and make it clear and measurable, it becomes a solid goal to base your decisions on.


Chapter 4: Project objectives and approach

Figure 4.2 Fixation of targets

Strategic design goals of the company

You will hear many statements that can be considered targets. Analyzing ambiguous goals, as shown below, will help you stabilize your goals and communicate them more effectively within the project team. business representative


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

This is a company-wide goal, but too broad for a specific project. Companies will need to take several initiatives to make this happen. any website or app can help with this, but it's unlikely to be able to handle the full load - unless the entire company pays attention to that website or app and it ends up being hugely successful. business representative


"Our goal is to excite our customer base."

This is better because the website or app can affect it, but it's still very vague. Why is it important to evoke emotion? How does this enthusiasm translate into meeting business needs? How do you know if you were successful? business representative


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

Now we are there. This is easy to measure, but focuses too much on intermediate steps. Assuming you're generating more traffic: If people aren't doing what you want them to do when they get there, it's probably not going to help.

Reinforcement of project objectives


Vague goals allow you to understand customer desires and larger goals. From there, you can develop more solid project goals, such as increasing your online sales revenue by 10%. Increase your online advertising revenue by 20%. Increase the number of existing and potential customers among our customers

Database up to at least 20,000. We provide our core users with highly rated and frequently referenced content.

(Note that it took some work to decide how to measure high rating and high mention, but these figures can be created.)

Each of these can be measured and affected by your project. They also match very closely to your design and functionality provided. For example, it is very common to offer an online newsletter as a means of achieving the goal of developing a customer database: to send a newsletter, customer email addresses must be captured and added to the database. Goals can also bring new requirements. For example, if you measure success by the average rating of the articles on your site, you need a feature that allows users to rate. In this way, goals help focus efforts on gathering website ideas that can later become project requirements. If there are multiple goals, be sure to create a priority list with your business sponsor and your project team. During the planning process, goals sometimes conflict and the team needs to know what to prioritize. The final list of priority goals should come from the project sponsor, but you can be a key part of the discussion. Let's talk about how.

How can UX designers help? You can use your facilitation skills if you find that project goals are not clear at the beginning of the project. Help the project team understand the business context of the project by holding workshops with key stakeholders (see the next chapter for more on identifying the right stakeholders). During this meeting, which usually lasts two to four hours, your goal is to provide information about your company's strengths and weaknesses,


Chapter 4: Project objectives and approach

chances and risks. Known as a SWOT analysis, it is a common business analysis technique and a way to discuss a company's position in the market. You can also use this time to discuss the company's competitors. Understanding Strengths and Weaknesses SWOT Analysis SWOT analysis identifies the company's current strengths and weaknesses in relation to the project. Strengths and weaknesses can include internal processes and external perceptions—and often influence each other. For example, a company with a large research and development (R&D) department may have access to a large source of published original research (an advantage), but may have no one to help make this content more accessible to general users, leading to perception of the company as “too academic (weakness); Identifying OT opportunities and threats is the future half of SWOT. Given the factors that differentiate the company from the competition, what steps can it take in the future to create new positions or strengthen existing ones? What conditions threaten these plans? For example, the research and development company may decide to hire writers to publish more accessible fiction articles about their original research (opportunity), but without the current toolbox of a website that has strong content curation capabilities, the publishing process may she is very slow. This can give competitors the opportunity to react more quickly (threats). Competitors Comparison Who are the company's main competitors? Who are the competitors of the created website? It may be different, especially for larger companies or brand new locations. Are there sites that are not direct competitors but represent interesting models that are worth considering? You can learn a lot by looking at other e-commerce sites to see if and how they sell what you sell. SWOT works together and discussions with competitors are good topics for discussion, at the same time they influence each other. it's hard to talk about it

Reinforcement of project objectives


Respond to future threats without knowing who your competitors are - when you start talking about future opportunities, new competitors may emerge. Once you have a good understanding of the competition and your company's SWOT, your project goals - and the overall alignment of the project with your company's strategy - should be easier to define and the priorities between them should become clear. Consolidation of project objectives helps to understand what the project intends to achieve. Next, let's talk about expectations for the progress of the project. Knowing project methodology will help you collaborate effectively and engage the right people at the right time.

Knowing the Project Approach Knowing the overall project approach or methodology is an important part of knowing when and how to get involved and how others such as the project team and business stakeholders should be involved. Sometimes it seems that there are as many design methods as there are projects. How to choose the right design approach is a big topic in itself. The approach chosen can depend on many factors, including the structure and location of the project team, the technology used in the project, and the extent to which collaboration is part of the company's culture. For the purposes of this book, we assume that you are involved in a project whose approach is largely determined by those responsible for the success of the project, such as the project sponsor and the project manager. In this case, your primary focus will be to understand the approach and help ensure it works for business stakeholders and users. Here we'll focus on the two most common approaches and a third that shows the possible variations you might encounter in your project. It should be noted that most approaches involve the same steps: planning the team's overall strategy, approach and structure. Define design requirements. Design interactions and visual concepts and turn them into details

Cation Technical Data. Develop, test and improve solutions.


Chapter 4: Project objectives and approach

Grow the solution with news, training and planned release. Extend the project by suggesting improvements.

These steps may have different names, as well as the extent to which they overlap and how the information is documented. But the general actions at each step are common to most designs and the three models presented here.

The Waterfall Method The Waterfall Method views the stages of a project as separate, distinct phases, each requiring approval before the next phase can begin. For example, the planning phase does not actually begin until the requirements are approved by the business actors who sign one or more requirements documents at the end of the definition phase. You agree with


You agree with

You agree with

Define a project deployment deployment extension

Figure 4.3 Example of a waterfall approach where each stage "falls" into the next stage

The problem with a pure waterfall approach is that it assumes that each stage can be completed with minimal changes from previous stages. Thus, if new requirements arise during the design phase (which is very common), you will need to propose changes to the document that were approved at the end of the definition phase, which can disrupt plans and schedules.

Agile Methods Because change is constant, project teams are always looking for ways to be more agile than the waterfall model. Many methodologies are based on a more fluid approach where certain steps are performed simultaneously. For example, agile or rapid development methods can be used to release a version of a website in a rapid, iterative manner. Agile methods tend to focus more on quick collaboration and less on detailed documentation and formal signatures. Explore the design approach


Repeat 1

to develop

Repeat 2

to develop

Repeat 3

to develop

Development Project Development Project Definition of the development project


defines approval


develop a release extension

Figure 4.4 Example of flexible method

A truly agile approach (for example, following best practices developed by members of the Agile Alliance) requires small teams whose members are physically adjacent to each other and pay little attention to defining formal roles among team members. Working in this way allows for a high degree of collaboration, reducing the need for extensive documentation between the design, development and testing phases. Team members can ask questions, work on answers with other team members in quick board sessions, and implement solutions without delaying detailed documentation and approvals. When one of the many iterations is released, stakeholders review the fully functional system and take the resulting input into account when planning the next iteration. (An iteration is a draft of a particular website or application.) It's beautiful when agile methods work as designed. However, in most companies and most consultancies, teams rarely adopt a purely agile approach. This is in part because companies are increasingly using distributed teams and remote workers, making it difficult to maintain the high level of collaboration required to take full advantage of pure agile methods.

A modified approach Most projects try to take an approach that combines the best of both worlds, with enough structure and documentation to reduce the risk of distributed teams and team member turnover, but enough collaboration and iteration to respond in a relatively agile way . Variability. For example, a project may follow a waterfall model but have overlapping phases so that there are key points of collaboration between teams. allows


Chapter 4: Project objectives and approach

Potential changes appear earlier in each stage. This may also include early releases with shorter iteration cycles (such as beta releases for specific user groups). Feedback from this version can then be incorporated before the new site is fully developed. plan


Development and design



Development Development Beta

develop a release extension

Figure 4.5 Modified beta version waterfall

Notice the smaller design iterations in Figure 4-5. As a UX designer, this is one of the biggest values ​​you bring to your team. Tools like skeletal modeling (Chapter 11) and prototyping (Chapter 12) let you gather feedback on iterative ideas quickly before you spend a lot of time developing them. The modified waterfall method shown in Figure 4.5 is one of the most effective and widely used methodologies, and thus 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, as the underlying activities behind them - such as definition and design - will still be necessary.

Dig Deep If your project uses agile methods, you have unique requirements when gathering requirements, such as writing a "user story" as a means of capturing requirements. We recommend Applied User Stories: For Agile Software Development by Mike Cohn (Addison-Wesley Professional, 2004).

Explore the design approach


How does this method work for me? Knowing your approach can help you understand many things: what questions to ask and when. For example, if you are

With a waterfall-only approach, extra effort must be made to ensure that the requirements captured in the definition phase contain all the information needed in the design phase. (We'll cover requirements in the next chapter.) Expectations of how and when project team members will work together

The partnership will close. For example, agile methods require very close collaboration. The sequential approach can in most cases involve individual work, with touchpoints once or several times a week. the level of detail required in the documentation i

formulations. The documents submitted at the time of signing should be formal, almost like a legal contract. Typically, you'll need more formal documentation with a waterfall approach that requires you to sign off before moving on to the next phase. However, when using agile methods, you can also have formal signature documentation - for example, getting information at important decision points, such as when an iteration is ready for full release and deployment. Key milestones including stakeholder approval i

arranged in different groups. This approach will determine what different audiences need to provide at different points in the project, including stakeholder approval at disconnect points and feedback from potential users during the beta release. Now that you have defined the project goals and understood the project methodology, in the next chapter we will start with the main task of the definition phase: requirements gathering.


Chapter 4: Project objectives and approach


Business Requirements Understanding the Problem Before Creating the Solution As the project team comes together, you've probably heard or had a lot of ideas about what needs to be done. Perhaps there is already a list of features provided by key company members (your business stakeholders) with their views on which features are most important. These are elements of the business requirements of the project and are a good place to start. To ensure that you have a complete solution at the end of the project, you need to create and explain the requirements from multiple perspectives. In this chapter, we will focus on gathering and defining the requirements of the business stakeholders. Carolina Chandler



Chapter 4 covers ambiguous goals and discusses various ways to help yourself and your project team understand them. In the early stages of a project, you may have a relatively vague set of requirements. These can be stakeholder ideas, user complaints or user requests. To have these useful and traceable elements in your project, you need to incorporate these ideas into the requirements. Requirements are statements that specify what a website or application should do. Ideally, business requirements provide information on general requirements to be considered, represent and integrate requirements provided by various stakeholders, guide design, but do not go into great detail about how to design

Completed as a separate unit of work for prioritization and tracking purposes

Below is an example of an idea for the functionality of an e-commerce website. At the beginning of the definition phase, you may have the same thought from many different business operators: "Customers can track their orders online." Start asking questions about the details of the requirements, such as why it is important to your business to let customers track their

online ordering? For example, are you reducing the number of customer service calls? Does the company have the ability to track shipments online?

If not, new monitoring requirements must be considered or the company may need to work with a third party. How accurate should tracking be? what information

Should it be included in the tracking details? For example, should the website provide up-to-date delivery time estimates? Asking these questions will help you distill vague ideas into firm requirements. It will also explain that the same statement can mean different things to different people.


Chapter 5: Business requirements

For example, a customer may believe that tracking a package involves receiving a confirmation email with a tracking number that can be entered on UPS.com or another website so that the customer can see how the package finally arrived. page. Idea Another stakeholder may believe that the company should push the boundaries of package tracking and invest in enabling customers to track packages using GPS, using online maps to see their exact locations in real time. As you can imagine, it makes a significant difference to the user experience and scope! It is important to outline these differences early in the project. Otherwise, you'll end up developing a solution that conflicts with the intentions of your business stakeholders and potential project goals. This leads to stakeholder dissatisfaction and wasted time and money if a feature needs to be redesigned. Therefore, clear and detailed requirements are a key part of the whole project. Obtaining a comprehensive list of project requirements involves the following steps: 1. Knowing the current state of your website or its competitors. 2. Gather the needs and ideas of business stakeholders and current and potential users. (See Chapter 6 for details on working with users.) 3. Consolidate ideas into requirements. 4. Prioritize requirements based on project goals. (See Chapter 9 for tips on prioritization.)

Business and project requirements of users require enterprise strategy

Figure 5.1 Combines ideas from business stakeholders with business requirements and ideas from user research with user requirements. Then use the project objectives to prioritize and create a comprehensive list of project requirements.

business needs


First, let's talk about understanding the current state of your site so you can understand the ideas that emerged during the requirements gathering process.

Knowing the Current State As you dive into the details of the website or app you're designing, it's important to have a basic understanding of the current state of your site (if you're redesigning an existing site) or better understand your competitors' key elements ( if you are designing a new website or app). Much can be learned about the current situation from interviews with stakeholders (more on that in a few pages). You can also gain a lot of self-understanding, which can serve as a solid foundation for stakeholder interviews and user research. A good way to find context and generate ideas that can become requirements is to do heuristic analysis.

By any other name... the word heuristic means rule of thumb or best practice. Heuristic analysis already means reviewing the product in terms of a set of rules (heuristics) for available projects, usually performed by UX designers. A user-friendly website will obey most or all of the heuristics used in the analysis. You may also have heard of this technique called heuristic evaluation, expert review, or a combination of these terms.

Heuristic Analysis Heuristic analysis is a technique that can be used to evaluate the usability of an existing design against user experience best practices. You can perform this type of analysis on your current website at the beginning of a redesign project, or you can analyze competitor websites for the ability to provide a better user experience than other companies. The result is a document that describes the strengths and weaknesses of the site, including suggestions for improvements. When you finish, you will have a deeper level


Chapter 5: Business requirements

An understanding of the site you are analyzing and a list of ideas to help you meet new site requirements. For example, a common heuristic from Jakob Nielsen's list of ten heuristic practices (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 the user of what is happening with appropriate feedback within a reasonable amount of time.

There are many instances on the site where this heuristic may not be followed. For example, suppose a user clicks the "Download" button but does not receive a message that their file is being downloaded. Even though the download has already started, the system does not inform the user that the file is being downloaded. So the user may click the button again thinking they missed it the first time... and then click again... which can lead to multiple downloads - possibly causing site performance issues for users who do now without their knowledge Downloaded many times. During heuristic analysis, you can mark it as a problem area, describe it, and evaluate its impact. You can also share an idea that can solve a problem that can be added to the needs list. Why heuristic analysis? Running this analysis is a relatively quick and inexpensive way to get feedback on a project. Heuristic analysis can provide an overall understanding of design quality and help identify any potential design issues. Please note that this activity does not directly affect end users and should not replace actual user research. For example, perhaps only 50% of your heuristic findings will actually be verified by subsequent research. However, the analysis allows the team to address potential areas of interest well. If you're redesigning an existing product or website, it's also helpful to identify obvious quick fixes that can be fixed immediately as redesign work continues in the background.

Learn about the current situation


What should I do? The specific heuristics you use may vary from project to project, but the analysis process remains basically the same: 1. Gather knowledge about the product and the project. Make sure you understand your site's goals, a list of key user groups that need support, information about the types of environments your users might be working in, and a basic understanding of what your users might have. (For example, your analysis will be different for a website built for consumers than for a website built for pharmacists.) If you need help with the latter, visiting various competing websites or apps can help you help you understand the most common terms and areas of interest. 2. Select the heuristic to use. Many heuristics are available. In addition to Jakob Nielsen's list, many UX designers refer to Bruce Tognazzini's list of Design Principles: www.asktog.com/basics/firstPrinciples.html. Once you're familiar with your site's themes, you may want to add a few of your own, especially if you're analyzing multiple sites. Make sure the list is a reasonable size (eg 8 to 12). too many heuristics can make it difficult for you and your readers to use this technique. 3. Go through the priority areas of the site, identifying areas where the heuristics worked well or missed. Each observation made must contain the following information: General observations. Brief statement summarizing the findings. Ideally, they will be numbered so that they can be referred to quickly when guiding people through the report. Short description. A paragraph or two describing the context of the observation - for example, a point in a particular process where you noticed a problem. affect ranking. This score can be high, medium, or low for problematic observations, or it can be a record of positive discovery if you're sharing something the site does well. Typically, a high-impact problem is one that you think will prevent many users from completing a particular task or


Chapter 5: Business requirements

Permanent loss of information (for example, a problem that caused the user to lose changes to a document they were working on). Medium-impact problems are those that cause frustration and errors, but do not lead to irreversible problems. Low-impact issues are minor issues that may cause some confusion, but usually don't lead to time or frustration. proposal. These are the next steps or ideas you share as a remedy for a problem you are experiencing. Figure 5.2 shows an example of these elements as they might appear in the heuristic analysis. Observation #4 It appears that the search function does not return all possible results.

very expected

Sample tests of the search function yielded mixed results. Searching by name from a relatively recent post with a less common topic sometimes returned no results. It also seems that the main search engine only returns links to new stories, not videos. Recommendation 1. Ensure that newly added content is indexed and searched before or shortly after it is released to the public. 2. Consider showing related content when you return search results - for example, articles in similar categories or similar tags - so that users who explore will have more leads to follow. 3. Consider a universal search that displays results organized by category. 4. Use the search terms log to learn about the terms you search for frequently. This can also provide information on items that are difficult for users to find.

Figure 5.2 Sample observations in the heuristic analysis report

4. Present your findings to the project team and key stakeholders. Guide them through your observations and suggestions. Discuss why you gave the rating you did. (This is also a good time to prepare proposals for validating your results using one of the techniques discussed in Chapter 6.) How does heuristic analysis help with requirements gathering? After completing the heuristic analysis, you will have a deeper understanding of the current state of the site (or its competitors), as well as a list of ideas to help you gather requirements. You will also have some ideas on how to organize the topics to be discussed during the requirements gathering session – which will lead us to the next step in the process.

Learn about the current situation


Collecting Ideas from Stakeholders As we saw in the example at the beginning of this chapter, if you don't understand the context of an idea like "customers can track their orders online," you can lose engagement with your stakeholders. , such as those who want to track packages via their friends' GPS. One of the most common design mistakes is to grab a feature and call it a requirement without first understanding the problem and expecting a solution. So why is the claims collection process often cut short? Collecting ideas—and combining them into requirements—can take a long time. It is easy to underestimate the number of questions that need to be asked to outline and prioritize requirements. If the process is poorly structured or commitment is lacking, there can be significant turnover that will continue throughout the project. (Disruption is a waste of time for additional meetings and rework due to lack of communication and engagement. These are different from the more productive rework that is part of planning and testing effective solutions to find the best solution.) So how do you encourage a well balanced requirements process that focuses on business needs but avoids wasting time? Here are some steps for an effective process: 1. Outline roles and responsibilities. Ensure project team members understand their role in requirements gathering. 2. Gather the right stakeholders into the right groups to ensure optimal use of time during needs-based interviews or meetings. 3. Create an agenda for the meeting, including topics to be covered and questions to ask during the meeting. 4. Conduct meetings effectively to brainstorm ideas and get clarification. Research ideas to discover the need behind each idea. At the end of the meeting, be sure to thank relevant stakeholders and update them on your progress as you move toward a consolidated priority list. Let's look at each step in more detail.


Chapter 5: Business requirements

Defining Accountability The act of gathering business requirements typically involves project team members interviewing key business stakeholders to gather ideas. Business stakeholders are those in the company who are business-oriented to the success of the project, or who have the essential knowledge to contribute, or both. These people are not involved full-time in the project, but they need to be involved in key points of the process, and requirements gathering is one of them. Keep in mind that they also have per diems (so to speak), so their time is precious and often hard-earned unless you plan ahead. A project sponsor (or sponsor) is a business stakeholder who is also directly responsible for the success of the project, usually at a relatively high level within the company, such as a manager. He/she will not be involved in the project on a day-to-day basis throughout the project life cycle, but may be actively involved in gathering requirements and ensuring a high level of commitment from business stakeholders. The initiator can also attend part or all of the meeting. The project team consists of people who are formally assigned to the project as current resources. They may be involved as project managers, UX designers, business analysts, technical leads, visual designers, QA managers, etc. Depending on the size of the project, this may be their main job. Within the project team, responsibility for the requirements gathering process is often unclear. Taking the time to identify your responsibilities early will help ensure an efficient collection process. Here are some questions to ask when determining the specific responsibilities of each team member during the requirements gathering process: Who is primarily responsible for gathering and planning the correct

Are stakeholders among the most productive groups? This can include internal and external stakeholders (eg partners, suppliers, etc.). Who creates the topic and topic structure for business stakeholders-

Meeting of the owners? If time permits, this is a great collaborative exercise for a team. The main moderator can then put them in the flow of the meeting structure. Who chairs the meeting? Who keeps the notes and how are they shared?

Collect ideas from stakeholders


Who was following whom? Will someone from the technical team be present at all meetings?

If so, how was that person involved (listening, offering information, or something else)? As a UX designer, whether you are primarily responsible for one or more of these areas, you have important skills to bring to the process. Structuring topics and questions requires clear categorization skills (which sounds like a good link to information architecture) and facilitation skills are obviously important to keep the meeting on topic and everyone involved.

Gather the Right Stakeholders The main goal of stakeholder interviews is to understand the project's ideas, needs, knowledge, and frustrations from different perspectives and then integrate them back into the project requirements. There's also the sometimes unspoken benefit of having many different teams involved, which makes everyone feel like they have a say in the project - and therefore buy into the final solution. While it may seem more political than practical to get people on board to gain their support, it is often a critical step in getting in touch with a network that will support you throughout your project. It also helps you avoid last-minute changes, which can happen when someone you haven't spoken to asks a question late in the process. That's why it's usually good to have different people involved. On the other hand, keep deadlines and budgets in mind. From their point of view and yours, getting a large number of people on board takes time just for meetings - not to mention organizing notes to spot trends and consolidate layoffs. For efficiency and your own sanity, it makes sense to prioritize the groups you want to talk to and select key people from those groups to serve as opinion leaders in your groups. Which stakeholders can you involve? These groups are often a great source of ideas:

Marketing campaigns that require information to be displayed on the website)


Chapter 5: Business requirements

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

applications such as content delivery, data entry and management and immediate response to collected information frontline customer service such as telephone or online support or

Anyone who interacts directly with customers (for example, in a retail store or via delivery) for sales, product management or consulting services on their behalf

Products and services presented Human resources, for recruitment purposes Public relations, to present information to investors and the media Any groups responsible for other relationships that need to be developed

As part of the project and will affect its form, e.g. relationships with partners or suppliers. In selecting the individuals to be included, the project sponsor and all members of the project team who are familiar with the relevant groups should be assisted in selecting appropriate individuals. People. Create groups where good discussions can take place. There is no right way to do this, but a common way is to group stakeholders by department as follows: Marketing (five people) Product Management (four people) Customer Service (two people) Sales (four people)

A smaller project might involve one person from each group, with everyone coming together in a series of two or more collaborative work sessions. After considering your stakeholders and the general structure of the meeting (discussed in the next section), you can begin planning the meeting. Try to start planning at least a few weeks in advance. it can be difficult to get everyone into a room.

Collect ideas from stakeholders


Schedule a Meeting As you work to select the right stakeholders, create a list of topics to cover and questions to ask (this will also help you refine your stakeholder list). You should have a different plan for each group you meet with, although some of your questions may be the same in different groups. You also need to decide how detailed the meeting will be. If you're meeting a lot of people only once (eg members of different departments, as above), you'll want to gather ideas, but you probably don't want to spend a lot of time going through complicated details during a meeting. In this case, if one of your stakeholders comes up with the idea that "customers can track their orders online," you can simply ask why this feature is important and if the stakeholder can immediately think of a way to make it a great site. These questions should help identify key differences between stakeholder expectations for the feature without devoting the entire meeting to a single statement. You can then work through the details of the idea with the project team, returning with the stakeholder to ensure that the requirements created still reflect their original ideas. Let's say you are redesigning an e-commerce website and you meet with various stakeholders and each group holds a meeting. This is an example of scheduling a meeting with the sales team.

Sales: Requirements Participants Focus Session Inside Sales: Jenny Bee, Tracy Kim, Joseph Arnold Lead: Kevin Abernathy, Cat Parnell Time: 2 hours Objectives: Understand your current sales process and identify issues and opportunities on how the Internet can better support this process. Background: We reviewed a PowerPoint presentation on the buying process that provided a good background on how buying decisions are made. We also plan to talk to the customer service team.


Chapter 5: Business requirements

Sales: Requirements Gathering (cont.) Questions Sales Process: How is the sales process different for different product lines? Are there regional differences? Are there any differences based on customer size (eg small vs. large)? How has this process evolved over the past two years and how will it evolve over the next three to five years? How does a potential customer perceive everything there is to buy and how it all works together?

Overall Impression: Who do you think are the primary users of your current website? Why; who are they What are they trying to achieve on the site? How is the Internet affecting today's sales process and/or closing rate? What information do customers need to make a purchase decision? Is this information available on the website today? Is it easy to find? is accurate How hard is it to maintain content on a website today? What metrics are you getting from your website? What other metrics do you find valuable? Why;

Looking Ahead: When thinking about your future website, what can we do to better support the sales process? What current features and functions on the site are critical to sales? What is unnecessary? What is missing?

Summary: Any other thoughts, suggestions, or concerns we haven't addressed? Which pages do you think support sales well? The most important thing a company can do to improve customer satisfaction?

Collect ideas from stakeholders


Lead meetings effectively Here are some practices that can help you conduct requirements gathering meetings. Make sure you use a common vocabulary If team meetings include agreement on a common list of terms and definitions, many misunderstandings can be avoided. For example, will the people who use the system be called users, clients or customers? Are people more familiar with the terms interaction designer or information architect? To avoid misunderstandings, take time at the beginning of each meeting to explain which terms are used and what they mean. You can also benefit from creating visuals to explain the relationship between different terms or roles (see Figure 5.3). Category












Figure 5.3 Diagram showing location conditions and relationships

The common vocabulary of deliverables to be used in the project will also help stakeholders understand the process and the type of results they expect. This creates confidence that their time and energy won't go down a black hole of ideas. In general, if you define the same words more than once or twice (especially if you notice that each definition changes slightly), consider including them in the project glossary and sharing them with the project team. Other examples of terms that are good to sort out at the start of a project include;


Chapter 5: Business requirements

Roles that will interact (eg job applicant with client or competitor)

stage builder and editor) will be broadly referred to as the main end product (functional specification

Visualization, Wireframe, Sitemap) and a brief explanation of the differences between them Differences between different levels of information (such as our category

information in figure 5.3) the difference between needs and ideas

Listen to ideas and dig into needs Stakeholders can make statements that appear to be needs. Consider an example. business representative

"We need a blog on the site."


It's really an idea, not a necessity. If the blogging functionality is fully designed and implemented, it becomes a solution, but not necessarily the solution that best meets the stakeholder's basic needs. When you ask why blogs are important, you'll likely hear long-winded statements like “We need to look relevant and connected. Everyone is talking about blogs, and I think if we don't include them, we'll be "We need a way to keep people coming back to the site to generate more ad revenue, and blog means recently published content that has a lot of followers." a way to show our more personal approach to knowledge.” “We need to have better ways to communicate and innovate with our customers, and the blog allows us to comment so we can hear from them.” Each of these statements describes the effective demand By pulling them out, you'll understand the drivers behind specific feature requests, which will help you build consensus when integrating and prioritizing requirements.

Collect ideas from stakeholders


Merger Requirements After the meeting, organize the ideas collected into common functional areas. You will start to notice that there is a lot of overlap. it is a good sign that the idea enjoys strong support from stakeholders. Remove the unnecessary elements and try to collect a set of ideas that can effectively capture the intentions of the stakeholders. To turn the collected ideas into useful and traceable elements of your project, you must incorporate these ideas into the requirements. Think of raindrops forming from a cloud: you go from a large undefined cloud to a mass of well-defined raindrops. So when you get a cloud of ideas like "customers can track their orders online," you have to translate that into various statements that explain what the system should do. The resulting requirements should provide information on the general requirements to be considered, represent and integrate requirements provided by various stakeholders, give direction to the project without being too specific

Completed 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 who can represent your project development team) is committed to asking questions to help you assess what you need as you prioritize your next workloads. If you have a dedicated QA team member, that person can also ask very specific questions to help you gather requirements. To translate your ideas into detailed requirements, ask the following questions: How accurate does the trace need to be? What information should be included in the tracking details?

For example, do we need to provide a current delivery time estimate? Ask and extend these questions to the stakeholders who brought you the original idea if they have significant time to devote to the project. If you don't have access to these stakeholders, you can work out the details yourself through discussions within the project team


Chapter 5: Business requirements

Then review the requirements with your project sponsor to make sure your options make sense for the business. Table 5.1 lists the types of requirements that can be incorporated by monitoring concepts and how they are captured. Table 5.1

Examples of business requirements

ID card



Order tracking



Order tracking

Order tracking

To require

business needs

Orders can be placed through

Encourage self-care

enter the tracking code

During childbirth (support

In connection


Users can track their packages -

Demonstration of innovation productivity

Age of GPS, track the truck

fast delivery (competitive

or airplane


Users can see all previous orders Encourage re-orders and orders in the last 365 days

Self-service (sales, support services)

Note that in some cases the requirements overlap, such as the first two requirements in the table, which are both monitoring methods. They can coexist in the same system as you can enter a code to find your package using the GPS view. However, they are separate as GPS requirements may require more effort and should be prioritized over other functions. With these statements in mind, keep in mind any business needs that you believe may conflict with the needs of your users. 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, filling out forms takes time, security and privacy are an issue, and this step can interrupt the larger task they're trying to accomplish. When you identify such conflicts, they will begin to give you insights that can help you meet the needs of your business and users. In the tracking example, you can suggest a "send to a friend" feature that captures email addresses and makes it easy for users. This means that sending to a friend can become a condition to prioritize the mix. such thoughts

Collect ideas from stakeholders


It can help meet the needs of businesses and users, so it's perfect for downloading. They also exist in the area of ​​design definition and overlay (see chapter 4) when you start thinking about design solutions to business problems.

Determining potential conflicts between the design development business and user needs is a good thing to explore in the user research we'll cover in the next chapter. User research also expands Table 5.1 into a full set of possible requirements that will be prioritized in a list of design requirements (shown in Figure 5.1 and discussed in more detail in Chapter 9). Remember that business requirements gathering is usually done in parallel with technical feasibility study and user requirements gathering. Next: it's time to talk about users!


Chapter 5: Business requirements


User Research Find out who you're inviting to your event There are many user research techniques you can use throughout the project lifecycle to better understand your users or test their behavior on a version of your website. In this chapter, we will focus on some of the most commonly used methods at the beginning of a project. These techniques will help you determine which user groups should be given the highest priority during the project, put their needs and frustrations into context, and evaluate the performance of your current site (if any) using user experience design best practices. Caro Lynn Chandler

Basic steps in user research 1. Identify the main user groups. This involves creating a framework that describes the main types of users you are designing for, allowing you to focus on recruiting users for research. 2. Plan user engagement. This includes choosing one or more technologies to engage user groups in the study, depending on the needs of the project. 3. Do your research. Here, we'll discuss key techniques, such as interviews and surveys, and provide guidance on how to conduct them. 4. Check the user group definitions. Using what you learned from your research, you can solidify your user group model. This model is then used as a platform for developing more detailed tools such as roles (discussed in Chapter 7). 5. Create user requirements. These are lists of features and functions that a website can contain. You will add these statements to your business requirements (discussed in Chapter 5) and prioritize them to become design requirements (discussed in Chapter 9). In this chapter, we'll cover the first three steps, starting with the first step: defining user groups.

Define your user group Planning user research at the beginning of a project can seem like a chicken and egg (chicken or egg?) dilemma. How can you make sure you're talking to the right people if you don't yet know who those people should be? One way to start is to create an initial or tentative definition of the users you want to design for. It describes the main user groups of your website, which can help you focus your research efforts on the right people, demographics, or other variables that may affect how users use your website. User group definitions can be complex (specifying a list of each target user group) or detailed and visual (diagrams showing different types of users and how they interact with each other).


Chapter 6: User Research

A general definition of a company's main .com site might include the following user groups: potential buyers, current buyers, partners, and job seekers. Your initial definition is based on the collective knowledge of business stakeholders and project team members about the types of potential users likely to interact with your site. These definitions can be created by collecting certain goals and characteristics that different groups of users may have. Here are the basic steps for defining user groups: 1. Create a list of properties to help define the different users of your site (the next section covers some of the more common ones). 2. Discuss the features with someone in your company who has been in contact with the relevant user type (eg customer). 3. Prioritize those features that appear to have the greatest impact on why and how potential users use your website or app. 4. Determine the user groups to focus your research and design on. In the following sections, we'll take a closer look at some brainstorming techniques to help you gather these features and how to prioritize and model them (creating representations of different types of users to help you focus your research efforts) .

Create a property list A good start to creating a property list is to collect and include any studies or other documentation from your organization that may be useful to your users. Here are some possible sources: Documents that explain the company's strategy, such as the company's goals,

Competitor information, marketing strategies and business plans Market segmentation and other demographics of current customers

Collection from the Marketing Department Previous user research (examples in Table 6.1)

Define your user group


Surveys such as user satisfaction surveys and feedback forms Customer service reports including frequently asked questions

Next, identify the people in your organization who have some insight into current or potential users. The number and types of people to be included depend on the type of project, its scope and schedule. If you know that the initial user group definition may have a short life (for example, it is only used for a month or two when planning the user survey), then you can only include two or three participants. If you feel that the initial definition may need to guide you through most of the design process (for example, if you only have this definition to work with until you do usability testing after the project is complete), include more participants and make sure that you have a cross section. Some of the potential participants are marketers responsible for brand representation, departments and campaigns, salespeople, product managers, customer service or support representatives, and trainers. It is also a good idea to include 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 common characteristics they encounter. Here are some examples that may vary: Main goals related to your site's topic. because it is

Users come here, what are they trying to achieve? For example, buying items, trading stocks, or answering certain questions are common goals. Role. This can be defined in many ways, but one way is to combine roles

Main user target: job seekers, support seekers, prospective customers, etc. As you learn more about your users, you can categorize your personas according to different needs or styles. for example, on an e-commerce site, buyers may be bargain hunters and bargain hunters. Demographics including age, gender, family (single, married, children);

Income level and area. Experience, including education, knowledge of relevant fields

Technology (often referred to as technical proficiency), level of technical knowledge and frequency of use (one-time, occasional, frequent). 88

Chapter 6: User Research

Organizational characteristics, including the workload of the company's users

Their department, job type (starter, freelancer, mid-level manager, director), seniority (long-term or high turnover?), and work model (remote work, number of business trips). Once you have a list of some of the characteristics that come up most when stakeholders describe potential users, you can begin to prioritize them by their level of importance, and then use that hierarchy to begin defining and modeling user groups.

Prioritize and identify which of the features listed above do you think have the greatest impact on how and why different groups of users use your website? Focus on the ones you think will have the biggest impact on user goals or behavior. Prioritize these features and remember the goals you set in chapter 4—they will also help you make choices. The example best illustrates the priority of features. Let's say you work with a company that provides tools for online trading of stocks, options and futures. The firm has determined that part of its strategy will be to attract non-professionals who trade stocks online on their own and encourage them to try trading new types of products, such as options and futures. The company plans to do this by offering easy-to-use trading tools and appeal to those looking for hands-on learning in a safe environment. When discussing features with business stakeholders, the following features seem to have the greatest impact on how people use these tools: Current frequency of transactions, especially directly online

(eg quarterly, daily, several times a day). Those who are new to trading (eg once a month) may not seriously try new things, and those who are already trading full time may not see much value in tools aimed at new traders. But these active part-time traders may have a keen interest in the company's tools. Number of product types traded: only stocks or shares, options and

futures contracts. Those who already market all types of products may already have a preference for their media, but those who market only one type may be ready to expand to others. Define your user group


The level of subject knowledge (for example, trade knowledge

conditions). This will help you determine how much help they need in this process, including tutorials and glossaries. Level of technical proficiency (for example, knowledge of markets

online banking and online transactions). This will affect the assurance they need about information privacy and how advanced or simple the online interface needs to be. You can prioritize these characteristics as they can influence the types of users you will target with your research. If it appears that where traders live has no real impact on how or why they trade, the regional characteristic can be removed from the list for study participants to consider. On the other hand, if the concept of a particular feature is generating a lot of discussion, it might be a good topic for a survey or interview question (we'll talk about surveys later in this chapter).


Comparing two or more properties can also help with prioritization. For example, if you create a chart using two characteristics of online merchants, you can start to see how the groups fall into certain ranges. Figure 6.1 is an example of a rough user model where the two attributes Direct Trade Frequency and Number of Product Types Traded can be used. It also shows groups of end users that may arise from the discussion.

Full time product specialist

Experienced full-time generalist

The frequency of direct transactions

Second career trader.

Extra Income Marketer

active explorer

long term investor





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

After the 90s

Chapter 6: User Research

Figure 6.1 Diagram of two features representing the approximate user model. Constructing this model can facilitate discussions about potential differences in user motivation and experience.

This user model provides a general way to discuss different types of users. It is not a definitive model, nor is it intended for specific groups of users (users may be long-term equity investors or actively exploring other options or futures opportunities). But it does begin to express your understanding of different groups of users and how they might be motivated to use your site. This overview of important features can also help you discover which features to focus on when recruiting users for research. If you decide that trading frequency is important and prioritize those who trade with moderate frequency, you should define what you mean by moderate frequency (eg, one to three times per week) and recruit study participants accordingly. Speaking of research, let's talk about techniques you can use to attract users to your projects.

Is it possible to design based on user models only? In the field of UX, there is a debate about building user models before starting research, because it will influence your thinking before you have real user data, and because your project team or project sponsor may see the model as basis for alternative user research. Using an unverified model runs a greater risk of your assumptions being wrong. However, in projects where you don't involve users at all, a well-thought-out model (validated by sources outside the project team, such as a customer service or training team) is better than no model at all in the design process.

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

Choose a research technique


Table 6.1

Standard user research techniques


What is this

when useful


Typical time frame *

user interview

One-on-one chats with participants belonging to one of the site's main user groups.

Users can be accessed, but the type of access (in person, phone, etc.) varies.

Get instant advice. Gathering information about attitudes and context is difficult, especially when conducting remote interviews.

2-4 weeks for 12 interviews: up to 1 week planning, 1-2 weeks interviewing, up to 1 week collecting results.

context question

Field visits with participants to observe and understand how they operate under normal, everyday conditions.

The Gaining Access project team has very few information contributors. Go ahead and target your users. The impact on the user environment may raise concerns for users about safety, cognition and job security in a unique environment (eg hospital). property projects and intruUsers. For companies with fairly complex applications, these are tasks or workflows. It may be easier to access on weekdays.

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


A series of mostly closed-ended (multiple-choice) questions used to identify patterns in large groups of people.

You want to present your results in quantitative terms (eg "80% of your target user base says they never buy a car online").

Short-term surveys take 3-4 weeks: 1 week to plan and write the survey, 1-2 weeks to conduct the survey, and 1 week to analyze and report the results.

You want to get the context but can't find the user.

You are more interested in gathering preference information than actual performance.


Chapter 6: User Research

Take a suitable sample. Make sure the questions are well worded to get accurate answers without leading the interviewer to a specific answer.

Table 6.1

Common User Research Techniques (continued)


What is this

when useful


Typical time frame *

special team

A type of group discussion in which a moderator answers questions from participants about a specific topic. It focuses on revealing the feelings, attitudes and thoughts of participants about a given topic.

The team believes that the attitude of users will have a big impact on the use of the solution (for example, if there have been problems in the past).

Learn how to ask for the right information for your question.

3-4 weeks: 1 week to plan and draft questions, 1-2 weeks to guide focus group discussions and 1-2 weeks to analyze and report results.

card sorting

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

You are working on a multi-project content source site and want to provide your user group with an efficient structure.

Determine which topics are best covered.

3-4 weeks: 1 week planning and preparation, 1 week conducting research, 1-2 weeks analyzing and reporting results.

usability testing

Users attempt to perform common tasks on a website or app while the moderator observes and in some cases asks questions to understand user behavior.

Existing solutions are being improved.

Choose the right task you want to focus on.

3-4 weeks for 10 users and average form: 1 week for programming and writing tasks, 1 week for testing, 1-2 weeks for analysis and reporting of results.

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

He really supported the team.

Determine the level of formality of the exam.

*Standard time slots represent the time typically required from the user's scheduled time. Assume there are two groups of six to eight users (except for surveys where the number of users should be larger). This does not include intake time, which can take one to two weeks after the screening questionnaire is created.

What part of the research activity can I include? Before choosing a campaign, ask yourself how much money and time your team can invest in user research. Consider the following scenarios to understand your client's interest in user research. If the project manager and project sponsor are comfortable with user research and are interested in using it for a known purpose, such as ensuring that the site meets the stated goals of the project, you may have more options in research techniques


When you schedule two or more activities or activities that you perform multiple times (for example, testing a project, changing the project based on the results, and retesting the new project). If no one in your organization is familiar with user research and has some resistance to it, it's best to do a round of research and choose the technique that you think will bring the most value to you, your project team, and the . business shareholders. Once the results are available, the project team will have a better understanding of what was involved and how the project will benefit. Then you'll have a good reason to do further research later if needed. If you have room for at least two research rounds, it's a good idea to include one early in the definition or design phase to better understand your users. Then add another round to verify the design before starting deployment. For example, for a task app, you might interview users before design and then perform usability testing of the prototype later in the process. Or for a content source, you can start with a contextual query and then include a card sorting exercise.

Research Design Considerations When planning any research technique, consider the following factors: Why are you doing the research: What do you want to learn from it Who are you including: The main user groups you mentioned above How to get participants: Recruit people to participate and test (i.e. ask questions to make sure they belong to your target audience) How to reward participants Tools Chapter 13 will cover all of this as part of an in-depth look at one of the most common techniques used by UX designers: usability testing .


Chapter 6: User Research

Note For more information about task applications and content sources, see Chapter 2.

Surfer Steve Baty wrote an article outlining the different approaches and how to choose them depending on your stage of development, your information needs, and the flexibility you need to allow for user research. It's titled "Bite-Sized UX Research" by Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.

Let's take a closer look at each of these techniques and how they are commonly used.

User Interviews User interviews are structured conversations with current or potential users of your website. This can be done over the phone, in person in a neutral place such as a conference room, or preferably in an environment where users are likely to use the website. (The latter situation is also excellent for contextual research, as described below.) Interviews can help understand participant preferences and attitudes, but should not be used to make formal statements about actual performance. If you're looking for specific information about how people interact with your site, it's best to observe how they use it (for example, in contextual queries) or ask them to complete tasks on your site (in testing ease of use). Web analytics can also provide some insight into performance information, which is especially useful when combined with interviews or queries that provide context for the data. Basic flow For user interviews, UX designers create a list of questions to obtain the following information: Site or topic experience

Choose a research technique


Participants' attitudes towards the company's brand, for example, in terms of the categories of topics covered (e.g.

source), design process (in the case of job applications) or marketing method (in the case of marketing campaigns) common goals or needs that drive users to your website or other websites

Competitors Typical next steps users take after visiting a company page Other people in the experience. do e.g

Do users tend to cooperate with others as part of a larger goal they are trying to achieve? Will they share information or ask others for information along the way? Any other information that will help verify your case

Previous views for groups of users - for example, whether the variables discussed when creating the transient user model actually affect how users use your site. To keep interviews consistent, you can use creating a list of questions and scripted introductions. Decide in advance how you want your interview to be structured. If you want a formal report, you probably want a high degree of structure, with little or no variation in the order in which each question is asked, with little or no extras. If richness of data is more important than consistency, you can opt for a semi-structured interview where you start with a series of questions, but let the conversation flow naturally and the interviewer asks questions to explore further interesting comments (the so-called poll ) The duration of the interview can vary, usually the best time for photos is 45 to 60 minutes. It gives you enough time to build relationships and discuss a wide range of topics without boring the participants. User interviews provide a rich set of data that can be used to create personas, as described in Chapter 7.


Chapter 6: User Research

Interview Tips The quality of 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 make them speculate about what they might do in the future or what other people might do. This kind of information rarely predicts what they will actually do. Don't ask questions that imply a certain answer or steer participants in a positive or negative direction. Ideally, questions are simple, neutral and open-ended. Here are some examples of basic questions: What do you like about PseudoCorporation.com?

It is assumed that the user enjoys using the website. Only use this question if you're asking what they don't like. Did PseudoCorporation.com meet your expectations?

This can be answered with a simple yes or no, which doesn't give you too much detail to help you with your design work. Prefer to use PseudoCorporation.com or CompetitorVille.com

If the latter, why do you think they are better than Pseudo? This has several problems: it asks two questions in one statement and imposes a hidden opinion on the participants. Better question: tell me when was the last time you visited PseudoCorporation.com. why did you go there What are your impressions of this visit?

If you're conducting a longer, more formal interview, you might include some multiple-choice questions. But in most cases, they won't provide much information. When participants are interviewed verbally, they can be difficult to follow and do not allow users to edit. Usually, these questions are left to the audit or researchers. Run the test with someone, perhaps someone in your organization who is not part of the core team. This will help you identify issues that may not have been clear and help you adjust the timing and process. If possible and with the participant's consent, record the interview so that others can hear the responses directly from the participant.

Choose a research technique


Contextual Research Contextual research combines user observation and interview techniques. The UX designer approaches the participants, preferably the context in which they can use the website. For example, for an office application, a contextual question would require sitting at a participant's desk. This approach provides a lot of information about the environments in which participants work, including the real problems users face Types of equipment used Spaces they work in - in particular, the size of the spaces they are in

How much (or little) privacy they have, how often they've been disturbed, and how they use phones and paper (pay particular attention to the printouts they post or the notes they have on hand). They prefer to use a mouse rather than a keyboard. This can make a big difference

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

rescue. For example, if more than one person is using the same computer, this will affect how the connection and security features are designed. Other tools they use both online and offline. how people use paper

Particularly interesting - for some tasks it is difficult to develop an online solution comparable to paper documents! The question combines observation time with interview time. They can last from several hours to several days. If the participant cannot commit to at least 2 hours, consider conducting only one interview. During the observation, the participant will need some time to get used to your presence and engage in some physical behavior, which does not happen after 15 minutes. Basic Flow Prepare a 10-15 minute introduction that you can use in the conversation with each participant. It should include the purpose of the study, a general description of what you will be doing together (observations and interviews) and 98

Chapter 6: User Research

The information will be used. This is also a good time to sign the consent form and assure participants that what they share will remain confidential. Start with some general questions about the standard participant process, especially those related to web design. Let participants know when you are ready to stop talking and start observing. Observation can range from active to passive. With active observation, a common approach is for the participant to take on the role of master and you to be the learner. The master explains what he is doing as if teaching you his process. Active observation often provides more information about why participants behave, but can influence how participants act. In passive observation, encourage participants to act as if you were not there. Your goal is to observe behavior that is as natural as possible. For example, if a participant is talking to you, they may be less likely to answer the phone or ask someone a question about the problem they are trying to solve, but if you passively observe, they are more likely to do so. You can then proceed to the interview section by asking about the reasons for certain behaviors you have observed. Either method will work well. In general, if you don't have a lot of time with the attendees (say only 2 to 4 hours at a time), you can choose active monitoring to make sure you get the details you need. If you have a full day or more, passive observation can be a great balance between physical behavior and conversation. Once you get information from queries, you have a lot of rich data to search! So how do you spot patterns or trends in your results? A useful approach is a technique called affinity plotting. There are many good resources available on the subject, but here is just a brief overview. A Quick Guide to Affinity Charts Affinity charts are a technique that takes many different and independent pieces of data, such as user testimonials or research observations, and combines them to create patterns and trends. Here are the steps needed to design a simple kinship map: 1. Assemble the research team and attach their notes.

Choose a research technique


2. Give everyone a pack of sticky notes and ask them to write a statement on each piece of paper along with a short code that allows you to trace the statement back to the participant, for example their initials. Watch for statements that appear to apply to the design of the page, either specifically (statements of functionality) or more generally (statements that represent participants' attitudes toward the company or the issue). 3. Ask everyone to stick the sticky notes on the wall. If you're making a large study, you'll need a large, blank wall. try to get one that you can visit for at least a few days. 4. After writing all your notes, start grouping similar statements side by side. This part of the exercise can involve larger groups. This is a great way to start sharing results. 5. Once the groups begin to form naturally, begin to label the groups to provide further structure. If some sticky notes belong to more than one group, you can repeat them and place them in each appropriate group. Note This method is intended for contextual queries, but can be used in many other situations. For example, it's a great way to create categories for theme collaborations without categories, so it can help bring card sorting results to other levels of the structure.

Patterns can appear in many ways, so it's best to let them form. However, here are examples of the types of categories you might see, including the types of statements you'll find in them: Goal: "I'm trying to clean up all unfinished projects before I leave for the day." telling the user how

Mapping external experience to internal thought): "I use this online tool as a folder for things I refer to often but don't want to take with me." Idea and feature request: "I hope to undo it. Always

I accidentally moved an entire folder and it took me ages to undo it. Frustration: “I would ask tech support about this, but half the time they don't

Also know where the problem is. "


Chapter 6: User Research

Solution: “It took too long so I ended up printing the file

list and use it throughout the day. Then enter your results at the end of the day. Value Statement: “This tool has saved me a lot of time, so if so

Changing won't remove it! "

A standard source for contextual inquiry is Scenario Planning by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also provides detailed information on how to interpret results using techniques such as affinity plots. For more information on mental models and how to understand them, see Mental Models: Aligning Design Strategy with User Behavior by Indi Young (Rosenfeld Media, 2008). This is particularly useful when dealing with the information architecture of content sources.

Surveys Surveys consist of a set of well-defined questions that are distributed to a large audience. They often contain closed-ended questions (such as multiple-choice questions) that can be easily collected with tools that can reveal patterns of responses. Surveys are great tools when you want to present results more quantitatively than you can (eg "82% of respondents who work from home have some form of high-speed Internet connection") Learn about interviews Various open-ended questions used in the . However, qualitative information about user habits and attitudes can also be collected from them. In the field of user experience, surveys are often used to measure user satisfaction (satisfaction with an existing website or application) or to create or validate user models such as segments or personas.

Choose a research technique


Basic Process As with user interviews, you don't want to ask questions that require users to make guesses. Don't ask "If you had function X, would you use it?" Unlike interviews, true/false questions are the best and easiest post-mortem questions in yes/no multiple choice surveys. They can also make participants respond more quickly. Use surveys when you have demographic questions such as: Which of the following devices do you personally own? Select all that apply. Gaming system for PC mobile phones like Xbox, Playstation or Wii

Or for a multiple-choice attitude question: Read the following statements and note the extent to which you agree or disagree with each. Pseudo Corporation customer service met my needs. Strongly Agree Agree Neither Agree nor Disagree Disagree Strongly Disagree

In particular, questions like the second example are often used to supplement usability testing tasks. You can use this formula as a follow-up question to find out if participants were frustrated with the task. Participants did not always want to comment on negative comments, but often expressed their opinion in front of the ranking system. This leads to another point: Surveys are a great complement to other forms of research you might conduct, such as user interviews or background checks. Combining these two research methods can provide a richer user profile than either method alone.


Chapter 6: User Research

Surf If you want a high degree of confidence in your performance and are on a budget, there are official user satisfaction tools available that are easy to use. These tools include tested questions to ensure they do not lead or mislead a general audience. Some of the most commonly used are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and Measurement Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi. ucc. T. J

When designing a survey, consider the following: Who is your target audience?

To determine this, use a temporary model. This will affect how you answer the other questions here. Which survey distribution method will get you the best results?

If your main user base tends to be concentrated in a certain location, you can go there and create a form where people fill out paper surveys and you will likely get more results. If your user group is active Internet users, conducting an online survey may be the best option for a large number of participants. Or you can choose to use your current customer list to find a user group through a phone survey. How much time can participants spend completing

Research? If you offer some kind of compensation or receive some other benefit from completing the questionnaire, you can often prepare a longer questionnaire - one that can take half an hour to complete. If not, you need to be short for people to do it - think 5 to 10 minutes. Either way, be sure to give participants an estimate of how long it will take and let them know your progress as they complete (for example, using the page number "2/4" or showing a percentage of completion).

Choose a research technique


How do you know when to start analyzing data?

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

If you are conducting an online survey, the data collection tool you are using may have options for viewing and analyzing the results. If not, you'll need a way to input data into your tool of choice. For paper-based surveys, this means a lot of data entry, so be sure to plan ahead.

Focus groups Focus groups are about bringing together different people from the target group and facilitating discussions with them. The common goal is to obtain feedback on issues related to the organization or its brand, such as past experiences, related needs, feelings, attitudes, and ideas for improvement. Focus groups are a great method for several purposes: Listening to different user stories. Open discussion is a great way

A storyteller that comes out of each of us. When a focus group goes well, people build on their stories and ideas and remember situations they might not remember in a more structured one-on-one interview. The small group format and energy gives you time to remember and share these stories. Know the important empirical differences. most people are born

ural share information and want to compare their favorite tools with others in their interest group. You can often learn about competing websites or services, or hear advice on solutions, resources and support. Generate ideas. Although you don't want it to be the group itself

As a designer, you often get great ideas for new features or designs directly from the team or by hearing about their workflows or frustrations. As with stakeholder ideas, be sure to trace these ideas to the key requirements (see chapter 4) to ensure they are taken into account. Understanding the many points of the collaboration process. And if you are

When designing a process that involves multiple relevant roles and collaboration, teams can be a great way to bridge gaps in understanding


Chapter 6: User Research

how people interact. For example, if you are working with a content source such as an intranet, it can be useful to connect the people who create, edit and consume the content to identify areas where the process can be improved. There is much debate about the use of focus groups in UX research. This is not a good way to test usability (as users tend to work individually, not in groups) and sometimes group settings can over-influence participants' speech. However, if properly planned and conducted, focus groups can provide a lot of valuable information during planning. Chapter 13 discusses this further in the context of concept testing. Basic Process When writing focus group questions, consider the same techniques as when writing user interview questions (described earlier). Start with simpler questions like "Tell me the last time you visited PseudoCorporation.com. Why were you there?" Leave any brainstorming questions in the center of the group. Allocate blocks of time to each topic and stick around, it's easy to start a discussion and time runs out! If you're worried about time, put your most important questions in the middle list of your topics, in the After people are interested in the event, but before the potential crisis that may emerge toward the end Much of the logistics of a focus group is the same as a usability test (Chapter 13 provides advice on with selection, recruitment and planning).The main difference with focus groups is that there is a larger room and table so participants can work together freely. Each 1-2 hour group session is videotaped for 6-8 people. Onsite for everyone Give everyone a name tag or business card so everyone can call each other by first and last name The format of the conversation itself should include an introduction that usually addresses the following key points: Your role as a moderator and what you can expect from the discussion, get something

discussion (eg some of the points above).

Choose a research technique


Why are participants selected for participation (eg “You are all

current users of Pseudo Corporation's website, we gathered you to understand your experience"). How will this information be used - either in the project or with

position of secrecy. As a moderator, you can hear their feedback and

experience. You want them to feel they can share information honestly, so ask everyone to be honest, but also respectful of the rest of the team. There are many topics to discuss, so at some point it ends up being

Cover one topic to make sure you can cover them all. This can then lead to a round of presentations for the panelists, which usually includes ice-breaking questions. Your goal is to get everyone talking about the first question, even if it's just a short story. You can start with one person and work around the table, or you can let people respond naturally and then leave the names of those who didn't respond. You usually go around the table with the first questions, and then when you feel the group is ready, you can use body language to open up the questions to everyone.

Snorkeling: Body Language A good understanding of body language can be an amazing tool when conducting focus groups or any personal user research. It can help you understand when someone is frustrated, excited, angry, or threatened, so you can determine when you should try to make someone more comfortable or investigate a particular comment. It may take more than a weekend to read the entire book on the following topic, but it is designed to be easily flipped through: The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).

When calling someone who hasn't answered yet, repeat the question in case someone doesn't understand or hear you


Chapter 6: User Research

There were few votes in the debate. Also, avoid making disagreements look like differences between two people. Don't say, “Bob, we haven't heard from you yet. What do you think about what Chris just said?' Instead (looking at Bob), “Bob, what about you? How was that experience?” As a moderator, you control the flow of the discussion and hand over a virtual microphone. You can maintain control through eye contact, speaking volume, hand movement, and body direction. Most people pay close attention to body language, and if someone is dominating a conversation, these cues can be helpful clues. If an overly receptive participant does not pick up on these cues, use a gentle but firm statement such as, “Okay, fine, I want to pass this on to someone else. Has anyone else experienced what happened to Teresa? Same problem?". when moving on to a new, broader topic, verbally announce that the previous discussion has ended and a new one has begun so people can clear their minds for the next topic. Finally, as the event draws to a close , a simple glance at the clock and a change in body orientation can signal that the discussion should end. As with other activities, be sure to thank the group for their time. Sharing results with a group usually receives one of in both forms: sharing results based on main topics or grouping results into related categories, as is the case with contextual queries.Affinity maps can be another effective way to link trends and behaviors to visualize them in groups project.

Card Sorting In a card sorting exercise, participants (whether working individually or in small groups) are given objects printed on cards and asked to sort them into groups that make sense to them. They either group them into ready-made categories (called closed classifications), or they create their own groups and name each group separately (called open classifications). By the final round of card sorting, you should start to see common patterns in how people sort items, as well as common areas of confusion or confusion.

Choose a research technique


A common reason to do this is to create a sitemap for your website or create content hierarchies, categories and subcategories for items such as articles, documents, videos or photos. This makes card sorting a great technique if you're dealing with content sources. Note For more information about content sources, see Chapter 2.

Let's say you're working with a typical content source: a corporate intranet. Many intranets tend to categorize information by department they belong to, going into human resources, operations, legal, marketing, etc. This may not be an obvious problem for older employees who may already know the responsibilities of each department and understand where to look for information. But for new hires or those who need information not usually listed, it can be difficult to find information that may belong to multiple departments (or appear to belong to none). For example, where can I find the policy for new hires signing contracts? This can be in the field of law or in the field of human resources. With card sorting, you can find common patterns in how potential users categorize information, regardless of segment boundaries. Basic Process Collect the items you want to include in your card sort. 40 to 60 is usually a good range. You want enough numbers to allow for potential big decks, but not so many that you overwhelm the participants (or overwhelm yourself when you need to analyze the results). Choose items that you think are easy to understand and free of unnecessary jargon. You can include some subject terms that you think may be familiar to your user group, but avoid using too many "sensitive" terms. If you include too many company-specific terms or acronyms (such as "successful campaign" to drive sales), you'll test your company's marketing and communications effectiveness, rather than creating a general messaging hierarchy. For example, on an intranet, you might include vacation rules, 401(k) plan information, new employment contracts, vendor contracts, confidentiality agreements,


Chapter 6: User Research

New employee orientation, health insurance information and computer security policies. This list is a collection of clearly worded items that can be sorted in many ways. You can have one participant group new employee orientations and leave policies under Human Resources, while another participant groups new employee orientations and new employment contracts and name them Employee Onboarding. Once you have a list of items, put them into tabs that can be easily grouped and ungrouped. You can print labels and stick them to index cards, or print directly onto cardstock, which is perforated to separate into individual cards. Do a test by asking someone to sort the cards and give the group a name - for example, put sticky notes in a pile and write a name on them with a pen. Ideally, test takers are people who are new to the project and activities. This will help you get an idea of ​​how long the event will last. If the test takes more than an hour, you may need to cut a lot of cards! Once you have the final deck, you can ask an actual participant for the following basic instructions: 1. Arrange the cards into groups that make sense to you. 2. Try to create a group of at least two cards. If a card does not appear to belong to any group, it can be discarded. 3. You can name the group at any time during sorting. At the end of the event, name as many groups as you can. Certain trends become visible after observing the meetings. Others may require more analysis before drawing conclusions. Various tools are available for entering and analyzing card sort results. Many include tools that allow you to perform a remote card sort (see "Card Sort Variants" below for more information). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) provide remote sorting capabilities and useful analysis tools. Or, if you want to do your own sorting in a more manual way, check out Donna Spencer's excellent spreadsheet,

Choose a research technique


Instructions are available at www.rosenfeldmedia.com/books/cardssorting/blog/card_sort_analysis_spreadsheet. Card Sorting Variations So far, the discussion has focused on individual card sorting, asking the participant to name the categories they have created. This is an open taxonomy, meaning that the main categories are not yet available to participants, but are open to be named. This is a great approach when completing a new navigation structure or making significant changes to an existing one. In other cases, you can consider the following popular variations of card sorting: closed sort. In closed sorting, you define an advanced category

and add participants to them. The results are relatively easy to analyze because you have a small set of possible categories and you can focus on understanding which items fall into which categories most often. If you're adding a lot of content to an existing information architecture or validating an existing sitemap, closed taxonomy can provide quick and useful information to help you make taxonomy decisions. Sort by groups. You can

Use card sorting as part of a focus group class where participants sort items together. Although the results don't necessarily reflect how someone groups the items, you can gain insight into how people view the items and their organization by listening to people working together on an action and discussing the rationale behind each setting. Remote sorting. Sorting with physical cards can be especially fun

For group sorting. But there are many great online tools to sort with people. It also allows you to reach more participants or specific participants that may be difficult to meet in person. The aforementioned OptimalSort and WebSort are two tools that facilitate this kind of online sorting.

Usability Testing Usability testing involves asking participants to run specific tests on a website or application (or its prototype) in order to detect potential usability problems and gather ideas for solving them.


Chapter 6: User Research

If you want to gather information on how to improve your current website, you can do usability testing during the definition phase. Alternatively, you can do this on similar sites (eg competitor sites) to see the potential for a more user-friendly solution. In most cases, usability testing is done as part of the design phase, preferably in iterative rounds (build, test, refine, and retest during the design phase). We'll cover usability testing in detail in Chapter 13, "User Design Testing." This chapter provides recruitment and planning tips that can also help with the activities discussed earlier in this chapter.

After You've Done Your Research Now that you've completed at least one of these user studies, it's time to revisit your initial assumptions about your user group. Putting these assumptions aside for now, ask yourself what user groups you would create if you had more information. If some of your previous assumptions were invalid, consider any gaps you may have in your user research because key groups were not being covered. If this gap is identified early in your research efforts, you may have time to adjust and add another group of participants to the ongoing study to ensure you have the full picture. Armed with your newfound knowledge, you can tweak your user definitions to more accurately reflect the groups you need to focus on. This will help you create more detailed tools, such as roles (discussed in Chapter 7), and will also help you create the user requirements for the list we started in Chapter 5. In this chapter, we discussed the process requirements for collecting and distilling statements of business stakeholders. You'll do a similar process for your users—your work doesn't stop when you capture an idea or a request. Look at your core needs and goals to make sure you understand them. This will ultimately help you design a solution that best meets the needs of all relevant user groups. In the next chapter, you'll learn how to use the insights gained from conducting user research to create a tool that can focus on groups of users throughout the design and development process: personas.

after research



Personas Find the best way to put your team or customers in the users' shoes Personas are often discussed among UX professionals. Opinions vary from how much content is needed, how much research is needed, to whether they add any value to the project. Some people question whether they belong in this process at all. No matter where you position yourself, personas can be used to help design teams and clients resonate with their users. Personas provide insight into who your audience is and what their expectations and behaviors are, allowing you to control many parts of the project (business requirements, visual design or quality assurance). Lars Unger


What is a role? Personas are documents that describe typical target users. They are useful to the project team, stakeholders and customers. With proper research and description, people can form a very clear picture of who uses a website or app, and perhaps even how they use it. UX designers often see creating personas as a great exercise in empathy. Well-prepared personalities are often used as points of contact when questions or concerns arise about how to design aspects of a project. Can you take out your character and ask how you would behave? or what should i look for? While this process may not be as thorough as actual user testing of functionality and design, it can help move the project forward until you can perform more detailed testing. Josh Seiden (www.joshuaseiden.com) points out that there are two different types of personas: marketing personas that shape purchase motivation, interactive personas that shape user behavior

In this chapter we will focus on interactive characters.

Why is it worth creating a character? Personas help you focus on representative users during the UX design process. By providing insight into the "real" behavior of "real" users, personas can help resolve conflicts that arise in design and development decisions so you and your team can keep moving forward. How realistic should the character be? The answers vary widely. One person can be enough for a group, while another can create a complete "living space" for users' people to gain insight into how they "live". You can even go to extremes and create a personal online presence that you can interact with to gain insights into online behavior. How you decide to expand your role is up to you. Roles can constantly remind users. A useful technique is for team members to assign roles to their workplaces

Why is it worth creating a character?


Constantly remind them who their users are. After sharing an ankle with "Nicole," a 34-year-old certified hand therapist from West Chicago, Illinois, for a while, you begin to feel the need to give her an experience that will do her good. If it helps, keep a hard copy at all times while you sleep and let the penetrating fairy transfer the empathy from the pages of the book through your pillow to your sleeping subconscious. The purpose of the persona is to help you, your team, and/or your clients clear up some of the confusion that can arise when you reach a decision crossroads.

Searching for information about personas Successful personas must accurately describe many specific users of your product or website. To achieve this goal, personas must be supported by research. Chapter 6 covers basic research and modeling techniques to give your face a solid foundation. But don't look for an approach as an answer. it is best to find as much data as possible and combine it with data from observations and interviews - this can also include using online surveys and analyzing behavior on social networks. A common theme when creating personas: get real data, but create personas as real people on the page. To see how one company does it, see the sidebar Case Study: The Role of Messagefirst.

Creating Personas Once you've identified your audience and gathered the data needed to create personas, the next step is to put pen to paper and start bringing them to life. The number of characters you need to create will vary. Generally, there are at least three, but more than seven is not unusual. Instead of targeting a specific number, think about how many target segments you have and what you think is the best way to get fair representation.


Chapter 7: Roles

Case Study: Messagefirst Personas To create effective data-driven personas, Messagefirst (www.messagefirst.com) used at least three different sources of input from the following: Stakeholders. We interview them to find out who they think the character is and what their behavior is like. Always included. Customer Advocate. We interview people within the company who talk directly to customers, which usually means sales/marketing and customer service. Everyone has their own biases and we try to keep that in mind when documenting our findings. For example, the people who contact customer service most often are people who have too much time (often retired or unemployed) or are so unhappy with a product or service that they actually take the time to contact you. Customer. We talk directly to the real people who use or are using the product or service. Include as much as possible. Customer data sources. We check available blog traffic, surveys and emails. people we know. We choose someone we know who fits the original image of the character. This helps keep us grounded, ensures the characters are believable and real, and provides a real way to connect if we have additional questions. This is very important for validation and is always taken into account. Since each input source we use has specific biases, we use multiple sources to normalize the data. With data-driven personas, it's important not to expect how much you will have, but to let the data reveal how much you should have. When I analyze data, I look for gaps in behavior and activity. These vulnerabilities reveal individual roles. Todd Zaki Warfel, CEO of Message First;

An example character in this chapter is Nicolle, a 34-year-old certified hand therapist from West Chicago, Illinois. He happens to be a commuter who doesn't drive and spends 2-3 hours a day commuting to and from work. The fictitious customer is ACMEblue, which produces Bluetooth headsets for Apple's non-fictitious iPhone.

Create a role


This short paragraph tells a lot about Nicolle, but as you can see in Figure 7.1, the character contains a more detailed story about Nicolle. Note that the content is about Nicolle, not "written by" Nicolle. It's better to write about your characters from a third-person perspective than to write them in different voices, especially if you're just starting out. As you expand your experience, you should naturally explore and find the style that suits you best and offers the most value.

Figure 7.1 The role of the ACMEblue fictitious client

What information is included in the role? This is the kind of information your audience will find relevant and credible. Based on the research data collected, you should be able to determine what is important to your customers, brand and project. Most roles you create will share a common set of required content along with any amount of data, statistics, and other relevant information that can be considered optional, as they will vary from client to client and even projects.


Chapter 7: Roles

Minimum Content Requirements When creating personas, you need to provide enough information to attract people and connect them to people reading the site. To help your audience understand what your persona is doing and thinking, be sure to include six key pieces of information: photo, name, age, location, occupation, and bio. The next section describes how to fill in the details for each item. Photos Photos are the first (and real) step to getting a character's face. When choosing a photo for your personality, try not to make it look overly posed or elaborate. Photos that appear to be staged look different from photos in a more natural setting. Personas seem to perform best with photos taken in more natural settings, such as the photo on the right in Figure 7.2, where the subject is standing outside in winter clothing, possibly on their way to and from work. Make sure the photo matches the character's lifestyle! constitute

Natural Image 7.2 Images that look natural are more effective.

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

Create a role


Finding the right photo can be a waste of time if you're not careful. If all else fails (or you have the time and budget), do it yourself! Name In short, you need to put a name on your face. The photo you use will humanize the combination of research data and personality traits, and the name will be what everyone calls your character in conversations. Not only does Nicolle sound better than "30-year-old blonde, professional mom," but she's easier to remember and relate to as a specific character. Try to avoid names you use for different roles in your project that sound too similar. For example, Nicolle and Noelle are easily confused, so look for different names. And while it may be tempting to use the name of a colleague or client, don't. When you use similar or identical names to those involved in the project, it will be easy for them to try to identify with you. By choosing a different name, you can avoid unpleasant situations or hurt feelings. If you're having trouble choosing a name, some online resources can help: Baby Name Sites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Social Security Administration Most Popular Baby Names: www.ssa.gov/

OACT/babynames random name generator: www.kleimo.com/random/name.cfm

One last thing about names: Make sure your name is believable for the character. Nicolle is fine for a midwestern mother, but Nicola or Natalia might be a better name for an Italian mother. Also, names that seem funnier or spicier, like Bob the Builder, actually aren't. They usually make your character look silly and devalue them. Age While your research should determine the age range of your consumers, giving your characters a specific age can help add authenticity to your written biography. A 21-year-old student and a 34-year-old working mother behave completely differently!


Chapter 7: Roles

Location At first glance, location may not seem like important information. However, keep in mind that cultural and behavioral changes may vary by location. For example, in Italy, different dialects are spoken in different parts of the country. In the United States, a person living in Chicago will likely have different living expenses than someone living in Savannah, Georgia. Profession Knowing what your character does for a living helps you identify with them by understanding their daily patterns. A character working in healing meets many people on a daily basis, while a drawbridge operator may not interact with others. A biography is a compelling story that makes a character real. This is where you provide details derived from research data and combine them with some 'real people'. This means that the data is very important to the character, but you don't want to just state that information in broken sentences. Instead, you want to combine facts, anecdotes, and observations into a story that resonates with your audience. It might seem a little strange, but biographies need to be believable, and bringing aspects of real people to your character is definitely not cheating. For example, Nicole is based on statistics and the actual behavior of a person with similar actions, beliefs and aspirations. Depending on the project, you may need to delve into the biography - sometimes the more detail the better. Don't feel like you have to cram your character onto a piece of paper. Choose the method that works best to bring your character to life and give as much meaning as possible to the project you're working on.

Optional content When you use roles, you'll find that different projects require different sets of information to make the roles more useful. The minimum content requirements can also be considered the least common

Create a role


The denominator of most characters you create. More often than not, you'll mix some of these optional content elements with your core persona. Optional things that can add value to your character include education levels. Knowing a person's level of education can provide some information

Learn more about some of their habits. Someone with a high school diploma may have completely different buying habits and brand perception than someone with a master's degree, which can affect how people perceive your image. Salary or salary range. Money says everything and in many cases the amount

A person's income greatly affects their standard of living and disposable income. This information can provide important insights when targeting a certain level of wealth. Personal offer. What will your character's motto be?

like yours? Sometimes this can give you a quick glimpse into a character's basic mindset. Internet Activities. This can be difficult because people spend money in many ways

their online time. Some pay the bills, others indulge in blogging and social networking, and some simply use the computer as a device that turns on when they need to get things done. Since so many projects have some sort of online component, this component is a bit critical. You need to rely on your research to help paint the picture. offline activity. Does your character have any hobbies? There is some extra

Insights into what life is like when your character isn't online? This element can be as difficult as online activities, but it can have an equally significant impact on your character. A key entry point or activation point for a client, brand or project. often very important

Learn how personas interact with customers, brands or projects. Has the person heard from word of mouth, online reviews, billboards, TV or radio, or online pop-ups? Does your role want to solve a solvable problem with a customer, brand or project? Using statistics to understand this and writing them to your personas can help you create ways to engage your users.


Chapter 7: Roles

Technical comfort. Does your character use a PC or Mac? If she

Do you have a computer? Does he use instant messages, Flickr or a blog? Is he comfortable with the activity or confused by it? Would a very simple beginner's solution help her? Does he have an MP3 player or other portable device? Watching TV on a DVR or AppleTV or on demand? The list can go on and on. To continue. Depending on the client, brand, or project, it may be important to define these concepts as well as various others. social comfort. With the growth of social media and social networks,

When working, it can be important to be very specific about how your character engages in that particular space. Does he have a Twitter account? If so, how many followers does he have? How active are they? Is he a leader? Does he use MySpace, Facebook, LinkedIn, or other online aggregators or communities? Mobile comfort. With the increasing use of mobile devices

Pop, it's important to think about how your characters find their way into the mobile space, if at all. Motivation to use a client, brand or project. In some cases you may want to

State why the character wants to use a client, brand, or project. If he's constantly tangling his jacket headphone cables and pulling them out of his head, that's probably a good reason to consider new headphones. Realistic scenarios based on research data can help you discover key motivations to include in your personas. user goals. You may also want to specify what the character is expecting

Do it with a client, brand or project. This helps you gain insight into what drives the character to use it. These are just data points to get you started. You can create your characters and represent them in infinite ways. If you want to delve into the world of personas, a good place to start is the book The User Is Always Right: The User Is Always Right: A Practical Guide to Creating and Using Personas on the Internet by Steve Mulder and Ziv Yaar (New Riders , 2006).

Create a role


Advanced personas Once you understand the basics of creating personas, you can extend your documents in countless ways. A simple role can usually cover most of your needs, especially if your project team just wants to empathize with their users. Things get more interesting when you introduce the persona to the customer. In these situations, you will often find that you need to provide much more information than you gathered for the primary role. Figures 7.3 to 7.7 illustrate some ways to extend roles. You can rent these examples, mix and match them to create something even better for your projects!


Get to know the brand's consumers

Personas and Scenarios (Based on Ethnographic Research) Personas are composite personas based on target consumer data: in this case, ethnographic data, existing segments, and customer database data.

Scenarios are hypothetical but realistic narratives that describe why these people visit your brand's website and what they do there.

Joan, 32 Consumer insights help us understand our users - their motivations, goals and desires. To apply this information to web design, we developed user personas and scenarios based on real-world environments. This approach to design helps create holistic experiences based on understanding customers, their motivations, desired outcomes and behaviors. The script goes into detail about three key questions that need to be answered before a website can be properly organized:

Pleasure lover "I really like it" "Young and sophisticated"


start exploring

build experience

"Aspiring Newcomer"

"$)*&7&-&7&- Comfort

"Positive Respondents"

Feeling 5)&365

explore again

"A seasoned explorer"

improvement and simplification

"Grown in a Ditch"

Minutes for completing the mission "It Must Work"

Alice, 26 years old

Raphael, 42 years old

Erica, 47 years old

Greta, 59 years old

Figure 7.3 Master role overview table (horizontal). It provides an aggregate view of many people and the departments they represent within the high-level organizational strategy. Courtesy of Will Evans.


Chapter 7: Roles


Characters and Settings (based on ethnographic research) Alice is an aspiring cook who wants to explore the world of food,


Special food for children, with friends, finding new recipes online and in magazines. Her explorations are about more

He raised a family effortlessly

But more fantasy than reality. he is still afraid and no

Find quick, easy recipes using basic ingredients

Trying too many new recipes. Her mother didn't teach her many cooking skills and her friends aren't very experienced

I (often) cook two meals: for adults, for children

Cook. Alice is a busy mom of one daughter in Chicago. She and her husband both work outside the home, running the offices of a small insurance company.

Alice, 26 'Aspiring Newcomer' x Generation married

1 daughter, 5 tired, aspiring



She is very busy and down to earth and doesn't spend much time cooking. Alice just wants to make it quick and easy - although since taking up exercise after the birth of Sophie two years ago, she often has to prepare different meals for herself and her husband and is trying to get back into marathon shape . Using a small selection of successful recipes that she is comfortable with, many of her meals are based on packaged and prepared meals.

Alice and Sophie watch Cartoon Network while eating breakfast. Brand ads appear here displaying the brand name. Alice uses a brand and believes that Sophie will choose this dish. He decides to check the website after he gets off work. Alice visits the site half an hour before the meeting. The home page is clean and organized. It sees the main section of the site and links to interesting content like the recipe of the day.

internet use

Health awareness

cost sensitivity

Click recipe of the day. She loves the included instructions - they make her feel like she can handle this recipe. Unlike other sites where it is easy to get lost, it is satisfied with clean navigation. She likes the practical features that go beyond what she sees in cookbooks, like the ability to search for recipes based on the contents of her pantry, as well as tips on how to use those products. Alice discovers that she can receive a cookbook newsletter and clicks Subscribe. Signing up is so easy! Fill out the basic information and opt-in to the 'Food Your Kids Will Love' newsletter.

She's happy to add her own twists and recreate dishes she loves at restaurants, like her favorite roast chicken. She also wants to add more fresh vegetables to her meals because she knows they are healthier. She prides herself on being a thorough planner and being able to run a household on a shoestring budget. Her refrigerator and pantry are always stocked with food. Plans to shop to take advantage of discounts and coupons.

Finding kid-friendly recipes and nutrition activities Finding ways to 'dress up' her favorite foods Projects and initiatives Improved navigation and information architecture Improved registration

A week later, at lunchtime, Alice came across the brand's first e-newsletter: "Pizza as Simple as 1, 2, 3". Perfect - her kids love pizza and she usually buys it frozen. A link to "Pizza for Beginners" inspired her to see if she could make her own pizza. The link led her to a recipe for pepperoni pizza on a show called "Pizza Wizard." He looked at the recipe and found it extremely simple. only 25 minutes and 4 ingredients. He looks into the kitchen to see what she has. She didn't have pepperoni or pizza sauce, but the "pizza wizard" suggested replacing them with something from her well-stocked pantry: sausage and tomato sauce. Perfect! There is a link to the coupon. Neena prints out a shopping list with recipes, adds a few things she needs and goes to the store. After returning from the store, Alice began. She saw step-by-step instructions on how to roll out the dough and add toppings. There are pictures next to each step. It is easy to understand and follow. He wondered if he should cook the toppings first, but that question was answered in the Pizza FAQ.

Tailor regional information content More targeted newsletters Recipe guides Better coupon integration Meal planning Rely heavily on convenience foods, add relatively few fresh fruits and vegetables Spend more time Searching for recipes instead of cooking them

Figure 7.4 Faces of the target audience (horizontal). This granular view of an individual covers a wider range of data and provides a more holistic view of user goals, needs and behaviors - all within a larger ecosystem. Courtesy of Will Evans.

Figure 7.5 Overview of target audience and target audience persona (vertical). The Target Overview on the left provides an overall summary and shows the brands that the three individuals interact with and connect with. The detailed description on the right includes an outline and biography of an individual character, as well as information about their actions and motivations.

superior role


Paul and Helen “I think we could put anything in there. I'm just not sure how well it would fit."

5 4

Helen's mother died a few weeks ago and now they are busy cleaning the house. They are going to sell the house, but first they have to clean up a lot of things. The house also needs renovation work in the master bathroom.


- by de The basement is full of things that Eleni's mom collected over the last decades. He never throws anything away. It has been publishing newspapers and Time magazine for 20 years. Eleni wants to keep something. Most of the clothes - "dinner and furniture will be donated to Goodwill. Unfortunately, most of her mother's dairy" was destroyed by water and mold. He also has cans of paint, but Paul and Helen don't know if the paint contains lead.

2 1




Know Ex led pe gerie nc e C on Pric ve e Senior tunc pe sp Re e M pu e dut type Tim ion C on eline t Main ss ajo er r L Sizifes D E ecven lutte t Year Re rding pe Wast to Buars dsine Price and Rec am nlin ycli ne ac g count stop rate

This is the first time Paul and Helen have experienced anything like this. They don't even know where to start. They just want it to be as easy as possible. They know they need a litter box, but they aren't sure how much it will hold. They assume that almost anything can end up in the bin unless someone tells them to. Their only concern is that the litter box is unsightly. They want to find a company that won't make their yard look like a construction zone or destroy the yard when they make deliveries or pick up containers.

Age: 24-65 years old

Life cycle January




1.0 Life Facts

Main features Ŕ Ŕ

A single event, such as acquiring a home or a minor renovation (eg bathrooms). Little or no previous waste experience.

The Ŕ Ŕ Ŕ Ŕ Ŕ

Buy a litter box now. Get rid of anything they haven't kept or donated. Avoid property damage in the process. Avoid unsightly litter boxes. When the litter box is full, remove it quickly.

Frustrations and Pain Points Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Question Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

AVAILABILITY WHEN NEEDED Prices Vendors leaving the property How they found it Delivery the required container size Speed ​​of installation and collection after contact Access to online account for settlement and payment Equipment quality and cleanliness Well-known brand

Ŕ ŕ ŕ ŕ

Initial price shock They don't know the process They don't know what they don't know Making comparisons between suppliers

Is there anything you can't get into? How fast do they deliver and pick up? Will they keep the property as is? How does it work; Is a license required? How much? How easy can I contact someone if I need to?

Figure 7.6 Faces of the target audience. This person suggests a range of target ages, taken from research data. The information contained herein is broad and directed to the public and not to a specific individual. This approach can be useful when making a sales presentation or when a client's budget allows for detailed exploration of personas. Courtesy of Todd Zaki Warfel.

know everything

Amanda Stone


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



AMANDA shares responsibility for the incentive program with several other partners. They share access and manage multiple programs for clients. It can be especially difficult to make sure you're paying the right people for the right programs. It must be able to switch between different programs and always know where it is.



wheel of life

Basic features

Manage multiple projects Medium to large companies Medium volume (50-2000+ orders at once) Multiple people share a role 70/30 for fast payments and administrative checks One week to two months Year-round use I'm very interested in reporting You want to report on everything the sections Heavy Excel uses a custom internal system for interaction

The Ŕ Ŕ Ŕ Ŕ

Integrate with your current systems. Ability to pay employees quickly and easily. Cost (mainly time). help getting started.

Other applications Ŕ Excel Ŕ PowerPoint How can I run reports in all my programs? Ŕ Can Internet Explorer somehow get my credentials without calling Ecount? We can somehow integrate into ClientZone so we don't have to switch different applications. Am I doing it right?

Ac FT N cew ou P n Cart Zod Rene que est E Adasy s m Pa in y C he c R Cu ep ks or rr en rting tB al Peace Cu ople stom S o f t Sy STEM EX CE L



with influence

Pay your employees quickly and easily. Ŕ Prevent retry. Ŕ Check their current balance to see if they need a bank transfer. Ŕ Track weekly, bi-monthly, monthly, quarterly and yearly transactions.


in front of




dg i ow Kn






Uses the Account Zone very often - several days a week. As she manages many projects, she is very active throughout the year.

activities and interests


Age: 28-55 years old



The knowledge


Account Zone has been very helpful in issuing new cards and ensuring fast payments to program participants. One thing she lacks is the ability to watch each show individually and all the shows she runs to see how things are going. Her clients like to watch how the procedures are performed. Now tracking in Excel. After all, he either sends Excel files to his clients or sometimes exports them and sends PowerPoint with nice charts. It would be great if the Account Zone had a way to run reports both in one program and in multiple programs.


Ŕ ŕ ŕ ŕ ŕ






setbacks and pain points

Question -


You cannot watch multiple programs at the same time. Reports cannot run in multiple programs at the same time. Debugging cheat files sucks. It is not known exactly what the problem is and how to solve it. Many steps in many applications are not efficient and it is easy to get "lost" where it is. Multiple confirmation screens. Another username and password to remember. Look for an email with her login information.

Figure 7.7 Faces of the target audience. This role is a highly data-driven model. While the stories of daily life are narrative, the rest are bulleted to serve as project checklists. A diagram is used to convey a large amount of information in a small space. Courtesy of Todd Zaki Warfel.


Chapter 7: Roles

As you can see, the data can be combined in many different ways to present faces and adapt them to different situations. Start with a basic character and then expand it to your needs.

Final Thoughts on Personas Many UX professionals do not believe that personas are a good way to explain user needs, goals, and attitudes. They believe that personas can hinder creativity, innovation or good design for many reasons. Other practitioners believe that personas fulfill specific needs that influence the design process in a very positive way - when based on solid research data and combined with some degree of personalized reality. Which side of the coin you land on is entirely up to you. This section is not intended to influence your decision in any way. There are tons of articles online about this, and many professionals are ready to give you their opinion. All of these resources can help you determine how a role best fits your project, so keep an eye out for them. Jared Spool, CEO and founder of User Interface Engineering (www.uie.com), also offers some insight on this topic: The value will be an input function and then become a character. During design, the ideas in the team leaders will influence the final design. Character descriptions are meant to remind everyone what happened.

Jared's bottom line is simple: by observing your target audience, combining what you learn with survey data, and putting it all together into segments, you should be able to create personas that trigger behaviors that keep your team on track and create the best empathy app possible. website or product. Ultimately, though, your characters will be a lot like Santa Claus: they'll only be valuable if people believe in them.

Final thoughts on the character



User Experience Design and Search Engine Optimization The Fundamental Role of User Experience Design in Effective SEO Search engines are the cornerstone of the interactive economy. As "interactors," everything we do is ultimately connected to the entire world through Google, Yahoo, MSN, Ask, and the countless additional search engines that make up the online search infrastructure. Information architecture is an important part of how search engines interpret websites. This chapter aims to give you a basic understanding of why UX design is critical to SEO and what factors need to be considered in order for the environment you create to be competitive on Google. Jonathan Ashton


Introduction to SEO Briefly, search engine optimization is the process of developing and maintaining web properties for the purpose of achieving and maintaining top positions in public search engines for specific key phrases. Search Engine Optimization (SEO) is like a martial art, the process of learning and practicing never ends. Even champions can use observed behaviors or learned methods to make further progress. As long as there are search engines and websites interested in selling something to searchers, SEO will work. SEO is based on three main areas that need to be improved and influenced:

May affect - site infrastructure, technology and content organization rules and all related keyword issues related to optimized terms

Search engines look at link or link popularity - the quantity and quality of links pointing to you

How the site differs from other sites and how the links on the site are organized. We'll distinguish each of these three aspects and examine them from a UX designer's perspective to better prepare you for future optimization challenges.

Why is SEO important? It is interesting that even today we have to explain the importance of SEO. Clients usually understand to some extent that it is important for their website to attract targeted visitors from the organic results of major search engines, but otherwise most interactive marketers struggle to understand the potential impact on SEO. Global search data is available from a variety of sources, but the most important thing to understand is that regardless of the source, the numbers are huge and the annual growth is always in the double digits. For the most part, global searches are increasing quarterly. When Google first launched in 1998, 10,000 searches a day was a huge number that put incredible strain on the beta system.

Introduction to SEO


Hitwise (www.hitwise.com) reports that Google and its subsidiaries (including AOL and YouTube) account for the largest search share in the world, accounting for nearly 72% of US searches in November 2008. Second place went to on Yahoo with nearly 18 percent, MSN and Ask.com with 4 percent and 3 percent respectively. Internationally, Google is even more dominant: its market share exceeds 80% in many markets. NOTE For more information on the origins of Google, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), in 2008, 750 million people worldwide performed more than 60 billion searches per month, with more than 18 billion searches occurring in the United States alone. In other words, 95% of Internet users use a search engine at least once a month, and the global average is over 80 searches per month.

Beyond these remarkable sales figures, what does this mean for interactive marketers on a practical level? In short, if you're not reaching your target customers when they're looking for your product or service, your competition has the opportunity to outsell them. Take a look at your website statistics and think about it this way: How much revenue would your website make if your strategically targeted traffic increased by 10%? What about a 100% increase? Or 1000%? SEO is essential if your website is not generating significant traffic through organic search. A small investment in SEO can go a long way, especially if all of your engagement marketing efforts so far have focused on buying traffic through sponsored lists. We've seen a 35-to-1 website ROI relative to monthly SEO spend. If you're paying search engine companies for sponsored list traffic, but not investing in organic traffic, you're essentially limiting yourself to about a 10% chance. Think about your search behavior: when was the last time you clicked on more than one or two paid sponsored listings in search results? Any discussion of why SEO is important and why it exists could go into chapters. Suffice it to say that Google is only going up, effective interactive marketing must have SEO as a fundamental element of effective execution.


Chapter 8: User Experience Design and Search Engine Optimization

Important Core Resources Expertise comes from a well-rounded education. A professional who focuses only on his specialty loses his perspective on everything that surrounds him. Therefore, it is imperative that every user spend at least a few minutes to learn SEO. Although there are no official guidelines, Google has been kind enough to provide some very important resources. If you are at all interested in working towards better search engine performance, check out this link: Webmaster/Website Owner Help: Search Engine Optimization:

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

www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35769 Beginner's Guide to SEO:

www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf If that's not enough, check out the newsletter and blog. Start with SEOmoz.org and dig deeper. Remember, like 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 technologies firmly embedded in the Web 2.0+ world. The basic principles of the search engine have not changed much since the launch of the WWW Wanderer in 1993, when they searched the web and built the first Internet search engine. Basically, every search engine has an application (also called crawler, spider or crawler) that looks for links and follows them, sending copies of the resources it sees back to its database. The database is then analyzed according to the search engine's proprietary algorithms. Using these rules, the web service is indexed and then ranked according to its score on the search engine scorecard. In this fairly simple process, UX designers face countless pitfalls.

Site technology, planning and infrastructure


Understanding these key relationships will allow you to see your website through the eyes of search engines. An optimized website is based on structures and techniques that facilitate the movement of search engine robots. Likewise, many decisions about how to treat content affect how well search engines rank results. So much of it is predetermined by decisions made in context and discussions about content design and management.

Flash, Ajax, JavaScript and other scripts Today's dynamic and interactive website designs rely on technologies that are not at all search engine friendly. There is a growing gap between what search engines see and what designers can do. User experience designers provide a strategic plan for implementing dynamic, intensively designed websites so that both search engines and users have the best possible experience. Having a basic understanding of how search engines interact with this type of content will help you decide when to implement it and where to address its weaknesses. It is entirely possible to create an optimized website that relies heavily on scripted content if proper compensation is done early in the process. Once your website is up and running, it becomes much more difficult to create static or indexable content. Therefore, there is a strong case for static content, both for usability and for search engine bots. This may seem like extra work upfront, but the return on investment is exponential. Flash Flash content is technically "indexable". Search engines have recently made some progress in their ability to crawl Flash files to find text and links embedded in these resources. Have you ever seen all-flash resources get the top spot in search results even though the content is indexed? You probably didn't, because opening a fully Flash-compatible browser through a search engine is dangerous. Assume that all links and text content embedded in SWF objects are fully visible to search engines. What prevents a rogue optimizer (or "black hat") from putting apples in an object's text layer on display


Chapter 8: User Experience Design and Search Engine Optimization

Send an orange to a user who views a fully compiled resource through the browser? How can I deep link a Flash resource without fully compiling it? These fundamental vulnerabilities will remain until search engines reach the level of artificial intelligence that can tell that an image is a picture of a horse without the associated text saying "this is a picture of a horse". To create a search engine friendly Flash site, you need to add a static content layer that renders Flash content. Leaving search engine needs aside for now, a level of static content is key to meeting usability requirements. Think of a search engine as someone browsing the web via a phone call or a browser with a screen reader. These people may be the lowest common denominator and the authorities behind web development may be ignoring this small percentage of users. But when you underestimate this small group of people, you also underestimate GoogleBot and Yahoo Slurp, the two most important users of your website because they are the crawlers that allow the major search engines to index your website. If search engines can't see any text or links that can be indexed, your content will inevitably not be found in meaningful search results. Static layers can be implemented in many ways. For search engine compatibility, the static content layer must reflect Flash content. It's not an opportunity to present search engines differently than in Flash. If you do, you will go against the spirit of the game and be on the dark side. The ideal way to embed Flash content in a static layer is to use a SWFobject so that the Flash content and the static content can reside in the same URL. This will allow search engines to find static content and Flash-enabled browsers to display animations instead of static content. If possible, do not use redirects to maintain popular links to Flash content. Google Code provides a simple set of instructions for implementing this simple JavaScript at http://code.google.com/p/swfobject. There is another option that works at the bottom of SEO. Hiding hiding may be a dirty word to SEO purists, but if you approach the challenges below with the right perspective, you can have your cake and eat it too.

Site technology, planning and infrastructure


Cloaking uses user agent detection to detect search engine bots when visiting websites and direct them to static pages for indexing. However, when a visitor sees the same page in search results and clicks the link, the site detects that the user's client is a human with a Flash browser and serves that person's stream to a completely different URL. The bottom line is the same as the SWFobject approach: you need to show search engines exactly what you're doing in the hidden content, what you're doing in the Flash content. Ajax, JavaScript, and other scripted content A powerful Web 2.0 content driver, Ajax enables web developers to create content without pages. However, search engine problems with Ajax are multiple and require good planning to avoid major mistakes. Ajax stands for asynchronous JavaScript and XML, which indicates the difficulty search engines have with this technology. Search engines are basically bad at JavaScript. The efficiency that JavaScript provides to developers is a problem for search engines with dynamic content. Another problem for search engines with Ajax is the asynchronous nature of the technology. Search engines only see content on initial page load, and content loaded via script after the shell is initially loaded will not be visible during indexing. Since Google cannot extend the session after the initial page load and there is no mouse or external agent to trigger the script, any user-triggered off-page content will not be visible unless the text content is contained in a preloaded shell. Specifying the 3D modeling required to create the pageless design also included the requirement to preload text and links into the page shell. Anything else, your nice design is invisible. Scripted Navigation One of the most common optimization problems is the use of JavaScript at the heart of site navigation. This is a very common situation and is due to the way many website builders and content management tools work. Scripted navigation looks cooler, so people tend to use it. But if JavaScript is the technology that drives site navigation, the result is that search engines can't model links correctly


Chapter 8: User Experience Design and Search Engine Optimization

Site Links: They just don't see the link structure of the site. If search engines can't model the link relationships on your site, in-depth content won't be visible or given the correct link popularity.

Content Management Systems Content management systems are built for human convenience, but many make it difficult for search engines to process their results. Here are some common problems to avoid by using workarounds or choosing a more search-friendly content management system: Dynamic URLs. Search engines don't understand "pages" of content.

Know the path to this content. Changes to the path or URL to this content may result in unexpected multiple cloning of the content by search engines. This condition can significantly impair the website's ability to function properly. If your content management system has a system for generating a session id in the url, you may be in big trouble. Use advanced analytics tools for tracking, not session IDs. Multiple URL paths. Common Ecommerce Content Management Problem——

Age is that as the product progresses through its life cycle, it creates multiple URLs. Also, since search engines can only identify content pages by the URL where they find the content, crawlers quickly track the page when a product appears in a category and is part of a gift basket and weekly special (and so on ). Many different links to find the same content. Do your best to ensure that each piece of content exists in only one URL, and that multiple paths actually depend on a single URL, regardless of where the link is growing. Rely on a mature analytics system to resolve channels. Unintentional cloning. when you realize the piece

Content should only be accessible via a URL path, it's easy to see other situations in content management systems that lead to unintended content cloning. Suffice it to say that the schema only needs to have one URL path to a single piece of content. Infinite loop. The corollary to the inadvertent cloning problem is this

Loop at night. Make sure you don't get search engine spiders

Site technology, planning and infrastructure


Keeping track of "next" links in a calendar or similar can be a never-ending task. If a search engine spider can follow the next link to the next calendar day where it can find another next link, it will follow that link to the next page, and so on. Prevent this by using captive links that search engines can't follow so crawlers can spend time on the content you want to index. Old URL structure. The first thing many website redesign projects do is

What ects does is replace the old URL structure. The problem is that search engines can already index the content of these old URLs, and when you change all of that, you're essentially sending the index back to where it was. Additionally, any backlinks the site has accumulated over time point to the old URL structure. Keep as many old URLs as possible at all costs. You will probably need to change all your urls after changing your CMS, so if this is unavoidable, we strongly recommend that the old urls get a "301 Moved Permanently" status code and redirect to oneto - Based on old url to new url 301 redirects are the only redirects accepted by search engines.

Domains, directories and URL structures are important. If you're starting from scratch and brand restrictions allow, try choosing a domain with one or two keywords. It's hard to find a .com domain with good keywords these days, but if you do, separate them with a hyphen. An important part of UX's impact on SEO is your site's directory structure. This has a big impact on the distribution of link popularity across the site. Simple is better. Avoid unnecessary files in your directory structure at all costs. Some content management systems will automatically insert a subdirectory. avoid it if possible. This situation weakens the importance of the whole site. Search engines recognize a site's hierarchy based on the site's directory structure, so make sure your most important directories are at the top of the hierarchy. If your environment allows it, use keywords related to parts of your website in your URL structure. separate keywords with dashes and


Chapter 8: User Experience Design and Search Engine Optimization

Don't use too many keywords in a file name. Look for something like: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure you set up a redirect for http://site-in-question. com to 301 Moved permanently redirects to http://www.site-in-question.com. If a site recognizes content with and without www, search engines (especially Yahoo) will index the content of both URLs, opening the entire site to prevent accidental copying. This tends to spread when third parties link to a non-www site and that site has a dynamic link structure.

Content: Was (Is) and Will Be King While producing content is someone else's problem, laying the foundation for your website architecture has a lot to do with making relevant content available to search engines. As with all forms of keyword research, you need to understand the actual behavior of people who want to view your property. Search engines are still very "primitive" because they rely on users entering keywords in order to match them with properties that are more or less related to those words. Choosing the right phrase is all about whether your site is relevant in the right context. Ideally, your SEO partner will provide you with a set of target keyword phrases before you start and work with you throughout the wireframing process. If you don't have such a capable partner in your process, take a look at the Google AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) and analyze the actual behavior of search engines in your category. Then spend some time processing this data to find out what phrases your potential customers are searching for and use those phrases appropriately throughout your website. Search engines look for keywords at several points during the website analysis process. Optimization is about making sure the right words appear in the right places. By understanding the role of keywords in the UX design process, you will create the framework necessary for future success.

Contents: Kings who were (and are) and will be


So why is content king? This is the essence of what a website is supposed to provide. Search engines need textual content that they can see and index. Website visitors demand engaging content that deserves their attention. Bloggers and webmasters need link-worthy content. Without the right content in the right place, search engines cannot link the right users to your site.

Naming Conventions and Battle Jargon Your keyword goals should be reflected in the taxonomy you develop for your site. Using key phrases in the main structure of your website makes your entire website more relevant to what you sell. If you sell widgets, don't call your online product offering a catalog, but a widget catalog. Likewise, use keyword research to make decisions against jargon. For example, use laptops instead of laptops in the structure because people search for laptops over 10,000% more often than they search for laptops.

Metadata, Titles, and Keywords It's amazing how far we've gotten in this chapter before we delve into the basics of metadata. There are countless meta tags available, but only a few really make a big impact as all others are prone to spam. Related tags are: Page Title. Note that this is not the casetag but

The actual markup in the header. This tag contains the actual page title, which is the most important 65 characters on the page. Think of book titles like the little labels on an old-fashioned library card catalog that say "Clements, Samuel," indicating that all the cards behind that label are books by Mark Twain. Every page on your website should have a unique page title. Don't stuff your titles with keywords and make sure your most important words come first. Meta keywords. The hashtag has almost zero impact on searches

engine as it is prone to spam. The exception seems to be that the Google AdSense union looks at the keyword meta tag, while Yahoo affects it in a very third-party way. metakey


Chapter 8: User Experience Design and Search Engine Optimization

You need to match the content of the page, and this tag is actually a good place to introduce potential typos. Each page should be different. meta description. As with page titles and meta keywords, keep this in mind

Each page's meta description is unique. This description is only: a summary of what is contained on the site. Say no to the sale, about 150 to 160 characters. This content is important because it is likely what search engines will display when they link to your site. If the page does not contain a meta description, search engines will look for a snippet of text or other content that contains the search keyword and display it in the results. Meta descriptions are more about usability than SEO, so make sure every page is properly tagged. "Noindex" meta tag. If you have pages you don't want to include

Use the noindex meta tag in your search results. Just make sure the pages you actually want indexed don't accidentally contain this tag. Heading. Search engines recognize titles etc.

As a factor it is enough not to spam. Make sure some titles are both descriptive and include relevant keywords for the page. The anchor text of the link. Important factors that affect what a link's anchor text is

Search engines will look at the page on the other side of the link. This is what created the “Google Bomb”. If several links point to pages with the same anchor text, Google will interpret the target as being related to the phrase in the anchor text. For example, if you search for "click here" on Google, Adobe's website will appear among the top results. There are thousands of Adobe links that say "Click here to download Adobe Reader" or something like that. Use it to your advantage. Anchor text should not contain the words "more" or "click here". Instead, it should contain keywords that are relevant to the landing page.

Share your hair. Having separate index pages for left-handed and right-handed Ripple widgets is beneficial to you. This level of detail increases the likelihood that your page will match the legendary long-tail search exactly. A website that focuses on one thing does

Contents: Kings who were (and are) and will be


You're more likely to win this than a site for many things (all other factors being equal, of course). Who cares to read pages with hundreds of words?

Using a Sitemap Skipping a page with a classic sitemap has become popular in recent years. It's a usability bug and an SEO bug. Know that every website needs a sitemap. It may not be cool, but it is necessary. Also include sitemap files in /sitemap.xml and /sitemap.txt. While this structure doesn't improve your site's ranking, it helps search engines understand your directory structure and find new and updated content.

Keeping Your Content Up-to-Date A key factor in achieving and maintaining top positions in search results is to constantly refresh your website content. This doesn't mean constantly editing everything on the site. This means that the site must be constantly evolving. Create a directory structure that makes adding content simple and intuitive and predicts your site's growth over time.

Other Content Issues The main challenge in hosting content-rich Web sites is preventing content from being cloned or copied. Beware of duplicating pages with seemingly innocuous conveniences such as print-friendly content, i.e. exact copies of pages in a PDF or similar document. Block pages of this type using script links or the rel="nofollow" link attribute. Don't neglect to optimize for the various digital properties that search engines can index. This topic could almost be a chapter in itself, but suffice it to say that PDFs, videos, images, and other offline resources are clearly part of organic search results. Wrapping these elements is critical because search engines need indexes for such content. For example, a search engine cannot determine that an item is a horse racing video if there is no link to that video with anchor text "horse racing video" in the code next to the text about the horse racing video on the page.


Chapter 8: User Experience Design and Search Engine Optimization

Using alt attributes is another way to help search engines find non-text elements and is always a good idea for usability reasons. Don't create blind pages of content. Make sure that even at the bottom of the structure there is a link to the home page, so that the search engine bots do not end up in a dead end. If your page type doesn't include navigation to the main site, navigation links are an easy way to do so.

Link Popularity Explained If there is an SEO holy grail, it is link popularity. It is the cornerstone of Google that surpasses other search engines when it was launched. Link popularity determines the quality and quantity of links to a web service from other websites. Google uses the term PageRank which is a super factor that overcomes many other shortcomings. Links are basically votes for web services, and it is often assumed that something of interest or value to others will have links pointing to it from other trusted web services. Over time, this concept has proven invaluable in the fight against spam and is based on the basic principle of high-quality search results. This principle is crucial for UX designers because of how link popularity will be distributed throughout the site structure.

Typical Link Popularity Distribution Like the Richter scale used to measure the intensity of seismic activity, Google's PageRank system (named after Larry Page himself) is a logarithmic scale from 0 to 10. This means (generally concept) that if a page has If one PR is 4 and another is 5, then a page with a PR of 5 has 10 times more link popularity than a page of 4. This is worth understanding because PageRank is distributed to sites based on link hierarchies and directory structures. Generally, if your home page has a PageRank of 5, then your main section should have a PR of 4, your secondary page should have a PR of 3, your tertiary page should have a PR of 2, and so on.

The popularity of the link is explained


Pages with the most internal links to them tend to have the most link popularity. The most important pages should have as many internal links to them as possible. This includes links in the main site navigation, sitemaps, footers and embedded links embedded in text. Since link popularity is critical to a good search ranking, you should be as careful as possible to have the most link popularity on your shopping recommendation pages. Each page has a certain link popularity that it can bring to other pages on the site. A link from one page to another will send the recipient 100% of its available value. A page that has 100 links to 100 other pages sends 1% of its value to each of those 100 pages. The homepage tends to have the most link popularity because a website's homepage tends to have the most links to it from third-party websites. This means that the home page contributes the most to the other pages of the site. If there is a key page that is part of your "offer to sell", link it directly to your home page so search engines can see how important that page is compared to the rest of your site. If possible, create a function that can spin links to deep content from the home page.

Footer Links When looking for ways to organize and control the distribution of link popularity on your site, keep in mind that text links in the footer of any page are both a blessing and a curse and have some effect on the distribution of link popularity on your site. Side. Standard footer links point to privacy policies and other non-transactional pages, so if you need those footer links, hide them behind some script, or better yet, use those rel="nofollow" "nofollow" link properties. This will prevent each page's link popularity from leaking to pages that don't need to rank in search results. Preventing link popularity is also better than excluding robots.txt pages entirely.


Chapter 8: User Experience Design and Search Engine Optimization

In-Content Networking Search engines eat links embedded in text. Just don't overdo it. Some schools of thought believe that search engines do not give favorable weight to the first links in a block of text. Place the most important links at the beginning of the text and the anchor text of the link contains keywords relevant to the landing page.

Gaming System Who said SEO is work and not fun? Search engines can give website owners real money, and in some environments, there is a truly limitless way to get top rankings at any cost. More than a few SEOs have taken advantage of their clients by charging the highest fees for bogus techniques that can bring positive results in the short term, but have disastrous consequences over time. Over the years, webmasters have used various optimization techniques to get the best results. One of the major developments in search engine technology has been the effort to develop clever ways that have been discovered to cheat the system. From a search engine's perspective, it is in the user's best interest to display clean, highly relevant results at the beginning of each query. From the perspective of many SEOs, both love and SEO are fair game.

White Hat vs. Black Hat It's easy and fun to describe an SEO approach as "white hat" or "black hat," but it's much harder to tell which is which. Many white hat optimizers are purists who claim in strong, declarative terms that certain technical treatments, content and link manipulation, and other methods are completely off-limits. The black hats see this as a contest that has nothing to do with cheating: how can cheating happen if there is no written rulebook or court? Their approach is more like a game of cat and mouse where the cat holds all the cards and the mouse stands to make a lot of money: risk, win and pay big. But when the search engines catch up to you (almost

game layout


always) be prepared for your site to be blocked or at least stop working when the method is called.

Keyword Spamming Many "cheating" techniques are based on UX principles. An early way to play with this system was keyword stuffing - basically stuffing keyword meta tags with hundreds of apple occurrences when the site's content was all about oranges. Essentially, the meta-keyword approach was created to help categorize the early web. Today, with all the keyword spam, this part of the page has little to no impact on search rankings. Search engines easily detect this technique and are able to bypass it quickly. Next-generation spam is more difficult to crack and is rooted in user experience issues.

Cloning and Door Pages Cloning and Door Pages are methods used to increase the size of a website or differentiate it from search engines. By cloning a page over and over again, webmasters can essentially create precisely targeted content that can quickly capture a specific search phrase. Because of this practice, it is important that your architecture prevents inadvertent cloning, as search engines are sensitive to copying, intentional or not. Door pages are another method of influencing search results that fall into the gray area between white hat and black hat methods. On the one hand, Google's Webmaster Quality Guidelines state that "login pages ... violate Webmaster Guidelines" (www.google.com/support/webmasters/bin/answer.py?answer=66355). The guidelines define doorway pages as low-quality pages optimized specifically for a set of keywords that may be unrelated to the actual site or contain spam. On the other hand, how can you help search engines access content that is stuck in unindexable databases or obscured by techniques that search engines don't like? Positively defined, an entry is high-quality static content that search engines can see and understand, while also providing visitors with a doorway to dynamic content. Today's content management systems are improving on the basics


Chapter 8: User Experience Design and Search Engine Optimization

This approach is no longer needed, but it's still very useful to create additional pages to show search engines a static representation of content they otherwise wouldn't be able to process.

Link spamming Recent approaches to systematic gaming have focused on manipulating link popularity, a concept central to how modern search engines work. As mentioned above, search engines determine the relevance of a particular web service by analyzing the quantity and quality of links pointing to that page from other places. SEOs have manipulated this part of the puzzle through sneaky redirects, overuse of subdomains, setting every page of the site to "/index.html" and various other subtle machinations.

Final Thoughts This is your first time researching SEO and it's questionable. It is now known how much website architecture and related issues can affect search engine performance. The current search experience is a huge leap beyond simple taxonomies or structures. Thoughtful SEO starts with a quality user experience. A website's architecture is a key point in its lifecycle that can prevent a search engine from succeeding or set the stage for imminent failure. Search engine optimization is a never-ending strategy, but quality SEO never really begins without the careful attention of a UX designer. Jonathan Ashton is VP of SEO and web analytics at Agency.com and directs the SEO Center of Excellence. His team provides company-wide SEO services, ensuring that the process of designing and creating rich interactive experiences leads to searchable websites. Industrial Strength SEO's monthly column can be found at http://searchengineland.com/lands/columns/industrial-strength.php.

some final thoughts



Go: From Definition to Design, Visualization, Prioritization and Planning You now have a detailed list of business and user needs. You can get feedback from users to keep discussions focused. Now what? Unless you're working on Shangri-La projects, you'll have a budget (tight), a schedule (tight), or both, which tells you that you need to focus and manage the list somehow. This chapter covers some ways to go from definition to design, including strategies to help your team visualize the solution to be designed, prioritizing features to create a unified set of requirements, and planning subsequent design activities. The next stage of the project. Carolina Chandler



Chapter 4 discusses different project approaches or methodologies and how they affect the way you work with project teams and business stakeholders. It compares the waterfall approach, where the definition and design phases are separated by the approval stage, with the modified waterfall approach, where the phases overlap. This chapter covers activities that may arise when the definition and planning phases overlap.

Set project development

This point in the process is the right time to find and visualize features that did not exist during the stakeholder period

User interviews or research. Doing this with your design team before prioritizing allows you to consider and design innovative features to meet your business and user needs. Prioritize project needs. This includes an extensive list

business needs, user needs and project team thinking and determine their relative importance to the achievement of project objectives. At this point, you will work with the development team to understand the total effort required to meet each requirement. Plan the activities and documents you will use during planning. This

Scheduling determines how you will work with other team members and what types of tools or documentation they will receive from you, such as sitemaps and wireframes (discussed in Chapters 10 and 11). This chapter covers each of these three areas, starting with a method of ideation and visualization that UX designers can easily use in collaboration with project team members.

Transition: from definition to design


Define and approve common script requirements and design the planned functionality of the site. Halfway through the design process, you realize that sharing a particular tool will really help your users. It's an exciting idea, but it doesn't describe the requirements for this new tool, so enabling it now would require changing the priority requirements. You must strongly advocate for changing the requirements list, especially if it means that something else needs to be removed from the list (which will certainly take some time) or may delay the project schedule. There's a chance this idea wasn't included, simply because it came so late in the game. While new ideas can emerge at any point in a project, taking the time to find features after you've finished gathering requirements but before prioritizing can help you generate those ideas earlier and increase your chances of onboarding. It also ensures that you spend some time thinking of innovative features that your business stakeholders or users may not have considered.

Concept and visualization UX designers have a unique skill set that can help bridge the mental gap between words (like requirements) and images (like sitemaps and wireframes). While people can talk about requirements and argue about language, they often don't really agree until they see a concept represented visually. On the other hand, if you jump to specific visual details too quickly, you risk focusing the discussion on smaller details before addressing more serious issues (eg, whether your users fill out that particular form in the first place). There are many conceptual design techniques that can be used throughout the process to help you visualize the context, process and story in an engaging way before detailed design begins. So are these technologies


Chapter 9: Transition: from definition to design

Before prioritizing, develop functional requirements that can be added to the requirements document. One such technique is collaborative storyboarding: visualizing specific user scenarios drawn on paper or a whiteboard during a brainstorming session. UX designers then add details based on these sketches.

Basic Storyboarding Process Prepare for your storyboarding session by creating a list of scenes you want to explore. To create the scenario, consider the following questions and add answers to the discussion: Who are the primary users in this scenario? What role does it play? This is

Your user models or personas will come in handy. If you have them, bring them to the meeting - they will focus the discussion and ensure your design team has a better understanding of how to use user modeling tools in the design phase. Is the selected user the first user of the site? If not, is it sporadic?

user, do you use it often? This will affect the level of functionality you will be talking about. The sheer number of options that users can often appreciate can overwhelm novice users. You can double-click scripts to discover different features that each team might need, such as context-sensitive help for new users or custom features for frequent users. What urgency prompted this user to visit the site? what does she want

why did it happen? You can see this by looking at high-level tasks (such as "finding product recommendations") that are relevant to your company's or user's needs. Maybe 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 brainstorming team for a meeting. The group can be just you and one other person, or it can be a small group of three or four people. (You can do more, but it's hard to get everyone on board and keep them focused on the task at hand.)

Functional conceptualization and visualization


Ideally, at least one person on the team is responsible for representing the user's point of view. The second should represent the business perspective (for example, business actors or business analysts if that role is represented in the project). That doesn't mean perspectives can't change. Discussions can and should take into account user and business needs as much as possible. See "Maintaining Good Volume" for more information on balancing user and business needs. Once the team is assembled, tell them what your goal is: to understand some of the features you might need to meet your business and user needs, and to focus on future design work. Provide answers to the above questions and a list of scenarios to discuss. Then go to the board (or put a pencil to paper) and ask the group questions about the scenario, e.g. how does this user get to the page? Consider online search, banner

Advertising, word of mouth and other media. If an online search comes to mind, accurately reflect the request

What kind of functionality or activity (eg markup is required for SEO) to support this search? What do users see on the site that suits their needs? Which path will the user choose to complete the task? describe it

Advanced details. Has anyone else been involved in this project? If so, how will they participate?

(calls, email, website collaboration features) and how do they affect key user decisions or behaviors? Where might the user need help along the way? How will he get it? What happens when the user completes their task? common design mistake

The plan is when the user's work is done and you're done, but this is a good time to encourage users to explore other areas of your site or consider purchasing related products. Consider an example from a typical business scenario: a new job posting needs to be posted on a company's .com website. In this scenario, let's say you interviewed stakeholders and discovered that the hiring process is primarily run by an HR guy, name Jeff, who works with people to be hired. 148

Chapter 9: Transition: from definition to design

Jeff is very familiar with existing job descriptions. When he needs a new position, he usually finds it when a potential manager for a new position asks him to advertise a position. Here's a collaborative process between Jeff and the manager (let's call her Emily) to write and publish the job description. Figure 9.1 shows what a script for this scene might look like. The diagram shows just some of the storyboards you can create here. You can start the scene early to show the approval process Emily has to go through, or you can continue the storyboard to show the job seeker applying for a job. The important thing to note is that a storyboard like this allows you and your design team to see your workflow as more than just a series of pages. It introduces the human element and context. Without the human element of the personality (Jeff), your team probably wouldn't think to build functionality starting with an existing job description - although we all do this to save time and make sure we're including everything we need.

Figure 9.1 The Storyboard was first created on a whiteboard, then drawn and detailed in Microsoft Visio using a Wacom tablet

Functional conceptualization and visualization


When using storyboards and other types of sketches, such as user flows and concept diagrams, keep in mind that they are primarily intended as brainstorming tools. While some great ideas came out of the exercise, these sketches were not intended to be detailed designs. This fact may be due to their sketch format (as opposed to prototype format), but it is still an important point of communication with business stakeholders, as even observing visual features in a sketch can sometimes lead to expectations. They will be in the final product. Another risk is that participants can derail into a discussion about user interface elements, such as whether something should be on the page or in a popup. It's very easy to get into these detailed discussions because these kinds of problems are often easier (or more familiar) to solve than the larger problems the script is meant to solve. To simplify the task and use time efficiently, ask participants to save these types of discussions until you plan them based on a list of prioritized needs. This brings us to the next step in the process: prioritizing those beautiful requirements you've spent so much time collecting, often graphically and sometimes painfully!

Facilitate the Prioritization Process You already have a set of business requirements that have been populated with functionality based on user needs and your ideas. Now comes one of the hardest parts: getting everything down to a prioritized list of high-value needs. When discussing requirements for prioritization, keep the project goals and user profiles handy to keep the discussion focused on your target audience. In addition to you in your role as a user advocate, the prioritization process should include: People with a business perspective (businesses

promote). A person who represents the views of the development team (

Development Ombudsman).


Chapter 9: Transition: from definition to design

A person who represents the needs of the project (eg

director). This person may not be required to attend the prioritization meeting, but will determine any constraints that affect prioritization (such as deadlines or budgets) and ensure that the final list meets those constraints.

The UX Designer's Role in Prioritization Consideration of prioritization is the joint responsibility of the project sponsor, project manager, and development team leader, not the UX designer's problem. But in reality it is not. Prioritization discussions are where successful solutions are made or broken. It is the job of UX designers to use their skills to navigate these important conversations. If you have already participated in the prioritization process, this section provides instructions on how to do so. If not, do what you can to get involved. This means you need to let the project team know about the skills you have (eg facilitation) and the balanced perspective you can bring. It is important to show that you can understand the perspectives of different team members and work together to achieve a unified understanding. For more information on how to achieve this balance, see Maintaining a Good Sense of Tension.

The prioritization team analyzes each requirement to answer the following questions: What is its level of importance to the company? how important

A requirement to achieve one or more project objectives? How much impact does ignoring this requirement have? How important is it to users? if it meets the requirements

Typical user needs (or high impact needs for priority user groups)? How does this affect the user experience if ignored? Are there other very similar and perhaps competing requirements? For the last question, keep in mind that multiple solutions to the same problem can compete and confuse users (and require more work to maintain). For example, the New York Times may have enough developers to handle all the features it provides

Facilitate the prioritization process


on nytimes.com (marked in blue in Figure 9.2), but some users may not know whether to click Share, Email, or Share to send the article to a friend. If your users may not be familiar with all the sharing options that have exploded in recent years, you should probably start with a smaller feature set. How technically feasible is the development requirement? What

How long will it take to develop? If you are using relatively new technology, the time here is estimated to be longer. How real are the funds for its development? or project

Does the team have the people, skills, and money to develop this feature? (Consider the cost of buying and learning new technology tools.)

Figure 9.2 Screenshot of www.nytimes.com showing the many sharing features offered by the online newspaper


Chapter 9: Transition: from definition to design

Create a worksheet to record your decisions for each need. This can include low, medium or high scores based on the questions above, or you can use a numerical scale to add the numbers and rank them. As you review the list, you may find that you need to combine similar requirements or break down a large requirement into several smaller requirements that represent potentially independent work units. Please note that this system is only intended to help with categorization and prioritization. not based on a scientific feasibility study. However, it is very useful for managing large lists, starting discussions, and determining relative importance. Figure 9.3 shows an example of a prioritization worksheet where each requirement is assigned relative values ​​using high-level importance and feasibility categories (low, medium, and high). priority sheet

To require


commercial importance

user meaning



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









)()%#&!%*& )##')*&(() $!%* #)* /)





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




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

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


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


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

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


+#2##$%* *

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


resource availability
















Figure 9.3 Sample requirements prioritization worksheet

Facilitate the prioritization process


Assigning a value to each category will create a lot of dialogue between priority groups. How can you facilitate discussions and decision-making? The two most important things you can do are understand (and sometimes represent) the different perspectives that are critical to defining a viable solution and help resolve areas of conflict within the project team. First, let's talk about representing the right set of views when prioritizing. This involves creating and maintaining tension between user advocates, business, and development advocates—a tension that is good because it provides a balanced solution that provides a good user experience, satisfies design constraints, and aligns with business goals.

Maintaining Good Tension During requirements gathering and throughout the rest of the project, you'll notice three roles interpenetrating team discussions:





Business Advocate: A team member who represents business needs and requirements and ensures they are captured and met as faithfully as possible. The main tasks of the business consultant are to achieve the strategic goals of the company and the department, to ensure that the business vision is not lost during the project and to focus on the project goals. User Advocate: A member of the team who represents the needs and perspectives of the primary users who will interact with the site. The primary concerns of user advocates include ensuring that the website meets usability expectations, provides a satisfying and engaging experience, and encourages behavior that supports the design goals. Development Master: A team member who represents the needs and constraints of the technical and QA teams. Key considerations include ensuring that the development team is working effectively within scope and that the product they deliver meets the quality standards expected by users and business stakeholders.

Chapter 9: Transition: from definition to design

Think of it as a three-way tug-of-war between lawyers. If the tension between these three parties is properly maintained (meaning no one champion dominates), the three parties can work to find a balanced solution that meets the project's goals. Each team member must be aware of their interest in maintaining balance throughout the project. If one party dominates, other roles become irrelevant and the project risks missing its goals - or achieving them at a much higher cost than expected. See Figure 9.4 for an example of what can happen when the voltage is unbalanced.

Figure 9.4 Consequences of not maintaining good voltage

keep good tension


Can multiple roles be played in a project? Absolutely! Ideally, different team members have primary responsibility for each role, but that doesn't mean you can't switch positions from time to time. In fact, you can switch roles from one conversation to another — even from one topic to another. As a UX designer, you are most often in an advocate role for users, but you need to understand the perspectives of all three roles and ensure they are consistently represented to create successful designs. While it's beneficial to switch roles from time to time, be careful not to designate yourself as the primary person responsible for multiple roles. As the project progresses, you can begin to make uncontested compromises, because you won't always have a "devil's advocate" asking uncomfortable but important questions. If you have to fill more than one role, try to find part-time workers who can fill other roles for you from time to time to ensure you maintain a good tension. So far, we have focused mainly on the roles 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 key player in our hierarchy discussion: the growth broker.

Developer If you're a UX designer at heart, you'll succeed when you put yourself in other people's shoes to understand their needs and goals. This skill is invaluable both in your role as a user advocate and in ensuring you communicate and collaborate effectively with those in your organization. Let's take a moment to use this skill to describe the goals of the development advocate. The main design debate concerns the extent to which the development agent should participate in and influence the requirements gathering process and his/her role in that process. If development proponents raise technical capabilities and constraints prematurely, it can limit some of the brainstorming that could lead to highly innovative solutions. After all, today's blue-sky ideas are possible with a little extra technological exploration. Even if the idea isn't feasible, discussing it can spark a basic need that you can fill. (Mapping feature requests to requirements is discussed later in this chapter.)


Chapter 9: Transition: from definition to design

These are the goals and related responsibilities of the Development Master: Fulfilling requirements on time and within budget Ensuring team effectiveness (avoiding duplication of effort, ensuring good

leverage available tools and platforms Select cost-effective additional tools Ensure future changes do not require significant additional effort. Standardizable: Fewer modifications

Build the purchased system, so less work needs to be rebuilt later Make sure the development team is working well Reduce turnover, ensuring relatively interesting and rewarding work


Use legacy claims Step 4

step 1

Review requirements and labeling requirements that are unclear or of questionable value to the user.

Inherit some requirements and do an initial review.


Step 2 collects information that provides context for potential users.

"The user is..."

Step 5 Review the highlighted requirements with your team to investigate requirements and conflicts. "Which is why."




Step 3 Create a temporary user model.

Step 6 Prioritize any changes you think need to be made. Present your arguments to them and present them to the design team. Simple and realistic.




"good idea!"





keep good tension


However, if the Development Facilitator is not involved early, the team may be so far along in pursuing an option that it becomes too costly to include it - or the Development Facilitator may lose one or more of its purposes. Finally, Dev Advocate is a great resource for showcasing some of the technology capabilities that can really make your solution shine, such as new technologies or underutilized features. An effective approach is to schedule critical reviews with the development leader after brainstorming, identifying high-level requirements, and beginning the prioritization process. This allows the Development Officer to explore the chosen tool early in the process to get more details on what might or might not be possible, and then get more involved with the requirements as certain topics and ideas become more relevant in the process. If you believe that specific requirements gathering meetings are important for the development advocate, make sure you agree in advance on their role in the meeting and how you will capture any potential concerns the advocate may have after the hearing. You can also record these types of meetings to review later with your development consultant. When you're busy designing, you might need them yourself! This clear communication and follow-through when gathering information is critical to building strong relationships among team members, which can make a big difference in how well the next steps of the prioritization process go. But sometimes, despite your best efforts, conflicts arise when you try to prioritize requirements. Let's talk about how you can help project teams manage this conflict.

Managing conflicts when prioritizing Prioritization can be a time-consuming process if there are significant conflicts. If these misunderstandings are not resolved, they will continue to arise during the design and development process. These conflicts can have many different root causes. here are some of the most common:


Chapter 9: Transition: from definition to design

The team is not aligned with the goals or understanding of the project

Deceptive business practices (misunderstanding, forgetting or disagreeing with them). Members of the opposition are closely associated with a particular set of characteristics.

(Perhaps these features excite them, or they've already promised them to an influential group of customers or stakeholders.) There's a conflict between the needs of the business and the needs of the users

Easy fix. The technology used is relatively new to the development team,

Therefore, they are reluctant to give estimates. Let's take some of the above situations as examples and discuss how as a UX designer you can get involved in solving them.

Pick your battles Some of your favorite features may get sidelined during the prioritization process. It's easy to start feeling bad about this, especially when user requirements seem to be the ones that cross the list the most. If you passionately defend each claim equally, you have the opportunity to make priority decisions on your behalf. When deciding when to push for a particular requirement and when to compromise, ask a few questions: How does the requirement support the project's goals? Does it significantly reduce a particular risk? For example, does it reduce the risk of exposing users to spam and negative website reviews? Are the other proposed site requirements dependent on its proper operation? What is the impact of not including this feature? Is the value of the feature worth the effort required to develop it (even at the expense of other features you consider valuable)? If you have a strong answer to all of these questions, put them on your priority list to make your case. If not, consider giving up, but be sure to share your reasons so others know you're compromising for the greater good of the project. This will demonstrate your ability to consider the wider business context and enhance your involvement in future discussions of priorities and requests for change.

keep good tension


Project Disagreement Teams do not agree on project goals or core business strategy. Let's divide this source of conflict into two areas: communication and consensus. If you're having trouble communicating your project goals or business strategy, ask yourself how you can improve communication yourself. Are goals or strategies posted in a place visible to all team members (for example, in the meeting room or online collaboration area, or at the beginning of each meeting's agenda)? Or maybe you need a visual representation of your goals or strategy to help your team stay focused and excited about the vision they're trying to achieve. Remember the visualization technique discussed at the beginning of this chapter? Use them to create images that are easy to print and post, or make quick sketches on the board to keep conversations focused. If achieving consensus is a problem, ask yourself how you can help bring everyone together. Is the conflict caused by concerns about the risks of giving users a completely different set of capabilities? You may be able to do research to help clear up some misconceptions, such as surveys, interviews or background checks (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 of Favorite Traits Members of the opposing team are associated with their own set of traits. Let's say the head of training wants comprehensive, up-to-date courses and the head of sales wants to send an exciting demo to generate interest. At the same time, you have 10 other business stakeholders in different roles - all with pressing needs. How do you help build consensus? One way is to use a variation of the method you read about in Chapter 6: Affinity Charts. In this approach, you can start with an existing set of requirements or ask stakeholders to brainstorm their own requirements (especially useful if the requirements gathering process is still in its early stages). If you are working on existing requirements, you can print them


Chapter 9: Transition: from definition to design

Separate the pages and stick them all to the wall. Otherwise, ask stakeholders to write their most important requirements on a set of sticky notes. What you need: A room large enough to move a group of interested parties

Have one or more large blank walls to stick sticky notes on a large stack of sticky notes, at least one sticky spot per stakeholder (found in office supply stores, come in many formats)

multiple colors), a set of ten points for each stakeholder Gather your key stakeholders in a room and ask everyone to take a moment to list their key needs one by one. Give them 15 to 20 minutes to do this. (Don't peek!) Have everyone hang their request on the wall. Then ask everyone to come up and describe what they posted. As you move around the room, start grouping similar requirements (if stakeholders agree they are similar). After the requirements are clarified and grouped, distribute the sticker points. Let stakeholders know they can indicate which needs are of highest priority to them by matching dots on sticky notes. They can choose to put all ten points on one requirement, for example, if they consider it important, or they can choose to put one point on ten different requirements. As people give points, you will start to see distinct forms of favorites. When they have finished placing points, review the results together. When forced to choose this path, stakeholders state their own internal priorities and the discussion can become much easier.

Browse For more information on variations of this prioritization technique, see "The KJ-Technique: A Group Process for Establishing Priorities" by Jared M. Spool: www.uie.com/articles/kj_technique.

keep good tension


This technique can help you jump-start the prioritization process or restart a process that has stalled due to poor communication. Once you have momentum and consensus, it will be much easier to complete the prioritization document (shown in Figure 9-3). Alongside the prioritization activities, preparations should be made for the upcoming full-scale project. Developing a work plan will help you estimate the effort required to create a detailed project, link your work to that of other project team members, and coordinate your work to align with project milestones. The next section describes some things that can help you plan.

Plan your activities and your documentation Once you have a prioritized list of requirements and ideals, if you've made some initial ideas (such as the scenarios explained earlier in this chapter), the project manager can start asking you for details about the your project. There are many types of design activities, each of which will have a different impact on how you design, how long, and what kind of final document you have. Is it a "document" in the general sense; it can go from a board sketch to a wireframe to a prototype. In the next three chapters, we will cover some interaction design activities. When planning which actions to use, keep the following questions in mind: How iterative is the entire process? Ideally you can start with

Familiarize yourself with several different concepts quickly (eg with sketches) and then agree on one to develop in more detail. This approach may also involve presenting one or more design concepts to the user (see Chapter 13 for more information on design testing). How will you collaborate during the design process? If you work closely

If your team is in the same location, you can join more collaborative sessions on the whiteboard. If your team is dispersed, consider online conferencing with tools that allow for a high degree of collaboration, despite the distance.


Chapter 9: Transition: from definition to design

How will design documents be shared with the larger team? Yes

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 should the backlog project include?

edit, process; If your documentation is part of a formal quality assurance (QA) process, you should involve someone from the QA team early on so they understand what details they will be getting from you. How long should a document "live"? For complex projects

When you stop updating a document, such as a set of mockups, it begins to "die" - the details become less and less accurate over time. (This isn't always a bad thing, as long as you participate in discussions about those changes.) Documents that focus on providing general guidance, such as branding guidelines or a library of interaction design patterns, tend to live longer. Who are the primary users of each type of document? this answer

It may differ in different parts of the project. The primary users of conceptual design documents are usually the business stakeholders and the project team, who use them to communicate and share ideas. Detailed design documents are primarily intended for developers who need to implement a project. These documents provide detailed guidance. What other types of documents do you need to be consistent with? You can

You must provide some connection between the prioritized feature list you created above and the project you created. You can also keep an eye on a few other documents to make sure they're all on the same page. These documents may include branding guidelines, content development plans, functional specifications, or use cases (see Chapter 2 for the different roles and types of documentation they can create). How would you estimate the amount of work required for each type of document? This

One is difficult because there are many variables in the design that affect the schedule. However, setting a baseline for rough estimates will give you a starting point and allow you to verify the numbers as more information becomes available. For example, you can set a base estimate that it will take about 6 hours to create each detailed wireframe. If you are calculating a specific function

Plan your events and documents


This will take about 5 pages (for example, based on the results of the storyboard session described earlier in this chapter) and you will have an initial estimate of 30 hours for this function. If you need eight pages per wireframe, try to understand why. If you think this is here to stay, you should revise your estimates and possibly change your priorities. What other factors might affect the timeliness of documentation? All

The time includes review time with the team and stakeholders, as well as the number of revisions you think should be done. For detailed sites, this may also include the time required to coordinate design documents with other documents such as detailed functional requirements (such as use cases). Record these assumptions to check them later. Will you be working with multiple designers? If so, what about you?

Do you want a division of labor? If you work in parallel but separate areas of the site, you can work on the documents you create completely independently. If you divide your work in a highly interdependent way, you'll need to allocate time to coordinate projects, and you'll also likely need a way to track and merge different versions of your documents. Setting up the process early and setting some design guidelines early on to keep things consistent on basics like navigation so you don't have a headache later. Now that we've covered some of the things to consider when choosing a design activity, let's take a look at these activities. In the next three chapters, we'll cover a variety of documents, including sitemaps, workflows, sketches, wireframes, and prototypes.


Chapter 9: Transition: from definition to design


Sitemaps and Workflow Build projects from start to finish Sitemaps help you define the structure of websites and applications. They can show hierarchy and connections, giving your audience an idea of ​​where users can find your content. Workflows take sitemaps a step further by identifying different courses of action a user can take on a site section. The workflow also creates links to 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 picture of how your content is structured and how users navigate it. Lars Unger


What is a sitemap? 1.0

1.0.1 Regulations


2,0 – 2, x








Figure 10.1 Sitemap for a basic blogging site

Starting with the most basic definition, a sitemap is simply a visual way of displaying representative pages of a website (Figure 10-1). A simple site map usually fits on a piece of paper, like an employer organization chart. But sitemaps aren't just for websites, they're for websites. You can use them for any type of application that would benefit from recognizing page instances, views, states, and whatever else is displayed. In most cases, you'll use a sitemap to show team members and clients how to organize your site's content. It will give you an overview of your site navigation and in some cases show you all the links that each page can have.

What is workflow? Figure 10.2 Basic workflow showing user path according to login status


Is the user logged in? The page is not connected



login page

A workflow specifies the path or flow that a user (and sometimes the system) will follow as they navigate a website or application (Figure 10-2). While a sitemap and workflow may look similar at first glance, the two types of diagrams serve different purposes: a sitemap shows a visual hierarchy of the site or application layout, while a workflow shows the options that will be available does the user and the details of the paths they will be able to accept. 166

Chapter 10: Sitemaps and Workflow

Practical tools If you are new to UX design and need a tool to create products that work, 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 to choose? You can ask other designers. everyone has a favorite and they're usually happy to name it. Don't be surprised if they answer "good pen and paper" like your writer did. You can also try the free trial online or choose a free solution like OpenOffice Draw, which is part of the OpenOffice.org suite of tools and results in the same formats as popular office suites. What else do we use besides pencil and paper? Many of the examples in this book were created using Microsoft Visio 2003 using templates created by Nick Finck, Director of User Experience at Blue Flavor (www.blueflavor.com) and publisher of Digital Web Magazine (www.digital-web. com ). You can download Nick's wonderful stencils from www.nickfinck.com/stencils.html. These ready-made templates, shapes and samples are invaluable for beginners and experienced professionals alike. In addition to Nick, check out the Information Architecture Institute, who have many of these tools on their Learning IA site: http://iainstitute.org/en/learn/tools.php. Note Microsoft currently offers Visio 2007. However, many companies have not yet upgraded to this product, and to avoid version differences, we currently recommend Microsoft Visio 2003.

trading tool


No matter which tool you decide to use, there are countless examples of other professionals online who are willing to share those tools and help you in your career. They are largely free and can provide the framework you need to create (at least) very professional-looking documents. Unfortunately, many people do not use these resources. Don't be like these people!

The Basics of Sitemaps and Workflows The most basic elements of the design program are enough to get you started creating sitemaps and workflows. However, to make your creations more understandable to a wide audience, it is best to use a standard set of shapes. The visual vocabulary of 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 a number of elements to help you articulate your sitemap and workflow, all with detailed descriptions and as downloadable templates for many popular design and sketching programs (more on that later). To get you started and familiar with the basics, the following sections introduce a basic set of visual vocabulary elements and what they represent. Figure 10.3 Page elements from Jesse James Garrett's visual dictionary

Figure 10.4 Page stack elements from Jesse James Garrett's Visual Dictionary

Pages According to Jesse James Garrett, a page is "the basic unit of user experience on the Web." Content "occurrences" or "views" may be more realistic today, but the page still makes sense. There are several ways to design these pages, but the simplest and most commonly used format is the regular format


Chapter 10: Sitemaps and Workflow

Rectangle (Figure 10.3). As you create your sitemap and workflow, you'll want to find a style of labeling and page numbering that works best for you.

Page Stack A page stack represents multiple pages of similar content (Figure 10.4). An easy way to understand page stacks is to look at dynamic content, such as a public blog page created using the publishing system. These pages are designed once and run on a design template, but you can navigate to many different content pages without leaving the original template design.

Decision Points Figure 10.5 Decision Points Elements in Jesse James Garrett's Visual Vocabulary


(10 a)


User home page

Decision points are used to show the paths a user can take based on the answer to a question (Figure 10-5). Point 10a of the decision may read: "Are the user's login details correct?" The answer to this question will determine which page (or content view) will be displayed. A failed connection leads to an error message, while a successful connection takes the user to the site's member home page. Take the time to get the decision points right. you'll be glad you did, especially when you share the results of your work with your teammates or clients.

Basic elements of sitemaps and workflows


Links and arrows Figure 10.6 Links and arrows from Jesse James Garrett's Visual Dictionary

Links and arrows are used to show movement or progress between pages, stacks of pages, decision points, etc. Links usually appear instead of CTAs from one page to another. For example, a link from your home page to an "About Us" page can be a link between the two pages. The arrows (at the top of Figure 10.6) indicate the "down" movement toward task completion. The bar link (bottom of Figure 10.6) can be used to determine when it is not possible to return to the home page (scroll up). For example, when a user logs in to a website, the home page content can now be personalized for the user, and generic pages or login pages will no longer be available for the user to follow from the path they just chose.

condition one


Figure 10.7 Terms in Jesse James Garrett's Visual Vocabulary

Dotted lines are a fairly common way of representing conditions. It can appear in sitemaps, workflows, and other work products you may create or devise. You can use dotted lines as links (as shown in Figure 10-7) or boxes around areas to emphasize that a page (or an entire page section) is linked to another action or event.


Chapter 10: Sitemaps and Workflow

Common Mistakes You don't go to a presentation with some peanut butter on your chin or a coffee stain on your shirt. Mistakes like this can not only undo all your hard work, but also prevent you from coming up with a good design. A messy sitemap or unprofessional workflow can do just as much damage. To help you spot small mistakes that can have major consequences, in the next section we'll take a closer look at some bad designs. Learn to spot these common mistakes—and then avoid them.

Inappropriate Connections Figure 10.8 The connection between two parties is lost

Messy connections are just that: messy. They don't draw well. They look very amateurish to say the least and give the writer the impression that they don't pay much attention to detail in their work. Most tools have some way to help you connect the wires to the box. Please make the most of it. Don't be lazy, regardless of the time constraints and pressures you may face. In most applications, using the Shift key in combination with other keys allows you to drag elements at a 45-degree angle from the starting point. Use this built-in feature and make sure the connection is well connected. If you're showing a pencil sketch, you should have an eraser handy just in case. Make a rule of thumb: always make sure all lines that touch anything else are exactly connected.

standard errors


Misplaced and unevenly placed items

Figure 10.9 Misaligned and misaligned pages

Depending on the tools you use, it can be difficult to ensure that objects are accurately aligned or evenly spaced in a sitemap or workflow. There are some fairly simple ways to make sure you follow this basic rule. First, open the grid in whatever app you're using. This way, you can always calculate the mesh size between objects, regardless of whether or not the tool provides an option to ensure evenly spaced, properly aligned objects. Fortunately, you can use graph paper and apply the same basic principles when using pencil and paper. It's so easy to make your documents look professional. Unfortunately, it's also very easy to make your documentation look like you don't really care about the quality of your work.

Misplaced text Figure 10.10 Inconsistency text

Step 1 Step 2

Careless text placement (shown in Figure 10-10) may seem easy to avoid, but it's another common mistake. Find a way to make the text fit well into the shape you created, and make sure any labels placed outside its elements have proper connections (Figure 10-11). 1.0 Home


1.0.1 Regulations

Chapter 10: Sitemaps and Workflow

Figure 10.11 Correctly positioned text

It may seem simple, but proper text placement and correct font size and usage will make your document easier to read and use.

Missing page numbers It's time to make another rule: number every page of every sitemap you create. Do not create a fuzzy map without numbers, as in Figure 10-12. Terms & Conditions







Figure 10.12 Site map without numbering structure

Each page identified in the sitemap should be assigned a number, and the numbering system should allow for further changes as new iterations and revisions are made to the design. You can number your pages in many ways, the most common being to identify the home page as 1.0 or (Figure 10.13). Over time, you'll be able to decide which one is best for you, but until you're familiar with and understand the pros and cons of both approaches, choose Home 1.0. This method allows you to count as 0.X any decisions and pages that may occur before the home page (such as flash preload, login or registration screens, or many other types of pages). The numbering system in the sitemap allows you to synchronize other documents with it. The numbering system can be extended to other documents, such as tables of contents. Content creators can map their copy and other content

Specific pages (and specific elements in mockups, more on that later). workflow. Workflows can use the same numbering system to show how

The user will continue to browse the page for the specified task. Wireframe models (see Chapter 11). Your site wireframe should be shared

Same numbering system as the pages in the sitemap to ensure a clear connection between the two documents.

standard errors


visual design. Visual designers can synchronize pages and design elements

A specific page in the sitemap. This allows them to share inventory when they need to deliver projects to developers. Quality Assurance Documentation. QA team can write tests -

Script for one or more specific pages in the sitemap. Your attention to detail and structure at this point helps others approach the project on the right track and provides structure to their tasks. 1.0

1.0.1 Regulations


Blog 2.0 – 2.x

3.0 O

4.0 work

contact 5.0

Figure 10.13 Sitemap with correctly linked pages, aligned, evenly spaced, and correctly numbered elements

In short, numbering the pages in your sitemap will make other people's lives easier - which means yours will be easier too.

A Simple Sitemap In addition to including page numbers, Figure 10-13 is a good model for creating a basic sitemap with limited dynamic functionality and mostly static features. The pages identified for this site are Home Blog About Us Work Samples Contact Us

As you can see, this simple sitemap contains the basics of the visual vocabulary while maintaining a professional style and look. Most importantly, it provides website users with a very clear view of the navigation, pages and terms of use.


Chapter 10: Sitemaps and Workflow

Advanced Sitemap A simple sitemap usually fits on a piece of paper and is likely to look like an employer's organizational chart. However, more advanced sitemaps can span multiple pages. 1.0 Lorem Ipsum Dolor Home

it makes pain good

February 9, 2008

page 3/9

Figure 10.14 Advanced main sitemap view

When creating more advanced sitemaps or sitemaps for larger sites and apps, one way is to use the home page to identify the steps needed to get to your site's home page. (Yes, we recommend using a workflow as part of an advanced sitemap.) You must also identify all top-level pages, global navigation elements, and footer elements. This allows you to initially display an overview of your site and give your team and clients a clear view of the project. The first page is also a good place to put a legend or keywords to help you read the sitemap (see Figure 10-14). Both your team and your customers need it. Don't skip this step!

Advanced Sitemap


it makes pain good

February 19, 2008

page 4/9

Figure 10.15 Advanced partial sitemap view

The pages you create after the first should basically map to it. For each top-level page, you should have at least one page that identifies all the pages, page stacks, and external content required by your website or application (Figure 10-15). Don't be afraid to link subpages together if necessary. Sitemaps can be much wider than a standard size sheet of paper allows. There is nothing to worry about as long as your sitemap is well organized and the links are clearly documented for your audience. These examples are enough to get you started in the world of sitemaps. As you start working on different projects and notice that your skills (and often the needs of your team or client) grow, you'll find that you can take a completely different approach to delivering your sitemap.


Chapter 10: Sitemaps and Workflow

Breaking the Sitemap Pattern Now that you know some solid sitemap examples, they should do most of the functionality you need to get the main job done. Don't let these models stop you from discovering what works best for you - share with us! Different approaches can highlight information beyond the basic site architecture. For example, consider the site map in Figure 10.16, courtesy of Andrew Hinton, senior information architect at Vanguard. Follow up on new research


Support bc.org



find similar people

"Academic" interests (medical, student, general)

I take part in something

Interactive access to printed material

Learn more about bc.org

new note

Manage the risk

they worry about their loved ones

social contact

Participation in a meeting of experts in science

New diagnosis, new tent/seat.

Figure 10.16 Advanced site map. Contributed by Andrew Hinton.

This sitemap not only shows the individual pages of your website, but also provides information about the paths and priorities of your visitors. Andrew (www.inkblurt.com) says he created the sitemap after seeing an example by Wolf Noeding that sparked his creativity. Andrew uses this sitemap to show different user scenarios and mental models related to the site. The larger circles on the map have an additional function: they mark the top areas of the site that generate the most traffic. Like all good UX professionals, Andrew borrowed - and also gave credit. Once you start using these tools more and identifying your work products and your clients' needs, there are countless ways to expand your sitemap. Let inspiration strike you wherever you find it! Don't be afraid to try new things, but take the time to make sure the time you spend is useful and valuable.

Break the sitemap pattern


Using many of the same basic elements as a sitemap, a workflow is a diagram that identifies the path or process that a user (and sometimes the system) will follow as they navigate a website or application. You can use workflows in many different ways. Combined with a sitemap, they can show how users arrived at pages containing a specific set of information. They are sometimes used to show how a certain type of user (person) is expected to navigate a website and what that person expects to see based on their personal mental model. Workflows can also be used to identify complex processes that must be fully understood before the project is sent to the development team. You probably won't use workflows on every project you work on, and they may not always end up as the work product you present to the client, but it's always a good idea to use them - even just with a pencil and - for a paper format designed for your own benefits. A little clarity can go a long way. To create a workflow, you need to understand the goals of your users. In some cases, you will receive a requirements document, while in others, you may receive (or be the author of) a use case. Although the use case consists of only a few sentences summarizing tasks and goals, it allows you to synthesize the user's perspective on the experience. A use case for the script in Figure 10.17 might look like this: The system displays a list of items. The user selects an item. The system displays basic information about the project, save mode. The user changes the status of the item to closed. The system checks pending tasks. If there are pending jobs, an error notification will appear. If there are no pending jobs...


Chapter 10: Sitemaps and Workflow

The system checks the pending payments. If the payment is pending, an error notification will appear. If no payment is pending... the system displays a summary page.

Home [My Claims List] Select a claim

info [record mode]

Claim status changed to closed

Pending tasks?


error notification


[Show pending tasks and requests] Yes

Pending payment request?


info [read-only mode]

Figure 10.17 This workflow defines how the system displays information to the user based on the response to various conditions.

The workflow in the diagram describes the sequence of information displayed to the user depending on the fulfillment of various conditions in the use case. If the answer to any of the distributor's questions ("Pending Jobs?" or "Pending Payment Requests?") is "Yes", an error message will appear, possibly containing additional information to help the user before proceeding. . task requested If the answer to both conditions is No, the system presents the user with a success screen. The workflow in Figure 10-18 shows the user's path from the calendar application to the travel shopping website. The workflow is very advanced because it identifies three very different paths that require user testing to ensure that the detailed flow of each path meets the user's needs.



Calendar S100 Calendar Finder of invoices for purchases

S10 Detailed Fare Finder


Search by price (show pricing table)

search by schedule

relaxed dates

Select R20 Price Search Results - Show Tours - Edit Search

P30 seat selector


R60 Flexible date Search results by price

R10 search results (programmed) display section - search processing

P10 View schedules/passenger information - select seats

To buy

P20 Payment and billing information



Many pages


Confirmation P50

Decision point link

conditional link

Figure 10.18 Workflow showing the user's journey through the stages of the purchase process

App users can enter a set of travel dates and shop based on their priorities. Once users set travel search dates, they can prioritize results based on the factors most important to them: price, travel date flexibility, or travel time (schedule). Workflows identify high-level paths that users can take to guide test facilitators. For each piece in the team, you can create a detailed workflow and then share it with the development team to build the pages needed for testing.


Chapter 10: Sitemaps and Workflow

Taking Workflow to the Next Level For all the topics in this book, it doesn't look like what you're seeing is the beginning and end of the world of workflow. Explore new apps and extend the use of the basics presented here as much as possible, as long as there are good apps. As you increase your workflow skills, you may find yourself creating richer work products with more options, including modified or improved language rules, etc.

Process Figure 10.19 shows the workflow that Will Evans (www.semanticfoundry.com) took to the next level and turned into a process flow diagram. The process flow is very advanced and flexible and is used here to demonstrate that among the many steps in the design process, the first design phase may seem like a single step, however in this particular case it is important to understand that this phase is not does not contain a single event. Instead, in this case, the first phase of the project actually consists of many different activities: user research, market research, ethnography and background research, usability testing, competitor analysis, market analysis, cultural analysis, log analysis

Take your workflow to the next level


Figure 10.19 This process flow diagram takes workflow to a new level to illustrate complex scenarios. Courtesy of Will Evans.

For each of these activities, reports are created that are included in various other documents before the project begins, and stakeholders are brought together to determine scope, priorities, and deadlines. All this is shown in the process flow chart. As you can see from this example, there are no limits to creating workflows. Take a look at the examples above and think about how to take your results to the next level. It may take some practice, but with a little skill, you can create workflows that will delight your customers!

Lane James Melzer (www.jamesmelzer.com) is the Chief Information Architect at SRA International Inc. (www.sra.com), where it creates diagrams that go far beyond basic workflows. The diagram in Figure 10-20 shows the workflow expanded to show the "paths" of activities, notifications, etc. in a multi-event process - a traditional workflow approach could be a nightmare for this project!


Chapter 10: Sitemaps and Workflow

Instead, James explores expanding the basic workflow to include all the different steps and activities that come in a more understandable form.

Figure 10.20 This bar chart is an example of an extended workflow that illustrates a complex scenario with multiple operations at multiple locations. Courtesy of James Meltzer.

James describes planning and swimming lanes as follows: The system allows people to manage information about the buildings they own. This extension will allow building service partners to provide system data on behalf of their customers, reducing the data entry required by owners. The project is divided into three parts: partners configure the presentation and operation of their data services, customer registration and use of partner data services, and ongoing partner data management and support troubleshooting. We are planning a major expansion of the existing system. We have long known that almost all business scenarios involve multiple users and multiple systems. There are many notifications and many processes are asynchronous. This diagram helps us to identify, plan and explain the service scenarios required in the project. In the full version of this work product, we have included detailed wires below the flow in this diagram. The whole thing covers the wall. Once we are confident enough about the design concept, we break it down into a more traditional multi-page specification.

Take your workflow to the next level


The important thing to remember is not to limit yourself to workflows or sitemaps. Go beyond the basics shown in this chapter. If you really need something to test your skills, take the time to create a shoe tying workflow. Good luck!


Chapter 10: Sitemaps and Workflow


Wireframes and Annotations Design and guidance before visual design Wireframes and annotations are methods of identifying the proposed content, structure, and functional behavior of a web page or application view. Combined with sitemaps and workflows, these documents are also very useful for prototyping and proof of concept scenarios. Wireframes are often rendered in grayscale, with no artwork or final content. Instead, they use placeholder content to highlight representative locations that can be used as visual design guidelines. Lars Unger

What is a skeleton? Essentially a prototype of a low-fidelity website or app screen, mockups are used to identify elements that will appear on the page or screen, such as navigation elements, image parts and/or multimedia needs, call-to-action (CTA) elements.

Wireframes are usually created in black and white or grayscale, use image placeholders, and do not include type details (although many use font size to distinguish type of copy). They come in all shapes and sizes, from the most basic to advanced, to near-mimicking full-screen designs. Cables are evolving. They are no longer just given to designers and developers as a to-do list. Wireframes are now used to represent a website or app to clients, designers, developers, and anyone else on the team who is interested at a basic level. They are often presented to clients to validate their "design thinking" before starting the visual design and development phase. Often, the person creating the cables works hand-in-hand with the person creating the business requirements (in some cases it's the same person). It should also be noted that some of the best mockups and annotations are the result of direct interaction and collaboration between various collaborators, from business analysts to developers and other designers. Some companies are turning to cables and annotations instead of Business Requirements Documents (BRDs). While the world is far from saying that BRD is gone, the beginning of this change is enough to show how important it is to be very careful and thoughtful when creating mockups and annotations. In many cases, the wireframe will be displayed to the user for feedback, who can verify page elements or request corrections. skeletons


Chapter 11: Wireframes and Annotations

What is presented to the user usually has another name: prototype. (For more on prototyping, see Chapter 12.) To help you decide which method is best for you, this chapter covers the basics of wireframing and provides examples of designers working in the field. As with the rest of the 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 elements or interactions in the wireframe. They typically contain information such as content ID or tags, content source, display rules, interaction rules, interaction targets, processing rules, content/error messages

Notes are best written in a very direct (if not concise) tone with clear explanations. Leave nothing to chance in the comments. there is a big difference between "must" and "must". Bad: "Executing this call to action (CTA) should take you to your home page." Good: "Activating this call to action (CTA) should bring you to your home page." honestly, the first example isn't terrible, but the word "must" can leave room for confusion among developers further down the line, who may not have the luxury of their favorite UX designer ready to answer questions. Make sure your annotation style is concise and leaves no ambiguity to anyone who might need to read and rely on your instructions.

What are annotations?


Who uses wireframes? With clear, concise annotations, mockups are beautiful, but who is the actual recipient of this output? Unfortunately, there are no easy answers. From project to project, your audience can vary from one person to any combination of multiple groups. Table 11.1 shows the possible audience for your backbone. Table 11.1


common skeleton



project management

Project managers can use mockups as a discussion point within the team to highlight strategy, technical requirements, and a very high level of user experience.

Business Analyst

Business analysts can use mockups to ensure their requirements are met and see if there are any missing requirements that should be included.

visual designer

Visual designers can use wires as a blueprint for their effects. The wireframe describes the page elements and behaviors that should be included.

Content creator

Copywriters, content strategists, editors, and other copywriters can use mockups to map to the content matrix and determine content needs throughout the project.

Search Engine Optimization (SEO) Specialist.

SEO experts can use mockups to determine appropriate naming schemes, copy needs, and improve your overall SEO strategy. (See Chapter 8 for more on SEO.)


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

Quality assurance

QA teams can use mockups as a basis for writing their test scripts. Once the wireframe is approved by the client, changes should be minimal, allowing the QA team to get things started early.


Users can see mock-ups at a very early stage, sometimes in the form of "paper prototypes" as a mechanism to test the design direction. (See Chapter 12.)


Clients are increasingly involved in mockup review to verify that business needs, goals and objectives are met and to gain approval to move into the visual design phase.

Chapter 11: Wireframes and Annotations

Scaffolding To build a scaffold, you usually need a set of requirements. These can take the form of a formal business requirements document from a client, a pitch or project plan, meeting notes, a clear site map or workflow, or even napkin notes with instructions. In any case, you need to understand what you're trying to create for the user, what the connection is, and a general understanding of the technical limitations and expectations. Note For more information on defining business requirements, see Chapters 4 and 5. For tips on effective meeting protocols, see the Online Rewards "Quick Guide to Meetings" chapter at www.projectuxd.com.

Once you've gathered the necessary information, taken the time to review all the requirements, ask questions, and think through the answers for clarity, you're ready to start mocking!

Tools The "Tools" section in Chapter 10 contains a list of design tools you can use to create sitemaps and workflows. The good news is that you can basically use the same app for cables and annotations. The bad news is that if you're making cables for the first time, you might feel a little overwhelmed. But wait - there's more good news. Almost every seasoned UX professional starts with a pencil and paper, so you shouldn't want to choose a technical solution right away (although it's very likely that you'll need to go from sketch to something digital fairly quickly). Adaptive Path Experience Designer Leah Buley emphasized the importance of using pencil and paper (as did the author) in her talk on "How to be a UX Team." When you first start designing wire ideas, it's not uncommon to have one or two good ideas and then hit a wall. These ideas can come from things you've seen and like, or things you've drawn in the past. It's not the end. is a great place to start.

Who uses wireframes?


The mind tends to run to the familiar, but the familiar is not always the best solution to a problem. When you push yourself to look for more different ideas, usually through idea 4 or 5, you end up with something new and interesting. I don't know why it has to be that way. This is. There are templates available to guide you through the process. In Adaptive Path, we use hexagram templates that simply provide space to draw six small thumbnail sketches. The number of sketches is not really important. It is important to move beyond the first obvious thoughts. Six (for me) is the magic number because the standard hexagram with six little boxes encourages me to keep going until all the little thumbnails are filled.

Figure 11.1 Hexagram template for adaptive path

These are great words to live by – especially when you just know what you're doing in the field of UX design. Over time, you'll begin to determine what's best for you, but nothing beats Lia's advice. To learn more about her approach, visit www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one for a full online demo of How to Be a UX-team- of-them. Don't be afraid to start with pencil and paper - remember to bring plenty of erasers. Mistakes are part of the process, and even after committing to a pencil sketch, expect to make corrections as you vote.


Chapter 11: Wireframes and Annotations

Few professions revolve around iteration as often and consistently as the UX Designer. Few (if any) design jobs are accepted on the first try, and sometimes you can only hope that you're "wrong in the right direction". So start small: take a page or a small section of your project and go over it first with your internal team and then with your account team to make sure you're getting it right. Tailoring designs to your clients' business goals in advance can save you a lot of rework. The same approach can be applied to user testing projects - get validated early!

Start simple: design a basic wireframe In this section, you'll learn how to create a wireframe at a very basic level. You can often just start with a simple sitemap and a few extra requirements, but with these you can create the backbone of your website's homepage. Remember the basic sitemap in Chapter 10, which showed you how to build a very simple website? Figure 11.2 shows the update, as you can see, showing some level of the navigation hierarchy. Any X.0 page specified is likely to be a top-level or home page. You can use this as a starting point to define some of your business requirements and frameworks. 1.0

1.0.1 Regulations


Blog 2.0 – 2.x

3.0 O

4.0 work

contact 5.0

Figure 11.2 Sitemap for a basic blogging site

Start simple: design a basic wireframe


Getting Started It's not unusual to write your own business requirements document, which can be a blessing or a curse. When you're a requirements writer, you basically only have yourself - or your customer - to discuss any vague or relatively undefined implications with. You may often feel like you're making things up, but don't let that stop you. In many cases, a wireframe will help you identify gaps in the information you're working with. This can help you ultimately find the best solution. Remember that UX professionals strive to find the best possible solution for users, and the first version of each of your projects will always be used to gain feedback and influence the next iteration of the project. Your design doesn't have to be perfect, but you want to make sure it looks clean and professional and, at worst, goes the wrong way in the right direction. The requirements for this home page design were limited and very brief. Fortunately, the sitemap shown in Figure 11.2 contains enough information to configure useful site navigation: the home page (number 1.0) is the top navigation. conditions

& Conditions (1.0.1) is probably a common footer element, or at least should not be considered part of the main navigation. The other main navigation elements are About (3.0), Work (4.0), Kon-

tact (5.0) and blog (2.0-2.x) - Described as a stack of pages so you can be sure it will be treated as multiple dynamic pages, possibly with "previous" and "next" navigation forms. These main navigation elements provide a lot of information to get you started, but not enough to effectively create a home page for your website. To help guide, the client provided additional information: The company is a boutique UX design firm that has gained traction through its blog and the range of projects it works on. It is important for website visitors to quickly understand what the company/website is about with limited text and strong, evocative images combined with UX design. It is also important that the navigation is clear (prefer reusable headers and footers where possible) and


Chapter 11: Wireframes and Annotations

A recent Call to Action blog post allows visitors to quickly read a summary of our latest thinking on current issues in the UX space. It would be nice to be able to highlight recent work on the home page if possible, but that's secondary as most of our work is usually under development or kept strictly confidential.

Wireframes and Annotations There are many ways to explain these requirements, and the first wireframe presented to the client might look a lot like Figure 11.3. Wireframe Annotated Home Notes 1

Logo 2





Our job


the to



1 · Logo Image. · The logo should act as a link to the home page

Access your site from anywhere on the site. 2. Main page navigation It should be linked to the main page of the website

from anywhere on the site. 3 · Browsing the blog. It should link to any blog landing page

site location. 4 · Move around our work. · It should link to our job landing page

from anywhere on the site. 5 · About us navigation. · It should contain a link to the About Us 6 7 landing page

7 8 9 10 11

welcome title 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.




Przejdę szędę tó prześci, tak jak to szędzym, kto nie karze fizycznie graczyyy, jak szęży z nich. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolor magna aliquam erat volutpat.

Przepraszam za ból, consectetuer adipiscing 12

13 more > 17

thing #


15 16 17 18 19

© UserGlue | Regulations | Contact


Przejdę szędę tó prześci, tak jak to szędzym, kto nie karze fizycznie graczyyy, jak szęży z nich. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolor magna aliquam erat volutpat. więcej >


from anywhere on the site. · Contact navigation. · The contact page should be accessible from anywhere on the site. · Rotate the hero image. Images should be rotated between several images that look good and are branded. · Welcome title. · The title of the general site review text. · Welcome content. · General overview of website content. · · Title. · Titles from random examples displayed in the portfolio. · · Image link. · Random sample images displayed from the portfolio. You must be logged in to view the details of the random examples displayed from the portfolio. · · Summary. · A brief text summary of the random examples presented in the portfolio (maximum 1-2 lines of text recommended). · · More links. · You must log in to view details of random examples displayed in the portfolio. · · Title. · The title of the most recent blog post. · · Submit your content. · The first 200 characters of the most recent blog post. · · More links. Full blog post should be logged in to view the latest live blog post. · Copyrighted content. ·Copyright and year and company name. · Terms · Link with terms. · The terms page should be linkable from anywhere on the website. · Contact link. · The contact page should be accessible from anywhere on the site.

8 · Welcome title · Title of general site review text. 9 · Welcome content. · General overview of website content. 10··Title··The title of a random example

Appears from the work portfolio. 11··Image Link··Random Image

nt blog title>


Pain sit amet, consectetuer a 15 ummy nibh euismod tincidunt aliquam erat volutpat.


I will let you know who we are



15 16 17 18

Note 19

Example shown in work portfolio. You must be logged in to view the details of the random examples displayed from the portfolio. · · Summary. · A brief text summary of the random examples presented in the portfolio (maximum 1-2 lines of text recommended). · · More links. · You must log in to view details of random examples displayed in the portfolio. · · Title. · The title of the most recent blog post. · · Submit your content. · The first 200 characters of the most recent blog post. · · More links. Full blog post should be logged in to view the latest live blog post. · Copyrighted content. ·Copyright and year and company name. · Terms · Link with terms. · The terms page should be linkable from anywhere on the website. · Contact link. · The contact page should be accessible from anywhere on the site.

Figure 11.3 Annotated wireframe uploaded to the homepage design

Start simple: design a basic wireframe


Annotated wires detail each element on the page, along with expected CTAs and action results (such as loading a specific page). This particular example works well because of the limited number of elements and limited details required.

Figure 11.4 Active homepage design for www.userglue.com

As shown in Figure 11.4, the current active version of the home page differs little from the original skeleton in Figure 11.3. The Portfolio Examples section has been removed because, for example, timing and content have become an issue. Also note the differences in navigation and CTA naming conventions: the skeleton is used as a guide, not the last word. Your final result will often contain various minor changes and updates compared to the wireframe content.


Chapter 11: Wireframes and Annotations

Exercise: Designing the home page wireframe Now that you've seen the example, it's time to create the wireframe yourself. Your goal is to redesign the homepage of Global Cruises, a fantastic international cruise line. Global Cruises wanted its home page to become a more effective sales tool and source of information for repeat customers - typically those who had already booked a cruise and wanted to learn more about other deals and add-ons, updates on travel conditions and more. In this exercise, you will create a skeleton home page as required below, with notes in one document or a separate document (your choice). That's all.

Requirements The main requirement is that the global header and footer (Figure 11.5) remain unchanged - absolutely unchanged. global destination title mark

Current Events Logo Travel Experiences

plan a trip


before the trip

world cruise

VIP club

Special offer

To go

my world cruise

Welcome back,N (the?) | XX days until next trip - Manage booking | BookTravel Add-on | Online check-in

Global Footer Sign up for emails from Global Cruises | aren't you from Click Here About Global Cruises |Contact Us |FAQ |Agent Search |Site Map |Legal Information |Pricing Terms |Privacy Policy © Global Cruises

Figure 11.5 Global header and footer of existing global flights

Title/Navigation should be Destinations|Travel Experiences|Plan Your Trip|Before You Travel|World Cruises VIP Club|Special Offers| Booking Management | Book additional travel | Online check-in

Exercise: draw a home page wireframe


To receive e-mails from Global Cruises, you must be subscribed to display CTA headlines/messages customer service Call the CTA Travel Agent Finder to browse popular itineraries

Optionally, it is possible to display the latest, most popular and/or best-selling itineraries. Ability to view geographic locations and waypoints. After logging in, routes can be viewed (My Routes/IES). Ability to view additional items, e.g.

Go to Hawaii, book an island tour), meals on board and more

World Cruises Now the work begins. Start designing your skeletons - don't forget the appropriate annotations! Once the wireframe is complete, check out the next page for examples of other top professionals who have the same set of requirements.


Chapter 11: Wireframes and Annotations

Result: Homepage skeleton design Will Evans, UX Architect at Semantic Foundry (www.semanticfoundry.com), was kind enough to create a skeleton based on the Global Cruise exercise. Compare your work with his work in Figures 11.6 and 11.7 to see how his approach compares with yours. Below is an explanation of how he put together the wireframe and annotations. 990px ​​wide travel notification

I'm looking for a cruise








new route

To go



popular route

11 1


|Travel experiences


plan a trip


before the trip


Klub VIP World Cruise

Welcome back, In iMMŔ Logout





Special offer


See the itinerary | My world

15 days until next cruise -

9,0 13


Travel Alert: Link to version


Homepage with link to brand/logo


Use predictive sentences to search for defined 3.X user scenarios



New route dropdown menu with links: shows routes with links to section 4.x Popular Routes - dropdown menu shows the 5 most popular destinations in the route


Travel Experience Link: go to X.0 section


Plan your trip Link: Go to section X.0


Pre-trip link: go to section X.0


VIP Club Global Cruises Link: Go to Section X.0 Special Offers Link: Go to Section X.0

my world 12




Multimedia/Flash/Nice picture


Titles with heroes 17 headlines from around the world | Create your own photo with the heroes


Need help planning a cruise?



Header Consectetut Adipisicing Clarity Is home a rope or the pleasure of winning in pain Do you want to be a hair in pain in EU



Voluptuous image


header tracking

header tracking

Be not angry with rebuke, reproach with pleasure, His hair shall grow from pain, never to grow again.

Be not angry with rebuke, reproach with pleasure, His hair shall grow from pain, never to grow again.

Idea title number 1

Idea title number 1

Idea title number 3

Idea title number 2

Idea title number 2

Creative title number 4

The brightness is the reins of the Lord himself, or the wrath of pain in rebuke, in pleasure wants to be a feather in pain

Idea title number 3


October 8, 2008 at 6:46 pm

Brand promotion

But that you may see whence come all the inherent errors of those who blame pleasure and glorify pain, I will show you the whole matter, and what these inventors have produced

post yours

I am very sorry for the loss of consectateur nonummy lorenzino. Sometimes an ordinary person sees this and then makes a mistake.

25 Sign up for emails from around the world.

NO with? Click here

My Global Cruises link: Goes to section X.0 Logout link: Logs the user out of the session


View Itinerary Link: Go to My World/View My Itinerary. My Global Links: Go to the photo carousel of personalized offers/packages


Crowdsourcing link for your highlights


Links to image deals on Big Hero Photos.


Need help planning a cruise?


Offers Promotions CT as / Affiliate


Share Moments Member Profile Call Post your own Star Moments link on a crowdsourced site.


But that you may see whence come all these innate errors of those who deny pleasure and glorify pain, I will unravel the whole matter and explain these words to the seeker of truth and the architect of a happy life.





Voluptuous image

Voluptuous image





your moment in the lead role

Book this special package

Your moment is now! To go


Sign up for emails


link to change country


Global footer links


About World Cruises | Brochures | Frequently Asked Questions | Search representatives | Sitemap | Legal information | Price terms | Privacy Policy

Page 2

Figure 11.6 Wireframe of Will Evans Global Cruises home page

Exercise: draw a home page wireframe


990px ​​wide travel notification

I'm looking for a cruise









new route

To go

OK Will "Bahamas" | Travel experiences | Plan your trip with us | Learn before you travel



Popular routes 1

Klub VIP World Cruise 6.0


Special offer


special cruises

Welcome back, In iMMŔ Logout


279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

charleston freeport

charleston freeport

15 days until next cruise -

7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


Great Stirrup Cay (our private island) Port Canaveral Charleston


Multimedia/Flash/Nice picture

Filter titles from around the world | Create Your Own Star Need help planning a cruise

charleston freeport

charleston freeport

Great Stirrup Cay (our private island) Port Canaveral Charleston



Quick tip: Saved results show matching strings


The cruise card contains the following metadata: 1. Price 2. Average rating 3. Title: Cruise Title 4. Duration 5. Ports of Call 6. Details link 7. Link to book this cruise 8. Save/favorite this cruise


Versatile navigation allows users to dynamically change port, voyage month, vessel or price range and dynamically sort/filter the corresponding result set. Each of these can be recalled when the user sees all results on the search results screen


After using advanced search predictive filters, they can click to see all search results, which will use Ajax to load the full set of results into a javascript table for quick sorting.


Share Moments Member Profile Call Post your own Star Moments link on a crowdsourced site.


Title Shot FridayHero Saturday

Book this special package


- Any ship offers/news

190 USD to 1650 USD

Title Adipisisic Duis will follow him, i.e. pain will rebuke pleasure, he wants to get out of pain without giving birth to anything.

The brightness is the reins of the Lord himself, or the wrath of pain in rebuke, in pleasure wants to be a feather in pain

your moment in the lead role


Price: voluptuous image

The brightness is the reins of the Lord himself, or the wrath of pain in rebuke, in pleasure wants to be a feather in pain

New routes expandable with link: view route with link to section 4.x Popular routes - dropdown menu shows the 5 most popular routes




-every month-

Voluptuous image

header tracking

Use predictive sentences to search for defined 3.X user scenarios



Your results are now instant! To go


Homepage with link to brand/logo


Fri Sat 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Homeport/City: Deals/News Washington, DC 8.0


See the itinerary | My world

Fri Sat 7 nights

Travel Alert: Link to version



Fri Sat 7 nights


my world

HEDONIC IMAGE 9.0 View all search results

Title Adipisisic Duis will follow him, i.e. pain will rebuke pleasure, he wants to get out of pain without giving birth to anything.

Idea title number 1

Idea title number 1

Idea title number 3

Idea title number 2

Idea title number 2

Creative title number 4

Idea title number 3


October 8, 2008 at 6:46 pm

Brand promotion

But that you may see whence come all these inherent errors of those who deny pleasure and glorify pain, I will unravel the whole matter and explain to you what the discoverer of this truth said, as in essence the architect of a happy LIFE. But that you may see whence come all the inherent errors of those who blame pleasure and glorify pain, I will show you the whole matter, and what these inventors have produced

post yours

11 1 12

Sign up for emails


link to change country


Global footer links

I am very sorry for the loss of consectateur nonummy lorenzino. Sometimes an ordinary person sees this and then makes a mistake.

13 12

Sign up to receive emails from around the world.

NO with? Click here


About World Cruises | Brochures | Frequently Asked Questions | Search representatives | Sitemap | Legal information | Price terms | Privacy Policy

Pages: 3

Figure 11.7 Wireframe of Will Evans Global Cruises home page with search enabled

Mockup with Words of Will To me, a mockup is a "thinking device" for shaping and exploring a specific problem space - in this case, the cruise operator's home page. Designing with wireframe models is a search for alternative solutions in a problematic space. it's a process of both posing and problem solving, which means I always start with the context. In this case, the mainstream audience wants to easily find the best cruise at the right price at the right time. Simply put, I chose my primary audience and a campaign that allowed them to quickly, easily and elegantly solve the goal. By drawing skeletons, I can explore alternatives and invent, test impossible and possible ideas and in many cases reject them. I already knew that I wanted to design the best possible cruise search interface and I wanted this activity to be at the center of the design. Here I sketched out the idea of ​​providing instant suggested cruises before the user commits to watching


Chapter 11: Wireframes and Annotations

Full screen search results. I want the user to be drawn into the conversation and involved in the process of finding a great cruise. I'm looking for a cruise


OK, we found a will for "Bahamas".

To go

18 special cruises

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

charleston freeport

charleston freeport

charleston freeport

charleston freeport

7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston





Fri Sat 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


Fri Sat 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


Friday Saturday


Friday Saturday

Y Filter Results Home Port/City: Month:



-every month-


- any vessel

190 USD to 1650 USD

see all search results

Figure 11.8 Cruise search results function on the Will Evans home page

For a cruise operator, I outlined the headers, footers, static content, and areas to block in the design of content units, such as calls to action and promotions. I share the results of this phase with key stakeholders, but also involve visual designers, development managers, and QA people so they can contribute to the process, provide more ideas, and start documenting pitfalls and limitations. Ultimately, as a designer, I have to make the decision to make the design within specifications. I created two or three candidates for final consideration and through the use of annotations, allowed the wireframe to present its case to stakeholders and target auditors. The cables you see in Figures 11.6 and 11.7 are currently at this stage with minimal design changes and details.

Exercise: draw a home page wireframe


Compare and Contrast Notice that the example in Figure 11.3 and Will Evans' work are very similar, but differ in wireframing style. Now it's easy to look at them and proudly say: "These are skeletons!". Both have their own style and approach, but the core is very similar. The examples in this chapter are a good starting point to find the wireframe style that works best for you.

Photo courtesy of Maciej Piwowarczyk

Visual Design: When wireframes grow up and find their way into the world

Figure 11.9 Global Cruises homepage visual design by Mark Brooks


Chapter 11: Wireframes and Annotations

Based on the requirements and cables of Will Evans, Mark Brooks (www.markpbrooks.com) created a home page design for the fictitious company Global Cruise Lines. As you look at the visual design in Figure 11-9, notice how it thinks about page layout and content. As the project moves through the process and enters the development phase, interaction patterns begin to emerge.

Continuing the design exercise: which design is right? As long as the requirements are met, there is no good or bad design. Sometimes you may feel the need to create multiple mockups for a single page to explore approaches, work out the details, and present them to potential users, team members, and perhaps clients. This is perfectly acceptable. Remember this is an iterative exercise. The work you present to clients will almost always not be considered "correct" or "finished" on the first try. You usually go through at least one round of iterations and updates. Unfortunately, this sometimes spans multiple rounds - but that's the nature of the project, and it ultimately leads to less exploration by partners working downstream. Check out the differences in approach and presentation style by comparing the wireframe and annotations to the two examples provided. Compare this to the home page example earlier in this chapter and what you did. Find the similarities and differences and create what works best for you, unless there is already a fixed pattern for you. In many cases, the hardest part of creating a cable is the first time you put pencil to paper. Take Leah Buley's advice and start drawing lots of ideas - doodles and drawings, exploring different approaches and testing your designs with colleagues, co-workers and family until you feel confident that you can defend your design (instead of defending yourself your). you will find that you are moving in the right direction.

Exercise: draw a home page wireframe


A Final Note on Wireframing Once you start creating wireframes and become more familiar with work products—and understand how important they are to your workflow—it's easy to forget that not everyone understands the thought and effort that went into creating them. . Often, clients and colleagues may have encountered mockups of completely different levels of quality, complexity, or with different annotation styles. In fact, you may find that many of your colleagues and clients have never seen a wireframe (even if they claim they have). It's also not uncommon for clients and colleagues to get confused about the difference between a sitemap and a wireframe and what they're used for. In other words, your first wireframe can be your client's first wireframe! This makes it extremely important to accurately stage the scene for what you want to present. Before showing mockups, you need to be clear about what they are, how they will look compared to the final visual design, and what their purpose is. Here are some additional suggestions for mockup presentation: If possible, involve the client's team in the discovery process. try to

Join the active drawing on the board. Explain that they are involved in the wireframe process and that the end result will look similar but will be produced in electronic form. It is very important to make it clear that this is an activity that will result in cables that may look very different as you explore the design options. Find powerful metaphors to convey the difference between your prospects -

The framework and final design of the project. A popular metaphor is that "a wireframe is to an app/website what a plan/floor plan is to a house". Wireframe models allow for easier and more efficient implementation of changes and at the stage when change is usually least expensive (before the build team is involved and the foundation is poured). Tell participants that the skeletons are not the final representation

Edit graphic pages. Wireframes are presented to illustrate content, overall layout and interaction


Chapter 11: Wireframes and Annotations

page elements. Once the frames are approved, construction can begin. (Oh, and minor tweaks are still possible!) Get your visual designer involved—if you have the time and budget—to ensure

Draw mockups to show the difference between the wireframe and the final design. If possible, show the client examples from other projects that show how the wireframe and final design can be similar and different at the same time. Explain how the rest of the design team will use the cable -

Framing - It never hurts to educate the client on the importance of reviewing and approving this milestone and how the wireframe informs the rest of the design. As your clients and colleagues begin to understand and appreciate the value of mockups and their place in the design process, your projects will become easier. Why; Because cables help create visual clarity and direction for the rest of the design. In many cases, colleagues and clients may even promote the usefulness of wireframing on your behalf. This allows you to spend more time designing the user experience and less time selling it!

A final note on the presentation of skeletons



Prototyping brings (somewhat) life to your project Prototyping is an effective way to test and validate proposed functionality and design before investing in development. You can use a variety of tools and methods to create prototypes, from quick and dirty (but we prefer quick and clean) to interactive and efficient. Which method you use depends mainly on two factors: time and the materials available for prototyping. Russ Unger and Jono Kane


What is the original? In the context of user experience design, prototyping is an activity (in many cases an art) of creating and testing with users all or part of the functionality of an application or website. Prototypes can be created using analog tools such as a whiteboard or pencil and paper, or digitally using PowerPoint, Acrobat, Visio, OmniGraffle, HTML, or other technology-based tools. Prototyping can be an iterative process, as prototypes are often created to identify or verify user experience issues. After gathering feedback, you can make modifications to the prototype for additional testing. In other cases, a (fairly) successful prototype allows the project to continue into other phases of the development cycle. Remember that prototyping is a process, not an artifact. You may end up creating screens and (sometimes simulated) features called prototypes, but these are part of the prototyping project, not the final product. The result of the prototyping process is active feedback from the idea that can be used to refine and improve the design. However, this chapter only focuses on prototyping, leaving the details of testing to chapter 13.

How many originals do I need? Every UX design process should involve some level of prototyping — formal or informal, interactive or static. It is not necessary to prototype the entire website or app. In fact, prototyping can be very efficient when only a representative sample of the system is used - in other words, you don't need to simulate the entire system, only key parts of it. Most of the time, you'll want to test some concepts, and your prototype should contain those concepts, nothing else. You can use a variety of ready-to-use prototyping methods: paintings, pen and paper sketches, storyboards, cardboard cutouts, and more. Additionally, there are many digital tools that allow you to create interactive prototypes and engage test users in a more realistic environment.

How many originals do I need?


The prototyping method you choose will depend largely on time and available materials. Below are some of the most common methods for many of your prototyping needs.

Paper Prototyping Few activities will take you back to your early days quite like the hands-on, art and craft approach to paper prototyping. The only tools you need are pencils and pens, paper, scissors, and anything else you can buy from the art department or local office supply store. Prototyping on paper is very flexible. As long as you have a rubber band or more fabric, you can create as many scenes as you want. You can also quickly change from test to test - meaning that if a potential user notices that something you've created has an obvious bug, updating the design before it's shown to the next potential user isn't a complicated process. It's also cheap. Aside from the time spent on paper prototypes, you can generally create any scene for much less than the cost of a few high-profile lattes. Paper, sticky notes, index cards, pencils, etc. it should already be available to you, and if not, you won't break the bank hoarding it. The process is simple: design the part of the functionality you want to test. Show functionality to users. Write your comments (this is paper, so turn your prototype over and start writing). Then move on to the next user or update and start over. simple. pleasure. Effective. Used early in the process, paper prototypes can help identify design issues before you invest a lot of money. At this stage, changes can be made quickly and efficiently, reducing risk. This allows you to make effective changes before you invest too much in the project. Using three sheets of different colored paper, draw each of the tabs in Figure 12.1 as they would appear on a web page stacked on top of each other. The Global Now tab is placed at the top to display its contents as if the user had just visited the home page for the first time. Each tab shows the navigation available to the user and allows them to select different browsing options.


Chapter 12: Prototyping

Figure 12.1 Paper prototype of vertical tabbed navigation

Figure 12.2 Vertical tabbed navigation paper template with the My Trips tab active

When the user selects a different bookmark, that particular bookmark moves to the top of the stack to display a view of the newly activated bookmark's content area, such as the My Trips tab shown in Figure 12-2. Paper prototyping is as low-budget as possible and can be as simple as the exercise above. The time investment can become significant (although material costs will increase slightly) as you begin to explore the entire system. This approach can be expensive if you need to change the main navigation in a 100-page paper prototype. While paper prototyping is inherently cheap, it is not reusable when parts need updating. It is then worth considering whether moving to digital tools would not be more beneficial.

Digital Prototyping If your prototyping needs go beyond paper, you may find that a technology-based solution is better for you and your audience. These tools allow you to show exactly how the interactive parts of your website or app will look to users. Digital Prototyping builds on many other aspects of the design process. You will be able to reference your characters when viewing or testing digital prototypes, reference mockups for sharing and visualizing prototypes, and reference visual design elements (if available at this stage of the process) for realism Effects are installed and complete your prototype .

Wireframe vs. Real-World Prototyping As with paper-based prototyping methods, mileage can be different with digital prototyping. It depends on the tools, resources and skills you have

digital prototype


process and requirements you are working on, you may find that making your prototype look like a wireframe is good enough for your project. In fact, it might be better. Wireframing can show viewers that the project is still a work in progress, not a finished site ready for production. On the other hand, sometimes when you test a design with users, you discover that the most important aspect of a prototype is how realistically it represents the final system. The outcome of your digital prototype depends on three factors: What does your timeline look like?

Do you have time to get your team together and create a stunning near-production-ready prototype that gives the users in front of you a clear vision of a production-ready website? Do you have a few hours to export mockups to HTML or create a very simple Flash project to just display the page flow and basic interactive elements in your project? Both types of digital prototypes are very useful. However, as with any real project nearing completion, it's important to set expectations based on time and available materials. Who are you building this prototype for and why?

Knowing what you're doing with it before diving into design is critical to the success of your prototype. Do you build prototypes to test the design with users? If so, what is the point of this test? Does it matter if the prototype is a black and white wireframe or should it look like a live website? Testing button and link tracking? Are you prototyping a business proposal that requires buy-in from an executive, manager, investor or other group that can sign a check at the end of the day? If so, what do you want to convey to them? What is supposed to be functional and what is only functional? These questions can help you determine your digital prototype requirements.


Chapter 12: Prototyping

What kinds 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 one, you can create very powerful prototypes with simple presentation tools like PowerPoint or Keynote or wireframe tools like Visio or OmniGraffle. Even a simple PDF file is enough.

HTML with WYSIWYG editors HTML is the digital equivalent of paper prototypes. It's (sometimes) free and (somewhat) simple. If you are not an HTML creator or front-end coding expert, you can become an HTML prototype creator with basic HTML knowledge. Basically, there are two ways to create HTML prototypes: coding HTML by hand or using a WYSIWYG editor like Adobe Dreamweaver, Realmac's RapidWeaver, or Microsoft Visual Studio. These tools have a code view and a layout view, which allows you to visualize how your code works without opening a browser. Prototyping with the WYSIWYG Editor The advantage of using the Layout View in the WYSIWYG HTML Editor is that you can create page layouts with about the same effort as creating a page layout in Microsoft PowerPoint (Apple's Keynote) or any other simple layout application chart (more on this later). It's just as easy to add interactivity like links, mouse events, etc. One of the most impressive aspects of Dreamweaver CS4 (Figure 12.3) is that it offers what Adobe calls Live View, which is based on the open source WebKit rendering engine. What it means? It just means that what you see in live view is exactly what you see in Apple Safari and Google Chrome - assuming you pay close attention to detail in your prototype. Dreamweaver CS4 is a very powerful prototyping tool, especially when combined with Adobe Fireworks CS4.

digital prototype


Figure 12.3 A simple sample prototype created in Dreamweaver CS4

Creating a Basic HTML Prototype Probably the cheapest way to create a simple, quick HTML prototype is to do it "by hand" - by entering the code manually into a text editor. One of the most common reasons for switching from wireframe to prototype is the need to preview or test a proposed site flow and navigation. By taking blocks of elements or even entire pages from a wireframe (or design mockup) and setting them 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 on the image of the entire page in your browser and load another page very simply. You will need a home page and search results skeleton to use in the exercises below, or you can download sample images from www.projectuxd.com. Note Spelling errors are the most common errors in HTML coding, so pay special attention to spelling.


Chapter 12: Prototyping

1. Export the home page frame from your preferred tool, such as Visio or OmniGraffle, or export the diagram from a visual design tool. You should save the entire page as a GIF image called homepage.gif, create a new folder called Prototype and save homepage.gif there. Note JPEG is ideal for raster and photo-like images, while GIF is better for wireframes and line drawings.

2. In a WYSIWYG HTML editor or a simple text editor such as Notepad (Windows) or TextEdit (Mac), create a new document and save it as homepage.html in the same Prototype folder. If you are using TextEdit, make sure you select HTML as the file format. 3. In the new document, enter 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 a web browser. You should see a blank page, but pay attention to the title bar in your browser. It should say "Home". 5. Edit the homepage.html code in a text editor. Between the tags and insert the following HTML code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

This code will turn the entire homepage.gif image into a clickable button that will load the searchresults.html page (you must create this page to verify that the function works successfully). 6. Save the document and reload the page in the browser. You should see the nice new home page you just created in your browser (Figure 12.4). When you click on an image in the browser, the browser will try to load the searchresults.html page (which doesn't exist yet).

digital prototype


7. Repeat step 1 for the search result wireframe content. 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 "searchreseults.html". Then update the HTML to display it and link back to the homepage (homepage.html). You will need to replace this line of code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

From these: 1V]gZ[2]dbZeV\Z#]iba31^b\hgX2hZVgX]gZhjaih#\^[WdgYZg2%31$V3

8. After creating this page, you will have a very simple HTML prototype showing how the two pages are linked together.

Figure 12.4 HTML prototype of the home page displayed in a web browser


Chapter 12: Prototyping

Code Analysis Now that you've created a basic prototype using very limited HTML, let's take a quick look at the code or HTML tags you've used to better understand what you've just done. HTML, head and title tags 1]iba3 1]ZVY3



is a basic tag required in every HTML document. An important thing to look out for is the title tag, which allows you to specify the name of the page. Image tag 1^b\hgX2]dbZeV\Z#\^[3

Also a simple card; that's all you need to see the image in the browser. An anchor tag like this, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

Used to define links in HTML documents. For simplicity, the example anchor tags use relative paths - "relative" because the tutorial is in the same folder. The absolute path is: 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

Although this HTML code is unstyled or non-standard (don't show it to the developer - they might be asked to teach you a hard lesson in coding practices!), it's good enough for your prototype to work in a browser. Keep in mind that this prototype doesn't have to be perfect: the goal is just to communicate your idea to your audience. This simple markup example creates linked HTML files that allow you to click between pages, but what if you want finer click areas in your layout? The answer is: image maps. Using image maps, you can specify areas of an image to link to and display a different page when clicked. The easiest way to create an image map is to use a WYSIWYG tool like Dreamweaver to distribute the linkable parts of an image without knowing how to generate HTML. For more information on creating an image map, see How to

digital prototype


Dave Taylor's Guide: www.askdavetaylor.com/how_do_i_create_an_image_map_for_my_web_page.html. HTML prototyping is only one approach to digital prototyping. Many different frameworks and dynamic coding languages ​​can be used to create very powerful prototypes for almost any need. If HTML prototyping is an area you want to explore and develop, you can find tutorials and other resources to gain a deeper understanding of the field. First, you might want to look into JavaScript, PHP (or another dynamic coding language), jQuery (http://jquery.com), or Yahoo! Interface Library (http://developer.yahoo.com/yu). Note For details on HTML, see HTML Dog: A Best Practices Guide to XHTML and CSS by Patrick Griffiths (New Riders, 2006).

Additional Prototyping Tools You've already learned about the practical options that can help you prototype in both the analog and digital realms. In addition to these methods, many other software tools can be used for prototyping, ranging from basic "do the job" to more advanced prototypes full of interaction and intelligence. The list below is not exhaustive, but gives you plenty of opportunities to create the right prototype for your situation. PowerPoint and Keynote Prototypes PowerPoint or Keynote fall into the quick and dirty category, and sometimes that's all you need. A PowerPoint or Keynote prototype can be built as a basic slideshow with simple interactions. Both tools allow you to create interactions to simulate the flow clicks you want to control with the user. If you're an advanced user of PowerPoint or Keynote, you can embed animations and other elements to make your presentations more interactive. Adobe Acrobat PDF Exporting a wireframe or visual design as a multi-page PDF may be all you need to show how your product will look and move linearly between pages. Note that many 214

Chapter 12: Prototyping

Export to PDF If you're using a Mac, you can choose "Print to PDF" for almost any document or file in any application that lets you print. Many applications, including Visio and OmniGraffle, allow you to specify access points and actions (such as link locations) for interaction. Visio and OmniGraffle Microsoft Visio and OmniGraffle from the Omni Group are well-known wireframe tools. Both allow you to create clickable prototypes that can be exported to HTML and PDF formats. In OmniGraffle, if you export to HTML, you can easily assign actions and specify jump points to PDF files or URLs. Visio offers a prototyping kit that can be downloaded from the web and easily exported to HTML or PDF with clickable areas for easy page navigation. Visio and OmniGraffle can also export to popular vector and raster formats such as EPS, GIF, and JPEG, making it easy to import images into Flash, use them as images in HTML prototypes, and more. Axure RP The "RP" in Axure RP stands for Rapid Prototyping, making the tool popular with many UX designers. This tool provides design features similar to those found in Visio and OmniGraffle, but adds a relatively easy-to-learn set of tools that allow you to create different navigation styles, forms, popups, and other common page-based interactions. In addition, its support for flexible integration of specifications, notes, tasks and progress flags allows you to create document-based specifications directly from prototypes. However, Axure is a Windows-only tool, which can be a challenge if you use a Mac and don't use apps that allow you to run Windows. Fireworks CS4 Adobe's Fireworks CS4 has recently become increasingly popular as a tool for creating a wide variety of design elements, from wireframes to visual designs. It has a standard set of Windows and Mac form elements and controls, allowing you to easily define interactions, emphasizing functionality without the need for external developers. The Shared Library stores elements that can be added and shared across multiple documents so they can be reused

digital prototype


Element. Fireworks also has a Pages feature that lets you create sets of elements common to all pages in a given document, similar to how developers use the word "contains" or how some document systems let you create backgrounds that can be reused on different pages of a document. This feature is useful for identifying repeating content areas at the page level, such as headers, footers, and navigation, while maintaining unique content areas on each page. Balsamiq Mockups Mockups by Balsamiq Studios is a wireframe and prototyping tool that gives you a wireframe experience similar to pencil and paper - only you're using a computer. There are many pre-designed generic UI controls (over 60 at the time of writing) that you can drag and drop onto your screen and customize to fit your design. Your mockups are designed as if they were drawn by hand, which gives digitally created displays a more organic feel, but the digital platform allows you to quickly modify designs for quick iteration. Flash and Flash Catalyst Prototyping with Adobe Flash is a great way to communicate interactive concepts beyond basic point-and-click prototyping. Flash allows you to easily create click prototypes, but it also allows you to add other interactive elements, including hover or hover events, click events, videos, and animations. If you're ready to 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 results. For the history of Flash prototyping, see Alexa Andrzejeski's article on boxes and arrows, "Quick and Easy Flash Prototyping": www.boxesandarrows.com/view/quick-and-easy-flash. At the time of publication, Adobe announced a new prototyping tool called Flash Catalyst. Flash Catalyst is a development environment that works with other Adobe CS4 applications, acting as a link between the design and development process. This allows you to effortlessly export your designs into viewable formats. Visit the Internet for more information. adobe.pl.


Chapter 12: Prototyping

Work with a developer If you have the resources, you can hire a developer to prototype for you based on your cable or design. Remember that developers need to have a good understanding of what you are trying to achieve, so this approach may also require you to create specifications and programming requirements to make the process efficient and effective. If your prototype is intended for iterative testing, be sure to state which parts of the prototype you are focusing on testing so that changes can be implemented quickly. It is recommended that you spend time with developers during the development process and identify critical areas of code that should be marked (with code comments) as vulnerable to change. Be sure to stay in touch with the developers while prototyping to keep the lines of communication open and the output accurate. NOTE For more information on various prototyping methods, see the forthcoming book A Practitioner's Guide to Prototyping by Todd Zaki Warfel (Rosenfeld Media, forthcoming 2009: www.rosenfeldmedia.com/books/prototyping).

Prototyping Examples The simple, easy-to-use prototype examples in this chapter are far from a complete set of approaches that should be used in every situation. To highlight some of the real-world applications of prototyping, Keith Tatum and Jon Hadden have generously shared their experiences. Keith Tatum, Senior User Experience Strategist at Slingthought (www.slingthought.com), created the paper prototype shown in Figure 12.5 to explain the navigation links on the left and define the navigation hierarchy for his partners at Align Interactive (www .aligninteractive) and classifieds.com). In addition, the paper-based prototyping process allowed him to skip the wireframe phase and proceed to the visual design and layout phase (Figure 12.6).

prototype example


Figure 12.5 A paper prototype used to explain the concept of navigation to the development team

Figure 12.6 Design of a working web page based on a paper prototype

Leveraging his team's collective knowledge of design and development work, Keith quickly built the project in two business days. This enabled the team to rapidly develop a visual design concept once approved.

Figure 12.7 Working prototype of the calendar tool, simulated using high-quality XHTML, CSS, and JavaScript. courtesy of Jon Harden


Chapter 12: Prototyping

Jon Hadden (www.jonhadden.com), a senior visual designer at Yahoo, has prototyped calendar functionality for a tool he's developing called Project Manager. Project Manager is an online collaboration application for project management. It starts with an OmniGraffle wireframe and then builds into a high-fidelity XHTML prototype to help you determine if features are available and affordable. Affordability is a big focus: In some cases, you might try a prototype of an app or part of a project to see if the functionality is worth it. If feature development costs are an issue and prototyping exceeds time and material expectations, you may need to evaluate the feasibility of the design.

What happens after prototyping? Once the prototyping process is complete, you need to synthesize the results and turn them into something actionable. If you're prototyping on paper, you can start creating digital wireframes based on the feedback you get. If you are already in digital wireframe mode, you may want to update your wireframe and continue with the design process. Alternatively, you may need to collect feedback and update the prototype for the next round of reviews. Todd Zaki Warfel, CEO of Messagefirst (www.messagefirst.com), shares the following insights: Technical feasibility testing (eg with boss, other designers, etc.) Testing design ideas with end users/customers Build prototypes as a feedback mechanism. Prototyping allows you to determine whether to pursue a particular design direction or explore another before moving on to the next design phase.

Remember: no matter what stage of the process you're at, prototyping is only one part of the process, and like any other part, you need to know when you've reached peak performance and are ready to move on to the next stage of the UX process. What happens after prototyping?



Design testing with users Get rid of what you think you know - and find out what people think, feel and like about the overall theme of the site. The techniques discussed in this chapter will help you gather user information about a specific project or design element. We will focus on exploratory techniques and usability testing, often used in the early design stage, which can be used at many points in the project. First, let's talk about exploring design concepts with users. Carolina Chandler


Concept Exploration A concept is usually a word used to describe an abstract idea, such as happiness, cooperation, or efficiency. In the field of user experience design, the concept is also used to refer to a design element intended to represent one or more abstract ideas to the design team or potential users. In this sense, conceptual design elements can be visual (e.g. a picture of a machine representing the concept of efficiency) or textual (e.g. a short sentence expressing the concept of efficiency). Companies focus on efficiency, words like timeliness and responsiveness). The concept can also refer to mockup exploration, visual design mockups, or initial prototypes designed to convey a general message on a website (see Chapter 12 for more on prototyping). Concept exploration usually happens early in the design process, after user groups are defined, but before we delve into the details of each page or screen. Research can inspire designers and reduce the risk of bringing a new product to market because you'll be able to listen to (and then design for) the different reactions of potential users.

The main goal of concept mining is to understand the different reactions and ideas elicited by a group of users when confronted with a set of design elements.

Conceptual exploration can involve one-on-one or small-group discussions, but it also involves individual activities to gather and discuss different perspectives. The latter can be structured like a focus group, with part of the time devoted to concept testing and followed by a group discussion (see Chapter 6 for more on focus groups). Let's look at an example of exploring the concept of a non-profit microfinance organization.

concept exploration


Potential Pitfalls of Exploring the Idea Henry Ford once said, "If I asked my customers what they wanted, they would ask for a faster horse." rely on them to replace the designer. After all, the most memorable designs are often different from previous designs, and study participants may not be comfortable with a large degree of change. Participants' answers will be based on their current understanding. You're gathering answers, not predictions about what they will or won't want in the future. Also, remember that many factors other than the project itself can influence future behavior (eg positive word of mouth). Avoid asking participants to make an immediate choice (eg "Which concept is better, A or B?"). Instead, listen to them describe the proposed idea in their own words. The results should be considered as an input to the design process and not as a mandatory requirement for the designer. For an excellent overview of the potential pitfalls of design concept testing and tips on how to use the technique properly, see 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 funds very small loans to entrepreneurs in poor countries. These loans allow borrowers to build businesses that improve the lives of their families and communities. Loan funding comes from people coming together to make small loans or donating small loans to form larger loans (for example, $25 each to finance an $800 loan needed by a shopkeeper in Kenya). The entrepreneur repays the loan as the business grows. The funding model is very powerful, but the organization sometimes struggles to explain the concept in simple words. In addition to the challenge of describing microfinance, the agency was unsure how to handle religion-related messaging and design. This microfinance organization was inspired by the beliefs of the founders and employees. Many people in the organization want to


Chapter 13: Testing Your Design

This inspiration was evident in the website design, but they were unsure how to strike the right balance: if the religious message was presented too strongly, it could alienate potential donors who were not members of that faith. Too thin and the organization does not fully reflect its values. The UX project designers decided to explore possible ways to use images and text to explain the microfinance model and represent the organization's religious inspiration without alienating potential donors. To this end, they selected images and text that could be used to explain concepts related to models, such as self-reliance and investment, and others that represented different degrees of religious information, such as faith and spirituality. Next, schedule focus groups with participants who are part of your website's target audience. Two groups of users were examined: those who stated that they had donated as an expression of their religious beliefs and those who did not. For each group, the facilitator explained the donation model (without mentioning religion). Each participant is then given a poster board, a set of pictures and a set of words to use, as well as additional blank cards where they can write their own words if they wish. They were asked to create a collage of the images and words they used to explain the model to friends and family. After completion, participants reconvened to present their collages, explaining why they chose certain images and text and not others. Figure 13.1 shows an example of the collage created in this exercise. Figure 13.1 Example of collages created by participants during a concept test

The project team gained valuable insights from these collages and subsequent discussions. Remarks include participants avoiding representing “Western

ern" (eg suit and briefcase). They want to improve the lives of entrepreneurs without changing the culture of entrepreneurship.

concept exploration


All user groups agree that a website should focus on its purpose

Organization (funding entrepreneurs to grow and prosper) rather than the motivation behind it (religious inspiration). Participants felt it was important for organizations to be true to their identity, but to include this information in areas dedicated to describing the organization itself, such as the About Us area. The resulting attitudes and interests helped the team determine the direction of the message on the site – and was a great example of the value of testing the idea!

Tips for Exploring Visual Design Mockups At some point in your project, you may have a mockup that represents a possible design for your website pages. If you decide to explore a project with participants, it's a good idea to present them with two or more variations to compare and contrast. There's only one, and you're more likely to have a "good" attitude: people don't want to sound too critical of the model because they don't want to hurt the designer's feelings. However, when there are two or more models, they tend to be more critical because they focus more on comparing designs than directly criticizing them. You can give participants each project individually (on screen or in print format) and ask a series of questions. For example, you could ask participants to take a minute to look at each project and then choose at least three terms from a list that best describe the project. They can circle their choices on a piece of paper with 20 words, such as boring, trendy, conservative, strong, safe, etc., in random order. You can also collect answers to open-ended questions. For example, you can give participants five blank lines to write their overall impressions of the project. Some of the information you may collect includes common brand associations that participants make:

"The pseudo-company is the Rolls Royce of gadget makers: it looks great, but you probably can't afford it."


Chapter 13: Testing Your Design

Design and lifestyle to match:

“I don't think I would send my son to this site. He is only 8 years old and the pictures are too big for him." The effectiveness of a particular model in explaining new concepts:

"Oh, I see - this site is like a marriage registry, but you register charitable donations instead of tableware."

"When I see the word solution on this page, I feel like I will find all the products and services I need to track my shipments." Questions or concerns about using a particular toolset

or the impact of their introduction (the following sections illustrate some examples of participant concerns). Designers can use these answers to determine if the answer they are getting is what they expect or if they should try a different approach. Remember that participants (and project stakeholders, for that matter) often choose different elements from different projects: "I like this part of Concept A and this part of Concept B." A natural reaction, but not literally. You don't want an unnatural combination of two different design directions. If the visual designer really thinks pop elements go well together, go for it. But give her space to tell you that instead of "chocolate and peanut butter" it's "chocolate and pickles." In general, there are no hard and fast rules about what should be included in a concept test or what kinds of things can be tested. Instead, the key is to make sure you set the right expectations for the design team about what kind of information will come out of testing and how that information will be used to make design decisions without stifling creativity.

Usability Testing Usability testing is one of the most commonly used methods of testing user experience design. It's also the most famous among those who aren't UX designers themselves, so your business stakeholders and design teams are probably already familiar with it. The idea itself is very simple: create a set of priorities

usability testing


Tasks for the site, ask some users to complete these tasks and note where they encountered problems and where they succeeded.

Usability Testing vs. User Acceptance Testing Some people in your organization may have the misconception that usability testing is only done at the end of development or at the beginning of development, when a working version of a website or application may be in beta. This impression may also be related to the common practice of performing User Acceptance Testing (UAT) afterwards. The similarity of the names can confuse the two. For applications that go through a formal QA process, UAT is one of the later stages of testing and is rarely performed by real users. The main purpose of UAT is usually to finally verify that the application meets the functional requirements stated by the stakeholders, as well as to detect any bugs or errors reported by the participants. While UAT can cause usability issues, it shouldn't be the only way to capture them in your design. Since this happens later in the process, changes based on UAT feedback are much more costly. It's much better to catch the big issues early, before too much time is spent in the development process. Usability testing is designed to provide more realistic performance information early in the process.

The following sections cover typical usability testing steps such as method selection, research planning, recruitment and logistics, writing a discussion guide, facilitating the analysis and presentation of results, making proposals


Chapter 13: Testing Your Design

Before you begin, think about the goals of your project. They will help you stay focused at all times, but are especially useful in the early stages of method selection and test planning.

Choice of Method Research methods are often described as either quantitative or qualitative. Quantitative research focuses on numerical data and aims to provide highly reliable, repeatable results for the target user base. It involves including a large enough group of users in that group (called a sample size) so that you can take the results from a smaller group and estimate to some extent how the whole group of users reacts inappropriately. Overall, it is a more scientific research approach with formal trial design and analysis. The emphasis is on evaluating your current design - especially compared to other iterations of the site, competitors, or a set of benchmarks. Doing quantitative research means involving more participants to account for individual differences you may find, such as typing speed, familiarity with similar websites, etc. Surveys are an example of an information gathering method that can be extended to larger audiences with quantitative data—if you ask the right questions (see Chapter 6 for more information on surveys). Qualitative research, on the other hand, is not about certainty and reproducibility, but about gaining context and insight into user behavior. It is based on the interpretation of the designer's findings, intuition and common sense. (Contextual research discussed in Chapter 6 is an example of qualitative research.) Discussions with the user are just as important, if not more important, than the results. The focus is on improving current design - gaining insights and responses to what is presented to generate ideas. So is usability testing quantitative or qualitative? This is one of the longest running debates in the field of UX design. Either approach is possible and can lead to useful results. Proponents of a more quantitative approach say:

usability testing


It allows you to set measurable benchmarks that can be tested

In later iterations, show progress toward a goal (for example, reducing checkout time by 20% or finding 80% of usability issues on your site). It's also a great way when you want to make a formal comparison between two sites or evaluate a specific site. It provides statistically verifiable results that can be significant

When it comes time to defend recommendations to stakeholders who trust data-driven decisions. This reduces the potential for bias on the part of individual UX designers

result. This gives a higher degree of certainty that results will be achieved

The results are reflected across the entire user base. It provides a transparent numerical method to validate the results (e.g.

how many users encountered the same problem). Proponents of qualitative usability testing say: Qualitative research builds experience and empathy among designers,

Facilitate the creation of creative, user-centered solutions. It relies heavily on the intuition of UX designers to make logical recommendations

It's recommended, which is largely why he joined the team. Particularly for usability testing, qualitative methods are often less accessible

More expensive than quantitative research, both because fewer users are needed and because qualitative research does not require formal knowledge of scientific design and analysis (eg, statistics). It is easy to misanalyze quantitative research results, to lie

(but unintentional) exploitation of data, so quantitative methods can actually introduce more risk than qualitative tests if done incorrectly. Although the results are not numerically verified, they can be verified

A designer who will use their conscious reasons to make a call about the potential impact of the problem and build a case with user stories. For those without formal training in scientific methods, qualitative usability testing is a more accessible approach that provides a rich source of design data. For these reasons, we will focus on qualitative test design later in this chapter.


Chapter 13: Testing Your Design

How many users is "enough"? The question "how many users is enough?" in a UX design team is like bringing up religious beliefs at a political rally - it's a hot topic. This is also an unavoidable problem because you need a framework as a starting point to plan your research. It has to do with the method you use: quantitative or qualitative. Briefly, here are the guidelines provided by Jakob Nielsen that seem to have the most consensus in the UX field: For quantitative testing, schedule more participants: 20 participants per study round (see http://www.useit.com/ alertbox/ quantitative_test.html). For qualitative testing, five to eight users per research group are usually sufficient. It is best to run multiple rounds of investigation to uncover issues that may be "hiding" under other issues or inadvertently introduce new designs (see http://www.useit.com/alertbox/20000319.html).

Planning Your Research When designing a usability test, several questions should be answered early on to ensure focus and scope. This can be provided as a document written and discussed with the project team and key stakeholders, often referred to as a user research plan. The drawing should show the method chosen above. Why are you taking a test? Write a clear statement outlining the objectives of the test, based on one or more objectives of the overall project. See Chapter 2 for examples of project goals and how they differ by project type. Who are you testing? After you've created a user model (see Chapters 6 and 7), you can use it as a basis for deciding which users to test. If you haven't already, meet with your project team and relevant stakeholders to prioritize your user groups. This information will be entered into your scanner (discussed in the Recruiting and Sourcing section). usability testing


Here you also choose the groups of users to represent and the number of users to include in each group. what are you testing The question of what are you testing consists of two related questions: What method will you use to present your website or app? What tasks do you plan to include? If you have an existing app that needs a redesign, you can run a full test on the current version first to identify important usability issues that need to be addressed. If you're working on a new project, you can use sketches or paper prototypes (for example, a set of printed wires) to represent new interface elements, such as pages. These low-fidelity user interface representations allow you to quickly create and discuss ideas in your project team and quickly reproduce them with participants (see Chapters 10 and 11 for more on sketches and mockups). When working on a new project that includes highly interactive elements, it's best to create a prototype that realistically simulates the design navigation flow, but can be built quickly before full development begins (see Chapter 12, Prototyping, for more information). The pages you include will be closely related to the tasks you choose. If you plan to use the prototype for user testing, you'll need to design a landing page for the task, as well as intermediate pages and alternate funnels. You probably don't need to detail each one, but you should design a response if the user goes in that direction. Sometimes it can be as simple as a page telling you that a certain route is not available and asking you to go back to the previous page and try again. Details of your tasks will be provided in the Discussion Guide (discussed below), but as the scope can vary greatly depending on the type of tasks you cover, it can be useful to make a list when planning.


Chapter 13: Testing Your Design

Dive In For more information on iterative design and testing with Sketch, and a truly inspiring insight into creativity in the design process, read Bill Buxton's Sketch User Experience: Designing Right and Designing Right (Morgan Kaufmann, 2007). For more information on paper prototyping techniques, see Paper Prototyping: The Fast 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: Design areas that violate certain established conventions. Who you are

Should we call it a "gift bag" instead of a "shopping cart"? It's worth checking if this is clear to users. An area where planning decisions are politically charged. you can have it

There is a strong belief that a particular design direction is the right one, but you know that there are many disagreements among stakeholders or other project team members. seeing is believing. Areas where usability issues can have serious consequences, such as scarcity

Sale or, at worst, loss of life (drug dosing applications are a good example). Next, you'll specify what information you want the user to collect when they try to complete each task. What information do you collect? We focus on qualitative usability testing, which typically has small sets of metrics. In most cases, you want to understand the problems your users may be having, the varying degrees of frustration they may be experiencing, and the severity of the particular issue. For example, there may be periodic issues (not experienced by all users) that result in the irretrievable loss of published articles. This should definitely be an important topic in your report!

usability testing


To gain insight into the users or test rounds you're testing with, consider collecting some data as part of your testing. Again, if you're running qualitative tests with fewer users, don't go overboard with the numbers (averaging doesn't make sense if you're only testing five users), but the following measures can help you understand what issues your users are experiencing. Success - the degree to which the user completed the task. If you're viewing users, you can also see the "success rate" - the number of users who successfully completed a task. It sounds simple, but it means you need to define what it means to be successful! For a less formal test, a task can be said to be successful if the user has reached an end state (for example, an editor has successfully approved an article). Success can be monitored more formally by noting the different levels of intervention required by the facilitator: Level 1 prompting: The test facilitator answers the participant's questions but does not provide further details. For example, a participant asks, "I think it's this button, should I click it?" Moderator replies: "Go ahead and try it." A level 1 tip in itself does not mean that the task failed, but it is a good idea to take some time to note, as participants may feel uncertain at this point. (Although if it's a first job, it might be because they're unfamiliar with usability testing.) If the user doesn't need prompts to complete the task, or only needs a level 1 prompt or two, you can consider this step successful - unless you think the user needs much more time than a user with a likely level of patience. Level 2 prompt: The test moderator sees that the participant is struggling and answers the question. This level does not involve an immediate response, but the response may have an impact on how the user handles it. For example, a moderator might say, "Is there anything else on this page that you think might be relevant to this task?" Number of level 2 clues that can be given before you "pass with difficulty".


Chapter 13: Testing Your Design

Level 3 Indication: The participant quit out of frustration or struggled to the point that they would likely quit if faced with a real-life task. In this case, the moderator will respond directly to part of the work, for example, "To approve this story, click submit." . User Satisfaction - Sure, it did the job successfully, but how does it look to you? It can be useful to add some follow-up questions after each task (outside of the timer) so you can get an idea of ​​how happy or frustrated the user is. If you meet someone who doesn't like to talk, this could be the main window into their soul. Table 13.1 shows some examples of post-questions you can include. Table 13.1: 13.1 Custom table

Satisfaction questions I strongly disagree

to disagree

I neither agree nor disagree


I agree very much

Shipments are taking longer than expected






the job is easy to do






I'm frustrated trying to complete this mission






User Satisfaction Questionnaires User Testimonials - This is not an indicator, but what users voluntarily provide is a basic set of details to collect. Adding user references to reports is an effective way to include the human factor in results so that stakeholders not only interpret the data but also understand the information that leads to information. During the test, you can mark statements as questions or comments, we will separate them in the report (see section "Generating information" later).

Recruitment and Logistics Now that you have your research plan and know how many participants you need for each group, it's time to set up your trials!

usability testing


Create a list When you create a survey proposal, you specify the types of users you want to include. You can use this outline as a contact point to create a list of potential participants. Ideally, you're looking for names, email addresses, and phone numbers. Here are some sources you can use to compile this list: Registered users of the relevant company's website Customer contact information Responses to research posts submitted to the relevant website or group

on your research topic. This can be broad, like posting on Craigslist, or targeted, like a newsgroup focused on your industry. Email friends about the test topic.

You want to ask them to forward the invitation to others who might be interested, because using subjects you know personally can skew the results. This type of word of mouth is a great way to find potential participants, but keep in mind that these applicants still need to be vetted. (If you or someone else on the team knows these people well, it's easy to overlook them.)

Advertising space on relevant website or company website

Temporary participants can be found. For sites that have a strong connection to an actual location, most of the testing and planning can be done on site. Third party recruitment companies who may also perform screens for you

and assist with formalities. This can be an expensive option, but if you are looking for a specific type of participant that is difficult to recruit or need to recruit multiple 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 provide guidance on how to encourage high participation rates.


Chapter 13: Testing Your Design

Get ready to get creative here. Use your empathic skills to think like your target users – where can you find them and what might motivate them to engage? The last question brings us to the next topic. Payout option What will motivate your user group members to participate in the survey? It may or may not be money, but participants want something of value for their time. If you're building a website for internal users, you'll need to prove its value to managers who need permission to use company time to participate in research. In this case, you can focus on how the best systems directly relate to his team's interests. If you are dealing with potential external users, here are some variables to consider when determining how to compensate: How general or specific is the audience? For a widely used e-commerce site where your audience is likely to be general, you can often offer a lower compensation percentage in the form of a check or gift card. For an app used by lawyers, your compensation should be of great value, and it's usually best to use something other than money as compensation (for example, to get a premium service). In these cases, the check can actually feel like an insult—someone charging $250 an hour is unlikely to come to a meeting for the money. If you are dealing with large clients, treat them as a specific audience and reward them well. What interest can this subject cause? Some participants will join because they want to see what's happening in the area you're testing. If it's an area of ​​high interest, you probably don't need to provide any additional compensation at all - the reward is access to something no one else is seeing yet. But be realistic: you may be passionate about the topic, but are your users? Will people get involved primarily because they want to contribute to a cause? Some groups will be motivated by an altruistic purpose and may be closed because they offer money to join. If you're trying something that improves your community (online or offline), you're likely to get more engagement—and happier participants—if the experience is about coming together, not

usability testing


From winning. In this case, you can show your appreciation by acknowledging it publicly and letting them know they can contribute by participating once the site is complete. How uncomfortable will it be to participate? Be prepared to offer higher compensation if participants must travel to your site. Fewer requirements are required if you participate in testing remotely from the comfort of your home or office. Of course time also plays a part in this equation and one would expect more compensation for 2 hours than for 30 minutes.

Possible Compensation Your situation may vary, but here are some things you can offer: $50, $80-$120 for a half hour general remote user test, $180 for an hour general field test - $250, three months free service after a one-hour trial with a specific group of users that you determine will respond well to monetary compensation, a free enterprise product (preferably one that is not yet available to everyone), exclusive membership to six monthly groups, and specific user groups for those less than impressed by the check , like lawyers, doctors and salespeople, again helps them to be creative and focus on their role. What will motivate your user base?

Screening Screeners are questionnaires you use with potential participants before you schedule them. This ensures that they fit your definition of a representative user. The questions are designed to ensure that respondents are current users of the tested functionality -

or a potential future user to determine whether it is appropriate for one or more user groups to help obtain a good mix of participants in that user group


Chapter 13: Testing Your Design

Exclude specific respondents who may have had experiences that may have biased them

Your Results Gather the most important information you need to know before your attendees arrive

(Optional) Your selector should include an introductory script that the recruiter can read over the phone, along with instructions on when to screen participants (if they're a good fit) or when to end the interview (if they're not a good fit ). The end user of the screener will be the person recruiting participants - potential participants if you used the online form for the screening. Either will work, but it's usually best to use a form or email to gather a list of interested parties and then screen them by phone. Why; Because, unfortunately, people are often more likely to misrepresent themselves on paper than to answer someone directly, and it's not uncommon even for people who don't qualify to try to take a survey. Especially when it comes to compensation! Your auditors should also weed out those with knowledge that could influence your results. For example, it is common to ask if a respondent works in market research because they may be very familiar with general research and therefore less likely to give you an honest answer. If you're concerned about sharing project information, you can also reject those who work for a competitor. Here are some examples of problems you might encounter with filters in your online B2B ordering application. In this case, we are targeting a user base who are used to consuming and shopping online and who can do it themselves. It should be noted that some questions are designed to screen participants, while others (such as question 4) are more geared towards placing qualified participants in the correct user group. 1. What age group do you belong to? [Over 18 years inclusive] a. Under 18 years of age


b. 18–24°C 25–34 days 35–44 45–54 floors 55 years and older

usability testing


2. How often do you use the Internet at home? A. under no circumstances


b. Less than once a month


C. Several times a month D. At least once a week e. Several times a week f. Once or several times a day 3. When was the last time you bought a product online? A. in the last month B. 1-3 months ago c. 3-6 months ago d. 6-12 months ago


e. More than 12 months ago


F. I have never made a personal purchase online


4. When was the last time you visited pseudocorporation.com? [group A is rarely or not used. group B is a frequent visitor]


A. I have never visited this site

control group A

b) Within the last month

control group B

C. 1-3 months ago

control group B

d. 3-6 months ago

control group B

e. 6-12 months ago

Check A or B

F 12 months ago

control group A

Chapter 13: Testing Your Design

You've been fired. Termination is a harsh word. This means that the interview should be terminated because the interviewee fails the test. You don't want the interviewer to feel bad about it, but you also don't want to waste her time asking follow-up questions when you know it's not a good fit. There are many ways to deal with this problem. The favorite solution is to simply say that the group he qualifies for is full and ask if you can contact him later if he is interested in other tests.

Space and equipment planning At this point, you know whether you will be testing remotely or in person and how much time each participant will need. Here are some other decisions you need to make: Where will you test: in a rented space with an observation room, in a conference room on the company premises, or where potential users will be present? Plan a quiet place that will comfortably fit two or three people and the computer configuration you will be testing. What staff other than moderators do you need: for example, you can save time and increase accuracy by recording information during the test. Other capabilities include greeters (who greet participants as they enter, distribute questionnaires while they wait, and escort participants to and from the testing room) and people who provide IT support in case of problems during the test. How to record your test: There are several methods you can use, but software like TechSmith's Morae and Camtasia Studio make it easy to record your screen, and Morae has the added benefit of embedding video and audio from a webcam.

Writing a Discussion Guide Finally, you need to gather the materials needed for the test itself. State your general duties in the research proposal. now you need the right text and instructions to complete your tasks. There are at least two packets here - one for the test host and one for the participants (with enough copies for each test to contain one).

usability testing


Start with an introductory script that the facilitator can read to the participants. There are many good examples 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 websites that are accessible to a wide audience. It includes an excellent set of reference materials to assist in user-centred design, including a sample video consent form (in Microsoft Word format) for participants to sign prior to registration: http://www.usability. gov/templates/docs/release.doc

Your instructions should include all the details participants need to successfully complete the test task. If your tasks require a lot of data entry and personalization, set up information in advance and provide participants with predefined data to use. For example, if connections are involved, all participants can use the same set of connections. Make sure your shipping statement includes all of this information clearly so it can be completed easily. Here's an example of how content editing tasks can be made more specific in the discussion guide. The initial task in the program was "find article to edit". In the Discussion Guide, it looks 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 an article is approved, it will be published in the news area of ​​the site. You and three other editors will approve the elements to make sure they fit the company's message. You have received the following login credentials for the editor: Username: grobertson Password: come2gether


Chapter 13: Testing Your Design

Read each task aloud, then use the editing tool to complete it. Task 1 Log in to the tool and open the article for editing.

As you can see above, we made some changes to the quest to end with a specific end state - article open. This adjustment will be common as you go to this level of detail and consider how to measure success. After each task, you can also ask user satisfaction questions, discussed in the planning section. In general, it's best to assign each task its own page so users don't want to move on. In summary, your test material should include the following:

more information on the page) Discussion guide for moderator, with introductory script Discussion guide for participants, with detailed tasks and user satisfaction

Questions A way to take notes if you have someone in charge. This is acceptable

From recording tools built into the testing software, to spreadsheets for entering answers and print templates to review key information such as questions required. Taking a little extra time to set it up before testing will ensure consistent results and save a lot of time reviewing recordings. Optional research. Sometimes attendees come early and have

Wait a moment - this is a great opportunity to collect additional information. If you've designed a survey before, why not reuse it here? Compensation method to be communicated to participants at the end

Proof (money in an envelope, commonly accepted gift cards such as Visa gift cards, etc.). If you have chosen a compensation, such as a free service where nothing will be given after the test, assure the participants that they will be visited no later than the next day. You can also use these materials if you make paper prototypes during testing. Before starting your first test, make sure you have a handy kit ready.

usability testing


The facilitator's job is to introduce the participants to the process, answer their initial questions, and then gather potential insights while trying to make the participants behave as naturally as possible. Make sure you ask your users to think out loud during the test, as if they were talking to each other (if they start working silently, gently remind them to do so). The "Think Out Loud" technique allows you to gain the best insight into user behavior. You will learn a lot about their problem-solving and thought processes if you hear about them during the task itself, rather than asking participants to recreate it later when their memories may not be as accurate. Also, be careful not to give participants the 'correct' answer too quickly! One of the hardest parts of conducting usability testing is watching carefully selected participants struggle with a task and then letting them struggle. After all, you probably got into this field because you're an empath. You want to help others. So watching someone get increasingly frustrated when they come to you for help and then reply, "What if you tried it yourself?" it can seem a bit sadistic. Whenever a participant asks you a question during your work, pause for a few moments before answering. Test takers are very likely to ask questions at the beginning of the test, especially if they are embarrassed that you are sitting next to them. Once they understand that you are there to observe and not talk, they will usually start focusing on the mission instead of your presence. Here are some examples of participant questions and suggested responses: Participant: "This looks like it might be a bookmark, should I go here?" Mediator:

"Keep trying."

Participant: "Should I go here?" Mediator:

"Is that what you thought you were going to do at this point?"

Contestant: "Is this the way to submit a comment?" Mediator:

Quiet. He smiled at the participant with a friendly and relaxed expression, then looked expectantly at his screen.

So when to step in?


Chapter 13: Testing Your Design

If the user has put in more effort than you think they actually did when working alone and you think you understand why they went down the wrong path, it's time to move on - especially when you're passing, when you have more work to do and don't want to view the his frustrations in 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 like you're getting too close to the project and criticism can make you defensive, consider instructing others to help you take notes.

Analysis and presentation of results You have done all the tests and now you have a lot of data to process. But there are some key findings that you already consider important and your design team is very interested in how it went. You can schedule an informal oral discussion with your team, outlining your top priorities. It can help you express some of the trends you've noticed and set the stage for future reporting. Be sure to convey that these are first impressions and you will need time to analyze the data in more detail. You don't necessarily want to go here to make suggestions until you have the full picture of what might be wrong. Once you find the time to sit down and analyze your data, consider the following: time spent analyzing. It's easy to get lost in the details and try to cover everything. As always, track your tests and goals as you discover key findings. If you have ten hours to record a test and five days to write a full report, you probably don't want to waste time watching videos of each test. Rely on your notebook and then go back and watch the video, mostly to make sure the key passages you remember are spelled correctly. How your results will be used. This is an important detail that is often overlooked. You may have created a beautiful 20-page report, but only one page of it can make a big difference: the executive summary.

usability testing


If 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 creating a presentation version of the report that highlights key findings in a more visible, understandable, and prioritized way. Those interested in details are referred to the full report. Prioritize Issues By the end of testing, you may have a long list of usability issues to understand and prioritize. Here are some characteristics that can help you determine the severity of an error: Consequences. Negative outcome of problem solving. For example, if a participant lost data due to usability issues, they may receive a high score. Let's say she spends ten minutes filling out a complicated form and accidentally clicks a link that takes her to another page. If she clicks the browser's back button, will her data disappear? recoverability The extent to which the participant can recover from a problem - for example, can he easily return via an alternative route? frequency of occurrence. As long as you don't work with many people, this in itself is not a sign of seriousness. But if five people made the same mistake and it led them down a less-than-ideal path, that's a good sign and you should consider making it a higher priority. logical reasons. If a question doesn't come up very often, but is asked by someone in your user group and they're asking it for a good reason, and there's a clear reason why it's wrong, then you should take that into account when making a suggestion. Generating Information In addition to the questions you collect, you will have many user-generated statements that can provide your project team with valuable information. As discussed in Chapter 6, the affinity diagram is a great way to combine these statements and work together to identify patterns.


Chapter 13: Testing Your Design

Here are some ways to categorize what users say (see "Context Questions" in Chapter 6 for more details): Goals Mental models Ideas and feature requests Frustration Alternatives Value claims Delight (don't skip these) - you don't want to miss the good ones things!) Expectations (especially when they are not met)

Among the observations and recommendations, remember to include positive findings. Usability test reports are often viewed as very negative, mainly because researchers prioritize discussing things that need to be fixed rather than things that are going well. Taking the time to discuss the good stuff will improve the overall reporting experience. It also helps the design team buy into the outcome and get excited about improving the design.

Making suggestions Even before you start the analysis, you probably already have some good ideas in your head to solve the problems you encountered during the test. Outline questions and ideas as you identify them so they don't get lost. Just be careful that one idea doesn't take over too soon and cloud your view of other possible solutions to more problems. A good proposal should address as many issues as possible. You can group questions

Depending on how detailed and specific your problem description is, put them into a longer sentence. Practical and simple - avoid premature detailed design.

usability testing


Use direct but not condescending language. undertake

Criticism is a difficult thing, especially for those directly involved in test design. Don't underestimate the problem, but remember that your words should come across as constructive and respectful. Please note that proposals must target end users such as systems. When you've finished your report, go back and ask yourself whether you've achieved your original goals and how best to share your results with the various people who will use them: stakeholders, designers, and developers. Speaking of developers, it's time to bring them back to the fore. In the next chapter, we'll cover things to keep in mind as you move from design to development and beyond.


Chapter 13: Testing Your Design


Transition: from design to development and beyond Where are we going? The defining and planning phase of the project has come to an end. what to do? A good UX design process never ends. After going through so much defining and planning, how do you stay involved to ensure the end result of the project is the user experience you designed - where are you going? Lars Unger


This is the end of the book………. This is the last chapter. However, this is not the end of the UX design process, contrary to appearances. After all the previous phases of the project are completed, you may think that your work is done and you have nothing more to contribute. In many cases, UX design work ends up somewhere in someone's project plan, and after you deliver the product to the rest of the team, you're always transferred to another project. Time to close that door and start something new, right? Big mistake! There's still a lot you can do to ensure the best possible user experience.

Visual design, development, and quality assurance In some cases, work seamlessly with design or development teams receiving project-based work products. From time to time, downstream partners need answers to questions, information and help with certain project concepts they are working on. (It might even sound like a prototype!) In those work environments where UX design is already accepted, the team may have had the foresight to give you time to complete these consulting tasks. However, roles like UX Designer, Information Architect, Interaction Designer, etc. they are still very new to many organizations. How to manage these roles may not be clear, and deciding how to get involved may come down to someone who doesn't fully understand UX design. You may need to find ways to stay engaged.


Chapter 14: Transition: From Design to Development and Beyond

Here are some suggestions: 1. Buy them a copy of this book. 2. Don't be shy. 3. Read the rest of this chapter looking for opportunities to get involved and make a difference. 4. Ask for a commitment and be prepared to defend your request. In other cases, you may find that the visual design or development team is the king of the company and its projects, and it can be difficult to stay engaged. You may find yourself trying to knock down walls just so you can inspect the work and ensure compliance. This doesn't always happen, but it does happen. Christopher Fahey, co-founder of Behavior (www.behaviordesign.com), is no stranger to overcoming this challenge. He gives this advice: some organizations are strictly divided. To continue to be involved in the development of the project beyond the initial design phase, you must be proactive and insist on feedback and corrections to the visual design and development teams. They usually don't want to invite you there at all. This is best done at the planning and budgeting stage of the project. If not, you may need to volunteer your services to make sure the project doesn't degenerate during later development. One trick is to simply ask to join the QA team, even if unofficially (assuming you have - if not, be sure to ask the visual designers and developers!) and get access and passwords to any development sites and a debugger. You can then add your criticisms and deviations to the same bugfix queue that developers go through every day.

Of course, many projects will not have a QA team. In an ideal world, every project would have such a team, but in practice QA is not always available. Sometimes developers do their own QA during development. Besides making you cringe, knowing this will make you work harder with developers.

Visual design, development and quality assurance


The Art of Negotiation The art of negotiation can become an important aspect of your role as a UX designer. Downstream collaborators, such as visual designers and developers, can change your work at will without realizing how it affects key elements of the user experience. If someone tells you that you "can't" do something, you need to be prepared to come up with a plan B. Good negotiation skills will help you defend your design decisions (this should be based on the research you've already done ) and convince others that UX can be done. Alternatively, these skills will help you work with partners to create a satisfying Plan B that best meets everyone's needs. For more information on negotiation, see "Agreement: Negotiating No-Bowling Agreements" by Roger Fisher, William L. Ury, and Bruce Patton (Penguin, 1991) and Dave Gray (XPLANE Corp., 2003).

This is especially true in many small businesses: quality control is a luxury. According to Troy Lucht, director and chief development officer at Ascend Realty Solutions (www.ascendrealtysolutions.com), QA "is done by everyone, especially developers." Everyone is trying—and wanting—to get involved, but without the resources to write test scripts, it's impossible to tell people what to test when development is often done at the last minute. In many cases, our in-house designer is someone who knows the app as well as I do, so they can provide more thoughtful feedback. Adding a UX designer to the mix really did the trick for our small team.

Although your UX design product may not include a test script, in some cases you may want to test the wireframes and annotations you create to ensure that all elements are included and that all defined CTA phrases work properly. It's not perfect, but it's a useful approach when there's no quality control. The bottom line is that UX design doesn't end just because you deliver a working product and impart knowledge. Your role may temporarily take on a more advisory nature, but you're not done.


Chapter 14: Transition: From Design to Development and Beyond

Design testing with users (again) We don't do user testing anymore? I hope the answer to this question is yes, but that's not always the case. Unfortunately, this particular testing step, which is designed to test the final designed and developed website with real users before it goes live, also does not. This allows you to take one last look at your site and find last-minute bugs and errors that you may have missed during QA testing. Once you've identified your target audience, you can test your site for any scenarios that seem high-risk or that may have caused problems in previous iterations of your site. This round of testing provides the necessary information to determine if your site is ready to go live. 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... Go! “If you build it, they will come. …” This theory has been put forward many times, but it has been dismissed almost as often. You can build the most beautiful, satisfying, useful app, show it to the world, and two months later find out that almost no one has adopted it. What gives? User adoption is the extent to which the target user base ends up using a website or application. You can avoid some adoption issues by following good SEO practices (Chapter 8) to ensure that users can find your new site. User adoption also means that good UX design doesn't stop at the end of the project - or that it's limited to the project you're working on. You can help your marketing, customer service, PR, and education teams ensure a smooth implementation and a user base that is excited about your site or project by helping them address three factors that often affect user adoption: Personal strengths

10, 9, 8, 7, 6, 5, 4, 3, 2, 1... Go!


Network feedback support

Let's take a closer look at each in turn.

One of the most important questions a personal features user must answer is "What's in it for me?" No matter how great your site may be, if you can't quickly explain it to a certain type of user (or one of the people identified a) Unique benefits you may struggle to attract users. Some of the benefits are immediate: "Using this camera feature, you can post photos to your online account with the click of a button." Some are indirect: "Using this schedule tool, companies can more easily track how much time they spend on each project." You've spent valuable time getting insights about your users. now use this information to help marketers perfect their message.

Support When your users need help with your site, how do they get it? Answering this question involves training and customer support, in addition to the contextual help that good UX design work tries to provide. Do you think your users respond better to face-to-face training than online training? Are some of your users skipping training and expecting everything they need from the website itself? Is live chat an important option for your users to get customer support, or will they be happy with phone and email support? Support is hard and knowing your users can help your customer service and training departments effectively.


Chapter 14: Transition: From Design to Development and Beyond

Internet Shared Opinion Word of mouth is the most important influencer. What is the reputation of your client's company and its current website among its target user base? Even if the answer here is yes, it doesn't mean no effort is required - maintenance is always important when it comes to reputation. Don't use a positive response as an excuse to move on to the next section: Maintenance doesn't have to be a huge effort, but the effort required to recover a plummeting reputation can be staggering. A little TLC can go a long way, so keep reading. If the answer is no, serious efforts must be made to improve perception. You may need to reach out to your community of users and find out who the influencers are, how they like to communicate and how they influence their audience – and then engage them. There are many ways to attract users and influence customer, company and website perception through social networks. Help your clients identify opportunities to participate in these communities and try to steer them in a positive direction. If all three of these factors are present and you're still seeing low usage, consider how and what your competitors are doing to keep users happy. How to make a product or website stand out?

Post-launch activities We live in interesting times: so many companies are putting themselves or their products into 'beta' status. Going beta usually means that real, unfiltered users are the audience for live testing websites to help spot bugs, errors, or other issues. At one time, betas were usually only available to developers, but now it's common practice to open up betas to the entire user community. During the testing phase, communication methods should be set up to record and report any problems users may encounter. Any type of system failure that occurs must be documented and delivered to the project

actions after launch


club. There must also be a mechanism by which users can report problems they encounter to the appropriate member of the project team. If this communication doesn't happen - and UX designers, visual designers and developers don't know what's going on during the often rigorous and rapid testing phase - the site can be updated and re-released to users without having to implement most strategies .

Post-launch analysis Once your website is live, the first thing you should do is start collecting data about how your website is being used. Your website logs are the best source. Unfortunately, a UX designer may not be the first choice to receive or review this information, so find out who hosts the site and use your negotiating skills. Web analytics can give you information about your website visitors. Among other things, you can find out who are new visitors to the site and who are returning visitors to the site. Page views. Page display time. Page depth where users left the site (which pages). Session duration. Ad impressions.

This information can help you understand where users are having problems by identifying problem areas on your site. While analytics may seem dry and full of numbers, data and insights will help you ask the right questions when doing post-launch testing. NOTE For more information on web analytics, start with Avinash Kaushik's Web Analytics: An Hour a Day (Sybex, 2007).


Chapter 14: Transition: From Design to Development and Beyond

Post-user design testing (again, again) After you've collected your site's analytics data and gathered input from customer support or other departments that interact with users, you're ready to start creating a list of questions for the next user design test round. In other words, use the collected data to create a new set of questions for your site visitors and use the skills you learned in Chapter 13. One of the benefits of this round of testing is that you have the opportunity to test the same users you they had worked together in the past to determine whether their opinions changed after the site was launched and they used it more often. This can be very useful: if you test the same group of users (or part of them) again, you can re-ask some of the initial questions (comments on functions, ability to perform certain tasks, etc.) and analyze the answers over time . This potential difference can help you identify new areas for improvement on your site and understand user learning curves from previous rounds. As an added bonus, analyzing the differences in responses can also help you identify new questions that you may not have considered before.

Everything is ready, right? NO.

It's like starting from scratch... by collecting analytics data and using survey data to run design tests, you can start building a list of tweaks and improvements that will benefit your site. Once you've gathered them all together, you can create a new proposal (Chapter 3) based on your suggestions. This proposal can lead you to an entirely new project, which can lead you to define a new set of project goals (Chapter 4) and business requirements (Chapter 5). You can

It's like starting over...


Then move on to additional research (Chapter 6), creating personas for new defined purposes (Chapter 7), improving SEO (Chapter 8), updating or creating new sitemaps and workflows (Chapter 10), updating or creating new templates, and annotations (Chapter 6)Chapter 11), doing more rounds of prototyping (Chapter 12) and more user design testing (Chapter 13)… you get the point. Projects must not die. They should be a springboard for new projects aimed at continuously improving UX design.


Chapter 14: Transition: From Design to Development and Beyond

Absolute indexing paths, used in HTML prototypes 213 Validated and signed, included in proposals 53-54 ACSI (American Customer Satisfaction Index) 103 Actions, plans 162-164 Adaptive paths for used pencil and paper 189-190 Additional costs and sites included 168 in application 50 Adobe Acrobat PDF prototyping tool, 214-215 Adobe Illustrator website functionality 167 Adobe InDesign website 167 Attorney, Priority 150-151, 154 Relevance diagram applied to feature conflict 160-161 Steps Test feature Ag24 in us 99- 65 Website AIGA 63–64 Resources 51 Ajax, Questions 132 Interactive Website Alignment 217 Alternative Features, Using 139 American Customer Satisfaction Index (ACSI) 103 Analytics Tool Ease of Use 24,254 Analytics Tool Benefits 24,254 Benefits of Optimized Website 891 817 and of Annomes19 186–187, 193 -194, 201 Aquent Talent Agency website 51 Arrows and Connectors, Defined 170 Ascend Reality Solutions website 250 Ash, Tim 16 Ashton, Jonathan 143 Ask.com, Search 128 cases contained in propositions 47–48

Compare Features 90 Axure RP Prototyping Tool Prioritization and Feature Definition 215 Sites 167


B Babyhold site 118 BabyNames site 118 Balance, applying to UX design 6-7 Balsamiq Mockups prototyping tool, features 216 Whips, Steve 12, 95 Behavior site 249 beta, definition 253-254 billing charge, definition 513 black hat- white hats 141– 142 Blog features, sitemaps 166, 191 Blue Flavor sites 167 CSS sitemaps 167 Body language, focus group explained 106 Bots, explained 129 Brand sites 11 of 13 features described Example 13-14 12-13 The Stratealist / Steward, 26- 27 Role of Brooks, Mark 200-201 Building Ownership, Systems 183 Buley, Leah 189-190, 201 Business Concerns 154 Development and User Advocacy 155 Role of Business Intelligence 27-2833 Wising See also Explanation of requirements gathering 68-69 Integration 82- 84 Heuristic analysis 70-73 Meeting scheduling 78-79



Business Requirements (continued) Creating Worksheet 153 Definition 68 Example 83 Pooling Responsibilities 75-76 Pooling Stakeholders 76-77 World Cruises Home Page 195-196 Develop Succession of Support 157 Listening to Ideas 8113 Negotiating 81415 Locating Essential Meetings 80 –81 Wireframes 189 Business stakeholders , 75 Buxton, Bill 231 definition

Calendar Tool C, 217 functional prototypes, 219 events. View Campaign Site Closed Stock Card Sort 110 Interpret 93 Batch Sort 110 Review 107-108 Run 109 Process Test Run 108-110 Provide Instructions 109 Remote Sort 110 Clients Via 188 Pre-Sort231-Client Review121 138 Unintended 133 Collage, Use Cases in Microfinance 223 –224 Communication, Importance of Prioritization 160 Companies Use SWOT Analysis 61–62 Competitors Comparison 61 Corporate Culture Hierarchy 36–37 History 34–35 Logistics 37



Trade-off, Identifying user groups 235, Competitors 241, Comparing 61 Concept exploration. See also 222-224 Examples of potential pitfalls in visual designs 222 Targets 221 conditions, 170 Defined conflicts, 158-162 Managing connections when prioritizing, Messy dashes and arrows 171, 170 Defined consensus conflict, Managing 160 priorities, 160 prioritization, consumer 139 Optimum content practices 135-136 The importance of freshness 138 Content creators, 188 Content management systems using skeletons, 133-134 Reviewing the content matrix, applying a numbering system to 173 Content source Objects11111 site description 17 Using Business Analyst 28 Using card sort 108 Content Strategist , Role 28-29 Cotextual Design, 101 Explaining Resources for Contextual Queries 92 Using relevance diagrams in 98 processes 98-99 in 98-99 in 99-101 Contextual website ag and Fees (extra) included in offers 50 Robot capabilities 131 Detecting successful impersonation 132 Explanation 129 Creative Commons 50 website

D The dotted line, representing conditions with 170 decision points, defined 169 defining and planning phases, overlapping 145 outcomes, contained in sentences 48-49. See also Product Design Goals for Brand Display Sites 13 Content Source Sites 17 E-Commerce Sites 19 E-Learning Apps 20 Campaign Sites 15-16 Settings 10 Social Apps 21 Task-Based Apps 18-19 Missing Pages Design Errors 173-17 Aligned Objects 172 Poor text placement 172-173 Messy links 171 Unequal spacing between objects 172 Design, improvement 227 Developer from 217 Using mockup for prototyping 188 Business development advocates and advocates for communication 515 Goals and responsibilities 157 Inheritance requirements 157-158 Participating in 158 includes 156 development teams, providing feedback on 249 digital assets, optimizing 138 digital experiences, designing 5-6 digital prototypes. See also Prototype audience 208 HTML and WYSIWYG editors 209-214 209 Timeline resources 208 Wireframes and real-life prototypes 207-209 Online magazine digital pages 167

Directory structure, 134 Discuss importance of guidelines, writing usability tests 239-241 documentation, scheduling 162-164 domains including 134 keywords on door pages, 142 point review, use in affinity diagrams, Preview 1694 Dreamweaver 1694 Duplication , Dynamic URL Prevention 138, Avoidance 133 in Content Management Systems

E-commerce website, 19 design goals for an educational site, 15 examples of e-learning applications, 20 emotional and logical design goals 7 Integrating parts of the PURITE process 46 Devices, usability testing plan 239 Evans, Will 122, 123, 181, 197 -201 Experience , tangible and numerical 4–5

F Fahey, Christopher 249 Favreau, Jean Marc 40 Feature capture and visualization 146–147 Conflict management related to 160–162 Feedback mechanisms, 219 Charges and costs (additional) Prototypes including proposal 50 Finck, Nick 167 Fireworks 2 Prototypes CS5 216 features of Flash, 130-132 features of Flash and Flash Catalyst prototyping tools, 216 features of Flash content, static level embedding 131 focus group discussion format 105-106 explaining 93 explaining body language in 106 107 process 105-107 example microfinance 22 use footnote 104-105 template 196



Footer links, link popularity from 140 front-end developers, role of 31 funding models, used in microfinance 222

G Garrett, Jesse James 168 Global Cruises, 195–201 Designing a Homepage for Google Analytics 24 The PageRank System 139 Quality Guidelines for Webmasters 142 Searching Through 128 Grids, Use in Apps 172 Formatting Group Discussions in Interprelain6 Bo 105–1016 moderation 107 process 105 -107 use in microfinance example 223 use 104-105

H Hadden, Jon 217–219 Header/Navigation, Design 195 Header Meta Tags, Allow 137 Gathering Heuristic Analysis Benefits Requirements 73 Overview 70–71 72–73 Rationale for 71 Hierarchy Steps Affecting Design 3, Andre71 Corporate 36 Homepage Design 192 Designing for World Cruises 195–201 Wireframe Design for 197–200 194 HTML Prototype Example 212 Link Popularity 140 HTML Prototype Parsing Code 213–214 Spelling 210– Creates 21



I Ideas, merging 82-84 Creating ideas and visualizing 145-147 Illustrator website 167 Image maps, using 213 image tags in HTML prototypes, using 213 InDesign website 167 Separate index pages 137-138 Website indexing 131 infinance content management systems 133–134 Information , search 17 Information architect Balance with other roles 248–249 Roles 22–23, 25 Information Architecture Institute website 51, 167 Guidelines, full usability testing 239–241 Interaction designer Balance with other roles –2 role 298 23, 25 interviews. View user interviews iStockphoto website 117 Iterative modules of the PURITE process 46 Iterations, Wireframes as an exercise in 201 Iterative Design, 231 Resources for Iterative Testing, Working with Prototypes 217

J JavaScript, jQuery Web Problemy 214


K Keynote Prototyping Tool, 214 Keynote Features Included in Sitemaps 175 Keyword Research Tools, 135 Footnote Searches Accessibility, 135 Keynote Behaviors Included in Domains 134 Naming Conventions, 136 Using in URL Structures 213515

L Homepage, post-launch analysis 254 left navigation links, legendaries prototypes 217-218 including sitemap 175

Projects function, definition 49-50 anchor link text meta tags, interpretation 137 Link popularity distribution 139-140 Interpretation 139 Footer links 140 Cross-links in content 141 Handling 143 SPAMMING 143 User registrations, generation 234-235 Live Preview, Consum 209 Logic and emotions in Dreamweaver CS4 7 Logistics, impact on corporate projects 37 Logistics - usability testing steps 233-239 Lucht, Troy 250

M Marketing Campaign site describes 11 examples 14 attributes for 14 goals in 15-16 markets and relationships 26-27 Melzer, James 182 Messagefirst Persona case study 115 Website 219 Description explanation meta tags 137 Explanation keyword meta tags 136-13 , 136-137 Accessibility of the method, 62 Significance of Micro-Funding, Definition 222 Microsite, Definition 15 Website Microsoft PowerPoint 167 Microsoft Visio Website 167 Page Number Errors 173 -174 Objects 172 Inappropriate Text 172-171 link 171 modified methods, performing 64-65 moves, commenting 170 MSN, searches made by 128

N names, role delivery 118 negotiation, art 250 online opinion, impact on user adoption 253 Nicolle roles, description 115–116 Nielsen, Jakob 71 nofollow link attribute, meta tag usage 140 noindex, explanation 137

O Purpose Application of SWOT analysis 61-62 Fuzzy vs. Solid 58-60 Relevance 57-58 Input from UX Designer 60-62 Measurement 58, 60 Correct merging of objects 171 Grid count 172 Misalignment 172 Uneven spacing 172 Observe, enable heuristic analysis functionality 721 website 72-ff2 Ice website Draw 167 Website OptimalSort 109 Overview included in offers 44-45 Ownership and rights included in offers 49-50

P page numbering, no title meta tag for pages 173-174, explanation of PageRank system 136, explanation of pages 139-140. See also site cloning 142-143 definition 168 separate index 137-138 page stack, definition 169 paper and pencil, for wires 189-190, 201 "paper culture", understanding 37



Paper prototyping 206-207 HTML example 217-218 Passive observation as a navigation concept 209 218 Passive observation, definition 99 Pieces, recognition in workflow 180 Payment schedule, including proposal 52-53 Pencil and paper, for mockups 189 -010 118 Age 119 Case Study 115 Definition 113 Education Level 120 Customer Entry or Trigger Point 120 Information Retrieval 114 Information in 116 Location 119 Maximizing Use 125 Mobility Comfort 121 Incentive Design or Triggering Customer Triggers 112 ities 120 Online Activities 120 Overview Main Form 122 Personal Proposal 12 0 Photos 117 -118 Rationale 113-114 Salary or Compensation Range 120 Social Comfort 121 Target Audience 123 Target Audience 124 Target Audience Individual 124 Technical User Source13 Types1211 Character Acquisition 117 sticky notes glue for affinity maps 161 Design test after publication 25 5. See also test. usability testing stages of power, defining characteristics of, 36 PowerPoint Prototyping Tool, 214;



PowerPoint page 167 PR (PageRank) explanation 139-140 Preparing the PURITE process 45 Pricing, project structure 51-52 Prioritization process used in usability testing 244-245 Facilitating role balance 154 150-154 Communicating with 160 processes 6 Materials management1 181-182 product examples, success 5. See also Results Agile design methodology 63-64 Importance 66 Included in recommendations 45-47 Modifications 64-65 62-63 Waterfall 63 Project direction steps, lack of consistency in 160 Project management, used in 188 Project goals Wireframes Using SWOT analysis 61-62 Ambiguity and unity 58-60 Importance of UX designer input 57-58 Pairs 60-62 Measurement 58, 60 Design review included in bids 44-45 Design bid included in bids 51-5 requirements steps involved 69 Sponsor project, 75 Project teams defined, 75 Project conditions defined, 80 Project best practice chart 191 Impact of company history 34-35 Process 181-182 Confirmation and approval of proposal elements 53-54 Additional costs and charges 50 Assumptions 47 -48 Results 48-49 Title and Rights 49-50 Payment Schedule 52-53

Project Methodology 45-47 Project Overview 44-45 Project Pricing 51-52 Change History 44 Workspace 47 Task List 54-55 Title Page 42-43 Proposal, Importance 40-41 Importance of Prototype 219 Using the Calendar 219 Changing Wireframes and 210 Completion 219 Creating with a WYSIWYG editor 209-214 217-219 Examples as a feedback mechanism 219 Goals 219 Iterative testing 217 Downloading by developers 217 Wireframes7-29. See also Digital Prototyping Best Practices 205-206 Overview 205 Documents 206-207 Adobe Acrobat PDF Prototyping Tools 214-215 Oxure RP 215 Balsamiq Mockups 216 Fireworks CS4 215-216m Catalystle 215-216 Flash 215-216 PowerPoint 214 Visio 215 Pure 45–46 process

Q Qualitative research, applied to usability testing 227-229 Qualitative usability testing, gathering information 231-232 quality assurance documentation, using a numbering system 174 QA team exchange 250 Participation 249

Quality assurance, 188 quantitative mockups applied to usability testing 227-229 questionnaires, including 241 discussion guide questions. See also Campaign Planning Filters 162–164 User Group Offset 235–236 Documentation Design 162–164 Focus Groups 105 Storyboards 148 surveys 102 Usability Testing 242 User Interviews 97 User Satisfaction 233

R Random name generator website 118 Recommendations, Usability testing 245–246 Usability testing recruitment steps 233–239 Redirect, setting 135 relative paths, using in HTML prototypes 213 Performance part of the PURITE process PURITE Reatheringor Definition 46 also Business requirements process, motivation 74 Research, usability testing plan 229–233 Research technique Card sorting 93, 107–110 Context question 92, 98–101 Focus group 93, 104–107 Roles 121 Research 92, 101–104 Testing 104 U. –111 User interviews 92, 95– 97 Resources. See also website resource relevance diagram 161 Agile methods 65 Analytics 254 Body language 106 Contextual design 101 Google 128 HTML (Hypertext Markup Language) 214



Resources (continued) Iterative design 231 Negotiation 250 Prototyping methods 217 Social networking applications 20 Tools 167 Usability testing 231 Responsibilities, review 75-76 Change history including proposals 44 Balancing roles in the prioritization process and management 154-65

S Sample size, 227 workspaces, including 47 in-app filters, were set for usability testing 236-239. See also Questions Script Navigation, Questions 132-133 Search Behavior, Understanding 135 Beginner's Guide to Search Engine Optimization 129 Search Engines, 129 Evolution of Search Results, Impact on 142 Searches Monthly, Statistics for 128 Section Titles, 1371 Titles Allowed, SEO (Search Engine Optimization) 127 Impact on UX 134 Importance 127–128 Resources for 129 SEO methods, White Hat vs. Black Hat 141–142 SEO experts, up to 188 Sign and validate use of skeletons included in offer 53–54 Site analytics, Tools 24 Advanced sitemap example 175–176 Blog functions 166, 191 Pattern breaking 177 Defined 166



Ignoring the numbering structure in 173 A simple example 174 with a workflow 166 using 138 using a tab sort 108 using a workflow with 178 location types, specifying 11 locations. See also index page 131 Writing text in a 29-30 hexadecimal template using a social networking application as described on the website 190 Slingthought 217 20 Social Security Administration 20 Design goals for popular baby names 118 Software Usability Measurement Checklist (SUMI) 103 SOW (Scope , Content 54-55 Space, design Usability testing 239 Keyword spam 142 Spencer, Donna 17, 109 spider, explanation 129 Spool, Jared 125 SRA International Inc website 182 Defining Stakeholders 75 Collection 76-77 Listening 81 Static Levels, Embedding Flash Content in 131 Affinity Diagram Sticker Points 161 Stock.XCHNG Site 117 Storyboard, Process 147-150 Software Testing147-150 WeaknessMISUAs list) ) 103 Build Network Support 32-33. See also UX Design Role Research Explained 92 Overview 101 Process 102-104 User Interviews 102

SWFobject, using SWOT analysis example of track 131, 182-184, implemented for project purposes 61-62

Tag T. See meta tag target users description 113. See also User workflow Apply numbering system 173 Create 178 Example 178-180 Overview 166 Process 181-182 with sitemap 166 Swim routes 182-184 Using sitemap 178 Site application description -based Features 18-19 and goals, using business analysts 28 Tatum, Keith 217-218 Taylor, Dave 214 technical construction, builders 31 standards, use of mock-ups 190 tension, balance between supporters 154-162 conclusion, use of usability testing 23 Resources, Registration Usability Testing 241 Testing the PURITE Process Part 46 Testing, Usability and User Acceptance 226. See also Post-Publication Design Testing. Usability testing stages Text completion for usability testing 239-241 172-173 Poor site layout 29-30 Covers including suggestion tags 42-43 Usage 213 Tools in HTML prototypes, Accessibility 167-168

U Purpose of UAT (User Acceptance Testing), 226 Understanding the PURITE Process, Part 45

URL Paths to Avoid in Content Management Systems 133 URL Structures to Avoid in Content Management Systems 134 Using Keywords in Usability Testing 227-228 Explanation 93 110-111 Usability Testing Stages 236-239 Overview. See also Post-launch trial design, trial analysis and results presentation 243-245 Method selection 227-228 Recommendation creation 245-246 Evaluation 250 Facilitation 242-243 Study design 229-233 Recruitment and logistics 233-239 Discussions W239 Gov User Behavior, get 227 User Experience (UX) Context. See UX (User Experience) User Group Definition 87 Feature List 87-89 UI Engineering Website 125 User Interview Interpretation 92 Interview Techniques 97 95-96 and Research Process 102



Μοντέλα Χρηστών, Σχεδιασμός Από 91 Ερευνητικές Δραστηριότητες Χρηστών 93–94 Συμπέρασμα 111 Σχεδιασμός 94 Βήματα Εκτέλεσης 86 Τεχνικές 92 Σχεδιασμός Έρευνας Χρήστη, Ανάπτυξη 229–233 Ερευνητής Χρηστών, Ρόλοι στον Καθορισμό της Ικανοποίησης Χρηστών 23–25 233 Μέτρηση Class10 Εργαλεία μέτρησης Δοκιμή 245 Βαθμολογήστε 233 Επιτυχία χρήστη, προσδιορίστε 232-233 χρήστες. Δείτε επίσης Επιλογή χρήστη-στόχου Αριθμός δοκιμών χρηστικότητας 229 Τύποι αναγνώρισης 88–89 Χρήση καλωδίων 188 UX (Εμπειρία χρήστη) Αριθμητικές πτυχές 6 Επιπτώσεις στο SEO 134 Σχεδιασμός UX, 3 Καθορισμένα Προσωπικά Σχεδιασμού UX. Δείτε επίσης Υποστήριξη Web Brand Strategist/Steward 26-27 Business Analyst 27-28 Selection 31 Content Strategist 28-29 Copywriter 29-30 Front-End Developer 31 Information Architect 22-23 Interaction Designer 23 User Researcher Visualsi 3-0 31 Ισορροπία σχεδιαστή εμπειρίας χρήστη με άλλους ρόλους 248-249 Ενσυναίσθηση 156 Δέσμευση στους στόχους του έργου 60-62 Οργάνωση 7-8 Ρόλος στην ιεράρχηση προτεραιοτήτων 151 Χαρακτηριστικά 6-7

Validation V, search for early 191 value propositions, presentation 15



Visio Prototyping Tool, 215 Visio site features 167 Visual Design Team, 249 Visual Designers participating in wireframes providing feedback 203 188 Visual Design 30-31 Characters using mockups. See also Using numbering systems 174 Models 224 Wireframes 200-201 Visual vocabulary definition conditions 170 Connections and arrows 170 Decision points 169 Pages 168-169 Page stack 169 Visualization and ideation 14 Iterative capabilities 750-4 Business capabilities 1

In WAMMI (Website Analysis and Measurement List) 103 Warfel, Todd Zaki 115, 124, 217, 219 Modified Waterfall Method 65 Steps for 63 Webmasters, Quality Guidelines Help for 142 Webmasters/Webmasters/Website Owners Analysis 12 Site Resources 28. See also ACSI (American Customer Satisfaction Index) Resources 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent Talent Agency 51 Ascend Proality RP7001 Names 118 Behavior 249

Blue Flavor 167 CSS Scheme 167 Brand Experience and the Web 12 Brooks, Mark 201 Card Sort Spreadsheet 109–110 Coroflot 51 Creative Commons 50 Online Digital Journal 167 Door Page 142 Evans, Will 181 181 Hackers 2, 194, 181 Google, Analysis 71 HTML Prototypes 214 Illustrator 167 Image Mapping 213–214 InDesign 167 Information Architecture Institute 51, 167 Information Search 17 jQuery 214 Keyword Research Tools 135 Campaign Locations 16 Message7 PowerPoint19 Microsoft19 8 Ohm niGraffle 167 OpenOffice Draw 167 OptimalSort 109 Fonts 113 Photo Resources 117 PowerPoint 167 Random Name Generator 118 Beginner's Guide to Search Engine Optimization 129 SEO (Search Engine Optimization) 143 Slingthought 217 Popular Baby Names at Social Security Administration International Inc. 118 SRA 182 SUMI (Software Measurement Inventory) 103 Tools 167 Usability test scenarios 240 Usability.gov 240

UI Engineering 125 User Satisfaction Measurement Tools 103 UX Design Methods 24 UX Organization 8 UX Research 95 Visio 167 WAMMI (Website Analysis and Metrics Inventory) 103 Webmaster/Site Owner Help 129 WebSort 129 WebSort 109 214 Web Sort Sites 109 WebTrends Sites 24 White hats and black hats 141–142 tables, storyboards 149 Wireframes & annotations 186–187, 193–194, 201 Using numbering systems 173 methods of creating standardization 201 and 201 9, 198–199 Designing the home page 197–200 as an iterative exercise 201 Collection of information from customers 192-193 Sketch 186-187 Demo 202-203 with reality prototypes 207-209 Getting started 192-193, 201 As "1-for-1 users-thinking device" 198 tools 188 visual design 200-201 renting workstations, defining 49 workflows, creating stories 149 worksheets, creating for business needs 153 WYSIWYG editors, using prototypes 209-214

Y Yahoo, a search interface library site powered by 128 Yahoo! 214



Get free online access to this book for 45 days! Sign up for a free trial of Safari Books Online to access even more books! When you buy this book, you get instant online searchable access to Safari Books Online for 45 days! While you're there, be sure to check out Safari Books Online's on-demand digital library and its free trial offer (separate registration process). Safari Books Online subscribers have access to thousands of technical, creative and business books, how-to videos and articles from the world's leading publishers.

Just visit www.peachpit.com/safarienabled and enter the code FJGSLZG to try it now.

Top Articles
Latest Posts
Article information

Author: Stevie Stamm

Last Updated: 07/01/2023

Views: 5477

Rating: 5 / 5 (60 voted)

Reviews: 91% of readers found this page helpful

Author information

Name: Stevie Stamm

Birthday: 1996-06-22

Address: Apt. 419 4200 Sipes Estate, East Delmerview, WY 05617

Phone: +342332224300

Job: Future Advertising Analyst

Hobby: Leather crafting, Puzzles, Leather crafting, scrapbook, Urban exploration, Cabaret, Skateboarding

Introduction: My name is Stevie Stamm, I am a colorful, sparkling, splendid, vast, open, hilarious, tender person who loves writing and wants to share my knowledge and understanding with you.