Companies need design leaders who still design. That’s something I feel strongly about, and I think it connects directly to the shift AI has brought to the role of product designer over the past few years. Designers are no longer expected to just design screens and flows in Figma. Now it’s also about analyzing business data, submitting a pull request, using agents to handle manual work. The bar for what “designing” means has moved, and design leaders need to be close enough to the work to actually understand that shift, not just manage around it.

This applies to any manager or lead in charge of product designers, not just people making a specific jump in title. It’s tempting to think that leading a team means stepping back, letting the team handle execution while you handle “strategy.” But from what I’ve seen, that distance has a real cost.

Why it matters

There isn’t much room left for managers who only manage. Teams need to do more with less, and designers want to be inspired by the people leading them, not just directed. When a design leader can’t design, the team notices. And it shows in the work.

I’ve seen middle management layers collapse when this happens. Not because those managers weren’t organized or good at their jobs, but because they stopped being useful in the room where design decisions actually get made. In my opinion, companies don’t want professional managers who happen to oversee designers. They want great designers who happen to manage: people who can inspire their team to do better work, and who can walk into a leadership meeting and show, through the work itself, how design moves the business forward.

The chef in the kitchen

The best way I’ve found to explain this is through kitchens. Think about how the best restaurants work. The chef is always in the kitchen. Not cooking every single dish, not hovering over every station, but present. They taste, they adjust, they call out what needs to change, and they do it while the line is moving, not after the plates go out. It’s guidance in real time, not a review meeting.

That’s what staying hands-on looks like to me. The chef doesn’t take over a cook’s station just because they can do it better or faster. They correct, and they do it constructively, but they leave room for the cook to actually cook. That’s the balance: close enough to shape the outcome, far enough back that people still own their work.

Where it stops scaling

There’s also a limit to how far this scales. Staying this close to the work only really holds up to a certain team size. Once a team grows past 10 or 12 people, you start needing other roles to help lead and carry the vision forward. At that point, one person being hands-on with everyone isn’t realistic anymore, and the structure itself has to change.

Hands-on, not micromanaging

This isn’t about micromanaging. Staying hands-on doesn’t mean redlining every screen or overriding your team’s decisions. It means staying close enough to the craft that your input still means something, and far enough back that the people doing the work still feel like it’s theirs. I think that’s what separates a design leader people want to follow from one they just report to.

For the first few years of my design career, I didn’t give this much thought. I believed designs should “speak for themselves.” If the solution was strong enough, it would defend itself in any room.

I couldn’t have been more wrong.

Over time, I’ve come to see that a huge part of a product designer’s job is communication. The rest is a mix of collaboration, alignment, visual and UX skills, and business sense — all of which depend, to some extent, on how well we communicate.

For me, the real turning point came when I started managing people. It was almost a reality check: I realized that if I couldn’t communicate well, my impact was going to be limited, no matter how strong my design judgment was. It wasn’t enough to have good ideas in my head. I had to be able to share them, defend them, and help others on the team do the same.

The storytelling gap

I’ve seen designers who are brilliant at execution struggle when it’s time to make their case in a presentation or a meeting. It’s not a talent problem. It’s a practice problem.

Designers aren’t really taught storytelling, while in other business roles, it’s a skill people often develop from the beginning of their careers. When you can’t structure your argument or connect your proposal to what your audience cares about, your idea shows up weaker than it should — even when it’s technically the best one on the table.

This gap becomes even more obvious in product design. Talking about flows, components, or usability principles is no longer enough. You need to sit with product managers, data teams, and business stakeholders, and explain how your proposal can move retention, conversion, or a specific product metric.

When we can’t translate design into that language, our ideas can end up outside the conversations that actually matter.

How you say it, and where

Part of the craft is adjusting your communication to who’s in front of you. Talking to another IC is not the same as talking to a director, a CPO, or a CEO.

