How to build user insights into your design process

Summary

Most design leaders would tell you that while it’s incredibly important to integrate user insights into the design process, it’s also very difficult to make those insights a daily, systematic part of their team’s workflow. Simon Mateljan is a design leader who has been working on that issue for many years, and has made very substantial progress. In addition to his current design management role at Atlassian, he’s a mentor, speaker, and UX Camp committee member in Perth, Australia. He’s worked in a wide variety of companies and industries, including the Royal Automobile Club (RAC) and the Australian Finance Group.

We talked with Simon about his experiences and strategies as a design leader. As you’ll see, he has a lot to share about what he’s learned and the best practices he’s developed.

Note: This transcript was edited for clarity and length. Simon approved the final version.

Your role: UX design vs. experience design

Q. In your LinkedIn profile, your title changed slightly over time. You were in UX and UX design, and then your title changed to Experience Design. I’m curious, are those just synonyms or was there a subtle evolution in your role?

When I was just looking after UX teams, we were very narrow in our focus. We were just looking at singular experiences. In those roles, whether I was leading a team or an individual contributor, we were working on a specific product. So it was a single app, or a single product journey within the website offering.

When I stepped into a role with broader scope and responsibility within experience design, I started to lead team members of various disciplines. Everything from service design, experience designers, user researchers, all of these sorts of different categories. UX just didn’t fit against that.

And it’s probably a really important thing to touch on that: if you are one part of that puzzle, there’s all these other bits of research that other designers with other disciplines are conducting, which do have an effect on the end user’s experience. Even if a service designer is looking at the in-house operations, the back of office experiences, they do have that flow-on effect.

Q. Help me understand how that experience design role is organized. Are there a lot of different products that are under you and you’re supervising the individual experiences there? Or is it more like you’re looking at experiences that happen to go across a lot of products, but it’s not like a hierarchy, it’s more that you’re the glue between those things?

It’s a bit of both. 

If I think about my previous role prior to joining Atlassian, we had team members distributed within different product teams, and those team members were of different disciplines. Some were UX, some were service designers, and we were that human glue. I could never think of a better phrase for it, but it was that human glue that was kind of holding it together historically.

That’s where using UserTesting, and other services as well, the discoveries and the learnings that the teams were having in their little pockets we could suddenly bring them all together. That allowed our teams and the business to see there’s overlap here, and that naturally occurs because you’ve got a user coming to your website to complete one task like renewing their home insurance, but they’re also thinking about another product offering too that is unrelated to that current task.

And so it was those sorts of things that even though they’re doing different tasks, the users are having the same experience. The path to purchase should be a similar experience, to allow for it to be easy to complete.

To share insights with the company, start small and simple

Q. So, how do you make those connections? You’ve got different people doing little bits of research that I presume are very much tied to their particular products. How do you distill that out and make the connections between those different things and share them? That sounds like something that would be really tough to do.

There’s a few formats that we tried.

My approach with anything is I’ll just start off small. Like, let’s just do something rather than nothing.

I think with any sort of business, especially enterprises, people can get overwhelmed with, “oh my God, how are we going to do this?” And then you end up talking about it for six months and nothing actually occurs.

So we had adopted UserTesting, team members had started being able to conduct remote interviews, and we suddenly had a method to put user insights into our delivery process. Then it came to, “how do we start bringing the stories together?”

So we just started small.

I just set up a monthly designers forum where people would come and play back “this is what I’ve heard from my research.” And we just started doing that. People are just getting around a virtual campfire and we’re just telling our stories. It was very low effort.

Then what naturally happens is, people are getting more comfortable with this storytelling. I then thought, well, we want to go broader than just our team at some stage. How do we do that? We had a company intranet, so I said to the team, let’s just publish really small articles there. You know, here are the highlights. Here’s what we are hearing from our users. Here’s what they like, here’s what they don’t like. Let’s just publish it there. Again, just something small, low effort.

We were already doing this within our project delivery. You know, including it within our documentation plan back to the stakeholders and our delivery teams. But I was also very conscious of how do we share that out to people that aren’t involved within the delivery. For example, how do we highlight this to the customer service team members that are in a call center or somebody in another business unit?

Then we started looking around at different research libraries and we landed on Dovetail as a product to be able to store all of our current and some historical research.

This was over the course of 9 to 12 months from “let’s just get together and share our findings in a Guild” to “let’s start evaluating different products for how we can store that information and share it out.”

