UX Design Project Guide - Free PDF Download (2023)

User Experience Project Guidelines

to design

For UX designers in practice or in production

RUSS UNGER I Caroline Chandler

peach pressure key

UX Design Project Guide: 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 online: www.newriders.com To report bugs, send a message to[email protected]New Riders is an affiliate of Peachpit, a division of Pearson Education. Copyright © 2009 Russ Unger and Carolyn Chandler Acquisitions Editor: Michael J. Nolan Project Editor: Becca Freed Production Editor: Tracey Croom Development Editor: Linda Laflamme Editor: Leslie Tilley Proofreading: Suzie Nasol Author: Danielle Foster Indexer: Valerie Perry Cover Design : Mimi Heft Cover Producer: 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 permission of the publisher. For information on reprint and excerpt licensing, please contact[email protected]

Disclaimer: The information in this book is forwarded without warranty or guarantee. 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 through the use of computer software applications and hardware products described herein.

Trademarks Many terms that manufacturers and sellers use to distinguish their products are considered trademarks. If these terms appear in this book and Peachpit is aware of a trademark claim, these terms will appear as the trademark owner intends. All other product and service names mentioned in this book are used for editorial purposes only and to serve the interests of those companies, and no trademark infringement is intended. The use of such trade names is not intended to convey an endorsement of this book or any other affiliation. ISBN-13 978-0-321-60737-9 ISBN-10 0-321-60737-6 987654321 Printed and bound in the USA

Kudos to the UX Design Project Guide If Russ Unger and Carolyn Chandler were magicians, the league would hunt them down for spilling their best-kept secrets. Fortunately, this is not the case. Russ and Carolyn have collected 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 designing user experience? No. Is there a book that best gets you there? There is now. Carolyn and Russ provide a solid foundation for planning and leading design projects. This is an essential guide for anyone struggling with competing methods, endless meetings, and all the important aspects of UX design. Dan Brown, author of Communication Design

This book is a great introduction to building great products for real people. But it's not just design - it's all about design: managing projects, collaborating with people, and communicating ideas. A great all-rounder. Donna Spencer, author of Card Sorting: Designing Usable Categories

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

If you've ever heard of author Wil Wheaton, you'll understand why I admire Russ Unger so much. Russ' experience and leadership was 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 to Russ Unger This book would not have been possible without the support of my family, friends, colleagues, and the many people who were complete strangers to me before I pressed the first few keys. Married voluntarily and intentionally to a geek with fly fever, my beautiful wife Nicole managed to double down on her parenting responsibilities for most of this writing. Our daughters, Sydney and Avery, would often nudge their near-comatose dad to wake him up to dance, sing and play Spore. I couldn't help but think that writing a book for the newborn in the family wouldn't be a challenge. I quickly learned the opposite was the case. Nicolle has been coming to my rescue and keeping me focused on finishing this project. She is the heroine I rely on the most. She keeps our house organized amidst the chaos. She is the center of our world here, and she lets us all off the hook too easily. Nicolle, Sydney and Avery made me look like a good dad and I'm grateful for that. I live in a house with three girls and I can't imagine loving any of them with all that I have to give. Caroline kept me informed. 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 from it! She is definitely the big UX yin to my UX yang. Michael Nolan, our Acquisitions Editor, is the perfect guide. Michael was genuinely friendly and really helped everything run smoothly. Rebecca Freed was the juggler, handling every aspect of the book, keeping us informed and emailing us often late into the night. Unfortunately, she often gets almost instant replies from me! Linda Laflamme was our development editor, and once I got used to her Red Pen of Doom, it became clear to me that despite her attempts to immerse me in incomplete ideas and consequences, she pointed me in the right direction. Leslie Tilley puts the finishing touches on the quote; Tracey Croom brings together the production, layout and graphic elements; a real book comes out. Steve “Doc” Baty read every chapter before the birth of the Peachpit office. I often send chapters to Steve around 2am and he iv


He sends feedback by 5am, which is no easy feat. Still, Steve was impressed in Australia. It's hard to imagine this book getting to the shelves without Steve's consistent helpfulness and quick solutions. Brad Simpson (www.i-rradiate.com) takes any graphics I throw at him and turns them into beautiful print images, and he often juggles two teenage sons in his life 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 the effort worth it, but I'll work hard to make it happen. Thanks to Brad for sacrificing many days off and late nights to support this work. Mark Brooks panicked me a few times when I was trying to communicate a message that required a visual component that was beyond my time and/or skills. Mark stepped in and saved the day on more than one occasion, and I owe him a huge debt of gratitude. Mark is brilliant, dedicated, and the type of person I want to be. Jonathan Ashton wrote a whole chapter for us on SEO. After talking to Jonathan for five minutes, I knew he was the right man for the job. His chapters themselves are a very good reason to buy the book, it was nice to have him around. Jono Kane spontaneously intervened at the last moment. Jono, a web developer, interaction designer, and prototyper at Yahoo, provided invaluable support and assistance while writing Chapter 12. Lou Rosenfeld really helped drive the development. In addition to co-authoring the famous "The Polar Bear Book" (O'Reilly's Information Architecture for the World Wide Web), Lou is brilliant, friendly, approachable and always willing to help others in our field. You'd be hard pressed to find someone as generous as Lou. I've had Christina Wodtke help with socializing and socializing. Without Christina, I don't know where we would be today, but it probably wouldn't be "in print". In addition to being a "worth-read author," she's someone who's always there to offer advice and insight. Many in the field of UX design attribute much of their knowledge to Christina's tireless efforts to expand our horizons through constant innovation. Thanks


Will Evans and Todd Zaki Warfel have generously provided high-quality results that you can use as a template 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 - you'll want to know and work with them - and I'm so excited to befriend them. I cannot express enough gratitude to these two. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING gang) and Wil Wheaton offer me as good friends and true supporters and believers Got great service. I'm so excited to make these names into a list of people I know, and I'm a big fan of everything they do. Your support is invaluable to me in everything I do. I thank from the bottom of my heart these amazing people who went out of their way to help me by generously offering advice, anecdotes, and access to their resources: Tonia M. Bartz (www.toniambartz.com), Chapter 7; Steve “Doc” Baty , (www.meld.com.au), Chapters 3, 11, 14 and “A Brief Guide to Meetings”; Mark Brooks (www.markpbrooks.com), Chapters 3 and 11; Leah Buley (www.adaptivepath. com), Chapter 11; Dave Carlson (www.deech.com), Chapter 11; Will Evans (www.semanticfoundry.com), Chapters 7, 10, and 11; Christopher Fahey (www.behaviordesign.com), Chapter 11 Chapter 14; Nick Finck (www.nickfinck.com), Chapter 10; Jesse James Garrett (www.adaptivepath.com), Chapter 10; Austin Govella (www.grafini.com), Chapter 11; Jon · Hadden (www.jonhadden.com), Chapter 12; Whitney Hess (www.whitneyhess.com), Chapter 11; Andrew Hinton (www.inkblurt.com), Chapter 10; Gabby Hon ( www.staywiththegroup.com), Chapters 3 and 11; Kaleem Khan (www.uxjournal.com), “A Brief Guide to Meetings”; Ross Kimbarovsky (www.crowdspring.com), Chapter 14; Livia Labate (www. livlab.com), Chapter 7; Michael Leis (www.michaelleis.com), Chapter 11; Troy Lucht (www.ascendrealtysolutions.com), Chapter 14; James Melzer (www.jamesmelzer.com), Chapter 10 ; Matthew Milan (www.normativethinking.com), Chapter 7; Chris Miller (www.hundredfathom.com/blog), “Quick Guide to Meetings”; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66) , Chapter 11; Stephanie Sansoucie (www.linkedin.com/in/smsansoucie), Chapter 11; Kit Seeborg (www.seeborg.com), Chapters 3, 11 and “A Brief Guide to Meetings”; Josh Seiden (www. joshuaseiden.com), Chapter 7; Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and “Quick Guide to Meetings”; Samantha Soma (www.sisoma. com), "Quick Guide



Meet”; Donna Spencer (www.maadmob.net), Chapter 7; Jared M. Spool (www.uie.com), Chapter 7; Keith Tatum (www.slingthought.com), Chapter 12; Todd Zaki Warfel (www.messagerst.com), Chapters 7, 12, and 14. I would also like to thank Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest SXSW, Peter Ina, Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton - and everyone at Manifest Digital and Draftfcb. I will inevitably miss someone and I hope they don't take it to heart On. There were quite a few people in the found "crowd", and I tried to keep up with everyone. If I missed you, please let me know and I'll find a way to make it up! In conclusion, it's important to note that if there is no information Organizations like Architecture Institute, Interaction Design Society, etc. I would not be able to get in touch with many of the people listed. If you are interested in the field of UX design, research these organizations, join them, and get involved!

Carolyn Chandler Many of us have dreamed of writing a book at some point in our lives. I don't know if I would have had the motivation to jump in and do this without Russ. His energy and passion help us get the right people at the right time, from the Peachpit team to UX industry execs who all have a major impact on what you see on these pages. He is truly one of the biggest helpers in our area and has managed to bring 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 for Steve Baty, who read all of our chapters in whatever raw form we could give him, and still managed to sound enthusiastic at 2am (his time). John Geletka also provided thoughtful feedback and engaged discussions with spark and multidisciplinary perspectives. And of course the Peachpit team; I'll never forget getting my first chapter from Linda Laflamme. It's not pretty (although she suggests it very subtly). you patient people



He guided me through changes and helped improve my workflow, which was initially more geared toward writing a one-off white paper than writing a full-blown book. Now, I've even added transitions in casual chats with colleagues! Speaking of which...Christine Mortensen, aka Morty, was my visual helper. The icons and diagrams you see in my chapters are the result of her hard work—I know how many, because she and I work on many of the same client projects while trying to meet chapter deadlines. Morty is one of those visual designers with a solid foundation in visual and interaction design, a pleasure to work with everyone on projects and bring concepts to life. She was a pleasure to work with and an honor to be her partner due to her integrity and focus on quality. We would also like to thank everyone at Manifest Digital for their incredible support over the past few months. Jim Jacoby brings a special blend of business acumen and UX perspective, and his signature Zen calm gets 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! Plus, Brett Gilbert and Jen O'Brien offer valuable insight into 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 were so patient with my constant reminders about the progress of the "book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. Always a pleasure to work with you. I appreciate your humor and insight every day. Thanks to my colleagues at the Interaction Design Institute for sharing their experiences and being active members of the UX community I love. 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 build 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 plenty of checks to cash and I look forward to spending time with you!



brief introduction

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

Chapter 1:

The way of UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is User Experience Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 General definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Don't forget about the tangible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-based applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 characters you can play or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Build networks that represent user interests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

gather together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Chapter 3: Proposals

Suitable for consultants and freelancers. . . . . . . . . . . . . . . . . 39 proposals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Create a quote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41



front page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 achievements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Title and Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional costs and fees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 item rewards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Confirmation and release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Service Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Chapter 4: Projects

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

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

Learn about project methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Enter the waterfall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Modified method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 access How will it affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 5: Work

Require. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Know the current status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

Gather ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Overview of Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Calling the right Stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Make a meeting plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Request Request Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Effectively lead meetings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Consolidation requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82



Chapter 6: Users

Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic Steps to User Research. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Create a property list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Prioritization and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A choice of research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How much research activity can I include? . . . . . . . . . . . . . . . . . . . . . . . . . 93 User interviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 surveys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 person information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Create a role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

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

Advanced people. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 final thoughts on characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Chapter 8: Users

Experience Design and SEO. . . . 126 Introduction to SEO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Why is SEO important? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Critical infrastructure resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Site technology, design and infrastructure. . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and other scripted content. . . . . . . . . . . . . . . . . . . . . . 130 Content Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, directories, and URL structure are important. . . . . . . . . . . . . . . . . . . . . . 134

Contents: Past (and current) and future kings. . . . . . . . . . . . . . . 135 Naming conventions and fighting jargon. . . . . . . . . . . . . . . . . . . 136 metadata, titles and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136



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

Link popularity explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical distribution of link popularity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 footer links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Cross-linking within content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

game system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 White hats and black hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Keyword spam targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Clones and landing pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Sending unsolicited links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

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

From definition to design. . . . . . . . . . . . . . . . . . . 144 Development and visualization capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Basic screenwriting process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitate the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Make sure you have good tension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Development Advocate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Manage conflict when prioritizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

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

Maps and mission flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is a task flow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Hand Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 of the site map and task flow fundamental element. . . . . . . . . . . . . . . . . . . . 168 pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168-page bundle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 decision points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Couplings and arrows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Sloppy connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171



Misaligned and unevenly distributed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Improperly placed text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Missing page numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Simple Sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Advanced sitemap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Break down the sitemap form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Task flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 will Task flow is taken to a new level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 lanes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Chapter 11: Wireframes

and notes. . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What is a musical note? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who Uses Wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Create wireframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 trades tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Start Simple: Design a simple wireframe. . . . . . . . . . . . . . . . . . . . . . . . . . 191 First step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Wireframes and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Exercise: Design a home page frame. . . . . . . . . . . . . . . . . . . 195 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Result: Designing the home page wireframe. . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When Wireframes Grow and Find Their Way in the World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Design Exercises - Continued: Which Design Is Right? . . . . . . . . . . . . . . . . . . . . . 201

A final note on wireframe presentations. . . . . . . . . . . . . . . . . . . . . . . 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 and WYSIWYG editors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional prototyping tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214



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

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

Test with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220. Conceptual studies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 tips for researching visual design models. . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Access Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Research planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Essay Writing Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Enabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and presentation of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Create a proposal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Chapter 14: Transition: Transition