Executives rarely want 20 minutes of context before getting to the point. They want to know, in the first minute, what problem you’re trying to solve, what impact it has, and what you’re proposing. The window you get with these profiles is often small, and the moment you start looping or spending time on unnecessary details, you risk losing them.

Learning to adjust your message and your delivery is an art. It takes practice, and it takes putting yourself in those rooms over and over again.

The same applies to writing, which has become increasingly important over the last few years. In remote teams, many decisions happen inside a document, a Slack thread, or the comments on a Figma file. Many designers are strong in person but struggle to bring that same clarity to the page, and that’s where a lot can get lost.

A well-written design document can move a decision as much as a full meeting, sometimes even more, because it stays.

Still learning

Don’t get me wrong. I’m not writing this from the perspective of some incredible speaker with impressive presentation skills. Not even close.

I’m still learning and practicing this craft, and I know I have a long way to go to really sharpen it. What changed for me was simply realizing how important it is.

Now I carry that awareness with me. It works as a kind of self-check that keeps pushing me to communicate more clearly, adapt to the room, and get better at it.

During 2022, I had a pretty clear idea in my head: we needed to get better at understanding our users.

At the time, I was responsible for one design team and had regular conversations with people in Product, managers, and other leaders. There was quite a lot of agreement that we needed to understand our users better. But when it came to the question of how to do that, there wasn’t really a clear answer.

So I decided to do something about it.

The company was growing, and I had some room to propose new hires. We started looking for UX Research profiles and, over time, ended up having two people dedicated to the discipline. I even proposed creating a UX Research Team Lead role to give the new team some direction and structure.

At the time, I thought we were doing the right thing. And for a while, it seemed like we were.

When everything seems to be working

For a good part of 2022, things went pretty well.

We started shaping the discipline, defining how we wanted to work, what kind of research we should do, and how it could fit into our existing processes. Over time, we tried to standardize the way Research worked, give it more structure, and make it easier for Product and Design teams to rely on it.

We were also lucky to have a Product leadership profile who strongly believed in the discipline and supported us. That made us think that this could have a real future.

And perhaps that was the moment when I was most convinced we were going to make it work. But little by little, the friction started to show.

The problem wasn’t doing Research

As time went by, we started noticing something that kept happening. Research was being done, but it wasn’t always being used.

We didn’t have an exact metric for this, but the feeling within the team was that maybe only 20–30% of the research projects ended up having a real impact on decisions.

And that was frustrating. For the researchers, because they were investing time and effort into work that often didn’t lead anywhere. For Product and Design teams too, because research also requires time: defining what we wanted to learn, preparing sessions, waiting for results, reviewing them and, most importantly, having enough mental space to actually do something with them.

And that time was almost never available.

The company had a culture that was very focused on shipping, measuring, and learning quickly. The logic was pretty simple:

Ship → measure → learn → iterate.

And it worked.

The problem was that we were trying to introduce another way of working, which in some cases looked more like:

Research → understand → decide → ship.

I don’t think one approach is necessarily better than the other. But I do think it took me too long to understand that we were trying to fit a piece into a system where it didn’t quite fit.

We tried to fix it

This is where I think one of my biggest learnings comes from.

When we realized Research wasn’t working the way we expected, my first reaction was to try to make Research better. So throughout 2022, 2023 and part of 2024, we kept working on it.

We tried to improve the process. We defined structures. We standardized ways of working. We tried to give Research more visibility. We looked for better tools and budget. I had recurring conversations with the Team Lead, trying to find new ways to give the discipline more space.

And sometimes, it felt like we were making progress. But eventually, we kept running into the same friction. There wasn’t enough time. There weren’t enough resources. And, most importantly, there didn’t seem to be a strong enough need within the organization for Research to become a natural part of how we worked.

With fewer resources, research projects also started becoming more superficial and that created a pretty dangerous cycle. If you have little time to research, you do smaller studies. If the studies are smaller or more superficial, it’s harder for them to generate truly relevant insights. If the insights aren’t relevant enough, teams trust Research less.

