The Power of Visual Maps to Foster Cross-discipline Collaboration and Team Alignment

Laura Dantonio at UXDX Community: Visual Maps, Healthy Designing and Creating Optimized Teams. Video: https://youtu.be/_VE027bHByY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction

[00:00:00] Hi everyone. Thank you so much for having me. It's a pleasure, and I actually think that the previous talk is quite related to what I'm talking about, because it's how we make sure that a team is aligned and works together towards the same goal. In this talk I'm going to share a series of visual maps that I've used in the past to ensure that a team works together, especially across disciplines.

[00:00:30] Just a few things about me first. My name is Laura Dantonio. I've been in the UX industry for the last 17 years, and I've worked for different sectors: telco industry, publishing, and finance. Specifically when I was at Elsevier, I worked for a team of about 50 people. That was one of the biggest teams I worked for, and with different disciplines, about ten disciplines working together: product manager, back-end and front-end engineer, tester, data scientist, analyst, UX researcher, visual designer, UX designer, strategist, and agile manager. A really different set of approaches that came together on a unique team.

[00:01:36] What I understood, based on my experience, is that the collaboration of a team and the team alignment was of paramount importance, and the way I approached and supported collaboration was by using visual maps.

Why cross-discipline collaboration matters

[00:01:55] But first of all, let me start off by saying why collaboration is important. Simply because we can do so much more if we are together as a team. Alone we can just do so little. And what's also important is that we collaborate across different disciplines. Why? Because we can have better results in terms of solutions.

[00:02:30] But it's also becoming important in the time that we're living in. Why? Because the problems that we're solving are more complex, and so we really need to bring different people with different points of view together to bring their own expertise. So we cannot get away from collaborating across disciplines.

[00:02:54] Another point that's important is that once you have different people together, you have a team, and what is important is to make sure that they have a unique vision. They know what they're aiming to do. That is because a team that is successful is a team that has many hands and one mind. They have a clear vision. They are aligned on what they're doing and why.

Why it's hard: the tree swing

[00:03:30] But why is it complicated? Why is it hard? There are many reasons, but the most important one I want to mention today is that it takes time to collaborate across disciplines, because each discipline has a different way of communicating, different vocabularies, different tools. They've been practicing their practice for a while, and if they haven't collaborated before, they really have a different mindset. So it's important for a discipline to adapt and adjust to a different way of thinking. They need to come together with the willingness to learn to communicate a different way.

[00:04:14] What you see here from this comic that I've shown is that often when a team with different disciplines comes together, they have in their mind a different view of what they need to do. So they think about the what. They have a different view of what they're doing. And what needs to change is that they should come together and think about how they're going to solve the problem, and have the same idea of what they are together.

[00:04:49] I want to share with you this famous tree swing analogy that is from the 1970s, that shows how different disciplines might interpret the same requirement, which is designing a tree swing. And just the fact that this picture is more than 15 years old makes me think, because it means that cross-discipline collaboration has been a problem for quite a while.

[00:05:24] What this picture shows, starting from number one, is how the customer explained the requirement, how the project leader understood it, how the analyst designed it, how the programmer wrote it, what the beta tester received, and how the business consultant described it. And you can see the other pictures, they are all different. They have in their mind a different picture of what they are doing.

The benefits of collaborating early

[00:05:57] So yes, it's difficult. But what are the benefits, and why should we bother about cross-discipline collaboration? I'm highlighting here just a few of the reasons I think are important. First of all is the fact that it saves time in the long run. If a team works together from the beginning, early on, it can eliminate a lot of back-and-forth communication or challenges throughout the process. They align on what they want to do from the beginning.

[00:06:32] It also helps to improve the communication among the team, because if they work together they are more familiar with each other's tools and style of communication, so each individual gets better at communicating among themselves.

[00:06:52] It also brings better alignment. When all the parties understand the rationale of their decisions and their points of view, it gives everyone ownership of the problem they're solving. And ultimately it helps to utilize the diverse perspectives. Each discipline brings their perspective, their way of doing things, and that helps to solve the problem and ultimately helps to create a better solution and better results.

Visual maps: the lean canvas and the opportunity solution tree

[00:07:25] So what I want to do now is share with you the way that I improved cross-discipline collaboration in my experience, and it's mainly through the use of visual maps. Why? Because they help to share and compare information. They put information out there rather than in people's heads, and they help everyone to see the problem in a way that transcends and integrates disciplinary boundaries.

