Building a UX Road Map

Editor's Notes

• #2: Building a UX Road Map Slide Deck // UX SOFIA // November 2018
• #3: UX SOFIA 2018 A stellar conference in beautiful Sofia, Bulgaria
• #4: No Unauthorized Use, Please Enjoy this slide deck. Learn from it. Just don’t call it your own or use any of the images. Really, that’s just not nice.
• #5: Follow me on Twitter Solid UX insight you can use. You can also email me at dean.schuster@truematter.com
• #6: I am from the American South. This is how we say hello. KEY You = One person Y’all = A small group of people All Y’all = A large group of people
• #7: South Carolina This is what the great state of South Carolina looks like. This is where I live, right in the middle.
• #8: South Carolina in the United States of America South Carolina is on the East Coast of America. We’re about three hours away from Atlanta and eight hours away from Washington, D.C. It’s hot in the summer and mild in the winter. I think it’s perfect.
• #9: About truematter I am a partner and co-owner of truematter (www.truematter.com), a UX consultancy. We’ve been in business for nearly 20 years. We do UX. Nothing else. We are not an agency or brand design firm. We don’t do SEO, social media, or inbound marketing. We don’t build commodity web sites. We solve difficult digital product and service problems.
• #10: Maps help you reach your destination. When we make digital products and services, we have a destination in mind. We have a vision. Users have needs and goals. A road map helps unite internal and external imperatives and show how to arrive at a stellar result for all.
• #11: What We’ll Cover in this Workshop.
• #12: Part 1
• #13: Part 1 What is a UX Road Map?
• #14: The UX RoadMap is Discovery documentation. But it is different from most documentation you may have seen. It sets the stage for a user-friendly digital products and helps you sell the solution to the client. It is both project guidance and buy-in tool.
• #15: Typical Parts A UX Road Map is made up of several parts, many of which will be familiar to you. They are simply presented differently and targeted to drive stakeholder buy-in.
• #16: Elements of the UX Road Map The Road map will morph and adjust based on project need. A Road Map for a highly technical desktop software redesign will be quite different from one for a a nimble watch app. But the Road Map always centers on the user, first and foremost.
• #17: Your research builds the Road Map.
• #18: Interally-Focused Elements Naturally, the Road Map must reflect the internal needs and goals driving the project.
• #19: Executive Summary This and the budget/timeline pages are the pages most likely to be read by a C-Level person. Here you must offer the essence of the value of the desired end-state for decision-makers.
• #20: Initial Recommendations Working from the Executive Summary, this screen relates core finings at a high-level. There’s not much detail here yet.
• #21: Goals and Objectives With a clear description (interpreted of course) of a client’s internal imperatives, you continue to win them over later. We offer Primary (user-based) goals and Secondary (Internal) goals. Right away, we are training stakeholders that their goals take a backseat to those of users. Everything however, works to achieve the end-state.
• #22: User-Focused At its heart, the Road Map centers on users, who they are and what they need to do.
• #23: User-Driven Personas Personas should always be directly informed by real users. The final Persona will reflect research, observation, analytics, testing results, and so forth. But fundamentally, real users must contribute. There is no substitute for this. The Persona above is 100% user-driven.
• #24: Findings In the Discovery process you may do interviews, contextual inquiry, user tests, or participatory users exercises. Either way, your high-level findings should make their way into your UX Road Map. Stakeholders will see this. Decision-makers will sign off on it. Later, they will find it difficult to argue against.
• #25: Sample: User Test Scenario Report This report is taken from a user test. A more in-depth Road Map might include samples lies this, or reference separate reports. In each case, reports are visual and simple.
• #26: Sample: User Test User Report This report is also taken from a user test. It may also inform or be a part of a Road Map. In each case, reports are visual and simple.
• #27: Sample: User Test Findings Interpreted findings are more likely to become a part of a Road Map. Always keep things simple.
• #28: Sample: Cards Sorting Results Based on spreadsheet or card sorting tool reports, a quick visual can reinforce key findings to stakeholders.
• #29: Sample: Cards Sorting Results Visuals can be offered in a variety of ways. A Road Map is modular. Beyond the basics of users and internal objectives, your Road Map will be tailored to your project and stakeholder audience.
• #30: Benchmarks All Road Maps should include benchmarks, which should be categorized by type (e.g., visual, content, Strategy, Function).
• #31: Features & Functions Good discovery uncovers technical issues early. The UX Road Map puts them in context of real-world use and sets the stage for project scope.
• #32: Benchmarks Always include a run-down of core features and functions. Note how they emanate from core user needs.
• #33: High-Level Technical Requirements This is an example of a list of third party tools that must be included in the final system (something often overlooked).
• #34: The Plan The UX Road Map shows the path forward and defines success.
• #35: Show the Process Clients perceive greater value when the process is transparent and open.
• #36: Be clear about the investment. Schedule and budget are always paramount. Don’t bury it. Show it prominently. If you can’t yet be specific (true for most large projects) offer a clear range.
• #37: The Rallying Point Your Road Map must include a central statement that defines the digital product solution. All work should be measured against this statement. Everyone, from the client team to all developers, must be accept and push for the end-state described by this statement.
• #38: Sample Challenge Statement Here we are user-focused, succinct, and direct. If you can summarize your project this way, you have not yet found the core value of the project. This statement takes on an internal voice, but reflects direct needs of the product’s users.
• #39: Why have we make UX Road Maps? We always knew we needed discovery. but we learned that our team and our clients were not using our initial research to its fullest value. Our developers and designers would do what they felt was right. Our client didn’t truly buy-in to the direction. Often, they would change strategy before development was even complete. They certainly would do it during maintenance.
• #40: Teams need focus. Even the best teams can stray from the mark without a guide.
• #41: Clients need it even more. Without a clear path forward, you are vulnerable to the whims of clients.
• #42: Construction We do this work in InDesign, but there is nothing magical about the software tool we’ve chosen.
• #43: Think of yourself as a scientist or doctor. You are first clearly identifying and understanding the problems at hand. You do this through typical user research. Findings are brought into the Road Map.
• #45: We’ll teach you have to lead these exercises. You’ll learn more in 3-4 hours in person with users than you thought possible. And the qualitative feedback will be far more useful than many subjective, highly flawed methods (E.g., Focus Group discussions).
• #47: The Focus Group Issue We don’t want group think or bias. We want real input, as objective as we can possibly get early on.
• #50: Technical teams often make this mistake. Users don’t know what they want. They can barely describe their needs and behavior.
• #53: Part 2 Conducting Exercises
• #54: User-Driven Personas Lead users to inform their own personas.
• #55: Sample Personas Personas are a common tool. The difference here is the presentation in the UX Road Map and the origin of the data.
• #57: Lauren Robinson This persona was crafted from research data and direct input from users fitting this profile.
• #58: Sample Persona Chart The essence of a persona is simple. Have users fill out the chart. Multiple users who fit the profile can do this. By keeping things simple, we retain focus on users themselves and their tasks. Users understand these things well. We avoid the complexity that comes from extraneous persona details.
• #59: Leading the Exercise - Each user fills out a persona, and contributes to all others. - Discuss when done. - We are not yet talking about an interface of any kind, just needs and tasks.
• #61: The Power of Real Users - They do not share your experience and bias. - They don’t know systems but they know themselves.
• #62: Users do the exercise. You facilitate. Your job is to set-up, prepare users, and observe them as they fill out the chart and/or discuss it. Naturally, you should take notes.
• #63: Don’t do the work for them. Don’t help. Just encourage them to offer their insight. No judging at this point.
• #64: Encourage client observation. Bring clients to user exercises. Just make sure they observe and take notes only. They should not speak or help in any way. They are scientists too.
• #65: Filter input through research and other activities. Because users can’t tell us what to do with an interface, their input must be compared and contrasted with other research, data, and exercises. Taken as a whole, your resulting personas will be highly effective.
• #67: Part 3 Benchmarks can teach us a great deal.
• #68: Exploring Benchmarks Often, we can glean valuable information about real-world use by having users comment on similar sites or apps.
• #70: Sample Screen In our exercise, we printed screens from several UX conferences and had everyone comment, in writing, on the print-outs. Each of us is a core user of UX Conference websites. Our comments therefore have specific value.
• #71: Sample Screen Do not direct user comments. Users may write whatever they wish, provided they comment on every screen. Comments are offered anonymously, but not in a guarded fashion. Users can read, and even comment on, other user’s statements.
• #72: Sample Screen All comments are offered in silence. No talking during the exercise.
• #73: Leading the exercise. Spend roughly 30-45 minutes on this exercise. After all users are done offering individual, written comments, hold a brief discussion.
• #75: Prepare users with these guidelines. You can get interesting qualitative feedback from an exercise like this.
• #76: Remember, you are a scientist. You are out for unfiltered feedback.
• #77: Part 4 Other Exercises
• #78: There are many types of user exercises you can include.
• #79: Surveys This is a tried-and-true research method.
• #80: Card Sorting This is an excellent individual exercise that can be conducted in a separate room from the group room. While a large group is going through exercises, individuals can perform card sorts. This will help maximize the efficiency and accuracy of user sessions. Problem users should be the first to exit the room to do a card sort. :)
• #81: Discussions Because you are in a group session, discussion is inevitable. Keep it short and targeted on specific subjects. Do not let discussion take the place of individual, or non-group feedback. Discussion is not central, but additive.
• #82: Part 5 Prototype Exercise
• #83: Making Prototypes User-Driven prototypes can offer valuable insight about how users understand their main tasks. They can be as simple as leading users to design an ideal home page.
• #84: Tools of the Trade User prototypes are low fidelity and use simple tools.
• #85: Sample Paper Prototype You are not looking for design ideas, layout, or exact content. When users construct a prototype on their own, they are telling you what matters most to them.
• #86: Helping Users Make Prototypes Show samples Focus on tasks. Do not prescribe solutions.
• #87: Our Exercise Since we are the actual users, our prototype will provide solid value.
• #88: Parallel Exercise One team will create a prototype for a digital product they do not actually use. We’ll compare and contrast the results.
• #89: Helping Users Make Prototypes
• #90: Explain the process clearly. This is not a normal exercise for most people. But with encouragement, they will do nicely.
• #91: Reassure users. There are no bad prototypes. We are not judging artistry. We are learning about priorities and tasks.
• #92: Offer targeted help. Help users construct their prototype, but don’t proscribe any solutions. Don’t judge their ideas.
• #93: Get details. Get users to tell you why they’ve made their choices. Take excellent notes.
• #94: Discuss If possible, the prototype team should present their ideas to the larger group. This allows further explanation of choices.
• #95: Part 6 Organizing Exercises
• #96: How to run effective user exercises.
• #97: Find the right users. Effective exercises depend on finding real users who use a product or will use it.
• #98: Neutral locations are non-threatening. Third party locations are almost always the best choice.
• #99: Always reassure users. Make sure users Have fun. Remind them they are not being tested. There are no wrong answers. We just want them to be themselves.
• #100: Leave room for improvisation. No user session or user group is quite the same. Devote more time to the most revealing exercises. Leave time to add new exercises if needed.
• #101: Police your users. You can often encounter problem users who demand too much attention or dominate the group. Separate them for early card sorting or special one-on-one discussions. :)
• #102: You need help. It takes at least two professionals to run user exercises and potentially another if you are doing card sorting. No matter what, always make sure you bring a dedicated note-taker.
• #104: The UX Road Map in Action Your Road Map guides your internal team and helps sell solutions to stakeholders.
• #105: Create something easy to read. You make digital products that are easy to scan, well titled, cleanly designed, and employ microcopy. Your UX Road Map should be no different.
• #106: CEOs don’t read. Give them something concise and visual. Make it easy to see the executive summary and the numbers. Everything else needs to appear easy to digest.
• #107: You are proving something. You are making a case for building a digital product the right way. The UX Road Map is your tool against internally-focused stakeholders, bureaucrats, and those who would derail a project for political purposes. Use the Road Map to build consensus.
• #108: Visuals tell better stories. When possible, make your Road Map template visual, but not ornate. Visuals must make information easy to digest, not obfuscate it. Again, practice what you preach.
• #109: One size does not fit all. Some UX Road Maps can be very small and short. Others, for complex projects may be longer. Create a template with multiple parts and use them as they are needed.
• #111: This is a collaborative process. The making of the UX Road Map is the best way to get your whole team on the same page before more development.
• #112: Bring stakeholders in early. Content area experts, internal team members, and internal stakeholders will be a part of any solid Discovery process. Continue to include them by showing them the UX Road Map in progress and when you are done. Early participation and buy-in will save you a great deal of time and heartache later.
• #113: Never blindly send the UX Road Map to a client. Show the UX Road map in person or via a video conference BEFORE providing it. If necessary, do more than one presentation. If you cede control here, much or your consensus building will be at risk.
• #114: Continue to sell the document. Even after sign-off, make sure you keep the UX Road Map front and center. refer to it often. Show pieces of it. Use it to judge strategy, process, and decisions.
• #115: Change sparingly. Change the UX Road Map if you must, but do so with everyone’s agreement. It shows flexibility. Always bow to new, better data.
• #116: How do you measure the value of the UX Road Map?
• #117: The UX Road Map helps you and your team.
• #118: It’s a hammer. Hard to argue with an evidence-based document. It’s easy. Even the CEO can read it. Open to any page and find quick value. Executive Summary and Cost. Easy.
• #119: Cost is Relative You are delivering value and reducing risk.
• #120: Find more insight at the truematter blog. We’re not out to sell you anything. It’s just great UX insight, freely offered and shared. Subscribe https://truematter.us1.list-manage.com/subscribe?u=fa4b4f8c36e84b065f35ddb13&id=8a00d2de9b (Please forgive our temporary, truly non-human-readable URL.)
• #121: Follow me on twitter. I’d love to interact more with you online. Drop me a line, ask me a question, and let’s talk UX.