A UX veteran of 19 years, Malini Rao has designed product experiences for diverse organizations–giants like Siemens Medical Systems and Oracle; Technology leaders with a cult following like Red Hat and also smaller and nimble organizations like Acquia and Ipswitch.
IA Summit 2015 Main Conference Talk
Topic(s): experience mapping and user research
Do you struggle with getting enough knowledge about the user and context of use before beginning your information architecture and design projects? Are you dealing with copious notes after conducting your contextual inquiries, interviews? Wondering where to begin in trying to parse the learning into insights about the problem; ideas on how to solve them and also identify what gaps in knowledge must be filled with future research or expert interaction? Reality Maps maybe just what you need!
Reality Maps are a lean method of collaboratively modeling a scenario of use and gather insight in the form of comments, questions and ideas in a quick and tangible visual format with the use of color coded sticky notes. This technique offers the ability to process multidimensional insights such as observations, ideas and questions within one activity and derive meta-insights to inform design and vision.
Come learn about this technique and see how it can creatively be used both as a research/analysis tool and a collaborative design tool. Check out two real word case studies from widely different places like Oracle and Acquia where this technique was used to meet completely different analysis goals.
Hear from a seasoned user experience professional that has tried, tested and tweaked many techniques and methodologies in her 15+ years of design practice. Design is about solving problems creatively… Sometimes we have to be creative in helping ourselves solve those problems as well!
Malini Rao: To get my talk started today, I want to start with a question. Are you ready to set yourself free? Yes, I am talking about the self-imposed restrictions that you may have placed on yourself in your design practice. This talk is about letting go of some of those restrictions and thinking of your design practice in a more flexible manner.
I am going to try to do that by introducing you to a technique called Reality Mapping. Then talk about how we can get creative with its use, to warm you up that idea. We are surrounded by many common tools at our disposal. This is about using them creatively, flexibly and also without guilt.
Perhaps, adapting them in ways and using them in ways that they were not originally meant to be used, but all to serve your specific purpose, because in the end it’s not so much about the tool or the technique, it’s about stimulating thinking, about ways in which you will meet your end user needs. It’s about taking inspiration and potentially bending some rules in order to get the job done.
Too many times in the corporate setting, we tend to shy away from the use of our repertoire of design and research techniques because we think that we may not be able to do it just right. This is because we don’t have the time to be comprehensive or to be academic.
So let’s not be. Let’s be flexible and lean in these activities and then move the agenda forward in the right direction. In a manner that is more considerate and better educated.
Talking about familiar tools, most of you must be familiar with the technique called “Customer journey mapping.” You must be was wondering if this is the same. Both of these techniques share many similar attributes and both of them are able to identify design opportunities at various levels, but they’re in fact not the same.
Customer journey maps are a great communication tool to outline the phases in your customer or users journey, across various touch points, all the time keeping a pulse on customer satisfaction levels.
Reality Maps on the other hand are a great research, and collaborative research and analysis tool that help you identify the various steps that a user takes, in order to achieve a certain goal with your tool or service. Usually, this is constructed together with a representative user. It is a recording of their current, here and now, their current reality.
We use different colored stickies to separate the tasks here, identified in the blue stickies as they’re laid down like a track. We separate the tasks from the questions in yellow, green comments, and pink design ideas. Because this technique not just allows you to identify tasks but also to enrich it with this kind of detail, this is a great task analysis tool.
It is also extremely flexible and can be used as a collaborative design tool as well. For instance, if you took the current flow and then swapped it with the proposed flow, suddenly you have a design map. This is now a non-visual storyboard with which you can discuss your proposed flows with your product team or your stakeholders.
Then all that discussion beneath the tasks is feedback or questions or ideas from your team. In this way you can focus on the tasks and the big picture in the early stages and get to sketching, much later. In that way you’re not getting distracted with the visual elements and it’s also a more efficient process.
Now, the benefit is that, this artifact is easily digitized and you can share it with remote collaborators and they are able to contextually contribute to the artifact even though their collaboration is asynchronous. In suggesting the use of a research technique as a design tool, I want to highlight the fact that the design process is not just iterative, it is also continuous.
Just because we move from the research phase into the design phase it’s not as if we ever take off our analysis hats. Yet our toolsets in these phases are pretty siloed. This is a call to change all of that and use any and all techniques from any phase or perhaps even unrelated disciplines, just so there is no break in your thinking or sharp transitions in your thinking.
To further give you an example of how to extend this technique, let me dive into my first case study, where we use the ability of this technique to tease out the rich details around tasks but also are simple adaptations to take this to the next level. Working in a large corporation, our user experience team supported the user experience for a product called the Metadata Repository Builder.
The chief persona for this product is a highly technical IT administrator. The problem that we were faced with, was the fact that there was a very low adoption rate for a bunch of functionality called the shared development capabilities. This was especially puzzling given this technical persona. These guys can solve anything.
Talking to various sources, we had discovered that the problems began at setup itself. This was puzzling, because when we looked at the tool it seemed like the setup was fairly simple. You create an empty repository. Then you import some metadata into it. Then you add some users or a team to work on that metadata. Then you create projects, so they can share the work.
What we could have done at this point, was to take these steps and talk to the people that were having trouble with the functionality and color it with the questions, ideas and comments, and it would have all been very insightful. But what we did was something different. We decided to talk to an internal group that had made this functionality work for them.
We hoped that in talking to them, we would have some ideas that we could then incorporate within the workflow and get going. We also did another thing differently. Instead of constructing the Reality Map together with a representative user, because the business group that we wanted to talk to did not have the time to spend with us to do this, we decided to do a detailed interview.
Then break it down on our own into a Reality Map and then took our outstanding questions and preliminary design ideas back to the business group and also the product team to simulate more discussion. In any case based on the interviews, when we actually broke down the findings into a Reality Map, it was quite a revelation.
This process that we thought we had for the setup was not simple at all, and you don’t need to really read this Reality Map from left to right or top to bottom to discover that. But to make things even more clear, we added another shade of blue to identify everything that was done outside of the tool.
We quickly discovered that this group had created a complex workflow, before and after what they did in the tool, for this to work for them. In order for this to be usable, we needed to draw in some of those workflows into the product. We were also able to plug in some of the user codes within this artifact in a contextual manner, and also our own notes from the interview.
For instance we had noted that this group had created an external artifact that listed a very clear ownership of all the metadata objects, so that there was absolutely no confusion. This made us wonder if the tool was letting people modify stuff that they were not supposed to? This is a question that we would take back to our product team to clarify.
We also came up with a tentative idea at this point that maybe we needed to start thinking about object level permissions. Besides this kind of granular analysis, standing back and looking at the Reality Map, you’ll also see that towards the left, you see a cluster of yellow stickies. This represents a gap in knowledge that still exists.
This is potentially when we would go back to that business group and flush things out more and those yellow stickies as they get answered, would either turn into blue stickies and up on the top as more steps or as comments or facts or ideas even. At this early stage we only had a couple of design ideas as you can tell by the two pink stickies there.
The notion here is that, as we answered more questions and responded to more of the green comments here, the greens and the yellows would transform into more of the pink design ideas and that seamlessly we would be moving from the research phase into the design phase. Now, you have your design ideas all contextualized to the reality that we are trying to improve.
Moving on to my second case study, here we use the technique to not just identify gaps but also to pool our knowledge together in a collaborative session. The product in consideration this time is a personalization tool for web content. This was a product that was organically developed at Acquia.
Because this was organically developed and not particularly user-centered at any given point in time, it was not surprising that the Achilles heel for the product was usability and user experience. We had tried many Band-Aids and it had not really worked and with a culture of failing fast and not being afraid to start over at Acquia, we decided that it was time for a major product overhaul.
With that big decision out of the way, a question still loomed in front of us. Where do we start? It seemed like none of the stakeholders had a clear grasp of what it is that we were trying to tame here. It was also evident that there was a lot of knowledge between us. So we decided to come together in a two-day meet-up and have Reality Maps come to our rescue.
In outlining some of the challenges that we dealt with in the two-day meet- up, I want to emphasize that I am going to be generalizing the challenges that we dealt with, because by no means are they unique to this product alone. Challenge one. Too many projects are kicked off without enough information about the users or how they use the product or in what context.
We don’t want to be in this situation, so we decided two goals for our meet-up. We wanted to be on the same page as a team about the current product experience and the customer experience of our product. We wanted to do this for two reasons. We had several team members that had joined in at different points in time and did not share the same historic product context.
More importantly, we wanted to improve the current product experience. To improve the current product experience really, we needed to understand the context of its use and this would give us our second goal, which was to actually identify meaningful feature expansions. Product improvement and meaningful feature expansions, those were our goals for the meet-up.
Unfortunately, we were not able to do a contextual inquiry for this project. So what we did instead was to leverage the first and second-hand experiences of our stakeholders in their capacities in the past, either as marketing professionals are in their capacities in their current roles as people that handle customer relationships and pain points.
In this way we were leveraging the past and the present to inform a fuller future vision. Another deviation that we did from the prescribed technique is that, this was not a story of a single persona achieving a certain goal with our product. Instead, this was stitched-up story of a marketing team that was planning, executing, and evolving their campaign strategy.
Assuming, you’ve done your data collection. The next challenge is you have all this insight, but it’s hard to keep the insight about users’ needs and behaviors in focus throughout your project lifecycle. That’s because it’s hard to keep a grasp on the details, when you’re thinking about the big picture and vice versa. In building the Reality Maps together as a group, we were making certain lists.
We were making lists of things that we didn’t know, that needed to be pursued in research and we were also making lists of pain points. That’s part of the prescribed technique of Reality Mapping tool, no doubt questions in the context of the tasks that you are looking at.
But this small adaptation of tagging some of the green comments here, with the sad faces that represents the pain points, it was small but extremely valuable for our researcher because these became her main takeaways to plan her usability test plans and her recent scripts around.
Borrowing peripherally Customer Journey Mapping, we also retraced the story and started to place a couple of colored dots that represented our primary personas for this product. In this way we were able to identify the flows that we had to design for one or the other persona.
Also more importantly we were able to identify where the collaboration took place or the handoffs took place, so we could address that in the redesign. Another big challenge once you do have the data to parse, it is pretty easy to make a list of granular insights that you may have collected and those are useful and have a place.
But it’s much harder to connect the dots and find those meaningful patterns with which you can have some design breakthroughs. Because the Reality Maps construct themselves and there’s a bunch of people that usually you do this with, you have more heads in analysis. Also the fact that we use different colored stickies allows for visual analysis.
Again, standing back and looking at this Reality Map. On the left you see a cluster of pink stickies there. It’s quite possible that the individual design ideas in that cluster, bubble up to become a design breakthrough. The other thing that you will notice when you look at this Reality Map here, is that the distribution of the stickies is not even at all.
If you remember when we began our meet-up we had two goals. We wanted to improve the current product experience and we also wanted to identify meaningful feature expansions. At this point in time when this picture was taken, we had clearly spent more time ideating on feature expansions than on improving the current product experience.
So this technique is not just useful to collaborate on our design problems but also to reflect on the state of your analysis. It helps you identify, where you may need to redirect your focus and time. Also, because this technique puts the whole workflow in front of your eyes, it makes it easy for us or easier to identify the various phases in the flows within these phases.
For the first time in this project for our team we were all on the same page and we were finally able to wrap our heads around this complex workflow. Last but not least, we have a common challenge of finding a seat at the table when it comes to product road mapping and strategy.
This is because most of the time we are responding to a predefined roadmap and in this process we lose many opportunities of having research insight or design vision, influence and direct product strategy. This collaborative session, this two-day meet-up at that I have been talking about changed all of that effortlessly.
After looking for patterns across the Reality Map we started to look down each of the columns and started to identify some theme. These themes became the biggest takeaways for our product manager because depending on the size and scope of these themes, they translated directly into the product roadmap. They translated as initiatives or as stories within the initiatives, depending on the size and scope.
In this way this technique became a bridge between the current reality and the future vision. So in two short days we had takeaways for our designer, for our researcher and for our product manager and because the deft leads were part of this meet-up as well and had been part of all the discussions around the customer pain points and the design ideas that we were going towards, they had plenty to start thinking about as well.
So what do we learn we learn? We learned a collaborative technique that you can use right away. We learned that this is an effective technique to distill research and reach consensus and you can also use it as a design tool. We learned that we can be as flexible as we want with the technique to make it work for us.
In conclusion, I want to say that design is creativity applied to problem-solving and most of the time that creativity is channeled in developing rich and engaging experiences for our end-users.
I am hoping this talk with the introduction of this technique and also how you can get creative with it has inspired you to channel some of that creativity into the design process itself to make it much more rewarding and efficient. Remember don’t feel guilty to set yourself free in your design process and you are the master of your techniques. Thank you.