[00:08:01] Something that I noticed is that all the visual maps I've used to foster cross collaboration had one thing in common. They had the problem and solution in the same map, so they were showing that connection clearly. And that really helps a team to understand why they're doing what they're doing. Rather than just having a list of features, they can see the problem that they solve and how. Like you see in this sign that I found on the web, which I thought was quite smart in that it really summarizes what the problem is, pollution, and visualizes a car, the cause of the pollution, and then shows the solution, which is using a bicycle.

[00:08:49] So the first visual map I want to share with you is a lean canvas. A lean canvas is basically a one-page business plan that helps a business to deconstruct a business idea. It's really the simplified version of the business plan model. It helps really to put on paper the problem that the team is solving. It requires you, for instance, to list out the customer problems that the idea wants to solve, with the solution, and also the key metrics. This is a tool that I've used in the past and it was mainly led by the product people, but I found it really useful to ensure that the teams come together and discuss what they are doing.

[00:09:51] The other tool that I've used is the opportunity solution tree. This is a tool that was popularized by Teresa Torres, a product discovery coach. She created this tool in 2016 as a way to help a product team streamline the product discovery process and keep track of their continuous discovery journey. The way she described it is that the opportunity solution tree is a way of visualizing how a team wants to reach a desired outcome and make sure that implicit assumptions are made explicit. It helps to align around a shared understanding and communicate how a team is going to reach a desired outcome.

[00:10:48] I've used this tool in the past. I found that it requires a coach, really a bit more complexity to get it right. But I want to highlight here again the fact that it puts together in the same image the opportunity and the solution. Opportunity is the language that Teresa Torres used to describe user pain points, so it's still a problem to solve.

[00:11:15] Here on the left side I gave an example of what I mean by an opportunity. This example is taken from the book that Teresa Torres wrote, Continuous Discovery. And it's for Netflix. So for instance, if the opportunity is to improve retention, the team wants to improve retention, and through user research you found that the users of Netflix don't know what to watch, then a solution could be user reviews, for instance. So that connection, opportunity to solution, is clear and shared among the team. And this is a visual map that you do together with your team and you continuously improve throughout the process.

Case study: redesigning Mendeley search

[00:12:04] Now I want to share with you a case study of how I used visual maps to improve the collaboration for a redesign of the Mendeley search experience. Mendeley is a tool that Elsevier owns. So this case study is not from my time at Global Relay but from my previous company, Elsevier. Elsevier is a publishing company that does tools and applications for scientists and researchers.

[00:12:43] Here, just to give a bit of context of what Mendeley is: it's a reference system used by millions of academic researchers to organize their research. They could use Mendeley to find articles that are useful for their research, and also they can save them in the library. Mendeley has a library where they can save the information.

[00:13:14] Why did we start working on the search redesign? Mainly because we were tasked to think about how to increase content engagement. The two metrics that we aimed to move were the number of views for PDFs and the add to library events.

[00:13:37] When we started to work on the search redesign, we had to create a new team, because search is a complex design problem to solve and requires a highly technical team and cross-discipline collaboration. There was a new team that was created at Mendeley, discovery, and I was one of the designer researchers that founded that team. But we also had to collaborate with two different teams, the shared service and the data platform. So basically we had three teams working together for the first time, about 21 people for one page. You see that there was a lot of disciplines coming together for the first time, and individuals coming together again for the first time.

[00:14:33] So what we did, to show you visually the project overall: in one year we redesigned the search experience. We started off with a page that looked more like the one you see on the left, which basically was a list of results. And after a year, this is what the team did. It's visually more appealing, but it also has features that support content engagement, such as the facets to filter results, an improved visualization of each result, and also a right side panel that gives an overview of the content in the search results page rather than going somewhere else, as well as autocomplete, which is not visible in this image.

[00:15:29] So in one year not only did we improve the visual representation of this page, but we also managed to improve the content engagement by 400%. It was really a successful redesign in terms of success, but also in terms of collaboration. And what I think made the collaboration of these teams successful was the fact that we used visual maps. I'm going to tell you now how I got to that visual map.

From pain points to features

[00:16:03] Of course, what was important to me was to ensure that all the teams that were working on the search redesign knew the user and their pain points. So we started off with user research, and by looking at what pain points the users were experiencing when using Mendeley. What I'm showing here is a section of the experience map that I created to summarize the user sessions with Mendeley users. As you can see here, it's quite a busy visualization, and I thought that was not something that I could share with the team and that could help us to understand what to do and what the user pain points were.

[00:17:00] So I summarized it for the team and for the senior stakeholders in something that looks like this. Especially the first part, the problem space, is the summary of the experience map. I wanted to make sure that all the team knew the phases of the search experience that the users were going through, and the pain points. So this is really a super summary that was useful for the teams to understand who the users were and what pain points they were experiencing. And what you see here at the bottom are the features to solve the pain points. The features are something that we came up with together as a team. Once everyone knew the user pain points, then we thought about, okay, how can we solve those problems?

