 creating a vision. My name's Kyle Walker. I am an interaction designer at Red Hat. I've been working in open source and software only for about the last year when I joined Red Hat, but I have been a designer in working on enterprise solutions in hardware actually for 15 plus years before that. And I am happy to connect with anybody afterwards. And my name is Sarah-Jane Clark and I go by SJ. I'm a user experience researcher at Red Hat. And I've worked in the enterprise IT industry for pretty much my entire career. So I feel like I know the space pretty well, but I'm still learning. And I'm always on the lookout for good study participants to always recruiting. And I'm a natural born ringleader, which is why I was attracted to this journey mapping project. So the goals for this presentation, first we want to help you learn when to use a journey map, how it's best to implement this with a group, when to use this as well, and then making sure, because if you create this, you need to also make sure that you can share it with everybody else. So how to parse that data and then come up with a plan to move forward from there. And the exercise that we did and that we will share with you was done in the before times, back when we could be together in the same room. And obviously that's not going to work these days. So throughout this presentation, we're going to give you some things to think about and to consider if you would like to do this activity remotely. So keep an eye out for the Zoom icon for recommendations on how you might conduct this online. So why do we need to do a design exercise in the first place? What we're working on as a team is to redesign a tool. This is a tool that we've has been around for about 10 years and we're redesigning. It's used to write and then to deploy business processes. This tool was taking a, was a one large tool and breaking it up into different sections to make it flexible to meet users where they are working rather than making them work. But this created different access points and different parts of the processes as you're going through and creating what you need to create in this tool, which led to what we were worried about anyway being a disjointed and unclear user experience. So we needed a design exercise to make sure that we could make it a cohesive project vision. So from there, there was a vision for the product but it was developed by people with different expertise working in different areas. So they were looking for one complete vision to make sure users would have a clear path to success. So being able to go from creating to deploying their processes, along with that, we had in our own UX team had assumptions about users that were seemed to be slightly different from those in the engineering team and other stakeholders were mentioning. So we wanted to make sure everybody on the team had a clear understanding, get everybody on the same page for what terms you're using for the users who we thought those users were and what their capabilities were as well. All right, so once you have your goals decided and your questions decided, now that's when you wanna select the method. And it kind of made sense to me that what we were trying to discover was what the workflow was. So it seemed like a journey map was a good option for this. So a journey map is a visual representation of the process that a user goes through, the steps that a user does to accomplish a particular goal. And a journey map can be as simple or as elaborate as you want it to be. At minimum, you need to document all the steps that the user is doing, what their goal is, and keep track of who the persona is. You can layer any amount of information that you want on top of that, anything that will help you answer your question. So if it's important to know what the user is thinking or feeling, that's a layer you can add on. If it's important to document the business processes, that's something else you could layer on. Really the sky is the limit. Think about whatever you need to know that will help you reach your goals. In terms of whether this is a good option for a group exercise, there's a few things I would encourage you to think through. So first, this is not a good exercise for a group that doesn't get along very well. It's a very collaborative exercise and there's a lot of discussion and back and forth. So if the team doesn't get along well or is kind of shy, this is not a good option. If you need to work with folks that you don't know or who don't know the topic very well, this is gonna be difficult for them to contribute. So you need folks who really know the space or at least have a good enough understanding that they can feel like they're participating in the exercise and be part of the discussion. As far as doing this online, there's some tools later on that we will recommend that you can use to help collaborate when we did this in person. It was in a conference room with lots of whiteboards and sticky notes and sharpies, but there are tools available that will approximate that experience online. We'll share those later. So once you have an idea of what you're doing, you obviously need to identify your participants. So what we started with was identifying those stakeholders and SMEs or subject matter experts. These are people within the community that are familiar with the content and have a stake in how the design will turn out. So that's engineers, architects, users, if that's at all possible, that could be helpful as well. So once we started to identify those people, we wanted to interview them ahead of time or at least some subset of them ahead of time just to get an idea of what they're thinking, kind of get ourselves a baseline of where this whole process might start and have an understanding for ourselves of what their vision of this process is. And this also helps to populate some of the stickies, some of the ideas ahead of time that you might want to put in there. While we're doing that interviewing, we wanted to make sure we were asking consistent questions between the different participants. This helps to make sure that you're getting roughly the same answers or at least the people are answering the same questions, which can help you, again, get that general understanding and have that baseline. You're gonna ask everybody a different question and you might get different answers and if you plot them on the same place, they're gonna be, it could be wildly different. So when you're planning the workshop, you want to send an agenda. Of course, it's important to let folks know how they're going to spend their time, but I think it's also important to briefly explain the exercise that you're going to do. This is kind of a design exercise and designers are probably used to working this way, but other folks who might be attending may not be so familiar and might be more comfortable if they knew how the exercise was going to go. So just give a little explanation, send a link to a blog post or some photos, just something to help them become familiar with the exercise. Also invite the group to contribute additional questions. So as Kyle said, as you're working through the interviews and discussing with folks what they want to know, some questions may come up later. So just give them the opportunity to contribute those questions so you can adjust your exercise if you need to. Definitely feel free and prepare to go off script. So the best laid plans, they can go off the rails very quickly. And you'll see later on, I'll give you an example of how that exact thing happened. So it's really important to know that this can happen and know that it's not a problem. We are not coming together to create the perfect journey map. We're here to answer questions. So if you can be flexible and kind of go where the discussion takes you, that's where the really interesting ideas and creation comes to life is in those conversations. So in advance, kind of take a look at your schedule and just prepare yourself mentally for how much time you're willing to allow this conversation to go on before you kind of have to gently nudge people back to the topic at hand. You want a good balance between the time that you have available and letting this free flow conversation happen. And I'm always going to encourage you to test your logistics in advance, particularly if you're using online tools to do this exercise. So if you're using Zoom, if you're using online whiteboards, get two or three of your friends together and test that out because on the day of, that's not when you wanna be trying these things out and finding it didn't work as expected. So speaking of the day of, so we started the meeting. Ahead of time, we wanted to present the plan. This is before lunch and then after lunch we're gonna do the exercise. So we started presenting the plan, talking about the questions that we had asked in the interviews and the answers and what we had come up with based on that. As we're presenting this, we were told that what we thought the flow was and what we thought our exercise was was wrong. The steps were not right, the people were not right. So it was kind of a, whoa, okay, that's a big deal. So also along in this meeting, there was discussions around the technical savviness of the different personas. So we discovered that, as I mentioned in the beginning, we had ideas of, we wanted to make sure that we in UX understood and had the same feeling about who the users were as those on the engineering team and the architects. What we found out during this meeting when we were having a discussion is that not only did we maybe not have the same understanding between UX and engineering, but the people within engineering didn't have the same understanding of who the users were. So this became a much larger question and a much more important question to answer during this exercise. So as a result of all this, it was really helpful that we had our goals ahead of time because they allowed us to be flexible and to figure out different ways that we could still get to those goals because we still needed to understand who the users were and we still needed to have an end to end flow and understand how users are gonna use this product or project from start to finish as well. So those two goals still allowed us to have a little bit of flexibility in what we were doing. So to address this kind of misunderstanding or misalignment on the personas, the design team gathered over lunch and we put our heads together while we were eating sandwiches and salads and everything to figure out how we could address this issue because it did seem to prevent us from moving forward. This was a longstanding issue with the team just to be clear. This is not an issue that came up during this workshop. It just kind of surfaced during the workshop as an issue that just it would not allow us to do the exercise as we intended and we would not have come out with anything productive at the end. So we really needed to figure out a way to address this problem. So as we're eating lunch, we decide to more or less fundamentally change the workshop exercise to help us get to the bottom of the situation. And what we decided to do was as we were mapping out the workflow, so mapping out the steps, we were going to have the workshop participants decide or identify which persona they felt was doing the task at the time. So this is kind of putting, design could have decided, we think this persona is doing this task, but we wanted to put it back on the workshop attendees to have them say who they thought it was. And hopefully we would see patterns and ways where they diverged. And that would help us figure out where the root of the issue was and to create some discussion around that. We wanted to have folks talk about why they thought a business analyst was doing this task and why some other folks thought a developer was doing this task. Why is that different? Let's talk about it. So when we went back in to the session, we told the workshop attendees that we were adjusting this and everybody was on board. It added a little more work to the exercise, but you'll see it definitely paid off to kind of do that in the moment shift. It was a little nerve wracking. I won't lie at the time to do that, but as Kyle said, if you have solid goals and you have planned ahead for a little bit of flexibility, we were able to adapt very well, I thought. So in the workshop, again, this was in the before times before COVID, so we were able to be together. And we were in a conference room together with lots of stickies, lots of Sharpies. So we wanted to make sure that everybody got a pad of sticky notes and some Sharpies. This is an inclusive exercise and we want to encourage everybody to participate. If you see some folks who are maybe kind of shy or don't know how to get started, encourage them a little bit, maybe talk to them to get some ideas flowing, but don't force it. You don't wanna make anybody uncomfortable, but maybe once they see some folks starting to put their ideas on the board, they might get into the flow of it. I would also encourage you to write your own stickies and your own ideas and put them on the board as well, even if you had intended to just be the moderator. If you know the space and you know the domain, add your ideas, that can also encourage other folks to participate or to question or to create some discussion. As you see some of these ideas and sticky notes being added to the board, you may wanna get some clarification from them. You might say things like, hey, this is an interesting idea, can you tell me a little bit more about it? Get to the clarity, get to the real understanding of the sticky note. It's a small piece of paper, it's a three inch by three inch piece of paper, so it's hard to put big ideas. And if you need to write out other sticky notes to clarify, that's great. But clarity is the goal of the exercise. And you definitely want to do active listening. So you want to say, I think I heard you say and kind of repeat back and give the person the opportunity to kind of refine what they said or to expand on what they said. This is definitely an ongoing exercise where there's a lot of back and forth and discussion and collaboration. So definitely prepare to listen and participate in the conversation. If you're doing this online, we've linked a couple of whiteboard options here, which is a good way of approximating the experience of being in the room together. And it lets everybody log in and contribute together to the same board. So after the exercise is done, everybody has added their sticky notes. You see a lot of sticky notes here. This was a really good exercise that everybody contributed. This is when you want to go through and kind of expand on some of these ideas. So as a moderator, you can go to the board and kind of read them through. You'll want to start arranging them into themes. So if you see sticky notes that are very similar or related, you can start rearranging them and putting them together. Be careful not to move them out of the category that they are in, but start to group them within the same category. And this is also where you want to, ask those clarifying questions. Read it out loud. Say, I think I understand this to say and say what you think it is and invite whoever wrote it to add to it or to expand on it. Now you don't want to call folks out specifically. You don't want to say, hey, John, this looks like you're handwriting. You want to tell me what you were thinking? Just read it out loud. And if somebody wants to identify themselves as the author, they'll speak up, they'll talk about it. And if not, then you've opened it up to the group for conversation, for general conversation. And then this is also where the discussion happens. So this is another thing to keep an eye out for as a moderator. In this particular group, we had talked earlier about how there was some, you know, misalignment and disagreement about who the actor was, who the persona was for these sorts of things. So encourage the discussion, but keep an eye out too for when it starts to go down the rabbit hole. You don't want this to become, you know, a big spiral downwards. Let it go for a minute or two, keep an eye out and then gently bring people back to the topic if you need to. As you see here, we broke out the map into two rows. So the first row, the top row here is the developer and the bottom, oops, gosh, my bad. And the bottom row is the business user. And these were the two personas that we wanted to track. And as you can see here, there were sticky notes in both of these rows and it really helped us to clarify who the actor was. And it really helped the group as a whole, kind of a line on who is doing what and when. Right, so once we have the exercise, really it was a lot of fun, it was really good. We had some really great discussions in that exercise. After that, we need to move forward. We need to get somewhere else from that. It does no good to do this exercise and then just have it be done. Like, yeah, everybody had fun. We need to take those insights and then create a plan going forward. So that's what this part is. So we started by, one to two days later, F-Revolve had a chance to decompress, start by reviewing everything within the UX team. So this is looking at all of the stickies, writing them down, making sure we all have a shared understanding within our own UX team of what they all meant. The conclusions from the exercise as well. And then taking those stickies, taking those ideas and putting them on a whiteboard. Again, obviously this is kind of, the before times, as the state said. So we did it in person in a conference room, but you can use one of those other whiteboarding techniques programs to do this virtually as well. But so this is taking out everything, putting it on the board, connecting dots. Where does this one process connect to this other section? And drawing those arrows all over the place, as you can see in that picture of the whiteboard. So you wanna, then once you have that drawn, you need to be able to communicate this back to the team. So picking the tool that is gonna be able to show this flow that we identified with this journey mapping exercise. Using that, in this case, we used a workflow tool. So you can see all of the places of entry points, all of the exit points where the arrows connect is where it's an easy transition or an understandable transition to get from one place to another. If the arrows don't connect, then, oh wait, we have a problem. We need to figure out, we need to help the user understand where to go next. So using different colors and graphics to represent the different sections of the workflow. So we had those, each of the different sections in the journey mapping exercise. So we can show those different sections by using color in this case. And then using graphics to represent the users, so we have little pictures of, which representing the different types of users that are using this project. Using those together to kind of create this cohesive vision. You can see that down on the bottom left. And this is creating the graphics that help explain what we went through in this exercise, what the user is gonna go through while they're creating this. And once we have that map that we drew, that we now have a shared understanding in UX, we reviewed it with a couple of stakeholders, not with everybody at first. Some of the stakeholders that we identified in the meeting and in the interviews as having a more active role in helping to guide where the program goes and having the clear ideas where they thought things were. So we identified, we worked with them, we showed them, okay, here's where we think the gaps are. They said, okay, we didn't see that gap or we had an idea for that already. So we added that in notes to add more depth to that map. And then once we have that discussion and where we had gone through that and understood where we thought their understanding was or what we thought the understanding should be from a user perspective, then we presented the whole full flow back to the team. We had a meeting with everybody that was in the journey mapping exercise. And we presented the full plan. So from this, we were able to identify the gaps in the process, making sure that users could get from one section to another. Excuse me, we, sorry. Using those gaps, we created issues so that we can track and focus on developing solutions for those and making sure that we can create that easy understanding for the user. And to this day, the team actually still goes back and references this happened to have an eight months ago now. The team is still referencing this periodically to show what the vision is for this product and where we need to focus and where the team needs to focus to create the best vision going forward. So takeaways from all of this. You need to have that well-defined goal at the beginning before you start anything, making sure you understand what you're trying to create, what you're trying to get at from doing exercise or from doing all of this designing in the first place. And then also being able to map out the information that will help you reach that goal. So you're trying to understand, once you know what your goal is, then you can understand what information you need to gather in order to get that goal and use this exercise to do that. And in your workshop, you want to, or before your workshop, you want to prepare and have that plan be ready to go. Things happen, humans are humans and you want to be ready to shift if you need to. During the discussion and during the workshop, as the moderator, listen for cues, that things need to get a little clearer or need to have a little more discussion. You'll know what those sound like when you hear folks asking questions or even worse if they're silent when there's some discussion going on. This should be collaborative. So keep an ear out for these things that need a little more work. And finally, doing this as a group, whether it's in person or online, can help create empathy for the users, which is always important, but also for parts of the flow, the workflow that they may not otherwise see or interact with. When we work on product teams, sometimes you just work on your own little piece of it and you never really think about what it's like to work with these things from end to end. So this sort of exercise helps expose folks to what it's like to do the entire flow, which is always great for creating empathy and creating those connections between folks. Thank you. Thanks for joining us for this. Feel free to reach out with any questions or thoughts afterwards. Thank you. Very much, Kyla and S.J. I think I was muted there. Audience, feel free to post your questions in chat. And Kyla and S.J., if you also wanna join, share your audio and video, you can also do that. Hey there, thank you for the amazing talk. Oh, thank you. You're welcome. Now it's fun to go back through that and think about all the things that we had done, really at the time when you're doing it, you think, okay, well, that was good work, but when you start laying it out in all the stuff that we accomplished, it was really, it was an interesting story to kind of think back through. Well, I wanna confess I've never done journey mapping and I'm very new to UX, but this was really amazing. Like it was very clear for even a newcomer. So thanks for that. Great, great, glad to hear it. Yeah, it was definitely my first time doing journey mapping as a group. I've certainly done it myself or maybe with one other person to kind of understand a workflow or essentially whatever a user is going through as they're passing through an experience, but doing it as a group, that was new to me. And it worked out, it worked out. Yeah, it was a very dynamic group at that too. That's amazing. I wanted to ask how did you folks decide on this topic? Is this something you work on in your day-to-day jobs or did you just, how did you come up with this idea? I mean, I wanted to give a talk at DevCon it was one of my goals for the year, honestly. And I kind of went along with, what did I do in the last year? What could I talk about? And then I remembered, we did this, SJ and I and a couple other people on their team and I just thought, hey, maybe that's a good story because it's got the, everything changes in the middle. But the plot twist in the middle is what sold it for me. That's amazing. We may have undersold it a little bit, but it was a very panicked moment to try to be eating a sandwich and on the fly, really coming up with a way to answer a question that just so fundamentally blocked us. Just, we had this day to get this one day together and if we couldn't figure out a way around this one thing, the whole rest of the day was gonna be a waste. So it was just, it was a very high pressure moment and very memorable. So for me, that was the real story that I wanted to share. Yeah, for me, it was the first time I met pretty much everybody in the room. So I was at Red Hat for six months at that point, but I just, I talked to some people, on the phone, but that was about it. Well, thank you for sharing experiences. I think talks which come from like real experiences are the best, I guess. More than theories, more than concepts. I find these to be most interesting. Yeah, I agree. I'm glad you found it useful. Thanks. Thank you. I don't see any questions in the chat. Maybe everybody's got everything. They certainly have our contact info if something comes up for them later. Yeah, absolutely. I'll also post a link to the breakout room here in the chat. So if anybody wants to catch Kyle or Eshi after the session, please feel free to do so. Sounds good. Great. Thanks so much for moderating. Thank you. Thank you.