 My name is Lajja. I'm a senior user researcher at Salesforce. And I've been with Salesforce for four years now. And in the last two years, I've been working with Salesforce.org, which focuses on building products for nonprofits and education industries. And it's interesting because when I started at Salesforce.org, I was their first ever researcher, which was very difficult because I don't know if any of you are a solo researcher, it is very hard. And don't get me wrong, I had my colleagues super excited about finally having a researcher on the team. They just didn't know how to work with them, work with me because they had never worked with a researcher before. They didn't know what to expect from my work. They didn't know when to include me in the process, whether to embed me into their team, or use research as a service. And I've seen at many companies when researchers use as a service, which basically means that there is a researcher who gets work from product team, but after that, kind of researchers are on their own, talking to customers, collecting data, putting together a report, alone in a corner like this lady. And then after a few weeks, they go back to the team with a perfectly polished report, but then this happens, the findings look good, but the development is already done. Yeah, this is from when I worked for White House and Obama is reading my research report, not true. Also things like this happen, we already knew this, but our system data says people love this. So, and after this, the report is kind of put aside, never mentioned again. And so when the findings from a good research is not utilized, it's not just a waste of time and effort, it's a missed opportunity because a knowledge that could have been used to make the right decision to reduce future risk. And I think one of the main reasons this happens is a lack of engagement. I love this quote by Lee, I'm a little bit rushing through because I have in my mind like, I don't have time, but if you think I'm just going too fast, please let me know. Okay, so you can have brilliant ideas, but if you can't get them across, your ideas won't get you anywhere. And yeah, one of the reasons why this happens is a lack of engagement with your stakeholders, which is what I'm gonna focus on today. There's a lack of understanding around when to involve UX, when to involve researcher in the process. There is always lack of time. We need to know all the answers by the end of this week. There is a expectation of not being in line, not knowing, not setting up with the researchers what the outcomes are going to be, how the team will use those outcomes. And trust, not having trust in the findings, like you only talk to five people, why do we believe it? And yeah, so let's look at how I solved everything in my company and how everything is perfect. Of course, I'm just kidding. Changing the culture is a slow process. It's not something that can be done overnight. And so I'm gonna be sharing some of the techniques which have worked for us and some of us, some of the techniques that are still work in progress for us. Okay, so this is not from Benjamin Franklin, contrary to what Google says. Tell me and I forget. Teach me and I may remember. Involve me and I learn. None of us read the fine brains when we accept terms and conditions. Your stakeholders are the same way. They don't, nobody reads research reports. What you have to do is you have to involve them in the research process. And when I keep saying stakeholders, it's basically your product team members, product managers, developers, designers, QA, dark writers, basically anyone who is a part of your team, anyone who is engaged with UX. Okay, so yeah, the best way to engage them is to have them witness what the users are seeing firsthand. Invite your team to observe customer interviews. This is maybe most of you know about this. What I usually do is I put my schedule of upcoming research in the spreadsheet. I share that with my team ahead of the time. And then I share the recordings with those who couldn't join. But like if you're gonna do 30 interviews, know that they're not gonna watch all 30 recordings. So kinda highlight the three or five most interesting ones. Post session debrief. So these basically is like a 15 minute informal chat with your team, those who had observed the interviews. And this is super important especially when you are in the beginning of the project. Only did a couple of interviews. So you can align with your team on what the outcome is. Like are you getting what you are doing this for? A lot of times when we did this after first couple rounds of interviews, and when we do the debrief and hear everyone's perspective, that's when we realized that well we should be focusing on completely different something, completely different problem than what we had initially set out for. And this was my favorite is the no pressure filled visits. Steve would know this. We started doing this at Salesforce like a once a month where a bunch of us will basically find a local customer who is willing to let us come in and observe a couple of users. And so we would go in a team of three to four, one person each from research design and development. And all we'll do is observe users interacting with Salesforce. And why no pressure? Because there is a minimal preparation before and there are no deliverables. And people love this aspect of no deliverables because that doesn't add any extra work to their plate. And it's still, it turned out to be a great empathy building exercise for the team. And it was like a really good success. People love doing this. Okay, now storytelling sessions. These are kind of similar to the debrief I just mentioned, but a little more structured. Yeah, question. I think of our, I don't know, who told that Steve? I think there is a quote by someone who is in the research field. It's like, every employee in the company should have at least like a two and a half hours of customer facing time per month. And I think that was we were trying to aim at. So we will always have a different people go and then just try and be in front of the company. Our selling point was we want to create an empathy within our team. Just one minute. And then sometimes we would take just photos and come back and share with the team. It's easier to just click photos and share instead of writing a report, which we did not want to do. It would kind of refute the purpose. I don't think we have time for questions. Jared Spool, yes, thank you. Yes, where was I? Yes, and I actually wanted to add one more thing there that if you do not have access to customers easily, you can also shadow your customer service representatives who are kind of frontline to customer. Just sit there for an hour and listen into all the issues that they are hearing from your customer, from your customers and ask them what are the top 10 issues, maybe this today or weekly or monthly basis, things like that. Okay, so these storytelling sessions are based on Karen's book, Rapid Contextual Design, highly recommend reading the book. But these are a little more structured and you can involve anyone no matter whether they've observed the session or not. And basically what I would do is I would have a storytelling session after I've done three to four interviews. This is really suited for a larger research initiative, kind of my number one go-to method. So what I do is once I've done three to four customer interviews, I'll have like one hour storytelling sessions. And so I'll take the first 10 minutes, I'll start with the first interview that I had done. I'll take first kind of 10 minutes to narrate the one hour interview. And then others are taking notes. So I have a bunch of team members, again a good mixture of research design, engineering. They're taking notes and trust me, 10 minutes is enough when you are telling someone a story from what had happened. And then I take, and basically you take next 10 minutes is when together as a team, we discuss the story, we talk about what we interpret from this particular interview. And this is also the time when team asks me questions about like if I noticed a customer click a button somewhere, did the customer mention anything about performance issues, things like that. So we do this exercise for each interview. So basically we take next 20 minutes to then go over the next interview. So and I'm throwing a lot of numbers and hypothetical scenarios, but think about if I'm doing a 30 interviews, I will have a multiple storytelling sessions scheduled throughout, and I'll have different team members come in every time. Okay, thank you. And so by the time I'm done with my 30 interviews, most of my team has heard the stories, customer stories. And not just that, they have shared their interpretations, their key takeaways with me, which is amazing. Think about it. But the most important thing to make this a success is having a structure, having a solid framework for taking notes. So this is an example of the framework that we use. We use the tool called Trello. And so you can see the columns, key takeaways, pain points, user needs. So as I mentioned when I'm narrating the story, others are capturing the notes here. And the most important column is the questions to ask in future interviews. So it's super important to kind of think about what you still don't know and what you should focus in the upcoming interviews. And kind of make sure to go around the room, ask everyone their key takeaways. Again, another important thing to think about is to not start discussing solutioning and technical visibility, because the goal is to learn about the users and their experiences at this time. Okay, so I'm gonna quickly go over some of the other techniques. But again, if you have questions and want to learn more about how exactly to do any of this step by step, feel free to meet me later. Just interest of time, moving faster. Okay, so when you don't know what the structure of the analysis should be like, that's when the affinity diagramming is super handy. You can come together as a team, think about the key themes from your data, and I'm sure everyone loves working with sticky notes. That's what we do in every meeting these days. Journey mapping, empathy mapping, those are, again, great activity to always do those with the team. What if you don't have enough research data? You can still come together as a team and brainstorm what an ideal journey should be like. And then later on, compare that with the actual journey when you start collecting data. The crazy age, we did this morning in Steve's workshop. Basically, you are, as a team, you are trying to sketch eight ideas on a piece of paper in a certain amount of time. But what we really, and I usually do this in partnership with my fellow designers, but before starting the crazy age, we usually set the stage with whatever research insights we have so far. Share that first, and if you don't have that, we start with kind of a competitive analysis. So we, everyone in the room kind of knows, already are on the same page before we attempt on the crazy age. And once you have different ideas from crazy age, or you have a list of work items that you want to prioritize, I know there are a number of techniques to do that as a team. But the simplest is dot voting. I'm sure most of you are familiar with that as well, where everyone is given a fixed number of votes that every person in the team can then use to vote on different ideas. Just kind of pausing five seconds. Any burning questions? Okay, good. Alrighty, and so if you do end up creating a co-creation, do make sure to show it off. Showing customer research data in hallways, that's an amazing way to make other people in the company curious about research, which is the goal when you want to create that culture. And also make sure to kind of have someone from upper management. Maybe involve them in the co-creation, or just ask them to just walk by these walls. Because when you are trying to change this culture, having allies in management can really help that create faster. And you want to show them the value of doing all of this. These are the actual pictures from all of my projects. That's the San Francisco office sales force. Yeah, that's the landmark. Another example here where we printed out our persona cards and kind of handed off to entire company. So these are a great way to make other people in the company curious about research. You can also have a bunch of sharpies and stickies next to the whiteboards for anyone else to add their input to the data that you already have. Okay, so I talked about a bunch of group synthesis and co-creation activities. And what are some of the top benefits? I think it's very visual and tactile in nature. It's inclusive. So people at different level can join regardless of their position, whether they are a director or a junior level person, they can kind of come together and share their thoughts. It's cross-functional in nature, so you can really absorb different perceptions. And it's an opportunity to think before sharing. I particularly love this because I don't like being put on spot and then suddenly someone asks me, what's your take on this? I like to have my time to think about things before sharing this out. And I think it also kind of helps create a shared vision because you're doing it in a team, kind of forces conversation with each other. But I think the biggest benefit of all is that your stakeholders are involved in the process with you when you're analyzing the data. You're not doing it alone in a corner. They're doing it with you, they're doing it for you. So A, it saves you time to do all the analysis by yourself. And then you're building the consensus and trust along the way. And because your team is now invested in this effort with you, it's so easier to get a buy-in from them. Okay, so I kind of share some of the techniques. I know there are many, many techniques available out there. And they have been great in kind of opening people up and coming together and sharing your thoughts. But as I mentioned before, I think creating a culture is a slow process and it basically is changing one person at a time. So over the period of time, from my kind of fellow colleagues, from the articles that I've read, I will learn these three core elements that I think are at the core of the UX and research mindset. And I call them my three mantras and I religiously try to follow them. I want to share them with you. The first one, empathize with your stakeholder before your users. So we use this buzzword empathy when it comes to our users, but we forget to apply that internally within our team. So take time to learn about your stakeholders, about your team. What are their fears about the product? Do they have time, and how much time they have to be involved in the research process? How do they want to consume findings? How do they make decisions? Understanding all of this can really help you in kind of speaking the same language and to share your findings in a way that is easy for stakeholders to understand and adopt. How do you think this picture matches with the context I have? Does that go fine? I don't know. Who do you think it's a stakeholder here? Dhoni or Kohli? I think so too. I think Dhoni. Okay, understand that research is a team sport, so don't keep research reserved just for researchers. That happens a lot of times. Research is not about finding aha moments. It's ultimately about reducing risks, and everyone in the team should be rowing in the same direction for that. So if you are someone who does customer interviews on a regular basis, make sure, find ways to involve your team in that. Think about your team's availability before even scheduling interviews. And if another team member, like a product manager or designer, is going to be meeting customers, find ways to help them. Help them putting together questions. Teach them how to reduce biases, not to ask leading questions. Okay, and my last month is kind of working towards creating a shared understanding. These days, everyone in our companies are collecting data. There is a marketing team doing something. There is a customer service reps. They are talking to addressing issues. There is a data science team. And probably every other day there is a new survey. And so have regular meetings with other customer-facing teams and share your understandings and data with them to make sure you are understanding everyone's perspective. You're not duplicating the efforts. I personally think that as a UX professional, our biggest strength is in facilitating conversations. So work, use that skill and work towards creating a shared understanding. I think I went really fast. So this is my almost last slide. I love this quote, user researchers fallacy is that my job is to learn about users. But truth is that my job is to help my team learn about users. I think only when your team realizes the value of the research, the value of understanding the users, I think only then they can really understand that UX and research should not be just a luxury, but an integral part of the culture. And that's the way to work towards creating, changing the culture and making it more user-centered. I think my last slide is thank you, which I can just say, thank you. Do I have time for Q and A? Or probably not. If someone has. Sorry, say that again. Crazy eight and dot four, you just mentioned. Sorry. Yeah, so the crazy eight is I usually do that with partnership with my designers. So we start, as I mentioned, we start with some kind of research and competitive analysis. We usually also print out what other people are doing in the market. And so crazy eight is basically you take a piece of paper, you fold it twice, and so you have kind of eight squares. And you set up a timer and you can decide based on how complexity of the project. But you can do like a 30-second or one minute, take, everyone takes one minute, and sketches the ideal. How do you see concept? It doesn't have to be beautiful. And everyone can participate, not just designers. So again, yeah, definitely help people from higher management, even if they're afraid of sketching. Once you actually start doing it, you can really visualize. It's just kind of trying to put together storyboards or visualization. And then dot voting is you can also do with crazy eight, which basically you have three votes and assume you have like 20 different ideas. And so each person vote is three ideas out of the 20 or so that you can have. Yeah, cool. Yeah. Can you say we should reserve about 2.5 hours of time each month for client tracing? If you're working from India, how difficult it is to actually do a client tracing job where your clients are selling remotely? Good question. So I will tell you what we do. I mentioned I work with salesforce.org where 80% of my team is remote. I work from home. And so pretty much everyone that I work with is also remote. So I don't think it matters which part of your, well it's like I'm also remote. So we do a lot of remote work. And obviously it is nice to be in person with the customers. But when I say customer facing time, observing remote sessions are a good way to start with that. And then whenever we get time, anytime in front of the people, if you have like company conferences or something, just find time there. And I don't think, are all your users, none of your users are in India? Some of them are just kind of basically fine if you don't have access to the users, kind of find proxy users as Tim mentioned this workshop. As I mentioned maybe find internal team members who are the first line kind of other customer facing team. Those will be the other ways to do it if you cannot travel and meet with customers on a regular basis.