We looked at SharePoint, because we already had access with it. But we landed on Dovetail because of the number of features that suited us, its integration into other platforms in our ecosystem, and ease of use for our stakeholders to self-service. 

This then set off a bigger program of work, because when you’re building a library then you’re starting to get into discussions around the information hierarchy. How do you store this information? What are the processes? What are the expectations for people to contribute their research into it? You need to talk about your tagging taxonomy, so that it’s logical for everyone.

So I had one of my leads drive that program and work, and we just worked with our group of designers to get that alignment. To give you an idea of scale, that was a team of about 15 or so designers.

So a lot of opinions and a lot of different scenarios. We had to be very flexible, but we also needed to have the right guidelines in there because otherwise what’s the point if you don’t have those.

We then had this environment where all of our research was, and then people from around the organization could self-service to be able to find that research, which was a big thing for us. We didn’t want to constantly be getting emails of, “Hey, can you tell us what our users are saying about this?” We want to have that so people can just find it themselves. Then if they’re really curious and they’ve got more questions, then great. come talk to us, and then we can dive deeper into what’s important to them.

To make people start sharing insights, focus on storytelling, not specific deliverables

Q. I think a lot of people have aspirations to do what you just described, but many of them have struggled to make it work. Talk to me about how you did it. You started with these little campfire meetings on Zoom. In those meetings, what exactly were you sharing? Was it just, “let me tell you verbally what I’ve learned?” Was it, “let me play my highlight reel for you?” How much work and prep did people need to do and which artifacts were most useful to share?

I had such a range of experience within the team — from new to industry designers to people that have been in the industry for 20+ years — so I purposely set the bar to share whatever you’ve got. If it is just notes in a Figma file, if it is just recordings of interviews and you’ve edited a highlight, whatever you want.

That’s always a really difficult thing because you’ve got people who naturally are a bit hesitant to share. Especially, if someone comes in and they’ve got a full highlight reel package edited together, and then the next person’s like, I’ve just got notes that I’m gonna talk to.

So what I really emphasize to the team is, don’t think about the format. Think about the story that you’re telling, and you can tell a story in any method. To make people feel comfortable about that, I said, “everyone turn your cameras off and close your eyes, and I’m going to tell you a story about a time I spoke to a user.” And then I said to them, “this is a method where you haven’t had to look at the screen. you haven’t had to look at anything that I’ve prepared, you’ve just listened to me tell a story. And that’s what we’re here to do.” I always want to create that sort of comfort, so it’s less about the medium.

Every team member is at a different stage of research. Some people, they just maybe completed their round of interviews with users. They hadn’t had time to really synthesize it, but they’re like, “look, here are my key takeaways: people are having trouble logging in, this terminology is confusing.” And that’s it. And the playbacks from each person would be five, 10 minutes, really simple.

And then you would have some team members who had probably had a bit more capacity between completing the interviews, and they put together a highlights package that would be broken into the good, the bad, and the things that we’re a bit unsure about. And that was always really useful.

That’s one thing that we had great impact with using the UserTesting platform. What the team were having to do before we started using that platform was record a Zoom call. We’re doing it all manually, download a Zoom call in iMovie or whatever they had access to. 

Being able to create those highlight packages within UserTesting cut the manual time down so quickly. That’s where it allowed us to really amplify findings across the business. Because while it was good for the 15 of us to get together and share those stories, the only way that we can have impact on behalf of our customers as well as design as a practice within the organization, is to be able to share these findings out in a consumable format.

I would always stress to think about our audience that are watching our work. They’re busy. They’ve got their own priorities, so let’s make it super simple for them. If it’s a five minute video that they can click on while they’re waiting for the kettle to boil at home, or between meetings, then that’s easy to consume, it’s easy to digest.

That’s where video played a really key part of showing those highlights, because the team were able to be present without having to set up a meeting, without having to get everyone together, which obviously is difficult.

We would also include a documented summary, with our key takeaways and other things that we want to explore in detail. We found that to be really useful for our product managers so that they could take those things, copy, paste, and put it within their slide decks so they weren’t having to rewrite those sorts of things.

Again, I always stress the team: create things that make it really easy for people to be able to tell our user story on our behalf.