From design to development and more. . . . . . 247 And so it ends… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual Design, Development and Quality Assurance. . . . . . . . . . . . . 248 design tests with users (again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1… …start! . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 personal strengths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Supported. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network thinking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Post-launch activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post-publication analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 with users Do a post-launch design test (again). . . . . . . . . . . . . . . . . . . . 255

Done, right? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Like a New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


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


Introduction Why We Wrote This Book Welcome to The UX Design Project Guide. Somewhere, UX design students lose sleep because they don't know what it's like to work on a real project at a new company. On the other side of town, there was a visual designer with extensive project experience who was eager 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 living project context. The goal of this book is to provide you with the essential tools and context to use UX tools and techniques in your workforce. As you'll see in many of these chapters, we're not trying to be all things to all people, but rather to give you the foundational information and knowledge you need to fulfill the many roles of a UX designer. In addition to our own examples, we provide examples to help you find ways to use basic materials and allow you to combine this information to create something new, better, or even better suited to your own needs. We hope we have expressed well that this is a very good approach to UX design projects. We just keep learning and improving with each iteration (no matter what we do). That's why we're active in this field to a certain extent. Russ's Words As a mentor at the Information Architecture Institute (www.iainstitute.org), I've noticed a pattern in the people I work with: most either can't find work or don't live up to the expectations of their potential employers. Some people have excellent training but are not always able to put their UX design skills into practice in a project-based environment. The same theme was reflected in many of my presentations at the 2008 Information Architecture Summit (www.iasummit.org).



The idea that this book addresses many of these common problems has been developed. I can't remember if it was Carolyn 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 develop the ideas that eventually led to this book, and perfected it. A quote from Carolyn Over the years I have been fortunate enough to build and lead UX teams. I say happy because I find that UX designers usually have a good balance of traits that are fun to use, blending right-brain intuition with left-brain logic. When I interviewed to form these teams, one thing struck me: Having a relevant educational background, such as human factors or communication design, is a good indicator that someone is committed to UX design, but numbers don't Indicate if someone is a good fit for the team or project. Equally important - if not more important - is the person's ability to adopt a consultant's mindset. This means a positive attitude, a desire to understand and involve others in projects, and most importantly, a focus on making a real impact on users and clients. This way of thinking means taking the time to understand the perspectives of other roles on the project, arguing and compromising when necessary. It takes experience and hard work to really get a firm grip on this mindset, but with an open mind, a solid foundation, and a good set of questions (and the courage to ask them), you can go a long way. This book may not have all the "answers," but it will provide the questions you need to ask to help you find them.

Who should read this book? UX Design Project Guide provides a comprehensive introductory overview of UX design in the context of a project. Anyone interested in UX design should find something useful here. We are particularly focused on the following groups: Students taking UX design courses (such as Human-Computer Interaction or Interaction Design) who wish to supplement their courses with information on how to apply what they have learned to real-world scenarios where Communication and collaboration are critical.



Practitioners looking to deepen their knowledge of essential UX design tools and techniques and improve team communication about the roles involved. Chapter 3 is dedicated to freelancers who need to create their own proposals. A UX design team lead was looking for a book to help their team incorporate project best practices into their UX design activities. All project team leaders who want to learn more about how UX design fits into their projects, its value, and what to expect from a UX designer. if you must...

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

Get started with effective meetings, clear goals, and easy-to-understand approval points

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

Clearly defined, easily prioritized project requirements from business stakeholders and users

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

Know your users in detail and represent their needs during the project

Chapter 6: User Research Chapter 7: Personas Chapter 13: Designing User Tests

Select and use tools and techniques that allow you to quickly communicate visual ideas to project teams

Chapter 10: Site Map and Task Flow. Chapter 11: Wireframing and Reviews. Chapter 12: Prototyping

Make it easy for users and search engines to find and search your site

Chapter 8: User Experience Design and Search Engine Optimization

Once development begins, communicate with the project team and develop your design

Chapter 14: Transition: From Design to Development and Beyond

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



Notes on methodology There are different approaches and approaches. We do not advocate one method over another. Our goal in this book is to focus on steps common to most projects: defining project requirements, designing experiences, and building and deploying solutions. The degree of overlap between these steps varies depending on the design method you use (see Chapter 4 for more details). For the most part, our framework is a loosely linear approach that puts the definition steps first—but at each step we use facilitation and design techniques where they are most helpful.

This book is not: an encyclopedia of all technologies. The UX field is full of creative people who are constantly trying new ways to solve design problems. Including all of these methods would make for a much larger book - and one that would quickly become outdated. What we have included here are the most commonly used techniques and are the whole and ultimate purpose of UX design. We have done our best to provide enough information to engage you and allow you to share activities with other project members - including the basic flow of each technique and other references from books or websites to help you implement it once you have decided on your own path. Your guide to becoming a project manager. Good project management, including setting and monitoring project goals, deadlines and budgets, is key to the success of any project. We do not go into 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 for effective processes, such as facilitation and communication, and the ability to articulate and focus on project goals. These skills will help you become a partner in project management. The only or perfect process or method. We don't have all the answers - no one knows anymore. The field of UX design is relatively young and we are all trying to improve it. You may experience trial and error, additions and improvements, and feedback



Information from others will help you adjust the process to your own needs. If you find something that works for you, please share! let us know!

How to use this book: There are many excellent resources for UX designers. We cover these topics comprehensively here, but refer you to references that allow you to explore these topics in more depth, depending on how much time you want to spend on them. To help you understand how much time each reference typically takes, we've broken them down into three broad categories:

References for surfing Surfboard visits are shorter posts (usually online) that take 5 to 30 minutes to read.

Snorkel Those as snorkel is called are longer Internet articles, white papers, or short books that can be read from an hour to a weekend.

Deep Diving, otherwise known as Diving Helmets, is a long book that probably takes more than a weekend to read; they give you a detailed view of the topic.



This page is intentionally left blank


The way of UXD. Curiosity meets passion and empathy The most important thing is not to stop questioning. Curiosity has its reasons for being. You can't help but be amazed as you contemplate eternity, the mysteries of life, and the wondrous fabric of reality. It is enough if you try to understand a little bit of this mystery every day. albert einstein

Curiosity is the original method of natural education. smiley blanton

Passion and determination go hand in hand. When you discover your purpose, you usually find that it is something you are very passionate about. Steve Pavlina

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 things work—from doorknobs to airplanes to the stuff in your throat. More than anything, 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, there are times when you always agree to be the naysayer, and sometimes drive your co-workers a little crazy, but you can't help but look at the other side of the coin. lucky person! The field of UX design attracts curious individuals who enjoy using multiple shades of gray. We look for patterns and work on organization and structure. We connect the dots. We are tirelessly chasing the next piece of the puzzle, and when the puzzle is solved, we find 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 talk Visio and "Graffle" and live in a world of boxes and arrows connecting each other across our many computer screens. We're not just curious. We are full of passion! We are passionate about brainstorming and facilitating discussions. We're passionate about creating things that have an impact on the people who use them and the people who create them. Weirdly, we're most proud when we create something so good that people don't even realize how good it is! Of course, we have empathy. When we have a bad experience, we can feel it deep down. 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 live with the confusion and sense of inadequacy that usually accompanies a bad experience. 2

Chapter 1: TAO for UXD

When you combine childlike curiosity with an unrivaled passion for "doing what we do" and an awareness of what others feel, you create a vibrant community of professionals who love to talk, ask questions, Sharing solutions and making mistakes - it's all about finding the right thing. Welcome to the user experience design community.

What is User Experience Design? There are many definitions of UX design. After all, this is a field that thrives on defining things. Admittedly, sometimes we're not very good at defining "curse" when it comes to the different parts of the whole, but at least we know what the whole is. In this book, we pay special 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.

A broad definition of 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 that users can touch (for example, physical products and packaging), hear (commercials and audio signatures), and even smell (the smell of freshly baked bread in a sandwich shop). This includes things that customers can interact with in ways other than the physical, such as digital interfaces (websites and mobile phone apps), and of course people (customer service representatives, salespeople, 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 more holistic, integrated experiences. Smell-o-Vision is still a long way from being a reality, but otherwise, the product continues to blur traditional boundaries.

Is it 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 just happen in a vacuum. When designing digital products, be sure to consider the impact of tangible experience. 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 context. Also, don’t forget about the other touchpoints that a product or company has with the people it interacts with. Because a company's brand is influenced by many factors, the brand experience doesn't just stay on the computer or mobile screen. The best website design can't make up for a poor customer service reputation, nor can it provide the satisfaction that comes from a well-designed product delivery package.

Figure 1.1 The modern classroom experience blends analog and digital.


Chapter 1: TAO for UXD

Tangible experiences such as classroom learning are increasingly influenced by digital applications. Likewise, previously personal experiences, such as the decision to buy a karaoke machine at home, are increasingly enriched by social interaction.

Figure 1.2 Online reviews have a significant influence on consumers.

Our Focus As you can see, the scope of UX design is large and growing. In this book, we focus on projects that focus on creating digital experiences—especially interactive media such as websites and software applications. To be successful, UX design for these products must address the project's business goals, the needs of the product's users, and any constraints that affect the viability of the product's functionality (for example, technical constraints or project budget constraints). or time frame).

Is it user experience design?


Free sample of new nutrition bar given away at marathon

door handle

packaging for a pair of shoes

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

Tangible text messaging for cell phones

call customer service



Our focus: Reading online product reviews, searching the Internet Archive, displaying targeted ads

Digital Customer Service Live Chat

About UX Designers While curiosity, enthusiasm, and empathy are common traits of UX designers, there is also a desire to strike a balance. We look for balance, especially between logic and emotion, like Spock and Kirk or Data and Data in an episode where his emotion chip overloads his positron relay. You have an idea In order to create truly memorable and satisfying experiences, UX designers must understand how to create a logical and sustainable structure for the experience and understand the important elements in creating an emotional connection with the product user. Exact balance may vary by product. An ad campaign for children's toys has a different balance than an app for monitoring hospital patients. Products developed without understanding both are likely to miss out on an opportunity for a truly memorable experience — and the benefits that the company behind the product reaps as a result. NOTE For more on emotional design, see Donald Norman's Emotional Design: Why We Love (or Hate) Everyday Things (Basic Books, 2005).


Chapter 1: TAO for UXD

Achieving this balance requires more empathy: the ability to penetrate into the world of a product’s potential users to understand their needs and motivations. UX designers conduct research to develop this understanding (see Chapter 6) and create tools like personas (see Chapter 7) to help other members of the project team focus. Remember, emotions are only part of the bigger picture. Use your logic skills to bring 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. Many of these organizations not only provide mailing lists, online resources, and a group of really smart people, but they also sponsor events or conferences that can help broaden your horizons while narrowing your professional focus. Many companies host educational events, including User Interface Engineering's Web Application Summit and User Interface Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. There are also a growing number of "no-assessments" in different cities; 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 briefly lists some of the better known organizations, their websites and the events they organize. Table 1.1

A range of user experience organizations


Web page

large meetings (usually)

Interaction Design Association (IxDA)


Interactive (early February)

Institute for Information Architecture (IAI)


IDEA Conference (September/October)

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


IA Summit (March)

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


CHI (early April)

Association of Usability Professionals


UPA (June)

let's start! You made it this far. Time to figure out why you picked up this book in the first place. Turn the page for an in-depth look at how UX design works in the project space. But don't stop there—this book is your guide to get you started. It contains many examples to help you accomplish many tasks that you need to accomplish. We also try to provide more examples to help you find the best way to create deliverables that benefit your team and clients. Keep your curiosity, enthusiasm and empathy! Challenge yourself to find new ways to inspire others to create the ideal customer experience. That's of course before you start improving it.


Chapter 1: TAO for UXD


Project Ecosystem Planning for Project Requirements, Roles, and Culture Ready to start a brand new project? Or are you right in the middle? 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 type of website or application are they? What roles and skills are required? What is the corporate culture like? Answering these questions will help you define your project and ultimately identify the tools and skills you need to succeed. Caroline Chandler



Every project has its unique challenges. When designing a website or application, many of these challenges relate to specific features and functions, such as developing a way for users to share photos online with friends and family, or reorganizing information on an intranet to make content more comprehensive and easier . Find and share. However, all projects have a broader context around these specific design goals that you need to understand and incorporate into your planning. This context is the "ecosystem" of the project, including the environment in which you will work (company culture), the general types of work you will be involved in (such as the type of website you are designing), and the interactions with the people you will be involved in (including their roles and responsibilities ). If you take the time to understand the project ecosystem, you will gain knowledge that will help you throughout the project. You can more effectively communicate your responsibilities and ideas, and help others on the team anticipate project needs they may not have considered. To help you, this chapter identifies the different types of projects you can work on, along with the roles you can play, the people you can rely on, and how their involvement may vary depending on the type of website or application design you're working on . Finally, the chapter discusses some elements of corporate culture that may affect your work during the project. Note Depending on how your client company structures its projects, a given project might involve the design of more than one site or application. For simplicity, this book assumes that the project is the design of a type of site. If you have multiple sites, consider each site individually to ensure the project team has the right roles.

Specifies the page type. While there are no black and white differences between one type of website and another, some relative differences in the focus and character of a website are evident. Once you understand these similarities and differences, you can set design goals for yourself. These are common problems that must exist

Addresses (eg "explains the company's business model") or attributes that should be represented in the visual and interactive design of the website (eg "shows the company's responsiveness to customers").


Chapter 2: Project Ecosystem

Consolidate the main objectives of the project (see Chapter 4). Know which departments or business units these could (or should) belong to.

You will participate in gathering business requirements (see Chapter 5). Identify best practices for incorporating user research (see Chapter 6). Ask questions about what systems and technologies might be involved.

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

Brand Image - A persistent online platform that facilitates the relationship between a company and its general audience (all those interested in its product or service). Marketing Campaign - A targeted website or application designed to elicit a specific and measurable response from a specific audience or other general audience for a limited period of time. Content Source - An information repository that can contain multiple types of media (articles, documents, videos, photos, instructions) designed to inform, engage, or entertain users. task-based application - a tool or collection of tools designed to enable a user to perform a set of important tasks or workflows

In the next few sections, we'll take a closer look at each type, discussing their characteristics and their impact on your website or app design challenges. We'll also discuss the most common crossover projects -- e-commerce, e-learning, and social -- 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 Swoosh or the Coca-Cola monogram. However, a company's brand is more than just a logo. It is a set of impressions someone has of a company.

specify page type


Dirk Knemeyer gives some excellent definitions of brands in his article "Brand Experience and the Web": in them is each of us. The science of branding is about designing for people and influencing their minds—in other words, building brands.

For more information on the difference between a company's brand UX and a company's branding efforts, see Dirk Knemeyer's explanation in Brand Experience and the Web: www.digital-web.com/articles/brand_experience_and_the_web. For an excellent discussion of how a website's UX design can affect a person's brand experience, read Steve Baty's article "Brand Experience in UX Design": www.uxmatters.com/MT/archives/000111.php.

Companies can do a lot to influence the associations they create with their brand, from running memorable ad campaigns to expressing brand characteristics (such as "responsiveness" or "value") through the functionality and design of their website. All websites within a company may have some impact on the company's brand, either directly (by showing which sites customers can visit) or indirectly (by providing important services that customers rely on, such as customer support). However, branding pages are most focused on presenting the 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 usually the company's main .com or .org site, such as GE.com, or for larger, more distributed companies, the primary site is the main site for a company of any size, such as B.GEhealthcare.com . Different product lines often have their own unique brand images online as well. For example, Pepsico.com has a brand image, while Pepsi.com has its own popularity.


Chapter 2: Project Ecosystem

If you work on a branded presence site, you likely design for a variety of audiences, including current and potential clients, investors, partners, media (such as news organizations and prominent bloggers), and job seekers.

Common webpages where branding is showcased Main company homepage (company.com, company.org, company.net, etc.) Pages for the main business unit of the company (usually a unique

(Specific industry, region, or broad range of products) Websites of well-known sub-brands within the company

Brand image design goals Usually the most important design goals in a brand image project are: to convey the company's brand value and brand information,

Be explicit (perhaps a statement about the importance of responding to customer needs) or by entering the overall experience of the site (for example, motivating business by ensuring that the site works well and has prominent features that users need to interact with). Provide quick access to company information Easy access. think

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

"What can the company do for me?" and "How can the company do it?" engage and guide relevant interactions across a range of key user segments.

features, functionality or content. Help companies achieve their goals using key metrics such as:

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

specify page type


Among other types of sites you may be using, include one that is closely related to brand presence sites: campaign sites.

A campaign website is similar to a brand website in that both are designed to provide users with an experience that influences their perception of a company's brand. However, websites with marketing campaigns are often judged on their ability to achieve very specific actions within a specific focus, such as within a certain time frame or target audience. They serve not as a channel to generate interest, but as an engine to generate interest. From an online perspective, this usually means that they are aligned with the overall marketing strategy and can be combined with other marketing activities through various channels, such as TV or radio advertisements, print advertisements and other promotional activities.

Common Marketing Campaign Pages Landing pages that promote specific offers. The site can be accessed by

Banner advertisements from other websites. A small website (or microsite) that promotes a specific event. Games or tools designed to create excitement

or traffic.

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

conferences) or seasons (eg Christmas) User Groups - eg B. Events for teens or teachers. The product, product packaging, and/or the specific use of the product—for

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


Chapter 2: Project Ecosystem

A campaign that combines these strategies would be a spring campaign aimed at selling yard equipment, combining timing and product assortment. See Figure 2.1 for an example showing a combination of product packages and user groups. A campaign website can be as simple as a banner ad leading to the landing page of the company's .com website, or it can be a microsite, a small website that is usually not branded as on the .com website. Customize the experience based on one or more focus areas. "Small" is relative here - some microsites have just one page while others have many, but regardless, microsites are smaller and more focused on the company's brand image than the main site.

Figure 2.1 Texas Instruments uses the educational microsite http://timathrocks.com/index.php to display information about the company's graphing calculators. This package is primarily intended for use by high school and algebra students. The microsite is still broadly associated with the Texas Instruments brand, but is intentionally different to appeal to a younger audience and organize content and functionality around their needs.

Campaign Design Goals For the individual or team responsible for designing and implementing a campaign website, the following design goals are often of greatest importance: Generate interest and excitement, usually by presenting clear and immediate content.

This could be a value proposition (the value the product or service brings to the user, such as the ability to meet loan requirements quickly) or some form of incentive (special offers, participation in contests or entertainment, such as an online game).

specify page type


Include a set of primary user groups to prohibit specific actions.

For example, by clicking on a specific spot on the brand's website, signing up for a newsletter, or applying for a loan. When a user performs that action, it's called a transition. Help companies achieve their goals by setting key metrics like numbers.

The number of unique visitors. It is often part of an overall marketing strategy.

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

Content Feeds Content feeds pages contain a repository of information, preferably different types of media (articles, documents, videos, photos, descriptions), designed to inform, engage and/or entertain users.

A website with a common source of content A company intranet An online library or resource center for members of an organization A website or part of a website focused on delivering news or general

Updated Posts (larger business blogs may fall into this category) Customer Support Center

Of course, all websites and apps have content, but some sites pay special attention to the presentation and structure of the content. The focus may be because the site has so much content that it presents its own challenges, or because certain types of content are of high importance. For example, they can support important decisions or bring users back to the site frequently.


Chapter 2: Project Ecosystem

The main purpose of a content source site is to increase the knowledge and independence of users by providing relevant content, such as an intranet. They also often encourage 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 will be the main attraction for first-time and return visits to the site. For example, demonstrate company leadership skills by

By gaining insight into the thoughts and perspectives of the CEO or other subject matter experts in the company. Support important decisions in your customer base. Extend a company's corporate knowledge by generating ideas

They can be buried in certain departments. This can be part of a larger goal of identifying more opportunities for innovation. Allow users to search for information in different 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 are more likely to use the search box).

For more information on the different ways users seek information, see Donna Spencer's Four Modes of Seeking Information and How to Design for Them: http://boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them

In terms of UX design, the most common tasks in content source projects include: Creating a taxonomy structure that fits the user's mental model. Determine how to integrate your organic content growth system

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


Task-based applications. Task-based applications can range from a simple calculator built into a mortgage website to a complete system that manages several key workflows. If your project involves the latter, there are multiple roles involved, and most likely an extensive requirements-gathering process (see Chapter 5 for more on this process).

Generic Task-Based Applications enable the creation of specific types of software applications

Items (such as spreadsheets or print) Web tools or applications that support key workflows within an organization.

Business (such as a ticket management app for an IT support group or a customer tracking app for a call center) Websites that allow access and management of personal data

(e.g. Flickr)

The main goal of task-based applications is to enable users to perform a series of tasks tailored to their needs and the end-user's business goals. Task-Based Application Design Goals Most task-based applications must allow users to do something they cannot do elsewhere—or if they can,

Work better ("better" can mean more efficient, effective, satisfying, or convenient) Help novice users with easily accessible instructions and visual prioritization.

Assign important tasks. Support for intermediate and advanced users to access the shortcut function

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

(e.g. reusing data instead of requiring repeated entry)


Chapter 2: Project Ecosystem

During conception and implementation, attention must be paid to the degree of change required

Application users – ideally with a design that facilitates learning and a communication plan that demonstrates value to users. One of the biggest challenges in designing task-based applications is controlling feature sprawl. During project development, great ideas often emerge late in design or even during development. UX design is good at preventing feature abandonment because user models like personas can be used to identify high-value features and keep them focused throughout the project. Later in the process, if a really good idea emerges that meets the needs of a high-priority user group and aligns with the site's business goals, your team may make a case for a change in direction. If the idea doesn't pan out, the delay and expense might not be worth it.

E-Commerce Sites E-Commerce sites can contain elements from all four item types, as sites primarily used for e-Commerce must be private-label, offer content (usually product specifications or product usage instructions). Make tasks easier (search, compare, write reviews, pay). Marketing activities are also often closely tied to these sites and may involve multiple marketing teams within the organization. Common additional goals for designing e-commerce sites are: If the site mockup is not standard, explain it. love the online marketplace

Constantly re-evaluating, this interpretation helps create expectations (eg: eBay, Amazon, and Craigslist have very different models). It supports decision making as users move from learning to thinking.

From compare to buy, with helpful content and features. Points of leverage in experiences where cross-sells and up-sells occur

And place the suggestions in a way that catches the eye without distracting. Create from point of purchase to

delivery location. Communication must not only take place within the website, but also with other channels, such as through integration with delivery tracking systems and email communication regarding order status. specify page type


eLearning Application An eLearning application is the interface between content sources and task-based applications. Class content needs to be generated, which often requires teams to add learning specialist and subject matter expert (SME) roles for the topics covered. The product is task-based, so users typically follow the course as it progresses and may need to monitor progress or research related topics. Some practice sessions may also include tasks to complete. The overall design goals are to: Provide an understanding of the basic knowledge required to begin the course

and who it is for. Deliver content on demand in manageable chunks

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

Next steps in the continuing education process, eg B. Advanced courses.

Social Networking Applications Social networking applications are primarily task-based applications because users need to be able to find and add friends, manage their profiles, socialize, post, and search. However, they also pose challenges related to content sources, most notably the need for an organic framework to handle potentially very large volumes of user-generated content. When a website essentially acquires its own identity, it also exhibits the characteristics of a branded showcase website.

Dig deeper If you're developing a social networking application or trying to integrate social functionality into another type of website, this book will help: 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. Enable meaningful interactions between endorsers and endorsers

Powered by prominent features such as image sharing, video sharing and discussions. Protect the integrity of your website by securing those who are online

Know how to control your information and react to inappropriate behavior. Harness the power of the community and showcase it to drive features.

Features only available to active members, such as popular features and reviews. Determining the type of website or application you will be using during 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 assignments: When you become a UX designer on a project, you often end up taking on multiple roles. Whether or not they are formally defined within your client organization, the roles you play will depend on the nature of the project and composition of the rest of the team, as well as the client's experience with each role. It's good to know which roles you already enjoy and which ones you think you can learn on the job. It is also helpful to find out what other people might expect from the responsibilities of these roles. With this understanding, you can present yourself more clearly from the beginning of the project. What is the most common role of a UX designer? Each client company you work for may have a different title for these roles (or no title at all if it's not a formal position in the organization). Generally, you'll come across the Big Three: Information Architects, Interaction Designers, and User Researchers. Note: Few companies have the scale or budget to assign these shared roles to different individuals. Remember role names when defining projects, but talk about requirements and responsibilities when talking to clients - otherwise they might think you're building a very large team! This focus on responsibilities rather than titles also helps keep you sane: having multiple roles like this doesn't necessarily mean you're doing the work of many people, because responsibilities vary for different parts of the project.

choose your hat


Information Architects Information architects are responsible for creating models for information structures and using them to design user-friendly navigation and content categorization. Common tasks in designing web pages and applications include creating detailed site maps (see Chapter 10) and making sure categories and subcategories of information are clear and understandable to users. Understanding Expectations In UX, the roles of information architects and interaction designers are differentiated (discussed below). In any organization, however, there are few common distinctions between these two roles, at least when it comes to the needs of a particular project. For example, you might end up joining a team with the title "Information Architect" because that's the historical term for the role, whether or not it actually fits your responsibilities. Does the project team need to be corrected if the title assigned to you does not match the leadership role you have assumed? If the project is short term (e.g. four months or less) and you have a title that is widely accepted within the organization and responsibilities are clearly defined, it may not be worth trying to change it, as you could create confusion. However, if there is no generally accepted designation and you feel that it is possible to represent both roles - ideally by different people - it is worth making the distinction at the beginning of the project when considering your engagement and communications plan. your responsibility. Essentially, it makes sense to emphasize the role of the interaction designer for more task-based applications, and the role of the information architect for more content-based projects. However, it is best to use terminology that is familiar to the client organization, and make sure the team understands how you define roles in terms of the responsibilities you assume. You should clarify this definition in the service description (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see other roles below). If these roles


Chapter 2: Project Ecosystem

If your project team is represented by different people, be sure to discuss at the beginning of the project how you will collaborate.

Interaction Designers Interaction designers are responsible for defining the behavior of a page or application based on user actions. This includes page flow across multiple views and interactions within specific views. When designing a web page or application, common activities include creating task flows that show interactions between pages or components within a web page (see Chapter 10) and creating frameworks that show interactions within pages, such as: B. Dynamic menus and Extended content area (see chapter). 11). Understand expectations. If you are working in a small team or on a project that is not focused on creating new task-based functionality (for example, if you are working on a brand showcase site that primarily consists of a few content categories, And (contact form and newsletter subscription form) interaction designers are likely to be the main task responsible for gathering project requirements (see Chapter 5). If you work as an interaction designer on a project with a high level of new functionality, it is likely that the team Use cases are enhanced by the impact of experience design on experience design by an independent person (such as a business analyst or product manager) who is responsible for describing detailed requirements. Be sure to sit down with the person responsible for gathering requirements and discuss how best to collaborate.

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

choose your hat


Understanding Expectations A client organization's expectations for user research can vary widely, depending on how important it is to the project team or project sponsor. The fact that you are discussing UX design with the project sponsor before the project even begins shows that someone on the account team knows that ensuring user needs are met is a top priority. But as those who have worked on computing-intensive projects know, bringing in research can also create anxiety among project team members—fears that user research might create a bottleneck and increase risk (what happens when we find and need bugs?). Make drastic changes to fix the problem? ) or the value of refuting a particular idea that has gained a lot of momentum. Research user expectations may differ between business stakeholders and project teams. Therefore, the role expectations of the two groups must be clarified. Clients may also want user researchers to provide insights based on website analytics - tools and reports that communicate website usage patterns such as: B. Frequently visited pages and frequent points where users leave the website. Some of the most popular analytics tools are from Google (www.google.com/analytics), WebTrends (www.webtrends.com) and Omniture (www.omniture.com/en/products/web_analytics). You can fill all three roles: Information Architect, Interaction Designer, and User Researcher. Can you do all three at the same time, or can you chew more than you can chew? This depends in part on the size and schedule of the project, but the nature of the project also affects how involved each role is. Table 2.1 describes how UX design roles vary by project type.

Browse Should You Support UX Design? Here are some articles that might help: "User Experience Is a Business Imperative" Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Promote User Experience Design for Ten Dollars a Day" Louis Rosenfeld: http: //www.hesketh.com/publications/user_experience.pdf louisrosenfeld.com/home/bloug_archive/000131.html


Chapter 2: Project Ecosystem

Table 2.1

General Responsibilities of a UX Design Role

information architect


Marketing activities

content source

apply to task

Moderate commitment.

Smaller sites, such as one landing page, have low engagement. Engagement is moderate when working with larger microsites.

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

Moderate to high involvement, with a primary focus on creating the navigation framework, unless larger content areas need to be referenced in certain workflows.

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

Moderate to high engagement.

Very high promise. Such projects often require the most difficult work, as interaction design deliverables (eg, user flows and frameworks) are critical to visual communication needs.

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

On-site research, such as background research, can help teams understand how different users are currently interacting with information.

The greater the content challenge, the more likely the item will be a source of content.

Interactive Design

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

Involvement of user researchers depends on budget and access to users. The following are common techniques for each type of project. 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 through 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 may also have workflows that include content creation and management.

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

On-site research, such as background research, can be done to understand what users are doing when they complete a task. However, the most widely used and best understood technique for engaging users in task-based application design is usability testing.

Once the framework is established, the structure can be validated through usability testing.

choose your hat


Other characters you can play or need. Multiple roles don't usually fall under the UX designer's role, but their responsibilities often overlap with those of a UX designer - especially if you're working on a project where no one else officially fills that role, and you have skills to bring to the table. The most common overlapping roles include: strategist or brand manager, business analyst, content strategist, copywriter, visual designer, front-end developer

The following sections detail each of these roles and how they vary depending on the type of website you are designing. Brand Strategists and Brand Managers Brand strategists are responsible for building relationships with key markets by defining and consistently presenting a company's brand elements, which can range from brand values ​​(such as "responsiveness") to copywriting guidelines and messaging specifications. all content. For logo handling, color and appearance. This role typically involves creating or presenting brand guidelines and understanding how they apply to different projects. It can also be about understanding or defining target groups that are important to the project you are working on. Most of the time, you may be working 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 assigned to the project's UX designer or visual designer. If the company's brand attributes, values, and guidelines are clearly defined, and the website is expected to follow them, then your role as the project brand manager is primarily to ensure that the results meet those guidelines. Your touchpoint outside of the project is likely to be


Chapter 2: Project Ecosystem

A member of the marketing department who may provide consulting or auditing services but is not part of the full-time team. If the website needs to expand the brand in some way - for example, by targeting new markets, the brand manager's role can be more active. The hardest part is when you are creating a brand new identity, or when a company drastically changes its brand and effectively rebrands itself. For example, CellularOne switched entirely to Cingular, a major effort by an established company. In this case, you should be very experienced in brand development, or have a clear and close relationship with someone in the company who has this experience. Important questions to help you understand what to expect from your brand persona are: Are there brand guidelines? If so, how exactly should they be respected in this project? Who is responsible for building or maintaining the message or brand?

The look, feel and tone of the content (e.g. casual or professional)? Are they targeting new target groups not previously covered?

brand definition? If so, who is responsible for ensuring that brand guidelines remain relevant for that audience? Will there be any naming or renaming activities? If so, how do I proceed?

include? (An example would be creating a name for a heavily promoted new tool.) For projects that don't have a big potential impact on customer brand perception, e.g. B. Developing an internal application, including a brand manager might just be an occasional check in to make sure the brand is well received display. Business Analyst The Business Analyst (sometimes referred to as the Business Systems Analyst in IT projects) is responsible for identifying key business stakeholders, initiating the requirements gathering process (see Chapter 5), and acting as the liaison between the business stakeholders and the technical team. primary contact for . Behavior. He or she is also the primary owner of detailed requirements documents, such as B. Functional specifications and use cases.

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. Task-based apps and content feeds often play this role; brand exposure projects and marketing campaigns may not. Task-based applications will most likely require this role. The more functions and the more complex the project, the more dedicated personnel and functional documentation are required. Although business analysts are not usually considered members of UX teams, small UX teams are often asked to fill the role. So it's important to understand where those responsibilities lie. Business analysts capture business requirements and act as liaisons between technical teams and key business stakeholders. When a project involves a business analyst, that person and the interaction designer are usually on the same page. If it is the same role, the person in charge may have to manage a lot of documents! To understand what to expect in this area, ask who is responsible for outlining the project scope, facilitating requirements discussions, and documenting requirements throughout the project. For small or non-featured projects, project managers sometimes take on this responsibility. Either way, even if you're not, you still know who to contact to make sure your results are consistent. Content Strategist Content Strategists are responsible for understanding the business and user needs of media content (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating the workflow and development of new content. Content efforts are often underestimated. A client may have a lot of fancy media content (such as a printed brochure or video) that may not be appropriate 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! Speaking of Premium Content


Chapter 2: Project Ecosystem

To identify the most important business drivers in your project, make sure you know who is responsible for: Setting content rules for new products (content type,

sound, quantity). Evaluate the suitability of existing content based on it

guidelines. Development of new content. It depends on the general type of project. for

For task-based applications, it can contain explanatory text, error messages, and help topics. Content sources can be articles, news, and blog posts. Serve as a liaison between stakeholders and technical teams to communicate this

Content Management System Limitations and Capabilities. Define different types of content and their corresponding metadata (

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

Target different types of content and ensure that content is properly tagged and loaded when pushed to the site's content management system. (Again, the amount of work required is often underestimated.) Copywriter A copywriter is responsible for writing the text on a website that shapes the overall experience. In some cases, this copy remains fairly constant from day to day. It usually includes site and page introductions or instructions within pages. Contributors may also be involved in the ongoing creation of dynamic content, such as news or texts for marketing campaigns. Writing text is one of the gray areas that UX designers often keep, especially when creating frameworks (see Chapter 11). You could insert sample text first as a placeholder for copy, such as a site description or page description, but at some point someone needs to populate it with the final text the user will see - and since many items won't, that's not the case, If you are a dedicated copywriter, this task may fall to you by default. It is unlikely that you will be asked to write a brand image or marketing campaign for a well-known area of ​​the site; in this case

choose your hat


Every word can be closely scrutinized. However, if you're working on a task-based application that requires brief instruction messages, error messages, or other types of information that don't necessarily belong in an explicit content area, you can inherit (or make it) a written Task. Default is owned by the developer). Ask ahead of time if a copywriter is available, and if no one can be found, use a wireframe check. If the task falls to you, make sure to incorporate this work into your event planning 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 includes creating a look and feel that creates an emotional connection with users and aligns with brand guidelines. For example, a bank's website often needs to appear stable, reliable, and accessible. Visual design can convey this certainty through visual elements such as color and imagery. This promise is then fulfilled (or broken) through the interaction design of the website and other touchpoints with the company, such as the call center. Let's face it: Many people call themselves visual designers, web designers, or graphic designers, and many websites have poor or passable visual design. There is a big difference between creating an effective, impressive and emotional visual design and just passing it by. Sometimes just making ends meet is enough to achieve project goals, and sometimes it can lead to frustration and delays when project sponsors are unhappy or early users aren't involved in the design. On the other hand, it is easy to pay too much attention to the visual design, which affects the usability of the design. If you're asked to take on this role and aren't sure if you have the ability to make a real difference to customers, look at the company's current website and visually support the site or product to gauge their satisfaction with it. Often playing a central role in branding projects and marketing campaigns, visual designers are primarily responsible for effectively communicating a company's brand.


Chapter 2: Project Ecosystem

For content source projects, they can focus on creating content templates (such as article templates) that can be applied to many pages. For task-based applications, they can provide style guides that can be applied to common interaction elements such as navigation panels and tools (this requires a high degree of collaboration with the interaction designer). Front-End Developer Front-end developers are responsible for building the technical structure behind the page design and flow, and interactive elements within the website, such as B. Drop-down menus, expandable content areas, and interaction with multimedia elements such as videos. Technologies such as XHTML, CSS, Flash, JavaScript, Ajax, and Silverlight are often used for this work. Front-end development focuses on the website elements that directly interact with what the user sees, rather than the back-end systems that provide the underlying platform (for example, databases, content management systems, and the code needed to build a website). Functions behind complex functions). When you or a member of your team take on the role of a front-end developer, it's important to work closely with the rest of the development team to understand the expectations and responsibilities. Other important questions include which back-end systems to integrate with, which method to use to generate HTML, what flexibility in page structure is required to allow custom "skins", and what to expect from technologies such as Flash. If a prototype is planned (see Chapter 12), ask who will be responsible for developing the prototype and what the expected functionality is. Prototypes designed only for communication functions can be built quickly in applications such as Flash, but full-featured prototypes that need to retrieve actual data (for example, the account information a user just entered into a form) need to be built in the near future with back-end development Team members cooperate. Are you afraid to take on all these roles? Unless you're working on a very small project - or in a very small company - you probably won't be taking on all the tasks. The key is to understand what roles you can and, if necessary, want to take on for the particular project you're working on. By the way, you can get the necessary support in the project team by building a network within the client company or by referring others to meet the needs. Let's take a moment to talk about how to do this.

choose your hat


Build a Customer Support Network For those areas that you're not sure you can or don't want to take on, it's time to seek help. You can achieve this in three main ways: It is recommended to add additional team members when needed

It is clear. Identify key areas where gaps exist - when new responsibilities

These tasks are bearable and you have time to devote to them. Create a support network within the company to support you in critical situations.

Let's take a closer look at how to build a support network. Most likely, there are some key resources from other parts of the company that can help you succeed. You need to estimate how much time you can get from these people, because it is difficult to request time from outsiders on projects that are primarily run by one department. If you don't want to ask them to spend a lot of time from the start, just ask if you can work with them (or consult with them) to get the best possible outcome for the role's main responsibilities. Once you become a partner, 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 his or her time. Every company has a different structure and different department titles, but here are some common places to look for partners: For a brand strategist role, ask if someone in marketing

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

B. In project or product management or research and development, operations or corporate strategy, you will often find business analysts and product managers. IT or engineering departments are often the best choice on the front end

Developers and others who can help you access and gain insight into web analytics tools.


Chapter 2: Project Ecosystem

If you have recently been hired by a new company and would like to work in a different department, the best thing you can do from the start is to identify key people with potential partners and schedule interviews with them to understand their roles and experience. It opens up a grid that you can usually rely on for a long time, and gives you a chance to explain your mission (and UX design in general). You can also ask a good question at the end of the interview: "Who else do you think I should talk to?" The answer can help you find someone the lead project manager or client contact may not know. Even if you've been with a company for a while, you can still create an interview schedule like this. In this case, it's best to tie it to a specific milestone (such as launching a new project) or a pressing business goal to ensure high engagement. Make sure your manager knows what you're doing so it doesn't look like you're bypassing them. Good communication is key to understanding role expectations and building trust. Another key to building trust within a company is understanding its culture, often the unspoken expectations of how the company operates, e.g. by previous project experience (positive or negative), labels and acceptable Created for work logistics such as working from home.

Know the company culture. Culture is a bit like pouring Alke-Seltzer into a glass—you can't see it, but it somehow makes a difference. — Hans Magnus Enzensburg

Company culture may not be consistent across regions, departments or divisions, 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 planning a project and dealing with potentially difficult political situations.

You know the corporate culture


History We've all heard the saying that those who don't remember the past are doomed to repeat it, and project work is no exception. Understanding how the project or team arrived at the current state of requirements can help you better understand the challenges you may face during the project. Let's walk through some questions you can ask to understand the process that might affect your project. While some of the answers to these questions may seem ambiguous, remember that there are certain things that need to involve you in a project so that it can go through a difficult history and still be successful. Maybe you are the key to success! However, if many of the issues discussed below apply to you, and you don't feel like you can fix them, that could be a warning sign. If so, consider a general assessment of whether the project is poised for success. What are examples of previous projects that seem to have been considered?

It was a success, what contributed to it? What previous projects seemed to fail (or were particularly painful), 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 the project, any biases or expectations affecting that project, and how well the method works. Did the company collaborate with the designers and publish them?

Project or team? If so, try to find out what doesn't work and to what extent customers expect something different than your approach. If you can ask this question to more people in the company, it will help you learn a lot about subconscious 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 there is adequate communication about your responsibilities throughout the project. Has the project team worked on the project (or related materials)?

Seems like it's taking a long time to complete?


Chapter 2: Project Ecosystem

If this is the case, it may indicate that key customer stakeholders are not on the same page or engaged at the correct time, which can lead to multiple delays, changes in direction, or wasted time due to multiple iterations. It can also mean that there is no clear leader, someone who can say "no" (or at least effectively set priorities) in order to keep focus on business goals. If you can influence communication about the project, it can be helpful to create engagement guidelines to move the project forward. Did the company create the design without prior input?

User experience designer? This may be a mixed blessing. On the one hand, you're dealing with a team that understands the design needs and tries to bridge the gaps. On the other hand, you might see designs that you think don't meet the project's UX goals. This can be a tricky situation. Creators of these themes are often best served by adopting the tone of a respectful mentor or helpful advisor, first highlighting the merits of the design, then discussing the UX goals and discussing how this might be better achieved through different approaches. Creators can be important members of your support network. So it's important not to break bridges here, but to redefine your role in a collaborative way that keeps the rumors alive. Is the lead sponsor or project manager particularly concerned?

About the project? There are many reasons for this, especially when it comes to some of the factors mentioned above. Fear can also come from market pressures, and you should understand this. For example, has the company's stock price fallen? Has any contestant made amazing progress recently? Is the company losing money? Again, these circumstances don't necessarily mean you shouldn't take on the project; after all, often in such cases, the project has no funding at all. However, if you are very concerned about the company not being able to pay its bills, you should consider this risk.

You know the corporate culture


Geert Hofstede's hierarchy has a good model for describing cultural differences, which he calls "cultural dimensions", which often affect the way people interact and communicate. One of them is the concept of power distance. It is about the degree to which members of society (companies in our case) understand and accept the distance between people at different levels of power. For example, if a company's executive team members are viewed as particularly powerful and potentially difficult to approach, the company may have a greater power distance and its employees may be more hierarchical. If the company encourages the democratic exchange of ideas and the challenge of vision, the power distance may be relatively small.

Power distance is “…the degree to which less powerful members of organizations and institutions (such as families) accept and expect an unequal distribution of power.” It represents inequality (more vs. less), but it is managed from below, rather than managed from above. This shows that both supporters and leaders support the level of inequality in society. ” Geert Hofstede The Cultural Dimension www.geert-hofstede.com

Neither of these extremes can be considered good or bad in itself, although in general most workers in the United States seem to prefer a sense of small distance in the workplace. Interestingly, this is not necessarily an indicator of how successful a company is. Apple has a relatively high power distance (given the aura around Steve Jobs) and Google, as part of its culture, has a relatively low power distance, but both companies are known as innovation leaders. It is important to note that power distance within the client organization can affect how successfully you navigate the political waters during the project. This aspect becomes especially important at key points in the project: during requirements gathering (discussed in Chapter 5) and at important milestones such as release points (discussed in Chapter 4). Bring something extra with you when you work for a company far from a major powerhouse


Chapter 2: Project Ecosystem

Before scheduling meetings such as interviews and stakeholder reviews, take the time to understand reporting relationships and consider involving more midlevel people in your communications.

Logistics In addition to the larger aspects of culture described above, it is also useful to understand some elements that are more logistical in nature so that you can better integrate into your current working methods or introduce change in a thoughtful way. For example, it is helpful to know the general progress expected within the organization, including key release dates or deadlines affecting the project (the progress of building a software application on an annual release schedule may differ from that of a microsite supported by seasonal events. For example) . Does your team have to work long hours to meet upcoming deadlines? The expectations of working remotely are also easy to understand compared to working on-site. If significant on-site time is expected, you must plan for travel and on-site resourcing. If remote working is acceptable (or encouraged, which is common when working with multinational corporations), it is important to understand the methods and tools of communication. For example, is it acceptable to use instant messaging apps? 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. For most things, some companies prefer electronic media. In this case, a good projector and consistent Ethernet connection are important. Others are very paper-focused. In this case, you need to make sure you bring enough copy to the meeting to make it productive. You might be able to change the project's culture if you think another approach is more effective. But it's nice to know that you're encouraging people to change so you can make the transition - and possibly understand why something isn't working as expected.

You know the corporate culture


Putting it all together Now that you've explored the project's terrain, it's time to better understand the project's ecosystem: the environment you'll be working in (organizational culture), the general types of work you'll be involved in (e.g., you'll the type of website you are designing) and the people you will be interacting with (including their roles and responsibilities). This information is useful when you've set up roles in your project and are ready to get started in earnest. If you are a freelancer or subcontractor, this provides the basis for writing a proposal covering your work on the project (see the next chapter on UX proposals). If you work as part of a larger team and are not directly involved in the preparation of the proposal, you can bring your new knowledge to the project kickoff - your team's first meeting. For a basic guide on how to run a good meeting, see the online chapter "Quick Guide to Meetings". If you want to skip right to the questions you need to ask at the beginning of the project, see Chapter 4, Project Goals. and reconciliation. "


Chapter 2: Project Ecosystem


Advice for consultants and freelancers A guide for professionals who also run their own businesses Managing projects and client expectations can be hard enough, but if you don't have a contract, you could be in a position to fail on any project you accept to take on. .Proposals and SOWs are very important to protect your business and yourself from financial and legal problems. After a project is accepted and processed, make sure you take the time to draft a contract outlining the terms of your relationship and the client's payment schedule. Lars Unger


Advice There's an old saying that "what's good isn't bad", and the same is true of getting an item in general - high fives and feel-good moments are quickly replaced by "oh crap!" Time to write the proposal! "The biggest challenge in proposal writing is writing your first proposal. If you've never written one yourself, it's nearly impossible to know where to start, and this chapter should help you do just that. Every type of proposal you come across Projects all have different flavors, which can keep you on your toes when creating proposals. Luckily, there are a few things like a core that are common to all proposals and can be reused across projects. (About project types For a detailed discussion, see Chapter 2.) When should you write a proposal? Constantly. Why write a proposal? Throughout the history of project work, people have always found themselves Being in the most awkward position. When you first connect with a prospect and everything seems to be going well, you might be tempted to skip this step. While you clearly know what your client wants and can express their needs in a way they understand , but you're not ready to start working. In fact, this is when you need to slow down and take a deep breath. Instead of getting involved directly, take the time to define your professional relationships and the rules for working with new clients. Washington DC Peer , Jean Marc Favreau of Gan & Gisler, LLP: Contractors and their clients often think that there is a disagreement early in their relationship, when in fact the ambiguity is just waiting. Although it is almost impossible to prepare for every possible situation , but a comprehensive written contract is your best defense and the smartest way to avoid discussing the terms of your relationship later in court. The clearer you can predefine the terms and parameters of your relationship with your client in a written contract, The less likely you are to later argue about the obligations of both parties.


Chapter 3: Advice for Consultants and Freelance Consultants

New projects and new people are exciting. People don't usually want to break a deal by proposing, but like in any relationship, the honeymoon feeling wears off with time. Both parties in the relationship may break promises. Customer may not provide you with access to the Content in a timely manner. (I know this sort of thing is almost unheard of, but believe it or not, it happens! Here's the irony, in case you missed it.) Funds that used to be available for projects can be diverted elsewhere -- and then you, J. When someone is busy at work, they may be holding a bag. Organizations are also aware that they take risks when working with external suppliers – especially if they are very small companies or independent contractors. A well-written proposal will give buyers a sense of stability and protection, which can help alleviate many of the concerns that may arise. As suggested, you can also define conditions that protect both parties when certain circumstances change. If customers don't give you timely access to their resources, your schedule can falter. You need to make them aware of their obligation to the success of the project. If the client loses funding and abandons the project -- and you don't have an offer or other form of contract -- you run the risk of not getting paid for work already done. The gist should be clear: always write a proposal.

Drafting a Proposal Once you've received your project, it's time to finalize your proposal. The sooner proposals are approved and signed off, the sooner you can start working and most importantly, the sooner you can get paid for your work. The key parts of a good proposal are: title page, revision history, project overview, project approach

create a proposal


Scope of Work Assumptions Deliverables Title and Title Additional Costs and Fees Project Pricing Payment Schedule Confirmation and Release

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

Cover A cover is a simple page that introduces a document. Covers are a funny thing: there are a variety of ways to design them to be stylish and informative. How you do it is up to you. A typical cover consists of the following elements: Client Company Name Client Company Logo (if you have access to it) Project Name Document Type (Proposal) Proposal Version Submission Date Your Company Name Proposal Author Project Number Cost Confidentiality

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


Chapter 3: Advice for Consultants and Freelance Consultants

Your customers know who they are. Obtaining permission to use a company logo is probably not worth the time and effort, nor the inconvenience it may cause if you accidentally misuse it. Costing is best set up when you have identified the various components of the project in the text and the cost information is a good fit for the payment plan. 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 point. If it's not on your cover, your proposal may be rejected.

Figure 3.1 Example of a Proposal Cover Page

Figure 3.1 shows a user's (imaginary) logo. If permission is not obtained or the relationship is not fulfilled, it is best not to display the client company's logo.

create a proposal


Revision History Revision History is a separate section of a proposal that tracks how many times you have updated a proposal since its original version. In general, it is a good idea to include the version number, date, author, and any comments related to the version, such as B. What changed to provide readers with context of the change (Table 3.1). Table 3.1 Revision

SECTION revision history table example




real document

European Union

January 8, 2009


Update according to software requirements

European Union

January 11, 2009

1,0 1,1

Sometimes a client will sign a quote and then ask you to make further changes. If you decide to continue using the client and make these changes, you should take the opportunity to upgrade your documentation from version 1.x to version 2.0. Once the client accepts the offer and the terms are agreed upon, you're basically ready to go. Therefore, you must consider very carefully if additional changes are requested. This ensures that your costs remain reasonable and that both parties have a clear understanding of what changes will be made and at which stage the project will be restarted (if necessary). In the revision history, you should always state why the revision is a new version.

Project Overview The overview section describes in your own words the project you will be working on. This description should give your customer a clear idea of ​​what you think their product will contain, as well as an explanation of what to expect from the rest of your offer. Here's an example of how to start a review: [Client Company Name] wants to create a new online website. This web presence provides [customer company name] customers with the ability to research and purchase products online, as well as other services and benefits offered through the company. The goal of the site is to...


Chapter 3: Advice for Consultants and Freelance Consultants

You should be able to give a solid overview in a paragraph or two and explain in detail what the client can expect from you. It is best to end the review with a sound explanation of your proposal and suggested approach to completing the project: The proposal outlines [your company name]'s proposal and approach in detail for the design and development of [client company name] as described. website. Given the deadline [deadline date], it is recommended that...

Project Approaches Project approaches vary depending on the type of project you are working on. This is your chance to let the client know how you want to work with them on the project. You can define rules of engagement and set expectations for future work. Many individuals and businesses operate in very similar ways - but use different names or clever acronyms to match their overall branding. The mythological methodology was developed long ago in order to present itself to (potential) clients and is found in many proposals. This process is called "The PURITE Process™" (pronounced "purity"), and while we tell you this fabulous being is only a little dead on the inside, so be sure to read it as fiction. The name of the process is a bit silly, and the process is clearly a bit unfinished. Post-launch analysis is omitted in this approach (an oversight), but of course all clients should be included. Without further ado, this is the PURITE approach: [YOUR COMPANY NAME] has established a standard process for project success for our clients. While each of these phases may not apply to [Project Name], the overall process is defined as follows: The PURITE Process™ is [Your Company Name]'s internal methodology for ensuring the success of all area-wide programs. With PURITE, [YOUR COMPANY NAME] has a proven policy of working closely with customers and users/target groups to reliably meet and exceed delivery expectations. Ask - get ready. We devote part of every initiative to understanding your industry and your competitors and their business processes so that we learn as much as possible before we capture demand. look. We work closely with your subject matter experts and/or users to define the requirements for properly building your project.

create a proposal


R - Rendering. During the rendering phase we create and develop all parts of the project/product. In our experience, each development phase requires a lot of dedicated and focused work, but also timely, open communication with your team. It also requires us to... I - I repeat. The iterative phase is repeated throughout the life of the project. We work as fast as possible to bring projects to life, often creating multiple iterations within tight time frames. This requires your direct and timely participation and your dedicated resources. The end result is a product that you specify and help create. T test. We test each project during the rendering phase; however, we need more eyes - from our own testing team and your specific user group/target audience for targeted testing. This extra round of testing helps ensure that as little as possible is delivered with a project that has been rigorously evaluated on multiple levels. E - Activate. After the first five phases have been successfully completed and signed off, we will launch the solution and put it into operation. The PURITE Process™ doesn't end there. After the project is completed, we communicate with the client regularly. We will continue to measure your satisfaction, understand your changing goals or project improvements, and support you in defining the best approach for the future development of your project.

Feel free to use as little or as much as you find applicable or useful. Also, the author of the myth who created the process won't mind if you don't cite sources. Your process definition can be as detailed as above, or as simple as: plan, define, develop, extend. Plan the overall strategy. Define detailed project requirements. Develop, test, improve, and release work products. Improve projects by suggesting improvements based on information gathered after development, testing, and release

Once the process is defined, you have the opportunity to detail the various efforts at each stage of the method and explain what each of these efforts means for you and your client. The length of your proposal interview section will vary depending on the project, your process, and the activities that occur during each step of your process. However, try to limit the scope to no more than two or three pages


Chapter 3: Advice for Consultants and Freelance Consultants

Only provide deliverables that you can deliver to the client - preventing further file updates or rechecking project pricing.

Scope of Work In the Scope of Work section, you define the division of work for the project. That is, you determine which project components you are responsible for and which project components the customer is responsible for. Read it again. think about it. Let it sink in. let's go. that's right. It's the part of the quote where you tell the client in writing that we're going to do it, and you're going to do it. Then, when the client signs your proposal later, they agree to the contract, and you have paperwork to help you clear up any misunderstandings. The point here is to clearly identify who is working on which aspects of the project and which aspects of the project are included in your proposal and your estimated costs. This should be enough reason if you can't find another really compelling reason to write a proposal. Here is a very brief example of the scope of work: [Client Company Name] has requested that we provide all services necessary to produce [Type of Item]. [YOUR COMPANY NAME] specializes in [customer experience design] [client company name]. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] based on the project plan. [Client Company Name] provides all necessary resources to be used in the project, including fonts, color schemes, branding standards, etc.

Assumptions The Assumptions section of a proposal is a great place to state what your client needs to ensure your success, leaving no room for debate. That is, you assume that you have access to these things, and that you will communicate them to the client, or that you can use them to make the project a success.

create a proposal


The assumptions you make in this section are actually expectations. It's more polite to just accept. You can create as many project plans as you need. However, if neither you nor the client commit to meeting milestones and goals, both agree that the project is doomed. The general assumption is that resources and assets are expected and that both can be accessed in a timely manner (translation: immediately, immediately). The following is an example of writing a hypothesis: Assume that [Client Company Name] needs to provide the following funds and resources. Failure to obtain these funds and resources in full and in a timely manner may result in unsuccessful completion or delay of this project. The following assets and resources are required: Timely access to all necessary personnel [Customer Company Name]. As-is timely access to all necessary assets of [project], including all source files, if available. Appropriate content of any aspect of [item], including but not limited to copy, images, sounds, etc.

Deliverables are work products that you create and deliver to the client. In this section, you have the opportunity to detail to the client what kind of work product he can expect from you during the project. It is recommended that you work on status reports separately towards the end of the project, but feel free to add them to this part of the project. Provide a description of any work product you may include, even if the work product has not yet been created. This might seem like overkill, or potentially open a can of worms like "I've read [shipping type] in the quote, but I don't see it here," but maybe one sentence will suffice for the difference. Deliverable [your company name] delivers a set of deliverables during the project. We have identified the following services for [Client Company Name]:

48 years old

Chapter 3: Advice for Consultants and Freelance Consultants

Creative Brief The creative brief is the first step in a project. This document will help us create project overviews quickly and efficiently. The purpose of the creative brief is to clarify the client'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 allow customers to use the work product you create. These rights can be defined in many different ways, but most of your work falls into two categories: proxy works, licensed works

Projects involving contingent work (known in legal circles as "contract work") are assumed to have been created and copyrighted by the party paying for the work, not the party responsible for performing the actual work. This means that when you work on a commissioned project, you have no rights to the work and everything you create in connection with the project is the property of the client. Many companies and individuals struggle with this situation: it often means no further "maintenance" work (with additional income), since the client can choose to maintain it himself after the project is completed. Don't be put off by projects that implement customer requirements; it's not uncommon. Placing procurement items in the context of a company's long-term employment is common in employer-employee relationships. 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 choose to do business. Time and experience will help you make the right decisions about the type of work you do and the pricing model you choose. A licensed work item 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. They are most likely to create proposals


If you retain ownership of all source materials for your work and only provide limited-use work product to your clients (e.g., PDFs rather than native Word, Visio, Axure, OmniGraffle, or other editable documents), please take advantage of licensing your work. ). You can license your work in a number of different ways, including licensing the work for unmodified, non-commercial use, or in any other way that may be appropriate for your situation. Creative Commons (http://creativecommons.org/about/licenses) provides an easy-to-follow explanation of the various types of licenses available to you, but that's only a small part of the licensing world. If you find yourself faced with very detailed and specific needs, it is best to contact a copyright attorney to help you find the best solution.

Additional Costs and Fees It's important to let your clients know if you're offering them the item price with (or without) outside sources in mind. For example, some projects may require the purchase of a photo library from a supplier. You can purchase the artwork (with appropriate usage rights) and have it included as part of your fee, or you can clearly identify the purchase of the artwork as an additional cost that is passed on to the client. You can also offer services that you want customers to know about - this is a great opportunity to promote them. The following is an example of 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 and approved by [Customer Company Name] at the time of invoicing. Additionally, [YOUR COMPANY NAME] provides hosting services to our clients without hassle. We offer hosting, including configurable web-based email, for as little as $25 per month plus a $25 setup fee. If [Client Company Name] wishes to purchase a Maintenance Package, [Your Company Name] will endeavor to create a mutually acceptable and beneficial package.


Chapter 3: Advice for Consultants and Freelance Consultants

Project Pricing: After you have documented the details of how you will perform the project work, it is best to communicate the cost to the client. How you arrive at a price is largely up to you, but here are some tips: Estimate how long you think it will take to complete the project - including a certain number of revisions, and estimate a reasonable project management time of about 25%; then decide The hourly rate you want to charge and collect all fees. There are various formulas that can help you with this, such as: B. Apply a difficulty level to each part of the project to help you determine the cost range you can offer your client. In most cases, experience is the key to properly estimating projects from a time and material standpoint. How do you determine billing rates? For comparison, research what others charge by targeting contractor wage and price surveys. For example, organizations such as the Information Architecture Institute (www.iainstitute.org), AIGA (www.aiga.com), Coroflot (www.coroflot.com), and talent agency Aquent (www.aquent.com) are responsible for compensation and contractor evaluation investigation. By considering your experience, the rates of others in the market, and what you think is reasonable and fair, you can get a good idea of ​​what rates you are likely to charge. Remember, you can lower your interest rate at any time. It's much harder to ask customers for more money after they see the numbers on the page! There are many different ways to price your project build. Depending on the nature of your project, you may want or need to provide multiple estimates to allow for different pricing options. For example, suppose you offer a client two options: a static HTML website and a website with a content management system (CMS) that supports dynamic content (which the client can manage without dedicated resources). Here's how you might develop a project estimate: Project Estimates [Your Company Name] has proposed multiple cost estimates for [Client Company Name] in order to provide the best possible options for your current and/or future needs. [Your Company Name] assumes that all Content is provided by [Customer Company Name]. If [Your Company Name] is involved in serving content, estimates will need to be redefined.

create a proposal


[YOUR COMPANY NAME] estimates allow flexibility in cost and needs. Estimates are as follows: Estimate 1 [your company name] Estimate [project] for [customer company name] No interactive content...

Remember, unless you end up in a negative cash flow situation, there really is no wrong way to put your project estimate together!

Payment Schedule There is a myth that all freelancing projects are paid 50% up front before the work starts and 50% when the project is completed. This myth needs to be busted – now! This is not the way to do business, nor is it the way to guarantee a timely and steady income while working. You don't want to put yourself in the position of making change after change for one client just because you want to complete the project and get paid instead of going through the change order process. You can evaluate projects in a number of ways, from submitting invoices within a given time frame to paying based on milestones. The smarter approach is to base your project on a recurring payment plan with detailed invoicing on a regular basis. This approach should also give the client a clear understanding of what has been achieved and what remains to be done in the project. The following is an example of one method of payment for your work arrangement: Payment Plan [YOUR COMPANY NAME] A typical payment plan requires XX% of the estimated total cost of the project to be paid in advance before the project begins. [YOUR COMPANY NAME] must submit invoices by the 1st and 15th of each month; full payment due within 14 days. Upon project completion, [Your Company Name] will deliver all work products to [Customer Company Name]. Once the materials have been satisfactorily approved, [your company name] will reimburse any overpayment on the advance payment, or [your company name] will issue a final invoice for amounts not covered by the advance payment. Note: If [Project] is on hold for more than 14 days without progress, [Your Company Name] must submit a final invoice for all charges not included in the booking, should the project reopen.


Chapter 3: Advice for Consultants and Freelance Consultants

While not required, it can be helpful to include notes on what to do with an item if it has been left on hold for an extended period of time. This determination can help keep your projects on track and move forward—and give you talking points with your clients. If you haven't offered them additional work for a long time, you want to be able to keep looking for work to fill the gap.

Confirmation and Approval While it is important to ensure that proposals are submitted, it is not sufficient. Proposals don't mean much until the right people at your company approve and sign off on clients. It is important to make sure everyone is clear about what to expect and what is expected of both parties. Just as importantly, you protect yourself from the "iteration highway" and reduce the risk of customers dragging you into "feature creep". H. Constantly asked to record "one more thing". Checkout is very simple and straightforward. After creating the proposal document, you can provide the client with an acknowledgment of receipt and approval to approve the contract between your two companies. Always prepare two copies - one for each party - and make sure both copies are signed. Here is an example of an acknowledgment you could use: Acknowledgments [Customer Company Name] has fully acknowledged and accepted this offer. This offer must be signed and dated by an authorized representative of [Buyer's Company Name] to be valid. Alternatively, in lieu of such signed document, a signed purchase order relating to this offer shall be deemed accepted (but only if all preprinted terms on 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 supersedes and supersedes any prior agreement, discussion, negotiation, undertaking, writing or arrangement, whether oral or written. This includes, without limitation, any statement contained in any sales literature, brochure or other written instruction or promotional material 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 contained herein or in the Agreement.

create a proposal


Accepted by authorized representative: [your company name]

[Customer company name]

from: ________________________________

from: ________________________________

arrive: _____________________________

Production: ________________________________

address: ________________________________

address: __________________________

Benchmark: ________________________________

Benchmark: ________________________________

Make all checks payable to: [Your Company Name]

The Statement of Work (SOW) is a general definition of the project's objectives, which you should be able to summarize in a 2-3 page document (not including the title page). Often a job description is written before delving into detailed requirements. However, depending on the needs of your client and project, you may choose to create a hybrid document that best suits your needs. Typically, the SOW should be used to build early consensus between your team and the client's stakeholders. The SOW defines the project's inputs and outputs, as well as assumptions and constraints. At this point, it's not uncommon for clients to ask you for a ballpark figure of the work you'll be doing for them. It might be a bit risky to answer at this point. It is recommended that you try to avoid details or commits where details are not defined. It's simply impossible to know how much a project will cost until you've written a proposal and/or requirements document. However, at this point you must use judgment. If you're working on a project like a simple website and have successfully completed several similar projects and/or have worked with the same client before, then you have some wiggle room. Remember, in the later stages of a project, it's better to be cautious than embarrassing. The statement of work should be two to three pages long and contain at least the following:


Chapter 3: Advice for Consultants and Freelance Consultants

Cover Revision History Project Reference Number Project Summary Start Date End Date Rates/Costs Project Reports Activities and Deliverables Cost Plan and Payment Plan Confirmation and Release

Are these elements familiar? You should -- you can use a simplified version of the proposal to create a statement of work. You've now seen how to collect two types of documents that you can use to identify the work you've done for your client. These documents should form the basis of any project work you perform for your client and provide you and your client with a clearly defined project description.




Goal and method of the project: Know which star to aim for. One of the keys to a good project is for the team to start with a clear project goal and an easy-to-understand methodology. Ideally, project management would set this up for you - but how do you know that's not the case? This chapter is about setting project goals and asking questions to help you solidify those goals. We also discuss some common project approaches (or methodologies) and how they affect the way you work. Caroline Chandler



You are at the beginning of the project, with the whole team for the first time. The project manager shares some material and gives you an overview of the project. By the end of the session, you should ideally have the following information:

Why is this project important to the company? How will stakeholders determine if the project is successful? What approach or methodology will the project follow? B. What are the key dates or milestones for confirmation, etc.?

Approve a business prospect? All of these questions are related to what stakeholders expect from the project: what will the project achieve and how will they participate? The first two questions relate to the project goals and the last two concerns the project methodology. Project objectives are the specification of measurable project goals. Let's talk about goals in more detail.

Consolidate Project Goals Goals are an important focusing lens 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 strategic initiatives within the company. For example, if there is a strategic move to target a new potential customer base (called a marketplace), the website or application you create may be an attempt to provide that marketplace with online access to products and services related to it. The goal of the project is to enter and develop this market. A clear purpose runs through the entire project. It helps you ask the right questions while gleaning ideas from business prospects. Plan studies with users and focus your analysis on results. Elaborate and implement ideas gathered from stakeholders and users

Combined into one list of project requirements. Prioritize these project needs based on value to the business

Strengthen project goals


Create effective interaction designs. Manage design change requests after development begins. Focus on deployment activities such as training and communications.

(to notify users before and during the launch of a new website or application) to determine whether you are meeting the needs of the client company

The project has already started. 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 some project-related requirements from the business stakeholders and the client, but they can all be a bit Fuzzy (Figure 4.1). Your goal is to turn them into educated statements that you can use as a benchmark for project success.

Project related consultation

The company's strategic goals are not clear

User Needs Stakeholder Thoughts

unclear goals

Thoughts from a User Complaints Advocate

Figure 4.1 Unclear goals, ideas, and needs

Firm goals are easy to understand. Avoid internal jargon. recognizable. Avoid ambiguous statements; instead, use terms that look similar to you

Can be useful when prioritizing requests. measurable. List specific statements that you can independently determine

Use it to measure your success. When you define a vague goal and make it clear and measurable, it becomes a solid goal on which to base your decisions.


Chapter 4: Project Objectives and Approach

Figure 4.2 The target is fixed

Goals of the company's strategic projects

You will hear many statements that could be considered goals. Analyzing vague goals like the one below will help you solidify your goals and communicate them 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 achieve this goal, multiple initiatives within the company must work together. A single site or application can help, but it likely won't be able to handle the entire load unless the entire organization is tasked with handling that site or application and it ends up being very successful. commercial lawyer


"Our goal is to create passion among our client base."

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


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

We are here now. This is easy to measure, but focuses too much on intermediate steps. Assuming you're generating more traffic, it probably won't help if people aren't taking the action you want.

Strengthen project goals


Vague goals can give you insight into your client's needs and larger goals. This allows you to develop more specific project goals, such as B. Increase online sales revenue by 10%. Increase your online advertising revenue by 20%. Increase the number of existing and potential clients in our client base

Database max at least 20,000. Deliver highly rated and frequently cited content to our key users.

(Note that it took some work to decide how to measure "highly regarded" and "highly cited", but these elements are built on.)

Each of these factors can be measured and influenced by your project. They can also be a good match for the design and functionality you offer. For example, it's common to offer an online newsletter with the goal of expanding your customer database: in order to send out the newsletter, you need to collect customer email addresses to add to the database. Goals can also bring new requirements. For example, if you measure success by the average rating of items on your site, you need the ability to allow users to leave comments. In this way, goals help you focus your efforts on gathering ideas for your website that can later become project requirements. If there are multiple goals, be sure to create a priority list with your corporate sponsor and project team. Sometimes there are conflicting goals during the design process and the team needs to know which takes precedence. The final list of prioritized goals should come from your project sponsor, but you can be an important part of the discussion. Let's talk about how.

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


Chapter 4: Project Objectives and Approach

opportunities and risks. This is known as a SWOT analysis and is a common business analysis technique and way of discussing a company's position in the market. You can also use this time to talk about your company's competition. Understanding SW strengths and weaknesses in a SWOT analysis is the company's current strengths and weaknesses with regards 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 number of originally published research resources (strength), but may not have anyone to help make this content more accessible to ordinary users, making the company "too academic" (weakness) the opinion of. Identify opportunities and risks. OT is the forward-looking half of SWOT. Given the factors that differentiate the company from its competitors, what are the possible future moves for the company to create new niches or strengthen existing ones? What circumstances threaten these plans? For example, our research and development company may choose to hire writers to publish more accessible articles related to their original research (an opportunity), but if the site's current toolset does not have strong content curation capabilities, the publishing process may will be very slow. This can give competitors the opportunity to react (threats) more quickly. Compare competitors. Who are the company's main competitors? Who are your competitors? They can be different, especially for large companies or brand new sites. Are there any places that are not 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. Collecting SWOT and competitive discussions are good topics to discuss at the same time because they influence each other. Hard to say

Strengthen project goals


You identify 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 here the SWOT, your project goals - and your overall fit of your project with your company's strategy - should be easier to define and prioritize among them should become clear. Setting project goals will help you understand what to expect from the project's outcome. Next, let's talk about expectations for project completion. Knowing the project methodology will help you collaborate effectively and get the right people on board at the right time.

Learn about project methods. Knowing the overall project approach or approach is an important part of knowing when and how to get involved and how you should involve others such as your project team and business stakeholders. Sometimes it seems that there are as many project methods as there are projects. How to choose the right project approach is a big topic in itself. The approach you choose depends 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 organizational culture. For the purposes of this book, we assume that you join a project whose course of action is largely determined by those responsible for the project's success, such as the project sponsor and project manager. In this case, your main goal is to understand the method and make it work for the business prospect and your users. Here we highlight the two most common approaches, and a third that shows possible variations you may encounter in your project. It's important to note that most approaches involve the same steps: planning the overall strategy, approach, and team structure. Define project requirements. Design and develop interaction and visual concepts into detailed concepts

Technical data. Develop, test and improve solutions.


Chapter 4: Project Objectives and Approach

Deliver solutions through news, training, and program rollouts. Extend the project by suggesting improvements.

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

Waterfall method The waterfall method views project steps as independent, distinct phases, requiring approval of one phase before the next phase can begin. For example, the design phase doesn't actually 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. allow




Define design, development, implementation, extension

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

The problem with the pure waterfall approach is that it assumes that each stage can be completed with minimal changes to the previous stage. So when you come up with new requirements during the design phase (which is often the case), you have to propose changes 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 methods take a more fluid approach, with some steps running side by side. For example, you can use agile or rapid development methods to release website versions in a rapid, iterative manner. Agile methods often place more emphasis on rapid collaboration than detailed documentation and formal approvals. Learn about the project approach


Iteration 1


repeat 2


repeat 3


Deployment Design Deployment Design Deployment Design Definition


define approval


Enable publishing extensions

Figure 4.4 Example of an agile method

A true agile approach (for example, following best practices developed by members of the Agile Alliance) requires small teams where members sit together, with little emphasis on defining formal roles between team members. This way of working enables a very high level of collaboration, reducing the need for extensive documentation between the design, development and testing phases. Team members can ask questions, conduct quick whiteboard sessions with other team members, and implement solutions—all without waiting for detailed documentation and approvals. In a fully operational system, when one of many iterations is released, stakeholders review it and the resulting input is considered when planning the next iteration. (An iteration is a draft version of a particular website or application.) It's a beautiful thing when agile methods work as intended. However, in most companies and most consulting businesses, teams rarely use pure agile methods. This is partly because organizations 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: use enough structure and documentation to reduce the risk of distributed teams and team member changes, while also using enough collaboration and iteration to be relatively flexible in responding to change. For example, a project might follow a waterfall model, but have overlapping phases so that there are key points for collaboration between teams. this allows


Chapter 4: Project Objectives and Approach

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


Development and Design

to design


Develop and deploy beta

Enable publishing extensions

Figure 4.5 The modified beta waterfall chart

Note the less repetition of the design phase 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 committing significant development time. The modified waterfall approach shown in Figure 4.5 is one of the most common. These are common methods and thus form the methods within the scope of this book. However, many of the topics covered here apply to your project regardless of the details of your approach, as basic activities (such as definition and design) are still required.

Digging Deeper If your project follows an agile approach, you will have unique requirements gathering needs, such as writing "user stories" as a way of gathering requirements. We recommend Mike Cohn's Applied User Stories: For Agile Software Development (Addison-Wesley Professional, 2004).

Learn about the project approach


How will the visit affect me? Knowing your approach will help you understand a lot of things: what questions to ask and when to ask them. For example, if you

If you use a pure waterfall approach, extra effort is required to ensure that the requirements covered in the definition phase contain all the information needed in the design phase. (We discuss requirements in the next chapter.) Expectations of how and how project team members will work together

Close cooperation will be. For example, agile methods require very close collaboration. The waterfall approach involves individual work most of the time, with touchpoints once or several times a week. The level of detail required for your document and level

formalities. Documents turned in at the pickup point must be official, almost like a legal contract. You'll typically need more formal documentation with a waterfall approach that needs to be approved before moving on to the next phase. However, when using agile methods, you may also have some formal release documentation - for example, gathering information at key decision points, such as preparing a specific iteration for a full release and deployment. Key Milestones Requiring Stakeholder Approval i

Serve different groups. The approach identifies what different audiences need to deliver at different points in the project, including stakeholder approval at launch points and potential user feedback during beta releases. Now that you have identified the project goals and understood the project methodology, in the next chapter we will begin the main work of the Define phase: gathering requirements.


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 thought a lot about what needs to be done. There may already be a list of features provided by some key members of the company (your business prospects), along with their opinions on which features are most important. These are the elements of the project's business requirements and are a good starting point. To ensure a complete solution at the end of the project, you need to generate and clarify requirements from multiple perspectives. In this chapter, we focus on gathering and detailing the needs of your business prospect. Caroline Chandler



Chapter 4 discusses ambiguous goals and discusses some of the 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 ideas from interested parties, user complaints or user requests. In order to create these useful and traceable components of your project, you need to condense these ideas into requirements. Requirements are instructions that define what a website or application must do. Ideally, business requirements provide insight into the overall needs that need to be addressed. It represents and gathers the demands of different interest groups. It sets the direction of the design without being too specific about what it will look like

Completed as a self-contained unit of work for prioritization and tracking

Below is an example of an idea for an e-commerce website functionality. Various business prospects in the early definition stage can convey the same idea to you: "customers can track their orders online". That's a good basis for a claim, but it's vague. Start by asking questions about the details of the request, such as: B. Why is it important for the business that customers can track their requests?

Order online? For example, is it about reducing the number of customer support calls? Does the company currently have online package tracking?

If not, new requirements for tracking capabilities need to be gathered, or the company may need to work with a third party. How precise must the tracking be? what information

Should it be included in tracking details? For example, should the website provide an up-to-date estimated delivery time? By asking questions like these, you can turn vague ideas into concrete requests. It is also clear that the same statement may mean different things to different people.


Chapter 5: Business Requirements

For example, a stakeholder might think that tracking a package involves receiving a confirmation email with a tracking number that can be entered on UPS.com or another website so that the customer's stakeholder can see when the package was last stopped. Ideas Another stakeholder may feel that the company needs to take package tracking to the next level and invest in developing the ability for users to track packages via GPS and see their exact location in real time using an online map. As you can imagine, there is a significant difference in user experience and scope here! It is important to emphasize these differences at the beginning of the project. Otherwise, you'll end up developing a solution that doesn't meet the intent of your business stakeholders—and possibly not meet your project goals. This leads to unhappy stakeholders and wastes time and money if functionality needs to be redesigned. Therefore, clear and detailed requirements are an important part of the overall project. Deriving a comprehensive list of project requirements requires the following steps: 1. Know the current status of the site or its competitors. 2. Gather needs and ideas from a business perspective and from the perspective of current and potential users. (See Chapter 6 for details on working with users.) 3. Consolidate ideas into requirements. 4. Prioritize requirements based on project goals. (See Chapter 9 for advice on prioritization.)

Business and User Project Requirements Business Strategy Requirements

Figure 5.1 combines ideas about business needs from business stakeholders with ideas about user needs from user research. Project goals are then used to guide prioritization efforts 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 thoughts that came to mind when you collected requests.

Knowing the current state When taking a deep dive into the website or app you're designing, it's important to make sure you understand the current state of the website (if you're redesigning an existing website) or better understand your main competitors thoroughly (before creating new website or application). You can learn a lot about the current state through stakeholder interviews (more on that on a few pages). You can gain a lot of insight on your own, which can serve as a solid foundation for stakeholder interviews and user research work. A good way to get context and generate ideas that might become requirements is to perform a heuristic analysis.

By any other name... the word heuristic means a rule of thumb or best practice. Heuristic analysis is now understood as the review of a product against a set of rules (heuristics) for an available design, usually performed by a UX designer. A user-friendly website follows most or all of the heuristics you use in your analysis. You may also hear this technique referred to as heuristic scoring, expert scoring, or a combination of these terms.

Heuristic Analysis Heuristic Analysis is a technique that can be used to evaluate the usability of an existing theme against user experience best practices. You can perform this type of analysis on your current website at the beginning of a redesign project, or analyze a competitor's website to identify opportunities to provide a better user experience than other companies. The result is a document that describes the site's strengths and weaknesses and includes suggestions for improvement. Upon completion, you will gain a deeper understanding of


Chapter 5: Business Requirements

Learn about the site being analyzed and a list of ideas to help meet the needs of the new site. For example, one commonly used heuristic is one of Jakob Nielsen's list of ten usability heuristics (see Jakob Nielsen's website www.useit.com/papers/heuristic/heuristic_list.html for a complete list):

Visibility of system status. The system should always inform the user about what is happening by providing appropriate feedback within a reasonable time frame.

There are many situations on a website that might not follow this heuristic. Let's say the user clicks the "Download" button, but doesn't 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 might click the button again, thinking they missed it the first time...and then click again...this could lead to multiple downloads and potential issues with site performance and users who are using Make multiple downloads without you realizing it. Through heuristic analysis, you can identify this as a problem area, describe it, and assess its impact. You can also share an idea to solve a problem that can be added to the request list. Why do heuristic analysis? Performing this type of analysis is a relatively quick and inexpensive way to gain design feedback. Heuristic analysis can provide a general understanding of design quality and help identify potential design issues. Note that this activity does not directly involve end users and should not be a substitute for actual user research. For example, maybe only 50% of your heuristic insights will actually be confirmed by follow-up research. However, the analysis gave the team a good overview of possible problem areas. If you're redesigning an existing product or website, it's also useful for identifying obvious quick fixes that can improve immediately while the redesign continues behind the scenes.

Learn about the current status


how do i do it The specific heuristics you use may vary from project to project, but the process for performing the analysis generally remains the same: 1. Gather background knowledge about the product and project. Make sure you have site goals, a list of key user groups that need support, information about the types of environments your users may work in, and a basic understanding of any specialized skills your users may have. (For example, your analysis will be different for a site built for general consumers versus one built for pharmacists.) If you need help with the latter, visiting different competing sites or apps can help you understand the best Common terms for areas of interest. 2. Select the heuristic 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: www.asktog.com/basics/firstPrinciples.html. Once you're familiar with site themes, you might want to add some of your own—especially if you're analyzing multiple sites. Make sure your list is a manageable size (e.g. 8 to 12); too many heuristics can make the technique difficult for you and your readers to use. 3. Go through priority areas of the website and identify areas where heuristic tracking is good or missing. Each observation you make should include the following information: General observations. A short statement summarizing the results. Ideally, they are numbered for quick reference as you browse through the report. 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 problem observations, this rating can be high, medium, or low, or it can indicate a positive result if you share something your site did well. Typically, a high-impact issue is one that you believe will cause many users to fail or be unable to complete a specific task


Chapter 5: Business Requirements

Permanent loss of information (for example, a problem that caused users to lose changes to a document 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 confusion, but usually don't cause time wasters or frustration. suggestion. These are next steps or ideas that you share as solutions to the problems you are facing. Figure 5.2 shows an example of how these elements appear together in your heuristic analysis. Observation #4: The search function doesn't seem to return all possible results.

a big problem

Sample search functionality tests yielded mixed results. Searching for a name in relatively recent posts covering a topic that isn't often mentioned occasionally returns no results. Also, the main search only seems to return links to new stories, 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 displaying search results—for example, stories from similar categories or similar tags—so that research users can follow multiple threads. 3. Consider a generic search that displays results by category. 4. Use the search term log to learn about frequently searched items. This can also clarify items that the user cannot find.

Figure 5.2 A Sample of Observations in the Heuristic Analysis Report

4. Present your findings to the project team and key stakeholders. Review your observations and suggestions. Discuss why you left off the grade you were given. (This is also a good time to develop recommendations to validate the results using one of the techniques discussed in Chapter 6.) How does heuristic analysis help gather requirements? Once you've completed your heuristic analysis, you'll have a deeper understanding of the current state of your site (or its competitors) and a list of ideas that can help you capture requests. You'll also get some ideas on organizing topics to cover in your requirements gathering sessions - which will lead us to the next step in the process.

Learn about the current status


Gathering Ideas from Stakeholders As we saw in the example at the beginning of this chapter, if you don't understand the context of an idea, such as "customers can track their orders online," you run the risk of missing the stakeholder relationship. different expectations. Our friend wants to track a package via GPS. One of the most common mistakes in projects is picking a feature and calling it a requirement without first understanding the problem and the expectations for the solution. Why is the claims collection process often shortened? Gathering ideas—and merging them into requirements—can take a long time. It's easy to underestimate the number of questions you need to ask when formulating requirements in order to prioritize them. If the process is poorly structured or the engagement is incomplete, there can be upheavals that last throughout the project. (Chrout wasted time in extra meetings and work iterations due to lack of communication and engagement. This is different from the more efficient work iterations of designing and testing working solutions to find the best one.) So how? Are you advocating a balanced claims process that focuses on business needs without wasting time? Here are some steps of an effective process: 1. Outline roles and responsibilities. Make sure project team members understand their role in gathering requirements. 2. Bring the right stakeholders into the right groups to ensure the best use of time during needs-based interviews or meetings. 3. Make a meeting plan, including the topics to be discussed and questions to be asked at the meeting. 4. Effectively chair meetings, gather ideas and provide clarification. Test these ideas to determine potential needs. After the meeting, don't forget to thank the stakeholders involved and update them on progress once you've made it to your comprehensive priority list. Let's consider each of these steps in more detail.


Chapter 5: Business Requirements

Overview of Responsibilities When gathering business requirements, project team members typically interview key business stakeholders to gather ideas. Business stakeholders are those within the organization who have a business-oriented interest in the success of the project, or contribute expertise, or both. These people are not involved in the project full-time, but they must be involved in key points of the process, and requirements gathering is one of them. Remember, they also have (sort of) day jobs, so their time is valuable and often hard to find unless you plan ahead. A project sponsor (or sponsor) is a business stakeholder who is also directly responsible for the success of the project, usually at a relatively high level in the company, such as a director. He or she will not be involved with the project on a daily basis throughout the project lifecycle, but may be actively involved in gathering requirements and ensuring high engagement of business stakeholders. Sponsors may also attend some or all of the meetings. The project team includes people formally assigned to the project as permanent resources. You can get involved as a project manager, UX designer, business analyst, technical manager, visual designer, quality assurance manager, and more. Depending on the size of the project, this may be their main task. Responsibilities for requirements gathering are often unclear within the project team. By taking the time to define responsibilities early on, you can ensure an efficient consolidation process. Here are some questions to ask when determining each team member's specific responsibilities in requirements gathering: Who will be primarily responsible for gathering and planning the correct business requirements?

Which stakeholders are the most productive groups? This can include internal and external stakeholders (eg partners, suppliers, etc.). Who develops the topics and question structure for business engagement?

Owner meeting? Time permitting, this is a great collaborative exercise for the team. The Lead Moderator can then structure them to suit the meeting. Who chairs the meeting? Who keeps the notes and how are they shared?

Gather ideas from stakeholders


So who is contacting whom? Will someone from the technical team be present at all meetings?

If yes, how was that person involved (listening, contributing, or otherwise)? Whether you are primarily responsible for one or more of these areas, as a UX designer you have important skills that you can bring to the process. Creating structure for topics and questions requires a clear sense of categorization (which sounds like a good overlap with information architecture), and of course facilitation skills are important to keep the meeting focused and all participants engaged.

Gather the right stakeholders. The main purpose of the stakeholder survey is to understand the ideas, needs, knowledge, and frustrations related to the project from different perspectives, and then incorporate them into the project requirements. There is also sometimes an unspoken benefit of involving many different groups, so that everyone feels they have a voice in the project—and thus support the final solution. While getting people involved to gain their buy-in may seem more political than practical, it's often an important step that gives you access to a network that will support you throughout the project. It also helps you avoid last-minute changes that can happen when someone you're not talking to asks a question later in the process. So it's usually a good idea to get a lot of people involved. On the other hand, schedule and budget should be kept in mind. Involve a large number of people, and from their perspective as well as yours, just having a meeting takes time—not to mention the time to sift through notes to identify trends and consolidate redundancies. For the sake of efficiency and your own health, it makes sense to prioritize the groups you want to talk to and select key individuals from among those groups to serve as thought leaders for your team. Which stakeholders can you involve? These groups are often a good source of ideas: groups with initiatives that rely on websites (such as those

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


Chapter 5: Business Requirements

Groups that need to support processes directly behind the site or

Applications, such as providing content, inputting and managing data, and reacting immediately to information collected. First-line customer service, such as B. Telephone or online support or

Anyone who deals with customers in person (such as retail or delivery), sales, product management or consulting services to represent them

Products and services displayed. Human resources to achieve employment goals. Public relations providing information to investors and media. All groups responsible for other relationships that need to be developed

When choosing who to include, you should seek the help of the project sponsor and any project team members familiar with the relevant groups to help you choose the right people. Create groups that encourage good discussion. There is no one right way to do this, but a common way is to group stakeholders by department, eg: Marketing (five people), Product Management (four people), Customer Support (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. After you've considered your stakeholders and the general meeting structure (see the next section), you can start planning your meeting. Try to start planning at least a few weeks in advance; it can be difficult to get everyone in one room.

Gather ideas from stakeholders


Make a meeting plan. While working to select the right stakeholders, make a list of topics to cover and questions to ask (this will also help you refine your stakeholder list). You should have a different plan for each group you meet, although some of your questions may be the same across groups. You also need to decide how detailed the meeting will be. If you're only meeting with lots of people once (e.g., members of different departments, as above), you'll want to brainstorm ideas, but you probably don't want to spend too much time on the details during the meeting. In this case, if one of your stakeholders comes to you with the idea that "customers can track their orders online", you might just want to ask yourself why this feature is important, and if the stakeholder can think of a way to A site that does this very well. These questions should help highlight the huge differences between stakeholder expectations for the feature without spending an entire meeting on one announcement. You can then work out the specifics of the idea with the project team, and then work with stakeholders to ensure that the requirements you generate still reflect their original ideas. Let's say you're redesigning an e-commerce website and you're meeting with different stakeholders, scheduling a meeting for each group. Below is an example of planning a meeting with a group from the sales department.

Sales: meeting to collect requirements. Internal Service Participants: Jenny Bee, Tracy Kim, Joseph Arnold. Directors: Kevin Abernathy, Kate Parnell. Time limit: 2 hours. Objective: To understand the current sales process and identify issues and ways in which the network can better support that process. Background: We watched a PowerPoint presentation on the buying process, which provided a great background on how buying decisions are made. We also plan to speak with the customer service team.


Chapter 5: Business Requirements

Sales: Requirements meeting follow-up questions Sales process: How does the sales process differ for different product lines? Are there regional differences? Are there differences based on customer size (for example, small business vs. large enterprise)? How has that process evolved over the past two years and how might it evolve over 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 are the main visitors to your current site? Why? How are you? What do you want to achieve with your website? How does the web contribute to the sales process and/or sales conversion rate today? 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?

Looking to the future: If you're considering a future website, what can we do to better support the sales process? What current functions and features on the 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 are best for driving sales? 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 hold a requirements gathering meeting. Make sure to use common vocabulary. A lot of confusion can be avoided if the requirements gathering team agrees on a common list of terms and definitions. Are people using the system named users, customers, or clients? Are the terms Interaction Designer or Information Architect more familiar? To avoid confusion, take some time at the beginning of each meeting to explain the terms being used and what they mean. It is also useful to create some visual elements that help explain the relationship between different concepts or roles (see Figure 5.3). category












Figure 5.3 Diagram Showing Item Conditions and Relationships

A common vocabulary of outputs used in the project also helps stakeholders understand the process and the type of output expected. This can boost their confidence and ensure their time and energy are not wasted in a black hole of ideas. In general, if you find yourself defining the same words multiple times (especially if you find yourself defining them slightly differently each time), consider putting them into a project dictionary and sharing them with a division of the project team. Other examples of terms that should be clarified at the beginning of a project include:


Chapter 5: Business Requirements

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

Tent Makers and Publishers) widely mentioned key findings (feature details

visualization, wireframe, sitemap) and briefly explain the differences. Differences between different levels of information (such as our categories).

Information in Figure 5.3) The difference between needs and expectations

Listen to ideas and respond to needs. Stakeholders may issue a statement if they deem it necessary. Consider an example. commercial lawyer

"We need a blog on the site."


This is really an idea, not a need. Then, when the functionality of the blog is fully designed and implemented, it becomes a solution, but it is not necessarily the solution that best meets the basic needs of the stakeholders who are looking for it. If you ask why blogging is important, you'll likely get broad-ranging need statements like "we need to be relevant and accessible." Everyone is talking about blogging and I feel like we are behind the times, don't get them involved. ” “We needed to position ourselves as thought leaders, and blogging was a more personal way to showcase our expertise.” “We needed a better way to communicate and innovate with our customers, blogging brought us reviews, That way we can hear them." Each of these statements describes a valid need. Raising them will help you learn more about the drivers behind certain feature requests. This will help you achieve consensus when merging and prioritizing requirements.

Gather ideas from stakeholders


Merge request. After the meeting, organize the ideas gathered into broad functional areas. You'll notice a lot of overlap. This is a good sign that an idea has strong support from stakeholders. Eliminate redundancy and try to integrate a set of ideas that effectively capture stakeholder intent. In order to turn the ideas you've gathered into useful and actionable components of your project, you must assemble those ideas into requirements. Think of raindrops that form from clouds: they range from a large undefined cloud to many well-defined raindrops. So when you get an idea like "customers can track their order online," you have to translate that into clear instructions that define what the system should do. The resulting requirements should provide insight into the overall needs that need to be addressed. Map and integrate the needs of different stakeholders. Provide design guidelines, but don't be too specific about what it will look like

Completed Prioritized and monitored as an independent unit of work

As you start moving from ideas to requirements, be sure to ask your tech lead (or someone else who can represent your project's development team) to ask questions that will help guide you in estimating what you need when prioritizing later. workload. If you have a dedicated QA team member, that person can also ask detailed questions to consolidate requirements. To turn your tracking ideas into detailed requirements, ask questions such as "How accurate does the tracking need to be?" What information should be included in the tracking details? for

For example, should we provide updated lead time estimates? If they spend a lot of time on the project, you can ask such questions and discuss them in detail with the stakeholders who gave you the initial idea. If you do not have access to these stakeholders, you can work out the details yourself through project team discussions


Chapter 5: Business Requirements

You then discuss the requirements with the project sponsor to ensure your decision makes business sense. Table 5.1 lists the types of requirements that might arise from the idea of ​​monitoring and how you might include them. Table 5.1

Examples of business requirements

ID card



Shipment Tracking



Shipment Tracking

Shipment Tracking


Business needs

Orders can be tracked by

Encourage self-service

enter tracking code

During delivery (support



Users can track their packages.

Demonstrate innovation in efficiency

Age Tracking with GPS Truck

Fast delivery (competitive

or airplane


Users can view all orders from the past 365 days. encourage reordering

Self-service (sales, support services)

Note that in some cases requirements overlap, such as the first two requirements in the table - both are trace methods. You can live together in the same system as you can locate your package by entering the code through the GPS display. However, they are separate because GPS-related requirements may incur higher costs and should be prioritized independently of other features. When merging reports, consider business requirements that you think may conflict with user requirements. For example, a business requirement might be to collect personal information about 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 interrupt the larger task they're trying to accomplish. Identifying such conflicts can give you ideas that can help you meet business and customer needs. For a tracking example, you could suggest a "send to a friend" feature that captures email addresses and provides a convenient feature for users. This means that "send to a friend" can become a request to include in your prioritized mix. thoughts like this

Gather ideas from stakeholders


You can help meet business and user needs, making them ideal for recording. When you start thinking about design solutions to business problems, you're still in the overlap between the definition and design phases (see Chapter 4).

Design Definition and Development Potential conflicts between business requirements and user requirements are excellent things to examine in user research, and we discuss them in the next chapter. Through user research, you can also extend Table 5.1 with the full set of potential requirements prioritized in the project requirements list (shown in Figure 5.1 and discussed further in Chapter 9). Keep in mind that business requirements gathering is usually done concurrently with technical feasibility studies and user requirements gathering. Next post: Time to talk about users!


Chapter 5: Business Requirements


User Research Learn about the guests you invite to your party. There are many user research techniques that can be used throughout the project lifecycle to better understand your users or test their behavior on site versions. This chapter focuses 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 website (if any) using UX design best practices. Caroline Chandler

Basic steps in user research 1. Define your main user groups. This involves creating a framework to describe the key user types you are designing for. This allows 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 interviews and surveys, and provide tips on how to use them. 4. Confirm your user group definitions. You can use research insights to solidify your user group models. This model is then used as a platform for the development of more detailed tools, such as B. Personas (see Chapter 7). 5. Generate a user request. These are statements about the features and functionality that the website may contain. You add these statements to your business requirements (see Chapter 5) and prioritize them so that they become project requirements (see Chapter 9). This chapter covers the first three steps, starting with the first step: defining your user groups.

Define your user groups. Planning user research at the beginning of a project can seem like a chicken-and-egg dilemma (chicken or egg?). How can you be sure you're talking to the right person when you don't know who those people are? One way to get started is to create an initial or preliminary definition of the users you are designing for. This describes your website's primary user base. This can help you focus your research efforts on the right personas, demographics, or other variables that may affect the way users experience your site. Audience definitions can be advanced (define a list of each target audience) or detailed and visual (diagrams showing multiple types of users and how they interact with each other).


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. Their initial definition was based on the collective knowledge of business stakeholders and project team members about the types of potential users who might interact with the website. These definitions can be created by capturing some of the goals and attributes that different groups of users might have. Here are the basic steps for defining user groups: 1. Create a property list that will help you define the different users of your site (some of the most common are covered in the next section). 2. Discuss the attributes with those in your organization who are connected to the relevant type of user (for example, a 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 the user group on which your research and design will focus. In the next few sections, we'll take a closer look at some brainstorming techniques to help you gather, prioritize, and model these attributes (creating representations of different types of users to help you focus your research efforts).

List properties. A good place to start listing attributes is to collect and process any research or other documentation from your organization that might provide guidance for users. The following are some possible sources: Documents explaining company strategy, e.g. B. Company goals,

Petition information, marketing strategies and business plans, market segments and other demographic data of current customers

Collected by Marketing Department Previously conducted user research (see Table 6.1 for some examples)

Define your usergroup


Surveys such as customer satisfaction surveys and feedback forms. Customer Service Feedback Frequently Asked Questions

Next, identify the people in your organization who know your current or potential users. The number and kind of people you should be involved with depends on the type of project and its scope and schedule. If you know that the lifespan of your initial audience definition is likely to be short (for example, if you only use a month or two when planning your user research), you can include only two or three participants. If you feel that the initial definition may need to follow you through most of the design process (for example, if you can only use this definition until usability testing is done after part of the design), bring in more participants. Make sure you have cross sections for all views. Potential participants include marketers responsible for brands, segments, and campaigns; salespeople; product managers; customer service or support personnel; and coaches. It's also a good idea to involve project team leads and other business stakeholders in this exercise. Have the group think about the different types of prospects they tend to interact with. Then have them list some common attributes they encounter. Here are some examples that may vary: Primary goals as they relate to the theme of your site. Why

What did users come up with and what did they want to achieve? Common goals include, for example, purchasing an item, trading a stock, or answering a specific question. reel. It can be defined in many ways, but one way is by associating roles with

Main target users: job seekers, support seekers, potential customers, etc. Once you have more information about users, you can divide personas based on different needs or styles; for example, on an e-commerce site, customers might include bargain hunters and connoisseurs. Demographic information, including age, gender, household (single, married, children),

Income level and region. Experience, including education, familiarity with relevant fields

Technology (often referred to as technical understanding), level of expertise, and frequency of use (once, occasionally, often). 88

Chapter 6: User Research

Organizational characteristics, including the size of the company in which the user works

B. For their department, type of work (onboarding, freelance, middle management, executive), tenure (permanent or high turnover?), and mode of work (remote work, travel). Once you have a list of some of the most common attributes stakeholders use to describe potential users, you can start prioritizing them according to their level of importance, and then use this hierarchy to start defining and modeling groups of users.

Prioritize and define which of the above attributes do you think have the most impact on how and why different groups of users can use the 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 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 firm decided that part of its strategy was to engage laypeople who traded stocks both independently and online, and to encourage them to try trading new types of products, such as options and futures. The company plans to achieve this by providing user-friendly trading tools for those looking for hands-on learning in a safe environment. When discussing characteristics with business stakeholders, you may find that the following factors appear to have the greatest impact on how individuals use these tools: Current transaction frequency, especially directly online.

ing (eg quarterly, daily, several times a day). Those who only trade (e.g. once a month) may not seriously try new things, and those who already trade full-time may not find much value in tools aimed at new traders. But those who work as part-time marketers may also be interested in the company's tools. Number of product types traded: stocks only or shares, options, etc.

Futures Those who already trade all types of products may already like their own instrument, but those who only trade one type may be willing to switch to other types. Define your usergroup


Level of professional training (e.g. trade knowledge).

situation). Guidelines and glossaries to help you determine how much help you need with this process. Level of technical understanding (e.g. familiarity with procurement).

online banking and online transactions). This will affect how much security they need in terms of privacy and how advanced or simple the network interface needs to be. You can prioritize these attributes because they affect the types of users you target in your research. If a trader's location does not appear to have a real impact on how or why they trade, regional attributes can be removed from the list as considerations for research participants. On the other hand, if the importance of an attribute generates a lot of discussion, it might be a good topic for a survey or interview question (we discuss surveys later in this chapter).


Comparing two or more attributes can also help you prioritize. For example, if you create a graph with two attributes for an online retailer, you can see how the groups fall into certain ranges. Figure 6.1 is an example of an advanced user model that you can create using the two attributes Direct Trade Frequency and Number of Product Types Traded. It also shows user groups that may have arisen from the discussion.

Full-time Product Specialist

Experienced full-time generalist

Direct transaction frequency

second job as a trader

an extra income trader

active researcher

long term investor





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


Chapter 6: User Research

Figure 6.1 shows a dual attribute diagram for the Power User model. Creating this model together facilitates 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 intended to be a definitive model, nor does it define an exclusive user base (users may be long-term stock investors, or may be actively exploring other opportunities in options or futures). But it expresses how you understand different groups of users and how they might be motivated to use your site. A discussion of important attributes will also help you understand which attributes to focus on when recruiting users for research. If you determine that transaction frequency is important and prioritize those who currently have a moderate frequency, you should define what you mean by "moderate frequency" (eg, one to three times per week) and recruit your study participants accordingly. Speaking of research, let's talk about techniques you can use to engage users in your projects.

Can you only design based on user models? In the UX field, there is a debate about building user models before research, because it affects how you think before you have real user data, and because your project team or project sponsor may see models as a substitute for user research Taste. Using an unvalidated model comes with a greater risk that your assumptions are wrong. However, for projects with no user engagement at all, a well-designed model (validated by sources outside the project team, such as customer service groups or training groups) is better than not using the model during design.

Choosing Research Techniques Now that you have a general idea of ​​the user base you want to engage with, it's time to plan the next step: your recommendations for the amount and type of user research activities to be conducted during the project. Table 6.1 provides some information on the most commonly used research techniques and when they are most useful. Use this table as a reference to choose the best one for your project. The following sections describe each technique in more detail.

Choice of Research Technology


Table 6.1

Common User Research Techniques


what is it

if 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, by phone, etc.) varies.

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

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

context study

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

The "Gaining Access" project team had only a handful of people involved in the information. Reach out to your audience. Adapting to user environments can raise concerns about the safety and mental health of users working in unique environments such as hospitals. Ownership and job importance for intruUsers. For companies with relatively complex applications, tasks, or workflows. It might be easier to visit on a weekday.

12 requests took 3-4 weeks: 1 week for planning, 1-2 weeks for observation, and 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 more quantifiable results (e.g. "80% of your target audience say 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 context, but can't reach the user.

They are more interested in gathering information about preferences than actual performance.


Chapter 6: User Research

Get a suitable sample. Make sure the questions are worded appropriately so that you get the correct answer without leading the respondent to a specific answer.

Table 6.1

Common User Research Techniques (continued)


what is it

if useful


Typical Time Frame *

special group

Moderators guide participants in group discussions through questions related to specific topics. It focuses on discovering participants' feelings, attitudes and thoughts on the topic.

The team predicts that users' attitudes will greatly influence their use of the solution (e.g., whether they have had problems in the past).

Learn how to get the right information for your problem.

3-4 weeks: 1 week for planning and writing questions, 1-2 weeks for conducting focus group discussions, 1-2 weeks for analyzing and reporting results.

card sorting

Show participants items on the cards (such as topics) and ask to sort them into groups that are meaningful to them.

You are working on a content source page with many items and want to provide an efficient structure for your user group.

Decide which topics are best to include.

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

usability testing

Users try to perform typical tasks on a website or application, while moderators observe user behavior and in some cases ask questions to learn about them.

Existing solutions have been improved.

Select the appropriate task to focus on.

3-4 weeks for 10 users and medium procedures: 1 week for planning and writing assignments, 1 week for creating tests, 1-2 weeks for analyzing and reporting results.

Competing solutions are available for testing. You have a prototype that users can use to complete (or simulate) tasks.

Moderate groups effectively.

Determine the level of formality of the test.

*Typical timelines represent the time typically required from a user scheduling perspective. 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 the time required for recruitment, which can take one to two weeks after the screening questionnaire is prepared.

How much research activity can I include? Before deciding on any campaign, ask yourself how much money and time your team can invest in user research. Consider the following scenarios to understand your client company's interest in user research. Project managers and project sponsors may have more freedom in choosing research techniques if they are familiar with user research and interested in using it for a known purpose, such as ensuring that a website meets specific project goals


When you plan two or more activities or an activity that you will perform many times (such as testing a design, changing it based on your results, then testing the new design again). If no one in the organization is familiar with user research and has any 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 benefit to you, the project team, and the team. business stakeholders. Once the research results are obtained, the project team will have a better understanding of what the project does and what benefits the project can bring. Then, you'll have a good reason to include additional research later, if necessary. If you have room for at least two rounds of research, a good approach is to include a round early in the definition phase or design phase to better understand users. Then, add another round to validate the design before starting development. For example, for a task-based application, you can conduct user interviews prior to design and usability test the prototype later in the process. For content sources, you can also start with contextual research and then include card sorting exercises.

Research planning considerations When planning your research technique, consider the following: Why you are doing the research: What you want to learn from it Who you are recruiting: The primary user groups you described above How will you engage participants: Recruit people to participate and Screen them (i.e. ask questions to make sure they belong to your target user group). How to reward participants. What space and equipment do you need? What you cover: main topics How you collect information: who is involved and what tools they use. Chapter 13 covers all of these considerations as part of an in-depth look at one of the most common techniques used by UX designers: usability testing.


Chapter 6: User Research

Note For more information on task-based applications and content sources, see Chapter 2.

Browse Steve Baty for an article outlining the different approaches and how to choose between them depending on your stage of development, your information needs, and your flexibility in incorporating user research. It's titled "A Bite-Sized User Experience Study" by Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.

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

User Interviews User interviews are structured conversations with current or potential users of your website. These can take place over the phone, in person in a neutral location such as a conference room, or ideally in an environment where users expect to use the website. (The last situation is also great for contextual investigation, as described below.) Interviews can help you understand participants' preferences and attitudes, but should not be used to make formal statements about actual performance. If you're looking for concrete information about how people interact with a website, it's best to observe them using it (such as in contextual research) or ask them to complete tasks on the website (in usability testing). Website analytics can also give you insight into some performance information, which is especially meaningful when combined with interviews or queries that provide context for the data. Basic Flow For user interviews, the UX designer creates a list of questions designed to elicit the following information: Experiences related to the site or topic

Choice of Research Technology


Company brand experienced by participants. settings, e.g. B. Regarding the subject categories covered (for

source), the process to be designed (for a task-based application), or the marketing method (for a marketing campaign) A common goal or need for attracting users to your sites or those sites

Competitors Common next steps users take after visiting a company website Others who participate in the experience. For example, make a

Users tend to collaborate with other people as part of a larger goal they want to achieve? Is it possible for them to pass on information or seek input from others throughout the process? Any other information that would help confirm the hypothesis

So far, we've been looking at user groups - for example, whether the variables you talked about when creating the initial user model actually affect the way users experience your site. If more than one person is conducting the interview, it's a good idea to have a list of questions and a scripted introduction to keep the interview consistent. Decide ahead of time on the structure of the interview. If you choose a formal report, you will probably want a high-level structure in which the order of the questions varies little, with several supplements for each question. If the richness of the data is more important than consistency, you can opt for a semi-structured interview, where you start with a series of questions but let the conversation flow naturally, with the interviewer asking questions to further explore interesting comments (so-called probing). ). The length of your interview may vary; 45 to 60 minutes tends to be the best shooting range. It gives you enough time to build rapport and cover a wide range of issues without overwhelming the participants. User interviews provide a rich set of data that you can use to write the personas discussed 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 are simple, neutral, and open-ended. Some examples of leading questions are: What do you like about PseudoCorporation.com?

This assumes that the user enjoys using the site. Use this question only if you're also asking what you don't like about him. Did PseudoCorporation.com meet your expectations?

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

If the latter, why do you think they are better than fakes? This poses some problems: two questions are asked in one statement, and implicit opinions are imposed on the participants. A better question: Tell me about the last time you visited PseudoCorporation.com. why did you go there What do you remember from this visit?

If you're doing a larger, more formal interview, you may want to include some multiple-choice questions. However, in most cases, you won't get exhaustive information. When participants ask verbally, they can be difficult to understand, and they don't allow users to elaborate. Generally, these types of questions are saved for surveys or surveys. Run the tests with someone, perhaps someone in the organization who is not part of the core team. This will help you uncover issues that may not have been clear, and can also help you improve your schedule and process. If possible and the participants agree, record the interview so others can benefit from hearing the answers directly from the participants.

Choice of Research 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 might be using the site. For example, contextual studies in office applications require participants to sit at a desk. This approach gives you comprehensive information about the environment in which participants work, including the real-world problems users face, the types of equipment they use, the spaces they work in—especially how the size of the spaces they are in is affecting

How much (or little) privacy they have, how often they are interrupted, and how they use phones and paper (pay special attention to printouts they post or any notes they have handy). The settings you use with the mouse on the keyboard. this can have a big impact

Your design decisions, especially when designing tools that require a lot of data input. How they work with others in terms of collaboration and sharing.

resource. For example, multiple people using the same computer can affect how you design login 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 online solutions that compete with paper solutions! The observation time is combined with the talk time for the query. They can last from hours to days. If the participant cannot devote at least two hours, consider simply conducting the interview. During the observation, it will take some time for the participant to get used to your presence and behave reasonably and naturally, which doesn't happen after 15 minutes. Basic Process Prepare a 10-15 minute introduction for each participant. It should include the purpose of the investigation, a general description of what you will do together (observation and conversation) and 98.

Chapter 6: User Research

Information is used. This is also a good time to get consent forms signed and reassure participants that what they share will remain confidential. Start with some general questions about the typical participant process, especially those related to website design. Let participants know when you are ready to stop talking and start observing. Observation can vary from active to passive. In active observation, it is common practice for the participant to play the role of the master and you to play the role of the apprentice. The guru explains what he's doing as if he's teaching you his process. Active observation can often give you more information about why a participant behaves, but it can affect how the participant behaves. Through passive observation, you encourage participants to pretend you're not there. Your goal is to observe behavior that is as natural as possible. For example, when a participant talks to you, they are less likely to answer the phone or ask someone a question about a problem they are trying to solve. However, if you observe passively, you are more likely to notice it happening. Then, as part of the interview, you can ask about the reasons behind certain behaviors you observed. Both methods work fine. In general, if you don't have much time with the participants (for example, only 2 to 4 hours at a time), you can opt for active observation to provide the in-depth information you need. If you have a full day or more, passive observation can be a great balance of natural behavior and discussion. Once you have obtained information from your queries, you can search through vast amounts of rich data! How do you spot patterns or trends in your results? One useful approach is so-called affinity graph construction. There are many good resources on this topic, but here's a brief overview. A Quick Guide to Creating Affinity Diagrams Affinity diagrams are a technique for combining a series of disparate and independent elements, such as user statements or researcher observations, to form patterns and trends. Here are the steps for a simple affinity graph session: 1. Gather the research team and their notes.

Choice of Research Technology


2. Give each person a pack of post-it notes and have them write a statement on it and a short code that will allow you to associate that statement with the participant, such as B their initials. Focus on statements that appear to be relevant to the page design, whether specific (statements about a particular topic) or more general (statements that represent participants' attitudes toward the company or topic). 3. Have everyone put the stickers on the wall. If you're doing a big study, you need a big blank wall. Try to get one that you can visit for at least a few days. 4. Once you have all your notes ready, start grouping similar statements side by side. This part of the exercise can involve larger groups. This is a great way to start sharing your results. 5. As 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 is suitable for contextual studies, but can be applied to many other situations as well. For example, this is a great way to co-create categories for unsorted topics, allowing you to push the results of tab sorting to other levels of structure.

Patterns can be formed in a number of 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'll find in them: Goal: "I'm trying to resolve all outstanding issues before I leave today." Mental models (including showing how users

Mapping external experience to internal thinking): "I use this online tool as a briefcase for things I refer to a lot but don't want to carry around." Ideas and feature requests: "I want this let me do this undo that. etc. one time

I accidentally moved an entire folder and it took a long time to cancel. ’ Frustration: “I would ask the help desk about this, but half the time they won’t.” "

He also knew what the problem was. "


Chapter 6: User Research

Solution: "This took a long time, I just typed it out."

Read the list and use it throughout the day. Then, at the end of the day, I document the results. ” Value Proposition: “Here’s a tool that saves me a lot of time, so if

Change won't take it away! "

In-Depth Research The essence of contextual research is Hugh Beyer and Karen Holtzblatt's "situational design" (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.

A survey is a set of well-defined questions distributed to a large audience. They consist mostly of closed-ended questions (such as multiple-choice questions), which can be easily collected using tools that can show patterns between responses. Surveys are great tools when you want to report results in a more quantitative way than you might think (for example, "82% of respondents who work from home say they have fast internet connections"). Know the open-ended questions used in job interviews. But they can also provide you with qualitative information about user habits and preferences. In the field of user experience, surveys are often used to measure user satisfaction (for an existing website or application) or to create or validate user models, such as segments or personas.

Choice of Research Technology


Basic Process As with customer interviews, you don't want to ask questions that keep users guessing. Don't ask, "If you had feature X, would you use it?" Unlike interviews, multiple-choice yes/no questions in surveys are the best and easiest to retrospectively analyze. Additionally, participants can respond more quickly. Use surveys when you have genuine demographic questions, such as: Which of the following devices do you personally own? Select all that match. Computer gaming system for mobile phones such as Xbox, Playstation or Wii

or Multiple Choice Attitude Question: Read the following statements and select the degree to which you agree or disagree. Pseudo-corporate customer service suits my needs. I totally agree. I neither agree nor disagree. I disagree. i don't agree at all

In particular, questions like the second example are often used as a supplement to usability testing tasks. You can use this type as a follow-up question to find out if participants are frustrated with completing the task. Participants are not always comfortable expressing negative opinions, but they are often willing to express them when confronted with a ranking system. This illustrates another point: surveys are a great complement to other forms of research you may be doing, such as B. user interviews or background research. The combination of these two research methods provides a more comprehensive picture of users than either method alone.


Chapter 6: User Research

Browse If you want to have high confidence in your results and have the budget to do so, there are formal tools to measure user satisfaction in terms of user experience. These tools include tested questions to ensure they do not mislead or confuse the public. The most commonly used of these are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and Measurement Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi.ucc. IE

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

Use your preliminary model for this. How you answer the other questions here will matter. Which survey distribution method provides the best results?

If your main user base tends to cluster in one particular location, you can go there and set up a form for people to fill out a paper survey, and you'll probably get better results. If your audience is active internet users, online surveys with high numbers of participants may be the best choice. Or, you may decide that the best way to find your audience is by conducting telephone surveys of your current customer list. How much time do participants expect to spend completing it?

surface? If you're giving some kind of compensation, or if the person gets some other benefit from completing the questionnaire, you can usually make a longer questionnaire—one that might take half an hour to complete. If not, you need to keep it short to make sure people fill it out - think 5 to 10 minutes. Either way, be sure to give participants an estimate of how long it will take, and let them know your progress as you complete it (using page numbers like "2 of 4" or indicating the percentage of work done).

Choice of Research Technology


How do you know when to start analyzing data?

You can conduct surveys with a certain number of respondents or by a specific deadline, depending on priority. What tools will you use to collect and analyze data?

If you conduct a survey online, the tool you use to collect the data may have options for viewing and analyzing the results. If not, you need a way to get data into the tool of your 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 from the target group and hold discussions with them. The common goal is to gather opinions on issues related to the organization or its brand, such as past experiences, relevant needs, feelings, attitudes and ideas for improvement. Focus groups are a great technique for several reasons: Listen to different user stories. Open discussions are a great way to connect things

Wake up the storytellers in us all. When focus groups go well, participants draw on each other's stories and ideas, and recall situations they might not have had in more structured one-on-one interviews. The small group format and energy allow time to remember and share these stories. Know the relevant experiential differences. most people are born

Frequently exchange information and want to compare their favorite tools with others in their interest group. You'll often learn more about a competing site or service, or get tips on workarounds, resources, and support. Generate ideas. Even if you don't want to organize yourself

As a designer, you often get great ideas for new features or designs directly from your team or by understanding 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 a few key points about the collaboration process. What if you are

Groups can be a great way to fill in the gaps in your understanding when designing a process that involves multiple related roles and collaboration.


Chapter 6: User Research

how people communicate. For example, when working with content sources such as intranets, it can be useful to bring together the people who create, edit, and consume content to identify areas where the process can be improved. There is a lot of debate about using focus groups in UX research. This is not a good approach for usability testing (since users are working individually, not in groups), and sometimes the group environment can unduly influence what participants are saying. However, if planned and moderated properly, focus groups can yield many valuable insights into your designs. Chapter 13 discusses this further in the context of testing of concepts. Basic flow When writing focus group questions, consider the same techniques you use when writing user interview questions (see above). Start with some simple questions like "Tell me about the last time you visited PseudoCorporation.com. Why did you go there?" When participants are comfortable with you, the other people, and the topic, leave all brainstorming questions to the middle of the group . Assign blocks of time to each topic and stick to them. It was just that the discussion really started and the time flew by so fast! If you're concerned about time, put the most important questions in the middle of the topic list after participants have become familiar with the activity, but before potential time constraints arise near the end. Most of the logistics of a focus group are the same as usability testing. (Chapter 13 contains advice on screening, recruiting, and scheduling.) The main difference with a focus group is that you need a larger space and a table where participants can easily mingle with each other. Record six to eight people per 1-2 hour group session. Give everyone a name tag or business card to put in their place so everyone can call each other 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.

Discussion (eg, some of the points above).

Choice of Research Technology


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

current users of the Pseudo Corporation website, we have brought you together to hear about your experience"). How this information is used - in the design and

Confidential views. You, as the moderator, are there to hear their opinions and attitudes

experience. They want to feel like they can share honestly. Therefore, you demand personal honesty, but also respect for others on the team. There are many topics to discuss, so in a moment

Topic discussions to make sure you can cover all topics. This can then turn into a round of introductions for the group members, often with some ice-breaking questions. Your goal is to get everyone talking about the first question, even if they're just telling a little story. You can start with one person and work around the table, or let people respond naturally and then call out the names of the people who don't respond. You will usually sit at the table and answer the first few questions, and then when you feel the group is ready, you can use body language to communicate the questions to everyone.

Dive In: Body Language A good understanding of body language can be an excellent tool for facilitating focus group discussions or conducting user research in person. It helps you understand when someone is upset, upset, angry or threatened, so you can recognize when you're trying to make someone more comfortable or following up on a specific comment. The following book on the topic may take more than a weekend to read in full, but is designed for easy browsing: The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).

If you call someone who hasn't answered, be sure to repeat the question if they don't understand or are not listening


Chapter 6: User Research

Several statements from the Discussion. Also, avoid making disagreements seem like disagreements between two people. Don't say, "Bob, we haven't heard from you yet. What do you think of what Chris just said?" But instead (looking at Bob), "Bob, what about you? Your customer service at Pseudo Corporation How experienced are you with this?" As the moderator, you control the flow of the discussion and speak through the virtual microphone. You can control eye contact, speaking volume, hand movement and body posture. Most people are very aware of their body language, and these cues can be useful in signaling when someone is dominating a conversation. If the overly vocal participant doesn't understand the signals, use a gentle but firm statement, such as, "Okay, that's great, I want to share this thought with someone else." Anyone else having the same problem as Theresa? Move to a larger topic, verbally announcing that the previous discussion is over and that a new topic is about to start so that participants can free up their minds for the next topic. Finally, as the event draws to a close, a simple glance at the clock and a change of posture can signal that the conversation should be over. As with any other activity, be sure to thank the group for their time. Sharing findings with your team typically works in two ways: sharing findings based on the main topics covered or grouped into related categories, similar to background research. Affinity diagrams are another effective way to bring together different trends and attitudes and illustrate them to project teams.

Card sorting In a card sorting activity, participants (working individually or in small groups) are given items printed on cards and asked to sort them into groups that are meaningful to them. They either group them into the above categories (called closed sorts), or form their own groups and name each group themselves (called open sorts). By the end of the card sorting cycle, you should be able to identify common patterns in how people sort items, as well as common areas of confusion or disagreement.

Choice of Research Technology


A common reason for doing this is to create a sitemap for a website or to create a hierarchy of content, categories, and subcategories with items such as articles, documents, videos, or photos. This is why card sorting is a great technique when dealing with content sources. Note For more information on content sources, see Chapter 2.

Let's say you're working with a common type of content source: a corporate intranet. Many intranets tend to categorize their data by 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 develop a knowledge of where to find information. But for new hires or those who need information they don't normally use, it can be difficult to find information that may belong (or appear to belong) to multiple departments. For example, where can you find guidelines for signing contracts with new hires? It might belong to the legal department or the human resources department. Category cards help you find common patterns in how potential users categorize information, regardless of departmental route. Basic Steps Gather the items to include in the card sort. 40 to 60 is usually a good range. You need enough numbers to allow for the creation of potentially large card sets, but not so many that participants are overwhelmed (or overwhelmed when you need to analyze the results). Choose items that you think are easy to understand and don't contain unnecessary jargon. You can include some technical terms that you think your user group might know, but avoid too much "insider" jargon. If you use too many company-specific terms or acronyms (for example, "SUCCESS campaign" to increase sales), you're testing the effectiveness of your company's marketing and communications rather than building a general message hierarchy . For an intranet example, you might include vacation policies, 401(k) plan information, lease agreements, vendor agreements, nondisclosure agreements, and more.


Chapter 6: User Research

New employee orientation, health insurance information, and computer security guidelines. This list is a collection of well-worded items that can be categorized in a number of ways. You might have one actor that combines HR's hiring and leave policies, and you might have another actor that combines new hire policies and new employment contracts, and call it employee onboarding. Once you have a list of items, put them on cards that are easy to group and ungroup. You can print labels and stick them onto index cards, or print directly onto cards with perforations to separate into individual cards. Try having someone sort the cards and name the groups - for example, stick a post-it note on top of the stack of cards and write a name on it with a pencil. Ideally, your interviewees are people who are unfamiliar with the topic and activities. This will give you an idea of ​​how long the event is likely to take. If the test is longer than an hour, you may need to cut some cards! Once you have your deck ready, you can gather the right participants and give these 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 the group at any time when sorting. At the end of the event, name as many groups as possible. Some trends can already be seen by observing the conference. Others may require more analysis to come up with. There are various tools available for entering and analyzing the results of card sorting; many of them have tools that allow you to sort cards remotely (see the Card sorting variants section below for more information). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) provide remote sorting capabilities and useful analysis tools. Or, if you want to sort manually yourself, check out Donna Spencer's excellent table, done

Choice of Research Technology


Instructions are available at www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet. Variations of Card Sorting So far, the discussion has focused on card sorting conducted face-to-face with individuals and asking participants to name the categories they created. This is an open sort, meaning that the main categories are not given to participants, but can be named. This is a great approach when building a new navigation structure or making major changes to an existing one. In other cases, you might consider the following common variants of card sorting: Closed sorting. In a closed sort you provide the parent category

Participants also contributed to this. The results are relatively easy to analyze because you only have a small subset of possible category choices 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 actionable information to help you make taxonomy decisions. group species. Instead of grouping the items individually you can do

Use card sorting as part of a focus group activity to have participants sort items together. While the results don't necessarily reflect how a person grouped items, you can gain insight into how people perceive items and their organization by listening to them share activities they're completing and discuss the reasons for each placement. Distant species. Especially sorting with physical cards can be a fun activity

Used for group sorting. However, there are many great tools for personal online classification. This can also allow you to reach a greater number of participants or specific participants that you may have had difficulty reaching. The aforementioned OptimalSort and WebSort tools are two tools that simplify this type of online sorting.

Usability testing In usability testing, participants are asked to perform specific tests on a website or application (or a prototype thereof) to discover potential usability problems and generate ideas on how to fix them.


Chapter 6: User Research

If you want to gather information on how to improve your current page, you can run a usability test during the definition phase. Alternatively, you can do this on a similar site (such as a competitor's site) to see some potential opportunities for a more user-friendly solution. Most of the time, usability testing is performed as part of the design phase, ideally in an iterative cycle (design is created, tested, improved and tested again). We'll discuss usability testing in detail again in Chapter 13, "Testing Designs with Users." This chapter provides staffing and planning tips that can also help you with the activities discussed earlier in this chapter.

After Research After completing one or more of these user research activities, it's time to re-examine 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 any flaws in your user research because key groups were not included. If this shortcoming is identified early on in your research activities, you may have time to adjust and add another group of participants to the ongoing study to ensure you get the full picture. Using your new knowledge, you can modify your custom definitions to more accurately reflect the groups that should be of interest. This allows you to create more detailed tools such as roles (see Chapter 7) and create user requests for the list we started in Chapter 5 Requests. Follow a similar process to your clients - your work doesn't stop when you capture an idea or request. Drill down to basic needs and goals to make sure you understand them. Ultimately, this will help you design a solution that best meets the needs of all relevant user groups. In the next chapter, you'll learn how to use the insights gained from conducting user research to create a tool that can keep your user groups at the forefront of design and development: personas.

after research



Personas Find out the best way to put your team or customers 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, and whether they add value to the project. Some people wonder if they belong in that process. No matter where you position yourself, personas can be used to help your project team and your clients resonate with their users. Personas can provide validation for many parts of a project—business requirements, visual design, or quality assurance—providing insight into audience identities and their expectations and behaviors. Lars Unger


What is a role? Personas are documents that describe typical target users. They are useful to your project team, stakeholders and clients. With proper research and profiling, one can get a very clear picture of who is using a website or app, and possibly even how they are using it. UX designers often find creating personas a great empathy exercise. Well-crafted personas are often used as focal points when questions or concerns arise about how aspects of the project should be designed. You can take out your character and ask, "What about that?"

implement? or what it isthey will search in? While this process may not be as precise as testing functionality and design with real users, it can help you move your project forward until you're ready to perform more extensive testing. Josh Seiden (www.joshuaseiden.com) points out that there are two different types of personalities: Marketing-oriented people shape buying motivations. Interactive characters based on user behavior

This chapter focuses on interacting people.

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 around design and development decisions, so you and your team can move forward. How real does the character have to be? The answers are quite different. One persona document might suffice for one team, while another might create entire "living spaces" for user personas, giving them a deeper understanding of how they "live". You can even go to the extreme and create a custom presence presence that you can interact with to gain insight into online behavior. How you expand your personality is up to you. Roles can constantly remind your users. A helpful technique is to have your team members keep people in their workspaces. that's how they are

Why do I need to create roles?


They are constantly reminded of who their users are. When you share a cube with “Nicole,” a 34-year-old certified hand therapist from West Chicago, Illinois, you feel compelled to provide her with an experience that benefits her. If it helps, you can carry a printed copy with you while you sleep and let the osmosis fairy sympathize with your sleeping subconscious from one side across the pillow. The purpose of personas is to help you, your team, and/or your clients clear up some of the confusion that may arise when you are at a decision crossroads.

Finding information for personas An effective persona must accurately represent a specific set of users of your product or website. To achieve this goal, personas must be backed by research. Chapter 6 covers techniques for researching and modeling prospects to give your personas a solid foundation. But don’t see just one method as the 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 when creating personas: keep the real data, but let the personas be real people on the page. To see how one company achieved this, check out the case study: Messagefirst Personas Sidebar.

Creating Personas Once you've identified your audience and gathered data to support your personas, your next step is to put pen to paper and start bringing them to life. How many characters you need to create will vary. 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 how best to represent them appropriately.


Chapter 7: People

Case Study: Messagefirst Personas To create effective data-driven personas, Messagefirst (www.messagefirst.com) uses at least three different sources of data input, drawing on the following: Stakeholders. We interview them to find out who these people are and what their behavior is like. This is always there. Customer Representative. We interview people in the company who talk directly to customers, usually from sales/marketing and customer service. They each have their own biases, which we certainly take into account when documenting our findings. For example, the people who contact customer service most often are those who have too much time (often retired or unemployed), or who are so dissatisfied with a product or service that they actually take the time to contact you. customer. We speak directly to real users who will use or are using a product or service. This includes where possible. Sources of Customer Data. We review all available blog traffic, surveys and emails. People We Know We select a person we know who fits the person's original profile. This helps keep us grounded, ensures the person is credible and realistic, and allows us to turn to real people if we have further questions. This is very important for validation and is always included. Because every data input source we use has some bias, we use multiple sources to normalize the data. With data-driven personas, it's important not to expect how many you will have, but to let the data show how many there should be. When I analyze data, I look for gaps in behavior and activity. These gaps are discovered by individuals. Todd Zaki Warfel, President, Messagefirst

The example in this chapter is Nicolle, a 34-year-old certified manual therapist from West Chicago, Illinois. He happens not to be a driver and spends two to three 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.

Creating a Role


This short text tells you a lot about Nicolle, but as you can see in Figure 7-1, the real person contains a more detailed story about Nicolle. Note that the content is about Nicolle, not "written by" Nicolle. It's better to write your characters from someone else's point of view than trying to write in their different voices, especially if you're just starting out. Of course, as you become more experienced, you should do your research and find the style that works best for you and provides the most benefits.

Figure 7.1 The role of a fictional ACMEblue client

What information goes into the role? It is the type of information that your audience finds relevant and credible. The research data you gather should help you determine what's important to your customers, brand, and projects. Most roles you create will consist of a generic set of required content mixed with any amount of data, stats and other relevant information that can be considered optional as it varies from client to client, if not project Varies by project.


Chapter 7: People

Minimum Content Requirements When creating a persona, you need to provide enough information to grab people's attention and connect them to the people they're reading on the page. To help your audience understand what your persona does and thinks, be sure to include six key pieces of information: photo, name, age, location, occupation, and bio. The next few sections explain how to fill in the details for each item. Photos Photos are the first step (and real) in showing your personality. When choosing a photo for your personality, make sure the image doesn't look overdone or elaborate. Photos that look posed don't look the same as photos in a more natural setting. Personas seem to work better for photos taken in more natural settings, such as the photo on the right in Figure 7.2, which shows a person standing outside in winter clothes, presumably on their way to work. Make sure the photo matches the person's lifestyle! Installed

Natural Image 7.2 Natural-looking photos are more effective.

There are various photo sources on the Internet. Better options include iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com), and Stock.XCHNG (www.sxc.hu).

Creating a Role


Finding the right photo can really be a waste of time if you're not careful. When all else fails (or you have the time and budget), make your own! Name Simply put, you need to give the person a name. The photo you use will humanize the combination of research data and personality traits, and the name will be how everyone refers to you in discussions. Not only does Nicolle sound better than “30-something blonde working mom,” but she’s more memorable and relatable. Try not to make the names used by different people on the project sound too similar. For example, Nicolle and Noelle are easily interchangeable, so be aware of different names. While it may be tempting to use a colleague's or client's name, you shouldn't. If you use a similar or identical name to someone involved in the project, they can easily try to identify themselves as you. Choosing a different name can avoid awkward situations or hurt feelings. If you're having trouble choosing a name, some online resources can help: Baby Naming Sites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Social Security Agency Popular Baby Names: www.ssa.gov/

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

Another thing about names: Make sure your name is credible to the person. Nicolle is for a Midwestern mom, but Nicola or Natalia might be better for an Italian mom. Nor did there seem to be funnier or more lively names, like Bob the Builder. They make your characters look ridiculous and can reduce their value. Age While your research should identify the age range of your consumers, assigning a specific age to your persona will help add authenticity to the resume you write. A 21 year old student and a 34 year old working mom act markedly different!


Chapter 7: People

Location At first glance, location may not seem like an important piece of information; however, it is important to remember that cultural and behavioral changes may vary from place to place. 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 If you know your person has an occupation, you can identify with them by relating their everyday patterns. A person who works in therapy encounters a lot of people on a daily basis, whereas a drawbridge operator may not interact much with others. Biographies are compelling stories that make people real. Here, you provide the details gleaned from your research data and populate it with some "real people". That is, the date is very important to this person, but you don't want to just quote that information in broken sentences. Instead, you want to connect 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 inserting aspects of real people into your character is certainly not cheating. Nicole, for example, is based on statistics and the real behavior of a person with similar activities, beliefs and aspirations. Depending on your project, you may need to study creatures very deeply - sometimes, the more detail you have, the better. You won't feel compelled to compress your personality onto a piece of paper. Decide what best makes your character as real and meaningful as possible to the project you're working on.

Optional Content When using roles, you'll find that different projects require different sets of information to make roles more applicable. Minimum content requirements can also be considered the least common

Creating a Role


The denominator of most people you will create. In most cases, you'll weave some of these optionals into the core of your character. One of the optional things that can add value to your character is the level of education. Knowing a person's education level can help a lot

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 you. Salary or salary range. It's all about money and in many cases quantities

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 motto will your people proclaim?

but your own? Sometimes this can be a quick overview of the core of your human mind. Online activities. This can be difficult; there are many ways people spend money

their online time. Some pay the bills, some are deeply involved in blogging and social networking, and still others just use their computer as a plug-in device when they need to get work done. Given that so many projects have web components, this element is a judgment call. You need to paint a picture based on your research. offline activity. Does your person have hobbies? Is there anything else?

Information about what your life is like when you're not online? This element can be as inconvenient as online activity, but it can be just as important in affecting your personality. A key entry or trigger point for a client, brand or project. often very important

Find out how a person communicates with clients, brands or projects. Did the person learn about it through word of mouth, online reviews, billboards, television or radio, or online pop-ups? Is your role looking for a solution to a problem that can be solved by a client, brand or project? Using your statistics to understand this and incorporating it into your personality can help you understand how your customers engage.


Chapter 7: People

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

Do you have a computer? Does he use instant messaging, flickr, or a blog? Is the activity enjoyable or confusing for her? Would a very simple solution for beginners help her? Does she have an MP3 player or other portable device? Does he watch TV on a DVR or AppleTV or on demand? The list could go on and on. etc. Depending on your client, your brand, or your project, it may be important to recognize these and many other terms. social comfort. Given the development of social media and social networking

At work, it can be important to determine exactly how your people are involved in that particular area. Does she have a twitter account? If so, how many followers does it have? How active is she? Is she the leader? Does it use MySpace, Facebook, LinkedIn or other aggregators or online communities? Move comfortably. As the use of mobile devices continues to increase

In general, it's important to consider how (if at all) your character positions itself in the movement space. Motivation for using the client, brand or project. In some cases you may want to

Explain why the person wants to use the client, brand, or project. If her headphone cord keeps getting tangled in her coat and pulling out of her head, that might be a good reason to start thinking about new headphones. Real-world scenarios based on research data can help uncover key motivations that appeal to your personas. user goals. You may also want to know what this person is trying to achieve

Realize by client, brand or project. This can help gain insight into a person's drivers for their use. This is just a starting point. You can build your characters and present them in countless ways. If you're interested in delving into the world of personas, a good place to start is "The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web" by Steve Mulder and Ziv Yaar (New Riders, 2006) .

Creating a Role


Advanced Personas Once you understand the basics of creating personas, there are countless ways to enhance your documents. A simple one can usually cover most of your needs, especially if your project team just wants to have an empathetic understanding of your users. It usually gets more interesting when you introduce people to clients. In such cases, you will often find that you need to provide far more information than you have gathered for the basic role. Figures 7.3 through 7.7 illustrate some of the ways you can extend roles. Feel free to borrow these examples, remix and remix them to create something even better for your projects!


Consumers who know the brand

Personas and Scenarios (Based on Ethnographic Research) Personas are composite 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 would visit a brand website and what they would do there.

Joan, 32 Consumer insights help us understand our users - their motivations, goals and desires. To apply these insights to website design, we develop user personas and scenarios based on real-world context. This approach to design helps create rich experiences based on understanding customers, their motivations, desired outcomes, and behaviors. Specifically, the script answers three fundamental questions that must be answered before a website can be properly organized:

Fun-seeker's "I'm Loving This" "Young Sophistication"


start research

build experience

"Future Freshmen"

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

"Activate Response"

Feeling 5)&365

found it again

"Senior Researcher"

Optimize and simplify

"Grown in a Ditch"

Get things done practically "it just needs work"

Alice, 26 years old

Rachel, 42 years old

Erica, 47 years old

Greta, 59 years old

Figure 7.3 The main page (landscape) with a person overview. It provides an aggregated view of multiple roles and what they represent in the context of the overall organizational strategy. Courtesy of Will Evans.


Chapter 7: People


People and Scenes (Based on Ethnographic Research) Alice is a novice cook who wants to explore the world of food.


Especially food for kids, find new recipes on the internet and in magazines with friends. Their research tells more

She can support her family with no trouble

Fantasy becomes reality. she's still scared and doesn't do it

Find quick, easy recipes with essential ingredients

Tried too many new recipes. Her mother didn't teach her much cooking, and her friends weren't very experienced

Prepare (often) two types of meals: adults and children

Can also cook. Alice is a working mother of a daughter in Chicago. Both she and her husband work outside the home—she runs the office of a small insurance company.

Married Alice, 26 "Ambitious Beginner" x Generation

1 daughter, 5 tired, ambitious



She's very busy and down-to-earth and doesn't spend a lot of time cooking. Alice just wanted to make it quick and easy - even though since she started working out and trying to get back into marathon form after giving birth to Sophie two years ago, she often finds herself having to cook different meals for herself and her husband. She has worked with a handful of successful recipes that have worked for her, and many of the dishes she prepares are packaged and prepared from food.

Scenario Alice and Sophie are having breakfast together while watching Cartoon Network. This is where brand ads with brand names come in. Alice uses the stamp and thinks Sophie will choose the dish. She decided to check out the place after get off work. Alice has free access to the site half an hour before the meeting starts. The home page is clear and organized. She sees the main section of the page and links to interesting content, like the recipe of the day.

use the internet

Health awareness

cost sensitivity

She clicks on the recipe of the day. She loves the tips included - they make her feel like she can handle this recipe. Unlike other sites where he often gets lost, he likes clear navigation. She likes the practical features that go beyond what she sees in cookbooks, like the ability to find recipes based on what's in her pantry and tips on how to use produce. Alice discovers that she can receive a cookbook newsletter and clicks to subscribe. Signing up is so easy! Fill out some basic information and select the "Food Your Kids Will Love" newsletter.

She wanted to add more of her own touch, recreating dishes she loved at restaurants, like her all-time favorite chicken. Also, she wants to include more fresh vegetables in her meals, as she knows they are healthier. She prides herself on being a thorough planner and able to run a household on a tight budget. Her refrigerator and pantry are always well stocked. She plans her purchases to take advantage of special offers and coupons.

Find meal-friendly recipes and activities for kids. Find ways to spice up their favorite ready-to-eat meals. projects and initiatives. Improved navigation and information architecture. Improved login

A week later at lunchtime, Alice found her first brand e-newsletter: "Pizza, as easy as 1, 2, 3." Perfect - her kids love pizza and she usually buys them frozen. A link to Pizza for Beginners inspired her to see if she could make her own pizza. That link takes you to a pepperoni pizza recipe on something called "Pizza Wizard." He looked up the recipe and found it to be very simple. Only 25 minutes and 4 ingredients. He checks his kitchen to see what he has. She didn't have pepperoni or pizza sauce, but the "pizza wizard" suggested replacing them with something from her well-stocked kitchen: sausage and tomato sauce. Perfect! There is a link to the coupon. Neena prints out a shopping list based on the recipe, adds a few things she also needs, and heads to the grocery store. After returning from the store, Alice gets down to business. 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. She wondered if she should cook the topping first, but got the answer in the pizza FAQ.

Contextualized surrounding information, more targeted newsletters, recipe assistant, better coupon integration, meal planning. The "done" setting relies heavily on ready-to-eat foods, with relatively little added fresh fruit and vegetables. He spends more time looking at recipes than actually cooking

Figure 7.4 Audience persona (landscape). This detailed understanding of an individual encompasses a broader range of data, allowing for a more complete understanding of a user's goals, needs, and behaviors—all within a larger ecosystem. Courtesy of Will Evans.

Figure 7.5 Audience profiles and audience personalities (longitudinal). The Goals view on the left provides a high-level summary and shows the brands that three people interact with and associate with. The detailed descriptions on the right provide overviews and biographies of individuals, as well as information about their actions and motivations.

advanced people


Paul and Helen "I think we can fit everything in. I'm just not sure how much it will fit."

5 4

Helen's mother passed away a few weeks ago and they were cleaning the house. They're about to sell the house, but there are a few things that need to be sorted out first. The house also needs a renovation of the main bathroom.


- of en The basement is filled with things that Helen's mother has collected over the decades. She never throws anything away. For the past 20 years, she was the owner of newspapers and Time Magazine. Helen wanted to keep something. Most of the clothes, clothing and furniture were donated to Goodwill. Unfortunately, mom's dishes were mostly 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




Znati Ex led Perienc e C on Pric ve e Senior tunc pe sp Re M pu e adult type Tim tion C on eline t Main ss ajoer r L Siz ife es D E ecven lutte t Year Re rding pe Wast Rate in Bu ar s ds ine Cizena i O Rec am nlin ycline ac g 计数

This is the first time Paul and Helen have experienced such a thing. They don't even know where to start. You just want to keep it as simple as possible. They knew they needed a container, but weren't sure how much it would hold. They assume almost everything goes in the trash unless someone tells them otherwise. Their only concern is that the container is ugly. They wanted to find a company that wouldn't make their front yard look like a construction site or ruin the yard while delivering or picking up litter boxes.

Change: 24-65

Life cycle January




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 or no experience purchasing containers.

to tear

Get a container fast. Get rid of anything they don't keep or donate. Avoid damaging property in the process. Avoid unsightly containers. Dispose of container promptly after filling.

Frustration pain points Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Fragen Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

Available when needed. price. The seller leaves the property as he found it. It has the desired tank size available. Quick setup and pickup after contact. Online account access for scheduling and payment. The quality and cleanliness of the equipment. famous brand

Ŕ ŕ ŕ ŕ

First sticker shock. Not familiar with the process. I don't know what they don't know. Perform like-for-like comparisons between service providers

Is there anything inappropriate? How fast can you deliver and receive? Will the property stay the way it is? How does this work? Is a license required? How much will it cost? How easily can I reach someone if needed?

Figure 7.6 Personas of target audiences. This person represents the target age derived from survey data. The information it contains is broad and is directed at a target audience rather than a specific individual. This approach is useful when creating a business plan or client budget to allow for detailed persona research. Courtesy of Todd Zaki Warfel.


Amanda Stone


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



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



life cycle

main features

Manage multiple programs. Large and medium-sized enterprises. Medium quantity (50-2000 pcs order at one time). Multiple people share one role Heavy Excel program uses custom internal system as interface

tear Ŕ Ŕ Ŕ Ŕ

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

Other Applications - Excel - PowerPoint How do I run reports in all my programs? Ŕ Is there a way for Internet Explorer to get my credentials without calling Ecount? Is there any way to integrate ClientZone so that we don't have to constantly switch between different applications? Am I doing well?

Ac FT N c ew ou P n Cart Zod Rene quest t E Ad asys m Pain y Che c R Cu ep ks or rr enting tB al Peance Cu ople st om Soft Sy Stamm em Exce l




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


one try




dg i ow Kn






He uses the Account Zone a lot - several days a week. Since she runs multiple programs, she is very active year-round.

activities and interests


Change: 28-55





Account Zone really helped her issue new cards and ensure fast payments for program participants. The only thing it lacks is the ability to look at each program and all the programs it's running to see how things are going. Your client wants to monitor how well the program is doing. He is currently tracking it in Excel. In the end, he either sends the Excel file to his client, or sometimes exports it and sends a PowerPoint file with a nice chart. It would be nice if Account Zone had a way to allow it to generate reports on both individual programs and multiple programs.


Ŕ ŕ ŕ ŕ ŕ






setbacks and pain points

question -


Cannot display multiple programs at the same time. Reports cannot be run for multiple programs at the same time. Fix bug in cheat file "Smelly". It's unclear exactly where the problem is and how to fix it. Multiple steps across multiple apps is ineffective and it's easy to "lose" where you are. Multiple confirmation screens. Another username and password to remember. I'm looking for an email with their credentials.

Figure 7.7 Individuals in a target group. This role is a data-driven model. While Everyday Story is narrative, the rest is presented in bullet points, serving as a design checklist. Diagrams are used to convey a lot of information in a small space. Courtesy of Todd Zaki Warfel.


Chapter 7: People

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

Final Thoughts on Personas Many practitioners in the field of UX design 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 personas are based on solid research data and combined with a degree of personalized reality, they can fulfill specific needs that can have a very positive impact on the design process. Which side of the coin you end up on is entirely up to you. This chapter is not intended to influence your decision in any way. There are many articles on the Internet on this topic, and many experts are ready to give you their opinions. All of these resources can help you understand how a role might best fit your project. So look for it. Jared Spool, CEO and founder of User Interface Engineering (www.uie.com), also offers some insight on the topic: When teams interview and observe their audience, absorb and discuss their observations, and reduce When there is chaos, that value is created, and then they become human. What the team thinks at design time affects the final design. People's descriptions are just to remind you of what happened.

Jared's point is simple: by observing your audience, supplementing what you've learned with research data, and breaking it down into components, you should be able to create personas that inspire empathy and get your team on the road Get on track and build the best possible app, website or product. Ultimately, however, your characters will be like Santa Claus: they are only valuable if people believe in them.

Final Thoughts on People



User Experience Design and Search Engine Optimization The Essential Role of User Experience Design in Successful SEO Search engines are the bedrock of the interactive economy. Everything we do as "interactors" is ultimately connected to the world through Google, Yahoo, MSN, Ask, and the multitude of smaller search engines that make up the online search infrastructure. Information architecture is a key component 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 chance of appearing on Google. jonathan ashton


Introduction to SEO Simply put, search engine optimization is the process of developing and maintaining web properties to achieve and maintain optimal rankings in public search engines for target keywords. Search Engine Optimization (SEO), like a martial art, is a never-ending process of learning and working. Even masters can progress further by observing behaviors or learning methods. Search engine optimization is important as long as there are search engines and websites interested in selling something to searchers. SEO relies on improvement and impact in three fundamental areas: A key set of considerations for professional UX designers

May affect the infrastructure, technical and organizational principles of the website. Content and keyword issues related to optimized terms

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

Organizational structure of pages and links within pages from other pages. 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 ahead.

Why is Search Engine Optimization Important? Interestingly, even today we have to explain the relevance of SEO. Clients often understand that it is important for their website to attract targeted visitors from the organic search results of major search engines. Beyond that, however, most interactive marketers find it difficult to understand what SEO means. Data on global search volume is available from a variety of sources. However, the most important thing to understand is that no matter the source, the numbers are huge and year-over-year growth is always double digits. Most of the time, 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 (www.hitwise.com) reports that as of November 2008, Google and its affiliates (including AOL and YouTube) account for the lion's share of searches worldwide, accounting for nearly 72 percent of searches in the United States. 18%, followed by MSN and Ask.com at 4% and 3%, respectively. Internationally, Google is even more dominant: its market share exceeds 80% in many markets. NOTE For more information on Google's origins, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), 750 million people worldwide performed more than 60 billion searches per month in 2008, with more than 18 billion in the US alone. That is to say, 95% of Internet users use a search engine at least once a month, and the global average searches more than 80 times a month.