Maybe I was asking the wrong question

Looking back, I think I spent too long asking myself the wrong question.

I was asking:

“How can we make UX Research work better?”

When perhaps I should have been asking:

“What decisions does this company need to make, and what information does it need to make them better?”

It sounds like a small difference, but I don’t think it is. Because believing that a discipline adds value is one thing. Understanding what role that discipline should actually play within an organization is something very different.

During those years, I was very convinced that understanding our users better was important. And I still believe it is. But today I also understand that not every company needs to do it in the same way.

There are companies where it makes a lot of sense to invest heavily in deep qualitative research. Companies where making the wrong decision is very costly, or where the information you need simply isn’t available in the data. And there are others where you have millions of users, lots of quantitative data, the ability to experiment quickly, and a culture that is heavily focused on shipping and measuring. In those companies, perhaps the balance between data and qualitative research needs to be different.

That doesn’t mean one company is more mature than the other. It means they have different needs.

The moment when we had to make a decision

By the end of 2023 and throughout 2024, the situation had become pretty clear. The Research profiles were becoming increasingly demotivated. Not having the tools or budget they needed, even after asking for them several times, was starting to take its toll.

One of the researchers eventually decided to leave the company because they felt they weren’t making progress and that the situation wasn’t going to change. Meanwhile, the Team Lead was also struggling to manage a team that wasn’t finding enough space to do its job properly.

Then, in early 2025, everything changed. There was a major leadership restructure, and the company’s strategy became even more focused on speed, quality, data, and the use of AI.

And then I had a conversation with my new manager that, although probably inevitable, was difficult to hear. He said: “Diego, we need to decide what we’re going to do with UX Research. I need a solution.”

After so many years of trying to make it work, the solution ended up being to dissolve the team. One of the researchers left the company, and the Team Lead moved to other projects, taking on a role that was also more focused on Product Design.

For me, it was a tough moment. Not just because something I had believed in for years was coming to an end, but because I had been one of the people who had pushed hardest to make it happen in the first place.

That’s when I started to understand a few things

For a while, I thought I had failed because I hadn’t managed to implement UX Research properly. Today, I see it differently. Yes, I made mistakes.

I probably took too long to understand the organization’s real needs. I focused heavily on building the discipline, and not enough on understanding whether that discipline was actually a priority for the business at that particular moment.

I also learned that hiring people isn’t the same as creating the conditions for those people to have an impact. You can have great researchers, a Team Lead, processes, methodologies, and good intentions. But if teams don’t have time to work with them, if there isn’t enough budget to conduct meaningful research, and if the results don’t become part of important decisions, it’s very difficult for the discipline to thrive.

And perhaps the biggest lesson for me was this: you can’t introduce a new discipline into an organization simply because you believe the organization needs it. First, you need to understand how that organization works. How it makes decisions. What information it relies on. Where it has uncertainty. What the cost of being wrong is. How fast it needs to move. And what kind of knowledge it’s actually willing and able to incorporate.

Would I do it again?

I think I would. But I wouldn’t do it the same way. I would still advocate for the importance of understanding users. I’d probably still look for ways to bring Research into the organization somehow.

But before hiring anyone, I would ask many more questions. I’d try to understand what problems we’re actually trying to solve. What decisions we want to improve. What kind of research we really need. Who is going to use the findings. And, most importantly, whether the organization is ready to do something with what we discover.

Because perhaps that was my biggest mistake. I thought the challenge was building UX Research. Now I think the challenge was much bigger: creating the conditions for UX Research to be useful. And those two things are not the same.

Today, I don’t look back at those years as wasted time. It was an initiative that ultimately couldn’t survive within the organization. But it was also one of the experiences that taught me the most about leadership, culture, strategy, and, above all, how difficult it is to change the way a company makes decisions.

Sometimes leadership isn’t about making something survive. Sometimes it’s about knowing when it’s no longer worth pushing. And I think that’s part of doing our job well, too.