[00:17:55] To get a bit deeper into the details: in the search experience for Mendeley we understood that when they start to search for information, even finding the time to search is a pain point. And so what the team suggested was to have saved searches, for instance. Then moving on to the next step of writing, when they actually write a search query, one of the pain points that we found out was that spelling and remembering what terms to use was a pain point. And so what we suggested to solve this problem was to have autocomplete and autosuggest.

[00:18:38] And then when they find the information, evaluating if the search result is something that is useful for them is something that takes time, to make sense of what they found. So what we suggested to improve that was highlighting the most important information that we knew was important for them through research, such as author, citation and abstract. And then at the end of the process, when they found something that was useful for them, one of the pain points was access to the PDF and understanding where to save it. And so the feature we suggested is to have a call to action to save to library and view PDF.

[00:19:26] What this map also did is it changed the view of the team about search. Everyone thought that search was a page, was designing a page. But through this map we understood that we needed to approach it as a process. We were designing a process rather than a page.

How we used the map

[00:19:55] I want to give you a bit more information on how we used it, because it's not only coming up with a visual map, but what is important is to share it, co-create it and work together, making sure that it's a live document that everyone can question and can pitch into.

[00:20:20] So how did we use this map? This map was a way of understanding the user pain points and the solution. We used it also to plan the roadmap and create the MVP, because it helped us to understand the features that we needed to develop for search. And we kept sharing it throughout the process regularly, every two weeks, every sprint, to review the progress of the team. We also used it to onboard new team members, as a way of understanding what this team was asked to do and what we were doing. And we used it to communicate with stakeholders. This map really summarized what the team was doing and made it easy for us to share and promote our project.

Benefits and lessons

[00:21:19] So what are the benefits of using this map and this approach of visual maps? What is important, I think the benefit of using this approach, was the fact that the team had awareness of the user pain points that we were solving. We were sharing the problems that we were solving, not just the list of features. And so there was that understanding and ownership of the problems. And also the connection between what we were doing and how, so the problem and the solution.

[00:21:58] The fact that we involved the team to brainstorm on solutions, on how to solve the problem, helped us to find the best way of solving the problems. It also guided our decisions to prioritize features. And it helped us to speak the same language and have a clear direction. Speak the same language, why? Because even the name that we were giving to a feature was something important, to ensure they were talking about the same feature, the same language.

[00:22:36] So the lesson that I learned here is that maps are fantastic really to foster cross-discipline collaboration, mainly because they give ownership of the problem and the solution to the whole team and create that vision. They create alignment and shared vocabularies. And also it's not just about creating the map, so what you put in the map, but how you use it. It needs to be a live document that you keep sharing and you involve people in the creation of.

[00:23:13] So my suggestion on how to foster cross-discipline collaboration and team alignment is to create maps that have a clear visualization of the pain points and the solution. Co-create whenever it's possible, involve the other people, facilitate the discussion, share it and review it often throughout the process. And that's the end of the talk for me. Thank you so much. Let me know if you've got any questions.

Q&A

[00:23:43] Host: Excellent, thank you very much. I'm always a big fan of visualization of things, because I've had that problem of people with the different bubbles with the different visions of a chair. I've had that happen so often.

[00:23:59] Host: And I did love the quote that I loved the most in your talk, which was, we weren't designing a page, we're designing a process. I think that's something that is so relatable to so many people out there, because often you think you're just designing something small, but it's actually how does that feed into the user's journey and how they're going to use it.

[00:24:21] Host: One thing I have a question on, and please do, if you have any questions, please do write them in either on UXDX or whichever channel you're watching this through. But my question to get things started is around the longevity of these maps. Let's say you're working on this feature, what happens next? You have this map you've done, do you archive that somewhere? Do you leave it available for people? And how do people keep track when you're on to feature 20 or whichever?

[00:24:53] Laura: Yeah, no, that's a great question. In the case of the case study I shared, basically we used that map until we completed the features that were present in that map. And so that was the longevity, until the plan was done. But in this specific case, after we did the Mendeley search redesign, I...

[00:27:59] Laura: It was really the minimum bare information there, and it almost asked for information. And so it fostered that collaboration: what do you mean by this? What do you mean by that?

[00:28:11] Host: Excellent. Well, thank you very much, Laura. I found that really useful. I hope people out there did as well. So thank you for sharing your insights.

[00:28:21] Laura: Thank you. Thank you for having me. Bye-bye.