Beyond those mind-boggling 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. Review your website analytics and think about questions like: How much revenue would the website generate if traffic to strategic goals increased by 10%? How about a 100% increase? Or 1000%? SEO is a prerequisite if your website is not generating a lot of traffic through organic search. A small investment in SEO can go a long way, especially if previous engagement marketing efforts have focused on buying traffic through sponsored lists. We've seen sites achieve a 35 to 1 ROI on monthly SEO spend. If you pay search engine companies for traffic from sponsored listings, but don't invest in organic traffic, you really only have a 10% chance. Think about your own 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 continues could take several chapters. It can be said that Google is just getting started, and effective interactive marketing must have SEO as a key component of effective implementation.


Chapter 8: User Experience Design and Search Engine Optimization

An important core resource competency comes from comprehensive training. A professional who only focuses on his field forgets about everything else. That's why every interactive artist must spend at least a few minutes learning SEO. While there is no official guide, Google has been kind enough to provide some very important resources. If you're interested in improving your search engine performance, check out this link: Help for Webmasters/Site Owners: Search Engine Optimization:

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

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

www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf If that's not enough, immerse yourself in the newsletter and blog. Start at SEOmoz.org and browse. 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 that are firmly embedded in the Web 2.0+ world. The basic idea of ​​a search engine has changed little since the creation of World Wide Web Wanderer in 1993 to search the web and create the first web search engine. Essentially, every search engine has an application, or crawler, spider, or robot, that finds and follows links and sends a copy of the asset back to the database for it to review. The database is then analyzed using a proprietary search engine algorithm. These rules are used to index web properties and rank them according to their performance on the search engine's respective scorecard. This fairly simple process hides a lot of pitfalls for UX designers.