All the research from the team would sit within Dovetail along with other different artifacts. We would include all of our pre-work, questions, and scripts, including the questions that we didn’t ask, so that people could see. And we would include things removed for interest of time, or that was not really relevant to what we’re trying to discover at this stage. It was that transparency that Dovetail really gave us so that people could go to the project area and see the pre-work that’s actually gone in, which I also think is valuable. And the science behind it. I would say to the team, I don’t think a lot of people understand the science that exists behind research and the hours of conversations that we have as designers and researchers before we actually do a half an hour interview with someone.

So we would include all of that and our findings, the combination of the design artifacts and prototypes and links to any of the workshops that we may have done as well.

When to use live versus self-guided tests

Q. Were these all live interviews that your folks were doing with customers, or were they self-guided (unmoderated) tests as well? What was the mix of methods?

When teams were starting their discovery phase, we would predominantly be doing the one-to-one (live) interviews. Because there were a lot of unknowns. We wouldn’t really get to the unmoderated until we had defined a lot of the scope and the understanding of what we were wanting to discover, when we had gone through a few rounds and the design was pretty solid on the web journey or the form or whatever. Then we did unmoderated. We can do that really quickly.

The discovery phase is where design’s kind of in isolation. Engineers aren’t necessarily involved. We would include them for awareness, but it would be as we’re getting through the delivery that engineering is most involved because they’re building out the things that we’ve confirmed. We would be working closely with them so our team members would actually have less capacity to be doing our long interviews and those sort of activities. So that’s where it also became an advantage to be able to do unmoderated.

The team would connect with their morning standup, and there would be questions around which way do we go with this journey, or this form. And then we would do some really quick unmoderated tests, and then within 24 to 48 hours we’ve got all the responses, and if that was a Monday morning standup, by Wednesday the team would have that clarity of like, yep, this is the nice option, that is what we’re going with.

And so we started then to be able to really promote to the business the idea that including users within your delivery process doesn’t slow you down. And I should touch on that: in some businesses there can be a big preconception that if we want to bring our users in, it just slows us down because of the effort. You could hear, “design takes three to four weeks to do this research.”

And that’s where once we were able to put the right tooling in place, with UserTesting, with Dovetail and other processes as well, we were able to bring that down. It was no longer an issue of “it just takes too long.”

How to divide research work between dedicated researchers and empowered designers

Q. Do you have any dedicated full-time researchers? Or are all of the designers also researchers?

At the moment within Atlassian, we do have dedicated researchers but our designers also still are conducting research. The difference will be mainly that for the researchers, that is their focus. They’re also thinking about that whole bigger picture of how we amplify our research, how we store it. All of those sorts of challenges.

At RAC, I actually had one of our service designers take on the ownership of that sort of task, of how do we organize our research, because of her experience specifically. In a discussion with her, we decided we want research and design to be a service, so let’s design it. Let’s not let it just happen. Because if you let things happen, we all know it kind of works, but then it’s not scalable. So that was the approach that we took, having that service design lens over it.

I do have an expectation that all designers — UX experience designers, product designers — will need to be able to conduct research interviews and workshops with end users.

The only discipline in the design space that I’m comfortable with research not necessarily being a skill set would be your interaction or UI designers that are solely working on interface work. But maybe that’s just been my experience with the designers that I’ve worked with that specialize in that skillset, they’re comfortable being involved with interviews, but they don’t want to be the driver behind them.

Q. Let me be sure I understand these roles, because as I talk to design teams, I’m finding all sorts of different labels for roles. So if I understand this right, you’ve got experience designers who are kind of the broader picture and you expect them to be able to drive research as a part of their portfolio. Then you have an interaction designer, who is just working on the specific look of an interface or something like that. And they may not drive the research, but you would expect that maybe they would be watching, they would look at the results?

Yeah, they would, they would use that research to influence their design decisions and then also justify what we’ve done. But I wouldn’t be expecting them to be driving it.

The design titles and expectations of designers and all of those things vary from business to business and environment to environment. It’s always challenging. As I’ve gone between businesses, the expectations of a designer can change from org to org, both in terms of the exact titles, and also how empowered the designers are to go out and gather their own information.

To prevent self-confirming research, use peer review and culture

Q. Let me play back something that I hear sometimes from full-time researchers. Whenever we get on this subject of empowering somebody who’s not a trained researcher to do research, I get some people who say, the problem is you get poorly-conducted research with confirmation bias where they just go out and gather information that confirms what they wanted to do anyway. How do you respond to somebody who raises that issue?

