UX Design Guide - PDF Free Download (2023)

UX DESIGN GUIDE FOR

PROJECT

FOR UX DESIGNERS IN THE FIELD OR CONSTRUCTION

RUSS UNGER I CAROLYN CHANDLER

PEACH PRESS

The UX Design Guide: For UX Designers in the Field or Developers Russ Unger and Carolyn Chandler

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

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

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

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

Praise for UX Design Project Guide If Russ Unger and Carolyn Chandler were wizards, the Alliance would be after them for revealing their greatest secrets. Fortunately for you, they are not. Russ and Carolyn took knowledge previously known only to the most experienced UX project leaders and codified it for all to see. Now you can learn the secrets needed to run great UX projects. Jared M. Spool, CEO and founder of UI Engineering

Is there a book that tells you everything you need to know about user experience design? NO. Is there a book that takes you most of the way? Is now. Carolyn and Russ have created a solid foundation for planning and managing project projects. This is a must-have primer for anyone immersed in competitive methodologies, endless meetings, and all the moving parts of user experience design. Dan Brown, author of Communication Design.

This book is a fantastic introduction to designing great products for real people. But it covers much more than just design, it also covers everything related to design: project management, working with people and communicating ideas. Great SUV. Donna Spencer, author of Card Sorting: Designing Usage Categories

It is a practical, accessible and very human guide to very human action: working together with people to do great things for other people. Steve Portigal, Portigal consulting firm

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

iii

Acknowledgments Russ Unger This book would never have been near completion without the support of my family, friends, coworkers, and countless people who were total strangers to me before I typed my first few keys. My beautiful wife Nicolle, who voluntarily and consciously married a self-improvement geek, managed to double up as a parent for much of the writing of this book. Our daughters Sydney and Avery often pushed and brought back their comatose father to dance, sing and play Spore. Unconsciously, I thought that writing a book with a newborn at home would not be such a challenge. I quickly learned otherwise. And Nicolle rose to the occasion time and time again to rescue me and give me the focus I needed to complete this project. She is the heroine I trust the most; keeps our house orderly in the midst of chaos. She is the center of our world here and she releases us all too easily. Nicolle, along with Sydney and Avery, make me look like a good parent and I'm grateful for that. I live in a house with three girls and I can't imagine loving any of them for less than I can give. Carolyn kept me on track. There were times when it seemed like this project would never start or end. He always kept things moving, explored ideas and steered us in the right direction. The cooperation was great and I learned a lot thanks to it! It's definitely a great UX yin to my UX yang. Michael Nolan was our Acquisition Editor and was an excellent guide. Michael is honest and kind and really helped to make things go smoothly. Rebecca Freed was a juggler, managing every aspect of the book, keeping us focused, and often e-mailing each other late, late at night. Unfortunately, he often got almost instant responses from me! Linda Laflamme was our development editor, and as I got used to her Red Feather of Doom, it became quite clear that she was guiding me in the right direction, no matter how much I tried to drown her in broken thoughts and runs-of-the- the -mill of sentences. Leslie Tilley put the finishing touches to the words; Tracey Croom combined graphic, design and production elements; and the real book appeared. Steve "Doc" Baty read each chapter before it saw the light of day in the Peachpit offices. I often sent Steve chapters around 2am.

GRATITUDE

reported his comments at 5 am, which is no small feat. Remember, Steve is in Australia, but he's still impressive. It's hard to believe that without Steve's constant willingness to help and quick twists, this book would have been shelved. Brad Simpson (www.i-rradiate.com) took all the artwork I threw at him and turned them into beautiful, print-ready images while often juggling his own life with two teenage children and a busy work schedule. It would be easy for Brad to leave at any time, but he is a true friend who was interested in the project and wanted to support me. I'm not sure there are enough steak dinners out there to pay for the effort, but I'm going to work hard at it. Thank you Brad for dedicating many days off and late nights to support this. Mark Brooks has found me panicking several times trying to deliver messages that required a visual component beyond my time and/or capabilities. Mark jumped in and saved the day on more than one occasion and I'm grateful for that. Talented and generous, Mark is the type of person I aspire to be. Jonathan Ashton wrote an entire chapter for us on Search Engine Optimization. After talking to Jonathan for 5 minutes, I knew he was the right person for the job. His chapter alone is a great reason to buy the book, and it was great to have him on board. Jono Kane jumped in at the last minute and at the last minute. Jono is a web developer, interaction designer, and prototype developer at Yahoo and has been invaluable support and help with Chapter 12. Lou Rosenfeld really helped get this ball rolling. In addition to co-authoring O'Reilly's Information Architecture for the World Wide Web, Lou is smart, friendly, approachable, and always willing to help others in our field. It will be hard to find many people as generous to themselves as Lou. Christina Wodtke helped me introduce myself and make contacts. Without Christina, I'm not sure where we would be today, but I probably wouldn't be "in print". In addition to being a "must-read author", she is a person who is always willing to give advice and information. Many UX designers owe much of their expertise to Christina's tireless efforts to expand our horizons through constant innovation. GRATITUDE

Will Evans and Todd Zaki Warfel generously provided high-quality materials that you can use as templates for your own materials. They were true brothers, giving their time and talents without question or concern, often at the same time. They are great members of our UX community, the ones you want to meet and work with, and I'm lucky enough to be friends with them. I certainly cannot repay my debt of 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 have been good friends, true supporters, and believers to me. I'm lucky enough to write these names together as a list of people I know, and I'm a huge fan of everything they do. Your support has been an invaluable benefit to me in everything I do. These wonderful people went out of their way to help me, generously sharing their comments, anecdotes, and resources, for which I thank them with all my heart: Tonia M. Bartz (www.toniambartz.com), Chapter 7; Steve "Doc" Baty, (www.meld.com.au), Chapters 3, 11, 14 and "A Quick Guide to Meetings"; Mark Brooks (www.markpbrooks.com), chapters 3 and 11; Leah Buley (www.adaptivepath.com), Chapter 11; Dave Carlson (www.deech.com), Chapter 11; Will Evans (www.semanticfoundry.com), chapters 7, 10 and 11; Christopher Fahey (www.behaviordesign.com), Chapter 14; Nick Finck (www.nickfinck.com), Chapter 10; Jesse James Garrett (www.adaptivepath.com), Chapter 10; Austin Govella (www.grafofini.com), Chapter 11; Jon Hadden (www.jonhadden.com), Chapter 12; Whitney Hess (www.whitneyhess.com), Chapter 11; Andrew Hinton (www.inkblurt.com), Chapter 10; Gabby Hon (www.staywiththegroup.com), Chapters 3 and 11; Kaleem Khan (www.uxjournal.com), "A Quick Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), Chapter 14; Livia Labate (www.livlab.com), Chapter 7; Michael Leis (www.michaelleis.com), Chapter 11; Troy Lucht (www.ascendrealtysolutions.com), Chapter 14; James Melzer (www.jamesmelzer.com), Chapter 10; Matthew Milan (www.normativethinking.com), Chapter 7; Chris Miller (www.hundredfathom.com/blog), "A Quick Guide to Meetings"; Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), chapter 11; Stephanie Sansoutie (www.linkedin.com/in/smsansoutie), Chapter 11; Kit Seeborg (www.seeborg.com), Chapters 3, 11 and "A Quick Guide to Meetings"; Josh Seiden (www.joshuaseiden.com), Chapter 7; Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and "A Quick Guide to Meetings"; Samantha Soma (www.sisoma.com), "A Quick Guide to

GRATITUDE

Meetings"; Donna Spencer (www.maadmob.net), Chapter 7; Jared M. Spool (www.uie.com), Chapter 7; Keith Tatum (www.slingthought.com), Chapter 12; Todd Zaki Warfel (www.messagefirst.com), Chapters 7, 12, and 14. I would also like to thank Andrew Boyd, Dan Brown, Tim Bruns, Christian Crumlish, Bill DeRouchey, Brian Duttlinger, Jean Marc Favreau, Hugh Forrest of SXSW, Peter Ina , Alec Kalner, Jonathan Knoll, Christine Mortensen, Steve Portigal, Dirk M. Shaw and Paula Thornton as well as the folks at Manifest Digital and everyone at Draftfcb. It's inevitable that you've left someone out, and I hope you don't take it personally. There are a large number of people in the "crowd" that was obtained, and I tried to keep track of everyone. If I missed you, let me know and I'll find a way to fix it! Finally, it should be noted that without organizations such as the Institute for Information Architecture, the Interaction Design Association, and others, it would not have been possible for me to connect with many of the people mentioned. If you are interested in the field of UX design, get to know these organizations, join them and get involved!

Carolyn Chandler Many of us dream of writing a book at some point in our lives. Without Russ, I don't know if I'd ever have the motivation to jump in and do it. Their energy and enthusiasm helped us find the right people at the right time, from the Peachpit team to UX industry leaders, all of whom have had a huge impact on what you see on these pages. He is truly one of the great liaisons in our field, trying to connect people day and night. Also, I think he posts more tweets in a day than I have since joining Twitter. Russ thanked the many people who helped us tremendously. I won't repeat all these names, except for Steve Baty, who read all our chapters in whatever primitive form we could throw at him and still managed to sound enthusiastic at 2am (his time). John Geletka also provided thoughtful commentary and intriguing discussion with spark and perspective that spans multiple disciplines. And of course the Peachpit team; I will never forget the first chapter of Linda Laflamme. It wasn't nice (although he made the suggestion tactfully). she patiently

GRATITUDE

VIII

guided me through the edits and helped me refine a flow that was initially better suited to writing one-off tech papers than an entire book. Now I even occasionally add transitions in my informal conversations with colleagues! Speaking of which… Christine Mortensen, aka Morty, was my partner in crime visually. The icons and diagrams you see in my chapters are the result of her hard work and I know how much because she and I have worked on many of the same projects for clients while trying to meet chapter deadlines. Morty is one of those visual designers who can really put his feet up in visual and interactive design, happily collaborating with everyone on a project and bringing concepts to life. She is characterized by integrity and focus on quality, which makes working with her a pleasure. It's an honor to have her as a partner in this regard. A huge thank you also goes to everyone at Manifest Digital who have given me tremendous support over the last few months. Jim Jacoby brought a special mix of business insight and UX perspective, with his trademark Zen calmness that helped me get through some stressful moments. Jason Ulaszek is one of the most enthusiastic people I know in the field of UX and has endless knowledge of tools and techniques; I have no idea where there is room for everything! Additionally, Brett Gilbert and Jen O'Brien provided valuable insights into some of the many roles that UX designers work with. Thanks also to the members of the Manifest UX team who provided me with inspiration and patiently listened to my constant references to the "book" progress: Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. Working with you is a constant joy. I appreciate your humor and perceptiveness every day. To my fellow Interaction Design Association members, thank you for sharing your experiences and being an active member of the UX community I love. In particular, I'd like to thank Janna Hicks DeVylder and Nick Iozzo, who have been instrumental in the development of the Chicago branch and who continue to find new ways to grow a vibrant network of smart people. Finally, I want to thank my family, friends and Anthony who patiently endured my disappearance and checked if I was still alive. You have plenty of rainy checks to cash and I can't wait to spend them with you!

VIII

GRATITUDE

Contents INTRODUCTION

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

CHAPTER 1:

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

About UX designers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Where UX designers live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Let's Get Started! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 CHAPTER 2:

Ecosystem project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Specify the site type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brand Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Marketing Campaign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Content source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 task apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 E-Commerce Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-learning applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 social apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Choose your hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Information architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Research User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you can or need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Creating a user protection network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

putting it together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CHAPTER 3: Suggestions

for consultants and freelancers. . . . . . . . . . . . . . . . . . 39 Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Creating an application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CONTENTS

Front page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Change history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Design Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Delivery items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Property and rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional Costs and Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Project prices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Confirmation and Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Work statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 CHAPTER 4: Design

Goals and focus. . . . . . . . . . . . . . . . . . . . . . . . . . 56 Consolidating project goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

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

Understanding the purpose of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Approaching a waterfall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Modified Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 How does concentration affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 CHAPTER 5: Business

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Understanding the status quo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Heuristic analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Collect ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Summary of Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Gather relevant stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Create a meeting agenda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Requirements meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Run meetings effectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Merger requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

CONTENTS

CHAPTER 6: User

Investigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic steps in user research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Create attribute list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Prioritize and define. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Selection of research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How many research activities can I include? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Interviews with users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Surveys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Focus groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Card sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

After investigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 CHAPTER 7: People

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Who are the people? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Why would you create Personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finding Information for People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Creating Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.114

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

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

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

Site technology, design and infrastructure. . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript and other scripted content . . . . . . . . . . . . . . . . . . . . . . 130 Content management systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, directories and URL structure Everything matters. . . . . . . . . . . . . . . . . . . . . . . . 134

Content: Eleven (and current) and the future king. . . . . . . . . . . . . . . 135 Naming conventions and fighting jargon. . . . . . . . . . . . . . . . . . . . . 136 Metadata, headings and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

CONTENTS

Part your hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Using sitemaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Update your content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other content issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Link popularity explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Typical Link Popularity Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Links in the footer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Links in content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

System game. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat vs. Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Spamming with targeted keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Clone and Gateway Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Spamming links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

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

From definition to design. . . . . . . . . . . . . . . . . . . . 144 Developing and visualizing functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Basic storyboard process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitating the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Maintain Good Tension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Development Ombudsman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Conflict management when prioritizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

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

Maps and workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is a workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Trading tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Basic elements of sitemaps and taskflows. . . . . . . . . . . . . . . . . . . . . 168 page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Page Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Decision point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Connectors and Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Careless connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

CONTENTS

Poorly positioned and irregularly placed objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Misplaced text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 No page numbering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 A simple sitemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Advanced sitemaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Breaking the Sitemap Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Task taking goes to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Belts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 CHAPTER 11: Wireframes

and Annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a skeleton? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What are annotations?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who uses skeletons? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Creating a skeleton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Trade tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

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

Exercise: design the skeleton of the home page. . . . . . . . . . . . . . . . . . . 195 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Results: Home Page Wireframe Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When Wireframes Grow and Find Their Own Way in the World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Continuing Design Exercise: Which Design Is Right? . . . . . . . . . . . . . . . . . . . . . . 201

One last note regarding the presentation of the mock-ups. . . . . . . . . . . . . . . . . . . . . . . . . 202 CHAPTER 12: Prototyping.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What is prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How many prototypes do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Paper prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital Prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe and Realistic Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML and WYSIWYG editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional Prototyping Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

CONTENTS

XIII

Work with the developer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Examples of prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 What happens after a prototype is created? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 CHAPTER 13: Design

User testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Concept exploration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Tips for exploring visual design mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Usability tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Choosing an approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Planning Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Writing discussion guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Facilitating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and presentation of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Creating Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 CHAPTER 14: Transition:

From design to development and beyond. . . . . . 247 This is the end…. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Visual Design, Development and Quality Assurance . . . . . . . . . . . . . 248 Testing the project with users (again). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10, 9, 8, 7, 6, 5, 4, 3, 2, 1... Go! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Personal Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Network Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Post-launch actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post-launch analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Testing the project after running with users (again, again) . . . . . . . . . . . . . . . . . . . . . 255

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

XIV

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

CONTENTS

Introduction Why we wrote this book Welcome to the UX design guide. Somewhere there's a user experience design student who can't sleep wondering what it's like to work on a real project at their new company. On the other side of town, there's a visual designer with a lot of design experience who's looking forward to taking on the new responsibilities of defining the user experience for his site. These are two people at different points in their lives, but with a similar need: to understand how to integrate user experience practices within the context of a living, breathing design. Our goal in this book is to provide the essential tools and context to help you use UX tools and techniques in your work teams. As you'll see in many of these chapters, we're not trying to be all things to everyone, but we're trying to give you the basic information and knowledge you'll need to accomplish the many tasks you'll have. Will be assigned as a UX designer. In addition to our own examples, we provide you with examples that will help you identify ways to develop basic materials and allow you to combine information and create something newer, better or even more suitable for your purposes. We hope we've done a decent job expressing that this is a pretty good approach for UX design projects. We are nothing more than a constant attempt to learn and improve (whatever we do) with each iteration. Therefore, we are in this area to some extent. A word from Russ As a mentor at the Institute for Information Architecture (www.iainstitute.org), I've noticed a pattern among the people I've worked with: most have struggled to find a job or haven't met the expectations of potential employers. Some had outstanding backgrounds, but not always enough practical application of their UX design skills in a design environment. The same themes ran through many of the conversations I had at the Information Architecture Summit (www.iasummit.org) in 2008.

ENTRY

The idea for this book, which deals with many of these common problems, began to take shape. I don't remember whether Carolyn or I sent the first e-mail, but I know that in her I found a willing and able co-author who helped me refine the intricacies of the idea that eventually became this book. A word from Carolyn For many years I have been lucky enough to build and manage UX teams. I say "lucky" because I believe that UX designers generally have the perfect balance of qualities that make them just plain fun to work with, combining right-brain intuition and left-brain logic. As I interviewed to build these teams, one thing really caught my attention: related background like human factors or communication design is a great indicator that someone is involved in UX design, but it's not a number. an indicator of whether someone will be a good fit for a team or project. Equally important, if not more important, is the person's ability to have a consultant's mindset. This means a positive attitude, striving to understand and include others in the project, and above all, focusing on making a real impact on users and customers. This mindset means taking the time to understand the perspective of other roles in the project, presenting cases and making compromises when necessary. It takes experience and effort to solidify this mindset, but having an open mind, a solid foundation, and a good set of questions (with the courage to ask them) can go a long way. This book may not have all the "answers," but it does have questions to ask to help you find them.

Who Should Read This Book The UX Design Guide provides a comprehensive introduction to UX design in the context of a project. Anyone interested in UX design should find something for themselves here. We focus specifically on the following groups: Students taking UX design courses (such as Human-Computer Interaction or Interaction Design) who want to supplement their coursework with information on how to apply what they learn to real-life situations where communication and collaboration are essential.

XVI

ENTRY

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

THEN YOU MUST READ...

Define user experience design and find out what attracts people in this field.

Chapter 1: Tao UXD

Ask questions that are important to answer before starting the project (or at least before starting work on it)

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

Start everything with smooth meetings, clear goals, and well-understood acceptance points

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

Define design requirements that are clear and prioritized, drawn from stakeholders and business users.

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

Get to know your users and represent their needs throughout the project

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

Select and apply tools and techniques that allow you to quickly present visual ideas to your design team

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

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

Chapter 8: User Experience Design and Search Engine Optimization

Communicate and develop your project with the design team as development begins

Chapter 14: Transition: From design to development and beyond

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

ENTRY

XVII

Note on methodology There are many approaches and methodologies. We are not in favor of one approach at the expense of the other. Our goal in this book is to focus on the steps that are common to most projects: defining the needs of the project, designing the experience, and developing and implementing the solution. The degree of overlap between these steps will vary greatly depending on the design approach used (see Chapter 4 for more information). For the most part, our framework follows a flexible, linear approach where the definition stage comes first, but at each stage we use facilitation and design techniques where they are most useful.

What This Book Is Not An Encyclopedia of All Techniques. The field of UX has a huge number of creative people who are always trying new approaches to design problems. Including all these approaches here would result in a much larger book that would quickly become obsolete. We have included here the most commonly used techniques, practical aspects of UX design. We have tried to provide enough information to intrigue you and allow you to communicate actions to other members of the project, including the basic process for each technique and additional references to books or websites to help you implement them as you choose your path. A guide to being a project manager. Good project management (including setting and tracking project goals, schedules, and budgets) is key to the success of any project. We do not discuss the details of how to be a project manager or how to choose a specific project methodology. We discuss the skills that a UX designer brings to a project that allow for its effective implementation, such as facilitation and communication, as well as the ability to explain and maintain focus on the goals of the project. These skills will help you become a project management partner. The only or perfect process or methodology to follow. We don't have all the answers, nobody has them today. The field of UX design is relatively young and we are all working to improve where we are. You'll probably find this trial and error, tweaks and improvements, and feedback

XVIII

ENTRY

from others will help you adapt the process to your needs. When you find something you like, share it! Please let us know!

How to use this book There are many great resources for UX designers. We cover the topics extensively here, but we've provided references that will allow you to explore the topics on a deeper level, depending on how much time you're willing to spend on them. To help you understand how much time each command usually takes, we've broken them down into three main categories:

The navigation links indicated on the surfboard are shorter features (usually available online) that will take 5-30 minutes to read.

Snorkel Diving Talks are longer online articles, whitepapers or short books that take anywhere from an hour to a weekend to read.

Deep Diving Helmet Calls are longer books that will probably take more than a weekend to read; provide a detailed description of the topic.

ENTRY

XIX

This page has been deliberately left blank

Tao UXD Curiosity meets passion and empathy. It's important to keep asking questions. Curiosity has its own reason for being. It is impossible not to be amazed when we contemplate the mysteries of eternity, life, the wonderful structure of reality. It is enough if we just try to understand this mystery every day. Albert Einstein

The sense of curiosity is the original school of nature education. smiling grandmother

Passion and purpose go hand in hand. When you discover your purpose, you will usually find that it is something you are very passionate about. Stefan Pawlina

The great gift of humans is that we have the power of empathy. meryl streep

In short, this chapter is about you and others who are 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 what's stuck in your throat. First of all, you want to know what makes people tick. You don't see things in black and white; There are tons of shades of gray to discover! Sure, he can drive his peers crazy at times by always volunteering to be devil's advocate, but it's not like he can help but try to look at the other side of the coin. You are a lucky man! The field of user experience design attracts curious people who are comfortable working with many shades of gray. We look for role models and develop ourselves in terms of organization and structure. We connect the dots. We tirelessly chase the next piece of the puzzle, and when it's solved, we look for ways to make it better! We can be analog or digital. We are at home with pencil and paper, whiteboards and dry-erase markers, sticky notes and Sharpie pens. We speak in terms of Visio and Graffle, and we live in a world of boxes and arrows connected across the many screens of our computers. We're not just curious. We are passionate! Our passion is generating ideas and facilitating discussions. We are passionate about creating things that matter to those who use them and those who create them. Oddly enough, we are most proud when something we create is so good that people don't realize how good it is. And of course we have empathy. We can feel it deep in the core of our being when we encounter bad experiences. Even worse, we immediately try to find solutions to solve the problems. We know what it's like to receive an unexpected response to a seemingly simple request, and we don't like it! We don't want users, people like us, to have to endure the confusion and feelings of inadequacy that often go hand in hand with bad experiences. 2

CHAPTER 1: TAO UXD

When you combine this near-constant childlike curiosity with an unparalleled passion for "doing what we do" and a sense of what others feel, you get a vibrant community of professionals who speak freely, ask questions, share solutions and be wrong, all in the name of getting right. Welcome to the community of UX designers.

What is user experience design? There are many definitions of user experience design. After all, this is a field that thrives on defining things. It's true that sometimes we don't do very well at "defining the damn thing" when it comes to the different parts of the whole, but at least we know what the whole is. In this book, we'll focus on two definitions in particular: the broader meaning of UX design, and the definition we'll use in the context of this book.

Broadly understood, user experience design is the creation and synchronization of elements that affect the experience of users with a specific company, with the intention of influencing their perception and behavior.

These elements include things that the user can touch (like tangible products and packaging), hear (ads and audio captions), and even smell (the smell of freshly baked bread in a sandwich shop). It includes things that users can interact with beyond the physical, such as digital interfaces (websites and mobile phone apps) and, of course, people (customer service reps, vendors, and friends and family). One of the most exciting developments in recent years is the ability to combine elements affecting these different senses into a richer, more integrated experience. Smell-o-vision is still a long way off, but otherwise the products continue to blur traditional lines.

WHAT IS USER EXPERIENCE DESIGN?

Don't forget the tangible While we focus on the digital aspects of the user experience, these kinds of interactions don't happen in a vacuum. When designing your digital products, be sure to include the tangible effects of the experience. The environment your users work in matters, as do the physical products — screens, keyboards, and other input devices — that affect how users interact with your design. Chapter 6 offers techniques to help you understand the influence of context. Also, don't forget about other points of contact between the product or company and those who interact with it. After all, a company's brand is influenced by many things, and the brand experience doesn't end on a computer or mobile screen. The best possible website design can't make up for poor customer service or provide the satisfaction of well-designed packaging once the product is delivered.

Figure 1.1 The modern classroom experience combines analog and digital.

CHAPTER 1: TAO UXD

Digital applications are increasingly influencing tangible experiences such as classroom learning. Similarly, experiences that were once individual, such as choosing a home karaoke system, are increasingly being reinforced through social interaction.

Figure 1.2 Online reviews have a big impact on consumers.

Our approach As you can see, the scope of UX design is wide and constantly evolving. For the purposes of this book, we will focus on projects focused on designing digital experiences, particularly interactive media such as websites and apps. To be successful, the user experience design of these products must take into account the business goals of the project, the needs of the users of the product, and any constraints that affect the feasibility of the product's features (such as technical constraints or constraints around the project's budget). or time frame).

WHAT IS USER EXPERIENCE DESIGN?

Free samples of the new nutrition bar delivered in marathon

the door handle

Packing a pair of shoes.

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

Tangible mobile text messaging features

Customer service telephone

Individual

Social

Our approach Read online product reviews Search the online archive See targeted ads

Live digital customer service chat

About UX Designers While curiosity, passion and empathy are common to UX designers, there is also a desire to find a balance. We're looking for a balance, especially between logic and emotion, like Spock and Kirk or Dane and Dane in this episode where his emotional chip overloaded the positronic relays. You have an idea. To create truly memorable and rewarding experiences, a UX designer must know how to create a workable, logical structure for the experience and must understand the elements that are important in creating an emotional connection with the users of the product. The exact balance may vary by product. A children's toy advertising campaign will have a different balance than a hospital patient information tracking app. A product designed without understanding the need for both is likely to miss the chance for a truly memorable experience and the resulting benefits for the company behind the product. Note For additional information on emotional design, see Donald Norman's Emotional Project: Why We Love (or Hate) Everyday Things (Basic Books, 2005).

CHAPTER 1: TAO UXD

Achieving this balance requires an increased sense of empathy - the ability to immerse yourself in the worlds of potential product users to understand their needs and motivations. User experience designers do research to understand this (see chapter 6) and create tools like personas (see chapter 7) to help the rest of the design team focus their efforts. Remember that emotions are only part of the whole. Use the logical side to bring yourself back from the brink and focus on the tasks to be done. In most cases, you will work with a budget based on the time and materials needed to complete the project. You have to understand that sometimes you have to fish or cut the bait.

Where UX Designers Live You're not alone. Look around you and you will find many organizations and communities that can contribute to your growth as a user experience designer. In addition to offering mailing lists, online resources, and lots of really smart people, many of these organizations sponsor events or conferences that can help you broaden your horizons while narrowing your career focus. Several companies host events focused on providing lifelong learning, including User Interface Engineering's Web Applications Summit and UI Conference, Adaptive Path's UX Intensive Conference, and Nielsen Norman Group's Usability Week. The number of "non-conferences" in different cities is also growing; they are created by a collection of motivated individuals, independent of any particular company or association.

WHERE UX DESIGNERS LIVE

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

UX organization sample

ORGANIZATION

WEBSITE

MAIN CONFERENCE (HAND ONLY)

Interaction Design Association (IxDA)

www.ixda.org

Interaction (early February)

Information Architecture Institute (IAI)

www.iainstitute.org

IDEA Conference (September/October)

American Society of Information and Technology (ASIS&T)

www.asis.org

IA Summit (March)

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

www.sigchi.org

CHI (early April)

Usability Professionals Association

www.usabilityprofessionals.org

EPS (June)

Let's start! You've come this far. It's time to find out why you chose this book in the first place. Turn the page and find out how UX design exists in the realm of design. But don't stop there: this book is a guide to get you started. It contains many examples that can help you accomplish many tasks that will be assigned to you. We also tried to provide additional examples to help you expand and find the best approach to creating output items that will be useful to your team and clients. Keep your curiosity, passion and empathy alive! Challenge yourself to find new ways to inspire others to create the perfect user experience. That is, of course, before you start upgrading it.

CHAPTER 1: TAO UXD

Project ecosystem Planning needs, roles and project culture Intend to start a new project? Or are you in the process? Either way, take a moment to consider the dynamics and context of the project - issues that will affect you and the rest of the project team. What kind of sites or apps are involved? What roles and skills are needed? What is company culture? The answers to these questions will help you define your project and ultimately determine the tools and skills you need to bring to the table to be successful. Carolina Chandler

Each project has its own unique challenges. If you're designing websites or apps, many of these challenges will be around specific features and functionality, such as creating a way to share photos with friends and family online or reorganizing information on your intranet to make content easier to find. find and share. However, around these specific design goals, all projects have a broader context that needs to be understood and integrated into planning. This context is the "ecosystem" of the project and includes the environment you work in (company culture), the general type of work everyone will be involved in (such as the type of website you are designing) and the people they will interact with (including their roles and responsibilities ). If you take the time to understand the project's ecosystem, you'll gain insights that will help you throughout your project. You can communicate your responsibilities and ideas more effectively and help other team members anticipate design needs they may not have considered. To help you, this chapter describes the different types of projects you can work on, the roles you can play, the people you can rely on, and the differences in their involvement depending on the type of website or app you are designing. Finally, the chapter discusses some elements of company culture that can influence the way you work during a project. Note Depending on the structure of your company's projects, a particular project may involve designing more than one website or application. For simplicity, this book assumes that a project involves designing only one type of website. If you have more than one location, consider each location separately to ensure you have the right roles represented on the project team.

Site Type Identification While there are no black and white distinctions between one site type and another, some relative differences can be identified in the scope and functionality of a site. Understanding these similarities and differences can help you set your own design goals. These are general problems that must be there

resolved (e.g., "explain the company's business model") or attributes that need to be presented (e.g., "show how the company responds to customer needs") as part of the site's visual and interactive design.

CHAPTER 2: THE PROJECT ECOSYSTEM

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

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

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

Brand Presence: An ever-present online platform that facilitates the relationship between a company and its general audience (anyone interested in its products or services). Marketing Campaign - A targeted website or application designed to elicit a specific and measurable response from a specific audience or general audience for a limited period of time. Content Source - A store of information, potentially consisting of multiple types of media (articles, docs, videos, photos, tutorials) designed to inform, engage or entertain users

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

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

SPECIFY THE PLACE TYPE

Dirk Knemeyer provides some excellent definitions of a brand in his article "Brand Experience and the Web": A brand represents the intellectual and emotional associations that people make with a company, product or person… This means that a brand is something that is really inside each of us. . The science of branding is about designing and influencing people's minds; in other words, build a brand.

Navigation To learn more about the differences between a company's brand experience and a company's branding efforts, read 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 website UX design can impact an individual brand experience, read Steve Baty's "Brand Experience in User Experience Design": www.uxmatters.com/MT/archives/ 000111.php.

A company can do a lot to influence its brand association, from running memorable advertising campaigns to expressing brand characteristics (such as "responsiveness" or "value") through the features and design of its websites. All the sites in a company can have some impact on the company's brand, either directly (by introducing a website that customers can visit) or indirectly (by allowing the customer a key service that customers trust, such as customer service). However, brand presence sites are most focused on showcasing your company's brand messages and values. They provide channels that directly engage customers and serve as a wide online funnel for those interested in learning about the company or what it offers. The brand presence site is typically the main .com or .org company site, such as GE.com, and for larger, more distributed companies, the main business unit sites of all sizes, such as GEhealthcare.com. Different product lines often also have their own unique online brand presence. For example, Pepsico.com has its own brand while Pepsi.com has its own distinctive presence.

CHAPTER 2: THE PROJECT ECOSYSTEM

If you're working on a branded site, you'll likely be designing for a variety of user groups, including current and potential customers, investors, partners, media (such as news organizations and prominent bloggers), and positions. seekers

Shared Brand Presence Sites The main company website (company.com, company.org, company.net, etc.) The company's main business unit website (often a unique website for

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

Brand presence design goals The design goals that are typically most important in a brand presence project are as follows: Communicate the company's brand values and brand messages.

either directly (perhaps a statement about the importance of responding to customer needs) or through the overall experience of entering the site (e.g. making sure it works well and offers distinctive features that encourage customers to communicate with business). Provide quick and easy access to company information. You want

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

"What can the company do for me?" and "How does the company do it?". Involve a group of core user groups and guide them to appropriate interactions.

features, functionality or content. Help the company achieve the goals that are set against key metrics such as

number of unique visitors. This is often part of an overall marketing strategy. Later, in the "Choose Caps" section, you'll learn about the different roles that may be involved in designing a brand presence site. Let's take a look for now

SPECIFY THE PLACE TYPE

on other types of sites you may be working on, including sites that are closely related to brand presence: marketing campaign sites.

Marketing Campaigns Marketing campaign sites are similar to brand presence sites in that they both focus on engaging users in an experience that influences their perception of the company's brand. However, marketing campaign sites are typically evaluated on their ability to perform very specific actions within a specific purpose (e.g., within a specific time frame or with a target audience). Instead of serving as a funnel to drive interest, they are meant to be engines for generating interest. From an online point of view, this usually means that they are in line with the overall marketing strategy and can be run in parallel with other marketing activities using different channels, such as radio or television advertisements, print advertisements and other promotions.

Typical marketing campaign sites A landing page that promotes a specific offer. The website is accessed via a

advertising banner from another site. A small website (or microsite) that promotes a specific event. A game or tool that was created to evoke emotion.

movement.

The main purpose of a marketing campaign site is to create a narrow-scope campaign, usually targeting a specific set of data. Focus is often narrowed by one or more of the following factors: Timing: for example, an event-focused campaign (e.g.

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

For example, a site that highlights kitchen appliances by displaying virtual kitchens with matching ovens, dishwashers, and cookers.

CHAPTER 2: THE PROJECT ECOSYSTEM

A campaign using a combination of these strategies would be a spring campaign targeting the sale of patio equipment, combining time and product mix. See Figure 2.1 for an example showing the combination of a product set and a user group. A marketing campaign site can be as simple as a banner ad linking to a corporate .com homepage, or it can be a microsite, a small site that often deviates from the prominent .com branding to provide a personalized experience according to one or more areas of interest. "Small" is relative here: some microsites have only one page, while others have many, but either way, a microsite is smaller and more focused than a major company branding site.

Figure 2.1 Texas Instruments uses this educational microsite, http://timathrocks.com/index.php, to provide information about the company's graphing calculators. The product suite is mainly used by high school and college students in algebra classes. The microsite retains the generic Texas Instruments brand affiliation, but is intentionally differentiated to appeal to a younger audience and organize content and features according to their needs.

Marketing Campaign Design Objectives For the person or team responsible for designing and implementing a marketing campaign site, the following design objectives are often most important: Generating interest and excitement, often by presenting a clear and immediate message.

a specific value proposition (the value that a product or service brings to the user, e.g. the possibility of qualifying for a quick loan) or some kind of incentive (a special offer, participation in a competition or entertainment, e.g. an online game).

SPECIFY THE PLACE TYPE

Involvement of a set of major user groups to illegally perform a specific action,

such as clicking on a specific location on a branding page, subscribing to a newsletter or applying for a loan. When a user performs this action, it is called a conversion. Help your business meet targets based on key metrics like numbers

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

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

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

Sites with common content sources Corporate intranet An online library or resource center for organization members Sites or areas of sites that focus on delivering news or information

current entries (large business blogs may fall into this category) Customer Service Centers

Of course, all sites and apps have some content, but some sites place particular emphasis on the presentation and structure of content. Emphasis may come because the site has so much content that it is challenging on its own, or because certain types of content have a high degree of importance; for example, they can support critical decisions or encourage users to return to the site frequently.

sixteen

CHAPTER 2: THE PROJECT ECOSYSTEM

The main purpose of a content feed site is to increase user awareness and self-sufficiency by providing relevant content (intranet, for example). They also often encourage some type of action, such as sharing information or buying a product after reading its description. Content Source Design Objectives A content source site often needs to do one or more of the following: Present content that is the main attraction on first and subsequent visits to the site. Demonstrate the company's ability for thought leadership, for example

providing access to ideas and perspectives from the CEO or other subject matter experts within the company. Support critical decisions among users. Increase the business knowledge of the company by revealing the ideas that

they may be buried in individual apartments. This may be part of a broader goal of identifying more opportunities for innovation. Support users searching for information in various ways. For example,

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

Explore To learn more about the different ways users search for information, read "The Four Modes of Information Search and Ways to Design for Them" by Donna Spencer: http://boxesandarrows.com/view/four_modes_of_seeking_information_and_how_to_design_for_them

When it comes to UX design, some of the most common tasks in content channel design are: Creating a categorization structure that matches the mental models of users Determining how to incorporate the system into organic content growth

(for example, features like tagging and filtering) Design an effective search tool DEFINE THE TYPE OF SITE

Task apps Task apps can range from a simple calculator built into a mortgage website to a complete system that handles multiple critical workflows. If your project involves the latter, there will be more roles involved and possibly a significant requirements gathering process (see Chapter 5 for more on this process).

Typical task applications An application that supports the creation of tasks of a specific type.

item (such as a spreadsheet or printable part) A tool or web application that supports a critical workflow in

company (such as a ticket management app for an IT support group or a customer tracking app for a call center) A website that allows you to access and manage your personal information

(like Flickr)

The main purpose of a task app is to enable users to perform a set of tasks that align with their needs and ultimately the client's business goals. Objectives of designing task applications Most task applications should allow users to do something that they could not do elsewhere, or if they can,

do better ("better" can mean more efficient, more efficient, more satisfying, or more convenient) Support first-time users with easily accessible instructions and a visual hierarchy of priorities.

assignment of key tasks Supports intermediate and advanced users with access to shortcut functions

and deeper functionality Reduce user workload and make full use of system resources

(e.g. reuse data instead of requiring duplicate entries)

CHAPTER 2: THE PROJECT ECOSYSTEM

Be designed and implemented with the degree of change required

app users, preferably with a learning design and communication plan that demonstrates value to the user. One of the biggest challenges when designing a task-based application is controlling "feature escalation". As a project develops, it's all too common for great ideas to come later in the design process, or even during development. UX design is well suited to guard against feature escalation, as user models such as personas can be used to identify high-value features and maintain focus throughout the design. If a really great idea comes along later in the process that meets the needs of a high-priority user group and aligns with your site's business goals, your team may justify a change of direction. If an idea can't get past this wringer, it may not be worth the delay and cost.

E-commerce sites E-commerce sites can include elements of all four types of design, because a site primarily for e-commerce needs to be self-branded, have content (usually product specifications or product usage descriptions), and facilitate tasks (search, compare, write reviews, pay ). Marketing campaigns are often closely tied to these sites and may involve multiple marketing groups within an organization. Additional common design goals for e-commerce sites are to clarify the site model if it is non-standard. Like online marketplaces

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

from comparison to purchase, with useful content and features. Take advantage of experience points where cross-selling and up-selling occur

as possible, and place these suggestions in a way that is eye-catching but not distracting. Create a communication flow from point of purchase to

Delivery point. Communication should take place not only within the website, but also through other channels, such as integration with shipment tracking systems and e-mail communication regarding the status of the order. SPECIFY THE PLACE TYPE

E-learning applications E-learning applications are a cross between a content source and a task application. The content needs to be generated for the lesson, which often requires the team to add the Learning Specialist and Content Expert (SME) roles for the topic being discussed. The product is task based as the user usually follows the course of the lesson and may also need to track progress or explore related topics. Some practical lessons may also require you to do homework. Typical project goals are to understand the basic knowledge needed to start the course.

and to whom it is addressed. Deliver content in manageable chunks that are scheduled

understanding. Engage the student in activities that simulate hands-on learning. Communicate results and progress, and make suggestions where appropriate

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

Social networking apps Social networking app is primarily a task based app as users need to be able to find and add friends, manage their profiles, connect, post and search. However, they also come with content source challenges, particularly the need for an organic structure that can handle a potentially very large amount of user-generated content. If the site basically has its own identity, it will also have the characteristics of a brand presence site.

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

CHAPTER 2: THE PROJECT ECOSYSTEM

A typical goal of designing social applications is to focus the attention of potential users on the purpose and values of the network. Facilitate meaningful interactions between users who are supportive and are

supported by featured features (such as photo sharing, video sharing, and discussions). Protect the integrity of your site by making sure people on your network understand

Learn how to control your information and respond to inappropriate behavior. Use and showcase the power of the community to introduce new features

tours that are only possible with active members, such as features and popular reviews. Identifying the type of website or app you're working on for a project is just the first step. Then consider the various roles that are often needed and how their involvement may vary depending on the type of project.

Pick hats When you become a UX designer on a project, you often have to fill multiple roles. Whether formally defined within the client's organization or not, the roles you will fill will depend on the type of project and the composition of the rest of the team, as well as the client's experience with each. It's good to know which roles you're already comfortable with and which ones you can learn on the job. It is also helpful to know what expectations others may have of the responsibilities covered by these roles. With this understanding, you can represent yourself more clearly from the beginning of the project. What are the most common roles expected of a UX designer? Each client company you work for may have different titles for these roles (or no name at all if it's not a formal job in the organization). In general, you can expect a meeting of the big three: information architect, interaction designer, and user researcher. Note Few companies have the size or budget to split these shared roles among different people. Remember the names of the roles when defining the project, but talk to the client in terms of needs and responsibilities; otherwise they might think you are building a very large team! This focus on responsibilities rather than titles will also help you stay sane: if you play several of these roles, it doesn't necessarily mean you are doing the work of many people, as responsibilities come and go through different parts of life. Work. . design.

CHOOSE YOUR HATS

Information Architect An information architect is responsible for creating information structure models and using them to design user-friendly navigation and content categorization. When designing websites and applications, common responsibilities include creating detailed sitemaps (discussed in Chapter 10) and keeping categories and subcategories of information distinct and easy to use. Understanding expectations In the field of UX, a distinction is made between the roles of an information architect and an interaction designer (discussed below). However, in a particular company, there is rarely a common distinction between the two roles, at least when it comes to what is established as a necessity for a particular project. For example, you might end up on a team called information architect because that's the technical name for the role, regardless of whether or not it actually fits your responsibilities. Should you improve your project team if the title you've been given doesn't match the lead role you're assuming? If it's a short-term project (say, four months or less) and the position you hold is widely accepted within the organization with clearly defined responsibilities, it may not be worth the potential fuss you'd have to deal with. Change it. . However, if there is no universally accepted title and you think there is a chance that both roles will be played, perhaps by different people, it makes sense to make the distinction early in the project when you plan your involvement and communication. your responsibilities. Generally, for more task-oriented applications, it makes sense to emphasize the role of the interaction designer, and for more content-driven designs, it makes sense to emphasize the role of the information architect. But it might make the most sense to use a term familiar to the client's organization and make sure the team understands how you define the role in relation to the responsibilities you take on. This definition is something you should explain in your job statement (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see "Other Roles" below). If they are roles

CHAPTER 2: THE PROJECT ECOSYSTEM

represented by different people on the project team, be sure to discuss how to collaborate at the beginning of the project.

Interaction Designer The Interaction Designer is responsible for defining the behavior of your website or application based on user actions. This includes site flows across multiple views and interactivity within a specific view. Common activities when designing a website or application include creating workflows that show interactions between pages or components on the site (see Chapter 10) and creating diagrams that show interactions on the page, such as dynamic menus and expandable content areas (see Chapter 10). eleven). Understanding expectations If you're working in a small team or on a project that doesn't focus too much on creating new task-based features (for example, if you're working on a branding site that mainly has a few content categories, a contact form, and a newsletter sign-up form) the designer The interaction manager may be primarily responsible for capturing project requirements (see Chapter 5). If you're working as an interaction designer on a project with a high level of new features, you'll most likely have a separate person on your team responsible for specifying detailed requirements (for example, a business analyst or product manager). UX designer skills can greatly assist in the process of gathering and refining functional requirements, and documents such as functional specifications and use cases are influenced by experience design. Be sure to sit down with the person responsible for qualifications to discuss the best way to work together.

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

CHOOSE YOUR HATS

Understanding Expectations A client company's appetite for user research can vary greatly, depending on the importance attached to it by the project team or project sponsor. The fact that you talk to the project sponsor about UX design before starting the project shows that someone on the client's team knows that representing users' needs is a priority. But as those who have worked on their computer projects know, the introduction of research can also cause anxiety among project team members, fueled by fears that user research will create a bottleneck. , increase risk (What if you find something wrong and you need to make big changes to fix it?) or subvert the value of a particular idea that has gained momentum. User research expectations can vary between business stakeholders and the project team, so role expectations for both groups should be clarified. Customer may also expect User Research to provide information based on site analytics: tools and reports that convey site usage patterns, such as frequently visited pages and common points where users leave the site. Some of the more popular analytics tools come from Google (www.google.com/analytics), WebTrends (www.webtrends.com) and Omniture (www.omniture.com/en/products/web_analytics). You can assume all three roles: information architect, interaction designer, and user researcher. Can you balance all three or are you biting off more than you can chew? In part, this depends on the size and schedule of the project, but the type of project also affects how each role is likely to be involved. Table 2.1 shows how the roles of UX designers can vary depending on the type of project.

Navigation Want to improve your UX design? These articles contain insights that may help: "User Experience as Corporate Imperative" by Mir Haynes: www.hesketh.com/publications/user_experience.pdf "Evangelizing User Experience Design on Ten Dollars a Day" by Louis Rosenfeld: http:///louisrosenfeld .com/home/bloug_archive/000131.html

CHAPTER 2: THE PROJECT ECOSYSTEM

TABLE 2.1

Typical UX design duties

information architect

BRAND PRESENCE

MARKETING CAMPAIGN

SOURCE OF CONTENT

TASK APP

Average share.

Low engagement for smaller sites (such as a single landing page). Average share when working with larger microsites.

Very high commitment. Content sources require an information architecture that strikes the right balance between structure and flexibility to give users a solid foundation for expansion and enable planned growth.

Medium to high involvement, mainly focused on building the navigation structure, unless there are larger areas of content that need to be referenced during certain workflows.

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

Medium to high share.

Very high commitment. This type of design often requires the most payload because interaction design elements (such as user workflows and wireframes) are key to visually communicating requirements.

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

Field research, like contextual research, can help your team understand how different users are currently working with information.

The greater the content challenge, the more the design will resemble the content source.

interaction design

Average share. The higher the number of tasks, the more the project will resemble a task app.

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

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

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

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

Field research, like context research, can be conducted to understand the tasks performed by users. However, the most commonly used and best-known technique of engaging users in task application design is usability testing.

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

CHOOSE YOUR HATS

Other Roles You May or Must Have Different roles usually fall outside the scope of the UX designer role, but their responsibilities often overlap with that of a UX designer, especially if you're working on a project that no one else is officially playing. role. and you have skills to bring to the table. Some of the most common overlapping roles are: Strategist/Brand Manager Business Analyst Content Strategist Copywriter Visual Designer Front-end Developer

The following sections go into more detail about each of these roles and discuss how they can vary depending on the type of site you are designing. Brand Strategist and Brand Manager The Brand Strategist is responsible for building relationships with key markets by defining and coherently representing the company's brand elements, which can include everything from brand values (such as "capacity response") to copying guidelines and messaging treatment specifications , colors and logo design. This role often includes creating or representing brand guidelines and understanding how they relate to different projects. This may also include knowing or defining your target audience that is important to the project you are working on. For the most part, you'll probably work with a brand strategist, but they won't take responsibility. The Brand Manager does not necessarily set the guidelines, but is responsible for ensuring that they are properly followed throughout the project. This responsibility can be delegated to the UX designer or visual designer of the project. If your company's brand attributes, values, and guidelines are already well defined and your site is expected to adhere to them, your role as the project's brand manager will primarily be to ensure that the outcome follows those guidelines. Your point of contact outside the project will most likely be a

CHAPTER 2: THE PROJECT ECOSYSTEM

A member of the marketing department who is available for consultation or review, but is not a full-time member of the team. The role of the brand manager can be more active if the site is to extend the brand in some way, for example by targeting a new market. It's more complicated when you're creating a brand new brand presence or when a company is making drastic changes to its brand, effectively revamping itself. For example, CellularOne was completely rebranded as Cingular, which was a major effort for an established company. In this situation, you need to have a lot of experience in branding or establish a clear and close relationship with the person in the company who is branding. Key questions to help you understand your brand role expectations include: Do you already have brand guidelines? If so, how strictly must they be followed for this project? Who is responsible for establishing or maintaining brand messages,

the look and tone of the content (like casual or professional)? Will the target be new audiences that are not covered by previous ones?

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

involved? (An example would be creating a name for a new tool that will be heavily promoted.) For projects that do not have a large potential impact on customer perception of the brand, such as developing an internal application, engaging a brand manager can be as simple as occasionally checking that the brand is adequately represented. Business Analyst The Business Analyst (sometimes called Business Systems Analyst in IT projects) is responsible for identifying key business stakeholders, guiding the requirements gathering process (see hardware. Also is the primary owner of detailed requirements documentation such as functional specifications and use cases if necessary .

CHOOSE YOUR HATS

The role of business analyst or product manager may not exist in your project, or it may be one of the most important roles in the entire design process. Task-based apps and content sources often have these types of features; branding projects and marketing campaigns cannot. A task-based app is more likely to need this role. The more functions and the greater the complexity of the project, the greater the need for a dedicated person and functional documentation. While a Business Analyst is not typically considered a member of a UX team, small UX teams are often asked to fill this role, so it's important to understand what these responsibilities are. Business analysts steer the capture of business requirements, serving as a liaison between the technology team and key business stakeholders. If a business analyst is involved in the project, that person and the interaction designer are often related. If it's the same role, the responsible person may have a lot of documentation to keep up with! To understand expectations in this area, ask who will be responsible for outlining the scope of the project, facilitating discussion of requirements, and documenting requirements throughout the project. For small projects or those that don't have many functions, the project manager sometimes takes over these responsibilities. Either way, if it's not you, you'll still know who you need to be close to to make sure deliveries are in sync. Content Strategist The Content Strategist is responsible for understanding business and user requirements for content across media (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating workflows and developing new content. Content efforts are often underestimated. A client may have a lot of content that is great in one medium (such as printed brochures or videos), but that content may not be appropriate for the project they are working on. In addition, there are sometimes unspoken expectations that people within the customer organization will generate content—expectations that can surprise those people when it comes time to fill your product with descriptions, news, and help topics! If high-quality content is a

CHAPTER 2: THE PROJECT ECOSYSTEM

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

tons, amount). Evaluate the relevance of existing content against

guidelines. Development of new content. This will vary depending on the type of overall project. For

task applications, may contain instructions, error messages, and help topics. For content sources, you can include articles, news, and blog posts. Act as a liaison between stakeholders and the technical team to communicate

Limitations and capabilities of the content management system. Define the different types of content as well as the metadata for each

information that ultimately makes searching and referencing more efficient). Content migration planning, which includes creating templates.

for different types of content and ensure that content is properly flagged and uploaded when it is transferred to the site's content management system. (This is another area where the effort required is often underestimated.) Copywriter A copywriter is responsible for writing the copy on the site, which is the framework for the overall experience. In some cases, this copy remains virtually unchanged from day to day. It usually contains an introduction to the site and the page, or instructions on the page. A copywriter can also be involved in the ongoing creation of dynamic content, such as news or texts for marketing campaigns. Copywriting is one of those gray areas that often falls to the UX designer, especially if you're doing wireframes (see Chapter 11). Initially, you can put sample text to serve as a placeholder for your copy, such as a site description or page instructions, but eventually someone has to fill it with the final text that users will see, and since many projects don't have a dedicated writer, this task can be commissioned to you. You're less likely to be asked to take on a copywriting role for high-profile areas of branding sites or marketing campaigns; in these situations

CHOOSE YOUR HATS

every word can be scrutinized. But if you're working on a task-based application that requires short instructional messages, error messages, or other information that doesn't necessarily fall into a clear content group, you may end up inheriting that writing task (or it will fall to the developer by default). ). Ask in advance if a copywriter will be available and ask again if not found. If the work is yours, be sure to include this effort when planning project activities. And be careful: this is a responsibility that is often overlooked or underestimated. Visual designer The visual designer is responsible for the elements of the website or application that the user sees. This effort includes designing a look that creates an emotional bond with the wearer, in line with the brand's guidelines. For example, a banking site often needs to appear stable, trustworthy, and easily accessible. Visual design can provide this reassurance with visual elements such as colors and images. This promise will be kept (or broken) with the site's interaction design and other touchpoints with the business (such as a call center). Let's be honest: a lot of people call themselves visual designers, web designers, or graphic designers, and many sites have poor or acceptable visual designs. There is a big difference between creating an effective, engaging and emotional visual design and simply surviving. Sometimes progress is enough to achieve project goals, and sometimes it leads to frustration and project delays when the project sponsor is dissatisfied or early adopters are not involved in the project. On the other hand, it can be easy to focus too much on influencing the visual design, which will suffer from the usability of the design. If you're asked to take on this role and you're unsure if you can make the right impression on customers, take a look at your current company website and the websites or products that customers admire from a visual point of view to gauge your comfort. level. Visual designers often play a very central role in brand awareness projects and marketing campaigns, being primarily responsible for effectively communicating a company's brand.

CHAPTER 2: THE PROJECT ECOSYSTEM

For content source designs, they can focus on creating content templates that can be applied to multiple pages (for example, an article template). For task applications, they can provide a stylistic guide that can be applied to common interaction elements such as navigation areas and tools (requiring a high degree of collaboration with the interaction designer). Front-end developer The front-end developer is responsible for building the technical framework behind the page layouts and flows, as well as the interactive elements on the site, such as drop-down menus, expandable content areas, interaction with multimedia elements such as video. This job often uses technologies such as XHTML, CSS, Flash, JavaScript, Ajax and Silverlight. Front-end development focuses on site elements that relate directly to what the user sees, as opposed to back-end systems that provide the underlying platform (such as databases, content management systems, and the code needed to build the functionality behind complex functions). If you or your team members assume the role of a front-end developer, it's important to work closely with the rest of the development team to understand expectations and responsibilities. Other important questions are what back-end systems they will need to integrate with, the method used to generate the HTML, the need for flexibility in the page structure to accommodate custom "skins", and expectations for technologies such as Flash. If a prototype is planned (see Chapter 12), ask who is responsible for developing the prototype and what level of functionality you expect. A prototype simply designed to communicate opportunities can be built quickly in an application like Flash, but a fully functional prototype that requires real data (for example, the account information the user just entered into a form) will require careful execution. . cooperation with members of the backend development team. Worried about taking on all these roles? Unless you're working on a very small project or a very small business, you probably won't cover all of them. The key is to understand which roles you can and want to take on if needed for the particular project you are working on. Otherwise, you can get the support you need in the project team by building a network at the client's company or by referring additional people to meet the needs. Let's take a moment to talk about how you can do that.

CHOOSE YOUR HATS

Building a Network of User Advocates For areas where you're not sure you can or want to address, it's time to start seeking help. There are three main ways to do this: Recommend adding additional team members as needed.

visible enough. Educate yourself in key areas where there are gaps if new responsibility

Skills are manageable and you have time to devote to them. Create a support network in the company that will help you in key moments.

Let's take a closer look at how you can build a support network. There's a good chance other departments of the company have key resources that can help you succeed. You need to figure out how much time you can trust these people as asking for outside people's time can be a tricky request for projects that are mostly about one department. If you don't want to demand a lot of time from them upfront, just ask if you can work with (or consult with) them to ensure you get the best out of the core responsibilities of the role. Once you've made some associations, you'll have a better understanding of how much interaction you might need and whether you need to make a more formal request for your time. Each company will have a different structure and different names for its departments, but here are some common places to look for partners: For a brand strategist role, ask if there is anyone in the marketing department.

department that can serve as a point of contact. It can also be a resource for visual designers and content strategists. Visual design and content strategy partners can also be found at

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

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

CHAPTER 2: THE PROJECT ECOSYSTEM

If you've recently been hired at a new company and expect to work across multiple departments, one of the best things you can do early on is identify key people who could become partners and schedule an interview with them to understand their roles. And experience. It starts with a network you can often rely on for a long time, and gives you a chance to explain your responsibilities (and user experience design in general). Or you can ask a great question at the end of the interview: "Who else do you think I should talk to?" The answer can help you find people who may not be obvious to the lead project manager or customer contact. If you've been with the company for a while, you can still start a talk show like this. In this situation, it is best to tie it to a specific milestone (e.g. starting a new project) or an urgent company goal to ensure high commitment. Make sure your supervisor knows what you're doing to avoid the impression that you overlooked it. Good communication is key to understanding role expectations and building trust. Another key to gaining trust in a company is understanding its culture, often unspoken expectations about how the company operates, for example, from previous project experiences (positive or negative), organizational hierarchy etiquette, and acceptable work logistics (e.g. working from home).

Understanding Company Culture Culture is a bit like throwing Alka-Seltzer in a glass: you can't see it, but somehow it works. — Hans Magnus Enzensberger

The company culture may not be consistent across regions, business units, or departments, but overall, you can identify key characteristics that will influence you and the projects you undertake. Here are some things to keep in mind when evaluating projects and navigating potentially difficult political situations.

UNDERSTANDING COMPANY CULTURE

History We all know the saying that those who don't remember the past are doomed to repeat it, and design work is no exception. Understanding how the project or team arrived at their current state of needs can help you understand the challenges you may encounter during the project. Let's go over some of the questions you can ask to understand the story that could affect your project. While some of the answers to these questions may seem scary, remember that something made you want to be involved in the project, so the project can have a difficult history and still succeed. You can be a key part of this success! However, if many of the issues discussed below seem to apply to you and you don't feel like you'll be able to help solve them, it may be a red flag. In this case, an overall assessment of whether this project has a chance of success should be considered. What is an example of an earlier project that seems to be considered?

Was it a success and what seems to have made it so? What past project was a failure (or a particularly painful one) and why did it fail? Asking these questions (either directly or in a more subtle, conversational way) can help you understand a few things: how the answerer defines success, potential risks to your project, and any biases or expectations that will carry over into your project. and approaches that have worked. Did the company work with the designer and released it in the same

project or team? If so, try to find out what doesn't seem to be working and how the customer expects a different approach. If you can ask this question to more than one person in the company, it will help you understand the many unspoken expectations. If you get two very different answers, it may mean that the designer's responsibilities have not been well defined and you may need to ensure that there is a lot of communication about their responsibilities throughout the project. Did the design team work on the project (or related materials)?

for what seems to have been unfinished for an unusually long time?

CHAPTER 2: THE PROJECT ECOSYSTEM

If so, it may mean that the client's key stakeholders are not on the same page or are not engaged in a timely manner, leading to multiple deadlocks, changes of 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 prioritize) to focus on your business goals. If you have an impact on project communication, it can be helpful to create engagement guidelines to help move the project forward. Did the company create projects without prior involvement

UX designer? It can be a mixed blessing. On the one hand, you are dealing with a team that understands the design needs and tries to fill the gap. On the other hand, you may end up with a design that you don't think meets the user experience design goals. This can be a difficult situation to navigate. It's often best to approach the creator of these projects in the tone of a self-respecting mentor or helpful consultant, first pointing out the good aspects of the project, then discussing the user experience goals and how best to achieve them using a different approach. . The Creator is likely to be a valued member of your support network, so it's important not to burn a bridge here, but to redefine your roles together to keep the enthusiasm alive. Does the main sponsor or project manager seem particularly concerned?

about the project? There are many reasons why this can happen, especially if some of the above factors are involved. Anxiety can also be caused by market pressure, which would be good to understand. For example, has the company's stock price fallen? Have any of your competitors made alarming profits recently? Does the company operate in red numbers? Again, these situations don't necessarily mean you shouldn't take on the project; after all, these are the situations that often fund a project in the first place. But if you have serious concerns that the company won't be able to pay your bills, that's a risk you'll want to consider.

UNDERSTANDING COMPANY CULTURE

Geert Hofstede's hierarchy has an excellent model for describing cultural differences, which he calls "cultural dimensions", which often influence the way people interact and communicate. One of them is the concept of power distance, i.e. the degree to which members of society (in our case, companies) understand and accept the distance between people with different levels of power. For example, if members of a company's leadership team are perceived as particularly powerful and potentially unavailable, the company may have a high power distance and its employees may be more hierarchically focused. If a company encourages democratic exchange of ideas and challenging visions, it may have a relatively small power distance.

Power distance is “… the degree to which weaker members of organizations and institutions (such as the family) accept and expect unequal distribution of power. This represents inequality (more versus less), but defined from below, not from above. This suggests that the level of inequality in society is supported by both supporters and leaders. Geert Hofstede Cultural Dimensions www.geert-hofstede.com

Neither extreme is inherently good or bad, although in general in the United States most workers seem to prefer the impression of a low power distance in the workplace. It is worth noting that this is not necessarily an indicator of a company's success. Apple has a relatively large power distance (considering the aura surrounding Steve Jobs) and Google has a relatively low power distance as part of their culture, but both companies are known as opinion leaders. It should be noted that the power distance within the client company will influence how successfully you navigate political waters during the project. This aspect will be particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as closure points (discussed in Chapter 4). If you work for a company with a high power distance, take a little more

CHAPTER 2: THE PROJECT ECOSYSTEM

Before scheduling meetings such as interviews and stakeholder reviews, take the time to understand your subordinates' relationships and consider involving more people at intermediate levels in your communication.

Logistics In addition to the broader aspects of culture mentioned above, it is also helpful to understand some of the elements that are more logistical in nature so that you can better integrate with current working methods or make thoughtful changes. For example, it's helpful to understand the overall pace expected by the company, including key release dates or schedules that will affect the project (developing an app with an annual release schedule would likely have a different pace than a microsite that supports a seasonal campaign, for example). Will your team have to work late to meet looming deadlines? It's also good to understand the expectations of working remotely versus working onsite. If you expect a lot of time on site, you will need to plan your travel and resource deployment. If remote work is acceptable (or encouraged, which is common when working with global companies), it is important to understand communication methods and tools. For example, is the use of instant messaging allowed? What web conferencing tools are used? Are there methods of engaging international stakeholders that have proven successful in the past? It is also interesting to understand the "paper culture" in the company. Some companies prefer electronic media for most things, in which case a good projector and a solid Ethernet connection are important. Others are very paper focused, in which case you need to make sure you have enough copies per meeting to make it productive. You may be able to change the project culture if you think another way is more effective. But it's nice to know that you're asking people to change to ease the transition and potentially understand why a particular approach isn't working as expected.

UNDERSTANDING COMPANY CULTURE

Putting it All Together Once you have familiarized yourself with the project site, you should have a better understanding of the project's ecosystem: the environment you work in (company culture), the general type of work everyone will be involved in (like the types of sites you are designing), and the people you work with you will interact with (including their roles and responsibilities). This information will be valuable as you describe your role in the project and prepare to get serious. If you work as a freelancer or subcontractor, this will be the basis for writing a proposal covering your work on the project (see the next section which discusses UX proposals). If you are working as part of a larger team and are not directly involved in writing the proposal, you can bring your new insights to the beginning of the project, to the first team meeting. For a basic guide to running a good meeting, see the online chapter "Quick Guide to Meetings" or if you want to jump straight to the types of questions to ask at the start of a project, see Chapter 4 "Project Objectives and Approach".

CHAPTER 2: THE PROJECT ECOSYSTEM

Proposals for consultants and freelancers A guide for people in business who also run their own business Managing projects and customer expectations can be hard enough, but if you don't have the right contract, you can lose every project you take on. Job offers and statements are essential to protect your company and you from financial and legal problems. After agreeing to the project and shaking hands, be sure to take the appropriate amount of time to draft a contract that details the terms of the relationship and the payment schedule for the client. Russ Unger

Proposals There is an old saying that "no good deed goes unpunished" and the same is often said about any project: feeling good and high five are quickly replaced by "Oh shit! It's time to write an application!" The biggest challenge in writing an application is writing the first one. It's almost impossible to know where to start if you've never had to write yourself, and that's where this chapter should come in handy. Every type of design you come across will have different flavors that will keep you ready when it's time to create your proposal. Fortunately, there is something like a core that is common to all proposals and can be reused from one project to another. (For a detailed discussion of project types, see Chapter 2.) When should I write an application? Always. Why is it worth writing an offer? In the entire history of working on projects, the most uncomfortable situations put people in those where there was no agreement between the client and the supplier. You may be tempted to skip this step when you're connecting with a prospect for the first time and everything seems to be working. Even if you clearly understand the customer's needs and can express them in a way they understand, you're not ready to get down to business yet. In fact, this is exactly the moment to slow down and breathe. Instead of getting down to business, take the time to define your professional relationship and how you work with your new client. Jean Marc Favreau of Washington, D.C. law firm Peer, Gan & Gisler, LLP, says: "Too often, contractors and their clients believe there is brainstorming going on early in their relationship when in fact the ambiguity just lies. pending. While it's nearly impossible to prepare for every possible eventuality, a fully written contract is your best defense and the smartest way to ensure you don't end up in court later arguing about the terms of your relationship. The more clearly you define the terms and parameters of your relationship with the client in a written contract in advance, the less likely you are to fight for the obligations of each party in the future.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

New projects and new people are exciting. There is often a desire not to "kill the deal" by throwing a proposal into the mix, but as with any relationship, the honeymoon feeling may eventually wear off. Promises can be broken on both sides of a relationship. The customer may not provide timely access to the content. (I know it's almost unheard of, but believe it or not, it does happen! It's sarcasm in case you missed it.) busy with work, it can be left with a bag. Companies also recognize that they are taking risks when working with external suppliers, especially those that are very small businesses or independent contractors. Well-written offers give customers a sense of stability and protection, which can help ease many of the concerns that may arise. The proposal also allows you to define conditions that protect both parties in case something changes. If a client fails to provide you with timely access to their resources, your timeline may be delayed; they must be aware of their obligations for the success of the project. If a client loses funds and cancels a project, and you don't have a proposal or other form of contract, you may be at risk of not getting paid for work you've already done. The point should be very clear: always write a proposal.

Creating a Proposal Once you've landed your project, it's time to submit your proposal. The sooner the proposal is approved and signed, the sooner you can start working and, more importantly, start getting paid for your work. The basic elements of a good proposal are: Cover page History of changes Project review Approach to the project

CREATING AN OFFER

Scope of work Assumptions Deliverables Ownership and rights Additional costs and fees Design price Payment schedule Confirmation and approval

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

Cover page The cover page is a single page that introduces the document. Cover pages are an interesting beast - there are many ways to create them from a style and information point of view. How you do it is up to you. A typical cover page consists of the following: Client company name Client company logo (if you have permission to use it) Project title Document type (offer) Offer version Submission date Your company name Authors of the offer Project reference Cost Confidentiality

For the first proposal, include everything but the client's company logo, cost, and (potentially) the project reference number. Why not put these elements on the cover?

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

Your client knows who he is. It's probably not worth the time and effort to ask permission to use your company logo, nor is it worth the potential upset if you inadvertently misuse it. The cost is best located after identifying the various design elements in the content, and the cost information leads very well to the payment schedule. Please note the project reference number. Many companies will not use it at all; however, some government agencies are known to trust this particular article, and if it is not on the cover page, your proposal may be rejected.

Figure 3.1 Example cover page for a proposal

Figure 3.1 uses a (fictitious) customer logo. In the event that consent has not been given or no relationship has been established, it is better not to display the client's company logo.

CREATING AN OFFER

Change history The change history is a separate section of the application and is used to determine how many times you have updated the application since the original version. In general, it's best to include the version number, date, author, and any version-related comments, such as what has been changed, to give the reader context of the changes (Table 3.1). TABLE 3.1 OVERVIEW

Sample change history table SECTION

DESCRIPTION

THE EDITOR

DATA

Original new document

REU

8-in-09

assumptions

Updated to reflect software requirements

REU

11-Jan-09

1,0 1,1

Sometimes clients approve a proposal and then ask for additional revisions. If you decide to go ahead with the client and make these changes, you should take the opportunity to upgrade your document from 1.x to 2.0. Basically, once the client approves the proposal and both parties agree to the terms, you're ready to go. Therefore, when additional modifications are required, they should be reviewed very carefully. This ensures that your costs still make sense and there is a clear understanding on both sides of the changes and at what stage the project will resume (if necessary). You should also always provide an adequate explanation as to why the version is a completely new version in the version history.

Project Overview The overview section is a description of the project you will be working on, in your own words. This description should give the customer a clear idea of what you expect your product to contain, as well as an explanation of what they can expect from the rest of your offering. Here's an example of a review start: [Client's company name] wants to create a new online presence on the web. This online presence provides customers of [Customer Company Name] with the ability to search and purchase products online, as well as other services and benefits available through the company. The goals of an online presence are…

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

You need to be able to give a solid overview in a paragraph or two, providing a great deal of detail about what the customer should expect from you. It's a good idea to end the review with a strong explanation of your recommendations and proposed approach for project delivery: This proposal details the recommendations and approach of [Company Name] for the design and development of [Company Name]'s online presence on the web. Given the [deadline], it is proposed that...

Project Focus Your project focus will vary depending on the type of project you are doing. This is your opportunity to introduce the client to how you plan to work with them on the project. You have the ability to define the rules of engagement and set expectations for future work. Many people and companies use very similar methodologies but use different names or clever acronyms that fit their overall branding. Once upon a time there was a mythological methodology that was created to show (potential) customers and found its way into many proposals. This process is called The PURITE Process™ (pronounced "purity"), and as I share this with you, the mythological creature just died a little bit inside, so be careful reading this as fiction. The name of the process is a bit trivial, and the process is clearly incomplete. The post-launch analysis of this methodology has been omitted (oversight), but should of course be included for all customers. Without further ado, here's the PURITE approach: [your company name] has established a standard project success process with our clients. While each of these phases may not be related to [Project Title], the overall process is defined as follows: The PURITE™ Process is [Your Company Name]'s internal methodology to ensure the overall success of all initiatives. When using PURITE, [your company name] has a proven set of guidelines for working closely with customers and users/audiences to reliably maintain and exceed content delivery expectations. P-Get ready. We dedicate part of every initiative to understanding your industry and competitors and how they do business so that you are as informed as possible before starting to gather requirements. You understand. We work closely with subject matter experts and/or users to define the requirements necessary to properly build the project.

CREATING AN OFFER

R - Render. In the rendering phase, we create and develop all parts of the project/product. In our experience, each phase of development requires a lot of focus, concentrated work, but also open and timely communication with your team(s). It also requires that we... I - Iteration. The iteration phase is repeated throughout the project life cycle. We work as quickly as possible to bring the project to life, and this often requires creating many iterations in a short time frame. This requires a direct and timely commitment from you and your dedicated resources. The end result is the product you defined and helped create. T- Try. We test each project in the rendering phase; however, we also need an extra pair of eyes, from our own test team and designated user/audience group for goal-based testing. This extra round of testing helps ensure that as few stones as possible are left unturned to deliver a design that has been rigorously assessed on multiple levels. E-Enable. After successfully completing the above five phases and signing the consent form, we will enable the solution and implement it. The PURITE™ process doesn't stop there. After the project is completed, we regularly communicate with our clients. We will continue to assess your level of satisfaction, understand the changing goals or improvements of your project, and help you determine the best approach for the future development of your project.

You can use as much or as little as is applicable or useful to you. The mythological author who created this process also doesn't care if you don't cite the source. Your process definition can be as detailed as above or as simple as: Plan, Define, Develop, Extend Plan an overall strategy Define specific project requirements Develop, test, refine and release a working product Extend the design by recommending enhancements and enhancements based on information gained during development, testing and post-release

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

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

be sure to only include the results you will be able to deliver to your client to avoid further document updates or project re-pricing.

Scope of Work The scope of work section is where you define the division of work for the project. This means that you specify which elements of the project you are responsible for and which are the responsibility of the client. Read it again. Think about it for a moment. Let it absorb. Let's go. Yes it is. This is the part of the proposal where you tell the client in writing that we will do this and you do that. Later, when the client signs your proposal, they will agree to this agreement and will have a paper record in case there are any misunderstandings. The goal is to be clear about who will handle what aspects of the project, and what aspects of the project are included in your proposal and at your estimated price. If you can't find another really compelling reason to write a proposal, that should be reason enough. Here is a very brief example of the scope of work: [Client's company name] asked us to provide all the services needed to build [Type of project]. [Your Company Name] will focus solely on [User Experience Design Aspects] of [Client's Company Name]. [Client's company name] will provide detailed feedback on all aspects of [Project type] in accordance with the project plan. [Client's company name] will provide the necessary resources to be used in the project, including fonts, color schemes, brand standards, etc.

Assumptions The proposal section with assumptions is a good place to define what the client needs to be successful without leaving any room for discussion. That is, these are the things that you assume and communicate to the client, that they will have access to or that will be delivered to make the project a success.

CREATING AN OFFER

What you call assumptions in this section are actually expectations. It's much more polite to accept it. You can create as many project plans as you want, but if neither you nor the client are committed to meeting milestones and goals, both parties are committing to some project failure. In general, the assumptions are the expectation of resources and assets, as well as timely access (translation: fast, immediate) to both. Here is an example of how to write the assumptions: Assumptions [Client's company name] is committed to providing the following assets and resources. Failure to deliver these assets and resources in a timely and complete manner may contribute to the failure or delay of this project. The following assets and resources are expected: Timely access to all required employees of [Client's company name]. Timely access to all required [Project] resources in their current state, including source files if available. Content, if necessary, including but not limited to copies, images, audio, etc. for any aspect of the [Project].

Deliverables Deliverables are the work product you create and deliver to the client. This section is an opportunity to tell the client in detail what kind of work product they can expect from you during the project. It's recommended that status reports be handled separately closer to the end of the project, but you can add them to this part of the project. Provide descriptions of any work products that you can include, even if the work product has not been produced. This may seem like overkill or could potentially open a can of worms "I read about [delivery type] in the offer, but I don't see it here", but one little word can, can make all the difference. Outputs [your company name] provides a variety of outputs over the course of the project. We have identified the following delivery items for [Customer Company Name]:

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

Creative outline The creative outline is the first stage of the project. This document will help us create a quick and effective overall project overview. The purpose of the creative brief is to clarify the goals and needs of users and to define any special resources and/or constraints related to the project. E.t.c…

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

Contract work designs (known in the legal world as "contract work") are considered to be created by the party paying for the work and copyrighted by the party paying for the work, not the party responsible for actually performing the work. This means that when you work on a project that is contract work, you have absolutely no rights to the work, and everything you create for the project is owned by the client. This situation is difficult for many companies and individuals to manage: it often means no "maintenance" work (with their additional income), as clients can choose to maintain the project themselves after completion. . Don't get carried away with a project where the client is forcing the terms; it's not unheard of. When you put job-for-hire projects in the context of full-time employment with a company, it's pretty standard for an employer-employee relationship. This is also an opportunity to test their pricing model - many projects are billed at a slightly higher rate to compensate for potential lost revenue in the future. Remember, it all depends on the relationship you have with the client and how you choose to do business. Time and experience will help you make the right choice for the type of work you do and the price models you choose. Licensed Designs of Works allow you to retain copyright in the work, but give other parties the right to copy and/or distribute it. You can include any number of terms in your license agreement. Most likely, MAKING PROPOSALS

use licensing of your work if you retain ownership of all source materials for your work and provide your clients with limited work products only (such as PDF files instead of Word, Visio, Axure, OmniGraffle or other original and editable documents). You can take many different approaches to licensing your work, including licensing your work for use without modification, for non-commercial use, or in any number of other ways that may suit your situation. Creative Commons (http://creativecommons.org/about/licenses) has easy-to-understand explanations of the different types of licenses you can use, but that's only a small part of the world of licensing. If you are in a situation where you have very specific and specific needs, it is always best to contact a copyright lawyer to help you create the best possible solution.

Additional costs and fees It is important for the client to understand whether the price of the project you provide includes external resources. For example, some projects may require you to purchase stock photography from a vendor. You can purchase images (with appropriate usage rights) and include them as part of your rate, or you can explicitly specify image purchase as an additional cost that will be passed on to the customer. You can also offer services that you want the customer to know about - this is a good opportunity to promote these services. Here is an example of how to explain how additional costs and fees will be handled: Additional costs and fees Where external resources (such as content, images, fonts, etc.) are required, these must be identified, approved, and invoiced to [ Customer company name]. In addition, [your company name] is able to provide hosting services to our customers at very low overhead costs. We provide hosting services, including customizable web email, starting at $25 per month with a $25 setup fee. In the event that [Client's company name] wishes to purchase a "maintenance" package, [your company name] will work to create a package that is mutually acceptable and mutually beneficial.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

Project Quote Once you have documented the details of how you intend to do the project work, it is a very good idea to inform the client of the cost. How you set the price is largely up to you, but here's a tip: Estimate how long you think it will take to complete the project, including a certain number of revisions, allow a reasonable amount of project management time, which can be around 25 percent; then calculate the hourly rate you want to charge and calculate everything. There are different formulas that can help you with this, such as applying degrees of difficulty to each part of the project to help you find a range of costs that you can provide to your client. In most cases, experience will be the key to properly evaluating projects in hindsight and materials. How to determine the billing rate? See what others are charging to compare by locating contractor pay and rate surveys. For example, organizations such as the Institute for Information Architecture (www.iainstitute.org), AIGA (www.aiga.com), Coroflot (www.coroflot.com), and talent agency Aquent (www.aquent.com) conduct and research contractor rates . You can get a decent idea of the fees you can charge based on your experience, the fees charged by others in your market, and what you consider fair. Remember: you can always lower your bid. It's much harder to ask a customer to pay more money once you see the numbers on the page! There are many different ways to price a project. Depending on the nature of your project, you may need or want to provide multiple estimates to allow for different pricing options. For example, let's say you provide a client with two options: a static HTML site, and a site with a content management system (CMS) that allows the display of dynamic content (which the client could manage without dedicated resources). Here's how you can create a project estimate: Project Estimator [your company name] has proposed multiple cost estimates for [client company name] to provide the best possible options for your current and/or future needs. [Your company name] assumes that all content will be provided by [Client company name]. In the event that [your company name] is required to provide content services, the estimates will have to be redefined.

CREATING AN OFFER

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

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

Payment Scheduling There is a myth that all independent projects are paid 50 percent up front before work begins and 50 percent after the project is completed. This myth must be busted immediately! This is not the way to do business and it is not the way to ensure a steady and timely income while doing your job. You don't want to put yourself in a situation where you have to make changes after changes for a client just because you want to finish the project and get paid, instead of working through the change order process. You can price projects in a variety of ways, from time-based invoices to milestone-based payments. A smarter approach is to put projects on a recurring payment schedule with regular, itemized invoices. This approach should also provide clients with a clear understanding of what has been achieved and what work remains on the project. The following example shows one way to arrange payment for your work: [Your Company Name] Payment Scheduling A typical payment schedule is to receive a maintenance fee of XX% of the project's estimated total price before starting. [your company name] must submit invoices on the first and fifteenth of each month; full payment within 14 days. Upon completion of the project, [your company name] will be required to deliver all work products to [client company name]. Once materials are satisfactorily approved, [your company name] will refund the remaining advance payment overpayment or [your company name] will submit a final invoice for amounts not covered by the advance payment. Note: If [Project] is suspended for more than 14 days without progress, [your company name] will be required to submit a final invoice for any fees not covered by the advance payment and will be entitled to a preferred project resumption.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

Although not required, it's a good idea to include a note on how to handle the project if it is put on hold for an extended period. This disclaimer can help keep the project on track and moving forward, and it also gives you a point to discuss with your clients. Unless you're going to be doing extra work for them for a long time, you'll want to be able to move forward and look for a job to fill the void.

Confirmation and Approval While it's important to ensure that your proposal is on track, it's not enough. The proposal doesn't matter much until the right person at your client's company approves and signs it. It is very important that everyone has a clear understanding of what is going to happen and how much is expected of each party. It's equally important that you protect yourself from the "highway of iteration" and reduce the risk of customer involvement in a "feature change" - constantly asking for "one more thing" to be included. The captions are quite simple and clear. Once you've created the quote document, you'll provide your client with an acknowledgment and signature that validates the contract between the two companies. Always prepare two copies, one for each party, and make sure both copies are signed. Here's an example of an acknowledgment you can use: Acknowledgment This proposal has been fully accepted and approved by [Client's company name]. This proposal must be signed and dated by an authorized representative of [Customer Company Name] to be effective. Alternatively, a signed purchase order relating to this proposal will constitute acceptance of the signed document instead (provided, however, that the terms printed on such purchase order are deemed invalid). This proposal constitutes the entire agreement between the parties with respect to the subject matter of this proposal. This proposal merges and supersedes all prior oral or written agreements, discussions, negotiations, commitments, letters or understandings. This includes, but is not limited to, any statements made in sales materials, brochures or other written descriptive or advertising materials and constitutes the complete and exclusive statement of the terms of the parties' agreement. Each party acknowledges and agrees that, in carrying out this proposal, it has not relied on any statement or representation not set forth herein or in the Agreement, and expressly disclaims any reliance thereon.

CREATING AN OFFER

Accepted by authorized representatives: [your company name]

[Customer Company Name]

By: ________________________________

Name: _____________________________

Name:_____________________________

Title: _______________________________

Title: ______________________________

Data: ______________________________

Make all checks payable to: [your company name]

Statements of Works A Statement of Works (SOW) is a general definition of the project's objectives, which you should be able to put together in a two or three page document (not counting the title page). The SOW is usually written before going into the detailed requirements, although depending on the needs of the client and the project, you can create a hybrid document that best suits your needs. In general, the SOW should be used to build consensus between the team and the client's stakeholders at an early stage. The SOW will define the inputs and outputs of the project as well as the assumptions and constraints. At this point, it's not uncommon for clients to ask you for an "estimate number" of work you'll be doing for them. Answering this question at this point may be a bit risky. It is recommended that every effort is made to avoid details or compromises without defining details. It's simply impossible to know how much a project will cost if you haven't written an application and/or requirements document yet. Given that, you need to make an assessment at this point. If you're working on a project, such as a basic website, and you've successfully completed several similar projects before and/or worked with the same client before, you have some leeway. Remember, erring on the side of caution is always better than getting awkward later in the project. The job description should be about two to three pages long and contain at least:

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND SELF-EMPLOYED PEOPLE

Home Change history Project reference Project summary Start date End date Rate/Price Explanation of project activities and deliverables Detailed costs and payment schedule Confirmation and approval

Do the items look familiar? You should: You can create an SOW using a stripped-down version of the offer. You have now learned how to collect two types of documentation that will allow you to identify the work you are doing for the client. These documents should form the basis of any project work you do for any client, and will provide you and your clients with a well-defined set of roadmaps for your projects.

JOB LISTS

Project goals and focus Knowing which stars to sail to One of the keys to a good project is starting a team with clear goals and a well-understood purpose. Ideally, the project leader should define it for you, but how would you know if they don't? This chapter talks about formulating project goals and offers some questions to help you solidify those goals. We will also discuss some common project approaches (or methodologies) and how they affect the way you work. Carolina Chandler

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

Why is the project important to the company? How will stakeholders determine whether the project has been successful? What approach or methodology will be used in the project? What are the major dates or milestones for key points like getting

approval from business stakeholders? All these questions are about what stakeholders expect of the project: what the project will achieve and how they will be involved in it. The first two questions refer to the objectives of the project and the last two to the objective of the project. The goal of the project is to define the measurable goal of the project. Let's talk about goals in more detail.

Consolidate Project Objectives Objectives are an important focus lens that you will use throughout your project. They must be driven by the client's overall business strategy, so the project's goals must align with strategic initiatives within the firm. For example, if there is a strategic initiative to attract a new group of potential customers (a market), the website or application you are developing may attempt to provide that market with online access to relevant products and services. . The goal of this project would then be to focus on reaching and capturing this market. A clear purpose echoes throughout the project. Helps you ask the right questions when gathering information from business stakeholders Plan user research and focus on analyzing results Analyze and transform insights collected from stakeholders and users in detail

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

ESTABLISHING PROJECT GOALS

Create effective interaction designs Manage design change requests once development has started Focus efforts on implementation activities (such as training and communication)

communicating with users about a new website or application before and during its launch) Determining whether it met the client's needs, after

the project is launched When you start a new project, you probably have project goals for the project sponsor (the business stakeholder who is directly responsible for the success of the project) and a set of project-related requests from business stakeholders and customers, but all of these can be a bit confusing (Figure 4.1 ). Your goal is to explain this in strong statements that you can use as criteria for project success.

Project related requests

Company strategy Blurred purpose

The user needs an interested idea

blurred target

Stakeholder idea for user complaint

Figure 4.1 Confused goals, ideas, and needs

A solid goal is easy to understand. Avoid internal terminology. Separate. Avoid vague statements; instead, use wording that looks like

useful when prioritizing requirements. Measurable. Make specific statements that you can establish independence

Challenge yourself to determine your success. When you define a fuzzy goal by making it clear and measurable, it becomes a solid goal on which to base your decisions.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Figure 4.2 Fixed targets

Company strategy Project objectives

You will hear many statements that can be considered objective. Analyzing obscure ones like the ones below will help you solidify your goals and communicate more effectively within your project team. business spokesman

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

This is a company-wide goal, but too broad for a specific project. For this to happen, it is necessary to combine many initiatives in the company; Any site or app can help with this, but it's very unlikely that it can handle the entire load unless your entire business is dedicated to that site or app and it's a huge success. business spokesman

“Our goal is to evoke emotions among our customers.”

This one is better because the site or app can influence it, but it's still too vague. Why is creating illusions important? How does this enthusiasm translate into satisfying a business need? And how do you know if you've been successful? business spokesman

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

Now we reach the destination. This one is easy to measure but is too focused on the intermediate step. Suppose you generate more traffic - it might not help you if people don't take the desired action once they get there.

ESTABLISHING PROJECT GOALS

Fuzzy goals can give insight into the customer's desires and broader goals. Based on these, you can formulate stronger project goals, such as increasing your online sales revenue by 10 percent. Increase your online advertising revenue by 20 percent. Increasing the number of current and potential customers in our clientele

database to at least 20,000. Deliver highly rated and highly quoted content to our core users.

(Note that it takes some work to decide how to measure "highly qualified" and "highly referenced", but the elements are there to build on.)

Each of them can be measured and influenced by your project. They can also be very specific to your projects and the features you offer. For example, it is very common to offer an online newsletter as a means of achieving the goal of growing a customer database: to deliver the newsletter, customers' email addresses will need to be captured and added to the database. Objectives can also generate new requirements. For example, if you measure success based on the average rating of articles on your site, you need a feature that allows users to rate. In this way, the goals help you stay focused when gathering site ideas, and then you can turn them into design requirements. If there are multiple goals, be sure to create a priority list with your company sponsor and project team. Goals sometimes clash during design, and the team needs to know what takes precedence. The final list of priority goals should come from the project sponsor, but you can be a key part of the discussion. Let's talk about how.

How can a UX designer help? If you find that the goals of the project are not clear at the beginning of the project, you can apply your facilitation skills. Help the project team understand the business context of the project by holding workshops with key stakeholders (see the next chapter for more on identifying the right stakeholders). Your goal in this session, which typically lasts two to four hours, is to provide insight into your strengths and weaknesses as well

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

chances and dangers. Called a SWOT analysis, it is a common business analysis technique and a way to analyze a company's position in the market. You can also use this time to talk about the company's competitors. Understanding SWOT Strengths and Weaknesses in a SWOT analysis is the company's current strengths and weaknesses with respect to the project. Strengths and weaknesses can include both 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 great source of original research that is being published (strength), but there may be no one to help make that content public. average user. leading to the impression that the company is "too academic" (a weakness). Identify Opportunities and Threats CT is the forward-looking half of SWOT. Given the characteristics that set the company apart from the competition, what future initiatives could you take to open a new niche or strengthen an existing one? What situations can threaten these plans? For example, our R&D firm may decide to hire writers to publish more accessible articles on their original research (opportunity), but if your current site's toolkit doesn't have extensive content management features, the publishing process may be excessively slow. This could give competitors the opportunity to react faster (threat). Compare competitors What is the company's main competition? Who are the competitors of the developing site? They can be different, especially for large companies or new sites. Are there sites that are not direct competitors but represent interesting models to consider? You can learn a lot by checking other e-commerce sites to see if and how they sell what you sell. Put it together SWOT and competitive discussions are good topics to discuss at the same time as they interact with each other. it's hard to talk about it

ESTABLISHING PROJECT GOALS

future threats without knowing who your competitors are, and when you start talking about future opportunities, new competitors may come to mind. Once you have a complete picture of your company's competitors and a SWOT analysis, the project's goals and overall alignment of the project with the company's strategy should be easier to define and priorities should be clear. Recognizing the goals of the project helps to understand the expectations of what the project is supposed to achieve. Next, let's talk about expectations for how the project will be implemented. Understanding the project approach will help you collaborate effectively and engage the right people at the right time.

Understanding the project approach Knowing the overall project approach or methodology is an important part of understanding when and how you will be involved and how you should involve others such as the project team and business stakeholders. Sometimes there seem to be as many design approaches as there are projects. How to choose the right approach to a project is a broad topic in itself. The methodology chosen may depend on many factors, including the structure and location of the project team, the technologies used in the project, and the degree to which collaboration is part of the company's culture. For the purposes of this book, we assume that you joined a project where the goal was largely determined by those responsible for the project's success, such as the sponsor and project manager. In this situation, your main focus will be to understand the approach and help make it effective for business stakeholders and users. Here we will focus on the two most common types of approach, as well as a third that shows the possible variations you may encounter in your project. Keep in mind that most approaches involve the same steps: planning the overall strategy, approach and team structure. Define project requirements. Design interactions and visual concepts and turn them into details

Specifications. Develop, test and refine the solution.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Deploy the solution with news, training, and planned release. Evolve the project with recommendations for improvements.

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

The Waterfall Approach The waterfall approach is to treat the stages of a project as distinct and separate phases, requiring acceptance of one phase before starting the next. For example, the design phase does not really start until the requirements are approved by business stakeholders who sign one or more requirements documents at the end of the definition phase. Approval

Plan

approved

Define Project Develop Implement Extend

Figure 4.3 Example of a cascade approach where each phase "fades over" to the next

The problem with a pure waterfall approach is that it assumes that each phase can be completed with minimal changes from the previous phase. Therefore, if you present new requirements at the design stage, which is common, you should propose changes to the documents that were approved at the end of the definition phase, which may upset the plan and schedule.

Agile Approaches Because change is constant, project teams are constantly looking for more flexible approaches than the waterfall model. Many of the methodologies follow a more fluid approach, with some steps taking place in parallel; For example, website versions can be released on a fast, iterative schedule using an agile or rapid development approach. An agile approach tends to place more emphasis on fast collaboration and less emphasis on detailed documentation and formal approval. UNDERSTANDING THE DESIGN APPROACH

iteration 1

To develop

iteration 2

To develop

iteration 3

To develop

Implement Design Implement Design Implement Design Definiowanie

define

define approval

Plan

Deploy the launch extension

Figure 4.4 An example of an agile approach

A truly agile approach (according to best practices developed by members of the Agile Alliance, for example) requires small teams whose members are physically located next to each other, with little emphasis on defining formal roles among team members. Working this way allows for a high degree of collaboration, which reduces the need for extensive documentation between design, development and testing. A team member can ask a question, come up with an answer with other team members in a quick whiteboard session, and implement the solution without delay in detailed documentation and approval. Stakeholder reviews take place on a fully operational system when one of many iterations is released and the resulting inputs are taken into account when planning the next iteration. (Iterations are preview versions of a specific site or app.) When an agile approach works as intended, it's a beautiful thing. However, in most companies and most consulting jobs, teams rarely adopt a purely agile approach. In part, this is because companies are increasingly making use of distributed teams and remote workers, which makes it difficult to maintain the high degree of collaboration needed to take full advantage of a pure agile approach.

Modified Approaches Most projects try to take a best-of-both-worlds approach, with enough structure and documentation to reduce the risks posed by distributed teams and team rotation, but with enough collaboration and iteration to respond to changes in a relatively agile way. . For example, a project may follow a waterfall model but involve overlapping phases so that there are key points of collaboration between teams. It allows

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

potential surface changes earlier in each phase. This may also include an early release (such as a beta for a specific user group) with a shorter iteration cycle. Feedback from this release can be considered before the new site is fully deployed. Plan

define

Develop a project

Project

define

Develop a beta implementation

Deploy the launch extension

Figure 4.5 Modified waterfall with beta version

Notice the smaller design iterations in Figure 4-5. This is one of the greatest values you bring to your team as a UX designer. Tools such as wireframes (Chapter 11) and prototypes (Chapter 12) allow you to collect feedback on rapid iterations of ideas before much development time is invested. A modified waterfall approach, such as the one in Figure 4.5, is one of the most commonly used methodologies, so this approach is the framework of this book. However, many of the topics covered here will apply to your project regardless of the specifics of your approach, as the basic activities behind them (for example, definition and design) are still necessary.

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

UNDERSTANDING THE DESIGN APPROACH

Sixty-five

How does concentration affect me? Knowing your approach helps you understand a lot of things: what questions to ask and when. For example, if you are

Working with a pure waterfall approach, you will need to ensure that the requirements captured in the Define phase contain all the information needed in the Design phase. (We'll cover the requirements in the next chapter.) Expectations about how project team members will work together and how

how close the cooperation will be. For example, an agile approach requires very close cooperation. The cascading approach can in most cases involve individual work, with touchpoints once or several times a week. The level of detail required in the documentation and level

formality. Documents presented at acceptance points must be formal, almost like legal contracts. Typically, you will need more formal documents in a waterfall approach where approval is required before proceeding to the next phase. However, when using an agile approach, you may also have formal approval documents, for example, to capture information at important decision points, such as when preparing a specific iteration for full release and deployment. Important milestones that require stakeholder approval and

Deploy to different groups. This approach will determine what different audiences need to provide at different points in the project, including stakeholder approvals at endpoints and feedback from potential users during the beta. Now that you have established your project goals and understand the design approach, in the next chapter we will begin the main work of the Define phase: gathering requirements.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Business requirements Understand the problem before creating a solution By the time the project team meets, you'll probably hear or come up with a lot of ideas about what needs to be done. There may already be lists of features provided by some prominent members of the company (business stakeholders), along with their thoughts on the most important features. These are the business requirements elements for the project and are a good start. To provide a complete solution at the end of the project, you need to generate and explain the requirements from multiple points of view. In this chapter, we will focus on gathering and detailing the requirements of business stakeholders. Carolina Chandler

Chapter 4 covers confusing goals and discusses some ways you can help clarify them for yourself and your project team. In the early stages of your project, you'll likely have a relatively confusing set of requests. These can be stakeholder ideas, user complaints, or user requests. To make these useful and traceable components of your project, you need to combine these ideas into requirements. Requirements are statements that specify what a site or app must do. Ideally a business requirement Provides insight into the overall need that needs to be met Represents and consolidates the needs raised by various stakeholders Provides direction for the project without being too specific about what it will look like

achieved Serves as a separate unit of work for prioritization and tracking

This is an example of a feature idea on an eCommerce site. At the beginning of the Define phase, you may get the same idea from several different business stakeholders: "Customers can track their orders online." This is a good basis for the requirement, but it is confusing. Start asking questions that will lead to the details of the requirement, such as Why is it important for the company that customers can follow them

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

If not, new tracking requirements will need to be addressed, or the company may have to work with a third party. How accurate does tracking need to be? What kind of information

should be included in the tracking details? For example, does the site have to provide an up-to-date estimated delivery time? Asking these types of questions will help you combine confusing ideas into strong demands. It will also explain that the same statement can mean different things to different people.

SECTION 5: BUSINESS REQUIREMENTS

For example, a stakeholder might think tracking packages involves receiving an idea confirmation email from the stakeholder along with a tracking number that can be entered on UPS.com or another site so that the interested customer can see the tracking number. arrived. Idea Another stakeholder might think that the company needs to go further with parcel tracking and invest in developing the ability for customers to track parcels using GPS, seeing the exact location in real time using an online map. As you can imagine, there is a significant difference in user experience and reach here! It is important to outline these differences early in the project. Otherwise, you'll end up developing a solution that bypasses the business stakeholder's intentions and potentially bypasses the project goals. This leads to stakeholder dissatisfaction, and if a feature needs to be redesigned, time and money are wasted. Therefore, clear and detailed requirements are a key part of the entire project. Getting to a consolidated list of project requirements involves the following steps: 1. Understanding the current state of your site or its competitors. 2. Collect the needs and ideas of business stakeholders and current and potential users. (See Chapter 6 for details on working with users.) 3. Combine ideas into requirements. 4. Prioritize requirements based on project objectives. (See Chapter 9 for prioritization tips.)

Business and user Project Requirements Requirements Company strategy

Category

subcategory

Article

Figure 5.3 Diagram showing the conditions and relationships in the project

A common vocabulary for the deliverables to be used in the project will also help stakeholders understand the process and the type of outcomes they can expect. This can build confidence that your time and effort will not go into a black hole of ideas. In general, if you find yourself defining the same words more than once or twice (especially if the definitions change slightly each time), consider including them in the project glossary and sharing it with the project team. Other examples of terminology that are good to clarify at the beginning of the project include:

SECTION 5: BUSINESS REQUIREMENTS

Roles that will interact (for example, job seeker vs. client or

tent manufacturer vs. publisher) Core products that will be commonly referenced (functional specification

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

see Figure 5.3) Distinguish between needs and ideas

Listen to ideas and delve into needs Stakeholders can make claims that sound like needs. Consider an example. business spokesman

"We need a blog on the site."

This is really an idea, not a necessity. If blog functionality is fully designed and implemented, it becomes a solution, but not necessarily the solution that best meets the basic needs of stakeholders who ask for it. Asking why a blog is important can trigger a wide range of needs statements such as “We need to appear relevant and connected. Everyone's talking about blogs, and I feel like we're going to fall behind if we don't include them." "We need a way for people to visit the site again and again to generate more ad revenue, and blogging means newly published content that has followers." "We need to position ourselves as opinion leaders, and blogs are a more personal way to show our expertise." "We need to have a better way to communicate and innovate with our customers, and blogs provide us with feedback so we can hear what you think." Each of these statements describes important needs. By bringing them to light, you'll learn about the drivers behind feature requests, which will help you build consensus when consolidating and prioritizing requirements.

COLLECT IDEAS FROM STAKEHOLDERS

Merger Requirements At the end of the meetings, collect the collected ideas and break them down into general areas of functionality. You will start noticing a lot of overlays; it is a good sign that the idea is widely accepted by stakeholders. Eliminate redundancies and try to consolidate a list of ideas that effectively captures stakeholder intent. To turn collected ideas into useful, traceable design components, you need to combine these ideas into requirements. Think of raindrops forming from a cloud: you go from a large, undefined cloud to more well-defined raindrops. So when you get a thought cloud like "Customers can track their orders online", you need to turn it into separate statements that state what the system should do. The resulting requirements should give you an idea of the overall need that needs to be met. Represent and consolidate the needs reported by various stakeholders. Give direction to the design without being too specific about what it will look like.

achieved Serve as a distinct unit of work for prioritization and tracking

As you start moving from ideas to requirements, make sure your technical lead (or someone else who can represent the development team on your project) is on board to ask questions to help gauge the effort required when prioritizing. forward. If you have a dedicated QA team member, that person may also ask a few specific questions to help frame your requirements. To detail the idea of requirements tracking, ask questions like How accurate does tracking need to be? What kind of information should be included in the tracking details; Down

For example, do we need to provide an updated estimated delivery time? These types of questions can be asked and discussed in detail with the stakeholders who gave you the original idea if they have a lot of time devoted to the project. If you don't have much access to these stakeholders, you can work out the details yourself through discussions with the project team.

SECTION 5: BUSINESS REQUIREMENTS

then review the requirements with the project sponsor to ensure your choices make business sense. Table 5.1 lists the types of requirements that can arise from a traceability concept and how to capture them. BOX 5.1

Example of business requirements

AREA

Order tracking

REQUIREMENT

BUSINESS NEED

Orders can be tracked by

encourage self-service

entering the tracking code

during delivery (Support

online

advantage)

Users can track their package -

Show innovation in performance

age by gps, truck tracking

Efficient delivery (Competitive

or airplanes

advantage)

Users can see all previous orders Encourage follow-up orders and orders placed within the last 365 days

self-service (sales, support benefit)

Note that in some cases the requirements overlap, as in the first two requirements in the table: both are tracking methods. They can live together in the same system because you can enter the code to find your package in the GPS view. However, they are separated as the GPS requirement is likely to be more of an effort and should be prioritized regardless of other features. When consolidating your listings, consider any business requirements that you believe may conflict with your users' needs. For example, a business requirement might be to collect personal information from potential customers, such as their email addresses. But customers may have reservations about providing information. After all, filling out forms takes time, security and privacy are an issue, and this step can interfere with the larger task they are trying to complete. Once you identify such conflicts, they start to provide you with ideas that can help meet your business and user needs. In the tracking example, you might suggest using the "Send to a friend" feature to capture the email address for user convenience. This means the Send to a Friend feature could become a requirement in the prioritization mix. such ideas

COLLECT IDEAS FROM STAKEHOLDERS

can help meet business and user requirements, so it's great for capturing them. They are also in this overlapping area between the Define and Design phases (see Chapter 4) as you begin to think about designing solutions to business problems.

Define Design, Develop Potential conflicts between business needs and users are excellent things to explore in user research, which we'll cover in the next chapter. User research will also expand Table 5.1 with a full set of potential requirements to be prioritized in the Design Requirements List (shown in Figure 5.1 and discussed in more detail in Chapter 9). Remember that collecting business requirements usually takes place in parallel with exploring technical possibilities and collecting user requirements. Next: It's time to talk about users!

SECTION 5: BUSINESS REQUIREMENTS

User Research Get to know the guests you're inviting 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 in different versions of the venue. In this chapter, we will focus on some of the methods that are most commonly 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 into context, and evaluate the performance of the current site (if any) using experience design best practices. user. . Carolina Chandler

Basic User Research Steps 1. Define basic user groups. This includes creating a framework that describes the main types of users you're designing for, allowing you to focus your efforts on recruiting users for research. 2. User Participation Plan. This includes choosing one or more techniques to engage user groups in the research, depending on the needs of the project. 3. Investigate. Here, we will discuss basic techniques such as interviews and surveys, and give tips on how to approach them. 4. Verify that the user group definitions are correct. Using what you've learned from your research, you can solidify your user group model. This model will then serve as a platform for developing more detailed tools such as characters (discussed in Chapter 7). 5. Generate user requirements. These are lists of features and functions that the site may contain. You will add these statements to your business requirements (discussed in Chapter 5) and prioritize them to become design requirements (discussed in Chapter 9). In this chapter, we'll cover the first three steps, starting with the first one: defining user groups.

Define your user groups Planning user research at the beginning of a project can seem like an egg or chicken dilemma (which comes first?). How do you make sure you're talking to the right people if you don't already know who they should be? One way to get started is to create a rough or pre-definition of the users you will be designing for. Describes the main groups of users on your site, which can help you focus your research efforts on the right roles, demographics, or other variables that may affect how users will use your site. User group definitions can be high-level (a list that defines each target user group) or detailed and visual (a diagram showing different types of users and how they interact with each other).

CHAPTER 6: USER RESEARCH

The general definition of a company's primary .com site may include the following user groups: prospective buyers, existing buyers, partners, and job seekers. As you start defining groups for user research, you'll begin to prioritize user groups in more detail. Their initial definitions are based on the collective knowledge of business stakeholders and project team members about the potential types of users who might interact with the site. These definitions can be built by collecting some goals and attributes that different groups of users may have. Here are the basic steps to define user groups: 1. Create a list of attributes that will help you define the different users of your site (we'll cover some of the more common ones in the next section). 2. Discuss the attributes with people in your company who are in contact with the relevant types of users (e.g. customers). 3. Prioritize the attributes that seem to have the greatest impact on why and how a potential user will use your site or app. 4. Define the user groups you will focus on in your research and design. In the following sections, we'll take a closer look at some brainstorming techniques to help you gather these attributes, and how to prioritize and model them (creating representations of different types of users to help you focus your research efforts).

Create an Attribute List A good start to creating an Attribute List is to collect and assimilate any research or other documentation from your organization that may provide guidance on users. Here are some potential sources: Documents explaining company strategies, such as company goals,

competitor information, marketing strategies and business plans Current customer market segmentation and other demographics

collected by marketing Previous user research (examples in Table 6.1)

DEFINE YOUR USER GROUPS

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

Then identify the people in your organization who have an idea of current or potential users. The number and variety of people to be included depends on the type of project and its scope and timing. If you know that the initial definition of your user groups may have a short lifespan (for example, it's only used for a month or two while user research is planned), then you can only include two or three participants. If you feel that the initial definition might need support for most of the design process (for example, if you only have that definition to work with until you do some usability testing after you've done some of the design), include more participants and make sure you have a cross-section of perspectives. Some potential participants are marketers responsible for brand representation, segmentation and campaigns; sales staff; product managers; customer service or support representatives; and trainers. It is also a good idea to involve project team management and other business stakeholders in this exercise. Ask the group to think about the different types of potential users they tend to interact with. Then ask them to list some of the common characteristics they found. Here are some examples of what may vary: Your site's main theme goals. Why

users coming to it and what are they trying to achieve? For example, buying an item, exchanging shares, or answering a specific question are common goals. Identity documents. This can be defined in many ways, but one way is to bind roles to

main purpose of the user: job seeker, support seeker, potential client, etc. As more information about the users is obtained, the roles can be divided according to different needs or styles; For example, on an e-commerce site, buyers may be bargain hunters and insiders. Demographic information including age, gender, family (single, married, children),

income level and region. Experience, including education level, language proficiency level

technologies (often referred to as technical knowledge), level of technical knowledge and frequency of use (single, occasional, frequent). 88

CHAPTER 6: USER RESEARCH

Organizational attributes, including work size for business users

for your department, job type (entry-level, freelance, mid-management, executive), seniority (long-term or high turnover?) and work patterns (remote work, amount of travel). Once you have a list of some of the attributes that come up most often when stakeholders describe potential users, you can prioritize them by their level of importance, and then use that hierarchy to start defining and modeling user groups.

Prioritize and Define Which of the features listed above do you think have the greatest impact on how and why different user groups can use your site? Focus on the ones you think will have the greatest impact on the user's goals or behavior. Prioritize these attributes and remember the goals you created in chapter 4; they will also help guide your choices. The example better illustrates how to prioritize attributes. Suppose you work with a company that provides tools for online trading in stocks, options and futures. This particular company has determined that part of its strategy will be to involve people who trade stocks online on their own and encourage them to try out trading new types of products such as options and futures. The company plans to do this by providing business tools that are easy to use and designed for those who want hands-on learning in a safe environment. When discussing attributes with business stakeholders, the following factors may seem to have the greatest impact on how people can use these tools: Current transaction frequency, in particular the frequency of direct online transactions.

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

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

The level of subject matter knowledge (for example, knowledge of trade

conditions). This will help determine how much help they'll need along the way, with tutorials and glossaries. Level of technical knowledge (for example, knowing how to shop

online and online banking and commerce). This will influence what security they need in terms of data privacy and how advanced or simple the online interface needs to be. You can prioritize these attributes as they can affect the types of users you'll be targeting. If it appears that where traders live has no real impact on how and why they trade, the Region attribute can be removed from the list as a note to study participants. On the other hand, if the importance of an attribute causes a lot of discussion, it might be a good topic for a survey or interview question (more on surveys later in this chapter).

Alt

Comparing two or more attributes can also help prioritize. For example, if you create a chart using two attributes for e-retailers, you can start to see how groups fit into certain ranges. Figure 6.1 shows an example of a rough user model that can be created using the two attributes Direct Trading Frequency and Number of Product Types Traded; it also shows the resulting user groups that can be created from discussions.

Full-time product specialists

Full-time general experts

Direct trade frequency

Second job sellers.

Extra Income Sellers

active explorers

long-term investors

Short

lovers

Short

Alt

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

CHAPTER 6: USER RESEARCH

Figure 6.1 A two-attribute plot representing the approximate user model. Building this model together can facilitate discussion of potential differences in user experiences and motivations.

This user model provides a general way to discuss different types of users. It is not intended to be a definitive model and does not imply user groups only (a user can be a long-term stock investor as well as actively exploring other options or futures opportunities). But it starts to express your understanding of different user groups and how they might be motivated to use your site. This overview of important attributes will also help you determine which ones you'll want to focus on when recruiting users for research. If you decide that trading frequency is important and your priority will be to engage those who currently have an average frequency level, you will want to define what average frequency means (for example, one to three times a week) and recruit participants with your research accordingly. Speaking of research, let's talk about techniques you can use to engage users in your project.

Is it possible to design only from user models? In the field of user experience, there is debate about creating user models before doing research, because it can affect their thinking before they get actual user data, and because the project team or project sponsor may view the model as a replacement for user research. Using an unverified model introduces a greater risk that your assumptions are wrong. However, in projects where you will not have any contact with the user, a well-thought-out model (verified with sources outside the project team, such as a customer service group or training group) is better than no model at all. . while designing.

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

SELECTION OF TEST TECHNIQUES

POLE 6.1

Typical user research techniques

ACTIVITY

WHAT IS THIS

WHEN IT IS USEFUL

SIMPLE

TYPICAL TIMEFRAME *

Interviews with users

A one-on-one conversation with a participant belonging to one of the main user groups of the site.

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

Get direct feedback. Gathering information about attitudes and context can be difficult, especially if interviews are conducted remotely.

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

contextual research

Site visit with participants to observe and learn how they work in their normal, everyday environment.

The Gaining Access project team has little information about the participants. Going to target users. to the environment of users may raise concerns about intellectual security (e.g. hospital). property, and intrusive users work intensively. For companies with fairly complex applications, tasks or workflows. may be easier to visit on a weekday.

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

surveys

A series of questions consisting mainly of closed-ended (multiple-choice) answers that are used to identify patterns among a large number of people.

You want to express the results more quantitatively (for example, "80% of the target user group said they never buy cars online").

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

You want to get the context, but you can't go to the user.

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

CHAPTER 6: USER RESEARCH

Get a suitable sample. Make sure the questions are well written to get accurate answers without forcing respondents to a specific answer.

POLE 6.1

Common User Research Techniques (continued)

ACTIVITY

WHAT IS THIS

WHEN IT IS USEFUL

SIMPLE

TYPICAL TIMEFRAME *

research group

A group discussion where a moderator guides participants through questions about a specific topic. It focuses on discovering participants' feelings, attitudes and ideas about a given topic.

The team believes that user attitudes will have a big impact on how they use the solution (e.g. whether there have been problems in the past).

Learn how to direct questions to get the right information.

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

card sorting

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

You're working on a multi-element content source site and need an effective structure for your user groups.

Determine which topics are best covered.

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

usability test

Users try to perform common tasks on the site or app while the facilitator observes and in some cases asks questions to understand the user's behavior.

The existing solution is improved.

Choose the right tasks you want to focus on.

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

Competitive solutions are available for you to try. It has a prototype that allows users to perform (or simulate) tasks.

Help the group effectively.

Specify how to formally approach the test.

* Typical time slot represents the time that often elapses from when users are scheduled. Two groups of six to eight users are assumed (except for surveys, where the number of users must be larger). This does not include recruitment time, which may take a week or two after the creation of the recruitment questionnaire.

How many research activities can I include? Before choosing between activities, ask yourself how much money and time your team can allocate to user research. Consider the following scenarios to understand how hungry your client company is for user research. If the project management and project sponsors are happy with the user research and are interested in using it for known purposes, such as making sure the site meets the project's stated goals, you will likely have more leeway.

when scheduling two or more activities, or one activity that you perform multiple times (for example, testing a project, changing it based on the results, and retesting a new project). If no one in your organization is familiar with user research and there is some resistance, it's best to propose a round of research and choose the technique that you think will bring the most value to you, the project team, and the project's business stakeholders. Once the research results are in place, the project team will have a better idea of what is involved and what benefits it can bring to the project. Then you will have strong arguments to do more research later if necessary. If you have room for at least two rounds of research, it's a good idea to include one round in the definition phase or early design phase to better understand your users. Then run one more round before starting development to verify the design. For example, for a task app, you might interview users before designing, then conduct usability testing on the prototype later in the process. Or for a content source, you can start with a contextual query and then include a tab sorting exercise.

Considerations when planning research When planning any research technique, consider the following: Why are you doing the research: what do you want to learn from it Who are you: the main user groups you described above How to get participants: recruit people to participate and select them (i.e. ask questions to make sure they belong to the target user groups) How will you compensate participants What space and equipment will you need What do you do: main topics How do you gather information: number of people involved and the tools they use Chapter 13 will discuss each of these issues in as part of an in-depth look at one of the most common techniques used by UX designers: usability testing.

CHAPTER 6: USER RESEARCH

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

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

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

User Interviews User interviews are structured conversations with current or potential users of your website. These can be done over the phone, in person in a neutral location (such as a conference room), or preferably in an environment where the user is likely to use the site. (The latter situation is also excellent for contextual research, discussed below.) Interviews help to understand participants' preferences and attitudes, but should not be used to make formal statements about actual results. If you're looking for specific information about how people interact with your site, it's better to observe how they use it (for example, in a contextual query) or ask them to complete tasks on your site (during usability testing). Site analytics can also provide insights into some performance information that can be particularly robust when combined with interviews or queries that provide context for the data. Basic process For user interviews, the UX designer creates a list of questions that are designed to gather information such as: Relevant experience with the site or topic.

SELECTION OF TEST TECHNIQUES

The company's brand as perceived by the participant Attitudes, e.g. towards the thematic categories discussed (for

tent source), design process (in the case of a task application) or marketing methods (in the case of a marketing campaign) Common goals or needs that drive users to your website or website

competitor Typical next steps that users take after visiting a company's website Other people involved in the experience. for example

Does the user tend to collaborate with another person as part of a larger goal they are trying to accomplish? Will they share information or ask others for opinions along the way? Any other information that will help verify the assumptions made.

fact about user groups up to this point; For example, if the variables you discussed when creating the temporary user model really seem to affect how users use your site. If more than one person is interviewing, it's a good idea to have a set list of questions and an introduction that can be used to keep the interviews consistent. Decide in advance how you want to structure your interviews. If you're looking for a formal report, you'll probably want a high degree of structure where the order of the questions doesn't vary much and all questions are asked with a few extras. If data richness is more important than consistency, you can opt for semi-structured interviews where you start with a list of questions but let the conversation follow its natural path, with the interviewer asking questions to further explore interesting comments. (what we call a probe). ). Interview length may vary; 45 to 60 minutes is usually the best range for shooting. It gives you plenty of time to build rapport and discuss a wide range of questions without participant fatigue. User interviews provide a rich set of data that can be used to create personas, which are discussed in Chapter 7.

CHAPTER 6: USER RESEARCH

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

It is assumed that the user likes using the website. Only use this question if you are also asking what they don't like about it. Does PseudoCorporation.com meet your expectations?

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

and if the latter, why do you think they are better than Pseudo? There are several problems with this: you are asking two questions in one statement and forcing an implicit opinion on the participant. Better to ask the following questions: Tell me about your last visit to PseudoCorporation.com. Why did you go there? What do you remember from your visit?

If you are conducting a large-scale, more formal interview series, you may want to include several multiple-choice questions. However, most of them do not provide too much information. They can be difficult for participants to follow when asked verbally, and do not allow users to elaborate. Generally, reserve these types of questions for filters or surveys. Test with someone, perhaps someone in your organization who is not a member of the core team. This will help you uncover questions that may not be clear and will also help you refine your timing and mileage. If possible and with the participant's consent, record the interview so that others can benefit from hearing the answers directly from the participant's mouth.

SELECTION OF TEST TECHNIQUES

Contextual research Contextual research combines user observation with interview techniques. The UX designer focuses on the participants, preferably the environments in which they are likely to use the site. For example, for an office application, a contextual query would require you to sit at a participant's desk. This method provides valuable information about the context in which the participant works, including the actual problems users face, the type of equipment they work with, the space they work in, in particular the amount of space they occupy.

they have, how much (or little) privacy they have, how often they have been disturbed, and how they use their phone and paper (pay special attention to any printouts they have posted or notes they have on hand). Your mouse and keyboard usage preferences. This can affect a lot

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

resources. For example, if more than one person uses the same computer, it will affect the design of 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 an online solution that competes with paper ones. Consultations combine the time of observation with the time of the interview. They can last from several hours to several days. If participants cannot commit at least 2 hours, consider simply conducting an interview. During the observation, the participant needs time to adapt to your presence and behave quite naturally, and this does not happen after just 15 minutes. Basic process Prepare a 10-15 minute introduction that you can use in conversation with each participant. It should include the purpose of the survey, a general description of what you will be doing together (observation and interview) and how

CHAPTER 6: USER RESEARCH

the information will be used. This is also a good time to collect signatures on consent forms and assure participants that what they share will remain confidential. Start with some general questions about common participant processes, especially those related to website design. Inform the participant when you are ready to stop talking and start observing. Observation can range from active to passive. With active observation, a common approach is for the participant to assume the role of the teacher while you assume the role of the student. The teacher explains what he is doing as if he is teaching you his process. Active observation often gives more information about the reasons for the participant's behavior, but it can influence the way the participant works. In passive observation, you encourage the participant to act as if you were not there. Your goal is to observe the behavior as natural as possible. For example, if a participant is talking to you, they're less likely to answer a call or ask someone a question about a problem you're trying to solve, but if they're passively watching, they're more likely to see it. happen. You can then continue part of the interview to ask about the reasons for some of the observed behaviors. Either approach can work well. In general, if you don't have a lot of time with attendees (say only 2-4 hours each), you may opt for active follow-up to make sure you get the details you need. If you have a full day or more, passive observation strikes a good balance between natural behavior and discussion. Once you've got information from your queries, you'll have plenty of rich data to sort through! So how do you identify patterns or trends in your results? One way that is useful is a technique called an affinity diagram. There are lots of great resources available on the subject, but here's a quick overview. A Quick Guide to Affinity Diagrams Affinity diagrams are a technique that takes many distinct and separate items (such as user statements or researcher observations) and group them together to create patterns and trends. Here are the steps for a simple affinity charting session: 1. Gather the investigation team together with their notes.

SELECTION OF TEST TECHNIQUES

2. Give each person a pack of sticky notes and ask them to write a statement on each one, along with a short code that allows you to trace the statement back to the participant, for example, their initials. Focus on statements that seem to be relevant to the site's design, either specifically (description of features) or more generally (a statement that represents the attendee's attitude to the company or topic). 3. Ask everyone to stick their sticky notes on the wall. You'll need a large blank wall if you're working in a large studio; try to get one to which you will have access for at least a few days. 4. When all your notes are ready, start grouping similar statements side by side. This part of the exercise may involve a larger team. This is a great way to start sharing results. 5. Once the groups start to form naturally, start labeling them for better structure. If some sticky notes belong to more than one group, you can write duplicates and place them in each appropriate group. Note This method works well for contextual research, but can be used in many other situations. For example, it's a great way to cooperatively create categories for unstructured topics, so it can help bring your card sorting results to additional levels of structure.

Patterns can take many forms, so it's best to let them create themselves. However, here are examples of the types of categories you might see, including the type of statements you might find in them: Objectives: "I try to clear all open positions before I'm done with the day." Mental models (includes statements that show what users are like

mapping external experiences to internal thinking): "I use this online tool as a folder for things I refer to often but don't want to take with me." Ideas and feature requests: "I wish this would let me undo. I follow

I accidentally moved a whole folder and it's taking me forever to undo it." Frustrations: "I'd ask tech support about it, but half the time they don't."

I don't know what the problem is either.

100

CHAPTER 6: USER RESEARCH

Workarounds: "Here it takes so long to finish printing

list and work with it throughout the day. Then, at the end of the day, I move on to the results." Value statements: "This tool here saves me a lot of time, so if you do

Change won't take it away!

Deep diving The quintessence of contextual research is Contextual Design by Hugh Beyer and Karen Holtzblatt (Morgan Kaufmann, 1997). The book also provides detailed information on how to interpret the results using techniques such as affinity diagrams. For more information on mental models and how to understand them, see Mental Models: Aligning Design Strategy with User Behavior by Indi Young (Rosenfeld Media, 2008). This is especially useful when working on the information architecture for a content source.

Surveys Surveys consist of a set of well-defined questions that are distributed to a large audience. In most cases, they consist of closed-ended questions (such as multiple-choice questions) that can be easily collected using a tool that can show patterns among the answers. Surveys are a good tool if you want to express results in a more quantitative way (for example, "Of respondents, 82 percent of people working from home say they have some kind of high-speed Internet connection") than anything else. get with the types of open-ended questions used in interviews. However, you can also collect qualitative information from them regarding the habits and attitudes of users. In the field of user experience, surveys are often used to measure user satisfaction (with existing sites or apps) or to create or validate user models such as segmentation or personas.

SELECTION OF TEST TECHNIQUES

101

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

or for attitude questions with a range of different options: Read the following statements and mark to what extent you agree or disagree with each one. Pseudo Corporation's customer service is responsive to my needs. Strongly agree Agree Neither agree nor disagree Disagree Strongly disagree

In particular, questions like the second example are often used to complement usability testing tasks. You can use this type as a follow-up question to find out if participants were frustrated with the task. Participants do not always like to voice negative feedback out loud, but they are often willing to express it in the face of a rating system. This highlights another point: surveys are a great complement to other forms of research you might be doing, such as user interviews or contextual queries. The combination of two research methods gives a more complete picture of the user than a single method can give.

102

CHAPTER 6: USER RESEARCH

Navigation If you want to have a high degree of confidence in your results and have the budget to do so, formal tools are available to measure user satisfaction in terms of ease of use. These tools include questions that have been tested to ensure they do not mislead a wide audience. Some of the most commonly used are ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Website Analysis and Measurement Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory): http://sumi.ucc. i.e

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

Use a temporary model to determine this. How you answer the other questions here will matter. Which survey distribution method will give you the best results?

If your main user groups tend to congregate in one particular place, you can get more results by going there and setting up a table for people to fill out a paper survey. If your user groups are active internet users, an online survey may be the best option for a large number of participants. You may also decide that phone surveys using a list of existing customers are better for your group of users. How much time participants are likely to be willing to spend on completion

Test? If you are providing some kind of compensation or other benefit from completing it, you can usually create a longer questionnaire that takes maybe half an hour to complete. If not, you need to shorten it so people can complete it - think 5-10 minutes. Either way, make sure participants get an estimate of how long it will take, and keep them updated on your progress (use page numbers like "2 out of 4", or show percentage complete).

SELECTION OF TEST TECHNIQUES

103

How will you know when to start analyzing your data?

You can participate in the survey until you reach a certain number of participants or until a certain cut-off date, whichever comes first. What tool will you use to collect and analyze data?

If you're conducting an online survey, the data collection tool you use may have options to view and analyze the results. If not, you will need a data input method for the tool of your choice. For paper surveys, this means a lot of data entry, so make sure you plan for that time.

Focus groups Focus groups are about bringing together different people in a target group and facilitating discussions with them. The common goals are to get feedback on topics relevant to the organization or its brand, such as past experiences, related needs, feelings, attitudes and ideas for improvement. A focus group is a good technique for several purposes: Listen to different user stories. Open discussion is a great way to contribute

the narrator in all of us. When a focus group does well, people build on their stories and ideas and recall situations they might not have encountered in a more structured one-on-one interview. The form and energy of the group can give people the time they need to remember and share these stories. Understand the significant differences in experiences. Most people are naturally

people who share information about rural areas and want to compare their favorite tools with other tools in their interest group. You can often get information about competing sites or services, or hear suggestions for workarounds, resources, and support. Generating ideas. Although you don't want the pool itself to be

As a designer, you often get great ideas for new features or designs, either directly from the group or by listening to your work processes or frustrations. As with stakeholder ideas, be sure to trace them back to the main need (see chapter 4) to ensure it is addressed. Understanding the many points of the collaboration process. if you are

designing a process that involves multiple related roles and collaboration, groups can be a great way to bridge gaps in understanding

104

CHAPTER 6: USER RESEARCH

how people interact. For example, if you are working with a content source such as an intranet, it can be helpful to bring together a variety of content creators, content editors, and content consumers to identify where the process can be improved. There is a lot of discussion about the use of focus groups in UX research. This is not a good usability testing technique (since users often work individually rather than in groups), and sometimes group settings can unduly influence participants' speech. However, if well planned and facilitated, focus groups can provide many insights that will be valuable to you as you design. Chapter 13 discusses this in more detail in the context of proof of concept. Basic Process When writing focus group questions, keep in mind the same guidelines you would use when writing user interview questions (discussed above). Start with easier questions like "Tell me about your last visit to PseudoCorporation.com. Why did you go there?” Leave any brainstorming questions at the center of the group when participants are comfortable with you, each other, and the topic. Assign blocks of time to each topic and stick to them; discussions are easy to really get moving and it's time to sneak out! If you're concerned about time, put your most important questions in the middle of your list of topics, after people have raved about the activity, but before the potential time crunch that can occur towards the end Most focus group logistics will be the same as for usability testing (Chapter 13 contains suggestions for selection, recruitment and planning). allows participants to easily interact with each other Take a photo of six to eight people for a 1-2 hour group session Give each person a badge or business card by their seat so that everyone can call each other by name. The format of the discussion itself should include an introduction that often addresses these key points: your role as a moderator and what you hope to get out of the discussion.

(for example, some of the points above).

SELECTION OF TEST TECHNIQUES

105

Why the participants were selected to participate (for example, "You are everything

current users of the Pseudo Corporation website and have brought them together to find out about their experiences"). How this information will be used, both in and out of the project

confidentiality point of view. That as a moderator you are there to listen to their opinions and

experience. You want them to feel they can share honestly, so ask people to be direct but also respectful of others in the group. That there are many topics to discuss, so at some point you will finish

Cover one topic to make sure you can cover them all. This can turn into a round of performances for group members, often including an ice-breaker question. Your goal is to get everyone talking about the first question, even if it's just a short story. You can start with one person and work around the table, or you can let people respond naturally and then call those who didn't respond by name. This often ends up with the first few questions around the table, and then when you feel the group is ready, you can use body language to open up the questions to everyone.

Snorkeling: Body Language A good understanding of body language can be an amazing tool when facilitating focus groups or any in-person user research. It can help you understand when someone is frustrated, excited, angry, or threatened, so you can determine when you should try to make someone feel more comfortable or ask for a specific comment. The following book on the subject may take more than a weekend to read, but it's designed to be easily browsed: The Definitive Book of Body Language, by Allan Pease and Barbara Pease (Bantam, 2006).

When you call someone who hasn't answered yet, repeat the question in case you missed it or missed the last one.

106

CHAPTER 6: USER RESEARCH

some comments in the discussion. Also, avoid making a disagreement look like a disagreement between two people. Don't say, "Bob, we haven't heard from you yet. What do you think about what Chris just said? but rather (looking at Bob), "And you, Bob? What experience have you had with Pseudo Corporation's customer service? As a moderator, you control the course of the discussion and hand over a virtual microphone. You maintain control through eye contact, speech volume, arm movements, and body orientation. Most people will be very aware of their body language, and these clues can be helpful cues if someone is dominating the conversation. If an overly vocal participant doesn't understand these cues, use a soft but firm statement such as "Okay, great, I'd like to open this thought to others. Has anyone else encountered some of the same issues Theresa has? Moving on to a new, broader topic, verbally say that the old discussion is over and a new one is starting so that people can clear their minds for the next topic. Finally, as the activity comes to a close, a simple glance at the watch and a change in body orientation can signal that the conversation needs to end. As with other activities, be sure to thank the group for their time. Sharing results with the team usually takes one of two forms: results are shared according to main themes or grouped into appropriate categories, as is the case with contextual research. Affinity diagrams can be another effective way to bring together different trends and attitudes to illustrate to your project team.

Card sorting In a card sorting exercise, participants (whether working individually or in small groups) are given items printed on cards and asked to sort them into groups that make sense to them. They either group them into categories that are given in advance (so-called closed classification), or they create their own groups and give each group a title (so-called open classification). By the end of your card sorting round, you should start to see common patterns in the way people sort items, as well as common areas of confusion or confusion.

SELECTION OF TEST TECHNIQUES

107

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

Let's say you're working on a typical source of content: a company intranet. Many intranets tend to categorize their information by the department that owns it, with navigation to Human Resources, Operations, Legal, Marketing, etc. For long-time employees, this may not be an obvious problem as they have probably learned the responsibilities of each department and understood where to find information. However, for new hires or those who need information they don't usually reference, it can be difficult to locate information that may apply to more than one department (or doesn't seem to apply to any). For example, where to look for a policy on signing contracts with new employees? This may be governed by law or it may be governed by human resources. By categorizing cards, you can find common patterns in how potential users categorize information, regardless of department. Basic process Gather the items you want to include in your card order; 40 to 60 is usually a good range. You need just enough to allow you to create a potentially large number of card groups, but not so many that you overwhelm participants with options (or overwhelm you when you need to analyze the results). Choose items that you think will be easy to understand and free of unnecessary jargon. You can include some thematic terms that you think user groups are likely to know, but avoid using too many "internal" terms. If you include too many company-specific terms or acronyms (such as "SUCCEED campaign" to increase sales), instead of creating a common hierarchy of information, you will be testing the effectiveness of your company's marketing and communication. For an intranet, you can include vacation rules, 401(k) plan information, a new lease, a vendor agreement, a confidentiality agreement,

108

CHAPTER 6: USER RESEARCH

orientation for new employees, information on health insurance and information security policy. This list is a combination of clearly worded items that can be classified in many ways. You may have one participant grouping new employee orientation and leave policies under human resources, and you may have another participant grouping new employee orientation and new employment contract and call it "employee onboarding". Once you have a list of items, put them on tabs that can be easily grouped and ungrouped. You can print labels and stick them on index cards or print directly on perforated sheets of cardboard to separate them into individual cards. Test by having someone break the cards into groups and give the groups names, for example by putting a sticky note in a stack and writing the name with a pen. Ideally, your test subject is someone who is unfamiliar with the items and activity. This will help you get an idea of how long an activity might take. If the test takes more than an hour, some tabs may need to be trimmed. Once you have your deck ready, you can invite a real participant and give them the following basic instructions: 1. Arrange these cards into groups that make the most sense to you. 2. Try to have at least two cards in a group. If a card doesn't seem to belong to any group, you can set it aside. 3. You can name the group at any time while sorting. At the end of the exercise, name as many groups as you can. Some trends will become apparent just by watching the sessions. Others may require a bit more analysis to bring to light. There are several tools for entering and analyzing card ranking results; many come with tools that allow you to sort cards remotely (see "Card Sorting Variations" below for more information). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) provide remote sorting capabilities and useful analytics tools. Or, if you want to do your own ranking in a more manual way, take a look at Donna Spencer's excellent spreadsheet, fill out

SELECTION OF TEST TECHNIQUES

109

with instructions, available at www.rosenfeldmedia.com/books/cardsorting/blog/card_sort_analysis_spreadsheet. Card Sorting Variations So far, the discussion has focused on self-made card sorting, in which the participant is asked to name the categories they have created. It is an open type, meaning the main categories have not been given to the participant but are open to being named. This is a good approach when you are defining a new navigation structure or making significant changes to an existing one. In other situations, you might consider the following popular card sorting variations: Closed sorting. For closed sort, it provides the top-level categories

and participants add them. The results are relatively easy to analyze because you have a small set of possible categories and can focus on understanding which items most often fall into which categories. Whether you're adding large amounts of content to an existing information architecture or validating an existing sitemap, closed sorting can provide quick and actionable insights to help you make categorization decisions. Group activities. Instead of sorting items individually into groups, they can

Make card sorting part of a focus group activity where participants sort items together. While the results do not necessarily reflect how a person would group items, you can get a good understanding of how people think about items and their organization by listening to them work together on an exercise, discussing the rationale for each placement. remote classes. Sorting with physical cards can be especially fun

for group lessons. But there are a lot of great tools for taking online classes with people. It also allows you to reach more attendees or individual attendees who may be difficult to meet physically. The aforementioned OptimalSort and WebSort are two of the tools that facilitate this type of online sorting.

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

110

CHAPTER 6: USER RESEARCH

You can run usability tests during the Define phase if you want to gather information about how your current site can be improved. Or you can do this on similar sites (such as competitor sites) to understand some potential possibilities for a more user-friendly solution. In most cases, usability testing is done as part of the design phase, preferably in iterative rounds (where the design is created, tested, refined, and retested). We'll cover usability testing in detail in Chapter 13, "Testing Your Design with Users"; This chapter provides recruiting and planning tips that can also help you complete the steps discussed earlier in this chapter.

After Research After you've completed at least one of these user research activities, it's time to review your original user group assumptions. Put those assumptions aside for a moment and ask yourself what user groups you would create now that you have more information. If some of your previous assumptions were not correct, consider any gaps you may have in your user research because a key group was not covered. If this gap is identified early enough in your research activity, you may have time to adjust and add another group of participants to ongoing research to ensure you get the full picture. With new knowledge, you can change your user definitions to more accurately reflect the groups you need to focus on. This will help you create more detailed tools such as personas (discussed in Chapter 7) and help you create the user requirements for the list we started in Chapter 5. In this chapter, we discussed the process of collecting feedback from business stakeholders and refining it to turn it into requirements. You'll do a similar process with your users: Your work doesn't end when you capture an idea or request. Go to the basic needs and goals to make sure you understand them. Ultimately, this will help design a solution that best meets this need for all relevant user groups. In the next chapter, you'll learn how to use the information you've gathered from your user research to create tools that can target groups of users in design and development: people.

AFTER THE INVESTIGATION

111

People Find the best way to put your team or client in their users' shoes People are often the subject of debate among user experience professionals. Opinions range from how much content is needed, how much research is needed, to whether it adds any value to the projects. Some people wonder if they belong in this process. Regardless of where you are located, personas can help your design team and your client get to know their users. People can provide an intuitive overview of many parts of your design—business requirements, visual design, or QA—providing insight into who your audience is and what their expectations and behaviors are. Russ Unger

What are people? Personas are documents describing typical target users. They can be useful to the project team, stakeholders and customers. With proper research and description, people can paint a very clear picture of who is using your site or app, and potentially even how they are using it. User experience designers often see persona creation as a great exercise in empathy. Well-designed personas are often used as a point of contact when there is a question or concern about how aspects of a project should be designed. You can pull your characters out and ask how it would work? or What will you look for in ? While this process may not be as precise as functionality and design testing with real users, it can help move the project forward until more detailed testing can be done. Josh Seiden (www.joshuaseiden.com) points out that there are two distinct types of personas: marketing-oriented personas that shape the motivation to buy, interactive characters that model usage behavior

In this chapter we will focus on interactive characters.

Why would you create Personas? In the user experience design process, personas help you focus on representative users. By providing insight into the "real" behavior of "real" users, people can help resolve conflicts that arise in design and development decisions so you and your team can continue to grow. How real do people have to be? The answer varies greatly. A one-person document may suffice for a team, while another may create entire "living spaces" for users to deeply understand how they "live." It may even go as far as creating individual online presences that you can interact with to provide insight into your online behavior. How you decide to expand your characters is up to you. People can be a constant reminder of your users. One useful technique is to keep people at their workplaces by team members; that's how they are

WHY CREATE A PERSON?

113

always remember who your users are. After sharing a bucket with "Nicolle", a 34-year-old certified hand therapist from West Chicago, Illinois, for a while, he begins to feel obligated to provide her with an experience that will be good for her. If it helps, feel free to carry printouts with you while you sleep, and let the osmosis fairy transmit page empathy through your pillow to your sleeping subconscious. The purpose of persona is to help you, your team, and/or your clients clear out some of the confusion that may arise when you reach a decision crossroads.

Searching for information about personas Successful personas must accurately represent the number of specific users of your product or website. To achieve this goal, people must be supported by research. Chapter 6 introduces techniques for researching and modeling potential users to build a solid foundation for your personas. However, don't look for a method that will be the answer; it is best to find as much data as possible and mix it with data from observations and interviews; this may also include the use of online surveys and behavioral analysis on social networks. This is a common theme in persona creation: get real data, but make people real people on pages. To see how one company achieves this, see the "Case Study: Messagefirst Personas" sidebar.

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

114

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, from the following: Stakeholders. We interview them to find out who their characters are and what their behaviors are like. It is always included. Customer representative. We interview people within the company who talk directly to customers, which usually means sales/marketing and customer service. Each of them has their biases, which we took into account when documenting our findings. For example, those who have too much time to contact customer service (often retired or unemployed) or people who are so nervous about a product or service that they actually spend time communicating, are the most likely to contact customer service. You. Customers. We talk directly to real people who intend to use or are currently using a product or service. This is taken into account whenever possible. Customer data sources. We review every blog traffic, surveys and emails that are available to us. Someone we know. We choose someone we know who fits the initial profile of the person. This helps keep us grounded by ensuring that the character is believable and realistic and provides a real person to contact if we have additional questions. This is very important for validation and is always considered. Since each input source we use has a specific bias, we use multiple sources to normalize the data. For people driven by data, it's important not to go in with expectations of how many people you'll have, but to let the data reveal how many people you should be. When analyzing data, I look for gaps in behaviors and actions. These spaces reveal individuals. Todd Zaki Warfel, CEO of MessageFist

An example character in this chapter is Nicolle, a 34-year-old certified hand therapist from West Chicago, Illinois. Is a non-driving commuter who spends 2-3 hours a day commuting to and from work. The fictitious customer is a company called ACMEblue, a maker of Bluetooth headsets for Apple's not-so-fictional iPhone.

CREATING PEOPLE

115

This short paragraph says a lot about Nicolle, but as you can see in Figure 7.1, a real person contains a much fuller story about Nicolle. Please note that the content is written about Nicolle, not "by" Nicolle. It's better to write your personas from a third person's perspective rather than having to deal with writing them in different voices, especially when you're just starting out. As you expand your experience, you should naturally explore and find the style that suits you best and provides the most value.

Figure 7.1 Persona for a fictitious ACMEblue client

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

116

CHAPTER 7: PEOPLE

Minimum content requirements When creating personas, you need to provide enough information to attract people and make them engage with the person they read about on the page. To help viewers understand how your character behaves and thinks, be sure to include six key pieces of information: photo, name, age, location, occupation, and bio. In the following sections, we'll take a closer look at filling out the details for each item. Photo A photo is the first step (and a real one) in giving your character a face. When choosing a photo for your character, try not to make the photo look too posed or polished. Photos that look posed don't have the same effect as those in more natural settings. People seem to be more effective with images taken in more natural settings, as in the image on the right in Figure 7.2, where a person is standing outside in a winter coat, probably on their way to work. Make sure the photo matches the person's lifestyle! lifted

Natural Figure 7.2 Natural looking photos are most effective.

There are many photo resources available on the Internet. Some of the best options are iStockphoto (www.istockphoto.com), Getty Images (www.gettyimages.com) and Stock.XCHNG (www.sxc.hu).

CREATING PEOPLE

117

Finding the right photo can be a complete waste of time if you're not careful. If all else fails (or if you have the time and budget), get your own! Name Simply put, you need to give your face a name. The photo you use will humanize your combination of research data and personality traits, and your name will be how everyone will refer to you during discussions. Not only does Nicolle sound better than "thirty-something blonde, professional mom," but it's much easier to remember and associate with a specific person. Try not to let the names you use for different people in the project sound too similar. For example, Nicolle and Noelle are easily confused, so look for different names. And while it may be tempting to use the names of co-workers or clients, don't do it. When you use names that are similar or the same as those involved in the project, it will be easy for them to try to identify themselves in your personas. Choosing different names avoids awkward situations or hurt feelings. If you're having a hard time choosing names, some online resources can help: baby name websites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Social Security Administration Popular Baby Names: www.ssa.gov/

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

One last thing about names: make sure your name is credible to the person. Nicolle works well for a Midwestern mom, but Nicola or Natalia might be a much better name for an Italian mom. Also, names that tend to be a bit more fun or lively, such as Bob the Builder, are not. They tend to make your characters look silly and may detract from their value. Age While your research should identify the age range of your consumers, providing a specific age for yourself helps add authenticity to your written biography. The behavior of a 21-year-old student and a 34-year-old working mother differ significantly!

118

CHAPTER 7: PEOPLE

Location At first glance, location may not seem like important information; however, it is important to remember that cultural and behavioral changes can take place in different places. For example, in Italy, different dialects are spoken in different regions of the country. In the United States, a person living in Chicago will most likely have different living expenses than someone living in Savannah, Georgia. Occupation Knowing what your person does helps you identify with them by relating to their daily life patterns. A person working in therapy meets many people on a daily basis, while a drawbridge operator may not interact with others. Biography Biography is a fascinating story that makes a person real. This is where you take the details you take from your research data and spice it up with a bit of "real people". This means that the data is very important to the person, but you don't want to just quote that information in broken sentences. Instead, you want to weave data, anecdotes, and observations into a story your audience can relate to. It may seem a bit odd, but a bio needs to be believable, and it's certainly not cheating to introduce aspects of a real person into your character. For example, Nicolle is based on both statistical data and very real behaviors of a person who has similar actions, beliefs and desires. Depending on the project, you may need to delve into the biography; sometimes the more details the better. Don't feel like you have to cram your personality onto one piece of paper. Choose what works best to make your character as realistic and meaningful as possible for the project you are working on.

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

CREATING PEOPLE

119

denominators of most people you will create. Most of the time, you'll be combining some of these optional content elements with your core characters. Optional content that can add value to your characters includes education level. Knowing how educated a person is can provide that

more information about some of their habits. Someone with a high school diploma may have fundamentally different buying habits and brand perception than someone with a master's degree, and this information can influence how they are perceived. Salary or salary range. Money speaks, and in many cases quantity

A person's income significantly affects their standard of living and disposable income. This information can provide significant insight when targeting specific wealth levels. Personal meeting. What would be your motto

as your own? Sometimes this can give you a quick overview of the core of your thinking. Internet activities. It might be difficult; people spend in many ways

your time online. Some people pay their bills, others are heavily involved in blogging and social networking activities, and some people just use their computer as a device that turns on when they need to get a job done. Since so many projects have some sort of online component, this element requires some judgment. You'll have to rely on your research to help paint the picture. Offline activities. Does your person have hobbies? There's more?

information about what your person's life is like when not online? This element can be as complicated as online activities and just as important in shaping your personality. A key input or trigger point for a client, brand or project. This is often important

understand how a person interacts with a client, brand or project. Does the person find out about it through word of mouth, online reviews, billboards, television or radio, or an online pop-up advertisement? Is your person looking for a solution to a problem that can be solved through a client, brand or project? Using statistics to understand this point and memorizing it for yourself can help guide your approach to user engagement.

120

CHAPTER 7: PEOPLE

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

have a computer at all? Do you use instant messaging, Flickr or write a blog? Are you comfortable with this activity or are you confused by it? Would a very simple solution designed for beginners help you? Do you have an MP3 player or other portable device? Do you use a DVR or AppleTV or on-demand programs to watch TV? The list can go on and on. I w. Depending on the client, brand or project, it can be important to identify these concepts and many others. Social comfort level. Considering the development of social media and social media

while working, it can be important to be very precise about how your character engages in that particular space. Do you have a Twitter account? If so, how many followers do you have? How active is she? Is he a leader? Do you use MySpace, Facebook, LinkedIn or other online aggregators or communities? Mobile level of comfort. As the use of mobile devices becomes more and more

first of all, it's important to consider how your characters are in the mobile space, if at all. Motivations for using the client, brand or project. In some cases you may want to

Include reasons why the person would like to use the client, brand or project. If you keep getting your headphone cord tangled in your coat and pulling it out of your head, this could be a good reason to consider new headphones. Real-life scenarios based on research data can help you discover key motivators to include in your personas. User Goals. You may also want to specify what the person expects

achieved through the use of a client, brand or design. This can help you gain insight into what motivates a person to use it. These are just data points to start with. You can construct your characters and represent them in an infinite variety of ways. If you want to delve into the world of personas, a good place to start is The User Is Always Right: A Practical Guide to Creating and Using Personas on the Web, by Steve Mulder and Ziv Yaar (New Riders, 2006). ).

CREATING PEOPLE

121

Advanced Characters Once you understand the basics of character creation, you have unlimited possibilities to extend your documents. A simple person can often meet most of your needs, especially when the design team is just trying to gain an empathetic understanding of users. Things get more interesting when you introduce people to your clients. In these cases, you will often find that you need to provide much more than the information gathered for the primary person. Figures 7.3 through 7.7 illustrate some ways of augmenting people. Feel free to borrow these examples, mix and match them to create something even better for your project!

trade name

Meet the consumers of the brand

PEOPLE AND SCENARIOS (based on ethnographic research) Personas are complex personas based on data about your target consumers: in this case, ethnography, existing segmentations and customer database data.

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

Joan, 32 Consumer insights help us understand users: their motivations, goals and desires. To apply these insights to web design, we develop personas and user scenarios based on real-life contexts. This design approach helps create holistic experiences based on understanding customers, their motivations, desired outcomes and behaviors. Specifically, the scenarios address three basic questions that must be answered before a site can be properly organized: Ŕ8IPBSFZPVSSFQSFTFOUBUJWFVTFST Ŕ8IBUBSFUIFVTFSōTTQFDJţDHPBMT Ŕ)PXDBOVTFSTBDIJFWFUIFJSHPBMTBOE Full Site Support

Pleasure Seekers "I Really Like It" "Sophisticated Young Man"

BEGIN

START DISCOVERING

BUILD THE EXPERIENCE

„Aspirant do Novato”

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

"Active Respondent"

FEEL 5)&365

DISCOVER AGAIN

"Acclaimed Explorer"

OPTIMIZE AND SIMPLIFY

"Grow in the Groove"

Getting Things Done Handily "It Just Has To Work"

Alice, 26

Rachela, 42

Erica, 47

Greta, 59

Figure 7.3 Character overview master sheet (landscape orientation). It provides an aggregated view of different people along with the segments they represent in the context of high-level organizational strategy. Courtesy of Will Evans.

122

CHAPTER 7: PEOPLE

trade name

PEOPLE AND SETTINGS (based on ethnographic research) Alicja is a novice cook who aspires to explore the world of food,

THE

especially children's food, with friends and searching for new recipes on the Internet and in magazines. Your exploration is about something more

feed your family without much thought or effort

however, fantasy than reality. She is still intimidated and not

find quick and easy recipes with basic ingredients

try too many new recipes. Her mother did not pass on many culinary skills to her, and her friends do not have much experience.

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

neither does the kitchen. Alice is a busy mother of a daughter in Chicago. She and her husband both work outside the home: she manages the office of a small insurance company.

Alice, 26th Generation X married a 'would-be rookie'

1 daughter, 5 tired, aspiring

income

Education

She is busy, practical and does not spend much time cooking. Alice just wants to make it quick and easy, although she often has to prepare different meals for herself and her husband since she started exercising after giving birth to Sophie two years ago and is trying to get back in shape for the marathon. She works with a small set of successful recipes that she is comfortable with, and many of the meals she prepares are based on packaged and ready-made products.

SCENARIO Alice watches Cartoon Network with Sophie over breakfast. Here comes the brand ad showing the brand name. Alice uses a brand and thinks Sophie would choose this dish. He decides to check out the site from work. Alice visits the site for free half an hour before the meeting. The homepage is clear and organized. See the main sections of the site and links to interesting things like the recipe of the day.

Internet use

Health awareness

cost sensitivity

Click the recipe of the day. He likes the directions that come with it, it makes him feel like he could handle this recipe. You like clear navigation, unlike other sites where you often get lost. She likes useful features that go beyond what she sees in cookbooks, such as the ability to search for recipes based on the contents of her pantry and tips on how to use the products. Alice discovers she can receive recipe newsletters and clicks "Register". Registration is very simple! He fills in the basic information and selects the "Food Your Kids Will Love" newsletter.

She would like to add more surprises of her own and recreate dishes she likes in restaurants, such as her favorite chicken. You'd also like to add more fresh vegetables to your meals because you know it's healthier. She prides herself on being a meticulous planner and being able to manage her home on a tight budget. Your fridge and pantry are always stocked. Planning shopping to take advantage of sales and coupons.

find kid-friendly recipes and cooking activities find ways to dress up your favorite ready meals PROJECTS AND INITIATIVEs improved navigation and information architecture improved registration

A week later, at lunchtime, Alice finds the brand's first e-newsletter: "Pizza, as simple as 1, 2, 3". Perfect: her kids love pizza and she often buys them frozen pizza. There is a link to "Pizza for Beginners" which inspires her to see if she can make pizza herself. The link leads her to a pepperoni pizza recipe in something called "Pizza Wizard". He looks at the recipe and sees that it is quite simple; only 25 minutes and 4 ingredients. He peeks into the kitchen to see what he has. There's no pepperoni or pizza sauce, but The Pizza Wizard suggests substituting what he has in his well-stocked kitchen: sausage and tomato sauce. And perfect! There is a link to the coupon. Neena prints out the shopping list for the recipe, adds a few things she needs, and heads to the store. After returning from the shop, Alice sets off. See step-by-step instructions on how to roll out the dough and add the ingredients. There are pictures next to each step. It is easy to understand and follow. He wonders if he should cook the ingredients first, but the Pizza FAQ suits him.

contextual side information more targeted newsletters recipe assistant better integration of vouchers MEAL PLANNING a do it mindset relies heavily on pre-prepared food with relatively few added fresh fruits and vegetables spends more time looking for recipes than cooking them

Figure 7.4 A person from the target group (landscape orientation). This detailed view of a person covers a broader spectrum of data and provides a more comprehensive perspective of users' goals, needs, and behaviors, all within a larger ecosystem. Courtesy of Will Evans.

Figure 7.5 Overview of the purpose and personality of the target group (portrait orientation). The Goals Overview on the left provides high-level summary information and shows the brands that these three people are interacting with and engaging with. The detailed description on the right shows an outline and biography of a single person, along with information about their behaviors and motivations.

ADVANCED PEOPLE

123

Paul and Helen “I think we can put anything in there. Not sure how much will fit.

5 4

Helen's mother died a few weeks ago and they are now starting to clean the house. They plan to sell the house, but there are a lot of things they will have to clean up first. The house also needs refurbishment work in the main bathroom.

- z The basement is full of things Helen's mother has been collecting over the past two decades. She never threw anything away. It houses Time newspapers and magazines from the last 20 years. There are a few things Helen wants to keep. Most of the clothing and furniture will be donated to Goodwill. Unfortunately, most of your mother's utensils have been damaged by water and mildew. He also has paint cans, but Paul and Helen don't know if the paint contains lead or not.

2 1

ain

Know Ex led pe gerie nc e C on Pric vee Senior tunc pe sp Re e Mpu ed ult type Timtion C on eline t Main ss ajo er r L Rozmiary D E ecven lutte t Rok Re rding pe Wast Bowls and Buars ds ine Price and O Rec am nlin ycli ne ac h count

This is the first time Paul and Helen have gone through something like this. They don't even know where to start. They just want it to be as easy as possible. They know they need a dumpster, but they're not sure how long it will last. And they assume that almost everything can go to waste unless someone tells them otherwise. Your only concern is that the garbage cans seem unsightly. They're hoping to find a company that won't make the yard look like a construction zone or ruin the yard when they deliver or pick up a dumpster.

Age: 24-65 years

life cycle january

July

Dic

medium

1.0 Life event

Key features Ŕ Ŕ

A one-time event, such as the acquisition of family property or a small remodel (e.g. bathroom). Little experience in the past with the purchase of a garbage container.

The Ŕ Ŕ Ŕ Ŕ Ŕ

Get a dumpster quickly. Get rid of all things that don't save or give back. Avoid damaging property during the process. Avoid the unsightly trash can. Throw away the garbage can immediately when it is full.

Points of frustration and pain Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Problemy Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

Available as needed Price Seller leaves property as found Required container size available Speed of setup and collection when contacted Access to online account for planning and payment Quality and cleanliness of equipment Well-known brand

Ŕ ŕ ŕ ŕ

Initial label surprise Not knowing the process I don't know what you don't know Conducting an apples to apples comparison between suppliers

Is there anything I can't get into? How fast can you deliver and pick up? Will they leave the property as it was originally? How it's working? Is a permit required? How much does it cost? How easy can I contact someone if I need to?

Figure 7.6 A person from the target audience. This person represents the target age range, taken from research data. The information it contains is broad and applies to target groups, not specific individuals. This approach can be useful when you are doing a business presentation or when the client's budget allows for detailed persona scanning. Courtesy of Todd Zaki Warfel.

Jill of all trades

Amanda's Stone

"I have to manage various programs for my clients."

AMANDA SHARES RESPONSIBILITY FOR THE INCENTIVE PROGRAM WITH SEVERAL OTHER EMPLOYEES. They share access and manage multiple programs for clients. It can be especially hard to make sure you're paying the right people in the right program. You need to be able to switch between different programs and always know where you are.

wheel of life

Key features Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Manages multiple programs Medium to large company Average number of orders (50-2000+ orders at once) Multiple people sharing one role Quick payouts and admin checks 70/30 Weekly to two months Year-round use High interest in reporting Wants to report a loss Heavy Excel uses a custom built-in interaction system

The Ŕ Ŕ Ŕ Ŕ

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

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

Ac FT N cew ou P n C ar t Zod Rene q est t E Ad asy s m Pa in y C he c R Cu epks orr en rting tB al Peance ce Cu ople stom Soft o f t Sytallo ex cel l

nc e

Ene

influencerzy

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

Rio

i ex

dg yow Kn

on how

and itp.

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

Activities and interests

you c

Age: 28-55 years

Knowledge

ain

The Account Zone really helps with the issuance of new cards and ensures quick payouts to program participants. The only thing it lacks is the ability to view each program individually as well as all running programs to see how things are going. Your customers like to be aware of the performance of programs. Right now it's tracking it in Excel. He ends up sending the Excel file to his clients or sometimes exporting it and sending a PowerPoint with nice graphics. If Account Zone had a way to run individual and multi-program reports, that would be really awesome.

July

Ŕ ŕ ŕ ŕ ŕ

medium

Frustrations and pain points

Questions -

Dic

You cannot watch multiple programs at the same time. Reports cannot run in multiple programs at the same time. Bug fix in "sucks" exception file. Knowing what the exact problem is and how to fix it is not clear. Multiple steps with multiple apps is not efficient and makes it easy to "get lost" where you are. Multiple confirmation screens. Another username and password to remember. Find your login email.

Figure 7.7 Individual person from the target group. This person is a heavily data-driven model. While the story of A Day in the Life is narrative, the rest is laid out in bullet points that serve as a design checklist. A diagram is used to convey a large amount of information in a small space. Courtesy of Todd Zaki Warfel.

124

CHAPTER 7: PEOPLE

As you can see, the data can be combined in many different ways to represent characters, adapting them to different situations. Start with a basic persona and develop it according to your needs.

Final Thoughts on Personas Many professionals in the world of user experience design do not believe that personas are good at expressing user needs, goals, and attitudes. They believe that people can hinder creativity, innovation, or good design for various reasons. Other practitioners believe that a person meeting a specific need has a very positive impact on the design process when it is based on solid research data and mixed with a dose of personalized reality. Which side of the coin you land on is entirely up to you. The purpose of this chapter is not to influence your decision in one way or another. Many articles on this subject are available online, and many professionals are ready to give their point of view. All of these resources can help you figure out how people will best work on your projects, so look them up. Jared Spool, CEO and founder of User Interface Engineering (www.uie.com), also offers insight on this topic: This value is created when the team visits and observes their target audience, absorbs and analyzes their observations, and reduces chaos. into patterns that then become people. What is in the team's mind during design will influence the final design. Character descriptions are meant to remind everyone of what happened.

Jared's conclusion is simple: looking at your target audience, combining what you learn with research data, and synthesizing it all into segments, you should be able to create personas that trigger the kind of empathy that keeps your team on track and builds that what's next. better. a possible application, website or product. Ultimately, however, your characters will be very much like Santa Claus: they will only be valuable as long as people believe in them.

FINAL THINKING ABOUT PEOPLE

125

User Experience Design and Search Engine Optimization The Critical Role of User Experience Design in Effective SEO Search engines are the cornerstone of the interactive economy. Everything we do as "interactives" is ultimately connected to the whole world through Google, Yahoo, MSN, Ask, and the countless smaller engines that make up the infrastructure for finding things on the Internet. Information architecture is a key component of how search engines interpret web pages. This chapter aims to give you a basic understanding of why UX design is critical to search engine optimization and what you need to consider in order for the environments you create to stand a chance against Google. Jonathan Ashton

Introduction to SEO Simply put, search engine optimization is the process of developing and maintaining an Internet resource with the intention of obtaining and maintaining a top position in public search engines for specific key phrases. Search Engine Optimization (SEO) is like a martial art, a process of learning and doing that is never complete. Even a teacher can make more progress by applying an observed behavior or a learned method. As long as there are search engines and websites interested in selling something to searchers, search engine optimization will play a role. SEO is based on three primary areas of improvement and impact: A critical group of things that a professional user experience designer takes care of

may affect: site infrastructure, technology and organizational policies content and all keyword issues that relate to optimized words

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

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

Why is SEO important? It is interesting that even today we have to explain the importance of search engine optimization. Clients usually understand to some extent that it is important for their sites to attract targeted visitors from the natural search results of major search engines, but beyond that, most interactive marketers find it difficult to understand the impact that SEO can have. Global search data is available from a variety of sources, but the most important thing to understand is that regardless of the source, the numbers are simply huge, with year-over-year increases always in double digits. In most cases, each quarter increases the global search volume. When Google was first launched in 1998, 10,000 searches a day was a huge number and put an incredible strain on the beta version of the system.

INTRODUCTION TO SEO

127

Hitwise (www.hitwise.com) reports that Google and its affiliates (including AOL and YouTube) own the majority of searches in the world, with nearly 72 percent of searches performed in the United States in November 2008. Yahoo is in second place, with almost 18 percent. , and MSN and Ask.com with 4 and 3 percent respectively. Internationally, Google dominates even more: in many markets, its market share exceeds 80 percent. 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), in 2008, over 60 billion searches were performed worldwide per month by 750 million people, with over 18 billion searches conducted in the United States alone. In other words, 95 percent of Internet users use a search engine at least once a month, and the global average is over 80 searches per month.

Beyond these amazing numbers, what does this really mean in practice for interactive marketers? Simply put, if you are not reaching your target customers when they are looking for your products or services, your competition has an opportunity to sell them something. Look at your site's analytics data and think of the problem this way: How much more revenue would your site generate if there was a 10% increase in strategically targeted traffic? Or maybe a 100 percent raise? Or 1000 percent? If your website isn't getting significant organic search traffic, SEO is a must. A small investment in SEO can go a long way, especially if your interactive marketing efforts have focused so far on buying clicks through sponsor lists. We have seen sites achieve a 35 to 1 return on investment on monthly SEO spend. If you pay search engine companies for traffic to sponsored sites but don't invest in natural traffic, you're actually limited to about 10 percent of what you can do. Think about your search behavior: when was the last time you clicked on more than one or two lists of paid sponsors in search results? Any discussion of why SEO is important and why it's permanent here could go on for entire chapters. Suffice it to say that Google is going nowhere, and effective interactive marketing must include search engine optimization as an essential element of competent execution.

128

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Important core resources Experience comes from a comprehensive education. A professional who simply concentrates on his specialty loses perspective on everything that surrounds him. That's why it's so important for every interactivist to spend at least a few minutes learning SEO. While there is no official set of guidelines, Google has been kind enough to provide some very important resources. If you want to improve search engine performance through your efforts, please check out the following links: Webmaster/Website Owner Help: Search Engine Optimization:

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

www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35769 A beginner's guide to Search Engine Optimization:

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

Site Technology, Design, and Infrastructure Search Engines are essentially Web 1.0.5 technology that is firmly embedded in the Web 2.0+ world. The fundamentals of the search engine have not changed much since the World Wide Web Wanderer was launched in 1993 to search the web and build the first Internet search engine. Basically, every search engine has an application, alternatively known as a crawler, spider or bot, that finds and follows links by sending a copy of the visible resources to the database. The database is then analyzed according to the search engine's proprietary algorithm. Using these rules, a web resource is indexed and then ranked according to its score in the search engine's results card. There are many pitfalls for the UX designer in this fairly simple process.

CONSTRUCTION TECHNOLOGY, DESIGN AND INFRASTRUCTURE

129

Understanding these basic relationships will allow you to see your site through the eyes of the search engines. An optimized website is based on a structure and technology that facilitates the navigation of search engine robots. Similarly, many content management decisions determine how well the resulting efforts are ranked by search engines. As a result, much of this is predetermined by the decisions made in the frameworks and in the discussions that take place about content design and management.

Flash, Ajax, JavaScript and other scripted content Today's dynamic and interactive web design relies on technologies that are completely unsuited to the needs of search engines. There is a growing gap between what search engines see and what designers can do. The UX designer's job is to ensure that strategic plans for dynamic and intensively designed websites are implemented so that both search engines and users get the best possible experience. Having a basic understanding of how search engines interact with this type of content will help you decide when to implement them and where to compensate for their weaknesses. It's entirely possible to create an optimized site that relies heavily on scripted content if the right trade-offs are made early in the process. It's much harder to create static or indexable content once your site is up and running. So, for the sake of usability and for the sake of search engine robots, make a strong case for static content. This may seem like extra work at first, but the return on investment is exponential. Flash Flash content is technically "indexable". Recently, there has been some progress in the ability of search engines to browse Flash files and find text and links embedded in these resources. Even if this content is indexed, have you ever seen an all-flash resource rank top in search results? You probably didn't, because opening yourself up to full Flash support is risky for search engines. Assume that search engines can fully see all links and textual content embedded in a SWF object. What stops the unethical (or "black hat") optimizer from putting apples on object text layers when displaying

130

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

oranges for a user viewing fully compiled assets through a browser? How can you deep link to a Flash resource without fully compiling it? These fundamental gaps will remain until search engines reach a certain level of AI that can tell that an image is an image of a horse without the associated text saying "this is an image of a horse." To design a Flash site that is search engine friendly, you need to add a static content layer that replicates the Flash content. Search engines aside for now, a static content layer is key to meeting usability requirements. Think of a search engine as someone browsing the web via a phone call or browser with a screen reader. These people may be the lowest common denominator, and it's possible that the strategy behind web development is discounting this very small percentage of users. But when you exclude these handful of people, you also exclude GoogleBot and Yahoo Slurp, the two most important visitors to your site, because they are the crawlers that will allow the major search engines to index your site. If search engines can't see words of text or links that can be indexed, your content will inevitably not be found in meaningful search results. A static layer can be obtained in many ways. To meet search engine requirements, the static content layer must reflect Flash content. This is not an opportunity to show search engines anything other than what is implemented in Flash; if you do, you violate the spirit of the game and put yourself on the dark side. The ideal way to embed Flash content in a static layer is to use SWFobject so that both the Flash content and the static content can be on the same URL. This will allow the search engine to find static content and allow a Flash-enabled browser to display animation instead of static content. If possible, don't use redirection to keep the link to Flash content popular. Google Code provides a simple set of instructions for implementing this simple piece of JavaScript at http://code.google.com/p/swfobject. There is another option that works on the gray side of SEO. Cloaking can be a dirty word for SEO purists, but if you approach the following challenges from the right angle, you can eat your piece of cake and eat it.

CONSTRUCTION TECHNOLOGY, DESIGN AND INFRASTRUCTURE

131

Cloaking uses user agent detection by detecting search engine crawlers when they visit a website and redirecting them to static pages for indexing. But when the visitor sees the same page in the search results and clicks on the link, the site detects that the user agent is a human with a Flash-enabled browser and shows that person a dynamic experience at a completely separate URL. The crux of the matter remains the same as with the SWFobject method: you need to show search engines exactly the same in hidden content as you do in Flash content. Ajax, JavaScript and other scripting content A powerful Web 2.0 content controller, Ajax provides web developers with the ability to create content without pages. However, search engines' problems with Ajax are manifold and require good planning to avoid big mistakes. Ajax stands for Asynchronous JavaScript And XML, suggesting search engines' difficulties with this technology. Search engines are fundamentally bad at JavaScript; efficiency that JavaScript provides developers is the problems search engines have with dynamic content. An additional problem of search engines with Ajax is the asynchronous nature of this technology. The search engine can only see the content on the initial page load, and any script-loaded content that happens after the initial shell load will not be visible for indexing. Since Google cannot extend the session beyond the initial page load, and there is no mouse or external agent to run the script, any content other than user-launched pages will be invisible unless the text content is placed in a pre-loaded shell. . It's up to the UX designer to ensure that the 3D modeling needed to structure the pageless layout also includes the requirement to preload text and links in the page shell. Anything else and your cool design is invisible. Scripted navigation One of the most common optimization problems is the use of JavaScript in the core navigation of the site. This is a very common condition and is due to the way many website builders and content management tools work. Script browsing looks better so people are interested in using it. But if JavaScript is the technology that drives site navigation, then search engines can't construct the link pattern properly as a result.

132

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

site relationships: they just don't see the link structure of the site. And if search engines can't model the link relationships on your site, deep content will be missed or not attributed to the correct link popularity.

Content Management Systems Content management systems were created for people's convenience, but many of these systems make it difficult for search engines to manage their results. Here are some common problems that should be avoided by using workarounds or choosing a content management system that is easier to search: Dynamic URLs. Search engines don't understand the content of "page"; He

understands the path to this content. Changing the path or URL to that content causes search engines to inadvertently copy that content multiple times. This condition significantly affects the website's ability to function properly. If your content management system has a system that creates session IDs in URLs, you could be in big trouble. Track with mature analytics, not session ID. Multiple URL paths. The common problem with e-commerce content persists

The deal is that as a product goes through its lifecycle, it accumulates multiple URLs. Again, since a search engine can understand a content page only from the URL where it finds the content, when a product appears in a category and is part of a gift basket and is a weekly special (etc.), very quickly, crawlers have taken advantage of many different links to find the same content. Do your best to ensure that each content resides in only one URL, and that multiple paths actually depend on a single URL, regardless of where links are implemented. Rely on mature analytics systems for channel analysis. Unintentional cloning. When you realize that piece

If content is only accessible through a single URL path, it's easy to see other conditions in content management systems that cause content to be inadvertently cloned. Suffice it to say that the architecture should only have one URL path to a single piece of content. endless loops. The consequence of the problem of unintentional cloning is

finished loop. Make sure you don't place search engine spiders

CONSTRUCTION TECHNOLOGY, DESIGN AND INFRASTRUCTURE

133

the potentially endless task of following "next" links in a calendar or similar situation. If a search engine spider can follow the next link to the next day on the calendar where it can find another next link, it will follow that link to the next page, and so on. Avoid this type of situation by using a scripted link that search engines can't track so that crawlers can spend time on the content you want to index. Old URL structures. The first thing many site remodeling projects do

ects is to replace the old URL structure. The problem is that the search engines have probably already indexed the content at these old URLs, and as soon as you change all of them, you're essentially sending the indexing back to square one. Additionally, any backlinks the site has accumulated over time point to the old URL structure. Regardless of the cost, keep as many old URLs as possible. You will probably need to change all URLs after replacing your content management system, so if this is unavoidable, recommend that old URLs be given a "301 Moved Permanent" status code and redirected in oneto -a base mode from the old URLs to the new URLs URL. A 301 redirect is the only allowed redirect for search engines.

Domains, directories and URL structure matter If you're starting from scratch and if branding constraints allow, try to choose a domain with one or two keywords. It's hard to get a .com domain with quality keywords these days, but if you do, separate them with dashes. The main part of the impact of UX on SEO is in the directory structure of the site. This has a decisive influence on the distribution of link popularity on the site. Simple is better. Avoid having redundant files in your directory structure at all costs. Some content management systems will automatically insert a subdirectory; prevent this if possible. This condition weakens the relevance of the entire site. Search engines understand site hierarchy based on site directory structure, so make sure your most important directories are at the top of the architecture. If your environment allows it, use keywords in the URL structure that are appropriate for sections of your site. Separate keywords with a hyphen and

134

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

do not use too many keywords in the file name. Look for something like: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure you have redirects set up for http://site-in-question. com to 301 Permanent redirect to http://www.site-in-question.com has been moved. If a site is terminated with and without www, search engines (especially Yahoo) will index the content of both URLs, opening up the entire site for accidental duplicates. This condition tends to spread when a third party links to a site without www and the site has a dynamic link structure.

Content: the old (current) and future king While content generation is someone else's business, the legislative work involved in site architecture has a lot to do with making relevant content available to search engines. As with all forms of keyword-based search, you need to understand the actual behavior of the people you want to show the resource to. Search engines are still very "primitive" because they rely on users typing keywords to link them to resources that are more or less relevant to those keywords. Choosing the right phrases has a lot to do with whether your website is relevant in the right context. In a perfect world, your SEO partner will provide you with a set of target keyword phrases before you start and will work with you throughout the schema development process. If you don't have such a competent partner involved in your process, check out the Google AdWords keyword research tool (https://adwords.google.com/select/KeywordToolExternal) and do some research on actual user behavior in search by browsing categories Then spend some time for this post to discover the phrases your potential customers are searching for and use them appropriately throughout your site. Search engines look for keywords in different places when analyzing a site. Optimization is about making sure the right words are in the right places. By understanding the role of keywords in the UX design process, you will create the framework necessary for future success.

CONTENT: THE ONLY (AND CURRENT) AND FUTURE KING

135

So why is content king? This is the crux of what a website is supposed to deliver. Search engines need textual content that they can see and index. Website visitors need engaging content that deserves their attention. Bloggers and webmasters need content that is link worthy. Without the right content in the right places, search engines can't connect the right users to your site.

Naming conventions and fighting jargon It's important that your keyword goals are reflected in the taxonomy you've developed for your site. Using key phrases in the main structure of your site makes your entire site more relevant to the products you sell. If you sell widgets, don't call your online product listing catalog, call it a widget catalog. Similarly, use keyword analysis to make jargon decisions. For example, use laptops instead of notebooks in your structure because people search for laptops more than 10,000% more often than notebooks.

Metadata, Headings, and Keywords It's amazing that we've gotten this far in this chapter before delving into the basics of metadata. There are tons of meta tags available, but only a few have a really big impact because everything else is prone to spam. Relevant tags are: Page title. Please note that this is not a label, But

the actual markup in the header of the page. This tag contains the actual title of the page and is the 65 most important characters on the page. Think of the title as a little bookmark sticking out of your old-fashioned library card catalog that reads "Clements, Samuel" and indicates that all the cards behind that bookmark are Mark Twain books. Each page on your site must have a unique page title. Don't put keywords in the title and be sure to load the title with your most important words. Meta keywords. This tag has virtually no effect on the search.

engines because it is very susceptible to spam. The exception seems to be that the Google AdSense distribution looks at the keyword meta tag and that Yahoo is influenced by it in a tertiary way. keywords

136

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

should match the content of the page, and this tag is actually a good place to insert potential misspellings. It has to be different for each side. Meta description. As with the page title and meta keywords, make sure

that the meta description is unique to each page. This description is just that: a summary of what the page contains. Say no to sell in about 150 to 160 characters. This content is critical because search engines are likely to display a link to your site below. If the page does not contain a meta description, the search engine will look for a snippet of text or other content containing the search keywords and display them in its results. The meta description is more about usability than SEO, so make sure each page is properly tagged. "Noindex" meta tag. If you have any pages you don't want to include

use the noindex meta tag in your search results. Just make sure that the pages you want to index don't accidentally include this tag. Headlines. Search engines recognize headlines, etc.

as influencers as long as you don't spam them. Make sure your section headings are descriptive and include keywords relevant to the page. The anchor text of the link. The link anchor text has a big impact on what

search engines think about the page on the other side of the link. This is the factor that creates the "GoogleBomb". If enough links point to a page with the same anchor text, Google interprets the placement as being related to a phrase in the anchor text. For example, if you click here on Google, the Adobe website will appear in the first results. There are hundreds of thousands of links that go to Adobe and say "click here to download Adobe Reader" or something similar. Use it to your advantage; the anchor text should not read "More" or "Click here". Instead, it should contain keywords that are relevant to the landing page.

Divide hair in half It's good for you if pages are indexed separately for both left-handed and right-handed corrugated widgets. This level of detail gives your pages a better chance of accurately matching legendary long-tail searches. A page that is about one thing only has

CONTENT: THE ONLY (AND CURRENT) AND FUTURE KING

137

more likely to win for that one thing than a page that is for many things (all other factors being equal, of course). And who is interested in reading a page with hundreds of words anyway?

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

Keep your content up-to-date A key element in getting and maintaining top rankings in search results is to keep your site content up-to-date. This does not mean constantly editing the entire content of the site; this means that the site must constantly evolve. Create a directory structure to make adding content easy and intuitive, and anticipate that your site will grow over time.

Other Content Issues The primary challenge with a content-rich site's UI is to avoid cloning or duplicating content. Beware of creating duplicate pages with seemingly innocuous conveniences such as "printable" content that is an exact duplicate of a page in a PDF or similar type of document. Protect these types of pages with scripted links or use the rel="nofollow" link attribute. Do not exclude optimization for the wide range of digital assets that search engines can index. This topic would almost be a chapter of its own, but suffice it to say that PDFs, videos, images, and other non-website resources are clearly part of the natural search results. It is very important to structure wrappers around these resources as search engines need metrics for this type of content. For example, search engines cannot tell that an item is a horse racing video if there is no link to that video with anchor text that says "horse racing video" next to the text about horse racing videos on the page. code.

138

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Using alt attributes is another way to identify non-text assets for search engines, and it's always a good idea for usability reasons. Don't create blind pages with content. Make sure even the bottom of the structure connects to your main site so search engine robots don't get stuck in a dead end. Breadcrumb links are an easy way to achieve this if your page type doesn't include navigation on your main site.

Link Popularity Explained If there is a holy grail of SEO, it is link popularity. This is the cornerstone of why Google performed so much better than other search engines when it first hit the scene. Link popularity is a determination of the quality and quantity of links leading to a web resource from other websites. Google uses the term PageRank and it is an über factor that can overcome many other shortcomings. Links are essentially votes for an Internet resource, and it is generally assumed that something that is of interest or value to others will have links to it from other trusted Internet resources. Over time, this concept has proven invaluable in the fight against spam and is, in essence, a fundamental principle of high-quality search results. This principle is crucial for a UX designer to understand how link popularity is distributed in the site structure.

Typical Link Popularity Distribution Like the Richter scale used to measure the strength of seismic activity, Google's PageRank system (named after Larry Page himself) is a logarithmic scale from 0 to 10. This means (very generally) that if one page has PR equal to 4 and another has PR equal to 5, a page with PR 5 has 10 times more link popularity than a page with 4. This should be understood because PageRank is distributed throughout the site based on link hierarchy and directory structure. In general, if your home page has a PageRank of 5, the parent section pages should have a PR of 4, the child pages of a PR of 3, the tertiary pages of a PR of 2, and so on.

EXPLANATION OF LINK POPULARITY

139

The pages with the most internal links to them tend to have the most link popularity. Pages that are most important to win should have the most internal links to them. This includes links in the homepage navigation, sitemap, footer, and inline links. Since link popularity is critical to a good search ranking, you should be as deliberate as possible to place as many links as possible on your "purchase proposal" pages. Each page has a finite number of popularity links that can contribute to other pages on the site. A page that has a link to another page sends 100 percent of its available value to the recipient. A page that has 100 links to 100 other pages sends 1 percent of its value to each of those 100 pages. The home page tends to have the most link popularity because the site's home page tends to have the most links to it from third-party sites. This means that the home page has the most value when it comes to contributing to other pages on your site. If there is an important page that is part of your "offer to sell", include a direct link from your homepage so search engines can understand how important that particular page is compared to the rest of your site. If possible, create a function that can rotate links to deep content from the homepage.

Footer Links When looking at how to organize and control the distribution of link popularity on your site, keep in mind that text links in the footer of any page are both a blessing and a curse and will have some impact on the distribution of link popularity. all over the page. Typical footer links point to privacy policy and other non-transactional pages, so if these links must be in your footer, hide them behind some script or better yet, "nofollow" those links with the rel="nofollow" link attribute. This will prevent each page's link popularity from flowing down to pages that don't really need to rank in search results. It's also better to avoid link popularity streaming than to completely exclude pages that use robots.txt.

140

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Cross links in content Search engines use links embedded in text. Just don't overdo it. Some schools of thought hold that after the first few links in a block of text, search engines do not give favorable weighting. Put the most important links at the beginning of the text and use link anchor text that contains keywords related to the landing page.

Playing the system Who said search engine optimization is work and not fun? Search engines can pay real money to site owners, and in some environments there is a truly limitless method of getting top rankings at any cost. Quite a few search engine optimizers have taken advantage of their customers by charging big bucks for bogus techniques that may yield positive results in the short term but devastating over time. Over the years, webmasters have used various optimization techniques in search of the best results. One of the major evolutions of search engine technology has been engineering work on clever ways to play the system. From a search engine's perspective, users' best interests are transparent, highly relevant results at the top of every query. From the perspective of many search engine optimizers, it's all about love and SEO.

White hat vs. black hat It's easy and fun to characterize SEO methods as "white hat" or "black hat", but it's much harder to tell which is which. Many white hat optimizers are purists and say bluntly, declaratively, that some technical management, content and link manipulation, and other approaches are simply not available. The black hats see the issue as a contest that has nothing to do with cheating: how can something be cheating if there is no specific written order or court of law? His approach is more like a game of cat and mouse, where the cat holds all the cards and the mouse can win a lot of money: risk, win, and the reward is great. But when the search engines get to you (and almost

PLAY IN THE SYSTEM

141

always) be prepared for your site to be banned or at least not able to function when the methods are revoked.

Spamming with metakeywords Many "cheat" techniques are based on UX principles. One of the first methods of cheating the system was meta keyword stuffing, i.e. placing hundreds of occurrences of apples in the meta keyword tag, while the website content is all about oranges. At the core, a meta keyword method was created to help with the taxonomy of the early web. Today, due to all the keyword spam, this part of the website has virtually no impact on search placement. Search engines easily detected this technique and quickly designed it. Next generation spam was a bit more difficult to unravel and was also rooted in UX issues.

Cloning and Landing Pages Both cloning and landing pages are methods used to increase or differentiate a site in search engines. By cloning a page over and over again, webmasters can essentially create meticulously targeted content that can be quickly dominated for a particular search phrase. Because of this practice, it's important that your architecture avoids accidental cloning, as search engines are sensitive to duplication, intentional or not. Post pages are another method of influencing search results that falls in the gray area between white hat and black hat methods. First, Google's Webmaster Quality Guidelines state that "accessing sites... violates our Webmaster Guidelines" (www.google.com/support/webmasters/bin/answer.py?answer=66355). The guidelines identify landing pages as low-quality pages that have been specially optimized for a set of keywords that may not match the actual site or are spam. On the other hand, how do you help search engines access content that is trapped in a database that is not searchable or that is hidden due to technology that search engines don't like? In its positive definition, a landing page is high-quality, static content that search engines can see and understand, while providing visitors with a door to dynamic content. Today's content management systems are getting better at the basics

142

CHAPTER 8: USER PERFORMANCE DESIGN AND SEARCH ENGINE OPTIMIZATION

needed this approach, but it can still be very useful to create additional pages to show search engines a static representation of content they otherwise couldn't handle.

Link spamming Recent methods of cheating the system have focused on manipulating link popularity, a concept that is central to the way modern search engines work. As discussed above, search engines determine the relevance of a particular web resource by analyzing the quantity and quality of links pointing to that page from other places. Search Engine Optimizers have been working to manipulate this part of the puzzle through tricky redirects, excessive use of subdomains, creating each page on the "/index.html" site, and many other subtle machinations.

Some Final Thoughts Doubt if this is your first exploration of search engine optimization. It is now known to what extent site architecture and related issues affect search engine performance. Today's search experience is a quantum leap from a simple taxonomy or structure. Careful search engine optimization starts with a quality user experience. The architecture of a website is a critical point in its life cycle, where it may be doomed to success in search engines or at risk of failing inevitably. Search engine optimization is a strategy that never really ends, but quality SEO will never really start without the careful attention of a UX designer. Jonathan Ashton is Vice President of SEO and Web Analytics at Agency.com and heads the SEO Center of Excellence. His team provides company-wide SEO services, ensuring that the process of designing and creating rich interactive experiences results in sites that can be found in search engines. His monthly column "Industrial Strength SEO" can be found at http://searchengineland.com/lands/columns/industrial-strength.php.

SOME FINAL REMARKS

143

Transition: From definition to design Time to visualize, prioritize and plan Now you have a good list of business and user requirements. You also have feedback from your users to focus on discussions. And now this? Unless you're into Shangri-la projects, you're going to have a (tight) budget, a (tight) schedule, or both, which tells you that you need to somehow focus and manage that list. This chapter covers some of the ways to move from definition to design, including tactics to help your team envision the solution they are designing, prioritize features to create a unified set of requirements, and plan future design activities. process. next stage of the project. Carolina Chandler

Chapter 4 discusses different project approaches or methodologies and how they impact how you work with your project team and business stakeholders. He compared the waterfall approach, in which the Define and Design phases are separated by the approval stage, with a modified waterfall approach, which has several overlapping phases. This chapter covers activities that may occur in the overlapping Define and Design phases.

Define project development

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

user interviews or research. Doing this with your design team before prioritizing allows you to consider and plan for innovative features that meet both your business and user needs. Prioritize design requirements. This includes taking a built-in list

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

Planning determines how you will work with other team members and what kind of tools or documents they will receive from you, such as site maps and diagrams (discussed in Chapters 10 and 11). This chapter covers each of these three areas, starting with an ideation and visualization method that is easy for a UX designer to use in collaboration with project team members.

TRANSITION: FROM DEFINITION TO DESIGN

145

Typical Scenario The requirements are defined and approved, and you are in the process of designing the terrain features in your plan. Halfway through the design process, you realize that sharing a specific tool will be really useful for your users. It's an interesting idea, but there are no requirements that describe this new tool, so enabling it now requires changing the priority requirements. You'll need to make a strong case for changing the list of requirements, especially if it means that something else has to be removed from the list (deciding what it is will take some time) or that the project's schedule may be delayed. There's a chance the idea wasn't included simply because it arrived too late in the game. While new ideas can come up at any point in a project, taking the time to come up with features after requirements gathering is complete but before prioritizing helps generate those ideas faster and increases the likelihood that they'll be incorporated. It also ensures that you take the time to consider innovative features that may not have occurred to your business stakeholders or users.

Inventing and visualizing Features UX designers have a unique skill set that helps bridge the mental gap between words (like requirements) and images (like sitemaps and mockups). Although people talk about requirements and argue about language, often they won't really be on the same page until they see a concept visually presented. On the other hand, if you jump to specific visual details too quickly, you risk focusing the conversation on smaller details (for example, whether an option on a form should be a radio button or a drop-down option) before answering questions. (as if your users have to fill out that particular form first). There are many conceptual design techniques that can be used throughout the process that help visualize the context, flow, and story in ways that engage others before detailed design begins in earnest. So are these techniques

146

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

highlight the need for features that can be added to the requirements document before prioritization occurs. One such technique is collaborative storyboarding: visualizations of individual user scenarios sketched on paper or on a whiteboard during a brainstorming session. The UX designer then works from these sketches to add details.

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

where your user or persona model will come in handy. If you have them, bring them to the meeting; both will focus the conversation and ensure the design team has a better understanding of how they can use user modeling tools in the design phase. Is the selected user the first user of the site? If not, is it sporadic?

user, do you use it often? This will affect the level of features you will cover; a novice user may be overwhelmed by the number of options that a frequent user might like. You can go through the scenario twice to discover different features each group might need, such as context-sensitive help for new users or customization features for frequent users. What urgency brought this user to the site? what are you trying

follow and why? You can gain insights by looking at high-level tasks covered by your company or user requirements, such as "find product recommendations". Perhaps the user wants to find product recommendations because they need a pair of snow boots and want to make sure they don't drip or get their feet wet. Get your team together to brainstorm sessions. This team may be just you and one other person, or it may be a small group of three or four other people. (More is possible, but it can be difficult to get everyone around the board effectively and focus them on the task at hand.)

IDEAS AND VISUALIZATION OF FUNCTIONS

147

Ideally, at least one person in the group should be responsible for representing the user's point of view. Another must represent a business point of view (for example, a business stakeholder or business analyst if that role is represented in the project). That doesn't mean you can't change your perspective; You can and should consider both user needs and business needs as much as possible during the discussion. See the section "Keeping Good Tension" for more information on balancing user and business needs. Once the team is assembled, tell them what your goals are: to understand some of the features you might need to meet your business and user needs, and to focus on future design work. Provide answers to the above questions and a list of scenarios to discuss. Then go to the board (or put pencil to paper) and ask the group questions about the scenario, such as: How is this user likely to get to the site? Consider online search, banner

advertisements, word of mouth and other opportunities. If online searches come to mind, do the requirements reflect exactly

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

high-level details. Are other people involved in this task? If so, how can they be involved?

(telephone, email, collaboration site features) and how might they influence the decisions or behavior of the primary user? Where might the user need help along the way? How will you get it? What happens when the user finishes his task? A common design error

take is to think you're done when the user's task is complete, but it's a good time to encourage the user to explore other areas of the site or consider purchasing related products. Consider an example of a typical business scenario: you need to post a new job on your company's .com website. For the purposes of this scenario, let's assume you interviewed stakeholders and discovered that the hiring process is primarily managed by one person, call him Jeff, in the human resources department who works with those who need to hire. 148

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

Jeff is quite familiar with today's job descriptions. When a new job is needed, you usually find out when a potential manager for a new position asks you to post a job. So it's a collaborative process between Jeff and the manager (let's call her Emily) to write and publish a job description. Figure 9.1 illustrates what a storyboard for this scenario might look like. The figure only shows part of the storyboard you can create here. You might start earlier in the storyboard to show the approval process Emily had to go through, or you might want to continue the storyboard to show the job seeker finding and applying for a job. The important thing to note is that such a storyboard allows you and your design team to see your workflow as more than just a series of pages. It brings a human element and context. And without the human element of the person (Jeff), your team might not have thought of enabling the Get Existing Job Description feature, even though we've all done it to save time and make sure we've got everything we need in it.

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

IDEAS AND VISUALIZATION OF FUNCTIONS

149

One thing to keep in mind when using storyboards and other types of sketches (such as user flows and conceptual frameworks) is that they are primarily intended as brainstorming tools. While great ideas emerge from this exercise, these sketches are not meant to be detailed designs. This fact can be seen in draft form (as opposed to prototype form), but it is still an important point for business stakeholders as seeing features visualized even in a sketch can sometimes raise expectations that they will be present in the final product. Another risk is that participants may become distracted by discussions about UI elements such as whether something should be on the page or in a pop-up window. It's very easy to get into these detailed discussions because these kinds of problems are often easier (or more familiar) to solve than the larger problems the scenarios are designed to solve. To streamline operations and use time efficiently, ask participants to save this type of discussion for the point you are designing based on a priority list of requirements. And that brings us to the next step in the process: the often lively, sometimes painful process of prioritizing those beautiful requirements you've spent so much time collecting!

Facilitate the prioritization process You have your own set of business requirements, which have been developed using features based on user requirements and your work on ideas. Now comes one of the hardest parts: narrowing everything down to a prioritized list of high-value requirements. When discussing which requirements to prioritize, keep the project goals and user model handy to help focus the discussion on your target audiences. In addition to you in your role as a user advocate, the prioritization process should also include: someone who represents the company's point of view (companies

spokesman). Someone who represents the point of view of the development team (so-called

development advocate.

150

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

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

manager). This person may not need to attend prioritization meetings, but will identify any constraints affecting prioritization (such as timelines or budget) and make sure the final list adheres to them.

The Role of the UX Designer in Prioritizing It can be tempting to see prioritization as a shared responsibility between the project sponsor, project manager, and development team leader, rather than as a problem for the UX designer. There is nothing further from the truth. Prioritization discussions are where successful solutions are made or broken. User experience designers have a responsibility to use their skills in these important conversations. If you are already part of the prioritization process, this section provides guidance on how to get involved. If not, do your best to get involved. This means you need to inform the project team about the skills you bring, such as facilitation, and the balanced perspective you can bring. Demonstrating that you can understand the point of view of different team members and working together to achieve a unified understanding is essential. See the "Maintaining Good Tension" section for more information on how to achieve this balance.

The prioritization team goes through each of the requirements to answer the following questions: What is their level of importance to the company? How important is the

requirement to achieve one or more project objectives? How much impact does omitting this requirement have? What is its level of importance for the user? Does it meet the requirements

common user need (or needs with a high impact on priority user groups)? How will this affect the user experience if this is omitted? Are there other requirements that are very similar and can compete? For the latter question, keep in mind that multiple solutions to the same problem can compete and cause confusion among users (as well as require more effort to support). For example, the New York Times may have a development team large enough to handle all the sharing features.

FACILITATING THE PRIORITY PROCESS

151

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

How long does it take to develop it? If you are working with relatively new technology, the estimated time here will be longer. What is the profitability of funds for its development? Design

does the team have the people, skills and money to develop this feature? (Take into account the cost of purchasing and learning new technology tools.)

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

152

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

Create a worksheet that captures your decisions for each requirement. This can include a low, medium or high rating based on the questions above, or you can use a numeric scale to add numbers to your ranking. As you move up the list, you may need to consolidate similar requirements or split one large requirement into several smaller requirements that represent potentially separate units of work. Keep in mind that this system is just there to help you sort and prioritize; it is not based on a scientific feasibility study. However, it is very useful for managing a large list, inspiring discussion, and capturing relative importance. Figure 9.3 shows an example of a prioritization worksheet that uses high-level categories of importance and feasibility (low, medium, and high) to assign relative values to each requirement. Prioritization worksheet

Requirement

Description

commercial importance

User Meaning

&%**%&

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

((("!%

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

("!%

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

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

((!)*&(/

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

((

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

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

((

+#2##$%* *

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

Technical lifetime

resource feasibility

!+$

Figure 9.3 Example of a requirements prioritization worksheet

FACILITATING THE PRIORITY PROCESS

153

Przypisanie wartości do każdej z kategorii zainspiruje wiele rozmów w zespole ustalającym priorytety. Jak możesz ułatwić dyskusję i podejmowanie decyzji? Dwie najważniejsze rzeczy, które możesz zrobić, to zrozumieć (a czasami reprezentować) różne punkty widzenia, które są kluczowe dla określenia zrównoważonego rozwiązania, i pomóc rozwiązać obszary konfliktów w zespole projektowym. Najpierw porozmawiajmy o reprezentowaniu właściwego zestawu punktów widzenia podczas ustalania priorytetów. Wiąże się to z tworzeniem i utrzymywaniem napięć między rzecznikami użytkowników, rzecznikami przedsiębiorstw i rzecznikami rozwoju — dobry rodzaj napięcia, ponieważ zapewnia zrównoważone rozwiązanie, które zapewnia dobre wrażenia użytkownika, spełnia ograniczenia projektowe i jest zgodne z celami biznesowymi.

Maintain a good tension During your requirements gathering, and throughout the rest of your project, you may notice that three roles play out during team discussions:

154

Business Champion – A team member who represents the company's needs and requirements and ensures that they are captured and met as faithfully as possible. The main concerns of the business advocate are to achieve the strategic goals of the company and the department, ensure that the business vision is not lost during the project, and to establish and maintain a focus on the goals of the project. User Advocate: A member of the team representing the needs and perspectives of the main users who will interact with the site. The main concerns of the User Advocate include ensuring that the site meets usability expectations, providing a satisfying and engaging experience, and encouraging behavior that supports the design goals. Development Champion: A team member representing the needs and constraints of the technology and QA teams. The main concerns are to ensure that the development team works efficiently and within scope, and that it delivers a product that meets the quality standards expected by users and business stakeholders.

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

Imagine it's a three-way tug-of-war between the defenders. If the tension between these three parties is maintained respectfully (meaning no one advocate dominates), then all three parties can work towards a well-balanced solution that meets the goals of the project. Each team member must be aware that they are interested in maintaining balance throughout the project. If one side dominates, the other roles lose importance and the project risks missing its goals or achieving them at a cost much higher than expected. See Figure 9.4 for examples of what can happen when the voltage is unbalanced.

Figure 9.4 Consequences of not maintaining good voltage

KEEP GOOD VOLTAGE

155

Can you fulfill more than one of these roles in the project? Absolutely! Ideally, different team members have primary responsibility for each role, but that doesn't mean you can't switch places from time to time. In fact, you can switch roles from one discussion to another, and even from one topic to another. As a UX designer, you will most often play the role of an advocate for users, but you must understand the viewpoints of all three roles and ensure that they are consistently represented to create successful designs. While it's healthy to switch roles from time to time, be careful to designate yourself as the primary person responsible for more than one of these roles. You can start making irrefutable commitments as the project progresses, because you won't have a "devil's advocate" around you all the time asking you those awkward but important questions. If you have to fill more than one role, try to find a part-time employee who can fill other roles from time to time to ensure you maintain a good tension. Up to this point, we have largely focused on the roles of the business advocate (especially in chapters 4 and 5) and the user advocate (especially in chapters 1 and 6). Let's take a moment to discuss the third main role in our prioritization discussions: the development advocate.

Development Advocate If you're a UX designer at heart, you thrive when you put yourself in the shoes of others to understand their needs and goals. This skill is invaluable both in your role as a user advocate and in ensuring effective communication and collaboration with the people in your organization. Let's take a moment to use this skill to outline the goals of the development advocate. One of the great project debates is to what extent the development ombudsman should be involved in and influence the requirements gathering process and what is his/her role in this process. If the development ombudsman presents the technical possibilities and constraints too early, it may limit part of the brainstorming that could lead to very innovative solutions. After all, the idea of today's blue skies may be possible with additional technical research. Even if the idea isn't feasible, discussing it can trigger a basic need that you can fill. (Mapping function requests to needs is discussed later in this chapter.)

156

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

These are the programmer's goals and related responsibilities: Deliver requirements on time and within budget Ensure team efficiency (avoid redundant work, ensure good

make the best use of available tools and platforms Choose cost-effective additional tools Make sure that future changes will not require much effort Make the solution scalable to accommodate growth Make a modular solution so that individual parts can be easily changed Make the solution as standardized as possible: as few changes as possible

in the purchased system, less rebuild work will be needed in the future. Make sure the development team is working well. Reduce rotation by providing relatively interesting and rewarding work.

gram

Working with Legacy Requirements Step 4

Paso 1

Review the requirements and mark those that have unclear needs or questionable value for the user.

Inherit tons of requirements and do an initial review.

Step 2 Gather information that provides context about potential users.

"Users are..."

Step 5 Review the selected requirements with your team to explore needs and conflicts. "This is why."

TEN

Step 3 Create a temporary user model.

Step 6 Prioritize any changes you feel are necessary. Display them and present them to the design team. Be direct and pragmatic.

pne

"Good point!"

"Mmm..."

KEEP GOOD VOLTAGE

157

However, if the developer doesn't get involved early enough, the team may go very far down the path of a particular option only to discover that it is too expensive to include, or the developer may lose one or more of their own goals. . Finally, the developer spokesperson is a great resource for some of the technology opportunities that can really make your solution stand out, such as new technologies or underutilized features. An effective approach is to schedule key reviews with the Development Ombudsman once the brainstorming is over, the high-level requirements are defined, and the prioritization process begins. This allows the Development Advocate to spend the early part of the process researching a selection of tools to get more details on what may or may not be possible, and then become more involved in the requirements process as certain topics and ideas gain more weight . If you feel that certain requirements gathering sessions are crucial for the development ombudsman, make sure you are both on the same page beforehand regarding your role in the meeting and how to capture any potential concerns the ombudsman may have. After the audition. You can also record these types of sessions to review with the developer later. You may need them yourself while you are designing! This type of clear communication and follow-up during information gathering is essential to building strong relationships among team members, which can make a big difference in the prioritization phase later in the process. But sometimes, despite your best efforts, conflicts arise when you try to prioritize requirements. Let's talk about how you can help your project team manage this conflict.

Conflict management during prioritization If there are large areas of disagreement, prioritization can be a lengthy process. And if these misunderstandings are not resolved, they will continue to arise during design and development. These conflicts can have many different root causes; Here are some of the most common:

158

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

The team is not on the same page as to the project's goals or understanding

Deceptive business strategies (due to misunderstandings, forgetfulness or misconceptions about them). Members of the opposing team are closely related to a specific set of traits.

(Maybe they were excited about features or promised a group of influential customers or stakeholders.) There are conflicts between business needs and user needs that are not

easy to solve. The technologies used are relatively new to the development team,

so they feel uncomfortable making estimates. Let's take a few of the above situations and discuss how as a user experience designer you can participate in solving them.

Picking Your Battles During the prioritization process, some of your favorite features may be on the fringe. It's easy to start feeling dissatisfied with this, especially if it seems that user requirements are the most frequently removed from the list. If you passionately advocate for equal requirements, you run the risk of making priority decisions for you. Here are some questions to ask yourself when deciding when to push for a particular requirement and when to back off: How does the requirement support the goals of the project? Does it significantly reduce a specific risk? For example, does it reduce users' exposure to spam by reducing negative reviews for the site? Do other proposed site requirements based on these requirements work correctly? What is the impact if the feature is not included? Is the value of the feature worth the effort you put into developing it (even at the expense of other features you value)? If you have a strong answer to all of them, bring them to the prioritization table to make your case. If not, consider letting go, but be sure to share your reasons so others can see that you're committed to the greater good of the project. This will demonstrate your ability to consider the broader business context and solidify your commitment to future prioritization discussions and requests for change.

KEEP GOOD VOLTAGE

159

Disagreement towards the project The team is not on the same page when it comes to project goals or underlying business strategies. Let's split this source of conflict into two areas: communication and consensus. If communicating project goals or business strategies is a problem, ask yourself how you can personally improve communication. Is it about posting goals or strategies where all team members can see them (for example, in a meeting room or online collaboration area, or at the top of every meeting agenda)? Or maybe you need a visual representation of your goals or strategy to help your team stay focused and enthusiastic about the vision they're working towards. Remember the visualization skills discussed at the beginning of this chapter? Use them to create an image that's easy to print and post, or quickly sketch on a whiteboard to help keep conversations focused. If consensus is an issue, ask yourself how you can help bring everyone together. Is the conflict caused by a fear of giving users a completely different set of features? You can conduct research to help resolve some misconceptions, such as surveys, interviews, or contextual inquiries (see Chapter 6). Or maybe you can use your facilitation skills by having a structured discussion of disagreements, going through issues point by point until they are resolved. Conflict over favorite features Opposing team members are tied to their own feature sets. Suppose the head of the training department wants built-in topical tutorials, and the head of sales wants to send an exciting presentation to generate interest. Meanwhile, you have ten other business stakeholders in different roles, and they all have pressing needs. How do you help build consensus? One method is to use a variation of the method you read about in Chapter 6: Creating Affinity Diagrams. In this method, you can either work with an existing set of requirements or ask stakeholders to brainstorm their own requirements (especially useful if you are still in the early stages of the requirements gathering process). If you are working with existing requirements, you can print them

160

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

individual pages and stick them all to the wall. If not, ask stakeholders to write down their main requirements on a set of sticky notes. What you'll need: A room large enough for a group of stakeholders to move around and

that has one or more large blank walls on which to stick sticky notes Block of large sticky notes, at least one for each shareholder Sticky dots (found in hardware stores)

bear colors), one set of ten points per stakeholder Gather the key stakeholders in a room and ask each of them to take time to write down the key requirements, one on a piece of paper. Give them 15-20 minutes for this. (No peeking!) Ask everyone to post their requirements on the wall. Then ask each person to come up and describe what they posted. As you walk around the room, start grouping similar requirements (if stakeholders agree they are similar). Once the requirements are clarified and grouped, hand out the sticky dots. Tell stakeholders that they can indicate which requirements have the highest priority for them by assigning them points between sticky notes. They can choose to put all ten points on one requirement, for example, if they think it is so important, or they can choose to put one point on ten different requirements. You will start to see clear favorites as people place their points. When you have finished placing the dots, discuss the results together. Forced to make such a choice, stakeholders will present their own internal priorities, and the conversation will probably become much easier.

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

KEEP GOOD VOLTAGE

161

This type of technique can help speed up the prioritization process or reset a process that has stalled due to disagreement. Once you have built momentum and shared understanding, it will be much easier to complete a prioritization document (like the one we saw in Figure 9.3). In parallel with your prioritization activities, you need to prepare for the full design work that is about to follow. Having a work plan will help you estimate the effort needed to create detailed designs, integrate your work with that of other project team members, and coordinate efforts to align with project milestones. The next section covers some considerations to help you plan.

Plan your activities and documentation Once you have a prioritized list of requirements and, ideally, some early concept work completed (such as the storyboards illustrated earlier in this chapter), the project manager will probably start asking you for details of what you are doing. do as you design. There are several types of design activities, and each will have a different impact on how you design, how much time it takes, and the type of document you create. It is a "document" in the general sense; it can be a sketch on a whiteboard, a wireframe, or a prototype. In the next three chapters, we'll cover some interaction design activities. When planning the activities you will use, keep the following questions in mind: How iterative will the whole process be? Ideally you can start with

Quickly explore several different concepts (e.g. with sketches), then agree on one to develop it further. This approach may also involve presenting users with one or more design concepts (see Chapter 13 for more information on design testing). How does the collaboration during design work? If you work closely

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

162

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

How will your design documents be shared with the larger team? If

Do you email them to a small team or post them to an online collaboration site? What does this mean in terms of size limits and version tracking process? How much detail will your designs require at a later stage of development

process? If your documents are part of a formal Quality Assurance (QA) process, you need to engage someone from the QA team early on so that they understand what details they will get from you. How long do your documents have to live? With complex projects

the moment you stop updating a document like a schematic set it starts to "die" - the details get more and more inaccurate as time goes on. (This isn't always a bad thing, as long as you participate in the discussion of these changes.) Documents that focus on providing general guidelines, such as a branding guideline or an interaction design pattern library, tend to have a longer lifespan. Who are the main users of each type of documentation? This answer

may be different at different points in the project. The primary users of conceptual design documents are usually business stakeholders and the project team, who use them to communicate and disseminate ideas. Detailed design documents are primarily intended for developers who need to implement projects; these documents contain a specific address. What other types of documentation will you have to adapt to? you will do it

You need to provide some relationship between the prioritized feature list you created earlier and the layouts you create. You may also need to keep an eye on various other types of documents to make sure they're all on the same page. These documents may include brand guidelines, content roadmaps, functional specifications, or use cases (see Chapter 2 for the different roles and types of documentation they can produce). How to estimate the effort required for each type of document? This

one is difficult because there are many variables in the design that can affect timing. But by setting a baseline for your rough estimate, you'll have a starting point and be able to verify the numbers as you learn more. For example, you can set a baseline estimate that each detailed structure will take approximately 6 hours to create. If you are evaluating a specific feature

PLAN YOUR ACTIVITIES AND DOCUMENTATION

163

will require about five pages (for example, based on the results of the storyboarding sessions described earlier in this chapter), you will have an initial estimate of 30 hours for this feature. If you end up needing eight pages per structure, try to figure out why. If you think this will continue, you will need to revise your estimates and possibly change your priorities. What additional factors will affect the time of the document? Total

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

Will you share the work? If you work in parallel but separate areas of the site, you can work quite independently on the documents you create. If you share work in a highly interdependent way, you need to schedule time to reconcile projects, and you may also need a way to track and merge different versions in different documents. Save yourself a huge headache later by working out the process up front and setting design guidelines early so you're on the same page for key elements like navigation. Now that we've covered some of the things to consider when choosing design activities, let's take a look at these activities. In the next three chapters, we'll look at a variety of documents, including sitemaps, workflows, mockups, mockups, and prototypes.

164

CHAPTER 9: TRANSITION: FROM DEFINITION TO DESIGN

Sitemaps and Workflows Structuring a Project From Here and Back Sitemaps help identify the structure of websites and applications. They can show hierarchies and associations that allow audiences to understand where users can locate content. Taskflows take sitemaps a step further by identifying different courses of action that a user can take in a site section. Task flows also draw links to error states, content, or page views based on decision points throughout the process. When used together, sitemaps and taskflows can give your audience a clear idea of how your content is structured and how users can navigate through it. Russ Unger

165

What is a sitemap? 1.0

1.0.1 Regulations

Home

2,0 – 2,x

3.0

Blog

4.0

5.0

Work

Contact

Figure 10.1 Sitemap for a basic site with blog functionality

Starting with the most basic definitions, a sitemap is simply a visual way of displaying representative pages of a site (Figure 10-1). A simple sitemap usually fits on a single sheet of paper and looks similar to an employer's organizational chart. However, sitemaps are not just for websites; you can use them in any type of application that benefits from identifying pages, views, states, and instances of everything that is displayed. Most of the time, you'll use a sitemap to show colleagues and clients how your site's content will be organized. It will give you an overview of your site navigation and in some cases will show you all the links that each page may have.

What is a workflow? Figure 10.2 Basic task flow showing user path based on login status

Home

Is the user logged in? Website without logging in

Workflows identify the paths or processes that users (and sometimes the system) will follow as they navigate a site or application (Figure 10-2). While sitemaps and taskflows may seem similar at first, the two types of diagrams serve different purposes: a sitemap shows a visual hierarchy of a site or app's design, while a taskflow provides details about user options and routes. they will be able to take 166

CHAPTER 10: SITEMAPS AND TASKFLOWS

Commercial tools If you're new to user experience design and need a work product development tool, you have many options: Microsoft Visio (http://office.microsoft.com/visio) Axure RP Pro (www.axure.com) OmniGraffle ( www.omnigroup.com/applications/OmniGraffle) Adobe InDesign (www.adobe.com/products/indesign) Adobe Illustrator (www.adobe.com/products/illustrator) Microsoft PowerPoint (http://office.microsoft.com/powerpoint ) OpenOffice Draw (www.openoffice.org) HTML Blueprint CSS (www.blueprintcss.org)

So how to choose? You can ask other designers; everyone has a favorite and is usually happy to name it. Just don't be surprised if they, like their authors, answer "nice pen and paper." You can also try free online trials or opt for a free solution like OpenOffice Draw, which is part of the OpenOffice.org toolkit and generates the same formats as popular office suites. What do we use besides pencil and paper? Many of the examples in this book were generated with Microsoft Visio 2003 using templates created by Nick Finck, director of . Nick's awesome stencils can be downloaded from www.nickfinck.com/stencils.html. These ready-to-use templates, shapes, and samples are invaluable to both new and experienced practitioners. In addition to Nick, check out the Information Architecture Institute, which provides many of these tools on its IA learning website: http://iainstitute.org/en/learn/tools.php. Note Microsoft currently offers Visio 2007; however, many companies have not yet updated the product and to avoid version differences, we currently recommend Microsoft Visio 2003.

TRADE TOOLS

167

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

Sitemap and workflow basics The most basic elements of the drawing program are more than enough to get you started creating sitemaps and workflows. However, in order for your creations to be easily interpreted by a wide audience, it is best to use a standard set of shapes. Visual Vocabulary for Information Architecture is one such standard used throughout this book. Created by Jesse James Garrett, one of the founders of Adaptive Path (www.adaptivepath.com), it is available online at www.jjg.net/ia/visvocab. The site has many elements to help you articulate sitemaps and workflows, all of which are available with detailed descriptions and as downloadable templates for many popular drawing and sketching programs (more on that in a moment). To help you get started and familiarize yourself with the basics, the following sections cover a basic set of visual vocabulary items and what they represent. Figure 10.3 Page entry from Jesse James Garrett's visual dictionary

Figure 10.4 Stack position of pages from Jesse James Garrett's visual dictionary

Page According to Jesse James Garrett, a page is "the basic unit of user experience on the Web." "Instances" or "views" of content may be more realistic today, but the page still matters a lot. There are several ways to draw these pages, but the simplest and most commonly used format is simple drawing.

168

CHAPTER 10: SITEMAPS AND TASKFLOWS

rectangle (Fig. 10.3). As you progress with your sitemaps and workflows, you'll want to find the style that best suits your labeling and page numbering needs.

Page Stack A page stack represents many pages of similar content (Figure 10-4). An easy way to understand page stacks is to think of dynamic content, like a regular blog page built with a publishing system. These pages are designed once and are in one layout template, but you have the option to click through many different content pages without leaving the original template layout.

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

access

(10 a)

mistake

member house

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

BASIC ELEMENTS OF NETWORK MAP AND JOB FLOWS

169

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

Connectors and arrows are used to show movement or progress between pages, page stacks, decision points, etc. Connectors usually appear where there is a call to action from one page to another. For example, a link to an About Us page from a home page could be a link between two pages. The arrows (top of Figure 10.6) indicate movement "down" towards task completion. Crossbars (lower part of Figure 10.6) can be used to identify when a return to the originating page (an "up" move) is no longer available. For example, when a user logs into a website, the content of the home page can now be customized for the user, and the general page or login page will no longer be available to the user from the route you just visited. Next.

Conditions

Figure 10.7 A conditional from Jesse James Garrett's visual dictionary

The dashed line is a fairly common way to show a condition. It can appear in sitemaps, task flows, and other work products that you create or invent. You can use a dashed line as a connector (as in Figure 10-7) or a border around an area to emphasize that a page or section of pages is linked to another action or event.

170

CHAPTER 10: SITEMAPS AND TASKFLOWS

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

Sloppy Connections Figure 10.8 Lost connection between two parties

Messy connections are just that: messy. They are badly drawn. They look very amateurish and give the author the impression that you do not pay attention to detail in your work, to put it mildly. Most tools have some method to help you connect your lines to your boxes. Take advantage of it. Don't be lazy, no matter what time constraints or pressure you may be under. In most applications, a combination of Shift and other keys allows you to drag items from the starting point in 45-degree increments. Use this built-in feature and make sure your connections are well connected. If you are showing pencil sketches, you should have an eraser handy just in case. Make it a ruler: always make sure that lines touching any other object are connected exactly.

COMMON ERRORS

171

Poorly positioned and irregularly placed objects

Figure 10.9 Pages that are misaligned and unevenly spaced

Depending on the tool you're using, it can be difficult to ensure that objects are accurately aligned or evenly spaced in a sitemap or task flow. There are a few fairly simple ways to make sure you follow this basic rule. To get started, enable grid in any app you use. This way, whether or not the tool offers options to ensure objects are evenly spaced and aligned correctly, you can always count the number of meshes between objects. Fortunately, when you use pencil and paper, you can use graph paper and apply the same basic principle. It's so easy to make your documents look professional. Unfortunately, it's just as easy to make documents look like you don't care about the quality of your work.

Misplaced text Figure 10.10 Inconsistently placed text

Step 1 Step 2

Careless text placement (as in Figure 10-10) seems easy to avoid, but it's another common mistake. Find a way to make the text fit snugly into the shape you created, and make sure any tags placed outside the elements have the correct connections (Figure 10-11). 1.0 Home

172

1.0.1 Regulations

CHAPTER 10: SITEMAPS AND TASKFLOWS

Figure 10.11 Well placed text

It may seem trivial, but the right text placement, along with the right font size and use, will make your documents easier to read and use.

No Page Numbering Time for another rule of thumb: number every page of every sitemap you create. Don't create a hazy, countless map like the one in Figure 10-12. Conditions &

Home

Blog

Conditions

Work

Contact

Figure 10.12 Site map without numbering structure

Each page referenced in the sitemap should be numbered, and the numbering system should allow for subsequent changes as new iterations and revisions of the design are made. You can take different approaches to page numbering; the most common is identifying the home page as 1.0 or 0.0.0.0 (Figure 10.13). Over time, you'll be able to determine which one is best for you, but until you feel comfortable and understand the pros and cons of both approaches, start by defining your homepage as 1.0. This method makes it possible to include any decisions and pages that may come before the home page, such as a Flash preloader, a login or registration screen, or many other types of pages, such as 0.X. The numbering system in your sitemaps allows you to synchronize with other documents. The numbering system can be extended to other documents, such as a content matrix. Content creators can attribute their copies and other content to them

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

the user will cycle through the pages of the specified task. Wireframe models (see chapter 11). Your skeleton pages should share

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

COMMON ERRORS

173

visual design. Visual designers can synchronize layout pages and elements

specific pages in the sitemap. This allows them to segment inventory when it's time to deliver designs to developers. Quality assurance documents. QA teams can create tests

scripts dedicated to a specific page or pages in the sitemap. Your attention to detail and structure at this point helps everyone else touch the project on the right track and gives them structure for their tasks. 1.0

1.0.1 Regulations

Home

Blog 2.0 – 2.x

3.0 O

4.0 Work

5.0 Contact

Figure 10.13 The Site Map links pages correctly, elements are aligned, evenly spaced, and numbered appropriately

In short, page numbering in your sitemap will make life easier for everyone else, and that means your life will be easier too.

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

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

174

CHAPTER 10: SITEMAPS AND TASKFLOWS

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

Let the pain be very good

February 9, 2008

P. 3/9

Figure 10.14 Advanced sitemap home page view

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

ADVANCED SITEMAPS

175

Let the pain be very good

February 19, 2008

page 4/9

Figure 10.15 Advanced view of the sitemap section

Any pages you create after the first page should basically map to it. For each top-level page, you should have at least one Next Page, which identifies all the pages, page stacks, and external content that will be required for your site or application (Figure 10-15). Don't be afraid to combine subpages if necessary. Sitemaps can be larger than a sheet of standard-size paper will allow. This is not a cause for concern as long as your sitemap is well organized and connections are clearly documented for your audience. These examples are more than enough to get you started in the world of sitemap creation. As you start working on different projects and notice that your skills (and often the needs of your team or client) grow, you will discover that there are very different approaches and methods you can use to deliver maps. side.

176

CHAPTER 10: SITEMAPS AND TASKFLOWS

Breaking the Sitemap Scheme You've already seen some solid examples of sitemaps that should cover most of your basic task needs. Don't let these models stop you from exploring the ways that work best for you, and share them with us! Different approaches can highlight information beyond the basic site architecture. For example, consider the sitemap in Figure 10-16, kindly provided by Andrew Hinton, senior information architect at Vanguard. Supervise new research

bc.org support

access

Update profile

Find similar people

"Academic" interests (medical, student, general)

Participate in something

Conversation Get Printed Mtrls

Learn more about bc.org

new concern

Manage risk

worried beloved

Socialize

Experts Conference Participate Learn

New Diag New Scenario / Siad.

Figure 10.16 Advanced sitemap. Courtesy of Andrew Hinton.

This sitemap not only shows the different pages of the site, but is also used to provide information about the routes and priorities of the users. Andrew (www.inkblurt.com) says he created the sitemap after seeing an example from Wolf Noeding that ignited his creative flame. Andrew uses this sitemap to show different user scenarios and mental models related to the site. The larger circles on the map have an additional function: they highlight the top-level areas of the site that generate the most traffic. Like all good UX professionals, Andrew borrowed but also gave credit. There are endless ways to expand your sitemaps once you start to feel more comfortable using the tools and identifying the needs of your work product and client. Let inspiration hit you where you find it! Don't be afraid to try something new, but take your time to make the time you spend useful and valuable.

BREAKING THE FORM OF THE SITE MAP

177

Taskflows Using many of the same basic elements as sitemaps, taskflows are diagrams that identify the path or process that users (and sometimes the system) will follow as they move around your site or application. You can use task flows in several different ways. Combined with a sitemap, they can show how a user lands on a page that contains a specific set of information. They are sometimes used to show how a certain type of user (person) would expect to navigate a website and what that person would expect to see based on their personal mental model. Task flows can also be used to identify complex processes that need to be thoroughly understood before submitting a project to the development team. You may not use workflows on every project you work on, and they may not always end up as a work product that you present to your clients, but it's always worth using them, even if only with a pen, and - formatting on paper for your own benefits. A little clarity can go a long way. To create a task flow, you need to understand the user's goal. In some cases you will receive a requirements document and in others you may receive (or create) a use case. Although the use case consists of only a few sentences summarizing tasks and goals, it will allow you to synthesize the user's view of the experience. A use case for the scenario in Figure 10.17 might look like this: The system displays a list of projects. The user selects a project. The system displays basic information about the project in save mode. The user changes the status of the project to Closed. The system checks pending jobs. If there are pending jobs, the system displays an error message. If there are no pending jobs...

178

CHAPTER 10: SITEMAPS AND TASKFLOWS

The system verifies pending payments. If there are pending payments, the system displays an error message. If there are no outstanding payments... The system displays a summary page.

Home [My Claims List] Select a Claim

About [Writing Mode]

Claim status changed to closed

Pending tasks?

error notification

[Show pending tasks and requests] Yes

Pending payment request?

Information [Read-Only Mode]

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

The task flow in the figure shows the sequence of information displayed to the user depending on whether various use case conditions are met. If any of the questions in the hub ("Tasks pending?" or "Payment pending?") are answered in the affirmative, the system will display an error message that may provide additional information to help the user complete the required tasks before proceeding. . If the answer to both conditions is no, the system displays a success screen to the user. The workflow in Figure 10-18 illustrates the paths a user can follow from a calendar application to a travel shopping site. The task flow is of a very high standard as it identifies three very different paths that require users to test them to ensure that the detailed flow for each path meets the user's needs.

TASK FLOW

179

S100 Calendar Shopping Calendar Rate Finder

S10 Detailed fee finder

to look for

Price Search (Rate Matrix Screen)

Search by schedule

flexible dates

select R20 Search results (by price) - View travel plans - Edit search

P30 seat selector

review

R60 flexible search result dates (by price)

R10 Search results (by time) Show segments - Edit search

P10 View itinerary/passenger information - select seats

purchase

P20 Payment and billing information

Key

Side

many pages

Confirm

P50 confirmation

Decision point connector

conditional link

Figure 10.18 Workflow used to demonstrate the user's path through the phases of the purchasing process

Users of this app can enter a set of travel dates and then make purchases based on their own priorities. Once tour search dates are set, users can prioritize the results by what is most important to them: price, flexibility of travel dates, or travel time (schedule). The task flow identifies high-level paths that a user can take to give instructions to those facilitating the test. You can create detailed workflows for each of the paths in groups, and then hand them over to the development team to create the pages needed for testing.

180

CHAPTER 10: SITEMAPS AND TASKFLOWS

Taking Workflows to the Next Level As with all the topics in this book, don't think that what you're looking at is the beginning and end of the workflow universe. Explore new applications and extend your use of the core concepts described here as much as possible as long as there is a good purpose for it. As you improve your ability to perform tasks, you may find yourself creating a work product that is a bit more colorful, has more options, contains modified or improved language rules, etc.

Process Flow Figure 10.19 shows a task flow that Will Evans (www.semanticfoundry.com) took to the next level and turned into a process flow diagram. Their process flow is very high and flexible and is used here to show that in many steps of the design process the first phase of the design seems to be just one step, however in this particular case it is important to understand that the phase is not made up of one events. Instead, in this case, the first phase of the project consists of many different activities: User research Market research Ethnographic and contextual research Usability testing Competitive analysis Market analysis Cultural analysis Log file analysis

TAKE YOUR WORKFLOW TO THE NEXT LEVEL

181

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

For each of these activities, reports are generated that feed into other miscellaneous documents before the start of the project, where the necessary stakeholders will meet to determine the scope, priority and deadlines. All this is shown in the process diagram. As you can see in this example, the sky is the limit when it comes to creating workflows. Take a look at the example above and think about how to take your products to the next level. It may take some practice, but with a little finesse, you can create workflows that will delight your customers.

Swimlanes James Melzer (www.jamesmelzer.com), Chief Information Architect at SRA International Inc. (www.sra.com), has created a series of diagrams that go well beyond basic workflows. The diagram in Figure 10-20 shows a workflow that has been extended to show "lanes" of activities, notifications, and so on. in a process where many events happened at the same time; With this design, you can use the traditional approach to workflows. that was a nightmare!

182

CHAPTER 10: SITEMAPS AND TASKFLOWS

Instead, James explored extending the basic workflow to cover all the steps and actions that take place in a much easier to understand format.

Figure 10.20 This belt diagram is an example of extending workflows to illustrate complex scenarios with many activities in many places. Courtesy of James Melzer.

James described the design and belts as follows: The system allows people to manage information about the buildings they own. This extension would allow building services partners to provide system data on behalf of their clients, reducing the need for data entry by property owners. The project consisted of three parts: partners configuring the presentation and operation of their data services, customers registering and using partner data services, and ongoing partner data management and troubleshooting in the backend. We planned a major expansion of the existing system. We knew from the start that almost all service scenarios involve multiple users and multiple systems. There were many notifications and many processes were asynchronous. This diagram helped us identify, design and explain the service scenarios needed to deliver the project. In the full version of this working product, we had detailed diagrams laid out under the flows in this diagram. The whole thing took up one wall. Once we were confident in the design concept, we broke it down into a more traditional, multi-page specification.

TAKE YOUR WORKFLOW TO THE NEXT LEVEL

183

The important thing to remember is that you don't limit yourself to using workflows or sitemaps. Go beyond the basic concepts that have been introduced to you in this chapter. If you really need something to test your skills, take the time to create a shoe lacing scheme. Good luck!

184

CHAPTER 10: SITEMAPS AND TASKFLOWS

Wireframes and Annotations Design and Governance: Before Visual Design Begins Wireframes and annotations are ways to identify the intended content and structure, as well as the functional behaviors of a web page or application view. Combined with sitemaps and workflows, these documents are also extremely useful for identifying prototypes and proof of concept scenarios. Wireframes are typically presented in grayscale, with no graphics or pre-made content; instead, they use placeholder content to highlight representative locations that can be used as a guide in visual layout. Russ Unger

What is a skeleton? Essentially a prototype of a low-fidelity website or application screen, the wireframe is used to identify elements to be displayed on the page or screen, such as navigation Content sections Image and/or media requirements Form elements Calls to Action (CTA)

Wireframe models are usually created in black and white or shades of gray, use placeholders for images, and don't go into details about fonts (although many use font size to convey copy type separations). They come in all shapes and sizes, from the most basic to the most advanced that almost mirror a full screen layout. Wireframes evolve; they are no longer simply provided to designers and developers as blueprints for their tasks. Wireframes are now used to represent a site or app to clients, designers, developers, and anyone else on the team who has a basic stake in it. They are often shown to clients to validate "design thinking" prior to the development and visual design phases. Often the people who create the skeletons work hand in hand with those who create the business requirements (in some cases the same people). It should also be noted that some of the best mockups and annotations are the result of direct interaction and collaboration between various business partners, from business analysts to programmers and other designers. Some companies are leaning towards using wireframes and annotations instead of Business Requirements Documents (BRDs). While the world is far from saying that BRDs are extinct, the beginnings of this change show how important it is to be very thorough and thoughtful when creating schematics and annotations. In many cases, users will be shown schemas to get feedback that can verify page elements or request modifications. skeletons that

186

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

placed in front of users usually have another name: prototypes. (For more on prototyping, see Chapter 12.) To help you determine the approach that best suits your needs, this chapter covers the basics of wireframe development and provides examples of designers working in the field. Like the rest of this book, these examples are just the beginning - don't be afraid to explore and innovate on your own.

What are annotations? Annotations are simply explanations and notes about an element or interaction in the wireframe. Usually contain information such as content identification or labeling Content sources Display rules Interaction rules Interaction destinations Processing rules Content/error messages

It is best to create annotations with a very direct, if not concise, tone and clear explanations. Leave nothing to chance in your entry; there is a very big difference between should and should. Wrong: "Triggering this call to action (CTA) should bring you to your home page." Good: "Running this call to action (CTA) will bring you to your home page." Okay, to be fair, the first example isn't exactly terrible, but the word should leave room for confusion for a developing developer who might not have the luxury of having their favorite UX designer ready to answer questions. Make sure your annotation style is concise and leaves no ambiguity to anyone who needs to read and trust your instructions.

WHAT ARE ANNOUNCEMENTS?

187

Who uses skeletons? With clear and concise annotations, mock-ups are great, but who is the real audience of these results? Unfortunately, there is no simple answer to this. From one project to another, your audience can range from one person to any combination of different groups. Table 11.1 shows the potential audience for your programs. TABLE 11.1

188

wired listeners

AUDIENCE

THE

Project management

Project managers can use wireframes as team discussion points to highlight strategy, technology needs, and a very high level of user experience.

Business analysts

Business analysts can use schemas to ensure that their requirements are met and confirm that they have not overlooked requirements that need to be included.

Visual designers

Visual designers can use wireframes as a template for their output. Wireframes give them a book of page elements and behaviors to consider.

content creators

Copywriters, content strategists, publishers, and other copywriters can use mockups to map the content matrix and identify content needs across the project.

Search Engine Optimization (SEO) specialists.

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

Developers

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

Quality assurance

The QA team can use mockups as the basis for their test scripts. Once the client approves the wireframes, the variance should be minimal, allowing the QA team to get to work faster.

users

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

clientele

Customers are increasingly involved in reviewing mockups to verify that business requirements, goals and objectives are met and to gain approval to move to the visual design phase.

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

Scaffolding To create a scaffold, you usually need a set of requirements. These can take the form of a formal business requirements document from a client, a creative outline or project summary, meeting notes, a well-formulated sitemap or task flow, or even napkin notes that provide guidance. Either way, you need to understand what you're trying to create for the user, what the connections are, and a general understanding of technology constraints and expectations. Note For more information on defining your business requirements, see Chapters 4 and 5. Tips for effective meeting notes can be found in the online bonus chapter "Meeting Quick Guide" at www.projectuxd.com.

Having compiled the necessary information, take the time to carefully read all the requirements, ask questions and consider the answers for clarity, you can start creating your schemes!

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

WHO USES WIREFRAME?

189

The mind tends to run towards the familiar, but the familiar may not always be the best solution to a problem. When you force yourself to look for more varied ideas, often by idea 4 or 5, you have come up with something new and interesting. I don't know why this is happening. It's just like that. Templates can help guide you through this process. In Adaptive Path, we use a template of six, which simply gives you space to make six small miniature sketches. The number of sketches is not really important. It's important to force yourself to go beyond the first obvious ideas. Six is the magic number (for me) because the six's template with six little squares encourages me to keep going until all the thumbnails are complete.

Figure 11.1 Six-part adaptive path template

These are solid words to follow, especially if you're just getting to know your job in the world of UX design. Over time, you will begin to identify the approach that works best for you, but there is no better advice than Leah. For more on his approach, see the full How to Be a UX Team of One online presentation at www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one. Don't be afraid to start with a pencil and paper, just remember to bring plenty of erasers. Mistakes are part of the process, and even after committing to a pencil sketch, expect to make adjustments as you get closer to digital.

190

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

Few professions work in the realm of iteration with as much frequency and consistency as UX designers. Very rarely, if ever, are design jobs accepted on the first try, and sometimes one can only hope to "get it wrong in the right direction." For this reason, start small: take a single page or a small section of a project, review it first with the in-house team, then with the client's team to make sure everything is on track. Keeping your designs aligned with how the client thinks about their business goals from the start saves a lot of rework in the future. The same approach can be applied to user testing projects: look for validation early!

Start simply: design a base model In this section, you'll see how to create a base model at a very basic level. You can often start with a simple sitemap and a few additional requirements, but with these you can create the structure of your site's home page. Remember the basic sitemap in Chapter 10, which showed you how to build a very simple website? Figure 11.2 shows the walkthrough: As you can see, one level of the navigation hierarchy is shown. It is very likely that any X.0 page identified is a parent or top-level page. You can use this as a starting point to define some of your business requirements and backbone. 1.0

1.0.1 Regulations

Home

Blog 2.0 – 2.x

3.0 O

4.0 Work

5.0 Contact

Figure 11.2 Sitemap for a basic site with blog functionality

START SIMPLY: DESIGN A BASIC FRAME

191

Getting Started It's common to create your own business requirements document, which can be a blessing or a curse. When you are a requirements writer, you basically only have yourself or your client with whom you can discuss the meaning of something vague or relatively undefined. It can often feel like you're making things up on the fly, but don't let that stop you. In many cases, wireframes will help you identify gaps in the information you are working with. This can ultimately help you come up with the best solution. Remember that user experience specialists are working to provide the best possible solution to users, and their early versions of each project will always be used to solicit feedback and influence the next iteration of the project. Your design doesn't have to be perfect, but you want to make sure it looks clean and professional, and in the worst case, will err in the right direction. The design requirements of this homepage are limited and very short. Fortunately, the site map shown in Figure 11.2 contains enough information to formulate navigation that can be used on the site: The home page (number 1.0) is the top level of navigation. Conditions

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

tact (5.0) i Blog (2.0–2.x), które są renderowane jako stos stron, dzięki czemu można mieć pewność, że będą wyglądać jak wiele stron dynamicznych i będą miały „poprzedni” i „następny” sposób nawigacji. Te główne elementy nawigacyjne dostarczają wielu informacji na początek, ale to nie wystarczy, aby skutecznie utworzyć stronę główną witryny. Aby pomóc w udzieleniu wskazówek, klient podał dodatkowe informacje: Firma jest butikową firmą zajmującą się projektowaniem UX, która zyskała rozgłos dzięki swoim blogom i różnorodności projektów, nad którymi pracowała. Ważne jest, aby odwiedzający witrynę mogli szybko dowiedzieć się, o czym jest firma/strona internetowa, dzięki ograniczonemu tekstowi i mocnym, sugestywnym obrazom, które działają w połączeniu z projektowaniem wrażeń użytkownika. Ważne jest również, aby nawigacja była przejrzysta (wolałbym nagłówek i stopkę wielokrotnego użytku, jeśli to możliwe) i

192

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

that the latest blog posts include a call to action so that visitors can quickly read a summary of our latest opinion on current issues in the world of user experience. If possible, it would be nice to be able to highlight recent work on the homepage, but this is secondary as most of our work is often in development or kept under the strictest secrecy.

Wireframes and Annotations There are several ways to interpret these requirements, and the first presentation of the wireframe to a customer might look very similar to Figure 11.3. ANNOTED ART MODEL Home Annotations 1

logo 2

Dom

Blog

Our job

the nas

Contact

1 Logo image. · The logo will function as a link to the homepage

site from anywhere on the site. 2 · Launch Navigation. It must contain a link to the website's home page

from anywhere on the site. 3 · Blog navigation. You must link to your Blog landing page from any

location within the site. 4 · Navigating our work. You must provide a link to our work homepage

from anywhere on the site. 5 · Navigation About us. Must contain a link to the About Us 6 7 homepage

7 8 9 10 11

welcome title goes here

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

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

Como on visto, vendré a un minimo, que no ejerce el castigo corporal de los jugadores como algunos de ellos. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolor magna aliquam erat volutpat.

I feel a lot of pain, consectetuer adipiscing 12

13 More > 17

Article #

sixteen

15 16 17 18 19

from anywhere on the site. · Navigation contact. · You need to connect to the contact page from anywhere on the site. · Hero image rotation. Images will rotate through multiple images that are aesthetically pleasing and true to the brand. · Welcome title. · Title of the website review text. · Welcome content. · Website content review. · · Title. · The title of a random example shown from a portfolio of works. · Image link. · A photo of a random example shown from a portfolio of works. You will need a link to see the details of a random example shown from the work portfolio. · · Summary. · A short text summary of a random example from your portfolio of work (maximum 1-2 lines of text recommended). · More links. · You need to connect to see the details of the random sample displayed from the wallet. · · Qualification. · Title of the latest live blog post. · Introductory content. · The first 200 characters of the most recent blog post. · More links. · You must connect to see the full blog post of the latest blog post. · Copyrighted content. · Copyright and current year with company name. · Terms · and · Terms and Conditions link. You must access the Terms and Conditions from anywhere on the Site. · Contact link. · You need to connect to the contact page from anywhere on the site.

8 · Welcome title. · Title of the website review text. 9 · Welcome content. · General website content. 10 · · Title · Title of a random example

which is displayed in the working folder. 11 · · Image link. random image

nt Blog title>

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

I'll let you know who we are.

15 16 17 18

Note 19

An exemplary portfolio of works was shown. You will need a link to see the details of a random example shown from the work portfolio. · · Summary. · A short text summary of a random example from your portfolio of work (maximum 1-2 lines of text recommended). · More links. · You need to connect to see the details of the random sample displayed from the wallet. · · Qualification. · Title of the latest live blog post. · Introductory content. · The first 200 characters of the most recent blog post. · More links. · You must connect to see the full blog post of the latest blog post. · Copyrighted content. · Copyright and current year with company name. · Terms · and · Terms and Conditions link. You must access the Terms and Conditions from anywhere on the Site. · Contact link. · You need to connect to the contact page from anywhere on the site.

Figure 11.3 Wireframes with uploaded annotations for home page layout

START SIMPLY: DESIGN A BASIC FRAME

193

The annotated wireframe details each element on the page, as well as expected CTAs and action results (such as loading a specific page). This particular example works very well due to the limited number of elements and limited details required.

Figure 11.4 Layout of the active home page of www.userglue.com

As shown in Figure 11.4, the current version of this home page differs only slightly from the original skeleton in Figure 11.3. As timeline and content, for example, became issues, the Portfolio Examples section was removed. Also note the difference in navigation and CTA naming conventions: the wireframe served as a guide, not the last word. Your end result will also often contain various minor changes and updates compared to your schematic content.

194

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

Exercise: design a homepage wireframe You've seen the example, now it's time to dive in and create your own wireframe. Your task is to redesign the homepage of Global Cruises, a fictional international cruise line. Global Cruises wants its homepage to be a more effective sales tool and a source of information for returning guests, who are often people who have booked a cruise and want to know more about other opportunities and perks. , travel conditions updates . , etc. In this exercise, you will use the requirements below to wireframe an annotated home page in a document or in a separate document (your choice). Nothing more.

Requirements The main absolute requirement is that the global header and footer (Figure 11.5) remain the same, absolutely unchanged. GLOBAL HEADLINE Logo Destinations

Logo of the current Travel experience campaign

plan a trip

To look for

Before the trip

world cruises

club VIP

sale

my global cruises

welcome back,NO?) | XX days to next sailing -Manage booking | BookTravel plugins| Online payments

Figure 11.5 Global Header and Footer of Existing Global Flights

ACTIVITY: DESIGN A HOMEPAGE LAYOUT

195

In the footer it should be Subscribe to emails from Global Cruises About Global Cruises | Contact us | FAQ | Travel agency search engine | Site map | Legal information | Price conditions | Privacy Policy Copyright Notice Additionally, site must be able to display multiple promotions Capable of displaying headlines/messages Customer Service Call CTA for Travel Agent Search CTA for Popular Travel Routes

"Worth having" is: The ability to view the latest, most popular and/or best-selling itineraries The ability to view the geographic location of the itinerary and waypoints The ability to view the itinerary (MY TRIP/IES) after logging in see up-sell items such as extra stops ( for example if you are going

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

Global Cruises And now the work begins. Start drawing the wireframe and don't forget the appropriate annotations! Once you've completed your outline, check out the next page for examples of other top professionals who received the same set of requirements.

196

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

Results: Designing the homepage skeleton Will Evans, user experience architect at Semantic Foundry (www.semanticfoundry.com), was kind enough to create the skeletons based on the requirements of the Global Cruise exercise. Compare your own work with their projects in Figures 11.6 and 11.7 to see how their approach compares to yours. Below is an explanation of how he put together the wireframe and annotations. Travel alerts 990 pixels wide

FIND A CRUISE

LOGO

5.0

4.0

3.0

2.0

1.0

Price

New routes

annotated notes

Popular routes

11 1

Destinations

| travel experience

plan a trip

Before the trip

Club VIP Global Cruise

Welcome back to iMMŔLog out

6.0

7.0

8.0

sale

see itinerary | my world

15 days until next cruise -

9,0 13

1.0

Travel alerts: link via 0.2.0.0

2.0

Links to Brand/Logo Home

3.0

Search with predictive suggestion of a defined user scenario 3.X

4.0

6.0

Combined New Trip Plans drop-down menu - shows an itinerary linked to Section 4.x Popular Trip Plans - Drop-down lists the 5 most popular travel plans Destination Link - Jumps to Section X.0

7.0

Travel Experiences link: goes to section X.0

8.0

Plan your trip Link: takes you to section X.0

9.0

Before you travel Link: takes you to section X.0

Global Cruises VIP Club Link: Links to section X.0 Link to special offers: Links to section X.0

My Global

5.0

Media/Flash/Hedonic image

sixteen

Hero Shot Title 17 Global Headlines | Create your own star

Need help planning a cruise

Header Consectetut Adipisicing Transparency is the very rope of home or pain of rebuke in pleasure wants to be a hair in pain EU

HEDONIC PICTURE

Konsekwentna Adipisicing Head

Do not be angry at pain in reproach to pleasure, which wants to be a hair's breadth away from pain in the hope that there will be no education.

Idea number 1 headline

Idea headline number 3

Idea header number 2

Idea header number 4

Brightness is the reins of the Lord himself, that is, the wrath of pain in rebuke, in pleasure he wants to be a feather of pain

Idea headline number 3

October 8, 2008 6:46 pm

brand promotion

But that you may see where all this error, born of those who blame pleasure and praise pain, I will open the whole matter and the same things that by this inventor

post yours

I am very sorry for the loss of the consecrated nonumma lorenzino. Sometimes the common man sees that he is making a mistake.

25 Sign up for global emails.

Do not give ? click here

My Global Cruises Link - Goes to section X.0 Logout Link - Logs out the user

sixteen

View Itinerary Link - Takes you to my global page/View My Itineraries. My global link: Takes you to a custom page Carousel image for special offers/bundles

The moment you perform Crowdsource link

Link to special offers of books combined with an image in a large shot of the hero.

Need help planning a cruise

20/21

CT promotions as / affiliate promotions

Share your moments Call me, member profile Post your own "Win your moments starring" link on the croudsourcing site.

But in order that you may see where all this error of those who deny pleasure and praise pain comes from, I will open the whole matter and explain the same thing that this discoverer of truth and, as it were, an architect said. happy life.

Promotional/News

HEDONIC PICTURE

IMG

Promotional/News

Moments with you in the lead role

Book this special package

Your moment now! To go

link to change country

Global footer links

Page 2

Figure 11.6 Wireframe of the Global Cruises homepage by Will Evans

ACTIVITY: DESIGN A HOMEPAGE LAYOUT

197

Travel alerts 990 pixels wide

FIND A CRUISE

LOGO

Destinations

5.0

4.0

3.0

2.0

1.0

Price

New routes

OK, Will "Bahamas" | Travel experience | plan your trip about us| found before the trip

18|

annotated notes

Popular Routes 1

Club VIP Global Cruise 6.0

sale

special cruises

Welcome back to iMMŔLog out

7.0

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

detached charleston harbour

15 days until next cruise -

7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Nassau

Great Stirrup Cay (our private island) Port Canaveral Charleston

Nassau

Media/Flash/Hedonic image

Filter headlines from around the world | Create Your Own Protagonist Need help planning a cruise

detached charleston harbour

Great Stirrup Cay (our private island) Port Canaveral Charleston

IMG

6.0

Quick Tip: The cached results return a matching string

7.0

Cruise ticket with the following metadata: 1. Price 2. Average rating 3. Title: Cruise title 4. Duration 5. Ports of call 6. Details link 7. Link to book this cruise 8. Save/mark this cruise as favorite

8.0

Faceted navigation allows the user to dynamically change the port, travel month, ship or price range and dynamically sorts/filters the matching result set. Each of them can be reversed when the user sees the full results on the search results screen

9.0

Once the user has customized the filters for predictive search, they can click to see all the search results, which will use Ajax technology to load the entire result set into a javascript array for quick sorting.

Share your moments Call me, member profile Post your own "Win your moments starring" link on the croudsourcing site.

Details

Title for Shot FridayHero Saturday

Book this special package

-Any ship related promotions/news

$190 to $1,650

Adipisitic Duis header will be followed or pain will be rebuked in pleasure, it wants to be an inch away from pain and there will be no birth.

Brightness is the reins of the Lord himself, that is, the wrath of pain in rebuke, in pleasure he wants to be a feather of pain

Moments with you in the lead role

Details

Price: HEDONIC PICTURE

Brightness is the reins of the Lord himself, that is, the wrath of pain in rebuke, in pleasure he wants to be a feather of pain

Dropdown list of connected new itineraries - shows the itinerary linked to section 4.x Popular itineraries - the dropdown lists the 5 most popular itineraries

5.0

Nassau

Barco:

-Every month-

HEDONIC PICTURE

Konsekwentna Adipisicing Head

Search with predictive suggestion of a defined user scenario 3.X

4.0

Details

Your results, yours and now! To go

Mes:

Links to Brand/Logo Home

3.0

Friday Saturday 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Homeport/Town: Promotion/News Washington, D.C. 8.0

Nassau

see itinerary | my world

Friday Saturday 7 nights

Travel alerts: link via 0.2.0.0

2.0

Details

Friday Saturday 7 nights

1.0

my world

HEDONIC IMAGE 9.0 View all search results

Adipisitic Duis header will be followed or pain will be rebuked in pleasure, it wants to be an inch away from pain and there will be no birth.

Idea number 1 headline

Idea headline number 3

Idea header number 2

Idea header number 4

Idea headline number 3

October 8, 2008 6:46 pm

brand promotion

But that you may see where all this natural error of those who accuse pleasure and praise pain comes from, I will open the whole matter and explain exactly what this discoverer of truth and, as it were, the architect of the happy life, said. But that you may see where all this error, born of those who blame pleasure and praise pain, I will open the whole matter and the same things that by this inventor

post yours

11 1 12

link to change country

Global footer links

I am very sorry for the loss of the consecrated nonumma lorenzino. Sometimes the common man sees that he is making a mistake.

13 12

Do not give ? click here

Page 3

Figure 11.7 Will Evans Global Cruises home page skeleton with search enabled

Skeletal modeling in Will's words For me, skeletal modeling works as a form of "thinking device" to shape and explore a given problem space; in this example, it is the home page of the cruise line operator. Designing with mock-ups is a search for alternatives in a problematic space; it's both a problem-finding and problem-solving process, which means I always start with context. In this case, the main audience wants to easily find the best cruise at the right time and at the right price. To keep things simple, I choose my primary audience and the only action that allows them to quickly, effortlessly, and elegantly solve the goal. By sketching a series of mock-ups, I am able to explore alternatives, and both impossible and possible ideas are presented, tested, and in many cases rejected. I already knew I wanted to design the best cruise line search interface possible, and I wanted this activity to be the center of the design. This is where I outlined the concept of offering suggested cruises instantly, even before the user commits to viewing.

198

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

full screen search results. I wanted the user to participate in the conversation and engage in the process of finding a great cruise. FIND A CRUISE

Price

OK, we found the Will for "Bahamas".

18 special cruises

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

detached charleston harbour

7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Nassau

7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Nassau

Details

Friday Saturday 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Details

Friday Saturday 7 nights

Great Stirrup Cay (our private island) Port Canaveral Charleston

Details

Friday Saturday

Details

Friday Saturday

Filter Results AND Port of Origin/City: Month:

Washington.

Barco:

-Every month-

Cena:

-Any ship

$190 to $1,650

View all search results

Figure 11.8 Cruise Search Results Function on the Will Evans Home Page

For a cruise line operator, I outlined the header, footer, static content, and the need to block areas in the design for content modules like calls to action and promotions. I share the results of this step with key stakeholders, but I also engage the visual designer and development leader as well as QA so they can contribute to the process, provide more ideas, and start documenting difficulties and constraints. Ultimately, as a designer, I had to make the decision to implement the design in the specification. I created two or three candidates for final consideration and, using annotations, enabled the wireframe to make arguments to specific stakeholders and reviewers. The wireframe you see in Figures 11.6 and 11.7 is currently at a stage where design changes are minor and details are being worked out.

ACTIVITY: DESIGN A HOMEPAGE LAYOUT

199

Compare and Compare Note that the example in Figure 11-3 and Will Evans's work are quite similar, though different, styles of wireframes. Now it's easy to look at both and proudly announce, "These are the schematics!" Both have elements of their own style and approach, but the core is very similar. The examples in this chapter are a good starting point for finding the wireframe style that works best for you.

Photos cortesía de Maciej Piwowarczyk

Visual Design: When wireframes grow and find their own way in the world

Figure 11.9 Global Cruises homepage visual design by Mark Brooks

200

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

Using the requirements and wireframe of Will Evans, Mark Brooks (www.markpbrooks.com) created a homepage design for the fictitious company Global Cruise Lines. As you review the visual design in Figure 11.9, notice how he thought about the layout and content of the page. As the project goes through process and development, the interaction models will come to life.

Continuing the design exercise: which design is the right one? There is no good or bad design as long as the requirements are met. Sometimes you may feel compelled to create multiple mockups for a single page to explore different approaches, work out the details, and present them to potential users, teammates, and perhaps your clients. This is perfectly acceptable. Remember that this is an iterative exercise. The work you hand over to a client is almost always guaranteed not to be "correct" or "final" on the first try. Most of the time you will be working on at least one round of iterations and updates. Unfortunately, this can sometimes stretch over multiple rounds, but that's the nature of projects and should ultimately lead to fewer searches for more working partners. By comparing the wireframe and annotations with the two provided examples, explore the difference in approach and presentation style. Compare it to the example on the home page earlier in this chapter and the work you've done. Find the similarities and differences and work out the approach that works best for you, unless there is already a set of templates for you. In many cases, the hardest part of creating a wireframe is the first touch of the paper. Take Leah Buley's advice and start sketching lots of ideas: scribble and draw, explore different approaches, and test your designs with co-workers, colleagues, and family members until you're confident you can justify your design (without compromising there). defensive) and it will. you will find that you are heading in the right direction.

ACTIVITY: DESIGN A HOMEPAGE LAYOUT

201

A final note on presenting mockups Once you start creating mockups and become more comfortable with the work product and understand how valuable they are to your workflow, it's easy to forget that not everyone understands the amount of thought and time it takes to create them. Often, clients and collaborators were faced with mock-ups of a completely different level of quality and complexity, or with a different style of annotation. In fact, many of your colleagues and clients may have never seen a wireframe before (even if they claim to have seen it). It's also not uncommon for clients and colleagues to be confused about the differences between sitemaps and wireframes and the purpose of each. In other words, your first wireframe can also be your client's first wireframe! This makes it extremely important to accurately stage the scene for what you intend to present. Before presenting the mockups, make it clear what they are, how they will look compared to the final visual design, and what their purpose is. Here are some additional tips for presenting mock-ups: if possible, involve the client's team in the discovery process; try to get them

engaged in active drawing on the board. Explain that they are involved in the structuring process and that the end result will be similar but will be produced electronically. It's very important to make clear that this is an activity that will lead to wireframes that may look very different as you explore design options. Find strong metaphors to convey the differences between your connection

framework and final project design. A popular metaphor is: "Layouts are to apps/websites what blueprints/plans are to a home." Wireframes make it easier and more efficient to implement changes at a stage where changes are generally less expensive (before construction crews are involved and foundations are poured). Tell the meeting participants that the diagrams are not the final representation

website graphic design. Wireframes are presented to include content, overall design, and interactions

202

CHAPTER 11: FRAMES AND ANNOUNCEMENTS

page elements. Once the skeletons are approved, construction can begin. (Oh, subtle changes can still happen!) Involve your visual designers if you have the time and budget for it

Design mock-ups to show the differences between your schematics and the final design. If possible, show the client examples from other projects that show how the wireframes and final designs are both similar and different at the same time. Explain how other members of the design team will use the cable.

Frames – It never hurts the client to understand the importance of reviewing and approving this milestone, and how wireframes inform the rest of the project. As your clients and colleagues begin to understand and appreciate the value of wireframes and where they live in the design process, it will be easier to move projects forward. Because? Because wireframes help create visual clarity and direction for the rest of the design. In many cases, business partners and customers can even proclaim the usefulness of mock-ups on your behalf. Thanks to this, you can spend more time designing the UX and less time selling it!

FINAL TIP FOR THE PRESENTATION OF STRUCTURAL MOCK-COUNTS

203

Prototyping brings designs to life (sort of) Prototyping is an effective way to test and validate proposed designs and features before investing in development. You can use many tools and approaches to prototyping, from quick and dirty (but we prefer quick and clean) to interactive and robust. The method you use will be largely determined by two factors: the time and materials you can devote to prototyping. Russ Unger and Jono Kane

What is prototyping? In the context of user experience design, prototyping is the act (and in many cases, the art) of creating and testing all or part of the functionality of an application or website with users. Prototyping can be done using analog tools (such as whiteboards or pencil and paper) or digitally using PowerPoint, Acrobat, Visio, OmniGraffle, HTML, or other technology-based tools. Prototyping can be an iterative process as prototypes are usually built to identify problems or test user experience. After gathering feedback, you can make modifications to the prototype for further testing. In other cases, a successful (sufficient) prototype can move the project to other phases of the development cycle. Remember that prototyping is a process, not an artifact. You may end up creating screens and (sometimes simulating) features that you call prototypes, but they are part of the prototyping, not the final product. The result of the prototyping process is actionable feedback on concepts that can be used to improve and refine the design. However, this chapter only focuses on prototyping, leaving the details of testing in chapter 13.

How much prototype do I need? Any user experience design process must involve some degree of prototyping, formal or informal, interactive or static. Prototyping doesn't have to be for your entire site or app. In fact, prototyping can be very effective when only a representative sample of the system is used; in other words, you don't need to simulate the entire system, just key parts of it. In most cases, you'll want to test a few concepts, and your prototype should contain those concepts and little else. You can create prototypes using any number of available methods: whiteboard, pencil and paper sketches, storyboards, cardboard cutouts, etc. In addition, several digital tools are available to create interactive prototypes and engage test users in a more realistic environment.

HOW MANY PROTOTYPE DO I NEED?

205

The prototyping method you choose will largely depend on the time and available materials. Here are some of the more popular methods that meet many prototyping needs.

Paper Prototyping Few activities can take you back to your early days quite like a hands-on, artisanal approach to paper prototyping. The only tools needed are pencils and pens, paper, scissors, and anything else you can steal from the art department or buy at your local office supply store. Paper prototypes are flexible. As long as you have a draft or more materials, you can create as many scenarios as you need. You can also quickly browse from one test to another, which means that if a potential user points out an obvious bug in something you've created, updating the design before showing it to the next potential user is not a complicated process. It's also cheap. No matter how much time you spend prototyping on paper, you can usually create any scenario for much less than the cost of a few luxury lattes. Paper, sticky notes, index cards, pencils, and the like should be available by now, and if they aren't, you won't break the bank by stocking up. The process is simple: draw the part of the functionality you want to test. Present functionality to users. Document feedback (it's paper, so turn your prototype over and start writing). Then move on to the next user or upgrade and start over. Simple. Game. Effective. Applied early in the process, prototyping on paper can help you spot design issues before you invest heavily. Changes at this stage can be implemented quickly and efficiently, reducing risk. This allows for effective changes before you spend too much on the project. Using three sheets of paper in different colors, each tab in Figure 12.1 was drawn as it would look on a web page and stacked on top of each other. The Global Now tab is placed at the top to display its contents as if the user had just visited the home page for the first time. Each tab displays the navigation available to users and allows them to select a different browsing option.

206

CHAPTER 12: PROTOTYPES

Figure 12.1 Paper prototype of tabbed vertical navigation

Figure 12.2 Paper prototype of a tabbed vertical navigation with the My Itinerary tab enabled

When the user selects another card, that particular card is moved to the top of the stack to display a view of the content area of the newly active card, such as the My Itinerary tab shown in Figure 12.2. Prototyping on paper is as cheap as possible and can be as simple as the previous exercise. Once you start exploring complete systems, the hours you spend can become substantial (although material costs will increase only slightly). If you have to change the main navigation on a hundred pages of paper prototypes, this method becomes expensive. While prototyping on paper is generally cheap, it is not reusable when parts need to be updated. At this point, you should consider whether switching to digital tools would not be more beneficial.

Digital Prototyping If your prototyping needs exceed paper, a technology-based solution may be better for you and your audience. With these tools, you can show exactly how the interactive parts of your website or app will be displayed to users. Digital Prototyping relies on many other aspects of the design process. You'll be able to reference your characters when uploading or testing your digital prototype, prototype visual machining and locking schemes, and visual design resources (if available at this stage of the process) for a realistic look. match and finish to your prototype.

Wireframe vs. wireframe Realistic Prototyping As with paper-based prototyping methods, the process can be different with digital prototyping. Depending on the tools, resources and skills you have

DIGITAL PROTOTYPES

207

layout as well as the requirements you are dealing with, you may find that giving your prototype a wireframe look is good enough for your project. In fact, it may be better. Wireframes can show viewers that a project is still a work in progress, not a final production-ready site. On the other hand, sometimes when testing a design with users, you'll discover that the most important aspect of a prototype is how realistic it represents the final system. The result of your digital prototype is based on three factors: What is your timeline?

Do you have time to get your team together and build an amazing near-production-ready prototype that shows the users sitting in front of it a crystal-clear view of the production-ready site? Do you have a few hours to export your mockups to HTML or create a very simple Flash project to show only the page flow and basic interactive elements in the project? Both types of digital prototypes can be very useful. However, as with any real project nearing its deadline, it's important to set expectations based on the time and materials available. Who are you building this prototype for and why?

Crucial to the success of your prototype is knowing what you're doing with it before you dive into the design. Are you building a prototype to test the design with users? If so, what should you focus on during the test? Does it matter if the prototype is a black and white wireframe or should it look like a working website? Are you testing the visibility of buttons and links? Are you prototyping a business presentation that requires buy-in from your executive team, managers, investors, or others to sign your check at the end of the day? If so, what are you trying to tell them? What is supposed to be functional and what is only functional? These questions can help you determine your digital prototype requirements.

208

CHAPTER 12: PROTOTYPES

What types of resources, tools and skills are available to you?

If you're not an HTML or Flash expert and don't have the budget to hire someone who is an expert, you can still create a highly functional prototype with a simple presentation tool like PowerPoint or Keynote, or a diagramming tool like Visio. or OmniGraffle. Even a simple PDF can work.

HTML editors vs. WYSIWYG HTML is the digital equivalent of a paper prototype. It's (sometimes) free and (somewhat) easy. If you are not an HTML creator or a front-end code expert, you can still be an HTML prototype creator with only a basic knowledge of HTML. Basically, there are two ways to create an HTML prototype: hand-coding the HTML code, or using a WYSIWYG editor such as Adobe Dreamweaver, Realmac RapidWeaver, or Microsoft Visual Studio. These tools have a code view as well as a design view that allows you to visualize your coding efforts without opening a browser. Prototyping with the WYSIWYG Editor The best thing about using the Design View in the WYSIWYG HTML editor is that you can create a page layout with about the same effort as you would design a page in Microsoft PowerPoint, Apple Keynote. , or any other simple graphic design application (more on that later). It's just as easy to add interactivity such as links, mouse events, and so on. One of the most impressive aspects of Dreamweaver CS4 (Figure 12.3) is that it offers what Adobe calls Live View, which is based on the open source WebKit rendering engine. What does it mean? Simply put, this means that what you see in the live preview is exactly what you'll get in Apple Safari and Google Chrome, assuming you've meticulously fine-tuned the details of your prototype. Dreamweaver CS4 is a very powerful prototyping tool, especially when combined with Adobe Fireworks CS4.

DIGITAL PROTOTYPES

209

Figure 12.3 A simple sample prototype created in Dreamweaver CS4

Creating a Basic HTML Prototype Probably the cheapest way to create a simple, quick and dirty HTML prototype is to do it "by hand", which is to write the code by hand in a text editing tool. One of the most common reasons to go from wireframe to prototype is the requirement to show or test your proposed site flow and navigation. By taking blocks of elements or even entire pages of your wireframe (or layout mockups) and setting them as clickable images in your HTML prototype, you can build a working prototype very quickly and easily. A very simple prototype that allows you to click on full page images in a browser and then load different pages is pretty straightforward. In the following exercise, you should be able to access the search results homepage and schema, or you can download sample images from www.projectuxd.com. Note Typos are the most common errors made in HTML coding, so pay special attention to the accuracy of your text.

210

CHAPTER 12: PROTOTYPES

1. Export a homepage wireframe from your preferred tool (such as Visio or OmniGraffle) or a layout theme from a visual design tool. You need to save the entire page as a GIF image named homepage.gif; create a new folder called Prototype and store homepage.gif there. Note The JPEG format works very well for raster and photographic images; GIF works best for wireframes and line drawings.

2. In a WYSIWYG HTML editor or a simple text editor such as Notepad (Windows) or TextEdit (Mac), create a new document and save it as homepage.html in the same Prototype folder. If you are using TextEdit, remember to select HTML as the file format. 3. In the new document, insert the following HTML code: 1]iba3 1]ZVY3

1i^iaZ3=dbZeV\Z1$i^iaZ3

1$]ZVY3 1WdYn3 1$WdYn3 1$]iba3

4. Save the document, then open the file in a web browser. You should see a blank page, but watch the title bar in your browser. It should say "Home". 5. Edit the homepage.html code in a text editor. Between the y tags, enter the following HTML code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

This code will convert the entire homepage.gif image into a clickable button that will load the searchresults.html page (which you'll need to create to verify that the feature is working properly). 6. Save the document and reload the page in the browser. You should see the new homepage you just created in your browser in all its glory (Figure 12.4). When you click on an image in the browser, the browser will try to load the searchresults.html page (which doesn't exist yet).

DIGITAL PROTOTYPES

211

7. Repeat step 1 for the content of the search skeleton. Save this page as a GIF image, name it searchresults.gif and save it in the Prototype folder. Save a new copy of the current homepage.html document as searchresults.html. Select "Save As" for the current page "homepage.html" and save it as "searchresults.html". Then update your HTML to display it and link back to your homepage (homepage.html). You will need to replace this line of code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

Con esto: 1V]gZ[2]dbZeV\Z#]iba31^b\hgX2hZVgX]gZhjaih#\^[WdgYZg2%31$V3

8. After creating this page, you will have a very simple HTML prototype that shows how two pages can be linked together.

Figure 12.4 Mockup of the HTML homepage as seen in a web browser

212

CHAPTER 12: PROTOTYPES

Code Breakdown Now that you've created a basic prototype using a very limited amount of HTML, let's briefly review the code or HTML markup used so you can better understand what you just did. The HTML tags head and title 1]iba3 1]ZVY3

1i^iaZ36Wdji1$i^iaZ3

1$]ZVY3

are the basic tags required in every HTML document. An important element to pay attention to is the title tag, which allows you to specify the name of the page. Image Tag 1^b\hgX2]dbZeV\Z#\^[3

it is also a simple tag; that's all you need to view the image in the browser. Anchor tags like this one, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

they are used to set up links in an HTML document. For simplicity, the example anchor tag uses a relative path: "relative" because the tutorial project is in the same folder. The absolute path is: 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

While this HTML code isn't styled or standards-compliant (don't show it to a programmer, they might be asked for a hard lesson in coding practice!), it's more than enough to get your prototype moving. works in the browser. Keep in mind that this prototype doesn't have to be perfect: the goal is simply to get your ideas across to the audience. This simple markup example created linked HTML files that are clickable from page to page, but what if you want to get more granular with the clickable areas in the layout? Answer: image maps. With image maps, you can designate areas of an image to be linked to and display different pages when clicked. The easiest way to create image maps is to use a WYSIWYG tool like Dreamweaver to map parts of an image that can be connected without any real knowledge of how to create HTML. For more information on creating image maps, see "How to create an image map for

DIGITAL PROTOTYPES

213

My Website” by Dave Taylor at: www.askdavetaylor.com/how_do_i_create_an_image_map_for_my_web_page.html. HTML prototyping is just one approach to digital prototyping. Many different frameworks and dynamic coding languages can be used to create very robust prototypes that will satisfy almost any need. If HTML prototyping is an area you want to explore and expand on, you can look at tutorials and other resources to dive deeper into this area. To get started, you might want to learn JavaScript, PHP (or other dynamic coding languages), jQuery (http://jquery.com), or Yahoo! Interface Library (http://developer.yahoo.com/yu). Note For more detailed information on HTML, see HTML Dog: The Best-Practice Guide to XHTML and CSS by Patrick Griffiths (New Riders, 2006).

Additional Prototyping Tools You've now learned about the practical options that can help you prototype in both the analog and digital space. In addition to these methods, there are many other software tools that can be used for prototyping, ranging from basic "get the job done" to more robust and full of interaction and intelligence. The following list is not exhaustive, but will give you plenty of options for creating the right prototype for your situation. PowerPoint and Keynote A PowerPoint or Keynote mockup falls into the quick and dirty category, and sometimes that's all you need. You can create your PowerPoint or Keynote prototype as if you were creating a basic slideshow, with simple interactions. Both tools allow you to create interactions to simulate the flow clicks you want to validate with your users. If you're a "PowerPoint or Keynote power user", you can enable animations and other elements to make your prototype a bit more interactive. Adobe Acrobat PDF Exporting wireframes or visual design artwork as a multi-page PDF may be all you need to show what your product will look like and how it can navigate in a linear format from page to page. Note that many 214

CHAPTER 12: PROTOTYPES

export to PDF, and if you're using a Mac, you can select Print to PDF for almost any document or file in any application that supports printing. Many applications, including Visio and OmniGraffle, allow you to specify hotspots and actions, such as placing links, for interactivity. Visio and OmniGraffle Both Microsoft Visio and OmniGraffle by The Omni Group are well-known wireframe tools. Both allow you to prototype clicks with the ability to export to HTML and PDF formats. In OmniGraffle, you can easily assign actions and specify an access point in a PDF or URL if you export as HTML. Visio offers downloadable prototyping kits on the web that allow easy export to HTML or PDF with clickable areas for easy page navigation. Visio and OmniGraffle can also export popular vector and raster formats such as EPS, GIF, and JPEG, which allows you to easily import images into Flash, use them as images in HTML prototypes, and more. Axure RP The "RP" in Axure RP stands for Rapid Prototyping, which makes the tool popular with many UX designers. The tool offers similar drawing capabilities to Visio and OmniGraffle, but adds a relatively easy-to-learn set of tools that allow you to create various navigation styles, forms, pop-ups, and other common page-based interactions. . In addition, the flexible integration of specifications, comments, assignments, and progress markers allows you to create document-based specifications directly from the prototype. However, Axure is a Windows-only tool, which can be tricky if you're working with a Mac and aren't using any apps that let you run Windows. Fireworks CS4 Adobe's Fireworks CS4 has recently become more popular as a tool for creating a variety of design components, from wireframes to visual designs. It has a standard set of Windows and Mac form elements and controls that allow you to easily define interactions that can emphasize functionality without the need for an external developer. A shared library stores items that can be added and shared across multiple documents so they can be reused

DIGITAL PROTOTYPES

215

Fireworks Components also has a Pages feature that allows you to create sets of elements that are common to all pages in a particular document, similar to how programmers use the word "contains" or how some documentation systems allow you to create backgrounds. document page. This feature is useful for identifying repetitive content areas at the page level, such as header, footer, and navigation, while maintaining unique content areas on each page. Balsamiq Mockups Balsamiq Studios' Mockups is a schematic and prototyping tool that gives you the experience of drawing schematics with pencil and paper, only you use a computer. There are plenty of pre-built common UI controls (over 60 at the time of writing) that you can drag and drop onto your screen and customize to your design. Their mock-ups are styled as if drawn by hand, giving a slightly more organic feel to the digitally created displays, however the digital platform allows the designs to be quickly adapted for quick iterations. Flash and Flash Catalyst Prototyping with Adobe Flash is a great way to convey interactive concepts that go beyond a simple clickable prototype. Flash allows you to easily prototype clicks, but also allows you to add other elements of interactivity, including hover or hover events, click events, video, and animation. If you have the ability to explore Flash in more detail, you also have a basic set of UI components that can be programmed to respond to user interaction and display the desired result. For an introduction to Flash prototyping, look for Alexa Andrzejeski's article "Flash Quick and Easy Prototyping" on Boxes and Arrows: www.boxesandarrows.com/view/quick-and-easy-flash. At the time this book went to press, Adobe announced a new prototyping tool called Flash Catalyst. Flash Catalyst is a development environment that works with other Adobe CS4 applications, acting as a link between the design and development process. This allows you to export your designs to a viewable format with little effort. For more information, please visit www. adobe.pl.

216

CHAPTER 12: PROTOTYPES

Working with a programmer If you have the resources available, you can hire a programmer to create a prototype based on your schematics or designs. Keep in mind that the programmer will need to understand exactly what he wants to achieve, so this approach may also require him to create programming specifications and requirements to make the process efficient and effective. If your prototype is used for iterative testing, be sure to let them know which parts of the prototype you are focusing on during testing, and thus will require changes to be implemented quickly. It's prudent to spend time with the developer during the development process and identify key areas of code that need to be marked (with code comments) as subject to change. Be sure to stay in touch with your developer throughout the development of the prototype to keep lines of communication open and ensure the accuracy of the results. Note For more information on the different approaches to prototyping, see the forthcoming book A Practitioner's Guide to Prototyping by Todd Zaki Warfel (Rosenfeld Media, coming in 2009: www.rosenfeldmedia.com/books/prototyping).

Prototyping Examples The simple, easy-to-follow prototyping examples in this chapter are far from a complete set of approaches that should be used in every situation. To highlight some of the real-world applications of prototyping, Keith Tatum and Jon Hadden generously shared their experiences. Keith Tatum, Senior User Experience Strategist at Slingthought (www.slingthought.com), created the paper prototype shown in Figure 12.5 to explain the navigation links on the left and identify navigation hierarchies and categorizations for his collaboration partners. .com). In addition, the paper-based prototyping process allowed him to bypass the wireframe phase and move on to design and visual design (Figure 12.6).

EXAMPLES OF PROTOTYPES

217

Figure 12.5 Paper mockup used to explain navigation concepts to the development team

Figure 12.6 Design of a working website based on a paper prototype

Keith used his team's collective knowledge of design and development tasks to quickly create a project within two working days. This allowed the team to move forward quickly once the visual design concept had been approved.

Figure 12.7 Functional prototype of the calendar tool, simulated using high-quality XHTML, CSS, and JavaScript; courtesy of Jon Hadden

218

CHAPTER 12: PROTOTYPES

Jon Hadden (www.jonhadden.com), a senior visual designer at Yahoo, has prototyped a calendar feature for a tool he is developing called Project Manager. Project Manager is a collaborative project management web application. It started with OmniGraffle wireframes and was then built as a high-fidelity XHTML prototype to help determine if functionality was usable and affordable. Affordability is an important point: in some cases, parts of an application or project can be prototyped to see if functionality is viable. If the cost of creating functionality becomes an issue and prototyping exceeds time and material expectations, you may need to evaluate the feasibility of the design.

What happens after prototyping? Once the prototyping process is complete, you will need to synthesize your results and turn them into something applicable. If you've been prototyping on paper, you may need to start creating digital mockups based on the feedback you receive. If you are already in digital wireframe mode, you may need to update the wireframes and continue the design process. I may have to take your feedback and update your prototype for the next round of revisions. Todd Zaki Warfel, president of Messagefirst (www.messagefirst.com), said: Prototyping is a way to achieve one or more of the following goals: Work on a design Create a common communication platform Sell your design ideas internally (e.g. to your boss, other designers, etc.) ) Test technical feasibility Test design concepts with end users/customers Prototyping serves as a feedback mechanism. With prototyping, you can decide whether to pursue a particular design direction or explore another before moving on to the next phases of the design.

Remember: no matter where you are in the process, prototyping is only one part of the process, and as with any other part, you need to know when you've reached peak performance and are ready to move on to the next step. the next stage of the user experience process. WHAT HAPPENS AFTER THE PROTOTYPE?

219

Design testing with users Break down what you think you know and find out how they think In Chapter 6, we discussed some UX design techniques that can help you understand user groups: their needs, attitudes, and preferences in relation to the overall environment. . theme represented by your site. This chapter discusses techniques to help you collect user information for individual layouts or layout elements. We will focus on exploration techniques that are often used in the early design stage and usability testing that can be used throughout many stages of a project. First, let's talk about exploring design concepts with users. Carolina Chandler

Concept Exploration A concept is generally a word used to describe an abstract idea such as happiness, collaboration, or efficiency. In the field of UX design, the term is also used to refer to design elements intended to present one or more abstract ideas to a design team or potential user. In this sense, a conceptual design element can be visual (for example, an image of a machine representing the concept of efficiency) or textual (for example, a short set of written sentences expressing the company's focus on efficiency, using words such as timeliness and responsiveness). Concept can also mean exploring mockups, visual design mockups, or initial prototypes to convey the overall message of the site (see Chapter 12 for more on prototyping). Concept exploration often takes place early in the design process, after user groups have been defined but before going into the details of each page or screen. Research can inspire designers and reduce the risk of launching a new product because you'll be able to listen to (and then plan for) the kinds of responses you can get from potential users.

The main goal of concept mining is to understand the types of responses and ideas that are gleaned from user groups when confronted with a set of design elements.

Concept exploration can be individual discussions or it can take place in a group, but also includes individual activities to gather and discuss different points of view. The latter can be organized as a focus group, with part of the time devoted to testing the concept, followed by a group discussion (see chapter 6 for more information on focus groups). Let's look at an example of a concept exploration conducted for a microfinance nonprofit.

LOOKING FOR CONCEPTS

221

Potential pitfalls of concept exploration Henry Ford once said, "If I asked my clients what they wanted, they would ask for a faster horse." While you can get some great ideas by researching concepts with potential users, you don't want to rely on them to replace designers. After all, the most memorable designs are often very different from those that have come before, and study participants may not feel comfortable with a large degree of change. Participants' answers will be based on their current understanding. What you collect are reactions, not predictions of what they will or will not want in the future. Also remember that many other factors besides the project itself will influence future behavior (e.g. positive word of mouth). Avoid asking participants to make direct choices (e.g. "Which concept is better, A or B?"); instead, listen to them use their own words to describe the concepts presented. The results should be treated as input to the design process, not as a mandate for designers. For an excellent overview of the potential pitfalls of testing design concepts and recommendations for using the technique properly, check out this article on the AIGA website: "Design Meets Research" by Debbie Millman and Mike Bainbridge: http:// www.aiga.org/content.cfm/design-meets-research

Microfinance is the financing of very small loans to entrepreneurs in impoverished countries. These loans can enable borrowers to build businesses and, as a result, improve the lives of their families and communities. Loan funds come from people who come together to borrow or transfer small amounts to form a larger loan (for example, $25 to finance an $800 loan needed by a shop owner in Kenya). Entrepreneurs repay the loan as the business grows. The funding model is very powerful, but the organization has sometimes struggled to explain the concept in simple terms. In addition to the challenge of describing microfinance, the organization was also unsure how to handle the message and project about religion. This particular microfinance organization was inspired by the faith of its founders and employees. Many in the organization wanted to do it

222

CHAPTER 13: TESTING THE PROJECT WITH USERS

This inspiration was evident in the site's design, but they weren't sure how to strike the right balance: overemphasizing religious messages could alienate potential donors who were not believers in that faith. Too subtle and the organization would not truly represent its values. The UX designers set out to explore possible ways to use images and text to explain the microfinance model and show the organization's religious inspiration without alienating potential donors. To do this, they selected pictures and words that could be used to explain concepts related to the model (such as self-reliance and investment) and words that represented varying degrees of religious message (such as faith and spirituality). Focus groups were then scheduled with participants who were in the site's target user groups. Two groups of users were considered: those who indicated that they donate as an expression of their religious beliefs and those who did not. For each group, the facilitator explained the donation model (without mentioning religion). Then each participant was given a poster sheet, a set of pictures and a set of words to use, as well as additional blank cards to fill in with their own words if they wanted to. They were asked to create a collage of images and words they would use to explain the model to their friends and family. When they were done, the participants came back together to present their collages, explaining why they chose certain images and text and not others. Figure 13.1 shows an example of the collage created in this exercise. Figure 13.1 Example of a collage created by a participant during a proof of concept

The project team gained valuable insights from these collages and from the discussions that followed. Ideas included Participants avoided images of success in “Western

ern" (for example, suits and briefcases). They wanted to improve the lives of entrepreneurs without changing their culture.

LOOKING FOR CONCEPTS

223

All user groups agreed that the site should be focused on the purpose

organization (providing entrepreneurs with funds for development and prosperity), not the motivation behind it (religious inspiration). Participants felt it was important for the organization to stay true to who they are, but these messages could be conveyed in an area reserved to describe the organization itself (such as the About Us area). The attitudes and interests that emerged helped the team decide on the direction of messaging on the site and provided a good example of the value of proof of concept!

Tips for exploring visual design mockups At some point in your project, you may have mock-ups that represent the potential layout of your site's pages. If you choose to explore designs with participants, it's best to have two or more variations available for them to compare and contrast. With only one, you're more likely to get a "nice" bias: people don't want to sound too critical of the mockup because they don't want to hurt the designer's feelings. However, with two or more mockups, they will generally feel more comfortable being critical, as they are more focused on comparing the designs rather than directly critiquing them. You can give participants each project separately (on a monitor or in paper form) and ask a series of questions. For example, you could ask participants to look at each project for one minute and then choose at least three terms from a list that best describe the project. They could circle their choices on a piece of paper with 20 words such as boring, trendy, conservative, loud, safe, etc. in random order. You can also collect answers to open-ended questions. For example, you could give participants five blank lines to write their overall impressions of the project. Some of the information you can collect includes common brand associations made by attendees:

"Pseudo Corporation is the Rolls Royce of gadget makers: it looks great, but you probably can't afford it."

224

CHAPTER 13: TESTING THE PROJECT WITH USERS

Matching your style and lifestyle:

“I don't think I would let my son go to this site. He's only 8 years old and these photos seem too grown-up for him." The effectiveness of a particular model to explain a new concept:

"Oh, I get it, this site is like a wedding registry, but you sign up for charitable donations instead of tableware." Ways participants define some of the key terms you use:

"When I see the word solution on this page, I think I'll find all the products and services I need to track my shipments." Questions or concerns about how to use a specific set of tools

or the impact of their presentation (the following section illustrates some examples of participants' concerns). Designers can use these responses to gauge whether the responses they get are what they intended or if they need to try a different approach. It should be noted that participants (and project stakeholders, for that matter) often choose different elements of different projects: "I like this part of concept A and I like this part of concept B". This is a natural reaction, but it should not be taken too literally. You don't want an unnatural fusion of two different design directions. If the visual designer thinks popular elements go well together, then go ahead. But leave space for her to tell you it's less "chocolate and peanut butter" than "chocolate and pickles." In general, there are no hard and fast rules about what to do in a proof of concept or what types of items can be tested. Rather, the key is to make sure you set the right expectations with the design team about the type of information that will come out of the tests, and how that information will be used to make design decisions without stifling creativity.

Usability testing Usability testing is one of the most commonly used methods of testing UX projects. He is also best known among those who are not UX designers, so business stakeholders and the design team may already be familiar with him. The concept is elegantly simple: create a set with priorities

USABILITY TEST

225

tasks for your website, ask a few users to complete them and note where they have problems and successes.

Usability Testing vs. User Acceptance Testing Some people in your organization may have the misconception that usability testing only takes place at the end of development or at the beginning of deployment, when a working version of your website or application is available. maybe something in beta mode. This impression may also be related to the common practice of performing User Acceptance Testing (UAT) at this later point in time. The similarity of the names can cause confusion between the two. For applications that go through a formal QA process, UAT is one of the last stages of testing and is rarely performed by actual users. The main purpose of UAT is usually the final verification that the application meets the functional requirements set by interested parties; You can also catch any bugs or bugs that attendees report. While UAT can cause usability issues, it should not be relied upon as the sole method of detecting them in a project. Because it happens so late in the process, changes based on UAT feedback are much more expensive. It's much better to catch major issues early on before spending a lot of development time. Usability testing is designed to provide more realistic performance information early in the process.

The following sections cover common usability testing steps, such as choosing an approach Planning research Recruiting and logistics Writing discussion guides Facilitating Analyzing and presenting results Making recommendations

226

CHAPTER 13: TESTING THE PROJECT WITH USERS

Before you start, consider the goals of your project. They will help you stay focused at all times, but will be especially helpful in the early stages when you are choosing your approach and planning your test.

Choosing an approach Research approaches are often described as either quantitative or qualitative. Quantitative research focuses on numerical data and aims to provide high confidence and reproducible results among the target group of users. It relies on including a sufficiently large set of users in this group (called sample size) so that you can take the results of this smaller set and draw conclusions about how a group of users will respond in their set, within some error range. Overall, it's a more scientific approach to research, with formalities in test design and analysis. The focus is on evaluating the current design, particularly when compared to other iterations of the site, whether compared to the competition or a set of benchmarks. Conducting quantitative research means involving more participants to account for differences between individuals, such as speed of typing, familiarity with similar sites, etc. Surveys are an example of an information gathering method that can be extended to a wider audience by obtaining quantitative data - that is, if you ask the right questions (see Chapter 6 for more information on surveys). Qualitative research, on the other hand, is not so much focused on levels of certainty and repeatability, but more on gaining context and insight into user behavior. It is based on the designer's interpretation of the results, intuition and common sense. (Contextual research, discussed in Chapter 6, is an example of qualitative research.) The qualitative approach allows for openness to testing, which leads to exploring ideas and gaining insights; discussion with the user is just as important as their performance, if not more important. The focus is on improving the current design: getting feedback and feedback on what is being presented to generate ideas. So is usability testing quantitative or qualitative? This is one of the oldest discussions in the field of UX design. Either approach is possible and can yield useful results. Proponents of a more quantitative approach say:

USABILITY TEST

227

It allows you to establish measurable patterns that can be tested

in subsequent iterations, showing progress toward a goal (for example, reducing time to checkout by 20 percent or detecting 80 percent of usability issues on your site). This also makes it a good approach when you want to do a formal comparison between two sites or evaluate a specific site. It provides statistically verifiable results, which can be important

important when defending the recommendations of stakeholders who trust data-driven decisions. It reduces the likelihood that individual UX designer's biases will influence it

results. It gives a greater degree of certainty that the results obtained will be

reflected in the results among the entire user base. Provides a transparent numerical method to check the results (e.g.

how many users encountered the same problem). Defenders of qualitative usability testing say: Qualitative research builds knowledge and empathy in the designer,

promoting creative, user-centric solutions. It relies heavily on the UX designer's intuition to make sensible recommendations.

recommendations, which is largely the reason he is on the team. For usability testing in particular, the qualitative approach is often less so

more expensive than quantitative, both because fewer users are needed and because qualitative research does not require formal scientific knowledge of design and analysis (such as statistics). It is very easy to misanalyze the results of quantitative research, to lie

(though not intentionally) with the data, so a quantitative approach may actually pose more risks than a qualitative test if not done properly. Although the results are not numerically validated, they can be verified with

a designer who will make a phone call about the potential impact of the issue using your informed justification and build a case with user stories. Qualitative usability testing is the most accessible approach for those without training in formal scientific methods and provides a rich source of data for design. For these reasons, we'll focus on qualitative test design for the rest of this chapter.

228

CHAPTER 13: TESTING THE PROJECT WITH USERS

How many users is "enough"? The question "How many users is enough?" in a group of UX designers, it's like bringing up religion at a political rally: it's a hot topic of debate. This is also an unavoidable question as you will need a framework from which to start planning your research. This is related to the applied approach: quantitative or qualitative. To give you a short answer, here are the guidelines that seem to have the most consensus in the UX field, provided by Jakob Nielsen: For a quantitative test, plan a larger number of participants: 20 participants per research round (see http://www.useit.com /alertbox/quantitative_testing.html). For a qualitative test, five to eight users per group for each test round are usually sufficient. Ideally, more than one round of investigation should be done to uncover issues that may have been "hidden" under other issues or accidentally introduced into a new project (see http://www.useit.com/alertbox/20000319.html).

Research planning When designing a usability test, it's important to answer a few questions early on to ensure focus and scope. This can be provided as a document written and discussed with the project team and key stakeholders, often referred to as a user research plan. The plan should describe your approach chosen above. Why are you testing? Write a clear statement describing the objectives of the test, based on one or more objectives of the overall project. See Chapter 2 for examples of project goals and how they vary by project type. Who are you testing? Once you've created a user model (see chapters 6 and 7), you can use it as a basis for making user testing decisions. If you haven't already, meet with the project team and relevant stakeholders to prioritize user groups. This information will be included in your filter (discussed in the Recruitment and Logistics section). USABILITY TEST

229

At this point, you also choose which user groups to render and how many users to include in each group. What are you testing? The question of what you are testing involves two related questions: What method will you use to render your site or app? And what tasks are you planning to include? If you have an existing app to redesign, you can run a full test of the current version first to find major usability issues that need to be addressed. If you're working on a new project, you can use paper sketches or prototypes (for example, a bundle of printed wireframes) to represent new interface elements, such as pages. These low-fidelity UI representations allow you to quickly generate and discuss ideas within your project team, and quickly replicate them with participants (see Chapters 10 and 11 for more on sketching and framing). When working with a new project that includes highly interactive elements, it may be best to create a prototype that realistically simulates the design navigation flow, but can still be built quickly before full-scale development begins (see Chapter 12 for more information) . . prototypes). The captured pages will be closely related to the selected tasks. If you plan to use prototypes for testing with users, you need to plan for job master pages as well as intermediate pages and alternate funnels. You may not need to go into detail about each one, but you will need to plan a response if the user goes in that direction. Sometimes it can be as simple as a page telling you that a certain path is unavailable and asking you to go back to the previous page and try again. The details of your tasks will be included in the discussion guide (discussed below), but since the scope can vary greatly depending on the type of tasks you include, it's worth having a mapped out list when planning.

230

CHAPTER 13: TESTING THE PROJECT WITH USERS

Details For more information on iterative design and sketch testing, as well as truly inspiring information on creativity in the design process, read Sketching User Experiences: Getting the Design Right and the Right Design by Bill Buxton (Morgan Kaufmann, 2007). For more information on paper prototyping techniques, see Paper Prototyping: The Quick and Easy Way to Design and Refine User Interfaces by Carolyn Snyder (Morgan Kaufmann, 2003).

If the list is too long and you're not sure how to prioritize, here are some possible priorities to consider: Areas where the project breaks some established conventions. If

calling it a "gift bag" instead of a "shopping basket"? It's worth checking if this is clear to users. Areas where design decisions are politically charged. you can have

a strong sense that a particular design direction is the right one, but knows that there are many disagreements between stakeholders or other project team members. Seeing is believing. Areas where usability issues can have critical consequences, such as loss

sales or, in the worst case, loss of life (drug dispensing apps are a good example of this). Then specify the information you want to collect when the user tries to complete each task. What information do you collect? We focus on qualitative usability tests, which usually have a smaller set of measures. In most cases, you want to understand the problems users may encounter, the different levels of frustration they may experience, and the severity of the specific issue. For example, there may be an intermittent problem (not experienced by all users) that causes you to permanently lose your published history. This should certainly be the focus of your report!

USABILITY TEST

231

To gain insights into the users you're testing or test rounds, you might want to consider collecting some data as part of your test. Again, if you're running a qualitative test with fewer users, don't go overboard with these numbers (calculating the average number doesn't make much sense if you're only testing five users), but the following metrics can help you understand the severity of some of the issues your users are experiencing. Success: The extent to which the user was able to complete the task. If you search among users, you can also refer to the "success rate" - the number of users who can successfully complete a task. It sounds simple, but it means you need to define the meaning of success! For less formal testing, a job can be said to succeed if the user reaches a final state (e.g., the publisher successfully approves the story). Success can be tracked more formally by looking at the different levels of intervention required by the facilitator: Level 1 prompt: The test facilitator answers the participant's question but does not provide any additional details. For example, a participant asks, "I think it would be this button, should I click it?" and the facilitator replies, "Go ahead, try it." A level 1 warning in itself does not indicate a failed task, but it is worth keeping in mind as the participant is likely to feel uncertain at this point. (Although if this is your first assignment, you might as well not be familiar with usability testing.) If the user doesn't need prompts to complete the task, or only needs one or two Level 1 prompts, you can consider this step a success, unless you believe the time it took for the user to far exceed the user's level of success Patience probably for Level 2 users Warning: The test facilitator sees that the participant has difficulty and gives hints in answering the question. This level does not involve answering directly, but the answer may affect the user's focus. For example, the facilitator might say, "Is there anything else on this page that you think might be related to this assignment?" Here you can set a limit on the number of level 2 prompts that can be given before a task is marked as failed (at the second prompt, for example) or "succeeded with difficulty".

232

CHAPTER 13: TESTING THE PROJECT WITH USERS

Level 3 Warning: Participant gave up out of frustration or fought to the point where they would likely give up if faced with a task in real life. In this case, the moderator gives a direct answer to part of the task, for example, saying "To approve this story, you must click the Submit button." If a participant requires a level 3 flag, the task is usually marked as failed. User Satisfaction - Sure, you've done the job successfully, but what do you think? It can be helpful to ask a few follow-up questions after each task (with the timer off) to understand how satisfied or frustrated users are afterwards. If you find someone who doesn't like to talk, this could be the main window where you can access their soul. Table 13.1 shows examples of some post-assignment questions you can include. TABLE 13.1: 13.1 Users TABLE

Satisfaction questions I STRONGLY DISAGREE

TO DISAGREE

I NEITHER AGREE NOR AGREE

I COMPLETELY AGREE

The job took longer than I expected.

The task was easy to do.

I was frustrated trying to complete this quest.

User Satisfaction Questions User Statements - This is not an indicator, but what users voluntarily report is a key set of details to collect. Adding user citations to a report is an effective way to incorporate the human factor into the results so that stakeholders not only interpret the data but also understand the insights that lead to insights. During the test, you can mark statements as questions or comments; we will break them down in the report (see the section "Generating information" below).

Recruitment and Logistics Now that you've outlined your research and know how many participants you need from each group, it's time to plan your tests!

USABILITY TEST

233

Creating a list When creating your research plan, you outlined the types of users you want to include. You can use this outline as an approach to generate a list of potential participants. Ideally, you're looking for names, email addresses, and phone numbers. Here are some sources you can use to compile this list: Registered users of the affiliated company's website Customer contact information Responses to research posts posted to relevant websites or groups

to your research topic. This can be broad, such as posts on Craigslist, or specific, such as newsgroups focused on your business's industry. Emails to friends related to the subject of the test.

You want to ask them to forward the invitation to others who might be interested, because using topics they know personally can skew the results. This type of word of mouth is a great way to find a pool of potential candidates, but keep in mind that these candidates still need to be vetted. (If you or other team members know people well, it can be tempting to let them slip away.) Conclusions in the form of short surveys that pre-qualify participants, or in

advertising space on relevant sites or on the company's website Publications or prequalification questionnaires in public places where

potential participants can be found. For sites with a strong connection to a physical location, you might as well do most of the testing and planning on the site. Third party recruitment companies that can also run a filter for you

and help with programming. This can be an expensive option, but if you are looking for a specific type of participant that is difficult to recruit, or if you need to recruit many people, you can save a lot of time by outsourcing this part of the process. Some companies also specialize in certain fields (such as medicine) and can provide tips on how to encourage a high engagement rate.

234

CHAPTER 13: TESTING THE PROJECT WITH USERS

Get ready to get creative here. Use your empathic skills to think like your target users: where can you find them and what might motivate them to join? This last question brings us to the next topic. Choice of remuneration What will motivate members of your user group to participate in research? It may or may not be money, but participants want something of value for their time. If you're working on a site for internal users, you need to demonstrate this value to managers who need to approve the use of company time to participate in research. In that case, you can focus on how a better system directly benefits your group. If you're working with potential external users, here are some variables to consider when determining how to compensate: How general or how specific is your audience? For a widely used e-commerce site, your audience will likely be general, and you can often offer a lower rate of pay in the form of a check or gift card. For an app used by lawyers, your compensation will need to be of high value and it is often better to use something other than money as compensation (access to a premium service, for example). In these cases, the check may seem like an insult: someone who pays $250 an hour probably isn't doing it for the money. If you work with large clients, treat them as a target group and reward them well. What interest can the topic generate? Some attendees will join because they want to see what's going on in the area you're testing. If this is an area of high interest, you may not need to provide much additional compensation: the reward is access to something that no one else sees yet. But be realistic: you might be so excited about this theme, but will your users be? Will people attend mainly because they want to contribute to a cause? Some groups will be motivated by altruistic goals and may be put off by the offer of money for participation. If you're testing something that improves the community (online or offline), you can get more engagement and happier participants if the experience is about joining, not doing.

USABILITY TEST

235

what to charge In this case, you can express your gratitude by thanking them publicly and letting them know when the site is ready, what contribution they have made by participating in it. How inconvenient will it be to participate? If attendees have to travel to your site, be prepared to pay more. If they are participating in remote testing from the comfort of their own home or office, less is needed. Of course, time also comes into the equation, and people will expect to be compensated more for 2 hours than for 30 minutes.

Possible Compensation Your situation may vary, but here are some things you can offer: $50 for a half-hour remote trial with general user group $80 - $120 per one-hour trial person with general user group $180 - $250 for one-hour trial with a specific group of users that you believe will respond well to monetary compensation Free service for three months, free company products (preferably those not yet available to everyone), membership in an exclusive group for six months, etc. for a specific group of users, for who wouldn't be impressed by a check, such as lawyers, doctors, and sales executives. Here again, creativity and focusing on your people helps. What will motivate your user group?

Assessment An assessment is a type of questionnaire that can be used with potential participants before scheduling them. This ensures that they fit your definition of a representative user. The questions are designed to ensure that the respondent is a current user of the features you are testing.

a potential or future user Determine if you fit into one or more user groups

236

CHAPTER 13: TESTING THE PROJECT WITH USERS

Exclude specific respondents who may have an experience that could be biased

Your results Gather the most important information you need to know before the participant shows up

(optional) The reviewer should include an introductory script that the recruiter can read over the phone, along with instructions on when to qualify the participant (if eligible) or end the interview (if not). The end users of your evaluator will be the people who recruit your participants or a potential participant if you are using an online form for evaluation. Both can work, but it's usually best to gather a list of stakeholders via a form or email and then evaluate them over the phone. Because? Because, unfortunately, it's usually easier for people to misrepresent themselves on paper than by responding directly to someone, and it's not unusual for someone to try to join a study even if they don't qualify. Especially when it comes to compensation! Your evaluator should also filter out those who have knowledge that may influence your results. For example, the question is often asked if the respondent works in the field of market research because they are probably too familiar with research in general and may not give you real feedback as a result. You can also exclude those who work for a competitor if you are concerned about sharing project information. Here are some sample questions you might see in the inter-business internet ordering app filter. In this case, we target a group of users who are comfortable using the Internet and making purchases over the Internet and probably also do it themselves. Note that some questions are designed to filter out participants, while others (such as question 4) are more geared towards placing qualified participants in the right group of users. 1. What age are you? [mixed age 18+] Under 18 years old

END

B. 18–24 v. 25–34 div. 35–44 e. 45–54 Fr. 55 or more

USABILITY TEST

237

2. How often do you use the Internet at home? Down. Never

END

B. Less than once a month

END

C. A few times a month d. At least once a week E. A few times a week F. Once a day or more 3. When was the last time you made a personal online purchase of a product? Down. last month b. 1 to 3 months ago C. 3 to 6 months ago D. 6-12 months ago

END

My. more than 12 months ago

END

F. I have never made a personal online purchase.

END

4. When was the last time you visited pseudocorporation.com? [Group A are infrequent users or not; Group B are frequent users]

238

Down. I have never visited the site

GROUP A CONSULTATIONS

B. Last month

CHECK for GROUP B

C. 1-3 months ago

CHECK for GROUP B

D. 3-6 months ago

CHECK for GROUP B

My. 6-12 months ago

CHECK A or B

F. More than 12 months ago

GROUP A CONSULTATIONS

CHAPTER 13: TESTING THE PROJECT WITH USERS

You've been fired. Saying is a harsh sounding word. This means that the interview should end because the respondent fails the test. You don't want the respondent to feel bad about it, but you also don't want her to waste time asking follow-up questions when she knows she doesn't fit. There are many ways to deal with this. Favorite is to just say that the pool she's eligible for is already full and ask if you could contact her in the future if there's another test she'd be interested in.

Planning space and equipment At this point, you will know whether you are testing remotely or in person, and how much time you need for each participant. Here are some other decisions you need to make: Where are you testing: in a rented space with an observation room, in a conference room on company premises, or somewhere where potential users will be? Plan a quiet place that will comfortably fit two or three people, along with the configuration of the computer on which you will be testing. What staff will you need besides the moderator: You can save time and increase accuracy by, for example, recording information during a test. Other possibilities include greeting (meeting incoming participants, handing out questionnaires while waiting, and escorting participants to and from the testing room) and someone to provide IT support in case something happens during the test. How you record your test: You can use different methods, but software like TechSmith's Morae and Camtasia Studio make it easy to record your screen, and Morae has additional webcam audio and video integration features.

Writing discussion guides Finally, you need to gather the materials needed for the test itself. You have your general tasks listed in the research plan; now you need to finalize the actual text and instructions for the task. You will have at least two packages here: one for the test moderator and one for the participant (with enough copies for each test to contain one of each).

USABILITY TEST

239

Start with an introductory script that the facilitator can read to the participant. Many good examples are available at http://usability.gov/templates.

Surfing Usability.gov is a website developed by the United States Department of Health and Human Services as part of an initiative to encourage websites that are accessible to a wide audience. It includes an excellent set of reference materials to help with user-centric design, including an example of a video consent form (in Microsoft Word format) that participants must sign before recording: http://www.usability. gov/templates/docs/release.doc

Your instructions must contain all the details needed by the participant to successfully complete the task or tasks you are testing. If your assignments require a lot of data entries and customizations, set up information in advance and provide participants with default data to use. For example, if it's a login, it's likely that all attendees are using the same set of login credentials. Make sure your homework instructions include all of this information clearly so that it can be easily completed. Here's an example of how the task for the content editor becomes more specific in the discussion guide. The plan's original task is "Find an article ready to be edited." In the Discussion Guide, it goes like this: INTRODUCTION Your manager has asked you to take on a new role: to edit and approve articles published by authors who contribute to the company's website. After the article is approved, it will be published on the website in the News area. You and three other editors will approve the items to ensure they fit the company's message. You have received the following authoring tool login details: Username: grobertson Password: come2gether

240

CHAPTER 13: TESTING THE PROJECT WITH USERS

Read each assignment aloud, then complete it using the editing tool. Task 1 Log in to the tool and open the article you want to edit.

As you can see above, we tweaked the quest a bit to get a clear end state: item open. This type of customization will be commonplace once you get into this level of detail and consider how you're going to measure success. You can also track each job with the user satisfaction questions discussed in the planning section. In general, it's best to give each task a separate page so that the user doesn't feel like looking ahead. In summary, your test materials should include the following: Video Consent Form (see Navigation Sidebar on the previous page).

see page for more information) Discussion guide for facilitators with introductory script Discussion guide for participants with detailed tasks and user satisfaction

questions Format for taking notes if you have someone dedicated to it. So maybe

these include a recording tool built into the test software, a spreadsheet for recording responses, a printed template for verifying key information (such as the types of prompts required). Taking a little extra time before setting up this test will ensure consistent results and will save you a lot of time reviewing recordings. Optional survey. Sometimes participants arrive earlier and have

some waiting time: this is a great opportunity to gather some additional information. If you've designed a survey before, why not reuse it here? The method of compensation that will be provided to the participant at the end

proof (money in an envelope, a commonly accepted gift card such as a Visa gift card, etc.). If you have chosen a compromise, such as free services where nothing is provided after the test, reassure the participant that they will receive a follow-up no later than the next day. If you use paper prototypes during your test, you will also have these materials to work with. Before starting your first test, make sure your games are set up for ease of use.

USABILITY TEST

241

Facilitation The role of the facilitator is to introduce the participant to the process, answer their initial questions, and then collect possible ideas while trying to let the participant act as naturally as possible. Be sure to ask users to think aloud during the test, as if they were talking to each other (and gently remind them to do so if they start working silently). Thinking aloud is a way to gain the best insight into user behavior. You'll learn a lot about problem solving and thought processes by learning about them during the task itself, rather than asking participants to recreate them later when their memory isn't as accurate. Also, be careful not to give the contestant the "correct" answer too quickly! One of the hardest parts of running a usability test is watching a carefully selected participant struggle with a task and just let it happen. After all, you're probably in this field because you're an empath. You want to help people. So it might seem a bit sadistic to see someone get more and more frustrated, ask for help, and then reply, "What would you do if you tried it yourself?" Whenever a participant asks you a question during your work, pause for a few seconds before answering. Participants are more likely to ask questions at the beginning of the test, especially if they feel uncomfortable working with you sitting next to them. Once they realize you're there to observe, not talk, they'll often start focusing on the task at hand rather than your presence. Here are some sample questions from participants and suggested answers: Participant: "Looks like this could be this card, or should it be here?" facilitator:

"Go ahead, try it."

Participant: "Should I go here?" facilitator:

"Do you think you would do that now?"

Participant: "Is this a way to submit feedback?" facilitator:

Silence. He has a friendly, relaxed expression on his face as he smiles at the participant and then looks expectantly at the screen.

So when are you stepping in?

242

CHAPTER 13: TESTING THE PROJECT WITH USERS

If the user has already put in more effort than you think they would really do working alone, and you think you've found out why they went down the wrong path, it's time to move on, especially if you have more tasks to accomplish. and you don't want him to take his frustration out on the rest of the test. In Chapter 6, we mentioned the importance of avoiding leading questions in user interviews. The same also applies here. If you feel you're too close to the project and that criticism might make you defensive, consider mentoring someone else to help you take notes.

Analysis and presentation of results You have finished all the tests and now you have a mountain of data to analyze. But there are some key findings that you already consider significant, and your project team is eager to find out how it turned out. You can schedule an informal oral discussion of key findings for the team. It can help verbalize some of the trends you've noticed and set the stage for a later report. Be sure to let you know that these are preliminary impressions and that you will need time to analyze the data in more detail. You don't necessarily want to jump to the recommendations here before you have a full picture of where the problems might be. When you have time to sit down with the data, review it with a few things in mind: The amount of time you have to analyze. It's easy to get lost in the details and try to cover everything. As always, keep an eye on your test and your goals while extracting important results. If you have ten hours of recording a test and five days to write the entire report, you probably don't want to waste your time watching the video of each test. Trust your notebook and go back to the videos mainly to make sure that the key quotes you remember are recorded correctly. How your results will be used. This is an important detail that can often be overlooked. You can create a beautiful 20-page report, but only one of those pages can have a lot of mileage: the executive summary.

USABILITY TEST

243

If business stakeholders want to see the details, the report itself can be the main way to communicate the results. If you think you'll need two levels of detail, one for stakeholders and one for the project team, consider also creating a presentation version of the report that presents key findings in a more visible, understandable, and prioritized way. Those interested in the details can read the full report. Prioritizing Issues By the end of the test, you'll likely have a long list of usability issues that need to be understood and prioritized. Here are some characteristics that will help determine the severity of the error: Consequences. Negative results indicate a problem. For example, if a participant loses data due to a usability issue, this guarantees a high rating. Let's say you spend ten minutes filling out a complex form and accidentally click on a link that takes you to another page. If you press the browser's back button, will your data be lost? recoverability The extent to which the participant can recover from finding the problem; for example, can you easily return via an alternate path? Frequency of appearance. Because you don't work with a lot of people, it's not just a sign of seriousness. But if five people make the same mistake and it takes them down a less than optimal path, that's a good sign that you should consider making it a higher priority. rational cause. If the problem didn't occur often, but someone within your user group encountered it, did so for a reasonable reason, and there was a clear reason for the error, then the problem should be taken into account when making recommendations. Generating information In addition to the collected issues, you will have a large amount of user feedback at your disposal, which can provide valuable information to the project team. As described in Chapter 6, the affinity diagramming exercise is a great way to bring these assertions together and identify patterns together.

244

CHAPTER 13: TESTING THE PROJECT WITH USERS

Here are some ways to categorize user comments (see the "Contextualization" section in Chapter 6 for more details): Goals Mental models Ideas and feature requests Frustrations Workarounds Value statements Pleasures (don't skip them, no, you don't want to miss out on a good thing! ) Expectations (especially when there are none)

Remember to also include positive conclusions in both observations and recommendations. Usability test reports are often considered too negative, mainly because the researcher prioritizes discussion of things that need to be fixed over things that are going well. Taking the time to discuss the good stuff will make the overall report experience better for everyone. It also helps the project team get involved in the results and get excited about further improving the project.

Making Recommendations Even before you start analyzing, you probably already have some good ideas in mind for solving the problems found in the test. Sketch them along the way, identifying problems and insights so you don't lose them. Just be careful that a single idea doesn't take over too quickly and influence your view of other potential approaches that might solve more problems. A good recommendation should, if possible, solve more than one problem. You can group issues

together under one larger recommendation, depending on how specific and detailed your problem descriptions are. Be practical and simple, avoiding prematurely detailed designs.

USABILITY TEST

245

Use vocabulary that is direct but not condescending. Adoption

Criticism is difficult, especially for those who were directly involved in the tested design. Do not underestimate the problems, but remember that your words should sound constructive and respectful. Remember that recommendations should be addressed to your end users just like the system. At the end of the report, take a step back and ask yourself if the original goals were met and how best to share the results with the different people who will use them: stakeholders, designers and developers. Speaking of developers, it's time to bring them back to the forefront. In the next chapter, we'll cover the things to keep in mind as you move from design to development and beyond.

246

CHAPTER 13: TESTING THE PROJECT WITH USERS

Transition: from design to development and beyond Where are we going? The definition and design phases of your project are now complete. What now? The process of designing a good user experience never ends. After going through so much defining and designing, how do you stay committed to ensuring that the final product of the project is the user experience you designed? And where does it come from? Russ Unger

247

This is the end... ...of the book. This is the last chapter. However, this is not the end of the user experience design process, although it may seem so. After going through all the previous phases of the project, you may think that you have done your job and have nothing more to contribute. In many cases, UX design work ends up somewhere as tasks in someone's project plan, and once the work product is delivered to the rest of the team, it is invariably transferred to another project. It's time to close that door and start something new, right? Very bad! There's still a lot you can do to ensure you're creating the best possible design for the user.

Visual Design, Development, and QA In some cases, working with a design or development team that receives a design-based work product is ideal. Sometimes downstream partners rely on you to answer questions, provide feedback, and help them with some design concepts they are working on. (It may even sound like prototyping!) In these work environments, UX design is already in place, and the team probably had the foresight to give them time to complete these consulting tasks. However, in many organizations, the roles of user experience designers, information architects, interaction designers, etc. are still very new. How these roles are managed may not be clear, and the decision of how much you should be involved may be up to someone who doesn't fully understand user experience design. Perhaps it's up to you to find ways to stay engaged.

248

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Here are some suggestions: 1. Please buy them a copy of this book. 2. Don't be shy. 3. Read the rest of this chapter and look for opportunities where you can participate and be useful. 4. Ask for participation and be ready to defend your request. There are other instances where you may find that the visual design or development team is the king of the company and your projects, and you may struggle to stay engaged. You may find yourself trying to tear down the walls just so you can review your work and ensure compliance. This is not always the case, but it does happen. Christopher Fahey, co-founder of Behavior (www.behaviordesign.com), is no stranger to overcoming this challenge. He gives the following advice: some organizations are strictly divided. To stay involved in project development beyond the initial design phases, you need to be proactive and insist on feedback and corrections to the development and visual design teams. Often they won't even think to ask you to be there. This is best done at the planning and budgeting stage of the project. Otherwise, you may literally have to voluntarily submit your services to ensure that the project doesn't degrade during further development. One trick is to simply ask to be added, even informally, to the QA team (assuming you have one; if not, definitely ask your visual designers and developers!). You can then add your criticisms and deviations to the same bug fix queue that developers check daily.

Of course, many projects will not have the luxury of a quality assurance team. In an ideal world, every project would have such a team; however, in reality quality control is not always available. Sometimes developers do QA themselves during development. In addition to making you cringe, knowing this should make you work even harder with programmers.

VISUAL DESIGN, DEVELOPMENT AND QUALITY ASSURANCE

249

The art of contracting The art of contracting can become a fundamental aspect of your role as a user experience designer. Downstream business partners, such as visual designers and developers, are free to make changes to their work without realizing how it affects key elements of the user experience. In case someone tells you that something "can't" be done, you should be prepared to come up with a plan B. Good negotiation skills will help you defend your design decision (which should be based on research). . done) and convince others that user experience is possible. Alternatively, these skills will help you work with partners to create a successful Plan B that meets as many of everyone's needs as possible. For additional information on negotiation, see Getting to Yes: Negotiating Agreement Without Give In by Roger Fisher, William L. Ury, and Bruce Patton (Penguin, 1991) and Selling to the VP of No by Dave Gray (XPLANE Corp., 2003).

This is especially true in many small businesses: quality control is a luxury. Quality control is "done by everyone, but especially by the developer," says Troy Lucht, director and chief development officer at Ascend Realty Solutions (www.ascendrealtysolutions.com). Everyone tries and wants to contribute, but without resources dedicated to creating test scripts, it may be impossible to tell people what needs to be tested when development is often down to the last possible minute. In many cases, our in-house designer is someone who knows the app as well as I do, so they can provide more thoughtful feedback. Adding a UX designer to the mix would really round things off for our small team.

While your UX design product may not include test scripting, in some cases you may want to test the schemas and annotations you've created to make sure everything is covered and that all Defined CTAs are working correctly. This situation isn't ideal, but it's an approach that can be useful when QA doesn't exist. The key takeaway is that user experience design doesn't stop just because you've delivered your working product and done the knowledge transfer. His role may temporarily take on a more consultative nature, but it's not over yet.

250

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Testing the design with users (again) Haven't we already done user testing? I hope you can answer yes to this question, but that's not always the case. Unfortunately, this particular testing step that is designed to test the final designed and developed site with real users before launching it also fails. This allows you to take one last look at your site and find any last-minute errors and glitches that you may have missed during QA testing. Once you've identified your target audience, you can test your site in any scenarios that appear to be high-risk or may cause problems in previous iterations of your site. This round of testing can provide the information you need to determine if your site is ready to go live. If significant issues are found during this round of testing, it may be important to update and retest.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1… Go! "If you build it, they will come..." This theory is often thrown around and almost as often disproved. You can create the most beautiful, most satisfying and useful application, publish it to the world and find out two months later that hardly anyone uses it. What does it give? User adoption is the degree to which your target group of users use your website or app. Some adoption issues can be avoided by following good search engine optimization practices. search (Chapter 8) making sure users can find your new site User adoption also means that good user experience design doesn't end when the project ends, or is limited to the project you're working on. can help marketing, customer service, public relations and training teams ensure a smooth implementation and user base that is excited about a site or project by helping them with three factors that often influence site adoption: user: personal benefit

10, 9, 8, 7, 6, 5, 4, 3, 2, 1… PREMIERE!

251

Support network feedback

Let's take a closer look at each of them in turn.

Personal benefit One of the most important questions users have to answer is "What do I get out of this?" No matter how great your site is, if you can't quickly explain the unique benefits it provides to a particular type of user (or one of the people you've identified), you may have a hard time engaging your users. Some of the benefits are simple: "Using this camera feature, you can post photos to your online account with one click." Some of them are indirect: "By using this timesheet tool, the company can more easily track the time spent on each project." You have spent valuable time collecting information about your users; Now use this information to help the marketing department customize your messaging.

Support When your users need help with your site, how do they get it? In addition to the contextual support that they will strive to provide excellent UX designs, the answer to this question also includes training and customer support. Do you think your users will respond better to face-to-face training than online training? Will some of your users skip training and expect everything they need to be right on the site? Is live chat an important customer support option for your users, or will they be happy with phone and email support? Support efforts are complex, and understanding your users can help your customer support and training departments effectively.

252

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Network opinion Word of mouth is the most important influencer. What is the reputation of your client's company and current website among the target user groups? Even if the answer here is positive, it does not mean that no effort is required: upkeep is always important when it comes to reputation. Don't use a positive answer as an excuse to move on to the next section: the effort to maintain doesn't have to be significant, but the effort required to regain a rapidly declining reputation can be staggering. A little TLC can go a long way, so keep reading. If the answer is no, serious effort must be made to improve perception. You may need to reach out to the user community and identify who the influencers are, how they prefer to communicate and how they influence the audience, and then engage them. There are many ways to engage users through social media and influence opinions about the client, company and website. Help your client identify opportunities to engage these communities and try to steer them in a positive direction. If all three factors are present and you are still seeing low usage, consider how and what your competitors are doing to meet user needs. How to make your product or site stand out?

Post-launch activities We live in interesting times: many companies are putting themselves or their products into the "beta" state. A beta usually means real, unfiltered users are the audience for live site testing to help identify crashes, bugs, crashes, or other issues. Once upon a time, betas were usually only offered to developers, but now it has become common practice to open betas to the entire user community. During the beta phase, it is necessary to set up communication methods to log and report any issues that users may have. Any occurring system faults should be recorded and made available to the project.

ACTIONS AFTER STARTUP

253

equipment. There should also be a mechanism that allows users to report issues they encounter to the appropriate project team members. If this kind of communication doesn't happen, if user experience designers, visual designers, and developers don't know what's going on during the often rigorous and fast-paced beta phase, the site can be updated and made available to users again without much effort. implemented strategy.

Post-launch analytics Once your website is up and running, one of the first things you should do is start collecting data about your website usage. The best source of information is your site's log file. Unfortunately, user experience designers are probably not at the top of the list of people receiving or viewing this information, so find the person responsible for hosting your website and use your negotiating skills. Website analytics can give you insights into your website visitors. Among other things, you can find out who is new to the site and who is returning to the site Number of page views Duration of a page view Page depth Where visitors to the site leave (which pages) Session view time Ad impressions Search terms used, results and re-searches

With this information, you can find out where users are having problems by pinpointing problematic points on your site. While the analytics may seem dry and full of numbers, the data and insights will help you ask the right questions in post-launch testing. Note For more information on web analytics, start with Avinash Kaushik's Web Analytics: An Hour a Day (Sybex, 2007).

254

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Testing the design with post-launch users (again, again) After gathering analytics from your website and gathering information from customer service or other departments that interact with users, you can start creating a list of questions to use in the next round of user testing In other words, use the collected data to create a new set of questions for your site visitors and use the skills you learned in Chapter 13. One of the Benefits One of the benefits of this round of testing is that you have the opportunity to test the same batch of users you've worked with before, to determine if their views have changed after launching and continuing to use the site. This can be quite useful: if you re-test the same group of users (or part of it), you can re-ask some of the original questions (feelings about functionality, ability to perform certain tasks, etc.) and analyze the variability of responses over time. This potential for variability can help you discover new areas for improvement on your site as well as gain insights into your user learning curve from previous rounds. As a bonus, analyzing differences in responses can also help identify new questions that have not been considered before.

Everything is ready, right? NO.

It's like starting over... By gathering analytics data and testing your design with research data, you can start to develop a list of improvements that would benefit the website. Once they are fully compiled, you can prepare a new proposal (Chapter 3) based on their recommendations. This proposal may lead you to a whole new project, which may send you back to defining a new set of project goals (Chapter 4) and business requirements (Chapter 5). Power

HOW TO START AGAIN...

255

then move on to further research (Chapter 6), creating personas (Chapter 7) for newly defined purposes, improving SEO (Chapter 8), updating or creating new sitemaps and workflows (Chapter 10), updating or creating new mockups and annotations ( chapter 11), running additional prototyping rounds (chapter 12) and further testing the design with users (chapter 13). Projects shouldn't die. They must be a springboard for new projects that are oriented towards continuous improvement of user experience design.

256

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Index Absolute path, using prototype HTML 213 confirmation and approval, contained in proposals 53-54 ACSI (American Customer Satisfaction Index) 103 action planning 162-164 Adaptive path using pen and paper in 189-190 Website 168 additional costs and fees, including in requests 50 Adobe Acrobat PDF prototyping tool, features 214-215 Adobe Illustrator website 167 Adobe InDesign website 167 advocates, priorities 150-151, 154 Feature conflict affinity diagram 160-161 steps out of 99-100 for use in usability testing 244 overview of agile approaches 63-64 resource for 65 AIGA site 51 Ajax issues 132 Align interactive site 217 alt attributes, usage 139 American Customer Satisfaction Index (ACSI) 103 analytics tools availability 24 benefits of 254 annotations summary of 187 tools for 189-190 and wireframes 186-187, 193-194, 201 Aquent talent site 51 predefined arrows and connectors 170 Ascend Reality Solutions site 250 Ash, Tim 16 Ashton, Jonathan 143 Ask.com, 128 guesses searched including proposals 47 -48

compare attributes 90 prioritize and define features of the Axure RP prototyping tool 215 website 167

89–91

B Babyhold Site 118 BabyNames Site 118 Balancing, Impactful UX Design 6-7 Balsamiq Mockup Prototyping Tool, Features by 216 Baty, Steve 12, 95 Behavioral Site 249 Beta, Defined Billing Rate 253-254, Determination 51 Defined Black Cap 130- 131 vs. white hat 141–142 blog functionality, sitemap for 166, 191 Blue Flavor site 167 Blueprint site CSS 167 body language, focus group interpretation 106 bot, explanation 129 brand presence sites described 11 examples of 13 features 12-13 goals for 13 - 14 Role of brand strategist/manager 26-27 Brooks, Mark 200-201 Building ownership, system for 183 Buley, Leah 189 a 190, 201 Business advocates' concerns 154 versus development and user advocates 155 business analysis role 27-28 use of mockups in 188 business requirements 73 See also gathering requirements explaining 68-69 combining 82-84 performing heuristic analysis for 70-73 scheduling meetings 78-79

INDEX

257

business requirements (continued) creating worksheets for 153 defined 68 example 83 collecting responsibility for 75-76 gathering stakeholders for 76-77 for Global Cruises homepage 195-196 legacy by developer 157 listening to ideas for 81 notifying conflicts between 83-84 determining priorities 151-152 conduct meetings effectively 80-81 for models 189 defined business stakeholder 75 Buxton, Bill 231

Calendar tool C, functional prototype of 217, 219 campaigns. View Marketing Campaign Pages Rating Cards Closed Ratings 110 Explanation 93 Group Ratings 110 Review 107-108 Testing 109 Process 108-110 Providing Instructions 109 Remote Assessments 110 Clients, Using Mockups 188 Masking, Explaining 131-132 Cloning Review 142 Prevention 138 unintentional 133 collage, use in microfinance example 223–224 communication, relevance to prioritization 160 SWOT analysis companies 61–62 competitor comparison 61 company culture hierarchy 36–37 history 34–35 logistics 37

258

INDEX

compensation, determination for 235 user groups, 241 competitors, comparison of 61 concept exploration. See also visual designs example 222-224 potential threats 222 goal 221 conditions, defined 170 conflict, manage in prioritization 158-162 connections, neglect 171 connectors and arrows, defined 170 consensus conflicts, manage in prioritize 160 consumers, impact 5 best practices on content for 138-139 relevance 135-136 keeping content creators informed 138, use of skeletons by 188 content management systems, review of the content matrix 133-134, application of the numbering system to 173 annotated content source sites 11 includes 16-17 targets for 17 17 using business analysts for 28 using card sorting for 108 content strategist, role 28-29 contextual design, resources for 101 contextual research explained 92 information obtained from 98 process 98-99 using affinity diagrams 99-101 writer , role 29-30 Coroflot website 51 (additional) costs and fees included in applications 50 Tracker capabilities 131 masking detection 132 explained 129 Creative Commons website 50

Dashed line D, representing conditions with 170 decision points, 169 defined Define and Design phases, overlaps 145 outcomes, including proposals 48–49. See also product design goals for branding sites 13 for content feed sites 17 for e-commerce sites 19 for e-learning apps 20 for marketing campaign sites 15-16 setup 10 for social apps 21 for task apps 18-19 layout errors missing numbers pages 173–174 misaligned objects 172 misplaced text 172–173 sloppy connections 171 irregularly placed objects 172 layouts, enhancements 227 developers receive prototypes 217 use of mockups by developers 188 proponents of development vs proponents of business and users 155 communication and follow-up 158 concerns about 154 goals and responsibilities from 157 requirements inheritance 157–158 participation of 158 features from 156 development teams, feedback to 249 digital assets, optimization for 138 digital experiences, designing 5–6 digital prototypes. See also Audience Prototyping for 208 HTML vs. WYSIWYG editors 209-214 resources needed for 209 timelines for 208 wireframe vs. realistic prototyping 207-209 Digital Web Magazine website 167

directory structure, importance of 134 discussion guides, documentation writing for usability testing 239–241, domain planning 162–164 including keywords on 134 input pages, overview 142 points, use of affinity diagrams 161 Dreamweaver CS4, Live View feature 209– 210 content duplication, avoidance of dynamic URLs 138, avoidance in content management systems 133

E-commerce sites, design goals for 19 educational microsites, sample 15 e-learning apps, design goals for 20 Emotion vs. Logic 7 Enabling Team Sections PURITE Process 46, Usability Test Planning 239 Evans, Will 122, 123, 181, 197-201 Experience, Tangible vs. Digital 4-5

F Fahey, Christopher 249 Favreau, Jean Marc 40 Feature Ideas and Visualizations 146–147 Managing Related Conflicts 160–162 Feedback Mechanism, Prototyping 219 Fees and (Additional) Costs Included in Claims 50 Finck, Nick 167 Fireworks CS4 Authoring Tool Prototyping, 215 –216 Flash features, 130–132 Flash and Flash Catalyst Prototyping Tool features, 216 Features Flash content, static embedding 131 Focus group discussion format for 105–106 Explanation 93 interpretation of body language in 106 moderation 107 process 105–107 use in Microfinance example 223 using footer 104-105, layout 196

INDEX

259

footer links, link popularity 140 front-end developers, role 31 financing model, microfinance application 222

G Garrett, Jesse James 168 Global Cruises, homepage design for 195–201 Google analytics tools 24 PageRank system 139 qualitative guidelines for webmasters 142 searches performed 128 grid, use in applications 172 newsgroup format for 105–106 explanation 93 interpretation body language 106 moderation 107 process 105-107 use in microfinance example 223 use 104-105

H Hadden, Jon 217–219 header/navigation, 195 header meta tag design, enabling 137 heuristic analysis benefit for requirements gathering 73 review 70–71 rationale for 71 steps involved in the hierarchy 72–73, impact on company designs 36–37 Hinton, Andrew 177 Hofstede, Geert 36 homepage design 192 design for Global Cruises 195–201 structure design for example 197–200 194 HTML prototype 212 link popularity 140 division of HTML prototype based on code for 213–214 typo checking 210 creating 210–212

260

INDEX

I Ideas, Fusion 82-84 Ideas and Display Functions 145-147 Illustrator Site 167 Image Maps, Use in HTML Prototype 213 Image Tag, Use in HTML Prototype 213 InDesign Site 167 Indexed Pages, Spacing 137-138 Site Indexing 131 Infinite Loops, avoidance in content management systems 133–134 information, search 17 information architects balancing with other roles 248–249 role 22–23, 25 website of the Institute of Information Architecture 51, 167 instructions, ending with usability testing 239–241 interaction designers balancing with other roles 248 –249 23 roles, 25 interviews. See user interviews iStockphoto website 117 PURITE Process iteration section 46 iterations, schematics as an exercise in 201 iterative design, resources for 231 iterative tests, prototyping for 217

J JavaScript, jQuery website issues 214

132-133

K Keynote prototyping tool, 214 key features including sitemaps 175 keyword research tool, accessibility 135 keyword searches, retention of 135 keywords contained within domains 134 naming conventions for 136 use in URL structure 134-135 Knemeyer, Dirk 12

L launched pages, post-launch analysis 254 left navigation links, prototype 217-218 legends, including 175 sitemaps

licensed work, defined 49-50 anchor link meta tag, explanation 137 link popularity distribution 139-140 explanation 139 footer links 140 content links 141 manipulation 143 link spam 143 userlist participants, generation 234-235 Live preview, using in Dreamweaver CS4 209 logic versus emotion 7 logistics, impact on corporate projects 37 logistics usability testing stage 233–239 Lucht, Troy 250

M marketing campaign sites described 11 examples 14 characteristics 14 goals for 15-16 markets, relationship building 26-27 Melzer, James 182 First person to submit case study 115 Website 219 Meta description tag explained 137 Keyword meta tag explained 136- 137 spam with 142 meta tags, accessibility 136–137 methodology, relevance 62 microfinance, defined 222 micropage, defined 15 Microsoft PowerPoint website 167 Microsoft Visio website 167 missing errors page numbering 173–174 misaligned objects 172 misplaced text 172–173 sloppy connections 171 spaced objects at irregular intervals 172 shift focus, follow 64–65 motion, representing 170 MSN, searches performed by 128

N names, delivering to people 118 negotiation, art from 250 network reviews, impact on user adoption 253 Nicolle person, described 115–116 Nielsen, Jakob 71 nofollow link attribute, use 140 noindex meta tag, explanation 137

Or goals apply SWOT analysis to 61-62 fuzzy vs. constants 58-60 importance 57-58 UX designer input 60-62 center 58, 60 correctly connecting objects 171 count meshes between 172 misalignment 172 unequal spacing 172 observations, creating heuristic analysis 72-73 OmniGraffle prototyping tool functions 215 Website 167 Website OpenOffice Draw 167 OptimalSort website 109 overview including proposals 44-45 property and rights including proposals 49 -fifty

Page numbering, no title meta tag for pages 173-174, explanation of PageRank 136, explanation of pages 139-140. See also site cloning 142-143 defined 168 separate indexing 137-138 stack of pages, defined 169 paper and pencil, use for mockups 189-190, 201 "paper culture", understanding 37

INDEX

261

paper prototyping 206–207 example 217–218 HTML as 209 for navigation concepts 218 passive observation, defined paths 99, identification in workflows 180 payment schedule, including in offers 52–53 pencil and paper, use for diagrams 189–190, 201 persons age 118 biography 119 case study 115 defined 113 level of education 120 entry points or triggers for customers 120 searching for information 114 information contained in 116 location for 119 maximizing use 125 level of mobile convenience 121 motivations for using customers, brands, or projects 121 creed 118 profession 119 offline activity 120 online activity 120 summary sheet for 122 face-to-face meeting 120 photos 117–118 justification for 113–114 salary or salary range 120 social comfort level 121 target group for 123 target group for 124 individual target group 124 technical comfort level 121 types 113 user goals 121 photo sources, people sourcing 117 post notes -it, use of affinity diagrams 161 post-release design tests 255. See also tests; Stages of remote usability testing, defined 36 PowerPoint prototyping tools, 214 functions

262

INDEX

PowerPoint website 167 PR (PageRank) explanation 139-140 PURITE process preparation section 45 Pricing, project structuring 51-52 Usability testing prioritization process 244-245 Role balancing 154 Facilitation 150-154 Importance of communication 160 Conflict management during the process flow 158–162, example of results 181–182, success 5. See also results of agile design approach 63–64 relevance 66 include in proposals 45–47 modified 64–65 steps to waterfall 62–63 63 project management, lack of consistency in 160 project management , use of diagrams in 188 project goals application of SWOT analysis to 61–62 unclear vs. solid 58–60 importance 57–58 UX designer input 60–62 measurement 58, 60 project review, including in bids 44–45 project valuation, included in bids 51-52 project requirements, steps involved 69 project sponsor, defined 75 project team, defined 75 project deadlines, 80 project diagram best practices for 191 company history impact on the process 34-35 181-182 elements of the offer acceptance and approval 53- 54 costs and additional fees 50 assumptions 47-48 results 48-49 ownership and rights 49-50 payment schedule 52-53

project approach 45–47 project review 44–45 project valuation 51–52 history of changes 44 scope of work 47 summary of works 54–55 title page 42–43 proposals, meaning 40–41 prototypes affordability 219 calendar tool 219 applications 217, 219 changing mockups for 210 completion 219 creation with WYSIWYG editors 209-214 217-219 examples as a feedback mechanism 219 goals out of 219 for iterative testing 217 getting mockups from developers 217 vs. realistic prototypes 207–209. See also Digital Prototyping Best Practices for 205-206 Overview 205 Paper 206-207 Adobe Acrobat PDF Prototyping Tools 214-215 Axure RP 215 Balsamiq Mockups 216 Fireworks CS4 215-216 Flash and Flash Catalyst 216 Keynote 214 OmniGraffle 215 PowerPoint 214 Visio 215 PURITA Process 45–46

Q qualitative research, application to usability testing 227-229 qualitative usability testing, information gathering for 231-232 quality assurance documents, application of numbering system to 174 alternative quality assurance team out of 250 participating in 249

quality assurance, use of mock-ups for 188 quantitative studies, use of questionnaires 227–229 for usability testing, 241 questions included in discussion guides. See also filters for action planning 162 - 164 for user group compensation 235 - 236 for documentation planning 162 - 164 for focus groups 105 for storyboards 148 for surveys 102 for usability testing 242 for user interviews 97 for user customer satisfaction 233

R Random Name Generator Website 118 recommendations, usability testing 245–246 usability testing recruitment 233–239 redirects, relative path setup 135, use in HTML prototype 213 PURITE process representation section 46 requirements, definition 66 requirements gathering, reduction 74 View also business requirements requirements process, support 74 research, planning usability tests 229–233 research techniques card sorting 93, 107–110 contextual research 92, 98–101 focus groups 93, 104–107 people 121 surveys 92, 101–104 usability tests 93 , 110–111 interviews with users 92, 95–97 resources. See also Affinity Diagram of Site Assets 161 Agile 65 Analytics 254 Body Language 106 Contextual Design 101 Google 128 HTML (HyperText Markup Language) 214

INDEX

263

Resources (continued) Iterative Design 231 Negotiation 250 Prototyping Approaches 217 Social Applications 20 Tools 167 Usability Testing 231 Responsibilities, Description 75-76 Review History, Including in Proposals 44 Balancing Roles in the Prioritization Process 154 Mixing and Changing 156 Governance 248-249

Sample size S, defined 227 scopes of work, including 47 evaluators in applications, using 236-239 in usability tests. See also Questions Scripting, Problems with Search Behavior 132-133, Understanding Search Engines, Evolution of Search Results 129, 135 Beginner's Guide to Search Engine Optimization, Influencing 142 Searches By Month, Stats on 128 Section Headings, enabling 137 Seiden, Josh 113 SEO (search engine optimization) defined 127 UX impact on 134 importance 127-128 resources for 129 SEO methods, white hat versus black hat 141-142 SEO specialists, use of mockups for 188 acceptance and recognition, including proposals 53-54 analyst pages, sitemap tools 24 advanced examples 175–176 blog functionality 166, 191 breaking the pattern 177 defined 166

264

INDEX

omit the numbering structure 173 simple example 174 vs. workflow 166 use 138 use card sorting for 108 use workflows with location type 178, identify 11 locations. See also pages that index 131 writing text in 29-30 template of six, using 190 Sling Thought site 217 social apps outlined 20 design goals for 21 Popular baby names from Social Security Administration 118 Inventory Utility Measuring System (SUMI) 103 SOW (Statement of Work), Space Content 54-55, Usability Test Planning 239 Meta-Keyword Spam 142 Spencer, Donna 17, 109 Spider, Explained 129 Spool, Jared 125 SRA International Inc. Website 182 stakeholders defined 75 meeting 76-77 listening 81 static layers, embedding flash content in 131 sticky points, using affinity diagrams 161 Stock.XCHNG website 117 storyboards, process 147-150 strengths and weaknesses, understanding 61 SUMI (Software Usability Measurement Inventory ) 103 support network, building 32-33 See also UX Design Role Surveys Explained 92 process overview 101 of 102-104 compared to user interviews 102

SWF object, using 131 lanes, SWOT analysis example 182-184, related to project objectives 61-62

T tags. See user-targeted meta tags describing 113. See also user workflows that apply the numbering system to 173 create 178 examples 178-180 overview 166 process flow 181-182 compared to sitemaps 166 lanes 182-184 use with sitemaps 178 tasks - application sites described 11 functions and goals for 18-19 year olds using business analysts for 28 Tatum, Keith 217-218 Taylor, Dave 214 usability testing 239 test materials, writing usability tests 241 PURITE process testing section 46 testing, usability and acceptance user 226 See also post-run project tests; stages of usability testing text completion for usability testing 239–241 getting lost 172–173 writing on pages 29–30 title page, including suggestions 42–43 title tag, use in HTML prototype 213 tools, accessibility 167–168

U UAT (User Acceptance Testing), Objective 226 Understanding the PURITE Process, Section 45

Avoiding URL Paths in Content Management Systems 133 Avoiding URL Structures in Content Management Systems 134 Using Keywords in Usability Testing 134-135 Choosing an Explanation Approach 227-228 93 Reviewing 110-111 Usability Test Steps 236-239. See also post-launch design tests; analysis of tests and presentation of results 243–245 choice of approach 227–228 creation of recommendations 245–246 evaluation 250 facilitation 242–243 research planning 229–233 recruitment and logistics 233–239 writing discussion guides 239–241 Usability.gov 240 user adoption impact on network 253 feedback impact 251–252 personal benefit 252 providing support 252 user advocacy role taking 150–151 network building 32–33 versus business and development advocacy 155 concerns 154 user attributes comparison 90 prioritizing and defining user 89–91 behavior by gaining context for 227 user experience (UX). View User Groups Definition UX (User Experience) 87 Attribute List 87-89 UI Engineering Site 125 User Interviews Explained 92 Interview Tips 97 Process 95-96 Surveys 102

INDEX

265

user models, design from 91 user research 93–94 full 111 planning 94 steps to perform 86 techniques 92 planning user research, development 229–233 user researcher, function 23–25 determining user satisfaction 233 measurement tools 103 categorizing user comments in usability testing 245 success assessment of 233 users, determination of 232-233 users. See also target users choosing number for usability testing 229 identifying types 88-89 use of mock-ups by 188 UX (user experience) digital aspects 6 SEO impact 134 UX design, 3 UX design roles defined. See also strategist/brand manager of the support network 26–27 business analyst 27–28 selection 31 content strategist 28–29 copywriter 29–30 front-end developer 31 information architect 22–23 interaction designer 23 responsibilities 25 user researcher 23–24 visual designer 30 –31 UX designers balance other roles 248–249 empathy 156 contribution to project goals 60–62 organizations out of 7–8 role in prioritization 151 traits 6–7

Validation V, Early Search 191 Value Propositions, Presentation 15

266

INDEX

The Visio prototyping tool includes 215 the Visio site 167 a team of visual designers providing feedback to 249 visual designers involved in the creation of wireframes 203 30-31 use of wireframes in 188 visual projects. See also concept mining using a numbering system 174 wireframes 224 wireframes 200-201 Visual vocabulary definitions terms 170 connectors and arrows 170 decision point 169 pages 168-169 page stack 169 visualization and idea functions 145-147 vocabulary, commercial sharing 80-81

In WAMMI (Website Analysis and Inventory Measurements) 103 Warfel, Todd Zaki 115, 124, 217, 219 modified waterfall approach 65 phases 63 webmasters, quality guidelines for 142 webmasters/help for website owners 129 Web Site Analysis and Measurement Inventory (WAMMI) 103 Website Resources 28. See also ACSI (American Customer Satisfaction Index) Resources 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent Talent Agency 51 Ascend Reality Solutions 250 Axure RP Pro 167 Babyhold 118 BabyNames 118 Behavior 249

Blue Flavor 167 CSS Scheme 167 "Brand Experience & Web" 12 Brooks, Mark 201 Card Ranking Spreadsheet 109-110 Coroflot 51 Creative Commons 50 Digital Online Warehouse 167 Entry Pages 142 Evans, Will 181 Google Code for Searching Static Content 131 Hadden , Jon 219 Heuristic Analysis 71 HTML Prototyping 214 Illustrator 167 Image Maps 213–214 InDesign 167 Information Architecture Institute 51, 167 Information Search 17 jQuery 214 Keyword Research Tool 135 Marketing Campaign Pages 16 Messagefist 219 Microsoft PowerPoint 167 Microsoft Visio 167 Names for People 118 OmniGraffle 167 OpenOffice Draw 167 OptimalSort 109 People Types 113 Photo Assets 117 PowerPoint 167 Random Name Generator 118 Search Engine Optimization Beginner's Guide 129 SEO (Search Engine Optimization) 143 Slingthought 217 Social Security Administration Common Baby Names 118 SRA International Inc. 182 SUMI (Software Measurement Inventory) ) ) 103 Tools 167 Usability Test Scripts 240 Usability.gov 240

UI Engineering 125 User Satisfaction Measurement Tools 103 UX Design Approaches 24 UX Organizations 8 UX Research 95 Visio 167 WAMMI (Website Analysis and Measurement Inventory) 103 Webmaster/Website Owner Help 129 WebSort 109 WebTrends 24 Yahoo! Interface Library Site 214 WebSort Site 109 WebTrends Site 24 White Hat vs. Black Hat 141–142 Whiteboards, Storyboards 149 Wireframes and Annotations 186–187, 193–194, 201 Applying a Numbering System to 173 Approaches to 201 Prototyping 210 Comparing and Contrasting 200 Creating 189, 198–199 Design for the home Page 197–200 As an exercise in iterations 201 Get customer feedback on 192–193 Summary 186–187 Present 202–203 vs. realistic prototypes 207–209 of 192–193, 201 as a “thinking device” , 198 tools for 189–190 users 188 visual design 200–201 contract work, defined workflow 49, storyboards 149 worksheets, development for business needs 153 WYSIWYG editors, prototyping with 209–214

And Yahoo, searches by 128 Yahoo! 214 interface library site

INDEX

267

Get free online access to this book for 45 days! And get access to thousands more by signing up for a free trial of Safari Books Online! By purchasing this book, you get instant access online and searchable for 45 days on Safari Books Online! And while you're there, be sure to check out the Safari Books Online digital on-demand library and its free trial offer (separate registration process). Safari Books Online subscribers have access to thousands of technical, creative and business books, how-to videos and articles from the world's leading publishers.

Just visit www.peachpit.com/safarienabled and enter the code FJGSLZG to try it out today.

UX Design Guide - PDF Free Download (2023)

References