Technology, design and infrastructure on construction sites


Understanding these key relationships will help you see your site through the eyes of search engines. An optimized website is based on structures and techniques that facilitate the movement of search engine spiders. Likewise, many content processing decisions determine how well search engines evaluate the work of the results. So it depends a lot on the decisions made in the framework and discussions about how the content should be designed and curated.

Flash, Ajax, JavaScript, and other script-based content Today's dynamic and interactive web design is based on technologies that simply cannot meet the needs of search engines. There is a growing gap between what search engines can see and what designers can do. It is the user experience designer's responsibility to ensure that a strategic plan for a dynamic, design-intensive website is implemented so that both search engines and users have the best possible experience. Once you have a basic understanding of how search engines interact with this type of content, you can decide when to use them and where to fill in their weaknesses. It is entirely possible to create an optimized website that relies heavily on scripted content if the appropriate fees are determined early in the process. After a website is built and live, it is much more difficult to create static or crawlable content. Therefore, there is strong support for static content in the interest of ease of use and search engine indexing. It may seem like extra upfront work, but the return on investment is exponential. Flash Flash content is technically "indexed". Recently, there have been some advances in the ability of search engines to examine Flash files for text and links embedded in these materials. Have you ever seen pure Flash material rank high in search results even though this content is indexed? This may not be the case, as it is risky for search engines to open up to full Flash compatibility. It is assumed that search engines can fully view all links and text content embedded in SWF objects. What's stopping an unscrupulous (or "black hat") optimizer from inserting apples into an object's text layer while viewing