It’s a very natural thing. You hope that the team members that are doing that are aware of it. And that’s probably something that I would bring up to them, that we want to really discover more. I’ve always found it comes down to the individual and the culture that’s around the team as well.

How I’ve combated that in the past is we would have team members conduct a peer review, and we would use the (approval) flow process within UserTesting. But even before we had UserTesting, like if someone’s got a series of questions or something like that, I would have someone else in the team conduct a peer review. Or I would do it, especially when we were starting out and it was a small team.

I was more hands on with the team then and I would just ask questions. And so we would work through that together to make sure that we’re not just going, “hey, we really want this to be this interface because we think it looks good.” I think having those processes in place helps.

And then culturally, it’s something I’ve always just felt as a leader, I need to encourage teams to remove themselves emotionally from the design, as much as they can. You know, we’re doing this for the user, we don’t know what they’re going to come back with.

Then I would make sure that they have the right sort of follow up questions. If we are looking at including this feature to help the login process, we should ask questions around, “if we include this, we might need to remove this other feature. How is that going to make you feel?” Ask about tradeoffs and those sorts of things.

I would always encourage the team to think about that. Any idea that we come up with, someone in the delivery team has to build it. And so we need to be realistic. You can’t include all features in a product because then it’s just feature-heavy and is it actually doing the right things and solving the right things?

I always use the analogy of, if you’ve got a certain size house, you can’t keep buying stuff and putting it in. Sometimes you need to take furniture out to get the new in. If you get to a point where you’ve got a full house, then you’re talking about building an extension or building an upgrade to the house, a second story. Then that’s okay, that’s a new whole feature or project that we’re looking at.

How to avoid the service group trap: Focus on wasted development time

Q. Let’s talk about the culture and processes a little bit. What you’re describing, the way you work with the organization and the things your team is responsible for, would sound like nirvana to some of the designers that I’ve talked to. Sometimes they’ll say, “look I am treated as a service group that is in charge of making pretty pictures. And so I don’t have the authority to push on the range of issues that you’re talking about. And also, I’m not given the time. It’s like: ‘oh, we have a sprint, draw the picture for me. I need it in a couple days because we have to go build this.’” Do you have any advice for somebody who’s in that sort of situation? How do they evolve the company’s culture? How do they build out the type of role that you are describing?

It’s a challenging thing. I wish I had a silver bullet to be able to share.

I have been very fortunate to have the support of leadership within many of my roles who have understood the value of including users within it. So that is a disclaimer there.

But that’s not to say we didn’t hit some roadblocks. So how I approached it was I don’t think about design in isolation. I think about the whole delivery process. And that’s how I would start those conversations. If I had stakeholders then they were talking to me about the time and effort and those sorts of things. I would say, “Let’s talk end-to-end here. Cause if we get this wrong at the beginning, then when it goes to delivery, it’s gonna be wrong and then we’re gonna have to fix it.”

So that’s my approach, I’ll always work with other disciplines. I’d work with the engineering manager, I’d work with all the other delivery teams that need to be involved. I presented not design in isolation, but as that broader sort of picture together. And then I would talk about the numbers, the time and effort that can be saved by developers if we confirm that this is the right thing to build.

What that saving would be, I would always keep it fairly broad. I would try not to put a dollar value against it unless it was an exact number I could confirm because that’s where I would find if you had those challenging stakeholders, they’d get really nitpicky on it questioning how I landed on that dollar value. So I would just talk hours instead of dollars, people can do the math themselves.

When it’s about time, that is the thing that allows us to speed up that delivery. It allows us to free up a whole developer to focus on something else that’s also a priority. 

The other area to be able to get that sort of support was removing any of the preconceptions that existed around how long design research takes. That’s where I really emphasized to the businesses: it wasn’t about getting more people, it was getting the right tooling in place. A lot of the effort was spent around capturing, “this is our current process” and being very transparent that our current process is slow. Like in my previous company, it was taking three to four weeks to be able to get users in, to get the feedback. And to change that, this is the tooling that I need.

In the organization I worked at previously, we were a membership-based organization, so everyone already was in that mindset of, our members and our users are the most important thing. And so I was very fortunate to be part of a business with that culture and mindset. 

