User Experience Design Guidelines - PDF Free Download (2023)

User Experience Design Guidelines


For user development designers on site or in the field

RUSS UNGER I Caroline Chandler

Peach Press

UX Design Guidelines: For UX Designers Live or in Development Russ Unger and Carolyn Chandler

New Riders 1249 Eighth Street Berkeley, CA 94710 (510) 524-2178 (510) 524-2221 (fax) Find us on the Internet: To report bugs, please email at[email protected]New Riders is a publishing house of Peachpit, a division of Pearson Education. Copyright © 2009 Russ Unger and Carolyn Chandler Acquisitions Editor: Michael J. Nolan Design Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laflamme Lyricist: Leslie Tilley Proofreader: Suzie Nasol Composer: Danielle Foster Index Author: Valerie Perry Cover Design : Mimi Heft Cover Production: Andreas deDanaan Interior Design: Mimi Heft

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

Disclaimer The information in this book is distributed "as is" without warranty of any kind. While 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 in this book or by software and hardware .

Trademarks Many signs that manufacturers and retailers use to distinguish their products are registered as trademarks. If such marks appear on this book and Peachpit has been informed of trademark claims, their appearance is at the sole discretion of the trademark owner. All other product and service names mentioned in this book are used for editorial purposes only and for the benefit of such companies, and no trademark infringement is intended. Such use, or use of any trade name, is not intended to convey an endorsement or other association 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 magicians, the league would hunt them down to reveal their biggest secrets. Fortunately, they didn't. Russ and Carolyn have collected sage wisdom previously known only to the most experienced UX project managers and codified it for all to see. Now you can learn the secrets you need to start a great UX project. Jared M. Spool, CEO and Founder, User Interface Engineering

Is there a book that tells you everything you need to know about UX design? no. Is there a book that best gets you there? It's now. Carolyn and Russ have provided a solid foundation in project planning and project management. This is an essential handbook for anyone immersed in the competitive methodology, endless meetings, and all the moving parts of UX design. Dan Brown, author of Communication Design

This book is a great introduction to designing great products for real people. But it covers more than just design - it covers everything related to design: project management, collaborating with people, and exchanging ideas. A great all-rounder. Donna Spencer, author of Sorting Cards: Designing Using Categories

This is a practical, accessible, and deeply human guide to a very human behavior: working with people and doing great things for others. Steve Portigal, Portigal Consulting

If you've ever heard of author Wil Wheaton, you'll understand why I think so highly of Russ Unger. Russ' experience and leadership were the foundation upon which Monolith Press was built and designed, and he has been one of the most valuable collaborators 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 never have been close to completion without the support of my family, friends, colleagues, and the many people who were complete strangers to me before the first few keystrokes. My beautiful wife Nicolle, willingly married to a successful geek with flaws, has doubled down on parenting for most of this writing. Our daughters, Sydney and Avery, constantly poked and prodded their comatose father to dance, sing and play Spore again. I automatically thought that writing a book at home with a newborn wouldn't be a challenge. I figured it out pretty quickly. Nicolle fought to save me time and time again and keep me focused on finishing this project. She is the hero I rely on the most; keeping our house organized amidst the chaos. He is the center of our world, and he sets us free too easily. Nicolle, and 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 more than all they have to offer. Caroline kept me on track. Sometimes the project never seems to start or end. She was always making things happen, exploring ideas and guiding us in the right direction. The collaboration was great and I learned a lot! This is definitely a big UX yin to my UX yang. Michael Nolan, our source code editor, was an excellent guide. Michael was honest and kind and really helped us keep things going. Rebecca Freed was a master, managing every aspect of the book, monitoring our assignments, and emailing us often late at night. Unfortunately, she often gets almost instant 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 wanted to use vague ideas and scattered Sentences flooded her, and she was pointing me in the right direction. Leslie Tilley distills the words; Tracey Croom combines production, layout and art; and the real book emerges. Steve “Doc” Baty read every chapter before it hit the Peachpit office. I often send chapters to Steve around 2am and he iv


He sends feedback by 5am, which is no easy feat. Remember, Steve is in Australia, but he's still impressive. It's hard to believe that this book would have been shelved without Steve's consistent helpfulness and quick action. Brad Simpson ( takes whatever art I throw at him and turns it into a beautifully printed image, while often juggling his own life with two teenage sons and a busy work schedule. Brad could easily walk away at any time, but he was a true friend, interested in the project and willing to support me. I'm not sure there will be enough steak dinners to make up for my efforts, but I'll work hard to make it happen. Brad, thank you for taking the many vacation days and late nights to support this work. Mark Brooks has found me in a panic many times, trying to deliver a message that requires a visual element that is beyond my time and/or abilities. Mark stepped in and saved the day on more than one occasion, for which I cannot thank you enough. Mark was brilliant, gave his all, and was the kind of guy I aspired to be. Jonathan Ashton wrote a whole chapter for us on SEO. After talking to Jonathan for 5 minutes, I knew he was the right person for the job. His chapters alone are a very good reason to buy the book, it's nice to have him on board. Jono Kane stepped in immediately at the last moment. Jono, a web developer, interaction designer, and prototyper at Yahoo, provided invaluable support and assistance on Chapter 12. Lou Rosenfeld really helped make that happen. In addition to co-authoring O'Reilly's Information Architecture for the World Wide Web, Lou is brilliant, kind, approachable, and always willing to help others in our field. You'd be hard pressed to find someone as generous as Lou. Christina Wodtke helped me introduce myself and make connections. Without Christina, I'm not sure where we would be today, but it probably wouldn't be "in print". In addition to being a "author you should read," she's someone who's always there to offer advice and insight. Much of the expertise of many UX designers is due to Christina's tireless efforts to broaden our horizons through constant innovation. Thanks


Will Evans and Todd Zaki Warfel have generously provided high-quality materials that you can use as templates for your own. They were true brothers who gave of their time and talents without question or concern, often at a moment's notice. They're great members of our UX community - people you want to know and work with - and I'm happy to be friends with them. Of course I cannot repay the kindness to these two. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING crew) and Wil Wheaton have been good friends, true supporters and believers of mine. I've been lucky enough to put these names together as a list of people I know and am a huge fan of everything they do. Their support has helped me a lot in everything I do. These amazing people went out of their way to help me with their generous contributions, anecdotes, and access to their resources, for which I sincerely thank them: Tonia M. Bartz (, Chapter 7; Steve “Doc” Baty (, Chapters 3, 11, 14 and “Quick Guide to Meetings”; Mark Brooks (, Chapters 3 and 11; Leah Buley ( ), Chapter 11; Dave Carlson (, Chapter 11; Will Evans (, Chapters 7, 10, and 11; Christopher Fahey (, Chapter 14 Chapter 10, Nick Finck (; Chapter 10, Jesse James Garrett (; Chapter 11, Austin Govella (; Harden (, Chapter 12; Whitney Hess (, Chapter 11; Andrew Hinton (, Chapter 10; Gabby Hon (www, Chapters 3 and 11; Kaleem Khan (, “Quick Guide to Meetings”; Ross Kimbarovsky (, Chapter 14; Livia Labate (www.livlab .com), Chapter 7; Michael Leis (, Chapter 11; Troy Lucht (, Chapter 14; James Melzer (, Chapter 10; Matthew Milan (, Chapter 7; Chris Miller (, “Quick Guide to Meetings”; Maciej Piwowarczyk (, Chapter 11; Stephanie Sansoutie (, Chapter 11; Kit Seeborg (, Chapters 3, 11 and “Quick Guide to Meetings”; Josh Seiden (www.joshuaseiden .com), Chapter 7; Jonathan Snook (, Chapter 12; Joe Sokohl (, Chapter 12 and “Quick Guide to Meetings”; Samantha Soma ( ),"quick guide



Conference”; Donna Spencer (, Chapter 7; Jared M. Spool (, Chapter 7; Keith Tatum (, Chapter 12; Todd Zaki Warfel (www., 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 of SXSW, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton - and everyone at Manifest Digital and Draftfcb. I inevitably left some people out, and I hope I didn't take it personally. There were a lot of people in that "crowd" and I tried to keep up with everyone. Let me know if I miss you and I'll figure it out! Finally, it should be noted that without the Information Architecture Society, the Interaction Design Society It's impossible to connect with many of the people mentioned. If you're at all interested in the field of UX design, visit these organizations, join them, and get involved!

Carolyn 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 had the motivation to jump in and do this. His energy and passion helped us get to the right people at the right time, from the Peachpit team to UX industry leaders who have had a huge impact on what you see on these pages. It truly is one of the greatest connections in our industry, successfully bringing people together day and night. Plus, I think he tweets more in a day than I do since I joined Twitter! Russ is grateful to the many people who have helped us tremendously. I won't repeat all those names except Steve Baty, who read all of our chapters in the original form we could give him and still sounded enthusiastic at 2am (on his time). John Geletka also provided thoughtful feedback and interesting discussions that were full of sparks and perspectives that spanned multiple disciplines. And of course the Peachpit team; I'll never forget Linda Laflamme's first chapter. It's not pretty (despite her tactful suggestion). she patiently



He guided me through the editing process and helped me refine a workflow that would have been better suited to writing a single article rather than an entire book. Now, I even occasionally include transitions in casual conversations with colleagues! Speaking of which... Kristen Mortensen, aka Morty, is visually my partner in crime. The charts and diagrams you see in my chapters are the result of her hard work—I know how many, because she and I were working on many of the same client projects at the same time while trying to meet chapter deadlines. Morty is one of those visual designers who can do solid visual and interaction design, enjoy collaborating with everyone on projects, and bring concepts to life. It was a pleasure to work with her due to her integrity and focus on quality and it was an honor to have her as a partner in this case. A big thank you to all of the Manifest Digital staff who have given us so much support over the past few months. Jim Jacoby brings a special blend of business acumen and UX perspective, along with a zen-like calm, to help me through some stressful moments. Jason Ulaszek is one of the most passionate people I know in UX and has an endless knowledge of tools and techniques; I don't know where he makes room for it all! Additionally, Brett Gilbert and Jen O'Brien provided valuable input on some of the many roles UX designers work in. I would also like to thank the members of the Manifest UX team who inspired me and patiently endured my constant references as I progressed through "The Book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. Working with you is a constant joy. I appreciate your humor and insight every day. To the rest of the Interaction Design Society, thank you for sharing your experiences and being an active member of my beloved UX community. My special thanks go to Janna Hicks DeVylder and Nick Iozzo, who were instrumental in the growth of the Chicago chapter and 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 can't wait to spend time with you!



brief introduction

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

Chapter 1:

Tao from UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is User Experience Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Broad definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Don't forget about the tangible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

About UX designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Where UX Designers Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Let's get started! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Chapter 2 :

Project ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Specify the page type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brand image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Marketing Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Contents source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Task application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 e-commerce venues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 e-learning applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 social networks application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Choose a hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Information Architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 users Explorer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you may have or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Build a user advocacy network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

pull together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Chapter 3: Proposals

Suitable for consultants and freelancers. . . . . . . . . . . . . . . . . 39 proposals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Make recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41



front page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Version history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Design Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Design methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Working range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Delivery items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Title and Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional costs and fees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Program Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Confirmation and signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Chapter 4: Design

goals and methods. . . . . . . . . . . . . . . . . . . . . . . . 56 Reinforce project goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

How Can UX Designers Help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Learn about design methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Approaching the waterfall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Modified method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 This How does this approach affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 5: Work

Require. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Get to know the status quo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

Gather ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Overview of Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Calling the right Stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Create a meeting agenda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Collect Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Effectively lead meetings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Coalescing Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82



Chapter 6: Users

test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic steps in user research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Create a property list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Set priority and define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A choice of research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How much research activity can I include? . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Dialogue with the user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 polls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Focus groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Classification cards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110

after research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Chapter 7: Personnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 What is people? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Why should I create a character? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Search for information about a person. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Create a role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.114

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

Advanced people. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Final thoughts on people. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Chapter 8: Users

Experience Design and SEO. . . . 126 Introduction to SEO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Why is SEO important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Important Basics resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Site technology, design and infrastructure. . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and other scripted content. . . . . . . . . . . . . . . . . . . . . . 130 Content Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, Directories, and URL Structure Everything matters. . . . . . . . . . . . . . . . . . . . . . 134

Contents: Past (current) and future kings. . . . . . . . . . . . . . . 135 Naming Rules and Combat Terminology. . . . . . . . . . . . . . . . . . . . 136 Metadata, title and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136



Part your hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Use a site map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep your content up to date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other Content issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Link popularity explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical distribution of link popularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Links in the footer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Content cross-linking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

System games. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 White hats and black hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Sending spam with meta keys mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Clone and setup pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 spam links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

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

From definition to design. . . . . . . . . . . . . . . . . . . 144 Thinking and Visualizing Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

The basic process of filming a script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitate the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Maintain good tension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Development of the Ombudsman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Manage conflict when prioritizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Plan your events and documents. . . . . . . . . . . . . . . . . . . . . . 162 Chapter 10: Placement

Maps and workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is a workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 trading instruments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Basics of Site Maps and Task Flow element. . . . . . . . . . . . . . . . . . . . 168 pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 pages in a stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Decision points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Couplings and arrows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Confused connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171



Misaligned and unevenly distributed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Misplaced text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 There are no page numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Simple Sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Advanced sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Breaking the sitemap schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 will Take your workflow to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 lanes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Chapter 11: Wireframes

and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What is a musical note? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who uses skeletons? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Create the skeleton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Tools of the Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Start simple: design a basic skeleton. . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Wireframes and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Exercise: Design a home page frame. . . . . . . . . . . . . . . . . . . 195 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 results: Wireframe homepage design. . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When Wireframes Grow and Find Their Way in the World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Sequential Design Exercise: Which Design Is Correct? . . . . . . . . . . . . . . . . . . . . . 201

A final note on the skeleton introduction. . . . . . . . . . . . . . . . . . . . . . . 202 Chapter 12: Prototyping.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What is prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How many prototypes do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Paper prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Create a digital prototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframes and Real-World Prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML editors and WYSIWYG editors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional prototyping tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214



Collaborate with developers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Prototype example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 What happens after prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Chapter 13: Design

Test with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Explore concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discover 221 tips for visual design models. . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Access Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Research planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Writing a discussion guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Facilitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and display of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Create a proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Chapter 14: Transition: Transition

From design to development and more. . . . . . 247 Ended… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual Design, Development and Quality Assurance. . . . . . . . . . . . . 248 Test the project with users (again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1… …Walk! . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal interests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network thinking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Operation after startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post-publication analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 in connection with Test the project after the user cooperates (again, again). . . . . . . . . . . . . . . . . . . . 255

Everything is ready, right? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 How to start over… … . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Index


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


Introduction Why We Wrote This Book Welcome to a guide to user experience design. There was a UX design student who couldn't sleep because he didn't know how he was going to work on a real project at his new company. Across town, a visual designer with extensive design experience wanted to take on new responsibilities in defining the user experience for her website. These are two people at different stages of life, but with a similar need: to understand how to integrate UX practices into a lively design environment. Our goal in this book is to provide the essential tools and context to help you use UX tools and techniques in your workforce. As you'll see in many of these chapters, we don't want to be everything to everyone, but we're trying to give you the basic information and knowledge you should have to fulfill the tasks assigned to you as UX Many duty designers. In addition to our own examples, we provide you with examples to help you identify ways you can quickly set up the basics, and allow you to combine this information to create newer, better, and even better-suited content for your own purposes. We hope we have expressed well that this is a very good approach to user experience design. We're nothing if we're not constantly trying to learn and improve with each iteration (no matter what we're doing). So we're a little bit on that front. A Quote from Russ As an instructor at the Information Architecture Institute (, I've noticed a pattern among the people I work with: Most have difficulty finding employment or fail to meet the expectations of potential employers. Some people have outstanding backgrounds, but are not always able to fully and practically apply their UX design skills in a design environment. These same themes run through many of my presentations at the 2008 Information Architecture Summit (



The idea for this book—which addresses many of these common questions—began to take shape. I can'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 competent co-author who helped me refine what would eventually become the book the edge of the idea. Caroline's words. I've had the privilege of building and managing UX teams over the years. I say "lucky" because I believe UX designers usually have the perfect balance of qualities that make their work fun, combining right-brain intuition and left-brain logic. When I was interviewing to form these teams, one thing really caught my attention: a related background like human factors or communication design is a good indicator that someone is involved in the field of UX design, but it's not about judging a person primary indicator of success. People would fit nicely into a band or project. Equally important, if not more important, is the individual's ability to adopt the consultant's mindset. This means having a positive attitude, striving to understand and involve others in projects, and most importantly, focusing on the actual impact on users and customers. This way of thinking means taking the time to understand the perspectives of other roles on the project, moving things forward and making compromises where necessary. It takes experience and hard work to really get that mindset right, but an open mind, solid foundations, and a good set of questions (with the courage to ask them) can get you a long way. This book may not have all the "answers," but it provides questions you can ask to help you find them.

Who Should Read This Book The User Experience Design Guide provides a broad, introductory overview of user experience design in the context of a project. Anyone interested in UX design should find something useful here. We pay particular attention to the following groups: Students taking UX design courses (such as Human-Computer Interaction or Interaction Design) who wish to supplement their coursework keys with information on how to apply what they have learned to real-life situations of communication and collaboration.



Practitioners looking to deepen their knowledge of essential UX design tools and techniques and improve their teams' communication about their roles. Chapter 3 is also dedicated to freelancers who need to create their own proposals. A UX design team lead was looking for a book to help their team integrate design best practices into their UX design work. Any leader of a design team who 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 read...

Define UX design and understand what draws people to the field

Chapter 1: The Tao of UXD

Ask important questions before starting a project (or at least before starting work)

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

Start work with smooth meetings, clear goals, and easy-to-understand support points

Networking Chapter: Quick Guide to Meetings Chapter 4: Project Objectives and Approach

Well-defined and easily prioritized design requirements from business stakeholders and users

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

Understand your users and represent their needs throughout the project

Chapter 6: User Research Chapter 7: Personas Chapter 13: User Project Testing

Select and use tools and techniques that allow you to quickly present visual ideas to the design team

Chapter 10: Site Map and Workflow Chapter 11: Wireframes 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

Communicate and develop your project with the design team at the beginning of development

Chapter 14: Transition: From Design to Development and Beyond

Be sure to visit to read the additional "Quick Guide to Meetings" chapter and to download other additional materials such as templates.



A Note on Methodology There are many approaches and methodologies. We are not advocating one method over another. Our goal in this book is to focus on steps common to most projects: defining project requirements, designing experiences, and developing and implementing solutions. The degree of overlap between these steps will vary considerably depending on the design method used (see Chapter 4 for details). Basically, our framework follows a loosely linear approach, starting with the definition steps - but we use facilitation and design techniques at each step where they are most helpful.

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 larger book - and one that would quickly become outdated. Here, we've included the most common techniques, specifics, in UX design. We have done our best to provide enough information to pique your interest and allow you to communicate with other members of the project - including basic procedures for each technique and additional references to books or websites to help you implement it when choosing a path . Project Manager's Guide. Good project management, including setting and monitoring project goals, schedule and budget, is critical to the success of any project. We don't discuss the details of how to become a project manager or how to choose a particular project approach. We discuss the skills that UX designers bring to projects that enable them to work effectively, such as facilitation and communication, and the ability to explain and maintain focus on project goals. These skills will help you become a project management partner. The only or ideal process or method to follow. We don't have all the answers -- nobody does today. The field of UX design is relatively young, and we are all trying to improve upon our status quo. You may find these trial and error, tweaks and improvements, and feedback



Advice from others will help you adjust the process to your own needs. When you find something you like, share it! please tell us!

How to Use This Book There are many excellent resources for UX designers. We've covered these topics broadly here, but have highlighted references that will allow you to explore them in more depth, depending on how much time you're willing to spend on them. To help you understand how much time each reference typically takes, we've broken them down into three broad categories:

Surflinks quoted from a surfboard are shorter articles (often available online) that take 5 to 30 minutes to read.

diving. Those invited to dive are longer online articles, official documents or short books, with reading time ranging from an hour to a weekend.

Deep Diving Those Called with Diving Helmet are longer books that might take more than a weekend to read; they give you a detailed view of the topic.



This page is intentionally left blank


Tao UXD Curiosity, passion and empathy meet It's important not to stop asking questions. Curiosity has its reasons for being. It is impossible not to be in awe as we contemplate the secrets of eternity, life, and the wondrous structure of reality. It is enough that we try to understand this mystery every day. albert einstein

Curiosity is the primary school of education in nature. smiley blanton

Passion and purpose go hand in hand. When you find your purpose, you'll usually find it's something you're passionate about. steve polling

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



In short, this chapter is about you—and anyone else interested in user experience design (or UX design for short).

If you are reading this sentence, you are a curious person. You want to know how everything works, from doorknobs to airplanes to what's stuck in your throat. First, you want to know what gets people excited. You can't see things in black and white; there are tons of shades of gray to discover! Sure, sometimes your willingness to be the devil's advocate might drive your peers crazy, but you can't help but try to see the other side of the coin. happy! The field of UX design attracts curious people who feel comfortable working with multiple shades of gray. We are looking for role models and we are developing organizationally and structurally. We connect the dots. We're always chasing the next piece of the puzzle, and when a puzzle is solved, we're looking for ways to make it even better! We can be analog or digital. We have pens and paper, whiteboards and dry erase markers, post-it notes and sharp pencils at home. We speak in Visio and "Graffle" and live in a world of boxes and arrows connecting the many screens of our computers. We're not just curious. We are full of passion! We are passionate about brainstorming and facilitating discussions. Our passion is to create things that matter to the people who use them and the people who make them. Weirdly, we're most proud when we create something so good that people don't realize how good it is! Of course, we have empathy. We can feel this deep down when we have a bad experience. 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 inadequacy that usually go with a bad experience. 2

Chapter 1: TAO UXD

When you combine this near-constant childlike curiosity with an unrivaled passion for "doing what we do" and a sense of what others feel, you get a vibrant community of professionals who Feel free to express yourself, ask questions, share solutions, and make mistakes—all in pursuit of the right goals. Welcome to the UX designer community.

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're not very good at "defining the damn thing" when it comes to the different parts of the whole, but at least we know what the whole is. In this book, we will pay particular attention to two definitions: the broadest meaning of the term user experience design and the definition we will use in the context of this book.

Broad definition UX design is the creation and synchronization of elements that affect a user's experience with a particular company, with the aim of influencing their perception and behavior.

These elements include things users can touch (such as physical products and packaging), hear (advertising and audio signage), and even smell (the smell of freshly baked bread in a sandwich shop). It includes things that users can interact with in non-physical ways, such as digital interfaces (websites and mobile phone apps), and of course people (customer service representatives, suppliers, and friends and family). One of the most exciting developments in recent years has been the ability to combine elements that affect these different senses into richer, more integrated experiences. Fragrance-o-vision still has a long way to go, but other products continue to blur traditional boundaries.

What is User Experience Design?


Don't Forget the Tangible While we focus on the digital aspects of the customer experience, these types of interactions don't happen in a vacuum. Remember to consider the practicality of the experience when designing digital products. The environment in which users work is important, as is the physical product (screen, keyboard, and other input devices) that affects how users interact with your design. Chapter 6 provides techniques to help you understand the effects of context. Also, don't forget about other touchpoints between a product or company and the people it interacts with. After all, a company's brand is influenced by many factors, and the brand experience doesn't stop at the computer or mobile screen. The best website design can’t make up for poor customer service or the satisfaction of providing well-designed packaging after product delivery.

Figure 1.1 The modern classroom combines analog and digital elements.


Chapter 1: TAO UXD

Digital applications increasingly impact tangible experiences such as classroom learning. Likewise, experiences that were once personal, such as choosing to purchase a home karaoke system, are increasingly enriched by social interaction.

Figure 1.2 Online reviews have a strong influence on consumers.

Our Goals As you can see, the scope of UX design is large and growing. For the purposes of this book, we'll focus on projects that focus on designing digital experiences—specifically, interactive media such as websites and apps. To be successful, UX design for these products must take into account the project's business goals, the needs of the product's users, and any constraints that affect the product's functional lifecycle (such as technical constraints or constraints related to the project's budget or schedule).

What is User Experience Design?


Free samples of new food bars distributed during the marathon

door handle

a pair of shoes in a box

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

Tangible Features of SMS

consumer hotline



Our Purpose To Read Online Product Reviews To Search The Internet Archive To Display Targeted Ads

Live Digital Customer Service Chat

About UX Designers While curiosity, enthusiasm, and empathy are common traits of UX designers, they also crave balance. We're finding a balance, especially between logic and emotion, like Spock and Kirk or Dane and Dane in this episode, whose emotion chip overloads the positronic relay. You have an idea. In order to create a truly memorable and useful experience, a UX designer must understand how to create the logical and functional structure of the experience, and must understand the elements that are important to creating an emotional connection with the product's users. Exact balance may vary by product. An ad campaign for children's toys has a different balance than a hospital app that tracks patient data. Products designed without an understanding of the needs of both are likely to miss out on the opportunity for a truly memorable experience — and the benefits that the company behind the product reaps as a result. 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 understand this (see Chapter 6) and create tools such as personas (see Chapter 7) to help the rest of the design team focus. Remember, emotions are only part of the bigger picture. Use your logical abilities to pull yourself back from the brink and focus on the task at hand. In most cases, you will create a budget based on the time and materials needed to complete the project. You need to understand that sometimes you have to fish or cut bait.

Where UX Designers Live You are not alone. Take a look around and you'll find many organizations and communities that can support your development as a UX designer. In addition to providing mailing lists, online resources, and a community of really smart people, many of these organizations sponsor events or conferences that can help you broaden your horizons while narrowing your career horizons. Many companies host events designed to provide lifelong learning, including User Interface Engineering's Web App Summit and User Interface Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. The number of "non-guilds" in different cities is also growing; they are created by a group of motivated individuals independent of any particular 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 better known organizations, their websites and events. Table 1.1

UX example organization


Web page

large conferences (usually held)

Interaction Design Association (IxDA)

Interactive (early February)

Institute for Information Architecture (IAI)

IDEA Conference (September/October)

American Society for Information 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 have come this far. Time to think about why you picked up this book. Turn the page and see how UX design exists in the field of design. But don't stop there—this book is your guide to get you started. It contains many examples to help you with many of the tasks that will be handed to you. We also try to provide more examples to help you develop and find the best way to create products that benefit your team and your customers. Keep your curiosity, enthusiasm and empathy! Challenge yourself to find new ways to inspire others to create the perfect customer experience. Of course, that's before you start upgrading.


Chapter 1: TAO UXD


Planning the project ecosystem from the perspective of needs, roles and project culture Are you starting a brand new project? Or are you in the process? Either way, take a moment 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 applications are included? What roles and skills are required? What is corporate culture? Answering these questions will help you define your project and ultimately identify the tools and skills you need to succeed. Carolina Chandler



Every project has its unique challenges. If you're designing a website or application, many of these challenges will revolve around specific features and functionality, such as building a way to share photos online with friends and family, or reorganizing information on an intranet to more easily find and share content. However , around these specific design goals, all projects have a broader context that needs to be understood and integrated into the plan. This context is the "ecosystem" of the project, including the environment you will be working in (company culture), the general type of work you will be involved in (such as the type of website you are designing), and the people you will be working with (including their roles and responsibilities )interactive. By taking 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 you can help other team members anticipate project 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 are designing. Finally, the chapter discusses some elements of company culture that may affect the way you work during a project. Note Depending on the structure of your company's projects, a given project may involve designing more than one website or application. For simplicity, this book assumes that the project involves designing one type of website. If you have multiple positions, consider each position individually to ensure you have the right role on the design team.

Identify Your Type of Website While there is no black and white difference between one type of website and another, you can recognize some relative differences in website scope and functionality. Knowing these similarities and differences can help you set your own design goals. These are general questions that must exist

Addresses (such as "explain the company's business model") or attributes to be represented (such as "demonstrates the company's responsiveness to customer needs") as part of the website's visual design and interaction design.


Chapter 2: Project Ecosystem

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

Participate in gathering business requirements (see Chapter 5). Determine the best way to incorporate user research (see Chapter 6). Ask questions about what systems and technologies might be involved.

Your site may have one of four types of strong links:

Brand Identity - a ubiquitous online platform that facilitates a relationship between a company and its general audience (anyone interested in its products or services) Marketing Campaign - a targeted website or app designed to gain traction from a specific audience or source that produces a specific and measurable response Content intended for a limited general audience - a store of information that may contain multiple types of media (articles, documents, videos, photos, instructions) designed to inform, engage, or entertain the application's user tasks - A tool or collection of tools designed to enable users to perform various key tasks or workflows

In the following sections, we'll take a closer look at each of these types, discussing their characteristics and their impact on your website or application's design challenges. We'll also cover the most popular crossovers -- e-commerce, e-learning, and social networking -- that feature more than one type of feature.

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 logo or the Coca-Cola logo. However, a company's brand is more than a logo; it is a set of impressions a person has about the company.

specify place type


Dirk Knemeyer gives some good definitions of branding in his article "Brand Experience and the Web": In each of us... the science of branding is about designing for people and influencing their minds—in other words, establish a brand.

Surf For more information on the difference between corporate brand experience and corporate branding efforts, read Dirk Knemeyer's explanation in "Brand Experience and the Web": For an excellent discussion of how website UX design affects personal brand experience, read Steve Baty's "Brand Experience in UX Design":

Companies can do many things to influence their brand associations, from running memorable advertising campaigns to expressing brand characteristics (such as "responsiveness" or "value") through the functionality and design of their website. All pages in a company have some impact on the company's brand, either directly (by presenting pages that customers can visit) or indirectly (by providing key services that customers rely on, such as customer support). However, branding pages are most focused on presenting your company's brand message and values. They provide direct access to customers and extensive web traffic for those who want to learn more about the company or what the company has to offer. The brand presence site is typically the company's main .com or .org site, such as, or for larger and more dispersed companies, the main sites for business units of all sizes, such as Different product lines often also have their own unique online brand identities. For example, has a brand, while has its own distinct existence.


Chapter 2: Project Ecosystem

If you work on a brand website, you likely design for a variety of user groups, including current and potential customers, investors, partners, media (such as news organizations and prominent bloggers), and employee research.

Where co-branding occurs Main company website (,,, etc.) Company business unit home page (usually a website

specific industry, region, or a large number of products) the location of an identifiable sub-brand within the company

The design goals of brand image The most important design goals in brand image projects are usually: to convey the company's brand value and brand information,

Either directly (perhaps a statement about the importance of responding to customer needs) or through general impressions upon entering the site (such as checking that it is functioning well and offering features that encourage customers to communicate with the company). Provides quick and easy access to company information. you want

Answer the question "What does the company do?" and "How do I contact someone for more information?" Show or explain the business model and value proposition:

"What can the company do for me?" and "How does the company do it?" include a set of key user groups and direct them to the appropriate user group

functions, features or content. Help companies achieve their goals based on key metrics such as

The number of unique visitors. This is often part of an overall marketing strategy. Later, in the "Choosing a Headwear" section, you'll explore the various roles that can be involved in designing a website to represent your brand. let's see for a moment

specify place type


Among other types of sites you may be using, including those that are closely related to brand sites: sites with marketing campaigns.

Campaigns Campaigns sites are similar to branded showcase sites in that both focus on engaging users in experiences that affect their perception of a company's brand. However, sites with marketing campaigns are often evaluated on their ability to achieve very specific actions within a specific goal, such as within a certain time frame or to a target audience. They should not serve as a conduit to generate interest, but an engine to generate it. From an online perspective, this usually means that they fit into an overall marketing strategy and can be run alongside other marketing activities across different channels, such as TV or radio commercials, print ads and other promotions.

Typical campaign website A landing page that promotes a specific offer. The site can be accessed by

An advertising banner from another site. A small website (or microsite) that promotes a specific event. Games or tools designed to make noise

That is exercise.

The main goal of a campaign website is to create a narrowly scoped campaign, usually targeting a specific set of metrics. Focus is usually reduced by one or more of the following factors:

conference) or season (such as the holiday shopping season) a group of users - for example, an event for teens or teachers a product, a group of products and/or a specific use of the product - in

For example, one website highlights kitchen appliances by showcasing a virtual kitchen with matching oven, dishwasher, and cooker


Chapter 2: Project Ecosystem

A campaign that combines these strategies would be a spring flooring sale campaign that combines timing and product mix. See Figure 2.1 for an example showing a combination of product sets and user groups. A marketing campaign website can be as simple as a banner ad leading to the landing page of a company's .com website, or it can be a microsite, which is a small website that is often differentiated from the brand on the .com to provide a customized experience based on one or more areas of interest . "Small" is relative here—some microsites have just one page, while others have many, but either way, the microsite is smaller and more focused than the main corporate brand page.

Figure 2.1 Texas Instruments uses the educational microsite to provide information about its graphing calculators. This product pack is primarily intended for use by high school students and students in algebra classes. The microsite maintains a generic association with the Texas Instruments brand, but intentionally stands out to appeal to a younger audience and organizes content and functionality according to their needs.

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

Come up with a value proposition (the value the product or service brings to the user, such as the ability to meet loan requirements quickly) or some sort of incentive (special offers, participation in contests or entertainment, such as online gaming).

specify place type


Attract a larger group of users to perform a specific action illegally,

Examples include going to a specific location on a brand's website, signing up for a newsletter, or applying for a loan. When a user takes this action, it's called a conversion. Help your company achieve its goals based on key metrics such as numbers

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

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

Content Feeds Content Feed pages contain a repository of information, which may exist in many types of media (articles, documents, videos, photos, descriptions), designed to inform, engage and/or entertain users.

A common source of content A website A company intranet An online library or resource center for members of an organization A website or area of ​​a website dedicated to news releases or frequent publications

Updated Posts (Larger Business Blogs May Fall into This Category) Customer Service Center

Of course, all websites and applications contain some content, but some websites put a special emphasis on the presentation and structure of the content. Emphasis may be because the page contains so much content that it is a challenge in itself, or because certain types of content have high importance; for example, they can support key decisions or bring users back to the page frequently.


Chapter 2: Project Ecosystem

The main purpose of a content origin site is to increase user knowledge and self-sufficiency by providing relevant content (for example, an intranet). They also often prompt users to take action, such as sharing information or purchasing a product after reading a description. Content Source Design Goals Content source sites must often do one or more of the following: Present content that is of primary interest to the site on first and subsequent visits. Demonstrate business management skills such as

By allowing access to ideas and perspectives from the CEO or other experts within the company. It supports key decisions among users. Expand your company's corporate knowledge by coming up with the following ideas

They can be buried in individual departments. This can be part of a larger goal of identifying more opportunities for innovation. Support users to search for information in various 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).

Surfing For more information on the different ways users seek information, read Donna Spencer's "Four Modes of Seeking Information and How to Design for Them":

In terms of UX design, some of the most commonly performed tasks in content source design are: Creating taxonomy structures that fit users' mental models Determining how to incorporate systems into the organic growth of content

(e.g. features such as tagging and filtering) Design effective search tools Identify site types


Task Apps Task apps can range from a simple calculator embedded into a mortgage website to a complete system supporting many key workflows. If your project involves the latter, there will be multiple roles involved and most likely a significant requirements gathering process (see Chapter 5 for more on this process).

Typical task-based applications support the creation of specific types of applications

Projects (such as spreadsheets or printables) web tools or applications that host key workflows

Websites used by companies (for example, a ticket management app for an IT support group or a customer tracking app for a call center) to access and manage personal data

(e.g. Flickr)

The main purpose of a task app is to enable users to perform a series of tasks that fit their needs and ultimately the client's business goals. Design Goals for Task Apps Most task apps should allow users to do something they can't do elsewhere—or, if they can,

Do it better ("better" can mean more effective, more efficient, more satisfying, or more convenient) Support novice users with easily accessible instructions and visuals

Key task definitions allow intermediate and advanced users to access quick functions

and deeper functionality to reduce user workload and optimize the use of system resources

(e.g. data reuse vs. requiring repeated entry)


Chapter 2: Project Ecosystem

Design and implement with the necessary degree of change

Users of the application - ideally with a design that facilitates learning and a communication plan that demonstrates value to users. One of the biggest challenges in designing task applications is controlling "feature creep". When developing a project, it's common for good ideas to emerge late in the design phase or even during development. UX design helps prevent feature slippage because user models (such as personas) can be used to identify high-value features and keep them focused throughout the design process. If a really good idea emerges while meeting the needs of a high-priority user group and aligning with your site's business goals, your team may be able to justify a change in direction. If an idea can't make it through this squeeze, it's probably not worth the delay and expense.

E-Commerce Websites An e-commerce site can contain elements of all four design types, since a major e-commerce site must be branded, contain content (usually product specifications or product usage instructions), and facilitate tasks (search, compare, write a review), view). Marketing activities are often closely tied to these sites and may involve multiple marketing teams within the organization. A typical secondary goal of e-commerce site design is to clarify the site model (if it is non-standard). love the online marketplace

Keep revising, this clarification will help set expectations (for example, eBay, Amazon, and Craigslist have very different models). Support user decision making from learning to consideration

Compare with purchase, with useful content and features. Use experience points where cross-selling and multi-selling occurs

possible and present them in a way that is engaging but not distracting. Create a communication flow from the point of purchase to the end

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


eLearning App An eLearning app is a cross between a content source and an assignment app. Course content needs to be generated, which often requires teams to add Learning Specialist and Content Expert (SME) roles to the topics being discussed. The product is task-based, as users typically follow courses as they progress and may need to monitor progress or research related topics. Some practical courses may also require you to complete assignments. A typical project goal is to understand the basic knowledge needed to start the course

and who it is for. Deliver content in manageable chunks at a specific speed

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

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

Social Networking Applications Social networking applications are primarily task applications because users need to be able to find and add friends, manage their profiles, connect, post, and search. However, they also contain content source challenges, notably the need for an organic structure to handle potentially very high volumes of user-generated content. If a website basically has its own identity, it will also have the characteristics of a brand display website.

Digging Deeper If you're developing a social networking application or trying to integrate social networking functionality into another type of website, this book will help you along the way: Designing for Social Networking by Joshua Porter (New Riders, 2008).


Chapter 2: Project Ecosystem

A common design goal for social networking applications is to bring potential users to the purpose and value of the network. Facilitate meaningful interactions between support users and existing users

Powered by prominent features such as image sharing, video sharing and discussions. Protect the integrity of your website by keeping people online

Become how to control your data and react to misconduct. Leverage and empower the community to improve

Tours only available to active members, such as top features and reviews. Deciding on the type of website or application you are developing for your project is only the first step. Then consider the different roles that are typically required, and how their involvement may vary by project type.

Pick your hat When you become a UX designer on a project, you often fill multiple roles. Whether or not they are formally defined within your client organization, the roles you fill will depend on the type of project and composition of the rest of the team, as well as the client's experience with each. It's good to know which roles you already enjoy and which ones you can learn on the job. It is also useful to know what others expect of the duties covered by these roles. Armed with this understanding, you can better represent yourself from the very beginning of your 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 title at all if it's not a formal job in the organization). In general, you can expect to 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. Remember role names when defining projects, but talk about needs and responsibilities when talking to clients - otherwise they might think you're building a really big team! Focusing on responsibilities rather than titles will also help you stay sane: having multiple such roles doesn't necessarily mean you're doing the work of many people, since responsibilities come and go in different parts of the project.

choose your hat


Information Architect An Information Architect is responsible for creating information structure models and using them to design user-friendly navigation and content categorization. When designing web pages and applications, common responsibilities include creating detailed site maps (discussed in Chapter 10) and ensuring that categories and subcategories of information are clear and user-friendly. Know what to expect In the UX world, information architects and interaction designers have different roles (discussed later). However, in a given company, there are few common distinctions between these two roles, at least when it comes to the definition of requirements for a particular project. For example, you might end up joining a team with the title Information Architect because that's the historical name for the role, whether or not it actually matches your responsibilities. Do you need to upgrade your project team if your title doesn't match your leadership role? If it's a short-term project (eg, four months or less), and you're in a position that's widely accepted within the organization with clear responsibilities, it's probably not worth the fuss to change it. However, if there is no commonly accepted designation, and you feel that both roles are likely to be represented by different people, it makes sense to make the distinction early in the project, when you plan for engagement and communicate your responsibilities. In general, it makes sense to emphasize the role of the interaction designer for more task-oriented applications, and the role of the information architect for more content-oriented projects. But it may make the most sense to use terms familiar to the client organization and to ensure the team understands how you define the role in relation to the responsibilities you undertake. You should explain this definition in your statement of work (see Chapter 3). An information architect's responsibilities may also overlap with those of a content strategist (see "Other roles" below). if role


Chapter 2: Project Ecosystem

Present to different people on the project team, and be sure to discuss how to collaborate early in the project.

Interaction Designers Interaction designers are responsible for defining the behavior of a page or application based on user actions. This includes web page flow across multiple views and interactions within specific views. A common activity when designing a web page or application is to create workflows that show interactions between pages or page components (see 11). Know what to expect if you're working on a small team or working on a project that isn't focused on creating new task-based functionality (for example, if you're working on a branded website with mostly category-specific content, contact forms, and newsletter signups Forms) Interaction designers can play a major role in documenting project requirements (see Chapter 5). If you're working as an interaction designer on a project with a high level of new functionality, you'll likely have someone on your team responsible for identifying detailed requirements (for example, a business analyst or product manager). The skills of a UX designer can greatly aid in the process of gathering and refining functional requirements, while documents such as functional specifications and use cases are influenced by experience design. Be sure to sit down with the person responsible for gathering the request and discuss the best possible way to work together.

User Researcher A user researcher is responsible for developing a deep understanding of end user needs based on information generated or confirmed from research conducted by individuals with users. There are many types of activities that can fall under the category of user research and can occur at multiple points in the project timeline. (See Chapter 6 for descriptions of common techniques such as user interviews, surveys, and usability testing.)

choose your hat


Knowing Expectations A client company's expectations for user research can vary widely depending on the importance placed on it by the project team or project sponsor. The fact that you discuss UX design with the project sponsor before the project begins suggests that someone on the account team knows that representing users' needs is a priority. But as those who have worked on their own computing projects know, bringing in research can also cause anxiety among project team members—worrying that user research will create a bottleneck, increasing risk (what if we find a problem and need to fix it?) or The value of undermining a particular idea that has already taken off. Research user expectations may vary across business stakeholders and project teams, so role expectations should be articulated across both groups. Clients can also expect user research to provide insights based on website analytics - tools and reports that convey patterns of website usage, such as frequently visited pages and common points where visitors leave the website. Some of the most popular analytics tools are from Google (, WebTrends ( and Omniture ( You can fill all three roles: Information Architect, Interaction Designer, and User Researcher. Can you balance all three, or do you chew more than you can chew? This depends in part on the size and schedule of the project, but the type of project also affects how involved each role is. Table 2.1 describes how UX design roles vary by project type.

Surfing Need parameters for UX design? The following article outlines how you can help: "User Experience Is a Business Imperative" Mir Haynes: "Evangelize UX Design for Ten Dollars a Day" Louis Rosenfeld: http:/ //


Chapter 2: Project Ecosystem

Table 2.1

Shared Responsibilities of the UX Designer Role

information architect


Marketing activities

content source

task app

Moderate commitment.

Smaller sites, such as one landing page, have low engagement. Moderate engagement with larger microsites.

Very high promise. Content sources require an information architecture that strikes the right balance between structure and flexibility to provide users with a solid foundation and allow for planned growth.

Moderate to high involvement, with a primary focus on creating a navigation framework, unless a larger context must be referenced in a specific workflow.

Small sites have low engagement, and large microsites or ad games (sponsored online games designed to create fun and buzz) have medium to high engagement.

Medium to high commitment.

Very high promise. This type of design often requires the most difficult work, as interaction design elements such as user flows and frameworks are critical to visual communication requirements.

Since campaigns are often temporary, user engagement is often low. A more permanent solution could use research similar to a branded showcase website. It's also common to use analytics tools to display two or more page variations to see which leads to the most conversions. This is called A/B testing.

On-site research, such as background research, can help your team understand how different users are currently using information.

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

Interactive Design

Medium duty. The higher the number of tasks, the more the project behaves like a tasks application.

User researcher involvement will vary depending on the user's budget and approach. Typical techniques for each type of project are listed below. See Chapter 6 for more information on these techniques.

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

Search, tagging, and filtering capabilities straddle the boundaries between information architecture and interaction design. Content sources can also have workflows for content creation and management.

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

On-site research, such as contextual queries, can be conducted to understand what tasks users are currently performing. However, the most widely used and well-known technique for involving users in the design task of an application is usability testing.

Once the structure is established, usability testing can validate the structure.

choose your hat


Other roles you may have or need Some roles don't usually fall under the umbrella of a UX designer role, but their responsibilities often overlap with those of a UX designer - especially if you're working on a project that no one officially fills that role , you have the ability to bring to the table. Some of the more common overlapping roles are: Strategist or brand 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 vary depending on the type of site you are designing. Brand Strategists and Brand Managers Brand strategists are responsible for building relationships with key markets by defining and coherently presenting a company's brand elements, which can range from brand values ​​such as "responsiveness" to copy and messaging guidelines to to the logo, working on specifications, colors and schedules. This role usually involves creating or presenting brand guidelines and understanding how they relate to different projects. It may also involve understanding or defining the target audience that is important to the project you are working on. In most cases, you will likely work with a brand strategist, but you will not be held accountable. The brand manager does not necessarily have to set the guidelines, but is responsible for making sure they are properly followed throughout the project. This responsibility can be delegated to a UX designer or visual designer on the project. If the company's brand attributes, values, and guidelines are well defined, and the website is expected to adhere to these principles, then your role as the project brand manager will primarily be to ensure that the deliverables adhere to these guidelines. Your contacts outside the project are likely to be


Chapter 2: Project Ecosystem

A member of the marketing department who can act as a consultant or reviewer but is not a permanent member of the team. If the website wants to expand the brand in some way - for example, by targeting new markets, the brand manager's role may be more active. He is most involved when creating an entirely new brand identity or when a company undergoes a complete overhaul of its brand by effectively rebranding itself. For example, CellularOne completely changed its name to Cingular, a major move for an established company. In this case, you should be very experienced in brand development, or have a clear and close relationship with people in the company. Key questions to help you understand what to expect from your brand persona include: Have brand guidelines been developed? If so, how strictly should the project adhere to them? Who is responsible for establishing or maintaining the brand message, brand

The look and tone of the content (e.g. casual or professional)? Is the target a new audience rather than a previous audience?

brand definition? If so, who is responsible for ensuring brand guidelines remain relevant to this audience? Will there be any naming or renaming activities? If so, how should I plan

include? (An example would be naming a new tool that will be heavily promoted.) Check in occasionally to make sure your brand is well represented. Business Analyst Business Analyst (sometimes called Business Systems Analyst in IT projects) is responsible for identifying key business stakeholders, leading the requirements gathering process (see Team. Also, is the leader of detailed requirements documents such as functional specifications and use cases Primary owner if desired.

choose your hat


The business analyst or product manager role may not exist at all in your project, or it may be one of the most important roles in the design process. Quest apps and content sources typically play this role; branding and marketing campaigns may not. Task-based applications will most likely require this role. The more functional and complex 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 manage the capture of business requirements, acting as liaisons between technical teams and key business stakeholders. If a business analyst is involved in a project, that person and the interaction designer are usually linked. If it's the same role, the person in charge may have a lot of documents to keep track of! To understand what to expect in this area, ask who will be responsible for outlining the project scope, facilitating requirements discussions, and documenting requirements throughout the project. For small projects or projects with few features, project managers sometimes take over these responsibilities. Either way, if it's not you, you'll still know who you need to be in close contact with to make sure your results are in line. Content Strategist Content Strategists are responsible for understanding business and user needs for all media content (articles, documents, photos and videos), identifying gaps in existing content and facilitating workflow and development of new content. Content efforts are often underestimated. A client may have a lot of content that does well in one medium (such as a printed brochure or video), but that content may not be a good fit for the project you're working on. Additionally, it is sometimes unspoken that people within the user's organization are expected to generate content - and those people may be surprised when it comes time to populate your product with descriptions, news, and help topics! if the content is high quality


Chapter 2: Project Ecosystem

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

tons, quantity). Assess the suitability of existing content compared to

guidelines. Develop new content. This will vary depending on the general type of project. for

A task application, which may contain instructions, error messages, and help topics. For content sources, this can be articles, news, and blog posts. Serve as a liaison between stakeholders and the technical communications team

Content Management System Limitations and Capabilities. Define different content types and metadata for each

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

Target different types of content and ensure that content is properly tagged and uploaded when uploaded to the site's content management system. (This is another area where the effort required is often underestimated.) Copywriters Copywriters are responsible for writing the text on the pages that make up the overall experience. In some cases, this copy remains unchanged overnight. It usually contains an introduction to the page and the page or instructions on the page. Contributors can also participate in the ongoing creation of dynamic content, such as news or texts for marketing campaigns. Copywriting is one of those gray areas that often falls into the hands of UX designers, especially when they are creating mockups (see Chapter 11). Initially, you can use the sample text as a placeholder for text such as page descriptions or page descriptions, but eventually someone has to populate it with the final text visible to the user - as many projects don't have a dedicated contributor who can assign the task to you . You are unlikely to be asked to write for a well-known domain on a brand's website or marketing campaign; in these cases

choose your hat


Every word can be double-checked. However, if you're developing a task-based application that requires brief instruction messages, error messages, or other types of information that don't necessarily fall within the explicit scope of content, you may end up inheriting that writing task (or It belongs to the developer by default). Ask songwriters ahead of time if they're available, and ask again if you can't find them. If the task falls to you, be sure to include this work in your plan of activities during the project. Be warned: this is a responsibility that is often overlooked or underestimated. Visual Designers Visual designers are responsible for the elements of a website or application that users see. This work includes designing the look and feel according to the brand guidelines, creating an emotional connection with the user. For example, bank addresses often need to appear stable, reliable, and easily accessible. Visual design can provide this assurance through visual elements such as color and imagery. That promise is then maintained (or broken) through the interaction design of the website and other touchpoints with the company such as the call center. Let’s be honest: many people call themselves visual designers, web designers, or graphic designers, and many websites have poor or only satisfactory visual design. There is a big difference between creating effective, engaging and moving visual design and simply surviving. Sometimes this is enough to achieve the project goals, other times it leads to frustration and delays when the project owner is unhappy or the first users don't get involved with the project. On the other hand, it is easy to pay too much attention to the impact on the visual design, which affects the usability of the design. If you’re being asked for this role and you’re not sure you can make a real impact with customers, gauge your comfort level by taking a visual look at the company’s current website and a website or product that customers appreciate. Visual designers often play a central role in the design of brand identity and marketing campaigns, playing an important role in effectively communicating a company's brand.


Chapter 2: Project Ecosystem

For content source design, they can focus on creating content templates (for example, article templates) that can be applied to multiple pages. For task apps, they can provide a style guide that can be applied to common interaction elements like navigation areas and tools (requiring a high degree of collaboration with the interaction designer). Front-end developers Front-end developers are responsible for building the technical structure behind the page design and flow, as well as the interactive elements on the website, such as scrolling menus, expandable content areas, and interaction with multimedia 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 that are directly related to what users see, rather than the back-end 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 a front-end developer, it is important to work closely with other members of the development team to understand expectations and responsibilities. Other important issues include which backend systems you need to integrate with, the method used to generate HTML, the need for flexibility in page structure to accommodate custom skins, and expectations for technologies such as Flash. If a prototype is planned (see Chapter 12), ask who will develop the prototype and what level of functionality you expect. Prototypes that focus on simple opportunity communication can be built quickly in an application like Flash, but full-featured prototypes that require retrieving actual data (for example, the account information a user just entered into a form) will require collaboration with members of the back-end development team. Are you apprehensive about taking on all of these roles? Unless you're working on a very small project -- or a very small company -- it's unlikely you'll be taking it all on your own. The key is to understand which roles you are able and willing to take on if required by the particular project you are working on. For the rest, you can get the support you need within the project team by networking at the client company or by referring others to meet needs. Let's take a moment to talk about how to do this.

choose your hat


Build a User Advocacy Network In areas that you're not sure you can or don't want to address, it's time to start asking for help. There are three main approaches: Suggest adding additional team members when needed

Visible enough. Educate yourself in key areas where gaps exist - if you're new

Skills are easy to learn and you have the time to invest in them. Build a support network within the company to help you in critical moments.

Let's take a closer look at how to build a support network. Most likely, there are some key resources from other parts of the company that can help you succeed. You'll need to estimate how much time you can rely on these people, as seeking outside time can be a difficult requirement for projects that are primarily run by one department. If you don't want to ask for a lot of time to get out of the gate, just ask if you can work with them (or consult) to make sure you get the most out of the role's main responsibilities. Once you form 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 for time. Every company has a different structure and different department names, but here are some common places to look for partners: For a brand strategist role, ask the marketing department if someone

Departments that can act as focal points. It can also be a resource for visual designers and content strategists. You can also find a visual design and content strategy partner at

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

Developers and others who can assist you in accessing and reviewing web analytics tools.


Chapter 2: Project Ecosystem

If you are new to a new company and looking to work across departments, one of the best things you can do at the outset is to identify key people who could become partners and arrange interviews with them to understand their roles. and experience. It starts with a network that you can often rely on long-term, and gives you the opportunity to explain your responsibilities (and UX design in general). Or you can ask a good question at the end of the interview: "Who else do you think I should talk to?" The answer can help you find people that the lead project manager or client contact may not see. If you have been with the company for a while, you can still start this interview arrangement. In this case, it's best to tie it to a specific milestone (such as launching a new project) or an urgent corporate goal to ensure high engagement. Let your supervisor know what you are doing so as not to give the impression that you are walking past them. Good communication is key to understanding role expectations and building trust. Another key to gaining trust in a company is understanding its culture, often the unspoken expectations of how the company should operate, for example from past project experiences (positive or negative), etiquette and acceptable Work logistics (e.g. at home).

Understanding Company Culture Culture is like pouring Alka-Seltzer into a glass - you can't see it, but somehow it works. — Hans Magnus Enzensburg

Company culture may not be consistent across regions, business units or departments, but you can often identify key characteristics that affect you and the project or projects you undertake. Here are some aspects to keep in mind when scoping a project and navigating potentially difficult political situations.

Understand company culture


History We all know that those who cannot remember the past are doomed to repeat it, and design work is no exception. Knowing how the project or team arrived at the current state of requirements can help you understand the challenges you might face during the project. Let's take a look at some questions you can ask to understand stories that might impact your project. While some of the answers to these questions may seem daunting, remember that there are certain things that make you want to work on the project, so the project can have a checkered history and still be successful. Maybe you will be the key to success! However, if many of the issues discussed below seem to apply to you, and you don't feel like you can fix them, this could be a warning sign. In such cases, an overall assessment of the project's chances of success should be considered. What are examples of early projects that seem to be under consideration?

is successful, what makes it so? What projects have been unsuccessful (or particularly painful) in the past, and why? Asking these questions (either directly or in a more subtle conversational style) can help you understand several things: how respondents define success, the potential risks of your project and any biases or expectations that will transfer to it, and the approach they take is it effective. Has the company cooperated with the designer and published on the same issue

Project or team? If so, try to find out what doesn't work and how customers can expect different approaches. If you can ask this question to more people in the company, it will help you understand a lot of unspoken expectations. If you get two wildly different answers, it probably means that the designer's responsibilities are not clearly defined, and you may need to make sure your responsibilities are communicated throughout the project. Whether the design team was involved in the project (or related materials)

Why does it seem like an unbelievably long, never-ending amount of time?


Chapter 2: Project Ecosystem

If so, it could mean that key customer stakeholders were not on the same page or engaged in a timely manner, leading to multiple delays, changes in direction, or wasted time due to multiple iterations. It can also mean not having a clear leader, someone who can say no (or at least effectively prioritize) focus on your business goals. If you are able to influence project communications, it may be helpful to create engagement guidelines that will move the project forward. Whether the company created the project without prior involvement

User experience designer? This may be a mixed blessing. On the one hand, you have a team that understands the design needs and tries to fill in the gaps. On the other hand, you may end up with a project that you don't think meets the project's UX goals. This can be a delicate situation. It's often best to approach the developers of these projects with the tone of a respectful mentor or helpful advisor, first emphasizing the good points of the project, then discussing UX goals and how different approaches could be used to better achieve them. Creators are likely to be valuable members of your support network, so it's important not to break bridges, but to redefine their roles in a collaborative way to maintain enthusiasm. Is the lead sponsor or project manager particularly concerned?

About the project? This can happen for a number of reasons, especially when some of the factors mentioned above are involved. It is understandable that market stress can also cause anxiety. For example, has the company's stock price fallen? Have any of your competitors made impressive strides lately? Is the company losing money? Again, these circumstances don't necessarily mean you shouldn't be working on the project; after all, in these circumstances, the project will usually get financed first. However, if you are very concerned about your company not being able to pay your invoices, then you should consider this risk.

Understand company culture


Geert Hofstede's Hierarchy has an excellent model of cultural differences, which he calls "cultural dimensions", which often influence the way people interact and interact. One of these is the concept of power distance, the degree to which members of society (in our case corporations) understand and accept the distance between people with different levels of power. For example, if members of a company's management team are perceived to be particularly powerful and may be difficult to approach, the company may have a large power distance and its employees may be more hierarchical. If a company encourages a democratic exchange of ideas and challenging visions, it may have relatively little power distance.

Power distance is "...the degree to which less influential members of organizations and institutions (such as families) accept and expect unequal distribution of power. This stands for inequality (more vs. less), but is defined under from above, not from above. It shows that the level of inequality in society is supported by believers and leaders.” Geert Hofstede Cultural Dimensions

Neither extreme is inherently better or worse, although in the US most workers prefer the small distances of the workplace. It's worth noting that this isn't necessarily an indicator of a company's success. Apple has a relatively high power distance (if you consider the aura around Steve Jobs), Google as part of its culture has a relatively low power distance, but both companies are known as innovation leaders. It should be noted that the power distance within the client company can affect how successfully you navigate the political waters during the project. This aspect will become especially important at key points in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as approval points (discussed in Chapter 4). If you work for a company with a large power distance, take extra


Chapter 2: Project Ecosystem

Before scheduling meetings such as stakeholder interviews and reviews, and consider involving more middle management in the communication process.

Logistics In addition to the larger cultural aspects mentioned above, it is also useful to understand some elements that are more logistical in nature so that you can better fit into the current way of working, or make changes in a thoughtful way. For example, it is helpful to know the overall velocity expected by the company, including key release dates or deadlines that will affect projects (for example, software development for an annual release schedule may not be at the same pace as a microsite supporting seasonal campaigns). Does your team Have to work overtime to meet a looming deadline? It's also good to know what to expect when working remotely versus on-site. If you anticipate staying at a location for an extended period of time, you need to plan your travel and resource allocation. If remote working is acceptable (or encouraged, which is common when working with multinational corporations), it is important to understand communication methods and tools. For example, is instant messaging allowed? What web conferencing tool do you use? Are there methods of engaging international stakeholders that have proven successful in the past? It is also interesting to learn about the "paper culture" in the company. Some companies prefer electronic media for the most part, in which case a good projector and consistent Ethernet connection are important. Others are very paper-conscious, in which case you need to make sure you have enough copy for each meeting to make meetings more efficient. You might be able to change the project's culture if you think another approach is more effective. But it's good to know that you're asking people to make changes to ease the transition -- and possibly understand why a particular approach isn't working as expected.

Understand company culture


All Now that you understand the project's terrain, you should have a better understanding of the project's ecosystem: the environment in which you will work (company culture), the general type of work you will be involved in (e.g. the type of pages you design), the people you will be working with Communication (including their roles and responsibilities). This information will be valuable when you define your role in the project and are ready to get started in earnest. If you're a freelancer or subcontractor, this will be the basis for writing a proposal covering your work on the project (see the next section on UX proposals). If you work on a larger team and are not directly involved in writing the application, you can use your new knowledge at the beginning of the project - your team's first meeting. Basic guidelines for running a good meeting can be found in the 'Quick guide to meetings' online chapter, and if you want to jump straight to the types of questions you should ask at the start of your project, see Chapter 4 'Project goals and methodology'.


Chapter 2: Project Ecosystem


Advice for consultants and freelancers A guide for business people who are also managing their own business Managing projects and client expectations can be hard enough, but if you don't have the right contracts in place, you can find yourself at a disadvantage at the end of any project you undertake. Job offers and claims 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 a contract detailing the terms of your relationship and the client's payment schedule. Russian Unger


Advice There's an old saying that "what's good is never bad" and it holds true for any program - the high fives and goodwill are quickly replaced by "Oh crap! Time to write the application!" The biggest challenge in writing an application is writing your first application. If you've never written one yourself, it's nearly impossible to know where to start, and that's where this chapter should come in handy. Every type of project you come across will have a different style, which will keep you on your toes when writing your proposal. Fortunately, there is something like a core that is common to all proposals and can be reused in subsequent projects. (See Chapter 2 for a detailed discussion of project types.) When should I write an application? continuously. Why is it worth writing a quote? In the entire history of working on a project, people have been put in the most unpleasant situations when misunderstandings arise between client and supplier. You might be tempted to skip this step when you're making an initial contact with a prospect and everything seems to be going well. Even if you seem to understand your client's needs and know how to express them in a way they can understand, you're not really ready to start working. In fact, this is exactly when you need to slow down and take a deep breath. Instead of getting involved directly, take the time to define your professional relationship and how you work with new clients. "Contractors and their clients often believe that there is an agreement at the outset of their relationship when, in fact, it This confusion is just a lie. Process. While it's nearly impossible to be prepared for every eventuality that may arise, a comprehensive written agreement is your best defense and the smartest way to avoid discussing the terms of your relationship in court later. The clearer you spell out the terms and parameters of your relationship with your client up front in a written contract, the less likely you will be to fight over the obligations of both parties in the future.


Chapter 3: Advice for consultants and freelancers

New projects and new people are exciting. People usually don't want to "kill the deal" by adding proposals, but like in any relationship, the honeymoon feeling will wear off over time. Both parties in the relationship may break promises. Customers may not be able to access the Content in a timely manner. (I know this is almost unheard of, but believe it or not, it happens! Here's the irony, in case you missed it.) Funds that were once available for a project can be redirected elsewhere -- and then you , busy people, you can keep your wallet. Companies also understand that they take risks when working with third-party suppliers, especially those that are very small businesses or independent contractors. A well-written offer gives buyers a sense of stability and protection, which helps alleviate many of the concerns that may arise. The proposal also allows for the definition of conditions that protect both parties should circumstances change. If the client does not give you timely access to their resources, your timeline may change; you must make them aware of their commitment to the project's success. If the client loses money and terminates the project -- and you don't have an offer or other form of contract -- you run the risk of not being paid for work already done. The gist should be clear: always write a proposal.

Creating a Proposal Once you have a project, it's time to prepare your proposal. The sooner a proposal is approved and signed off, the sooner you can start working and most importantly, start getting paid for your work. The essential elements of a good proposal are a cover page, change history, project overview, project approach

create quote


Scope of Work Assumptions Results Title and Title Additional Costs and Fees Project Valuation Payment Plan Confirmation and Signature

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

Cover A cover is a simple page that represents the introduction to a document. Covers are an interesting beast: there are many ways to create them, both from a stylistic and messaging standpoint. 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 name Document type (quote) Proposal version Submission date Your company name Proposal author Project reference Cost confidentiality

Include everything in your first quote except the client company logo, price and (possibly) project reference number. Why not put these elements on the home page?


Chapter 3: Advice for consultants and freelancers

Your client knows who he is. It's probably not worth the time and effort to ask for permission to use your company's logo, or the possible harassment you might inadvertently misuse it. Costs are best determined after identifying the various design elements in your content, and cost information can serve as a good guide for your payment schedule. Need to remember the project reference number. Many companies won't use it at all; however, some government agencies have been known to rely on this particular item, and if it's not on the cover, your proposal may be rejected.

Figure 3.1 Example of a Proposal Cover Page

Figure 3.1 uses a (fictitious) customer logo. It is best not to display a client's company logo without their consent or relationship.

create quote


Change History Change History is a separate section of a proposal that tracks how many times a proposal has been updated since it was originally compiled. In general, it's a good idea to include the version number, date, author, and any comments related to the version, such as what changed, to provide readers with context about the change (Table 3.1). Table 3.1 Version

SECTION sample change history table




original new file

European Union



Update according to software requirements

European Union


1,0 1,1

Sometimes, clients will sign off on a quote and then ask for further revisions. If you decide to continue using the client and make these changes, you should take the opportunity to upgrade your documentation from 1.x to 2.0. Basically, once the client approves the proposal and the terms are agreed upon, you can begin. Therefore, when additional changes need to be made, they should be reviewed very carefully. This ensures that your costs are still reasonable and that both parties understand what has changed and at which stage the project will restart (if necessary). You should also always provide a proper explanation of why the version is brand new 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 to expect from you, what their product will include, and an explanation of what they can expect from the rest of the offer. Here's an example of how to start an audit: [Client Company Name] is trying to create a new online presence on the Internet. This online presence provides [Customer Company Name] customers with the ability to search and purchase products online, as well as other services and benefits offered through Company. The purpose of an online presence is to…


Chapter 3: Advice for consultants and freelancers

You should be able to give a solid overview in a paragraph or two, providing very detailed information about what your client expects from you. It is a good idea to end the review with a solid explanation of the proposal and proposed approach to project implementation: The proposal details the proposal and approach for [Company Name] to design and develop [Client Company Name]'s online presence. Given the deadline [deadline date], it is recommended that...

Project Approach Your project approach will vary depending on the type of project you are working on. This is your chance to tell the client how you intend to work with them on the project. You can define rules of engagement and set expectations for future work. Many individuals and companies use a very similar approach but use different names or clever acronyms to resonate with their overall branding. Once upon a time, a mythical method was created to prove this to (potential) clients and found its way in many proposals. This process is called The PURITE Process™ (pronounced "purity"), and in sharing this process with you, the mythical creature is just a little bit dead in it, so be careful and read it like fiction. The name of the process is a bit silly, and the process is clearly incomplete. Post-launch analysis is omitted from this approach (monitoring), but of course all customers should be included. Without further ado, this is the PURITE approach: [YOUR COMPANY NAME] has established a standard process for successful projects 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 approach to ensuring the success of all programs. With PURITE, [YOUR COMPANY NAME] has a proven set of guidelines for working closely with clients and users/audiences to reliably maintain and exceed content delivery expectations. P - get ready. We dedicate part of every initiative to understanding your industry and competitors and how they operate so that you are as informed as possible before you start collecting requests. you understand. We work closely with subject matter experts and/or users to determine requirements for appropriate project development.

create quote


R - Rendering. In the rendering phase we create and develop all elements of the project/product. In our experience, each phase of development requires highly focused, targeted work, but also timely, open communication with your team. It also requires us to... I - Iterate. The iterative phase is repeated throughout the life of the project. We work as fast as possible to bring projects to life, which often requires creating many iterations in a short period of time. This requires a direct and timely commitment to you and your dedicated resources. The end result is a product that you define and help create. T-try. We test each project during the rendering phase; however, we also need an additional pair of eyes - our own testing team and a specific set of users/viewers for target-based testing. This additional round of testing helps ensure that as little as possible is left untouched to deliver a design that has been rigorously evaluated at multiple levels. Electronically enabled. After you have successfully completed the first five phases and signed the agreement, we will enable the solution and implement it. The PURITE™ process doesn't stop there. After the project is completed, we communicate with the client regularly. We will continue to measure your satisfaction, understand your changing goals or program improvements, and help you determine the best way to develop your program going forward.

You can use as little as possible of what is applicable or useful to you. The author of the myth who created this process won't mind if you don't cite sources. Process definition can be as detailed as above, or as simple as the following: Plan, define, develop, expand Planning Overall strategy definition Detailed project requirements Develop, test, improve, and initiate Work products are expanded by recommending enhancements and improvements based on information obtained After the project is developed, tested and launched

Once the process is defined, you have the opportunity to detail the various efforts that will go into each stage of your approach, and what each of these efforts means for you and your client. The methods section of a proposal will vary in length depending on the project, the process, and the activities that occur at each stage of the process. However, try to limit it to a maximum of two or three pages, and


Chapter 3: Advice for consultants and freelancers

Make sure you include only those deliverables that you will be able to provide to the client - to prevent further document updates or project valuation re-evaluations.

Scope of Work In the Scope of Work section, you define the division of work in the project. This means you decide for yourself which elements of the project are your responsibility and which the client is responsible for. Read it again. think about it. Let it absorb. Here we are. Exactly. It's the part of the offer where you tell the client in writing that we'll do this and you'll do that. Later, when the client signs off on your proposal, they agree to the arrangement, and you have a written record to back it up, in case any disagreements arise. The goal is to clarify who will handle which aspects of the project, and which aspects of the project are included in your proposal, at your estimated cost. If you can't find any other really compelling reasons to write an application, this should be enough reason. Here is a very brief example of the scope of work: [Client Company Name] approached us to provide all services required for the construction of [Project Type]. [YOUR COMPANY NAME] will focus on the [customer experience design aspect] of [client company name]'s website. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] against the project plan. [Client Company Name] will provide all necessary resources for use in the project, including fonts, color schemes, branding standards, etc.

Assumptions The assumptions section of a proposal is a great place to define what the client needs to be successful without leaving room for debate. That is, these are things that you take and communicate with the client, that you can access or deliver to you to make the project a success.

create quote


The assumptions you make in this section are actually expectations. It's much more polite to assume. You can create as many project plans as you want, but if neither you nor the client is committed to meeting milestones and goals, both will be committed to project failure. In general, these assumptions are expectations for resources and assets, and timely (translation: fast, immediate) access to both. Here is an example of how to write a hypothesis: Assume that [Client Company Name] needs to provide the following assets and resources. Failure to deliver these assets and resources in full and on time may result in failure or delay of the project. The following assets and resources are required: Prompt access to all necessary employees of [Customer Company Name]. Get timely access to all required [project] resources in their current state, including all available source files. Content, as the case may be, including but not limited to copy, images, audio, etc. relating to any aspect of [Project].

Deliverables Deliverables are work products that you create and deliver to the customer. This part is an opportunity to tell the client in detail what kind of work product they can expect from you during the project. It is recommended to report status separately towards the end of the project, but you can add it to this part of the project. Provide a description of any work product you may have included, even if the work product was not produced. This might seem like overkill, or it might open up a can of worms of "I've read about [shipping type], but I don't see it here", but one little word can make all the difference. Deliverables [YOUR COMPANY NAME] provides a series of deliverables throughout the project. We have identified the following deliverables for [Customer Company Name]:

48 years old

Chapter 3: Advice for consultants and freelancers

Idea Draft The idea draft is the first step in a project. This document will help us create a quick and efficient overview of the overall project. The purpose of the Creative Brief is to clarify the user's goals and needs, and to define any special resources and/or constraints associated with the project. etc…

Ownership and Rights It is important to consider the extent to which you will allow your customers to use the work product you create. These rights can be defined in many different ways, but most of your work can be divided into two categories: contract work permit work

Under copyright law, contract work items (known in legal circles as "contract works") are created by the party paying for the work, not the party responsible for actually performing the work. This means that when you work on a project for contract work, you have absolutely no rights to that work, and everything you create for the project becomes owned by the client. This situation is unbearable for many companies and individuals: it often means no further "maintenance" work (with additional income), because the client can choose to maintain the project itself after completion. Don't be fooled by the design of clients implementing conditions; it's not unheard of. This is pretty standard for employer-employee relationships when you place the employment-for-work item in the context of full-time employment at the company. This is also an opportunity to look at your pricing model - many programs charge a slightly higher rate to cover possible lost revenue in the future. Remember, it all depends on your relationship with your clients and how you decide to do business. Time and experience will help you make the right choice for the type of work you do and your pricing model. A licensed work design allows you to retain the copyright to the work, but grant other parties the right to copy and/or distribute the work. You can include any number of clauses in your license agreement. you are likely to suggest


Use your work license if you retain ownership of all source materials for your work and only provide limited work products to your clients (such as PDF files rather than raw Word, Visio, Axure, OmniGraffle, or other editable documents). You can license your work in a number of different ways, including licensing your work unmodified, for non-commercial use, or in many other ways that may be appropriate for your situation. Creative Commons ( has an easy-to-understand explanation of the different types of licenses you can use, but this is only a small part of the licensing landscape. If you find yourself in a situation with very specific and specific needs, it is best to contact a copyright attorney to help you find the best solution.

Additional Costs and Fees It is important that the client understands whether external resources are (or are not) included in the project you are offering him. For example, some projects may require you to purchase stock photos from suppliers. You can purchase the photos (with appropriate usage rights) and include them as part of the fee, or you can explicitly list the purchase of the photos as an additional cost that will be passed on to the client. You can also offer services that you want to tell your customers about - this is a great opportunity to promote these services. The following example explains how additional costs and charges are handled: Additional Costs and Charges If external resources (such as content, images, fonts, etc.) are required, they must be identified, approved and billed to [Customer Company Name]. Additionally, [Your Company Name ] can provide hosting services to our clients with very low overhead. We offer hosting services - including responsive web-based email - starting at $25 per month, plus an additional $25 setup fee. If [Customer Company Name] wishes to purchase a Maintenance package, [Your Company Name] will endeavor to create a mutually acceptable and mutually beneficial package.


Chapter 3: Advice for consultants and freelancers

Project Pricing Once you've documented the details of how you plan to complete the project work, it's a good idea to let the client know the cost. How you determine the price is largely up to you, but here are some tips: Estimate how long it will take you to complete the project - including a certain number of revisions, estimate a reasonable time for project management, this may be around 25%; then determine The hourly rate you want to charge and calculate everything. There are various 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 give your client. In most cases, experience will be the key to properly evaluating a project - support and materials. How is the billing rate determined? Research what others are charging by finding contractor wages and price surveys to compare. For example, organizations such as the Information Architecture Institute (, AIGA (, Coroflot (, and talent agency Aquent ( perform and research rate contractors . You can get a rough idea of ​​what you can charge based on your own experience, the prices of others in the market, and what you think is reasonable and fair. Remember: you can lower your bid at any time. It's much harder to ask customers to pay you more when they see the numbers on the page! There are many different ways to price your 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, suppose you offer users two options: a static HTML site and a site with a content management system (CMS) that supports dynamic content that users can manage without dedicated resources. Here's how you can develop a project estimate: Project Estimates [Your Company Name] proposes multiple estimates for [Client Company Name] to provide the best option for your current and/or future needs. [Your Company Name] assumes that all content will be provided by [Customer Company Name]. If [Your Company Name] is asked to provide content services, estimates will need to be redefined.

create quote


Estimates for [YOUR COMPANY NAME] allow for flexibility in cost and needs. Estimates are as follows: Estimate 1 [Your Company Name] Estimate [Project] for [Client Company Name], without any interactive content...

Remember, there really is no wrong way to value a project - unless you put yourself in a negative cash flow situation!

Payment Schedule It is a myth that all independent projects are paid 50% up front before the work begins and 50% after the project is completed. This myth needs to be busted – now! This is not the way to run a business or ensure that you receive timely, steady income while you work. You don't want to put yourself in a situation where you have to make change after change for a client just because you want to get the project done and get paid instead of going through the change order process. Projects can be valued in a number of ways, from invoices delivered within a predetermined time frame to milestone-based payments. A smarter approach is to steer projects on a recurring payment plan with regular itemized invoices. This approach should also give the client a clear understanding of what the project has achieved and what still needs to be done. The following example shows one way to structure payment for a job: Payment Schedule [YOUR COMPANY NAME] A typical payment schedule is a maintenance fee of XX% of the total estimated cost of the project prior to commencement. [YOUR COMPANY NAME] will send invoices on the 1st and 15th of the month; full payment within 14 days. Upon project completion, [Your Company Name] will deliver all work products to [Customer Company Name]. Upon satisfactory approval of the materials, [Your Company Name] will refund any overpayment remaining in the fee, or [Your Company Name] will submit a final invoice for the amount not covered by the fee. Note: If [Project] is on hold for more than 14 days with no progress, [Your Company Name] will issue a final invoice for any charges not covered by the prepayment and prioritize restarting the project.


Chapter 3: Advice for consultants and freelancers

While not required, it is a good idea to include a note explaining what will happen if the project is left on hold for a long time. This disclaimer can help keep projects on track and move forward—and give you talking points with your clients. If you don't do extra work for them for a long time, you want to be able to move on and find work to fill the void.

Confirmation and Approval Ensuring that the proposal is ready is important, but not sufficient. Proposals don't really mean much until the right people at the client company approve and sign off. It's important to make sure everyone has a clear idea of ​​what's going to happen and what's expected of each party. It's also important to protect yourself from the "highway of repetition" and reduce the risk of customers dragging you into "full functionality": constant demands for "one more thing to do". The inscription is very simple and clear. After creating the offer document, you will provide your client with an acknowledgment and signature confirming 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 a confirmation you could use: Confirm that [Client Company Name] has fully accepted and accepted this offer. To be effective, this proposal must be signed and dated by an authorized representative of [Buyer Company Name]. Alternatively, a signed purchase order relating to this proposal will constitute acceptance of the signed document (provided, however, that all preprinted terms of such purchase order shall be deemed void and void). This Proposal constitutes the entire agreement between the parties regarding the subject matter of this Proposal. This proposal incorporates and supersedes all prior agreements, discussions, negotiations, undertakings, letters or arrangements, whether oral or written. This includes, but is not limited to, any statement in sales materials, brochures or other written descriptions or advertising materials and constitutes the complete and exclusive statement of the terms of the agreement between the parties. Each party acknowledges and agrees that, in implementing this proposal, it has not relied on and expressly disclaims reliance on any statement or representation not stated herein or in the Agreement.

create quote


Accepted by authorized representative: [your company name]

[Customer company name]

author: ________________________________

author: ________________________________

arrive: _____________________________

Production: ________________________________

address: _______________________________

address: __________________________

data: __________________________

data: __________________________

Make all checks payable to: [Your Company Name]

Statement of Work The Statement of Work (SOW) is a general statement of the project's goals, which you should be able to summarize in a two- or three-page document (excluding the cover page). SOWs are usually written before you get into specific requirements, although depending on the needs of the client and the project, you may choose to create a hybrid document that best suits your needs. In general, the SOW should be used to build consensus as early as possible between the team and the client's stakeholders. The SOW will define project inputs and outputs as well as assumptions and constraints. At this point, it's not uncommon for clients to ask you for "numbers" of the work you'll be doing for them. It might be a bit risky to answer this question at this point. It is recommended that every effort be made to avoid giving details or promises without giving them. If you haven't written the application and/or requirements, it's simply impossible to know how much the project will cost. However, at this point you must make an assessment. If you're working on a project, say a basic website, and have successfully completed several similar projects before and/or worked with the same client before, then you have some leeway. Remember, it's better to play it safe than to feel uncomfortable late in the project. Job descriptions should be two to three pages long and contain at least:


Chapter 3: Advice for consultants and freelancers

Home Change History Project Reference Number Project Summary Start Date End Date Rates/Prices Project Explanation Activities and Results Costs and Payment Schedule Acknowledgments and Signatures

Do these items look familiar? You should -- you can create a SOW with a simplified version of your proposal. You've now learned how to put the two types of documentation together, allowing you to identify the work you've done 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 orders for moving forward with the project.

work list



Project goals and methodology Know which star to navigate One of the keys to a good project is starting a team with a clear project goal and an easy-to-understand methodology. Ideally, the project management should define this for you - but if they don't, how do you know? This chapter discusses developing project goals and provides some questions to help you reinforce those goals. We'll also discuss some common project approaches (or methodologies) and how they affect the way you work. Carolina Chandler



For the first time you are starting a project with a full team. The project manager distributes materials and provides 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 if the project is successful? What method or approach will be used in the project? What are the major dates or milestones for obtaining key points such as

Approval from business stakeholders? All of these questions relate to 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 project goals and the last two concerns the project methodology. Project objectives define the measurable goals of the project. Let's talk about goals in more detail.

Consolidate Project Goals Goals are an important lens of focus that you'll use throughout your project. They should be derived from the overall business strategy of the client company, so project goals should be aligned with the company's strategic initiatives. For example, if there is a strategic plan to target a new potential group of customers (called a market), the website or application you develop might attempt to provide that market with online access to related products and services. The goal of the project is to focus on entering and participating in this market. A clear purpose resonates throughout the project. It helps you ask the right questions when gathering ideas from business stakeholders. Plan studies with users and focus on analyzing results. Elaborate and translate ideas gathered from stakeholders and users

Consolidate into a comprehensive list of design requirements Prioritize those design requirements based on their value to the business

Determination of project goals


Create effective interaction designs Manage design change requests after development begins Focus efforts on implementation activities such as training and

Messaging users about the new site or application before and during the launch of the new site or application) Determine if you meet the needs of the client company, after

When you start a new project, you may have project goals from the project sponsor (the business stakeholder directly responsible for the success of the project) and a set of project-related requirements from the business stakeholders and the client, but they can both Somewhat vague (Figure 4.1). Your goal is to explain them with solid statements that you can use to measure the success of the project.

Project related requirements

corporate strategy fuzzy goals

Users need stakeholder ideas

red blood cells

Stakeholder Ideas for User Complaints

Figure 4.1 Unclear goals, ideas, and needs

Firm goals are easy to understand. Avoid confidential terms. Separated. Avoid ambiguous statements; instead, use phrases that indicate it

Useful when prioritizing requests. measurable. Make specific statements that you can set yourself

Measure your success. When you define a vague goal in a clear and measurable way, it becomes a firm goal upon which you can base your decisions.


Chapter 4: Project Objectives and Approach

Figure 4.2 Fixed target

Company Strategy Project Goals

You'll hear a lot of statements that could be considered goals. An ambiguity analysis like the one below will help you solidify your goals and communicate more effectively across the project team. commercial lawyer


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

This is a company-wide goal, but too broad for a specific project. To do this, it is necessary to combine many initiatives of the company; any website or application can help with this, but it is unlikely to handle the full load - unless your entire business is dedicated to that website or application and is a huge success . commercial lawyer


"Our goal is to evoke emotions in our clients."

This one is better because a website or app can affect it, but it's still too blurry. Why is it important to arouse emotions? How does this excitement translate into meeting business needs? How do you know if you are successful? commercial lawyer


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

Now we have reached our destination. This one is easy to measure, but focuses too much on intermediate steps. Assuming you're generating more traffic: if people don't take the desired action once they get there, it probably won't help you.

Determination of project goals


Vague goals can give you insight into your client's desires and larger goals. From there, you can set firmer project goals, such as increasing online sales revenue by 10%. Increase your online advertising revenue by 20%. Increase the number of existing and potential customers of our clients

Database increased to at least 20,000. Highly rated and frequently cited content for our key users.

(Note that it took some work to decide how to measure "highly rated" and "highly cited," but those elements are built upon.)

Each of them can measure and influence your project. They can also replicate your design and functionality very accurately. For example, it is very common to offer an online newsletter as a way to achieve the goal of increasing your customer database: to send a newsletter, you need to capture customer email addresses to add to your database. Goals may also be accompanied by new requirements. For example, if you measure success based on the average rating of articles on your site, you need a feature that allows users to rate. In this way, goals help you focus as you gather website ideas that can later become project requirements. If there are multiple goals, be sure to come up with a priority list with your business sponsor and project team. Goals sometimes conflict during the design process, and the team needs to know which takes precedence. The final list of prioritized 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 the 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 information on identifying relevant stakeholders). This meeting typically lasts two to four hours, and your goal is to gain information about your company's strengths and weaknesses,


Chapter 4: Project Objectives and Approach

opportunity and danger. Known as a SWOT analysis, it is a common business analysis technique and a way of discussing a company's position in the market. You can also use this time to talk about the company's competitors. Understanding SWOT Strengths and Weaknesses In a SWOT analysis, the company's current strengths and weaknesses with regard to the project. Strengths and weaknesses can involve 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 originally published research (power), but there may be no one to help make this content more accessible to ordinary users, leading to the impression that the company is "too academic" " (weakness). Identifying Opportunities and Threats OT is the forward looking part of SWOT. Given what makes a company stand out from the competition, what steps could it take in the future to create new niches or strengthen existing ones? What circumstances threaten these plans? For example, our R&D company might decide to hire writers to publish more accessible articles about their original research (an opportunity), but if the site's current toolset lacks robust content curation capabilities, the publishing process could be horribly slow . This can give competitors the opportunity to react (threats) more quickly. Comparing Competitors Who are the company's main competitors? Who are the competitors of the website you are building? They can be different, especially for larger companies or brand new sites. Are there any sites that aren't in direct competition but offer interesting models to consider? You can learn a lot by looking at other ecommerce sites to see if and how they sell what you sell. Combining SWOT discussions and discussions with competitors are good topics to discuss at the same time because they influence each other. Hard to say

Determination of project goals


Deal with future threats without knowing who your competitors are - When you start talking about future opportunities, new competitors may come to mind. Once you have a solid understanding of your company's competitors and SWOT, your project goals—and the project's overall alignment with company strategy—should be easier to define, and priorities between them should become clear. Determining project goals helps to understand what the project is supposed to achieve. Next, let's talk about expectations for how the project will run. Knowing the project methodology will help you collaborate effectively and get the right people on board at the right time.

Understanding the project approach Understanding the overall project approach or methodology is an important part of understanding when and how you are involved and how you should interact with others such as the project team and business stakeholders. Sometimes there seem to be as many design approaches as there are projects. How to choose a suitable project method is a big topic in itself. The approach you choose may 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 culture. For the purposes of this book, we assume that you join a project where the approach is largely determined by those responsible for the project's success, such as the project sponsor and project manager. In this case, your main focus will be to understand the approach and help make it work for business stakeholders and users. Here we'll focus on the two most common approaches, and a third that shows possible variations you might encounter in your project. Note that most approaches involve the same steps: planning the team's overall strategy, approach, and structure. Define design requirements. Design and translate interaction and visual concepts into details

Technical data. Develop, test and improve solutions.


Chapter 4: Project Objectives and Approach

Implement solutions through news, training and program releases. Extend the design by suggesting improvements.

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

Waterfall method The waterfall method treats each phase of the project as an independent, distinct phase that requires approval of one phase before the next phase can begin. For example, the design phase doesn't really begin until the requirements are approved by business stakeholders who sign off on one or more requirements documents at the end of the definition phase. agree with




Define project Development and implementation Expand

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

The problem with the pure waterfall approach is that it assumes that each stage can be completed with minimal changes to the previous stage. Therefore, if new requirements come up as usual during the design phase, changes must be proposed to the document approved at the end of the definition phase, which can disrupt plans and schedules.

Agile methods Because change is continuous, project teams are always looking for ways to be more agile than the waterfall model. Many approaches are based on a more fluid approach where some steps are carried out in parallel; for example, agile or rapid development methods could be used to release versions of a website in a rapid, iterative manner. Agile methods often place more emphasis on rapid collaboration than detailed documentation and formal approvals. Learn about design methods


Iteration 1


repeat 2


repeat 3


Implement Projects Implement Projects Implement Define Projects


define approval


Implement version extensions

Figure 4.4 Example of an agile method

True agile methods (e.g. according to best practices developed by members of the Agile Alliance) require small teams with members next to each other, with little emphasis on defining formal roles between team members. This way of working allows for a high level of collaboration, reducing the need for extensive documentation between design, development, and testing. Team members can ask questions, work out answers with other team members in a quick whiteboard session, and implement solutions without unnecessary delays in detailed documentation and approvals. When one of several iterations is released, the fully functional system is reviewed by stakeholders and the resulting input is considered when planning the next iteration. (An iteration is a blueprint for a particular website or application.) It's a beautiful thing when agile methods work as expected. However, in most companies and most consulting work, teams rarely use pure agile methods. This is partly because companies are increasingly using distributed teams and remote workers, making it difficult to maintain the high levels of collaboration needed to take full advantage of pure agile methods.

A Modified Approach Most projects try to take an approach that combines the best of both worlds, using enough structure and documentation to reduce the risks posed by distributed teams and changing team members, but enough collaboration and iteration to respond to change in a relatively agile manner. . For example, a project might follow the waterfall model but include overlapping phases so that there are key points of collaboration between teams. it allows


Chapter 4: Project Objectives and Approach

The underlying surface changes at each stage are earlier. It may also include early releases with shorter iteration cycles (such as beta releases for specific user groups). Feedback from this release may be incorporated before the new site is fully implemented. plan


development project



Development beta implementation

Implement version extensions

Figure 4.5 The modified beta waterfall chart

Note the minor design iterations in Figure 4-5. This is one of the greatest values ​​you bring to the team as a UX designer. Tools such as wireframing (Chapter 11) and prototyping (Chapter 12) allow you to gather feedback on rapidly iterating ideas before spending a lot of time developing them. A modified waterfall approach, such as the one in Figure 4.5, is one of the most commonly used 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 fundamental activities behind them, such as definition and design, will still be necessary.

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

Learn about design methods


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

With a pure waterfall approach, you will need to put in extra effort to ensure that the requirements covered 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 how project team members will work together

Cooperation will be close. For example, agile methods require very close collaboration. In most cases, the cascading approach can involve individual work, with one or several contacts per week. Required documentation detail and level

formalities. Documents submitted to the signing site must be formal, almost like a legal contract. You'll typically need a more formal documentation of the waterfall approach, where a signature is required, before moving on to the next stage. However, when using agile methods, you may also have some formal approval documents - for example, gathering information at major decision points, such as when preparing iterations for full release and deployment. Key Milestones Requiring Stakeholder Approval i

assigned to different groups. This approach will identify what different audiences need to deliver at different points in the project, including stakeholder approval at sign-off points and potential user feedback during testing. Now that you have set the project goals and understood the design methodology, in the next chapter we will begin the basic work of the definition phase: requirements gathering.


Chapter 4: Project Objectives and Approach


Business needs Understand the problem before creating a solution By the time the project team is assembled, you've probably heard or had a lot of ideas about what needs to be done. There may already be a list of features provided by some key members of the company (business stakeholders), along with their feedback on the most important features. These are elements of the project's business requirements and are a good place to start. To ensure a complete solution at the end of the project, you need to generate and interpret requirements from multiple perspectives. In this chapter, we will focus on gathering and detailing the requirements of business stakeholders. Carolina Chandler



Chapter 4 covers ambiguous goals and discusses some ways you can clarify them for yourself and your project team. 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 make these useful and traceable project components your project, you need to combine these ideas into requirements. Requirements are statements that tell you what your website or application should do. Ideally, Business Requirements Provide insight into the overall needs that need to be met Represent and integrate requirements raised by different stakeholders Give direction to the project, but not be too specific about how the project will proceed

Completed Prioritized and tracked as a single unit of work

Here is an example of a feature idea on an e-commerce website. At the beginning of the define phase, you might get the same idea from several different business stakeholders: "Customers can track their orders online." This is a good basis for the claim, but it's vague. Start asking questions that lead to details of requirements, such as why it is important for the company that customers can track their requirements

online order? For example, is it to reduce customer service calls? Does the company currently have the ability to track shipments online?

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

Should it be included in tracking details? For example, does the website have to provide updated estimated delivery times? Asking questions like these will help you connect vague ideas with concrete needs. You will also realize that the same statement can mean different things to different people.


Part 5: Business Requirements

For example, a stakeholder might think that tracking a package involves receiving a confirmation email. The stakeholder's idea is that a tracking number can be entered on or another website so that the customer's stakeholder can see where the package was last delivered. Idea Another stakeholder might think that the company should expand its package tracking and invest in GPS tracking customers, using online maps to see their exact location in real time. As you can imagine, there is a significant difference in user experience and scope here! It is important to emphasize these differences early in the project. Otherwise, you'll end up developing a solution that goes against the intent of your business stakeholders - and possibly against your project goals. This leads to unhappy stakeholders and wastes time and money if the feature needs to be redesigned. Therefore, clear and detailed requirements are a key part of the overall project. Deriving a comprehensive list of project requirements involves the following steps: 1. Know the current status of your site or its competition. 2. Gather the needs and ideas of business stakeholders, as well as current and potential users. (See Chapter 6 for details on working with users.) 3. Assemble ideas into requirements. 4. Prioritize requirements based on project goals. (See Chapter 9 for advice on prioritization.)

Business Requirements and User Projects Requirements Corporate Strategy

Figure 5.1 Combines ideas from business stakeholders into business requirements and ideas from user research into user requirements. Project goals are then used to determine priorities 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 context of the ideas that came up when you were gathering requirements.

Understand the current state Know the current state of your website (if you are redesigning an existing website) or better understand your main competitors (if you are designing a new site) when learning the details of the website or application you are designing or application). Stakeholder interviews can reveal a lot about the current state of affairs (more on that in a few pages). You can also gain a lot of understanding yourself, which can serve as a solid foundation for stakeholder interviews and user research. A good way to get some background information and generate ideas that can become requirements is to do a heuristic analysis.

Another name... the word heuristic means rule of thumb or best practice. Heuristic analysis already means reviewing a product against a set of user design rules (heuristics), usually performed by a UX designer. A user-friendly page will follow 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 do this analysis on your current website at the beginning of a remodel project, or you can analyze a competitor's website for opportunities to provide a better user experience than other companies. The result is a document outlining your site's strengths and weaknesses, including suggestions for improvement. When you're done, you'll have a deeper


Part 5: Business Requirements

An understanding of the site being analyzed and a list of ideas to help develop new site requirements. For example, one commonly used heuristic is Jakob Nielsen's List of Ten Usability Heuristics (see the complete list on Jakob Nielsen's website at

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 situations on a website that might not follow this heuristic. For example, suppose a user clicks a "Download" button but does not receive a message that their file is being downloaded. The user is not notified that the file is being downloaded even though the download has already started. So the user can click the button again, thinking they missed it the first time... and then click again... which could result in multiple downloads - possibly causing performance issues with the page and the fact that multiple downloads are now taking place users, unknowingly. During heuristic analysis, you can note them as problem areas, describe them and evaluate their effects. You can also share ideas that can solve a problem, which can be added to the request list. Why do heuristic analysis? Conducting this type of analysis is a relatively quick and inexpensive way to get feedback on a project. Heuristic analysis can provide a comprehensive understanding of design quality and help identify potential design issues. Note that this activity does not directly involve end users and should not replace actual user research. For example, only 50% of your heuristic results may be validated in follow-up research. However, the analysis gave the team a good idea of ​​areas of possible interest. If you're redesigning an existing product or website, it's also helpful to identify obvious quick fixes that can improve immediately while the redesign is happening behind the scenes.

understand the current situation


how do i do it The exact heuristics you use may vary from project to project, but the analysis process is basically the same: 1. Gather product and project knowledge. Make sure you have site goals, a list of the main user groups that need support, information about the types of environments the users might work in, and a basic understanding of the expertise the users might have. (Your analysis will be different for a site built for general consumers versus a site built for pharmacists.) If you need help with the latter, visiting various competing sites or apps can help you understand the most common Terminology and Area of ​​Interest. 2. Select the heuristic you want to use. There are many heuristics that can be invoked. In addition to Jakob Nielsen's list, many UX designers refer to Bruce Tognazzini's list of design principles: Once you know what your site is about, you can add some of your own, especially if you have multiple sites to analyze. Make sure the list is a reasonable size (say, 8 to 12); too many heuristics can make the technique difficult for you and your readers to use. 3. Go through the priority areas of the page to identify areas where the heuristic is honored or ignored. Each observation should contain the following information: General observations. A short statement summarizing the findings. Ideally, they will be numbered so you can quickly refer to them when viewing reports. short introduction. A paragraph or two describing the context of the observation - for example, the point in a particular process where you noticed the problem. affect rankings. For discovery issues, this rating can be high, medium, or low, or it can be a positive discovery record if you're sharing something your site does well. Typically, a high-impact issue is one that you think will prevent multiple users from completing a specific task or


Part 5: Business Requirements

Permanent loss of data (for example, problems with users losing changes to documents they were working on). Medium-impact issues are those that cause frustration and errors, but not unfixable problems. Low-impact issues are small issues that can cause some confusion, but usually don't cause time or frustration. suggestion. These are next steps or ideas that you share as a remedy for a problem you're experiencing. Figure 5.2 shows an example of these elements appearing together in a heuristic analysis. Observation #4 The search function doesn't seem to return all possible results.

highly anticipated

Tests of the pattern search functionality have yielded mixed results. Searching for an infrequently discussed topic by last name in a relatively new post sometimes returns no results. Also, basic searches only seem to return links to new articles, not videos. Recommendation 1. Make sure newly added content is indexed and searchable shortly before or soon after it is publicly available. 2. Consider showing related content when refreshing search results—for example, articles in similar categories or with similar tags—so that research users have multiple threads to follow. 3. Consider a universal search that displays results organized by category. 4. Use the search term log to know frequently searched items. It also provides insight into items that are difficult for users to find.

Figure 5.2 Example of Observations in a 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 grade for what you did. (This is also a good time to suggest how to validate your findings using one of the techniques discussed in Chapter 6.) How does heuristic analysis help gather requirements? Once you've completed your heuristic analysis, you'll have a deeper understanding of the current state of the site (or its competitors) and a list of ideas that can help gather requests. You'll also have some ideas on how to organize the topics that need to be covered during the requirements gathering meeting - which brings us to the next step in the process.

understand the current situation


Gathering Stakeholder Thoughts 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 might miss out like our friends who want to track Differences in stakeholder expectations for parcels with GPS. One of the most common design mistakes is calling a feature a requirement without first understanding the problem and anticipating the solution. So why is the claims collection process often cut short? Gathering ideas—and combining them into requirements—can take a long time. It's easy to underestimate the number of questions that need to be asked in order to outline requirements in order to prioritize them. If the process is not well organized or the participation is incomplete, many changes may continue throughout the project. (Abandonment is the time wasted in additional meetings and rework due to lack of communication and commitment. This is different from the more productive rework of designing and testing working solutions to find the best one.) Encourage balanced needs to focus on business needs But avoiding time-wasting processes? Here are some steps of an effective process: 1. Outline roles and responsibilities. Make sure project team members understand their role in the requirements gathering process. 2. Bring the right stakeholders into the right groups to ensure the best use of time during needs-driven interviews or meetings. 3. Create a meeting agenda, including topics to be discussed and questions to ask during the meeting. 4. Lead meetings effectively by gathering ideas and clarifying questions. Explore ideas and explore the needs behind each idea. At the conclusion of the meeting, remember to thank the relevant stakeholders and update them on your progress as you progress towards the consolidated priority list. Let's take a closer look at each of these steps.


Part 5: Business Requirements

Responsibilities Overview Business requirements gathering activities typically involve project team members interviewing key business stakeholders to gather ideas. A business stakeholder is someone within the company who has a business-oriented interest in the project's success, or who has significant knowledge to contribute, or both. These people are not involved in the project full-time, but they need to be involved in key points of the process, and requirements gathering is one of them. Remember, they also have day jobs (so to speak), so their time is precious and often hard to come by unless you plan ahead. Project sponsors are business stakeholders who are also directly responsible for the success of the project and are usually at a relatively high level within the company, such as a director. He will not be associated with the project on a daily basis throughout the project lifecycle, but may be actively involved in gathering requirements and ensuring a high level of engagement from business stakeholders. The sponsor can also participate in some or all of the meeting. The project team consists of people who are formally assigned to the project as current resources. They can be involved as project managers, UX designers, business analysts, technical managers, visual designers, quality assurance managers, and more. Depending on the size of the project, this may be their main task. Within the project team, responsibilities for the requirements gathering process are often unclear. Taking the time to define responsibilities early on will help ensure an efficient collection process. When determining the specific responsibilities of each team member in collecting requirements, some questions to ask are: Who is primarily responsible for collecting and planning appropriate requirements

Presence of stakeholders among the most productive groups? This can include internal and external stakeholders (eg partners, suppliers, etc.). Who creates the structure of topics and issues for stakeholders

Owner meeting? Time permitting, this is a great collaborative exercise for the team. The primary moderator can then organize these into a structure that works well in meetings. Who chairs the meeting? Who takes notes and how are they shared?

Gather ideas from stakeholders


Who chased whom later? Will someone from the technical team be present at all meetings?

If yes, how was that person involved (listening, contributing, or otherwise)? As a UX designer, whether you are primarily responsible for one or more of these areas, you have important skills that you can bring to the process. Structuring topics and questions requires the ability to clearly categorize (this sounds like a good link for information architecture), and of course facilitation skills are important to have a topic session where all participants are involved.

Gather Relevant Stakeholders The main purpose of stakeholder interviews is to understand project-related ideas, needs, knowledge, and frustrations from different perspectives, and then incorporate them into project requirements. There is also sometimes an unspoken benefit of involving many different groups so that they each feel like they have a say in the project - and thus buy into the final solution. While getting people involved to gain their support may seem more political than practical, it is often a critical step in getting you in touch with a network that will support you throughout your project. It also helps you avoid an 11th hour shift, which can happen when someone you didn't talk to asks a question later in the process. So it's usually a good idea to get a lot of different people involved. On the other hand, you have to pay attention to your schedule and budget. Getting lots of people involved in the meeting itself takes time, both from their perspective and yours—not to mention taking notes to identify trends and incorporate layoffs. To improve productivity and your own mental health, prioritize the groups you want to talk to and select key individuals from those groups to serve as thought leaders for your team. Which potential stakeholders can you reach? These groups are often a good source of ideas: Groups that develop initiatives for individual places (for example, z

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


Part 5: Business Requirements

Groups that need to support flow directly behind the page or

Applications, such as content delivery, data entry and management, and immediate response to information collected First-line customer service, such as telephone or online support or

Anyone who has direct contact with customers (for example, retail or via delivery) Sales, product management or consulting services, representatives

Featured products and services Human resources for recruitment purposes Public relations for informing investors and media All teams responsible for other relationships to be developed

As part of the project, this will affect their projects, such as relationships with partners or suppliers. In choosing who to include, the help of the project sponsor and all members of the project team who understand the groups involved should be sought in order to select the right people. Create groups that will start good discussions. There is no one right way to do this, but a common way is to group stakeholders by department, for example: Marketing (five people) Product Management (four people) Customer Service (two people) Sales ( four people)

A smaller project might involve one person from each group participating in a series of two or more collaborative work sessions where everyone gets together. With stakeholders in mind, as well as the general meeting structure (discussed in the next section), you can start scheduling meetings. Try to start planning at least a few weeks in advance; getting everyone in the room together can be difficult.

Gather ideas from stakeholders


Create an agenda While selecting the right stakeholders, create a list of topics to bring up and questions to ask (this will also help round out the stakeholder list). You should have a different plan for each group you meet, although some of your questions may be the same across groups. You'll also need to decide what level of detail you want to go into during the meeting. If you're only meeting with lots of people once (eg, with members of different departments, as above), you'll want to gather ideas, but you probably don't want a meeting that spends too much time on the details. In this case, if one of your stakeholders comes to you with the idea that "customers can track their orders online", you can simply ask yourself why this feature is important, and whether the stakeholder can immediately think of one Well done site. These questions should help identify key differences between stakeholder expectations for the feature without devoting the entire meeting to one announcement. You can then work out the details of the idea with the project team, talking to stakeholders to ensure that the resulting requirements still reflect their original ideas. Let's say you're redesigning an e-commerce website, and you're meeting with many different stakeholders, with each group holding a meeting. Below is an example agenda for a meeting with a group of people in the sales department.

Sales: Requirements Gathering Session Participants Internal Sales: Jenny Bee, Tracy Kim, Joseph Arnold Leads: Kevin Abernathy, Cat Parnell Timeframe: 2 hours Objectives: Understand the current sales process and identify issues and opportunities to better support the process The Web. Background: We reviewed PowerPoint presentations on the buying process that provide a good background for making buying decisions. We also plan to speak with the customer service team.


Part 5: Business Requirements

Sales: Follow up requirements meeting questions Sales Process: How does the sales process differ for different product lines? Are there regional differences? Are there any differences depending on the size of the client (e.g. small business vs. large enterprise)? How has this process developed over the past two years, and how is it expected to develop in the next three to five years? How does a potential customer understand all the things they need to buy and how do they all work together?

Overall Impression: Who do you think the main users of the current website are? Why? what are they like What are they trying to achieve on the site? How does the internet currently contribute to the sales process and/or closing rates? What information do customers need to make a purchasing decision? Is this information available on the website today? Is it easy to find? is it right? How hard is it to maintain content on a website today? What metrics are you getting from the site? What other metrics do you think are valuable? Why?

Future Vision: When considering a future website, what can we do to better support the sales process? Which features and functions of the current website are critical to sales? What is unnecessary? What is missing?

Summary: Are there any other thoughts, suggestions, or concerns that we haven't addressed? Which sites do you think provide good sales support? What is the most important thing a company can do to improve customer satisfaction?

Gather ideas from stakeholders


Run meetings effectively Here are some practices that can help you during your requirements gathering meeting. Ensure use of a common glossary Many misunderstandings can be avoided if the requirements team agrees on a list of common terms and definitions. For example, will people who use the system be called users, customers, or customers? Are people more familiar with the terms interaction designer or information architect? To avoid confusion, take some time at the beginning of each meeting to identify the terms that are being used and what they mean. You can also benefit from creating visual elements that help explain the relationship between different concepts or roles (see Figure 5.3). category












Figure 5.3 Diagram Showing Conditions and Relationships in a Project

A common deliverables vocabulary used throughout the project will also help stakeholders understand the process and the types of deliverables they can expect. This reassures them that their time and energy will not fall into a black hole of ideas. In general, if you find yourself defining the same words multiple times (especially if the definition changes slightly each time), consider including them in the project dictionary and sharing them with the project team. Other examples of terms appropriate to explain at the beginning of a project include:


Part 5: Business Requirements

The roles that will interact (e.g. job applicant with client or

tent makers and editors) will be widely referenced for the basic results (functional specification

, mockups, sitemap) and a brief description of the differences between them Differences between different levels of information (such as our category

See Figure 5.3) Differentiate between needs and ideas

Listen to ideas and ask for information about needs Stakeholders can make statements that appear to be needed. Consider an example. commercial lawyer

"We need a blog on the site."


This is really an idea, not a need. If the blog's functionality is then fully designed and implemented, it becomes a solution, but not necessarily the one that best meets the basic needs of the stakeholders who are looking for it. By asking why blogs are important, you can get broad-ranging need statements such as “We need action that is relevant and connected. Everyone is talking about blogs, and I feel like if we don’t include them, we’ll be falling behind.” “We There needs to be a way to keep people coming back to the site to generate more ad revenue, and a blog means fresh releases satisfy followers.” “We need to position ourselves as thought leaders, and blogs are a more personal way to showcase our expertise way.” “We need to have better ways to communicate and innovate with our customers, and through blogging we can get reviews so we can hear from them.” Each of these statements describes a significant need. By presenting them, you'll understand the drivers behind feature requests, which will help you reach consensus when merging and prioritizing requests.

Gather ideas from stakeholders


After the Merge Requirements meeting, break down the ideas gathered into general functional areas. You'll start to notice a lot of overlap; this is a good sign that the idea has strong stakeholder support. Eliminate redundancy and try to put together a list of ideas that effectively captures stakeholder intent. In order to turn the collected ideas into useful, traceable project components, you must assemble these ideas into requirements. Imagine raindrops forming from a cloud: you go from a large, blurry cloud to clearer raindrops. So when you get ideas like "customers can track their orders online", you have to turn those ideas into separate statements of what the system should do. The resulting requirements should provide insight into the overall needs that need to be met. Represent and integrate reporting needs from various stakeholders. Determine the direction of the design without being too specific about how it will be implemented.

Prioritize and monitor almost as a single unit of work

As you start moving from ideas to requirements, make sure your tech lead (or someone else who may represent your project's development team) is involved in asking questions to help you gauge the effort required when prioritizing later. If you have a dedicated QA team member, that person can also ask some very specific questions to help you organize your claims. To refine the idea of ​​traceability in requirements, ask the following questions: How precise does traceability need to be? What information should be included in the trace details; down

For example, should we provide an updated estimated delivery time? These questions can be asked and discussed in detail with stakeholders if they have significant time to devote to the project. If you do not have access to these stakeholders, you can work out the details yourself through discussions within the project team


Part 5: Business Requirements

Then review the requirements with the project sponsor to ensure your selection makes sense for the company. Table 5.1 lists the types of requirements relevant to the concept of traceability and how they are covered. Table 5.1

Examples of business requirements

ID card



order tracking



order tracking

order tracking


Business needs

Orders can be tracked by

Encourage self-service

enter tracking code

During delivery (support



Users can track their packages

Demonstrate the power of innovation

GPS age, truck tracking

Fast delivery (competitive

or airplane


Users can view all incentive reorders and orders placed in the past 365 days

Self-Service (Sales, Support Benefits)

Note that in some cases requirements overlap, such as the first two requirements in the table - both trace methods. They can co-exist on the same system as you can enter the code to find your package in GPS view. However, they are separate as GPS requirements may require more effort and should take precedence over other features. When merging lists, be mindful of business needs that you think might conflict with user needs. For example, a business request might be to collect personal information from potential customers, such as their email addresses. However, users may have reservations about providing information. After all, filling out forms takes time, security and privacy are concerns, and the step can interfere with the larger task they're trying to accomplish. Once you identify these conflicts, it will begin to provide you with ideas that can help you meet the needs of your business and your customers. In the tracking example, you could suggest a "send to a friend" feature to capture email addresses and provide a user experience. This means that the send-to-friend feature can be a condition for your entry into the priority group. such thoughts

Gather ideas from stakeholders


They can help meet business and user needs, making them ideal for recording. They are also in the overlap area between the definition and design phases (see Chapter 4) when you start thinking about designing solutions to business problems.

Defining potential conflicts between design development business needs and users is an important element to explore in user research, which we will cover in the next chapter. User research also extends Table 5.1 to the full set of potential requirements that will be prioritized in the design requirements list (shown in Figure 5.1 and discussed in more detail in Chapter 9). Don't forget that gathering business requirements usually happens at the same time as researching technical possibilities and gathering user requirements. Next post: Time to talk about users!


Part 5: Business Requirements


User Research Know Who You're Inviting To The Party There are many user research techniques that you can use throughout the project lifecycle to better understand your users or test their behavior on different versions of your website. In this chapter, we'll focus on some of the most common methods used in the early stages of a project. These techniques will help you define the user groups that should be given the highest priority during the project, put their needs and frustrations in context, and evaluate the performance of your current site (if any) using best practices in UX design. Carolina Chandler

Basic steps of user research 1. Define the main user groups. This involves creating a framework to describe the main types of users you are designing for, allowing you to focus on recruiting users for research. 2. Plan user engagement. This involves engaging user groups in research by selecting one or more technologies based on the needs of the project. 3. Do your research. Here, we'll cover basic techniques like interviewing and surveying, and give you tips on how to do it. 4. Verify that the user group definition is correct. Using what you learn 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. Generate a user request. These are lists of features and functions that a page can contain. You'll 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.

Defining Your User Group Planning user research at the start of a project can seem like a chicken-and-egg dilemma (chicken or the egg?). How can you be sure you're talking to the right person if you don't already know who those people are supposed to be? One way to start is to create an initial or temporary definition of the users you want to design for. It describes your site's primary user groups, which can help you focus your research efforts on the right personas, demographics, or other variables that may affect how users use your site. User group definitions can be advanced (defining a list of each target user group) or detailed and intuitive (diagrams showing multiple types of users and their interactions).


Chapter 6: User Research

A general definition of a company's primary .com site might include the following user groups: potential customers, current customers, partners, and job applicants. When you start defining user research groups, you'll start to prioritize user groups in more detail. Your initial definition is based on the collective understanding of business stakeholders and project team members about the types of potential users who might interact with your website. These definitions can be built by gathering some of the goals and attributes that different groups of users might have. Here are the basic steps to define a user group: 1. Create a property list that will help you define the different users of your site (we'll cover some of the more common users in the next section). 2. Discuss these attributes with the people in your company who are connected to the relevant type of user (eg customer). 3. Prioritize those attributes that seem to have the greatest impact on why and how potential users use your site or app. 4. Define user groups to focus on in your research and design. In the next sections, we'll take a closer look at some brainstorming techniques to help you gather these attributes and how to prioritize and model them (creating representations of different types of users to help you focus your research efforts).

Creating a Property List A good start in creating a property list is to gather and incorporate any research or other organizational documentation that might provide user guidance. Some possible sources are: Documents explaining company strategy, such as company goals,

Small information, marketing strategy and business plan Market segmentation of existing customers and other demographic data

Marketing collects past user research (example see Table 6.1)

Define your usergroup


Surveys such as customer satisfaction surveys and feedback forms Customer service reports covering frequently asked questions

Next, identify people in your organization who have some insight into current or potential users. The number and types of people involved depend on the type of project and its scope and timing. If you know that the user group you initially define will likely be short-lived (e.g. only used for a month or two when planning user research), then you can include only two or three participants. If you think the initial definition may need to guide you through most of the design process (for example, if you only have that definition until usability testing after the project is complete), involve more participants and make sure you have a cross-sectional view. Some potential participants are marketers responsible for brand representation, segments, and campaigns; salespeople; product managers; customer service or support representatives; and coaches. It's also a good idea to involve project team leaders and other business stakeholders in this exercise. Have the group think about the different types of prospects they typically interact with. Then have them list some common traits they encounter. Here are some examples of changes: Main goals related to the theme of the site. Why

What do users want to achieve when they come here? For example, buying merchandise, trading stocks, or getting answers to specific questions are all common goals. Role. This can be defined in a number of ways, but one way is to combine roles with

The main target of the user: job seekers, help seekers, potential customers, etc. When you have more user information, personas can be segmented based on different needs or styles; for example, on an e-commerce site, customers could be bargain hunters and connoisseurs. Demographic information, including age, gender, household (single, married, children),

Income level and region. Experience, including level of education, level of relevant knowledge

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

Chapter 6: User Research

Organization attributes, including the size of the user's company

For their department, job type (entry-level, freelance, middle management, executive), length of service (long-term or high turnover?) and work pattern (remote work, number of business trips). Once you have a list of some of the attributes that come up most frequently when stakeholders describe potential users, you can start prioritizing them by level of importance, and then use this hierarchy to define and model groups of users.

Prioritize and define which of the above features do you think will have the greatest impact on how and why different user groups can use your site? Focus on those factors that you think will have the greatest impact on user goals or behavior. Prioritize these attributes and keep in mind the goals you set in Chapter 4—they will also help you decide. An example best illustrates how attributes are prioritized. Let's say you work with a company that provides online trading tools for stocks, options and futures. This particular company decided that part of its strategy was to get non-professionals involved in online stock trading 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 aimed at those looking for hands-on learning in a safe environment. When discussing attributes with your business stakeholders, you may find that the following attributes have the greatest influence on how individuals use these tools: Current transaction frequency, especially direct online transaction frequency

(e.g. quarterly, daily, several times a day). Those who are just getting into trading (say, once a month) may not be serious about trying new things, and those who are already trading full-time may not find much value in tools aimed at new traders. But those active part-time traders may be very interested in the company's tools. Number of product types traded: stocks only or stocks, options and

forward contract. Those who already trade all types of products may already love their own tools, but those who only trade one type may be ready to expand into others. Define your usergroup


The level of knowledge on the subject (e.g. trade knowledge

situation). This will help determine how much help they need with the process, including guides and glossaries. Level of technical knowledge (for example, knowing how to shop

online and online banking and commerce). This will affect how assured they are of information privacy and how advanced or simple the web interface needs to be. You can prioritize these attributes because they affect the type of users you'll be targeting. If where traders live doesn't seem to have a real impact on how and why they trade, the regional attribute might drop off the list as a note to research participants. On the other hand, if a feature's importance generates a lot of discussion, it might be a good topic for a survey or interview question (we'll discuss surveys later in this chapter).


Comparing two or more properties can also help with prioritization. For example, if you create a dual attribute chart for an online retailer, you can start looking at groups within a specific range. Figure 6.1 is an example of a rough user model that can be constructed using the two attributes of direct transaction frequency and number of product types traded; it also shows the end-user groups that can emerge from discussions.

Full-time Product Specialist

Experienced full-time generalist

Direct transaction frequency

Other commercial traders.

traders with extra income

active researcher

long term investor





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


Chapter 6: User Research

Figure 6.1 shows the display of two attributes of the approximate user model. Building this model together can facilitate discussion of possible differences in user motivation and experience.

This user model provides a generic way to talk about different types of users. It is not a definitive model, nor does it apply only to user groups (users can be long-term investors in stocks, or actively exploring other options or future possibilities). But it starts to express your understanding of different user groups and how they might be motivated to use your site. This discussion of important attributes will also help you discover which attributes to focus on when recruiting users for research. If you believe that transaction frequency is important, and you would prioritize recruiting those whose current frequency is average, you should define what you mean by average 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 engage users in your projects.

Is it possible to design based only on the user model? In the UX field, there is an argument about creating user mockups before research, because it can change mindsets before you have real user data, and also because project teams or project sponsors can see mockups as substitutes for user research. Using an untested model puts your assumptions at greater risk of being wrong. However, on a project where you won't have any contact with users at all, a well-designed model (validated by sources outside the project team, such as customer service groups or training groups) is better than no model used at design time.

Choosing a Research Technique Now that you have a general idea of ​​the user group you want to reach, it's time to plan the next step: making recommendations on the amount and type of user research activities to be conducted during the project. Table 6.1 provides information on the most commonly used research techniques and the situations in which they are most useful. Use this table as a reference to choose the ones that are best for your project. The next section describes each technique in more detail.

Choice of Inspection Technology


Table 6.1

Typical User Research Techniques


what is that

when is it useful


Typical Time Frame *

user interview

One-on-one conversations with participants who belong to one of the site's main user groups.

There is user access, but the type of access (in-person, phone, etc.) varies.

Get direct feedback. Gathering information about attitudes and context can be difficult, especially when interviewing remotely.

2-4 weeks for 12 interviews: up to one week for planning, up to 1-2 weeks for interviews, and up to one week for gathering results.

Contact information

Take a field trip with participants to observe and understand how they function in normal day-to-day settings.

The design team gets small information about the participants. Let's go to target users. The user's environment may raise concerns about the intellectual safety of users working in unique environments such as hospitals. Property, Intruders work intensive. In a business with fairly complex applications, these are tasks or workflows. It might be easier to visit on a weekday.

3-4 weeks 12 queries: 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 designed to identify patterns in large groups of people.

You want to present the results in a quantitative way (eg "80% of the target user group said they never buy a car online").

Short-term surveys of 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 you can't go to the user.

You're more interested in gathering information about preferences than actual performance.


Chapter 6: User Research

Get the right samples. Make sure the questions are well written so that you get the right answer without forcing the respondent to give a specific answer.

Table 6.1

Common User Research Techniques (continued)


what is that

when is it useful


Typical Time Frame *

research group

A group discussion in which the moderator guides the participants through questions about a specific topic. It focuses on discovering participants' feelings, attitudes and thoughts on a topic.

The team believes that user attitudes can have a strong impact on solution usage (e.g., whether problems have occurred in the past).

Learn how to ask direct questions to get the right information.

3-4 weeks: 1 week for planning and writing questions, 1-2 weeks for conducting focus groups, and 1-2 weeks for analyzing and presenting results.

card sorting

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

You are working on a content source site with multiple elements and you need a valid user group structure.

Identify topics that are best covered.

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

usability testing

Users try to perform common tasks on a website or application, and moderators observe and in some cases ask questions to understand user behavior.

Existing solutions have been improved.

Choose the right task to focus on.

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

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

Effective group support.

Determine how formally the test will be conducted.

*Typical timelines represent the time it typically takes from scheduling a user's time. Assume there are two groups of 6 to 8 users (except for surveys, where the number of users should be higher). This does not include recruitment time, which may take one to two weeks after the screening questionnaire is created.

How much research activity can I include? Before choosing an activity, ask yourself how much money and time your team could spend on user research. Consider the following scenarios to understand your client company's interest in user research. If project managers and project sponsors enjoy user research and are interested in using it for a known purpose, such as making sure the site meets stated project goals, you may be more free to choose research techniques


When two or more activities are scheduled or an activity is performed multiple times (for example, to test an item, make changes based on the results, and test the new item again). If no one in your organization is familiar with user research and has some resistance to it, it's better to come up with a round of research and choose the technique that you think will bring the most value to you, your project team, and your team. business stakeholders. Once the research results are in place, the project team will have a better understanding of what this entails and what benefits the project can bring. You will have good reason to do further research at a later date if necessary. If you have room for at least two rounds of research, it is best to include a round early in the definition phase or design phase to get to know your users better. Then run another round to check the design before starting development. For example, for a task app, you can interview users before designing, then usability test the prototype later in the process. Or for a content source, you could start with a contextual query and then include a card sorting exercise.

Research Planning Considerations When planning any research technique, the following factors should be considered: Why do the research: What do you want to learn from it Your research subjects: The main user groups you identified above How to recruit participants: Recruit people to participate and screen They (i.e. ask questions (to make sure they belong to your target user group) How do you reward participants What space and equipment do you need What you cover: Main topics How do you gather information: Quantity People involved and the tools they use Chapter 13 Each of these issues will be covered, delving into one of the most common techniques used by UX designers: usability testing.


Chapter 6: User Research

Note See Chapter 2 for more information on task apps and content sources.

Surfing Steve Baty has written an article detailing the different approaches and how to choose them based on your stage of development, your information needs, and the flexibility you need to enable user research. It's titled "A Bite-Sized UX Study" by Steve Baty, UXmatters:

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 location such as a conference room, or ideally in an environment where users are likely to use the site. (The latter case is also well-suited for background research discussed below.) Interviews are useful for understanding participant preferences and attitudes, but should not be used to make formal statements about actual results. If you're looking for specific information about how people interact with your site, it's best to observe how people use your site (for example, in contextual queries) or ask them to complete tasks on your site (during usability testing). Website analytics can also provide insight into certain performance information that may be particularly relevant when combined with interviews or inquiries that provide context for the data. Basic Flow For user interviews, UX designers create a list of questions to gather information such as: Experiences related to the site or topic

Choice of Inspection Technology


Participants’ perceptions and attitudes towards the company’s brand, e.g. according to the category of topics discussed (for

tent source), design process (in the case of a mission application), or marketing method (in the case of a campaign) a common goal or need to bring users to your site or website

Competitors Typical next steps users take after visiting a company website Other people involved in the experience. Is it for example a

Users tend to collaborate with other people as part of a larger goal they're trying to achieve? Will they share information or seek input from others along the way? Any other information that would help confirm the hypothesis

Regarding user groups so far - for example, whether the variables discussed in Creating the Temporary User Model actually seem to affect how users use the site. If interviewing more than one person, it's a good idea to prepare a list of questions and an introductory script, which can be used to maintain consistency between interviews. Decide in advance how you want to structure your interview. If you want a formal report, you'll probably want a highly structured set of questions where the order of the questions doesn't vary much, and with some appendices for each question. If richness of the data is more important than consistency, you can opt for a semi-structured interview, starting with a series of questions but letting the conversation flow naturally, with the interviewer asking questions to further explore interesting comments (callout). The length of the interview can vary; 45 to 60 minutes is usually the best time to shoot. It allows for ample time for relationship building and discussion of a wide range of issues without tiring out the participants. Customer 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 the information you get in an interview depends largely on the quality of the questions you ask. Focus on the personal experiences of the participants. Don't make them guess what they might do in the future or what other people might do. This type of information rarely predicts what they will actually do. Do not ask questions that imply a specific answer, and do not lead participants in a positive or negative direction. Ideally, questions should be simple, neutral and open-ended. Here are some examples of leading questions: What do you like about

Assume that users enjoy using the site. Use this question only if you're also asking what they don't like. Did meet your expectations?

This can be answered with a simple yes or no, which doesn't give you much detail to help with your design efforts. Instead, use or

If the latter, why do you think they are better than Pseudo? This has several problems: it asks two questions in one statement and forces participants to assume one opinion. Best questions to ask are: Tell me about the last time you visited why did you go there What is your impression of this visit?

If you are conducting a more formal, extensive interview, you may wish to include some multiple-choice questions. However, most of them don't provide much information. Participants may have difficulty understanding when asked verbally, and users are not allowed to elaborate. Typically, such questions are left to reviewers or investigators. Test with someone, such as someone in your organization who is not a core team member. This will help you spot issues that may not have been clear, and clarify time and mileage. If possible and with the participant's consent, record the interview so others can benefit from the participant's verbal responses.

Choice of Inspection Technology


Contextual Research Contextual research combines user observation and interview techniques. A UX designer goes to the participants, preferably to the context in which they are likely to use the site. For example, for an office application, contextual prompts ask you to sit at a participant's desk. This approach provided a wealth of information about the participants' work environments, including the real-world problems users faced, the types of equipment they used, and the spaces they worked in—especially the amount of space they used

How much (or little) privacy they have, how often they are harassed, and how they use their phones and paper (pay special attention to any printouts they post or notes they keep handy). Their mouse and keyboard usage settings. it makes a big difference

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

resource. For example, if more than one person uses the same computer, this will affect login design and security features. Other tools they use both online and offline. how people use paper

Especially interesting - for some tasks it can be difficult to design an online solution that competes with a paper solution! Surveys combine observation time and interview time. They can last from hours to days. If the participant cannot spare at least 2 hours, consider simply conducting the interview. During the observation, the participant needs some time to adjust to your presence and behave naturally, and this does not happen after only 15 minutes. Basic Process Prepare a 10-15 minute introduction that you can use in your conversations with each participant. It should include the purpose of the survey, a general description of what you will do together (observations and interviews) and how

Chapter 6: User Research

Information will be used. This is also a good time to gather signatures on the consent form and assure participants that what they share will remain private. Start with some general questions about the flow of common participants, especially related to site design. Let participants know when you are ready to stop talking and start observing. Observation can vary from active to passive. In active observation situations, a common practice is to have the participant take on the role of the master and you play the role of the apprentice. The guru explains what he's doing as if he's teaching you his process. Active observation often provides more information about why participants behave, but it can affect their work. In passive observation, you encourage participants to act as if you don't even exist. Your goal is to observe behavior that is as natural as possible. For example, if a participant is talking to you, they are less likely to answer the phone or ask someone a question about a problem they are trying to solve, but you are more likely to see this happen if you are passively observing them. You can then continue that part of the interview by asking questions about the reasons for certain observed behaviors. Both methods work fine. In general, if you do not spend a lot of time with participants (say only 2 to 4 hours at a time), you can choose to actively observe to make sure you get the information you need. If you have a full day or more, passive observation can be a great balance between natural behavior and discussion. Once you've got the information from your queries, you'll have a lot of rich data to wrangle! So how do you identify patterns or trends in your results? One useful approach is a technique called an affinity graph. There are many great resources available on the topic, but here's a quick overview. A Quick Guide to Affinity Diagrams Affinity diagrams are a technique that takes many different and independent items, such as user statements or researcher observations, and combines them to create patterns and trends. Here are the steps for a simple affinity graph session: 1. Bring the survey team together and attach their notes.

Choice of Inspection Technology


2. Give everyone a pack of Post-it notes and ask them to write a statement on each note, along with a shortcode that allows you to trace that statement back to the participant, for example, their initials. Focus on statements that seem to be relevant to the site's design, either specifically (feature descriptions) or in a more general way (statements representing participants' attitudes toward the company or topic). 3. Have everyone post the sticky notes on the wall. If you're doing a large study, you're going to need a big blank wall; try to get one that you can visit for at least a few days. 4. When all your notes are ready, start grouping similar statements side by side. This part of the exercise may involve larger teams. This is a great way to start sharing your results. 5. Once groups begin to form naturally, begin labeling groups to provide further structure. If some sticky notes belong to more than one group, you can repeat and place them in each corresponding group. Note This method works for contextual queries, but can be used in many other situations as well. For example, this is a great way to co-create categories for uncategorized topics, so it can help bring an extra layer of structure to your card sorting results.

Patterns can appear in many ways, so it's best to let them form themselves. However, here are examples of the types of categories you might see, including the types of statements you might find in them: Goal: "I'm trying to resolve all open cases before I leave." Mental models (including what a user is such statement

Mapping external experiences to internal thinking): "I use this online tool as a folder for things I refer to a lot but don't want to carry around." Ideas and feature requests: "I want this to make me undo. Wait a minute

I accidentally moved an entire folder and it took forever to undo it. ” Frustration: “I will ask tech support for help, but most of the time they won’t

I know where the problem is. "


Chapter 6: User Research

Workaround: "It's taking a long time here, I'm just printing

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

Change won't take it away! "

In-Depth Research The essence of contextual research is contextual design by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also provides details on how to interpret the results using techniques such as affinity diagrams. For more information on mental models and how to understand them, see Indi Young's Mental Models: Aligning Design Strategy with User Behavior (Rosenfeld Media, 2008). This is especially useful when dealing with the information architecture of a content source.

Surveys Surveys consist of a series of well-defined questions that are distributed to a large audience. They often contain closed-ended questions (such as multiple-choice questions), which can be easily collected using tools that show patterns in answers. Surveys are a great tool if you want to present results in a more quantitative way than you do (e.g. "82% of those surveyed who work from home say they have some form of high-speed internet connection") , check List open-ended questions used in interview qualifications. However, you can also gather qualitative information about user habits and attitudes 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 build or validate user models, such as segments or personas.

Choice of Inspection Technology


Basic Flow As with customer interviews, you don't want to ask questions that require the user to guess. Don't ask "If you had feature X, would you use it?" Unlike interviews, in surveys, multiple-choice yes/no, true/false questions are best and easiest for subsequent analysis. Participants were also more responsive. Use surveys when you have questions about requests for real demographic data, such as: Which of the following devices do you personally own? Select all that match. A computer system for mobile games such as Xbox, Playstation or Wii

or Multiple Choice Attitude Question: Read the following statements and mark the degree to which you agree or disagree with each item. The fake company's customer service department responded to my needs. Strongly Agree Agree Neither Agree nor Disagree Disagree Strongly Disagree

In particular, questions like the second example are often used to supplement usability testing tasks. You can use this type as a follow-up question to find out if participants were frustrated completing the task. Participants didn't always like to voice negative feedback out loud, but they were often willing to do so in front of the ranking system. This brings up another point: surveys are a great addition to other forms of research you may be doing, such as customer interviews or background checks. The combination of the two research methods provides a richer user picture than the methods alone.


Chapter 6: User Research

Surf If you want to have a high level of confidence in your performance and have the budget, there are formal tools to measure user satisfaction in terms of ease of use. These tools include tested questions to ensure they do not mislead the public. Some of the most commonly used are ACSI (American Customer Satisfaction Index): WAMMI (Website Analysis and Measurement Inventory): SUMI (Software Usability Measurement Inventory): http://sumi.ucc . tj

When planning your survey, consider the following: Who are you sending the survey to?

Use a temporary model to determine this. The way you answer the rest of the questions here will change. Which method of survey distribution will give you the best results?

If the main user base is clustered somewhere, you might get more results if you go there and set up a form for people to fill out a paper survey. If your user base is active internet users, online surveys may be the best option for high participation. You may also decide to use your current customer list to find your customer base through phone surveys. How much time participants might be willing to spend on completing

test? If you offer some kind of compensation or they get some other benefit from completing it, you can often make a longer questionnaire -- one that might take half an hour to complete. If not, you need to shorten it so people can finish it - think 5 to 10 minutes. Either way, make sure participants estimate how long it will take, and keep them updated on your progress (use page numbers like "2 of 4" or show percent complete).

Choice of Inspection Technology


How do you know when to start analyzing your data?

You can conduct surveys with a certain number of participants or with a specific deadline, depending on which takes precedence. What tools will you use to collect and analyze data?

If you are conducting an online survey, the data collection tool you use may have options for viewing and analyzing the results. If not, you'll need an input method appropriate for your tool of choice. With paper surveys, this means a lot of data entry, so be sure to plan for that time.

Focus groups Focus groups bring together different people into a target group and facilitate discussions with them. A common goal is to obtain feedback on topics relevant to the organization or its brand, such as past experiences, relevant needs, feelings, attitudes, and ideas for improvement. Focus groups are a great technique that can be used for several purposes: Listening to different user stories. Open Discussions are a great way to contribute

The storyteller in all of us. When focus groups work well, individuals can develop stories and ideas with each other and recall situations that might not have occurred in a more structured one-on-one interview. The format and energy of the group allows for time to remember and share these stories. Understand significant differences in experience. Most people are-

ural information sharing and would like to compare their favorite tools with others in their interest group. You can often learn more about competing sites or services, or hear tips about workarounds, resources, and support. Generate ideas. Although you don't want the group itself to be

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 them back to an underlying requirement (see Chapter 4) to ensure it is addressed. Learn about the many essentials of the collaborative process. What if you are

Design a process involving multiple related roles and collaboration, groups can be a great way to bridge understanding gaps


Chapter 6: User Research

how people communicate. For example, if you are working with a content source such as an intranet, it can be useful to bring together content creators, content editors, and content users to identify where the process can be improved. There is a lot of debate about using focus groups in UX research. This is not a good usability testing technique (as users usually work individually, not in groups), and sometimes the group setting influences participants' responses too much. However, if planned and executed properly, focus groups can provide many valuable insights into your design. Chapter 13 discusses this further in the context of testing of concepts. Basic Procedure When writing focus group questions, consider the same guidelines you use when writing user interview questions (discussed earlier). Start with a few simple questions, such as "Tell me about the last time you visited Why did you go there?" As participants feel comfortable with you, each other, and the topic, write down all ideas generated in the middle of the group question. Allocate chunks of time for each topic and stick to them; they make it easy to get the discussion really started, time is running out! If you're concerned about timing, put the most important questions in the middle of the topic list, after people are already interested in the event but before any potential time constraints that might arise towards the end. Most of the logistics of a focus group are the same as usability testing. (Chapter 13 contains advice on selection, recruitment, and planning.) The main difference compared to a focus group is that you need a larger room and a table for participants to interact easily. Record six to eight people per 1-2 hour group session. Give everyone a name tag or business card to place next to their seat so everyone can be called by name. The format of the discussion itself should include an introduction, which usually touches on the following points: your role as moderator and what you can expect from the discussion

(such as the above points).

Choice of Inspection Technology


Why participants were selected to participate (e.g., “You are everything

current users of the Pseudo Corporation website, and bringing you together to learn about your experiences"). How this information is used - both within and within the project

confidentiality position. You, as moderator, are there to hear their opinions and

experience. You want them to feel like they can share information honestly, so you demand personal honesty, but also respect for others on the team. There's a lot to talk about, so at some point you'll find --

Discuss one topic to make sure you can cover them all. This can then lead to a performance round with the panelists, which usually includes an icebreaker question. Your goal is to get everyone talking about the first question, even if they only tell a short story. You can start with one person and work your way around the table, or let people respond naturally, then call out the names of those who haven't responded. This usually ends with sitting around the table answering the first few questions, and then when you feel the group is ready, you can use body language to open up questions to everyone.

Snorkeling: Body Language Having a good understanding of body language is an incredible tool when conducting focus groups or any personal client research. It can help you understand when someone is upset, excited, angry, or threatened, so you can determine when you should try to make someone more comfortable or investigate a particular comment. The following book on the topic may take more than a weekend to read, but is designed for easy browsing: The Definitive Book of Body Language by Allan and Barbara Pease (Bantam, 2006).

When calling someone who hasn't answered, be sure to repeat the question in case they don't understand or can't hear the last question


Chapter 6: User Research

Some comments in the discussion. Also, avoid making disagreements seem like disagreements between two people. Don’t say, “Bob, we haven’t heard from you. What do you think of what Chris just said?” But (looking at Bob), “What about you, Bob? How is your experience with Pseudo Corporation customer service? "As a moderator, you can control the flow of the discussion and hand over the virtual microphone. You can maintain control through eye contact, speaking volume, hand movement, and body direction. Most people will be very aware of your body language, and if someone dominates Talk, these cues can be useful clues. If the overly outspoken participant does not notice these cues, use a gentle but firm statement such as "Okay, that's great, I want to open this idea up to others. Has anyone else had the same problem as Theresa? "When you move on to a new, broader topic, verbally say that the previous discussion is over and a new one begins so people can clear their minds for the next topic. Finally, when an activity is coming to an end, simply A quick glance at the clock and a change in body position can signal that the conversation should be over. As with any other activity, be sure to thank the group for their time. Sharing results with the group usually takes one of two forms: based on the main theme of the discussion or grouped into appropriate Similar to contextual research, Affinity Maps are another effective way to bring together disparate trends and attitudes to illustrate to your project team.

Card Sorting In a card sorting exercise, participants (whether working individually or in groups) receive items printed on cards and are asked to sort them into groups that are meaningful to them. They either group them into previously given categories (called closed sorts), or create their own groups and name each group (called open sorts). By the end of the card sorting round, you should start to see common patterns in the way people sort items, as well as common areas of confusion or confusion.

Choice of Inspection Technology


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

Let's say you're working with a typical source of content: a corporate intranet. Many intranets tend to categorize information according to the department that owns it, navigating to HR, operations, legal, marketing, etc. For long-term employees, this may not be an obvious problem, because they may already understand the responsibilities of each department and know where to look for information. But for new hires or those who need information they don't usually mention, it can be difficult to find information that may belong to multiple departments (or appear to belong to none). For example, where can you find the rulebook for signing contracts with new hires? This can be regulated by law or human resources. By sorting cards, you can find common patterns in how potential users categorize information, regardless of department. Basic Procedure Gather the items you want to include in the card sort; 40 to 60 is usually a good range. You need enough cards to create potentially large decks, but not so many that you overwhelm the participants (or overwhelm you 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 terms that you think your user group might be familiar with, but avoid using too many "confidential" terms. If you include too many company-specific terms or acronyms (such as "SUCCESS campaign" to increase sales), you'll be testing your company's marketing and communications effectiveness instead of building a generic message hierarchy. For an intranet, you can include vacation policies, 401(k) plan information, employment agreements for new hires, vendor agreements, nondisclosure agreements,


Chapter 6: User Research

New employee orientations, health insurance information, and computer security rules. This list is a collection of clearly worded items that can be categorized in a number of ways. You might have one attendee who groups new employee orientation and leave policy together and calls it Human Resources, and you might have another attendee who groups new employee orientation and new employment contracts and calls it For "Employee Onboarding". Once you have a list of items, put them on cards that can be easily grouped and ungrouped. You can print labels and stick them on index cards, or directly on card stock that is perforated to separate into individual cards. Create a test by asking someone to sort the cards and name the group—for example, put post-it notes in a pile and write names on them with a pencil. Ideally, test-takers should be people who are new to the subjects and activities. This will help you see how long the event might take. If the test takes longer than an hour, you may need to cut out a few cards! Once you have your deck ready, you can gather the right participants and give the following basic instructions: 1. Group the cards into groups that make sense to you. 2. Try to have at least two cards in a set. If you don't think the card belongs to any group, you can put it aside. 3. You can name groups anytime while sorting. At the end of the exercise, list as many sets as possible. Just by looking at sessions, some trends become apparent. Others may require more analysis to come out. There are various tools for entering and analyzing the results of card sorting; many come with tools that allow you to sort cards remotely (see the "Card Sorting Variations" section below for more information). In particular, OptimalSort ( and WebSort ( provide remote sorting capabilities and useful analysis tools. Or, if you want a more manual way of categorizing yourself, check out Donna Spencer's excellent spreadsheet, complete

Choice of Inspection Technology


Instructions are available at Variations of Card Sorting The discussions so far have focused on face-to-face card sorting, where participants are asked to name the categories they create. This is an open sort, which means that the main categories will not be given to participants - but can be named. This is a great approach when defining a new navigation structure or making major changes to an existing one. In other cases, you might consider the following popular card sort variants: Closed sorting. In closed sorting, you specify the advanced category

and add participants to them. The results are relatively easy to analyze because you have a small set of possible categories and can focus on understanding which items belong to which categories most often. If you're adding a lot of content to an existing information architecture or validating an existing sitemap, closed sorting can provide quick and useful information to help you make classification decisions. Sort by group. Instead of grouping the items individually you can do

Use card sorting as part of a focus group and have participants sort items together. While the results don't necessarily reflect how a person groups items, you can get a sense of how people perceive items and their organization by listening to them do the exercises together, discussing the rationale behind each placement. Remote sorting. Sorting with physical cards can be especially fun

Used for group sorting. But there are a lot of great tools you can use to categorize individuals online. It also allows you to reach more participants or specific participants who are difficult to meet in person. The aforementioned OptimalSort and WebSort are two tools that facilitate such online sorting.

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


Chapter 6: User Research

Usability testing can be done during the definition phase if you want to gather information on how to improve your current site. You can also do this on a similar site (such as a competitor's site) to see some potential for an easier-to-use solution. Most of the time, usability testing is performed as part of the design phase, preferably in an iterative cycle (creation of design, testing, improvement, and testing again). We discuss usability testing in detail again in Chapter 13, “Testing Your Designs with Users”; the recruiting and planning tips provided in this chapter can also help you with the activities discussed earlier in this chapter.

After you've done your research Now that you've completed at least one user study, it's time to revisit your initial assumptions about your user group. Putting these assumptions aside for a moment, ask yourself which user groups you would create if you had more information. If some of your previous assumptions were incorrect, consider possible gaps in your user research because key groups were not covered. If this shortcoming is identified early enough in your research activity, you may have time to adjust and add another group of participants to the ongoing study to ensure you get the full picture. Armed with new knowledge, you can change user definitions to more accurately reflect the groups you want to focus on. This will help you create more detailed tools like roles (discussed in Chapter 7), and it will also help you create user requests for the list we started in Chapter 5. In this chapter, we discussed the process of collecting statements from stakeholder companies and converting them into requirements. You'll go through a similar process with your users -- your work doesn't end when you capture an idea or request. Research your basic 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 knowledge gained from conducting user research to create a tool that can focus the attention of user groups while designing and creating: personas.

after test



Personas Find the best way to put your team (or your client) in the shoes of users Personas are often a topic of discussion among UX practitioners. Opinions range from how much content is needed, how much research is needed, to whether it adds any value to the project. Some people wonder if they belong in the process. Personas can be used to help your design team and your clients resonate with their users no matter where you are. People can examine many elements of your design—business requirements, visual design, or quality assurance—gaining insight into who your audience is and what their expectations and behaviors are. Russian Unger


What is a role? Personas are documents that describe typical target users. They are useful to project teams, stakeholders, and clients. With the right research and profiling, individuals can gain a very clear picture of who is using your website or app, and possibly even how they are using it. UX designers often see the creation of personas as an excellent exercise in empathy. A well-prepared individual is often used as a point of contact when there are questions or concerns about how to design various aspects of a project. Can you take your character and ask what that would look like? Or what would you be looking for? While this process may not be as thorough as testing functionality and design with real users, it can help move the project forward until you are able to run more detailed tests. Josh Seiden ( points out that there are two different types of personas: marketing-oriented personas that model purchase motivations, and interactive personas based on usage behavioral modeling

This chapter focuses on interactive characters.

Why should I create a character? Personas help you focus on representative users during the UX design process. By gaining insight into the "real" behavior of "real" users, personas can help resolve conflicts that arise during design and development decisions so you and your team can move forward. How real does the character have to be? The answers vary widely. One persona document might suffice for one team, while another might create complete "living spaces" for user personas to gain insight into how they "live". You can even go to the extreme and create a personal online presence that you can interact with to gain insight into your online behavior. How you expand your personality is up to you. Roles can constantly remind your users. A helpful tip for team members is to keep people in their workspace; they are

Why should I create a person?


They constantly remind you who their users are. After sharing a cube with "Nicole," a 34-year-old certified manual therapist from West Chicago, Illinois, you begin to feel compelled to give her an experience that is good for her. If it helps, take the print with you to sleep and let the fairytale seep through your pillow to transfer empathy for the pages into your sleeping subconscious. The purpose of personas is to help you, your team, and/or your client clear up some of the confusion that may arise when you reach a decision crossroads.

Find Personas Successful personas should accurately represent a specific number of specific users of your product or website. In order to achieve this goal, individuals must be supported by research. Chapter 6 introduces prospect research and modeling techniques to provide a solid foundation for the personas you create. But don’t just look for one approach as an answer; it’s better to find as much data as possible and combine it with observation and interview data – this can also include using online surveys and analyzing social media behaviour. This is a common theme in personas: take real data, but turn personas into real people on the page. To see how one company achieved this, check out the sidebar "Case Study: First Messages from Personas."

Creating Personas Once you've identified your audience and gathered data to support your personas, the next step is to put the pen to paper and start bringing them to life. The number of characters you need to create varies. Generally, a minimum of three, but more than seven is not uncommon. Instead of targeting specific numbers, think about how many target segments you have and what you think is the best way to fairly represent those segments.


Chapter 7: Personality

Case Study: MessageFirst Personas To create effective data-driven personas, MessageFirst ( uses at least three different sources of input, drawn from the following elements: Stakeholders. We interview them to find out who they think they are and what their behavior looks like. It is always on. Customer Representative. We interview people within the company who talk directly to customers, which usually means sales/marketing and customer service. They each have their own biases, and we must keep that in mind as we document our findings. For example, the people who contact customer service most often are those who have too much free time (often retired or unemployed), or those who are so dissatisfied with a product or service that they actually take the time to contact you. customer. We speak directly to real people who intend to use or are using a product or service. Take this into account as much as possible. Sources of Customer Data. We review all available blog traffic, surveys and emails. people we know. We choose a person we know who fits the initial profile of the person. This helps ensure the characters are believable and realistic, keeping us grounded and providing a real way to contact us if we have further questions. This is very important for validation and is always taken into account. Because every input source we use has some bias, we use multiple sources to normalize the data. For data-driven people, it is important not to expect how many people you will have, but to let the data reveal how many people you should have. When I analyze data, I look for gaps in behavior and procedures. These gaps reveal an individual's personality. MessageFirst CEO Todd Zaki Warfel

An example of a character from this chapter is Nicolle, a 34-year-old certified manual therapist from West Chicago, Illinois. He doesn't drive and spends 2-3 hours a day commuting to and from get off work. The fictional customer is ACMEblue, a manufacturer of Bluetooth headsets for Apple's not-fictional iPhone.

character creation


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

Figure 7.1 The role of a fictional ACMEblue client

What kind of information does this person receive? The type of information your audience will find relevant and credible, right here. Based on the research data gathered, you should be able to determine what is important to the client, brand, and project. Most roles you create will have a common set of required content mixed in with any amount of data, stats and other relevant information that can be considered optional as it will vary from client to client, if not project to project varies.


Chapter 7: Personality

Minimum Content Requirements When creating a persona, you need to provide enough information to hook people and make them connect with the persona they're reading about on the page. To help your audience understand what you do and think, be sure to include six key pieces of information: photo, name, age, location, occupation, and bio. In the following sections, we'll take a closer look at filling in the details for each item. Photography Photography is the first (and real) step in giving a face to a person. When choosing a photo for your character, try not to make it look overly posed or elaborate. Photos that appear to be posed will not have the same effect as photos taken in more natural conditions. Characters seem to work better for images taken in more natural environments, such as the image on the right in Figure 7.2, where the subject is standing outside in winter clothing, presumably on their way to and from get off work. Make sure the photo matches the person's lifestyle! constitute

Natural Figure 7.2 Photos that look natural are more effective.

There are many photo resources available on the Internet. Some better options are iStockphoto (, Getty Images (, and Stock.XCHNG (

character creation


Finding the right photo can be terrible if you're not careful. If all else fails (or you have the time and budget), do it yourself! Name Simply put, you need to have a name written on your face. The photo you use will humanize the combination of research data and personality traits, and the name will be how everyone calls you in discussions. Not only does Nicolle sound better than "30 year old blonde working mom", but it's more memorable and associated with a particular character. Try not to make the names used by different people on the project sound too similar. For example, Nicolle and Noelle are easily confused, so look for different names. While it may be tempting to use a colleague's or client's name, please don't. When you use a similar or identical name to someone involved in a project, it's easy for them to try to identify themselves by you. By choosing a different name, you will avoid unpleasant situations and harm. If you're having trouble choosing a name, some online resources can help: Baby Names Sites! Babyhold: Social Security Administration Popular Baby Names:

OACT/babynames Random Name Generator:

Another thing about names: Make sure your name is credible to the person. Nicolle is great for Midwestern moms, but Nicola or Natalia might be better for Italian moms. Also, funnier or racy names, like Bob the Builder, aren't. They tend to make your characters look ridiculous and reduce their value. Age While your research should indicate the age range of your consumers, assigning yourself a specific age can help add authenticity to your resume. A 21-year-old student and a 34-year-old mom behave very differently professionally!


Chapter 7: Personality

Location At first glance, location may not seem like an important piece of information; however, keep in mind that culture and behavior may change depending on where you are located. In Italy, for example, different dialects are spoken in different parts of the country. In the United States, someone living in Chicago will most likely have a different cost of living than someone living in Savannah, Georgia. Occupation Understanding how your people earn a living can help you identify with them by understanding their day-to-day patterns. People who work in therapy encounter a lot of people on a daily basis, while a drawbridge operator may not interact with others. Biography A biography is a compelling story that makes a character real. This is where you go into the details you got from the research data and plug some "real people" into it. That said, the data is very important to the person, but you don't want to just quote that information in rambling sentences. Instead, you want to weave data, anecdotes, and observations into a story that resonates with your audience. This may seem a bit odd, but a biography has to be believable, and introducing aspects of real people into your personality is certainly not a hoax. Nicolle, for example, is based on statistics and the real behavior of people with similar behaviors, beliefs, and aspirations. Depending on the project, you may need to dig into your resume - sometimes the more detailed the better. Don't feel like you have to squeeze your personality onto a piece of paper. Choose what best makes your personality as real and meaningful as possible to the project you're working on.

Additional content As you work with roles, you'll find that different projects require different sets of information to make roles more useful. Minimum content requirements can also be considered the least common

character creation


The denominator of most people you create. In most cases, you'll combine some of these optional content elements into the core of your character. Optional things that can add value to your character include education levels. Knowing a person's education level can help

Learn more about some of their habits. Someone with a high school diploma may have very different buying habits and brand perceptions than someone with a master's degree, and this information can influence how people perceive your personality. Salary or salary range. Money talks everything, and in many cases it's quantity

A person's income has a significant impact on their standard of living and disposable income. When targeting specific levels of wealth, this information can provide important insights. Personal offer. What is your motto?

as your own? Sometimes this can give you a quick glimpse into your core ideas. internet activity. It can be difficult; people spend money in many ways

Your online time. Some pay their bills, others are heavily involved in blogging and social networking, and still others just use their computer as a device to turn on when they need to get work done. Given that so many projects have some sort of online component, this element requires some judgment. You will need to rely on your research to help paint the picture. offline activity. Does your character have hobbies? Is there anything extra?

Information about what life is like when your people aren't online? This element can be just as difficult as online activity, and can have an equally important impact on your personality. Key inputs or triggers for customers, brands or projects. it's usually important

Find out how a person interacts with customers, brands or projects. Did the person learn about it through word of mouth, online reviews, billboards, television or radio, or online pop-ups? Does your role want to solve a problem that can be solved with a client, brand or project? Using statistics to understand this and writing it into your personas can help solidify your approach to customer engagement.


Chapter 7: Personality

Technical comfort. Do your people use PCs or Macs? if she

Do you have a computer? Does he use instant messaging, Flickr, or blogs? Was she happy with the activity or confused? Would a very simple solution for beginners help her? Does he have an MP3 player or other portable device? Does he watch TV on a DVR or AppleTV or on demand? The list can go on indefinitely. and the following. Depending on the client, brand, or project, it may be important to recognize these concepts, and many others. social comfort. Consider the development of social media and social networks

Business, it may be important to be very specific about how your personality engages with that particular space. Does she have a twitter account? If so, how many followers does he have? How active is she? Is he the leader? Does it use MySpace, Facebook, LinkedIn or other online aggregators or communities? Mobile comfort. Because of the growing use of mobile devices

As always, it's important to consider how your characters feel in the space of movement - if they feel any at all. Motivation for using the client, brand or project. In some cases you may want to

Include why the person wants to use the client, brand, or project. If he keeps tangling his headphone cords in his jacket and pulling them out of his head, that might be a good reason to consider new headphones. Real-world scenarios based on research data can help you uncover key motivations you should include in your roles. user goals. You can also describe the person's wish

Realize with clients, brands or projects. This helps gain insight into what drives people to use it. This is just the data to get you started. You can build your own personalities and present them in endless ways. If you want to delve deeper into the world of personas, start with Steve Mulder and Ziv Yaar's The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web (New Riders, 2006). ).

character creation


Advanced Roles Once you understand the basics of creating roles, you can extend your documents in countless ways. A simple person can often cover most of your needs, especially if your design team is just trying to empathize with your users. Things get more interesting when you introduce the persona to the client. In these cases, you will often find that you need to provide far more information than you have gathered for the key person. Figures 7.3 to 7.7 illustrate some of the ways to extend a person. You can take these examples, remix and remix them to create something even better for your projects!

firm name

Consumers who know the brand

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

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

Joan, 32 years old. Consumer insights help us understand our users - their motivations, goals and desires. To apply these insights to web design, we developed personas and user stories embedded in real-world contexts. This approach to design helps create an end-to-end experience based on understanding customers, their motivations, desired outcomes, and behaviors. Specifically, these scenarios address three fundamental questions that must be answered before a website can be properly organized:

Pleasure-seeking couple "very fond of" "young and promising"


start to discover

build experience

"Rising Newcomer"

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

"active reactants"

Feeling 5)&365

found again

"Recognized Researcher"

Zoom in and simplify

"Growing Up in the Ditch"

Practical Ways to Get the Job Done "It Had to Work"

Alice, 26 years old

Rachela, 42 years old

Erica, 47 years old

Greta, 59 years old

Figure 7.3 Main page (landscape) of the logo overview. In the context of high-level organizational strategies, it provides an aggregated view of multiple leads and the segments they represent. Courtesy of Will Evans.


Chapter 7: Personality

firm name

People and scenes (based on ethnographic research) Alicja is a beginner chef who wants to explore the world of food,


Especially food for kids, find new recipes on the internet and in magazines with friends. Her research is more about

Effortless support for the family

However, there is more fantasy than reality. she's still scared, no

Find quick, easy recipes using basic ingredients

Trying too many new recipes. Her mom didn't really teach her to cook, and her friends weren't very experienced either

(often) they prepare two types of meals: adult's, children's

She also cooks. Alice is a working mother of a daughter in Chicago. She and her husband both work outside the home, running the offices of a small insurance company.

Alice, 26 years old, "newcomer ambition" generation. x married

1 daughter, 5 tired, longing



She's very busy and down-to-earth and doesn't spend much time cooking. Alice just wanted to make it quick and easy - although since she started exercising after giving birth to Sophie two years ago, she's often had to prepare different meals for herself and her husband and try to get back into marathon form. Using a small selection of successful recipes that have worked for her, many of the dishes she prepares are based on packaged and prepared foods.

Scenario Alice is having breakfast with Sophie and watching Cartoon Network. A brand ad showing the brand name appears. Alice uses the stamp and thinks Sophie will choose the dish. He decided to check out the place after get off work. Alice visits the site half an hour before the meeting starts. The home page is clear and organized. He sees the main section of the site and links to interesting content, such as the recipe of the day.

use the internet

Health awareness

cost sensitivity

Click for the recipe of the day. She loves the instructions it comes with - she seems to be able to handle this recipe. She's happy with the clear navigation, unlike other sites where you can get lost. She likes the practical features that go beyond what she's seen in cookbooks, like being able to search for recipes based on what's in your pantry and tips on how to use produce. Alice discovers that she can receive the cookbook newsletter and clicks Sign Up. Signing up is so easy! Fill out the basics and select the "Food Your Kids Will Love" newsletter.

She wanted to add more of her stamp, recreating dishes she loved at restaurants, like her favorite roast chicken. She wants to include more fresh vegetables in her meals because she knows they are healthier. She prides herself on being a meticulous planner and able to run a family on a tight budget. Her refrigerator and pantry are always well stocked. Plan your shopping to take advantage of sales and coupons.

Find recipes and activities for your child Find ways to dress up her favorite ready meals Projects and initiatives Improved navigation and information architecture Improved registration

At lunchtime a week later, Alice discovers the brand's first e-newsletter: "Pizza, as easy as 1, 2, 3." Perfect - her kids love pizza and she usually buys them frozen. There was a link to "Pizza for Beginners," which inspired her to see if she could make her own pizza. The link took her to a pepperoni pizza recipe in something called "Pizza Wizard." He looked at the recipe and saw it was easy; just 25 minutes and 4 ingredients. He peeked at what was in the kitchen. There's no pepperoni or pizza sauce, but "The Pizza Wizard" suggests replacing them with something from his well-stocked pantry: sausage and tomato sauce. Perfect! There is a link to the coupon. Neena printed out a shopping list based on the recipe, added a few things she needed, and headed to the store. After returning from the store, Alice started. See step-by-step instructions on how to roll out the dough and add toppings. There are pictures for every step. It's easy to understand and follow. He wonders if he should cook the toppings first, but the pizza FAQ answers that question.

More targeted newsletters, recipes, better coupons, integrated meal planning, do-it-yourself approach relies heavily on ready-to-eat foods, adds relatively little fresh fruit and vegetables, and spends more time reviewing recipes instead of cooking

Figure 7.4 Target audience personas (horizontal). This detailed view of personas 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 (vertical) of target groups and target group personalities. The target view on the left provides a high-level summary and shows the brands that three people are interacting with and connecting to. The detailed description on the right shows a sketch and biography of a person, along with information about their actions and motivations.

advanced people


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

5 4

Helen's mother passed away a few weeks ago and they are only now starting to clean the house. They're going to sell their house, but first they need to clean it up. The house also needs a renovation of the main bathroom.


——of de The basement is full of things that Helen's mother has collected over the years. She never throws anything away. Contains period newspapers and magazines from the past 20 years. Helen wanted to keep something. Most of the clothes, wheels and furniture will be donated to Goodwill. Unfortunately, most of my mother's "lectables" were damaged by water and mold. There are also cans of paint, but Paul and Helen don't know if the paint contains lead.

2 1




Know Ex led pe management C on Price ve e Senior tunc pe sp Re M pued ult type Timtion C on eline t Main ss ajo er r L Sizife es D E ecven fight t Rock Re rding pe Wast Oceń w Buars dsine Price i O Rec信息am nlin ycli i ac g 计数

This is the first time Paul and Helen have experienced such a thing. They don't even know where to start. They just want it to be as simple as possible. They know they need a trash can, but they're not sure how much it will hold. They think almost anything can end up in the trash unless someone tells them otherwise. Their only concern is that the container is ugly. They want to find a company that doesn't make the yard look like a construction site or wreck it when delivering or picking up litter boxes.

Age: 24-65 years old

January life cycle




1.0 Life Events

Main features Ŕ Ŕ

A single event, such as the acquisition of a home property or a minor remodel (such as a bathroom). Little, if any, previous experience buying containers.

Ŕ ŕ ŕ ŕ ŕ

Get a container fast. Get rid of anything you don't hold or pass on. Avoid property damage during the procedure. Avoid unsightly garbage. Discard quickly after container is full.

Frustration pain points Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Pitanja Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ


Ŕ ŕ ŕ ŕ

Initial sticker shock ignorance of the process I don't know what they don't know Apples to apples comparison between suppliers

Is there anything I can't get in? How fast can I deliver and pick up? Will they stay the way they are? How does it work? Is a license required? how much does it cost? How easily can I grab someone if need be?

Figure 7.6 Personas of target audiences. This person represents the target age range and is drawn from survey data. The information contained therein is broad in scope and is directed at groups of recipients rather than specific individuals. This method is useful when preparing a business plan or when a client's budget allows for detailed personality research. Courtesy of Todd Zaki Warfel.

jill of all walks of life

Amanda Stone


"I have to manage many projects for my clients."



AMANDA is responsible for the incentive program with several other colleagues. They share access and manage multiple programs for clients. Making sure it pays the right people on the right shows can be especially difficult. It must be able to switch between different programs and always know where it is.



wheel of life

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

Manage multiple programs Medium to large businesses Medium volumes (50-2000+ orders at a time) Many people share one role 70/30 Quick payments and manage checks Use one to two months throughout the year Very interested in reports Want to generate in Heavy Reporting Excel program using a custom internal interface system

Ŕ ŕ ŕ ŕ

Integration with existing systems. Ability to pay employees quickly and easily. Cost (mainly time). Guidance assistance.

Other Applications Ŕ Excel Ŕ PowerPoint How do I generate reports for all my programs? Ŕ Is there a way for Internet Explorer to get my login information without calling Ecount? Can we somehow integrate with ClientZone so that we don't have to constantly switch between different applications. Am I doing it right?

Ac FT N cew ou P n Cart Zod Rene quest E Adasy s m Pa in y Che c R Cu epks or rr ent rting tB al Peance ce Cu oplestom S o ft t System Exce l




Pay your employees quickly and easily. Ŕ Avoid duplication of effort. Ŕ Check their current balance to see if they need to… transfer money. Ŕ Track transactions weekly, bi-monthly, monthly, quarterly and yearly.


that ex




dg i ow Kn






He uses the account area a lot - several days a week. She is very active throughout the year due to the many programs she hosts.

activities and interests

you c

Age: 28-55 years old





The account area really helped her issue new cards and provide fast withdrawals for program participants. The only thing she lacks is the ability to watch each show individually and all the shows she hosts to see how things are going. Her clients enjoy monitoring the program's effectiveness. Now he's tracking it in Excel. After all, he either sends the excel file to his clients, or sometimes exports it and sends it a PowerPoint with nice charts. It would be awesome if Accounts Zone could run single and multiple program reports.


Ŕ ŕ ŕ ŕ ŕ






setbacks and pain points

question -


You cannot watch multiple programs at the same time. You cannot run reports in more than one program at the same time. Fix bug "sucks" in received file. It's unclear exactly what the problem is and how to fix it. Multiple steps across multiple applications is not efficient, and it's easy to "lose" where she is. Multiple confirmation screens. Another username and password to remember. Look for an email with her login information.

Figure 7.7 Individuals in the target group. This role is a data-driven model. While the story of a day in the life is narrative, the rest is presented as a checklist of items. Diagrams are used to convey a lot of information in a small space. Courtesy of Todd Zaki Warfel.


Chapter 7: Personality

As you can see, data can be combined in many different ways to represent people, adapting them to different situations. Start with a basic character, then expand it to suit your needs.

Final Thoughts on Personas Many practitioners in the UX design community do not believe that personas are a good way to express users' needs, goals, and attitudes. They believe that people can block creativity, innovation or good design for many reasons. Other practitioners believe that, when based on solid research data and combined with a degree of personalized reality, personas can fulfill specific needs that can have a very positive impact on the design process. Which side of the coin you stand on is entirely up to you. It is not the purpose of this chapter to influence your decision in any way. There are many articles on the web on this topic, and there are many experts willing to share their views with you. All of these resources can help you decide which roles are best for your project, so check them out. Jared Spool, CEO and founder of User Interface Engineering (, also offers some insight on this topic: the value comes from teams visiting and observing target audiences, absorbing and discussing their observations, and reducing confusion to patterns, and then they become characters. What the team thinks during the design process will influence the final design. Character descriptions are just to remind you of what happened.

The bottom line for Jared is simple: by observing your target audience, combining what you learn with research data, and synthesizing everything into segments, you should be able to create empathetic personas that keep your team engaged. Get on track and build the best app, website, or product possible. Ultimately, however, your personalities will be very much like Santa Claus: they will only be valuable if people believe in them.

Final Thoughts on People



UX Design and SEO The fundamental role of UX design in effective SEO. Search engines are the cornerstone of the interactive economy. Everything we do as "interactors" is ultimately connected to the world through Google, Yahoo, MSN, Ask, and the myriad of little machines that form the infrastructure for finding things on the Internet. Information Architecture is a key part of how search engines interpret web pages. The purpose of this chapter is to give you a basic understanding of why UX design is critical to SEO and what you need to consider so that the environments you create have a good chance at Google. jonathan ashton


Introduction to SEO In short, search engine optimization is the process of developing and maintaining Internet resources with the goal of gaining and maintaining the number one position in public search engines for certain key phrases. Search Engine Optimization (SEO) is like a martial art, the learning and execution process is never complete. Even a master can improve by using observed behaviors or learned methods. As long as there are search engines and websites interested in selling something to searchers, SEO will play an important role. SEO is based on three fundamental areas of improvement and impact: a set of key things considered by professional UX designers

May affect - Site infrastructure, technical and organizational rules. Content related to the optimized term and all keyword issues

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 within the site are organized. We'll break down each of these three domains and look at them from the perspective of a UX designer to better prepare you for the optimization challenges you face.

Why is Search Engine Optimization Important? It's funny how even today we have to explain the importance of SEO. Clients often understand on some level that attracting targeted visitors via organic search results on major search engines is important to their website, but beyond that, most interactive marketers struggle to understand the impact SEO can have. Global search data is available from a variety of sources, but the most important thing to understand is that no matter the source, the numbers are huge, with year-over-year growth always in double digits. In general, global searches increase every quarter. When Google first launched in 1998, 10,000 searches a day was a huge number, putting incredible strain on the beta system.

Introduction to SEO


Hitwise ( reports that Google and its affiliates, including AOL and YouTube, control the vast majority of searches worldwide, accounting for nearly 72 percent of searches in the United States in November 2008. Yahoo came in second with nearly 18 percent, while MSN and had 4 percent and 3 percent, respectively. At the international level, Google's dominance is even more pronounced: in many markets, its market share exceeds 80%. NOTE For more information on Google's origins, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (, 750 million people worldwide conducted more than 60 billion searches per month in 2008, with more than 18 billion searches performed in the US alone. In other words, 95% of Internet users use a search engine at least once a month, with a global average of more than 80 searches per month.

Beyond these staggering numbers, what does this actually mean for interactive marketers? In short, if you don't reach your target customers when they're looking for your product or service, your competitors have an opportunity to sell to them. Look at your website stats and think about it this way: If your strategically targeted traffic increased by 10%, how much revenue would your website generate? What about a 100% increase? Or 1000%? If your website isn't generating a lot of organic search traffic, you need SEO. A small investment in SEO can go a long way, especially if your engagement marketing has so far been focused on buying clicks through sponsored listings. We've seen a 35 to 1 ROI on monthly SEO spend for websites. If you pay search engine companies for sponsored listing traffic but don't invest in organic traffic, you're only really doing about 10% of the work. Think about your search behavior: when was the last time you clicked on more than one or two paid sponsored listings in the search results? Any discussion of why SEO is important and why it exists could drag on to an entire chapter. Suffice it to say, Google can only go upwards, and effective interactive marketing must incorporate SEO as an essential element of effective performance.


Chapter 8: User Effective Design and Search Engine Optimization

Important core resources Expertise comes from comprehensive education. A professional who is only focused on his specialty ignores everything around him. That's why it's so important that every interactive artist spends at least a few minutes learning SEO. While there isn't a formal set of guidelines, Google has been kind enough to provide some very relevant resources. If you really want to work towards better search engine results, check out this link: Help for Webmasters/Site Owners: Search Engine Optimization: Webmaster/Site Owner Help: Webmaster Tips: Quality Guidelines: A Beginner's Guide to SEO: If that's not enough, delve into the newsletter and blog. Do the digging yourself, starting with Remember, like everything else in life, if it sounds too good to be true, it probably is.

Website Technology, Design and Infrastructure Search engines are essentially Web 1.0.5 technologies firmly embedded in the Web 2.0+ world. The fundamentals of search engines haven't changed much since 1993, when WWW Wanderers was launched to search the web and create the first Internet search engine. Basically, every search engine has an application, or called a crawler, spider, or robot, that finds and follows links, sending back copies of the resources it can see to the database. The database is then analyzed according to the search engine's own algorithms. Using these rules, a web resource is indexed and then ranked based on its performance on a particular search engine's result card. In this fairly simple process, UX designers encounter many pitfalls.

Building Technology, Design and Infrastructure


Understanding these basic relationships will allow you to see your site through the eyes of search engines. An optimized website is based on a structure and technology that makes it easier for search engine bots to navigate. Likewise, many of the decisions you make about how to handle your content determine how well search engines value the results work. So a lot of things are predetermined in the decisions made in the framework and in the discussions around style and content management.

Flash, Ajax, JavaScript, and other scripting content Today's dynamic and interactive web designs rely on technologies that are simply not search engine friendly. The gap between what search engines see and what designers can do is growing. User Experience Designers make sure to implement a strategic plan for a dynamic, intensively designed website so that both search engines and users have the best possible experience. A basic understanding of how search engines interact with such content will help you decide when to implement them and where to bridge their weaknesses. It is entirely possible to build an optimized website that relies heavily on scripted content if the appropriate fees are introduced early in the process. After your website is up and running, creating static or crawlable content is much harder. So, for usability reasons and in the interest of search engine bots, stick to static content. It may seem like extra upfront work, but the return on investment is exponential. Flash Flash content is technically "indexed". Recently, search engines have made some progress in their ability to crawl Flash files to find the text and links embedded in these resources. Although this content is indexed, have you ever had a resource built entirely in Flash rank #1 in search results? Probably not, since opening up full Flash compatibility is risky for search engines. Assume that all links and text content embedded in SWF objects are fully visible to search engines. This prevents unscrupulous (or "black hat") optimizers from placing apples in the object's text layer when rendering


Chapter 8: User Effective Design and Search Engine Optimization

Orange for users viewing fully compiled assets through a browser? How can I deep link into a Flash asset without fully compiling it? These fundamental gaps will remain until search engines reach a level of AI that can tell an image is a picture of a horse without any accompanying text saying "this is a picture of a horse." To design a search engine friendly Flash website, you need to add a static content layer that replicates the Flash content. Now search engines aside, the static content layer is key to meeting usability requirements. Think of a search engine as someone browsing the web on a phone or using a screen reader browser. These people may be the least common denominator, and the strategies behind your network growth may deny this tiny minority of users. But when you ignore that handful of people, you're also leaving out GoogleBot and Yahoo Slurp -- two of your site's most important visitors, as they are the crawlers that allow the major search engines to index your site. If search engines cannot see scannable text words or links, the content will inevitably not appear in meaningful search results. Static layers can be obtained in a number of ways. To be search engine compliant, the static content layer must mirror the Flash content. This is not an opportunity to show search engines anything other than what's used in Flash; if you do, you're breaking the spirit of the game and being on the dark side. The ideal way to embed Flash content into a static layer is to use a SWFobject, so that the Flash content and the static content can be on the same URL. This will allow search engines to find static content and allow browsers that support Flash to display animations instead of static content. If possible, don't use redirects to keep links to Flash content popular. Google Code provides a simple set of instructions to implement this simple JavaScript snippet at There is another option that applies to the gray part of SEO. Cloaking might be a dirty word for SEO purists, but if you tackle the following challenges the right way, you too can have your cake and eat it.

Building Technology, Design and Infrastructure


Cloaking uses user agent detection by detecting search engine bots when visiting a website and redirecting them to static pages for indexing. However, when a visitor sees the same page in the search results and clicks on the link, the page will detect that the user's client is someone with a Flash-enabled browser, and will serve the URL to that person at a completely different URL. Show dynamic experience. The crux of the matter is the same as with the SWFobject approach: you need to show search engines in hidden content exactly as you would in Flash content. Ajax, JavaScript, and Other Scripted Content As the powerful engine of Web 2.0 content, Ajax provides Web developers with the ability to create content without pages. However, Ajax's search engine problems are multifaceted and require good planning to avoid major mistakes. Ajax stands for Asynchronous JavaScript And XML, which shows how difficult the technology is for search engines. Search engines are simply not good at JavaScript; the efficiency JavaScript provides developers is a problem for search engines for dynamic content. Another problem search engines have with Ajax is the asynchronous nature of the technology. The crawler can only see the content of the initial page load, and any script loads that occur after the initial shell load will not be visible to the index. Since Google cannot extend the session after the initial page load, and there is no mouse or external proxy to trigger the script, user-triggered non-paged content will be invisible unless text content is placed in a preloaded shell. It is up to the UX designer to ensure that the 3D modeling necessary to construct a no-page design also includes the requirement to preload text and links in the page shell. Anything else and your cool design is invisible. Script-Based Navigation One of the most common optimization problems is the use of JavaScript in the basic navigation of a site. This is a very common situation and is a result of the way many website builders and content management tools work. Scripted navigation looks cool, so people are interested in using it. However, if JavaScript is the technology that drives page navigation, search engines won't be able to model links properly because of it


Chapter 8: User Effective Design and Search Engine Optimization

Site Relationships: They just don't see the link structure on the site. If search engines can't model the link relationships on your site, deep content won't be visible or gain proper link popularity.

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

Learn about the path to this content. Changing the path or URL of that content can cause search engines to clone the content unintentionally multiple times. This condition significantly reduces the ability of the site to function properly. If your content management system has a system for creating session IDs in URLs, you could be in big trouble. Use sophisticated analytics for tracking, not session IDs. Multiple URL paths. A Common Ecommerce Content Management Problem

Yes many URLs are created during the product lifecycle. Also, since a search engine can only understand the content of a page from the URL it finds the content, when a product appears in a category and is part of a gift basket and is a weekly special (and so on), very quickly the search engine goes through many different links to find the same content. Do your best to ensure that each piece of content only exists in one URL, and that it actually follows the same URL multiple times, no matter where the link is located. Rely on a mature analysis system for channel analysis. Unintentional cloning. when you conclude

Content should only be accessible via a single URL path, other situations that lead to inadvertent cloning of content can easily be seen in content management systems. Suffice it to say that the architecture should have only one URL path to a piece of content. Infinite loop. A consequence of the unintentional cloning problem is that

night cycle. Be careful not to set up search engine spiders

Building Technology, Design and Infrastructure


Potentially endless task of keeping track of "next" links in a calendar or similar. If the 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 scripted links that search engines cannot follow, so searchers can spend their time on the content you want to index. Old URL structure. The first thing many website remodeling projects do

ects is meant to replace the old URL structure. The problem is that search engines may have already indexed the content on these old URLs, and once you change everything, you're essentially restoring the index back to how it was. Additionally, all the backlinks a website has amassed over time point to the old URL structure. At all costs, keep as many old URLs as possible. You may need to change all URLs after replacing your content management system, so if this is unavoidable, it is recommended to assign the old URL a "301 Moved Permanently" status code and redirect from the old URL to the new one on a one-to-one basis URL of the . 301 redirects are the only redirects allowed by search engines.

Domain, directory, and URL structure matter If you're starting from scratch and branding restrictions allow, try picking a domain that includes a keyword or two. It's hard to get a .com domain with high-quality keywords these days, but if you do, separate them with a hyphen. An important part of the impact of UX on SEO is the website's directory structure. This has a decisive influence on the link popularity distribution of the entire site. It's simply better. In any case, avoid placing redundant files in your directory structure. Some content management systems will automatically insert a subdirectory; prevent it if possible. This situation weakens the relevance of the entire page. Search engines understand your site hierarchy based on your site's directory structure, so make sure your most important directories are at the top of the schema. If your environment allows, use keywords in the URL structure that fits the part of the page. Separate keywords and


Chapter 8: User Effective Design and Search Engine Optimization

Do not use too many keywords in one filename. Select the following: Also make sure you've set up a redirect for http://site-in-question. com to 301 Moved permanently redirects to If a page is broken both with www and without www, search engines (especially Yahoo) will index the content of both URLs, opening the entire page to accidental duplicates. This tends to creep in when third parties link to non-www sites and that site has a dynamic link structure.

Content: The Past (Present) and Future King While content creation is someone else's problem, the foundations of website architecture have a lot to do with making relevant content available to search engines. As with all forms of keyword-based search, you need to understand the actual behavior of the person to whom you are showing your source. Search engines are still very "primitive", relying on users to enter keywords to link to resources more or less related to those keywords. Choosing the right term depends largely on whether your website is relevant to the correct context. Ideally, your SEO partner will provide you with a targeted set of key phrases before you begin and work with you throughout the wireframing process. If you don't have such a competent partner in your process, check out the Google AdWords Keyword Research Tool ( and do some analysis on the actual behavior of people using your category . Then spend some time on that list to understand what phrases your potential customers are searching for and use them appropriately on your website. Search engines look for keywords in many places when analyzing a page. 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: A (and present) and future king


So why is content king? This is the core content that the website should 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 connect the right users to your website.

Naming Conventions and Battle Jargon It's important that your keyword goals are reflected in the taxonomy you develop for your website. Using keyphrases in the main structure of your website can make your entire website more relevant to the products you sell. If you sell widgets, don't call your online product listing a catalog, but a widget catalog. Again, use keyword research to make decisions about jargon. For example, use laptops instead of laptops in your structure because people search for laptops more than 10,000% more often than laptops.

Metadata, Titles, and Keywords It's interesting how far we've gone in this chapter before getting back to the basics of metadata. There are tons of meta tags available, but only a few really have much impact, since all the rest are prone to spam. Related tags are: Page Title. Note that this is not a label, but it is

The actual markup in the header. This tag contains the actual page title and represents the most significant 65 characters of the page. Think of the title as a little bookmark sticking out of an old-fashioned library card catalog that says "Clements, Samuel" and indicates that all the cards after that bookmark are books by Mark Twain. Every page on your website must have a unique page title. Do not put keywords in the title and make sure the title contains the most important words. Meta keywords. This tag has little effect on search

Because it's easy to get spam. The exception seems to be that Google AdSense distribution looks at the keyword meta tag, which Yahoo has a very high influence on. meta keywords


Chapter 8: User Effective Design and Search Engine Optimization

They must match the content of the page, and this tag is actually a great place to insert potential typos. Every page should be different. meta description. As with page titles and meta keywords, make sure

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

Use noindex meta tags in search results. Just make sure that the pages you want to index don't accidentally contain this tag. title. Search engines recognize titles , , etc.

As an influencer, as long as you don't spam them. Make sure section titles are both descriptive and contain relevant keywords for that page. Link anchor text. Important Factors in What Link Anchor Text Is

Search engines will consider the page on the other side of the link. This is what causes the "Googlebomb". If enough 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 Google for "click here," Adobe's website will appear among the top results. There are thousands of links to Adobe that say "Click here to download Adobe Reader" or something like that. Use this to your advantage; anchor text should not read "more" or "click here." Instead, it should contain keywords relevant to the landing page.

Divide hair into four sections. It would be useful for you to have separate index pages for left and right squiggly widgets. This level of detail makes it more likely that your page will be an exact match for the legendary long-tail search. Pages that talk about one thing have

Contents: A (and present) and future king


You have a better chance of winning for one thing than a site with multiple things (all other things being equal, of course). Anyway, who cares about reading pages with hundreds of words?

Using Sitemaps In recent years, it has become popular to skip the classic sitemap page. It's a usability bug and an SEO bug. Address the fact that every website needs a sitemap. It might not be cool, but it's necessary. Also includes the sitemap files in /sitemap.xml and /sitemap.txt. While this structure won't improve your site's rankings, it can help search engines understand the directory structure and find new and updated content.

Keep your content up to date. A key factor in gaining and maintaining a top position in search results is to constantly refresh your website's content. This doesn't mean constantly editing everything on the page; it means that the site must constantly evolve. Build a directory structure so adding content is easy and intuitive, and anticipates site growth over time.

Additional Content Considerations A major user interface challenge for content-rich sites is preventing content from being cloned or copied. Beware of creating duplicate pages with seemingly innocuous conveniences, such as "printable" content that is an exact copy of a page in a PDF or similar document type. Secure these types of pages with scripted links or with the rel="nofollow" link attribute. Don't neglect to optimize for the wide variety of digital properties that search engines can index. This topic is good enough for a separate chapter, but suffice it to say that PDFs, videos, images, and other non-web resources are clearly part of the organic search results. Building wrappers around these sources is critical because search engines need pointers to such content. For example, search engines won't recognize an asset as a horse racing video unless the page has a link to that video and the anchor text "horse racing video" is next to the horse racing video text in the code.


Chapter 8: User Effective Design and Search Engine Optimization

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

Link Popularity Explained If there's one holy grail of SEO, it's link popularity. This is the cornerstone of why Google was so much better than other search engines when it came out. Link popularity is a measure of the quality and quantity of links pointing to web resources from other web pages. Google uses the term PageRank and it is the most important factor that can overcome many other shortcomings. A link is essentially a vote on a web resource, and it is often assumed that something of interest or value to others will have links pointing to it from other trusted web resources. Over time, this concept has proven invaluable in the fight against spam and is a fundamental principle of high-quality search results. Because of how link popularity will spread throughout the structure of a web page, it is imperative that UX designers understand this principle.

Typical Distribution of Link Popularity 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 (very commonly, category) that if one page has a PR of 4 and another page has a PR of 5, the page with PR 5 will have 10x the link popularity of the page with PR 4. This is important to understand because PageRank is distributed through pages based on link hierarchy and directory structure. In general, if your home page has a PageRank of 5, then the main section page should have a PR of 4, the secondary pages should have a PR of 3, the tertiary page should have a PR of 2, etc.

Description of Link Popularity


Pages with the most internal links tend to have the highest link popularity. The most important pages must have the most internal links. This includes the main site navigation, sitemap, links in the footer, and embedded links embedded in text. Since link popularity is the key to ranking well in search, you want to place as many links as possible to pages that contain "buy offers" as wisely as possible. Each page has a limited number of links that can point to other pages on that page. A site with a link to another site sends 100% of its available value to the recipient. A website with 100 links to 100 other websites sends 1% of its value to each of those 100 websites. The home page usually has the most links because the home page of the site has the most links from third-party sites. This means that the home page has the most value and can communicate to other pages of the website. If there's a key page that's part of your "sales pitch," include a direct link to that page on your homepage so search engines can see how important that particular page is compared to the rest of your site. If possible, build a feature that can rotate links to in-depth content from the home page.

Footer Links As we look for ways to organize and control the distribution of link popularity on the site, keep in mind that text links in the footer of any page are both a blessing and a curse, having some effect on the distribution of link popularity on the site. Typical footer links point to privacy policy pages and other non-transactional pages, so if you need to put these links in the footer, hide them behind some script, or better yet, use rel="nofollow " link attribute "nofollow" those links. This will prevent per-page link popularity from leaking to pages that don't actually need to rank in search results. It's also better to prevent links from becoming unpopular than to completely exclude pages that use robots.txt.


Chapter 8: User Effective Design and Search Engine Optimization

Cross-linking of content Search engines eat links embedded in text. Just don't overdo it. Some schools claim that search engines don't give favorable ratings after the first few links in a text block. Put the most important links at the beginning of the text, and use link anchor text that includes keywords relevant to the landing page.

Gaming Systems Who Said SEO Is Work, Not Fun? Search engines can pay site owners real money, and in some environments, there are truly limitless ways to get top rankings at any cost. Quite a few SEOs take advantage of their clients by charging large sums of money for bogus techniques that may yield positive results in the short term but can have damaging effects over time. Over the years, webmasters looking for the best results have used various optimization techniques. One of the basic developments in search engine technology is the development of clever systematic game methods. From a search engine perspective, the user's best interest is transparent, highly relevant results at the top of every query. From the perspective of many SEO tools, it's love and SEO.

White Hat vs. Black Hat It's easy and fun to describe SEO methods as "white hat" or "black hat," but it's hard to say which is which. Many white hat optimizers are purists who assert in strong declarative terms that certain technical management, content and link manipulation, and other methods are simply not available. Black hats see this issue as a competition that has nothing to do with cheating: How can there be cheating if there is no established rulebook or court? Their approach is more like a game of cat and mouse, where the cat has all the cards and the mouse can make money: risk, win, big rewards. But when search engines catch up to you (soon

system game


Always) be prepared for your site to be banned or at least inoperable if the method is revoked.

Meta Keyword Spam Many "cheat" techniques are based on user experience principles. An early method of exploiting the system was meta keyword stuffing – essentially stuffing the meta keyword tags with hundreds of occurrences of apples when the website content was about oranges. Basically, a meta-keyword approach was created to help classify the early web. Today, this part of the site has little impact on its search position due to keyword spam. Search engines easily detect this technique and are able to bypass it quickly. Next-gen spam is harder to detect and has its roots in user experience issues.

Clone and Landing Pages Both clone and landing pages are methods used to make a website appear larger or different to search engines. By cloning pages over and over again, webmasters can basically create highly targeted content that can quickly become dominant for specific search terms. Because of this practice, it's important to ensure that the schema prevents accidental cloning, as search engines are sensitive to duplicates, whether intentional or not. Doorway pages, another method of influencing search results, fall into the gray area between white and black methods. On the one hand, Google's webmaster quality guidelines state that "incoming pages ... violate our webmaster guidelines" ( The guidelines identify landing pages as low-quality pages that are optimized for a set of keywords that may not match the actual site or contain spam. On the other hand, how do you help search engines access content that's stuck in unsearchable databases or hidden by techniques that search engines don't like? In its positive definition, a landing page is high-quality static content that search engines can see and understand, while providing visitors with a gateway to dynamic content. Today's content management systems are getting better at the basics


Chapter 8: User Effective Design and Search Engine Optimization

This approach is needed, but it can still be very useful for creating extra pages to present to search engines a static representation of content that they wouldn't otherwise be able to process.

Link Spamming A newer method of deceiving the system aimed at manipulating the popularity of links, which is the foundation of modern search engines. As mentioned above, search engines determine the relevancy of a particular web resource by analyzing the quantity and quality of links pointing to that page from other sites. SEOs manipulate this part of the puzzle through dodgy redirects, subdomain abuse, making every site page "/index.html", and many other subtle machinations.

Final Thoughts This is your first time doing SEO research and it's doubtful. It is now known how much site architecture and related issues affect search engine performance. The current search experience is a step ahead of simple taxonomies or structures. Careful SEO starts with quality of user experience. The architecture of a website is a pivotal point in its life cycle where it either succeeds in search engines or faces inevitable failure. Search engine optimization is a strategy that never really ends, but quality SEO never really begins without the careful attention of a user experience designer. Jonathan Ashton is's Vice President of SEO and Web Analytics and leads the SEO Center of Excellence. His team provides company-wide SEO services, ensuring that the process of designing and building rich interactive experiences results in pages that can be found in search engines. You can find his monthly column "Industrial Strength SEO" at

some final thoughts



Transition: From Definition to Design Time to Visualization, Prioritization and Planning You now have a beautiful, comprehensive list of business and user requirements. You can also get feedback from users to focus discussions. What now? Unless you're on a Shangri-La project, your budget (tight), schedule (exhausted) or both will tell you that you need to focus and manage this list somehow. This chapter covers some approaches from definition to design, including strategies to help your team visualize the solution to be designed, prioritize features to create a unified set of requirements, and plan the next phase of design activities. this project. Carolina Chandler



Chapter 4 explores different project approaches, or methodologies, and how they affect your collaboration with project teams and business stakeholders. A waterfall approach in which the definition and design phases are separated by an approval phase is compared with an improved waterfall approach in which the phases partially overlap. This chapter covers the activities that may occur during the overlap definition and design phases.

define the project, develop it

This point in the process is the right time to brainstorm and visualize features that didn't come up during the stakeholder period

Interviews or user research. By doing this with your design team before prioritizing, you can consider and plan innovative features that meet your business and user needs. Prioritize design requirements. This includes the use of comprehensive checklists

business needs, user needs, and the project team's thinking, and determine their relative importance in achieving the project's goals. At this point, you'll work with the development team to understand the overall effort required to fulfill each request. Plan the activities and documents you will use during the design process. this

Planning determines how you will work with other team members and what tools or documentation they will receive from you, such as site maps and frameworks (discussed in Chapters 10 and 11). This chapter covers each of these three areas, starting with ideas and visualizations that are easy for UX designers to use when collaborating with project team members.

Transition: From Definition to Design


Common Scenario Requirements are defined and approved, and you are designing planned site functionality. Halfway through the design process, you realize that providing a specific tool will really help your users. It's an exciting idea, but the requirements for this new tool are not described, so enabling it now requires a change in priority requirements. You need to make a strong case for changing the requirements list, especially if it means that something else has to be removed from the list (definition takes time) or the project schedule may be delayed. There's an idea that might not have been included simply because it came too late in the game. Although new ideas can arise at any point in a project, taking the time to design features after requirements gathering is complete but before prioritization helps generate those ideas earlier and increases the likelihood that they will be incorporated. It also ensures that you take the time to consider innovative features that your business stakeholders or users may not have thought of.

Generating Ideas and Visualizing Features UX designers have a unique set of skills that can help bridge the mental gap between words (like requirements) and images (like sitemaps and boxes). While people can discuss requirements and discuss language, they often don't agree until they see concepts represented visually. On the other hand, if you jump to some visual detail too quickly, you may be addressing the most important issue (for example, if your users fill out this form). There are a number of conceptual design techniques that can be used throughout the process to help visualize context, flow and story in an inclusive manner before detailed design begins. These technologies will also


Chapter 9: Transition: From Definition to Design

Emphasize the need for features that can be added to requirements documents before prioritization. One such technique is collaborative storyboarding: the visualization of individual user scenarios sketched out on paper or a whiteboard during a brainstorm. UX designers then add details based on these sketches.

Basic Scenario Development Process Prepare for a scenario development session by listing the scenarios you want to explore. To create a scenario, consider the following questions and bring the answers to the conversation: Who are the main users in this scenario? What does it do? 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 they use user modeling tools during the design phase. Is the selected user the first user of the site? if not it is sporadic

User, do you use it often? This will affect the level of functionality you will cover; first-time users may be overwhelmed by the number of options that may appeal to frequent users. You can run the scenario twice to discover different features that each group might need, such as context-sensitive help for new users or custom features for frequent users. What exigencies prompted this user to visit the site? What does he want to do?

Realized, why? You can get an idea of ​​this by looking at the high-level tasks covered by a business or user requirement (such as "find product recommendations"). Maybe a user wants to find product recommendations because they need a pair of snow boots and want to make sure they won't leak or get their feet wet. Gather your brainstorming team for a meeting. The team can be just you and one other person, or it can be a small group of three or four people. (More are possible, but hard to keep everyone engaged and focused on the task at hand.)

Thinking and Visualizing Functions


Ideally, at least one person in the group should be responsible for representing the user's point of view. The second should represent the business perspective (for example, business stakeholders or business analysts, if that role is represented in the project). That doesn't mean you can't change your perspective; you can and should consider both user needs and business needs during the discussion. See the "Maintaining a Good Tension" section for more information on balancing user needs with business needs. Once your team is assembled, tell them what your goals are: understand some of the features you might need to meet your business and user needs, and focus on future design work. Provide answers to the above questions and a list of discussion scenarios. Then walk up to the whiteboard (or put a pen to a piece of paper) and ask the group questions about the scenario, such as: How is it possible that this user got to that page? Consider online search, banner

Advertising, word of mouth and other opportunities. If online searches come to mind, do they accurately reflect the requirements

What types of functionality or actions (such as SEO tagging) support this search? What will the user see on the page relevant to his needs? Which path will the user choose to complete the task? draw with it

Advanced details. Was anyone else involved in this task? If yes, how to include them

(telephone, e-mail, collaborative site functionality) and how do they affect the decision or behavior of key users? Where might the user need help along the way? How will they get it? What happens when users complete their tasks? Common Design Flaws

You might think the user's job is 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: You need to post a new job on your company's .com website. For the purposes of this scenario, let's assume you interview stakeholders and discover that the hiring process is primarily managed by a guy in HR, call him Jeff, who works with people who need employment. 148

Chapter 9: Transition: From Definition to Design

Jeff is very familiar with the job descriptions that currently exist. When he needs a new position, he usually finds out when a potential manager for the new position asks him for a job ad. Then there's the collaborative process between Jeff and the manager (let's call her Emily) to write and publish the job description. Figure 9.1 illustrates what a scene plate for this scene might look like. This image only shows a portion of the scene that can be created here. You can start the storyboard early to show the approval process Emily must go through, or you can continue the storyboard to show job seekers searching and applying for jobs. It's important to note that storyboarding like this allows you and your design team to see your workflow as more than just a series of pages. It introduces human factors and context. Without the human factor (Jeff), your team probably wouldn't remember to enable the "Include Existing Job Description" feature in the first place - although we do this to save time and make sure it includes everything we need.

Figure 9.1 Storyboard initially created on a whiteboard, then sketched and detailed in Microsoft Visio using a Wacom tablet

Thinking and Visualizing Functions


One thing to keep in mind when using storyboards and other types of sketches such as user flows and concept maps is that they are primarily used as brainstorming tools. While this exercise generated some great ideas, these sketches are not meant to be detailed designs. This fact may be due to their sketch form (rather than prototype form), but it is nonetheless an important consideration for business stakeholders, as seeing features visualized even in sketches can sometimes lead to expectations that they will exist in the final product. Another risk here is that participants might be sidelined in discussions about UI 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 scene is designed to solve. To simplify your work and use your time efficiently, keep participants in these types of discussions until you have designed them against a list of prioritized needs. This brings us to the next step in the process: prioritizing those lovely requests that you've spent so much time gathering, the process is often brisk and sometimes painful!

Simplify the prioritization process You have a set of business needs that are enhanced with features based on user requests and your creative work. Now comes one of the hardest parts: narrowing everything down to a prioritized list of high-value needs. When discussing requirements that need to be prioritized, keep the project goals and user personas handy to help you focus the discussion on the target group. In addition to you as the user advocate, the prioritization process should also include: People who represent the company's views (company

spokesman). A person who represents the views of the development team (the so-called

Advocate for development.


Chapter 9: Transition: From Definition to Design

A person who represents a project's needs (such as a project

manager). This person may not have to attend the prioritization meeting, but will identify any constraints that affect prioritization (such as deadlines or budgets) and ensure that the final list complies with those constraints.

The UX Designer's Role in Prioritization Think of prioritization as a shared responsibility of the project sponsor, project manager, and development team lead, not a problem for the UX designer. Nothing could be further from the truth. Prioritization discussions are where successful solutions are made or broken. It is the responsibility of UX designers to use their skills in these important conversations. If you have already participated in the prioritization process, this section provides guidance on how to do so. If not, do what you can to get involved. This means you need to inform the project team of your skills (such as facilitation) and the balanced perspective you can bring. It is necessary to show that you can understand the perspectives of different team members and work together to achieve consensus. See the "Maintaining Good Tension" section for more information on how to achieve this balance.

The prioritization team goes through each request to answer the following questions: What is its level of importance to the business? how important this is

A requirement to achieve one or more project objectives? What is the impact of omitting this requirement? How important is it to users? Does it meet the requirements?

A common user need (or a need that strongly affects priority user groups)? How would it affect the user experience if it were left out? Are there other very similar and potentially competing claims? For the latter problem, keep in mind that multiple solutions to the same problem may compete with each other and cause user confusion (and require more support work). For example, The New York Times might have a development team large enough to handle all shared features

Facilitate Priority Procedures


on (highlighted 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 the past few years, you should probably start with a smaller set of features. How technically feasible is the requirement? What

How long does development take? If you're using a newer technology, expect the time here to be longer. How feasible is the resource for its development? is design

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

Figure 9.2 A snapshot of showing the many sharing features offered by the online newspaper


Chapter 9: Transition: From Definition to Design

Create a worksheet recording your decision on each request. This can include low, medium, or high scores based on the questions above, or you can use a number scale to add numbers to rank. As you develop the list, you may need to combine similar requirements or break down a large requirement into several smaller requirements that represent potentially independent units of work. Note that this system is only intended to help you sort and prioritize; it is not based on scientific feasibility studies. However, it is very useful for managing large lists, sparking discussions, and documenting relative importance. Figure 9.3 shows an example of a prioritization worksheet that uses high-level importance and feasibility categories (low, medium, and high) to assign relative values ​​to each requirement. priority worksheet



business relevance

user meaning



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


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


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


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

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


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


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

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


+#2##$%* *

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

technical feasibility

resource availability















Figure 9.3 Example Request Priority Worksheet

Facilitate Priority Procedures


Assigning a value to each category will generate a lot of discussion in the prioritization team. How do you facilitate discussion and decision-making? The two most important things you can do are understand (and sometimes represent) the different perspectives that are critical to identifying viable solutions and helping resolve areas of conflict within the project team. First, let's talk about representing the right set of viewpoints when prioritizing. This involves creating and maintaining tension between user advocates, business advocates, and development advocates—a tension that is good because it provides a balanced solution that delivers a good user experience, satisfies Design constraints and align with business goals.

Maintain a good tension During requirements gathering and throughout the rest of the project, you may notice conflicts between three roles in team discussions:




Business Advocate: A team member who represents business needs and requirements and ensures that they are captured and implemented as faithfully as possible. The main concerns of business consultants are: to achieve the strategic goals of the company and the department, to ensure that the business vision is not lost during the project process, and to focus on the project goals. User Advocate: A team member who represents the needs and perspectives of the primary users who will interact with the website. Key concerns of user advocates include ensuring that the site meets usability expectations, provides a satisfying and engaging experience, and encourages behaviors that support design goals. Development Spokesperson: A team member who represents the needs and constraints of the technical and QA teams. The main concern is to ensure that the development team is working efficiently within scope and delivering a product that 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 among the three parties is properly maintained (i.e., no single constituency dominates), then the three parties can work toward a balanced solution that meets the project's goals. Each team member should be aware of their interest in maintaining balance throughout the project. If one party dominates, the other roles become irrelevant, and the project risks failing to achieve its goals—or doing so at a much higher cost than expected. See Figure 9.4 for an example of what can happen when the voltage is unbalanced.

Illustration 9.4 Consequences of not having the proper voltage

maintain good tension


Can you play multiple roles on 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 discussion to another—even from one topic to another. As a UX designer, you will often take on the role of user advocate, but you need to understand the perspectives of all three roles and ensure they are consistently represented in order to create successful designs. While it is beneficial to switch roles from time to time, be careful not to designate yourself as the primary person responsible for more than one role. As the project progresses, you can begin to make unquestionable compromises because you won't have "the Devil's Advocate" asking you these troubling but important questions as often. If you have to fill multiple roles, try to find someone who works part-time to fill other roles from time to time to ensure tension is maintained. So far, we've focused primarily on the roles of the business advocate (especially Chapters 4 and 5) and the user advocate (especially Chapters 1 and 6). Let's take a moment to discuss the third central role in the priority discussion: the Development Champion.

Development Advocate If you're a UX designer at heart, you thrive when you put yourself in other people's shoes to understand their needs and goals. This skill is invaluable in your role as a client advocate and ensuring effective communication and collaboration with those in your organization. Let's take a moment to use this skill to outline the goals of developing an advocate. One of the biggest design debates is the extent to which development advocates should be involved in and influence the requirements gathering process, and their role in that process. A developmental advocate's premature presentation of technical possibilities and limitations may limit some of the brainstorming that could lead to highly innovative solutions. After all, the blue sky idea is possible today with additional technical research. Even if the idea isn't feasible, discussing it can reveal basic needs you can meet. (Mapping feature requests to requirements is covered later in this chapter.)


Chapter 9: Transition: From Definition to Design

These are the goals and related responsibilities of the Development Champion: Completing requests on time and within budget Ensuring team efficiency (avoiding duplication of work, ensuring good

communication) Take full advantage of available tools and platforms Choose cost-effective additional tools Ensure future changes do not require a lot of additional work Make the solution scalable to accommodate growth Modular solution so that individual parts can be changed as easily as possible Standardize the solution as much as possible more: fewer modifications

On the system you buy, you will need less retrofit work in the future. Make sure the development team is functioning well. Reduce turnover by offering relatively interesting and rewarding work.


Dealing with Legacy Requirements Step 4

step 1

Review requirements and flag those that are unclear or of questionable value to users.

Inherit a bunch of requests and do pre-checks.


Step 2 gathers information that provides context about the potential user.

"The user is..."

Step 5 Review the selected requirements with your team to explore requirements and conflicts. "that's why."




Step 3 Create a temporary user model.

Step 6 Prioritize any changes you think need to be made. Show them your arguments and present them to the design team. Be direct and pragmatic.




"Good reason!"





maintain good tension


If the development ombudsman is not involved early on, the team may delve into a particular option only to find that it is too expensive, or the development ombudsman ends up missing one or more of its own goals. Finally, the Development Advocate is a great source of information about technical opportunities that could really improve your solution, such as new technologies or unused functionality. One effective approach is to schedule critical reviews with the development ombudsman after the brainstorming is complete, high-level requirements are addressed, and the prioritization process begins. This allows development advocates to examine tool choices early in the process to gain more detail on what might or might not be possible, and then become more involved in the requirements process itself as certain topics and ideas grow in importance. If you believe that certain gatherings will be essential to your attorney after the hearing. You can also record these types of meetings to review later with the development advocate. You may need it during your design process! This clear communication and follow-up during information gathering is key to building strong relationships among team members, which can significantly affect how well the prioritization step proceeds later in the process. Sometimes, however, despite your best efforts, conflicts arise when trying to prioritize requests. Let's talk about how to help your project team deal with this conflict.

Managing Conflict When Prioritizing Prioritization can be a lengthy process if there are significant disagreements. And if these misunderstandings are not resolved, they will continue to appear during the design and development process. These conflicts can have many different causes; here are some of the most common:


Chapter 9: Transition: From Definition to Design

The team disagrees with the goals of the project or

Misleading business tactics (not understanding, forgetting or disagreeing with them). Members of the opposing team are closely related to a specific set of functions.

(Perhaps they are excited about their features, or have already committed to them to a group of influential customers or stakeholders.) There is a conflict between business needs and user needs

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

So they are reluctant to evaluate. Let’s take a few of the situations above as examples and discuss how you, as a UX designer, can be involved in solving them.

Pick Your Battles Some of your favorite features may get sidelined in the process of prioritizing. It's easy to start feeling bad about this, especially when user requests seem to be the most removed from the list. If you defend each claim equally and passionately, chances are that the decision will be made for you. When deciding when to push a particular request and when to compromise, ask yourself some questions: How does the request support the goals of the project? Does it significantly reduce specific risks? For example, does it reduce the chances of users being exposed to spam, and does it reduce negative feedback on the site? Do other suggested site requirements depend on it being functional? What is the impact if this feature is not enabled? Is the value of the feature worth the effort required to develop it (even at the expense of other features you value)? If you have strong answers to all of these questions, put them on the priority list to prove your point. If not, consider dropping it, but be sure to share your reasons so others can see that you're compromising for the overall good of the project. This will demonstrate your ability to consider the wider business context and strengthen your commitment to future discussions on priorities and change requests.

maintain good tension


Disagreement on Project Direction The team disagrees on project goals or the underlying business strategy. Let's break down the source of this conflict into two areas: communication and consensus. If there is a problem communicating project goals or business strategy, ask yourself how you can improve the communication. Are goals or strategies posted where all team members can see them (for example, in conference rooms or online collaboration spaces or at the start of each meeting)? Or, you may need a visual representation of goals or strategies to help your team focus on them and get team members excited about the vision they're working towards. Remember the visualization trick we talked about at the beginning of this chapter? Use them to create images that are easy to print and publish, or make quick sketches on the whiteboard to keep conversations focused. If reaching consensus is an issue, ask yourself how you can help bring everyone together. Is the conflict caused by the fear of giving the user a completely different set of functionality? You can do some research to help resolve some misconceptions, such as surveys, interviews or background checks (see Chapter 6). Or, maybe you can use your coordination skills by having a structured discussion of disagreements, working them out point by point until they are resolved. Conflicting objections to favorite features Team members are bound by their own set of features. Let's say a training executive wants an integrated subject guide, and a sales manager wants to send an exciting demo to spark interest. At the same time, you also have 10 business stakeholders in different roles - and they all have pressing needs. How do you help build consensus? One way is to use a variation of the method you read about in Chapter 6: Creating Affinity Graphs. In this approach, you can use an existing set of requirements or have stakeholders consider their own requirements (especially useful if the requirements gathering process is still in the early stages). If you are working on existing requirements, you can print them


Chapter 9: Transition: From Definition to Design

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

It has one or more large blank walls on which to stick post-it notes A large block of post-it notes, at least one for each shareholder Post-it notes (can be found at stationery stores; there are a variety

different colors), each participant made a set of ten dots. Gather your key stakeholders in a room and ask each of them to take the time to write down key requirements on a slip of paper. Give them 15 to 20 minutes to do this. (Don't peek!) Ask everyone to post their requests on the wall. Then ask everyone to come up and describe what they posted. As you look around the room, start grouping similar requests (if stakeholders think they are similar). Once clearly requested and grouped, distribute sticker points. Inform stakeholders that they can mark which requests have the highest priority for them by drawing dots on post-it notes. They can choose to put all ten points on one request, for example, if they think it's important, or they can put one point on all ten different requests. You'll start to see some definite favorites as people add points. When they finish placing points, review the results together. When forced to choose this path, stakeholders will reveal their internal priorities and the conversation may become much easier.

Surfing For more information on variations of this technique that can be used for prioritization, see "KJ-Technique: A Group Process for Prioritization" by Jared M. Spool:

maintain good tension


This type of technique can help jump-start a prioritization process or reset a process stalled by disagreement. Once you have motivation and a shared understanding, it is much easier to complete a priorities document (as shown in Figure 9.3). In parallel with your prioritization activities, you should prepare for the upcoming full-scale design work. Developing a work plan will help you estimate the effort required to create a detailed design, combine your work with that of others on the project team, and coordinate work to align with project milestones. The following sections describe some considerations to help with your planning.

Plan your activities and documentation Once you have a prioritized list of requirements, and ideally, completed early concept work (e.g. design-time work. There are many types of design activities, each of which will have a different impact on how you design Impact, amount, time required and the type of documentation you will get. This is "documentation" in a general sense and can range from whiteboard sketches to frameworks to prototypes. In the next three chapters we will cover some of the design activities When planning the activities you will use, keep these questions in mind: How iterative is the whole process?

Quickly explore several different concepts (for example, using sketches), then agree on one concept for further detailed development. This approach may also involve presenting the user with one or more design concepts (see Chapter 13 for more information on design testing). How to collaborate during the design process? if you work closely

With a co-located team, you can join more collaborative whiteboard sessions. If your team is widely distributed, consider web conferencing with tools that enable high levels of collaboration over distance.


Chapter 9: Transition: From Definition to Design

How will your project files be shared with the larger team? if

Do you email them to a small team or post them on a collaborative site? What does this mean in terms of size limits and version tracking? How much detail your design needs to include in post-development

program? If your documentation is part of a formal Quality Assurance (QA) process, you should involve someone from the QA team up front so they know what details they will receive from you. How long must your documents be kept? complex project

Once you stop updating a document (such as a set of models), it starts 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 of these changes.) Documents that focus on providing general guidance, such as brand guidelines or libraries of interaction design patterns, tend to exist longer. Who are the primary users of each type of document? this answer

They may be different at different points in the project. The primary users of concept documents are usually business stakeholders and project teams, who use them to communicate and disseminate ideas. The detailed project documentation is primarily intended for designers who need to implement the project; these documents provide specific guidance. What other types of documents do you need to accommodate? You can

You need to provide some kind of link between the prioritized feature list created above and the project you build. There are a few other types of documents you may want to keep an eye on to make sure everyone is on the same page. These documents may include brand guidelines, content plans, functional specifications, or use cases (see How do I estimate the effort required for each type of documentation? here

One is difficult because there are so many variables in a project that affect timing. But by setting a baseline for a rough estimate, you'll have a starting point and be able to check the numbers as more information becomes available. For example, you can set a base estimate that creating each detailed framework will take you about 6 hours. If you are evaluating specific features

Plan your events and documents


It will take about five pages (for example, based on the results of the scenario meeting described earlier in this chapter), and you will have an initial estimate of 30 hours for the function. If you end up with eight pages per frame, try to find out why. If you think this is going to persist, you will need to revise your estimates and possibly change your priorities. What other factors can affect file preparation time? total

The time includes review time with the team and stakeholders, as well as the number of revisions you think need to be made. For detailed sites, this may also include the time needed to align design documents with other documents, such as detailed functional requirements (such as use cases). Write down these assumptions so you can check them later. Do you work with a lot of designers? If yes, how about you?

Do you share work? If you work in parallel but separate areas of your site, you can work on the documents you create fairly independently. If you divide your work in an interdependent manner, you'll need to schedule time to align projects, and you'll probably need a way to track and merge different versions of your documents. Develop the flow early and set design guidelines early so you can be consistent on key elements 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 the activities. In the next three chapters, we'll cover various documents, including sitemaps, workflows, sketches, frameworks, and prototypes.


Chapter 9: Transition: From Definition to Design


Sitemaps and Workflows Building projects from here to there and back Sitemaps help identify the structure of web pages and applications. They can show hierarchy and associations, letting viewers know where users can find content. Task flows take web maps a step further by identifying the different courses of action a user can take within a portion of a web page. The task flow also draws links to error states, content, or page views based on decision points throughout the process. When used together, sitemaps and task flows can give your audience a clear understanding of how your content is built and how users navigate it. Russian Unger


What is a sitemap? 1.0

1.0.1 Regulations


2,0 – 2,x








Figure 10.1 Sitemap for a basic website with blogging capabilities

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 can usually fit on a piece of paper, similar to an employer's organizational chart. However, sitemaps aren't just for websites; they can be used in any type of application where it's useful to identify the page, view, state, and whatever instance is being rendered. In most cases, you'll use a site map to show colleagues and clients how content is organized on your website. It provides an overview of web page navigation and in some cases shows all links each page may have.

What is the workflow? Figure 10.2 Basic Task Flow Showing User Path Depends on Login Status


Is the user logged in? The site is not logged in



bookmark page

A workflow identifies the path or process that a user (and sometimes a system) will follow as they move through a website or application (Figure 10.2). While a site map and a task flow may look similar at first glance, the two types of diagrams serve different purposes: a site map shows the visual hierarchy of a website or application layout, while a task flow describes the options users will be able to select and the Choose the path to take. take. 166

Chapter 10: Web Maps and Task Flow

Business Tools If you are new to UX design and need a tool to create an effective product, you have several options: Microsoft Visio ( Axure RP Pro (www.axure. com ) OmniGraffle ( Adobe InDesign ( Adobe Illustrator ( Microsoft PowerPoint (http :// ) OpenOffice Draw ( HTML Blueprint CSS (

So how to choose? You can ask other designers; everyone has a favorite and is usually happy to name it. Don't be surprised if they respond with "good old pen and paper" like your authors. You can also test a free online trial or choose a free solution like OpenOffice Draw, which is part of the suite of tools and produces the same formats as popular office suites. What else do we use besides pen and paper? Many of the examples in this book are in Microsoft Visio 2003 using Nick's excellent stencils from These ready-made stencils, shapes, and patterns are invaluable to both novice and experienced practitioners. Besides Nick, check out the Institute for Information Architecture, which offers many of these tools on their Learning IA website: Note Microsoft currently offers Visio 2007; however, many companies have not yet upgraded to this product, and to avoid having to deal with version differences, we currently recommend Microsoft Visio 2003.

tool of trade


No matter which tool you choose to use, the internet is full of countless examples of other professionals willing to share them and help you in your career. Most of them are free and can provide the framework you need to create, at least very professional documentation. Unfortunately, many people do not use these resources. Don't be like these people!

Basics of sitemaps and workflows The most basic elements of the drawing program are enough to get you started creating sitemaps and workflows. To make your creations more accessible to a wider audience, it's best to use a standard set of shapes. One such standard is the information architecture visual vocabulary used in this book. It was created by Jesse James Garrett, one of the founders of Adaptive Path (, and is available online at The site has a number of elements to help you articulate your sitemap and workflow, all with detailed instructions and as downloadable templates for many popular drawing and sketching programs (more on that later). To get you started and familiarize yourself with the basics, in the following sections we'll look at the core set of visual vocabulary elements and what they represent. Figure 10.3 Page elements from Jesse James Garrett's Visual Dictionary

Figure 10.4 The page stack in Jesse James Garrett's Visual Dictionary

Pages According to Jesse James Garrett, a page is "the fundamental unit of user experience on the web". Content "views" or "views" may be more realistic today, but pages still matter. There are many ways to draw these pages, but the simplest and most commonly used format is plain


Chapter 10: Web Maps and Task Flow

Rectangle (Figure 10.3). As your sitemap and task flow progresses, you'll want to find a style that works best for labeling and numbering your pages.

Page bundles A page bundle represents many pages with similar content (Figure 10.4). An easy way to understand page strings is to consider dynamic content, such as a shared blog page created using a publishing system. These pages are designed once and live in the design template, but you can click through many pages with different content without leaving the original template design.

Decision Point Figure 10.5 Decision Point elements from Jesse James Garrett's Visual Dictionary




Member Home

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 might be: "Are the user's login details correct?" The answer to this question will determine which page (or content view) is displayed. A failed login results in an error message, while a successful login takes the user to the site's member home page. Take the time to properly label decision points; you'll be glad you did, especially if you share the results of your work with teammates or clients.

Basic Elements of a Site Map and Task Flow


Connectors and Arrows Figure 10.6 Connectors and Arrows from Jesse James Garrett's Visual Dictionary

Connectors and arrows are used to show movement or progression between pages, page sequences, decision points, etc. Connectors usually appear where there is a call to action from one page to another. For example, a link from the home page to an "About Us" page could be a link between the two pages. Arrows (at the top of Figure 10.6) indicate "downward" movement toward completing the task. The barcode connector (bottom of Figure 10.6) can be used to identify when it is not possible to return to the page you came from (scroll "up"). For example, when a user logs into a website, home page content can now be personalized for the user, and users will no longer be able to access generic or login pages from the path they just took. follow.



Figure 10.7 Conditional sentences from Jesse James Garrett's Visual Dictionary

Dashed lines are a fairly common way to display status. It can appear in site maps, task processes, and other work products you may create or invent. You can use dashed lines as links (as shown in Figure 10-7) or borders around regions to emphasize that a link to a page (or an entire section of a page) is conditional on another action or event.


Chapter 10: Web Maps and Task Flow

Common Mistakes You don't go to a presentation with a dollop of peanut butter on your chin or a coffee-stained shirt. Mistakes like this not only sabotage all your hard work, but also prevent you from completing a good project. A messy sitemap or workflow that looks unprofessional can do just as much damage. To help you spot these little bugs with big consequences, we'll take a closer look at some bad designs in the following sections. Learn to spot these common mistakes and then avoid them.

Slow connections Figure 10.8 The connection between two parties is broken

A messy relationship is just that: messy. They don't draw well. They look amateurish and give the impression, to put it mildly, that the author didn't pay much attention to detail in his work. Most tools have some way to help you connect the leads to the box. Take advantage of it. Don't be lazy, no matter what time constraints or pressures you have. In most applications, you can use Shift and other key combinations to drag items in 45-degree increments from the starting point. Take advantage of this built-in feature and make sure your connection is well connected. If you're showing off your pencil sketches, you should keep an eraser handy just in case. Make a rule: Always make sure that all lines touching other objects are fully connected.

common mistakes


Misaligned and unevenly distributed objects

Figure 10.9 Misaligned and unevenly distributed pages

Depending on the tools you use, it can be difficult to ensure that objects are accurately aligned or evenly distributed in a site map or task flow. There are some fairly simple ways to make sure you follow this basic rule. First, enable the grid in any application you use. This way, you can always calculate the grid between objects whether or not the tool provides an option for evenly spaced, properly aligned objects. Fortunately, you can use graph paper and apply the same basic principles as you do with pen and paper. It's very easy to make your documents look professional. Unfortunately, it's easy to make your documentation look like you don't really care about the quality of your work.

Misplaced text Figure 10.10 Inconsistently placed text

Step 1 Step 2

Accidentally placing text (as shown in Figure 10-10) might seem easy to avoid, but it's another common mistake. Find a way to make the text fit nicely into the shape you create, and make sure that any labels placed outside its elements have the correct links (Figure 10-11). 1.0 Homepage


1.0.1 Regulations

Chapter 10: Web Maps and Task Flow

Figure 10.11 Properly placed text

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

No Page Numbers Time to make another rule: number every page of every sitemap you create. Don't create vague, uncountable maps like Figure 10-12. terms and Conditions







Figure 10.12 Sitemap without numbering structure

Every page indicated in the sitemap must be numbered, and the numbering system must allow for further changes as new iterations and design revisions are made. You can use different methods for page numbering; the most common are to identify the main page as 1.0 or (Figure 10.13). Over time, you'll be able to decide which method works best for you, but until you're familiar with and understand the pros and cons of both, let's define your homepage as 1.0. This method allows you to include all decisions and pages that may appear before the main page - such as Flash preloaders, login or registration screens, or many other types of pages - as 0.X. The numbering system in the page map allows other documents to be synchronized with it. The numbering system can be extended to other documents, such as catalogs. Content creators can map their copy and other content

to a specific page (and a specific element in the layout; more on that later). Task is running. Task flows can use the same numbering system to show how

The user will cycle through pages of assigned tasks. Wireframe models (see Chapter 11). Your wireframe page should be shared

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

common mistakes


visual design. Visual designers can synchronize pages and design elements

A specific page in a sitemap. This enables them to segment the inventory when handing over designs to developers. Quality Assurance Documentation. The QA team can

Scripts specific to specific sitemap pages. Your attention to detail and structure at this point helps keep others approaching the project on track and provides structure to their tasks. 1.0

1.0.1 Regulations


2.0 – 2.x blog

3,0 Australia

4.0 radians

5.0 contact

Figure 10.13 Sitemap of properly linked pages, with elements ordered, evenly spaced, and properly numbered

In short, numbering the pages in your sitemap will make other people's lives easier—and that means yours, too.

A simple site map In addition to page numbers, Figure 10-13 is a good model for creating a basic site map for a mostly static site with limited dynamic capabilities. The pages identified for this site are Home Blog About Us Jobs Examples Contact

As you can see, this simple sitemap includes the essential elements of a visual vocabulary while maintaining a professional style and appearance. Most importantly, it provides website users with a clear picture of the navigation, pages and terms.


Chapter 10: Web Maps and Task Flow

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

make pain very good

February 9, 2008

Channel 3/9

Figure 10.14 Advanced View of the Sitemap Home Page

When creating more advanced or larger site maps and web applications, one approach is to use the front page to identify all the steps required to get to the home page of the site. (Yes, we recommend using a task flow as part of an advanced sitemap.) Also, you must identify all top-level pages, global navigation elements, and footer elements. This allows you to show a general overview of your website up front 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 key to help you read the site map (see Figure 10-14). Your team and clients will need it. Don't skip this step!

Advanced Four Cards


make pain very good

February 19, 2008

Channel 4/9

Figure 10.15 Advanced View of the Sitemap Section

The pages created after the first page are created should basically be a mirror image of it. After each top-level page there should be at least one page identifying all the pages, page stacks, and external content required by the site or application (Figure 10-15). Don't be afraid to link subpages if needed. Sitemaps can become wider than standard-sized paper will allow. As long as your sitemap is well organized and links are clearly documented for your audience, there is nothing to worry about. These examples are enough to get you started in the world of sitemaps. As you work through various projects and find that your skills (and often the needs of your team or your clients) grow, you'll find that you can use very different approaches and approaches to delivering your sitemap.


Chapter 10: Web Maps and Task Flow

Breaking Down the Sitemap Architecture You've seen some solid example sitemaps that should cover most of your basic tasks. Don't let these models stop you from discovering what works better for you - and share it with us! Different approaches can highlight information beyond the basic site architecture. For example, consider the site map in Figure 10.16, kindly provided by Andrew Hinton, Senior Information Architect at Vanguard. Stay tuned for new research

subscription support


update personal information

find similar people

"Academic" Interests (Medical, Student, General)

take part in something

Razgovor for print

Learn more about

new battle

manage risk

worried relatives

hang out

expert group study

New diagnosis new stage/sit.

Figure 10.16 Advanced site map. Contributed by Andrew Hinton.

This sitemap not only shows the different pages of your website, but also provides insight into visitor paths and priorities. Andrew ( says he created the sitemap after seeing Wolf Noeding's example, which ignited his creative fire. Andrew uses this site map to show different user scenarios and mental models related to the website. The larger circles on the map have an additional function: they highlight the top areas of your website that generate the most traffic. Like all good UX practitioners, Andrew both borrows and borrows. Once you start to feel more comfortable using these tools and identify what your product and your customers want, there are countless ways to expand your sitemap. Let inspiration be everywhere! Don't be afraid to try new things, but take your time so that the time you spend is useful and valuable.

break page mapping table


Using many of the same basic elements as a site map, a task flow is a diagram that identifies the path or process a user (and sometimes a system) will take as they move through a website or application. Taskflow can be used in many different ways. Combined with a sitemap, they can show how users arrived at pages that display a specific set of information. They are sometimes used to show how a particular type of user (person) would like to view a web page and what that person would like to see based on their personal mental model. Task flows can also be used to identify complex processes that need to be thoroughly understood before the project is sent to the development team. You may not use workflows on every project you work on, and they may not always end up as the work product you present to clients, but they are always worth using - even if just for yourself with pen and paper The benefits of serving. A little clarity can go a long way. To create a workflow, you need to understand the purpose of your users. In some cases you will receive a requirements document, while in other cases you may receive (or write) a use case. Although a use case consists of only a few sentences to summarize the tasks and goals, it allows you to synthesize the user's perspective on the experience. A use case for the scenario in Figure 10.17 might look like this: The system displays a list of items. The user selects an item. The system displays the basic information of the project in the saved mode. A user changes the status of an item to closed. The system checks for pending jobs. If there are pending jobs, the system displays an error message. If there are no pending tasks...


Chapter 10: Web Maps and Task Flow

The system checks for pending payments. If there are pending payments, an error message will appear. If there are no pending payments... a summary page will appear.

Home [My Requests List] Select a Request

Information [Record Mode]

Request status changed to closed

Pending tasks?


error notification


[View pending tasks and requests] Yes

Pending payment request?


info [read-only]

Figure 10.17 This workflow determines how the system displays information to the user based on responses to several conditions.

The task flow in the diagram shows the order in which information is displayed to the user based on whether various conditions in the use case are met. If the answer to any question in the hub ("task pending?" or "payment pending?") is yes, an error message will be displayed, possibly providing additional information to help the user complete the requested task before proceeding. If the answer is "No" in both cases, the user is shown a success screen. The workflow in Figure 10-18 shows the user's path from the calendar application to the travel purchase location. The task flow has a high standard as it identifies three distinct paths that the user must test to ensure that the detailed flow of each path meets the user's needs.

task flow


Calendar S100 Search Purchasing Tariff Calendar

S10 detailed price search engine

looking for

Search by Price (Tariff Matrix View)

search by schedule

scattered date

Select R20 Search Results by Price - Show Trips - Edit Search

P30 seat selector


R60 Flexible Date Search Results by Price

R10 search results (planned) display breakdown - edit search

P10 View Itinerary/Passenger Information-Select Seats


P20 Payment and Billing Information



many pages


Confirmation of P50

Decision Point Connector

conditional conjunction

Figure 10.18 A Workflow to Showcase the Journey of a User at Each Stage of the Purchasing Process

Users of the app can enter a set of travel dates and shop according to their priorities. After setting travel search dates, users can prioritize results based on the factors that matter most to them: price, travel date flexibility, or travel time (schedule). This workflow identifies a high-level path that users can follow to provide guidance to those facilitating the testing. You can create detailed workflows for each path in the group, and hand them off to the development team to build the pages needed for testing.


Chapter 10: Web Maps and Task Flow

Take your workflow to the next level For all the topics in this book, don't think that what you see is the beginning and end of the world of workflow. Explore new uses and expand as much as possible the uses of the foundations described here - as long as there is a good purpose in doing so. As you develop your workflow skills, you may find that you create work products that are more colorful, have more options, change or improve language rules, and so on.

Flow Diagram 10.19 shows a task flow that Will Evans ( takes to a higher level and turns it into a process flow diagram. Its flow is very high-level and flexible, and is used here to illustrate that among the many steps in the design process, the first phase of the design appears to have only one step, but in this particular case, it is important to understand that this phase is not composed of a single event composition. In this case, instead, the first phase of the project consists of many different activities: User research Market research Ethnographic and background research Usability testing Competitor analysis Market analysis Cultural analysis Document analysis

Take your workflow to the next level


Figure 10.19 This flowchart takes task flow to the next level to formulate complex scenarios. Courtesy of Will Evans.

For each of these activities, reports are generated that will be used in various other pre-project documents, and stakeholders will come together to define scope, priorities and dates. All of this is shown in the process flow diagram. As you can see from this example, there are no restrictions when creating workflows. Take a look at the examples above and think about how you can take your product to the next level. It might take some practice, but with a little skill, you can create workflows that delight your clients!

Lane James Melzer (, Chief Information Architect, SRA International Inc. (, created a series of diagrams that go far beyond basic workflows. The diagram in Figure 10-20 shows a workflow that has been expanded to show a "trajectory" of activities, notifications, etc., in a process where multiple events occur simultaneously. They are a nightmare!


Chapter 10: Web Maps and Task Flow

Instead, James explores extending the basic workflow to capture all the different steps and activities in a more understandable format.

Figure 10.20 This swim lane diagram is an example of an extended workflow to illustrate a complex scenario with many activities in many places. Courtesy of James Meltzer.

James describes the project and path as follows: The system allows people to manage information about the buildings they own. This extension will allow building service partners to pass data between systems on behalf of their clients, limiting data entry for owners. The project consisted of three parts: the presence and operation of partners configuring their data services, customer registration and usage of partner data services, and ongoing partner data management and back-office issue resolution. We plan to make major extensions to the existing system. We knew from the beginning that almost all business scenarios involve multiple users and multiple systems. There are a lot of notifications, and a lot of processes are asynchronous. This diagram helps us identify, design and explain the service scenarios needed to implement the project. In the full version of this work product, we have placed detailed wireframes below the flow in this diagram. The whole thing covers the walls. Once we're reasonably confident in the design concept, we break it down into a more traditional multi-page specification.

Take your workflow to the next level


It's important to remember that you're not limited to using task flows or sitemaps. Push the boundaries of the basics shown to you in this chapter. If you really need something to test your skills on, take the time to create a shoe tying scheme. Good luck!


Chapter 10: Web Maps and Task Flow


Design and Manage Wireframes and Reviews - Before You Begin Visual Design Wireframes and reviews are methods of identifying suggested content and structure, as well as the functional behavior of a web page or application view. Combined with sitemaps and workflows, these documents are also useful for identifying prototyping and proof-of-concept scenarios. Wireframes are typically presented in grayscale, with no artwork or final content; instead, they use placeholder content to highlight representative locations that can be used as visual design cues. Russian Unger

What is a wireframe? Basically a low-fidelity prototype of a web page or app screen, a wireframe is used to identify elements that will appear on the page or screen, such as navigation, content sections, imagery and/or media needs, form elements, call-to-action (call to sexual terms) actions). )

Wireframes are usually drawn in black and white or grayscale, use image placeholders, and don't go into font detail (although many use font size to separate types of copy). They come in all shapes and sizes, from the most basic to the very advanced, which almost mimic the look of a full screen. Wireframes are constantly evolving; they are no longer just given to designers and developers as a to-do list. Wireframes are now used to present a website or application to clients, designers, developers, and anyone else on the team who has a core interest. They are often shown to clients to validate "design thinking" before the visual design and development phase begins. Often, the person who creates the skeleton works side-by-side with the person who creates the business requirements (in some cases, they are the same person). It should also be noted that some of the best frameworks and reviews are the result of face-to-face interactions and collaborations between various partners, from business analysts to developers and other designers. Some companies are switching to using their frameworks and notes instead of Business Requirements Documents (BRDs). While the world is far from saying BRDs are extinct, the onset of this change speaks volumes about the importance of being very thorough and thoughtful when making models and reviews. In many cases, the mockup will be presented to the user for feedback that can validate page elements or request changes. wired model


Chapter 11: Frameworks and Announcements

In front of users, they usually have another name: prototype. (See Chapter 12 for more on prototyping.) To help determine the best approach, this chapter covers the basics of framework development and provides examples from designers 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 notes? Annotations are simply explanations and notes about elements or interactions in the wireframe. These typically include information such as content identification or tagging content source display rules interaction rules interaction targets processing rules content/error messages

Comments are best done in a very direct (if not concise) tone with clear explanations. Don't miss an opportunity when taking notes; there's a big difference between should and should. Bad: "Launching this CTA should take you to your homepage." Good: "Running this CTA should take you to your homepage." Well, to be fair , the first example isn't too bad, but the word should confuse developers who might not have their favorite UX designer ready to answer the question. Make sure your commenting style is concise and clear, leaving no ambiguity for anyone who might need to read and rely on your instructions.

What is an announcement?


Who Uses Wireframes? Clear, concise annotations, mockups are great, but who is actually the recipient of this output? Unfortunately, there is no easy answer to this. Your audience may vary from one project to another, from one person to any combination of several groups. Table 11.1 shows the potential recipients of the skeleton model. Table 11.1





project management

Project managers can use these models as discussion points within the team to highlight strategy, technical needs, and very high-level user experience.

business analyst

Business analysts can use these models to ensure their requirements are met and to confirm that they are not missing requirements that need to be included.

visual designer

Visual designers can use wireframes as a blueprint for their output. Wireframes give them a representation of the page elements and behaviors to be included.

content creator

Copywriters, content strategists, editors, and other contributors can use the model to map to the content matrix and identify content needs in projects.

Search Engine Optimization (SEO) Specialist.

SEO professionals can use the model to help determine appropriate naming schemes, replication requirements, and improve overall SEO strategy. (See Chapter 8 for more on SEO.)


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

quality assurance

QA teams can use these models as the basis for their test scripts. Once the model is approved by the client, variability should be minimal, allowing the QA team to start their tasks earlier.


Users can see mockups at a very early stage, sometimes in the form of "paper prototypes," as a mechanism for testing design directions. (See Chapter 12.)


Clients are increasingly involved in mockup reviews to verify that business needs, goals and objectives are being met and gain approval to proceed to the visual design phase.

Chapter 11: Frameworks and Announcements

Scaffolding To build scaffolding, you typically need a set of requirements. These can take the form of a formal client business requirements document, an idea or project outline, meeting minutes, an elaborate site map or workflow, or even a note on a napkin to point you in the right direction. Either way, you'll need an understanding of what you're trying to create for your users, what the connections are, and a general understanding of technical limitations and expectations. Note See Chapters 4 and 5 for more information on defining business requirements. Suggestions for effective meeting minutes can be found in the "Quick Guide to Meetings" in the online awards section of

Once you've gathered the necessary information, taken the time to read through all the requirements, asked questions, and mulled over the answers for added clarity, you can start building your model!

Store Tools Chapter 10, "Store Tools," lists the many design tools you can use to create site maps and workflows. The good news is that you can use most of the same apps for frames and notes. The bad news is that if this is your first time working with wireframes, you might feel a little overwhelmed and not know where to start. But wait - there's more good news. Almost every experienced customer service professional starts with pen and paper, so you shouldn't settle for a technical solution right away (although you'll most likely need to turn your sketches into something digital very quickly). Adaptive Path's Experience Designer Leah Buley emphasized the importance of using pen and paper (as do authors) in her talk "How to Be a UX Team". Leah says: When you first start sketching wireframe ideas, it usually goes something like this: You have one or two good ideas, and then you hit a wall. These ideas might come from things you've seen and liked, or things you've designed in the past. This isn't the end; it's a great place to start.

Who Uses Wireframes?


The mind tends to run around the familiar, but the familiar isn't always the best solution to a problem. When you force yourself to find more different ideas, usually around idea 4 or 5, you come up with something new and interesting. I do not know why it has to be like this. That's it. Templates are available to guide you through this process. In Adaptive Path, we use a hexagonal template, which only provides space for six thumbnails. The number of sketches is not that important. It's important to push yourself beyond the first few obvious thoughts. Six is ​​the magic number (for me) because the six little box templates encourage me to keep going until all the little thumbnails are filled.

Figure 11.1 Six-person adaptive path template

These are wise words to follow - especially if you're just starting to get acquainted with what you're doing in the field of UX design. Over time, you'll start to realize what works best for you, but there's no better advice than Leah. To learn more about her approach, visit for the full How to Be a UX-team-of-one presentation online. Don't be afraid to start with pen and paper—just remember to bring plenty of erasers. Mistakes are part of the process, so even if you've already worked on your pencil drawings, you'll want to make adjustments as you transition to the digital world.


Chapter 11: Frameworks and Announcements

Few professions revolve around iteration as frequently and consistently as UX Designer. A designer's work is rarely, if ever, accepted first hand, and sometimes one can only hope "hope it goes in the right direction". For this reason, start small: take a page or a small section of the project and review it first with your internal team and then with the client team to make sure everything is going according to plan. Aligning the design with the way the client thought about the business goals in advance can save a lot of rework. The same approach can be applied to user testing projects - check it out ASAP!

Start simple: design a basic wireframe. In this section, you'll learn how to create wireframes on a very basic level. You can usually start with a simple sitemap and a few extra requirements, but from these you can build the backbone of your site's home page. Remember the basic site map from Chapter 10, which showed what the structure of a very simple website might look like? Figure 11.2 shows a refresher - as you can see, there is some level of navigation hierarchy. Any X.0 pages identified are likely to be the first or bottom pages. You can use this as a starting point to define some of your business requirements and backbone. 1.0

1.0.1 Regulations


2.0 – 2.x blog

3,0 Australia

4.0 radians

5.0 contact

Figure 11.2 Sitemap for Basic Website with Blogging

Start Simple: Designing the Basic Framework


Getting Started It's not uncommon to write your own business requirements document, which can be both a blessing and a curse. When writing requirements, basically only you - or your customers - can discuss any vague or relatively undefined meaning with them. It often seems like you're making things up - but don't let that discourage you. In many cases, boxes will help you identify gaps in the information you are working with. This can help you create the best solution in the end. Remember that UX practitioners strive to provide the best solution for users, and any first draft of your design will always be used to solicit feedback and influence the next design iteration. Your design doesn't have to be perfect, but you want to make sure it looks clean and professional, and worst case, it's going in the wrong direction. The requirements for this homepage design were limited and brief. Fortunately, the site map shown in Figure 11.2 contains enough information to formulate usable navigation on the page: the home page (number 1.0) is the highest level of navigation. situation

& conditions (1.0.1) are likely common footer elements, or at least shouldn't be considered part of basic navigation. Other basic navigation elements include About (3.0), Work (4.0), Con-

tact (5.0) and Blog (2.0-2.x) - displayed as a bunch of pages, so you can be sure it will be seen as multiple dynamic pages, and can have "previous" and "next" navigation. These basic navigation elements provide a lot of information to get you started - but it's far from enough to effectively create a home page for your website. To help guide, the client provided some additional information: The firm is a boutique UX design firm known for its blog and the range of projects it works on. It is important for website visitors to quickly understand what your company/website is about through limited text and strong, evocative images combined with UX design. Also, clear navigation is important (I prefer reusable headers and footers if possible) and


Chapter 11: Frameworks and Announcements

Include a call to action in your latest blog post so visitors can quickly read a summary of our latest approach to current issues in the customer experience space. It would be nice to be able to highlight recent work on the homepage if possible, but that's secondary since most of our work is usually in development or strictly confidential.

Wireframes and Annotations There are many ways to interpret these requirements, and the first time a framework is presented to a client, it might look very similar to what is shown in Figure 11-3. Art Model Home Notes with Notes 1

Logo 2





Our business





1 · Logo image. · The logo will be used as a link to the home page of the site

Place anywhere from anywhere. 2 · Initial navigation. · Contains a link to the home page of the site

from anywhere on the page. 3. Blog navigation. · From any link to the blog landing page

placed on the page. 4 · Our after-hours navigation. · Contains a link to our dissertation landing page

from anywhere on the page. 5 · Navigation About Us · Contains link to landing page About 6 7

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.




Jak widziełem, dojdę do minimum, korzy nie sządą kar cielesnych wobec graccy, 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.

Bardzo mi przykro z kuglice u prahu, consectetuer adipiscing

13 more > 17

thing #


15 16 17 18 19

© User Glue | Regulations | Contact


Jak widziełem, dojdę do minimum, korzy nie sządą kar cielesnych wobec graccy, jak szęży z nich. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam volutpat.维切伊 >


from anywhere on the page. · Contact navigation. · Allows you to link to the contact page from anywhere on the page. · Rotate the hero image. Images will alternate between images that are aesthetically pleasing and on-brand. · Welcome salutation. · A general textual title for the page comment. · Welcome content. · A general overview of the content of the website. · · Title. · The title of the random sample shown in the portfolio. · · Image link. · Images of random samples shown in the working portfolio. Included is a link to view details of a random sample shown in the portfolio of work. · · Summary. · A short textual summary (maximum 1-2 lines of text recommended) of examples randomly selected from the portfolio. ··More links. · Link to view details of a random sample shown in the portfolio. · · Title · The title of the latest live blog post. · · Introductory content · The first 200 characters of the latest blog post. ··More links. It will link to show the full blog post and the latest live blog post. · Content protected by copyright. · Copyright and current company name. · Terms · & · Terms Link · Allows you to link to the Terms · and · Terms page from anywhere on the site. · Contact link. · Allows you to link to the contact page from anywhere on the page.

8. Welcome title. · A general textual title for the page comment. 9 · Welcome content. · A general overview of the content of the website. 10··Title. · Random headline example

Present with portfolio. 11··Image link·Random photo

nt blog title>


ból siedzieć amet, consectetuer a 15 ummy nibh Euismod tincidunt some erat volutpat.


i will let you know who we are



15 16 17 18

Note 19

Example shown in working portfolio. Included is a link to view details of a random sample shown in the portfolio of work. · · Summary. · A short textual summary (maximum 1-2 lines of text recommended) of examples randomly selected from the portfolio. ··More links. · Link to view details of a random sample shown in the portfolio. · · Title · The title of the latest live blog post. · · Introductory content · The first 200 characters of the latest blog post. ··More links. It will link to show the full blog post and the latest live blog post. · Content protected by copyright. · Copyright and current company name. · Terms · & · Terms Link · Allows you to link to the Terms · and · Terms page from anywhere on the site. · Contact link. · Allows you to link to the contact page from anywhere on the page.

Figure 11.3 Wireframe for loading comments in homepage design

Start Simple: Designing the Basic Framework


Annotated wireframes detail each element on the page, along with expected CTAs and action outcomes (such as loading a specific page). This example works very well due to the limited number of elements and the limited amount of detail required.

Figure 11.4 Active home page design for

As shown in Figure 11.4, today's version of the home page is slightly different from the original frame in Figure 11.3. For example, the Portfolio Examples section was removed as time frames and content became an issue. Also note the difference in naming conventions for navigation and calls to action: the skeleton is used as a guide, not the final word. Your final result will often also contain various minor changes and updates compared to the contents of the frame.


Chapter 11: Frameworks and Announcements

Exercise: Design a homepage wireframe. Now that you've seen the examples, it's time to get down to business and make your own wireframes. You've been tasked with redesigning the homepage of Global Cruises, a fictional international cruise line. Global Cruises wants to make its homepage a more effective sales tool and source of information for repeat customers – typically those who book a cruise and want to learn more about other options and add-ons, updated terms and conditions, and more. In this exercise, you'll use the following prompts to create a framed home page that includes comments on a 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 title destination sign

Update travel experience with event logo

plan your trip

looking for

before travel

world cruise

Club VIP

sales volume


my world cruise

Welcome back,no? ) | XX Days to Next Cruise - Reservations Management | Book Travel Extras | Online Application

GLOBAL CRUISES Sign up to receive emails from Global Cruises | Not with? Click Here About Global Cruises |Contact Us |FAQ |Travel Agency Search Engine|Site Map |Legal Information |Price Conditions |Privacy Policy © Global Cruises

Figure 11.5 Global Header and Footer for Existing Global Cruises

Title/Navigation must be Destinations | Travel Experiences | Plan Your Trip | Pre-Travel | World Cruises VIP Club | Promotions | My World Cruises Welcome Back(No?) XX days of travel | Booking Management | Booking Travel Allowance | Online Application

Activity: Home Page Layout Design


Footer must readSign up to receive emails from Global CruisesAbout Global Cruises|Contact Us|FAQ|Travel Agency Search Engine|Site Map|Legal Information|Price Conditions|Privacy PolicyCopyright Information Additionally, the site must be able to display multiple promotions Ability to display title/message CTA for customer service CTA for travel agency search CTA for popular itineraries

"Nice to have" is the ability to display the newest, most popular and/or discounted itineraries. Ability to display geographic location and waypoints. As an additional site (eg

To Hawaii, book an island tour), meals on board, etc. Anything you can add that might be of value

World Cruises Now work begins. Start sketching wireframes - don't forget to properly annotate! Once the framework is complete, see the next page for examples of other top professionals who have acquired the same set of requirements.


Chapter 11: Frameworks and Announcements

The Result: Designing the Homepage Wireframe Will Evans, UX Architect at Semantic Foundry (, was kind enough to create a wireframe as requested by the Global Cruise exercise. Compare your work to his project in Figures 11.6 and 11.7 to see how his approach compares to yours. Below is an explanation of how he puts his framework and annotations together. Road warning 990 pixels wide

looking for a cruise








new route




popular routes

11 1


|Travel experience


plan your trip


before travel


Club VIP World Cruise

Welcome back to iMMŔLogout





sales volume


View itinerary |My World

15 days until next sailing -

9,0 13


Travel Warning: link to v0.2.0.0


Link to homepage of brand/logo


Search using defined predictive user scenarios 3.X



New Linked Itineraries dropdown: view links to section 4.x for itineraries Popular Itineraries - dropdown shows top 5 itinerary destinations Links: jump to section X.0


Travel Experience Link: Go to Section X.0


Plan your trip Link: Takes you to Section X.0


Pre-Travel Link: Go to Section X.0


Global Cruises VIP Club Link: Points to Section X.0 Special Offer Link: Points to Section X.0

my world 12




Media/Flash/Pleasure Image


Hero Shot 17 World Title | Create Your Own Star


I need help planning a cruise



Header Consectetut Adipisicing Transparency is only narrower Houses or the pain of feeling wants to be a hair in EU pain



pleasure pictures


Header Results Adipisicing

Header Results Adipisicing

He is more than angry, more painful than life, hoping to be uncultivated.

He is more than angry, more painful than life, hoping to be uncultivated.

Creative Headline #1

Creative Headline #1

Title idea number 3

Title idea number 2

Title idea number 2

Creative title number 4

Light is the Lord's own rein, that is, wrath hurts in reproach, and in sweet he wants to be a feather in pain.

Title idea number 3


November 8, 2008 at 18:46

Brand Promotion

But in order for you to understand where all these delusions of those who blame pleasure and glorify pain come from, I'm going to unravel the whole thing and what this inventor did

publish your

I am so sorry for the loss of consectateur nonummy lorenzin. Sometimes the average person finds out that he is wrong.

25 Sign up for global email.

not with? Click here

My Global Cruises link: Go to Section X.0 Logout link: Log out user from session


Link to View Itinerary: Takes you to the My World/View My Itinerary page. My Global Links: Takes you to a personalized page Rotating image for special offers/packages


with your link to Crowdsourcing


Links to special book deals related to the hero's large image.


I need help planning a cruise


Promotions for CT as/Affiliates


Share Your Moment Call Me Member Profile Post your own "Earn Your Moment" link on crodsourcing.


But in order for you to see the root of all these fallacies of those who accuse pleasure and glorify pain, I will open up the whole thing and explain exactly what this discoverer of truth and builder of a happy life says.





pleasure pictures

pleasure pictures





moments with you

Book this special package

You now! go


register e-mail


link change country


Global Footer Links


About World Cruises |Brochures |FAQs |Travel Agency Search Engine|Site Map |Legal Information |Price Conditions |Privacy Policy

page 2

Figure 11.6 Will Evans’ Global Cruises Homepage Wireframe

Activity: Home Page Layout Design


Road warning 990 pixels wide

looking for a cruise









new route


OK, Will "The Bahamas" | Travel Experiences | Plan Your Travel My | Discover Before You Travel



Popular Route 1

Club VIP World Cruise 6.0


sales volume


special cruise

Welcome back to iMMŔLogout



bahamas and florida


bahamas and florida


bahamas and florida


bahamas and florida

charleston freeport

charleston freeport

15 days until next sailing -

7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


Great Stirrup Cay (our private island) Port Canaveral Charleston


Media/Flash/Pleasure Image

Filter global titles | Create your own star Need help planning your cruise

charleston freeport

charleston freeport

Great Stirrup Cay (our private island) Port Canaveral Charleston



Quick tip: cached results show matching strings


Cruise map with the following metadata: 1. Price 2. Average Rating 3. Title: Cruise Name 4. Duration 5. Ports of Call 6. Details Link 7. Book This Cruise 8. Save/Favorite this Cruise


Faceted navigation allows users to dynamically change port, month of travel, vessel or price range and dynamically sort/filter the corresponding results. Each of these actions can be undone when the user views the full results on the search results screen


After the user adjusts the predictive search filters, they can click to view all search results, which will use Ajax techniques to load the full set of results into a javascript field for quick sorting.


Share Your Moment Call Me Member Profile Post your own "Earn Your Moment" link on crodsourcing.


Shot FridayHero Saturday title

Book this special package


- All promotions/news related to ships

$190 $1650

The title of Adipisisic Duis will follow, or pain will be rebuked in pleasure, which wants to be an inch away from pain, and there will be no birth.

Light is the Lord's own rein, that is, wrath hurts in reproach, and in sweet he wants to be a feather in pain.

moments with you


Price: Pleasure Image

Light is the Lord's own rein, that is, wrath hurts in reproach, and in sweet he wants to be a feather in pain.

New expandable itineraries: see links to section 4.x itineraries Popular itineraries - dropdown list showing top 5 itineraries




-any month-

pleasure pictures

Header Results Adipisicing

Search using defined predictive user scenarios 3.X



Your You Y Moment results are out now! go


Link to homepage of brand/logo


Friday Saturday 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Homeport/City: Promotions/News Washington, DC 8.0


View itinerary |My World

Friday Saturday 7 nights

Travel Warning: link to v0.2.0.0



Friday Saturday 7 nights


my world

HEDONIC IMAGE 9.0 View all search results

The title of Adipisisic Duis will follow, or pain will be rebuked in pleasure, which wants to be an inch away from pain, and there will be no birth.

Creative Headline #1

Creative Headline #1

Title idea number 3

Title idea number 2

Title idea number 2

Creative title number 4

Title idea number 3


November 8, 2008 at 18:46

Brand Promotion

But in order that you may see where all these natural errors of those who accuse pleasure and glorify pain come from, I shall open the whole matter and explain exactly what this discoverer of truth and builder of a happy life says. But, In order for you to understand where all these delusions of those who blame pleasure and glorify pain come from, I'm going to unravel the whole thing and what this inventor did

publish your

11 1 12

register e-mail


link change country


Global Footer Links

I am so sorry for the loss of consectateur nonummy lorenzin. Sometimes the average person finds out that he is wrong.

13 12

Sign up for global email.

not with? Click here


About World Cruises |Brochures |FAQs |Travel Agency Search Engine|Site Map |Legal Information |Price Conditions |Privacy Policy

Pages: 3

Figure 11.7 Will Evans Global Cruises Home Page Frame with Search Enabled

Wireframes in Will's Words To me, wireframes serve as a form of "thinking device" for setting up and exploring a specific problem space - in this case, it's the cruise line operator's homepage. Designing with a model is about finding alternatives in a problematic space; it's a process of setting up and solving a problem, which means I always start with context. In this case, the main client wants to easily find the best cruise at the right time at the right price. Simply put, I choose my primary audience and a campaign that allows them to solve a goal quickly, easily, and elegantly. By drawing a series of wireframes, I can explore alternatives and come up with, test, and in many cases reject impossible and possible ideas. I already knew that I wanted to design the best cruise search interface possible, and I wanted this activity to be at the heart of the design. Here I outline the concept of providing instant sailing suggestions, even before the user commits to viewing them


Chapter 11: Frameworks and Announcements

Full screen search results. I want the user to be drawn into the conversation and participate in the process of finding a great cruise. looking for a cruise


Ok, we found the will for "Bahamas".


18 special routes


bahamas and florida


bahamas and florida


bahamas and florida


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





Friday Saturday 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


Friday Saturday 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston


Friday Saturday


Friday Saturday

Filter Results Y Home Port/City: Month:



-any month-


- any ship

$190 $1650

view all search results

Figure 11.8 Willa Evans cruise homepage search result function

For a cruise operator, I outline headers, footers, static content, and areas that need to be masked when designing content modules such as calls to action and promotions. I'm sharing the results of this step with key stakeholders, but I'm also bringing in visual designers and development and QA managers so they can contribute to the process, provide more ideas, and start documenting pitfalls and limitations. Ultimately, as a designer, I have to make decisions about the implementation of the project in the specification. I create two or three candidates for final consideration and use annotations to make the wireframes explain the situation to stakeholders and target testers. The wireframe models you see in Figures 11.6 and 11.7 are now at a stage where design changes are minor and details are being worked out.

Activity: Home Page Layout Design


Compare and Contrast Note that the example in Figure 11.3 and Will Evans' work have a very similar -- albeit different -- framework style. Now it's easy to look at them and proudly declare, "These are skeletons!" Both have their own style and approach, but are very similar at their core. The examples in this chapter are a good place to start finding the style of framework that works best for you.

Photography by Maciej Piwowarczyk

Visual Design: When Wireframes Grow and Find Their Way in the World

Figure 11.9 The Global Cruises home page by Mark Brooks


Chapter 11: Frameworks and Announcements

Based on Will Evans' requirements and framework, Mark Brooks ( created the homepage design for the fictional Global Cruise Lines. When looking at the visual design in Figure 11.9, notice how it takes into account the layout and content of the page. As the project moves through the process and into development, the interaction model becomes a reality.

Continuation of the design exercise: which design is the right one? Design is neither good nor bad as long as it meets the requirements. From time to time, you may be prompted to create multiple mockups for a single page to explore different approaches, work out details, and present yourself to potential users, colleagues, or even clients. This is perfectly acceptable. Remember this is a repetitive exercise. We almost always guarantee that the work you present to a client won't be deemed "right" or "final" on the first try. Typically, you'll find yourself doing at least one round of iterations and updates. Unfortunately, this sometimes spans multiple rounds - but this is the nature of the project and should ultimately result in less research for downstream working partners. Explore the differences in approach and presentation style by comparing wireframes and reviews to the two examples above. Compare it to the example home page earlier in this chapter and what you've done. Find the similarities and differences and come up with what works best for you, unless you already have a set template. In many cases, the hardest part of creating a wireframe is when you first start drawing. Follow Leah Buley's advice and start sketching out lots of ideas - doodling and drawing, exploring different approaches, and testing your designs with co-workers, colleagues and family until you're sure you can defend your designs (rather than become defensive ). Make sure you're heading in the right direction.

Activity: Home Page Layout Design


A final note on wireframe presentations Once you start creating wireframes and feel more comfortable with your work products - and realize how important they are to your workflow - it's easy to forget that not everyone knows that creating them takes How much time and thought. Often, customers and business partners may encounter models that differ in quality, complexity, or annotation style. In fact, you may find that many of your business partners and clients have never seen a wireframe before (even if they claim to have). It's also common for clients and business partners to be confused about the difference between sitemaps and frameworks and what they are used for. In other words, your first wireframe could be your client's first! That's why it's so important to set up the scene exactly for the scene you want to portray. Before showing the mockups, clarify what they are, how they look compared to the final visual design, and what their purpose is. Here are some additional tips for presenting models: If possible, involve the client's team during the unveiling; try to get them

Actively participate in the drawing board. Explain to them that they were involved in the wireframing process and that the end result will look similar but will be produced in electronic format. It's very important to clarify that this is an activity that will result in wireframes that can look very different as you explore design options. Find strong metaphors to convey the difference between the two

frame and final project. A popular metaphor is: "A layout is to an app/website what a blueprint/floor plan is to a house." Wireframes make it easier to implement changes at a stage when changes are usually less expensive (before the construction team gets involved and the foundation is poured). easier and more effective. Tell attendees that wireframes are not final renders

Graphical processing of the page. Rendered wireframes include content, overall appearance, and interactions


Chapter 11: Frameworks and Announcements

page elements. Once the skeleton has passed, construction can begin. (Oh, there will still be minor changes!) Get your visual designer involved - if you have the time and budget - to make sure

Design mockups to show the difference between wireframe and final design. If possible, show the client examples from other projects that show how the wireframe and final design are both similar and different. Explain how the rest of the design team will use it

Model - It never hurts the client to understand the importance of reviewing and approving this milestone and how the model interacts with the rest of the project. Moving your designs will be easier when your clients and work partners begin to understand and appreciate the value of models and their place in the design process. Why? Because wireframes help create visual clarity and direction for the rest of the design. In many cases, coworkers and clients can even advertise the usefulness of the framework on your behalf. This allows you to spend more time designing user experiences and less time selling!

A final note on the introduction to the framework



Prototyping breathes (some kind of) life into your design Prototyping is an effective way to test and validate proposed functionality and design before investing in development. You can use many tools and methods for prototyping, from quick and dirty (but we prefer quick and clean) to interactive and powerful. The method you use depends largely on two factors: the time and materials you can allocate to developing a prototype. Russ Unger and Jono Kane


What is prototyping? In the context of user experience design, prototyping is the act (and in many cases art) of creating and testing all or part of the functionality of an application or website with users. Prototyping can be done using analog tools such as a whiteboard or pen and paper, or digitally using PowerPoint, Acrobat, Visio, OmniGraffle, HTML, or other technology-based tools. Prototyping can be an iterative process, as typically prototypes are created to identify UX issues or to validate UX. After gathering feedback, you can make changes to the prototype for additional testing. In other cases, a (sufficiently) successful prototype can push the project into the next phase of the development cycle. Remember, prototyping is a process, not an artifact. You may end up creating screens and (sometimes tentative) features called prototypes, but these are part of the prototype design, not the final product. The result of the prototyping process is actionable feedback from the concept that can be used to improve and refine the design. However, this chapter focuses only on prototyping, leaving the details of testing to Chapter 13.

How many prototypes do I need? Any UX design process should include some level of prototyping, whether formal or informal, interactive or static. You don't need to prototype an entire website or app. In fact, prototyping can be very effective when using only a representative sample of the system—in other words, you don't need to simulate the entire system, just the key parts of it. In most cases, you'll want to test a few concepts, and your prototype should include these concepts and more. You can create prototypes using any number of ready-made methods: whiteboards, pen and paper sketches, scripts, cardboard cutouts, and more. Additionally, many digital tools are available to create interactive prototypes and engage test users in a more realistic environment.

How many prototypes do I need?


The prototyping method you choose will largely depend on time and available materials. Below are some of the more popular methods that can meet many of your prototyping needs.

Paper Prototyping Few activities bring you back to your early days quite like hands-on paper prototyping. The only tools you'll need are pencils and pens, paper, scissors, and whatever else you can roll up from the art department or buy at your local office supply store. Paper prototypes are flexible. As long as you have an eraser or more material, you can create as many scenes as you want. You can also quickly modify the design between tests - that is, if a potential user reports that something you've created is obviously wrong, it's not a complicated process to update the design before showing it to the next potential user. It's also cheap. Aside from the time you invest in paper prototypes, you can generally create any scene for far less than the cost of some great lattes. Paper, sticky notes, index cards, pens, etc. should already be available, and if not, you won't break the bank by hoarding. The process is simple: draw the piece of functionality you want to test. Show functionality to users. Record feedback (it's paper, so flip your prototype over and start writing). Then move on to the next user or upgrade and start over. simple. game. Efficient. Applied early in the process, paper prototypes can help you uncover design issues before large investments are made. Changes at this stage can be implemented quickly and efficiently, reducing risk. This allows you to make effective changes before the project becomes too invested. Using three sheets of different colored paper, draw each card in Figure 12.1 as it would appear on a web page, stacking each other. The Global Now tab is positioned at the top to display its content 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 choose different browsing options.


Chapter 12: Prototyping

Figure 12.1 Paper prototype with vertical navigation with tabs

Figure 12.2 Paper prototype of vertical tabbed navigation with My Trips tab activated

When the user selects another card, that particular card moves to the top of the stack to reveal the content area view of the new active card, such as the My Itinerary card shown in Figure 12.2. Prototyping on paper can be done on the lowest possible budget and can be as simple as the exercise above. Once you start exploring the complete system, the time investment becomes considerable (although the cost of materials only increases slightly). This approach can get expensive if you have to change the basic navigation of a hundred-page paper prototype. While paper prototypes are usually cheap, they are not reusable when components need updating. At this point, you should consider whether it would be more beneficial to switch to digital tools.

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 users exactly the interactive parts of your website or application. Digital prototyping relies on many other aspects of the design process. When presenting or testing your digital prototypes, block models and visual prototypes, and visual design resources (if available at this stage of the process), you will be able to refer to your personas for a realistic fit and completion of your prototypes.

Wireframe vs Reality Prototyping As with paper-based prototyping methods, digital prototyping mileage may vary. Depends on the tools, resources and skills you have

digital prototype


process and the requirements you face, you may find that a prototype that looks like a wireframe mockup is good enough for your project. In fact, it could be better. Wireframes can show your audience that the project is still a work in progress, rather than a final page ready for production. On the other hand, sometimes when you test a design with users, you discover that the most important aspect of the prototype is the reality of the final system. The outcome of your digital prototype depends on three factors: What does your timeline look like?

Do you have time to gather your team and build an amazing near-production-ready prototype that presents a clear vision of a production-ready site to users sitting in front of it? Do you have hours to export a wireframe to HTML or create a very simple Flash project that just shows the page flow and basic interactive elements in your project? Both types of digital prototypes are very useful. However, with any real project approaching a deadline, it's important to set expectations in terms of time and available materials. Who are you building this prototype for and why?

The key to successful prototyping is knowing what to do with it before diving into the design. Are you building a prototype to test your project with users? If so, what should you focus on when testing? Does it matter if the prototype is a black and white wireframe or does it have to resemble a live web page? Did you test the visibility of buttons and links? Are you prototyping a business presentation that requires an initiation fee from a director, manager, investor, or other team that can sign a check at the end of the day? If so, what are you trying to tell them? What should be functional, and what just needs to look functional? These questions can help determine your digital prototype requirements.


Chapter 12: Prototyping

What resources, tools and skills are available to you?

If you're not an HTML or Flash expert and don't have the budget to hire one, you can still build powerful prototypes using simple presentation tools like PowerPoint or Keynote or wireframing tools like Visio or OmniGraffle. Even a simple PDF file is enough.

HTML and 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 an expert in front-end coding, you can still become an HTML prototype creator with basic HTML knowledge. Basically, there are two ways to create HTML prototypes: manually code the HTML or use a WYSIWYG editor such as Adobe Dreamweaver, Realmac's RapidWeaver, or Microsoft Visual Studio. These tools have a code view and a layout view, allowing you to visualize your coding work without opening a browser. Prototyping with a WYSIWYG editor. The nice thing about using Layout View in a WYSIWYG HTML editor is that you can build page layouts with roughly the same amount of effort as creating page layouts in Microsoft PowerPoint, Apple's Keynote, or any other simple layout application (more on that later) ). Adding interactivity like links, mouse events, etc. is just as easy. 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 does that mean? It just means that what you see in Live View is exactly what you get in Apple Safari and Google Chrome - assuming you've fine-tuned the details of your prototype. Dreamweaver CS4 is a very powerful prototyping tool, especially when combined with Adobe Fireworks CS4.

digital prototype


Figure 12.3 Simple Example Prototype Created in Dreamweaver CS4

Creating a Basic HTML Prototype Probably the cheapest way to create a simple, quick and dirty HTML prototype is to do it "by hand" -- manually typing the code into a text editor. One of the most common reasons for moving from wireframes to prototypes is the need to demo or test a proposed page flow and navigation. By taking element blocks or even entire pages from wireframes (or design mockups) and placing them as clickable images in your HTML prototype, you can build a working prototype very quickly and easily. A very simple prototype that allows you to click an image on a page in the browser and it loads a different page is very simple. For the exercises below, you must have a home page and skeleton search results, or you can download sample images from Note Typing errors are the most common errors in HTML coding, so pay special attention to typing accuracy.


Chapter 12: Prototyping

1. Export a home page frame from your favorite tool such as Visio or OmniGraffle or a design upgrade 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 store homepage.gif there. Note JPEG is great for raster and photo-like images; GIF is better for frames 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 in the same Prototype folder as homepage.html . If you're using TextEdit, be sure to select HTML as the file format. 3. Insert the following HTML code into the new document: 1]iba3 1]ZVY3


1$]ZVY3 1WdYn3 1$WdYn3 1$]iba3

4. Save the document and open the file in a web browser. You should see a blank page, but pay attention to your browser's title bar. It should say "House". 5. Edit the homepage.html code in a text editor. Enter the following HTML code between the and tags: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

This code turns the entire homepage.gif image into a clickable button that loads the searchresults.html page (which you need to create for this to work successfully). 6. Save the document and reload the page in the browser. You should see the new home page you just created in your browser (Figure 12.4). When you click on the 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 contents of the search results box. 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 return a link to the home page (homepage.html). You will need to replace this line of code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

Where: 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 to link the two pages together.

Figure 12.4 Home Page HTML Prototype as Seen in a Web Browser


Chapter 12: Prototyping

Breaking Down the Code Now that you've created a basic prototype using very limited HTML, let's take a quick look at the code or HTML markup you used to better understand what you've just accomplished. HTML tags head and title 1]iba3 1]ZVY3



is the basic tag required by every HTML document. An important element to note is the title tag, which allows you to specify the name of the page. Image label 1^b\hgX2]dbZeV\Z#\^[3

Also a simple tag; that's all you need to view the image in your browser. An anchor tag like this, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

Used to place links in HTML documents. For simplicity, the anchor tag example uses a relative path - "relative" since the tutorial project is in the same folder. The absolute path is: 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

While this HTML is unstyled or non-standard (don't show it to developers - they might be asked to give you a tough lesson in coding practices!), it's enough to get your prototype working in the browser - like The way. Remember, this prototype doesn't have to be perfect: the goal is just to get your idea across to your audience. This simple markup example creates linked HTML files that let you click between pages, but what if you want more granularity in the clickable areas in your layout? Answer: Picture card. Using image maps, you can specify an area 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 map parts of the image that can be combined without actually knowing how to create HTML. For more information on creating image maps, see "How to

digital prototype


My Web Page," by Dave Taylor, HTML prototyping is just one approach to digital prototyping. Many different frameworks and dynamic coding languages ​​can be used to create very robust prototypes , for almost any need. If HTML prototyping is an area you want to explore and expand on, you can find tutorials and other resources for more detailed information in this area. To get started, you'll probably need to be familiar with JavaScript, PHP (or other Dynamic Coding Language), jQuery (, or the Yahoo! Interface Library ( Note For more information on HTML, see Patrick Griffiths' HTML Dog: XHTML and CSS Best Practices Guidelines (New Riders, 2006).

Other Prototyping Tools You've learned about useful options that can help you prototype in both analog and digital spaces. In addition to these methods, there are many other software tools that can be used for prototyping, from basic "get the job done" tools to more powerful, interactive and intelligent tools. The list below is not exhaustive, but will give you options to create the right prototype for your situation. PowerPoint and Keynote Prototype PowerPoint or Keynote falls into the quick and dirty category, and sometimes that's all you need. You can create a PowerPoint or Keynote prototype just like a basic slideshow, with simple interactions. Both tools allow you to create interactions to simulate the clickability of the flow you want to test with your users. If you're a PowerPoint or Keynote "power user", you can embed animations and other elements to make your prototypes more interactive. Adobe Acrobat PDF file Exporting frames or visuals as a multi-page PDF is sufficient to show what the product looks like and how it moves from page to page in a linear format. Note that many 214

Chapter 12: Prototyping

Export to PDF If you're using a Mac, you can choose to print to PDF for almost any document or file in any application that supports printing. Many applications, including Visio and OmniGraffle, allow you to specify hotspots and actions (such as the location of links) for interaction. Visio and OmniGraffle Microsoft Visio and OmniGraffle from the Omni Group are well known wireframing tools. Both allow for one-click prototyping and the ability to export to HTML and PDF formats. In OmniGraffle, if you're exporting to HTML, you can easily assign actions and specify jump points in PDF or URL. Visio offers a prototyping kit downloadable from the web that allows you to easily export to HTML or PDF with clickable areas for page navigation. Visio and OmniGraffle can also export common vector and raster formats such as EPS, GIF, and JPEG, so you can easily import images into Flash, use them as images in HTML prototypes, and more. Axure RP The "RP" in Axure RP stands for rapid prototyping, which has made this tool popular with many UX designers. The tool provides drawing functionality similar to Visio and OmniGraffle, but adds a relatively easy-to-learn set of tools that allow you to create different navigation styles, forms, pop-ups, and other common page interactions. Additionally, flexible integration of specifications, comments, tasks, and progress markers 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 any apps that allow you to run Windows. Fireworks CS4 Adobe's Fireworks CS4 has recently become increasingly popular as a tool for creating a variety of design components, from frames to visual designs. It features a standard set of Windows and Mac form elements and controls, allowing you to easily define interactions that emphasize functionality without the need for external developers. Shared libraries store items that can be added and shared across multiple documents so they can be reused

digital prototype


raw material. Fireworks also has a page feature that lets you create sets of elements that are common to all pages in a given document—similar to how developers use the word "contains" or how some documentation systems let you create reusable Background. This feature can be used to identify 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 wireframing and prototyping tool that offers a similar experience to drawing wireframes with pen 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 the screen and adapt to your design. The shape of your model is as if it were drawn by hand, which gives a slightly more organic feel to the digitally created display, but the digital platform allows you to quickly modify the design for rapid iteration. Flash and Flash Catalyst Prototyping with Adobe Flash is a great way to communicate interaction concepts beyond the clickable prototype itself. Flash makes it easy to prototype clicks, but it also lets you add other interactive elements, including hovers or rollovers, clicks, video, and animation. If you're equipped to explore Flash in more detail, it also has a basic set of user interface components that can be programmed to respond to user interaction and display desired results. For the basics of Flash prototyping, see Alexa Andrzejeski's article on Boxes and Arrows, "Quick and Easy Flash Prototyping": As this book went to press, 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 easily export your designs into a viewable format. To find more information, please visit the Internet.


Chapter 12: Prototyping

Work with a developer If you have the resources, hire a developer to build a prototype for you based on your framework 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 development specifications and requirements to make the process efficient and effective. If your prototype is for iterative testing, be sure to specify which parts of the prototype you focus on during testing so that changes can be implemented quickly. Spend time with developers during development and identify critical areas of code that should be marked as change-sensitive (along with code comments). Be sure to stay in touch with your developers during prototyping to keep communication open and results accurate. NOTE For more information on different prototyping methods, see Todd Zaki Warfel's forthcoming A Practitioner's Guide to Prototyping (Rosenfeld Media, 2009:

Prototyping Examples The easy-to-follow prototyping examples in this chapter are not a complete set of methods and can be used in all situations. To highlight some real-world applications of prototyping, Keith Tatum and Jon Hadden generously shared their experiences. Keith Tatum, Senior User Experience Strategist at Slingthought (, created the paper prototype shown in Figure 12.5 to explain the left navigation links and for his partners at Align Interactive ( Determine navigation hierarchy and classification).aligninteractive). .com). Additionally, the paper-based prototyping process allowed him to bypass the wireframing stage and move on to visual design and layout (Figure 12.6).

prototype example


Figure 12.5 A paper prototype used to explain the navigation concept to the development team

Figure 12.6 Job site design based on a paper prototype

Using his team's shared understanding of design and development tasks, Keith quickly built the project in two working days. This allows the team to start development work quickly after the visual design concept has been approved.

Figure 12.7 A functional prototype of a calendar tool, modeled using high-quality XHTML, CSS, and JavaScript; courtesy of Jon Harden


Chapter 12: Prototyping

Jon Hadden (, a senior visual designer at Yahoo, prototyped the calendar functionality for a tool he was building called Project Manager. Project Manager is a web-based collaborative project management application. It starts with OmniGraffle wireframes, then builds into high-fidelity XHTML prototypes to help determine whether features are useful and accessible. Affordability is an important point: In some cases, parts of an application or project may need to be prototype tested to see if functionality is possible. If the cost of creating a feature is an issue and prototyping exceeds time and material expectations, you may need to evaluate the cost-effectiveness of the project.

What happens after prototyping? Once the prototyping process is complete, you need to synthesize the results and turn them into something actionable. If you've been prototyping on paper, you may want to start creating digital mockups based on the feedback you receive. If you're already in digital wireframe mode, you may want to update your wireframe and go through the design process. Or you may need to gather feedback and update the prototype for the next round of review. Todd Zaki Warfel, President of MessageFirst (, shared the following insights: Prototyping is a way to accomplish one or more of the following: Work on projects Create a common communication platform Sell your design ideas internally (e.g. to your boss , other designers, etc.) to test technical feasibility with end users/clients to test design concept prototyping as a feedback mechanism. Prototyping allows you to decide whether to follow a particular design direction or explore another direction before moving on to the next stage of design.

Remember: no matter where you are in the process, prototyping is only part of the process, and like anything else, you need to know when you have reached your peak efficiency point and are ready to move on to the next stage of the UX process. What happens after the prototype is created?



Test your designs with users Take a break from what you think you know—see what they think The needs, attitudes and preferences of your website are at hand. This chapter discusses techniques to help you collect user information about individual projects or project elements. We'll focus on exploratory techniques that are often used early in the design phase, and usability testing that can be used at many points in a project. First, let's talk about researching design concepts with users. Carolina Chandler


The Study of Concepts Concepts are often words used to describe abstract concepts such as happiness, cooperation, or efficiency. In the field of user experience design, the concept is also used to denote a design element intended to present one or more abstract ideas to the design team or potential users. In this sense, conceptual design elements can be visual (e.g., a photograph of a machine representing the concept of efficiency) or textual (e.g., a set of short sentences written to express a company's focus on efficiency, using words such as and responsiveness). Concepts can also represent exploration mockups, visual design mockups, or initial prototypes to convey the overall message of a site (see Chapter 12 for more on prototyping). Concept research usually happens early in the design process, after user groups are defined, but before you get into the details of each page or screen. Research can inspire designers and de-risk new product launches because you'll be able to hear (and then plan) the responses you can get from potential users.

The main goal of concept mining is to understand the types of responses and thoughts elicited by a user group when faced with a set of design elements.

Concept research can consist of one-on-one discussions or in small groups, but also includes some individual activities where different perspectives are gathered and discussed. The latter can be structured as a focus group, spending some time on concept testing followed by a group discussion (see Chapter 6 for more on focus groups). Let's look at an example of a concept study conducted for a microfinance nonprofit.

I'm looking for a concept


Potential Pitfalls of Concept Research Henry Ford once said, "If I asked my clients what they wanted, they'd ask for a faster horse." While you can come up with great ideas by exploring concepts with potential users, You don't want to rely on them to replace the designer. After all, the most striking designs are often quite different from earlier designs, and study participants may not feel comfortable with a large degree of change. Participants' answers will be rooted in their current understanding. You're gathering responses, not predictions about what they will or won't want in the future. Also keep in mind that many other factors besides the project itself can influence future behavior (such as positive word of mouth). Avoid asking participants to make a direct decision (for example, "Which concept is better, A or B?"); instead, listen to them describe the proposed concept in their own words. Results should be seen as input to the design process, not as commands from the designer. For an excellent overview of the potential pitfalls of design concept testing and recommendations for using the technique correctly, 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 is a form of financing that provides very small loans to entrepreneurs in poor countries. These loans help borrowers start businesses that improve the lives of their families and communities. Loans are financed by people coming together to borrow or donate small amounts to supplement larger loans (for example, $25 each to fund 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 terms. In addition to describing the challenges of microfinance, the group is unsure how to approach religion-related messaging and design. This microfinance organization was inspired by the beliefs of its founders and employees. Many people in the organization want to do this


Chapter 13: Testing the Project with Users

This inspiration was evident in the website design, but they weren't sure how to find the right balance: If the religious message was presented too strongly, it could alienate potential non-faith donors. Too subtle and the organization doesn't truly represent its values. UX designers set out to explore possible ways to use imagery and text to explain the microfinance model and convey the organization's religious inspiration without alienating potential donors. To do so, they selected images and text that could be used to explain concepts related to the model (such as self-sufficiency and investing) and other messages that represent varying degrees of religious belief (such as faith and spirituality). Then plan focus groups with participants who belong to the target group of website users. Two groups of users were considered: those who indicated that they donated as an expression of their religious beliefs and those who did not. For each group, the leader explained the pattern of giving (no mention of religion). Then give each participant a poster, a set of pictures, and a set of words to use, as well as extra blank cards to fill in with their own words if they wish. They were asked to create a collage featuring images and text that they would use to explain the model to friends and family. Upon completion, participants reconvened to present their collages, explaining why they had chosen some images and text over others. Figure 13.1 shows an example of the collage created in this exercise. Figure 13.1 Example of collages created by participants during concept testing

The project team gained valuable insights from these collages and the ensuing discussions. Included observations that participants avoided images of Western success

ern” (such as suits and briefcases). They hope to improve the lives of entrepreneurs without changing the corporate culture.

I'm looking for a concept


All user groups agree that websites should be goal-oriented

The organization (funding the growth and advancement of the entrepreneur), not the motivation behind it (religious inspiration). Participants felt that it was important for organizations to maintain an authentic identity, but that information could be conveyed in areas dedicated to describing the organization itself, such as the About Us area. The views and interests that emerged helped the team decide on the direction of messaging on the site - a great example of the value of concept testing!

Tips for Exploring Visual Design Mockups At some point in your project, you probably have mockups that represent potential page designs for your website. If you choose to explore the design with participants, it is best to have two or more variants to compare and contrast. There's only one, and you're more likely to get a "good" bias: people don't want to sound overly critical of the model because they don't want to hurt the designer's feelings. However, for two or more models, they are usually more willing to criticize because they focus more on comparing designs rather than criticizing them directly. You can hand each item to participants individually (on a display or on paper) and ask a series of questions. For example, you could ask participants to spend a minute looking at each item and then choose at least three terms from a list that best describe the item. They can circle their choice on a list of 20 words, such as boring, funky, conservative, loud, safe, etc., in random order. You can also collect answers to open-ended questions. For example, you could give participants five blank lines to write their overall impressions of the project. Some of the information you may collect includes common brand associations created by participants:

"Pseudo company is the Rolls Royce of widget makers: it looks great, but you probably can't afford it."


Chapter 13: Testing the Project with Users

Design and Lifestyle:

"I don't think I'd let my son go to this place. He's only 8 years old and these pictures are too grown up for him." The effectiveness of a particular model in explaining a new concept:

“Oh, I see – this page is like a marriage registry, but you’re signing up to receive charitable donations instead of cutlery.” How participants define some of the key terms you use:

"When I saw the word solution on this page, I started thinking I'd find all the products and services I needed to track my packages." Questions or concerns about how to use a specific set of tools

or the effects of their presentations (the next section presents some examples of participants' concerns). Designers can use these responses to assess whether the responses they get match their expectations, or whether they should try a different approach. Note that participants (and project stakeholders, for that matter) often choose different elements from different projects: "I like this part of Concept A, and I like this part of Concept B." This is a natural response , but should not be taken literally. You don't want an unnatural combination of two different design directions. If the visual designer thinks that popular elements can come together well, so be it. But give her space to tell you that it’s not so much “chocolate with peanut butter” as it is “chocolate with pickles.” In general, there are no hard and fast rules about what to do in a concept test or what types of projects can be tested. Instead, the key is to make sure you set the right expectations for the design team, understand the type of information that will be generated in testing, and how that information can be used to make design decisions without stifling creativity.

Usability testing Usability testing is one of the most common methods of testing user experience projects. It is also most familiar to those who are not UX designers themselves, so business stakeholders and design teams are likely already familiar with it. The concept is very simple: create a priority pool

usability testing


Design tasks for your site, ask some users to complete them and note where they had problems and where they succeeded.

Usability Testing vs. User Acceptance Testing Some in your organization may have the misconception that usability testing only happens at the end of development or the beginning of deployment, when you have a working version of your website or application—perhaps a beta version. This impression may also be related to the common practice of doing User Acceptance Testing (UAT) later. The similarity in the names can lead to confusion between the two. For applications that pass a formal QA process, UAT is one of the later stages of testing and is rarely performed by actual users. The main purpose of UAT is usually to ultimately check that the application meets the functional requirements set by stakeholders; it also catches any bugs or bugs reported by participants. While UAT can detect usability issues, it should not be the only way to detect them in your design. Because it happens later in the process, changes based on UAT feedback are much more expensive. It's much better to catch major problems in the process early on, before a lot of time is spent on development. Usability testing is designed to provide more realistic performance information early in the process.

The following sections describe common steps in usability testing, such as choosing a method, planning a study, recruiting and logistics, writing a discussion guide, facilitating analysis and presentation of results, making recommendations


Chapter 13: Testing the Project with Users

Before you start, consider the goals of your project. They will help you stay focused at all times, but are especially useful in the early stages of your method selection and testing planning.

Choosing a method Research methods are often described as quantitative or qualitative. Quantitative research focuses on numerical data and aims to provide highly reliable, repeatable results for the target user group. This involves including a sufficiently large group of users (called a sample size) in that group so that you can draw conclusions from this smaller group and draw conclusions about how the entire group of users will respond, within a margin of error conclusion. Overall, it is a more scientific research method with formality in test design and analysis. The focus is on evaluating the current design—especially compared to other iterations of the site, to the competition, or to a set of benchmarks. Conducting quantitative research means including multiple participants to account for individual differences such as typing speed, familiarity with similar sites, etc. Surveys are an example of a method of gathering information that can be extended to a wider audience by obtaining quantitative data—that is, if you set the right questions (see Chapter 6 for more on surveys). Qualitative research, on the other hand, is not so much concerned with levels of security and reproducibility, but rather with gaining context and insight into user behavior. It is based on the designer's interpretation of findings, intuition, and common sense. (Contextual research, discussed in Chapter 6, is an example of qualitative research.) Qualitative methods allow an open mind to testing, encouraging exploration of ideas and gaining insights; conversations with users are as important, if not more important, than their performance. The focus is on improving the current design - gaining insight and responding 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 user experience design. Both approaches are possible and can yield useful results. Proponents of a more quantitative approach say:

usability testing


It allows you to build measurable patterns to test them against

In later iterations, show progress towards a goal (for example, reducing review time by 20% or finding 80% of usability issues on the site). It's also a great way to do it when you want to make a formal comparison between two places or evaluate a specific place. It provides statistically verifiable results that can make a difference

When recommendations must be defended against stakeholders who trust data-driven decisions. This reduces the possibility of individual UX designer bias

result. This provides a greater degree of certainty in obtaining results

Reflected in results across the user base. It provides a transparent numerical method to inspect the result (e.g.

How many users have encountered the same problem). Proponents of qualitative usability testing say: Qualitative research builds designers' experience and empathy,

Promote creative, user-focused solutions. It relies heavily on the intuition of UX designers to make informed recommendations

suggested, which is largely why he joined the team. Especially for usability testing, qualitative methods are usually less important

More expensive than quantitative research, both because it requires fewer users and because qualitative research does not require formal knowledge of scientific design and analysis (such as statistics). It is easy to misanalyze the results of quantitative research, to lie

(albeit unintentional) data, so quantitative methods can actually pose more risk than qualitative testing if done incorrectly. Although these findings have not been confirmed numerically, they can be verified

A designer would call to discuss the potential impact of the problem, use their conscious reasoning, and build cases with user stories. For those without formal training in scientific methods, qualitative usability testing is a more accessible method and provides a rich source of data for design. For these reasons, we will focus on creating qualitative tests before the end of this chapter.


Chapter 13: Testing the Project with Users

How many users is "enough"? “How many users are enough?” is a question among UX designers that is like mentioning religion at a political rally — it’s a topic of much debate. This is also an unavoidable problem because you need a framework to plan your research. It is related to the method applied: quantitative or qualitative. To give you a short answer, here are Jakob Nielsen's guidelines that seem to have the most consensus in the UX field: For quantitative testing, have more participants: 20 participants per study round (see http://www . using For qualitative testing, groups of five to eight users are usually sufficient for each round of testing. Ideally, more than one round of research should be done to uncover issues that may be "hiding" under other issues or inadvertently introducing new designs (see

Research Plan When designing a usability test, there are several questions that need to be answered early on to ensure focus and scope. This can be delivered as a document written for and discussed with the project team and key stakeholders, often called a user research plan. The plan should outline the method you have chosen above. Why are you testing? 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 vary by project type. Who are you testing? Once you've created your user model (see Chapters 6 and 7), you can use it as the basis for deciding which users to test. If you haven't already, meet with the project team and relevant stakeholders to prioritize user groups. This information will be entered into your scanner (discussed in the Recruiting and Logistics section). usability testing


At this point you must also choose which user groups to represent and how many users to include in each group. what are you testing The question you're testing involves two interrelated questions: What method will you use to present your website or application? What tasks do you plan to include? If you have an existing application that needs to be redesigned, you can first run a full test of the current version to identify major 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 stack of printed mockups) to represent new interface elements, such as pages. These low-fidelity user interface representations allow you to quickly generate and discuss ideas within a project team, and quickly reproduce them to participants (see Chapters 10 and 11 for more on sketches and frameworks). When working on a new project with highly interactive elements, it's best to create a prototype that realistically simulates the project's navigation flow, but can still be built quickly before full-scale development begins (see Chapter 12 for more information). . prototyping). The included pages will be closely related to the selected task. If you plan to use prototypes for user testing, you need to plan the main job pages as well as intermediate pages and alternate flows. You probably don't need to know each one in detail, but you'll want to plan a response if the user moves in that direction. Sometimes it can be as simple as a page telling you that a certain track is not available and asking you to go back to the previous page and try again. The details of your tasks will be included in the discussion guide (discussed below), but since the scope can vary greatly depending on the type of tasks you include, it is helpful to have a list when planning.


Chapter 13: Testing the Project with Users

For more in-depth information on iterative design and sketch testing, as well as some really inspiring insights into creativity in the design process, read Sketch User Experience: Designing Right and Designing Right by Bill Buxton (Morgan Kaufmann, 2007) . For more information on paper prototyping techniques, see Carolyn Snyder, Paper Prototyping: A Quick and Easy Way to Design and Optimize User Interfaces (Morgan Kaufmann, 2003).

If the list is too long and you're not sure how to prioritize, here are some possible priorities to consider: Areas where the project violates some established convention. Who are you

Call it a "gift bag" instead of a "shopping basket"? It's worth checking that the user is aware of this. An area where design decisions are politically charged. you can have it

There is a strong belief that a certain design direction is the right one, but you know there are many disagreements among stakeholders or other project team members. seeing is believing. Areas where availability issues can have serious consequences, such as loss of

Sales or in worst case loss of life (health application related to drug dosage is a good example). Next, specify the information to collect when users attempt to complete each task. What information do you collect? We specialize in qualitative usability tests, which typically have small measurement sets. In most cases, you want to understand the problems your users might have, the varying degrees of frustration they might have, and the severity of a particular problem. For example, there may be intermittent issues (not experienced by all users) that cause you to permanently lose your published history. This should definitely be a question of great interest in your report!

usability testing


To get an idea of ​​the users or rounds you're testing with, you may want to consider some metrics as part of your testing. Again, if you're running qualitative tests with fewer users, don't take the numbers too seriously (calculating an average doesn't make much sense if you're only testing five users), but the following measures can help you understand what your users are experiencing seriousness of some of the problems. Success - The degree to which the user was able to complete the task. If you're looking at users, you can also refer to "success rate" -- the number of users who were able to successfully complete a task. Sounds simple, but it means you need to define what success means! For a less formal test, a task can be said to be successful if the user reaches a final state (for example, editing successfully binds a story). You can track success more formally by noting the different levels of intervention required by the examiner: Level 1 Prompt: The examiner answers the participant's questions but does not provide any other details. For example, a participant asks, "I think it's this button, should I click it?" The moderator replies, "Go ahead, try it." A level 1 query by itself doesn't indicate a task failure, but it's worth keeping in mind because this Participants may experience uncertainty. (Although it is the first job, it may also be unfamiliar with usability testing.) If the user does not need prompts to complete the task, or only needs one or two Level 1 prompts, you can consider this step a success-unless you think The user spends far more time than your user's likely patience level. Level 2 Inquiry: The test administrator sees that the participant is struggling and asks questions. This level does not involve direct replies, but replies may affect the user's visit. For example, a moderator might ask, "Is there anything else on this page that you think might be relevant to this task?" but have difficulty" limit on the number of level 2 queries that can be made before.


Chapter 13: Testing the Project with Users

Level 3 Instruction: Participants give up out of frustration, or struggle to the point where they are likely to give up if faced with a real-life task. In this case, the moderator directly answers part of the task by saying, for example, "To approve this story, you must click the submit button." If a participant requests a level 3 query, the task is usually marked as failed. User Satisfaction - Sure, it does its job successfully, but what do you think? It might be useful to post some follow-up questions after each task (with the timer off) to see how happy or frustrated the user is. If you have someone who doesn't like to talk, this could be a major window into their soul. Table 13.1 shows some examples of post-task questions you might include. Table 13.1: 13.1 User Table

Questions about satisfaction I strongly disagree


I neither agree nor agree

I agree

I totally agree

This job is taking longer than I expected






this task is easy to do






I'm getting frustrated trying to complete this task






Customer Satisfaction Questions Customer Testimonials - This is not a metric, but customer voluntary is a key set of details to collect. Adding user citations to reports is an effective way to incorporate the human element into results so stakeholders can not only interpret the data but understand the insights that lead to them. During testing, you can easily mark statements as questions or comments; we'll break them down in the report (see the "Statistics generation" section later).

Recruitment and logistics Now that you have a study design and know how many participants you need in each group, it's time to plan some tests!

usability testing


Generating a List When you create your research proposal, you map out the types of users you want to include. You can use this outline as a goal for creating a list of potential attendees. Ideally, ask for a name, email address, and phone number. Here are some sources you can use to compile this list: Registered users of affiliated sites User contact information Responses to research posts sent to related sites or groups

your research topic. This can be broad, like a Craigslist post, or targeted, like a newsgroup focused on your business. Email a friend about the subject of the test.

You want them to forward the invitation to others who might be interested, as using topics that you know personally can skew the results. This kind of word of mouth is a great way to find potential participants, but keep in mind that these candidates still need to be vetted. (If you or another team member knows someone well, they may be allowed to pass.) Ask in the form of a short survey to pre-qualify participants or

Advertising space on relevant pages or company websites Publication or pre-qualification questionnaires in public places

Participants can be found. For sites with a strong connection to the physical site, much of the review and planning can also be done on-site. Third-party recruiting firms that may also screen for you

and planning assistance. This can be an expensive option, but if you're looking for a certain type of participant that's difficult to recruit, or you need to recruit a lot of people, you can save a lot of time by outsourcing this part of the process. Some companies also specialize in certain fields (such as medicine) and can provide guidance on how to encourage high participation rates.


Chapter 13: Testing the Project with Users

Get ready for creativity here. Use your empathy skills to think like your target customers - where can you find them and what might motivate them to join? The last question brings us to the next topic. Compensation Options What will motivate your user group members to participate in the survey? It may or may not be money, but participants want something that has value for their time. If you're developing a site for internal users, you'll need to demonstrate the value to managers who need approval to use company time to participate in research. In this case, you can focus on how better systems directly relate to your team's strengths. If you're dealing with potential external clients, here are some variables to keep in mind when deciding how to compensate: How general or specific is your audience? For a widely used eCommerce site, where your audience is likely to be general, you can often offer a lower compensation rate in the form of a check or gift card. For an application to be used by lawyers, your compensation must be of high value, and it is usually best to use something other than money as compensation (such as premium service). In those cases, the check felt like an insult — someone who was paying $250 an hour probably wouldn't be coming for it. If you work with clients who sell high-value products, treat them as a special audience and reward them handsomely. What interest can this topic generate? Some participants will join because they want to see what happens in the area you are testing. If the area is in the spotlight, you probably don't need to pay much extra at all - the reward is getting something you haven't seen before. But be realistic: you can be so passionate about the topic, but will your users be? Will people attend just because they want to contribute to the cause? Some groups, motivated by altruistic goals, may be ostracized by monetary offers to participate. If you're testing content that improves your community (online or offline), you're likely to get more engagement -- and happier participants -- if the experience is more about connecting

usability testing


rather than a salary. In this case, you can show your appreciation for their contribution by participating in it by publicly acknowledging them and letting them know when the page is complete. How awkward would it be to participate? If attendees must travel to your location, be prepared to pay more. Fewer requirements are required if they participate in remote testing from the comfort of their own home or office. Of course time is also factored in and people expect to be paid more for 2 hours than for 30 minutes.

Possible forms of compensation Your situation may be different, but here are some things you can offer: $50 for a half hour remote test for a general user group $80 - $120 for a one hour field test for a general user group 180 USD - USD 250 Test for one hour with a specific user group that you think will respond well to monetary compensation. Three months of free service, free products from the company (preferably those not yet available to everyone), six months of exclusive group memberships, etc., for a specific segment of users who are unlikely to be impressed by the check, e.g. , lawyers, doctors and sales managers. This is where creativity and self-centeredness help. What will motivate your user base?

Screening Screening is a questionnaire that is administered to potential participants prior to their appointment. This ensures that they meet your definition of a representative user. These questions are designed to ensure that the respondents are current users of the feature you are testing −

or potential future users identify a good fit for one or more user groups help create a good mix of participants in that user group


Chapter 13: Testing the Project with Users

Exclude certain respondents who may have potentially biased experiences

Your Results Gather the key information you need to know before attendees arrive

(Optional) Your recruiter should include an introductory script that the recruiter can read over the phone, along with instructions on when to determine participant eligibility (if eligible) or close the interview (if not). The end users of the screener will be your participant recruiters – possibly potential participants if you use the online screening form. Either will work, but it's usually best to use a form or email to gather a list of interested parties, then seek them out by phone. Why? Because, unfortunately, it's often easier for people to impersonate themselves on paper than to answer someone directly, and it's not uncommon for someone to try to join a study even if they don't meet the requirements. Especially when it comes to compensation! Your examiner should also exclude those with knowledge that could affect your results. For example, it is common to ask respondents if they work in the field of market research, as they may be too familiar with research in general and thus be less likely to give you the correct answer. If you are concerned about sharing project information, you may also want to filter out those who work for competitors. Below are some examples of questions you may see on the Inter-Business Online Ordering application verification screen. In this case, we're targeting a group of users who are used to using and buying online and who might do it themselves. It is important to note that some questions are designed to select or exclude participants, while others (such as Question 4) are more focused on placing qualified participants in the correct user group. 1. What age group do you belong to? 【Age group over 18 years old】 a. Under 18 years old


B. 18-24 v. 25–34 grids. 35–44e. 45–54 Priest 55

usability testing


2. How often do you surf the Internet at home? A. Never


B. Less than once a month


C. A few times a month D. At least once a week E. A few times a week F. Once a day or more 3. When was the last time you purchased a product online in person? A. Within the last month b. 1-3 months ago About 3-6 months ago D. 6-12 months ago


menu. over 12 months ago


F. I have never shopped online in person


4. When was the last time you visited [group A is used infrequently or not; group B is frequent visitor]


A. I have never visited the site

check group A

B. Within the last month

check group B

C. 1-3 months ago

check group B

D. 3-6 months ago

check group B

menu. 6-12 months ago

Check A or B

F. More than 12 months ago

check group A

Chapter 13: Testing the Project with Users

You broke up. Breakup is a harsh word. This means that the interview should stop because the respondents did not answer the test. You don't want the interviewee to feel bad about it, but don't waste her time asking follow-up questions when you know she's not a good fit. There are many ways to get rid of it. A favorite method is to simply say that the group she is eligible for is full and ask if she can be contacted at a later date if she is interested in taking another test.

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'll need to make: Where will you test: in a leased space with an observation room, a conference room on a company site, or where potential users will show up? Plan a quiet place where two or three people can sit comfortably, and the configuration of the computers you want to test. What more people do you need than a moderator: You save time and increase accuracy, for example, by recording data in notebooks during tests. Other options include a welcome (meeting potential participants, distributing questionnaires while they wait, and escorting participants in and out of the testing room) and someone to provide IT support should any issues arise during the test. How to record a test: You can use a variety of methods, but software like TechSmith Morae and Camtasia Studio make it easy to record your screen, and Morae has the added feature of webcam video and audio integration.

Writing a Discussion Guide Finally, you need to gather the materials you need for the test itself. You listed your general tasks in your research proposal; now you need the actual text and instructions for completing your tasks. Here you will have at least two packets - one for the test host and one for the participant (each test has enough copies to contain one).

usability testing


Start with an introductory script that the host can read to participants. Many good examples are available at

Surfing is a website developed by the U.S. Department of Health and Human Services as part of an initiative to encourage a broad audience to visit the website. An excellent set of reference materials is included to aid in user-centred design, including an example of a video consent form (in Microsoft Word format) that participants should sign prior to recording: http://www.usability. gov/templates/docs/release.doc

Your instructions should include all the details participants need to successfully complete the task you are testing. If your task requires a lot of data entry and personalization, set up some information ahead of time and provide participants with predetermined data to use. For example, if a login is required, all participants will likely use the same set of login credentials. Make sure the mission statement clearly includes all of this information so it can be done easily. Below is an example of how a content editor task becomes more detailed in the discussion guide. The original task in Drafts was "find an article ready 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 to the company Web site by contributors. After approval, the article will be published in the news section of the website. You and three other editors will approve the articles to make sure they fit the company's message. You have received the following credentials to log into the editor: Username: grobertson Password: come2gether


Chapter 13: Testing the Project with Users

Read each task aloud, then use the editing tool to complete it. Task 1 Log in to the tool and open an article for editing.

As you can see above, we've made some changes to the quest to end with a definite end state - an open article. This type of adjustment will be common when you get to that level of detail and think about how to measure success. You can also track each job with the customer satisfaction questions discussed in the planning section. In general, it's best to give each task a separate page so users aren't tempted to look ahead. In summary, the exam material should include the following:

See page for details) Moderator Discussion Guide with introductory script Participant Discussion Guide with detailed tasks and user satisfaction

questions Format for taking notes, if you have someone responsible. Maybe

From recording tools built into testing software to spreadsheets, type answers into printable templates to check key information such as the types of questions asked. Spending a little extra time setting up before testing will ensure consistent results and save a lot of time looking at shots. Election vote. Sometimes participants come early and have

Some waiting time - this is a perfect opportunity to gather more information. If you've already designed a survey, why not reuse it here? Compensation methods that will be awarded to participants at the end

Test (money in an envelope, commonly accepted gift cards such as Visa gift cards, etc.). If you opted for compensation such as free service where nothing is given away after the test, reassure participants that they will receive a follow-up response no later than the next day. You can also use these materials if you are using paper prototypes during testing. Before starting your first test, make sure you have an easy-to-handle kit.

usability testing


The facilitation facilitator's job is to introduce the participant to the process, answer his initial questions, and then gather as much information as possible, trying to make the participant behave as naturally as possible. Be sure to ask users to think aloud during testing, as if they were talking to each other (if they start working silently, gently remind them to do so). Thinking out loud gives you the deepest insight into user behavior. You'll learn a lot about their problem-solving and thought processes if you hear them during the task itself, rather than asking participants to recreate it later when their memory may not be as accurate. Also, be careful not to give participants the "correct" answer too quickly! One of the hardest parts of running a usability test is watching carefully selected participants struggle to complete a task and letting them go. After all, you're probably in this field because you're an empathetic person. You want to help others. So it seems a bit sadistic to watch someone grow increasingly frustrated, turn to you for help, and then reply, "What would you do if you tried it yourself?" Whenever a participant asks you a question in your work, wait a moment before answering. Participants will often ask questions at the beginning of the test, especially if you make them uncomfortable by sitting next to them. Once they realize you're there more to observe than talk, they'll often be more focused on the task at hand than your presence. Here are some examples of participant questions and suggested answers: Participant: "Looks like this might be the card, or should I go here?" Leader:

"Go and try."

Participant: "Should I go here?" Leader:

"Do you think you'd do it now?"

Participant: "Is this the way to comment?" Leader:

silence. He smiled at the participants, then looked expectantly at their screens with a friendly, relaxed expression on his face.

So when to step in?


Chapter 13: Testing the Project with Users

If the user has put in more effort than you think they'll actually do, and you think you've discovered why they're going the wrong way, it's time to move on - especially if you have more work to do and don't want to vent their frustration for the rest of the exam. In Chapter 6, we mentioned the importance of avoiding leading questions in user interviews. The same applies here. If you feel you are getting too close to the project and criticism might make you resistant, consider training someone else to help you take notes.

Analysis and Presentation of Results You've done all the testing and now have a lot of data to navigate. But there are some key discoveries that you already think are important and your project team can't wait to see how it goes. You can schedule an informal oral discussion with your team about your most important outbound requests. It can help you verbalize some of the trends you've noticed and lay the groundwork for future reporting. Do let them know that these are first impressions and you need time to analyze the data in more detail. You don't necessarily want to jump to advice until you fully understand what the problem is. When you have time to sit down and crunch data, keep in mind how much time you have to spend analyzing it. It's easy to get lost in the details and try to cover everything. As always, keep an eye on your tests and goals as you draw important conclusions. If you have 10 hours to record a test and 5 days to write a full report, you probably don't want to waste time watching the video for each test. Rely on your notebook and mostly review the video to make sure the key quotes you remember are captured correctly. How your results will be used. This is an important detail that is often overlooked. You can create a beautiful 20-page report, but only one page can make a big impact: the executive summary.

usability testing


If business stakeholders want to see detailed information, the report itself may be the main way to communicate the results. If you think you need two levels of detail - one for stakeholders and one for the project team - also consider creating a presentation version of the report that presents key findings in a more visible, understandable and prioritized way. Those interested in more detailed information can view the entire report. Prioritize Issues By the end of your test, you'll likely have a long list of usability issues that need to be understood and prioritized. Here are some characteristics that can help you determine the severity of the error: Consequences. Negative consequences of encountering problems. For example, if a participant lost data due to usability issues, a high score could be given. Let's say he spends ten minutes filling out a complicated form and accidentally chooses a link to another page. If she hits the back button on her browser, will her data disappear? possibility of recovery. To what extent can the participant recover from the problem—for example, can he easily return by another route? occurrence frequency. Since you're not working with a lot of people, that's not in itself a sign of seriousness. However, if five people make the same mistake and it leads them down a path that isn't optimal, it's a good sign that you should consider making it a higher priority. rational reasons. If the problem is uncommon, but created by someone corresponding to your user group, with a valid reason, and has a clear reason for the error, then this should be considered when making a suggestion. Generating Insights In addition to the collected questions, you also have access to a wealth of user feedback that can lead to valuable insights for the project team. As discussed in Chapter 6, the affinity diagram exercise is a great way to connect these statements and identify patterns.


Chapter 13: Testing the Project with Users

Here are some ways to categorize what users say (see "Contextual Queries" in Chapter 6 for more information): ) Good stuff! ) expectations (especially when they are not met)

Among observations and suggestions, don't forget to include positive conclusions. Usability testing reports are often viewed as overly negative, mostly because researchers prioritize talking about things that need to be fixed rather than things that are going well. Taking the time to discuss the good stuff will make everyone's overall reporting experience better. It also helps the project team to commit to the outcome - and get excited about what the project can do better.

Make Suggestions Even before you start your analysis, you probably already have some good ideas in your head for solving the problems you encountered during the test. Draw them along the way, finding questions and insights so you don't lose them. Be careful not to let an idea take root too early and turn your perspective into other potential solutions to more problems. A good recommendation should address more than one problem, if possible. You can group questions

Depending on how specific and detailed your problem description is, put them under a larger suggestion. Practical and simple - avoid premature detailing.

usability testing


Use simple but not condescending vocabulary. take over

Criticism is a difficult thing to do, especially for those directly involved in testing projects. Don't underestimate these issues, but remember that your words must be constructive and respectful. Note that recommendations must target the end user as well as the system. At the end of the report, step back and ask yourself whether you met your original goals and how best to share the results with the different people who will use them: stakeholders, designers, and developers. Speaking of developers, it's time for them to stand up again. In the next chapter, we'll cover things to keep in mind as we go from design to development and beyond.


Chapter 13: Testing the Project with Users


Transition: From Design to Development and Beyond Where are we going? The definition and design phase of your project is complete. What should we do now? The process of designing a good user experience is never-ending. After going through so much defining and designing, how do you stay involved so that the end result of the project is the user experience you designed - where are you going? Russian Unger


This is the end... of the book. This is the last chapter. However, this is not the end of the UX design process, despite the fact that it may seem like it. After going through all the previous phases of the project, you may think that your job is done and you have nothing left to contribute. In many cases, UX design work ends up as a task in someone's project plan, and after handing off the product to the rest of the team, you inevitably move on to another project. Time to close that door and start something new, right? very bad! You can do a lot to ensure you create the best possible design for your users.

Visual Design, Development, and Quality Assurance In some cases, it's easy to work with a design or development team that receives a design-based work product. Sometimes downstream partners rely on you to answer questions, provide information and help them with some project concepts. (It even sounds like prototyping!) In these work environments, where UX design is already in place, the team may have had enough foresight to give you time for these consulting assignments. However, roles such as UX designer, information architect, interaction designer, etc. are very new in many organizations. How to manage these roles can be confusing, and deciding how you should be involved is up to those who don't fully understand UX design. Maybe you need to find ways to stay engaged all the time.


Chapter 14: Transition: From Design to Development and Beyond

Here are some suggestions: 1. Please buy them a copy of this book. 2. Don't be ashamed. 3. Read the rest of this chapter and look for opportunities where you can get involved and make a difference. 4. Ask to engage and be ready 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 staying engaged can be a challenge. You may find yourself trying to knock down walls just to check the work and make sure it's up to par. This isn't always the case, but it does happen. Christopher Fahey, co-founder of Behavior (, is no stranger to overcoming this challenge. He offers the following advice: Some organizations are strictly compartmentalized. To remain involved in project development beyond the initial design phase, you must be proactive and persistent in taking opportunities to provide feedback and corrections to your visual design and development teams. Often they just don't remember to have you there. This is best done during the planning and budgeting phase of the project. If not, you may have to really volunteer your services to make sure the project doesn't degrade later in development. One trick is to simply request that a bug tracker be added to your QA team, even informally (assuming you have one - if not, be sure to ask your visual designers and developers!) Add a bug tracker. You can then add your criticisms and deviations to the same bug fix queue that developers see every day.

Of course, many projects will not have a quality assurance team. In an ideal world, every project would have such a team; however, in practice quality control is not always available. Sometimes developers do QA themselves during development. Besides giving you goosebumps, knowing this should make you want to work with developers more.

Visual Design, Development and Quality Assurance


The Art of Negotiation The art of negotiation can be a key aspect of your role as a UX designer. Downstream partners, such as visual designers and developers, are free to make changes to your work without realizing how it affects key elements of the user experience. In case someone tells you you "can't" do something, you need to be ready to have a plan B. Good negotiation skills will help you defend your design decisions (this should be based on the research you've done. Done) and convince others that UX is possible. Alternatively, these skills will help you work with your partners to create a satisfying Plan B that meets everyone's needs as best as possible. For more on negotiating, see Getting to Yes: Negotiating Agreement Without Give by Roger Fisher, William L. Ury, and Bruce Patton (Penguin, 1991) and Selling to the VP of No by Dave Gray (Selling to the VP of No No Vice President) (XPLANE Corp., 2003).

This is especially true in many small businesses: quality control is a luxury. Troy Lucht, director and chief development officer of Ascend Realty Solutions (, said quality control is "done by everyone, but especially by developers." Everyone is trying - and hoping - to get involved, but without resources dedicated to creating test scripts, it may not be possible to tell people what they should test when development often happens at the last minute. In many cases, our in-house designer knows the app as well as I do, so he or she can provide more thoughtful feedback. Adding a UX designer would really round out the situation for our small team.

Although your UX design product may not include test scripts, in some cases you may want to test the boxes and comments you create to ensure that all elements are included and that all defined CTAs are working properly. This isn't ideal, but it's a useful approach when QA doesn't exist. The key takeaway is that UX design doesn't end just because you changed your work product and did a knowledge transfer. Your role may be more of a consulting nature for the time being, but you're far from done.


Chapter 14: Transition: From Design to Development and Beyond

Test the design with users (again) Haven't we done user testing before? Hopefully your answer to this question is yes, but that's not always the case. Unfortunately, this specific testing step, designed to test the final designed and developed website with real users before launch, didn't work either. This allows you to take a last look at your website and find the latest bugs and bugs 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 could have caused problems in previous iterations of the site. This round of testing can provide the information you need to determine if your site is ready to go live. If major issues are found 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'll come. . . . " This theory is often said—and almost as often refuted. You can make the most beautiful, satisfying, useful app, release it to the world, and find out two months later that almost no one has adopted it. What's the point? User adoption refers to the degree to which your target user base ends up using your website or application. Some adoption issues can be avoided by following good SEO practices (Chapter 8) to ensure users can find your new site. User adoption also means that a well-designed user experience doesn't end when the project ends - or that it's limited to the project you're working on. You can help your marketing, customer service, public relations, and training teams ensure seamless integration and ensure user base enthusiasm for a site or project by helping them address the three factors that typically drive user adoption: Personal Interest

10, 9, 8, 7, 6, 5, 4, 3, 2, 1... Go!


Online Feedback Support

Let's take a closer look at each of them in turn.

One of the most important questions a user has to answer is "What do I get out of this?" No matter how great your website is, if you can't quickly explain what it brings to a particular type of user (or one of its identified personas) unique advantages, you may have difficulty attracting users. Some of these benefits are simple: "Using this camera feature, you can post a photo to your online account with the click of a button." Some are indirect: "Using this timeline tool makes it easier for companies to track you Time spent on each item." You spent valuable time learning about your users; now use that knowledge to help marketing tailor their message.

Support When your users need help with your site, how will they get it? The answer to this question includes training and customer support, in addition to contextual help dedicated to delivering a great user experience. Do you think your users will respond better to in-person training than online training? Will some of your users skip the training and expect everything they need from the site itself? Is live chat an important customer support option for your customers, or will they be happy with phone and email support? Support work is challenging, and knowing your users allows you to effectively assist your customer support and training departments.


Chapter 14: Transition: From Design to Development and Beyond

Internet public opinion Word of mouth is the most important factor affecting the environment. What is the reputation of your client's company and its current website among the target user base? Even if the answer here is yes, it doesn't mean it doesn't require effort - maintenance is always important when it comes to reputation. Don't use an affirmative answer as an excuse to move on to the next section: the effort to maintain doesn't have to be huge, but the effort required to recover from a declining reputation can be mind-boggling. A little TLC can go a long way, so read on. If the answer is no, serious efforts must be made to improve cognition. You may need to reach out to the user community and determine who the influencers are, how they like to communicate and how they influence their audience, and then engage with them. Through social media, you can reach users and influence the opinions of customers, companies and websites in many ways. Help your clients identify opportunities to participate in these communities and try to steer them in a positive direction. If all three factors are met, but you're still seeing low usage, consider how and what your competitors are doing to satisfy user demand. How to highlight your product or website?

Post-Launch Events We live in interesting times: so many companies are putting themselves or their products in "beta". A beta launch usually means real, unfiltered users are a live website testing audience to help identify bugs, crashes, or other issues. Once upon a time, betas were usually only available to developers, but it is now common practice to open betas to the entire user community. During the testing phase, communication methods need to be set up for reporting and reporting problems that users may encounter. Any system errors that occur must be logged and provided to the project



team. There must also be a mechanism for users to report problems they encounter to the appropriate member of the project team. If this communication doesn't happen—if the UX designers, visual designers, and developers don't know what's going on during the often rigorous and fast-paced testing phase—the site can be updated and made available to users again without too much to ask. strategy to follow.

Post-Launch Analysis Once your website is up and running, the first thing you should do is collect data about how your website is being used. The best source of information is your site's log files. Unfortunately, a UX designer may not be at the top of the list of people receiving or reviewing this information, so find someone who will host your site and use your negotiating skills. Web analytics can give you insight into your website visitors. Among other things, you can find out which are new visitors to the page and which are returning visitors to the page, page views, page view duration, page depth, where (which pages) are visitors leaving the page, sessions Duration, ad impressions, search terms used, results, and more. - he is looking for

With this information, you can find out where users are having problems by highlighting problem spots on the page. While analytics may seem tedious and too reliant on numbers, data and insights will help you ask the right questions when conducting 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

Do post-launch design testing with users (again, again) After gathering data from website analytics and gathering information from customer support or other departments that interact with users, you can move on to creating a list of questions to use in the next round of user design testing. In other words, use the collected data to create a new set of questions for site users, and use the skills learned in Chapter 13. One of the benefits of this round of testing is that you can test the same group of users you have worked with before to see if their opinions change after launching and using the site more frequently. This can be very useful: if you test the same group of users (or part of it) again, you can re-ask some of the original questions (feedback on functionality, ability to perform certain tasks, etc.) and analyze the deviation of the responses over time. This ability to deviate can help you discover new areas of improvement on your site and gain insight into user learning curves from previous rounds. As an added bonus, analyzing differences in responses can also help identify new questions that had not been considered before.

Everything is ready, right? no.

It's like starting from gathering analytics and testing your designs against research data, you can start compiling a list of improvements and improvements that will benefit your website. Once you have fully compiled them, you can prepare a new proposal (Chapter 3) based on your suggestions. This proposal can lead you into an entirely new project, which allows you to redefine a new set of project goals (Chapter 4) and business requirements (Chapter 5). you can

just how to start over...


Then move on to additional research (Chapter 6), creating personas for newly identified goals (Chapter 7), improving SEO (Chapter 8), updating or creating new sitemaps and task flows (Chapter 10), updating or Create new models and critiques (Chapter 11), run more rounds of prototyping (Chapter 12), and further test the design with users (Chapter 13) get the idea. Projects shouldn't die. They should serve as a springboard for new projects aimed at continuously improving UX design.


Chapter 14: Transition: From Design to Development and Beyond

Index Absolute path, using HTML prototype 213 Confirmation and signature, including recommendations 53-54 ACSI (American Customer Satisfaction Index) 103 Action, planning 162-164 Customizable pen path and paper usage on web page 189-190 Additional costs and fees 50 Adobe Acrobat PDF Prototyping Tool, Features 214-215 Adobe Illustrator Website 167 Adobe InDesign Website 167 Advocate for Prioritization 150-151, 154 Affinity Diagram for Feature Conflict 160-161 Step 99- 100 Use in Usability Testing 244 Agile Methodology Resource Overview 63-64 65 AIGA Website 51 Ajax, Issue 132 Align Interactive Website 217 Alt Attributes, Use 139 American Customer Satisfaction Index (ACSI) 103 Usability of Analytical Tools 24 Benefits 254 Comments 187 Tools 189-190 and Models 186-187, 193- 194, 201 Talent Agency Aquent Website 51 Predefined Arrows and Connectors 170 Ascend Reality Solutions Website 250 Ash, Tim 16 Ashton, Jonathan 143 by 128 Assumptions Conduct a search, including recommendations 47- 48

Comparing Properties 90 Prioritizing and Defining Axure RP Prototyping Tool Features and 215 Web Pages 167

89-91 (View, Professional).

B Babyhold Website 118 BabyNames Website 118 Balance, UX Design Achievement 6-7 Balsamiq Prototyping Tool Model, Functionality 216 Whips, Steve 12, 95 Behavior Website 249 Beta Release, 253-254 Billing Rate Definition, Black Hat Spec 51 Definition 130-131 Contrast.. White Hat 141–142 Blogging Features, 166 Sitemaps, 191 Blue Flavor Sites 167 Blueprint CSS Sites 167 Body Language, Focus Group Translations 106 Bots, Explaining 129 Brand Showcase Sites, 11 Examples of 13 Features 12- 13 Goals, Strategists/Brand Managers for 13-14, Roles 26-27 Brooks, Mark 200-201 Building Ownership, Systems 183 Buley, Leah 189-190, 201 Business Advocate Focus 154 vs Development and User Advocates 155 Role of Business Intelligence 27-28 Using Models 188 Business Requirements 73 See also Requirements Gathering Clarification 68-69 Merging 82-84 Performing Heuristic Analysis 70-73 Scheduling Meetings 78-79



Business Requirements (continued) Creating Spreadsheets 153 Definitions 68 Examples 83 Gathering Accountability 75-76 Stakeholder Meetings 76-77 Global Cruises Homepage 195-196 Propagating Succession 157 Listening to Ideas 81 Identifying Conflicts 83-84 Setting Priorities 151 –152 Running Effective Meetings 80–81 Creating Models 189 Defining Business Stakeholders 75 Buxton, Bill 231

Calendar Tool C, Functional Prototype 217, Event 219. View Campaign Page Card Sorting Closed Sorting 110 Interpretation 93 Group Sorting 110 Overview 107-108 Test Execution 109 Process 108-110 Giving Instructions 109 Remote Sorting 110 Customer, Using Model 188 Masking, Interpretation 131-132 Cloning Overview 142 Prevention 138 Unintentional 133 collage, used in the case of microfinance 223–224 communication, relevance of prioritization 160 SWOT analysis of companies 61–62 comparison of competitors 61 hierarchy of company culture 36–37 history 34–35 logistics 37



Compensation, identification of 235 user groups, 241 competitors, 61 comparisons of concept studies. See also Visual Design Examples 222-224 Potential Pitfalls 222 Goal 221 Conditions, Definitions 170 Conflicts, Priority Management 158-162 Links, Carelessness 171 Connectors and Arrows, Definitions 170 Consensus Conflicts, Priority Management 160 Consumers, Affects 5 Most Content Best Practices 138–139 Maintaining Existing 138 Importance of Content Creators 135–136, 188 Use of Models in Content Management Systems, Content Matrix Overview 133–134, Numbering System Applied to 173 Content Source Locations 16–17 Targeting 11 characteristics for 17 tasks related to 17 usage business analyst 28 usage card sorting 108 content strategist, role 28-29 contextual design, resource 101 contextual query interpretation 92 information obtained from 98 process 98-99 usage Affinity Charts 99-101 Contributors, Roles 29-30 Websites Coroflot 51 Costs and Fees (Extra) Included in Quote 50 Indexing Features 131 Block Detection 132 Interpretations 129 Creative Commons Websites 50

Dashed line D represents the conditions for 170 decision points defined by 169 definition and design phases, corresponding to 145 outcomes, including Propositions 48-49. See also Product Design Goals for Brand Showcase Sites 13 Executive Summary Sites 17 E-Commerce Sites 19 E-Learning Apps 20 Campaign Sites 15-16 Settings 10 Social Apps 21 Task Apps 18-19 Design Errors No Page Numbers 173–174 No Matched Objects 172 Misplaced Text 172–173 Messy Links 171 Unevenly Placed Objects 172 Design, Improvement 227 Developers Using Models to Get Prototypes from 217 188 Development Support Relevant to Business and User Advocates 155 Best Practices Communication and Monitoring 158 Application 154 Goals and Responsibilities 157 Requirements Inheritance 157-158 Commitment 158 ​​Features 156 Development Team Feedback 249 Digital Asset Optimization 138 Digital Experience Design 5-6 Digital Prototyping. See Also Prototype Audience 208 HTML Editors vs. WYSIWYG Editors 209 - 214 209 Resources Needed for Timelines 208 Wireframes vs. Real-Life Prototypes 207 - 209 Digital Web Magazine Websites 167

Directory Structure, Importance 134 Discussion Guide, Writing Documents for Usability Testing 239-241, Planning 162-164 Domains, Including Keywords in 134 Entry Pages, 142 Point Views, Using Affinity Diagrams 161 Dreamweaver CS4, in Live View 209-210 Duplicate Content, Prevent 138 Dynamic URLs, Avoid in Content Management Systems 133

E-Commerce Websites 19 Design Goals for Educational Microsites 15 Design Goals for E-Learning Applications 20 Emotional and Logical 7 Enabling Hardware Parts PURITE Process 46 Usability Testing Plan 239 Evans, Will 122, 123, 181 , 197–201 Experience, Tangible with numbers 4–5

F Fahey, Christopher 249 Favreau, Jean Marc 40 Including Ideas and Visualization 146–147 Managing Feedback Conflict 160–162, Prototyping 219 Fees and Costs (Additional) Including Requirements 50 Finck, Nick 167 Fireworks CS4 Prototyping 215–216 Flash, Functions 130 -132 Flash and Prototyping Tool Flash Catalyst, Functionality 216 Flash Content, Static Embedding 131 Focus Group Discussion Formatting 105-106 Interpretation 93 Interpreting Body Language 106 Moderation 107 Processes 105 – 107 Using in the Microfinance Example 223 Using Footers 104 -105 Design 196



Footer Links, Link Popularity 140 Front-End Developer, Role 31 Funding Model, Microfinance Application 222

G Garrett, Jesse James 168 Homepage Design for Global Cruises, Google Analytics 195–201 Google Analytics 24 The PageRank System 139 Qualitative Guidelines for Webmasters 142 Searches Performed on the 128 Web, Application Use 172 Newsgroup Formats 105–106 Explanations 93 Interpreting body language w 106 Auditing 107 Process 105-107 Examples of application in microfinance 223 Using 104-105

H Hadden, Jon 217–219 Heading/Navigation, Design 195 Heading Meta Tags, Enabling 137 Gathering Requirements Using Heuristics 73 Overview 70–71 Rationale for 71 Steps Involved in a Hierarchy 72–73 Implications for Corporate Design 36 –37 Hinton, Andrew 177 Hofstede, Geert 36 Homepage Design 192 Global Cruises Design 195–201 Wireframe Design 197–200 Example 194 HTML Prototype 212 Link Popularity 140 HTML Prototype Code Cracking 213–214 Typo Checking 210 Creation 210–212



and Ideas, Connections 82-84 Ideation and Visualization 145-147 Illustrator Web Pages 167 Image Maps Used in HTML Prototypes 213 Image Tags Used in HTML Prototypes 213 InDesign Web Pages 167 Index Pages, Separation 137-138 Web Index Pages 131 Infinite Loops, Avoiding in Content Management Systems 133-134 Information, Search 17 Information Architect vs. Other Roles 248-249 Roles 22-23, 25 Information Architecture Institute Website 51, 167 Instructions, Complete Usability Testing 239-241 Interaction Designer vs. Others Balance of roles Roles 248–249 Roles 23, 25 interviews. View User Interviews iStockphoto Website 117 PURITE Process Iterations Part 46 Iterations, Wireframes as Exercises in 201 Iteration Design, Resources 231 Iteration Testing with Prototypes 217

J JavaScript, jQuery Web Issues 214

132–133 (views, others).

Prototyping tool K Keynote with 214 keys, including sitemaps 175 keyword research tools, accessibility 135 keyword-based searches, 135 keyword reservations, including domain names 134 naming conventions for 136 users In URL Structure 134 –135 Knemeyer, Dirk 12

L Launch analysis after page launch 254 left nav link prototypes 217-218 legends, including 175 sitemaps

Licensed Work Definitions 49-50 Link Anchor Meta Tags Explained 137 Link Popularity Distribution 139-140 Explained 139 Footer Links 140 Cross-Linked Content 141 Tampering 143 Spam 143 User Contributor List, Generate 234-235 Live View, in Dreamweaver CS4 Using 209 Logic and Emotion 7 Logistics, Impact on Company Projects 37 Stages of Logistics Usability Testing 233–239 Lucht, Troy 250

Marketing Campaign M Website Description 11 Examples 14 Characteristics 14 Goals 15-16 Market, Relationship Building 26-27 Melzer, James 182 First Person Messaging Case Study 115 Web Pages 219 Meta Description Tags Explained 137 Keywords Meta Tags Explained 136- 137 Spam 142 Meta Tags, Method Availability 136–137, Relevance 62 Microfinance, Defined 222 Microsite, Defined 15 Microsoft PowerPoint Site 167 Microsoft Visio Site 167 Page Numbering Errors 173–174 Misaligned Objects 172 Misplaced Text 172–173 Messy Links 171 Unevenly Distributed Objects 172 Modified Method, After 64-65 Moves, Reps 170 MSN, Search 128

N names, providing roles 118 Negotiation, art 250 Internet opinion, impact on user acceptance 253 Nicolle roles, description 115–116 Nielsen, Jakob 71 Nofollow link attributes, use of meta tags 140 noindex, explanation 137

For goals using SWOT analysis 61-62 Fuzzy vs. firm 58-60 Meaning 57-58 UX designer input 60-62 Measurement 58, 60 Correctly connected objects 171 Count between networks 172 Mismatch 172 Unequal spacing 172 Observation , for Heuristic Analysis 72- 73 OmniGraffle Prototyping Tools Website Features 215 167 OpenOffice Draw Website 167 OptimalSort Website 109 Overview, including Recommendations 44-45 Ownership and Rights, including Benefits 49-50

Page number P, page title meta tag missing 173-174, PageRank system description 136, page description 139-140. See also Page Clone 142-143 Definition 168 Individual Index 137-138 Page Stack Definition 169 Paper and Pencil, Using Wireframes 189-190, 201 "Paper Culture", Understanding 37



Paper prototyping 206-207 Examples 217-218 HTML as 209 for navigating concepts 218 passive observation, defining 99 paths, identifying 180 payment schedules, including proposals 52-53 pen and paper, for mockups 189 -190, 201 118 biography of a person at age 119 case study 115 definition 113 education level 120 entry point or trigger point of a customer 120 finding information 114 information contained in 116 location 119 maximum usage 125 mobile phone comfort 121 motivation to use a customer, brand or project 121 Naming 118 Occupation 119 Offline Activities 120 Online Activities 120 General Master List 122 Personal Quotes from 120 Photos 117–118 Rationale 113–114 Salary or Salary Range 120 Social Comfort 121 Target Group 123 Target Group 124 Individual Recipients 124 Technical Comfort 121 Genre 113 Target Users 121 Image Sources, People Sources 117 Post-it Notes, Usage in Affinity Graphs 161 Post-Publish Design Tests 255 See also Test; Power Distance Usability Test Phase, 36 powerpoint prototyping tools defined 214 functions



PowerPoint Sites 167 PR (PageRank) Explained 139-140 Preparing for the PURITE Process Section 45 Pricing, Project Structure 51-52 Usability Testing, Prioritization Processes 244-245 Role Balancing 154 Facilitation 150-154 The Importance of Communication 160 Managing Conflict in the Process 158 -162 Product Examples 181-182 Success 5. See also Agile Design Methodology Results 63-64 Importance 66 Included in Recommendations 45-47 Modifications 64-65 Waterfall Steps 62-63 63 Design Direction, Not Aligned in 160 Project Management, Designing with Models 188 Applying SWOT Analysis 61–62 Ambiguity and Firms 58–60 Meaning 57–58 UX Design Inputs 60–62 Measurements 58, 60 Design Reviews, Including Conclusions 44–45 Project Evaluation, Including Applications 51–52 Project Requirements, Implementation Phases 69 Project Sponsor Definition 75 Project Team Definition 75 Project Conditions Diagram 80 Best Practice Projects 191 Company History Impact on 34–35 Processes 181–182 Elements Quote Acceptance and Signing 53–54 Additional Costs and Fees 50 Assumptions 47-48 Results 48-49 Ownership and Rights 49-50 Payment Schedule 52-53

Project Methodology 45-47 Project Overview 44-45 Project Evaluation 51-52 Change History 44 Scope of Work 47 Work List 54-55 Cover 42-43 Proposal, Meaning 40-41 Prototype Accessibility 219 Benefits 219 Calendar Tools 217, 219 Change Layout 210 Finishing 219 Creating with WYSIWYG Editor 209-214 Example 217-219 As Feedback Mechanism 219 Objectives 219 Iterative Testing 217 Obtaining from Developers 217 Model and Reality 207-209 Prototyping. See also Digital Prototyping Best Practices 205-206 Reviews 205 Papers 206-207 Prototyping Tools Adobe Acrobat PDFS 214–215 Axure RP 215 Balsamiq Mockups 216 Fireaworks CS4 215–216 Flash and Flash Catalyst 216 Keynote 214 ORIFFRAFT 215 PowerPoint 214 Powerpo - 46

Q Qualitative Research, Application of Usability Testing 227-229 Qualitative Usability Testing, Gathering Information for 231-232 QA Documentation, Application of Numbering System to 174 QA Team Alternatives 250 Participation 249

Quality assurance, 188 quantitative studies using models, using 227-229 usability testing questionnaires, including 241 questions from the discussion guide. See Also Event Planning Audience 162-164 User Group Compensation 235-236 Documentation Planning 162-164 Focus Groups 105 Creating Scenarios 148 Surveys 102 Usability Testing 242 User Interviews 97 User Satisfaction 233

R Random Name Generator Page 118 Proposal, Development of Usability Testing 245–246 Recruitment Phase of Usability Testing 233–239 Redirecting, Setting 135 Relative Paths, Using 213 PURITE Process Rendering Part 46 Requests in HTML Prototypes, Definition 66 Collecting Requests, Truncating 74 See also business requirements requirements process, incentives 74 research, planning usability testing 229–233 research techniques card sorting 93, 107–110 contextual surveys 92, 98–101 focus groups 93, 104–107 people 121 surveys 92, 101–104 Usability Testing 93, 110–111 User Interviews 92, 95–97 Resources. See also Site Resource Affinity 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 Applications 20 Tools 167 Usability Testing 231 Responsibilities, History of Change, Including Requirements 44 Balancing Roles in the Prioritization Process 154 Merge and Transformation 156 Management 248-249

Sample size S, defined 227 working ranges, included in the conclusion of 47 browsers, used 236-239 in usability testing. See also Script Navigation Issues, Search Behavior Issues, Understanding 135 A Beginner's Guide to SEO 129 Search Engines, 129 The Evolution of Search Results, Monthly Impact on 142 Searches, Statistics Related to Section 128 Titles Including 137 Seiden, Josh 113 SEO (Search Engine Optimization) Definition 127 UX Impact 134 127-128 Importance of Resources for 129 SEO Methods, White Hat vs. Black Hat 141-142 SEO Experts, Using Models 188 Signature and Validation, Including Conclusions 53-54 for 24 Advanced Sites Examples of Site Analysis Tools for Maps 175–176 Related to Blog Functionality 166, 191 Breaking Forms 177 Definitions 166



Omit numbering structure 173 Simple example 174 Contrast workflow 166 Use 138 Use card sort 108 Use location type workflow 178 Identify 11 locations. See Also Index Page 131 Writing Text on Templates 29-30 Hexagons, Using 190 Slingthought Websites 217 Social Networking Applications 20 Design Goals 21 Social Security Administration Common Baby Names 118 Software Usability Measurement Checklist (SUMI) 103 SOW) , Space Content 54 - 55 Usability Testing Arrangement 239 Keyword Spam 142 Spencer, Donna 17, 109 spider, explanation 129 Spool, Jared 125 SRA International Inc Website 182 Defining Stakeholders 75 Collections 76-77 Listening 81 Static Layer, Embedded Flash Content 131 Sticker points, use affinity graph 161 Stock.XCHNG website 117 Scene construction, process 147-150 Advantages and disadvantages, understanding 61 SUMI (Utility Measurement Inventory) software) 103 Support network, construction 32-33. See Also UX Designer Role Explained Survey 92 Overview 101 Process 102-104 Interviewing Users 102

SWFobject, using track 131, SWOT analysis examples 182-184, associated with project objectives 61-62

label T. See Target User Meta Tag, Description 113. See also Applying Numbering Systems 173 Creating 178 Examples 178-180 Overview 166 Process Flow 181-182 with Web Maps 166 Paths 182-184 User Workflows 178 Jobs Using Map Sites 178 Application Pages Describe 11 of 18-19 Functions and goals, using business analysts 28 Tatum, Keith 217-218 Taylor, Dave 214 Technical structures, builders 31 templates, using wireframes 190 tension, final supporters 154-162 balance between, used in usability testing 239 Testing Materials, Writing Usability Tests 241 Testing Part of the PURITE Process 46 Testing, Usability and User Acceptance 226. See also Post-Launch Project Testing; Usability Testing Phase Complete Usability Testing Text 239-241 Misalignment 172-173 Writing on Title Page Pages 29-30 Including Recommendations 42-43 Title Tags Using HTML Prototyping 213 Tools, Accessibility 167-168

In UAT (User Acceptance Testing), the purpose of section 226. Learn about the PURITE 45 process

Avoiding URL Paths in Content Management Systems 133 Avoiding URL Structures in Content Management Systems 134 Using Keywords 134-135 Choosing a Usability Testing Method 227-228 Instructions 93 Usability Testing Steps 110-111 236-239 Overview. See also Post-initiation project testing; testing analysis and presenting results 243-245 Selecting methods 227-228 Creating recommendations 245-246 Evaluation 250 Facilitating 242-243 Research planning 229-233 Recruiting and logistics 233-239 Writing discussion guides 239-241 Usability. gov 240 network effects user adoption feedback 253 influence 251-252 personal strengths 252 for 252 customer advocacy role adoption 150-151 network 32-33 related to business advocacy and development 155 applications 154 user attribute comparison 90 prioritization and defining user behavior 89- 91 Get 227 User Experience (UX) Context. Display UX (User Experience) Definition User Group 87 Property List 87-89 User Interface Engineering Website 125 User Interview Interpretation 92 Interview Technique 97 Process 95-96 Survey 102



User Model, from 91 Design of User Research Activities 93-94 Complete 111 Planning 94 Execute Steps 86 Technique 92 User Research Planning, Development 229-233 User Researcher, Roles 23-25 ​​Determining User Satisfaction 233 Measurement Tools 103 User Statement Testing Usability Classification 245 performance evaluation 233 user determination 232-233 users. See also Target User Usability Testing No. Selection 229 Recognition Types 88-89 Usage Models 188 UX (User Experience) Numerical Aspects 6 SEO Impact 134 UX Design, 3 UX Design Role Definition. See also Web Strategist/Support Brand Manager 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 Responsibilities 25 User Researcher 23–24 Visual Designer 30–31 User Experience Designer Balance with Other Roles 248–249 Empathy 156 Contributing to Project Goals 60–62 Organization 7–8 Priority Setting Role 151 Traits 6–7

Validation V, Finding Early Value Propositions 191, Presentation 15



Visio prototyping tool has 215 Visio sites 167 Team of visual designers providing feedback to 249 visual designers involved in creating wireframes 203 Roles 30-31 Using wireframes in 188 visual projects. See also Concept Mining with Numbering Systems 174 Wireframes 224 Wireframes 200-201 Visual Vocabulary Term Definitions 170 Connectors and Arrows 170 Decision Points 169 Pages 168-169 Page Stacks 169 Visual Features and Ideas 145-147 Dictionaries for Business Purpose Sharing 80 - 81

In WAMMI (Website Analytics and Measuring Inventory) 103 Warfel, Todd Zaki 115, 124, 217, 219 Improved Waterfall Methodology 65 Stages 63 Webmasters, 142 Quality Guidelines for Webmasters/Website Owners Help 129 Web Analytics And Measuring Inventory (WAMMI) 103 Web - Website Resource 28. See also Resource ACSI (American Customer Satisfaction Index) 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent Talent Agency 51 Ascend Reality Solutions 250 Axure RP Pro 167 Babyhold 118 BabyNames 118 Behavior 249

Blue Flavor 167 CSS Blueprints 167 "Brand Experience and the Web" 12 Brooks, Mark 201 Card Sorting Spreadsheets 109-110 Coroflot 51 Creative Commons 50 Digital Web Journals 167 Input Pages 142 Evans, Will 181 Google Code Finding Static Content 131 Hadden, Jon 219 Heuristic Analysis 71 HTML Prototyping 214 Illustrator 167 Image Mapping 213–214 InDesign 167 Information Architecture Institute 51, 167 Information Searching 17 jQuery 214 Keyword Research Tools 135 Campaign Pages 16 MessageFirst 219 Microsoft PowerPoint 167 Microsoft Visio 167 Names and 118 OmniGraffle 167 Open Office Drawing 167 OptimalSort 109 Types of People 113 Photo Resources 117 PowerPoint 167 Random Name Generator 118 A Beginner's Guide to Search Engine Optimization 129 SEO (Search Engine Optimization) 143 Slingthought 217 Universal Social Security Administration Baby Names 118 SRA International Inc. 182 SUMI (Software Measurement Checklist) 103 Tools 167 Usability Testing Scripts 240 240

UI Engineering 125 User Satisfaction Measurement Tools 103 User Experience Design Methods 24 UX Organization 8 UX Research 95 Visio 167 WAMMI (Website Analytics and Measurement Inventory) 103 Helping Webmasters/Website Owners 129 WebSort 109 WebTrends 24 Yahoo! Interface Library Website 214 WebSort Sites 109 WebTrends Sites 24 White Hats and Black Hats 141-142 Panels, Scripts Based on 149 Frames and Comments 186-187, 193-194, 201 Using Numbering Systems 173 Accessing 201 Changing Prototypes 210 Comparing and Contrasting 200 Creating 189, 198-199 Home Page Design 197-200 As an Iterative Exercise 201 Get Customer Feedback on 192-193 Preview Pages 186-187 Display Pages 202-203 with Reality Prototypes 207-209 Getting Started 192-193, 201 As "Thinking Devices", 198 Tools for 189-190 users use 188 visual designs 200-201 hired jobs, define 49 workflows, storyboards 149 worksheets, create 153 WYSIWYG editors for business needs, made with 209-214 prototype

Y Yahoo, Search 128 Yahoo! Interface Library 214 Websites



Get 45 days of free online access to this book! And gain access to thousands by signing up for a free trial of Safari Books Online! By purchasing this book, you get instant online access to Safari Books Online with 45 days of searchable access! While you're there, be sure to check out the Safari Books Online on-demand digital library and its free trial offer (separate sign-up 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 and enter code FJGSLZG to try it out now.

Top Articles
Latest Posts
Article information

Author: Kerri Lueilwitz

Last Updated: 06/09/2023

Views: 6228

Rating: 4.7 / 5 (67 voted)

Reviews: 90% of readers found this page helpful

Author information

Name: Kerri Lueilwitz

Birthday: 1992-10-31

Address: Suite 878 3699 Chantelle Roads, Colebury, NC 68599

Phone: +6111989609516

Job: Chief Farming Manager

Hobby: Mycology, Stone skipping, Dowsing, Whittling, Taxidermy, Sand art, Roller skating

Introduction: My name is Kerri Lueilwitz, I am a courageous, gentle, quaint, thankful, outstanding, brave, vast person who loves writing and wants to share my knowledge and understanding with you.