Chapter 8: User Experience Design and Search Engine Optimization

The oranges for a human user viewing fully compiled assets through a browser? How do you deep link into Flash material without fully compiling it? These fundamental loopholes will remain until search engines reach the level of AI that can recognize an image as an image of a horse without any accompanying text saying "this is an image of a horse". To create a search engine compatible Flash site, you need to add a static content layer that replicates the Flash content. In addition to search engine requirements, the static content layer is also critical to meeting usability requirements. Think of a search engine as someone viewing web content over a dial-up connection or reading a screen with a browser. These people may be the least common denominator, and the strategy behind your web development may ignore this tiny fraction of human users. However, by ignoring these few, you're also excluding 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 text words or spider links are not visible to search engines, your content will certainly not be visible through important search results. Static layers can be created in a number of ways. To satisfy search engines, the static content layer must mirror the Flash content. This is not an opportunity to show search engines anything other than what Flash has to offer; if you do, you're going against the spirit of the game and going straight to the dark side. The ideal way to embed Flash content into a static layer is to use a SWFobject, so that Flash and static content can be stored under the same URL. This allows search engines to find static content and allows browsers that support Flash to display animations instead of static content. If possible, avoid redirects to preserve the popularity of links to Flash content. Google Code provides a simple tutorial for implementing this simple JavaScript element at http://code.google.com/p/swfobject. There is another option that applies to the gray part of SEO. Cloaking may be a dirty word for SEO purists, but if you approach the following challenges from the right perspective, you can have your cake and eat it.