Q. Within UserTesting we’ve been telling ourselves lately that we probably need to explain to customers what we do for them in terms of reducing the risk of rework. That every sprint you burn on doing the wrong thing, there’s a dollar value to it or; or an hourly value to it, as you’re saying. And just saving a few of those sprints actually is a pretty massive benefit. Both in time, but also reducing burnout of engineers, other things like that. And our feeling is that’s a very bread-and-butter issue that we can get attention and traction from managers for. At the risk of creating my own confirmation bias, I think you’re kind of saying the same thing. Am I reading that correctly?

A hundred percent.

It was something that we had support from the product managers on. They wanted to be able to include the users. Some engineers were like, “no, I just, I just want to come in and build things, I don’t need to hear from the users. Just tell me what you want me to build and I’ll build it.” That was the mindset. That’s where I needed to spend a lot of time with their managers and their teams to emphasize that’s actually important.

Back to the tooling, we were able to include the information within their Jira tickets. We were able to include the highlights packages, play them at standups, play them at retros, and then it became just part of the team’s DNA and it wasn’t something that would happen once a quarter at a town hall. It became about that continuous playback and making it easy for the team to consume. 

How and why to integrate user insights into Jira

Q. Let me understand exactly what you did with the Jira tickets. There’d be a ticket saying, “we need to do X” or something like that. And would you put a highlight reel in? What would it be? People looking at the prototype saying, “oh my God, that’s what I want?” Or would it be more about defining the problem, like “here’s where I’m stuck.” What was the artifact you put in there?

Mainly we’d focus on the problem and why we’ve made the decision.

In some teams obviously the ticket would be focused on the problem, now let’s as a team come up with the solution. So that’s where we would have that in there. That would allow the engineering designers that are working on it to be reminded of, yeah, this is actually a really frustrating thing for some users, so let’s solve it.

Now, the important thing was we would then close the loop with that sort of stuff. So after we had decided this would be the solution, whether we had built it or just come up with a prototype, we would then go back to the users — different users perhaps, or maybe the same group depending on the product that we were doing — and get their feedback on that. And then if it was, “Hey, this is great, we love it,” we’d then play that back to the team so that people would be like, “Okay, cool. I know I’m doing the right thing now and I’m not gonna have a manager or a leader from the business or whoever come and ask. ‘why did we do this?’ We’ve got the evidence to support us.”

It is something that commonly happens in a business where perhaps a team would work on a solution, they would ship it, and a stakeholder who was removed from the delivery process would then come and ask, “why have we done this? This doesn’t make sense to me.” Or “I was at a barbecue and spoke to a friend who went through this journey and they said it was annoying that we added this feature. Can we change it back?”

And my reply is, “well, you spoke to one person who’s a friend at a barbecue, so we need to play back our research.” We were able to flip those conversations because of that evidence. Added to this we were able to start to include those broader stakeholders within the discovery journey as well by making short highlight packages available. 

By amplifying the research, when you get to that point of shipping something, you hope that those people have seen it in a town hall presentation or they’ve seen it in an Intranet update or they’ve gone to Dovetail or whatever it may be. It wasn’t perfect, but it can create more of that awareness across the organization of why the delivery teams were making certain decisions.

Q. So I’m seeing this trajectory: you started small just within the team, sharing the stories and artifacts, and then figuring out how to do it more rigorously. And then you became almost the Ministry of Education in the sense of you’re educating the company about “here’s what we’re doing and why we’re doing it” so that they’re all there with you as you’re doing the work. Is that right?

Pretty much. And transparency was key.

Let’s just be honest. If someone has an opinion, then cool. I’m keen to hear it, but it needs to be backed up with some science or some reasoning. And the best science we can speak to is our users. They’re the ones that are gonna be using it at the end of the day.

How design and product management work together

Q. Talk to me about your relationship with product management. Some of what you’ve described here is stuff that I also hear product managers talking about them needing to do, in terms of sharing information across the company, describing where we’re going, all of all of that sort of stuff. Is there a firm line between you and them on what they do? How does that work?

I’ve worked in teams where we are all part of a single leadership team that includes a product manager, so you would naturally all be talking. 

In other organizations, design would be more of a service delivery to product. That is sometimes more challenging because you have a new product manager come in and they want to operate in a particular way. So you do need to build that trust of like, “hey, I’m not here to step on your toes, but we do need to work together and this is how design can help.”

I would really spend time building that trust that design is here to help you achieve what you want to achieve, but we’re the experts in being able to do design the best way. We would be directed by them on what they wanted us to go conduct research on, but I really wanted to emphasize that we are the technical experts when it comes to the approach in how we do it.

