Presentation by John Yesko at the 2011 Information Architecture Summit (IA Summit) entitled: "The User Experience Brief: The What and Why Before the How."
We IAs spend a lot of time discussing the “core” documents in information architecture—wireframes, site maps, prototypes. But we often jump into these very tactical, design-oriented deliverables too hastily.
The user experience brief takes on a more strategic role. Early in the project, it’s our vehicle to summarize what we know so far, particularly requirements and research results. More importantly though, it lays the foundation for the UX design approach, with the goals of gathering consensus and identifying sticking points early on. The user experience brief illuminates the organizing principles—user experience fundamentals to be followed and referenced throughout the project.
We’ll talk about the value of this early-project document, its role in shaping the user experience approach, how its composed, and its limitations. We’ll look at a number of great visual examples too. Introduced the right way and at the right time, the UX brief can be an invaluable stake in the ground with clients and internal stakeholders.
2. About me Now: Director of User Experience at Walgreens Web! 1993 1995 2000 2005 2010 Information Architect / UX Designer Web Designer Medical Illustrator
4. User Experience at UX group Organized by lines of business 13 UX designers Information architecture Interaction design Taxonomy User research Just announced deal to acquire Drugstore.com 60K more products 3M loyal customers Several strong URLs/brands Looking for experienced UX help in Chicago! And small agencies
6. What is the UX brief? Early-stage strategic approach document with two primary goals: Summarizes what we know so far = output of Discovery process Sets up how we intend to attack the project
7. Who is it for? Stakeholders Clients (external) Business owners and executives (internal) “Downstream” team Creative Technical
8. Where does it fit? DISCOVERY DESIGN Delivery to Creative and Technical Business Requirements Document User Experience Team UX Business Insight UX Brief Implementation / Product Assignment UX Business Insight User Flows * User Flows and Wireframes: Conceptual Wireframes: Detailed / Annotated Input from Stakeholders User Research User Research *Your process may vary
9. Why do we use it? To get a head start on building consensus To discover any early “red flags” As a touch point to reference later (CYA)
11. What’s in the UX brief? “Master” content outline includes: Project overview User experience inputs Organizing principles Deliverables Issues and risks Tailored to the particular project Varies in length depending on needs (and audience’s attention span) Often doesn’t include every possible element
15. Inputs User research insights Usability tests Card sorting Surveys “I can’t find where to refill my prescription.” “THIS APP SUCKS!!! IT DOESN'T BRING UP MY PHOTO ALBUMS...WALGREENS, I USED TO WORK FOR YOU, I BUY YOUR CRAP, SO GET YOUR [EXPLETIVE]TOGETHER!!!” “Let me finish my primary task first—then I’m OK with being upsold.” “No additional features - the Home page is so crowded now that I want to give up now rather than slog through the ads and options for what I'm after…” @heyhiLindsay “[Expletive] just ordered a calender on walgreens.com and it was literally the hardest thing I've ever done in awhile, [expletive] that.”
16. Inputs Personas and scenarios May be developed specifically for larger / longer-term projects Existing “approved” personas can be referenced where applicable Scenarios may reflect requirements and preview functionality
17. Inputs Competitive insights Best practices Opportunities to fill a missing need Emerging standards, e.g., common functionality or taxonomy
18. Inputs Stakeholder insights Goals and challenges from those sponsoring the project Consensus, or alliances on controversial topics “We have a great story to tell. We need rich case studies to show what we’ve done in the past.” “Booking appointments online is great, but it doesn’t necessarily mean we can get them into the shop right away when they show up.” “When a potential customer sends an email inquiry through the site, it typically gets shuffled around to five or six people. We don’t have any way to track whether it’s been followed up.”
19. Inputs User experience / heuristic insights Observations from the UX team May be hypotheses, not yet proven by user research (or unprovable) Potentially confusing category labels Inefficient global navigation
22. What are organizing principles? Loosely interpreted: Fundamentals and strategies we will observe while designing Major areas of UX focus High-level design approach Range from general to specific Generic UX guidelines Project-specific design ideas General Specific
23. What are organizing principles? May include other “deliverables”: Concept map User flow High-level wireframes Suggestions of look and feel (e.g., mood boards)
25. Examples Really means… There will be several influences, but we’re ultimately making the decision. Leverage multiple inputs to taxonomy design Industry Standards New Taxonomy Internal Business Insight User Experience Team Analysis User Research
26. Examples Really means… We care most about what customers think of our higher-level taxonomy. Once we get down to the deeper levels, we need the internal team to make decisions—because it’s harder to test (and it’s a lot of work.) Leverage multiple inputs to taxonomy design The inputs will have different levels of influence at various levels of the taxonomy. User Research Internal Insight Influence Industry Standards Tier 1 Tier 2 Tier 3 Tier 4
27. Examples Really means… If we can’t figure this out pretty soon, it will be hard to proceed with the UX design at all. We’ll give you our opinions, but it’s primarily a business decision that we don’t have authority to make. Establish the online relationship among the three brands
28. Examples Really means… There are parts of the site that we’re not going to touch—but others that we need access to and cooperation on. Position the holiday content as free-standing, but with key hooks into permanent site features
29. Examples Really means… Just what is says—this one is more about a design philosophy. Treat the product as the core, and organize the site around it
30. Examples Really means… We’re getting rid of all this crap that you all fight over, but users don’t care about. Eliminate underused or poor-performing content Candidates Low usage; poor content Low usage; poor labeling May be consolidated Low usage; especially frames 2-5 Low usage; redundant
31. Examples Really means… You came to us for a re-design of your site, and we’re doing that. But your main call-to-action is that users should contact you to establish a relationship. If you screw that up, it doesn’t matter how good the site is. By the way, we don’t do CRM systems—this isn’t an upsell. Develop a lead management / CRM solution
32. Examples Really means… This is a multi-channel experience (even though we’re only working on one channel). If we promise something on the Web that the in-store experience doesn’t follow through on, both are screwed. Adapt store operations to integrate with eCommerce
33. Examples Really means… There’s a real “cool factor” with your work, but your 100x100 pixel graphics aren’t cutting it. Also we have a bunch of visual designers with hipster glasses who get tired of combing through stock photo sites. Leverage the rich visual nature of the company’s work
34. Examples Really means… This kind of shopping is still new to a lot of people. If they don’t understand the overall concept, it won’t matter how usable the site is. Introduce customers to the concept of buying online, not just buying from us 1 2 3 4 5 Make an appointment at one of our certified installers Go in for your installation appointment, and you’re done! We ship your tires to the installer Choose your tires Check out online
35. Examples Really means… We’re going to expand the use of dynamic menus. Expand the use of dynamic menus Fly-out menus can empower more direct user navigation to deeper content and functionality Accessibility and mobile device limitations need to be considered Pharmacy Refill Prescriptions Transfer Prescriptions New Prescriptions Express Refills In-Store Chat With a Pharmacist Automatic Refills Example
37. Risks and limitations May quickly become out-of-date as details are fleshed out Approach evolves as design details are worked out Treat as a “snapshot” in time Can create a perception of added time that could be spent designing Although it probably saves time in the long run Stakeholders may not understand what they’re agreeing to Can be too abstract for some to provide meaningful feedback May not engage until they’re seeing design treatments
38. Wrap up Helps survey the situation Who has strong opinions? How much weight do we need to give them? What factions are going to clash? What important issues may have been missed? Encourages collaboration early (or at least healthy discussion) Can save time defending solutions later Winning over key allies can smooth the road Builds credibility for UX Demonstrates that a lot goes into the design process Positions us as strategic thinkers and experience planners, not order-takers