Technology, design and infrastructure on construction sites


By utilizing user agent detection, cloaking can detect search engine bots when visiting a website and redirect them to static pages for indexing. However, when a human visitor sees the same page in search results and clicks the link, the site recognizes that the user agent is someone using a Flash-enabled browser and serves that person the URL on a completely separate URL. Dynamic experience. The crux of the matter is the same as with the SWFobject approach: you need to show search engines exactly the same content in your invisible content that you do in your Flash content. Ajax, JavaScript, and other script-based content Ajax is a powerful Web 2.0 content engine that enables Web developers to create content without pages. However, search engines have many problems with Ajax, and good planning is required to avoid major mistakes. Ajax stands for Asynchronous JavaScript And XML, which shows how difficult the technology is for search engines. In principle, search engines can't handle JavaScript; the efficiency JavaScript brings to 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 first page loaded, and any script-loaded content that comes after the initial shell load is invisible 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 no-page content is invisible unless the text content is included in the pre-installed shell. UX designers need to ensure that the 3D modeling required to construct a no-page design also includes the requirement to preload all text and links into the page shell. Everything else and your cool design is invisible. Script-Based Navigation One of the most common problems hindering optimization is the use of JavaScript at the heart of site navigation. This is a very common situation and is a result of the operation of many web development and content management tools. Scripted navigation looks cool, so people are interested in using it. However, when JavaScript is the technology that controls web page navigation, it causes search engines to model links incorrectly


