Facilitating Cross-Functional Collaboration as a UX Designer

Ganesh Karthik Sankar at UXDX Community: Collaboration That Ships, Acumen That Sticks. Video: https://youtu.be/qAUlZP7erOQ

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 and agenda

[00:00:08] Hello everyone. I am Ganesh Karthik Sankar, and today I'm going to be talking to you about facilitating cross-functional collaboration as a UX designer. A little bit about myself: I am currently designing customer support experiences at Amazon. Previously, I was the founding designer for the software analytics and global automation business division at an organization called Qualcomm, which is a major chip manufacturing company. Prior to that, I was the founding designer for a public transit agency called Sound Transit. I've also worked at the likes of Bank of America.

[00:00:43] Throughout my career I have worked in organizations of varying UX maturity and varying structures, and I've learned what strategies work best for collaborating with different stakeholders. That's what I'm hoping to share with you today over the course of this presentation.

[00:00:59] A little bit about the agenda. Firstly, why does cross-functional collaboration matter? Why should you be listening to this talk? Secondly, I'll help you identify who the key stakeholders are that you need to be collaborating with. Then we'll figure out how to engage with them, how to build trust with them, and how to build long-lasting relationships with them. Finally, I want to leave you all with some practical strategies, frameworks and artifacts on how you can improve your collaboration skills and engage with your stakeholder partners effectively.

Why cross-functional collaboration matters

[00:01:33] Jumping right into the first item on the agenda: why does cross-functional collaboration matter? It helps you create impact beyond your team. As you talk with different stakeholder partners and teams, every now and then you will come across a situation where another team is working on the same challenge that you're trying to solve for, so your solution could also work for them. This way you would be able to come up with solutions that solve problems not just within your team but for other teams as well, and create impact beyond your team. But for that to happen, you need to first collaborate with them and understand what their challenges are.

[00:02:12] Secondly, it helps you understand deeper business and organizational context. It helps you understand how your product came into being, and the larger organizational or business context within which your product lies. Thirdly, collaboration helps increase your visibility and influence across the entire organization.

[00:02:36] Fourth, it helps you avoid conflicts. How? Every now and then you will come across a situation where a random team or person pops up and says, hey, I was never involved in this project, but I have a lot of information that I want to share, and I also have a vested interest in this project. Every now and then they might share some information that could potentially change the entire product strategy, and that could reflect poorly on us too. So collaborating early on helps us avoid such conflicts. And if you're working in a large organization, you almost always have a yearly appraisal, and you want a lot of people to attest to your skills during that appraisal and serve as references for you. When you collaborate with a lot of people, you are building a stronger support system.

[00:03:25] Last but not least, if you're somebody who is breaking into the industry, or currently looking for jobs in the UX industry, collaboration is definitely the most sought-after skill. If you look towards the left, there are a bunch of excerpts from job descriptions that I pulled from LinkedIn just a few hours ago, and almost all of them talk about how you need to be a great collaborator. At the end of this presentation I actually have a few questions related to collaboration that might pop up during interviews. Hopefully that helps those folks who are interviewing or looking to break into the industry prepare.

Identifying your key stakeholders

[00:03:59] Now that we understand why cross-functional collaboration matters, let me help you figure out who your key stakeholders are. To figure this out, I do a simple stakeholder mapping exercise. How this works is, I know who my immediate product partners are. There's almost always an engineer or a product manager that you collaborate with. So I engage in conversations with them and ask them: who else should I talk to, who has worked on products or projects that are similar to what we are working on, who might be tangentially related to this project? This will help them think and come up with different folks that you could potentially meet. And as you meet these new folks, ask them the same question: who else should I talk to? It has this snowballing effect. That way you'll be able to identify different stakeholders, map them onto a document, and write down their goals and challenges alongside them, as shown on the left.

