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

UX GUIDE PROJECT FOR

THE PLAN

FOR USER EXPERIENCE DESIGNERS IN THE FIELD OR IN MANUFACTURING

RUSS UNGER E CAROLYN CHANDLER

PEACH PRESS

A Design Guide to UX Design: For User Experience Designers in the Field or on the Factory Floor Russ Unger and Carolyn Chandler

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

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

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

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

Praise for a UX Design Project Guide If Russ Unger and Carolyn Chandler were magicians, the Alliance would be after them for leaking their best kept secrets. Fortunately this is not the case. Russ and Carolyn have taken wisdom previously known only to the most seasoned UX project leaders and coded it for all to see. Now you can learn the secrets needed to run great UX projects. Jared M. Spool, CEO and Founding Director of User Interface Engineering;

Is there a book that can tell you everything you need to know about user experience design? NO. Is there a book that moved you the most? It exists now. Carolyn and Russ have laid a solid foundation for project planning and management. This is an essential guide for anyone dealing with competitive methodologies, endless meetings, and all the important aspects of user experience design. Dan Brown, author of Communicating Design

This book is a fantastic introduction to creating great products for real people. But it encompasses much more than just design - it encompasses everything design-related: managing projects, collaborating with people, and communicating ideas. A great handyman. Donna Spencer, author of Card Sorting: Designing Usable Category

This is a practical, accessible, and very human guide to a very human activity: collaborating with humans to create great things for other humans. Steve Portugal, Portugal Consulting

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

iii

Acknowledgments Russ Unger Without the support of my family, friends, colleagues, and many people who were complete strangers to me before I pressed the first keys, this book would never have been completed. My beautiful wife Nicolle, who deliberately and knowingly married a nerd with an over-the-top bug, managed to be a double mom while she was writing this book. Our daughters Sydney and Avery used to nudge their nearly comatose father and urge him to live so he could dance and sing and play Spore. It occurred to me that writing a book at home with a newborn wouldn't be much of a challenge. I quickly learned otherwise. And Nicolle kept reaching out to save me and give me the focus I needed to complete this project. He is the hero I trust the most. He keeps our house in order in the midst of chaos. He's the center of our world here and he's letting all of us get away 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 with less than I have to give. Carolyn kept me posted. There were times when it felt like this project would never start or end. He always kept things moving, exploring ideas and pointing us in the right direction. The cooperation was great and I learned a lot! It's definitely a great yin UX for my yang UX. Michael Nolan was our acquisitions editor and the perfect guide. Michael is honest and friendly and really helped to make everything go smoothly. Rebecca Freed was the juggernaut who handled all aspects of the book, kept us informed, and frequently emailed us late into the night. Unfortunately, he often got responses from me almost immediately! Linda Laflamme was the developmental editor, and once I got used to her Red Pen of Doom, it was clear that no matter how hard I tried to drown her in unfinished thoughts and careful sentences, she was leading me in the right direction. Leslie Tilley added the finishing touches to the words. Tracey Croom joined production, layout and graphics. and a real book came out. Steve "Doc" Baty read every chapter before it was born in the Peachpit offices. Many times I would send chapters to Steve around 2 am, and he

THANKS

He would submit his comments at 5 am, which is no small feat. However, Steve is in Australia, but he is still impressive. Without Steve's constant help and quick responses, it's hard to believe this book would have made it to the bookshelf. Brad Simpson (www.i-radiate.com) took all the graphics I threw at him and turned them into beautiful print-ready images, often while juggling life with two teenage children and a busy work schedule. It would have been easy to leave Brad 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 will be enough steak dinners to make the effort worth it, but I'm going to work hard to get there. Thank you Brad for sacrificing so many of your days and nights off to support this. Mark Brooks sometimes found me in a state of panic trying to convey messages that required a visual element that was beyond my time and/or skill. Mark stepped in more than once and saved the day and I have him to thank for that. Mark is talented and true to one thing - he's the kind of person I want to be. Jonathan Ashton wrote the entire chapter on search engine optimization for us. After talking with Jonathan for five minutes, I knew he was the right person for the job. Your chapter alone is a good reason to buy this book and it was great to have you on board. Jono Kane stepped in at the last minute and instantly. Jono is a web developer, interaction designer, and prototyping at Yahoo and was invaluable in his support and help with the writing of Chapter 12. Lou Rosenfeld really helped get this rolling. In addition to being the author of the acclaimed "Polar Bear Book" (O'Reilly's information architecture for the World Wide Web), Lou is bright, friendly, approachable and always willing to help others in our fields. Hardly anyone is as generous as Lou. Christina Wodtke helped me socialize and socialize. Without Christina I wouldn't know where we would be today, but I probably wouldn't be "in press". Not only is he a must-read author, but someone who has always been there to offer advice and help. Many in the field of UX design owe much of their knowledge to Christina's tireless efforts to broaden our horizons through constant innovation. THANKS

Will Evans and Todd Zaki Warfel have generously provided high quality results for you to use as templates for your own results. They were true brothers and gave of their time and talents without question or concern, often on the spur of the moment. They are great members of our UX community - people you want to meet and work with - and I'm lucky to be friends with them. There is no way to do justice to the gratitude I owe these two. David Armano, Chris Miller, Kurt Karlenzig, Livia Labate, Matthew Milan, Michael Leis, Mario Bourque, Troy Lucht, Ross Kimbarovsky (and the crowdSPRING gang) and Wil Wheaton have served me well as good friends and true and loyal supporters. I'm lucky enough to be able to compile these names as a list of people I know and I'm a huge fan of everything they do. Your support has been an invaluable asset to me in everything I do. These amazing people did their best to help me by providing facts, anecdotes, and access to their resources, and I thank them from the bottom of my heart: Tonia M. Bartz (www.toniambartz.com), Chapter 7; Steve "Doc" Baty, (www.meld.com.au), Chapters 3, 11, 14 and "A Brief Guide to Meetings"; Mark Brooks (www.markpbrooks.com), chapters 3 and 11; Leah Buley (www.adaptivepath.com), chapter 11; Dave Carlson (www.deech.com), chapter 11; Will Evans (www.semanticfoundry.com), chapters 7, 10, and 11; Christopher Fahey (www.behaviordesign.com), Chapter 14? Nick Finck (www.nicknck.com), chapter 10; Jesse James Garrett (www.adaptivepath.com), Chapter 10; Austin Govella (www.grafofini.com), chapter 11; Jon Hadden (www.jonhadden.com), chapter 12; Whitney Hess (www.whitneyhess.com), Chapter 11; Andrew Hinton (www.inkblurt.com), Chapter 10; Gabby Hon (www.staywiththegroup.com), chapters 3 and 11. Kaleem Khan (www.uxjournal.com), "A Brief Guide to Meetings"; Ross Kimbarovsky (www.crowdspring.com), Chapter 14; Livia Labate (www.livlab.com), Chapter 7. Michael Leis (www.michaelleis.com), Chapter 11; Troy Lucht (www.ascendrealtysolutions.com), Chapter 14; James Melzer (www.jamesmelzer.com), Chapter 10; Matthew Milan (www.normativethinking.com), chapter 7; Chris Miller (www.hundredfathom.com/blog), “A Brief Guide to Meetings,” Maciej Piwowarczyk (www.linkedin.com/pub/3/a74/a66), chapter 11; Stephanie Sansoucie (www.linkedin.com/in/smsansoucie), chapter 11; Kit Seeborg (www.seeborg.com), chapters 3, 11 and "A Brief Guide to Meetings"; Josh Seiden (www.joshuaseiden.com), Chapter 7. Jonathan Snook (www.snook.ca), Chapter 12; Joe Sokohl (www.sokohl.com), Chapter 12 and "A Quick Guide to Meetings"; Samantha Soma (www.sisoma.com), “A brief guide to

THANKS

Find"; 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 I'll miss someone, and I hope it doesn't get taken personally. lots of people in the “crowd” coming and I've been trying to keep up with everyone. If I missed you, let me know and I'll make it right! In conclusion, it's important to note that without organizations like the Information Architecture Institute, the Interaction Design Association, and others , it would have been impossible for me to establish contact with many of the individuals named. If you are curious about the field of UX design, explore these organizations, join and get involved!

Carolyn Chandler Many of us have dreamed of writing a book at some point in our lives. I don't know if without Russ I would have had the motivation to go in and do this. Their energy and enthusiasm helped us find the right people at the right time, from the Peachpit team to UX industry executives, all of whom have had a huge impact on what you see in these pages. He truly is one of the great enablers in our field and loves to bring people together day and night. Also, I think she tweets more in a day than I have since I got on Twitter! Russ thanked many people who helped us tremendously. I won't repeat all those names, except for Steve Baty, who read all of our chapters in every draft we got and managed to sound enthusiastic at 2am (his time). John Geletka also provided thoughtful feedback and interesting discussions with a spark and perspective that spanned many disciplines. And of course the Peachpit team. I will never forget to return my first Linda Laflamme chapter. It wasn't pretty (although he delivered the sentences very nicely). you patient

THANKS

vii

He guided me through edits and helped me improve my workflow, which initially was better suited to writing single white papers than writing an entire book. Now I even add transitions to my casual conversations with co-workers! Speaking of which... Christine Mortensen, aka Morty, was my visual partner. The icons and graphics you see in my chapters are the result of her hard work—and I know how hard it was because she and I were working on many of the same client projects simultaneously while trying to meet chapter deadlines. Morty is one of those visual designers who has a strong foundation in both visual design and interaction design, and she enjoys collaborating with everyone on the project and bringing concepts to life. Her integrity and focus on quality make her a pleasure to work with and an honor to partner with. Thanks also to everyone at Manifest Digital who have been so supportive over the last few months. Jim Jacoby brought a special combination of business knowledge and UX perspective, with his typical zen calm that helped me through some stressful moments. Jason Ulaszek is one of the most enthusiastic people I know in UX and has an endless knowledge of tools and techniques. No idea where he makes room for all this! Additionally, Brett Gilbert and Jen O'Brien provided valuable insight into some of their many roles working with UX designers. I'd also like to thank the Manifest UX team members who inspired me and were so patient with my progress reports in the "book": Brian Henkel, Chris Ina, Haley Ebeling, Jenn Berzansky, Meredith Payne, and Santiago Ruiz. Working with you is always a pleasure. Every day I appreciate your humor and insight. Thanks to my colleagues at the Interaction Design Association for sharing their experiences and being active members of the UX community, which I love. In particular, I would like to thank Janna Hicks DeVylder and Nick Iozzo, who have been instrumental in growing the Chicago chapter and continue to find new ways to build a vibrant network of bright people. Finally, I would like to thank my family, friends, and Anthony, who patiently endured my disappearance and continued to check that I was alive. You have a lot of rain checks to cash and I can't wait to go over them with you!

viii

THANKS

Contents INTRODUCTION

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

CHAPTER 1: The

Tao by UXD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What is User Experience Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The general definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Don't forget the tangible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Our focus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

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

project ecosystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Determine the location type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brand Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Marketing Campaign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Content Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Task-Based Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 E-Commerce Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 E-Learning Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 social networking apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Choose your hats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Information Architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Interaction Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 User Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Other roles you may have or need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Creating a User Advocacy Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

Pulling together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CHAPTER 3: Suggestions

for consultants and freelancers. . . . . . . . . . . . . . . . . . 39 suggestions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Origin of the phrase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CONTENT

page title. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Project Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Scope of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 achievements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Ownership and rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Additional costs and fees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 project awards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Payment Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Identification and Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Performance Declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 CHAPTER 4: Project

Goals and Approach. . . . . . . . . . . . . . . . . . . . . . . . . . 56 Consolidation of project objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

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

Understand the project approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 waterfall approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Agile Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Modified Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 How will the approach affect me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 CHAPTER 5: Business

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

Gather ideas from stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Description of Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Gather the right stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Make a meeting plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Sales: Collection meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Conduct meetings effectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Fusion Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

CONTENT

CHAPTER 6: Users

To look for. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Basic User Research Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Define your user groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating a resource list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Prioritize and Define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Selection of research techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 How many research activities can I include? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 User Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Contextual Examination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 investigations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 focus groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Sorting Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

After the poll. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 CHAPTER 7: Personas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 What are personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Why Create Personas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Finding information about personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Creating Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Minimum Content Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Optional Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Advanced Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 final thoughts on personas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 CHAPTER 8: Users

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

Website technology, design and infrastructure. . . . . . . . . . . . . . . . . . . . . 129 Flash, Ajax, JavaScript, and other scripted content . . . . . . . . . . . . . . . . . . . . . . 130 Content Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Domains, directory and URL structure are important. . . . . . . . . . . . . . . . . . . . . . . . 134

Contents: The former (and current) and future king. . . . . . . . . . . . . . . 135 Naming conventions and the fight against jargon. . . . . . . . . . . . . . . . . . . . . 136 metadata, headers and keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

CONTENT

Part the hair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 use location maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Keep content fresh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Other content issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Link popularity explained. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Normal Distribution of Link Popularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 footer links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Interfaces within content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141

Play the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 White Hat versus Black Hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Meta keyword spamming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Cloning and landing pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Link spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

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

From definition to design. . . . . . . . . . . . . . . . . . . . 144 Designing and viewing functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

The basic storyboarding process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Facilitate the prioritization process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Maintain good tension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 The Defender of Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 conflict management in prioritization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

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

Maps and workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 What is a sitemap? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 What is workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Hand Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 sitemap fundamentals and workflows. . . . . . . . . . . . . . . . . . . . . 168 page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 stacks of pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 decision point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Links and Arrows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Common mistakes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Confusing Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

xii

CONTENT

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

Advanced sitemaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Breaking the sitemap trend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 taking workflows to the next level. . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 Swimming lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 CHAPTER 11: Wire Structures

and notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 What is a wireframe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 What are annotations?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Who uses wireframes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Create wireframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 tools of the craft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Start simple: create a simple wireframe. . . . . . . . . . . . . . . . . . . . . . . . . .191 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 The wireframes and annotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

An exercise: create a wireframe homepage. . . . . . . . . . . . . . . . . . . 195 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The results: Design a wireframe homepage. . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Visual Design: When wireframes grow and find their way into the world. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Project follow-up exercise: which project is correct? . . . . . . . . . . . . . . . . . . . . . . 201

One final note about presenting wireframes. . . . . . . . . . . . . . . . . . . . . . . . . 202 CHAPTER 12: Standardization.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 What is prototyping? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How much original do I need? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 original paper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Digital Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Wireframe vs. Realistic prototypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 HTML vs. WYSIWYG editors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Additional tools for prototyping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

CONTENT

xiii

Partner with a developer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

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

Test with users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 exploration of the concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 tips for exploring visual design mockups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

usability tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Zoom Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Research Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Recruitment and logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Write discussion guides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Moderation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Analysis and presentation of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . form 243 sentences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 CHAPTER 14: Transition:

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

Post-launch activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Post-launch review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Post-launch design testing with users (again) . . . . . . . . . . . . . . . . . . . . . 255

It's all done, isn't it? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Like a New Beginning... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 CONTENTS

xiv

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

CONTENT

Introduction Why We Wrote This Book Welcome to the UX Design Project Guide. Somewhere there's a user experience design student who's been sleepless because he doesn't know what it's going to be like to work on a real project at his new company. On the other side of town, there's a visual designer with a lot of project experience who's eager to take on new responsibilities in her website's user experience design. They are two people at different times in their lives, but with a similar need: understanding how to integrate user experience practices in the context of a live project. Our goal with this book is to provide you with the basic tools and framework that will support you in using UX tools and techniques in workgroups. As you'll see in many of these chapters, our goal is not to provide everything for everyone, but to provide you with the background information and knowledge you need to accomplish many of your tasks. I'm hired as a UX designer. . In addition to our own examples, we provide examples to help you find ways to start with the basic materials and allow you to combine the information and create something new, better, or even more appropriate for your own purposes. We hope we expressed it well that this is a very good approach to UX design projects. We are nothing if we don't constantly try to learn and improve (whatever we do) with each iteration. That's why we're kind of active in that area. A Word from Russ As a mentor for the Information Architecture Institute (www.iainstitute.org), I've noticed a pattern in the people I've worked with: most have had trouble finding a job or haven't lived up to their future employer expectations. Some have had good training but not always enough hands-on application of UX design skills in a project-based environment. The same themes echoed in many of the conversations I had at the 2008 Information Architecture Summit (www.iasummit.org).

INTRODUCTION

The idea for this book, which addresses many of these common issues, took shape. I don't remember whether Carolyn or I sent the first email, but I do know that in her I found a willing and capable co-author who helped me realize the idea that eventually spawned this book. A Word from Carolyn For many years, I've been fortunate enough to build and lead UX teams. I say “luck” because I think UX designers in general have a balanced mix of traits that are fun to work with, combining right-brain intuition and left-brain logic. While conducting interviews to assemble these teams, one thing really stuck in my mind: having a relevant educational background like human factors or communication design is a good indicator that someone is committed to the field of UX design, but he is not. is the most important indicator Indicator of whether someone would be a good fit on the team or on a project. Equally important, if not more so, is the ability to adopt a consultant's mindset. That means a positive attitude, a drive to understand and involve others in a project, and most importantly, a focus on making a real impact on users and customers. This mindset means taking the time to understand the perspectives of other roles on the project, making assumptions and making concessions where necessary. It takes experience and effort to become very good at this mindset, but with an open mind, a solid foundation, and a good set of questions (and the courage to ask them), you can go a long way. This book may not give you all the "answers", but it will give you the questions you need to ask so you can find them more easily.

Who should read this book? A UX design project guide provides a comprehensive and introductory overview of UX design in the context of a project. Anyone interested in UX design should find something useful here. In particular, we focus on the following groups: Students taking UX design courses (e.g., Human-Computer Interaction or Interaction Design) who want to supplement their courses with information on how to apply their learning in real-world situations where communication applies and collaboration are key.

XVI

INTRODUCTION

Professionals who want to deepen their knowledge of basic UX design tools and techniques and improve team communication about the roles involved. Chapter 3 is particularly aimed at freelancers who have to create their own proposals. UX design team leaders are looking for a book that will help their teams incorporate design best practices into their UX design activities. Project team leaders interested in learning more about how UX design is incorporated into their projects, its value, and what to expect from UX designers. IF YOU HAVE TO...

THEN YOU NEED TO READ…

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

Chapter 1: The Tao of UXD

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

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

Start right with effective meetings, clear goals, and well-understood points of approval

E-Chapter: A brief guide to meetings. Chapter 4: Project Goals and Approach

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

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

Learn about your users and represent their needs throughout the project

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

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

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

Make sure your site is easily found and searchable by users and search engines

Chapter 8: User Experience Design and Search Engine Optimization

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

Chapter 14: Transition: From Design to Development and Beyond

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

INTRODUCTION

xvii

Note on methodology There are a variety of approaches and methods. We are not advocating one approach over another. Our goal for this book is to focus on the steps common to most projects: defining the project requirements, designing the experience, and developing and deploying the solution. The degree of overlap between these steps varies greatly depending on the design approach you are using (see Chapter 4 for more details). For the most part, our framework is a loose, linear approach that puts the definition step first, but at each step we use facilitation and design techniques where they are most useful.

This book is not an encyclopedia of all techniques. There are a huge number of creative people in the UX space who are constantly trying new approaches to design problems. Incorporating all of these approaches would result in a much longer book—and one that would quickly become obsolete. What we've included here are the most commonly used techniques, the be-all and end-all of UX design. We've tried to provide enough information to engage you and give you the opportunity to share the activities with other project members - including the basic process for each technique and additional references to books or websites to help you implement it once you've decided on it. your way. A guide to becoming a project manager. Good project management (including setting and tracking goals, schedules and budgets) is the key to success for any project. We don't go into detail about how to become a project manager or how to choose a specific project methodology. We discussed the skills a UX designer brings to a project that allow it to function effectively, such as facilitation and communication, as well as the ability to clarify and focus on project goals. These skills will help you become a partner in project management. The only or perfect process or methodology to follow. We don't have all the answers - today nobody has an answer. The field of UX design is relatively new and we are all working to improve. You will likely encounter trial and error, tweaks and improvements, and feedback.

xviii

INTRODUCTION

from others will help you customize a process to meet your needs. If you find something that works for you, please share! Inform us!

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

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

Snorkeling Snorkeling is a longer online article, white paper, or short book that takes anywhere from an hour to a weekend to read.

Deep Dives The so-called Diving Helmet are longer books that will likely take more than a weekend to read. They provide in-depth coverage of the topic.

INTRODUCTION

xix

This page was internationally left in blank

The Tao of UXD Curiosity meets passion and empathy. The important thing is to never stop questioning. Curiosity has its own reason for being. He can only marvel as he contemplates the mysteries of eternity, life, and the wondrous fabric of reality. Just try to understand a little of this mystery every day. albert einstein

The sense of curiosity is nature's original method of education. Smiley Blanton

Passion and determination go hand in hand. When you discover your purpose, you usually find that it's something you're incredibly passionate about. Steve Pavlina

The great gift of man is that we have the power of empathy. Meryl Streep

Very simple: this chapter is for you - and for others interested in the field of user experience design (or UX design for short).

If you are reading this sentence, you are a strange person. You want to know how things work - from door handles to planes and something on the back of your neck. Above all, you want to know what makes people special. You don't see things in black and white. There are many shades of gray to discover! Sure, you can drive those around you a little crazy sometimes by always agreeing to play devil's advocate, but you can't help but look at the other side of the coin. Happy! The field of user experience design attracts curious people who are familiar with many shades of gray. We look for patterns and live by organization and structure. We connect the dots. We're always looking for the next piece of the puzzle, and when the puzzle is solved, we look for ways to make it better! We can be analogue or digital. We're at home with pencil and paper, whiteboards and whiteboard markers, sticky notes and Sharpie pens. We talk in terms of Visio and "Graffle" and we live in a world of boxes and arrows attached to our various computer screens. We are not just curious. We are passionate! It is important for us to exchange ideas and facilitate discussions. We are passionate about creating things that make a difference for those who use them - and for those who create them. Surprisingly, we get a lot of pride when something we create is so good that people don't even notice how good it is! And of course we have empathy. We can feel it deep within our being when we face a bad experience. Even worse, we immediately try to find solutions to 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 put up with the confusion and sense of inadequacy that often accompany a bad experience. two

CHAPTER 1: THE TAO OF UXD

When you combine that near-constant, childlike curiosity with an unrivaled passion for "doing what we do" and a talent for knowing how others think, you create a vibrant community of professionals who are comfortable speaking their minds, asking questions , to share solutions. and being wrong - all in the name of justification. Welcome to the UX design community.

What is User Experience Design? There are many definitions of user experience design. After all, it is an area that thrives on defining things. It's true that sometimes we're not very good at defining "the damn thing" when it comes to the different parts of the whole, but at least we know what the whole is. In this book, we focus on two definitions in particular: the broader sense of the term UX design and the definition we will use in the context of this book.

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

These elements include things a user can touch (for example, tangible products and packaging), hear (promotional messages and audio signatures), and even smell (the smell of freshly baked bread in a sandwich shop). This includes things users can interact with beyond the physical, such as digital interfaces (websites and mobile apps) and, of course, people (customer service representatives, vendors, friends and family). One of the most exciting developments in recent years has been the ability to merge the elements that affect 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 boundaries.

What was the user experience design?

Don't forget the tangible. While we focus on the digital aspects of the user experience, these types of interactions don't happen in a vacuum. When designing your digital products, consider the impact of the tangible experience. The environment your users work in is important, as are the physical products (monitors, keyboards, and other input devices) that affect how your users interact with your design. Chapter 6 provides techniques to help you understand the implications of context. Also, don't forget the other touchpoints that a product or company has with those who interact with it. Because a company's brand is influenced by many things, and the brand experience doesn't end at the computer or mobile screen. The best website design cannot make up for a reputation for poor customer service or the satisfaction of well-designed packaging when a product is delivered.

Figure 1.1 A modern classroom experience combines analog and digital.

CHAPTER 1: THE TAO OF UXD

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

Figure 1.2 Online reviews are an important influencer for consumers.

Our focus As you can see, the scope of UX design is large and growing. For the purposes of this book, we will focus on projects that focus on creating digital experiences – particularly in interactive media such as websites and software applications. To be successful, the design of the user experience for these products must consider the business objectives of the project, the needs of the users of the product, and any constraints that affect the feasibility of the product's functionality (for example, technical constraints or budget constraints of the product). project). etc. ). window of opportunity).

What was the user experience design?

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

a doorknob

Package for one pair of shoes

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

Tangible SMS mobile functions

customer service call

Atom

social

Our focus: Read product reviews online. Search the online archive. Watch targeted ads

Digital customer service live chat

About UX Designers While curiosity, passion, and empathy are traits that UX designers share, there is also a desire to strike a balance. We're looking for a balance, mostly between logic and emotions, like Spock and Kirk or Data and Data in the episode where his emotion chip overloaded his positron relays. you have the idea To create truly memorable and satisfying experiences, a UX designer must understand how to create a logical and sustainable structure for the experience and understand the elements that are important to create an emotional connection with the users of the product. The exact balance may vary depending on the product. An advertising campaign for a children's toy will register differently than an application that tracks patient information in a hospital. A product that is developed without understanding the need for both is likely to miss an opportunity for a truly memorable experience - and the resulting benefits for the company behind the product. Note For more information on emotional design, see the book Emotional Design: Why We Love (or Hate) Everyday Things by Donald Norman (Basic Books, 2005).

CHAPTER 1: THE TAO OF UXD

Achieving this balance requires greater empathy: the ability to delve into the world of potential product users to understand their needs and motivations. User experience designers conduct investigations to arrive at this understanding (see Chapter 6) and create tools like personas (see Chapter 7) to help the rest of the project team focus their efforts. Remember, emotions are just part of the bigger picture. Use the logical side to step back from the edge and focus on the task at hand. In most cases, you will work with a budget based on the time and materials needed to complete the project. You must understand that sometimes you need to fish or cut the bait.

Where UX Designers Live You are not alone. Look around and you will find many organizations and communities that can support your development as a user experience designer. Many of these organizations not only offer email lists, online resources, and a whole host of really smart people, but they also sponsor events or conferences that can help broaden your horizons while narrowing your professional focus. Some companies host educational events such as User Interface Engineering's Web App Summit and User Interface Conference, Adaptive Path's UX Intensive, and Nielsen Norman Group's Usability Week. There are also a growing number of “non-conferences” in various cities. These are created by a group of motivated individuals, independent of any particular company or association.

WHERE UX DESIGNS LIVE

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

A selection of UX organizations

ORGANIZATION

WEB SITE

Large conference (usually held)

Interaction Design Association (IxDA)

www.ixda.org

Interaction (early February)

Information Architecture Institute (IAI)

www.iainstitute.org

IDEA Conference (September/October)

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

www.asis.org

AI Summit (March)

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

www.sigchi.org

CHI (early April)

The Convenience Professionals Association

www.usabilityprofessionals.org

UPA (June)

Let's begin! You've made it this far. It's time to understand why you picked up this book in the first place. Turn the page and dive into how user experience design works in the project space. But don't stop there - this book is a guide to help you get started. It contains many examples that can help you accomplish many of the tasks you will be asked to do. We've also tried to provide additional examples to help you find your best approach to creating products that are useful for your team and customers. Keep your curiosity, passion and empathy alive! Challenge yourself to find new ways to inspire others to create the ideal user experience. That is of course before you start to improve.

CHAPTER 1: THE TAO OF UXD

Project ecosystem planning for project requirements, roles, and culture Ready to launch a new project? Or are you in the middle of one right now? Either way, take some time to think about the dynamics and context of the project – the issues that will affect you and the rest of the project team. What kind of websites or apps are they? What roles and skills are required? How is the corporate culture? Answering these questions will help you define the project and ultimately identify the tools and skills needed to succeed. Carolyn Chandler

Each project has its own unique challenges. When designing websites or apps, many of these challenges involve specific features and functionality, such as: For example, creating a way for the user to share photos with friends and family on the Internet, or restructuring information on an intranet to make content easier to find, find and share. However, around these specific design goals, all projects have a larger context that you need to understand and factor into your planning. This context is the project's "ecosystem" and includes the environment you will be working in (the company culture), the general type of work everyone will be doing (for example, the type of website you will be creating), and the people you will work with. will interact (including their roles and responsibilities). If you take the time to understand the project ecosystem, you will gain insights that will help you throughout the project. You can communicate your responsibilities and ideas more effectively and help other team members identify project needs they may not have considered. To help you, this chapter identifies different types of projects you can work on, the roles you can play, the people you can rely on, and how their involvement depends on the type of site or application you are involved with. vary. it is planned. Finally, the chapter discusses some elements of corporate culture that can affect how you work during the project. Note Depending on how the client company structures its projects, a given project may involve the design of more than one location or application. For simplicity, this book assumes that a project involves designing only one type of site. If you have more than one site, review each one individually to ensure the project team has the correct roles.

Identify Your Type of Site While there are no distinctions between one type of site and another, some relative differences in focus and site characteristics can be identified. Once you understand these similarities and differences, you can set design goals for yourself. These are the general questions that should be present

to solve (e.g. “Explain the company's business model”) or the characteristics to be presented in the visual and interactive design of the website (e.g. “Demonstrate the company's responsiveness to its customers”).

CHAPTER 2: THE PROJECT ECOSYSTEM

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

Participate in business needs gathering (see Chapter 5). Determine best practices for incorporating user research (see Chapter 6). Ask questions about systems and technologies that may be involved.

Your site will likely have a lot of links to one of four types:

Brand presence – ubiquitous online platform that facilitates the company's relationship with the general public (anyone interested in its products or services). Marketing Campaign - A targeted website or application designed to elicit a specific, measurable response from a specific audience from a general audience for a limited time. Content Source - A repository of information that can consist of various types of media (articles, documents, videos, photos, tutorials) exists and is designed to inform, engage or entertain users. Application Task Based - A tool or collection of tools designed to allow users to perform a basic set of tasks or workflows

In the following sections, we'll take a closer look at each of these types, discussing their characteristics and the impact they have on your website or app's design challenges. We'll also discuss the most common cross-projects - e-commerce, e-learning and social - that have characteristics of more than one type.

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

DETERMINE THE TYPE OF WEBSITE

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

For more information on the differences between a company's branded customer experience and a company's efforts to build its brand, see Dirk Knemeyer's explanation of "Brand Experience and the Web": www.digital-web .com/articles/brand_experience_and_the_web . For a great discussion of how a website's UX design can impact a person's brand experience, check out Steve Baty's article “Brand Experience in User Experience Design”: www.uxmatters.com/MT/archives/ 000111.php.

A company can do a lot to influence the associations associated with its brand, from executing memorable advertising campaigns to expressing brand attributes (such as "responsiveness" or "value") through brand features and design. your websites. All of a company's websites are likely to have some impact on the company's brand, either directly (by presenting a website for customers to visit) or indirectly (by providing an important service that customers rely on, such as customer support). However, brand presence sites focus more on presenting the company's brand messages and values. They provide channels that connect directly with customers and serve as a broad online funnel for anyone wanting to learn more about the company or what it offers. A brand presence site is usually the company's main .com or .org site, for example, for example, GE.com, or for larger companies more distributed around the main sites for companies of different sizes, for example. B. GEhealthcare. with. Certain product lines also often have their own unique online presence. For example, Pepsico.com has a branded presence, while Pepsi.com has its own separate presence.

CHAPTER 2: THE PROJECT ECOSYSTEM

If you're working on a branding website, you'll likely be designing for a variety of audiences, including current and potential customers, investors, partners, the media (eg, news organizations and featured blog authors), and job seekers.

Common Brand Presence Pages A company's main website (company.com, company.org, company.net, etc.) A website for a company's primary business unit (usually a single website for

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

Brand Presence Design Objectives The design objectives that are often most important in a brand presence project are: communicating brand values and corporate messages;

either explicitly (perhaps a statement of how important it is to respond to customer needs) or through the overall experience of visiting the site (for example, ensuring the site works well and has great features that encourage customers to stay with the company Contact ). Provide quick and easy access to company information. You want

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

“What can the company do for me?” and “How does the company do this?” Engage a variety of key user groups and guide them through relevant interactions

elements, functionality or content. Help the organization achieve defined goals against key metrics such as:

the number of unique visitors. This is often part of an overall marketing strategy. Later, in the Pick Your Hats section, you'll learn about the different roles that can be involved in designing a brand presence website. Let's take a look first

DETERMINE THE TYPE OF WEBSITE

to the other types of sites you might work on, including one that is closely related to brand presence sites: the marketing campaign site.

Marketing campaign sites are similar to brand presence sites in that both aim to provide users with an experience that influences their perception of the company's brand. However, marketing campaign sites tend to be judged on their ability to drive very specific actions within a defined focus (eg, within a specific time period or target audience). Rather than serving as a conduit for channeling interest, they are intended to serve as engines for generating interest. From an online perspective, this usually means that they are in line with an overall marketing strategy and can be done in conjunction with other marketing efforts through various channels such as TV or radio advertising, print ads and other promotions.

Common Marketing Campaign Sites A landing page that promotes a specific offer. The website is accessed through a

Banner ads from another website. A small website (or microsite) that promotes a specific event. A game or tool designed to generate emotion

or circulation.

The main objective of a marketing campaign website is to create a narrowly focused campaign, usually targeting a specific set of metrics. Focus is often limited by one or more of the following factors: Time - for example, a campaign focused on an event (p.

conference) or a season (for example, the Christmas shopping season) User group - for example B. A campaign targeting teenagers or teachers Product, product suite and/or a specific use for this product - for

For example, a site that highlights kitchen appliances showing virtual kitchens with matching ovens, dishwashers, and ranges

CHAPTER 2: THE PROJECT ECOSYSTEM

A campaign using a combination of these strategies would be a spring campaign aimed at selling yard equipment, matching weather and product variety. See Figure 2.1 for an example showing a product suite and user group combination. A marketing campaign website can be as simple as a banner that links to a landing page on the company's .com website, or it can be a microsite, a small website that often differs from the branding displayed on the .com website varies to provide offers of experience corresponding to one or more of the areas of focus. “Small” is relevant here – some microsites consist of just one page, others consist of multiple pages, but in each case the microsite is smaller and more focused than the main page for the company's brand presence.

Figure 2.1 Texas Instruments uses this educational microsite, http://timathrocks.com/index.php, to present information about the company's graphics computers. The product suite is primarily used by high school and algebra students. The microsite remains largely associated with the Texas Instruments brand, but is deliberately designed differently to appeal to a younger audience and organize content and resources around their needs.

Marketing Campaign Design Objectives For the individual or team responsible for designing and implementing a website marketing campaign, the design objectives that are often most important are: Arouse interest and excitement, usually by presenting a clear and straightforward presentation

This can be a value proposition (the value that a product or service provides to the user, such as being able to quickly qualify for a loan) or some form of incentive (a special offer, participation in a contest, or entertainment). , like an online game).

DETERMINE THE TYPE OF WEBSITE

Engaging multiple groups of primary users to simulate a specific action,

B. clicking on a specific location on a brand presence website, signing up for a newsletter, or applying for a loan. When this action is performed by a user, it is called a conversion. Help the organization achieve goals defined in key metrics like "No".

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

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

Content source A content source site contains a collection of information, possibly in various types of media (articles, documents, videos, photos, tutorials) and is intended to inform, engage and/or entertain users.

Common content source sites A company's internal network An online library or resource center for members of an organization Sites or sections of sites that focus on providing common news or news

up-to-date posts (major expert blogs may fall under this category) customer support centers

Of course, all websites and apps have some content, but some websites pay special attention to the presentation and structure of their content. The focus may be because the site has such a large volume of content that it presents a challenge of its own, or because certain types of content are of high importance. For example, they can support important decisions or direct users to the site frequently.

CHAPTER 2: THE PROJECT ECOSYSTEM

The main purpose of a content source page is to increase user knowledge and independence by providing relevant content (eg an intranet). They often also encourage an action, such as sharing information or purchasing a product after checking the description. Content Source Design Objectives A site with content sources generally needs to do one or more of the following: Present content that will be the main attraction for the first and repeated visits to the site. Demonstrate a company's thought leadership skills, for example

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

can be dug into separate sections. This may be part of a broader objective to identify more opportunities for innovation. Help users find information in different ways. For example,

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

Navigation For more information on the different ways people look for information, see Four Ways of Seeking Information and How to Design for Them by Donna Spencer: http://boxesandarrows.com/view/four_modes_of_seeking_ information_and_how_to_design_for_them

When it comes to UX design, one of the most common tasks in a content source project includes: Creating a categorization structure that fits your users' mental models. Determine how to integrate an organic content development system

(e.g. features like tagging and filtering) Design an effective search tool DETERMINE WEBSITE TYPE

Task-Based Applications Task-based applications can range from a simple calculator integrated into a mortgage website to a complete system that handles many important workflows. If your project involves the latter, there will be more roles and likely an extensive requirements gathering process (see Chapter 5 to learn more about this process).

Generic task-based applications A software application that supports the creation of a specific type

Component (such as a spreadsheet or printout) A tool or web application that supports an important workflow in a

Business (for example, a ticket management app for an IT support team or a customer tracking app for a call center) A website that provides access to and management of personal information

(as Flickr)

The main objective of a task-based application is to enable users to perform a set of tasks that meet their needs and, ultimately, the customer's business objectives. Design Goals for Task-Based Applications Most task-based applications must allow users to do something they couldn't do elsewhere - or, if they can,

do better (“better” can mean more efficient, more efficient, with a higher level of satisfaction, or more convenient) Support inexperienced users with easily accessible instructions and visual priority.

Write basic tasks. Support intermediate and advanced users with access to shortcut features

and deeper functionality Reduce user load and make optimal use of system resources

(e.g. reuse data versus requesting duplicate entries)

CHAPTER 2: THE PROJECT ECOSYSTEM

Be mindful of the degree of change required during design and development

the application user – ideally with a design that facilitates learning and a communication design that offers added value to the user. One of the biggest challenges in designing a task-based application is keeping "stealth running" under control. As a project develops, it is common for great ideas to emerge in later phases of the project, or even during development. User experience design is useful for guarding against feature creep because user models such as personas can be used to identify high-value features and maintain focus throughout the project. Later in the process, if a really great idea comes along that meets the needs of a high-priority user group and aligns with the site's business goals, your team can advocate for a change in direction. If an idea doesn't survive this predicament, it may not be worth the delay and expense.

E-Commerce Sites E-commerce sites can contain elements of all four design types because a site intended primarily for e-commerce will have its own branding, provide content (usually product specifications or descriptions of product usage), and facilitate tasks required (search, compare, write reviews, checkout). Marketing campaigns are often closely tied to these sites and may involve multiple marketing teams within the organization. Additional common design goals for e-commerce sites are: Explain the site template if it is not standard. how to shop online

are constantly being reinvented, this explanation will help set expectations (e.g. eBay, Amazon and Craigslist have very different models). Support decision making as the user moves from learning to thinking

Market comparison with useful content and resources. Benefit from experience points where there is cross-selling and up-selling

If possible, phrase these phrases in a way that is attention-grabbing without being distracting. Create a purchase-to-purchase communication flow

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

E-Learning Applications E-Learning Applications are a hybrid of a content source and a task-based application. Courses require content creation, which often requires staff to add Learning Specialist and Subject Matter Expert (SME) roles for the topic covered. The product is task-based, so the user generally follows a flow in the lesson and may also need to track progress or explore related topics. Some hands-on courses may also require homework to be completed. Common design goals are: Identify understanding of the foundational knowledge needed to start a course

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

Understanding. Engage the student in activities that simulate hands-on learning. Communicate performance and progress and recommend if necessary

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

Social Networking Applications A social networking application is primarily a task-based application as users need to find and add friends, manage their profile, socialize, post and search. However, they also present challenges related to content sources, most notably the need for an organic structure that can handle a potentially very large amount of user-generated content. When the site essentially takes on an identity of its own, it also exhibits the characteristics of a branded presence site.

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

CHAPTER 2: THE PROJECT ECOSYSTEM

Common design goals for social media apps are to keep potential users focused on the network's purpose and values. Enable meaningful interactions between supporters and sympathizers

Supports featured features (such as image sharing, video sharing, and discussions). Protect site integrity by ensuring everyone is present on the network

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

Programs that are only possible with active members, such as popular features and reviews. Identifying the type of website or application you are working on during a project is just the first step. Next, consider the different roles that are often needed and how their involvement might vary depending on the type of project.

Choose your tasks: When you become a UX designer for a project, you usually take on multiple roles. Regardless of whether the roles are formally defined within the customer's organization or not, the roles you fill will depend on the nature of the project and the makeup of the rest of the team, as well as the customer's experience with each role. It's good to know which roles you already like and which ones you think you can learn on the job. It is also helpful to know what expectations others might have about the responsibilities of these roles. With this understanding, you can present yourself more clearly from the beginning of the project. What roles are most commonly expected from a UX designer? Each client company you work for may have different titles for these roles (or no names at all if it is not an official role in the organization). In general, you can expect to find the big three: information architect, interaction designer, and user researcher. Note: Few companies have the size or budget to divide these common roles among different people. Remember role names when defining a project, but talk about needs and responsibilities when talking to the client – otherwise they might think you're building too big a team! This focus on responsibilities rather than titles also helps maintain sanity: if you take on several of these roles, you don't necessarily have to do a lot of other people's work, as responsibilities will fluctuate and fluctuate in different parts of the project.

CHOOSE YOUR HATS

Information Architect An information architect is responsible for creating models for the structure of information and using them to design user-friendly navigation and content categorization. Common tasks in website and application design include creating detailed site maps (see Chapter 10) and ensuring that categories and subcategories of information are clear and easy to use. Understanding expectations In the UX space, a distinction is made between the roles of information architect and interaction designer (see below). However, in any organization there is rarely a common distinction between the two roles, at least when it comes to the so-called need for a given project. For example, you might end up on a team titled Information Architect because that's the historical term for the role, regardless of whether it actually fits your responsibilities. Should you correct the project team if the title you've been assigned doesn't match the primary role you're taking on? If the project is short term (e.g. four months or less) and the title you hold is widely accepted within the organization and responsibilities are clearly defined, it may not be worth trying to change it for the potential confusion you would cause. However, if there is no commonly accepted title and you feel there is a chance that both roles need to be represented - possibly by different people - it is worth making a distinction early in the project when planning your involvement and communicating responsibilities. . Essentially, for more task-based applications, it makes sense to emphasize the role of the interaction designer, and for more project-based projects, it makes sense to emphasize the role of the information architect. However, it makes more sense to use the term that is familiar to the client's organization and ensure that the team understands how you define your role in relation to the responsibilities you assume. You should clarify this definition in the service description (see Chapter 3). The responsibilities of an information architect can also be confused with those of a content strategist (see the Other Roles section below). If these papers are

CHAPTER 2: THE PROJECT ECOSYSTEM

If you are represented by different people on the project team, it is important to discuss early on in the project how you will work together.

Interaction designer An interaction designer is responsible for defining the behavior of a website or application according to user actions. This includes site flows across multiple views and interactivity within a specific view. When designing websites or applications, common activities are creating workflows that show interaction between pages or elements on the site (see Chapter 10) and creating connections that show interactions on the page, such as B. dynamic menus and expandable content areas (see Chapter 11). Understand expectations If you're working on a small team or on a project that doesn't particularly focus on building new task-based features (for example, if you're working on a branded site that primarily includes a few categories of content, a ( eg a contact form and an application form for a prospect) the interaction designer may be primarily responsible for gathering the project requirements (see Chapter 5). If you are an interaction designer working on a project with a high level of new features, your team is likely to be a separate person responsible for describing the detailed requirements (for example, a business analyst or a product manager) the use cases are influenced by the design of the experience. to sit down with the person responsible for gathering requirements to discuss how best to work together.

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

CHOOSE YOUR HATS

Understand expectations The client organization's appetite for user research can vary greatly, depending on the importance the project team or project sponsor places on it. The fact that you talk to a project sponsor about UX design before a project starts shows that someone on the client's team knows that ensuring the user's needs are met is a priority. But, as those who have worked on various computational projects know, the introduction of search results can also create anxiety among project team members -- caused by concerns that user search is a barrier and increases risk (What it happens when we find something wrong and we need it Can you make big changes to fix the problem?) or disprove the value of a specific idea that has gained a lot of momentum. User search expectations can differ between business stakeholders and the project team. So be sure to clarify role expectations with both groups. The customer can also expect the user researcher to provide information based on site analytics - tools and reports that communicate usage patterns on the site, for example. B. Frequently visited pages and frequent points at which users leave the site. Some of the most 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 take on all three of these roles: information architect, interaction designer, and user researcher. Can you juggle all three, or are you biting off more than you can chew? This depends in part on the size and timing of the project, but the nature of the project also influences how likely each role is to be involved. Table 2.1 describes how UX design roles can vary by project type.

Search Would you like to support UX design? These articles offer approaches that can help: "User Experience as a 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

General Responsibilities of the UX Design Role

information architect

BRAND PRESENCE

MARKETING CAMPAIGN

CONTENT SOURCE

WORK-RELATED REGISTRATION

Average service.

Low engagement for smaller sites (e.g. a single landing page). Moderate involvement when working with larger micro positions.

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

Moderate to high engagement, focused primarily on creating the navigation pane unless there are larger areas of content that need to be referenced during specific workflows.

Low participation for smaller sites, medium to high participation for larger microsites or advergames (sponsored online games designed to create fun and excitement).

Moderate to high participation.

Very high turnout. This type of project usually requires the heaviest work, as the interaction design deliverables (for example, user process flows and wireframes) are essential for visually communicating the requirements.

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

Field research, like contextual research, can help staff understand how different users are interacting with information.

The greater the content challenge, the more likely the project will become a content source.

interaction design

Average service. The greater the number of tasks, the more the project resembles a task-based application.

User Researcher involvement varies by budget and access to users. Here are common techniques for each type of project. See Chapter 6 for more information on each of these techniques.

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

Search, tag and filter functions move on the boundary between information architecture and interaction design. Content sources can also have workflows that involve creating and managing content.

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

Field research, like contextual research, can be performed to understand tasks as users complete them. However, the most commonly used and best understood technique for involving users in the design of a task-based application is usability testing.

Once a framework is in place, the framework can be validated through usability testing.

CHOOSE YOUR HATS

Other roles you may have or need. Several roles don't typically fall under the UX designer role, but your responsibilities often overlap with the UX design role - especially if you're working on a project where no one is officially doing the role, but you have the skills that can to bring. Some of the more common overlapping roles include: Brand Strategist or Manager, Business Analyst, Content Strategist, Copywriter, Visual Designer, Front End Developer

The following sections examine each of these functions in more detail and explain how they can differ depending on the type of site being designed. Brand Strategist and Brand Manager A brand strategist is responsible for building relationships with key markets by defining and consistently presenting the company's brand elements. This can include anything from branding values (eg "Reaction") to guidelines for copying and messaging, following guidelines for editing the logo, colors and layout. This role often includes creating or representing brand guidelines and understanding how to apply them to different projects. It can also be about knowing or defining the important target audience for the project you are working on. Most of the time, you'll likely work with a brand strategist but not take responsibility. The brand manager doesn't necessarily set the guidelines, but is responsible for ensuring they are followed correctly throughout the project. This responsibility can be assigned to a project's UX designer or visual designer. When the company's characteristics, values and guidelines are already clearly defined and the site is expected to follow them, your role as project brand manager is mainly to ensure that the result complies with these guidelines. Your contact outside the project would 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 staff member. The brand manager role can be more active if the site intends to extend the brand in some way – for example, targeting a new market. This is especially the case when creating an entirely new brand presence or when the company makes a drastic change to its brand and basically rebrands itself. For example, CellularOne was fully rebranded as Cingular, a major undertaking for an established company. In this case, you must have a lot of experience in brand development or have a clear and close relationship with the person at the company. Important questions to help you understand the expectations of a brand role are: Are the brand guidelines already in place? If so, how exactly should they be respected in this project? Who is responsible for establishing or maintaining the brand, brand messages?

Content look and feel (e.g. casual or business)? New previously discovered target groups are addressed

brand definitions? If so, who is responsible for ensuring that brand guidelines remain appropriate for these audiences? Will there be any naming or renaming activity? If yes, how should I proceed?

involved? (An example would be creating a name for a heavily promoted new tool.) For projects that don't have a large potential impact on customer brand perception, such as B. developing an in-house application, involving a brand manager can be helpful, even if it's just an occasional check-in to make sure the brand is well represented. Business Analyst A business analyst (sometimes called a business systems analyst on IT projects) is responsible for identifying key business stakeholders, leading the requirements gathering process (see Chapter 5), and serving as the key liaison between business stakeholders and the acting technology group. He is also primarily responsible for detailed documentation requirements such as B. Functional specifications and potential use cases.

CHOOSE YOUR HATS

The business analyst or product manager role may not exist on your project, or it may be one of the most important roles in the design process. Task-based applications and content sources often play this role. Brand exposure projects and marketing campaigns may not be the case. A task-based application will likely need this function. The more features and the more complex the project, the greater the need for a dedicated person and functionality documentation. While a business analyst is typically not considered a member of the UX team, small UX teams are often asked to fill the role. Therefore, it is important to understand where these responsibilities lie. Business analysts drive the fulfillment of business needs and act as a liaison between the technology team and key business stakeholders. When a project involves a business analyst, that person and the interaction designer are usually at the center. If it's the same role, the person in charge may have a lot of documents to keep track of! To understand expectations in this area, ask who is responsible for defining the project scope, facilitating requirements discussions, and documenting requirements throughout the project. For small or under-resourced projects, the project manager sometimes assumes this responsibility. Either way, even if it isn't, you still know who to keep in touch with to make sure your results are in sync. Content Strategist A content strategist is responsible for understanding business and user requirements for content across all media (articles, documents, photos, and videos), identifying gaps in existing content, and facilitating workflows and developing new content. Content efforts are often underrated. A client may have a lot of great content in a medium (for example, brochures or print videos), but that content may not be appropriate for the project you are working on. In addition, there are sometimes unspoken expectations from people within the customer organization who create content - expectations that may surprise these people when it comes time to fill your product with descriptions, news, and help topics! When it comes to quality content

CHAPTER 2: THE PROJECT ECOSYSTEM

To determine the most important business driver in your project, make sure you know who is responsible for: Establishing content policies for the new product (content type,

ton, quantity). Assessment of adequacy of existing content compared

guidelines. Development of new content. This depends on the general nature of the project. For

Task-based apps can contain tutorials, error messages, and help topics. For content sources, this could include articles, news, and blog posts. Acts as a liaison between stakeholders and the technical team for communication

Limitations and possibilities of the content management system. Specification of the different types of content and respective metadata (the

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

for different types of content and ensure that content is tagged and loaded correctly when submitted to the site's content management system. (Here, too, effort is often underestimated.) Copywriter A copywriter is responsible for writing the text on the site that shapes the overall experience. In some cases, this copy remains relatively unchanged from one day to the next. It usually contains site and page introductions or on-page instructions. A copywriter may also be involved in the ongoing creation of dynamic content such as news or copy for marketing campaigns. Copywriting is one of those gray areas that a UX designer often falls into, especially when it comes to creating wirelines (see Chapter 11). You can start by entering some sample text to act as a placeholder for text, such as a website description or on-page instructions. Eventually though, someone will have to fill it in with the final text that users will see - and since many projects don't have a dedicated copywriter, that job might just be the default job for you. You are less likely to be asked to fill in the copywriting role for high-profile areas of branded websites or marketing campaigns. in these situations

CHOOSE YOUR HATS

Every word can be checked carefully. However, if you're working on a task-based application that needs short tutorial messages, error messages, or other types of information that don't necessarily fall into a clear content area, you can inherit that writing task (or she). is left to the developer by default). Check in advance if a copywriter is available and double check with wireframing if none are found. If you are the developer, be sure to consider this effort when planning your activities during the project. And attention: this is a responsibility that is often neglected or underestimated. Visual Designer A visual designer is responsible for the elements of the site or application that the user sees. This includes creating a look and feel that creates an emotional connection with the user and is consistent with brand guidelines. For example, a banking website generally needs to appear stable, reliable, and accessible. Visual design can provide this assurance through visual elements such as colors and images. This promise is fulfilled (or broken) by the interaction design of the website and other points of contact with the company (for example, a call center). Let's face it: a lot of people out there call themselves visual designers, web designers, or graphic designers, and a lot of websites have bad or passable visual designs. There is a big difference between creating effective, immersive and emotional visual design and actually being successful. Sometimes success is enough to meet project goals, and sometimes it leads to frustration and project delays when the project sponsor is dissatisfied or early adopters don't engage with the design. On the other hand, it's also easy to focus too much on making an impact with the visual design, thereby compromising the usability of the design. If you're asked to fill this role and you're not sure if you're capable of making the right customer impact, take a look at the company's current website and the sites or products customers are exploring, admire it visually from a perspective to gauge the how comfortable you are with him. Visual designers often play a very central role in branding projects and marketing campaigns and are primarily responsible for communicating the company's brand effectively.

CHAPTER 2: THE PROJECT ECOSYSTEM

For content source projects, they might focus on creating content templates that can be applied to multiple pages (for example, a template for an article). For task-based applications, they can provide a style guide that can be applied to common interaction elements such as dashboards and navigation tools (requiring a high degree of collaboration with the interaction designer). Front-end developer A front-end developer is responsible for creating the technical framework behind page designs and flows, as well as interactive elements on the site such as update menus, expandable content areas, and interactions with media elements such as videos . Technologies such as XHTML, CSS, Flash, JavaScript, Ajax and Silverlight are often used in this work. Front-end development focuses on the elements of the site that directly relate to what the user sees, as opposed to the back-end systems that provide the underlying platform (e.g., databases, content management systems, and the code needed to build the functionality behind them). complex features). When you or your team members take on the front-end developer role, it's important to work closely with the rest of the development team to understand expectations and responsibilities. Other important questions are what backend systems they need to integrate with, what method to use to generate HTML, what flexibility is needed in the page structure to adapt to custom skins, and what is expected of technologies like Flash. If a prototype is being designed (see Chapter 12), ask who will be responsible for developing the prototype and what functionality is expected. A prototype intended just to communicate functionality can be quickly created in an application such as Flash, but a fully functional prototype that contains real data (for example, the account information a user has just entered into a form) must be retrieved, but it must be built by working closely with the back-end development team members. Are you afraid to take on all these roles? Unless you're working on a very small project - or a very small company - you probably won't take on everything. The key is figuring out what roles you are able and willing to take on as needed for the specific project you are working on. By the way, you can get the necessary support from the project team by building a network within the client company or by suggesting additional people to fill the need. Let's talk a little bit about how you can do this.

CHOOSE YOUR HATS

Create a user support network. For those areas you're not sure you can or want to take on, it's time to seek help. There are three main ways to do this: Recommend adding more team members as needed

very obvious. Train on key areas where there are gaps - if the new answer -

Skills are manageable and you have time to dedicate to them. Create a support network within the company to help you in key situations.

Let's take a look at how you can build a support network. There are likely to be some important resources elsewhere in the organization that can help you succeed. You have to estimate how much time you can expect from these people, because on projects that are primarily owned by one department, it can be difficult to ask outsiders for time. If you don't want to ask too much of them, ask if you can work with (or consult with) them to get the best result for the main responsibilities of this role. Once you've collaborated, you'll better understand how much interaction you might need and whether to make a more formal request for their time. Every company has a different structure and different names for their divisions, but here are some common places to look for partners: For the brand strategist role, ask if there's someone in marketing

Department that can serve as a contact for you. This can also be a resource for visual designers and content strategists. Visual design and content strategy partners can also be found

B. program or product management, or in the areas of research and development, operations, or corporate strategy, where you often find business analysts and product managers. For the front end, IT or engineering is usually the best choice

Developers and others who can help you gain access to and information about website analytics tools.

CHAPTER 2: THE PROJECT ECOSYSTEM

If you're newly hired at a new company and expect to work across multiple departments, it's best to identify key individuals who are potential partners early on and schedule an interview with them to establish their roles and backgrounds. It gives you access to a network you can trust for a long time to come, and it gives you the opportunity to explain your responsibilities (and user experience design in general). You can also 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 might not be obvious to the main project manager or the customer line. Even if you've been with a company for a while, you can still start that talk show. In that case, it's best to tie it to a specific milestone (e.g. the start of a new project) or business goal that has some urgency behind it to ensure high engagement. Make sure your manager knows what you're doing so it doesn't look like you're running. Good communication is key to understanding role expectations and building trust. Another key to building trust within the company is understanding its culture, the often unspoken expectations of how a company works, such as those driven by past project experiences (both positive and negative), etiquette around organizational hierarchy, and work arrangements. acceptable (e.g. from home) came up).

Understanding Company Culture Culture is a bit like pouring Alka-Seltzer into a glass – you can't see it, but it somehow makes a difference. —Hans Magnus Enzensberger

A company's culture may not be consistent across regions, divisions or departments, but you can usually identify the key characteristics that affect you and the project or projects you undertake. Here are some things to keep in mind when directing projects and navigating potentially difficult political situations.

UNDERSTANDING CORPORATE CULTURE

History We've all heard the quote that those who can't remember the past are doomed to repeat it, and project work is no exception. Understanding how a project or team arrived at its current state of need can help you better understand the challenges you may face during the project. Let's cover some of the questions you can ask to understand the flow that can affect a project. While some of the answers to these questions may seem daunting, consider that for some reason it has become necessary to involve you in the project for a project to have a difficult history and still be successful. You can be the key factor in this success! However, if many of the problems listed below apply to you and you feel that you cannot fix them, this could be a red flag. If so, consider doing an overall assessment to see if this project can be successful. What example of earlier work seems to have been considered?

did it work, and what seems to have contributed? What previous project seems to have failed (or been particularly painful) 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 person responding defines success, potential risks to your project, and any biases or expectations towards that project. as well as approaches that worked well. The company collaborated and released a designer for her

project or team? In that case, try to find out what didn't work and how the customer expects a different approach than yours. If you can ask this question of more than one person in the company, it will help you understand a lot about unspoken expectations. If you get two very different answers, it could mean that the designer's responsibilities have not been clearly defined and you may need to ensure that there is plenty of communication about your responsibilities throughout the project. Did the project team work on the project (or related material)?

Why does it seem to take an unusually long time to finish?

CHAPTER 2: THE PROJECT ECOSYSTEM

If this is the case, it could be a sign that key customer stakeholders are not on the same page or not engaging at the right time, which can result in multiple delays, changes in direction, or wasted time due to multiple iterations. . It could also mean that there is no clear leader, someone who can say “no” (or at least prioritize effectively) to stay focused on business goals. Being able to influence project communication can help you create participatory policies that move the project forward. Did the company make plans without prior involvement?

User Experience Designer? This can be a mixed blessing. On the one hand, you're dealing with a team that understands the need for design and has tried to bridge the gap. On the other hand, you may come across a design that you believe does not meet the user experience goals of the project. This can be a tricky situation to navigate. It is often best to approach the creator of these themes in the tone of a respected mentor or helpful consultant, first highlighting the good aspects of the design, then discussing the user experience goals and discussing how to make them better with a different approach. . . The breeder is likely a valued member of your support network. So it's important not to burn the bridge here, but redefine their roles collaboratively to keep the tension alive. The main sponsor or project manager seems particularly concerned

About the project; There are many reasons for this, especially if any of the above factors come into play. Stress can also result from market pressures, which would be helpful to understand. For example, has the company's stock price dropped? Have any competitors in particular taken any worrisome actions recently? Is the company in the red? Again, these situations don't necessarily mean you shouldn't take on the project. After all, it's situations like this that usually finance a project. However, if you have significant concerns about the company not being able to pay your bills, consider this risk.

UNDERSTANDING CORPORATE CULTURE

Hierarchy Geert Hofstede has an excellent model that describes cultural differences, what he calls "cultural dimensions", which often affect the way people interact and communicate. One is the concept of power distance. It's about the extent to which members of a society (in our case, a company) understand and accept the distance between people at different levels of power. For example, if a company's executive team members are perceived as particularly powerful and potentially unapproachable, a company may have high power distance and its employees may be more hierarchical. If the company encourages a democratic exchange of ideas and challenges the vision, there can be relatively little power distance.

Power distance is "...the extent to which less powerful members of organizations and institutions (such as the family) accept and expect power to be unequally distributed." This represents inequality (more versus less), but it is seen from below, not from above. They are defined. This suggests that the level of inequality in a society is supported by both supporters and leaders.” Geert Hofstede Kulturdimensionen www.geert-hofstede.com

Neither extreme can be considered good or bad by itself, although in the United States in general, most workers seem to prefer the appearance of low power distance in their workplace. Interestingly, this is not necessarily an indicator of a company's success. Apple has a relatively large power distance (given the aura around Steve Jobs) and Google has a relatively small power distance as part of their culture, yet both companies are considered leaders in innovation. It is important to note that the power distance within the client's organization has an impact on how successfully you navigate political waters during the project. This aspect becomes particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at important milestones such as release points (discussed in Chapter 4). If you work at a high energy distance company, take a little extra

CHAPTER 2: THE PROJECT ECOSYSTEM

Take time to understand reporting relationships before scheduling meetings such as stakeholder surveys and assessments, and consider involving more mid-level people in your communications.

Logistics In addition to the broader aspects of culture mentioned above, it is also helpful to understand some of the elements of a more logistical nature so that you can better integrate into current working methods or thoughtfully introduce changes. For example, it helps to understand the overall expected pace within the organization, including key release dates or deadlines that impact the project (developing a software application on an annual release schedule would likely pace differently than developing a microsite, which supports a seasonal release timeline). campaign, for example). Is your team expected to work long hours to meet looming deadlines? It's also good to understand the expectations of working remotely versus working onsite. If you expect to be locally for an extended period of time, plan travel and resources locally. If remote work is accepted (or encouraged, which is common when working with global companies), it is important to understand communication methods and tools. For example, is it acceptable to use instant messaging apps? What web conferencing tools are used? Are there international stakeholder engagement methods that have proven successful in the past? It is also interesting to understand the “paper culture” in a company. Some companies prefer electronic media for most things, so a good projector and a stable Ethernet connection are important. Others are very paper-centric, so make sure you bring enough copies to a meeting to make it productive. You can change the culture of the project if you feel that another way is more effective. But it's nice to know you're encouraging people to change so you can transition smoothly — and potentially understand why a certain approach isn't working as expected.

UNDERSTANDING CORPORATE CULTURE

Putting It All Together Now that you've explored the project terrain, it's time to better understand the project ecosystem: the environment you'll be working in (the organizational culture), the general type of work everyone will be doing (e.g., the types of websites ). you design) and the people you will interact with (including their roles and responsibilities). This information comes in handy as you define your role in the project and get ready to get started in earnest. If you work as a freelancer or a subcontractor, this forms the basis for writing a proposal that covers your work on the project (see the next chapter on UX proposals). If you work in a larger team and are not directly involved in preparing the bid, you can apply your new knowledge at the project kickoff – your team's first meeting. For a basic guide to running a good meeting, see the online chapter A Quick Guide to Meetings. If you want to skip straight to the types of questions to ask at the beginning of the project, see Chapter 4, “Project Objectives and”. Approach."

CHAPTER 2: THE PROJECT ECOSYSTEM

Tips for Consultants and Freelancers A Guide for Entrepreneurs Who Also Run Their Own Businesses Managing projects and client expectations can be difficult enough, but if you haven't closed a proper deal, you could find yourself on a losing streak with every project you undertake. Proposals and Statements of Work are vital to protecting your company – and yourself – from financial and legal problems. After accepting a project and shaking hands, take the time to draft an agreement outlining the terms of your relationship and payment schedule for your client. Russ Unger

Suggestions There's an old saying that goes, "No good deed goes unpunished," and the same goes for carrying out a project in general - high tension and happy times are quickly replaced by "Oh shit!" Time to write the sentence!” The biggest challenge in sentence writing is writing the first sentence. It's almost impossible to know where to start if you've never had to write one, and this chapter should come in handy. Each type of project you come across has different flavors that will stick in your mind as you draft the proposal. Fortunately, there is a core common to all proposals that can be reused from project to project. (See Chapter 2 for a detailed discussion of project types.) When should you write a proposal? Ever. Why write a sentence? In the history of design work, the most uncomfortable for people are situations where there is no agreement between the customer and the supplier. You might be tempted to skip this step when you're engaging with a prospect for the first time and everything seems to be going well. Even if you obviously understand the customer's needs and can articulate them in a way the customer understands, you're not really ready to get down to business. It's actually here to slow down and take a deep breath. Rather than jumping right in, take the time to define your relationship and the rules for working with your new client. Jean Marc Favreau of Washington law firm Peer, Gan & Gisler, LLP says: Too often, contractors and their clients believe there is a disagreement early in their relationship, when in reality the ambiguities are lies from them. While it's nearly impossible to prepare for every eventuality, a comprehensive written contract is your best defense and the smartest way to ensure you don't end up fighting the terms of your relationship in court later on. The more clearly you define the terms and parameters of your relationship with a customer upfront in a written contract, the less likely you are to argue about the obligations of both parties later.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

New projects and new people are exciting. There is often a desire not to ruin the deal by proposing, but as with any relationship, the honeymoon feeling can eventually wear off. Promises can be broken on both sides of the relationship. A client may not provide timely access to content. (I know this is almost unheard of, but believe it or not, it happens! That's sarcasm in case you missed it.) Funds once dedicated to the project can be siphoned off - and then you, who are busy with work, can keep the handbag. Companies are also aware that they take risks when working with outside vendors – especially very small companies or independent contractors. Well-written suggestions give clients a sense of stability and security, which can help alleviate many of the concerns that may arise. A proposal also allows you to define terms that protect both parties in case something changes. If the customer doesn't give you timely access to their resources, your schedule may fail. You must inform them of their obligations to the success of the project. If a client loses funding and abandons the project - and you don't have a quote or other form of contract - you run the risk of not getting paid for work already completed. The point should be clear: always write one sentence.

Creating the Proposal After completing the design, it's time to complete the proposal. The sooner a proposal is approved and signed, the sooner you can start work and, more importantly, the sooner you can get paid for your work. Key elements of a good proposal are: title page, revision history, project overview, project approach

CREATION OF THE SENTENCE

Scope of Work, Deliverables, Title and Rights, Additional Costs and Fees, Project Price, Payment Schedule, Confirmation and Output

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

Title page The title page is the single page that introduces your document. Front pages are an interesting thing: there are different ways to design them in terms of style and information. How you do this is up to you. A typical homepage consists of the following elements: Client company name Client company logo (if you have permission to use it) Project title Type of document (proposal) Proposal version Submission date Name of your company Proposal authors Number of reference of the project Confidentiality of the costs

Include everything in your initial quote – except the client's company logo, cost and (if applicable) the project reference number. Why not put these elements on the front page?

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

Your customer knows who he is. It's probably not worth the time and effort to ask permission to use a company logo, nor is it worth worrying about possible resentment if you use it accidentally. Costing is best done after you have identified the various project elements in the body and the costing information leads well to the payment schedule. The project reference number is something you need to know. Many companies will not use it at all. However, some government agencies are known to rely on this particular element. If it is not on the first page, your proposal may be rejected.

Figure 3.1 Example of a proposal title page

The (fictional) customer logo was used in Figure 3.1. If permission has not been granted or the relationship has not been established, it is preferable not to display the client company logo.

CREATION OF THE SENTENCE

Revision History The revision history is a separate section of the proposal and is used to track how many times you have updated the proposal since the original version. In general, it's best to include the version number, date, author, and any comments associated with the version, for example, B. State what changed to provide the reader with context for the changes (Table 3.1). TABLE 3.1 VERIFICATION

Example Revision History Table SECTION

DESCRIPTION

AUTHOR

GIVEN

authentic document

REU

January 8, 2009

cases

Updated to meet software requirements

REU

11.01.09

1,0 1,1

Occasionally, customers sign a proposal and then request further revisions. If you decide to go ahead with the client and make these changes, take the opportunity to upgrade your document from version 1.x to version 2.0. Basically, once a customer agrees to an offer and both parties agree to the terms, you're good to go. Therefore, if you want additional changes, you should consider them very carefully. This will ensure that your costs continue to make sense and that there is a clear understanding on both sides of what changes will be made and at what stage the project will restart (if necessary). Also, you should always use the revision history to explain in detail why the revision is a completely new version.

Project Overview The Overview section provides a description, in your own words, of the project you will be working on. This description should give your customer a clear picture of what you want their product to look like and what they can expect from the rest of your offer. Here is an example of how to start an overview: [Client Company Name] wants to create a new online web presence. This web presence offers [Customer Company Name] customers the opportunity to research and purchase products online, as well as other services and benefits available through the company. The objectives of the online presence are...

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

You should be able to give a solid overview in a paragraph or two and provide very detailed details of what the customer should expect from you. It's a good idea to end the overview with a detailed explanation of the recommendations and proposed approach to completing the project: This proposal outlines [your company name]'s recommendations and approach to the design and development of [customer company name ] described in detail. . Online presence on the Internet. Given the deadline of [deadline date], it is proposed that...

Project Approach Your project approach will vary depending on the type of project you are undertaking. This is your opportunity to let your client know how you would like to work with them on the project. You can define your rules of engagement and set expectations for the work to follow. Many individuals and companies work in very similar ways - but use different names or clever acronyms that fit their overall brand. Once upon a time there was a mythological methodology that was developed to represent (potential) clients and that resulted in many proposals. The process has been dubbed The PURITE Process™ (pronounced "purity"), and when I shared it with you, a mythological being was dying a little bit inside, so please read it as fiction. The process name is a bit cheesy and the process is obviously a bit incomplete. Post-launch analysis has been left out (forgotten) in this methodology, but should be included for all customers. Without further ado, here's the PURITE approach: [your company name] has identified a standard process for project success at our clients. While not all of these phases are applicable to [Project Title], the overall process is defined as follows: The PURITE™ process is [your company name]'s internal methodology for ensuring the success of all initiatives. With PURITE, [your company name] has proven guidelines for working closely with customers and users/target groups to reliably meet and exceed delivery expectations. Q - Get ready. We dedicate a portion of each initiative to understanding your industry and your competitors and how they work, so that you are as informed as possible before starting requirements gathering. You understand. We work closely with your subject matter experts and/or users to define the requirements for successful project implementation.

CREATION OF THE SENTENCE

R - performance. In the rendering phase we create and develop all parts of the project/product. In our experience, each development phase requires a lot of attention, focused work, but also open communication from the beginning with your team. It also requires... I - Iterate. The iteration phase is repeated throughout the project lifecycle. We are working to deliver the project as quickly as possible, and this often requires building multiple iterations on tight timelines. This requires immediate and timely intervention from you and your professionals. The end result is the product you specified and helped create. T—Test. We test each project during the rendering phase. However, we also need additional eyes - from our own test team and the designated user group/audience to conduct targeted testing. This extra round of testing helps ensure that as few stones as possible are left unturned to deliver work that has been rigorously judged on multiple levels. E - Activation. After successfully completing the previous five phases and your signed approval, we activate the solution and go live. The PURITE™ process doesn't end there. Upon completion of the project, we communicate regularly with our customers. We continue to measure your satisfaction, understand changing goals or improving your project, and help you define the best approach for your project's future development.

Feel free to use as little or as much as possible or that makes sense to you. Also, the mythical author who created the suit doesn't care if you don't credit the source. Your process definition can be as detailed as above or as simple as: plan, define, develop, expand. Plan the overall strategy. Define detailed project requirements. Develop, test, improve, and release the work product. Grow the project by suggesting improvements and enhancements based on information gathered during development, testing and post-launch

Once you've defined your process, you'll have the opportunity to detail the different efforts involved in each phase of your approach and explain what each of these efforts means to you and your client. The length of your proposal's approach section depends on your project, your process, and the activities that occur at each step of your process. However, try to limit the scope to a maximum of two or three pages.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

Be sure to only provide deliverables that you can deliver to your client - to avoid additional document updates or repricing of the project.

Scope of Work In the Scope of Work section, you specify the division of work for the project. That is, you determine which elements of the project you are responsible for and which the client is responsible for. Read This Again Think about this for a moment. Let it sink in. Let's go. Correctly. This is the part of the quote where you tell the customer in writing that we'll do this and you'll do that. When the client later signs your proposal, he agrees to this agreement and you have a document to help you with any misunderstandings. The point here is to clearly identify who is taking on which aspects of the project and which aspects of the project are included in your proposal and the price you are estimating. 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 Company Name] asked us to provide all necessary services for the construction of [Type of Project]. [your company name] focuses exclusively on the [user experience design aspects] of [client company name]. [Client Company Name] will provide detailed feedback on all aspects of [Project Type] in accordance with the project plan. [Customer Company Name] provides all necessary elements to be used in the project, including fonts, colors, branding templates, etc.

Assumptions The assumptions section of the proposal is a good place to explain, without room for debate, what your client needs to ensure its success. That is, they are things from which you start - and which you communicate with the client - that you have access to or that are made available for you to carry out the project.

CREATION OF THE SENTENCE

What you call assumptions in this section are actually expectations. It's much easier to accept. You can create as many project plans as you like, but if neither you nor the client commit to meeting milestones and targets, both sides will assume the project will surely fail. In general, the assumptions are an expectation of resources and assets and timely access (translation: immediate, immediate) to both. Here is an example of writing cases: Cases [Client Company Name] is required to provide the following assets and resources. Failure to provide these assets and resources in a timely and complete manner could result in the failure or delay of this project. The following assets and resources are expected: Timely access to all required [Customer Company Name] personnel. Timely access to all required components of [Project] in its current state, including all source files, if available. Content, as required and including but not limited to copies, images, audio, etc. for any aspect of [Project].

Deliverables are the work products that you create and deliver to the customer. In this section, you have the opportunity to explain to the client in detail what kind of work product he can expect from you during the project. It is recommended that you handle status reports separately at the end of the project, but you can also add them to this part of the project. Provide descriptions of any work product that you may include, even if the work product was not created. This may seem like overkill or has the potential to open the "I read about [delivery type] in the sentence but don't see it here" worm, but one little word, can, can make a difference. Deliverables [your company name] provides a variety of deliverables throughout a project. For [customer company name] we have identified the following services:

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

Creative Brief The creative brief is the first stage of the project. This document helps us create a project overview quickly and efficiently. The purpose of the creative brief is to clarify the users' goals and needs and to identify any special features and/or limitations associated with the design. etc…

Ownership and Rights It's important to consider the extent to which you allow your customer to use the work product you've created. These rights can be defined in many different ways, but most of your work falls into two categories: temporary work, licensed work

Works for hire (known in the legal world as “works for hire”) are deemed to have been created and copyrighted by the party paying for the work – not the party responsible for performing the actual work. This means that when you perform work on a rental project, you have no rights to the project and everything you create in connection with the project is owned by the client. This situation is difficult for many companies and individuals to deal with: it often results in no subsequent "maintenance" work (with additional revenue) as clients can choose to maintain the project themselves once completed. Don't get carried away by a project where the customer imposes the obligation. it's not uncommon. If you are using contract work projects as part of a full-time position with a company, this is very typical of an employer-employee relationship. It's also an opportunity to reconsider your pricing model - many projects are asking for a slightly inflated price to compensate for potential revenue loss down the road. Remember that it all depends on the relationship you have with your customer and how you choose to do business. Time and experience will help you make the right decision for the type of work you do and the pricing models you choose. With licensed works, you retain copyright to the work, but grant others the right to copy and/or distribute it. You can create as many terms as you like in your license agreement. You will most likely CONSTRUCT THE SENTENCE

Benefit from licensing your work if you retain ownership of all source material in your work and only provide limited-use work products to your customers (e.g. PDF files instead of Word, Visio, Axure, OmniGraffle - or other original and editable documents). You can take a number of different approaches to licensing your work, including licensing work for non-commercial use and unmodified or otherwise suited to your situation. Creative Commons (http://creativecommons.org/about/licenses) provides easy-to-understand explanations of a variety of types of licenses you can use, but these are just a small part of the world of licenses. If you find yourself in a situation where you have very detailed and specific requirements, it is always best to contact a copyright attorney who will help you find the best possible solution.

Additional Costs and Fees It is important for your customer to understand whether the price of the services you provide includes outsourcing or not. For example, some projects may require you to purchase photos from a vendor. You can purchase the images (with appropriate usage rights) and include them in your fee, or you can clearly identify the purchase of the images as an additional cost to be passed on to your customer. You can also offer services that you want to inform your customer about - this is a good opportunity to promote these services. Here is an example of how additional costs and fees are handled: Additional costs and fees If external resources are required (such as content, images, fonts, etc.), these will be identified and approved by . and billed to [customer company name]. Additionally, [your company name] is able to offer hosting services to our customers with very little overhead. We offer hosting services - including configurable web-based email - starting at $25 per month, plus a $25 setup fee. [Your Company Name] will work to create a package that is acceptable and beneficial to both parties.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

Project Pricing After documenting the details of how the project will work, it's a good idea to communicate the cost to the client. A lot depends on how you arrive at the price, but here's a tip: estimate how long you think it will take to complete the project - including a certain number of revisions. Estimating a reasonable amount of time to manage the project might be around 25%; Then specify the hourly rate you want to charge and charge for everything. There are several formulas to help you with this, such as: B. Apply difficulty levels to each part of the project to help you find a range of costs to offer your client. In most cases, experience is the key to correctly evaluating your projects - in terms of time and materials. How do you determine your billing rate? Research what others are charging to compare by finding salary surveys and contractor rates. For example, organizations such as the Information Architecture Institute (www.iainstitute.org), AIGA (www.aiga.com), Coroot (www.coroot.com) and talent agency Aquent (www.aquent.com) deal with payroll and tariff surveys for contractors. You can get a good idea of what prices you might be charging given your experience, what others are charging in your market, and what you think is reasonably fair. Remember, you can lower your rate at any time. It's much harder to charge your customer more when they see numbers on a page! There are many different ways to structure pricing for your project. Depending on the nature of your project, you may want or need to provide multiple estimates that allow for different pricing options. Suppose you give a customer two options: a static HTML site and a content management system (CMS) site that allows for dynamic content (which the customer could manage without dedicated resources). How to Formulate Project Estimates: [Your Company Name] Project Estimate has proposed various estimates for [Client Company Name] to provide the best possible options for your immediate and/or future needs. [your company name] assumes that all content is provided by [client company name]. If [your company name] is required to provide content services, the estimates will need to be reset.

CREATION OF THE SENTENCE

Estimates from [your company name] allow for flexibility in terms of costs and requirements. Estimates are as follows: Estimate 1 [your company name] estimates that [project] for [client company name], no interactive content…

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

Pay Schedule There is a myth that all freelance projects are paid 50% upfront before work begins and 50% upon completion, when the project is over. This myth needs to be dispelled - now! It's not a way to do business and it's not a way to earn a steady income while you work. You don't want to put yourself in the position of making change after change for a client just because you want to complete the project and get paid instead of completing a change order process. You can invoice projects in a variety of ways, from sending invoices within a certain amount of time to making payments based on milestones. A wiser approach is to move your projects towards a recurring payment schedule with regular, itemized invoices. This approach should also provide customers with a clear understanding of what has been accomplished and the work that remains on the project. The following example is one way to structure payments for your work: Payment Schedule The default payment schedule for [your company name] is for a prepayment of XX% of the total estimated price of the project to be done. [Your company name] will send invoices on the 1st and 15th of each month. Payment is made within 14 days. Upon completion of the project, [your company name] will deliver all work products to [client company name]. Once the materials are satisfactorily approved, [your company name] will refund the remaining overpayment amount of the advance or [your company name] will provide a final invoice for amounts not covered by the advance. Note: If [project] is suspended for a period longer than 14 days with no work in progress, [your company name] will provide a final invoice for all costs not covered by the advance and will have the right of first refusal if the project is restarted.

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

While not required, it is helpful to include a note of how the project will be handled if it is put on hold for an extended period of time. This contract can help keep your project on track and moving forward—and get your customers talking. If you don't have to do extra work for them for an extended period of time, you can look for work to fill the gap.

Acknowledgment and Detachment While it's very important to make sure you have a proposition, that alone is not enough. A proposal doesn't mean much until it's approved and signed by the right person at your client company. It is important to ensure that everyone has a clear understanding of what is about to happen and how much is expected from both sides. It is equally important to guard against "boulevard repetition" and to reduce the risk of a customer involving you in "feature creep". H. constantly asking to "add something else". Registration is quite simple and clear. After creating the proposal document, you provide your client with a confirmation and signature approving the contract between the two companies. Always prepare two copies - one for each party - and make sure both copies are signed. Here is an example of an acknowledgment you can use: acknowledgment This offer is fully acknowledged and accepted by [client company name]. This offer must be signed and dated by an authorized representative of [customer company name] to be valid. Alternatively, a signed Purchase Order referred to in this Quotation will be deemed acceptance in lieu of such signed document (provided any pre-printed terms of such Purchase Order are deemed invalid and unenforceable). This Proposal constitutes the entire agreement between the parties with respect to the subject matter of this Proposal. This Proposal summarizes and supersedes any prior oral or written agreement, discussion, negotiation, commitment, written or understanding. This includes, without limitation, any representations contained in any written literature, brochures or other descriptive or promotional material and constitutes the complete and exclusive statement of the terms of the parties' agreement. Each party acknowledges and agrees that it has not relied on, and expressly disclaims any reliance on, any representation or representation not contained herein or in the Agreement in the implementation of this proposal.

CREATION OF THE SENTENCE

Accepted by authorized representatives: [your company name]

[client company name]

Com: ________________________________

Name: _____________________________

Name:_____________________________

Title: ________________________________

Title: ______________________________

Given: ________________________________

Make all checks payable to: [your company name]

Statement of Work (SOW) is a high-level statement of your project's objectives, which you should be able to summarize in a two- to three-page document (no cover page). The statement of work is usually written before you receive the detailed requirements. However, depending on your client's needs and your project, you may choose to create a hybrid document that best suits your needs. In general, SOWs should be used to build initial consensus between your team and your customer's stakeholders. The SOW defines project inputs and outputs, as well as assumptions and constraints. At this point, it's not uncommon for clients to ask for a rough estimate of the work you'll be doing for them. It might be a little risky to answer this at this point. It is recommended that you do your best to avoid details or appointments without providing the details. It is simply not possible to know how much a project will cost until you have written the proposal and/or requirements document. However, you have to make a judgment call at this point. If you are working on a project, say a simple website, and have successfully completed several similar projects in the past and/or worked with the same client in the past, then you have some wiggle room. Remember, it's always better to be safe than sorry later in the project. A statement of work should be about two to three pages long and contain at least the following:

CHAPTER 3: SUGGESTIONS FOR CONSULTANTS AND INDEPENDENT PROFESSIONALS

Home Page Revision History Project Reference Number Project Summary Start Date End Date Price/Price Project Statement Activities and Deliverables Detailed Costs and Payment Schedule Confirmation and Cancellation of Registration

Do the characters seem familiar to you? You must do this - you can create a statement of work with a simplified version of the proposal. You've now learned how to collect two types of documentation that you can use to identify the work you do for a client. These documents should form the basis of any design work you undertake for each client and provide you and your clients with a clearly defined set of roadmaps for your projects.

statements of work

Project Approach and Goals Knowing which star to navigate One of the keys to a good project is starting the team with clear project goals and a well-understood approach. Ideally, project management has set this up for you - but how do you know if this isn't the case? This chapter is about setting project goals and asking some questions to help you solidify those goals. We also discuss some common design approaches (or methodologies) and how they can affect the way you work. Carolyn Chandler

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

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

Approval of business prospects? These questions are all about the stakeholders' expectations of the project: what the project will achieve and how they will be involved. The first two questions relate to the project's objectives and the last two to the project's approach. The project objective is a statement of a measurable objective for the project. Let's talk about goals in more detail.

Solidifying Project Goals Project goals are an important focus that you will use throughout the project. They should flow from the client company's overall business strategy, so project goals should align with the company's strategic initiatives. For example, if there is a strategic initiative to reach a new group of potential customers (called a market), the website or application you create may be an attempt to provide that market with online access to related products and services. The objective of this project, then, would focus on reaching and developing this market. A clear objective resonates throughout the work. It helps you ask the right questions while gathering information from potential customers. Design user surveys and focus your analysis on the results. Dig deeper into the insights collected from stakeholders and users and turn them into

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

DETERMINING THE PROJECT OBJECTIVES

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

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

The project begins. When starting a new project, you likely have project goals from the project sponsor (the business stakeholder who is directly responsible for the success of the project) and a number of project-related requests from business stakeholders and customers, but all can be a bit confusing (Figure 4.1). Your goal is to articulate them into informed statements that you can use as a measure of project success.

Project related queries

Unclear purpose of corporate strategy

Idea of stakeholder user needs

uncertain fate

User complaints advocate idea

Figure 4.1 Unclear goals, ideas and needs

A fixed goal is easy to understand. Avoid internal jargon. discreet. Avoid vague statements. Instead, use phrases that make sense to you.

This will be helpful when prioritizing requirements. counted Make concrete statements that you can define yourself

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

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Figure 4.2 Goals that solidify

Objectives of the corporate strategy project

You will hear many statements that could be considered targets. Analyzing ambiguities like the following will help you solidify your goals and communicate more effectively within the project team. business lawyer

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

This is a company-wide goal, but too broad for a specific project. For this to work, many initiatives across the company must come together. Any website or app can help with this, but it's highly unlikely to take the full brunt - unless the whole business is involved with that website or app and it turns out to be hugely successful. business lawyer

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

This is better because a website or app can have an impact on it, but it's still pretty vague. Why is it important to create tension? How does that enthusiasm translate into meeting a business need? And how do you know if it was successful? business lawyer

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

Now we're getting there. This is easy to measure, but it's too focused on an intermediate step. Let's say you drive more traffic: it might not help if people don't take the actions you want when they get there.

DETERMINING THE PROJECT OBJECTIVES

Vague goals can give you a sense of a client's larger desires and goals. From there, you can formulate more concrete project goals, such as B. increasing online sales revenue by 10 percent. Increase your online advertising revenue by 20%. Increase the number of existing and potential customers in our customer base

Database for at least 20,000. Provide our top users with highly rated and frequently referenced content.

(Note that deciding how to measure "high score" and "high benchmark" takes a little work, but the data is there to use as a baseline.)

Each of these factors can be measured and influenced by your project. They are also highly customizable for their designs and offered features. For example, it is very common to offer an online newsletter to achieve the objective of growing a customer base: to send the newsletter, it is necessary to collect the e-mail addresses of the customers that will be added to the database. Goals can also highlight new requirements. For example, if you measure success by the average ranking of items on your site, you'll need a feature that allows users to post comments. In this way, goals help you focus on gathering ideas for the site, which can later become project requirements. If there are multiple objectives, be sure to create a priority list with your corporate sponsor and project team. During planning, goals can conflict with each other, and the team must know what takes priority. The final list of prioritized goals should come from the project sponsor, but you can play an important role in the conversation. Let's talk about how.

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

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Possibilities and risks. This is known as a SWOT analysis and is a common business analysis technique and a way to discuss a company's position in the marketplace. You can also use this time to talk about the company's competition. Understanding Strengths and Weaknesses The SW in a SWOT analysis is the company's current strengths and weaknesses in relation to the project. Strengths and weaknesses can include 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 large source of published original research (a huge benefit), but there may be no one helping to make that content more accessible to the average user, which leader said to the perception that the company is “too academic” (weakness). Identifying Opportunities and Threats OT is the forward-looking half of SWOT. Given the things that differentiate the company from its competitors, what future initiatives can the company take to create a new niche or strengthen an existing one? What situations can jeopardize these plans? For example, the R&D company might decide to hire writers to publish more accessible articles about their original research (an opportunity), but if their current website tools don't have powerful content management features, the publishing process could be unreasonably slow. . This can give competitors the opportunity to react more quickly (threat). Compare competitors Who is the company's main competitor? Who are the competitors for the site to be developed? This can be different, especially for large companies or completely new locations. 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 are selling what you are selling. Gathering SWOT and competition discussions are good topics to discuss at the same time because they interact with each other. It is hard to talk

DETERMINING THE PROJECT OBJECTIVES

You identify 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 the company's competition and SWOT here, your project objectives - as well as your project's overall alignment within the company's strategy - should be easier to define and prioritize. Of course. Defining project goals can help you better understand what you expect from the project. Next, let's talk about the expectations of how the project will be. 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 approach or methodology of a project is an important part of understanding when and how you will and 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 for a project is a big topic in itself. The methodology chosen can depend on many factors, including the structure and location of the project team, the technologies used on the project, and the extent to which collaboration is part of the organizational culture. For the purposes of this book, we assume that you are involved in a project where the approach is largely determined by those responsible for the project's success, such as the project sponsor and manager. In this case, your main goal is to understand the approach and make it effective for your customers and business users. Here we focus on two of the most common types of approaches, as well as a third that shows possible variations you might encounter in a project. The important thing to note is that most approaches involve the same steps: planning the overall strategy, approach, and team structure. Define project requirements. Design interaction and visual concepts and develop them into detailed concepts

specifications. Develop, test and refine the solution.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Evolve the solution through messaging, training, and planned adoption. Expand the project by making suggestions for improvement.

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

Waterfall Approach A waterfall approach treats the steps in a project as separate and distinct phases, requiring approval of one phase before the next phase can begin. For example, the design phase doesn't really start until the requirements are approved by the business stakeholders, who sign off on one or more requirements documents at the end of the definition phase. to allow

The plan

to allow

Define Design Develop Develop Ext

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

The problem with a pure waterfall approach is that it assumes that each phase can be completed with minimal changes to the previous phase. Therefore, when new requirements arise during the design phase, which often happens, it is necessary to propose changes to the documents approved at the end of the definition phase, which can affect the project and the schedule.

Flexible Approaches Because change is constant, project teams are constantly looking for more flexible approaches than the waterfall model. Many methods take a more fluid approach, with certain steps happening side by side. For example, site versions can be released on a fast, iterative schedule using an agile or rapid development approach. An agile approach generally places more focus on rapid collaboration and less focus on detailed documentation and formal approval. UNDERSTAND THE PROJECT APPROACH

repeat 1

To develop

repeat 2

To develop

repeat 3

To develop

Deploy Design Deploy Design Deploy Design Define

Please

approval statement

The plan

Build version extension

Figure 4.4 Example of a flexible approach

A truly Agile approach (for example, following best practices developed by Agile Alliance members) requires small teams, with members naturally sitting next to each other, with no focus on defining formal roles among team members. This way of working allows for a very high level of collaboration, reducing the need for extensive documentation between the design, development and test phases. A team member can ask a question, find the answer, and implement a solution during a brief whiteboard session with other team members, all without waiting for detailed documentation and approval. In a fully operational system, stakeholder reviews occur when one of many iterations is released and the resulting input is incorporated into the design of the next iteration. (Iterations are preliminary versions of a given site or application.) When an agile approach works as planned, that's great. However, in most organizations and most consulting engagements, teams rarely take a purely agile approach. This is in part because organizations are increasingly using distributed teams and remote workers, making it difficult to maintain the high levels of collaboration needed to take full advantage of a pure Agile approach.

Modified Approaches Most projects try to adopt an approach that combines the best of both worlds, with enough structure and documentation to reduce the risks posed by distributed teams and team member turnover, but also enough collaboration and iteration to be able to react with relative flexibility the changes. For example, a project might follow a waterfall model, but it overlaps in phases, so there are key points for cross-team collaboration. This allows

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Potential changes occur earlier in each phase. This may also include an early release (for example, a beta release for a specific user group) with a shorter iteration cycle. Feedback from that version can be incorporated before the new site is fully developed. to plan

Please

design development

The plan

Please

Deploy the Deployment Beta

Build version extension

Figure 4.5 Modified beta cascade

Note the small iterations in the design phase in Figure 4.5. This is one of the greatest values you bring to your team as a UX designer. Tools like wireframes (Chapter 11) and prototypes (Chapter 12) allow you to gather feedback on rapid iterations of ideas before too much development time is spent. A modified waterfall approach, such as the one shown in Figure 4.5, is among the most commonly used methods and is therefore the scope of this book. However, many of the topics discussed here will apply to your project, regardless of the specificity of your approach, as the key activities behind them – such as definition and planning – are still required.

Deep Dive If your project uses an Agile approach, you will have unique requirements gathering needs, such as writing “user stories” to capture requirements. We recommend Mike Cohn's Applied User Stories: For Agile Software Development (Addison-Wesley Professional, 2004).

UNDERSTAND THE PROJECT APPROACH

How will the approach affect me? If you know your approach, you can better understand many things: what questions to ask and when. For example if it's you

If you are working with a pure waterfall approach, then you need to put extra effort into ensuring that the requirements captured in the definition phase contain all the information needed for the design phase. (We'll discuss requirements in the next chapter.) Expectations for project team members to work together and how

This cooperation will be close. For example, an agile approach requires very close collaboration. A waterfall approach might involve most of the time working one-on-one with touchpoints one or more times a week. The level of detail and level required in your documentation

Text. The documents submitted to the signing offices must be formal, almost like legal contracts. Typically, you need more formal documents in a waterfall approach that require a signature before moving on to the next phase. However, you can also have some formal signature documents when using an agile approach - for example, to receive input at key decision points, such as when preparing a specific iteration for full release and deployment. Key milestones that require stakeholder approval and

development in different groups. The approach determines what different audiences need to provide at different points in the project, including stakeholder approvals at connection points and feedback from potential users during a beta. Now that you've solidified your project objectives and gained an understanding of the project's approach, we begin the main work in the Define: Requirements Gathering phase in the next chapter.

CHAPTER 4: PROJECT OBJECTIVES AND APPROACH

Business needs: Know the problem before developing the solution. By the time the project team is assembled, you will likely have heard or have 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 (your potential customers) along with their opinions on which features are most important. These are elements of the project's business requirements and are a good starting point. To ensure you have a complete solution at the end of the project, you need to create and clarify requirements from multiple perspectives. In this chapter, we focus on gathering and detailing the needs of your prospects. Carolyn Chandler

Again

Chapter 4 covered vague goals and discussed some ways to clarify them for you and the project team. In the early stages of a project, you are likely to have relatively vague requirements. These could be stakeholder ideas, user complaints, or user requests. To create these useful and traceable elements of your project, you need to combine these ideas into requirements. Requirements are instructions that specify what the site or application must do. Ideally, a business requirement provides information about the overall need that needs to be addressed. It represents and unifies the needs of different interest groups. It sets a direction for the design without being too specific about how it will look.

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

Here is an example of an idea for a feature on an e-commerce website. You can get the same idea from a few different entrepreneurs early in the define phase: “Customers can track their orders online.” That's a good basis for a complaint, but it's vague. Start by asking questions about the specifics of the requirement, such as why is it important to the company that customers can track it

Online ordering? For example, is it about reducing the number of calls to customer support? Does the company have the ability to track packages online?

If this is not the case, new requirements for monitoring functions must be documented or the company may have to work with a third party. How accurate should the tracking be? what kind of information

Should it be included in the tracking details? For example, should the website provide an up-to-date estimate of delivery time? By asking these types of questions, you can turn vague ideas into concrete requirements. It also shows that the same statement can mean different things to different people.

CHAPTER 5: BUSINESS REQUIREMENTS

For example, a stakeholder may believe that tracking packages involves receiving a confirmation email from the stakeholder's idea with a tracking number that can be entered on UPS.com or another website for the stakeholder's idea to be interested party can see where the package last arrived. Idea Another stakeholder might think that the company should take parcel tracking to a new level and invest in developing the ability for customers to track parcels via GPS and see exact location in real time using an online map. As you can imagine, there is a significant difference in user experience and scope here! It is important to explain these differences early in the project. Otherwise, you'll end up developing a solution that ignores the intentions of business stakeholders—and potentially fails to meet project goals. This irritates stakeholders and, if the function needs to be re-engineered, a waste of time and money. Therefore, clear and detailed requirements are an essential part of your overall project. Accessing a consolidated list of project requirements involves the following steps: 1. Understand the current state of the site or its competitors. 2. Gather needs and ideas from potential customers and current and potential users. (See Chapter 6 for more information on working with users.) 3. Consolidate ideas into requirements. 4. Prioritize requirements based on project goals. (See Chapter 9 for suggestions on how to prioritize.)

Business and user requirements, project requirements, corporate strategy

Figure 5.1 Merging ideas from business perspectives into business requirements and user research ideas into user requirements. Then use project goals to focus your prioritization efforts and create a unified list of project requirements.

BUSINESS REQUIREMENTS

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

Understanding the Current Status When looking at the specifics of the website or app you are designing, it is important to first understand the current status of the website (if you are redesigning an existing one) or better understand your main competitors (if you are redesigning a new website or app ). You can learn a lot about the current situation through stakeholder interviews (more on that in a few pages). You can also gain a lot of understanding for yourself, and this can serve as a solid foundation for stakeholder interviews and user research efforts. A good way to get background information and generate ideas that can become requirements is to perform heuristic analysis.

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

Heuristic analysis Heuristic analysis is a technique you can use to evaluate the usability of an existing theme based on user experience best practices. You can perform this analysis at the start of a redesign project on your current site, or you can review competing sites to identify opportunities to provide a better user experience than other companies. The result is a document that outlines the site's strengths and weaknesses and includes recommendations for improvement. Once done, you will have a deeper insight

CHAPTER 5: BUSINESS REQUIREMENTS

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

Visibility of system status. The system should always inform users of what is happening, providing appropriate feedback within a reasonable time frame.

There are many instances on a website where this heuristic might not be followed. Suppose the user clicks the Download button and does not receive a message that their file is being downloaded. The system did not inform the user that the file is being downloaded, even though the download has started. That way, the user can click the button again, thinking they missed the button the first time... and then click again... This can result in multiple downloads - and potential problems for the site's performance and also for the user who now performs multiple downloads without you noticing. During the heuristic analysis, you can mark the area as a problem area, describe it and assess its impact. You can also share an idea to solve the problem that can be added to the requirements list. Why Heuristic Analysis? Performing this type of analysis is a relatively quick and inexpensive way to get feedback on a project. Heuristic analysis can provide an overall understanding of design quality and help identify potential design issues. Please note that this activity is not directly related to end users and should not replace actual user research. For example, it is likely that only 50% of your heuristic findings can be validated by subsequent research. However, the analysis gives the team a good overview of potential problem areas. If you're working on redesigning an existing product or website, it can also be helpful to identify obvious quick fixes that can lead to immediate improvements while redesign efforts continue in the background.

UNDERSTAND THE CURRENT SITUATION

How do I do it? The specific heuristics you use may vary from project to project, but the process for performing the analysis generally remains the same: 1. Gather knowledge about the product and project history. Make sure you have the site's goals, a list of the main user groups you intend to support, information about the type of environment your users are expected to work in, and a basic understanding of the experience your users are likely to have. (For example, your analysis will differ on a site designed for general consumers versus a site designed for pharmacists, for example.) If you need help with the latter, visiting several competing sites or apps can help you understand the terminology most common and areas of interest. 2. Choose the heuristic to be used. There are too many heuristics to refer to. In addition to Jakob Nielsen's list, many UX designers consult Bruce Tognazzini's list of design principles: www.asktog.com/basics/irstPrinciples.html. Once you're familiar with the site's topic, you can add some of your own - especially if you're reviewing more than one site. Make sure your list is a manageable size (eg 8-12). Too many heuristics can make the technique cumbersome for you and your readers. 3. Examine the priority areas of the site and identify areas where heuristics are well followed or missed. Each observation you make should include the following information: The general observation. A brief explanation summarizing the conclusion. Ideally, they are numbered for quick reference as you go through the people in the report. A brief description. One or two paragraphs describing the context of the observation - for example, the point in a specific process where you noticed a problem. impact rating. This rating can be high, medium, or low for notes of issues, or it can be a positive discovery when sharing something the site did well. In general, high-impact issues are issues that you believe will cause many users to fail or fail to complete a specific task.

CHAPTER 5: BUSINESS REQUIREMENTS

Information is permanently lost (for example, an issue that causes a user to lose changes to a document they were editing); Medium-impact problems are those that cause frustration and errors, but do not cause irreversible problems. Low-impact issues are small issues that can be confusing, but usually don't result in wasted time or frustration. Recommendations. These are next steps or ideas you share that might serve as a solution to the issue you are facing. Figure 5.2 shows an example of these elements together, as they might appear in your heuristic analysis. Note #4: The search function doesn't seem to return all possible results.

high anxiety

A sample test of the search function produced mixed results. Searches for a name on a relatively recent post that included a less frequently discussed topic occasionally returned no results. It also appears that the main search only returns links to new stories and no videos. Recommendations 1. Make sure newly added content is indexed and searchable before or shortly after it is made publicly available. 2. Consider showing related content when search results come back—for example, stories in similar categories or with similar tags—so that browsing users have more topics to follow. 3. Explore the global search that displays results organized by categories. 4. Use search term logs to understand the most searched items. This can also provide information about items that users find difficult to find.

Figure 5.2 An example of an observation in a heuristic analysis report

4. Present your findings to the project team and key stakeholders. Look for their comments and recommendations. Discuss why you left the ratings you gave. (This is also a good time to have a recommendation ready to validate your results using one of the techniques discussed in Chapter 6.) How does heuristic analysis help with requirements gathering? Once you've completed your heuristic analysis, you'll have a deeper understanding of the current state of your site (or that of your competitors) and a list of ideas that can help capture the requirements. You'll also get some ideas for structuring the topics you need to cover in your requirements gathering sessions - which brings us to the next step in this process.

UNDERSTAND THE CURRENT SITUATION

Gathering Insights from Stakeholders As we saw in our example at the beginning of this chapter, if you don't have context for an idea like "Customers can track their orders online", for example those of our friends who want their packages to be tracked with GPS . One of the most common mistakes made on a project is to take a feature and call it a requirement without first understanding the problem and what is expected of a solution. Why is the claim recovery process aborted so often? Gathering ideas – and merging them into requirements – can take a little time. It's easy to underestimate the number of questions you need to ask to describe requirements so they can be prioritized. And if the process isn't well structured or there's a lack of involvement, there can be a significant disruption that can stretch across the entire project. (Chunk is time lost in extra meetings and work iterations caused by lack of communication and engagement. This is different from the more productive work iterations that are part of designing and testing valid solutions to find the best solution.) How and how to promote a solution. Balanced requirements process that focuses on business needs but avoids insensitivity? Here are some steps to an effective process: 1. Describe roles and responsibilities. Make sure project team members understand the roles they must fulfill when collecting requirements. 2. Bring the right stakeholders together in the right groups to ensure optimal use of time during interviews or requirements focus meetings. 3. Create a meeting plan, including topics to be covered and questions to ask during the meeting. 4. Conduct meetings effectively, capture ideas and seek clarification. Discover ideas to determine the needs behind them. Once your meetings are complete, don't forget to thank stakeholders and update them on progress after moving to a consolidated list of priorities. Let's take a look at each of these steps.

CHAPTER 5: BUSINESS REQUIREMENTS

Description of Responsibilities When gathering business needs, project team members with key business stakeholders are often interviewed to gather ideas. Business stakeholders are those within the organization who have a business interest in the success of the project, or have expertise to contribute, or both. These people are not involved in the project full-time, but they need to be involved at key points in the process, and requirements gathering is one of those points. Consider that they also have a daily wage (so to speak). As such, their time is precious and often hard to come by if you don't plan ahead. The project sponsor (or sponsors) is the business stakeholder who also has direct responsibility for the success of the project, often at a relatively high level in the organization, such as the manager. He or she will not be involved in the project on a daily basis throughout the project lifecycle, but will likely be actively involved in gathering requirements and ensuring a high level of buy-in from business stakeholders. The sponsor may also attend some or all of the meetings. The project team includes people officially assigned to the project as ongoing resources. You could be a project manager, UX designer, business analyst, technical lead, visual designer, quality assurance lead, etc. Depending on the size of the project, this could be your main task. Within the project team itself, responsibilities for requirements gathering are often unclear. If you take the time to define responsibilities early on, you can ensure an efficient assembly process. Here are some questions to ask when determining the specific responsibilities each team member will have in gathering requirements: Who will have primary responsibility for gathering and scheduling the right work?

Stakeholders in the most productive groups? This can include internal and external stakeholders (such as partners, suppliers, etc.). Who creates the structure of topics and issues of business interest?

owner meetings? This is a great teamwork exercise for the team, time permitting. The lead moderator can then bring them into a structure that fits well in a meeting. Who moderates the meetings? Who takes notes and how are they shared?

COLLECT Stakeholder IDEAS

Who follows whom to follow? Will someone from the technology team be present at all meetings?

If so, how is that person involved (listening, providing information, or otherwise)? Whether or not you are primarily responsible for one or more of these areas, as a UX designer, you have important skills to bring to the table. Creating a structure for topics and questions requires the ability to clearly categorize (which sounds like a good combination with information architecture) and, of course, facilitation skills are important for keeping the meeting on topic and engaging everyone present.

Gather the right stakeholders. The main objective of the stakeholder interview is to understand the relevant ideas, needs, knowledge and frustrations related to the project from different perspectives, which can then feed into the project requirements. There is also the sometimes unrecognized benefit of involving many different groups so that everyone feels they have a say in the project - and thus will be involved in the final solution. While getting people's approval may seem more political than practical, it's often an important step that puts you in touch with a network that will support you throughout the project. It can also help you avoid last-minute changes that can occur when someone you haven't spoken to raises an issue late in the process. Therefore, it is often a good idea to involve a variety of different people. On the other hand, schedules and budgets must be taken into account. Onboarding large numbers of people requires time, both from their perspective and yours, just for meetings, not to mention time sorting through notes to identify trends and consolidate redundancies. For the sake of efficiency and your own health, it makes sense to prioritize the groups you speak with and select key individuals from those groups to act as thought leaders for the group. What potential stakeholders could you include? These groups are often good sources of ideas: groups with local initiatives (for example, those with

Marketing campaigns that require the presentation of information on the website)

CHAPTER 5: BUSINESS REQUIREMENTS

Teams that need to support processes directly behind the site or

Application, how to provide content, enter and manage data, and quickly respond to collected information. Frontline customer service, such as phone or online support, or

Anyone dealing with customers in person (for example, in a retail store or through deliveries), sales, product management, or consulting to represent them

featured products and services. Human resources to achieve recruitment goals. Public relations to present information to investors and the media. All teams responsible for other relationships that need to be developed

As part of the project, this affects your design, such as relationships with partners or vendors. When choosing who to involve, get help from the project sponsor and any project team members who are familiar with the groups involved in selecting the right people. Form groups where there are good discussions. There is no right way to do this, but a common way is to group stakeholders by department as follows: Marketing (five people), Product Management (four people), Customer Support (two people), Sales (four people ).

On a smaller project, one person from each of these groups might be involved in a series of two or more collaborative work sessions where everyone comes together. Once you have your stakeholders in mind and an overall structure for your meetings (see the next section), you can start planning your meetings. Try to start planning at least a few weeks in advance. It can be difficult to get everyone in one room.

COLLECT Stakeholder IDEAS

Make a plan for meetings. In addition to trying to select the right stakeholders, make a list of topics to cover and questions to ask (this will also help you refine your stakeholder list). You should have a different plan for each group you meet with, although many of your questions may be the same from group to group. You also need to determine the level of detail you want in your meetings. If you're meeting a large number of people just once (for example, members of different departments, as suggested above), you might want to brainstorm ideas, but you probably don't want to spend too much time going over key details during the meeting. In that case, if a potential customer gives you the idea that "customers can track their orders online", you might just ask why this feature is important and whether the prospect might fool himself into thinking he's doing well. on a website. These questions will help highlight key differences between stakeholders' expectations of the feature, without spending the entire meeting on a single statement. You can work through the idea-specific details with the project team, collaborating with the stakeholder to ensure that the requirements created still reflect the original idea. Let's say you're redesigning an e-commerce site and meeting with a variety of stakeholders, hosting a meeting with each group. Here is an example of a meeting agenda with a team from a sales department.

Sales: Inside Sales Requirements Meeting Participants: Jenny Bee, Tracy Kim, Joseph Arnold Leaders: Kevin Abernathy, Cat Parnell Timeframe: 2 hours Objective: Understand your current sales process and identify issues and opportunities to better support that process. Context: We saw a PowerPoint presentation on the buying process that provides a good background on how purchasing decisions are made. We also plan to speak with the customer service team.

CHAPTER 5: BUSINESS REQUIREMENTS

Sales: Continuation of service and requirements gathering. Sales Process Questions: How does the sales process differ for different product lines? Are there regional differences? Are there differences based on customer size (eg, small businesses versus large businesses)? How has this process evolved over the past two years, and how will it likely evolve over the next three to five years? How does a potential customer understand all the things that need to be bought and how do they all work together?

Overall Impression: Who do you think are the top visitors to your current site? Why; How is that exactly? What do you want to achieve with the website? How is the Internet contributing to the sales process and/or sales conversion rate today? What information do customers need to make a purchase decision? Is this information available on the website today? is it easy to find? Is correct? How difficult is it to maintain website content today? What metrics are you getting from the site? What additional metrics would you find valuable? Why;

We look to the future: what could we do to better support the sales process if you are considering a local future? What current functions and features on the site are critical for sales? What is not necessary? What is missing?

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

COLLECT Stakeholder IDEAS

Conduct meetings effectively. Here are some practices to help you with requirements gathering meetings. Make sure a common vocabulary is used. Much confusion can be avoided if the groups agree on a common list of terms and definitions for the requirements. Are the people using the system named, for example, users, customers or customers? Are the terms interaction designer or information architect better known? To avoid confusion, take some time at the beginning of each meeting and explain what term is being used and what it means. You may also find it helpful to create some visuals that help explain the relationships between different terms or functions (see Figure 5.3). category

Category

subcategory

Article

Figure 5.3 Diagram showing project conditions and relationships

A common vocabulary for the deliverables to be used in the project will also help stakeholders understand the process and type of expected deliverables. This can boost confidence that your time and effort isn't bogged down in a black hole of ideas. In general, if you find yourself defining the same words more than once or twice (especially if you find that the definitions change slightly each time), consider putting them in a project glossary and sharing it with the project team division. . Other examples of terminology that should be clarified at the beginning of the project are:

CHAPTER 5: BUSINESS REQUIREMENTS

Roles that interact (e.g. job seeker versus customer or

Stage Producer vs. Editor) Primary deliverables that need to be commonly referenced (Functional Specification

tion, wireframes, sitemap) and a brief description of their differences. Distinctions between different levels of information (eg, our category).

Information in Figure 5.3) Distinction between needs and expectations

Listen to ideas and respond to needs. Stakeholders can make statements that appear to be needs. Consider an example. business lawyer

"We need a blog on the site."

This is really an idea, not a necessity. Then, when the blog functionality is fully conceived and implemented, it becomes a solution, but not necessarily the solution that best meets the basic needs of the stakeholders requesting it. If you ask why a blog is important, you can get a wide range of needs statements, such as “We need to be relevant and outreach”. include them. "We need a way to get people to revisit the site to generate more ad revenue, and blogs mean newly published content with a following." Demonstrate expertise." "We need a better way to communicate and innovate with our customers, and our blogs take feedback so we can hear your thoughts.” Each of these statements describes valid needs. By citing them, you'll learn more about the drivers behind specific feature requests, helping to build consensus by consolidating and prioritizing requests.

COLLECT Stakeholder IDEAS

Merge requirements When the meetings are over, sort the collected ideas into broad functional areas. You will notice a lot of overlap. This is a good sign that stakeholders are interested in a specific idea. Avoid redundancies and try to consolidate a list of ideas that effectively reflects the intentions of your stakeholders. In order to transform the collected ideas into useful and understandable elements of your project, you need to combine these ideas into requirements. Consider raindrops forming from a cloud: they move from a large, undefined cloud to a larger number of well-defined raindrops. So when you get a cloud of ideas like "customers can track their orders online", you need to turn them into discrete statements that define what the system is supposed to do. The resulting requirements should provide information about the general needs that need to be addressed. Represent and integrate the needs of different stakeholders. Give design direction without being overly specific about how it will look

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

As you start to move from ideas to requirements, be sure to engage your technical lead (or someone who can represent the development team on your project) to ask questions that will help you prioritize later and estimate the effort required. If you have a dedicated QA team member, that person can also ask some detailed questions to gather the requirements. To break down your tracking idea into requirements, ask questions like: How accurate should the tracking be? What information should be included in the tracking details? For

For example, should we provide an up-to-date estimate of delivery time? These questions can be asked and discussed at length with the stakeholders who gave you the initial idea, if they spend significant time on the project. If you don't have much access to these stakeholders, you can work out the details yourself by talking to the project team.

CHAPTER 5: BUSINESS REQUIREMENTS

You then discuss the requirements with the project sponsor to ensure your decisions make business sense. Table 5.1 lists the types of requirements that can be combined using the monitoring concept and how you can capture them. TABLE 5.1

Example business requirements

I WENT

AREA

shipment tracking

APPLICATION

BUSINESS REQUIREMENTS

Orders can be tracked by

encourage self care

entering a tracking code

on delivery (support

in connection

accessible)

Users can track their package-

Show innovation in action

Guy with GPS tracking trucks

accurate delivery (competitive

or planes

accessible)

Users can see all previous orders placed in the last 365 days. Encourage new orders

Self-service (sales, support services)

Note that in some cases the requirements overlap, as in the case of the first two requirements in the table - both are monitoring methods. You can live together on the same system as you can enter a code to locate your package through the GPS view. However, they are separated because the GPS-related requirement will likely be a higher overhead and should take precedence regardless of the other features. When consolidating claims, consider business needs that you think may conflict with user needs. For example, a business need might be to collect personally identifiable information from potential customers, such as email addresses. However, customers may have reservations about providing information. After all, filling out the forms takes time, security and privacy are an issue, and this step can interrupt the larger work they are trying to do. Identifying conflicts like these provides information that can help you meet business and user needs. For the tracking example, you can suggest using the Send to a friend feature to collect the email address and make it easy for the user. This means sending to a friend could become a requirement you consider prioritizing. ideas like this

COLLECT Stakeholder IDEAS

One can help meet business and user needs, making them perfect for capture. You also live at this intersection between the Define and Design phases (see Chapter 4) because you start to think about design solutions to business problems.

Developing Theme Definitions Potential conflicts between business and user needs are big things to explore in user research, and we'll discuss these in the next chapter. Using user search, you can also expand Table 5.1 to a complete set of possible requirements that are prioritized in a project requirements list (shown in Figure 5.1 and discussed further in Chapter 9). Remember that gathering business needs is often done in parallel with exploring technical possibilities and gathering user needs. Next: time to talk about users!

CHAPTER 5: BUSINESS REQUIREMENTS

User Search Know the guests you invite to the party. There are many user research techniques that can be used throughout the project lifecycle, whether to better understand your users or to test their behavior across versions of a site. This chapter focuses on some of the most commonly used methods in the early stages of a project. These techniques will help you define which groups of users should be given top priority during the project, put their needs and frustrations into context, and evaluate the current site's performance (if any) using best practice user experience design benchmarks. Carolyn Chandler

Basic User Research Steps 1. Define your key user groups. This includes creating a framework that outlines the main types of users you're designing for, so you can focus your efforts on recruiting users for search. 2. Plan user participation. This involves choosing one or more techniques to engage groups of users in research based on your project's needs. 3. Conduct the search. Here, we cover basic techniques such as interviews and surveys and provide tips on how to use them. 4. Validate your user group definitions. With the insights from your research, you can solidify your user pool model. This model then serves as a platform for developing more detailed tools such as faces (see Chapter 7). 5. Create user requirements. These are statements about the features and functionality that the site may contain. You add these statements to your business needs (see Chapter 5) and prioritize them to become project requirements (see Chapter 9). This chapter covers the first three steps, starting with the first: defining your user groups.

Define your user groups. Planning user research at the beginning of a project can seem like a chicken and egg dilemma (which comes first?). How can you be sure you're talking to the right people when you don't know who those people are yet? One way to start is to create an initial or preliminary definition of the users you want to design for. Your site's main user groups are described here. This can help you focus your research efforts on the right roles, demographics, or other variables that can affect users' experience on your site. User group definitions can be high-level (a list defining each of the target user groups) or detailed and visual (a graph showing many types of users and how they interact with each other).

CHAPTER 6: USER RESEARCH

A general definition for a company's .com homepage might include the following user groups: potential buyers, current buyers, partners, and job seekers. As you begin to define groups for user search, start prioritizing groups of users in more detail. Its initial definitions are based on the collective knowledge of business stakeholders and project team members about the likely types of users who might interact with the site. These definitions can be created by capturing some of the goals and characteristics of different user groups. Here are the basic steps for defining your user groups: 1. Make a list of characteristics that will help you define the different users of your site (the next section covers some of the more common users). 2. Discuss roles with those in the organization who have exposure to relevant user types (eg customers). 3. Prioritize the features that seem to have the biggest impact on why and how a potential user would use your site or app. 4. Identify user groups to focus research and design on. In the sections that follow, we'll take a closer look at some brainstorming techniques to help you collect these resources, prioritize them, and model them (creating representations of different types of users to help you focus your research efforts).

Creating a Role List A good starting point for your role list is to collect and process any research or other documentation from your organization that might provide guidance to users. Here are some possible sources: Documents that explain corporate strategies, such as B. Company objectives,

Things to know, marketing strategies and business plans. Current customer market segments and other demographics

User research collected by the marketing department in the past (see Table 6.1 for some examples)

DEFINE YOUR USER GROUPS

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

Next, identify people within the organization who have visibility into current or potential users. The number and variety of people you should involve will depend on the type of project, its scope and timeline. If you know that your initial user groups might be short-lived (for example, just for a month or two while the user research is being designed), you might only involve two or three participants. If you feel that the original definition might need to keep you busy during much of the design process (for example, you can only work with it until you do usability testing after part of the design is complete), see Bring in other participants and make sure you have a cross section of prospects. Potential participants include the marketing team responsible for branding, targeting, and campaigns. Sales team? Product managers, customer service or support representatives, and trainers. It is also a good idea to involve project team leadership and other business stakeholders in this exercise. Ask the team to think about the different types of potential users they tend to interact with. Then ask them to list some of the common traits they found. Here are some examples of what might differ: Main goals related to your site's theme. Because is

Which users create it and what do they want to achieve? For example, common goals include buying an item, trading a stock, or answering a specific question. Clock. This can be defined in several ways, but one of them is to associate the roles with the

the primary purpose of the user: job seeker, support requester, prospect, etc. After getting more information from the user, the functions can be divided according to different needs or styles. For example, on an e-commerce site, shoppers might include bargain hunters and connoisseurs. Demographic information, including age, gender, family (single, married, children);

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

Technologies (often referred to as technical expertise), level of expertise, and frequency of use (once, occasional, frequent). 88

CHAPTER 6: USER RESEARCH

Organizational characteristics, including the work size of the company's users

for your department, type of work (entry level, freelancer, middle management, executive), stability (long term or high turnover?) and work patterns (remote work, travel). Once you have a list of some of the traits that come up most frequently when stakeholders describe potential users, you can start to prioritize them based on their level of importance, and then use that hierarchy to start define and model user groups.

Prioritize and define Which of the above features do you think have the greatest impact on how and why different groups of users can use the site? Focus on the ones you believe will have the greatest impact on a user's goals or behavior. Prioritize these attributes and remember the goals you created in Chapter 4 - they will also help you with your decisions. An example further illustrates how features are prioritized. Let's say you work with a company that provides tools for trading stocks, options and futures online. This particular company has decided that part of its strategy will be to attract non-professional stock traders online and encourage them to try trading new types of products such as options and futures. The company plans to achieve this by providing easy-to-use trading tools aimed at those who want hands-on learning in a safe and secure environment. When discussing the features with potential customers, you may find that the following seem to have the biggest impact on how people might use these tools: Current frequency of transactions, particularly frequency of direct online transactions

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

futures contracts. Those who already market all types of products may already prefer their own tools, but those who only market one type may be willing to switch to other products. DEFINE YOUR USER GROUPS

Level of professional competence (eg, familiarity with the trade).

Conditions). Tutorials and glossaries help you determine how much help you need along the way. Level of technical knowledge (e.g., familiarity with purchasing).

online and online banking and transactions). This affects how much security they need in terms of privacy and how advanced or simple the online interface needs to be. You can prioritize these characteristics as they can influence the type of user you want to search for. If traders' location doesn't seem to have any real impact on how or why they trade, the "region" attribute could be removed from the list as a criterion for survey participants. On the other hand, if the importance of a specific feature generates a lot of discussion, it might be a good topic for a poll or interview (we'll talk about polls later in this chapter).

hoch

Comparing two or more resources can also help you prioritize. For example, if you create a chart with two attributes for online marketers, you can see how the groups stack up in some of the areas. Figure 6.1 is an example of a high-level user model that you can build using the two attributes frequency of direct trades and number of product types traded. The resulting user groups that can be formed from the discussion are also displayed.

Full-time product specialists

I understand general things full time

Frequency of Direct Transactions

"Secondary" trader.

Supplementary Income Merchant

active explorers

Long Term Investors

Low

Dumbler

Low

hoch

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

CHAPTER 6: USER RESEARCH

Figure 6.1 A graph of two resources representing a high-level user model. Building this model together can facilitate discussion of possible differences in user motivation and experience.

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 exclusively target groups of users (a user may be a long-term investor in equities and also be actively exploring other opportunities in options or futures). But it begins to express your understanding of different user groups and how they can be motivated to use your site. This discussion of key features will also help you figure out which ones to focus on when recruiting users for search. If you come to the conclusion that trading frequency is important and that the priority is to reach those who currently have an average frequency, you should define what average frequency means (for example, one to three times a week) and recruit participants Adjust your search accordingly. Speaking of research, let's talk about techniques you can use to engage users in your project.

Can you design yourself using user models? In the user experience space, there is debate about creating user models before conducting research, as this can influence your thinking before you have actual user data and because your project team or project sponsor can see the template as a replacement for user search. Using an unvalidated model carries a greater risk that your assumptions are wrong. However, for projects where you don't have any user contact, a well-designed template (verified with sources outside the project team, such as customer service or training staff) is better than no template to use during design. .

Choosing Research Techniques Now that you have a rough idea of which user groups you want to involve, it's time to plan the next step: your recommendations for the amount and type of user research activities that will take place during the project. Table 6.1 provides some information about the most commonly used search techniques and when they are most useful. Use this chart as a reference to choose which ones are best for your project. The next section describes each technique in more detail.

CHOICE OF RESEARCH TECHNIQUES

TABLE 6.1

Common user research techniques

ACTIVITY

WHAT IS IT

IF USEFUL

CHALLENGES

TYPICAL TERM *

user interviews

A one-on-one chat with a participant from one of the main user groups on the site.

User access is available, but the type of access (personal, telephone, etc.) varies.

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

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

Contextual investigation

On-site visit with participants to observe and learn how they work in their normal day-to-day environment.

The "Get Access" project team has little information about the participants. Next are target users. in the users' environment may raise security concerns, of an intellectual nature (for example, a hospital), in users working in a unique environment. Property and trespassers act sensitively. For companies with relatively complex applications, tasks or workflows are accomplished. Visiting on a weekday might be easier.

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

investigations

A series of questions consisting primarily of closed-ended (multiple choice) answers designed to identify patterns among large numbers of people.

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

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

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

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

CHAPTER 6: USER RESEARCH

Obtaining an adequate sample. Make sure the questions are well worded to get accurate answers without misleading respondents into a specific answer.

TABLE 6.1

Common User Research Techniques (continued)

ACTIVITY

WHAT IS IT

IF USEFUL

CHALLENGES

TYPICAL TERM *

focus groups

A group discussion in which a moderator guides participants through questions related to a specific topic. The focus is on revealing the participants' feelings, attitudes and ideas about the topic.

The team assumes that user behavior has a strong influence on the use of the solution (for example, whether there have been problems with it in the past).

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

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

ranking cards

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

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

Determine which topics are best included.

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

Usability Tests

Users try to perform standard tasks on a website or application, while a moderator observes user behavior and, in some cases, asks questions to understand it.

An existing solution is improved.

Choosing the right tasks to focus on.

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

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

Effective team moderation.

Determine how formal the test will be.

* Typical time period represents the time it often takes from where users are scheduled to visit. Two groups of six to eight users are considered (except for surveys in which the number of users must be greater). This does not include recruitment time, which can take a week or two after completing the screening questionnaire.

How many research activities can I include? Before deciding on an activity, ask yourself how much money and time the team can dedicate to user research. Consider the following scenarios to understand how passionate your client company is about user research. If project leadership and project sponsors are familiar with user research and are interested in using it for known purposes, such as ensuring the site meets specific project goals, they likely have more search techniques to choose from.

when planning two or more activities or for an activity you do multiple times (for example, trying out a plan, changing it based on the results, and trying the new plan again). If no one in the organization is familiar with user research and there is some general resistance to it, it might be best to propose a round of research and select the technique that you think will bring the most benefit to you, the project team and other stakeholders. of business. Once you have the survey results, the project team will have a better idea of what is at stake and how it can be useful for the project. You'll have a good case for doing more research later if necessary. If you have room for at least two rounds of research, a good approach is to include one round in the definition phase or early in the design phase to better understand your users. Then, before starting the deployment, add another round to validate the design. For example, with a task-based app, you can survey users before design and usability test a prototype later in the process. With a content source, you can also start with contextual research and then create a card sorting exercise.

Survey planning considerations When planning a survey technique, consider the following: Why you are conducting the survey: What do you hope to learn from the survey Who do you involve: the key user groups described above How do you attract participants: Recruit people to participate and track them (i.e. ask questions to make sure they fit the user groups you are targeting). How to reward participants. What space and equipment do you need. What you cover: The main topics. How you collect information: the number of participants and the tools they use. Chapter 13 covers all of these considerations as part of an in-depth look at one of the techniques most used by UX designers: usability testing.

CHAPTER 6: USER RESEARCH

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

Surfer Steve Baty wrote an article describing different methods and how you can choose between them depending on your stage of development, information needs and the flexibility needed to incorporate user research. The title is "Bite-Sized UX Research" by Steve Baty, UXmatters: http://uxmatters.com/MT/archives/000287.php.

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

User Interviews User interviews are structured conversations with current or potential users of your site. This can be over the phone, in person at a neutral location (for example, a conference room) or, ideally, in the environment where the user expects to use the site. (This last situation is also great for conducting contextual research, which is discussed below.) Interviews help to understand participants' preferences and attitudes, but should not be used to make formal statements about actual performance. If you're looking for specific information about how people interact with a website, the best way is to observe them as they use the website (for example, in contextual search) or ask them to perform tasks on the website (in usability testing). . Site analytics can also provide insight into specific performance insights that can be particularly meaningful when combined with interviews or surveys that provide context for the data. The Basic Process For user interviews, the UX designer creates a list of questions aimed at eliciting information such as: Relevant experiences with the site or topic

CHOICE OF RESEARCH TECHNIQUES

The company brand experienced by the participant. Settings, for example, in relation to the thematic categories covered (ex.

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

Competitor Common next steps users take after visiting the company's website Other people involved in the experience. can for example

Is the user likely to collaborate with someone else as part of the larger goal they want to achieve? Are they likely to pass along information or seek inspiration from others along the way? Any other information to help you validate your assumptions

about user groups up to this point - for example, when the variables you discussed when creating a temporary user model really seem to affect how users experience your site. If more than one person is conducting the interviews, it's a good idea to have a list of questions and an introductory script that you can use to keep the interviews consistent. Decide in advance how the interviews should be structured. If it's a formal report, you'll probably want a high level of structure, where the order of questions doesn't vary too much, and where each question is asked with few additions. If data richness is more important than consistency, you might opt for semi-structured interviews, where you start with a list of questions but allow the conversation to flow naturally and the interviewer asks questions to explore more interesting comments (called : detection ). The length of your interview may vary. 45 to 60 minutes is usually the best recording range. This gives you enough time to build rapport and cover a wide range of questions without boring the participant. User interviews provide a rich set of data that you can use to write the personas discussed in Chapter 7.

CHAPTER 6: USER RESEARCH

Interview Tips The quality of information you receive in an interview depends largely on the quality of the questions you ask. Focus on participants' personal experiences. Don't ask them to speculate about what they might do in the future or what others might do. That kind of information rarely predicts what they will actually do. Don't ask questions that imply a specific answer or push a participant in a positive or negative direction. Ideally, questions should be simple, neutral and open-ended. Some examples of key questions are: What do you like about PseudoCorporation.com?

This assumes that the user enjoys using the site. Only use this question if you are also asking what you don't like about her. Is PseudoCorporation.com meeting your expectations?

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

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

If you're conducting large, more formal interviews, you might want to include some multiple-choice questions. However, in most cases you will not get very comprehensive information. Oral questions can be difficult for participants to follow and do not allow users to explain. In general, save these types of questions for screening or research. Test it out with someone, perhaps someone within the organization who isn't part of the core team. This will help you identify questions that may not be clear and improve your timing and flow. If possible, and if the participant agrees, record the interview so that others can benefit from hearing the responses directly from the participant's mouth.

CHOICE OF RESEARCH TECHNIQUES

Contextual research Contextual research combines user observation with interview techniques. The UX designer goes to the participants, ideally in the contexts where they are likely to use the site. For example, in an office application, contextual search would require sitting at the participant's desk. This method provides comprehensive information about the context in which a participant works, including the problems that users face in real life. The type of equipment they work with. The space they work in - especially the size of the space they work with

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

Your design decisions, especially when designing a tool that requires a lot of data input. How they work with others, both in terms of collaborating and sharing

Resources. For example, if more than one person is using the same computer, the connection design and security features will be affected. Other tools they use online and offline. The way people use paper is

Particularly interesting - for some tasks it can be difficult to design an online solution that competes with paper! The surveys combine observation time and interview time. They can last from a few hours to several days. If participants cannot commit to at least two hours, consider simply conducting an interview. During an observation, it takes some time for the participant to get used to your presence and behave reasonably naturally, and this does not happen after 15 minutes. The Basic Process Prepare a 10-15 minute introduction to use with each participant. It should include the purpose of the research, a general description of what you will be doing together (the observation and the interview), and how the 98th

CHAPTER 6: USER RESEARCH

information is used. This is also a good time to obtain signatures for consent forms and to reassure participants that what they are sharing will remain confidential. Start with some general questions about standard attendee processes, particularly those related to site design. Let the participant know when you're ready to stop talking and start observing. Observation can range from active to passive. In active observation, a common approach is to have the participant assume the role of the teacher while you assume the role of the student. The master explains what he is doing as if he were teaching his process. Active observation usually provides more information about the reasons for the participant's behavior, but it can influence the participant's course of action. In passive observation, encourage the participant to pretend you are not present. Your goal is to observe behavior as natural as possible. For example, if an attendee is talking to you, they're less likely to take a call or ask someone a question about a problem they're trying to solve, but if you watch passively, they're more likely to see it as it happens. Then, during the interview portion, you can ask about the reasons behind some of the behaviors you observed. Both approaches can work well. Generally, if you don't have a lot of time with participants (for example, only 2-4 hours each), you can opt for active observation to ensure you have the depth of information you need. If you have a full day or more, passive observation provides a good balance between physical behavior and conversation. Once you get the information from your queries, you'll have a lot of valuable data to sort through! How do you identify patterns or trends in your results? One useful way is through a technique called affinity diagrams. There are many resources on the subject, but here is a brief description. A Quick Guide to Creating Correlation Charts A correlation chart is the technique of grouping a number of disparate and separate items (for example, user statements or researcher observations) to form patterns and trends. Here are the steps for a simple relationship chart session: 1. Gather the research team and their notes.

CHOICE OF RESEARCH TECHNIQUES

2. Give each person a packet of sticky notes and ask them to write an explanation on them along with an access code that you can use to trace that statement back to a participant, for example B. in your initials. Focus on statements that seem to relate to the design of the site, whether specific (a statement about a feature) or more general (a statement that reflects the participant's attitude toward the company or item). 3. Let everyone hang their sticky notes on the wall. If you're working in a big office, you'll need a big blank wall. Try to get one that you'll have access to for at least a few days. 4. Once all notes are complete, start grouping similar statements side by side. This part of the exercise can involve the largest group. It's a great way to start sharing results. 5. Once groups begin to form naturally, start labeling them to provide additional 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 searching, but it can be applied to many other situations as well. For example, it's a great way to collaboratively categorize unclassified topics to send your card sorting results to additional levels of structure.

Patterns can emerge in many ways, so it's best to let them emerge on their own. However, here are examples of the types of categories you might see, including the type of statement you'll find in them: Goals: "I'm trying to clear up any open items before heading out for the day." Mental Models (including Statements that show how users

Mapping External Experience to Internal Thinking): "I use this online tool as my briefcase for things I refer to often but don't want to carry around with me." Outstanding Ideas and Wishes: "I'd like to get rid of it. Hold on

Accidentally moving the entire folder and undoing it takes forever.” Frustrations: “I would ask the helpdesk about this, but half the time they don't

you know what the problem is

100

CHAPTER 6: USER RESEARCH

Solutions: “It takes so long here that I end up having to print

Read the list and work with it throughout the day. At the end of the day, I take care of the results.” Value Propositions: “This tool here saves me a lot of time, if you want to

Change doesn’t take that away!”

Deep Dive The main resource for 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 creating affinity diagrams. For more information about mental models and how to understand them, see Mental Models: Aligning Design Strategy with User Behavior by Indi Young (Rosenfeld Media, 2008). This is particularly useful when working on the information architecture of a content source.

Polls are a set of well-defined questions that are distributed to a large audience. They usually consist of closed questions (e.g. multiple choice questions) that can be easily collected using a tool that can reveal patterns between answers. Surveys are good tools when you want to report results more quantitatively (e.g., "82 percent of respondents who work from home have some type of high-speed internet connection") rather than the open-ended questions used in interviews. . However, you can also get high-quality information about user habits and preferences. In the area of user experience, surveys are often used to measure user satisfaction (with existing websites or apps) or to create or validate user models such as segmentations or personas.

CHOICE OF RESEARCH TECHNIQUES

101

The Basic Process As with user interviews, you don't want to ask questions that require users to make assumptions. Don't ask, "If you had Feature X, would you use it?" Unlike interviews, for multiple choice or yes/no surveys, true/false questions are better and easier to analyze later. In addition, participants can react more quickly. Use surveys when you have questions that are genuine demographic requests, such as: Which of the following devices do you own? Select all that apply. Computer, mobile phone, gaming system such as Xbox, Playstation or Wii

or for multiple choice questions, read the following statements and choose the extent to which you agree or disagree with each statement. Pseudo Corporation customer service meets my needs. Totally agree about. I do not agree nor disagree. I do not agree. I disagree with everything

In particular, questions like the second example are often used as a complement to usability testing tasks. You can use this formula as a follow-up question to find out if participants were disappointed in completing a task. Participants do not always like to express a negative opinion, but are often willing to express one when confronted with a rating system. This brings up another point: surveys are a great complement to other forms of research you might be doing, such as B. User interviews or contextual research. The combination of two research methods provides a more comprehensive picture of the user than either method alone can provide.

102

CHAPTER 6: USER RESEARCH

Navigation If you want a high level of confidence in your results and you have the budget, authoritative tools are available to measure user satisfaction based on ease of use. These tools include questions that have been tested to ensure they won't mislead or confuse the general public. Among the most used are the ACSI (American Customer Satisfaction Index): www.theacsi.org/ WAMMI (Site Analysis and Measurement Inventory): www.wammi.com SUMI (Software Usability Measurement Inventory) : http://sumi. ucc.ie

When creating a survey, consider the following: Who are you targeting?

Use your temporary model to determine this. How you answer the rest of the questions here will make a difference. Which search distribution method gives the best results?

If your main user groups tend to meet in a specific location, you might get more results if you go there and create a worksheet for participants to fill out the paper survey. If your user groups are active Internet users, conducting an online survey for a large number of participants may be the best option. Or you decide that your user group can best be served by phone surveys using a list of current customers. How much time are participants likely to spend on completion?

to look for? If you're providing compensation or if the person will gain some other benefit from filling it out, you can usually create a longer questionnaire - one that can take half an hour to complete. If not, keep it short to ensure users fill it in - think 5-10 minutes. In any case, be sure to give participants an estimate of how long it will take and to let them know your progress as they work (use page numbers like "2 of 4" or indicate percentage complete).

CHOICE OF RESEARCH TECHNIQUES

103

How do you know when to start analyzing data?

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

If you conduct the survey online, the tool you use to collect the data may have options for viewing and analyzing the results. If not, you'll need a method to import the data into your tool of choice. With paper surveys, that means a lot of data entry effort. So make sure you plan for this time.

Focus Groups Focus groups are about bringing together different people from a target group and allowing a discussion with them. The common goals are to gather opinions on issues related to the organization or its brand, such as past experiences, related needs, feelings, attitudes and ideas for improvement. A focus group is a good technique for several purposes: Listening to different user stories. An open discussion is a great way to bring something together.

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

who want to share Ural information and compare preferred tools with others in their interest group. You will often learn about competing sites or services, or get tips for solutions, resources, and support. generate ideas. Although you don't want to create the group yourself

As a designer, you often get great ideas for new features or designs, either directly from the team or by hearing about their workflows or frustrations. As with stakeholder ideas, be sure to trace them back to the core need (see Chapter 4) to make sure it gets addressed. Understand many aspects of a collaborative process. If you are

When designing a process that includes multiple relevant functions and collaboration, Teams can be a great way to fill in the gaps in your understanding.

104

CHAPTER 6: USER RESEARCH

about how people interact. For example, when working with a content source such as an intranet, it can be useful to bring together a mix of people who create, edit and consume the content to see where the process can be improved. There is a lot of debate about the use of focus groups in UX research. It's not a good technique for usability testing (since users often work individually rather than in groups), and sometimes the group setting can unduly influence what participants say. However, when properly planned and moderated, focus groups can yield many insights that will be valuable to you as you plan. Chapter 13 discusses this further in the context of proof of concept. The basic process When writing focus group questions, consider the same tips you would use when writing user interview questions (see above). Start with some of the easier questions, like "Tell me about your last visit to PseudoCorporation.com. Why did you go there?" others and the topic is familiar. Allocate time blocks for each topic and stick to them. It's easy to start discussions and pass the time! If you're concerned about time, put your top questions in the middle of the bullet list after people get excited about the activity, but before any potential timing conflicts that might arise at the end. Many of the logistics of focus groups are the same as for usability testing. (Chapter 13 offers suggestions for screening, recruiting, and planning.) The main difference with focus groups is that you need more space. with a table so participants can interact with each other easily Filming for six to eight people per 1 to 2 hour group session. Give each person a badge or seat card at their seat so everyone can address each other by name. The format of the discussion itself should include an introduction that generally addresses the following key points: your role as a facilitator and what you hope to achieve by interrupting

Discussion (eg some of the points above).

CHOICE OF RESEARCH TECHNIQUES

105

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

current users of the Pseudo Corporation website and we collect it to learn more about their experiences"). How this information is used - both in design and

confidentiality perspective. That you, as a moderator, are there to hear their opinions and

Experiences. They want them to feel like they can honestly share. So ask people to be honest but also respectful of others in the group. That there are many issues that need to be addressed that will eventually be completed

Discussion on a topic to ensure you can cover everything. This can culminate in a round of introductions to team members, which usually includes some kind of icebreaker question. Your goal is to get everyone talking about the first question, even if they're just telling a short story. You can start with one person and work around the table, or let people respond naturally and then nominate people who haven't responded yet. At the end, you usually walk around the table to ask the first few questions, and when you feel the group is ready, you can use body language to open the questions up for everyone.

Snorkeling: Body Language A good understanding of body language can be a great tool when facilitating focus groups or personal user surveys. This can help you understand when someone is feeling frustrated, upset, angry, or threatened, so you can decide when to try to make someone more comfortable or follow up on a specific comment. The following book on the subject may take more than a weekend to read in its entirety, but it is designed to be one easy page to flip through: The Definitive Book of Body Language by Allan Pease and Barbara Pease (Bantam, 2006).

If you call someone who hasn't answered, repeat the question if the person didn't understand or hear the last question.

106

CHAPTER 6: USER RESEARCH

some statements in the discussion. Also, avoid making the disagreement seem like a disagreement between two people. Don't say, "Bob, we haven't heard from you. What do you think of what Chris just said? but (looking at Bob), "What do you say, Bob?" What is your experience with Pseudo Corporation customer service? As a moderator, you control the flow of the conversation and pass the virtual microphone. Maintain control through eye contact, speaking volume, hand movements and body alignment. A most people are very aware of their body language, and these cues can be helpful when someone is dominating the conversation. If a very vocal participant doesn't understand these cues, use a gentle but firm statement such as, "Okay, great, I'd like to to share that thought with others". When you move on to a new, broader topic, verbally announce that the previous discussion is over and a new one is starting, so that people can free their minds for the next topic. When the activity finally ends comes to an end, a simple glance at the clock and a change in body alignment can signal that the conversation must end.As with any activity, you should thank the team for their time. Sharing results with your team is usually done in one of two ways: results are broken down according to the main topics covered or grouped into related categories such as contextual search. The affinity diagram can be another effective way to capture various trends and behaviors for visualization within the project team.

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

CHOICE OF RESEARCH TECHNIQUES

107

A common reason for this is to create a sitemap for a website, or to 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 when working on a content source. Note For more information on content sources, see Chapter 2.

Let's say you're working on a common type of content source: the corporate intranet. Many intranets tend to categorize their information by the department that owns it, with navigation in human resources, operations, legal, marketing, etc. This may not pose an obvious problem for longtime employees, as they likely know their responsibilities and know where to find information. But for new employees or those who need information that isn't commonly reported, it can be difficult to find information that might (or doesn't seem to) fit into more than one section. For example, where can you find guidance on entering into contracts with newly hired employees? It could fall into the legal department or the human resources department. Card sorting helps you find common patterns in how potential users would categorize information, regardless of departmental lines. The Basic Process Gather the items you want to include in your card ranking. 40 to 60 is generally a good range. You need enough to allow for a potentially large number of decks, but not so many that you overwhelm participants with choices (or overwhelm you when you need to analyze the results). Choose items that you think will be easy to understand and won't contain unnecessary jargon. You can include some topical terms that your user groups are likely to be familiar with. However, avoid using too many built-in terms. If you use too many company-specific terms or acronyms (for example, “the SUCCEED campaign” to increase sales), you are testing the effectiveness of the company's marketing and communications rather than creating a common hierarchy of information. For the intranet example, you might include your vacation policy, 401(k) plan information, a new lease, a vendor agreement, a nondisclosure agreement, and so on.

108

CHAPTER 6: USER RESEARCH

Guidance for new hires, health insurance information, and computer security guidelines. This list is a hodgepodge of well-formulated items that can be categorized in many ways. You might have one participant who summarizes the new hire onboarding and leave policy in Human Resources, and another that puts the new hire onboarding and new hire agreement together and calls it “employee onboarding”. Once you have your list of items, place them on cards that are easy to group and ungroup. You can print labels and stick them onto index cards, or print directly onto cut sheets of paper to separate them into individual cards. Simulate asking someone to sort the cards into groups and name them - for example, putting a sticky note on top of the pile and writing the name on it with a pen. Ideally, the candidate is someone who is not familiar with the objects and the activity. This will help you get a general idea of how long the activity might take. If the test drive lasts longer than an hour, you may need to cut some maps! Once you have a full deck, you can bring in a real player and provide the following basic instructions: 1. Organize these cards into groups that make sense to you. 2. Try to have at least two cards in a group. If a card doesn't seem to belong in any groups, you can put it aside. 3. You can choose a name for a group at any time during sorting. At the end of the activity, name as many groups as possible. Some trends are already evident when looking at the sessions. Others may need a little more analysis to bring it up. There are many tools for entering and analyzing card sorting results. Many of them have tools that allow you to perform card sorting remotely (see the Card Sorting Variants section below to learn more about this). In particular, OptimalSort (www.optimalsort.com/pages/default.html) and WebSort (http://websort.net) provide remote sorting capabilities and useful analysis tools. Or, if you want to do your own sorting by hand, check out Donna Spencer's excellent chart in full.

CHOICE OF RESEARCH TECHNIQUES

109

with instructions, available at www.rosenfeldmedia.com/books/cardssorting/blog/card_sort_analysis_spreadsheet. Card Sorting Variations So far, the discussion has centered on a face-to-face card sort, where the participant was asked to name the categories they created. This is an open ranking, which means that the main categories are not given to the participant, but can be freely nominated. This is a good approach when establishing a new navigation structure or making significant changes to an existing one. For other situations, you might want to consider these common map sort variations: Closed sorts. In a closed taxonomy, specify parent categories

and the participants contribute to it. The results are relatively easy to analyze because you only have a small selection of possible categories and can focus on understanding which items most often fall into which categories. When adding large amounts of content to an existing information architecture or validating an existing sitemap, a closed taxonomy can provide fast, actionable information to help you make categorization decisions. group rates. Instead of sorting individual objects into groups, you can also do this

Sorting cards can be part of a focus group activity where participants work together to sort items. While the results don't necessarily reflect how a person would group items, you can gain a lot of insight into how people think about items and how they are organized by listening to them work together in the activity and discussing their reasoning for each placement. Distant Species. Sorting with physical cards can be a fun activity, especially

for group items. But there are many great tools for collaborating with people online. This also allows you to reach a larger number of participants or specific participants who may be difficult to find in person. The OptimalSort and WebSort tools mentioned above are two of the tools that allow for this type of online sorting.

Usability testing In usability testing, participants are asked to perform specific tests on a website or application (or a prototype thereof) to uncover potential usability issues and generate ideas for resolving them.

110

CHAPTER 6: USER RESEARCH

You can run usability tests during the definition phase if you want to gather information on how to improve the current site. Or, you could run it against similar sites (eg competing sites) to understand some of the potential possibilities for a more user-friendly solution. More commonly, usability testing is performed as part of the design phase, ideally in iterative cycles (where a design is created, tested, refined, and tested again). We'll discuss usability testing again in detail in Chapter 13, "Testing a Project with Users." This chapter contains recruiting and planning tips that can also help you carry out the activities discussed earlier in this chapter.

After Research Once you've completed one or more of these user research activities, it's time to reconsider the assumptions you originally made about your user groups. Put those assumptions behind you for a moment and ask yourself which user groups you would create now that you have more information. If any of your previous assumptions are invalid, consider any gaps in your user research because a core group was not included. If this gap is identified early enough in your research activity, you may have time to adjust and add another group of participants to the ongoing research to ensure you have a complete picture. With your new knowledge, you can revise your custom definitions to more accurately reflect the groups you should focus on. This will help you create more detailed tools such as personas (discussed in Chapter 7) and user requirements for the list we started in Chapter 5, refining into requirements. With users, you follow a similar process — your work doesn't stop once you've captured the idea or request. Figure out needs and goals to make sure you understand them. Ultimately, this will help you design a solution that best meets this need for all relevant user groups. In the next chapter, you'll learn how to use user research insights to create tools that can focus on your user groups during design and development: personas.

AFTER INVESTIGATION

111

Personas are the best way to put your team – or your customer – in your users' shoes. Personas are a common topic of discussion among user experience professionals. Opinions vary on how much content is needed, how much research is needed, and whether they add value to projects. Some people wonder whether they belong in the process or not. No matter where you are, personas can be used to help your project team and your client empathize with their users. Personas can provide an intuitive review of many parts of your project – business needs, visual design, or quality assurance – giving you insight into your audience and their expectations and behaviors. Russ Unger

What are personas? Personas are documents that describe typical target users. They can be useful to your project team, your stakeholders, and your customers. With the right research and descriptions, personas can paint a very clear picture of who is using the site or app, and possibly even how they are using it. User experience designers often find creating personas to be a great exercise in empathy. Well-crafted personas are often used as a point of contact when questions or concerns arise about how aspects of the project should be conceived. They can pull out their personas and ask, "How would they do?" or What will you look for? While this process may not be as accurate as functional and design testing with real users, it can help move your project forward until you can perform more extensive testing. Josh Seiden (www.joshuaseiden.com) points out that there are two different types of personas: Marketing-oriented personas that model buying motivations. Interactive personas that model usage behavior

This chapter focuses on interactive personalities.

Why create personas? In the user experience design process, personas help you focus on representative users. By providing insights into the "real" behavior of "real" users, Personas can help resolve conflicts that arise in design and development decisions so you and your team can keep moving forward. How real should the personas be? The answer is very different. A single Persona document might be enough for a team, while another might create complete "habitats" to deeply understand user personas and how they "live". You can even create custom web presences that you can interact with to gain insights into online behavior. However, whether you decide to expand your personality is up to you. Personas can be constant reminders for your users. One useful technique is to have your team members save faces to their workspaces. that's how it is

WHY SHOULD I CREATE PERSONAS?

113

are constantly reminded who their users are. When you share a cube with "Nicolle," the 34-year-old hand therapist from West Chicago, Illinois, for a while, you feel the need to offer her an experience that's good for her. If it helps, feel free to carry impressions with you while you sleep, and let the Osmosis Fairy transfer your empathy from the sides through the pillow to your sleeping subconscious. The purpose of personas is to help you, your team and/or your customers eliminate some of the confusion that can arise when you are at a crossroads in decision making.

Finding information about personas Effective personas must accurately represent a set of specific users of your product or site. To achieve this goal, Personas need to be supported by research. Chapter 6 introduces techniques for researching and modeling your potential users to create a solid foundation for your personas. However, don't look for a method that will provide the answer. It's best to find as much data as possible and combine it with a mix of observational and interview data – this can also involve using online surveys and analyzing behavior on social media. It's a common theme in creating personas: preserving real data but turning the faces on pages into real people. To see how one company achieves this, see the sidebar Case Study: Messagefirst Personas.

Creating personas Once you've identified your audience and gathered data to support your personas, your next step is to put pen to paper and start bringing them to life. How many personas you need to create varies. Usually the minimum is three, but more than seven is not uncommon. Rather than aiming for a specific metric, consider the number of your target segments and how best to properly represent them.

114

CHAPTER 7: PEOPLE

Case Study: Messagefirst Personas To create effective data-driven personas, Messagefirst (www.messagefirst.com) uses at least three different data input sources, relying on the following: Stakeholders. We interviewed them to find out what they think the faces are and how they behave. This is always included. Client's attorney. We interviewed people in the company who speak directly to customers, typically sales/marketing and customer service. Each has its own bias, which we take into account when documenting our findings. For example, the most common people who contact customer service are those who have a lot of time on their hands (usually retired or unemployed) or someone who is so upset about a product or service that they actually take the time to contact them. you. Customers. We speak directly to real people who will use or are using the product or service. This is included whenever possible. Customer Data Sources. We analyze all blog traffic, polls and emails available to us. someone we know We chose someone we know who fits the original persona profile. This helps keep us grounded, ensures the persona is believable and realistic, and provides a real person to turn to if we have more questions. This is very important for validation and is always included. Since every data input source we use has some bias, we use multiple sources to normalize the data. The important thing about data-driven personas is not that you expect how many people you will have, but that the data reveals how many people there should be. When I analyze data, I look for gaps in behaviors and activities. These gaps reveal individual personas. Todd Zaki Warfel, President, First Message

The example person in this chapter is Nicolle, a 34-year-old hand therapist from West Chicago, Illinois. She is not a driver and spends two to three hours a day commuting to and from work. The fictional customer is a company called ACMEblue, which makes Bluetooth headphones for Apple's not-so-fictional iPhone.

CREATION OF PEOPLE

115

You can learn a lot about Nicolle in this short paragraph, but as you can see in Figure 7-1, the real persona contains a much more detailed story about Nicolle. Please note that the content was written for Nicolle, not "by" Nicolle. It's better to write your characters from a third-party perspective and not worry about writing in their individual voices, especially when you're just starting out. Of course, as you expand your experience, you should explore and find the style that fits you best and gives you the most benefit.

Figure 7.1 Persona for a fictitious ACMEblue customer

What information goes to personas? The type of information your audience finds relevant and reliable is the type of information. The research data collected should help you determine what's important to the customer, brand, and project. Most personas you create will have a common set of required content mixed with whatever amount of data, statistics, and other relevant information that can be considered optional, as they vary from client to client, if not project to project.

116

CHAPTER 7: PEOPLE

Minimum Content Requirements When creating personas, you need to provide enough information to grab people's attention and connect them to the person they're reading about on the page. To help your audience understand how you act and think, be sure to include six key pieces of information: photo, name, age, location, occupation, and biography. The following sections detail how to fill in the details for each item. Photo A photo is the first (and real) step in putting a face on yourself. When choosing a photo for your personality, make sure the image doesn't look too crowded or too bright. The photos shown do not have the same effect as photos in more natural surroundings. Personas seem to be most effective in photos taken in more natural settings, such as the photo on the right in Figure 7.2, where the person is outside in their winter coat, presumably on the move. Make sure the photo fits the persona's lifestyle! to drink

Natural image 7.2 Natural looking photos are more effective.

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

CREATION OF PEOPLE

117

Finding the right photo can be a total mess if you're not careful. If all else fails (or if you have the time and budget), get your own! Name Simply put, you must give the person a name. The photo you use will humanize the mix of research data and personality traits, and the name will serve as how everyone relates your personality in conversations. Not only does Nicolle sound better as "Blonde Professional Mom of 30", she's also much easier to remember and relate to. Try not to make the names you use for different personalities on a project too similar. For example, Nicolle and Noelle can be easily confused. So look for separate names. And while it might be tempting to use the names of co-workers or clients, don't. If you use similar or the same names as the people involved in the project, they can easily try to identify with your personality. Choosing different names avoids embarrassing or heartbreaking situations. If you're having trouble choosing names, some online resources can help: Baby Naming Sites! BabyNames.com: www.babynames.com Babyhold: www.babyhold.com Popular Social Security Agency Baby Names: www.ssa.gov/

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

One last thing about names: make sure your name is believable to the person. Nicolle works well for a midwestern mother, but Nicola or Natalia might be a much better name for an Italian mother. Nor are names that sound a little funnier or more lively, like Bob the Builder. They tend to make their personas look silly and can devalue them. Age While your research should determine the age range of your consumers, providing a specific age for your persona helps add authenticity to the bio you're writing. The attitudes of a 21-year-old student and a 34-year-old working mother are very different!

118

CHAPTER 7: PEOPLE

Location At first glance, location doesn't seem to be an important piece of information. However, it is important to remember that cultural and behavioral changes can occur from place to place. In Italy, for example, different dialects are spoken in different regions of the country. In the United States, a person living in Chicago is likely to have a different cost of living than a person living in Savannah, Georgia. Profession If you know what your personality does professionally, you can identify with it by relating it to your daily life patterns. A person working in therapy encounters many people on a daily basis, whereas a drawbridge operator may not interact with others very much. Biography Biography is the captivating story that makes the person real. Here you provide details of your research data and flesh it out with some "real people". That is, dates are very important to the persona, but you don't want to just list this information in confusing sentences. Instead, you want to combine facts, anecdotes, and observations into a story your audience can relate to. It may sound a little strange, but the bio has to be believable and it certainly isn't cheating to infuse aspects of a real person into your personality. Nicolle, for example, relies on both statistical data and the very real behavior of an individual who shares similar activities, beliefs, and desires. Depending on your project, you may need to go into more detail in the bio - sometimes the more detailed you are, the better. You don't feel like you have to squeeze your personality onto a single sheet of paper. Go with what works best to make your persona as realistic and relevant as possible to the project you're working on.

Optional Content When working with faces, you will find that different designs require different sets of information to make faces more editable. In addition, the minimum content requirements can be considered the least common

CREATION OF PEOPLE

119

Denominator of most faces you will create. In most cases, you combine some of these optional content elements with your main personalities. One of the optional contents that can add value to your personas is the educational level. Knowing a person's education level can make a difference

more knowledge of some of your habits. A person with a high school education may have significantly different buying habits and brand perceptions than someone with a master's degree, and this information may affect how their personality is perceived. salary or salary range. It's about money and, in many cases, the amount

A person's income has a significant impact on their standard of living and disposable income. This information can provide important insights when targeting specific asset levels. personal quote. What motto would your persona claim?

than yours? This can sometimes provide a quick overview of your persona's core mindset. online activities. This can get difficult; There are many ways people spend money.

your time online. Some people pay their bills, others love blogging and social media activity, and some just use their computer as a power-on device when they have work to do. As many projects have an online component, this component is quite critical. You have to rely on your research to draw the picture. offline activities. Does your personality have any hobbies? Have more

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

to understand how a persona interacts with the customer, brand or project. Does the person learn about it through word of mouth, online reviews, a billboard, on TV or radio, or through an online pop-up ad? Are you looking for a solution to a problem that can be solved by the client, brand or project? Understanding this point using your stats and incorporating it into your persona can help you attract users.

120

CHAPTER 7: PEOPLE

Technical comfort. Does your persona use a PC or Mac? she makes

Do you still have a computer? Does he use instant messaging, flickr or blogging? Is she very comfortable with this activity or is she confused by it? Would a very simple solution for beginners help her? Does he have an MP3 player or other portable device? Does he use a DVR, AppleTV or on-demand to watch TV? The list can be continued indefinitely. It's up. Depending on your client, brand or project, it may be important to define these and many other concepts. social comfort. Given the growth of social media and social networks

At work, it can be important to recognize exactly how your personality engages in that particular space. Does he have a Twitter account? If yes, how many followers does he have? How active are you? he is a leader Does he use MySpace, Facebook, LinkedIn or other aggregators or online communities? Mobile comfort. As the use of mobile devices increases more and more

Because they are so prevalent, it's important to consider how your personas position themselves on mobile devices, if at all. Incentives to use a client, brand or project. In some cases, you may want

Provide the reasons why the person wants to use the client, brand or project. If she keeps wrapping her headphone cord around her coat and pulling it off her head, that might be a good reason to start thinking about new headphones. Real-world scenarios based on research data can help uncover the key drivers behind inclusion in your personas. user goals. You may also want to determine what the persona is expecting.

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

CREATION OF PEOPLE

121

Improved Personas Once you understand the basics of creating personas, there are countless ways to improve your documents. A simple persona can usually meet most of your needs, especially if your project team is just trying to empathize with your users. Things tend to get more interesting when you introduce your customers to faces. In these cases, you will often find that you need to provide much more than the information gathered about the basic persona. Figures 7.3 through 7.7 illustrate some of the ways you can expand faces. Feel free to use these examples, mix and match them to create something even better for your project!

brand

Familiarize consumers with the brand

PERSONAS AND SCENARIOS (based on ethnographic studies) Personas are characters composed 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 personas might visit the brand's website and what they would do there.

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

Pleasure seekers "I really like it" "Sophisticated Young"

PRINCIPLE

start to discover

AGRICULTURAL EXPERIENCE

"Aspiring Beginner"

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

"Enable Correspondent"

FEEL 5)&365

DISCOVER AGAIN

"Established Explorer"

CHURCH AND SIMPLIFY

"Grown in a Groove"

Practical tasks "It has to work"

Alice, 26

Rachel, 42

Erika, 47

Greta, 59

Figure 7.3 Persona main summary sheet (landscape). It provides an overview of various individuals and the departments they represent within an overall organizational strategy. Courtesy of Will Evans.

122

CHAPTER 7: PEOPLE

brand

PEOPLE AND SCENARIOS (based on ethnographic studies) Alice is a novice cook who wants to explore the world of gastronomy.

GOALS

eat especially for kids, hang out with friends, and look up new recipes online and in magazines. There's more to your exploration

She supports her family without much thought or effort.

More fantasy than reality. He's still scared and not

Find quick and easy recipes with basic ingredients

Try many new recipes. Her mom didn't inherit many cooking skills from her and her friends aren't very experienced.

(often) two types of meals are prepared: for adults and for children

kitchen too. Alice is a busy mom of one daughter in Chicago. She and her husband both work outside the home - he runs the office of a small insurance company.

Married to Alice, age 26 "Aspiring Rookie" Generation X

1 daughter, 5 tired, ambitious

income

Training

She's busy, practical, and doesn't spend a lot of time cooking. Alice just wants to make it quick and easy - though she often has to cook different meals for her and her husband since she started training after giving birth to Sophie two years ago and is trying to get back into marathon shape. She works from a small number of successful recipes that she is familiar with and many of the meals she prepares are packaged and prepared based on food.

SCENE Alice is having breakfast with Sophie watching Cartoon Network. A branded ad with a branded name appears here. Alice uses brandy and says that Sophie prefers this dish. He decides to check out the job website. Alice visits the site for a free half hour before a meeting. The homepage is clean and uncluttered. He sees the main sections of the site and links to interesting things like a recipe of the day.

Internet use

health awareness

cost sensitivity

Click on the recipe of the day. She likes the tips it contains—it makes her feel like she can tackle this recipe. She is pleased with the clean navigation unlike other sites where she tends to get lost. She likes useful features that go beyond what she sees in cookbooks, like being able to find recipes based on what's in her pantry and tips on how to use the produce. Alice discovers that she can receive recipe newsletters and clicks subscribe. Signing up is very easy! He enters some basic information and selects the Food Your Kids Will newsletter.

She would love to add even more of her own twist and recreate dishes she enjoys in restaurants, like her all-time favorite, chicken. Also, she would like to add more fresh vegetables to her meals because she knows they are healthier. She prides herself on being a detail-oriented planner and being able to manage her home on a tight budget. Your fridge and pantry are always stocked. She plans her purchases to take advantage of special offers and coupons.

Find kid-friendly recipes and mealtime activities. Find ways to improve your favorite foods. PROJECTS & INITIATIVES: better navigation and information architecture, better registration

A week later, at noon, Alice finds her first branded newsletter: "Pizza, Easy as 1, 2, 3." Perfect-her kids love pizza and she usually buys them frozen pizza. There's a link to Pizza for Beginners that inspires her to see if she can make her own pizza. The link takes you to a pepperoni pizza recipe on something called "Pizza Wizard". He flips through the recipe and realizes it's pretty simple. just 25 minutes and 4 ingredients. She checks her kitchen to see what she has. She doesn't have pepperoni or pizza sauce, but The Pizza Wizard suggests replacing them with things she has in her well-stocked kitchen: sausage and tomato sauce. It's perfect! There is a link to a coupon. Neena prints out the shopping list for the recipe, adds a few items she also needs, and heads to the store. Alice comes back from the store and starts. See the step-by-step on how to open the dough and add the ingredients. There are photos next to each step. It's easy to understand and follow. She wonders if she should cook the toppings first, but her pizza FAQ answers that.

contextual regional information, more targeted newsletters, recipe guides, better coupon integration, MEAL PLANNING. Positive attitude relies heavily on ready-to-eat meals with relatively little added fresh fruit and vegetables and spends more time flipping through recipes than cooking them

Figure 7.4 Audience faces (horizontal orientation). This detailed view of a persona covers a broader range of data and provides a more comprehensive perspective on the user's goals, needs and behaviors, all within a larger ecosystem. Courtesy of Will Evans.

Figure 7.5 Overview of the audience's purpose and personality (portrait). The goal map on the left provides high-level summary information showing the brands that the three personas interact with and relate to. The detailed description on the right provides an overview and biography of an individual, along with information about their behavior and motivations.

ADVANCED PEOPLE

123

Paul and Helen “I think it all fits in there. I'm just not sure how much will fit.

5 4

Helen's mother passed away a few weeks ago and they are preparing to vacate the house. You are planning to sell the house, but you need to clean it up first. The house is also in need of some renovations to the main bathroom.

- von de The basement is full of things Helen's mother has collected over the past two decades. He never threw anything away. It features Time newspapers and magazines from the past 20 years. There are some things Helen wants to keep. Most clothing, collars and furniture are donated to Goodwill. Sadly, most of her mother's words have been destroyed by water and mildew. He also has cans of paint, but Paul and Helen don't know if the paint contains lead or not.

2 1

one

ain

Know Ex led pe ge rie nce C on Pricve e Senior tunc pe sp Re e M Pued ult type Time C on eline t Haupteigentümer L Size ife es D E ecven lu tte t Year Waste Report Rating in Buar s ds ine Pr ss og r O Rec am nlin ycline e ac g count

This is the first time Pavlos and Eleni have experienced something like this. They don't even know where to start. You just want it to be as simple as possible. They know they need a trash can, but they're not sure how much it can hold. And they assume that almost anything can go to waste unless someone tells them otherwise. Their only other concern is that trash cans tend to be ugly. They hope to find a company that doesn't make their front yard look like a construction site or destroy the yard when delivering or picking up the trash can.

Change: 24-65

january life cycle

July

December

Month

1.0 fact of life

Main features Ŕ Ŕ

One-time event, eg B. acquisition of family property or minor renovations (e.g. restrooms). Little to no experience buying a trash can.

Goals

Grab a trash can quickly. Get rid of all the things you don't keep or give away. Avoid damaging property during the process. Avoid an ugly litter box. Empty the trash can quickly when it's full.

Points of frustration and pain Ŕ Ŕ Ŕ Ŕ Ŕ

Fragen Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ Ŕ

Ŕ ŕ

Available if needed. Price. The seller leaves the property as found. The required container size is available. Quick installation and collection after contact. Online account access for scheduling and payment. Quality and cleanliness of equipment. known brand

Ŕ ŕ ŕ ŕ

First sticker shock. I don't know the process. I don't know what they don't know. Comparing apples to apples across suppliers

Is there anything that doesn't fit? How fast can you deliver and receive? Will the property be left in its original condition? How does this work? Is a license required? How much will it cost? How easily can I contact someone if needed?

Figure 7.6 Faces of the target audience. This face represents a target age range derived from survey data. The information it contains is comprehensive and is addressed to groups of audiences, not specific individuals. This approach can be useful when doing a business promotion or when the client's budget allows for a detailed exploration of personas. Courtesy of Todd Zaki Warfel.

the handyman

Amanda Stone

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

AMANDA SHARE THE RESPONSIBILITY OF THE INCENTIVE PROGRAM WITH A FEW OTHER COLLEAGUES. They share access and manage multiple programs for clients. It can be especially difficult to ensure that the right people are paid in the right program. He must be able to switch between different programs and know where he is at all times.

circle of life

Key Features

Manages multiple programs. Medium to large company. Medium volume (50+ to 2000 orders at a time). Multiple people share a single role. 70/30. Fast payment and cashier's checks. Weekly to bimonthly use throughout the year. Very interested in reports. Want to create reports Heavy Excel programs use an internal custom system for the interface

Goals

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

Other applications Ŕ Excel Ŕ PowerPoint How can I run reports in all my programs? To Internet Explorer Is there a way to get my login details without having to call Ecount? We can somehow integrate ClientZone so that we don't have to switch between different apps as often. Am I doing this right?

Ac FT N c ew ou P n Cart Zo d Re ne quest t E Ad asys m Pa in y Che c R Cu ep ks ou rr e rting tB al P ence Cu opl est om Soft Sy Stamm em Ex ce eu

nc e

January

influencer

Pay employees quickly and easily. Ŕ Avoid duplicate attempts. Ŕ Check your checking account balance to see if you need money from the bank. Ŕ Track transactions weekly, bimonthly, monthly, quarterly and yearly.

rie

at once

dg e ow Kn

Kn y

etc

one

Use Account Zone regularly - several days a week. And since it manages many programs, it is quite active year-round.

Activities and Interests

O C

Change: 28-55

the knowledge

ain

Account Zone really helps her issue new cards and ensure program participants are paid quickly. The only thing missing is the ability to see each individual program as well as all programs running to see how things are going. Your customers like to monitor the performance of programs. He is currently tracking in Excel. She ends up sending the Excel file to her clients or sometimes exporting a PowerPoint file with some nice graphics and sending it to them. If Account Zone had a way to generate reports on individual programs and across programs, that would be really great.

July

Ŕ ŕ ŕ ŕ ŕ

Month

frustrations and pain points

Questions -

December

You cannot watch multiple programs at the same time. Reports cannot run in multiple programs at the same time. Debugging on download "stinks". It is not clear where exactly the problem is and how to fix it. Multiple steps with multiple applications are inefficient and make it easy to "lost". Multiple confirmation screens. Another username and password to remember. Find an email with login details.

Figure 7.7 Targets. This face is a highly data-driven model. While the daily story is narrative, the remainder is tagged to serve as a planning checklist. The diagram is used to communicate a large amount of information in a small space. Courtesy of Todd Zaki Warfel.

124

CHAPTER 7: PEOPLE

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

Final Thoughts About Personas Many professionals in the user experience design world don't believe that personas are good at articulating users' needs, goals, and attitudes. They believe that personas can get in the way of creativity, innovation, or good design for a variety of reasons. Other practitioners believe that when personas are based on solid research data and mixed with a dose of personalized reality, they fill a specific need that has a very positive impact on the design process. Which side of the coin you land on is entirely up to you. This chapter is not intended to influence your decision in any way. Many articles on this subject are available online and many professionals are ready to give you their opinions. All of these features can help you figure out which personas are best for your projects. So check it out. Jared Spool, CEO and Founding Director of User Interface Engineering (www.uie.com), also offers some insights on the subject: That value comes from the team visiting and observing their audience, recording and discussing the observations, and reducing chaos in patterns, which then become faces. What goes on in the team's mind during the project will make all the difference in the final project. The descriptions of the faces are just there to remind everyone what happened.

Jared's point is simple: by tracking your audience, supplementing what you've learned with research data, and breaking it all down into segments, you should be able to create personas that spark the kind of empathy that keeps your team engaged. Good way and creating the best app, website or product possible. Ultimately, however, your personas will be like Santa Claus: they are only as valuable as people believe in them.

FINAL CONSIDERATIONS ABOUT PEOPLE

125

User Experience Design and Search Engine Optimization The Key Role of User Experience Design in Successful SEO Search engines are the foundation of the interactive economy. Everything we do as “interactive” connects to the world at large through Google, Yahoo, MSN, Ask and the myriad sub-engines that make up the online search infrastructure. Information architecture is a crucial component of how websites are interpreted by search engines. This chapter aims to give you a basic understanding of why UX design is crucial to search engine optimization and what you need to consider to ensure the environments you create have a chance on Google. Jonathan Ashton

Introduction to SEO Simply put, Search Engine Optimization is the process of developing and maintaining a web component with the aim of achieving and maintaining a top position in public search engines for certain specific keywords. Search Engine Optimization (SEO) is like a martial art, a never-ending process of learning and doing. Even a master can go further through observed behavior or learning methods. As long as there are search engines and websites that are interested in selling something to users, search engine optimization will matter. SEO depends on three fundamental areas of improvement and influence: The critical set of things that the professional user experience designer considers

may affect the infrastructure, technology and organizational principles of the site. Content and any keyword issues related to optimized words that

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

Site from other sites and the organizational structure of links within the site. Let's break down each of these three areas and look at them from a user experience designer's perspective to better prepare you for the optimization challenges ahead.

Why is SEO important? It is interesting that even today we have to explain the importance of optimization for search engines. Customers tend to understand, to some extent, that it's important for their websites to attract targeted visitors from the physical search results of major search engines. Beyond that, however, understanding the implications of SEO is difficult for most interactive marketers. Global search volume data is available from a variety of sources. The most important thing, however, is to understand that regardless of the source, the numbers are simply huge and year-over-year increases are always in the double digits. Global search volume tends to increase quarterly. When Google first launched in 1998, 10,000 searches a day was a huge amount and put incredible pressure on the beta version of the system.

INTRODUCTION TO SEO

127

Hitwise (www.hitwise.com) reports that Google and its subsidiaries (including AOL and YouTube) account for the majority of searches worldwide, with nearly 72 percent of searches occurring in the United States as of November 2008. Yahoo is a distant second at nearly 18 percent, and MSN and Ask.com are at 4 percent and 3 percent, respectively. Internationally, Google is even more dominant: its market share tops 80% in many markets. Note For more information about Google's beginnings, see The Google Story by David A. Vise and Mark Malseed (Delta, 2008). According to comScore (www.comscore.com), there were more than 60 billion searches per month by 750 million people worldwide in 2008, with more than 18 billion searches being performed in the United States alone. In other words, 95% of Internet users use a search engine at least once a month, with a global average of more than 80 searches per month.

Aside from these remarkable volume numbers, what does this really mean on a practical level for interactive marketers? Simply put, if you don't reach your target customers when they search for your product or service, your competition has the opportunity to sell them more. Look at your website analytics and think: how much more revenue would your website generate if strategically targeted traffic were increased by 10%? How about a 100% increase? Or 1000 percent? If your site isn't generating significant traffic through natural search, then SEO is a requirement. A small investment in SEO can go a long way, especially if your previous interactive marketing efforts focused on buying clicks through sponsored listings. We've seen websites achieve a 35 to 1 ROI on their monthly SEO spend. If you pay search engine companies for sponsored listing traffic but don't invest in organic traffic, you're actually limited to about a 10% chance. Think about your own search behavior: when was the last time you clicked on more than one or two paid sponsor listings in a search result? Any discussion of why SEO is important and why it persists could last for several chapters. Suffice it to say that Google is just on the rise and that effective interactive marketing must incorporate search engine optimization as a key component of competent execution.

128

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Important specialization in core features is based on extensive training. The professional who focuses only on his field loses sight of everything else around him. Hence, it is imperative that every blogger spend at least a few minutes learning about SEO. While there are no official guidelines, Google has been kind enough to provide some very valuable resources. If you are interested in getting better search engine performance through your efforts, check out these links: Help for Webmasters/Site Owners: Search Engine Optimization:

www.google.com/support/webmasters/bin/answer.py?hl=de&answer=35291 Help for Webmasters/Site Owners: Guidelines for Webmasters: Quality Guidelines:

www.google.com/support/webmasters/bin/answer.py?hl=de&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, drown yourself in newsletters and blogs. Start at SEOmoz.org and browse. Remember, like anything else in life, if it sounds too good to be true, it probably is.

Website Technology, Design, and Infrastructure Search engines are essentially Web 1.0.5 technology, firmly embedded in the Web 2.0+ world. The basic idea of the search engine has changed little since the World Wide Web Wanderer was launched in 1993 to search the web and create the first web search engine. Virtually every search engine has an application, also called a crawler, spider, or bot, that finds and follows links and sends a copy of what it sees back to the database. The database is then analyzed using the search engine's proprietary algorithm. These rules are used to index a web asset and then rank it based on its ranking in the specific search engine scorecard. In this rather simple process, there are many pitfalls for the UX designer.

SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE

129

Understanding these important relationships will help you see your site through the eyes of search engines. An optimized website is based on a structure and technology that facilitates the movement of search engine spiders. Likewise, many content handling decisions determine how well search engines rank the resulting efforts. As such, much of this is predetermined by decisions made on wireframes and discussions about how the content is structured and managed.

Flash, Ajax, JavaScript, and other scripted content Today's dynamic, interactive web design relies on technologies that are anything but search engine friendly. There is a growing gap between what search engines can see and what designers can do. It is up to the UX designer to ensure that strategic plans are developed for dynamic and design-heavy websites so that search engines and users alike have the best possible experience. Once you have a basic understanding of how search engines interact with this type of content, you can decide when to develop it and where to compensate for its weaknesses. It's entirely possible to create an optimized website that relies heavily on scripted content if the right tradeoffs are made early in the process. It is much more difficult to create static or indexable content once the site is created and published. Therefore, make a strong case for static content based on ease of use and interest from search engine crawlers. It may seem like extra work upfront, but the return on investment is exponential. Flash Flash content is technically "indexable". Recently, there have been some developments in the ability of search engines to crawl Flash files to find the text and links embedded within those elements. Even if that content is indexed, have you ever seen a Flash element reach number one in search results? It probably isn't, because it's dangerous for search engines to open for full Flash compatibility. Assume that search engines can fully see all links and text content embedded in the SWF object. What prevents an unethical (or "black hat") optimizer from placing apples on object text layers during display?

130

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Oranges for the human user viewing the fully compiled components through a browser? How can you deep link to a Flash component without fully compiling it? These fundamental vulnerabilities remain until search engines reach a level of artificial intelligence capable of recognizing that an image is an image of a horse without the accompanying text that says "This is an image of a horse." To create a search engine friendly Flash website, you need to add a static content layer that duplicates the Flash content. In addition to search engine requirements, a static content layer is critical to meeting usability requirements. Think of the search engine as the person viewing web content over a dial-up connection or using a screen-reader browser. These people may form the lowest common denominator and it is possible that the strategy behind web development is to ignore this very small percentage of human users. But by ignoring this handful of people, you also exclude GoogleBot and Yahoo Slurp – the two most important visitors to your website, as they are the crawlers that allow the major search engines to index your website. Without text words or spider links visible to search engines, your content is unlikely to be found in meaningful search results. A static layer can be achieved in several ways. To meet search engine requirements, the static content layer must reflect Flash content. It's not an opportunity to show search engines anything other than what's being developed in Flash. By doing so, you break the spirit of the game and are explicitly on the dark side. The ideal way to embed Flash content in a static layer is to use SWFobject so that both Flash and static content can be stored in the same URL. This allows the search engine to find static content and allows the Flash-enabled browser to display animation instead of static content. If possible, avoid redirects to maintain link popularity leading to Flash content. Google Code provides a simple guide to implementing this simple piece of JavaScript at http://code.google.com/p/swfobject. There is another option that works on the gray side of SEO. Cloaking might be a dirty word for SEO purists, but if you approach the following challenges from the right angle, you can benefit from it too.

SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE

131

Cloaking exploits user-agent detection, detecting search engine crawlers when visiting a website and redirecting them to static pages for indexing. However, when a human visitor sees the same page in the search results and clicks on the link, the site recognizes that the user-agent is a human with a Flash-enabled browser and provides that human with the dynamic experience in an entirely separate URL. . The core of the problem remains the same as with the SWFobject method: you need to show search engines exactly the same things in your masked content as you do in your Flash content. Ajax, JavaScript, and other scripted content A powerful Web 2.0 content driver, Ajax enables Web developers to create content without pages. However, the problems that search engines have with Ajax are many and require good planning to avoid serious mistakes. Ajax stands for Asynchronous JavaScript And XML, which indicates the difficulties search engines have with this technology. Search engines generally don't handle JavaScript. The efficiency that JavaScript brings to developers is the problem search engines have with dynamic content. Another problem search engines have with Ajax is the asynchronous nature of the technology. A search engine can only see content from the initial page load, and any content loaded through a script that occurs after the first shell load is not visible to indexing. Since Google cannot extend a session beyond the initial page load and has no mouse or external agent to trigger a script, all user-triggered off-page content is invisible unless the text content is in the preloaded shell. loaded included. It is up to the UX designer to ensure that the 3D modeling needed to structure the pageless design includes the requirement for text and links to be preloaded into the page shell. Everything else and its beautiful design are invisible. Script-Based Navigation One of the most common issues that impede optimization is the use of JavaScript at the center of the site's navigation. This is very common and is due to the way many website development and content management tools work. Scripted browsing looks cooler, so people tend to be interested in using it. However, when JavaScript is the technology that controls the navigation of the website, it causes search engines to not be able to model the link correctly.

132

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

In-Site Relationships: You just can't see the site's link structure. And when search engines can't model link relationships on the site, deep content becomes invisible or doesn't get the right link popularity.

Content Management Systems Content management systems are designed to make people's jobs easier, but many of these systems make it difficult for search engines to handle their results. Here are some typical problems to avoid by using workarounds or choosing a more search-friendly content management system: Dynamic URLs. Search engines don't understand a "page" of content. O

understands the path to this content. Changing the path or URL pointing to that content will result in the content being accidentally cloned multiple times by search engines. This situation significantly reduces the performance of a website. If your content management system has a system that generates session identifiers in URLs, you could be in serious trouble. Tracking with adult analytics, not session IDs. Multiple URL paths. A typical problem when managing e-commerce content

Age means that a product accumulates multiple URLs over its lifecycle. In turn, since the search engine can only understand a page of content by the URL where it finds the content, if a product appears in a category and is part of a gift basket and is a weekly (and increasing) sale, very soon search crawlers will be on it I followed a bunch of different links to find the same content. Do your best to ensure that each piece of content only exists at one URL and that multiple paths are actually based on one URL, regardless of where the links grow. Rely on sophisticated analysis systems for channel analysis. Accidental Cloning. If you understand that a piece

Content must only be accessible via a unique URL path. Content management systems can easily detect other conditions that lead to inadvertent cloning of content. Suffice it to say that the architecture should only have a single URL path to a single piece of content. infinite loops. A corollary to the problem of inadvertent cloning is the information

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

SITE TECHNOLOGY, DESIGN AND INFRASTRUCTURE

133

a potentially endless task of tracking "upcoming" links in a calendar or similar situation. On the next day of a calendar, if the search spider can mark a next link where it can find another next link, it will follow that link to the next page, and so on. Avoid this situation by using a reserved link that search engines can't follow, so crawlers can spend their time on the content you want indexed. Old URL structures. The first thing many site rehabilitation projects do:

Our goal is to replace the old URL structure. The problem is that search engines have probably already indexed the content of those old URLs, and if you change them all, you're basically sending your indexing back to the first one. Also, all deep links accumulated on the site over time point to the old URL structure. Make sure you keep as many old URLs as possible. It is likely that when changing your content management system you will need to change all the URLs. If this is unavoidable, we strongly suggest giving the old URLs a 301 Permanently Moved status code and individually redirecting them from the old URLs to the new URLs. A 301 redirect is the only acceptable redirect for search engine purposes.

Domains, directory and URL structure are important. If you're starting from scratch and your branding restrictions allow it, try to choose a domain that contains a keyword or two. Nowadays it is difficult to find a .com domain with quality keywords. However, if you do, separate those keywords with hyphens. An important part of how UX affects SEO is a website's directory structure. It has a crucial impact on how link popularity is distributed across the site. Simple is better. Be sure to avoid external files in your directory structure. Some content management systems automatically add a subdirectory. avoid this if possible. This condition reduces the relevance of the entire site. Search engines understand the website hierarchy from the structure of website directories. So make sure the most important directories are at the top of the architecture. If your environment allows it, use keywords in the URL structure that relate to the area of the site. Separate keywords with a hyphen and

134

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Don't use too many keywords in a filename. Go to something like this: sitename.com/widget-catalog/aquatic-widgets/underwater-submersible.html. Also make sure to set up redirects to http://site-in-question. com for 301 redirect permanently moved to http://www.site-in-question.com. When a website is resolved both with and without www, search engines (especially Yahoo) index the content of both URLs, thus opening up the entire website to random copying. This condition can spread when a third party connects to the non-www website and the website contains a dynamic link structure.

Content: The former (and current) and future king While creating content is someone else's problem, the foundation of website architecture has a lot to do with getting the right content to search engines. As with all forms of keyword-based search, you need to understand the actual search behavior of the people you want to show an article to. Search engines are still very "primitive" as they rely on users typing in keywords to link to articles more or less related to those words. Choosing the right text is all about whether your site is relevant in the right context. In a perfect world, your SEO partner will give you a set of keyword goals before you start and work with you throughout the wireframing process. If your process doesn't involve such an experienced partner, check out the Google AdWords Keyword Research Tool (https://adwords.google.com/select/KeywordToolExternal) and do a little research on the actual search behavior of people who explore your category. Then take some time with this introduction to understand the phrases potential customers are looking for and use those phrases appropriately on your website. Search engines look for keywords at various points when analyzing a website. Optimization is making sure the right words are in the right places. By understanding the role of keywords in the UX design process, you create the necessary framework for future success.

CONTENT: THE OTHER (CURRENT) AND FUTURE KING

135

Why is content king? It is the core of what a website should offer. Search engines need text content they can see and index. Website visitors need engaging content that deserves their attention. Bloggers and webmasters need reliable content to build links. Without the right content in the right places, search engines can't drive the right visitors to your website.

Naming conventions and fighting jargon It is important that your keywords are reflected in the taxonomy developed for a website. Using keyword phrases in the main structure of the site makes the entire site more relevant to the products you are selling. If you sell widgets, don't call your online product listing a "catalogue" but a "widget catalog". Also, use keyword research to make decisions against jargon. For example, use the words "laptops" as opposed to "laptops" in your structure because people search for laptops over 10,000% more often than laptops.

Metadata, Headings, and Keywords It's quite remarkable that we've gotten this far in this chapter before delving into the fundamentals of metadata. There are many meta tags, but only a few are really influential as all others are prone to spam. Relevant tags are: Title of the page. Please note this is not the label, but that's it

actual page header tag. This tag contains the actual title of the page and consists of the most important 65 characters on the page. Think of the title as the little tag attached to the old library card catalog that says "Clements, Samuel" and indicates that all the cards behind that tag are Mark Twain books. Each page on the site must have a unique page title. Don't put keywords in the title and make sure you preload the title with the most important words. meta keywords. This tag has virtually no effect on search

Engines because it is very prone to spam. The exceptions seem to be that the Google AdSense consortium handles the meta keyword tag and Yahoo is heavily affected as a third party. meta keywords

136

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

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

that the meta description is unique for each page. This description is just that: a summary of what's on this page. Say, don't sell, around 150-160 characters. This content is crucial as search engines are likely to link to your page. If the page does not contain a meta description, the search engine will look for a snippet of text or other content that contains the searched keywords and display it in its results. The meta description is more about usability than SEO. So make sure each page is tagged correctly. Meta tag "Noindex". If you have pages you don't want to include

Use the noindex meta tag in search engine results. Just make sure the pages you want indexed don't accidentally contain this tag. Headlines. Search engines recognize headers, etc.

as influencers, as long as you don't spam them. Be sure to allow section titles that are descriptive and contain the relevant keywords for that page. anchor text link. The anchor text of the link is an important factor that affects it.

Search engines think of the page on the other side of the link. This is the factor that creates the "Google Bomb". When multiple links point to a page with the same anchor text as the link, Google interprets the destination as relevant to the phrase in the anchor text. For example, if you search Google for “click here”, Adobe's website will appear in the first results. There are hundreds of thousands of links pointing to Adobe that say "Click here to download Adobe Reader" or something similar. Use it in your favor. Anchor text should not say "more" or "click here". Instead, it should contain keywords that are relevant to the landing page.

Parted Hair It's an advantage to have separate indexed pages for left-handed and right-handed wave widgets. This level of granularity gives your pages a better chance of exactly matching legendary long-form searches. A page about a thing has a

CONTENT: THE OTHER (CURRENT) AND FUTURE KING

137

A better chance of winning for one cause than a page about many things (all other factors being equal, of course). And who cares about reading a page with hundreds of words?

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

Keep the content up to date. A key element to getting and maintaining a top position in search results is to constantly update your website content. This does not mean that all content on the site is constantly being edited. This means that the site must constantly grow. Structure the directory so that adding content is easy and intuitive, and expect the site to grow over time.

Other Content Issues One of the main challenges when dealing with the UX of a content-rich site is preventing content from being cloned or copied. Be sure to duplicate pages with seemingly innocuous conveniences, such as "print-friendly" content that is an exact copy of a page in a PDF or similar document type. Protect this type of page with linked links or use the rel="nofollow" link attribute. Don't neglect optimizing for the wide range of digital assets that search engines can index. This topic almost deserves a chapter of its own, but suffice it to say that PDFs, videos, images, and other non-web content are clearly part of natural search results. The structure of the wrappers around these elements is critical, as search engines need indexes for this type of content. For example, search engines cannot tell that an item is a horse racing video unless there is a link to the video with anchor text that says "horse racing video" next to the text about racing videos of horses on the code page.

138

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Using alt attributes is another way to identify non-text elements in search engines and is always a good idea for ease of use. Don't create dead-end content pages. Make sure there are also links to the main page at the bottom of the structure so search engine spiders don't get trapped. Trail links are an easy way to achieve this when a page type does not include the main site navigation.

Link Popularity Explained If there's a Holy Grail in SEO, it's link popularity. This is why Google performed so much better than other search engines when it first launched. Link popularity is a measure of the quality and quantity of links pointing to a web component from other sites. Google uses the term PageRank and it is the super factor that can overcome many other shortcomings. Links are essentially votes for a web component, and it is generally assumed that something of interest or value to others will have links pointing to it from other trusted web components. Over time, this concept has proven invaluable in preventing spam efforts and is, in essence, a key principle for high-quality search results. It is important for the UX designer to understand this principle because link popularity is distributed throughout the structure of a website.

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

LINK POPULARITY STATEMENT

139

Pages with the most internal links tend to have the highest link popularity. Most internal links should point to the most important pages to earn money. This includes links in the main site navigation, sitemap, footer, and inline links in the body. Since link popularity is crucial to ranking well in search results, you need to be as conscientious as possible to bring as many as possible to the pages containing the “Offer to Purchase”. Each page has a finite amount of link popularity that it can contribute to the other pages on the site. A page with a link pointing to another page sends 100% of its available value to the recipient. A page with 100 links to 100 other pages sends 1% of its value to each of those 100 pages. The homepage tends to have the most link popularity because a website's homepage tends to have the most links from third-party websites. This means that the homepage has more value for the other pages on the site. If there is a critical page that is part of the "point of sale", include a direct link to it on the homepage so that search engines understand how important that particular page is compared to the rest of the site. If possible, create a role that can link to the homepage's rich content.

Footer Links As we look for ways to customize and control the distribution of link popularity across the site, remember 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 site popularity. link Get link popularity across your site. Default footer links point to privacy policy and other non-transactional pages. So if these links need to be in the footer, hide them behind some kind of script or, even better, nofollow those links with rel="nofollow". link attribute. This prevents each page's link popularity from spilling over to pages that don't necessarily rank in search results. Preventing link popularity migration is also better than blocking pages entirely using robots.txt.

140

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

Links within the content Search engines use links embedded within the text. Just don't overdo it. Some schools of thought argue that after the first few links in a block of text, search engines stop providing beneficial weighting. Put your most important links at the beginning of the text and use link anchor text that includes keywords relevant to the landing page.

Playing with the System Who said search engine optimization is all work and no fun? Search engines can make real money for website owners, and in some environments there is a truly no-holds-barred approach to achieving top rankings at any cost. Many search engine optimizers have taken advantage of their clients and charged a lot of money for bogus techniques which, while providing positive results in the short term, have disastrous effects in the long term. Over the years, webmasters have used various optimization techniques in their quest for the best results. One of the most important developments in search engine technology has been the search for clever ways to manipulate the system. From a search engine's perspective, their users' best interests are served by providing clear, highly relevant results at the start of each search query. From the perspective of many SEOs, all is well and good when it comes to love and SEO.

White Hat vs Black Hat It's fun and easy to refer to 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 in no uncertain terms that certain management techniques, content and link manipulation, and other approaches are simply taboo. The Black Hats treat the question as a competition unrelated to cheating: How can something cheat if there is no specific rulebook or court? Their approach is more like a game of cat and mouse, where the cat holds all the cards and the mouse can swing to earn some decent money: take a chance, win and the payoff is big. But once the search engines catch up with you (and almost

SYSTEM GAMES

141

Be prepared for your site to be blocked or at the very least unable to run when the methods are called.

Meta keyword spamming Many of the "cheating" techniques are based on UX principles. One of the first methods of manipulating the system was meta keyword stuffing — essentially stuffing the meta keyword tag with hundreds of occurrences of apples when the site's content is all about oranges. Basically, the meta keyword approach was developed to help rank the initial web. Nowadays, due to the large number of keyword spam, this part of a website has virtually no influence on search rankings. Search engines easily recognized this technique and were able to process it quickly. The next generation of spam was a little harder to crack and also had its roots in UX issues.

Cloning and Doorpages Both cloning and doorpages are methods used to make a website appear bigger or different to search engines. Essentially, by repeatedly cloning a page, webmasters can create targeted content that can quickly become dominant for a given search phrase. Because of this practice, it's important to ensure that your architecture prevents accidental cloning, as search engines are sensitive to duplicates, whether intentional or not. Landing pages are another method of influencing search results that falls somewhere between the white hat and the black hat. For one thing, Google's Webmaster Quality Guidelines state that "Login pages... violate our Webmaster Guidelines" (www.google.com/support/webmasters/bin/answer.py?answer=66355). The guidelines define doorway pages as low-quality pages that are specifically optimized for a set of keywords that may not be relevant to the actual site or may be spam. On the other hand, how can you help search engines access content that is trapped in an uncrawlable database or hidden by technology that search engines don't like? In the positive definition, a landing page is high-quality static content that search engines can see and understand, while also providing the visitor with access to dynamic content. Today's content management systems improve the bottom line

142

CHAPTER 8: USER EXPERIENCE DESIGN AND SEARCH ENGINE OPTIMIZATION

required this approach, but it can still be very useful to create additional pages with the express purpose of showing search engines a static representation of content that they might not otherwise be able to handle.

Link Spamming The latest methods of tricking the system focus on manipulating link popularity, a central idea of how modern search engines work. As explained above, search engines determine the relevance of a given web asset by analyzing the quantity and quality of links pointing to that page from other parties. Search engine optimizers have worked to manipulate this piece of the puzzle by stealth redirecting, overusing subdomains, making every page of a site "/index.html", and using a variety of other subtle mechanisms.

Some Final Thoughts It's doubtful that this is your first exposure to search engine optimization issues. It is now clear how much a site's architecture and related issues affect search engine performance. The current research environment is a quantum leap forward from simple classification or structure. A well-thought-out search engine optimization starts with a high-quality UX. A website's architecture is the critical point in its lifecycle where it can be destined for search engine success or primed for imminent failure. Search engine optimization is a strategy that never ends, but quality SEO will never really start without the careful attention of a UX designer. Jonathan Ashton is Vice President of SEO and Web Analytics at Agency.com and leads the SEO Center of Excellence. His team provides company-wide SEO services, ensuring that the process of designing and creating immersive interactive experiences results in sites that can be found on search engines. His monthly Industrial Strength SEO column can be found at http://searchengineland.com/lands/columns/industrial-strength.php.

SOME PERFECT THOUGHTS

143

Here we go: From definition to planning, time to visualize, prioritize and plan. Now you have a nice list of business and user needs. And you get insights from your users to focus your conversations. And now? Unless you're in the Shangri-La of projects, you have a (tight) budget, (specific) schedule, or both that tell you to focus on that list and manage it somehow. This chapter describes some ways you can move from definition to design, including tactics to help your team visualize the solution being designed, prioritizing features to create a single set of requirements, and the planning-to-design activities that will follow in the next step. project phase. Carolyn Chandler

Again

Chapter 4 examined different project approaches or methodologies and how they affect how the project team and business stakeholders work together. Compare a waterfall approach, where the definition and design phases are separated by an approval step, with a modified waterfall approach, where the phases partially overlap. This chapter discusses activities that can occur at the intersection between the Define and Design phases.

Define project development

This point in the process is a good time to brainstorm and preview features that were not discussed during the stakeholder meeting.

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

business needs, user needs, and project team ideas and determining their relative importance to achieving project objectives. At this point, you work with the development team to understand the total effort required to meet each requirement. Plan the activities and documentation that you will use in planning. O

Scheduling determines how you will collaborate with other team members and what types of tools or documents they will receive from you, for example B. sitemaps and wireframes (see chapters 10 and 11). This chapter covers each of these three areas, starting with a method of generating and visualizing ideas that is easy for a UX designer to use in collaboration with project team members.

TRANSITION: FROM DEFINITION TO PLANNING

145

A common scenario: Requirements are defined and approved, and you are in the process of planning site features. Halfway through the design process, you realize that providing a specific tool will be really helpful for your users. It's an exciting idea, but there are no requirements describing this new tool, so its inclusion requires a change to the prioritized requirements. You have to put a lot of effort into changing the list of requirements, especially if it means something else needs to be checked off the list (it takes time to decide what that is) — or if the project schedule could fail. There is a chance the idea was not considered simply because it came too late in the game. While new ideas can emerge at any point in the project, taking the time to generate ideas after requirements gathering is complete but before prioritization will help you generate those ideas sooner and increase the likelihood that they will be considered. It also ensures that you take the time to think about innovative features that might not have occurred to your customers or users.

Designing and Visualizing Features UX designers have unique skills that help bridge the mental gap between words (eg requirements) and images (eg sitemaps and wireframes). Even when people talk about requirements and argue about language, they often don't agree until they see the concept represented visually. On the other hand, if you jump too quickly to certain visual details, there is a risk that the conversation will focus on smaller details (such as whether an option on a form should be a radio button or a drop-down menu) before the big questions are answered. resolved (for example, whether your users should fill out this form). There are many conceptual design techniques you can use during the process to help visualize the context, flow, and story in a way that appeals to others before the detailed design begins in earnest. These techniques also

146

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Highlight the need for features to add to your requirements document prior to prioritization. One such technique is collaborative scenario creation: visualizations of user-specific scenarios sketched out on paper or a whiteboard during a brainstorming session. The UX designer works from these sketches to add details.

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

where your user model or personas will come in handy. If you have them, bring them to the meeting - they will focus the discussion and ensure your project team has a better understanding of how to use the user modeling tools during the design phase. Is the featured user a new user of the site? If not, it's sporadic

user or use frequently? This affects the level of features you are discussing. A novice user might be impressed with the plethora of options that a frequent user can enjoy. You can review the script twice to discover different features that may be needed by each group, such as: B. Inbox help for new users or customization features for frequent users. What immediate need brought this user to the site? What is he trying to do?

success and why? You might think about this by looking at the high-level tasks covered by your business or user needs, such as “find product recommendations”. The user may want to find product recommendations because they need a pair of snow boots and want to be sure they won't leak and get their feet wet. Gather your brainstorming team for the session. This group can be just you and one other person, or it can be a small group of three or four other people. (More is possible, but it can be difficult to get everyone around the table effectively and focus on the task at hand.)

VIEW AND VIEW FUNCTIONS

147

Ideally, at least one person on the team is responsible for representing the user's point of view. Another person should represent the business point of view (for example, a business stakeholder or a business analyst if that role is represented on the project). That doesn't mean you can't change perspective. You can and should consider user and business needs as much as possible in the discussion. For more information on balancing user and business needs, see Maintain Good Volume. Once you've assembled your team, share with them the goals of the activity: understand some of the features that might be needed to meet business and user needs, and focus future design efforts. Present the answers to the questions above and the list of scenarios to be discussed. Then go to the board (or put pencil to paper) and ask the team questions about the scenario, eg B. How is this user likely to get to the site? Check web searches, banners

Advertising, word of mouth and other ways. If online searches come to mind, be specific about the requirements.

What types of resources or activities (for example, markup for SEO needs) support this search? What does the user see on the site that is relevant to their needs? Which path will the user take to complete the task? sketch it with me

High level details. Are other people involved in the project? If yes, how can they participate?

(phone, email, co-location features) and how might they affect key user decisions or behavior? Where is a user likely to need help along the way? How is he going to make it? What happens when the user completes their task? A common design mistake

You're done when the user is done. However, this is a good time to encourage the user to explore other areas of the site or consider purchasing related products. Consider an example of a common business scenario: the need to post a new job posting on the company's .com website. For this scenario, let's say you've researched stakeholders and found that the hiring process is primarily led by a person named Jeff in HR who works with those they need to hire. 148

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Jeff is very familiar with current job descriptions. When he needs a new job, he usually finds out when the potential manager for the new position asks him for a job ad. Then it's a collaborative process between Jeff and the manager (let's call her Emily) to write and publish the job description. Figure 9.1 shows what the script for this scenario might look like. The image only shows part of the scenery you can create here. You may want to start earlier in the script to show the approval process Emily had to go through, or continue the script to show a job seeker finding and applying for the job. It's important to note here that a script like this allows you and your project team to view the workflow as more than just a series of pages. It brings the human element and the context. And without the human element of the persona (Jeff), your team might not have considered including the ability to get an existing job description early on - although we all did it to save time and make sure we included everything we needed.

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

VIEW AND VIEW FUNCTIONS

149

One thing to keep in mind when using storyboards and other types of sketches (for example, user flows and concept lines) is that they are primarily intended as brainstorming tools. While some great ideas emerge from the exercise, these sketches are not intended to be detailed drawings. This fact may be apparent in the sketch format (as opposed to the prototype format), but it's still an important point to raise with potential customers, as recognizing features that already exist in a sketch can sometimes lead to an expectation that they will be present in the final product will be. Another danger is that participants can be drawn into discussions about user interface elements, such as whether something should appear on the page or in a popup. It's very easy to get into these lengthy discussions, as these types of problems are often easier (or more familiar) to solve than the larger problems that the scripts are intended to solve. To streamline processes and use time efficiently, ask participants to hold these types of discussions in a location that you design according to your priority list of needs. And that brings us to the next step in the process: the often hectic, sometimes tedious process of prioritizing those beautiful requirements you've been collecting for so long!

Facilitate the prioritization process. They have integrated all their business needs with features based on user needs and their ideas. Now comes one of the hardest parts: putting everything on a prioritized list of high-value requirements. As you work through the requirements that need to be prioritized, you'll have your project goals and your user model to help focus the discussion on your audience. In addition to you as a user advocate, you should also be involved in the prioritization process: Someone who represents the point of view of the company (the company).

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

development advocates).

150

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Someone who represents the needs of the project (eg the project).

Director). This person may not need to attend prioritization meetings, but will set any constraints that affect prioritization (such as deadlines or budget) and ensure the final list is right for them.

The UX Designer's Role in Prioritization It can be tempting to think of prioritization as a shared responsibility between the project sponsor, project manager, and development team lead, rather than an issue for a UX designer. There is nothing but the truth. Successful solutions are found or fail in prioritization discussions. User experience designers have a responsibility to bring their skills to these important conversations. If you're already part of the prioritization process, this section provides tips on how to get started. If not, do what you can 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. It's important to show that you understand the points of view of different team members and can work together to reach a common understanding. See the Maintaining Good Volume section for more information on achieving this balance.

The prioritization team examines each requirement to answer the following questions: How important is this to the business? how important is this

Prerequisite for achieving one or more project objectives? What is the impact of omitting this requirement? How important is this to the user? The requirement is met

a general user need (or a high-impact need for priority user groups)? How does this affect the user experience if this is left out? Are there other requirements that are very similar and potentially competing? For that last question, keep in mind that multiple solutions to the same problem can compete with each other and confuse users (and also require more support effort). For example, The New York Times may have a large enough development team to support all sharing functions.

FACILITATION OF THE PRIORITY PROCESS

151

on nytimes.com (in blue in Figure 9.2), but some of its users may be confused about whether to click Recommend, 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 set of features. What is the technical feasibility of developing the requirement? What

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

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

Figure 9.2 A photo from www.nytimes.com that highlights the many sharing opportunities the online newspaper offers

152

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Create a spreadsheet that records your decisions for each requirement. This could be a low, medium, or high score based on the questions above, or you could use a numeric scale to add the numbers together for ranking purposes. As you compile the list, you may find that you need to consolidate similar requirements or break a large requirement into several smaller requirements that represent potentially independent units of work. Please note that this system is intended for ranking and prioritization only. it is not based on any scientific analysis of the feasibility of the requirement. However, it is very useful for managing a long list, stimulating discussion and capturing relevance. Figure 9.3 shows an example of a prioritization worksheet that uses the top high-level importance and feasibility categories (low, medium, and high) to assign relative values to each requirement. Prioritization Worksheet

application

Description

business importance

user meaning

&%**%&

&($

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

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

((("!%

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

("!%

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

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

((!)*&(/

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

((

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

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

((

+#2##$%* *

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

Technical viability

resource viability

!+$

Figure 9.3 Example of requirements prioritization worksheet

FACILITATION OF THE PRIORITY PROCESS

153

Assigning values to each category will lead to numerous discussions within the prioritization team. How can you facilitate discussion and decision making? Two of the most important things you can do are understand (and sometimes embrace) the different points of view that are critical to defining a balanced solution and help resolve areas of conflict within the project team. First, let's talk about how to get the right views when prioritizing. This involves creating and maintaining tension between user interests, business interests, and development interests—a good kind of tension because it ensures a balanced solution that provides a good user experience, meets design constraints, and aligns with goals. commercials.

Keeping good tension As requirements are gathered and the project progresses, you may find that three roles come together in group discussions:

154

Business Advocate: The team member who represents business needs and requirements and ensures they are captured and met as faithfully as possible. The company representative's primary concerns include achieving the company's and department's strategic goals, ensuring that the business vision is not lost during the project, and establishing and maintaining focus on project goals. User Advocate: The team member who represents the needs and perspectives of the key users who will experience the site. The user representative's primary concerns include ensuring that the site meets user experience expectations, providing a satisfying and engaging experience, and encouraging behavior that supports the project's goals. Development Lead: The team member who represents the needs and constraints of the Technology and Quality Assurance teams. One of the main concerns is to ensure that the development team works efficiently and purposefully and delivers a product that meets the quality standards expected by users and business stakeholders.

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Think of it as a tug of war between three followers. If the tension between the three is maintained respectfully (ie, no single bidder is dominant), the three sides can work toward a balanced solution consistent with the project's goals. Each team member needs to know that they have an interest in maintaining balance throughout the project. When one side dominates, the other roles lose space and the project runs the risk of missing its objectives — or achieving them at a much higher cost 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 tension

KEEP GOOD TENSION

155

Can you play more than one of these roles in a play? Absolutely! Ideally, different team members will have primary responsibility for each role, but that doesn't mean you can't switch roles from time to time. In fact, you can switch roles from one conversation to another — or even from one topic to another. As a UX designer, you will often take on the role of the user representative, but you need to understand the viewpoints of all three roles and ensure they are consistently represented in order to create successful designs. While it makes sense to switch roles from time to time, be careful not to identify yourself as primarily responsible for more than one of these roles. As the project progresses, you can start making unquestionable concessions, as no ubiquitous "devil's advocate" will ask these strange but important questions. If you have more than one role to fill, try to find a part-time employee who can fill in the other roles for you from time to time to ensure a good tension is maintained. So far, we've focused heavily on the roles of the Business Advocate (particularly in Chapters 4 and 5) and the User Advocate (particularly in Chapters 1 and 6). Let's take a moment to discuss the third key role in our prioritization discussions: the development advocate.

The development champion If you are a UX designer at heart, you are able to put yourself in other people's shoes to understand their needs and goals. This skill is invaluable both for fulfilling your role as a user advocate and for ensuring that you communicate and collaborate effectively with the people in your organization. Let's take a moment to use this skill to describe pro-development goals. One of the great debates in design concerns the extent to which the developer should participate in and influence the requirements gathering process - and what role they play in it. If the development proponent presents technical possibilities and limitations too early, this can limit some of the brainstorming that could lead to some very innovative solutions. Finally, today's blue sky concept might be possible with some additional technical exploration. Even if the idea isn't viable, discussing it may reveal an underlying need that you can fill. (Mapping functional requirements to requirements is discussed later in this chapter.)

156

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

These are the goals and associated responsibilities of the development advocate: Meet requirements on time and within budget. Ensure team effectiveness (avoid unnecessary work, ensure good results).

Communication) Make better use of available tools and platforms. Choose cost-effective complementary tools. Make sure future changes don't require a lot of extra work. Make the solution scalable to accommodate growth. Make the solution modular so that individual parts can be easily changed. Make the solution as standardized as possible: minimal modifications

With a purchased system, less redesign work is required later. Make sure the development team is working well. Reduce turnover by doing relatively interesting and rewarding work. Reduce burnout that can occur with last-minute pressure

Working with Legacy Requirements Step 4

Step 1

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

Take the batch o requirements and do the first review.

you

Step 2 Gather information that provides context for potential users.

"Users are..."

Step 5 Review the identified needs with the team to explore needs and conflicts. "Here's why."

B U

Step 3 Create a temporary user template.

Step 6 Prioritize any changes you feel need to be made. Defend them and present them to the project team. Be direct and realistic.

SAME

you

Chr

"Correct observation!"

you

"Ah..."

KEEP GOOD TENSION

157

However, if the proponent doesn't get involved early enough, the team could go too far on a particular option and find that inclusion is too expensive - or the proponent could end up missing one or more of its objectives. Last but not least, the Development Advocate is a great resource for highlighting some of the technology features that can really help your solution succeed, such as new technologies or underutilized features. An effective approach is to schedule major reviews with the development champion once brainstorming is complete, high-level requirements have been captured, and the prioritization process is about to begin. This allows development support to spend the early part of the process exploring the chosen tools for more detail on what may or may not be possible, and then to get more involved in the requirements process itself when specific issues arise and get ideas. greater severity. If you feel that certain requirements gathering sessions are critical for the development proponent, be sure to agree in advance on the proponent's role in the meeting and know how to understand any concerns that may arise after the meeting hearing. You can also record these types of sessions to discuss later with your development officer. You might even need them if you're in the middle of planning! This kind of clear communication and following through as information is gathered is critical to building strong relationships between team members, which can have a big impact on how easily the prioritization step goes later in the process. But despite your best efforts, conflicts sometimes arise when you try to prioritize requirements. Let's talk about how you can help the project team manage this conflict.

Dealing with Prioritization Conflicts When there are large disagreements, prioritization can be a time-consuming process. And if these disagreements are not resolved, they will continue to surface during design and development. These conflicts can have many different causes. Here are some of the most common ones:

158

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

The team does not agree on the project objectives

wrong business strategies (misunderstood, forgotten or disagreed); Members of the opposing group are closely related to certain traits.

(Perhaps they are excited about the features or have promised them to several customers or key stakeholders.) There are conflicts between business needs and user needs that don't exist.

easily resolved. The technologies used are relatively new to the development team.

Therefore, they feel uncomfortable making estimates. Let's take some of the situations above and discuss how you, as a user experience designer, can help resolve them.

Pick Your Battles Some of your favorite features may be up for grabs during the prioritization process. It's easy to get angry about this, especially when it seems that user requirements are the most frequently crossed off the list. If you defend all claims with equal passion, you risk making decisions your priority. Here are some questions to ask when deciding when to push for a specific requirement and when to compromise: How does the requirement support the project objectives? Does it significantly reduce a specific risk? For example, does it reduce users' exposure to spam by reducing negative site views? Are the other suggested location requirements dependent on it for proper operation? What are the implications of not including the attribute? Is the resource's value worth the effort required to develop it (even at the expense of other resources you deem valuable)? If you have a compelling answer to all these questions, bring them to the priority table to support your case. If not, consider abandoning the project. Be sure to state your reasons, however, so that others can see that you are making concessions for the good of the project. This will demonstrate your ability to consider the broader business context and increase your involvement in future priority discussions and change requests.

KEEP GOOD TENSION

159

Lack of alignment in the direction of the project. The team disagrees about project goals or underlying business strategies. Let's divide this source of conflict into two areas: communication and consent. When it comes to communicating project goals or business strategy, ask yourself how you can personally help improve communication. Is it posting the goals or strategies where all team members can see them (for example, in a war room or online collaboration area, or at the top of each meeting's agenda)? Or perhaps a visual representation of goals or strategies is needed to bring them into the focus of the team and engage team members in the vision they are working towards. Remember those visualization skills discussed at the beginning of this chapter? Use them to create an easy-to-print and post image, or quickly sketch on a whiteboard to help focus conversations. When it comes to consensus, ask yourself how you can help bring everyone together. Is the conflict caused by fear of the risk of providing users with an entirely different resource? You can do some research to clarify some of the disagreements, for example B. surveys, interviews or contextual questions (see Chapter 6). Or perhaps you could use your facilitation skills to have a structured discussion of disagreements and work through issues point by point until they are resolved. Conflict over favorite traits Opposing team members are associated with their own traits. Let's say the training manager wants comprehensive courses on the subject and the sales manager wants to send out an exciting demo to generate interest. Now you have ten other prospects in different roles – and they all have urgent needs. How do you contribute to consensus building? A method is implementing a variation of a method you read about in Chapter 6: Affinity Diagrams. With this method, you can work with an existing set of requirements or ask stakeholders to capture their own requirements (particularly useful when the requirements capture process is just getting started). If you are working with existing requirements, you can print them out

160

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Select individual pages and stick them all on the wall. If not, ask stakeholders to write their key requirements on a set of sticky notes. What you need: A space big enough for your stakeholders to come and go

you can attach sticky notes to one or more large, blank walls. A pad of large sticky notes, at least one for each person involved. Glue dots (you can find these at office supply stores, they come in different varieties).

colors), a set of ten markers per stakeholder. Gather key stakeholders in a room and ask everyone to take a moment to write down their key requirements one by one on a piece of paper. Give them 15 to 20 minutes to do this. (No peeking!) Ask everyone to post their demands on the wall. Then ask each person to walk around and describe what they posted. As you move around the room, start grouping similar needs together (if stakeholders feel they are similar). After explaining and grouping the requirements, distribute the glue points. Tell stakeholders that they can indicate which requirements are their top priority by putting their points on sticky notes. For example, they might choose to put all ten dots on one requirement if they find it that important, for example, or they might choose to put one dot on ten different requirements. You'll see clear favorites forming as people place their points. When you finish placing the points, review the results together. If stakeholders are forced to choose this path, they will bring their own internal priorities to the fore and the discussion will likely become much easier.

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

KEEP GOOD TENSION

161

This type of technique can help you start the prioritization process or restart a process that has stalled due to disagreements. Once you have momentum and a common understanding, filling out the prioritization document (like the one we saw in Figure 9-3) becomes much easier. Along with your priorities, you should prepare for the overall design effort that will happen soon. When you have a plan for your work, you can estimate the effort required to create detailed plans, integrate your work with that of other members of your project team, 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, have completed some initial conceptual work (such as the scenarios presented earlier in this chapter), your project manager will likely ask for details about what you intend to do. . There are different types of design activities, and each one has different implications for how you design, the time it takes, and the type of final document. This is a "document" in the general sense. It can range from a whiteboard sketch to a wireframe to a prototype. In the next three chapters, we'll cover some interaction design activities. When planning which activities to use, consider the following questions: How iterative will the overall process be? Ideally, you can start with this

Quickly explore several different concepts (eg using sketches) and then agree to develop one in more detail. This approach can also involve making one or more design concepts available to users (see Chapter 13 for more on design testing). How does collaboration work during the project? When you work together

With a team in a common location, you can schedule more collaborative whiteboard sessions. If the team is dispersed, consider web conferencing sessions with tools that allow for a high level of collaboration despite distance.

162

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

How are design documents shared with the larger team? AND

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

edit, process; If your documents form part of a formal Quality Assurance (QA) process, you should involve someone on the QA team early on so they understand what kind of details they are getting from you. How long do your documents have to “live”? for complex projects

Once you stop updating a document, such as a frameset, it starts to “die” — the details become less and less precise over time. (This isn't always a bad thing, as long as you participate in the discussion of these changes.) Documents that focus on providing general guidance, such as a brand policy document, for example, or a library of interaction design patterns, tend to have a longer service life. Who are the main users of each type of documentation? this answer

it may be different in different parts of the project. The primary users of your conceptual design documents are typically business stakeholders and the design team, who use them to communicate and socialize ideas. Detailed design documents are primarily intended for developers who need to implement the designs. These documents provide concrete direction. What other types of documentation does your documentation need to adapt to? I owe

It should create some kind of relationship between the prioritized list of features you created above and the designs you create. You may also need to keep track of several other types of documents to ensure they are all on the same page. These documents might include branding guidelines, content development plans, feature specifications, or use cases (see Chapter 2 for an overview of the different roles and types of documentation they can create). How to calculate the effort for each type of document? O

One is difficult because there are so many variables in a project that can affect timing. However, establishing a baseline for a rough estimate provides a starting point and can validate numbers as more information becomes available. For example, as a baseline estimate, you could set each detailed wireframe to take about 6 hours to create. When you calculate a specific attribute

PLAN YOUR ACTIVITIES AND DOCUMENTATION

163

As the job takes about five pages (based on, for example, the results of the storyboarding sessions described earlier in this chapter), you'll need about 30 hours for this role initially. If you end up needing eight pages per wireframe, try to figure out why. If you think this will continue to be the case, you should review your assessment and possibly re-prioritise. What additional factors influence the timing of document publication? in total

Time includes meeting time with the team and stakeholders and time for the number of revisions you feel need to be done. For detailed locations, this could also include the time needed to verify design documents with other documents, such as detailed functional requirements (for example, use cases). Write these assumptions down for yourself so that you can check them later. Will you be working with a lot of designers, and if so, how are you doing?

you'll split the work Working in parallel, but in different areas of the site, you can work completely independently on the documents you create. When you divide the work up in a highly interdependent way, you need to take the time to harmonize your plans, and you may also need a way to track and merge different versions of documents. Save yourself a huge headache later on by defining a process up front and establishing some design guidelines early on so you're on the same page on the basics like navigation. Now that we've talked about some things to consider when choosing your design activities, let's dive into those activities. In the next three chapters, we'll discuss a variety of documents, such as site maps, workflows, sketches, wireframes, and prototypes.

164

CHAPTER 9: TRANSITION: FROM DEFINITION TO PLANNING

Sitemaps and Workflows Build your project from here to there and vice versa. Sitemaps help define the structure of sites and applications. You can show hierarchies and connections that allow your audience to understand where users can find content. Workflows take sitemaps a step further by identifying the different actions a user can take on a section of the site. Workflows also make connections to defect states, content, or pageviews based on decision points throughout the process. When sitemaps and workflows are used together, you can give your audience a clear picture of your content structures and how users can navigate them. Russ Unger

165

What is a sitemap? 1.0

1.0.1 Terms and Conditions

Heim

2,0 – 2,x

3,0

blog

4,0

One

5,0

To work

Contact

Figure 10.1 A sitemap for a simple site with blog functionality

Let's start with the most basic definitions: A sitemap is just a visual way to display representative pages on a website (Figure 10.1). A simple sitemap usually fits on a single sheet of paper and looks like an employer's organizational chart. Sitemaps aren't just for websites, however. You can use them for any type of application that benefits from being aware of pages, views, states and instances of what is being displayed. In most cases, you use a sitemap to show teammates and clients how the content on a site is organized. It provides an overview of site navigation and, in some cases, shows all the links that each page may contain.

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

Heim

Is the user logged in? unlinked page

linked page

Workflows specify paths or processes that users (and sometimes a system) follow as they move through the site or application (Figure 10.2). While sitemaps and workflows may look similar at first glance, the two types of diagrams serve different purposes: a sitemap shows the visual hierarchy of a website or application layout, while a workflow provides details about user choices. and the routes that are available to them. 166

CHAPTER 10: SITE MAPS AND WORKFLOWS

Professional Tools If you're just getting started with user experience design and need a tool to get started creating work products, you have several options: Microsoft Visio (http://office.microsoft.com/visio) Axure RP Pro (www . axure.com) OmniGraffle (www.omnigroup.com/applications/OmniGraffle) Adobe InDesign (www.adobe.com/products/indesign) Adobe Illustrator (www.adobe.com/products/illustrator) Microsoft PowerPoint (http: //office .microsoft.com/powerpoint) OpenOffice Draw (www.openoffice.org) HTML Blueprint CSS (www.blueprintcss.org)

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

TRADE TOOLS

167

Whichever tools you choose, there are countless examples online from other professionals ready to share them with you and support you in your career. They are mostly free and can provide the structure needed to produce - at the very least - professional looking documentation. Unfortunately, many people don't use these features. Don't be like these people!

Sitemap Basics and Workflows The most basic elements of your design program will be more than enough to get you started creating sitemaps and workflows. However, to ensure that your creations can be easily interpreted by a wide audience, it's best to use a standard set of shapes. The Visual Vocabulary for Information Architecture is one such pattern and is used in this book. It was created by Jesse James Garrett, one of the founders of Adaptive Path (www.adaptivepath.com) and is available online at www.jjg.net/ia/visvocab. The site offers many elements to help you formulate your sitemaps and workflows. They are available with detailed descriptions and as downloadable stencils for many of the popular design and sketch programs (more on that in a moment). . To help you get started and familiarize yourself with the basics, the following sections examine the main visual vocabulary elements and how they are represented. Figure 10.3 Jesse James Garrett's Visual Vocabulary page element

Figure 10.4 Pagestack Element from Visual Vocabulary by Jesse James Garrett

Page According to Jesse James Garrett, a page is “the basic unit of user experience on the web”. “Hits” or “views” of content may be more realistic today, but a page still makes a lot of sense. There are different ways to style these pages, but the simplest and most commonly used format is simple

168

CHAPTER 10: SITE MAPS AND WORKFLOWS

Rectangle (Figure 10.3). As you continue to create sitemaps and workflows, you'll want to find the style that works best for your labeling and pagination.

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

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

Connection

(10A)

Error

member's house

A decision point is used to indicate the path a user might take depending on the answer to a question (Figure 10.5). Decision point 10a could be: "Are the user's credentials correct?" The answer to that question would determine which page (or content view) is displayed. A failed connection results in an error message, while a successful connection redirects the user to the site's members home page. Take time to highlight appropriate decision points. You won't regret it, especially if you share the results of your work with teammates or clients.

KEY ELEMENTS OF SITE MAPS AND WORKFLOWS

169

Links and Arrows Figure 10.6 Link and Arrow Elements from Visual Vocabulary by Jesse James Garrett

Links and arrows are used to indicate movement or progress between pages, page stacks, decision points, etc. Links usually appear where there is a call to action from one page to another. For example, a link to the About Us page on the homepage could be the link between the two pages. The arrows (above Figure 10.6) indicate movement “downstream” toward task completion. The crossbar links (below in Figure 10.6) can be used to indicate when going back to the page you came from is no longer available ("up-traffic"). For example, when a user logs in to a website, the home page content can now be customized for the user and the generic or login page is no longer available to the user via the path they just took.

Conditions A

Figure 10.7 Jesse James Garrett's Visual Vocabulary condition element

A dotted line is a very common way of indicating a state. It can appear in sitemaps, workflows, and other work products that you create or design. You can use a dotted line as a link (as in Figure 10.7) or as a box around an area to indicate that a link to a page – or an entire section of a page – is subject to conditions based on some other action. or event. .

170

CHAPTER 10: SITE MAPS AND WORKFLOWS

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

Sloppy Links Figure 10.8 A broken link between two pages

Sloppy connections are just that: shameless. They are poorly designed. They look very amateurish and give you - the author - the impression that you don't pay much attention to detail in your work, to say the least. Most tools have a method for connecting your leads to their boxes. Please use it. Don't be lazy no matter how tight your time is and the pressure you are under. In most applications, you can use a combination of Shift and other keys to drag items from a starting point in 45-degree increments. Take advantage of this built-in feature and make sure your connections are well connected. If you're showing pencil sketches, make sure you have an eraser handy just in case. Make it a rule: always make sure that all lines touching another object are connected exactly.

COMMON MISTAKES

171

Misaligned and unevenly distributed objects

Figure 10.9 Misaligned and unevenly spaced pages

Depending on which tool you use, it can be difficult to ensure that your objects in your sitemap or workflow are precisely aligned or evenly spaced. There are some pretty easy ways to make sure you're breaking this basic rule. First, enable the grid in the app you are using. That way, you can always count the number of meshes between your objects, regardless of whether the tool offers options that ensure objects are evenly spaced and correctly aligned. Luckily, if you're using pencil and paper, you can use graph paper and use the same basic principle. It's very easy to give your documents a professional look. Unfortunately, it can also happen so easily when writing that it seems like you don't care about the quality of your work.

Badly positioned text Figure 10.10 Incoherent text

Step 1 Step 2

Sloppy text placement (as in Figure 10.10) seems easy to avoid, but it's another common mistake. Find a way to make your text fit perfectly with the shape you are creating, and make sure that any labels placed outside your elements have the correct bindings (Figure 10.11). 1.0 Start

172

1.0.1 Terms and Conditions

CHAPTER 10: SITE MAPS AND WORKFLOWS

Figure 10.11 Well-Placed Text

It may sound simple, but proper placement of your text - along with proper font size and usage - makes your documents easier to read and use.

No Pagination It's time to lay down another rule of thumb: number every page of every sitemap you create. Do not create a fuzzy uncountable map like Figure 10-12. Conditions &

Heim

blog

One

Conditions

To work

Contact

Figure 10.12 Site map without numbering structure

Each page you identify in your sitemap should be assigned a number, and your numbering system should allow for future changes as new iterations and versions of your project are created. You can use different approaches to page numbering. Most commonly, you specify your home page as 1.0 or 0.0.0.0 (Figure 10.13). Over time, you will be able to find which one works best for you. However, until you are familiar with the pros and cons of both approaches and understand the pros and cons, start by specifying your homepage as 1.0. With this method, you can count as 0.X all decisions and pages that may appear before your homepage - such as a flash preloader, a login or registration screen, or some other types of pages. A numbering system in your sitemaps allows other documentation to be synchronized with it. The numbering system can be replicated in other documents, for example in the content matrix. Content creators can combine their copy and other content

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

A user accesses pages for a specific task. Wireframes (see Chapter 11). Cable sides must be shared

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

COMMON MISTAKES

173

visual design. Visual designers can sync pages and design elements

specific pages in your sitemap. This allows them to segment their inventory when it comes time to hand their designs over to developers. Quality Assurance Documents. Quality Assurance teams can prepare the test.

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

1.0.1 Terms and Conditions

Heim

2.0 – 2.xBlog

3.0 relatives

work 4.0

5.0 Communication

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

In short, numbering the pages in your sitemap will make everyone's life easier — and that means yours will be easier too.

The simple sitemap in Figure 10.13 not only includes page numbers, but it's also a good template for creating a simple Web site map that has limited dynamic features and is mostly static in nature. The pages identified for this site were "Home", "Blog", "Samples of related works", "Contact".

As you can see, this simple sitemap incorporates important visual vocabulary elements while maintaining a professional style and appearance. More importantly, it provides a very clear view of the navigation, pages and terms available to site users.

174

CHAPTER 10: SITE MAPS AND WORKFLOWS

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

that the pain is very good

February 9, 2008

Page 3/9

Figure 10.14 Sitemap homepage advanced view

When creating sitemaps that are more complex or intended for larger sites and applications, one approach is to use your home page to identify all the steps required to get to your site's home page. (That's right, we recommend using a workflow as part of your advanced sitemap.) In addition, you should identify all top-level pages, global navigation elements, and footer elements. This allows you to have a very comprehensive overview of the site and gives your team and clients a clear view of the project. The front page is also a good place to add a caption or key to make the sitemap easier to read (see Figure 10.14). Your team and your customers will need one. Do not skip this step!

ADVANCED LOCATION MAPS

175

that the pain is very good

February 19, 2008

Page 4/9

Figure 10.15 Expanded view of sitemap area

The pages you create after your first page should essentially map to it. For each top-level page, you should follow at least one page that identifies all the pages, page stacks, and external content required by the site or application (Figure 10.15). If necessary, don't be afraid to link subpages together. Sitemaps can be made larger than any standard sized sheet of paper would allow. This is nothing to worry about as long as the sitemap is well organized and the links are clearly documented for your audience. These examples are more than enough to get you started in the world of sitemap creation. As you start to iterate through a variety of projects and find that your skills - and often your team's or clients' needs - grow, you'll find that there are many different approaches and methods you can use to deploy maps. of websites.

176

CHAPTER 10: SITE MAPS AND WORKFLOWS

Breaking away from the Sitemap method You've already seen solid examples of sitemaps that should cover most of your needs to accomplish your main tasks. Don't let these templates stop you from finding ways that work best for you - and share them with us! Different approaches can highlight information that goes beyond the basic site architecture. For example, consider the sitemap in Figure 10.16, courtesy of Andrew Hinton, senior information architect at Vanguard. follow new searches

bc.org support

Connection

update profile

Find similar people

“Academic” Interest (Medical, Student, General)

Contribute

Chat Get Printed Materials

Learn more about bc.org

new concern

Risk management

worried loved one

Socialize

expert conference. join to learn

New Diag New Stage / Sit.

Figure 10.16 Advanced Sitemap. Courtesy of Andrew Hinton.

This sitemap not only shows the different pages on the site, but also serves to provide information about user paths and priorities. Andrew (www.inkblurt.com) says he created the sitemap after seeing an example of Wolf Noeding that ignited his creative fire. Andrew uses this sitemap to present various 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 receive the most traffic. Like any good user experience professional, Andrew borrowed, but he also gave credit. There are countless ways to expand your sitemaps as you become more comfortable using the tools and understand the needs of your work product and customers. Find inspiration wherever you find it! Don't be afraid to try something new, but take the time to make sure the time you spend is useful and valuable.

CONSTRUCTION OF THE LOCATION MAP

177

Using many of the same basic elements as sitemaps, workflows are diagrams that identify a path or process that users (and sometimes a system) follow as they move through the site or application. You can use workflows in different ways. In conjunction with a sitemap, they can show how a user arrives at a page that displays specific information. They are sometimes used to show how a certain type of user (persona) would expect to navigate a website and what that person would expect based on their personal mental model. Workflows also allow you to define complex processes that need to be clearly understood before the project is sent to the development team. You might not use workflows on every project you work on, and they don't always end up as a work product that you present to your clients, but it's always a good idea to use them - even in pencil and paper format - your favor to use . A little clarity can go a long way. To create a workflow, you need to understand the user's purpose. In some cases, you will receive a requirements document, and in other cases, you may receive (or write) a use case. Although a use case is just a few sentences summarizing tasks and goals, it allows you to incorporate the user's point of view into the experience. The use case for the scenario in Figure 10.17 might be as follows: The system displays the list of projects. The user selects a project. The system displays basic project information in recording mode. User changes project status to "Closed". The system checks pending tasks. For pending orders, the system will display an error message. If there are no pending tasks...

178

CHAPTER 10: SITE MAPS AND WORKFLOWS

The system checks for outstanding payments. In the case of pending payments, the system displays an error message. If there are no outstanding payments... The system displays the summary page.

Home [My claims list] Select claim

Information [Registration Mode]

Changed claim status: Closed

Pending tasks?

Error message

[View pending tasks and requests] Yes

Pending payment request?

About [Read-only mode]

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

The workflow in the figure illustrates the order of information presented to a user based on whether various conditions of the use case are met. If a question in the middle ("Pending Tasks?" or "Pending Payment Request?") is answered with "Yes", the system will display an error message that may contain additional information to help the user complete the necessary tasks, before to continue. If both conditions are answered with "No", the system displays a success message to the user. The workflow in Figure 10.18 shows the paths a user can take from a calendar application to a travel shopping website. The workflow is very advanced as it identifies three very distinct paths that require user testing to ensure that the detailed flow of each path meets the users' needs.

WORKFLOW

179

Calendar S100 Calendar Shopping Rate Locator

S10 Detailed Tariff Finder

to search for

Search by price (see tariff matrix)

Search by time

Flexible dates

Select "R20 Search Results (by Price)" - "View Itineraries" - "Edit Search".

P30 seat selector switch

analysis

Search Results for R60 Flexible Dates (by price)

R10 Survey Results (By Schedule) View Sections - Edit Survey

P10 Itinerary Summary/Passenger Details – Select Seats

We get

Payment and billing information P20

I like

book page

multiple pages

confirmed

P50 confirmation

Link to decision point

conditional link

Figure 10.18 Workflow illustrating a user's journey through the stages of a buying process

Users of this app can enter multiple travel dates and shop according to their own priorities. Once users set their travel search dates, they can prioritize their results based on what matters most to them: price, travel date flexibility, or travel times (schedule). The workflow identifies high-level paths a user can take to provide guidance to the people running the test. Detailed workflows can be created for each path in the bundles and then provided to the development team to create the necessary pages for testing.

180

CHAPTER 10: SITE MAPS AND WORKFLOWS

Taking Workflows to the Next Level As with everything else in this book, you don't feel that what you see here is the beginning and end of the workflow universe. Explore new uses and expand the use of the core elements described here as much as possible - if there is good cause to do so. As your workflow design skills continue to grow, you may find that you create a slightly more colorful work product, have more options, change or improve the language rules, etc.

Process Flow Figure 10.19 shows a workflow that Will Evans (www.semanticfoundry.com) took to the next level and turned into a process flow diagram. The process flow is at a very high and flexible level and is used here to show that in the various steps of a design process, the first phase of the design appears to be just one step. In this particular case, however, it is important to understand that it is not a one-time event. Instead, in this case, the first phase of the project actually consists of several different activities: user research, market research, ethnography and contextual research, usability testing, competitive analysis, market analysis, culture analysis, protocol

Take your work to the next level

181

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

For each of these activities, reports are produced, which feed into several other documents before the start of the project, where the necessary stakeholders meet to establish scope, priority and deadlines. All this is shown in the process flow diagram. As you can see from this example, there are no limits when creating workflows. Look at the example above and think about how you can take your results to the next level. It may take some practice, but with a little finesse, you can create workflows that will wow your customers!

Swimlanes James Melzer (www.jamesmelzer.com), Senior 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 an advanced workflow for showing "floats" of actions, notifications, etc. in a process where many events occurred simultaneously - on this project, a traditional workflow approach could have been a nightmare!

182

CHAPTER 10: SITE MAPS AND WORKFLOWS

Instead, James explored expanding the basic workflow to include all the different steps and actions performed in a much easier to understand way.

Figure 10.20 This floating diagram is an example of extending workflows to represent complex scenarios involving multiple actions at multiple points. Courtesy of James Melzer.

James described the project and the floats as follows: The system allows people to manage information about the buildings they own. This enhancement will allow building services partners to provide system-to-system data on behalf of their customers, reducing the data entry required for homeowners. The project consisted of three parts: partners configuring the presentation and operations of their data services, customers subscribing to and using partner data services, and ongoing management of partner data and back-end troubleshooting. We were planning a major expansion of an existing system. We knew from the beginning that almost all service scenarios involve multiple users and multiple systems. There were a lot of notifications and many of the processes were asynchronous. This diagram helped us to identify, design and explain the service scenarios needed for the project. In the full version of this work product, we actually had detailed wireframes laid out below the flows in this diagram. The whole covered one wall. Once we were confident in the design concept, we boiled it down to a more traditional multi-page specification.

Take your work to the next level

183

It's important to remember here not to limit yourself to just using workflows or sitemaps. Go beyond the limits of the fundamentals shown to you in this chapter. If you really need something to test your skills, spend some time creating a workflow for tying your shoes. Lots of luck!

184

CHAPTER 10: SITE MAPS AND WORKFLOWS

Design and route wireframes and annotations - before visual design begins. Wireframes and annotations are ways of specifying the intended content, structure, and functional behavior of a view of a page or web application. Combined with sitemaps and workflows, these documents are also extremely useful for identifying prototype scenarios and testing concepts. Lines are normally presented in grayscale, without graphics or final content. Instead, they use placeholder content to highlight representative locations that can guide the visual design. Russ Unger

What is a wireframe? Basically, it's a low-fidelity prototype of a webpage or app screen. A wireframe is used to identify elements that appear on the page or screen, eg B. Sections, navigation content, images and/or media require form elements. Calls to action (CTAs).

Cables are typically created in black and white or grayscale, use image placeholders, and are not covered by font specs (although many implement font sizes to allow separation of text types). They come in all shapes and sizes, from very simple to so advanced that they almost replicate the full-screen design. Cables are evolving. They are no longer just available to designers and developers as sketches for their assignments. Wireframes are used today to represent the website or application to clients, designers, developers and all other team members involved at the main level. It is common to show them to clients to get “design thinking” validation before the visual design and development phase begins. Often, the people making the cables work side by side with those creating the business needs (in some cases, the same people). It should also be noted that some of the best wireframes and annotations are the result of direct interaction and collaboration between the various contributors - from business analysts to developers and other designers. Some companies use their cables and notes instead of Business Requirements Documents (BRDs). While the world is far from saying that BRDs are extinct, the beginning of this change shows the importance of taking great care and attention when creating your cables and notes. In many cases, users are provided with wireframes to evoke feedback that can be used to validate page elements or request changes. cable that

186

CHAPTER 11: ELEMENTS AND COMMENTS

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

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

It's best to write comments in a very direct - if not concise - tone and with clear explanations. Don't leave anything to chance in a comment. There is a big difference between should and should. Bad: "Enabling this call-to-action (CTA) should make the homepage appear." Good: "Enabling this call-to-action (CTA) will make the homepage appear." Okay To be fair, the first example isn't exactly terrible, but the word can be confusing during the process for a developer who might not have the luxury of answering questions from their favorite UX designer. Make sure your note-taking style is concise and leaves no confusion for anyone who needs to read and rely on your instructions.

WHAT ARE COMMENTS?

187

Who uses wireframes? Wireframes are all well and good with their clear and concise annotations, but who is really the target audience for these results? Unfortunately, there isn't a simple answer to this. From project to project, your audience can range from one person to any combination of groups. Table 11.1 describes possible target groups for your cables. TABLE 11.1

188

Shared wireframe

PUBLIC

PURPOSE

project management

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

business analysts

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

Designer visual

Optical designers can use the wires as a template for their production. Wireframes give them a record of the page elements and behaviors to include.

content creator

Copywriters, content strategists, editors, and others responsible for copy can use wireframes to map out a content matrix and determine a project's content needs.

Specialists in search engine optimization (SEO).

SEO professionals can use wireframes to identify appropriate naming schemes, writing requirements, and improvements to their overall SEO strategy. (See Chapter 8 for more information on SEO.)

programmer

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

quality control

A QA team can use wireframes as a basis for writing their test scripts. Once the cables are approved by the customer, deviation should be minimal, allowing the QA team to start working on their tasks sooner.

from the user

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

Customers

Customers are increasingly involved in reviewing frameworks to verify that business needs and goals are being met and to provide approval to move into the visual design phase.

CHAPTER 11: ELEMENTS AND COMMENTS

Creating a wireframe To create a wireframe, you generally need a set of requirements. These can take the form of a formal document of a client's business requirements, a creative or project letter, meeting notes, a well-crafted website or workflow map, or even notes on a napkin with instructions. In either case, you need to understand what you want to create for a user, the context, and a general understanding of the technology's limitations and expectations. Note For more information on defining business needs, see Chapters 4 and 5. For suggestions on effective meeting notes, see the bonus online chapter, A Quick Start Guide for Meetings, at www.projectuxd .with.

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

Tools of the Trade The Tools of the Trade section of Chapter 10 lists the various design tools you can use to create sitemaps and workflows. The good news is that you can basically use the same apps for cables and notes. The bad news is that if this is your first experience wireframing, you might be a little confused about where to start. But wait - there's more good news. Almost all seasoned user experience professionals start with pencil and paper, so you shouldn't feel like you have to decide on a technology solution right away (although it's entirely possible that you'll need to translate the sketches into something digital quickly). Leah Buley, Experience Designer at Adaptive Path, emphasizes the importance of using pencil and paper (as writers do) in her presentation of her How to Be a UX Team of One. Leah says: When you start drawing ideas for a wireframe, it often happens that you have one or two good ideas and then you hit a wall. These ideas likely come from something you've seen and liked or designed in the past. This is not an end point. It's a good starting point.

WHO USES FRAME WIRES?

189

The mind tends to gravitate towards the familiar, but the familiar is not always the best solution to the problem. If you make the effort to look for more varied ideas, often with idea 4 or 5, you will have something new and interesting. I don't know why this is happening. He just does. Templates can be helpful to guide you through this process. In Adaptive Path, we use a Six-Up model that only has room to create six small miniature sketches. The number of sketches doesn't really matter. The important thing is that you force yourself to go beyond the first obvious ideas. Six is a magic number (for me) because the Six template above, with its six little boxes, encourages me to keep going until all the thumbnails are filled.

Figure 11.1 Adaptive Path Six-up Model

Those are good words to live by, especially if you're just starting out in the UX design world. Over time, you'll start to find an approach that works best for you, but there's no better advice than Leah's. For more information on their approach, see the entire How to Be a UX Team of One presentation online at www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one. Don't be afraid to start with pencil and paper - just make sure you have enough erasers with you. Mistakes are part of the process, and you should expect that even after you've done a pencil sketch, you'll still make adjustments when switching to scanning.

190

CHAPTER 11: ELEMENTS AND COMMENTS

Few professions move into the iteration arena as often and consistently as UX designers. Very rarely, if ever, is the draft accepted on the first pass, and sometimes we can only hope to make a "wrong turn in the right direction". So start small: take a single page or a short snippet from a section of a project and review it first with your internal team and then with the client team to ensure your understanding is on track. If you align your plans up front with how the customer thinks about their business goals, you'll avoid a lot of rework down the road. The same approach can be applied to user design testing - look for validation early!

Start simple: create a simple wireframe. In this section, you'll learn how to wireframe a very basic layer. Often you start with nothing more than a simple sitemap and some additional requirements, but with that you can create a wireframe for a website's homepage. Remember the basic sitemap from Chapter 10, which showed how a very simple site can be structured? Figure 11.2 shows an update - as you can see, some navigational hierarchy is displayed. Each identified X.0 page is likely to be a master or higher level page. You can use this as a starting point to define part of the business requirements and a cable. 1.0

1.0.1 Terms and Conditions

Heim

2.0 – 2.xBlog

3.0 relatives

work 4.0

5.0 Communication

Figure 11.2 A sitemap for a simple site with blog functionality

Start Simple: Create a Simple Wireframe

191

Introduction It is not uncommon to author your own business requirements document, and this can be both a blessing and a curse. As a requirements writer, you basically only have yourself - or your customer - with whom to discuss the meaning of something vague or relatively undefined. It can often feel like you're making something up - but don't let that put you off. In many cases, your leads will help you identify gaps in the information you are working with. This might help you find the best solution in the end. Remember that UX professionals work to suggest the best possible solution to users, and early versions of a project are always used to gather feedback and influence the next design iteration. Your design doesn't have to be perfect, but you want to make sure it looks clean, professional, and at worst, wrong in the right direction. The requirements for this homepage design are limited and very short. Fortunately, the site map in Figure 11.2 provides enough information to configure the navigation that can be used for the site: The homepage (number 1.0) is the top-level navigation. Conditions

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

tact (5.0) and blog (2.0-2.x) - rendered as a stack of pages, so you can be sure they'll display as multiple dynamic pages and have a "previous" and "next" navigation format. These key navigational elements provide enough information to get you started, but not enough to effectively create a home page for a website. So, for guidance, the client provided some additional information: The company is a boutique user experience design firm that has gained notoriety through its blogs and the variety of projects it has worked on. It is important that site visitors quickly learn what the company/site is all about through limited text and strong, impactful images that work in tandem with the user experience design. Also, it's important that the navigation is clear (I prefer a reusable header and footer if possible) and

192

CHAPTER 11: ELEMENTS AND COMMENTS

that there is a call to action in our most recent blog posts so visitors can quickly read a summary of our latest take on current issues in the user experience world. If possible, it would be nice to be able to feature recent work on the homepage, but this is secondary as many of our jobs are often in progress or strictly classified.

Wireframes and Annotations There are many ways to interpret these requirements, and the initial presentation of the wireframe to the customer can look very similar to Figure 11.3. WIRE FRAME WITH COMMENTS Home Comments 1

Logo 2

Heim

blog

our work

About Us

Contact

1 Logo image. The logo acts as a link to the homepage

the website from any location within the website. 2 Home Navigation. · Must contain a link to the home page of the website

from anywhere within the site. 3 Blog Navigation. · You must link to your blog landing page from every location

location within the website. 4 · "Our work" navigation. It should link to Our work landing page

from anywhere within the site. 5 · About Navigation. · You must link to the "About Us" home page 6 7

7 8 9 10 11

Welcome title is 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 Schmerz Sit Amet, Consectetuer Adipiscing Elite, 15 Sed Diam Nonummy Nibh Euismod Tincidunt Out Laoreet Pain Magna Aliquam Erat Volutpat.

Wie ich gesehen habe, werde ich zum Minimum kommen, das nicht wie einige von ihnen die körperliche Bestrafung der Spieler ausübt. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Sinto muito pela dor, consectetuer adipiscing 12

13 More > 17

Article #

15 16 17 18 19

from anywhere within the site. · Contact navigation. · There must be a link to the contact page anywhere on the site. · Rotating hero icons. · Images are rotated into multiple images that are aesthetically pleasing and consistent with the brand. · Welcome title. · Title for the site overview text. · Welcome content. · Overview of site content. · · Title.· Title of example randomly displayed from portfolio of work. · · Image link. · Image of the random sample shown from the job card. You must login to view the details of the randomly selected sample from the portfolio. · · Summary. · Short summary of text from the random sample shown in the portfolio of work (maximum 1-2 lines of text recommended). · · More link. · You must be logged in to view details of random portfolio samples. · · Title. · Title of the latest live blog post. · · Enter Content. · The first 200 characters of the last live blog post. · · More link. · You must be logged in to view the full blog post from the last live blog post. · Content protected by copyright. · Copyright and current year and company name. · Terms and Conditions · Link and Conditions · You must create a link to the "Terms and Conditions" and "Terms and Conditions" page at every point of the site. · Contact link. · Must contain a link to the contact page anywhere on the site.

8 · Welcome title. · Title for the site overview text. 9 Welcome content. · Overview of site content. 10 · · Title. · Random sample title

of the task portfolio. 11 Image link. · Image by chance

nt Blogtitel>

I feel a lot, I dissect a prolapso nibh Euismod de 15 mm com aliquam erat volutpat.

I will tell you who we are

15 16 17 18

Comment 19

Sample portfolio of work shown. You must login to view the details of the randomly selected sample from the portfolio. · · Summary. · Short summary of text from the random sample shown in the portfolio of work (maximum 1-2 lines of text recommended). · · More link. · You must be logged in to view details of random portfolio samples. · · Title. · Title of the latest live blog post. · · Enter Content. · The first 200 characters of the last live blog post. · · More link. · You must be logged in to view the full blog post from the last live blog post. · Content protected by copyright. · Copyright and current year and company name. · Terms and Conditions · Link and Conditions · You must create a link to the "Terms and Conditions" and "Terms and Conditions" page at every point of the site. · Contact link. · Must contain a link to the contact page anywhere on the site.

Figure 11.3 Annotated wireframes uploaded to home page design

Start Simple: Create a Simple Wireframe

193

The annotated wireframe describes each element on the page, as well as the expected calls-to-action and the results of the action (for example, loading a specific page). This particular example works really well because of the limited number of elements and the limited amount of detail required.

Figure 11.4 Creating an active homepage for www.userglue.com

As shown in Figure 11.4, today's live version of this home page differs slightly from the original wireframe in Figure 11.3. For example, as time and content became issues, the Portfolio Samples section was removed. Also note the difference in naming conventions for navigation and call-to-action: the wireframe served as a guide, not the final word. Your end result will also feature several small changes and updates compared to the wireframe content.

194

CHAPTER 11: ELEMENTS AND COMMENTS

Exercise One: Designing a Wireframe Homepage You've seen an example, now it's time to jump into it and create your own wireframe. Your task is to redesign the homepage of Global Cruises, a fictitious international cruise company. Global Cruises wants its homepage to be more effective as a sales tool and source of information for returning guests - who often appear to be those who have already booked a cruise and are interested in learning about other deals and extras, as well as updates to learn cruise policies, etc. The exercise is to use the following requirements to create an annotated landing page wireframe in the document or a separate document (your choice). Just it.

Requirements The most important requirement you must meet is that the global header and footer (Figure 11.5) remain the same—absolutely unchanged. GLOBAL HEADER Destinations with logo

Current travel experience with campaign logo

planning a trip

to search for

before your trip

world cruises

VIP club

Particularly

I am going

my world cruises

Welcome back,No?) | 20 Days Until Your Next Cruise - Manage Reservations | Book Travel Extras| Online check-in

Figure 11.5 Global header and footer of an existing global cruise

AN EXERCISE: DESIGN A WIREFRAME HOMEPAGE

195

The footer should read "Sign up to receive emails from Global Cruises" "About Global Cruises |" Contact us | Frequently Asked Questions | Find a Travel Agency | Site Map | Legal Information | Pricing Terms | Privacy Policy Copyright Information In addition, the site must have the ability to display various promotions. Ability to display headlines/news. CTA for customer service. CTA for travel agency locator. CTA to find popular routes

The "nice thing" about them is the ability to display newer, more popular and/or discounted itineraries. The ability to view geographic locations and travel points. The ability to view the itinerary (MY TRIP if you are logged in). The ability to display upsell items, e.g. B. as additional stops (eg when you are on the move).

in Hawaii, booking an island tour), onboard dining experiences, etc. Anything else you can think of that might be helpful

World Cruises And now the work begins. Start designing your cable - and don't forget to leave a comment! When you're finished with your wireframe, check out the next page for examples of other top professionals who have received the same requirements.

196

CHAPTER 11: ELEMENTS AND COMMENTS

The Results: Designing a Homepage Wireframe Will Evans, a User Experience Architect at Semantic Foundry (www.semanticfoundry.com), was kind enough to create wireframes based on the requirements of the Global Cruise exercise. Compare your own work with his projects in Figures 11.6 and 11.7 to see how his approach compares to his. Here's an explanation of how he put together the wireframe and his notes. Travel alerts 990 pixels wide

FIND CRUISES

LOGO

5,0

4,0

3,0

2,0

1,0

Bahamas

New itineraries

I AM GOING

Annotated Notes

popular routes

11 1

Destinations

| travel experience

planning a trip

before your trip

Global Cruises VIP Club

Welcome back W iMMŔLogout

6,0

7,0

8,0

Particularly

Route View | my global

15 days until the next cruise –

9,0 13

1,0

Travel warnings: Connection via 0.2.0.0

2,0

Brand/Logo Links Home

3,0

Search with predictive suggestion, custom scenario 3.X

4,0

6,0

New Itineraries Linked Dropdown: View itinerary linked to section 4.x Popular Itineraries - Top 5 Popular Itineraries dropdown Destination Link: Goes to section X.0

7,0

Link Travel Experience: Goes to section X.0.

8,0

Link to plan a trip: Go to Section X.0

9,0

Before Your Trip Link: Go to Section X.0

Global Cruises VIP Club Link: Go to Section X.0 Special Offers Link: Go to Section X.0

my world 12

5,0

Media/Flash/Hedonic Image

Title for Hero Shot 17 Global Headlines | Create your own lead

Need help planning your cruise?

Header Consectetut Adipisicing clarity is the body's string or pain in rebuke in pleasure wants hair in pain by e.e. to be.

IDEAL IMAGE

Title Consistent Adipicism

Don't be irritated by the pain in the rebuke in the joy that wants to be a hair's breadth away from the pain in the hope that there will be no procreation.

Header idea number 1

Main Idea Number 3

Header idea number 2

Title of idea number 4

Clarity is the Lord's own reins, or the fury of pain in rebuke, in joy that wants to be pity in pain

Main Idea Number 3

October 8, 2008 6:46 pm

brand promotion

But that you may see whence comes all this error inherent in those who blame pleasure and exalt pain, I want to expose all the matter and the very things this inventor made.

post your

I'm so sorry for the loss of connecteur nonummy lorenzino. Sometimes the common man sees that he is making a mistake in this.

25 Sign up for global email.

Not of? Click here

My Global Cruises Link: Goes to section X.0 Logout Link: Logs user out of session

View Itinerary Link: Opens the My Worlds/View My Itineraries page. My Global Link: Go to the Promotions/Custom Bundles Image Carousel page.

Starry Moment Crowdsource-Link

The Book Deals link links to the image in the big hero photo.

Need help planning your cruise?

20/21

CT Promotional Offers as/Affiliate

Perfil do membro do convite Starring Your Moments Publique seu link Starring Your Moments no site de crowdsourcing.

But that you may see where all this inherent error comes from in those who blame pleasure and praise pain, I want to open up the subject and explain exactly what this discoverer of truth and, as it were, the architect of a happy life, said.

Advertising/News

IDEAL IMAGE

IMG

Advertising/News

starring you-moment

Book this special package

Wait a minute! I am going

Change country link

Globale Footer-Links

Page 2

Figure 11.6 Wireframe of Will Evans Global Cruises home page

AN EXERCISE: DESIGN A WIREFRAME HOMEPAGE

197

Travel alerts 990 pixels wide

FIND CRUISES

LOGO

Destinations

5,0

4,0

3,0

2,0

1,0

Bahamas

New itineraries

I AM GOING

OK Will "Bahamas" | Travel Experience | to plan a trip we| Found before your trip

18|

Annotated Notes

Popular routes 1

Global Cruises VIP Club 6.0

Particularly

Cruise Offers

Welcome back W iMMŔLogout

7,0

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

Charleston Freeport

15 days until the next cruise –

7 nights

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

Nassau

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

Nassau

Media/Flash/Hedonic Image

Filter Global Headlines | Create your own lead. Need help planning your cruise?

Charleston Freeport

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

IMG

6,0

Quick Tip: Saved results will show 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. Detailed Link 7. Link to Book This Cruise 8. Remembered/Favorite Cruise

8,0

Faceted navigation allows the user to dynamically change port, month of travel, vessel, price range and dynamically sort/filter the appropriate result set. Any of these items can be undone once the user sees the complete results in the search results screen.

9,0

Once the user has customized the predictive search filters, he can click through to view all the search results, using Ajax to load the complete results into a javascript table for quick sorting.

Perfil do membro do convite Starring Your Moments Publique seu link Starring Your Moments no site de crowdsourcing.

details

Title for Shot FridayHero Saturday

Book this special package

-All ship offers/news

190 to 1650 US dollars

Cephala Adipisisik Duis will follow, or pain will be frowned upon by pleasure, he will be a hair's breadth from pain and there will be no birth.

Clarity is the Lord's own reins, or the fury of pain in rebuke, in joy that wants to be pity in pain

starring you-moment

details

Preis: HEDONICAL IMAGE

Clarity is the Lord's own reins, or the fury of pain in rebuke, in joy that wants to be pity in pain

New Itinerary Dropdown with Link: View itinerary with link to section 4.x Popular Itineraries - Top 5 Popular Itineraries Dropdown

5,0

Nassau

Schiff:

-Every month -

IDEAL IMAGE

Title Consistent Adipicism

Search with predictive suggestion, custom scenario 3.X

4,0

details

Your You Y Moment results now! I am going

Month:

Brand/Logo Links Home

3,0

friday saturday 7 nights

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

Homeport/City: Advertising/News Washington, D.C. 8.0

Nassau

Route View | my global

friday saturday 7 nights

Travel warnings: Connection via 0.2.0.0

2,0

details

friday saturday 7 nights

1,0

my global

HEDONICAL IMAGE 9.0 Show all search results

Cephala Adipisisik Duis will follow, or pain will be frowned upon by pleasure, he will be a hair's breadth from pain and there will be no birth.

Header idea number 1

Main Idea Number 3

Header idea number 2

Title of idea number 4

Main Idea Number 3

October 8, 2008 6:46 pm

brand promotion

But that you may see whence all this error inherent in those who blame pleasure and exalt pain, I will open up the subject, and explain the very things done by this discoverer of truth, and, as you say, the architect of truth, had a life happy. But that you may see whence comes all this error inherent in those who blame pleasure and exalt pain, I want to expose all the matter and the very things this inventor made.

post your

11 1 12

Change country link

Globale Footer-Links

I'm so sorry for the loss of connecteur nonummy lorenzino. Sometimes the common man sees that he is making a mistake in this.

13 12

Not of? Click here

page 3

Figure 11.7 Will Evans Global Cruises homepage wireframe with search enabled

Wireframe construction, as Will puts it, for me, wireframes act as a sort of "thinking device" for setting up and exploring a specific problem area - in this example, the homepage of a cruise line. Designing with wireframes is a search in a problematic space of alternatives. It's as much a problem-solving process as it is a problem-solving process, which means I always start with context. In this case, the general public wants to easily find the best cruise, at the right time and for the right price. For simplicity's sake, I'll pick my core audience and the one activity that allows them to solve a goal quickly, easily, and gracefully. By designing a series of cables, I can explore alternatives and impossible, conceivable ideas are presented, tested and, in many cases, rejected. I already knew that I wanted to design the best possible research interface for cruise ships and I wanted this activity to be at the heart of the project. Here I described the idea of instantly recommending cruises, even before the user commits to viewing

198

CHAPTER 11: ELEMENTS AND COMMENTS

a full screen with search results. I wanted the user to be part of a conversation and included in the process of finding a great cruise. FIND CRUISES

Bahamas

Okay Will to the "Bahamas" we found

I AM GOING

18 cruise deals

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

279 $

Bahamas and Florida

Charleston Freeport

7 nights

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

Nassau

7 nights

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

Nassau

details

friday saturday 7 nights

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

details

friday saturday 7 nights

Great Stirrup Cay (unsere Privatinsel) Port Canaveral Charleston

details

Friday Saturday

details

Friday Saturday

Filter your results Y Home Port/City: Month:

Washington.

Schiff:

-Every month -

Preis:

-Any ship

190 to 1650 US dollars

Show all search results

Figure 11.8 Will Evans home page contains search results for cruises

In the case of the cruise line, I described the header, footer, static content, and the need to hide areas in the design for content modules like CTAs and promotions. I share the results of this phase with key stakeholders, but also involve the visual designer and lead dev and QA so they can contribute to the process, provide more ideas, and start to identify pitfalls and limitations. Ultimately, as a designer, I had to make the decision to translate the design into a specification. I created two or three candidates for final review and used annotations to allow the wireframe to present its arguments to targeted stakeholders and reviewers. The cables you see in Figures 11.6 and 11.7 are now at this stage where there are minor design changes and details are being polished.

AN EXERCISE: DESIGN A WIREFRAME HOMEPAGE

199

Compare and Contrast It is important to note that the example in Figure 11.3 and the work of Will Evans are quite similar—but different—in styles of wire construction. It's easy to look at both now and proudly proclaim, "Those are wires!" Both have elements of their own style and approach, but the core is very similar. The examples in this chapter are good starting points for finding the wireframing style that works best for you.

Photos cortesia de Maciej Piwowarczyk

Visual design: when wireframes grow and find their way into the world

Figure 11.9 Global Cruises homepage visual design by Mark Brooks

200

CHAPTER 11: ELEMENTS AND COMMENTS

Based on Will Evans' requirements and wireframe, Mark Brooks (www.markpbrooks.com) created a homepage design for the fictional Global Cruise Lines. As you look at the visual design in Figure 11.9, notice how it takes into account page layout and content. Once the design is underway and developing, the interaction models come to life.

Hands-On Draft Supervision: Which Draft Is Right? There is no right or wrong design as long as the requirements are met. Sometimes you might feel like creating multiple wireframes for one page to explore different approaches, work out the details and present them to your potential users, teammates and possibly clients. This is perfectly acceptable. Remember this is a repetitive exercise. It's almost always guaranteed that the work you present to a client won't be deemed "right" or "complete" on the first try. Most of the time, you work through at least one round of iterations and updates. Unfortunately, this can sometimes stretch over several rounds - but that's the nature of projects and should result in their eventual partners doing less exploration. As you compare your wireframe and notes to the two examples provided, consider the difference in approach and style of presentation. Compare them with the example on the front page earlier in this chapter and with your work. Find the similarities and differences and develop the approach that works best for you, unless there is already an established pattern for you. In many cases, the hardest part of creating a handle is putting pen to paper for the first time. Take Leah Buley's advice and start sketching lots of ideas - doodle and draw, explore different approaches and test your drafts with classmates, classmates and family until you're sure you can defend your draft (without getting defensive). find that you are moving in the right direction.

AN EXERCISE: DESIGN A WIREFRAME HOMEPAGE

201

One final note on wireframing presentation: once you start creating wireframes and get comfortable with the work product – and understand how valuable they are to your workflow – it's easy to forget that not everyone understands how much time and thought are needed to create them. Customers and business partners were often faced with cables of completely different quality and complexity or with a different labeling style. In fact, you may find that many of your partners and customers have never seen a wireframe before (even if they claim they have). It's also not uncommon for customers and business partners to be confused about the differences between sitemaps and wireframes and the purpose of each. In other words, your first wireframe could be your customer's first wireframe! Therefore, it is extremely important to accurately design the basis of what you want to present. Before introducing the cables, you need to clearly explain what they are, how they look compared to the final visual design, and their purpose. Here are some additional tips for presenting cases: Whenever possible, involve your client's team in the investigation. try to catch them

Take an active part in drawing on a blackboard. Explain that they will contribute to the wireframing process and that the end result will be similar but in electronic form. It's very important to explain that this is an activity that can result in cables looking completely different as you explore the design options. Find powerful metaphors to convey the differences between your cable

Framing conditions and final design of the project. A popular metaphor is "wireframes are to applications/websites what blueprints/blueprints are to a house". the foundation is laid). Tell meeting participants that wireframes are not definitive representations.

the graphic design of the website. Threads are introduced to consider their content, overall layout, and how they interact

202

CHAPTER 11: ELEMENTS AND COMMENTS

page elements. Once the cables are approved, construction can begin. (Oh, and there may still be minor changes!) If you have the time and budget, ask your visual designers to provide

Create mockups to show the differences between your wiring and a final design. If possible, show the customer examples of other projects that show that the cables and final designs are similar and different at the same time. Explain how other members of your project team will use the cable

Wireframes - It never hurts for a client to understand the importance of reviewing and approving this milestone and how wireframes affect the rest of the project. Once your clients and partners begin to understand and appreciate the value of wireframes and their importance in the design process, it becomes easier to move your projects forward. Why; Because cables help provide visual clarity and direction as the project progresses. In many cases, partners and customers can even promote the usefulness of wireframes on their behalf. This allows you to focus more on creating the user experience and less on selling!

A final note on the wiring diagram

203

Prototyping brings (some kind of) life to your designs. Prototyping is an effective way to test and validate proposed features and designs before investing in development. You can use a variety of prototyping tools and approaches, from quick and dirty (we prefer quick and clean) to iterative and robust. Which method you use will be largely determined by two factors: the time and materials you can dedicate to prototyping. Russ Unger and Jono Kane

What is prototyping? In the context of user experience design, prototyping is the process (and in many cases the art) of building and testing the functionality of an application or website, in whole or in part, with users. Prototypes can be created using analogue 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 often created to identify or validate user experience issues. After collecting feedback, you can make changes to the prototype for further testing. In other cases, a (fairly successful) prototype can propel a project through other phases of the development lifecycle. Remember that prototyping is a process, not an artifact. You may end up creating (sometimes fake) screens and functions that you call a prototype, but that's part of prototyping and not the end result. The result of the prototyping process is active feedback of concepts that can be used to refine and improve the design. However, this chapter focuses only on prototyping, leaving the details of testing for Chapter 13.

How original do I need? Every user experience design process should involve some level of prototyping, whether formal or informal, interactive or static. Prototyping doesn't have to be done for an entire website or application. In fact, prototyping can be very efficient if only representative samples of a system are used. In other words, you don't need to simulate the whole system, just important parts. In most cases, you want to test a few concepts, and your prototype should include those concepts and a little more. You can create prototypes using any number of methods at your disposal: whiteboard, pencil and paper drawing, storyboarding, cardboard cutouts, etc. more realistic environment.

How many originals do I need?

205

The prototyping method you choose will depend heavily on the time and materials available. Here are some of the most popular methods available to meet many of your prototyping needs.

Paper Prototyping Few activities can take you back to your early years as much as the practice, art and craft of paper prototyping. The only tools needed are pencils and pens, paper, scissors, and anything else you can get from the art department or buy at a local office supply store. Paper prototyping is flexible. As long as you have an eraser or more materials, you can create as many backdrops as you need. You can also quickly revise from test to test - which means that if a potential user sees a glaring flaw in something you've created, it's not a complicated process to update the design before showing it to the next potential user. It's cheap too. Aside from the time you invest creating paper prototypes, you can usually create any script for far less than the cost of a few quality lattes. Paper, sticky notes, index cards, pencils, and the like should already be on hand, and if not, stocking up won't break the bank. The process is simple: create the functionality you want to test. Introduce resources to users. Document the feedback (it's paper, so turn the original over and start writing). Then move on to the next user or make updates and start over. Simply. Fun. Effective. Used early in the process, paper prototyping can help uncover design-related issues before you make large investments. Changes at this stage can be made quickly and efficiently, reducing risk. This allows you to make effective changes before investing too much in the design. Using three different colored sheets of paper, each tab in Figure 12.1 was drawn as it would appear on the website and stacked one on top of the other. The Global Now tab is placed on top to display its content as if the user has just visited the homepage for the first time. On each tab, users are presented with the available navigation and can choose a different view option.

206

CHAPTER 12: STANDARDIZATION

Figure 12.1 Paper mockup of tab-based vertical navigation

Figure 12.2 Paper model of vertical tabbed navigation with the My Itinerary tab activated.

When a user selects another tab, that particular tab is placed on top of the stack to show the last active tab view of the content area, for example, B. The My Itinerary tab in Figure 12.2. Making paper prototypes is as inexpensive as possible and can be as simple as the exercise above. When you start exploring full systems, the hourly investment can become significant (although your material costs increase only slightly). If you need to change the main navigation on one hundred pages of original paper, then this method becomes expensive. While making paper prototypes is inherently inexpensive, it doesn't scale well for reuse when parts need to be updated. At this point, you should consider whether switching to digital tools would make more sense.

Digital Prototyping If your prototyping needs are greater than paper can handle, you may find that a technology-based solution works best for you and your audience. These tools allow you to show exactly how the interactive parts of your website or application will appear to users. Digital prototyping builds on many other aspects of the design process. You can refer to their faces, their wires to block and visually edit the prototype and visual design elements (if available at this point in the process) when rendering or testing your digital prototype to ensure a realistic fit and finish your prototype achieves.

Wireframe versus Realistic Prototyping As with paper prototyping methods, digital prototyping mileage can vary. Depending on the tools, resources and skills you have at your disposal

DIGITAL PROTOTYPING

207

Due to rejection and the requirements you are dealing with, you may find that if your prototype looks like yarn, that will be fine for your project. In fact, it could even be better. Wireframes can show the audience that the project is a work in progress and not the final production-ready website. On the other hand, when testing designs with users, you will sometimes find that the most important aspect of the prototype is how realistic it represents the final system. The result of your digital prototype is based on three factors: What is your timeline?

Você tem tempo para reunir uma equipe e construir um incrível protótipo quase pronto para produção que mostre aos usuários sentados em frente a ele uma visão cristalina do site pronto para produção? Você tem algumas horas para exportar seus wireframes como HTML ou criar um projeto Flash muito básico para mostrar apenas o fluxo da página e os elementos interativos básicos dentro do projeto? Ambos os tipos de protótipos digitais podem ser muito úteis. No entanto, como em qualquer projeto do mundo real com prazo, é importante definir as expectativas com base no tempo e nos materiais disponíveis. Para quem você está construindo este protótipo e por quê?

It's critical to the success of your prototype that you know what you're doing with it before diving into the design. Do you create a prototype to test the design with users? If yes, what should be considered during testing? Does it matter if the prototype is a black and white wireframe or does it have to look like a live website? Do you test the discoverability of buttons and links? Are you prototyping a business proposal that needs approval from a group of executives, managers, investors, or anyone else who might be signing your check at the end of the day? If yes, what are you trying to tell them? What has to be functional and what just has to look functional? These questions can help you identify requirements for your digital prototype.

208

CHAPTER 12: STANDARDIZATION

What resources, tools and skills do you have at your disposal?

Unless you're an HTML or Flash expert and don't have the budget to hire someone who is, you can create a very functional prototype using a simple presentation tool like PowerPoint or Keynote, or a wiring tool like Visio or OmniGraffle. Even a simple PDF can do it.

HTML vs. WYSIWYG HTML editors is the digital equivalent of a paper prototype. It's (sometimes) free and (reasonably) easy. If you're not an HTML wizard or front-end code expert, you can still be an HTML prototyping wizard with some basic knowledge of HTML. There are two main ways to create an HTML prototype: by hand coding the HTML or using a WYSIWYG editor such as Adobe Dreamweaver, Realmac's RapidWeaver or Microsoft Visual Studio. These tools have a code view as well as a layout view that allows you to visualize your code efforts without having to open a browser. Prototyping with a WYSIWYG Editor The nice thing about using Layout view in a WYSIWYG HTML editor is that you can create a page layout with almost the same amount of effort as creating a page in Microsoft PowerPoint, Apple Keynote, or any other simple layout application. needed (more on that later). And it's so easy to add interactivity like links, mouse events, etc. One of the most impressive aspects of Dreamweaver CS4 (Figure 12.3) is that it has what Adobe calls Live View, based on the open source WebKit rendering engine. What does that mean? This simply means that what you see in Live View is exactly what you get in Apple's Chrome and Google's Safari browsers - as long as you're careful with the details of your prototype. Dreamweaver CS4 is a very powerful prototyping tool, especially when used in conjunction with Adobe Fireworks CS4.

DIGITAL PROTOTYPING

209

Figure 12.3 An example of a simple prototype created in Dreamweaver CS4

Creating a Simple HTML Prototype Perhaps the least expensive way to create a simple, quick, and straightforward HTML prototype is to do it "by hand," which means manually typing the code into a text editor. One of the most common reasons for transitioning from a wireframe to prototype design is the need to showcase or test the flow and navigation of the proposed website. By taking blocks of elements or even entire pages from your wireframe (or design mockup) and setting them as clickable images in your HTML prototype, you can create a working prototype very quickly and easily. A very simple prototype that allows you to click on full page images in a browser and load different pages is pretty simple. For the following exercise, you should have a homepage and search result wireframe, or you can download sample images from www.projectuxd.com. Note: Typos are among the most common errors in HTML coding. So be very careful about typing accuracy.

210

CHAPTER 12: STANDARDIZATION

1. Export your homepage wireframe from your favorite tool (such as Visio or OmniGraffle) or export the composite design from your visual design tool. You must save the entire page as a GIF image called homepage.gif. Create a new folder called Prototype and save the homepage.gif file there. Note: The JPEG format is great for raster and photo-like images. GIF works best for yarn and line art.

2. In your WYSIWYG HTML editor or a plain 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, be sure to select HTML as the file format. 3. In your new document, paste 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 and open the file in your web browser. You should see a blank page, but look at the title bar in the browser. It should say "home". 5. In your text editor, change the "homepage.html" code. Enter the tags and enter the following HTML code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

This code turns the entire homepage.gif image into a clickable button that loads the searchresults.html page (which you need to create to see if the functionality works successfully). 6. Save your document and reload the page in your browser. You should see the new homepage you just created in your browser in all its glory (Figure 12.4). When you click on the image in the browser, the browser tries to load the searchresults.html page (which does not yet exist).

DIGITAL PROTOTYPING

211

7. Repeat step 1 to wireframe the search results content. Save this page as a GIF image, name it searchresults.gif and save it in the Prototype folder. Save a new copy of the current homepage.html document as searchresults.html. Select "Save As" for the current page "homepage.html" and save it as "searchreseults.html". Then update your HTML to reflect this and link back to the homepage (homepage.html). You need to replace this line of code: 1V]gZ[2hZVgX]gZhjaih#]iba31^b\hgX2]dbZeV\Z#\^[WdgYZg2%31$V3

Με αυτό: 1V]gZ[2]dbZeV\Z#]iba31^b\hgX2hZVgX]gZhjaih#\^[WdgYZg2%31$V3

8. Once this page is created, you will have a very simple HTML prototype that shows how two pages can be linked together.

Figure 12.4 HTML prototype of the home page as displayed in a web browser

212

CHAPTER 12: STANDARDIZATION

Analyzing the Code Now that you've created a simple prototype using a very limited amount of HTML, let's take a quick look at the code or HTML tags you used to better understand what you've just done. The HTML, Header and Title tags 1]iba3 1]ZVY3

1i^iaZ36Wdji1$i^iaZ3

1$]ZVY3

are basic tags needed in all HTML documents. Important here is the title tag, with which you can specify the name of the page. An image tag 1^b\hgX2]dbZeV\Z#\^[3

it is also a simple term; is all you need to display an image in a browser. Anchor tags like this one, 1V]gZ[2hZVgX]gZhjaih#]iba31$V3

are used to set up links in your HTML document. For simplicity, the example anchor tag uses a relative path - "relative" because the tutorial is in the same folder. An absolute path looks like this: 1V]gZ[2]iie/$$lll#jhZg\ajZ#Xdb$XdciVXi#e]e31$V3

While this HTML code is not styled or standards-compliant (don't show it to a developer - he might be asked to teach you a hard lesson in code development practices!), it's more than enough to provide your prototype to a program to navigate. Remember, this prototype doesn't have to be perfect: the goal is just to get your ideas out to the public. This simple markup example creates linked HTML files that allow for page-by-page navigation. But what if you want more detailed information about the clickable areas of the layout? The answer: image maps. Image maps let you define areas of an image to link and show different pages when clicked. The easiest way to create image maps is to use a WYSIWYG tool like Dreamweaver to map parts of a linkable image without having any real knowledge of creating HTML code. For more information about creating image maps, see How do I create an image map for?

DIGITAL PROTOTYPING

213

My webpage tutorial by Dave Taylor at: www.askdavetaylor.com/how_do_i_create_an_image_map_for_my_web_page.html. HTML prototypes are just one approach to digital prototyping. Many different frameworks and dynamic programming languages can be used to create very powerful prototypes that cover almost any need. If HTML prototyping is an area you want to explore and expand on, look for tutorials and other resources to delve deeper into this area. To get started, you might want to research JavaScript, PHP (or other dynamic programming languages), jQuery (http://jquery.com), or Yahoo! to search for. Interface library (http://developer.yahoo.com/yu). Note For a more in-depth look at HTML, see HTML Dog: The Best-Practice Guide to XHTML and CSS by Patrick Griffiths (New Riders, 2006).

Additional Tools for Prototyping You've now explored practical options that can help you with prototyping in both analog and digital spaces. In addition to these methods, there are several other software tools you can use to create prototypes, ranging from the simple "do the job" to the more robust and full of interaction and intelligence. The list below is far from exhaustive, but it does offer a variety of options for creating the right prototype for your situation. PowerPoint and Keynote A PowerPoint or Keynote template falls into the "quick and dirty" category, and sometimes that's all you need. You can create your PowerPoint or Keynote prototype with simple interactions, as well as create a simple presentation. Both tools let you create interactions to simulate a click on a flow that you want to validate with your users. If you're a PowerPoint or Keynote power user, you can incorporate animations and other elements to make your prototype a little more interactive. Adobe Acrobat PDF Exporting the wireframes or parts of the visual design as a multi-page PDF can be sufficient to show what the product looks like and how it can be navigated in a linear page-by-page format. Remember that many apps use 214

CHAPTER 12: STANDARDIZATION

Export to PDF, and if you're using a Mac, you can select "Print to PDF" of virtually any document or file in any application that supports a print function. In many applications, including Visio and OmniGraffle, you can use hotspots and actions, such as connection location, for interactivity. Visio and OmniGraffle Both Microsoft Visio and the Omni Group's OmniGraffle are well-known tools for creating wireframes. Both allow you to create prototypes in a few clicks, as they can be exported to HTML and PDF formats. In OmniGraffle, you can easily assign actions and specify a jump point to a PDF file or URL when exporting to HTML. Visio offers downloadable prototyping kits on the web that allow easy export to HTML or PDF with clickable areas to navigate from page to page. Visio and OmniGraffle can also export popular vector and raster formats such as EPS, GIF, and JPEG, so you can easily import your images into Flash, use them as images for HTML prototypes, and more. Axure RP The "RP" in Axure RP stands for Rapid Prototyping, which makes the tool popular with many user experience designers. The tool offers similar design capabilities to Visio and OmniGraffle, but has a relatively easy-to-learn toolset that lets you create a variety of navigation styles, forms, pop-ups, and other typical page-based interactivity. In addition, the flexible integration of specifications, comments, tasks and progress indicators allows the creation of document-based specifications directly from the prototype. However, Axure is a Windows-only tool, which can pose a challenge if you're on a Mac and don't use apps that allow you to boot into Windows. Fireworks CS4 Adobe's Fireworks CS4 has recently gained popularity as a tool for creating a variety of design elements, from wireframes to visual designs. It has a standard set of Windows and Mac form elements and controls that allow for easy-to-define interactions that can highlight functionality without requiring an external developer. Shared library stores items that can be added and shared in documents so you can reuse them

DIGITAL PROTOTYPING

215

components. Fireworks also has a pages feature that lets you create sets of elements that apply to all pages in a given document — similar to how developers use includes or how some documentation systems let you create backgrounds for reuse across pages in your document. document. This feature is useful for identifying repetitive content areas at the page level, for example B. Header, Footer and Navigation, keeping content areas unique on each page. Balsamiq Mockups Balsamiq Studios Mockups is a wiring and prototyping tool that offers an experience similar to sketching cables with pencil and paper - only you use a computer. There are several common pre-built UI controls available (over 60 at the time of writing) that you can drag and drop onto your canvas and customize for your project. His models are designed as if they were hand-painted, giving the digitally created displays a slightly more organic look. However, the digital platform allows you to quickly change designs for quick iterations. Flash and Flash Catalyst prototyping with Adobe Flash is a great way to communicate interactive concepts beyond a simple clickable prototype. With Flash, you can easily create clickable prototypes, but you can also add other interaction elements, including hover or hover events, click events, videos, and animations. If you can explore Flash further, it also has a core set of UI elements that can be programmed to respond to user interaction and exhibit the desired effect. For a protocol for prototyping in Flash, see Alexa Andrzejeski's article "Quick and Easy Flash Prototypes" in Boxes and Arrows: www.boxesand Arrows.com/view/quick-and-easy-flash. As this book was about to be published, Adobe announced a new prototyping tool called Flash Catalyst. Flash Catalyst is a development environment that works with the other applications in the Adobe CS4 suite and acts as an interface between the design and development process. This allows you to export your designs to a browser-ready format with little effort. For more information visit www. adobe. with.

216

CHAPTER 12: STANDARDIZATION

Work with a developer If you have the resources, you can hire a developer to prototype for you based on your wireframes or designs. Remember that the developer must have a solid understanding of what you are trying to achieve. So with this approach, you might also need to create specifications and development requirements to make the process efficient and effective. If your prototype is going to be used for iterative testing, be sure to communicate what parts of the prototype you want to test and therefore what changes need to be implemented quickly. It is recommended that you spend some time with the developer during the development process and identify key areas of code that should be marked (with code comments) as susceptible to change. Be sure to stay in touch with your developer during prototyping to keep the lines of communication open and ensure the results are accurate. Note For more details on the different approaches to prototyping, see Todd Zaki Warfel's book, A Practitioner's Guide to Prototyping (Rosenfeld Media, released 2009: www.rosenfeldmedia.com/books/prototyping).

Prototyping Examples The simple, easy-to-implement prototyping examples in this chapter are far from a complete set of approaches that you should use for all situations. To highlight some real-world uses of prototyping, Keith Tatum and Jon Hadden generously shared their experiences. Keith Tatum, Senior User Experience Strategist at Slingthought (www.slingthought.com), created the original document in Figure 12.5 to explain left navigation links and navigation hierarchies and categorizations to his partners at Align Interactive (www.slingthought.com). alignin.com). . identify). Additionally, the paper prototyping process allowed him to skip the wireframing phase and move on to visual design and layout (Figure 12.6).

EXAMPLES OF PROTOTYPES

217

Figure 12.5 Prototype document explaining navigation concepts to the development team

Figure 12.6 Designing a live website based on the paper prototype

Keith used his team's shared understanding of design and development work to quickly produce a project in two business days. This allowed the team to quickly move forward with development once the visual design concept was approved.

Figure 12.7 Functional prototype calendar tool, mockup using high-fidelity XHTML, CSS, and JavaScript. Courtesy of Jon Hadden

218

CHAPTER 12: STANDARDIZATION

Jon Hadden (www.jonhadden.com), a senior visual designer at Yahoo, has prototyped calendar functionality for a tool he developed called Project Manager. Project Manager is a web-based application for collaborative project management. It started as an OmniGraffle wireframe and then prototyped as high fidelity XHTML to see if the functionality was usable and accessible. Accessibility is an important issue: in some cases, parts of an application or project may be prototyped to verify that the functionality is cost-effective. When the cost of build functionality becomes an issue and prototyping exceeds expectations for time and hardware, you may need to assess the feasibility of your project.

What happens after prototyping? Once you've completed the prototyping process, you need to consolidate your findings and turn them into something that can work. If you've already done paper prototypes, you may need to start creating digital wireframes based on the feedback you've received. If you are already in digital wireframe mode, you may need to update your wireframes and continue with the design process. Alternatively, you may need to consider their feedback and update your prototype for another round of review. Todd Zaki Warfel, president of Messagefirst (www.messageirst.com), shared the following: Prototypes are a way to accomplish one or more of the following goals: Work your way through a design. Create a common communication platform. Sell your design ideas internally (eg to your boss, other designers, etc.) Technical Feasibility Testing Test design concepts with end users/clients. Prototyping serves as a feedback mechanism. Prototyping lets you decide whether you want to continue with a specific design direction or explore another before moving on to the next phases of your project.

Remember, no matter where you are in the process, prototyping is just part of the process, and like any other part, you need to know when you've reached peak efficiency and are ready to move on to the next phase of the experience process. of user. WHAT HAPPENS AFTER PROTOTYPING?

219

Test the design with users beyond what you think you know — and learn how they think. In Chapter 6, we covered several UX design techniques that can help you understand your audience - their needs, attitudes and preferences towards the general theme represented by your website. This chapter discusses techniques to help you gather user information about a specific theme or theme element. We focus on exploratory techniques, often used early in the design phase, and usability testing, which can be used at various points in your project. First, let's talk about exploring design concepts with your users. Carolyn Chandler

Concept Exploration Concept is often the word used to describe an abstract idea, such as happiness, collaboration, or efficiency. In the field of UX design, the term also refers to design elements that serve to present one or more abstract ideas to the project team or a potential user. In this sense of the word, a conceptual design element can be visual (for example, a photograph of a machine representing the concept of efficiency) or text-based (for example, a small collection of sentences written to convey the concept of efficiency). ). Focus on efficiency and use words like timely and responsive. The concept can also involve exploring frameworks, visual design mockups, or rudimentary prototypes intended to express the overall message of the site (see Chapter 12 to learn more about prototyping). Concept exploration is usually done early in the design process, after you've defined your user groups, but before you delve into the details of each page or screen. Research can provide inspiration for designers and, in part, reduce the risk of bringing a new product to market because you can listen to (and then plan for) reactions from potential users.

The main purpose of concept exploration is to understand the types of reactions and ideas that come from your user groups when they are faced with a set of design elements.

Concept exploration can consist of individual or group sessions, but also includes some individual activities aimed at gathering and discussing different points of view. The latter can be set up as a focus group, with part of the time devoted to proof-of-concept activities followed by a group discussion (see Chapter 6 for more on focus groups). Let's look at an example of concept exploration conducted by a not-for-profit microfinance organization.

EXPLORATION OF THE CONCEPT

221

Potential pitfalls of concept exploration Henry Ford once said, "If I had asked my customers what they wanted, they would have asked for a faster horse." count on them who support designers. After all, the most memorable designs often differ greatly from those that preceded them, and survey participants may not be comfortable with a large amount of change. Participants' responses are based on their current understanding. What you collect are reactions, not predictions of what they want or don't want in the future. Also, keep in mind that many other factors outside the plan itself will influence future behavior (eg, positive word of mouth). Avoid asking participants to make direct decisions (eg “Which concept is better, A or B?”). Instead, listen as they describe the concepts presented in their own words. The results should be seen as input to the design process and not as an obligation for designers. For an excellent overview of the potential pitfalls of testing design concepts and recommendations for the correct use of the technique, see this article on the AIGA website: "Design Meets Research" by Debbie Millman and Mike Bainbridge: http://www. aiga.org/content.cfm/design-meets-research

Microcredit is the financing of small loans to entrepreneurs in poor countries. These loans can allow borrowers to build businesses and thereby improve the lives of their families and communities. Loan money comes from people coming together to lend or donate small amounts to cover a larger loan (for example, $25 each to fund an $800 loan needed by a shopkeeper in Kenya). Entrepreneurs repay the loan as the business grows. The funding model is very effective, but the organization sometimes found it difficult to explain the concept in simple terms. In addition to the challenge of describing microfinance, the agency was also unsure how to approach religion-related messaging and design. This specific microfinance organization was inspired by the beliefs of its founders and employees. Many in the organization wanted to do it

222

CHAPTER 13: TESTING THE PROJECT WITH USERS

That inspiration was evident in the site's design, but they weren't sure how to strike the right balance: if the depiction of religious messages was too strong, it could alienate potential donors who weren't of that faith. Too thin and the organization would not really represent your values. The project's UX designers decided to explore the ways in which images and text could be used to explain the microfinance model and showcase the organization's religious inspiration, without angering potential donors. To do this, they chose images and words that could be used to explain concepts related to the model (eg, self-reliance and investment), as well as other concepts that represent different degrees of religious messages (eg, faith and spirituality). Then, focus groups were created with participants who belonged to the site's target user groups. Two groups of users were included: those who indicated that donations were an expression of their religious beliefs and those who did not. For each group, the moderator explained the donation model (without talking about religion). Each participant received a poster sheet, a set of images and words to use, and additional blank cards to write their own words on if they wished. They were asked to create a collage of the images and words they would use to explain the model to their friends and family. When finished, participants came back together to present their collages and explain why they chose certain images and texts and why they chose not to include others. Figure 13.1 shows an example of a collage created in this exercise. Figure 13.1 An example collage created by a participant during proof of concept

The project team gained valuable information from these collages and the ensuing discussion. information has been included. Participants avoided images that denoted success in the "West

'ern' (eg suits and folders). They wanted to improve the lives of entrepreneurs without changing their culture.

EXPLORATION OF THE CONCEPT

223

All user groups agreed that the focus of the page should be on the objective

of the organization (providing entrepreneurs with the means of growth and prosperity) and not the motivation behind it (religious inspiration). Participants felt that while it was important for the organization to remain true to its essence, these messages could be provided in a dedicated section describing the organization itself (for example, in the About Us section). ). The resulting attitudes and interests helped the team decide the direction of messaging on the site - and provided a great example of the value of proof of concept!

Tips for Exploring Visual Design Mockups At some point in the project, you may have mockups that represent the potential design of your site's pages. If you choose to explore designs with participants, it's best to have two or more variations available to compare and contrast. With just one, you're more likely to have the "nice" bias: people don't want to sound overly critical of the model because they don't want to hurt the designer's feelings. However, with two or more models, they are often more comfortable criticizing, as they focus more on comparing designs rather than directly criticizing them. You can present each draft to participants individually (either on screen or in hard copy) and ask a series of questions. For example, you could ask participants to look at each draft for one minute and then choose at least three terms from a list that best describe the draft. They could circle their choices on a 20-word sheet like boring, modern, conservative, strong, safe, etc. in random order. Answers to open-ended questions can also be collected. For example, you could give participants five blank lines to write their overall impressions of the design. Some of the information you may collect includes common brand associations from your participants:

"Pseudo Corporation is the Rolls Royce of widget makers: it looks great, but you probably can't afford it."

224

CHAPTER 13: TESTING THE PROJECT WITH USERS

Lifestyle design and implementation:

"I don't think I would let my son go that way. "He's only 8 years old and these photos look too mature for him." Effectiveness of a specific model in explaining a new concept:

“Oh, I see – this site is like a marriage registry, but you register for charitable donations instead of the courts.” See how participants define some of the key terms you used:

"When I see the word 'solution' on this site, I think this is where I can find all the products and services I need to track my shipments." Questions or concerns about using a specific toolkit

or the impact of its introduction (the following section illustrates several examples of participant concerns). Designers can use these responses to assess whether the responses they are getting are what they intended or if they need to try a different approach. Keep in mind that participants (and stakeholders alike) often choose different elements from different designs: "I like this part of idea A, and I like this part of idea B." quite literally. You don't want an unnatural merging of two different design directions. If the visual designer thinks the popular elements go together well, move on. But give her room to say it's less about "chocolate and peanut butter" and more about "chocolate and pickles." In general, there are no hard and fast rules about the activities included in concept tests or the types of items you can test. Instead, the key is to ensure that you and the project team set the right expectations about what kind of information will emerge from testing and how that information will be used to inform design decisions, without stifling creativity.

Usability Testing Usability testing is one of the most commonly used methods for testing UX designs. It's also better known among non-UX designers, so business stakeholders and the project team may already be familiar with it. The idea itself is elegantly simple: create a set of priorities

USABILITY TEST

225

Ask a few users to perform tasks on your site and see where there are problems and successes.

Usability Testing versus User Acceptance Testing Some people in your organization may have the misconception that usability testing only happens at the end of development or early in development when there is a working version of the site or application - possibly 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 lead to confusion. For applications that go through a formal QA process, the UAT is one of the later stages of testing and is rarely performed by real users. The main purpose of the UAT is often to serve as a final verification that the application meets the functional requirements defined by the stakeholders. it can also detect bugs or errors reported by participants. While UAT can highlight usability issues, it should not be considered the only method for capturing these issues in a design. Because it happens so late in the process, changes based on UAT feedback are much more expensive. It's much better to catch important issues early in the process, before spending too much time on development. Usability testing aims to provide true performance information early in the process.

The following sections discuss general usability testing steps such as: B. Choosing an approach, designing the survey, recruiting and logistics, writing discussion guides, facilitating, analyzing and presenting results, and generating proposals

226

CHAPTER 13: TESTING THE PROJECT WITH USERS

Before you begin, think about your project's goals. They help you stay focused at all times, but are especially helpful in the early stages when choosing an approach and designing the test.

Choosing an approach Research approaches are often described as either quantitative or qualitative. Quantitative research focuses on numerical data and aims to provide reliable and repeatable results to your target audience. The goal is to include a large enough group of users in that group (called the sample size) so that you can learn from this smaller group and make inferences about how the group of users as a whole will react, within a given tolerance for error. . Overall, it is a more scientific research approach involving formal test design and analysis. The focus is on evaluating the current design - particularly against other iterations of the site, against competitors or against a set of benchmarks. Quantitative research means involving a larger number of participants to account for differences between individuals, e.g. typing speed, familiarity with similar websites, etc. Polls are an example of an information gathering method that can be scaled up to a larger audience and produce quantitative data - as long as you ask the right questions (learn more about polls, see Chapter 6). Qualitative research, on the other hand, focuses less on levels of confidence and repeatability and more on gaining context and insights into user behavior. It is based on the interpretation of the designer's insights, intuition and common sense. (The contextual inquiry discussed in Chapter 6 is an example of qualitative research.) A qualitative approach allows for an openness to testing that encourages the exploration of ideas and the acquisition of knowledge. Talking to the user is just as important as your performance, if not more so. The focus is on improving the current design - getting insights and reactions to what is presented to generate ideas. So is usability testing a quantitative or qualitative method? This is one of the oldest debates in UX design. Either approach is possible and can yield useful results. Proponents of a more quantitative approach say:

USABILITY TEST

227

Allows definition of measurable benchmarks against which they can be tested

Later iterations show progress towards a goal (for example, reducing checkout time by 20% or fixing 80% of a site's usability issues). This also makes it a good approach if you want to do a formal comparison of two sites or rank a specific site. It provides statistically validated results that can be meaningful

This is not necessary when there is a need to support recommendations for stakeholders who rely on data-driven decisions. Reduces the likelihood that an individual UX designer's bias will influence you

Results. Offers a higher level of confidence in the resulting results

reflected in the results of the entire user base. It provides a clear numerical method for validating a finding (e.g.,

how many users encountered the same problem). Proponents of qualitative usability testing say: Qualitative research creates experience and empathy for the designer,

Encourage creative and user-centric solutions. Too much relies on the UX designer's intuition to make sensible recommendations

Bug fixes, which are a big part of why he's on the team. In the case of usability testing in particular, a qualitative approach often makes less sense.

more expensive than quantitative research, both because fewer users are needed and because qualitative research does not require design knowledge and formal scientific analysis (eg, statistics). It is very easy to misinterpret the results of quantitative studies by lying

(though unintentionally) with data, so a quantitative approach can actually carry more risk than a qualitative test if not done correctly. Although the results are not validated numerically, they can be validated by

A designer who uses his/her reasoned thinking to show the potential impact of the problem and builds the reasoning around user stories. Qualitative usability testing is the most accessible approach for those unfamiliar with formal scientific methods and provides a rich source of data for design. For these reasons, we will focus on qualitative test design in the remainder of this chapter.

228

CHAPTER 13: TESTING THE PROJECT WITH USERS

How many users is "enough"? Ask “How many users are enough?” In a group of user experience designers, it's like talking about religion at a political rally – it's a hotly debated topic. There's also no avoiding this question, because you need a framework from which to plan your search. It depends on which approach you use: quantitative or qualitative. To give you a short answer, here are the guidelines that seem to have achieved the most consensus in the UX space, provided by Jakob Nielsen: For a quantitative test, plan for a larger number of participants: 20 participants per survey round (see .http :/ /www.useit.com/alertbox/quantitative_testing.html). For a qualitative test, five to eight users per group per survey round is usually sufficient. Ideally, more than one round of investigation is performed to uncover issues that may have been "hidden" in other issues or inadvertently introduced into the new design (see http://www.useit.com/alertbox/20000319.html).

Research Design When designing a usability test, you should answer a few questions at the start to establish focus and scope. This can be provided as a document to be written and discussed with the project team and key stakeholders, often referred to as a user research plan. The plan should describe the approach chosen above. Why are you testing? Write a clear statement describing the test objectives based on one or more overall design objectives. See Chapter 2 for examples of design objectives and how they differ by project type. Who are you testing? Once you've created your user model (see Chapters 6 and 7), you can use it as the basis for your decisions about which users to test. If you haven't already, convene with the project team and relevant stakeholders to prioritize user groups. This information will be forwarded to your controller (see Recruitment and Provisioning section). USABILITY TEST

229

At this point, you must also select the user groups to represent and the number of users to include in each group. What are you trying When it comes to what you are testing, two related questions need to be asked: What method will you use to render the website or application? and what tasks do you plan to include? If you want to redesign an existing application, first run all the testing with the current version to identify the main usability issues that need to be resolved. When working on a new design, you can use sketches or paper prototypes (for example, a bundle of printed wires) to represent new interface elements, such as pages. These low-fidelity UI representations allow you to quickly generate and discuss ideas within the project team and quickly iterate with stakeholders (see Chapters 10 and 11 to learn more about sketches and wireframes). When working with a new theme that contains highly interactive elements, it may be best to create a prototype that realistically simulates the theme's navigation flow, but can still be built quickly before full-scale development begins (for more on this, see Chapter 12). develop prototype). The pages you enter are closely related to the tasks you've selected. If you want to use prototypes for user testing, you need to plan the main task pages as well as intermediate pages and alternate paths. You may not need to detail each step, but you should craft a response when a user goes in that direction. Sometimes this can be as simple as a page stating that a certain route is unavailable and asking the user to go back to the previous page and try again. Details of their tasks are listed in the discussion guide (see below). However, as the scope can vary greatly depending on the type of tasks you're including, it's helpful to outline the list as you plan.

230

CHAPTER 13: TESTING THE PROJECT WITH USERS

Deep Dive To learn more about iterative design and sketch testing, and truly inspiring insights into creativity in the design process, see Bill Buxton's "Sketching User Experiences: Getting the Design Right and the Design Right" (Morgan Kaufmann, 2007). For more information on paper prototyping techniques, see Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (Morgan Kaufmann, 2003) by Carolyn Snyder.

If the list is too long and you're not sure how to prioritize, here are some possible priorities to consider: Areas where the design violates certain established conventions. You are

You call it a "gift bag" instead of a "shopping cart"? It's probably a good idea to make sure this is clear to your users. Areas where planning decisions are politically charged. maybe you have one

You have a strong feeling that a particular design direction is the right one, but you know that there are many disagreements among stakeholders or other members of the project team. Seeing is believing. Areas where usability issues can have serious consequences, such as losses

Revenue or, in the worst case, loss of life (health applications involving drug dosing are a good example of this). You then specify what information to collect as the user attempts to complete each task. What information do you collect? We focus on qualitative usability testing, which tends to have a smaller set of metrics. In most cases, you want to understand the issues users might encounter, the varying degrees of frustration they might experience, and the severity of a given issue. For example, there may be a temporary issue (not all users experience this) that causes a published story to be irretrievably lost. This should definitely be a big issue on your report!

USABILITY TEST

231

To get an overview of the users or test runs you are testing, you should consider some key numbers as part of your testing. Again, if you're doing a qualitative test with a smaller number of users, don't overdo these numbers (calculating an average number doesn't make much sense if you're only testing five users), but the following actions can help you understand the severity of some problems faced by users. Success - The extent to which a user was able to complete a task. If you are looking up users, you can also see the "success rate" - the number of users who can successfully complete the task. Sounds simple, but that means you need to define success! For less formal tests, you can say that a task succeeds when the user reaches the final state (for example, when an editor successfully approves a story). You can track success more formally by looking at the different levels of intervention the moderator needs: Level 1 prompt: The test moderator responds to a participant's question but does not provide further details. For example, a participant asks, "I think that would be this button, should I click on it?" and the moderator responds, "Just try it." keep this in mind, as the participant is likely to feel some uncertainty at this point. (However, if this is their first job, it could also be that they don't know about usability testing.) If a user doesn't need a prompt to complete the task, or just needs one or two Level 1 prompts, they can You consider this step a success - unless you believe that the time it took the user to do so was far beyond the level of patience users are likely to have. Level 2 Prompt: The test moderator sees that a participant is having difficulty and provides a hint in response to a question. This level does not include the direct response, but the response can affect the user's actions. For example, the moderator might say, "Is there anything else on this page that you think might be relevant to this assignment?" Here you can set a limit on how many Level 2 Prompts can be provided before the task is declared not passed (for example, the second question) or marked as "passed with difficulty".

232

CHAPTER 13: TESTING THE PROJECT WITH USERS

Level 3 Prompt: Participant quit out of frustration or struggled so much that they likely would have quit if faced with the task in real life. In this case, the moderator immediately gives a response to part of the work, saying, for example: “To approve this story, click the “Submit” button. When a competitor requests a Level 3 prompt, the task is usually marked as a failure. User Satisfaction - Sure, he successfully completed the task, but how did that make him feel? It can be helpful to include some follow-up questions after each task (with the timer off) to understand how satisfied or disappointed users are later on. When you meet someone who doesn't like to talk, that can be the main window you open into that person's soul. Table 13.1 provides examples of some of the questions you might ask after the assignment. TABLE 13.1: 13.1 TABLE Users

Satisfaction issues do not agree on anything

DIFFERENT OPINIONS

I DON'T AGREE NOR DON'T AGREE

TO AGREE

I FULLY AGREE

The work took longer than I expected.

The task was easy to do

I got frustrated trying to complete this project

User satisfaction questions. User Testimonials: This is not a metric, but what users voluntarily provide is an important detail that we need to collect. Adding user input to a report is a powerful way to incorporate the human factor into the results, allowing stakeholders to not only interpret the data, but also understand the insights that lead to the insights. During testing, you can easily mark statements as questions or comments. Let's break this down into the report (see the next section, Generating Insights).

Recruitment and Distribution Now that you have your survey outline and how many respondents you need from each group, it's time to plan some tests!

USABILITY TEST

233

Creating a List When creating your survey project, you described the types of users you would like to include. You can use this outline as a starting point for creating a list of potential participants. Ideally, you're looking for names, email addresses and phone numbers. Here are some of the sources you can use to compile this list: Registered users of a related company's website. Customer contact information. Responses to survey posts submitted to related sites or groups

to your research topic. This can be broad, like Craigslist posts, or targeted, like newsgroups focused on your company's industry. E-mail acquaintances related to the test topic.

You want to ask them to forward the invite to others who might be interested, as using topics you know personally can skew the results. That kind of word of mouth is a great way to attract potential attendees. However, keep in mind that these candidates still need to be verified. (If you or others in the group know the people well, it can be tempting to let them slip away.) Suggestions take the form of short surveys that participants review, either in

Advertising space on relevant websites or on the company's website. Post or pre-screen surveys in public places whenever possible

participants meet. For sites with a strong connection to a physical location, you can do most of your testing and programming locally. Third-party recruitment companies that can also carry out your screening for you

and help with planning. This can be an expensive option, but if you are looking for a specific type of participant that is difficult to recruit or needs to recruit a lot of people, you can save a lot of time by outsourcing this part of the process. Some companies also specialize in certain areas (eg medicine) and can advise you on how to encourage a high participation rate.

234

CHAPTER 13: TESTING THE PROJECT WITH USERS

Be prepared to get creative here. Use your empathetic skills to think like your target users – where can you find them and what might motivate them to get involved? This last question leads us to the next topic. Choosing Compensation What motivates your user group members to take the survey? It may or may not be money, but attendees want something worth their time. If you work on a site for internal users, you must demonstrate this value to managers who must approve the use of company time to participate in surveys. In that case, you can focus on how a better system directly relates to benefits for your team. When working with potential external users, consider the following variables when determining compensation: How broad or specific is the audience? With a well-established e-commerce site, your audience is likely to be generic, and you can often offer a smaller percentage of commission in the form of a check or gift certificate. For an application used by lawyers, your compensation must be of great value, and it is often better to use something other than money as compensation (for example, access to a premium service). In these cases, a check can actually feel like an insult -- someone charging $250 an hour probably isn't interested in the money. If you work with large accounts, treat them like a specific target group and reward them well. How interesting should the topic be? Some participants will join because they want to see what's happening in the area you're testing. If it's an area of high interest, you may not need to pay any additional compensation - the reward is access to something that no one else can see yet. But be realistic here: you might be just as excited about the topic, but will your users be too? Will people participate primarily because they want to contribute? Some groups are motivated by altruistic motives and may be prevented from providing money to participate. If you try something that improves the community (online or offline), you might get more engagement - and happier attendees - if the experience is more about togetherness.

USABILITY TEST

235

instead of getting paid. If so, you can show your appreciation by publicly acknowledging and letting them know how much they contributed by participating once the site is complete. How uncomfortable will it be to participate? If participants have to travel to your location, you should expect higher compensation. When they participate in studies from the comfort of their home or office, less is required. Of course, time is also an issue and people expect to be paid more for 2 hours than they do for 30 minutes.

Possible Compensation Your situation varies, but here are some things you can offer: $50 for a 30-minute remote trial with a general user group $80-120 for a 1-hour in-person trial with a general user group $180-$250 for a one-hour trial with a specific user group that you determine will respond well to monetary compensation. Free service for three months, free company products (ideally ones that aren't available to everyone yet), exclusive group membership for six months, and things like that for a certain group of users who aren't likely to be impressed with a check, for example, lawyers, doctors and salespeople. Again, it helps to be creative and focus on your personas. What will motivate your user group?

Screening A screener is a type of questionnaire that you can use with potential participants before scheduling them. Ensures they match your definition of representative user. The questions are designed to ensure that the respondent is a current user of the features you are testing.

or a potential future user. Determine if it fits into one or more user groups. Help get a good match of participants in this user group

236

CHAPTER 13: TESTING THE PROJECT WITH USERS

Exclude specific respondents who may have had biased experiences

Your results Gather the key details you need to know before an attendee arrives

(optional) The tracker should include an introductory script for the recruiter to read over the phone, along with instructions on when to qualify the participant (if a match) or end the interview (if not). The end users of your screening program are the people who recruit your participants – or potential participants if you use an online screening form. Either can work, but it's usually best to compile a list of prospects via a form or email and then call them to verify them. Why; Unfortunately, it's often easier for people to misrepresent themselves on paper than to respond directly to someone, and it's not uncommon for someone to try to participate in a study even if they're not qualified to do so. Especially when it comes to compensation! Your examiner should also eliminate those that have knowledge that could affect your results. For example, a frequently asked question is whether the respondent works in market research, as they are likely to be very familiar with research in general and therefore less likely to get genuine responses. You can also check with those who work for competitors if you have concerns about sharing design information. Here are some sample questions you might see in a tracker for a business-to-business web ordering application. In this case, we are targeting a group of users who are familiar with using and shopping on the Internet and who are likely to do the same. Note that some questions are designed to include or exclude participants, while others (eg question 4) are more intended to match qualified participants with the correct user group. 1. What age group do you belong to? [mixed age 18+] a. under 18

you 18–24 cents 25–34 T. 35–44 f. 45–54 f. 55 or higher

USABILITY TEST

237

2. How often do you use the internet at home? one. Never

you Less than once a month

Yes. A few times a month d. At least once a week p. Several times a week F. Once a day or more 3. When was the last time you personally purchased a product online? one. In the previous month b. 1-3 months ago c. 3-6 months ago passed away 6-12 months ago

M. over 12 months ago

food I've never bought in person online

4. When was the last time you visited pseudocorporation.com? [Group A are infrequent users or non-users. Group B are frequent users]

238

one. never visited the site

GROUP A CONTROL

you In the last month

GROUP B CONTROL

Yes. 1-3 months ago

GROUP B CONTROL

hey 3-6 months ago

GROUP B CONTROL

M. 6-12 months ago

Check A or B

eat More than 12 months ago

GROUP A CONTROL

CHAPTER 13: TESTING THE PROJECT WITH USERS

You're fired Termination is a harsh word. This means that the interview must be closed because the respondent failed the test. You don't want the interviewer to feel bad about this, but you also don't want to waste it asking follow-up questions when you know it's inappropriate. There are many ways to deal with this. It's best to just say that the pool she qualifies for is already filled out and ask if you can contact her in the future if there's another test she's interested in.

Space and Equipment Planning At this point, you know whether you are testing remotely or in person and how much time you will need for each participant. Here are some other decisions you need to make: Where are you testing: in a rented observation room, in an on-campus meeting room, or somewhere where potential users will be? Plan a quiet spot that can comfortably seat two or three people with the computer configuration you want to test. What staff do you need besides the moderator? You can save time and increase accuracy by, for example, writing down log information during testing. Other resources include a receptionist (to greet incoming participants, distribute questionnaires while people wait, and escort participants in and out of the test room) and someone to provide IT support if something happens during the test. To record the test: You can use several methods, but software like TechSmith's Morae and Camtasia Studio make screen recording easy, and Morae has additional features for embedding video and audio from a webcam.

Writing Discussion Guides Finally, you need to gather the materials needed for the test itself. Your general tasks are listed in the research plan. Now you need to complete the actual text and instructions for the task. You will receive at least two packages here - one for the test moderator and one for the participant (with enough copies for each test to include one of each).

USABILITY TEST

239

Start with an introductory script that the moderator can read to the participant. You can find many good examples at http://usability.gov/templates.

Surfing Usability.gov is a website developed by the US Department of Health and Human Services as part of an initiative to encourage the development of websites accessible to a wide audience. It has several excellent reference materials to help with user-centered design, including a sample video consent form (in Microsoft Word format) that participants must sign before recording: http://www.usability. gov/templates/docs/release.doc

Your instructions should include any specific information the participant needs to successfully complete the task(s) you are testing. If your assignments require a lot of data entry and customization, define some information in advance and give participants predefined data to use. For example, if it's a login, chances are all participants will use the same credentials. Make sure the work instructions include all of this information clearly and concisely to facilitate completion. Here's an example of how a task for a content editor is made more specific in the discussion guide. The first task in the plan is "Find an item ready to edit". The discussion guide is as follows: INTRODUCTION Your manager has asked you to take on a new role: editing and approving articles posted by contributing authors on the company website. Once an article is approved, it will be published on the website in the news section. She and three other editors will approve elements to ensure they align with the company's message. You have received the following editor credentials: Username: grobertson Password: come2gether

240

CHAPTER 13: TESTING THE PROJECT WITH USERS

Read each task aloud and complete it with Notepad. Task 1 Log in to the tool and open an article ready for editing.

As you can see above, we modified the task a bit to end up with a clear end state - an open article. This type of optimization will be common once you get down to this level of detail and start thinking about how you will measure success. You can also follow up each task with the user satisfaction questions discussed in the design section. In general, it's best to give each task its own page so the user isn't tempted to look ahead. In summary, your test materials should include: Video Recording Consent Form (see navigation sidebar above).

Page for more information) Moderator Discussion Guide with Introductory Script Participant Discussion Guide with Detailed Tasks and User Satisfaction

Questions A format to watch if you have someone investigating this. That can

These range from a logging tool built into the testing software to a spreadsheet for entering responses into a printed template to verify important information (such as the types of messages required). Taking a little more time to set this up before testing will ensure you get consistent results and save a lot of time reviewing logs. Optional quiz. Sometimes participants arrive early and have

a little wait - this is a great opportunity to gather additional information. If you've already created a survey, why not reuse it here? The type of compensation that will be communicated to the participant at the end

the test (cash in an envelope, a commonly accepted gift card such as a Visa gift card, etc.); If you opted for offsets, such as free services where nothing is passed on after the race, ensure the participant will receive a late registration by the following day. If you use paper prototypes during testing, you will also have those materials to work with. Be sure to prepare the kits for easy handling before starting the first test.

USABILITY TEST

241

Facilitator The facilitator's role is to involve the participant in the process, answer their initial questions, and then gather as much insight as possible while trying to allow the participant to behave as naturally as possible. Be sure to ask users to think aloud during the test, as if they were talking to themselves (and gently remind them to do this when they start working silently). The “think aloud” technique provides the best insight into user behavior. You will learn a lot about your problem-solving and thinking processes by learning about them yourself during the task, rather than asking participants to re-enact them later when their memory may not be as accurate. Also, be careful not to give the participant the “right” answer too quickly! One of the hardest parts of running a usability test is watching the carefully selected participant struggle with a task and just letting them struggle. After all, you're probably in this space because you're an empath. you want to help people So it might seem a little sadistic to watch someone get frustrated, ask you for help, and then say, "What would you do if you tried it yourself?" asks a question, pause before answering. Candidates are very likely to ask questions early on in the test, especially if they are uncomfortable with you sitting next to them. When they sense that you're there to observe rather than talk, they're often more focused on their work than your presence. Here are some sample questions and answers suggested by participants: Participant: “It looks like this tab. Shall I go here?” Intermediary:

"Go ahead, try it."

Participant: "Should I go here?" Facilitator:

"Do you think you would do that at this point?"

Participant: "Is this the opportunity to provide feedback?" Facilitator:

Stay quiet. She has a friendly, relaxed expression on her face as she smiles at the participant and then looks expectantly at the screen.

So when do you intervene?

242

CHAPTER 13: TESTING THE PROJECT WITH USERS

If the user has already put in more effort than you think they would on their own and you think you've figured out why they went down the wrong path, it's time to move on, especially if you still have more work to do. frustration for the rest of the test. In Chapter 6, we mentioned the importance of avoiding leading questions in user interviews. The same applies here. If you feel like you're too close to the plan and criticism might make you defensive, consider having someone guide you with notes.

Analyzing and presenting results You've completed all the tests and now you need to analyze a mountain of data. But there are some key takeaways that you already think are relevant and your project team is dying to know how it went. You can schedule an occasional oral review of your food excellence for the group. It can help you put some of the trends you've observed into words and set the foundation for your future reference. Make sure they know that these are first impressions and that you need time to analyze your data in more detail. Don't necessarily jump to the recommendations here until you have a complete picture of where the problems might lie. When you have time to deal with the data, review it, considering a few things: The time you have for analysis. It's easy to get lost in the details and try to include everything. As always, keep the test and your goals in mind as you discover key takeaways. If you have ten hours of test recording and five days to write the full report, you probably don't want to waste time watching video of each test. Count on the note taker and, above all, the videos to ensure that the most important passages you remember are captured correctly. How your results are used. This is an important detail that is often overlooked. You can create a good 20-page report, but only one of those pages is likely to get a lot of attention: the executive summary.

USABILITY TEST

243

If your prospects want to see the details, the report itself can be the main way to communicate the results. If you find that you need two levels of detail – one for stakeholders and one for the project team – consider also creating a presentation version of the report that impacts key deliverables in a more visible, understandable and prioritized way. Those interested in more detail can view the full report. Prioritize Issues By the end of testing, you may have a long list of usability issues that you need to understand and prioritize. Here are some characteristics that can help you determine the severity of an error: Consequences. The negative impact of problem resolution. For example, if a participant loses data due to a usability issue, this guarantees a high score. Let's say she spends ten minutes filling out a complicated form and accidentally clicks on a link that takes her to another page. If she clicks the browser's back button, will her data be lost? recoverability. To what extent can the attendee recover after the problem occurs - for example, is he able to easily return via an alternate route? frequency of occurrence. Since you are not working with large numbers of people, this in itself is not a sign of seriousness. But when five people make the same mistake and it sends them down a less-than-optimal path, that's a good sign that you should consider giving it a higher priority. reasonable reason. If the problem doesn't occur often, but it was caused by someone who falls into your user group, it was done for a reasonable reason, and there was a clear cause of the error, then you should factor that issue into your recommendations. Generate Insights In addition to the issues you collect, you have a wealth of user information that can provide valuable insights to the project team. As described in Chapter 6, an affinity diagram exercise is a great way to bring these statements together and identify common patterns.

244

CHAPTER 13: TESTING THE PROJECT WITH USERS

Here are some ways to categorize user statements (see the "Contextual Examination" section in Chapter 6 for more details): Goals Mental Models Functional Ideas and Desires Frustrations Solutions Value Statements Pleasure (don't leave this out - you don't have to ) t “You don't want to miss out on the good stuff!) Expectations (especially when they're not met)

Be sure to include positive insights in both insights and recommendations. Usability test reports are often seen as very negative, mainly because the researcher prioritizes discussing things that need to be fixed over discussing what is going well. Taking the time to discuss the good stuff makes the overall reporting experience better for everyone. It also helps the design team engage with the results and get excited about making the design even better.

Generate Suggestions Before starting your analysis, you probably already have some good ideas in mind about how to fix the problems you found in the test. Sketch them along the way as you identify problems and ideas so you don't lose them. Just be careful that one idea doesn't catch on too quickly and sway your view of other possible approaches that could solve more problems. A good recommendation should address more than one issue whenever possible. You might want to group problems

under a higher recommendation depending on how detailed and specific you get with your problem descriptions. Be practical and simple - avoid hasty detailed plans.

USABILITY TEST

245

Use clear but non-condescending words. receipt

Criticism is a difficult thing, especially for those directly involved in the proven project. Don't underestimate problems, but remember that your words should be interpreted constructively and respectfully. Remember that the recommendations, like the system, should target your end users. When you've finished your report, go back and ask yourself if the original goals were achieved and how best to communicate your findings to the many people who will use them: stakeholders, designers, and developers. Speaking of developers, it's time to put them back in the spotlight. In the next chapter, we'll cover things to consider during the transition from design to development and beyond.

246

CHAPTER 13: TESTING THE PROJECT WITH USERS

Transition: From Design to Development and Beyond Where do we go from here? The definition and design phase of your project is complete. And now? A good user experience design process never ends. After defining and designing so much, how do you ensure the end result is the user experience you've designed - and what's next? Russ Unger

247

This is the end... ...of the book. This is the last chapter. However, it is not the end of the user experience design process, even if it seems superficially. After going through all the previous phases of a project, you might feel like your job is done and you have nothing left to contribute. In many cases, UX design efforts end up as tasks somewhere in someone else's project plan, and once your work product is delivered to the rest of the team, you always move on to another project. Time to close the door and start something new, right? Very wrong! There's still a lot you can do to ensure the best possible user experience design is created.

Visual Design, Development, and Quality Assurance In some cases, collaborating with a design or development team that gets your project-based work product goes smoothly. Future co-workers sometimes rely on you to answer questions, provide input, and help them with some design ideas they're working on. (This might even seem too prototypical to you!) In these environments, user experience design has already been adopted, and the team probably had the foresight to give you time to do these consulting tasks. However, in many organizations, the roles of user experience designers, information architects, interaction designers, etc. they are still very young. It may not be clear how these roles are managed and the decision of how much you should commit to someone who is not fully versed in UX design. It might be up to you to find ways to stay engaged.

248

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Here are some suggestions: 1. Buy them a copy of this book. 2. Don't be shy. 3. Read the remainder of this chapter looking for ways to get involved and be helpful. 4. Ask for a commitment and be ready to plead your case. There are other instances where you may find that the visual design or development team is king of the company and its projects and you may find it difficult to stay engaged. You might be trying to tear down walls just to check work and ensure compliance. This doesn't always happen, but it does. Christopher Fahey, founding partner of Behavior (www.behaviordesign.com), is familiar with this challenge. He advises: Some organizations are strictly segregated. To stay involved in project development after the initial design stages are complete, you must be proactive and ask for opportunities to provide feedback and corrections to the visual design and development teams. Often they don't even think to ask you to be there. Ideally, you'll do this during the planning and budgeting phase of the project. Otherwise, you might literally have to offer your services to ensure the design isn't compromised during the next development. One trick is to simply ask to join the QA team (assuming you have one - if you don't, ask the visual designers and developers about it!) - even informally - and log in and get passwords to all the development pages and websites Bug tracking tools; You can add your revisions and deviations to the same queue of bug fixes that developers review daily.

Of course, many projects don't have the luxury of a quality assurance team. In a perfect world, every project would have such a team. In reality, however, quality assurance is not always available. Sometimes developers themselves do quality assurance during development. In addition to making you cringe, the knowledge will make you work even harder to work with developers.

VISUAL DESIGN, DEVELOPMENT AND QUALITY ASSURANCE

249

The Art of the Deal The art of the deal can become a crucial aspect of your role as a user experience designer. Downstream contributors such as visual designers and developers can adopt your changes into their work without realizing how they affect important parts of the user experience. In case someone tells you that something is "not feasible", 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 the research you've done). ) and convince others that the user experience is viable. Alternatively, these skills will help you work with your partners to develop a satisfying Plan B approach that meets as many of everyone's needs as possible. For more information on negotiation, see "Getting to Yes: Negotiating Agreement Without Ceving 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 for many small businesses: quality assurance is a luxury. Quality assurance "is done by everyone, but primarily by the developer," says Troy Lucht, principal and director of development at Ascend Realty Solutions (www.ascendrealtysolutions.com). Everyone tries and wants to, but without resources dedicated to writing test scripts, it can be impossible to tell people what to test when development often runs until the last possible moment. In many cases, our in-house designer is the person who knows the app as well as I do, so they can provide the most informed feedback. Adding a UX Designer would really make things better for our small team.

While your UX design work product may not involve creating test scripts, in some cases you can test the wireframes and annotations you create to ensure that all elements are considered and that all call-to-actions you define work. correctly. This situation is not perfect, but it is an approach that can be useful when there is no quality assurance. The key takeaway here is that user experience design doesn't end just because you've delivered your work product and accomplished a knowledge transfer. Your role may be of a more advisory nature temporarily, but you're not done yet.

250

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

User test design (again) Haven't we already done user testing? I hope you can answer yes to this question, but this is not always the case. Unfortunately, the same does not apply to this particular test step, which aims to test the final, designed and developed website with real users before launching it. This allows you to take one last look at the site and find any final bugs and errors you may have missed during QA testing. Once you've identified your target audience, you can test the site against any scenario that poses a high risk or that may have had issues in previous iterations of the site. This round of testing can provide the information you need to determine if your site is working or not. If significant issues are discovered during this round of testing, an update and retest may be required.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1... Start! “If you build it, they will come. …” This theory is mentioned often – and almost as often disproved. You can create the most beautiful, satisfying and user-friendly app, present it to the world, and find out two months later that almost nobody adopts it. What gives? User adoption is the extent to which your target user base uses the site or application. Some opt-in issues can be avoided if you follow search engine optimization best practices ( Chapter 8) to ensure your users find the new site. User adoption also means that good user experience design doesn't stop at the end of the project or be limited to the project you're working on. You can help your development teams marketing, customer support, public relations and education ensure smooth growth and a user base that is enthusiastic about the site or project by helping them with three factors that often influence user adoption: Personal benefit

10, 9, 8, 7, 6, 5, 4, 3, 2, 1… LOS!

251

Support network opinion

Let's take a look at each of them in turn.

Personal Benefit One of the most important questions users need to answer is, "What do I like?" It doesn't matter how good your site is if you understand the unique value it brings to a specific type of user (or one of the personas you've identified). , can not quickly explain, you may have trouble attracting users. Some benefits are immediate: “This camera feature allows you to post photos to your online account with the click of a button.” Some are indirect: “This timesheet tool makes it easy for the company to track the time you spend on each project.” You've spent valuable time gaining insight into your users. Now use that knowledge to help your marketing department adapt its messaging.

Support If your users need help with the site, how do they get it? Answering that question involves training and customer support, in addition to the contextual support that great user experience designs try to provide. Do you think your users might respond better to classroom training than online training? Will some of your users skip training and expect everything they need to be available on the site itself? Is live chat an important customer support option for your users or will they be happy with phone and email support? Support efforts are tough, and understanding your users can help your customer support and education departments effectively.

252

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Opinion Network Word of mouth is the most important influencing factor. What is the reputation of your client's company and current website among the target audience? While the answer here is yes, that doesn't mean it's effortless — maintenance is always important when it comes to reputation. Don't use a positive response as an excuse to move on to the next section: the effort required to maintain doesn't have to be significant, but the effort required to recover from a reputation disaster can be impressive. A little loving care can go a long way, so read on. If the answer is no, serious effort must be made to improve awareness. It may be necessary to reach out to the user community and find out who the influencers are, how they prefer to communicate and how they influence their audience, and then engage them. There are many ways to engage your users through social media and influence their opinion of your customer, your business and your website. Help your client identify opportunities to engage with these communities and try to steer them in a positive direction. If all three of these factors hold true and you're still seeing low usage, consider how and what your competitors are doing to meet user needs. How can you differentiate the product or website?

Post-launch activity These are interesting times: many companies are launching – or releasing their products – in “beta” mode. A beta release usually means that real, unfiltered users are the target audience for live testing of the site to identify errors, bugs or other issues. Previously, betas were typically only offered to developers, but it is now common practice to make betas available to the entire user community. During a beta phase, it is imperative that communication methods are implemented to catch and report any user issues. Any system failures that occur should be recorded and made available to the project

ACTIVITIES AFTER START

253

Association. There should also be a mechanism to allow users to report issues that arise to the appropriate members of the project team. If that kind of communication doesn't happen - if the UX designers, visual designers and developers don't know what's going on during the often tight and fast beta phase - the site can be updated and pushed out to users without much strategy in place.

Post-Launch Analysis Once you've launched your site, the first thing you should do is start collecting data about site usage. The best source for this is your site's log file. Unfortunately, UX designers are probably not at the top of the list when it comes to getting or verifying this information. So look for the website host and use your negotiation skills. Website analytics may provide information about website visitors. Among other things, you can understand who your new site visitors are, who is returning to your site, number of page views, page view duration, page depth, where visitors leave your site (which pages), duration of session, ad impressions, search terms used, results, etc. again - search

This information can help you better understand where users are having problems by pointing out pain points on the site. While the analysis may seem dry and the numbers bulky, the data and insights will help you ask the right questions as you conduct your post-launch testing. Note For more information on website analytics, Web Analytics: An Hour a Day (Sybex, 2007) by Avinash Kaushik is a good starting point.

254

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Post-launch design testing with users (again) Once you've gathered data from your site analytics and gathered input from customer support or other departments that interact with users, you can start compiling a list of questions to ask yourself if want to use another round of design testing with users. In other words, use the data you've collected to create a new set of questions to ask your site's users, using the skills you learned in Chapter 13. One of the benefits of this round of testing is that it gives you the opportunity to test the same group of users you worked with previously to see if their opinions have changed since launching and using the site more often. This can be very useful: if you test the same group of users (or part of them) again, you can re-ask some of the original questions (opinions on functionality, ability to perform certain tasks, etc.) the answers over time. This attrition feature can help you discover new opportunities for improvement on the site and gain insight into users' learning curve based on previous rounds. As an added bonus, response difference analysis can also help you identify new questions that were not previously considered.

It's all done, isn't it? NO.

It's like starting from scratch... By piecing together analysis and test designs with research data, you can begin to compile a list of improvements and enhancements that would benefit your site. Once you've put them together, you can draft a new proposal based on your recommendations (Chapter 3). That suggestion might lead you to a new project, which might lead you to define new project objectives (Chapter 4) and business requirements (Chapter 5). You can

How to start from scratch...

255

Then move on to further research (Chapter 6), creating personas (Chapter 7) for new audiences, improving your SEO (Chapter 8), updating or creating new sitemaps and workflows (Chapter 10), updating or creating new leads, and notes (Chapter 11), starting more rounds of prototyping (Chapter 12), and more design testing with users (Chapter 13)... You get the hang of it. Projects must not die. They are intended to be the springboard for new projects that aim to continually improve user experience design.

256

CHAPTER 14: TRANSITION: FROM DESIGN TO DEVELOPMENT AND BEYOND

Table of Contents An absolute path, used in identifying and deleting the original HTML 213, including suggestions 53-54 American Customer Satisfaction Index (ACSI) 103 activities, planning 162-164 pencil-and-paper adaptive path on site 189-198 16 additional costs and fees , including suggestions 50 Adobe Acrobat PDF prototyping tool, resources 214–215 Adobe Illustrator website 167 Adobe InDesign website 167 proponents, 150–151 prioritization, 154 applied affinity diagrams for 61 steps 99–100 use in usability testing 244 agile approaches vision feature overall 63 –64 to 65 AIGA site 51 Ajax, issues with 132 Align Interactive site 217 alternate attributes, usage 139 American Customer Satisfaction Index (ACSI) 103 tools availability overview 254 general notes 187 tools for 189-190 and wireframes 186-187, 193-194, 201 Aquent Talent Website Service 51 Arrows and Links, .com, searches were conducted on 128 cases, including sentences 47-48

Attributes prioritizing and defining 90 attributes benchmarking from 215 sites 167 Axure RP prototyping tool

89–91

B Babyhold website 118 BabyNames website 118 balance, achieving UX design 6-7 Balsamiq mockups prototyping tool, features by 216 Baty, Steve 12, 95 behavior website 249 beta release, set skew rate of 253-254 black rate, 253- 254 sets 130 -131 vs. white hat 141-142 blog functionality, site map for 166, 191 blue flavor site 167 site plan CSS 167 body language, interpretation in focus groups 106 bots, explains 129 brand presence sites described 11 examples 13 features of 12 -13 targets for 13-14 brand strategist/companion role 26-27 Brooks, Mark 200-201 construction property, system for 183 Buley, Leah 189-190, 201 business proponent 154 vs. development proponent and users 155 Usage business analysis paper 27-28 wireframes on 188 business requirements 73 See also requirements capture, clarification 68-69, merging 82-84, performing heuristic analysis for 70-73, creating development plans meeting 78-79

INDEX

257

Business needs (continued) Creating worksheets for 153 defined 68 example 83 gathering responsibilities for 75–76 gathering stakeholders for 76–77 for the Global Cruises home page 195–196 adoption by development supporters 157 listening to ideas between 48–81 prioritizing 151–152 real meetings 80–81 wireframes 189 defined business perspectives 75 Buxton, Bill 231

C calendar tool, 217 functional prototype, 219 campaigns. View marketing campaign sites, card sorting, closed categories 110, explanation 93 group ratings 110, overview 107-108, running a test 109, process 108-110, providing instructions for 109 categories removed, 110 customers, usage of wireframes by 188 camouflage , explanation 1–11321, overview 142 prevention 138 unintentional 133 collage, used in microfinance example 223–224 communication, importance for prioritization 160 companies using SWOT analysis to compare 61–62 competitors 61 corporate culture hierarchy 36–37 history 34–3 34- 3

258

INDEX

Compensation, identification for user groups 235, 241 competitors, comparison 61 concept exploration. See also visual design examples 222-224 potential pitfalls 222 purpose 221 conditions, defined conflicts 170, management in prioritization 158-162 sloppy links, links and arrows 171, defined conflicts 170 in 170 consumer priorities, completion of 5 content best practices for 138– 139 importance of 135–136 staying current 138 content creators, cable usage of 188 content management systems, content matrix overview 133–134, numbering system applied to 173 content source pages, described 11 Characteristics of 16-17 objectives for 17 tasks related to 17 with the use of business analysts for 28 with card classification in 108 content strategist, function of 28-29 contextual planning, resource for 101 contextual research explains 92 information of 98 98-99 process using relevance charts in 99-101 Writer role 29 -30 Coroot website 51 (Additional) costs and fees included in suggestions 50 Tracking features 131 Hide detection Hide 132 Explanations 129 Creative Commons website 50

Dashed line D representing conditions with 170 decision points, 169 specified define and planning phases, overlapping between 145 outcomes, including proposals 48-49. See also product design goals for branded websites 13 for content source websites 17 for e-commerce websites 19 for e-learning apps 20 for marketing campaign websites 15-16 setup 10 for social networking apps 21 for task-based applications 18-19 design flaws missing pagination 173–174 misaligned objects 172 misplaced text 172–173 sloppy links 171 unevenly spaced objects 172 designs, improvement 227 developers prototyping 217 using wireframes 188 advocates and 188 tracking and development business5 to 158 concerns 154 goals and responsibilities 157 Inheritance requirements 157-158 Participation 158 Properties 156 Development team providing feedback on 249 digital assets Optimizing for 138 digital experiences Designing 5-6 digital prototypes. See also Audience prototype for 208 HTML editors vs. WYSIWYG 209-214 Resources Required for 209 Timeline for 208 Wireframes vs. realistic prototypes 207-209 Digital Web Magazine 167 website

Directory Structure Importance of 134 Discussion Guides for Writing Usability Tests 239–241 Documentation Design 162–164 Domains Including Keywords in 134 Port Page Overview 142 Bullet Points Usage in Relevancy Charts 161 Live View Feature of Dreamweaver CS4 in 209 210 Preventing Duplicate Content 138 Preventing Dynamic URL in Content Management Systems 133

E-commerce sites, design goals for 19 education-focused microsites, sample 15 e-learning applications, design goals for 20 emotion versus logic 7 PURITE Process device module activation 46, design for usability testing 239 Evans, Will 122, 123 , 181 , 197–201 Experience, tangible vs. digital 4–5

F Fahey, Christopher 249 Favreau, Jean Marc 40 Traits of Idealism and Visualization 146–147 Managing Conflict Related to the Feedback Mechanism 160–162 Prototyping 219 Fees and (extra) Costs Included in Proposals 50 Finck, Nick 167 Prototyping Tools CS4 Resources of Flash 215 –216 Flash Prototyping and Flash Catalyst Resources 130–132 Flash Content Resources 216 Embedding in Static Layers 131 Focus Group Discussion Format for 105–106 Explained 93 Interpreting Body Language in Monitoring 106 107 Process of 105 – 107 use in microfinance Example 223 Footer use 104–105 Draft 196

INDEX

259

Footer links, link popularity 140, front-end developer, role 31, funding model, microcredit application 222

G Garrett, Jesse James 168 Global Cruises, Home Page Design for 195-201 Google Analytics Tools 24 PageRank System 139 Quality Guidelines for Webmasters 142 Surveys Conducted in Grid 128 Use in Apps 172 Group Discussion Format for 105- 106 Explained body language 93 in 106 Damage control 107 Process 105-107 Use in microfinance example 223 Use 104-105

H Hadden, Jon 217–219 header/nav, 195 header meta tag design, enabling 137 heuristics to leverage requirements collecting 73 overviews from logic 70–71 to 71 steps in hierarchy 72–73, impact on business designs 36– 37 Hinton , Andrew 177 Hofstede, Geert 36 Home Page Design 192 Design for Global Cruises 195–201 Wireframe Design for 197–200 Example 194 HTML Prototypes 212 Link Popularity 140 HTML Prototypes Code Analysis for 21413 – HTML Revision21413 – Creation of 210-212

260

INDEX

I ideas, 82-84 idea combination and preview functions 145-147 Illustrator website 167 image cards, use in HTML prototype 213 image tags, use in HTML prototype 213 InDesign website 167 indexed pages, 137-138 separation lofisni sites13, avoidance in management systems Content 133–134 information, research 17 information architects, comparison with other roles 248–249 role of 22–23, 25 Information Architecture Institute site 51, 167 guidelines, finalization for usability testing 239 –241 balancing design with other Rolls 248– 249 Roll 23, 25 interviews. View User Interviews Website iStockphoto 117 Iterative part of the PURITE process 46 iterations, wireframing as an iterative design exercise 201, resource for 231 iterative tests, use of prototypes for 217

J JavaScript, Problema com jQuery 214 Website

132–133

The K Keynote prototyping tool provides 214 keywords including in sitemaps, 175 keyword research tools, 135 keyword search availability, 135 keyword behavior including in domains, 134 keyword conventions naming for 136, usage in URL structures 134–135, Knemeyer, Dirk 12

Launched sites, 254 post-launch analysis, left navigation links, prototype for 217-218 legends, including 175 sitemaps

Licensed Work Defined 49-50 Link Anchor Text Meta Tag Explained 137 Link Popularity Distribution 139-140 Explained 139 Footer Links 140 Link In Content 141 Manipulation 143 Link Spam 143 Contributing User List, Authoring 35 Live 23, Usage in Dreamweaver CS4 209 Logic versus emotion 7 logistics, effects on company projects 37 logistical step of usability testing 233–239 Lucht, Troy 250

M Marketing Campaign Sites Described 11 Examples 14 Resources 14 Purchasing Goals 15-16 Year Olds Building Relationships Melzer Age 26-27 James 182 Messaging Personas Case Study 115 Website 219 Meta Tag Description Explained 137 Words -meta keys explained 111376 Spam with 142 meta tags 136- 137 methodology availability meaning of 62 microfinance defined 222 microsites defined 15 Microsoft PowerPoint site 167 Microsoft Visio site 167 missing pagination errors 173-27 incorrect objects 173 sloppy links 171 objects unequally distributed 172 changed approaches, after 64–65 moves, display of 170 MSNs, performed searches of 128

N-names, providing persona negotiation 118, type 250 network views, user adoption impact 253 Nicolle persona described 115–116 Nielsen, Jakob 71 nofollow link attribute, noindex meta tag usage 140, explanation 137

The objectives using SWOT analysis in 61-62 vague vs. concrete meaning 58-60 of 57-58 UX designers input on 60-62 measurement 58, 60 connect objects correctly 171 measurement grid between 172 misalignment 172 unequal observations, 17 unequal spacing for heuristic analysis 72-73 Prototyping tool features OmniGraffle of 215 site 167 Site OpenOffice Draw 167 Site Map OptimalSort 109, including in Suggestions 44-45 ownership and rights, including Suggestions 49-50

P pagination, missing page title meta tag 173–174, 136 PageRank system explained, page 139–140 explained. See also 142–143

INDEX

261

Paper prototype 206-207 Example 217-218 HTML as 209 for navigation concepts 218 Passive observation, 99 defining routes, identifying in workflows 180 Payment plan, including suggestions 52-53 Pencil and paper, uses for 8-29101, age of people 118 Biography 119 Case study 115 Defined 113 Level of education 120 access points or activation for clients 120 find information about 114 information contained in 116 location to 119 maximize use of 125 mobile comfort level, 121 motivation to use clients or projects 121 name 118 profession 119 offline activities 120 online activities 120 overview sheet for 122 personal offer 120 photos 117-118 justification for 113-114 salary or salary range 120 social comfort level for 121 individuals target group common to 124 individual target group 124 technical comfort level 121 types 113 users goals 121 photo sources, face detection 117 sticky notes, use in affinity diagrams 161 post-launch design tests 255. See also testing. Usability test steps power distance defines 36 powerpoint prototyping tool features of 214;

262

INDEX

Website PowerPoint 167 PR (PageRank) explained 139-140 Pricing Section Preparation 45 PURITE Process, Framework for Projects 51-52 Usability Testing Prioritization Process 244-245 Balancing Roles 154 Facilitating the Importance of Communication 150-15 Conflict During the process flow 158 – 162 successful example of 181–182 products 5. See also outcomes, flexible design approaches 63–64 meaning of 66 including changed in proposals 45–47 64–65 steps to 62–63 project direction 63 lack of alignment in project management 160 use of wireframes in 188 project objectives, application of SWOT analysis in 61-62, vague meaning vs. fixed, 58-60 of 57-58, input from UX designers in 60-62, measurement 58, 60 project overview, including in proposals, 44 – 45 project pricing, including proposals 51–52 project requirements, milestones involved 69 project sponsors, 75 project teams defined, 75 project terms defined, 80 project blueprint best practices for 191 impact of company story on process flow 34–35 181 –182 confirmation of proposal elements and signature 53 –54 Additional costs and fees 50 Acceptances 47-48 Benefits 48-49 Entitlement and rights 49-50 Payment schedule 52-53

Project Approach 45–47 Project Overview 44–45 Project Pricing 51–52 Revision History 44 Scope of Work 47 Job Descriptions 54–55 Title Page 42–43 Suggestions Meaning 40–41 Accessibility of Prototypes 219 Applications 219 tools 217 calendaring, 219 changing wireframes for 210 finalizing 219 creating with WYSIWYG editors 209–214 examples 217–219 as a feedback mechanism 219 219 goals for iterative testing 217 developer download 217 wireframes 207– realistic9 prototyping. See also recommended digital prototyping practices for 205-206 Overview of 205 paper prototyping tools 206-207 Adobe Acrobat PDF 214-215 Axure RP 215 Balsamiq 216 Fireworks 215 215 216 21 Purite Key216 and Catalyst 214 214 Visio 215 215 2116 Purite 216 Purite Key216 and Catalyst 214 214 VISIO 215 215 2116 Purite 216 Purite Key216 and Catalyst 214 214 215 215 216 216 Purite Key4 46

Q qualitative research, application to usability testing 227–229, qualitative usability testing, information retrieval for 231–232 quality assurance documents, application of numbering system to 174 quality assurance teams instead of 250 participants out of 249

Quality assurance, use of frameworks for quantitative research 188, usability testing 227–229 questionnaires, including 241 questions in discussion guides. See Also Highlights for Activity Planning 162-164 for User Group Compensation 235-236 for Documentation Planning 162-164 for Focus Groups 105 for Stories 148 for Surveys 102 for Usability Testing 242 for User Interviews 97 for User Satisfaction 233

Random Name Generator Site R 118 recommendations, building for usability testing 245-246 usability test ingest step 233-239 redirects, setting 135 relative path, use in HTML prototype 213 PURITE Process Performance Module 46 requirements, defining 6 requirements 6, gathering requirements 6, linking 74 See also business requirements research planning for usability testing 229–233 research techniques card sorting 93, 107–110 contextual research 92, 98–101 focus groups 93, 104–107 personas 121 Research 92, 104 Usability Testing 93, 110–111 User Interviews 92, 95-97 Resources. See Also Site Feature Relevance Charts 161 Flexible Approaches 65 Analytics 254 Body Language 106 Contextual Design 101 Google 128 Hypertext Markup Language (HTML) 214

INDEX

263

Features (continued) Iterative Design 231 Negotiation 250 Prototyping Approaches 217 Social Media Applications 20 Tools 167 Usability Testing 231 Responsibilities, Presentation 75-76 History of Revisions, Including in Proposals 44 Roles in the Prioritization Process 154 Changes Among Employees 154

Sample size S, defined workload of 227, including suggestions from 47 reviewers using 236-239 in usability tests. See Also Scripted Navigation Questions, Search Behavior Issues 132-133, Understanding 135 Search Engines, 129 Search Results Development, Impact on 142 Searches Per Month, Statistics on 128 Section Titles, Activation 137 Josh Seiden, 113 SEO (search engine optimization) defined 127 UX impact on 134 importance of 127–128 features for 129 SEO methods, white hat vs. black hat 141–142 SEO experts, using 188 signature wireframes and detection, including suggestions 53–54 website analysis, tools for 24 sitemaps, advanced examples 175-176 for blog functionality 166, 191 specific model 177 166

264

INDEX

Omitting numbering structure from 173, simple example 174 vs workflow 166, using 138, using card sorting to 108, using workflows with location type 178 specifying 11 locations. See Also Indexed Pages 131 Text Written in 29-30 Six-Up Templates Using 190 Slingthought Sites 217 Social Networking Applications Described 20 Design Objectives for 21 Popular Social Security Administration Baby Names 118 Software Usability Measurement Inventory ( SUMI) 103 SOW (Government Work), Page Content 54–55, Design for Usability Testing 239 Keyword Meta Spam 142 Spencer, Donna 17, 109 Spider, Explains 129 Spool, Jared 125 SRA International Inc. website 182 stakeholders defined 76-7 listening7 81 static layers, embedding Flash content in 131 markers, use in affinity diagrams 161 storyboard Stock.XCHNG 117 website, process 147-150 strengths and weaknesses, understanding 61 SUMI (Network Measurement of software usability) 103 support 33. See also explanation of UX design functions - Surveys 92, overview 101, process 102-104 versus user interviews 102

SWFobject, using 131 Swimlane, sample SWOT analysis 182-184, applicable to project objectives 61-62

T tags. See meta tags segmenting users and describing 113. See also user workflows applying the numbering system to 173 to create 178 examples 178–180 overview 166 process flow 181–182 vs. sitemaps 166 swimming 182-18 182-18 the application developers of the sites described 11 features and goals for 18–19 , business analyst use for 28 Tatum, Keith 217–218 Taylor, Dave 214, technical framework, 31 creators of templates, use with wireframes 190, intensity, balance between defenders 154–162, use of termination, usability testing 239, test materials, writing for usability -Tests 241 PURITE Process Test Test Section 46, Usability vs. User Acceptance 226. See also post-launch design testing. Steps for testing usability Finalizing text for usability testing 239–241 Bad positioning 172–173 Writing on websites 29–30 Title page including title tag in sentences 42–43 Using tools in HTML prototype 213 Availability 167–168

U UAT (User Acceptance Testing) Purpose 226 PURITE Process Module 45 Understand

URL paths, prevention in content management systems 133 Prevention of URL structures in content management systems 134 Use of keywords in usability testing 134–135 Choosing an approach to 227–228 explained 93 steps overview usability test 110 -111 236-239. Also check out the post-launch design test. Testing, analysis, and presentation of results 243-245 Approach selection 227-228 Proposal creation 245-246 Evaluation 250 Facilitation 242-243 Research design 229-233 Recruitment and logistics 233-239 Writing discussion guides 239-242 Views on 253 Influences on 251 –252 personal benefit of 252 providing support for 252 user advocacy having a role for 150–151 network building 32–33 versus advocacy and business development 155 on 154 user characteristics compared 90–90–99 prioritization and 8, drawing Context to 227 User Experience (UX). See User Groups Defining UX (User Experience) 87 Site Listing Features 87-89 User Interface Engineering 125 User Interviews Explained 92 Interview Tips 97 Process of 95-96 x Surveys 102

INDEX

265

user models, planning 91 user research activities 93–94 completion 111 planning 94 steps to implementation 86 techniques 92 user research design, development 229–233 user researcher, role 23–25 determining user satisfaction 233 tools for measurement 103 categorization of user statements in US tests 245 evaluation of success 233 user identification 232–233 users . See also target users selecting number for usability testing 229 types of identification 88-89 using wireframes 188 digital aspects of UX (user experience) 6 impact on SEO 134 UX design, 3 defined UX design roles. See Also Support Network Strategist/Brand Assistant 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 Researcher users 23-24 30-31 UX - Designers balance other roles 248-249 empathy 156 inputs to design goals 60-62 organizations for 7-8 role in prioritization 151 characteristics of 6-7

V-Validation, early search for value proposition 191, presentation 15

266

INDEX

The Visio Prototyping Tool has 215 visual design teams from the Visio 167 site providing feedback to 249 visual designers involved in building 203 wires function 30-31 using frames of 188 visual designs. Also see Exploring Concepts, Applying a Numbering System to 174 Mockups, 224 Wireframes, 200–201 Visual Vocabulary Definitions, Conditions, 170 Connections and Arrows, 170 Decision Points, 169 Pages, 168–169 Page Stacks, 169 Visualizations business and ideas requirements, 5–1 ideas, 074-81

WAMMI (Website Analytics and Metrics Inventory) 103 Warfel, Todd Zaki 115, 124, 217, 219 Waterfall Approach Modified 65 Stages by 63 Webmasters, Quality Guidelines for 142 Webmasters/Site Owners Webmaster Help AMW30 WebAn30 and 129. -Resources 28. See Also American Customer Satisfaction Index (ACSI) Resources 103 Adaptive Path 168 Adobe Illustrator 167 Adobe InDesign 167 AIGA 51 Align Interactive 217 Aquent Talent Agency 51 Ascend Reality Solutions 174 Baby 18 250 18 Behavior 249

Blue Flavor 167 Blueprint CSS 167 "Brand Experience and the Web", 12 Brooks, Mark 201 Card Sorting Table 109-110 Coroot 51 Creative Commons 50 Digital Web Magazine 167 Doorway Pages 142 Evans, Will 1811 Google Content Code 1811, Jon 219 Heuristics Analysis 71 HTML Prototyping 214 Illustrator 167 Image Maps 213–214 Information Architecture Institute 51, 167 Information Search 174 Keyword Recherche-Tool 135 Websites for Marketing Campaigns 16Point 7 Names for People 118 Omnigraffice Draw 167 Open Place 109 EsSourcen Face Type 117 PowerPoint 167 Random Name Generator 118 Search Engine Optimization Starter's Guide 129 SEO (Search Engine Optimization) 143 Slingthought 217 Social Security Administrator 143 Census) 103 Tools 167 Usability Testing Scripts 240 Usability.gov 240

User Interface Engineering 125 User Satisfaction Measurement Tools 103 UX Design Approaches 24 UX Organizations 8 UX Research 95 Visio 167 WAMMI (Website Analytics and Measurement Inventory) 103 Help for Webmasters/Site Owners 129 WebSort 102 WebSort 102 WebSort 104 WebSort! Interface Library Site 214 WebSort Site 109 WebTrends Site 24 White Hat vs. Black Hat 141–142 Whiteboard, 149 wire illustration and annotations 186–187, 193–194, 201 application of the numbering system to 173 prototypes 201 approaches to change through compare and contrast 20 0 create 189, 198–199 design to homepage 197–200 as exercises in iterations 201 collect customer information for review 192–193 of 186–187 present 202–203 versus realistic prototypes 2019391, 201 –1932 201 defined as “thinking device”, 198 tools for 189 –190 users 188 visual design 200–201 contract workforce 49 workflow, scripting 149 spreadsheets, authoring for business needs 153 WYSIWYG editors, authoring 409–

And Yahoo, research by 128 Yahoo! Site da interface library 214

INDEX

267

Get 45 days of free online access to this book! And get access to thousands more by signing up for a free trial of Safari Books Online! Purchasing this book gives you 45 days of instant, searchable online access to Safari Books Online! And while you're there, be sure to check out Safari Books Online's on-demand digital library and free trial offer (a separate sign-up process). Safari Books Online subscribers have access to thousands of technical, creative and business books, instructional 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.