Chapter 8: User Experience Design and Search Engine Optimization

On-page relationships: You don't see the link structure of your pages at all. If search engines can't model the link relationships on a page, deep content won't be visible or gain true link popularity.

Content Management Systems Content management systems are designed for people's convenience - but many of these systems make it difficult for search engines to process their results. Here are some typical problems that can be avoided by using a solution or choosing a searchable content management system: Dynamic URLs. Search engines don't understand "pages" of content; they

Learn about the path to this content. Changing the path or URL to that content will cause search engines to clone the content unexpectedly multiple times. This situation can severely impact website performance. If your content management system has a system for creating a session id in the URL, then you could be in real trouble. Use sophisticated analytics for tracking instead of session IDs. Multiple URL paths. A typical problem when managing e-commerce content

The problem is that a product accumulates multiple URLs over its lifetime. Because in turn, search engines only know about content pages based on the URL where they were found, and soon this tool can search if a product appears in a category and is part of a gift basket and is a weekly special (blah blah blah), Follow a series of different links to find the same content. Every effort is made to ensure that each piece of content exists on only one URL, and that multiple paths are actually based on a single URL regardless of where the link is listed. Rely on sophisticated analysis systems for channel analysis. Accidental cloning. when you realize that piece

Although content should only be accessible via a single URL path, other conditions can easily be detected in a content management system, resulting in inadvertent cloning of content. Suffice it to say that the architecture must have only one URL path to point to a piece of content. endless loop. One consequence of the unintentional cloning problem is the lack of it

