31,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Do you want to create better products and innovative solutions? User experience maps will help you understand your users and improve communication with them. Maps can also champion user-centricity within the organization.
This book is the first print resource covering two advanced mapping techniques—the behavioral change map and the 4D UX map. You’ll explore user story maps, task models, and journey maps, while also creating wireflows, mental model maps, ecosystem maps, and solution maps. You’ll learn how to use insights from real users to create and improve your maps and products.
The book delves into each major user experience map type, ranging from simple techniques based on sticky notes to more complex map types, and guides you in solving real-world problems with maps. You’ll understand how to create maps using a variety of software products, including Adobe Illustrator, Balsamiq Mockups, Axure RP, and Microsoft Word. Besides, you can draw each map type with pen and paper too!
The book also showcases communication techniques and workshop ideas. You’ll learn about the Kaizen-UX management framework, developed by the author, now used by many agencies and in-house UX teams in Europe and beyond.
Buying this book will give you hundreds of hours worth of user experience knowledge, from one of the world’s leading UX consultants. It will change your users’ world for the better. If you are still not convinced, we have hidden some cat drawings in it, just in case.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 405
Veröffentlichungsjahr: 2017
Ähnliche
Title Page
BIRMINGHAM - MUMBAI
Copyright
User Experience Mapping
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: May 2017
Production reference: 1240517
ISBN 978-1-78712-350-2
www.packtpub.com
Credits
Author
Peter W. Szabo
Copy Editor
Dhanya Baburaj
Reviewer
Jay Heal
Project Coordinator
Ritika Manoj
Commissioning Editor
Ashwin Nair
Proofreader
Safis Editing
Acquisition Editor
Reshma Raman
Indexer
Francy Puthiry
Content Development Editor
Aditi Gour
Graphics
Jason Monteiro
Technical Editor
Murtaza Tinwala
Production Coordinator
Shantanu Zagade
About the Author
Peter W. Szabo is one of the world's leading user experience consultants, the principal of the farZenith.com agency. He is a frequent conference speaker, workshop host, and user centricity evangelist. His UX blog, Kaizen-UX.com, gained its popularity for UX management articles and novel user experience approach. He used to be a senior manager leading the UX team at the world's biggest online gambling corporation, Amaya Inc. (known for brands such as PokerStars, BetStars or FullTilt). As UX Director at WhatUsersDo (Europe's largest remote testing platform), he contributed to the widespread acceptance of remote research in the UX industry.
Outside of the UX world, he is the proud father of Maya and Magor. He enjoys reading, writing, and playing games (not just computer ones). He is a cat person. Ok, that's an understatement, he is simply crazy for cats.
About the Reviewer
Jay Heal is a Cambridge-based UX consultant with expertise in user-centered design, service design, interaction design and user research.
His principle belief is that design is both a collaborative and interactive process of problem solving. Great design solutions are achieved from a deeper understanding and empathy of the people they are intended for.
As a practitioner, Jay is a vocal advocate of the test early, test often approach to UX, where numerous ideas and concepts can be quickly validated until the right solution is found.
Having graduated from the University of East London in New Technology and Multimedia Design in the early 2000s, his passion for designing for people has led him to work with organizations that include the BBC, Ministry of Justice, Just Eat, Virgin Trains East Coast, and Transport for London.
Away from design and research, Jay is a devoted family man to his children (Dennis, Yasmin and Max), a music enthusiast, home barista and self proclaimed foodie.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1787123502.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Dedication
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the color images of this book
Errata
Piracy
Questions
How Will UX Mapping Change Your (Users) Life?
Getting started with User Experience Mapping
Why did the requirements document fail?
How to jump-start mapping?
Visualizing - what the cat wants you to know
Creating a backlog for a cat-sitter
Pen and paper are all you need – but adding color makes the maps great
Drawing the diagram
Cats of the digital age use a computer
Summary
User Story Map - Requirements by Collaboration and Sticky Notes
Why should you create user story maps?
Just tell the story
How to tell a story?
The audience
Start with action
Simplify
Tell the story of your passion
The grocery surplus webshop
The opportunity to scratch your own itch
How to create a user story
User story templates
The Three Rs or the Connextra format
Five Ws
Lean Startup
Kaizen-UX template
INVEST - the characteristics of a good user story
I for independent
N for negotiable
V for valuable
E for estimable
S for small
T for testable
Epics
Breaking down epics into good user stories
3 Cs – the process to turn stories into reality
Card
Conversation
The power of four amigos
Confirmation
The narrative flow
Events (tasks)
Milestones (activities)
The user story map on the wall
Creating user story maps digitally
Creating a new board
Adding cards to your board
Summary
Journey Map - Understand Your Users
F2P FPS (an example from the gaming industry)
Personas
3i: How to create personas
Investigating (potential) users
Interviews
Existing user database and analytics
Surveys
Social media
Identifying behavior likelihood
Imagining the characters
The primary persona
HAL 9000 will not use your app
Creating persona documents with Smaply
Creating a journey map with Smaply
Task models
Creating the task model in Adobe Illustrator
Milestones (stages)
The origin story
Milestones of a task model
Evaluations
Creating an evaluation diagram
The finished task model
Designing the user journey
Interactions
Summary
Wireflows - Plan Your Product
The customer support chatbot
Wireframes
Wireframes and color
Low-fidelity versus high-fidelity wireframes
Lo-fi wireframes
Hi-fi wireframes
Wireframing with Balsamiq Mockups
Beyond the first wireframe
Creating symbols
The after chat survey
Creating the wireflow
Wireflow Improvement Workshop (WIW)
Why should you run a WIW?
Running a WIW
Summary
Remote and Lab Tests for Map Creation
Samsung's 2017 redesign
Test objectives
The amigos run user tests
Lab, remote, and guerrilla testing
Lab testing
Remote testing
Guerrilla testing
Why run both lab and remote testing
Rapid Iterative Testing and Evaluation (RITE)
How to test Samsung UK?
How many test users?
46 users walk into a lab
Finding the right users
Devices
Target audience
Pre-screener
Private panel
Moderated versus unmoderated tests
The scenario
Writing tasks and questions
Asking for opinions and expectations
Privacy concerns
Exit questions and exit surveys
Test script for our smartphone buying journey
The pilot test
Testing with WhatUsersDo.com
Summary
Solution Mapping Based on User Insights
Contiki adventure
Tagging - the science of active watching
How to tag videos
What to tag
Tag title and comment
Tag types
Positive tags
Suggestions
The negatives: High, Medium and Low
The behaviorist issue severity model
The research summary
The solution map
Five steps to create the solution map
Step 1 - put the issues on the map
Step 2 - form the issue trees
Step 3 - solve the root issues
Step 4 - identify obstacles
Step 5 - create actions to remove the obstacles
Put the solution map to action
Summary
Mental Model Map - A Diagram of the Perceived Reality
What's a mental model?
Buying a car
How mental models work?
Longitudinal research
Logging types - how to log?
Prompts: what to Log?
Mental model mapping
Analyzing longitudinal research
Find units
Group units into towers
Form mental spaces
Supporting solutions
Finishing touches
Using the mental model map
Summary
Behavioral Change Map - The Action Plan of Persuasion
The Amazon miracle
Is it possible to change behaviors?
Credibility
The cue-routine-reward framework
From external to internal cues
Automate repetition
Heuristic and systematic processing
The LEVER framework
Limitation
Elevation
Validation
Ease
Reversibility
Drawing the behavioral change map
How to use the behavioral change map
Summary
The 4D UX Map - Putting It All Together
The restaurant without tables
Sum of all maps
Greater than the sum of all maps
The MAYA map
The first dimension - milestones
The second dimension - events
The third dimension - importance
The fourth dimension - severity of the problems
Mental model snippets
Ratings
Drawing the 4D UX Map
Using the 4D UX Map
Evolving the 4D UX Map
Summary
Ecosystem Maps - A Holistic Overview
Shutter Swipe – where photographers and models meet
The ecosystem
How to map an ecosystem
Creating hexagon maps
Hexagon mapping with Inkscape
Creating hexagon maps with Adobe Illustrator
From hexagons to ecosystem maps
Using ecosystem maps
Stakeholder maps
Summary
Kaizen Mapping - UX Maps in Agile Product Management
Your opportunity
The manager and the map
Kaizen-UX manifesto
Agile beyond the buzzword
The three UX roles
The Kaizen-UX framework
UX strategy – the beginning of all maps
The UX strategy document
Summary
References
Preface
There is no map to writing introductions. Fortunately, there are maps to great user experience and outstanding products. This book is about those maps.
Do you want to create better products and innovative solutions? User Experience Maps will help you understand users and communicate this understanding with others. Maps can also champion user-centricity within your organization. They will fight for your users.
But no map can carry the sway of product design battles alone. That's why you need an army of maps. And that's why we need you to wield them like the shining sword of user-centricity.
This book reveals two advanced mapping techniques for the first time in print, the behavioral change map and the 4D UX map. You will also explore user story maps, task models, and journey maps. You will create wireflows, mental model maps, ecosystem maps, and solution maps. In this book, we will show you how to use insights from real users to create and improve your maps and your product.
Start mapping your products now to change your users' lives!
What this book covers
Chapter 1, How Will UX Mapping Change Your (Users') Life?, gets the reader started with User Experience Mapping in a fun and engaging way. In this chapter, we will create a simple map, not worried about map types and UX mapping theory. We will use pen and paper, to give the reader the first taste in mapping and demonstrate its strength.
Chapter 2, User Story Map - Requirements by Collaboration and Sticky Notes, is a simple technique to visually tell the users' story. The linear map helps you create a narrative flow. Because it's quick and easy, it can be used in the early ideation phase of a product.
Chapter 3, Journey Map - Understand Your Users, the journey maps is a tool, that helps us to understand and communicate users' behavior as they progress through a route using interactions, trying to accomplish their goals.
Chapter 4, Wireflows - Plan Your Product, wireflows are journey maps where key interactions are represented by wireframes of the relevant views. They allow you to create, explore, communicate, and improve the interactions in detail.
Chapter 5, Remote and Lab Tests for Map Creation, by watching users while they interact with a solution, we gain understanding. This understanding leads to better maps and better experiences.
Chapter 6, Solution Mapping Based on User Insights, a solution map is a tool that will help us find solutions and communicate them. They are visual representations of an actionable project plan. Ideally, solution maps should be based on user testing sessions with real users.
Chapter 7, Mental Model Map - A Diagram of the Perceived Reality, a mental model map is a visual representation of a user group's thought process and patterns. The mental model shifts the focus from designing a solution to understanding the user's state of mind, and how we can support those states.
Chapter 8, Behavioral Change Map - The Action Plan of Persuasion, a behavioral change map is a path to changing a user group's behavior. It should be simple and impactful, based on a real understanding of our user's mindset and thought processes.
Chapter 9, The 4D UX Map - Putting It All Together, the 4D UX map is a compact summary of a UX project, a high-impact deliverable to visualize how the users' needs are met.
Chapter 10, Ecosystem Maps - A Holistic Overview, the ecosystem map places our solution in the greater context of the holistic user experience. This map aids the identification and integration of complex, interdisciplinary information concerning the user experience ecosystem.
Chapter 11, Kaizen Mapping - UX Maps in Agile Product Management, you can use the Kaizen-UX framework to structure your product design and user experience efforts. The agile framework defines the three core roles within the UX team, it has a UX strategy at its core, and it leads to better products and better communication within the team and with stakeholders.
What you need for this book
To draw a map, you only need a pen and a slightly larger sheet of paper. But software can help tremendously. That's why this book contains detailed, beginner-level tutorials on creating maps using different software products, including Adobe Illustrator, Balsamiq Mockups, Axure RP, or even Microsoft Word. Remember, even if you don't have access to any of those, each map type can also be drawn using a broad range of software or even freehand.
Who this book is for
This book is for Product Managers, Service Managers, Designers, and anyone who is keen on learning User Experience Mapping techniques to improve how they communicate their ideas. It's for You!
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "If you do, you can share your results with me on my Twitter account:@wszp".
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "If you want, you can rotate the text from theFormat Shapepanel (Text Options | Text directiondropdown)".
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/UserExperienceMapping_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
If you want to contact the author, use [email protected].
How Will UX Mapping Change Your (Users) Life?
In this book, I will change your life. I will show you techniques that will help you to understand your users, gain strategic insights, and improve communication within the team and with stakeholders.
In this introductory chapter, we will perform the following things:
Create our first User Experience Map.
Similar to the other chapters of this book, we will solve a real-world problem, but for this one, we will start with a rather fun and unusual one.
After setting the scene, we will take a look into the shortcomings of the old requirements document from the waterfall product management model.
This naturally leads to the solution that states that most problems can and will be solved with improved communication.
We will see how mapping can be the ideal tool to facilitate communication.
We will have to discuss some basic mapping terms, output, outcome, and opportunity.
The next sections of this chapter are about visualizing and creating a backlog.
All this should equip the reader to create their first UX map on paper.
Then, they should be able to do it digitally. (You should use the software you are most comfortable with to map. In the following chapters, we will use a wide array of software tools, but for this chapter, I have chosen Microsoft Word.)
Getting started with User Experience Mapping
Now, let's talk about cats, and improving their lives. After all, cats always come first, when you need to improve someone's life. Later in this book, we will create maps for complex apps, websites and other digital projects, but in this introductory chapter, we will get started with a low-tech problem.
Imagine having a cat. You can imagine any other pet, but the example will be a bit different with longhorn or other cattle. You are planning an extended holiday with limited phone and no Internet access, and you need to leave your cat at home. (Not because of the lack of Internet access. Unlike UX designers, cats can survive prolonged periods of time without the Internet.) Fortunately, you have found a cat-sitter. Now, for the plot twist--although the cat-sitter has watched thousands of cat videos, she never had a cat.
You could tell her what to do. Chances are you would forget something obvious to you, but surprising for her. On top of that, you would have to rely on her memory and understanding.
Why did the requirements document fail?
Why shouldn't you give a 100 page document to your cat-sitter? Writing a documentation and sharing that with your cat-sitter might seem like a better idea. In the "information stone-age" of the early 90's, software delivery was based on a requirements document created as the first phase of the waterfall model. It seemed like a good idea back then. In this analysis phase, a long document was written. This document contained many details about what's being built, ahead of time, as well as an executive summary and product description and possibly many other sections. The requirements document was then approved and signed, and it represented a commitment. Requirements documents assumedthat it's possible to know every eventuality up front and that priorities would not change. Obviously, they were not cast in stone. They were often revised, and sometimes even drastically changed.
Now, imagine our cat-sitter getting a 100-page requirements document with many sections. What are the chances that she misses or misunderstands something? Software developers cursed with a massive documentation feel the same.
According to Paul Vii and most other experts, waterfall was the most popular product management model in software development. In the first phase of waterfall, usually named analysis, the business analyst and the product owner will put together a set of requirements. Why has this approach failed?
The waterfall model's requirements document can lead to dysfunctional communication, lack of collaboration, and understanding
.
The emphasis is often put on negotiation
. Cat-sitting and software development share the hate for contract negotiations, and walls of text are usually a source of a few misunderstandings. I hope that you appreciate the irony of arguing against writing long texts, while my arguments are part of a long text in a printed book.
The requirements documents are intimidating
, not just for cat-sitters, but anyone involved in a project. When you get a requirements document, the first thing that might cross your mind is whether you will ever be done with this, or what exactly you will deliver at the end.
Documents usually don’t break down projects into tiny functionality bits, and some functionalities can be lost among thousands of lines of text
. Now, imagine if the location of the cat food was on page 74, paragraph 8. Remember, there is no easy way to contact you.
Such a document places our process above people
. In our case, it would seem as though we cared more about the paperwork than the cat-sitter and her interactions with our cat.
Even if you could create the best masterplan ever, unforeseeable things can and will happen. Rigid documentations and plan-following mindsets will make responding to change backbreakingly hard
. What if your cat explodes while you are away? You cat-sitter will flip through your lengthy documentation over and over, not finding anything about exploding cats. Although cats very rarely, if ever, explode (unless you are playing the
Exploding Kittens
card game), in software development even more unexpected things can be produced by the machine-spirit.
Even the best ideas will need continuous improvement, to stay competitive
. If you regularly go on holiday, sooner or later technology will make most of your cat-sitting requirements document quite obsolete. With the
Internet of things
connected to your cat bowl, you will not need a cat-sitter to feed your cat manually. They can simply download the app to their phone.
People want to work on making the world better, not spend time creating or understanding a long documentation
. The cat-sitter wants to concentrate on making your cat happy, not lawyering a comprehensive documentation.
As you can see, our problem will not be solved by telling the cat-sitter what to do or writing a comprehensive documentation.
Most problems can and will be solved with improved communication. The goal of the improvements in communication is to achieve a shared understanding. I think that the best communication method for shared understanding is drawing a map.
In Chapter 2, User Story Map – Requirements by Collaboration and Sticky Notes, we will see how maps and improved communication will address the problems of rigidity, lack of collaboration, and inflexibility of traditional requirements documents.
This book will teach you many User Experience Map types so that you can pick the right tool for the situation. The examples in the other chapters are product management, usually software development problems. I certainly don’t expect you to build software for your cat-sitter (at least not in this chapter.)
There is a communication technique much older than the writing technique. You guessed it, some 40,000 years ago our ancestors started to draw. At first, they didn’t draw maps, but that changed more than 15,000 years ago. A prehistoric map of the night sky on the walls of the caves at Lascaux, France, testifies this. Obviously, the creators of that map preferred hand drawing over sophisticated software products, so we will also start with hand-drawn maps.
To solve the cat-sitter's communication problem, let’s draw a map using pen and paper. Often sticky notes or other small pieces of paper are used because it's easier to rearrange them. We will create sticky notes based user story maps in Chapter 2, User Story Map – Requirements by Collaboration and Sticky Notes, but here, we will just use a sheet of paper. Don’t worry if your drawing skills stop at stick figures. Maps can be composed of some simple lines and a few written words. Some people do this instinctively during meetings. The most important thing to remember is that although mapping is a powerful tool, maps should never replace conversations.
A map is a tool you should use to facilitate the conversation. You need both the map and a conversation to solve a problem.
It’s easy to overdo mapping, hoping to reduce the need for conversation. Remember that the map is not a substitute for a conversation. It will also not work if you overdo it, as it will be confusingly complicated for others. It’s a tempting idea to draw a map so detailed that you can simply send it to the cat-sitter and get done with it. Don’t do that, it’s a terrible idea. I have seen agencies creating journey maps as a deliverable and e-mailing it to project stakeholders. Although they can look great, they rarely--if ever--meet the goals or solve problems alone, without a conversation.
We agreed that you will draw a map, and you will have a conversation where the map will help. You could also create the map during the conversation if you are an experienced mapper, but most of the time it’s better if you have the first version ready for the conversation, and create a new iteration together with the stakeholders--in our case, the cat-sitter.
Before you start drawing, you need to decide what to draw. It’s perfectly fine if your approach and strategy are not crystal clear at this stage.
Mapping is a useful tool, not just in getting understood, but it also helps you to find holes and contradictions in your strategy and approach.
How to jump-start mapping?
First, you need an idea obviously, but we already have that. The idea is to go on holiday without your cat. A terrible idea if you ask your cat, but the world is not a perfect place, not even for our feline companions.
Another thing you should decide is the opportunity. What do you expect to happen because of our process? It’s easy to confuse opportunity, outcome, and output, not just because they all start with “o”, but because some people use the terms interchangeably.
The outputs are products of the map’s usage. In other words, whatever happens because of the map is an output of the map.
In our example, opening a can of cat food is the output, but so is the cat biting our cat-sitter. We want to minimize outputs. Your resources are always limited. Even if you somehow got virtually countless people and money for this project, time will never be unlimited. Throwing more money at a project is probably the worst thing you can do, so it makes sense to do as few things as possible.
The outcomes are the results of the map’s usage; in other words, how running the whole process impacts the outside world.
For example, the cat will not be hungry after the feeding process. While opening a can of cat food or putting food in front of the cat are outputs, the outcome can be a well-fed cat or a starving cat. We will not know the outcome until the map is put in production. This means that we will only know how our map changed our cat’s life when we come home from the holiday, but not before we board the plane.
The opportunity is the desired outcome we plan to achieve with the aid of the map. This is how we want to change the world.
We want our cat to be well-fed and healthy and, most importantly, happy while we are away. This is our opportunity, the outcome we would love to happen. We will know the results of our map after it's put into practice. For now, let’s aim for a happy cat. It goes without saying that we want to have the biggest possible opportunity. It's human nature to be greedy, but cats also share this character trait with us.
Mapping will help you to achieve the most, with as little as possible. In other words, maximize the opportunity, while minimizing the outputs.
If you have an idea and opportunity, grab a piece of paper and a pen, and you can start drawing the solution.
Visualizing - what the cat wants you to know
This is not a cat-food advertisement, but a twist on Ram Charan's book, What the Customer Wants You to Know. Without delving too deep into sales, the main takeaway from the book is beginning with the customers' needs. To ensure that we maximize the opportunity and minimize the output, we need to visualize what our users want.
In Chapter 5, Remote and Lab Tests for Map Creation, we will research what our users need and what they usually do when interacting with similar products. Cats, unlike humans, really hate being researched, tested, and analyzed. So, we just assume what a cat needs and wants during our time away.
You need to make sure you visualize something implementable, something which helps you to fulfill the opportunities within the constraints of time, budget, and human resources. For our demo project, getting nine cat-sitters 24/7 in three shifts would certainly be nice, but that's probably way too expensive and way too hard to organize. Later in this book, we will see how mapping can help us in understanding our limits, but for now, we assume to know our limitations.
Creating a backlog for a cat-sitter
If you know what you want and what are your limitations, you need a prioritized list within those constraints. In the SCRUM agile software development framework, we call this list a product backlog, and it is one of the most iconic SCRUM artifacts. My favorite definition for a product backlog is from Ken Schwaber: “Product Backlog: A prioritized list of project requirements with estimated times to turn them into completed product functionality. […] The list evolves, changing as business conditions or technology changes.”
For our cat-sitter, the backlog's most important element should be to make sure that the cat has access to fresh, clean water at all times. Dehydration is definitely not an outcome we would want. A close second is making sure that the cat is well fed, but not overfed. If the cat survives, we need to make sure that she does so in good health. So, the cat-sitter should check whether the cat is sick or injured, then take it to a vet, if needed. The above three elements are strictly necessary for the survival of the cat. Among those, probably the health of the cat is the top priority. There is no time or point to feed the cat if it is about to die from some illness. Cleaning the litter box is the fourth element here, and those four elements are why we have the cat-sitter. There are many other things a good cat-sitter can and will do, for example, checking and cleaning the cat’s ears and teeth, and brushing its coat. Some cat-sitters may even give the cat a bath, or at least try and usually end up with some claw marks and bites, but that's another story. Keeping the cat clean and groomed is obviously important, not just for the looks, but for the health of the cat; but let's be honest, the cat will be just fine if a human doesn't groom her for a week. They spend lots of time cleaning themselves anyhow. Sleeping is also an important biological need, but I haven't seen any cat who needed help with that. However, there is another backlog item, which is a must, but is easy to forget. This is making sure that the cat is not lost and can't escape. (We assume it is an indoor cat in this mapping example.) If you think about it, this is the most important backlog item. If the cat-sitter loses the cat, all of our efforts will be pointless, as we will have no cat. Even a sick cat is a bit better than a non-existent one.
So, our backlog will have the following five items, starting with the highest priority:
As a cat-sitter, I want to
make sure that the cat is
not lost, and it can’t escape
, so the cat will be safe
As a cat-sitter, I want to ensure that
the cat is not sick or injured and if it is, I need to take it to the vet
so that it will be healthy
As a cat-sitter, I want to
provide fresh and clean water for the cat at all times
, so it doesn't become dehydrated
As a cat-sitter, I want to
give the cat e
nough food, without overfeeding it
so that it will be well fed
As a cat-sitter, I want to
clean the
litter box
so that the environment of the cat is clean and fresh
At the visualization phase, we don't assign time estimates to the backlog items, but later that will become important. What's important to note here is the backlog item template we have used. This is what Paul VII and other SCRUM gurus call the Three R format. In the next chapter, we will see a few other formats, but this one is the most popular.
The role is the user type. It's easy to understand why we want a map that works for any cat-sitter, not just one specific cat-sitter. We also don't want any miscellaneous passer-by to fit into it. We don't expect the janitor to take our cat to the vet, for example. In Chapter 3, Journey Map – Understand Your Users, we will create maps with multiple user groups, personas with different goals and abilities, but for now, we will focus only on the cat-sitter user group. The requirement explains what will happen. The requirements generate the outputs of the map, whereas the reasons are a subset of the positive outcomes. For example, the cat being sick would also be an outcome of the map, but certainly not a reason. As long as all reasons are aligned with our opportunity, we should be able to reach and end up with a well-fed, happy, and healthy cat when we come back. The preceding list was easy to create because we know what's more important for our opportunity. We could have written a list with 10 or 100 items, but probably we would have neither the resources nor the time for anything beyond the 5th.
Pen and paper are all you need – but adding color makes the maps great
A piece of paper and a pen is all you really need for mapping. For our purpose, the only "drawing" you need to do is drawing lines. Sounds simple enough, right? We have all created millions of lines. When we connect those, shapes emerged. Writing is simply a set of lines, no matter the language. Alyona Nickelson goes beyond that and emphasizes that lines and shapes carry an emotional message to the viewer; straight lines convey a sense of accuracy, directness, solidity, and stiffness. On the other hand, curves create a feeling of compromise and agreement, and flexibility and indecisiveness. To balance our communication, we can incorporate both types of lines. Don't worry if you can't draw a straight line. You can use rulers, or better to avoid communicating stiffness and be 100% agile, use only freehand-drawn lines.
Any pen and paper will do, but if you had more than one color, that would be really helpful. The often neglected aspect of experience mapping is color. We use brightly colored sticky notes for our user story maps (see Chapter 2, User Story Map – Requirements by Collaboration and Sticky Notes), but many UX experts just pick colors to represent a group of notes or even worse, just randomly. I hope that after reading this book, you will have a different approach. Color is an important aspect of communication. Judy Martin argues that our response to color is instinctive. We use it as a means of recognition and analysis. It not only defines space and form, but we also use color cues as invitations or warning signals. It has a subconscious emotional appeal. We associate green with the idea of life, growth, youth, spring, hope, and recently, environmental consciousness. For the artists out there, that might be a shock, because there are few natural sources of green pigment and the green coloring agents in artists' materials have been chemically developed so make sure that no green pastel dust falls on your cat, or any pastel dust for that matter.
This is a fraction (the cleaner, more presentable fraction) of my drawing equipment, but don't let yourself be intimidated by that. You don't need such a wide range of equipment for User Experience Mapping. Simply use what is available to you. A piece of printer paper and a pen is a good start. Colored mud on the wall of a cave was the choice of our ancestors, and it worked wonderfully for their purposes. Remember Barber Barrington's famous quote: A keen artist will drawwith anything and make it work to his advantage. All user experience experts are artists. Communication is an art after all.
Now, we really need to get started with drawing a map. I'm sure that the inner artist in you is itching to take a pencil in hand and draw something.
Drawing the diagram
Now things will get exciting. We will add the opportunity to the map. You can write "Opportunity: Happy Cat", or have some fun creating a happy cat line art like I did:
The main map elements in User Experience Mapping are often called cards. This is because you can use a blank card, or more often a sticky note to represent them.
For each map, you need to create a structure that can be easily understood at a glance. For many maps, it makes sense to name the card by the outcome. Geographic and route map elements have their name, but those names can also be outcomes. For example, if I want to go to Budapest by car, the outcome is getting to Budapest. All I need to do is find the map element name Budapest to use the map.
In the next chapter, we will use sticky notes to represent cards, as they have many advantages. Movable, easy-to-rearrange cards are vital in the early, ideation phase of a product. Fortunately, our vision is clear, and we cast our priorities into stone in a totally non-agile way. Please don't try this at home, and always maintain flexibility in product management and in life. However, for this demo, it's okay to draw the cards on the paper.
For each card, we also want to add a short version of the requirements associated with the outcome. For multi-user, multi-platform, or multi-channel cards, we want to add those classifications. As our map is only aimed at cat-sitters, it's pointless to define the cat-sitter user group.
The last step is adding a title. Usually, you want to give your maps a meaningful title. I have seen digitally created maps with titles ranging from "Untitled" and "UXMap" to the URL of the site. Needless to say, all those are terrible choices. People who are not familiar with the process used to generate the map should know instantly what it is describing. Titles are also helpful when distributing the maps to the wider organization to get buy-in.
In our example, “How to make a cat happy?” will do the trick. I add the "Opportunity" to the title, if that can be spelled out with simple and short words. If not, then you might need to think a bit more about your opportunity. Remember that now you need to discuss this with your main stakeholder, the cat-sitter. You need both the map and a conversation to solve a problem. In the following chapters, we will see business situations and get into facilitating the conversation using the map, but this chapter's examples stop at the finished map:
