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.)
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 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 assumed that 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.
In my experience, companies who still work based on burdensome requirements documents have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, my mobile rang. The IT director of a well-known Hungarian eCommerce site was calling, seemingly in distress. The summary of the call was that they created a new responsive website with new design and information architecture. Now, it’s been live for two weeks, and our sales plummeted, especially on mobile. That was odd because the site was not responsive before. Why the call on Sunday? It was because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased third party.I got the documentation and opened the site. There was a sitemap in it, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled "Sitemap". Although the other link titles were in Hungarian, this one was in English. This link led me to the
sitemap.xmlfile. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but far from ideal for humans, it just looked gibberish.The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard-to-read labels under them. Category names were long, and the designer made sure that they would not ruin his nice design. The documentation was followed to the letter, but the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.
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.
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.
Most of the time you should start mapping with the opportunity. It’s important to initiate the discussion and the map with something positive and impactful. It also helps you focus on the goal, and grabs the attention of your conversation partners from the first minute. This is also why the first sentence of this chapter is, “In this book, I will change your life”.
If you have an idea and opportunity, grab a piece of paper and a pen, and you can start drawing the solution.
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.
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.”
Arrange the possible things in the descending order of importance. This is the first and most crucial step of creating a successful product backlog.
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 thatthe 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 enough 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.
When creating backlogs, you can use the Three R format, so each item will include the Role, the Requirement and the Reason. This can be templatized as: As a _____ [role -> persona], I want _____ [requirement -> output], so _____ [reason -> outcome].
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.
Setting priorities right usually means the difference between success and failure for corporations. A famous example is from the summer of 2002. Sergey Brin and Larry Page, the founders of Google, were about to sell their company. Yahoo's then-chief executive Terry Semel refused to pay three billion dollars for it. At that time, search was clearly not important for Yahoo. Of course, it's easy to pass judgement on them in 2017, knowing that Verizon acquired Yahoo for less than five billion, while Google is worth about 500 billion dollars. The web was vastly different 15 years ago. Semel couldn't foresee how it would evolve. Continuing the story, in 2006, Yahoo had a different company in sight: Facebook. Mark Zuckerberg turned down a one billion offer, but some reports suggest that Facebook's board would have forced him to sell if the offer had been increased by only 10%. Yet again, Yahoo's CEO refused to increase the offer. Although Semel approached both Google and Facebook with an acquisition offer, both offers were too low. Money and other resources are allocated based on a priority list. For some corporations, investing in the future is not high on the priority list. History suggests that those companies, such as Yahoo, Kodak, or Blockbuster, perish within a decade. Even if you don't run a multi-billion dollar corporation, you should always think about the future, embrace change, and set your priorities accordingly.
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.
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.
If you draw two boxes or place two cards, one above the other, then people assume that the one above is more important. Horizontal alignment usually represents progress, so placing a card to the right, usually means something happening after or as a cause. This is only true where left-to-right writing is more popular and not as obvious as a vertical placement. So, for horizontal layouts, use arrows to reinforce the meaning.
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.
When creating a title for your map, try to find something that the stakeholders can relate to. Something that stops them in their tracks and starts user-centric thinking based on the subject.
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:
This map is also an example for cards not needing well-defined edges. It's customary to draw a rectangle or use a sticky note as a card, but sometimes it's not needed. I could have added a thin border around each card, but it would have added only visual clutter. As you can see, just a few words on a paper can form a map.
In the next section of this chapter, we will draw the same map with well-defined card boundaries, and more importantly using digital tools instead of free-hand.
Drawing by hand is great fun, and all maps in the book can be done with pen and paper; each chapter will show you how to do the map with software. Digital tools will result in easier to edit and more readable maps while sacrificing the handmade charm. If you don't intend to sell your maps on Etsy or eBay, but use them as a communication tool, then digital might be the way to go.
I will use different software, my personal favorite for a map type. This, of course, doesn't mean that you need to use that software. This book is not intended to be a tutorial for any of those software products, so just use what's the easiest for you.
Always use the software you are the most familiar with for mapping. You want to focus on the users and the message, not on quirks of the software you are using to map.
In my eight years as a people manager, the most frequent software product I have seen in CVs is Microsoft's Office package, more specifically Word. Although Microsoft Word is rarely among job requirements for a UX job, most people will know the software at least to a basic level. Although people have Word installed on their machines and use it to write shorter or longer texts, most people would not think of it as a User Experience Mapping tool.
A few years ago I told a junior UX-er to do a simple journey map. She was new to UX, Adobe Illustrator, and most other software, but had a great attitude. I asked her what software she knew. She replied with “I have used Word to write my papers during Uni”. She thought I was joking. When she realized that I wasn't, she jumped into the task. She did a good job, but it took her quite a bit, as she used a wild combination of special characters, tabs, and shapes. Then, I realized two things. First, that SmartArt is not something you can assume people will know about or use. Second, more importantly, you can do anything if you have the right attitude and approach to work. Skills come second. I could teach her User Experience Mapping in a few weeks, and I will try to share my knowledge with you through this book. What is much harder to teach is attitude and approach to work. (By the way, the heroine of our story is now the senior UX designer at a successful start-up, and she found real joy in researching users.)
On the screenshots, you will see Microsoft Word 2016, but you can use older versions to achieve similar effects. I will not use any feature new to Word 2016. I will use the Windows version, running on Windows 10. Again, you can use the Mac version to achieve the same look and feel.
To create our journey map, launch Word and
Insert a SmartArt Graphic from the
Illustrations group, selecting
In the following choose a SmartArt graphic dialog box, click on the type and layout that you want. There are many types available, but for our mapping purposes,
Process seems to be the best starting point. With that said, please experiment with other types too.
For now, let's just pick
Choosing a SmartArt Graphic
Now, we can add our textual content. For this demo exercise, we will not specify user groups, just as we only intend to target cat-sitters. To add text to SmartArt, we can use the text pane. If it's not visible, you should click on the control button (that usually looks like a "
Once you are in the text pane, simply type in the text. Each top-level list item in the text pane will create a card as a map element. You can even copy and paste a list. If you press Tab, you can add sub-elements; those will be shown on the card as a list:
Remember, for each map, you need to create a structure that can be easily and quickly understood by a miscellaneous passer-by. For our map, it makes sense to name the card by the outcome.
As the second level, we want to add a short version of the requirements associated with the outcome. Pressing the Tab key at the beginning of the line will enable you to make a first-level item a second-level item, pressing again will make it a third-level item, and so forth. Pressing the Backspace key at the beginning of the line will decrease the level, making the second-level item a first-level, for example:
Adding text to different level items
At this point, you might realize that the
Basic Process SmartArt type might not be the best for our map, as one card is not the result of the previous card, but they are all needed to make our cat happy. Fortunately, you don't need to recreate the SmartArt. You can change the type on-the-fly from the
Layouts selection in the
Design tab, as follows:
Deciding the design for our map
When you hover over different layout types, you can see their effect on our map, while clicking on one commits the change of type. For this map, arguably the best type would be
Vertical Arrow List. All of our efforts should lead to fulfilling the opportunity, and they are not necessarily a result of the previous card's fulfillment. You can easily give food and water at the same time, no need to wait until the cat finishes drinking before you put down the food bowl.
Same as with the hand-drawn map, vertical placements of a color can be a good representation of importance here. Remember, if you draw two cards, one above the other, then people assume that the one above is more important. What's easier to do digitally is to gradually add tints of a color to highlight importance. A tint is the mixture of a color with white, which increases lightness. This means that the most important box will be the pure color, without white mixed in, and we add more and more white as we go down the importance scale.
To do this, Office has an easy solution. Just go to the
Design tab and select . There, you can find the gradient range of your chosen color. I have picked green because it is often associated with safety or the most important outcome. Moreover, it has a strong emotional correspondence with life, health, and clean environment. It is also the most restful color for the human eye. Another fun fact here is that cats don't see colors like we do. Reds and pinks appear greenish to them, whereas purple is just another shade of blue, but they can see shades of green similarly to how we see the color, according to Nickolay Lamm (http://nickolaylamm.com/art-for-clients/what-do-cats-see/):
Changing the color scheme
You may find it odd that we started with the opportunity on the hand-drawn map, but not digitally. The main difference is that we are using the hand-drawn map as a guide for our digital map. Therefore, we know the opportunity and it's always in our focus, even if we haven't added it to the map yet, but now it's time.
Although you can add shapes inside the SmartArt, sometimes it's easier to add another SmartArt or Text Box next to it. To do so, we will start with resizing the SmartArt, so there is space to the left. In parts of the world where left-to-right writing is more common, it makes sense to add the opportunity to the right-hand side of the page. To resize the SmartArt, move the mouse cursor over the SmartArt's left edge. There should be a dot in the middle when the SmartArt is selected. Click on the SmartArt if it's not selected. Now, the cursor should turn into a double arrow, and you can start dragging it to the left to set the size. Most drawing elements in Word (and other software) can be resized the same way:
Resizing the SmartArt
Changing any element of the SmartArt is simple and intuitive. Just click on the element, and set the option in the
Format panel. For example, I changed the text color for the second-level elements on the following screenshot to better match the rest of the map. This step is, of course, optional:
Customizing the elements
After you finish formatting your SmartArt, we will add the "Opportunity" as a
Text Box; you can find that in the
Text group. You can choose a
Simple Text Box and format it later:
Now, you can move the Text Box to the right location by dragging and dropping with the mouse. Then, you can resize it by dragging the dots on the edges to make it the right size:
Optionally, you can change its appearance by selecting one of the
Theme Styles or by manually setting your
Shape Fill and
Shape Outline colors:
Now, you can rotate and add the text for our Opportunity box. If you want, you can rotate the text from the
Format Shape panel (
Text Options |
Text direction dropdown):
Rotating the text
The last step is adding a title. You can type in a title as your first line of text in the document. Remember, when creating a title for your map, try to find something that the stakeholders can relate to. Something that stops them in their tracks and starts user-centric thinking based on the subject.
How to make a cat happy? was my choice, because it introduces the "Opportunity" with simple and short words. Format the title to your liking and publish the final map by printing it. Don't forget that you need to discuss this with your cat-sitter. Both the map and a conversation are needed to solve the problem. In the following chapters, we will delve deeper into facilitating the conversation using the map, but this chapter stops at the finished map:
The finished map of the previous section summarizes the most important discovery of this chapter, User Experience Mapping is a technique which will help you to understand the users, gain strategic insights, and improve communication. Most problems can and will be solved with improved communication, which can be done by achieving shared understanding. The best communication method for shared understanding is drawing a map.
Before you start mapping, you need to visualize something implementable and create a backlog (list with the most important outcomes) to achieve the opportunity. When creating backlogs, each item should include the role, the requirement, and the reason. (To refresh the mapping lingo, the outputs are products of the map’s usage, whereas the outcomes are the results. 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 should start the map with the opportunity.)
This concludes our introduction to User Experience Mapping. In the next chapter, we will have some fun with sticky notes and learn to create User Story Maps.