Last loop. Be careful not to use search engine spiders

Technology, design and infrastructure on construction sites


Potentially endless task of keeping track of "next" links in a calendar or similar. If the search engine spider can route the next link to the next calendar day, where it can find another next link, it follows that link to the next page, and so on. This can be avoided by using scripted links that search engines cannot follow, so the crawler can spend time on the content you want to crawl. Old URL structure. first thing in many site update projects

The task is to replace the old URL structure. The problem is that search engines may have already indexed the contents of these old URLs, and when you change all of them, you're effectively setting the index back to zero. Additionally, any deep links that have accumulated on the site over time point to the old URL structure. Be sure to keep as many old URLs as possible. When changing content management systems, you may need to change all URLs. If this is unavoidable, we strongly recommend that you give the old URL a 301 Moved Permanent status code and perform a one-to-one redirect from the old URL to the new URL. 301 redirects are the only redirects acceptable to search engines.

It depends on domain, directory and URL structure. If you're starting from scratch and branding restrictions allow, try picking a domain with a keyword or two in it. It's hard to find .com domains with good keywords these days. However, if you do, separate these keywords with a hyphen. A big part of how UX affects SEO is in the directory structure of your website. It has a crucial impact on how link popularity is distributed across the site. It's simply better. Redundant files in the directory structure must be avoided. Some content management systems automatically add a subdirectory. Avoid this as much as possible. This situation reduces the relevance of the entire page. Search engines understand the page hierarchy from the page's directory structure. So make sure your most important directories are at the top of your architecture. If your environment allows, use keywords related to parts of the page in the URL structure. Separate keywords and


Chapter 8: User Experience Design and Search Engine Optimization

Don't use too many keywords in the filename. Select the following: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure you have a redirect set up for http://site-in-question. com to 301 Moved Permanent redirects to http://www.site-in-question.com. When resolving webpages with and without www, search engines (notably Yahoo) index the content of both URLs, thus opening up the entire webpage to random duplicates. This condition can be extended if non-WWW third parties link to this website and this website contains a dynamic link structure.

Content: The King of the Past (and Present) and the Future While content creation is someone else's problem, the basics of website architecture go a long way toward making the right content available to search engines. As with all forms of keyword-driven search, you need to understand the actual behavior of the people you want to expose your search assets to. Search engines are still very "primitive" in that they rely on users to enter keywords to link them to elements more or less related to those keywords. Choosing the right text is critical to a page's relevance in the right context. Ideally, your SEO partner will provide you with a set of key phrase objectives before you begin, and will work with you throughout the wireframing process. If you don't have such a competent partner in your process, learn more about the Google AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) and check the actual search behavior of users in your category. Then spend some time reviewing that list to understand the terms your potential customers are searching for, and use those terms appropriately on your website. Search engines look for keywords in several places when analyzing a website. Optimization is all about making sure the right words are in the right places. By understanding the role of keywords in the UX design process, you can create the necessary framework for future success.

What: Former (and current) and future kings


Why is content king? This is the essence of what a website should offer. Search engines need textual content that they can see and index. Website visitors demand engaging content that deserves their attention. Bloggers and webmasters need linkable content. Without the right content in the right place, search engines cannot link the right visitors to your website.

Naming Conventions and Battle Terminology It is important that the target keywords are reflected in the taxonomy developed for the website. Using key phrases in the main structure of your website can make the entire website more relevant to what you're selling. If you sell widgets, think of your online product listing as a widget catalog, not a catalog. Also, use your keyword research to base your decisions on technical terms. For example, use "laptop" instead of "laptop" in the 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 basic metadata issues. There are tons of meta tags available, but only a few have much impact because all the rest are prone to spam. Related tags are: Page Title. Note that this is not- it's daytime, but the priest


Labels in the header. This tag contains the actual page title, consisting of the most significant 65 characters on the page. Think of the book title as a little sign on an old-fashioned library card catalog that says "Clements, Samuel" and indicates that all the cards behind the sign are Mark Twain's books. Every website page must have a unique page title. Don't stuff your titles with keywords, and make sure to put your most important words before your titles. target keywords. This tag has little effect on search<p>engine because it is prone to spam. The exception seems to be that Google AdSense syndication respects keyword meta tags, while Yahoo suffers in a very third way. target keywords</p><p>136</p><p>Chapter 8: User Experience Design and Search Engine Optimization</p><p>Must match the content of the page, and this tag is actually a good place to include potential typos. Each side should be different. meta description. As with page titles and meta keywords, make sure</p><p>Each page's meta description is unique. This description is only: a summary of what is contained on the page. Say, do not sell, about 150 to 160 words. This content is critical because search engines are likely to show it below links to your site. If a page doesn't include a meta description, search engines look for snippets of text or other content that contain the search keywords and display them in the results. Meta descriptions are more about usability than SEO. So make sure every page is properly tagged. Meta tag "Noindex". If you have pages that you don't want to include</p><p>Use noindex meta tags in search engine results. Just make sure that the pages you want to index don't accidentally contain this tag. title. search engine recognition title</p>
Top Articles
Latest Posts
Article information

Author: Dan Stracke

Last Updated: 06/04/2023

Views: 6236

Rating: 4.2 / 5 (63 voted)

Reviews: 94% of readers found this page helpful

Author information

Name: Dan Stracke

Birthday: 1992-08-25

Address: 2253 Brown Springs, East Alla, OH 38634-0309

Phone: +398735162064

Job: Investor Government Associate

Hobby: Shopping, LARPing, Scrapbooking, Surfing, Slacklining, Dance, Glassblowing

Introduction: My name is Dan Stracke, I am a homely, gleaming, glamorous, inquisitive, homely, gorgeous, light person who loves writing and wants to share my knowledge and understanding with you.