[00:05:02] Another piece of advice I would give is to go through all of the artifacts for the project. Let's say you receive a product requirements document. Go through it, figure out who wrote it, and then reach out to that person as well and start establishing a conversation with them. Also make sure that you leave your trail in these documents. What I mean by that is, put a comment or a question in that document, and then whoever owns that document will respond to it, and a conversation starts from that, which could eventually evolve into a relationship. Using both of these techniques, you can figure out who your different stakeholders are and map them.

[00:05:44] Once you have figured out your different stakeholders, there are different frameworks to identify and map the roles and responsibilities of each of them, but the one that I found to be the most useful is the RACI chart. Any product managers in the audience will be very familiar with this framework. RACI stands for responsible, accountable, consulted and informed. Responsible is the person who is directly responsible for the task. Let's say you are the UX designer for a project; then you are directly responsible for the design tasks. Accountable is the person who is in charge of the entire project, the product lead, which is almost always the product manager, but it changes from company to company. Consulted is the person whom you have to consult. This could be the engineering team, because they can help you identify the technical feasibility of your designs. And informed is the people who need to be kept in the loop. So identify your stakeholders and have a chart mapping what their roles and responsibilities are, so that you can involve them whenever appropriate.

Understanding goals and preconceived notions

[00:06:53] Now we have identified all of our stakeholders, we need to actively engage in conversations with them and start building trust, and that's what this next section is all about. For building any strong relationship, you need to first understand the goals of your stakeholder. Ask them what their goals are and what matters most to them, and actively contribute to helping them achieve these goals within the scope of UX. You can ask these questions in your one-on-one meetings with them, or if you come across them in the corridor, in your office cafe, or even in your internal office messaging application. But make sure you ask them.

[00:07:36] Also ask them what a successful collaboration with a UX designer looks like based on their past experiences, or what they think the roles and responsibilities of a UX designer are. This question will help you uncover preconceived notions that folks may have about the roles and responsibilities of a designer, especially when you're working in an organization where the UX maturity is relatively low. A lot of folks may not even know what a UX designer does. This helps you understand what they think of a UX designer, and you can then work with that.

[00:08:10] For example, let's say you're working in a low UX maturity environment, and they expect a UX designer to be somebody who can push pixels, who can just make visuals, but they don't want them to be an equal product partner. Instead of immediately pushing back, you can share successful examples from your own past of how you have been an equal product partner, and also collaborate with them over time and work to change this perception. But before that even happens, you need to know what perception they have. Where do they draw the boundaries for a UX designer? This helps you foresee any potential conflicts, because they might come up to you and say, hey, stay in your lane. So to identify and foresee such conflicts, you need to figure out what preconceived notions they have and where they draw the boundaries for UX designers, so that you can work towards it or against it as you see fit.

Supporting product, engineering and AI teams

[00:09:10] This way you'll understand what their goals are, what they think of UX designers, and what matters most to them. Now let me give you a few examples of how you can collaborate with these different stakeholders, understand their goals and contribute to them.

[00:09:25] Starting with product management. This could include your project management partner or your product manager, your PM. What they typically care about is the business outcomes and the prioritization of the different features in the product that you're collectively working on. Their goals could be improving any of the business metrics: increasing revenue, increasing retention, increasing adoption. You can support them in achieving these goals by mapping all of your UX goals to these metrics, and by helping them identify what the minimum viable prototype should be, what the most critical features are that users will have to use, which will help them with prioritization. In this way, within the scope of UX, you can help them achieve their different goals.

[00:10:15] Another example of a stakeholder would be engineering teams. What they typically care about is the technical feasibility of the designs. They're also responsible for the ultimate product that gets into the hands of the users, so the quality and accuracy of that deliverable matter to them. What would be a few goals for them? Improving latency, which is basically the amount of time it takes to load a UI screen, matters to them a lot. The data model matters to them, which is pretty much the information that's displayed on the screen. They have to figure out what the data sources are, what databases or APIs they need to use to fetch this information and display it on the screen.

[00:10:59] Those are some examples of their goals, and you can support them by involving them early on in the process. You may not have your designs finalized, but if you have an idea of what kind of information is displayed on the screen, you can share it with them early on, so that they can start figuring out what the data sources are going to be for this information and start the technical feasibility discussions early. It would save both you and the engineering team any last-minute surprises.