So that still allowed my team to feel empowered that they weren’t being controlled, but they were aligning to the goals of the product managers.

The role of Design Ops

Q. I want to ask you about design operations. You referenced that role several times on LinkedIn. I’ve been trying to understand the institution of design ops and the more I learn about it, the more confused I am, because I get very different definitions of it from different places. So what does it mean to you and what role does it play?

In my previous role, we had a developer operations team working within our engineering space. That’s where I saw the advantage of it. To answer your question of what does design ops mean to me, it means having the right processes in place to allow our designers to be the most successful. So it was all around, do our designers use the same tooling? Because when I started, some were using whatever design tool they wanted. Some were using Sketch, some were using Figma, some were using Photoshop. And I’m like, “whoa, this doesn’t make sense.” So it was those sort of basic things to allow a team to operate and grow. It was defining guidelines and asking ourselves questions like “How do we document our things within Confluence?” “How do we work with engineers?” “What are our boundaries?”

It was even going to the point of confirming people’s role descriptions. We had some designers who were doing some sort of frontend development work because they had that skillset. And that was setting an expectation within some delivery teams that all designers can do frontend dev work. And I’m like, no, that’s just that specific person because they’ve got that experience.

So defining roles, defining processes, alignment on tooling, and then also around how do we then amplify the work that we’re doing and how do we tell our stories. 

It was also around creating these processes and guidelines around governance as well. You know, how do we put things into Dovetail? How do we contribute stuff into our design system?

Then a long term goal that I had for it as well was thinking about our own designers’ experience. What is the onboarding experience for our designers? What is the growth path? Like going back to that earlier point around how do we design research as a service. How do we design the experience for our designers and  make it the best that we can? That’s something that I’m working on in my role now and will continue to, I think, throughout my career. I think that’s one of the most valuable things for design ops is how do you create and design that best experience for designers.

Spend time on your internal systems

Q. Do you have any “war stories,” things you’ve done that you were particularly proud of or that worked out really well? Or things you learned that surprised you?

I’d like to touch a bit more around the effort that we put into designing our own internal experiences. Even though we were a small team, like five or six, we were looking at building out our design system, which the organization didn’t at that time have across the business. So we had all these products that didn’t have a unified look or feel. That caused lots of rework, all that sort of stuff.

We went through a process of explaining to the organization why we needed to shift to a design system method, how much it would save in rework. But the effort of us conducting research with our internal developers, our internal designers, brand and marketing, and then playing back here’s the current state of just how confusing everything is, that’s where it was challenging to be able to carve out that time to focus internally.

Sometimes we are very focused externally on just delivering things for our users. But if we’re not looking in-house to fix our own systems, we’re never going to be able to deliver great things externally.

So that sort of looking internally was definitely a lesson for me, about the power that it can bring to the teams. It solved a lot of cultural challenges that we were having. Cross-collaboration, it solved as well. And also it educated a lot of people around our design process because they got to watch it happen. So then when we were doing stuff for users, they had experienced it themselves. And so they knew when we were doing the discovery workshop or whatever, they had some concept around it.

So I was very fortunate to have the support of leadership to be able to dedicate me and someone else to that project. Maybe this is on a bit of a tangent, but as a design manager or design leader to get traction, I believe you need to be hands-on for a period of time. My approach has always been not that sort of, “I’m hands-on command and control, everyone do what I say,” but my approach is, “hey, I’m going to work with two or three other people and I’m going to help them.” And that we’re all kind of in it together.

The light-bulb insight is a shared responsibility

Q. Is there anything else you wanted to be sure that you mentioned that I haven’t brought up?

I really focus on the concept of storytelling. That’s where I think research plays a critical part. We are the storytellers within an organization. Sometimes we are not there with a solution in mind. Sometimes we don’t know what that solution is, and that’s where it’s best for us to tell the story of our users and then include engineers, data team members, whoever it may be to help us get to that solution.

I always found early on in my career that designers were expected to come up with the solution design, the great thing. And what I began to learn over my career is as the digital landscape became far more complex, we can’t be those people that just come up with those light bulb moment ideas and expect it to work. We need to include others as well. So that’s where I always emphasize the idea of storytelling, transparency, and then inclusion of others to co-design or co-build the great customer experiences we aim for as a team.

Construction photo by Alexander Tsang on Unsplash

The opinions expressed in this publication are those of the authors. They do not necessarily reflect the opinions or views of UserTesting or its affiliates.