[00:11:29] Another example would be AI or science teams. Every team right now is working on one AI feature or another, so almost always you'll end up in a situation where you're collaborating with a team focused on improving AI models. They typically care about model accuracy, quality and safety, and their goals could be increasing model accuracy and model reliability over time. You can support them by surfacing edge cases for them, and by providing them with user feedback data that they can use to effectively train their model and improve its accuracy. So have these conversations with them, understand their goals, and then figure out how you can help support those goals. That's what's going to help you earn their trust and build a strong relationship.

Artifacts: metrics mapping and data models

[00:12:27] Now let me leave you with a bunch of artifacts that will help you collaborate effectively with some of these stakeholders. Here is a quick example of a metrics mapping, which I typically use to engage with product management or product managers. I try to first understand what their business goals are. In this specific example, we were working on a product where we wanted to increase the number of trial-to-paid users. Then we map out the different metrics that will affect this business goal. The success metrics could be the trial-to-paid conversion rate, since if this increases we are achieving the business goal, the drop-off rate, and the checkout completion rate. So brainstorm with them what the different success metrics are that will help achieve this business goal.

[00:13:22] Then this is where you can contribute, in the performance driver section. Basically you're identifying the areas that would help you improve these success metrics and, in turn, achieve the business goal. Let's say we have to improve the checkout completion rate. Then obviously you'll have to improve the UX of the checkout flows or the purchase flows. If you reduce the number of steps in the purchase flow, that can help with the checkout completion rate. This way we identified different investment areas for UX that could contribute to these success metrics, which would eventually help product management achieve their goal, which is the business goal. So this is one framework that you can use to engage effectively with your product partners.

[00:14:10] Another example is engaging with your engineering partners. What I've observed over the years is that every UI you design is either showing some information to the user or collecting some information from them. Even though you may not have the final designs, if you have an idea of what the data model is going to be, what information will be displayed or collected from the user, share it early on and have that discussion with the engineering team. That way they can figure out which API or data source, for example, they are going to collect this data from, so that they can deduce the technical feasibility of it, because the bulk of engineering effort is spent in this area, figuring out the data model. So this is one area in which you can collaborate with them early on, even though you don't have the designs finalized.

[00:15:07] Before I move on to the next section, I want to leave you with a quick tip. Whenever you are invited to any major product decision-making meetings, try to be an ideation partner for everyone. Let's say someone has an interesting idea: try to visualize that idea, put together a quick wireframe. Now, with the advent of AI, it's so much easier to do that; you can quickly just vibe-code an image or prototype for them. This way people start realizing the value you bring to these meetings as an ideation partner, and they start inviting you to these meetings more often. Now you have an audience who believes in you and sees your value, and slowly you can also start contributing to the product strategy and to major product decisions, even though you may not have direct authority over any of them. That's how you do it. That's just a quick tip that I wanted to leave you with.

Workshops: alignment through visual artifacts

[00:16:03] Now we have figured out our stakeholders, and we've learned how to build trust with them, how to understand their goals and how to contribute to them. Every now and then you might want to bring them all together, for aligning on a certain product vision, for example, or for brainstorming some problem, and the best way to do that is to organize a workshop. In the next section I'm going to give you examples of a few workshops that you can organize to bring all of these different stakeholder partners together.

[00:16:36] These are the three most common types of workshop that I've come across in my career. I'm sure there are a lot of workshops, but these are the three most common. The first one is alignment workshops. Whenever you have a product strategy or some vision in place, you might want to bring all your stakeholders together and share this vision with them. This could happen early on in the design process, when you have a strategy or vision finalized, and it could even happen later on in the design process, when you have a prototype or a finalized design that you can show. Another workshop would be the product value proposition workshop, where you're trying to identify the unique value proposition of your product: what it is trying to solve, who the target audience is, and all of those interesting details. And probably the most common, which we have all experienced at some point in our lives, is a brainstorming or ideation workshop, where you have a problem and you're working with your stakeholders to brainstorm ideas to solve that problem. In the interest of time, I'll just focus on the first two workshops and leave you with some frameworks on how you can effectively engage folks in them.

[00:17:43] Let's start with alignment workshops. The typical challenge that you will face with alignment workshops is that every time a product vision or strategy is finalized, there will be a long document, two or three pages or more, that folks have to read to understand what the vision and strategy is. When your teams are geographically distributed, and when your stakeholders are simply in a lot of meetings every single day, they may not fully read the document, and this leads to some misinterpretation of what's written in it, or some understanding gaps.

[00:18:25] The solution is to not just rely on these long, text-heavy documents or emails to drive alignment, but also to come up with more visual artifacts, like schematics and system maps, to explain the problem effectively and highlight your solution. Let me give you a quick example. One of the projects that I was working on during my tenure at a public transit agency was to build a mobile app for fare checkers in public transit. I first had to figure out the different workflows that the fare checkers are part of, and based on that I put together this system map. I don't have to get into the details of each of these workflows, but this visual easily conveys the different workflows that the target users, the fare checkers, are part of, and how huge the entire system is.

[00:19:24] Then I introduced a mobile app that helps streamline all of these different workflows and reduce time on task. Again, I don't have to go into the depths of what the mobile app does, because I had not yet got into the designing part; I'm just figuring out the product strategy here. Between these two images, it clearly conveys what the product strategy is, what the vision is, what we want to do with the mobile app, which is to streamline all of the workflows. This image gets seared into the brains of your stakeholders, and they will always be able to recall visual artifacts such as this rather than long text documents. So, to the best of your ability, come up with such visual artifacts. UX-ify it, basically, so that it's easy for anyone to understand what the product strategy is. Because before you drive alignment, you need to make sure that they all understand what your strategy is, and visual artifacts help convey that.

Value proposition workshops and general tips

[00:20:23] The other type of workshop is the product value proposition workshop. This is the template that I use. You first identify what the customer profile is, what their needs are, and what their pain points are. Then you figure out how your product helps solve the needs and pain points of that specific customer. Once you have the solutions in place, there's what's called the value proposition assessment, which is a list of 10 questions that you can get from the internet. It basically asks questions like: is it embedded in a great business model? Is it something that's easy to copy? As you'll notice, some of these questions are more relevant for a product manager or for an engineering partner. This way each of your stakeholder partners will have something to contribute as you assess the value proposition of your solutions and your product. So make sure you use such questions, artifacts and templates to engage with your stakeholder partners effectively.

[00:21:29] Before I move on to the next section, I want to leave you with some general tips that you can use for any sort of workshop. Anchor everything to the stakeholder goals. In the previous section I talked about how it's important to identify your stakeholders' goals. Now that you have an idea of what the stakeholder goals are, ensure that each of these workshops is addressing those goals.

[00:21:55] Another underrated piece of advice that I received early on in my career was to get alignment and buy-in before you even have the ultimate workshop. Let's say you have five stakeholder partners in a certain workshop and you're hoping to get buy-in for your solution from them. Before you even have that workshop, have one-on-ones with them and make sure they have an idea of what this is all about. Make sure you get their buy-in before you even get into the workshop. This will avoid surprises for you and for them.

[00:22:29] And like I said earlier, try to use artifacts as much as possible, either a user journey or some system map. Try to use visual artifacts as much as possible, as they're easier for someone to understand and align on. Storyboarding is another great example of an artifact that you can use to help folks understand easily.

Interview questions and close

[00:22:52] With that, I would like to conclude my presentation, and I want to leave you with some interview questions that might come up if you're interviewing for any UX design job. These are questions that I collected from my own experiences interviewing and being interviewed at different companies, and I picked them out specifically because they are related to collaboration. An interesting thought exercise for you would be to take these questions and see how you would use some of the artifacts and strategies that we discussed earlier to answer them. With that, thank you so much for listening, and thank you all.