“I heard uninstalls were up when I started this project.”

A client mentioned this to me offhand, not realizing it was the core of her work story.

It sounded like a simple ask: users were experiencing notification fatigue because the app kept triggering. She went in, simplified the system, and reduced uninstalls.

Now picture how you’d write that up for your portfolio.

She wrote what she knew from a UX perspective: I reduced cognitive load by streamlining the notification system, resulting in a measurable drop in uninstalls.

It was true, and it showed her competency. But employers were going “cool” and forgetting by the next slide. Why?

Cognitive load describes the mechanism of the work and stops short of the stakes. It read like “things were hard for users” without explaining what that resulted in.

She wasn’t sure what else she could say. Then I spent forty-five minutes researching her company.

The design work hadn’t changed. But once you understood the larger context, the same project told a far bigger story, one that showcased the value of design at scale.

What the brief left out

Here’s what her brief didn’t say, and what her company was going through.

Her company was a fast-growing startup with over five million users, and it was taking a one-two punch. It was in the middle of one of the hardest transitions a product can face: moving people from a free model to a paid one.

It had also just come through a controversy that drove 1M users to leave the product and uninstall.

Put that next to her project, and the notifications stop being the story. Yes, users were frustrated with notification fatigue, but the real question was: how do we rebuild user trust at this crucial time?

Every lost user wasn’t just the user base bleeding out. It was a missed opportunity to convert someone to the paid model.

So the second version of her case study read like this: The company was mid-transition from free to paid, right after a controversy that had shaken user confidence.

We had a high number of uninstalls, and I was handed a project to fix notifications. My work didn’t just simplify notifications: it gave users a reason to trust the app again.

Same designs. Same outcome. But it tells a much bigger story, one that interests far more people.

The skill is diagnosis, not decoration

It's easy to read that as a storytelling trick: same facts, fancier words. But the difference is about knowing the kind of story you’re telling.

She didn’t know it was a trust story. She thought it was a notifications story, and she would have presented it that way on the job or in a portfolio review.

It wasn’t that she was hiding the business stakes. She genuinely couldn’t see them. That market context, the free-to-paid pressure and the controversy, just isn’t something most of us are aware of.

The design brief didn’t mention it. Her users didn’t mention it. It lived in earnings calls and press coverage, exactly the material that designers never read.

That’s because it’s usually lumped into market research. We’re trained to think about what users need, where they struggle, and what they’re trying to do.

Meanwhile, somewhere else in the building, someone is studying the market: who the target buyer is, who the competitors are, and what drives people to buy or to leave.

The two halves are about the same product, but they often never meet. User research told her notifications were the problem. Market research told her why anyone upstream cared.

More importantly, you can still do this, even on a project you finished years ago.

Why market research still works, after the fact

There’s a version of this article that says: do market research before you design, so you target the right audience. That’s real, and for some teams it saves expensive pivots.

But even if you’re staring at projects you haven’t touched in years, you can still make use of market research.

If you ship something and you have feedback that it’s good, you can look at market research to answer one of the hardest questions designers run into: What is the impact of my designs?

You don’t need anyone’s permission, either. Between press releases, shareholder meetings, company blogs, and more, most of the research is already out there.

The work is yours, the results are in, and you can do it yourself. Here’s how.

Understanding value, with AI

The good news is that the digging used to take a week, and now it can take an afternoon.

The raw material is all public: press releases, shareholder letters, news coverage, company blogs, and it’s exactly the stuff the business itself cares about. Why?

Companies love to brag about wins. Whether it’s to look like a great place to work or to let executives point to results under their leadership, if your designs got implemented, the value of your work is out there somewhere.

But you don’t have to read every piece of public data to find it. You can ask AI to synthesize the public sources and answer five specific questions (with a guardrail at the end).

• What was the state of the company at that time? If you took on this project in September of 2024, what were the company’s conditions then? Were they growing? Had they just come off a bad quarter? This context often surfaces market pressures you weren’t aware of.

• Who were the main competitors, and what were they doing? This, alongside the question above, is often the biggest thing to figure out. If a direct competitor had just shipped a feature customers were asking for, that’s often the unspoken reason design got pulled in.

• How was the business making money? This is a blind spot for many designers. Was your project for existing paying customers or new users? Was it a market pivot, or delivering on a feature people were requesting?

• Given all that, what business problem was my work actually solving? Once you’ve thought through those three questions, this is the connective tissue designers usually miss. You weren’t just updating notifications. You were running a quick win to help regain users’ trust.

• What business metric did my outcome actually move? In an ideal world, this is something you’d already know. But sometimes you never get to hear it. If you were told in passing that uninstalls were up, did they go down after you shipped?

Just be aware that this isn’t the final story.

The last step isn’t a prompt

The catch is the same one that’s always true with AI. It might get you eighty percent of the way there, but you can’t trust it completely.

You might find that the market context points to a trust problem. Before you commit to that story, check it against proof.

That might be an actual earnings call from the quarter, or, better yet, five minutes with the PM you worked with. A specific question will usually get you the answer you need:

“Hey, looking back. That notifications project, was it tied to the trust stuff after the controversy? Did it actually help?”

That one question does two things a prompt can’t. It tells you whether your reconstruction is sound before you build a case study on it. And it puts your thinking on the radar of someone who decides what gets noticed.

Design work can’t stay invisible

For a long time, the job was to take a brief and execute it beautifully. Craft was the whole game. But craft was never what held designers back. Communication was.

The ability to spell out how design work, especially invisible work, connects to tangible business outcomes matters more than ever.

Market research has always been part of that conversation, but it used to feel out of reach. Too much data, too far outside your job description, too hard to synthesize.

AI has changed the math and made it accessible. A few good questions and a focused afternoon can now give you the missing context that turns your work from “UX-centric outcomes” into “larger business impact.”

So go reopen the case study you’re proudest of. Ask what business problem it was really solving, what the company was worried about when it landed on your desk.

You’ll probably find the project was bigger than the way you wrote it up, and that you’d been underselling your own work without knowing it.

Struggling to translate your work? Book a chat to talk through what you’re working on. Communication is the soft skill many designers need to level up.

I help Senior and Lead designers (and beyond) learn to tell their work story, to land jobs, get buy-in, and gain influence. I write weekly about what I’ve seen across 250+ design interviews in The Designer’s Field Guide.

Drastic ‘transformations’ are happening overnight, and it’s causing designers undue stress.

You’ve probably seen this before. Someone who used to be disorganized suddenly gets a lot better.

They used to struggle to keep notes; they’d forget to follow up, and now they’re suddenly sending agendas and clean summaries with tasks attached.

Probably using AI, like most people are. Maybe it’s unauthorized AI, plugging sensitive company data into Claude or ChatGPT and asking for meeting notes.

But when everyone else is moving faster, from organization to meetings to agendas, the pressure gets passed to you as well.

Engineering is claiming 10x output on AI-written code. Your PM and your VP are moving fast, and they’re asking you for things: a quick documentation request, high-fidelity prototypes by Monday, all that other stuff.

How do you say no? That’s the million-dollar question, and it’s harder than you realize.

Why designers struggle, and why creativity is a tough sell against AI

The good news is that AI isn't replacing designers. The companies that tried it have mostly produced case studies in what not to do, with failed products and millions of dollars lost.

But all the things that used to take a while now move faster.

People can vibe code something in an afternoon.

They can generate roadmaps, tech initiatives, meeting summaries, all of it, and make decisions quickly off the back of it.

So taking three weeks to sketch out screens is no longer an option.

It gets your company to think: maybe we need a designer who can move faster.

That’s what Jakob Nielsen said a couple of years ago in his UX Tigers post.

“Designers won’t be replaced by AI, but you might be replaced by a designer who knows how to work with AI.”

So you’ve been forced to work faster and faster. You’re overwhelmed with additional tasks, and there’s no time to slow down for user research or anything like it. What do you do?

You don’t make it a question about capacity. Capacity is how we used to talk about this.

• "I’m working on these three things, I don’t have capacity for the 4th.”

That works when there was a standardized process and no way to drastically shorten timelines.

But design has a problem other fields don’t face: Legibility.

Peter Merholz wrote about design’s legibility gap a couple of weeks ago, and it comes down to one question: what unit of measurement does the organization use to track design?

Engineering has tickets, burndown, hours, features. Very high legibility.

They have tickets that take X hours. Once they check off the tickets, a feature gets developed, tested, and moved into production.

Design’s legibility problem is different. Design gets measured in screens. That’s the main thing.

Yes, user research exists; yes, you ran a workshop, but the unit the organization actually tracks is screens and features.

So when a PM can go to an AI and say Make the screen, and the screen shows up in an afternoon, your team’s sense of what design work costs gets skewed.

You’re working on three projects, and they ask for a fourth.

They’re thinking it’s a small lift, maybe two or three screens, and they generated a screen in an afternoon, so what’s that, two or three days?

That’s how time gets wrecked, and that’s why designers are under so much pressure.

Displacement is the solution

Archimedes, as the story goes, figured out something nobody else could at the time. How much water gets displaced, and how that relates to volume.

The answer came to him when he got into a very full bathtub. He noticed the water got displaced when he got in.

It overflowed and flooded the room, and that’s when he realized how you’d measure it. Get in the tub, collect all the water that comes out, and you have your volume.

Capacity is part of this conversation: “I have three projects; I’m really busy; I can’t squeeze in a fourth.”

But when people’s estimates get skewed? Make it about displacement.

The displacement conversation is different. “Okay, I hear that you want this. Which of these projects should I put on hold?”

Capacity is:

• “This bathtub is really very full. I don’t think I can fit in here without something going wrong.”

Displacement is:

• “Okay, water is going to flood the bathroom once I do this. We can do that, or scoop some water out, or something else.”

You’re not arguing if water if overflow automatically. You’re saying, okay, this WILL happen.

This way, you’re turning the conversation back to the person asking. What would you like to put on the back burner?

This makes people think, because it reintroduces friction. Maybe this person wants to deprioritize a project belonging to a PM, so now your VP has to go negotiate with that product manager.

Either the PM says yes, and you’ve taken one of your responsibilities off the plate. Or maybe the request just disappears, because it’s not free.

Regulate workplace stress related to AI

A lot of designers are feeling fatigue around AI.

It’s not just about learning newer tools. It’s about managing relationships and perception around AI.

If a company thinks that AI can do your job in an afternoon, they just won’t keep you around.

But that can lead to a dangerous mindset.

“Hey, this should be a quick thing; can you tackle this in the afternoon?” Is a conversation many designers dread.

And it can feel impossible to say no.

Until you make the conversation about displacement. Point out that things WILL fall through the cracks based on the choices they make, and people will be less willing to pile stuff on your plate.

Want to learn how to have more productive conversations at work (and grow your career)? I teach designers a storytelling framework that showcases their value, on the job and in the market. Book a call to learn more.

Photo by Felicity Tai : https://www.pexels.com/photo/employees-on-a-conference-room-7964146/

“I feel really bad for our design Leader. We’ve all been using Claude design and Figma Make, and it’s really tough for him to justify things.”

This is what a VP of Product told me the other day, at a kid’s birthday party. We were casually chatting about work, and he could see that the design at his org was struggling.

Not in producing design work. Justifying their work.

This was a company embracing AI for survival. From Claude Code to Figma Make to Cursor across the org. They were churning out designs and laying off the design team in the same quarter.

But here was the wild thing: they knew the designs weren’t good. They knew the design debt was piling up faster than they could ship. Given the choice between fixing what was breaking and generating features that might get them acquired, they built new ones every time.

“At the very least, I wish we had someone to minimize these problems.” The VP said.

That’s the design responsibility that’s emerging. And it runs entirely on language.

The problem has only grown with AI

A senior design leader I talked to recently has performed on stage as a classically trained musician. She has 2 decades in design, in companies you’d recognize.

But one problem ran through her whole career: presentation anxiety.

“My manager at the time was asking me, you know, what are you thinking about when you’re presenting? I just told her, I am thinking about how I can take that chair, break that window and jump into the river, calculating if I’ll survive or not.”

She’d done the user research. She knew what the right path forward was. But the words tangled up in her mind.

In the silence between knowing and saying, her brain started doing physics. The gap has been there for many designers. AI has just made it more costly.

Design is mostly re-designs now

I’m not writing from Silicon Valley’s frontier. I’m writing from where most designers actually live: companies that aren’t building AI but are buying it, deploying it, restructuring around it because they think they have to.

In those companies, the work is already changing shape. Engineers are auditing PRs that someone vibe-coded.

Designers are re-designing Figma Make mockups a PM generated over coffee. The center of gravity is shifting from making the artifact to evaluating it.

By the end of 2025, more than half of Figma’s biggest enterprise customers were building in Figma Make weekly. A quarter earlier, it was 30%.

More people than ever are taking a crack at design sketches, which means craft isn’t enough.

For many designers, the craft WAS the argument. Since people didn’t have a clear idea of what the final product would look like, they relied on you to generate your best ideas.

AI changed that. Now, even trust runs against you.

When an engineer looks at broken code that’s been vibe-coded, the org trusts them to fix it. A bug is a bug, and engineers still have final say.

Designers haven’t always had that, because everyone can design (or thinks they can). So when a PM says, “look, I made this in Figma Make, let’s ship it,” design’s answer can’t be “this won’t work.” Because it sounds like two opinions about a thing that already exists.

The thing that already exists usually wins.

You’re a senior designer, and you saw something created in Figma Make. You can see, in 3 seconds, that’s wrong. The information architecture is messed up. You can spot 2 places where users will get tripped up.

This is where critical thinking is supposed to kick in.

What critical thinking actually is

“Designers need critical thinking” is one of those phrases that gets thrown around a lot, so let’s explain what that means.

Critical thinking isn’t spotting the flaw. You already do that. Look at any Figma Make output, and you can feel in three seconds where it breaks.

The hero is doing too much. The CTA is louder than the decision it’s tied to. The hierarchy is composed but behaviorally incoherent.

That’s craft. You feel it.

Critical thinking is the next move. Translating that feeling into language that a non-designer can act on.

Because the artifact, the Figma Make screen, exists. You can click it. Your critique needs to be as tangible in people’s minds as it is in yours, or it loses.

Figma’s own 2025 AI report found that 78% of users say AI significantly enhances their efficiency. Only 32% say they can rely on the output. That gap is the job.

Critical thinking, operationally, is making your critique more concrete than the artifact you’re critiquing.

• “The banner is too big on the home page.” Probably gets ignored.

• “Do we want people to create an account or click on our banner? Because the banner is so big, it seems like we’ll drive traffic away from the ‘Create an Account’ button.”

That argument has a greater chance.

The root of both of these ideas is probably the same place: your taste as a designer. You know, at a glance, what is likely to be a usability problem or what’s likely to break.

But until you surface behavioral consequences, or the larger product/business outcome? You’ll be stuck justifying.

When you can do the translation, the fight is fair. Losing a fair fight is fine. You made your case, the org made its call, and you live to design another day. Losing the same fight every week because the language wasn’t there: that’s what causes designers to burn out, and people to question why you’re in the room.

How to get started at your workplace

Every screen has a path the user must take for it to do its job.

Onboarding step 2: see context, check this box, click next. Multi-page form: parse the field, fill it in, move on. Checkout: review, confirm, pay.

Most design pushback skips straight to what’s wrong: the banner is too big, the CTA is buried, the form field is confusing. You’re pointing at problems before establishing what success looks like.

The practice is to flip the order. In front of any AI-generated mockup, ask yourself two questions, in this order:

1. What’s the path the user has to take for this screen to do its job?

2. What’s competing with that path?

Everything you spot (the visual hierarchy, the information architecture, the friction) becomes an answer to question 2. But it only carries weight because you answered question 1 first.

You can practice this alone tonight. Open any product you use and ask the two questions. The room comes later.

The verbal version is shorter. When the Figma Make mockup goes up, ask: “What decision are we trying to get the user to make on this screen?” The PM has to answer in business language.

Once they do, you’re not arguing about the banner anymore. You’re arguing about whether the banner serves the decision. Craft and translation are on the same side.

The craft is still the work. The sentence after the craft is the job now.

Want to understand how to learn how to build critical thinking to accelerate your design career? I teach designers how to do this, with step-by-step frameworks. Book a call to learn more.

“I am trying to show the value that I brought. But it seems I’m failing.”

Cheyenne is a senior designer with more than a decade of experience, but she had one specific problem: her best work is small.

Sometimes, your best work isn’t part of a company-wide AI initiative with a $17M budget attached. Sometimes, it’s the “one quick thing” she got asked to do that turned into some of her best work.

The key to translating that kind of impact isn’t to fudge the scale. It’s to talk about the problem in more detail.

The ask sounds simple. The problem isn’t.

In 2016, Meta (then Facebook) had a problem that would shape future social media interactions: people didn’t know how to react to a funeral announcement.

Hitting “Like” on news that someone’s uncle died felt wrong. But 90% of Facebook’s traffic came from mobile, where typing a comment was real friction.

So most people stayed silent, and Facebook watched whole categories of human moments slip past the platform, including grief, sympathy, and shock.

The brief was straightforward: build a Like alternative, one tap, that covered the full range of human emotion.

The artifact they shipped looked simple. Six animated emoji. Love, Haha, Wow, Sad, Angry, alongside the original Like.

The work underneath the artifact was not simple at all. Geoff Teehan, one of the design directors who led the project, wrote up the process on Medium.

Over a year of global research. A soft launch in three countries. They cut two reactions during testing because no one used them. A late realization that static prototypes didn’t work, and that animation was what made the reactions feel human.

And under all of it, a constraint most companies never face. Facebook’s entire business ran on the Like button. Every change risked breaking a behavior that hundreds of millions of people did every day without thinking.

That is what shipping six emojis actually meant. Which leads to the question that catches many senior designers off guard: how do you describe work like that?

Why relying on visuals isn’t the answer

If you asked a designer who worked on Reactions what they did, a lot of them would tell you, “I designed the reactions.” Maybe “I worked on the animations.”

The screenshot tells the same small story. Six little faces. Anyone could have picked six little faces.

What the screenshot can’t show is the dozen decisions underneath each one. Why this set of emotions and not another? Why animation and not static?

How to introduce something new without destroying the behavior that built the company. The taste and judgment that produced the result aren’t visible. The artifact just shows the result.

This is the communication problem I see senior designers run into constantly in case studies and portfolios. The visual does all the talking, and too many decisions are buried beneath it for it to carry.

Mary, a senior product designer in EdTech, put it this way: “I was very proud of the invisible work that was done. The stuff that’s not translated in visual design.”

She named the whole problem in two sentences. A ton of invisible work went into it, and visuals alone can’t show it.

Where designers get tripped up

The invisibility isn’t just external. The designer who did the work is usually the first one to undersell it.

“I just designed the reactions.” “I tweaked the interaction.” “I cleaned up the flow.”

This is what senior designers actually sound like when you ask them about their work. They don’t brag or exaggerate. They describe what they did, not what it took. They’ve seen patterns like this a thousand times.

They know the best practices, the industry standards, and the shape of the problem. So, of course, it felt manageable.

But “manageable for me” and “small piece of work” are different sentences, and senior designers blur them constantly. It’s the same reason “another routine operation” sounds incomprehensibly complex to anyone outside the OR.

Other people hear that language and take it at face value. Why wouldn’t they? The person who did the work just told them it was nothing.

Over time, the designer starts to believe their own framing. After enough cycles of describing the work in flat terms, the designer can’t quite remember why it felt bigger than the way they describe it.

How to make the work show up

The fix isn’t to oversell. It’s to describe what actually happened once you’ve thought about the larger problem.

The move is simple: ask “so what” until the real problem shows up.

UX goal: Design an emoji-based alternative to the Like button to enable easier interactions.

Why does this matter? Users get a way to express nuanced emotions beyond “Like.”

So what? They can engage appropriately with all types of content, including celebrations, sad news, and surprising updates.

So what? That comfort increases overall engagement, because people feel comfortable interacting with more posts.

So what? Higher engagement means people spend more time actively participating in their News Feed.

Product outcome: “Created new emoji reactions” becomes “X% higher engagement by getting more users to actively participate in their feed.”

There are other steps in this process. You may need to learn a bit about metrics to understand what “engagement” means in your context.

But this is how a small solution can solve a huge problem, and how you have to talk about it. A dozen small decisions, otherwise invisible, become legible when you describe the problem in larger detail.

Designers are often too humble

In the 250+ conversations I’ve had with Senior Designers & Design Leaders this past year, the pattern that comes up most often is that designers tend to be humble in a way that doesn’t serve them.

They love the craft. They talk about the things they’re most proud of, the parts where they built a beautiful solution. But they often fail to put that solution into context and explain why it mattered.

This shows up in performance reviews, case studies, portfolios, and interviews, where designers lean on visuals and beautiful experiences rather than making bold (but logical) claims that they affected the business.

Missing this translation has a cost. Businesses today don’t just want craft. They want senior designers who understand how design affects the business and why it matters.

If you can’t answer those questions, the work isn’t the problem. The translation is. And it’s not as hard as you might imagine to solve.

Struggling to translate your work? I help overworked designers land Senior, Lead, or Principal Design positions by telling their story. Book a chat to talk through what you’re working on.

One hour, five days a week, I message strangers online.

That’s around 260 hours a year I don’t spend writing, working with clients, or spending time with my family.

I spend it talking with people who sometimes block me, say ugly things, or just reject me. But that wasn’t what was eating at me recently.

It was that this was on my calendar, renewing every Monday, from now until infinity. And the only exit seemed to be admitting that my business would die.

This is why an experimental mindset matters, and it’s not about success at all.

Experiments end.

Most of us are terrible at stopping

You’ve probably seen this, one way or another.

Someone stays in a bad job (or relationship) for three more years.

Someone survives a toxic team and calls it resilience.

Someone spends the entire education budget every single year on another certification, because that’s the official path, and the official path is supposed to lead somewhere.

None of those people are dumb. They’re stuck in the same trap I was in recently, where stopping feels like losing.

When most people say “Cold outreach is just part of running a business”, they’re partially right.

I can’t pay my bills unless I talk to people.

But there’s more stuff under my control than I realize, when I started adopting experimentation:

I control the action, and how long I run it. That’s the whole lever.

A pact is not a formal experiment

Anne-Laure Le Cunff, author of Tiny Experiments, doesn’t like to actually call these things experiments. She calls it a pact.

A pact has two parts. A duration and an action.

For twelve weeks, once a week, I will write up the agenda for our team meeting and send it out.

That’s the whole thing. No hypothesis. No success metric.

She calls it a pact because experiments get designers tangled up. Bring up experiments at work, and people think of p-values, sample size, minimum detectable effect, sampling bias.

That’s the organizational version, and it matters enormously when you’re running research that affects other people, users, or the entire business.

A personal pact is a different animal. It measures whether you did the thing. Nothing else.

Which sounds like a nice-to-have, until you notice what it buys you.

A Japanese woman taught the world the solution

Back when Marie Kondo took the world by storm, one central insight stood out: how to declutter.

We keep stuff we never use because letting go is hard.

The guitar is still in the closet after three lessons. The microbrewing kit is in the garage, used twice.

There’s a ball of tangled yarn and a bin of crochet supplies somewhere.

You’re going to get back to it when work calms down. When it gets easier. One day.

At work, it’s the same thing. The old design library nobody wants to scrap.

The workshop software still on the invoice, so you schedule a workshop to justify keeping it.

The critique ritual you keep restarting, even though it has collapsed twice already.

And we treat it all as binary. Either we make the thing work, or we fail. That framing leaves no third option, and it ignores context completely.

Maybe the critique is impossible to maintain because your design team got cut in half. That isn’t a failure. That’s a different situation.

But the wording is marketing genius.

The language is marketing genius

Wording does a lot of work here, and companies know it.

Go cancel a subscription sometime and actually read the buttons.

Are you sure you want to quit? You’ll lose your progress. Your streak ends today. Cancel my membership and give up my discount.

Those are high-impact words, chosen on purpose. Quit. Lose. Give up. They’re built to make leaving feel like a small personal failure. And it works.

I have absolutely backed out of a cancellation flow because I didn’t want to be the guy who gave up on Japanese.

Then we turn around and use those same words on ourselves. On projects nobody is charging us for. And we end up trapped by things we never agreed to in the first place.

Persist, pivot, pause

Le Cunff suggests a better alternative. Once a pact has run its course, she says it’s the perfect time to reflect and take one of 3 moves:

Persist. Your once-a-week meeting notes are working, so keep going. Turn the twelve-week run into six months.

Pivot. Something’s off, but the idea is sound. You’ve got five meetings a week and once a week isn’t enough, so you go daily. Or you drop the general notes and only do it for strategy meetings.

Pause. You stop.

Look at that third one closely, because it’s doing something sneaky. Pausing and quitting are essentially the same action. The difference lives entirely in the word.

Quitting means you failed at it. Pausing means maybe in five years, maybe in two months, you might pick it up. Or you might never pick it up.

That’s the trick. It’s psychologically easier to pause something than to quit it, and pause gets you to the same place.

What you actually get

Less junk, first of all. You’re not hauling a habit around because stopping would be an admission.

And you get honest about tradeoffs. Say the meeting agendas cost you two extra hours a week. That’s real. But the PMs loved it, the meetings got shorter, people showed up prepared.

So you stick with it for another three months and decide again later. Or the two hours were wrecking your week, and nobody noticed either way, so you pause and move on.

Either answer is fine. That’s the point. You set the duration up front, so the end of the pact becomes a scheduled decision instead of a crisis.

Try one

If you’re a UX team of one, which is how I spent a good chunk of my career, or you’re stuck on how to reach the next level, or you’re just not sure what your next move is, run a pact.

Pick an action. Pick a duration. Twelve weeks, once a week.

Then give yourself permission to pause it.

I’m doing this with the outreach. Eight more weeks at an hour a day, five days a week, and then I sit down and look at what actually happened.

Do I persist, because it’s working better than I think?

Do I pivot and change how I’m doing it?

Or have I found a different way of getting clients, so I can pause this one?

I don’t know which yet, and that’s sort of the point. But having a date written down changes the mornings. Rejection is a lot easier to walk into when it isn’t forever.

That outreach hour is really about this.

I get designers onto the shortlist for Senior, Lead, and Principal roles. Not just the first interview: the final one, where it comes down to you or another person.

You tell me your story on a call. I write the portfolio, presentation slides, and interview scripts that get you there.

If you’d rather not wait for me to turn up in your DMs, learn more here: https://theshortlistedportfolio.com/

Photo by Pavel Danilyuk: https://www.pexels.com/photo/a-man-sitting-on-the-bed-while-playing-with-the-robot-8294758/

If you’re a designer working on agentic AI right now, congratulations. You might have just gotten your first experience as a design manager.

Most AI projects can still be approached like traditional design work. Agentic AI is different. The main challenge isn’t the interface. It’s management.

What is an agent hired to do, what can it decide on its own, and when does it need to come find you?

Answering those three questions can make agentic AI design a whole lot easier.

“They were going outside to ChatGPT. They wanted to do it in our product.”

That’s how Karen, a senior UX designer, described the project that became her first real agentic build:

“Customers wanted to upload a job description and get an appropriate salary range, including location and years of experience, from our database. They were going outside to ChatGPT to try to do it. They wanted to do it in our product, in just a few seconds.”

That’s how a lot of agentic AI work starts right now. Customers are already doing the thing somewhere, in ChatGPT, in Claude, in a tab next to your product. The job is to bring it inside, on terms that work for your users and your business.

The brief says “make it agentic.” The reality is more specific than that, and the designer in the middle is the one figuring out the difference.

What is agentic AI, really?

When people say agentic AI, they usually point to Claude, ChatGPT, or Figma Make. From the outside, it looks like a chatbot. You put in a prompt, and the agent responds.

The difference is that agents act. They book the flight. Send the email. Pull the report. Match a job description to a salary range and return the matching salary range.

https://www.logicgate.com/blog/what-is-agentic-ai-a-new-frontier-in-artificial-intelligence/

Anthropic, the company behind Claude, defines agents as LLMs autonomously using tools in a loop. The keyword is autonomously. The agent isn’t just answering. It’s deciding what to do next, taking the action, and going again.

Greg Nudelman, in AI in UX, frames it from the design side: workflows are sequences a person walks through. Agents are systems that walk through sequences for the person.

You’re not designing a tool where the user evaluates one suggestion at a time. You’re designing a worker who acts on the user’s behalf, even when they’re not watching.

Which is why the first thing to figure out is what the agent is actually for.

What is this agent hired to do?

Agents tend to fall into two buckets: generalist or specialist.

A generalist handles many things shallowly, closer to a customer service replacement. Someone comes in with one of fifty different problems, and the agent’s job is to sort it, figure out what to do, and either resolve it or route it.

The line between a generalist agent and a regular chatbot is whether it acts. Kore.ai puts it bluntly: if it can’t issue a refund or change a flight without a handoff, it’s not an agent. It’s a fancy FAQ.

A specialist trades range for precision. Instead of fifty things, it handles one. Karen’s agent matches job descriptions to salary ranges.

It won’t draft the JD, pressure-test the market, or recommend a candidate. But it can find the exact range for a Software Engineer in Raleigh with five years of experience and React on the resume.

This isn’t a small distinction. It changes how much trust the user has to extend, how much error tolerance you can build in, and how the agent should behave when it hits the edge of what it knows.

A generalist who says, “I’m not sure, let me transfer you,” feels reassuring. A specialist who says the same thing feels broken.

What’s in the job description?

Here’s where the brief gets blurry.

When a designer is told to “design something agentic,” they’re rarely being asked to define the agent itself. The technical capabilities and integrations are decided. The boundaries of autonomy are decided, or at least sketched.

What’s left is everything that happens between the user’s request and the agent’s result. That’s the product.

Take Karen’s spec: “match an uploaded job description to an appropriate salary range from our database in a few steps.” It describes an outcome, not a product.

How does a user upload a job description, and how complete does it need to be? What does the user see while it’s working? What range does the agent return when the match is uncertain, the role is unusual, or the data is thin? How does the user override it? How do they trust it next time?

None of that is in the spec. All of it is in the product.

So before you design anything, ask: what is this agent allowed to decide on its own, and what does it have to hand back to the user?

You have a direct report who is eager, willing, and works 24/7. The question isn’t whether they’ll do the work: they will. The question is which decisions you trust them to make alone, which ones need sign-off, and which ones they should never touch.

The temptation is to let the agent do as much as possible, because that’s where the magic feels biggest. It’s also where the support tickets live, and the customer headaches. The discipline of agent design is figuring out the handoff.

Before you open Figma, do the two-column exercise

Write two columns on a piece of paper.

• Column 1: What can the agent do without asking?

• Column 2: What does the agent have to ask permission for?

Force every action the agent might take into one column or the other. No middle ground, no “it depends.” If you can’t decide, that’s something to figure out now, not later.

Every screen you design after this is downstream of the list. It’s uncomfortable because you’re committing to trust boundaries before you have any data. Do it anyway.

Then the harder follow-up. For everything in Column 1, ask: how does the user find out it happened? A notification. A summary email. An audit log they can review later. Or sometimes, just a small mention. Understanding how in the loop a user needs to be is key in making sure they still trust agents.

For everything in Column 2: what does the permission moment feel like? A modal that blocks. A toast they can confirm in passing. A pre-approved setting with a “change this anytime” link. The right answer depends on the stakes, but it’s the designer’s call, not the spec’s.

This is the work the spec doesn’t capture. It’s also where most agent products quietly fail.

Is the agent running the meeting, or sitting in on it?

Once you know the scope and the decision boundary, you can consider how the agent appears in the interface. There are two main patterns, and the choice comes down to who’s doing the work.

Full-screen. The agent is running the meeting. The chat log is front and center, history is preserved, and the conversation is the work. This is what you see in Claude or ChatGPT. The agent is the user’s interaction partner, and everything else is the supporting cast.

Side sheet. The agent is sitting in on the meeting. It rides alongside the work, suggesting next steps and handling the small stuff while the user stays in the main flow. This is the more common pattern in modern software, because most agentic AI isn’t replacing a workflow. It’s accelerating one. The agent is a tool, not the destination.

Both are legitimate. The mistake is bolting a chat interface onto a product that didn’t need one.

The optional transparency question: volume.

Volume is where a lot of agent UX gets uncomfortable. The default instinct is to show everything the agent is doing, in the name of transparency.

In practice that feels like working next to someone who narrates their own thoughts. Quiet, well-timed agents feel more trustworthy. Chatty ones feel exhausting.

How loud is the agent? Does it pop up unprompted, or wait to be asked? Does it interrupt with a modal, surface with a toast, or sit quietly until the user looks? Does it narrate every step, or only speak up when it’s done?

Get volume right, and people forget the agent is there until they need it.

Three questions, in order

What is the agent hired to do? What’s in the job description? Is the agent running the meeting or sitting in on it?

If you’re stuck on an agent project right now, don’t open Figma. Open a doc and write the two columns. When you realize that agentic AI is more about understanding boundaries and maintaining trust (like a good manager), designing agentic projects becomes much easier to work through.

Working on AI Agentic projects and need a thought partner? Book a free 30-minute fit call to talk through what you’re working on.

The first time I ever got chewed out at work, it was because I was asking questions.

I was a mid-level designer working for an extremely siloed organization. I saw a connection between two teams building related things, so I reached out to learn more about a project that wasn’t mine and to offer some shared insights.

My manager pulled me aside and lectured me afterward.

“You are under my department, not theirs. Why are you talking with them? This feels like you’re trying to switch departments.”

She was typically pretty nice, but that was the angriest I’d ever seen her. So I took the lesson and shrank back, the way you do when you’re still figuring out how organizations work.

Questions are a liability. Whatever’s going on in the other silo, somebody else is paid to wonder about it.

That was ten years ago. Since then I’ve interviewed 32 top design leaders about how design has changed in 2026, and one word keeps coming up.

“You either have it or you don’t, and I think that’s the suckiest part of this, but it’s true… If the curiosity is not there, then the question is, maybe design is not the right discipline for you.” — Head of Design, SaaS

Curiosity is the answer. Curiosity is what survives AI. Curiosity is how you grow as a designer even in this messed-up job market.

Fine. I believe it. But I was curious in that hallway, and it cost me, so “be curious” was never the advice I needed. The advice I needed was about delivery, like most designers.

What I eventually figured out is that I’d made four separate mistakes that afternoon, and none of them had anything to do with my curiosity.

First, though: the wall, and terrible advice

Plenty of leaders told me the fear is self-inflicted.

“Up until the point where someone tells you that you’re not allowed to do that — screw it. Just do it. What’s the worst thing that can happen? I’ve yet to get to the point where somebody is like, ‘you totally wasted my time.’ From a very junior role to a very executive role, I’ve never had that experience… People are much more willing to help you get to the end result you’re trying to drive than folks anticipate.” — Head of Design, SaaS

He also put his finger on where the silence starts, and this one I recognized immediately:

“Designers discount their business acumen and understanding of data points, not because they are bad at it, but at some point someone told them that it’s not their job.” — Head of Design, SaaS

Someone told me it wasn’t my job. I believed her for about four years.

And I’ll be honest: just do it is the advice I would have hated at 28.

Easy to say as a Design Head where the organization loves design. Or as an extrovert who appears to build relationships in their sleep.

A Head of Strategy and Design at Europe’s largest retailer named the barrier closer to how I actually experienced it:

“The thing that can stop them is that it feels intimidating. You might have to ask a bunch of different teams for permissions, you need to get trained in different things.” — Head of Strategy and Design, retail

Both camps are describing the same wall from opposite sides. The people telling you to just ask are probably got over it years ago, in increments too small to notice at the time.

By now it doesn’t feel like a wall they cleared. It feels like something they’ve always been able to do.

The wall is real, especially if you’re junior, or shy, or new. It’s also thinner than it looks, if you know how to knock.

Some rooms are political enough that nothing you do will save you, and there are managers who will read any question as a threat no matter how carefully you frame it. I’ve been on the wrong end of that.

What follows improves your odds, but it won’t make you bulletproof, and getting shut down after doing everything right usually says more about the company than about you.

So here are the 4 parts to tear down that wall, which I didn’t do.

1. I never gave her a because

I told the other team why I was reaching out. It didn’t occur to me to tell my own manager.

From where she sat, a designer on her team started spending time on another department’s project, unprompted, for no stated reason. She had a gap where my motive should have been, and she filled it with the worst available option: he’s trying to switch departments.

That’s what a missing because does. It doesn’t leave a neutral blank. Somebody fills it in for you.

A Director of UX who built a design team from scratch teaches a script for exactly this:

“My favorite expression is, ‘help me understand,’ or ‘I want to learn. Will you teach me? Will you show me? I don’t understand X, can you help me?’ Be curious, ask questions, and do so with genuine curiosity and respect.” — Director of UX

And the sentence that does the real work: I’m not trying to waste your time with random questions. I just want to understand because it helps me design a better solution.

It’s a small clause, and it changes what the question is. “Why are you in my numbers?” becomes “you’re trying to do your job better,” without you having to say either of those things out loud.

There’s a sequencing version of this too:

“It always starts with the why question… ‘Can you help me understand why we’re doing that? What’s the value behind it? What’s driving it?’ So trying to understand their thinking is the first thing. And then you can question it.” — VP of Design, startups

Understand first, question second. I had the order backward, and it took me an embarrassingly long time to notice.

2. I researched the problem. I never researched her.

I could tell you exactly what the two teams were building and where I thought the overlap was. I could not have told you a single thing about what my manager was measured on, her worries this quarter, or her relationship with the other department contact.

If I’d spent twenty minutes on that, I think I’d have seen the “switching departments” read coming. In a siloed company, a manager’s currency is her people. Someone on her team volunteering hours to another department isn’t curiosity to her. It’s leakage.

The leaders who don’t step on these landmines treat stakeholders the way we treat users.

“I literally go to people’s LinkedIns, and I try to understand who my project team is. I try to understand what their motives are. You literally do like a UX kind of research on all of them, especially the main stakeholders. What are their motivators? What’s important to them?” — Design Consultant

Another director, at a completely different company, described almost the identical habit:

“This is just people and conversations. And the same way that we would try to get to know an audience is what I like to do with stakeholders — I build out a persona in my head of, here’s the five people I have to present to. Knowing what drives this person, knowing what motivates this person, knowing what this person’s pain points are.” — Director of UX, enterprise

One UX research consultant turns it into a project you can actually run: build personas of your business stakeholders, then go tell them you’re doing it. You’re one of my users.

A question from someone who hasn’t thought about you at all is just an interruption in your day, whereas the identical question from someone who’s clearly spent a little time on what you care about comes across as help.

You didn’t change the question. You changed what showed up with it.

3. I gave the value to the wrong people

I actually did bring something here, which is what makes this one sting. I offered the other team shared insights. I wasn’t just mining them for information.

But look at how it was distributed. The other team got insights, and my manager got a report that one of her designers was off doing unauthorized work with a department she didn’t control. She carried all the risk for value that went elsewhere entirely.

Compare that to how one Head of Design described plugging in:

“This is where, even as a junior designer, this is exactly where I would plug in and be like, okay, what happens because of this? Here are these three points that came from understanding the discoverability perspective from the user research and the conversation we had about the project history.” — Head of Design, SaaS

That’s not a question. It’s a trade — and the trade is with the person whose permission he needs.

The same consultant framed it as a trust sequence: the professionals who succeed approach stakeholders proactively, with information that helps them make their own decisions.

You bring them in. You show them you want to help.

A research consultant also raised something I hadn’t considered. A lot of the defensiveness you’re running into may have nothing to do with you:

“People are afraid of layoffs… People want to keep their information and their data close to them. So that might be where this is coming from, where they get the resistance, because people are protective of their space.” — UX Research Consultant

The person guarding the dashboard might not think you’re annoying at all. They might think you’re a threat to their job, which is a completely different problem and a much easier one to solve.

Give them something before you ask for anything, and most of it goes away.

I’d add the version I learned the hard way: give it to your own side too.

4. I started in the highest-stakes room available

Cold outreach to another department, in a company where departments didn’t talk. And I’d never once floated a half-formed idea with my own manager and watched how she reacted.

Neither of us had any read on the other, and there was nobody in either department who could have said oh, he does this, it’s fine.

“Once you hone that in in low, low stakes meetings, you start building the confidence to do that in bigger, higher stakes meetings… I would start with one-on-ones. Sit with your product manager and be like, ‘I understand your request, but this is what I want,’ and articulate why that’s not sitting well with you.” — Design Leader

And then the part I think matters most:

“That sort of starts building relationships that helps you create your allies internally, and then they start speaking about you in rooms where you’re not there.” — Design Leader

Rooms where you’re not there: that’s what I was missing. When my manager heard about the outreach, she learned about it through a system, not from someone who knew me.

Another leader was more concrete about the venue: recognize that the person across from you isn’t just Jasmine or Bob, it’s the head of brand, it’s the head of product. Then go get coffee with them.

And a design leader who runs her own team found the same pattern playing out. The designers who became genuinely data-fluent didn’t get there by being braver in meetings:

“It’s having an ally and having a genuine curiosity that has been the thing that has always unlocked designers to really become data savvy… finding that data analyst or the data scientist or whoever it is on your team, and just saying, ‘I’m really curious about what you do. I really want to learn more.’” — Design Leader

Curiosity in a meeting is high stakes. Curiosity in one-on-one is coffee chats.

Ten years later, the same problem

At my last job, I needed to talk to people I had no right to talk to.

Small HealthTech company, building for hospital administrators. I wanted a real user research channel, but our users were second-order contacts — friends of our executives, long-term customers on contracts running from $50,000 to well past $250,000 — and every one of them was reachable only through an introduction from our VP.

Structurally, that’s the hallway again. Something I needed, sitting on the other side of someone else’s relationships. The difference is that this time I went through him instead of around him.

• I made the because about them. Not “I want to do user research.” Instead: let’s find out what frustrates customers most, so we can go fix the biggest of it.

• I dropped the jargon. “User research” sounds like an academic exercise with his best accounts. “Understanding where people run into problems” doesn’t.

• I did his work for him. I wrote the intro emails and sent them to the VP as copy-and-paste text, so his job was to forward, not compose.

• I kept the ask small. Fifteen minutes at the end of calls already on the calendar, instead of a meeting anyone had to create.

• I sent value back. Every interview turned into something shareable — summary reports, visualizations, artifacts that made sense to people who weren’t in the room.

That last one mattered most, and not for the reason I expected. Those deliverables went places I didn’t. They got forwarded into conversations I wasn’t part of — which is the exact thing my mid-level self never had.

That’s how a new UX research channel got built at the organization.

So is curiosity innate?

I opened with a leader who says it’s an impulse you either have or you don’t.

Maybe he’s right about the impulse. Maybe some people are just wired to want to know how the thing works, and you can’t install that in someone who doesn’t have it.

But the impulse isn’t the part that gets rewarded. What gets rewarded is the delivery: the reason attached to the question, the homework on the person, the finding you brought with you, the relationship you built in a room where nothing was at stake.

Those are all communication skills, and communication skills are teachable. So the one thing he called untransferable turns out to be sitting right next to four things that aren’t.

That’s the difference between the curious mid-level designer who gets chewed out and the curious senior designer who gets invited back. It isn’t the curiosity.

I had it in that hallway. I just hadn’t learned to translate it yet.

The poll is anonymous, and I’m asking for a real reason: I’m building the next version of a communication cohort around whichever one wins.

Mine was the second, and it took me about a decade to admit it.

If there’s a story behind your answer, hit reply: that comes to my inbox, not public comments.

Photo by PNW Production: https://www.pexels.com/photo/women-hiking-in-a-forest-7624850/

You’ve been a Senior Designer for a few years. Maybe Lead for one or two. Staff or Principal is the next rung, and nobody can quite tell you what the job actually is.

Some recruiters call it “player-coach.” Job descriptions say “set direction.” LinkedIn posts romanticize “mentorship-while-shipping.” None of it tells you what you’ll be doing Tuesday morning when you get there, or how to start practicing now to be ready.

I’m not a Staff or Principal designer. I’m the person who rewrites portfolios for them (seven in the past year), and I’ve cross-referenced what I’m seeing against Artiom Dashinsky’s Path to Staff Designer. So this is an adjacent experience, plus the homework.

Here’s what the jump looks like.

On “player-coach”, and why it muddies the waters

The term “Player-Coach” has been showing up in many design career conversations recently. Andy Budd, who founded Clearleft and now coaches design leaders for a living, wrote the piece on this that gets passed around the most.

If you’ve been looking at Staff/Principal Designer job listings, you’ve probably seen the term as well.

The pitch is simple: you’ll still design, but you’ll lead. You’ll ship, but you’ll mentor.

It sounds great. It’s also two different jobs pretending to be one, and conflating them is what costs people years.

One version is management: a design manager with 1–3 reports who still ships their own work. Budd says most people fail at this within 18 months.

The Leadership Research Institute calls the failure mode the “player-player trap”: managers who default to taking the work themselves, where coaching and feedback “happen after hours or via email.”

The other version is IC: a senior designer expected to set direction without managing anyone. That’s the path most seniors are on once they pass lead, and it’s the one this piece is about.

It has a name. It’s not player-coach. Its direction.

Direction, and why it’s so important to Staff/Principal ICs

Direction comes from the creative world. Art direction, sound direction, creative direction. Same job everywhere it shows up: set the priorities, the principles, and the bar, then make sure the work everyone produces ladders up.

For a Staff or Principal, that looks like:

• Turning business outcomes into design priorities your team can run with

• Setting the quality bar by making it legible enough that other designers can hit it

• Owning consistency, identity, and how the design system gets used

• Critiquing in a way that teaches, not just corrects

Notice what’s missing: screens as the main thing.

Most Staff and Principals still ship work. Some ship a lot, especially at smaller companies. But it’s no longer how they create their primary value, and that’s where I see seniors getting tripped up.

The thing that got you to senior was usually being the person who could ship work that solved problems. Whenever someone handed you a gnarly problem, they trusted that you’d figure out the design.

That’s not a bad instinct. It’s the instinct that earned you the role. But it’s also the instinct that quietly stalls a lot of strong seniors at the next door. “I’ll just tackle it” gets in the way of the actual job.

Dashinsky describes the Principal-level shipping competency this way: “Motivates, unblocks, and coaches others to ship fast. Able to identify blind spots across teams in estimating or delegating work and builds processes to resolve that. Delegates work often.”

Personally shipping the hardest screen on the team isn’t in there.

The seniors who don’t make the trade tend to be the strongest individual designers on the team, which is what makes it hard. The thing that’s been working for you is exactly the thing you’re being asked to outgrow.

So if you’re senior right now and reading this, the audition starts before the title does. The question isn’t whether I’m shipping the best work on the team. You probably are.

The question is closer to: can I make the work around me better, even when I’m not the one doing it?

The moment you stop being the one moving pixels, you have to figure out how to communicate what you’d do if you were.

Staff/Principals become the stakeholder you used to hate

You become the person you used to roll your eyes at. The PM who slacks, “Can you make this pop?” and disappears. The exec who says “this doesn’t feel premium enough” and offers nothing else. The senior who reviews your work for ten minutes and lands on “I dunno, something’s off.”

Now you’re one of them.

When you’re setting direction, you’re giving feedback on work you didn’t do. You can see the better version. You just haven’t done the work of translating it into something a designer can act on.

That gap between what you can see and what you can say is the actual next-level skill.

It’s also the thing seniors can start practicing now, on the designers below them, before any title shows up. Every time you give feedback to a junior or mid-level designer, you’re either building this muscle or you’re not. And honestly, most of us skip the rep.

When critique stays at “I like” and “I don’t like,” the design ends up reflecting the preferences of whoever argues the loudest. The team grinds through cosmetic changes that get reversed in the next review. The senior who can’t articulate the call is often the one creating the churn, even when they’re the strongest designer in the room.

Underneath better feedback, you need a position. A stable sense of what good looks like for this product, this moment, this team.

That position is what people call “taste”.

Taste isn’t the problem. Externalizing it is.

Taste’s been having a moment for a couple of years. The argument’s straightforward (from the Nielsen Norman Group): when AI lowers the cost of execution, technical skill stops being where designer value lives. Selection and discernment do.

But there’s a version of this that turns taste into something mystical. A gift, a vibe, an aesthetic instinct you either have or you don’t. That version lets people off the hook for the actual work.

Phil Morton said it best: “Good taste isn’t magic. It’s pattern recognition developed through years of experience.”

Here’s the useful piece of news. It’s not that you don’t have taste. If you’ve been doing this for ten years, you have taste. The Staff and Principals I work with don’t describe themselves as having more of it than the seniors on their team.

They describe themselves as having gotten a little better at getting it out of their head.

Direction is the what. Taste is the why. Once you’re at this level, the why has to leave your head. It has to become something others can use in their work, their reviews, and their decisions when you’re not in the room.

If it stays internal, you’re back to “make it pop” in a fancier outfit.

The real skill, the one nobody trains you for, isn’t developing taste. It’s externalizing it. And the seniors who start practicing this a year or two before they need it tend to be the ones who don’t get stuck.

Six ways to externalize your taste

None of these are clever. They’re just the work most of us skip.

1. Stop saying “I like” and “I don’t like.” Replace them with “I think this is effective because…” and “I think this could be more effective by…” Fill in the rest with actual design vocabulary: hierarchy, contrast, rhythm, density, voice. The grammar forces the thinking. You’ll catch yourself reaching for “I like” and realize you don’t actually know why.

2. Write your taste down as principles, not preferences. A preference is “I like generous whitespace.” A principle is “When the page has more than three priorities, we resolve them with whitespace before we resolve them with type weight.” The first can’t be argued with. The second can be applied by someone who isn’t you. Three to seven of these, written down and shared, is what direction actually looks like.

3. Build a reference library. 20 to 30 examples that exemplify the bar you’re setting. Next to each one, write a sentence or two about what you’re actually pointing at. The way the empty state uses one strong illustration instead of three weak ones. When you tell a designer “make this feel more confident,” send them three references with the sentences attached. Vague becomes specific.

4. Pre-state your criteria before you review. Before you open the Figma file, write down what good looks like for this specific brief. It forces you to commit to a position before the work biases you. And when you share the criteria with the designer up front, the review stops being a black box. Most “the senior is impossible to please” complaints disappear once the senior writes the brief down.

5. Use the five whys on your own gut reactions. The feeling that something’s off is the alarm bell, not the feedback.

It feels cluttered. Why? Too many priorities competing. Why? Hierarchy is collapsed, three things use the same weight.

So the feedback is: “the H2, the CTA, and the alert are all weighted the same. We need to drop two of them.” That’s actionable. It feels cluttered isn’t.

6. Connect the aesthetic call to a user or business outcome. “This feels too playful” is a taste. “This feels too playful for the moment a user is entering their bank credentials, and we’ll lose conversion at the trust step” is the direction.

Same instinct, same eye. But now the designer doesn’t have to choose between your aesthetic preference and their understanding of the user. Do this consistently and what would [you] say about this? becomes a useful question for your team to ask when you’re not in the room.

Growing in this tough job market is about learning to externalize

Your job at the next level is to make your call legible enough that the designer next to you can act on it tomorrow. The career move from senior to Staff or Principal isn’t about getting better at design. You’re already good at design.

It’s about making the good you already have leave your head.

The designers you work with don’t need you to be a better player. They need a coach who can actually coach. Which means saying out loud, in words they can use, what you’d do if you were them.

The title catches up later.

Working on positioning yourself for a Staff or Principal jump? Book a free 30-minute fit call to talk through where you are and what’s next.

I rewrite portfolios for Senior, Lead, Staff, and Principal designers. I write about what I see in the Data and Design Newsletter, and help designers tell the story of why their work matters: to land jobs, get buy-in, and reach the next level.

I’m about to say something that would irritate my old academic advisors and half the people I used to work with.

You don’t need nearly as much scientific rigor as you think to run a design experiment.

That’s something I’ve learned after talking with 260+ designers. Experimentation is increasingly becoming a bigger part of what design does, whether that’s running AI experiments in your process or laying out a hypothesis so other people can actually see the risk you’re weighing.

But the word “experiment” makes a lot of designers freeze, so they avoid it entirely.

So here’s the reframe. If the word “experiment” makes you tense up, just call it a bet. That’s what many design leaders do, and I’ll show you exactly what it looks like.

Why experiments carry a stigma

I understand the freeze, because I went to grad school and teach designers how to work with data. I’ve watched whole classrooms shut down the moment A/B testing comes up.

Minimum detectable effect. Statistical power. Sampling bias. A/B versus multivariate testing. P-values. These are terms most designers never expected to run into, and unless you’re running enterprise-wide research studies, you don’t.

Some organizations (and researchers) require that amount of scientific rigor, but it often does more harm than good. It convinces designers that to “really” experiment you need a dedicated research org, specialized A/B testing software, a user base big enough to power a test, and a week to let it run.

But most designers don’t need to understand laboratory experiments. They need to understand the experimental mindset, what design leaders call strategic curiosity, and the willingness to try something.

The startup case for an experimental mindset

If you’ve ever worked at a startup, you’ve seen this up close. Startups don’t have all the data. They don’t have clean lab conditions, reliable metrics, or much certainty at all. Everyone’s wearing three hats, so the experimental mindset is usually on full display.

It often looks like a stripped-down version of the Lean Startup loop: build, measure, learn. Say I kept watching users trip over the same spot in the prototype, and I wondered whether cutting that section would fix it.

Build: work with an engineer, or vibe code, a rough but functional version in an afternoon.

Measure: push it live and watch whether anything actually changes.

Learn: keep it, kill it, or try the next version.

There aren’t three layers of approval. There are no laboratory conditions or scientific rigor. But that move, taking an observation and turning it into a small testable bet, is one of the things designers at big organizations can learn the most from.

Why experiments matter more

There are two reasons this matters more now than it did a few years ago.

The first is hiring. AI experimentation has become something managers screen for, especially for Senior+ design roles. You might not have shipped a real AI project, but they want to see that you’re at least curious about working with AI.

Whether it’s pulling meeting summaries out of Copilot and doing something useful with them, or spinning up a rough PR with generated code instead of waiting weeks on engineering. The specific experiment matters less than the fact that you ran one.

The second is defending your judgment once you’re inside. When a PM can generate a passable mockup in thirty seconds, the question you’ll get asked is why yours is better. That’s where the slower work of running a real test earns its keep.

If your answer goes past “users seemed frustrated” and into what you set out to measure and what the result would mean for the business, you’re not defending taste anymore.

You’re showing your work. That’s experimentation, and it comes straight out of strategic curiosity.

One design leader I interviewed put it bluntly.

“You need curiosity if you still want to call yourself a designer. If you don’t have that curiosity to explore? Well, you’re better served being in another field.”

Head of Design, Security SaaS

Now that building the screens is the easy part, strategic curiosity is one of the few things left that can’t be commoditized. But curiosity on its own is a trait, not a method, and a trait won’t tell you how to develop it. That’s the job the experimental mindset does.

Turn the curiosity into a bet

So here’s what “calling it a bet” actually looks like.

A good bet answers three questions, and none of them require a lab.

Read more

“Designers do great work, but they don’t know how to communicate it. I get all these screens in a Figma file, and I’m like, where’s your annotations? You can’t go to a VP and show them this stuff.” — Senior Director of Product Design

That’s what a Director of Product Design told me the other day, and it’s not an uncommon sentiment.

The era of self-explanatory visuals is over. A well-designed screen used to be enough to carry a product review. It doesn’t anymore.

The fix is one of the smallest, most transferable skills you can build as a senior designer: a simple three-part frame for annotating your own work. Decision, hypothesis, outcome.

Your screens don’t speak for themselves anymore

Redesigns used to be drastic enough to speak for themselves. When the before screen was from the 1990s and the after was modern, you could see it at a glance.

I’m not the only one that feels this way

People said things like “design modernized the site,” and even though much of the design work was invisible (Information Architecture, typography, decision-making), the overall story read decently. Design made things modern, sleek, and intuitive.

Those comparisons are much harder now. The difference between “before” and “after” might not just be invisible to non-designers. The difference between your design and AI might be imperceptible (to non-designers).

A PM used Google Stitch to turn Miro sketches into a design that looked real. It looked finished, but when you start looking at it, it’s not quite right and broken in places. But it raised this worry for the team, because decision-makers might think otherwise. — Head of Design, Legal Tech

Visual comparisons of screens, especially between your work and AI, aren’t always going to tell the story. You have to say it.

Nowhere does this hit harder than in how you present research.

UX Research is where it really breaks

User research doesn’t photograph well.

The most common thing you see in a readout deck is a zoomed-out FigJam board with two hundred stickies on it. Proof that something happened.

Can you tell what happened here?

But when you actually look, all a VP learns is that you checked the box. You ran the workshop. You built the persona. You conducted the competitive audit and generated 100 Post-it notes.

That’s not what they’re sitting in the meeting for. It used to be enough to show you could run a workshop. It isn’t anymore. They want to know what came out of the workshop that helped the business.

The same logic runs through the design section of your deck. A screen that shows you can push pixels is not an argument for the decision you’re presenting. If you want a VP to understand more than “you came up with something,” you need words next to the screens. Words that do the argument the screens can’t.

Annotations aren’t what you think

When you hear “annotate your work,” you probably picture the same thing everyone does: callouts on a screen. An arrow pointing at a chip that says “filters by date range.” A label on a CTA that says “primary, mobile.” Short, specific, attached to a pixel.

That kind of callout is useful. But it’s the wrong emphasis for a presentation.

What the people in the room (and those reading the deck after the meeting) are trying to follow are the decisions around the artifact. The copy on the slide that tells them why this screen exists, what you chose against, and what happened because of the choice.

A good review slide is a screen, something pointing at it, and something framing it. The callouts are the smallest part.

Decision, hypothesis, outcome

The structure that holds up across product reviews, stakeholder updates, and the screenshot you paste into Slack has three parts. I think of them as a decision, a hypothesis, and an outcome. Each one lives in a different place on the slide, and the geometry matters.

Decisions get annotated directly onto the artifact. A line, an arrow, a callout pointing at the specific UI element, and naming the choice.

It can take two specific forms:

The problem. Calling out a problematic UI element and what goes wrong with it. This is what you use when you’re pitching a design recommendation in a presentation. For example: “5/5 users couldn’t figure out how this selector worked.”

The decision. Highlighting the choice you made that led to positive outcomes. This is what you use when you’re walking someone through work you’ve already shipped. For example: “I re-did our selector layout because of these difficulties.”

Someone skimming your slide should be able to reconstruct what you decided just from reading your arrows.

Hypothesis lives in the slide itself, usually near the top.

Simply put, this is the bet you made on how user behavior would change, based on your decision. If your decision is about redoing the selector layout, your hypothesis might be: “We expected to see less drop-off on the Product Details page, because users weren’t getting stuck on the selectors.”

It doesn’t attach to a single pixel because it’s about the whole bet, not one element of the screen.

Outcome lives at the bottom of the slide or in a results strip. A number when you have one. A specific qualitative shift when you don’t.

“Mobile completion rose from 38% to 54% over six weeks. We saw a shift in customer complaints, especially regarding wrong sizing.”

Treat it as the close of the argument, not an afterthought.

Sample of Hypothesis, Decision, Outcome

Decision on the artifact means the reader can reconstruct your thinking element by element. Hypothesis at the top means they know what you were trying to do before they see whether it worked. Outcome at the bottom means the slide lands.

How to check if your annotations are working

Cover the screens with your hand. Can a VP who wasn’t in the room still follow what you decided, what you expected, and what happened? The arrows should still point at something meaningful, even if they’re pointing at air. The hypothesis should still read. The outcome should still land.

If yes, your writing is carrying its weight, and your screens are supporting it. If not, your screens are doing the presentation’s job, and your writing is decoration. This is exactly the position the director at the top of this piece was complaining about.

This is how you surface the invisible work you do as a designer.

Rather than trying to craft the perfect image that spells out everything visually, adding annotations (and arguments) is how you get your team to see your strategic judgment, and how your decisions keep traveling in the rooms you’re not in.

Struggling with figuring out the decisions? Book a free 20-minute fit call to talk through how to frame these decisions.

Kai Wong is a Design Storytelling Coach and author of the Data and Design Newsletter. He helps designers tell the story of why their work matters to businesses, to get buy-in for their ideas, and advance their careers.

There’s one thing that doesn’t get talked about enough when career ladders break, like they have with design.

Classic frameworks, like 10,000 hours, don’t make sense anymore. When the next step isn’t clear, hours aren’t as important as experiments.

So let me run contrary for a second and pick a fight with Malcolm Gladwell.

The 10,000-hour rule has an assumption baked into it

In case you haven’t heard of it, the 10,000-hour rule is basically about practice.

The world’s best designers, basketball players, violinists, surgeons: they gain mastery in their craft after putting 10,000 hours of practice.

It’s a decent rule of thumb, albeit one that’s been debunked recently.

But it just doesn’t make sense for designers for one key reason. It just assumes the game you’re practicing will still be there when you’re done.

You could have been a polished master of the craft with 10,000 hours on a mechanical typewriter, right as the PC came about.

Or 10,000 hours of being a great event coordinator, and then COVID hits.

Or, just recently, 10,000 hours of design, and then AI changes the game.

10,000 hours only make sense when there’s a clear path forward towards success. You start as a mailroom clerk and you work your way up all the way to CEO.

Every hour compounds because the ladder stays where it is. But that’s no longer the case.

Why 10,000 experiments, instead of 10,000 hours

James Altucher has a slightly different number: 10,000 experiments.

Altucher hates waiting in line. That’s why he wrote a book called Skip the Line. In it, he proposes another idea: if you don’t want to wait for permission, run experiments instead.

That mindset is one of the most important things designers need to have nowadays, because the game is changing rapidly.

In Figma's 2026 AI survey, nearly three out of four hiring design managers said they see an increasing need for candidates who are proficient with AI tools.

That seems unthinkable when 2 years ago, at Config 2024, the design community was up in arms about an AI design feature.

When things are moving that fast, 10,000 hours doesn’t make sense.

By the time you get 10,000 hours in ChatGPT, there’s something that blows it out of the water.

You get really good at Replit, and hey, all of a sudden Replit’s not that popular; actually, it’s v0 or Lovable or Claude and MCP or whatever ships next quarter.

Investing 10,000 hours in “AI tools” just doesn’t make any sense, because the tool isn’t the skill.

What matters more than ever is transferability. If you know how to make a NotebookLM second brain, you can probably make a Claude second brain or a Notion second brain.

If that’s the case, experiments, not hours in a single tool, makes the most sense.

So how do you actually run an experiment?

For design experiments, it really just consists of three parts:

• What the product was about

• What you asked AI to do, and

• What you did.

Each of these is important, but the 2nd and 3rd are what employers want to see.

Because while some people might work on AI features, most aren’t. Most are working on non-AI projects, but you’ve integrated AI into your workflow.

Maybe you use Figma’s AI to summarize user research.

Maybe you use it to generate first ideas before you start polishing options in Figma.

Or maybe you vibe-code a PR so something actually ships instead of sitting in a spec doc.

AI is somewhere in the project. But what’s the scope? Why did you ask it to do task A but not task B?

How did you set up guardrails and rationale to limit AI to doing this because of X, Y, and Z?

You might not have a clearly defined scope, but saying “Oh yeah, I used AI for this project?” won’t fly.

This is where making it an experiment helps. Saying “I tried to have AI vibe code this, to make a easier PR for engineers to review?” or something similar helps people understand where you’re coming from.

How to actually experiment

Running experiments is, in a lot of ways, about confronting your discomfort.

Read more

One of the hardest parts of being a designer isn’t knowing what’s broken. It’s convincing someone who wasn’t in the research session, hasn’t read the reports, and has a different opinion backed by seniority.

What changes that isn’t better arguments: it’s better evidence.

We’re often taught to generate evidence from our users: recruit users, do testing, and synthesize findings. However, sometimes you don’t have time or resources to do that, especially if you’re trying to change an opinion on a limited time.

But sometimes, your competitors have already done the research. Their users are telling anyone who will listen exactly what’s broken. You just have to know where to look.

What people get wrong with Competitive research

A lot of people roll their eyes at competitive research because it’s been taught as a biased comparison exercise.

As Dscout notes, it often lands on someone’s plate because no one else wants to do it. When it does, the default is to compare and contrast visuals.

You might be beating your competitor on visual design, but that’s because you’re targeting B2C customers who expect beauty, and they’re targeting B2B customers who care about functionality. That doesn’t tell you much.

Nielsen Norman Group puts it plainly: competitive evaluations exist to help teams base decisions on data rather than opinions or popular trends. But in practice, that means walking through a competitor’s experience with no context into their market or their users.

The more useful direction is the one most designers skip: the negative review.

Understanding the negative signal

Most designers who do competitive research look at what competitors are doing well. That’s the weaker argument.

When you compare screenshots of us against a polished competitor, you’re giving the argument of “look how good they are compared to us.” That might motivate a team, but it won’t persuade a stakeholder.

Negative reviews flip that entirely. Instead of pointing at someone else’s strengths, you’re pointing at their gaps.

If their users are consistently frustrated by something your product handles well, you’re not arguing pixels: you’re making a business case. Fix it on your side, and you give their frustrated users a reason to switch.

The goal is to identify those gaps, represented as complaint clusters. The same frustration, described in the same words, by people who don’t know each other.

As Invesp describes, this kind of review mining surfaces the challenges customers have experienced and points directly to where your product can outperform the competition.

The fastest place to start is Reddit. Search "[App name]" Reddit in Google and you’ll find threads where users are far more candid than any star rating.

You can also google other search strings like “Competitor X frustrating”, “Competitor X vs your product”, “Should I buy Company X”.

You can also try sites like G2 or Trustpilot, which let people filter and view 1–2-star reviews in aggregate.

Start mapping the negative landscape and see whether things break.

Look at aggregate reviews, not individuals

When you first dive in, you might be skeptical. Some 1-star reviews are more about people’s personal lives than a specific product.

There’s also a temptation is to read each complaint as a one-off. One person who had a bad day. One edge case that doesn’t matter. Resist that.

One person’s frustration with onboarding is just an opinion. Five people describing the same friction in the same words? That’s a pattern you want to take note of.

What you’re looking for is clusters of language. When you see the same complaint surface repeatedly, you’ve found something real. Not just what’s broken for them, but how users think and talk about what’s broken. And where your product has room to do better.

“It’s easy to stand behind something you want to suggest if the numbers are easy to translate.” — Head of Design, Silicon Valley Startup

That vocabulary matters. “I can never find where to change my notifications” tells you more about the mental model than any heuristic evaluation report.

A few guardrails so this doesn’t ruin your afternoon

Diving into negativity can ruin your afternoon, so set a few guidelines.

Time-box it. Give yourself 30 minutes. Set a timer. You’re not trying to read everything. You’re looking for frequency.

Filter hard. Go straight to one and two-star reviews. Everything else is noise for this exercise.

Count, don’t curate. Set a small, arbitrary threshold. If something gets mentioned five or more times, write it down. You’re not building a research report, you’re building a complaint cluster.

Note the exact words people use. Not your interpretation: their words. That language will show up again when you’re writing tooltips, error messages, and onboarding copy.

If you want to go deeper

The complaint cluster is useful on its own, and is all the evidence you need. But if you want to make it harder to argue with, take one more step.

Once you have your complaint clusters, put them in a spreadsheet and count frequency. Even a simple bar chart showing the most common complaints turns a qualitative observation into something that reads as data in a meeting.

You’re not running sentiment analysis software. You’re counting, sorting, and presenting. Anyone can do this in 30 minutes with a spreadsheet and a basic chart.

The point isn’t precision: it’s a pattern. A chart that shows onboarding complaints outnumber every other category three to one makes the argument for you before you say a word.

When you have that, you have something you can actually use, not just for your own awareness, but in a room full of stakeholders.

The difference between “I don’t think this new onboarding direction is right” and “the single most common complaint in one-star reviews is onboarding, and this direction doesn’t address it” is the difference between opinion and evidence

That’s how you bring proof and argue a point of view with something behind it.

This is for designers who have a meeting in two hours and need to walk in with something real. The sources are free. The method takes less time than a standup.

And the output, a pattern of real user frustration in their own words, is exactly the kind of evidence that moves a conversation forward.

Kai Wong is a Design Storytelling Coach who helps Designers advance their careers through storytelling.

“Three of five users struggled with the signup flow.”

“We have an 80% onboarding abandonment rate.”

Same findings. But it feels like your team only listens to the second one.

You know the first line because user research is what you’re funded to collect. The second line, you probably assume, you don’t have access to.

That’s the part that’s changed with AI.

How high-stakes conversations get resolved

In Crucial Conversations: Tools for Talking When Stakes Are High, the authors talk about returning to one move to keep high-stakes conversations productive: when tempers flare, start with facts. Facts are the least controversial thing you can put on the table and the most persuasive.

It’s the first skill in their STATE model, and it’s what makes everything after it possible.

But facts on their own don’t cool a conversation down. What they do is let you re-establish the two conditions the book says dialogue depends on:

• Mutual Purpose

• Mutual Respect

By zooming out to the larger purpose, you re-ground the conversation, and productive discussion can follow. Tom Greever calls the same move “establishing common ground” in Articulating Design Decisions.

The problem is that the facts have to matter to both parties. And UX facts often don’t.

“We both want to fix the signup flow that three of five users struggled with, right?” That might not be true.

“We both want to fix an 80% onboarding abandonment rate, right?” That one is a business fact, which means your team already cares about it. You care about it too, just from the user’s side.

Grounding a conversation in shared purpose is one of the fundamental building blocks of handling high-stakes conversations well. But this is where designers say one specific thing:

“I don’t have access to data.”

That doesn’t have to be a limitation anymore.

The experiment nobody’s running

Why does everyone keep showing up with the first line? Because it’s the only evidence anyone gives them room to collect.

There’s a set user research process to follow, and it’s something you’ve done at least once.

But the core of this newsletter, and of my philosophy, is data-informed design. Forming hypotheses, running experiments, A/B tests.

And while some of this stuff can be treated as a nice-to-have, an experimental mindset can easily solve the “I don’t have data” issue.

Even when deadlines are pushing in, everyone wants you to ship faster, and there isn’t a budget for it.

Evidence isn’t only the stuff you generate yourself. Some of it is already sitting in public.

AI can gather the market research for you

I don’t necessarily trust AI to do design. But I do trust it to find facts with quoted sources, because it’s unlikely to hallucinate.

So imagine you don’t know why a project started. You’re on Project Neptune; it hasn’t been released yet, and you don’t really know much about it.

AI has never heard of Project Neptune either. It’s an internal codename, and it isn’t in any public document. Ask about it by name, and you’ll get nothing, or worse, you’ll get something invented.

So don’t ask AI to find Project Neptune. Ask it to find the problem that Project Neptune is meant to solve in boring places like shareholder meetings, press releases, and more.

Read more

Photo by Jo Szczepanska on Unsplash

“Even though the Head of Product felt the workshop was good, he was still confused about what, exactly, we had achieved by the end.”

I’ve been hearing that from designers a fair bit recently, across companies and domains. Workshops have been fading recently: not gone but quieter. It’s not because stakeholders suddenly hate collaboration.

It’s because the last time they did one of these, they walked out with a Miro board nobody looked at again and a vague sense that something had happened.

The week-long, 30-person workshop is basically dead. The State of Facilitation 2025 now recommends that most facilitation sessions be 60 to 90 minutes.

If you’re still pitching anything longer than that, you’re already losing the room before anyone’s shown up.

The “what did the business get out of this?” problem

“Great, so you did a workshop. What was the outcome? Did the business make money? What were the cost savings? What did you implement? Oh, you don’t have that. You just have some Post-its.” — Design Manager

That’s not one person being harsh. It’s a pretty common reaction in 2026, and the reason is usually the same: nobody defined what “done” looked like before the thing started.

Gothelf and Seiden were making this point in Lean UX, and it’s somehow more true now than when they wrote it. The board full of stickies has become the output. It looks like work, it feels like momentum, and then nothing moves.

The 2026 State of Facilitation report puts a number on it: facilitation gets credit for how people felt in the room, not for what changed after.

There’s also the math, which almost nobody does out loud.

Your workshop isn’t free, and it’s not because of catering. It’s just that the cost doesn’t show up anywhere obvious. If a VP blocks off half a day, that’s thousands of dollars in opportunity costs to attend your workshop. Multiply that across everyone attending, and that might be hundreds of thousands of dollars.

One designer I know tried to bring nearly 40 stakeholders from several teams together to work through a shared problem. It fell apart, and it wasn’t because the problem wasn’t worth solving. It was because those teams were all trying to ship things. Stopping to attend a session with no guaranteed output wasn’t a trade they were willing to make.

That’s the real reason workshops disappeared. Not because collaboration is dead. Because nobody made the case that this one was worth what it actually cost.

Why is this a designer’s problem to solve

Designers are actually pretty well positioned to fix this, and it’s not because we’re the best facilitators in the room. It’s because we’re the most motivated to get it right.

We spend most of our working lives translating things: between users and engineers, between research and roadmaps, between what someone says they want and what they actually need. The instinct to reframe the problem before jumping to solutions isn’t something we learned in a workshop certification. It’s just kind of how we work.

Gothelf calls the real output of a good workshop “shared understanding.” Not the deck, not the Miro board, not the summary doc nobody reads. The alignment means teams stop having the same argument in every meeting. That’s a business outcome. We just don’t call it that, which is part of the problem.

We’re also the ones who have to design something when it’s over. That matters more than people give it credit for. We have more skin in the game than anyone else in the room, which means we have more reason than anyone to make sure something real comes out of it.

Facilitation is increasingly being recognized as a leadership skill, not just a process tool, with nearly a third of professionals now using it in-house. Designers who get ahead of that are going to look very different from those who are still booking conference rooms and buying Post-its.

How to run the workshop that actually works

The organizations doing workshops well have moved toward what’s being called “Activation Workshops”: sessions designed not to generate insights, but to turn existing insights into decisions. Here’s how to actually build one.

Let’s say someone comes to you with this: “We need a workshop to figure out what we don’t know about user group B.” That’s a real request. It’s also not a workshop yet. Here’s what you do with it.

Make it about a time-based decision. Don’t just book a conference room based on “What we don’t know about user group B.”

Push back, and ask one important question:

• Why does the team need to know about user group B right now?

If the answer then becomes “we’re trying to decide if we’re expanding the product to serve this user group?”

That’s the real point of the workshop, not cataloging knowledge gaps.

Shrink the room by doing the math out loud. Figure out the rough opportunity cost, because small, focused teams outperform large ones. If you’re bringing in executives, who might cost $500/hour to be in the room? You have to be able to answer “What does the business get for that?”

Having 5–6 people in the room for 1 hour often is $1500+ in opportunity costs.

If you’re justifying it by saying “We’ll be able to say whether user group B is worth designing for”, then you need to ensure that you have the right people who can make those decisions.

There’s no sense in workshopping with your product team if they can’t make these big business decisions without a VP.

Cap the time and don’t apologize for it. A 90-minute session with a named decision on the table is a completely different meeting from a half-day alignment session.

Shorter formats force sharper objectives, and people tend to stay engaged when they feel their time is respected. Pitch the shortest version that could still hit the goal. You can always go longer. You can’t get buy-in back once you’ve lost it.

Format follows outcome:

Rather than planning a long agenda, defining the outcomes also helps to determine the content of the workshop. If your goal is to determine “Yes/No” on user group B, it might take the form of an Impact/Effort Matrix exercise (and a prioritization framework).

Bring existing research to make that existing exercise easier. That’s a very different design from “let’s brainstorm what we don’t know.”

With those things in mind, the original request of “a workshop to figure out what we don’t know about user group B,” became a 90-minute session with six people, a clear decision on the table, and a format built around making that call.

That’s how facilitation works in 2026.

Designers who run workshops this way stop being the person who organized the sticky-note session and become the person who helped the team make a call they’d been avoiding for three months. That’s the positioning shift, and what makes them valuable when people are cutting budgets.

Kai Wong is a Design Educator and author of the Data and Design Newsletter. He helps designers tell the story of why their work matters to businesses, to get buy-in for their ideas, and advance their careers.

A few years ago, I could have recited mine without thinking. Senior, then lead, then principal, maybe director, at some healthcare company betting big on telemedicine or AI. I had the whole thing mapped.

Then AI came along, and it wasn’t just a market shift. A script broke, and it’s putting a lot of designers through real anguish.

Cognitive script theory might explain why. The theory says we build scripts from repeated experiences to save ourselves mental effort.

Imagine walking into a hospital. Announcements over the loudspeaker, patients sitting everywhere, unfamiliar equipment and jargon, people hurrying past.

If you’ve ever taken a kid there, you’ve seen what no script looks like. They’re overwhelmed, asking a hundred questions, unsure what’s going on.

But you’re not, because you’ve loaded the “going to the doctor” script.

You know not to undress in the waiting room, and you won’t think twice about it in the exam room.

You know you don’t have to stand in line: you check in, sit anywhere, and they’ll call you.

You already know a trip to the pharmacy is coming because you’ll leave with a prescription.

None of it takes any mental effort. That’s the whole point.

And it’s exactly what quietly wrecks people when their world changes.

When the Great Depression hit in the 1930s, even the people who didn’t lose all their money fell apart. The scripts they’d built as bankers and stock traders vanished overnight.

You’ve probably seen a quieter version in people who retire and suddenly seem adrift and purposeless.

We’re nowhere near that. But a milder version of the same thing is happening to designers right now.

The script that broke

A lot of designers are getting hit with a double whammy: laid off, then finding out the job market changed beneath them.

The script for how they used to find work is broken. Some never even built a portfolio because they got recruited.

Others build portfolios like documentaries, not realizing no one has time to read the whole thing.

Some never had to sell themselves at all. Their script was simple: list what you’ve done, and that’s enough.

But the deeper problem is that AI has made craft feel cheap. A lot of these designers just wanted to get paid to solve problems and build cool stuff.

Now? Building cool screens can now be done (badly) with AI. So these are the people that are most negative about AI.

If AI is just a buzzword…if it’ll flame out in a couple of years and everything snaps back to normal… then you never have to touch the broken script.

You just wait it out.

But that’s not the most probable path.

Plenty of AI hype will die, and a lot of it deserves to. But things are not going back to how they were.

The workshop where you slowly hash out a problem over the course of a week.

The month of research before anyone expects to hear findings.

The weeks spent crafting a design because there was no faster way.

That world isn’t coming back. I hate saying it as much as anyone. We opened the box, and we can’t close it.

Which means the old five-year plan is gone too. Junior, mid, senior, then lead or principal, then director, up and up. That clean ladder mostly doesn’t exist anymore.

Maybe I’ll end up as a Director of UX at a healthcare company. Maybe I won’t. Right now I help designers tell their story, and I don’t know whether I’ll go back.

For a while, that terrified me. No five-year plan felt like no plan at all. Then I stopped trying to write one.

And I’m not the only one who feels better on the other side of that. I interviewed 32 design leaders about where the field is going, half expecting a wall of doom.

That’s not what I got. Most were optimistic. They just agreed on one thing: the work has changed.

One Director of Design put it in a way that stuck with me:

The core design responsibilities aren’t going anywhere. A PM isn’t going to run the design process. But designers can do more now. They can bridge the gap. Not just prototypes, but experiments, even rough drafts of the implementation code.

That’s the part the doomers miss. The core of the job is still yours. What changed is that the edges are widening.

That’s the opportunity hiding inside the broken script. You just can’t get to it with a five-year plan.

Run the experiment instead

If a five-year vision has become unrealistic, stop forcing one. Trade it for an experiment.

According to Anne-Laure Le Cunff, ex-Googler and author of Tiny Experiments, an experiment has three parts:

• A bet on one thing worth getting better at.

• A timebox short enough to actually finish: three to six months.

• One visible output at the end. Something you made that proves you ran it.

Not a career. A bet, a deadline, and a thing you can point to.

Leaving healthcare to help designers write was one of these. It wasn’t a master plan.

It was a bet: that designers don’t have a craft problem, they have a communication problem, and that I could help.

The timebox was four months.

The output was real work with real clients, proving the bet held. If it hadn’t, I’d have known in 90 days instead of guessing for five years.

You can run these experiments at work, too, even if it doesn’t feel like it. Why? Because it’s about output, not outcome.

You can’t plan your way to stakeholder buy-in in 90 days, or “get better at communicating” in six months.

Those are lofty goals: not entirely in your control, and too vague to point to.

But you can run an experiment like this:

• For the next three months (the timebox),

• Write up the rationale for one design decision each week and send it to your team(the bet).

• At the end, you’ll have twelve worked examples of your own thinking (the output).

It could just as easily be a bet on the AI tools you’ve been curious about. Not “master Claude Design,” but “use it three times a week for three months.”

Pick whichever you want. It just has to be small enough to finish and real enough to teach you something, whether it works or not.

I know a lot of you are being asked to do more with less, and this can feel like a nice idea that never makes it off the backlog.

But here’s the part I didn’t expect when I started. The experiment doesn’t just move you forward. It takes the anxiety out.

When the worry about AI taking your job (or not having a five-year plan) starts creeping up, you can actually do something about it. Make a bet. Run an experiment. Maybe you won’t have a five-year vision.

But you’ll have a small bet to work toward over the next three months.

That, more than ever, can calm your nerves in this crazy market.

Want help, coming up with an experiment that you can run even at your day job? Book a call, and I’ll help you set one up.

“I worked with her for two and a half years, and we were about to launch. Then Covid came, and the whole thing went up in flames. I felt like all the work I did for the past two and a half years disappeared.”

A designer said that to me recently, while I was trying to figure out how to talk about a project that never made it. She wasn’t alone in that feeling.

You might have spent months doing discovery, research, and design iterations. You had designs you believed in, and got stakeholder buy-in based on solid rationale.

Then the roadmap shifted, the stakeholder changed, the budget got cut. And just like that, the project was gone.

Now you’re in a review, or an interview, and someone asks what you’ve contributed. You have a Figma file and a story that ends with “it never launched.”

Most designers, at this point, assume the project took the impact down with it. No launch, no data, nothing to show.

But that’s not it. The preliminary impact was there. The evidence just wasn’t collected. And that’s a very different problem, because it’s one you can solve before the next project disappears.

The real gap happened before any of that. Before the project got cut. Before the launch that never came. It happened the moment the work started, when nobody stopped to ask: if this is working, what would we expect to see?

That question isn’t for the business. It’s for you. It’s what takes the project you’re most proud of, the one collecting dust because it never shipped, and gives it a story worth telling.

Why We Tie Everything to Launch

Designers are trained to think in deliverables. You define the problem, design the solution, hand it off, ship it. The outcome lives downstream in data someone else owns, in metrics that take months to move.

That’s fine when things follow the arc. But they often don’t. Projects get deprioritized. Reorgs happen. You move to a new role before anything launches.

If your only evidence of impact is the outcome, and the outcome never comes, you have nothing to show for the work.

(Quick note: if you’ve never shipped anything, that’s a different and bigger problem. This is about the work that was real, that was ready, that just didn’t make it.)

This isn’t a personal failure. Designers are often deliberately kept upstream of outcomes. Metrics live with the PM, data lives with the analyst, and by the time anything meaningful moves, you’ve been handed a new brief.

The feedback loop was never yours to close. But that doesn’t mean you have to walk away empty-handed.

Revenue Is the Last Step in a Chain. You Can Own The First Step.

When designers think about measurement at all, they reach for the big numbers. Revenue. Retention. Churn. These are called lagging metrics. They’re outcomes that accumulate slowly, long after the work ships.

They’re the last step in a long chain, and they’re completely out of reach if the project never launches.

Earlier in that chain are leading metrics: behavioral indicators like activation rates or early engagement that predict business outcomes before they fully materialize. They’re closer to the work, but they still require a live product to observe (like a 7-day A/B test).

What you can collect even earlier than that are signals. And signals don’t require shipping at all.

What a Signal Is, and When to Define It

A signal is simply a user behavior you’d expect more or fewer people to do if your design is working.

If you redesign an onboarding flow, a signal might be: more users complete onboarding without dropping off at step two.

If you simplify a form, a signal might be: fewer users abandon mid-completion. If you restructure a dashboard, a signal might be: users find what they’re looking for faster, with fewer wrong turns.

None of those requires a full launch to observe. You can see them in prototype testing or a limited rollout. You can see them in a structured usability session with five people. The behavior either moves or it doesn’t.

That’s what makes signals useful when a project gets cut. You’re not claiming a revenue number you never saw. You’re pointing to something real and observable: users doing something differently, even in a controlled setting, even before launch.

It’s a preliminary behavior change. Not a projected outcome, but the first chain in the story. It’s honest evidence that the design might have gotten the desired result, even if the product didn’t make it.

Naming a signal forces you to be specific. Instead of shipping a redesign and hoping something improves, you’ve made a concrete bet: this behavior will move because of this change. It gives you something to collect that doesn’t expire if the project gets cut.

What This Looks Like In Practice

You don’t need a research budget, a data team, or your PM’s permission. You just need to decide what you’re watching for before the work leaves your hands.

Start by asking yourself three things:

• What are users doing (or not doing) that’s costing the business?

• Why is it happening?

• What would you expect to see if your design fixed it?

Take onboarding, for example. The business might see users bailing before they even reach the core product. That’s the answer to the first question.

You talk to a few of them and find out why: too many decisions too early, and they give up before they see the value. That answers the second one.

So you simplify the steps, defer some choices, and before you run a single test, you ask: if this works, what would users do differently? More people are completing onboarding without hitting the skip button. That’s your signal.

In the session, five users run through it. Four reach the dashboard without backtracking. In the previous flow, two did. The behavior moved.

You document that. Not in a sprawling metrics framework. Just a note you can find later. What you expected to see, what you observed. That record travels with you. It doesn’t disappear when the roadmap shifts.

And when someone asks what you contributed to a project that never shipped, you have an answer.

Shipping Is Not In Your Control. Evidence Is.

The designers who can speak most clearly about their work aren’t the ones whose projects always launch. They’re the ones who knew what to watch for while the work was happening.

You weren’t without impact. The work moved something, in a test, in a session, in the behavior of five users who never knew they were proving your hypothesis right. The project got scrapped. That doesn’t mean the work did.

You don’t control the roadmap. You don’t control the budget. You don’t control whether the thing you spent months on ever reaches a single user. But you control whether you pay attention along the way.

Define the signal before you ship. Collect it while you can. Because the project might not make it. The evidence can.

Struggling with this issue? Book a free consultation to help untangle the issues you’re running into at work.

Kai Wong is a Design Educator and Storytelling Coach. He helps experienced UX professionals, from Mid-Level Designers to Directors of UX, get everything they need to advance their careers in a tricky job market.

“I think we need to slow down and do more user testing before shipping.” Sometimes, this statement seems like the hardest thing to tell a PM.

Sometimes a usability session finds major problems. Four out of five users stumbled in the same place, and one said it wasn’t frustration: they hesitated because they wouldn’t trust the process.

That’s a meaningful finding, but when you bring it back to your PM, you hear: “We’re already behind. What are we actually trying to learn that we don’t already know?” Or: “We can’t disrupt the timeline, just do your best.”

That pushback is fair. Your PM has a concern. And if all you have is “users seemed uncertain”, you’re not going to get the time you need.

What most design projects are actually about

Every design project you work on is about the same thing to businesses: changing user behavior.

The business sees that users are clicking “unsubscribe”, so you’re asked to redesign the feature to stop it. Design is how they get there.

That reframe matters because it clarifies what you’re actually arguing when you ask for more research. You’re not asking for time. You’re making a claim about why users aren’t behaving a certain way, and stating that the claim needs to be tested before the team ships something.

The Fogg equation

Dr. BJ Fogg, a researcher at Stanford’s Behavior Design Lab, developed a behavioral science model for thinking about why users do or don’t do things:

Behavior = Motivation + Ability + Prompt

Take something as common as creating an account.

Ability is whether someone can complete the task once they’ve started. Is the form too long? Are the error messages confusing? Are you asking for information users don’t have on hand? If ability is the problem, users want to sign up, but they just can’t get through it.

Prompt is whether something triggered the attempt in the first place. An email campaign, a CTA at the right moment, a nudge after a key action. If the prompt is weak or mistimed, users never even start.

Motivation is whether users actually want to do this, and whether anything is making them hesitant or uncertain. Do they understand what they’re signing up for? Does creating an account feel worth it? Is there something about the ask that makes them pause?

Why motivation is the hardest to defend

With ability and prompt issues, the questions can be answered by looking at analytics:

“How many people started this workflow?” → Prompt

“How many people completed this task?” → Ability

Motivation problems show up in what people tell you. That evidence is harder to quantify and easier for people to dismiss.

When you tell your PM “users don’t trust this step,” the reasonable follow-up is: how many users? How much is it actually driving the drop-off?

This is the confidence gap, and it’s where most designer advocacy quietly falls apart. Your PM isn’t dismissing your research. They’re waiting for you to show that the pattern holds beyond the session room.

The two-question survey

Nielsen Norman Group draws a distinction between attitudinal research (what users say) and behavioral research (what users do). Ability and prompt problems are behavioral. Motivation problems are attitudinal.

The way to measure motivation at scale is a targeted survey. Take the hesitations users described in your sessions and turn them into answer choices.

Use a two-step structure: first confirm whether the experience occurred, then ask what caused it.

Step one: a neutral filter question

“How did you feel during the sign-up process?”

• Confident throughout

• Uncertain at some point

• Confused at some point

• I didn’t complete it

Step two: only shown to people who selected uncertain or confused

“What caused that feeling?”

• Open text field

If the pattern from your sessions shows up at scale, you have your evidence. If it doesn’t, you’ve learned something equally valuable and saved your team from solving the wrong problem.

How to have this conversation with a PM

Frame it this way:

“I’m not trying to cause any delays, but we have a motivation problem we can’t fully explain. Right now, users told us that they’re hesitating because they don’t trust us. If we ship without understanding how widespread that feeling is, we might ship something no user wants to use. What I’m asking for is one targeted survey to find out. Then we’ll know exactly what we’re solving for.”

This doesn’t ask for open-ended research time. It presents a specific knowledge gap, a specific method, and a specific endpoint. The survey isn’t a delay. It’s the fastest way to get to a decision you can both stand behind.

That’s how you get your team to slow down and do good work when everyone just wants to hurry.

Struggling with this issue? Book a free consultation to help untangle the issues you’re running into at work.

Kai Wong is a Design Educator and author of The Designer’s Field Guide Newsletter. He helps designers explain, through 1:1 sessions, why their design work matters to businesses.

Imagine you’re starting a new project. You sit down for the kickoff meeting, and the PM walks in already holding something: a Figma Make mockup, a competitor screenshot, or an AI-generated wireframe from Sketch.

They already have a solution, and people are excited. They just look to you and say, “Can you ‘do your magic’ and make it ready?”

What do you do?

Push back too hard, and you become the person who slows things down. Stay quiet and execute, and you ship something that doesn’t solve the actual problem. Neither is a good place to be, and most designers choose the path of least resistance without fully clocking what it costs them.

Not today. Not this sprint. Three years from now.

This Problem Is Getting Worse, Not Better

This has always been an issue. PMs sketching in Balsamiq. Stakeholders emailing Paint mockups. Someone’s nephew who “knows Photoshop.”

But AI tools changed the stakes. Figma Make, Lovable, and v0 don’t just make it easy to generate mockups.

They make it easy to generate polished mockups. Something that looks considered. Something people get attached to before a single user has touched it.

When anyone can produce a credible-looking UI in five minutes, stakeholders arrive at the design conversation with their minds already made up. And the pressure on you, to execute, to refine, to just build the thing, gets heavier.

“Most people outside the design world think it’s pixel pushing — ‘I’ll tell them to design this in Figma and they’ll make it.’ That’s really like the last ten or fifteen percent. The rest is asking the right questions, understanding what value we’re going to bring.” — Enterprise Design Consultant

If designers don’t hold that line, the role gets commoditized. You become a polishing service. And polishing services get cut.

But here’s the part that’s hard to see while it’s happening: the damage isn’t immediate.

The Problem That Hides Until It’s Too Late

I recently worked with a designer on her portfolio. She was smart, experienced, and had a strong B2C background. She had an AI project she was proud of and wanted to lead with it.

I asked her one question: “What was the business problem?”

“We are trying to put together an AI solution.”

“Okay, but what’s the problem?”

“No, that is the problem statement. The company needs an AI story. Only companies with AI are getting investors right now. So we needed an AI story.”

She wasn’t wrong about the business reality. But somewhere along the way, the solution handed down from leadership had become the problem statement.

It wasn’t due to carelessness, but to organizational momentum. Nobody pushed back, so nobody had to. She was an expert at working within a frame. She’d just never been asked to set one.

Design recruiter Tom Scott put it plainly after reviewing the market:

“Most designers are more shielded than they realize.”

He’s not being critical: he’s describing the structural reality of how things used to work.

The PM defined the problem space. Research translated user behavior into insight. You sat at the intersection, receiving well-organized inputs and converting them into considered outputs. If you were good at it, you got promoted and given harder intersection problems.

https://medium.com/@nurxmedov/why-senior-ux-designers-are-struggling-in-2026-0bfca609dfb6

You were never asked to generate the inputs.

The brief comes in, the timeline is tight, and the PM already has a Figma draft. You execute. Then again. Then again.

Then, one day, you’re updating your portfolio, and you realize you can’t answer a basic question about any of your last five projects: what problem were we actually solving?

That’s not just a portfolio problem. The market has started grading on it.

The Compounding Cost Nobody Talks About

This is part of why Senior UX designers are struggling in 2026.

Figma’s 2026 State of the Designer survey found that 56% of companies are hiring senior design talent, but for a different kind of senior. They want designers who reduce organizational chaos. Not designers who need it reduced for them.

Staying in your lane feels fine in the moment. You ship. You hit the deadline. Nobody complains. But two years of that builds a portfolio that looks like you were told what to make and made it.

In a market where hiring managers spend thirty seconds per portfolio, that’s the problem, because what they’re scanning for isn’t outputs. It’s evidence that you understood what the business actually needed.

“Just following orders is less desirable right now. How you phrase past work plays a large role in whether you seem like someone who took orders and didn’t ask questions — or someone who partnered to get things done.” — Senior UX Designer, Healthcare

It doesn’t just happen to junior designers who don’t know better. It happens to experienced people in environments that never got pushed back on, until the damage shows up somewhere unexpected, like a job search that’s going nowhere.

Which is exactly why the fix has to happen before the work starts.

What to Do When You Get a “Just Build This”

When someone arrives with a solution they want polished, you’re probably not going to talk them out of it. That’s not the goal anyway.

The goal is to reframe the work, for the project and for what you’ll be able to say about it later.

Get concrete about the timeline

“As soon as possible” is not a timeline. It’s pressure with no information.

Pin it down. Is there a competitor launching in eight weeks? A board presentation in two? A product demo next Tuesday?

A specific date changes the entire scope of what’s realistic, and shifts the conversation from “why aren’t you moving faster” to “here’s what we can accomplish by that date.”

Vague timelines are where scope creep starts. A real date is the first line of defense.

Understand the outcome, not just the output

Businesses don’t actually want a design, on some level. They want a result that the design will create for them. More signups. Fewer support tickets. A demo that closes a deal.

Ask what success looks like after this ships. It gives you design direction beyond aesthetics, and it establishes shared criteria for whether the work was worth doing. You can’t write a case study around “I made it look nicer.”

Start summarizing through writing

This is the one most designers skip, and it’s the one that compounds most over time.

Most teams use AI notetakers now. After a kickoff, something like this lands in your inbox:

📋 Copilot meeting recap — Project Kickoff: Mobile Checkout Redesign

Meeting summary The team aligned on redesigning the mobile checkout flow. Sarah presented three competitor examples. Marcus noted engineering capacity is limited through Q2. The group agreed to move forward with a visual refresh of the current flow. Design to begin wireframes by end of week.

Action items

* Design team: deliver initial wireframes by Friday

* Marcus: confirm engineering availability for Q3

* Sarah: send competitor audit to full team

That summary accurately captures what was said and some key points. What doesn’t it capture? Key decisions that weren’t said, and what a decision-maker needs to know.

Before you open Figma, write a short note to your PM. Not a formal doc. Just your read:

“Hey Bill, quick thought before we kick off. In our last planning session, you said the goal was reducing checkout abandonment by 15% this quarter. I don’t think a visual refresh gets us there.

Abandonment at that stage is usually a trust problem, people hesitating at the payment step, not a layout problem. If that’s true, new colors and spacing won’t move the metric. Can we pull the drop-off data before we commit to wireframes? I want to make sure we’re solving the right thing.”

That gap, between what Copilot summarized and what you just wrote, is the territory that separates designers who execute from designers who lead. It’s not a framework. It’s just having an opinion before someone else provides one.

The Bigger Picture

Design’s strategic value doesn’t defend itself. Nobody’s going to advocate for problem framing on your behalf: that’s your job.

The good news is you don’t have to win every argument. You don’t have to be the smartest person in the room. You just have to show up the same way every time: a real timeline, a real outcome, and a point of view you formed before the room decided for you.

The cost of skipping those steps is invisible today. Three years from now, it isn’t. The designers who stay in the game won’t be the ones who had the best ideas.

They’ll be the ones who brought clarity with their design process, through clean and chaotic projects alike.

Struggling with this issue? Book a free consultation to help untangle the issues you’re running into at work.

Kai Wong is a Design Educator and author of the Data and Design Newsletter. He helps designers explain, through 1:1 sessions, why their design work matters to businesses.

Photo by Bujar Islamaj: https://www.pexels.com/photo/people-standing-around-sunken-suv-in-water-15630993/

Imagine you followed all the right steps, and users still didn’t use the product.

You talked to users. You ran the research. Created prototypes, did user testing and iteration, and shipped a solution you thought might genuinely solve the problem.

But then it launches, and six weeks later, nothing’s changed. When you go back to find out why, you discover the workaround: a word-of-mouth process, an unofficial channel, a habit so ingrained that nobody thought to mention it.

Nobody hid this from you. It just never came up — because you asked about the feature and they answered about it. The workaround was so normal to them it didn’t register as something worth mentioning.

This isn’t a research failure. It’s the question that was never asked:

How are users currently seeking help with this?

If you’re working in B2B design, this is one of the most important questions you can make a habit of asking.

What “Seeking Help” Actually Looks Like in B2B

This is a more common problem in B2B environments, because employees don’t choose their tools: they’re required to use them. When software is mandatory but confusing, users can’t give up. So they build structures around it.

It’s rarely dramatic. It’s usually friction that people have quietly learned to absorb.

Someone hits a wall and pings the one colleague who’s been on the product longest. That person answers again and loses twenty minutes. The knowledge lives in their head, not the product.

Or there’s a shared doc somewhere. A “how we do things” guide that was accurate eighteen months ago. Users find it, half-trust it, and proceed anyway because it’s better than nothing.

Or they follow a workaround their manager taught them in their first week: a sequence of steps that gets the job done without ever understanding why it works.

None of this shows up in your analytics as help-seeking behavior. The only things that show up are delays, lower productivity, and flat adoption of whatever you just shipped.

There’s another wrinkle: users often won’t volunteer this information. Partly because the workaround feels normal to them. But partly because they’re not sure they’re supposed to be using it.

If there’s any ambiguity about whether a shortcut reflects negatively on them (or if they’re breaking the law), users will answer your questions about the feature without ever mentioning the thing they actually do.

You have to go looking.

This is critical data that doesn’t show up on a dashboard

Workarounds don’t appear in dashboards, but they’re as real as any funnel metric, and often more informative. They tell you what users need badly enough to solve on their own, what they trust, and what bar any new feature has to clear.

As one designer, who worked in hospitality management, told me:

“I often get stuck with solutions. Even when I might have a better solution, users resist it because they’ve spent years building trust and familiarity in a 30 year old system.” — Senior UX Designer

That’s what asking about current help actually surfaces. Not more dashboard data: the data that exists outside it. And without it, you’re designing against a bar you can’t see.

Once you can see it, two things get easier.

You know what to prioritize. Most B2B roadmaps include features and requirements. Asking about help tells you which ones are load-bearing (i.e. the primary drivers that determine whether users actually switch) vs requirements that are nice to have.

You have a stakeholder conversation instead of a design opinion. “Users are currently solving this by asking one person, who’s spending eight hours a week fielding the same questions,” lands differently than “I think we need better onboarding.”

They might involve the same exact design idea or solution. But when you can speak directly to the cost of the current workaround — in time, in productivity, in risk — you’re not asking stakeholders to trust your design judgment.

You’re showing them what the problem is actually worth solving.

How to Actually Use It

You don’t need a formal research plan. You need to know which version of the question fits where you are in the project — and then go ask it.

Discovery — before anything is defined

This is where the question does the most work. You’re not asking about the feature yet. You’re asking about the behavior that exists without it.

• Walk me through what you do when you get stuck on [task].

• Who do you go to when you can’t figure something out?

• Is there a doc, a channel, a person, or a process you rely on that isn’t officially part of the product?

• How long has that been the way you handle it?

What you’re building here is a map of the existing help infrastructure, the one your feature will have to displace or absorb.

Design iteration — mid-project, active wireframing

Now you’re testing whether your design actually closes the gap you found in discovery.

The question shifts from “what do you do” to “would this change what you do.”

• If you hit this situation and the new feature was available, what would make you use it instead of [the workaround]?

• What would have to be true about this for you to trust it the first time?

• Is there anything here that would make you go back to [the old way] instead?

This is where you find out whether you’ve actually earned the switch—or just designed something that coexists with the workaround.

Pre-launch / stakeholder alignment

You’re not asking users here: you’re translating what you found into language that moves prioritization decisions.

• Here’s the current behavior: [X]. Here’s what it costs: [time, errors, dependency on one person]. Here’s what our feature needs to do to replace it: [Y]. Here’s what’s currently missing from the roadmap to get there.

It’s more about reframing a solution instead of asking a question.

But it comes directly from asking the question earlier, and it’s what turns user research into a prioritization argument rather than a design recommendation.

Post-launch / adoption troubleshooting

If adoption is flat, the workaround will probably work. The question now is which one and why.

• What do you do now when you need to [task] — are you using the new feature, or something else?

• When did you last use [the new feature]? What made you use it then?

• What would have to change about it for it to become your default?

The answer will almost always point back to something the workaround still offers that the feature doesn’t. Which is fixable — but only once you know what it is.

One Question. Every Project.

Sometimes B2B projects fail, not because of craft. The interface might be clean. The team was aligned. The solution was ‘technically good’.

What was missing was an understanding of what users were doing before the feature existed — and what it would actually take to make them stop.

That’s what this question gives you. By getting in the habit of asking this, at every stage of the project, you can always keep track of the user workarounds.

The workaround is always there. Someone built it, someone taught it, and someone is using it right now instead of whatever you shipped. The only question is whether you found it first, and if your design can replace it.

Kai Wong is a Design Educator and author of the Data and Design Newsletter. He teaches a course, Data Informed Design: How to Pitch Why Your Work Matters, on how to explain why your design work matters to businesses.

“Designers need to assume that, many times, it’s not our call. It’s not our final decision. Many of those business decisions are not ours anyway.” — Head of Design

‘Influence’ gets thrown around a lot in conversations about growing your design career, usually in the context of winning arguments.

But after talking with 28 design leaders, one subtle yet important distinction kept recurring when discussing influence.

Many design leaders aren’t trying to win every argument. They’re building something slower and more durable: the kind of credibility that means people come to them before decisions get made, not after.

You’re Not Trying to Win. You’re Trying to Be Worth Listening To.

Many of the designers I interviewed weren’t at design-centric organizations, which reflected the reality of the market.

Whether they were at early-stage startups or companies that had just decimated their design teams, they were often starting from scratch, without pre-existing power or political capital.

In those environments, the most effective designers weren’t playing the hero, fighting for every last initiative.

They weren’t consultants swooping in with recommendations or advocates pushing their position.

They were strategic advisors: people who bring their clearest thinking, present it honestly, and then trust the people around them to make the call.

That last part is where most designers get stuck.

We’re trained to advocate for users. We believe in our work.

So when a decision goes in a different direction, like the roadmap deprioritizing something we feel matters, it can feel like a failure.

But letting go is a skill.

“You have to separate your work from your ego… not everything you create is the right solution for this right moment.” — Director of UX

When you bring your best thinking and signal that you’re willing to let go, you do something most people in a room can’t: you make it safe for others to think alongside you. There’s no hidden agenda to navigate, no ego to manage around. That’s not passivity. That’s influence.

The Scenario That Tests How You Treat Influence

Your executive team opens it up: “We have four to six weeks of bandwidth this quarter. What should we focus on?”

Marketing has a feature request. Engineering wants to tackle technical debt. Sales is pushing a major client’s ask.

You, the UX person who spends more time with users than almost anyone, also have a perspective.

If you’re not a major player in your organization, you should come prepared with a position and a view of the larger picture.

The designers who build real influence come prepared not just with a position, but with a clear-eyed view of the full picture.

They present the user reality. They quantify the scale. They name the trade-offs. And then they trust the room.

“If I vehemently disagree with something, I will let you know and I will come in with strong opinions… but ultimately, I trust them to make really great decisions.” — VP of Design, Startups

Organizational Rigor — For Your Sake and Theirs

To help build that bigger picture, user observations aren’t enough. You also need to speak to scale.

One framework that helps is RICE — a product management tool that’s equally useful for designers thinking rigorously about what they’re proposing.

• Reach — How many people does this affect?

• Impact — How much of a difference will solving it make?

• Confidence — How certain are you, based on what you know?

• Effort — How much work will it take?

Most designers already think intuitively about Impact and Effort. Reach is where the discipline sharpens. It moves you from “this confuses users” to “this likely affects 37,000 people, most of them our core audience.”

Getting there can be as simple as two questions:

• Where in the workflow does the problem occur, and

• Do we have any data on how many users reach that step?

If you’re flagging a broken bulk upload flow, check whether it’s early or late in the user journey, then look at how many users actually land on that page.

The number doesn’t need to be precise. But by saying “this initiative affects 37,000 people”, and backing it up with analytics and the user workflow, is exactly what a thoughtful advisor brings.

Why Letting Go Is Part of the Job

Sometimes, you’ll bring rigorous thinking, quantify the reach, name the trade-offs, and it doesn’t work.

Sometimes the organization will still go a different direction. That’s not a failure of influence. That’s just how influence works sometimes.

Real influence isn’t getting your way 100%. It’s about playing a larger part in shaping how decisions get made over time. It’s about being the person who brings the big picture, whose questions are heard, and whose perspective people want.

“Don’t show up to a meeting without at least some qualitative or quantitative research. If you lack it, say: ‘This is my assumption — I’d like to validate it.’ Be clear about what you’re certain of. I’m just a messenger. I’m bringing you the facts.”— Head of Design, Startup

If you’re constantly fighting for every initiative? You often become known for strong opinions, and people start going around them.

How to Start Building This Type of Influence

The entry point is simple: develop strategic curiosity, and pair it with the discipline of letting go. Start asking questions that get you closer to the business picture:

• “What does a typical week look like for you?”

• “Can you help me understand this metric? I think it’ll help me design a better solution.”

• “Who else is affected when this goes wrong?”

And when you make your case, try finishing with: “That’s my take. Happy to be wrong, and curious what I’m missing.”

It signals that your goal isn’t to win. It’s to get to the right answer.

In an environment where everyone’s fighting for airtime, that calm, prepared, non-defensive presence is rare. It’s also exactly what sustained influence looks like.

Want to learn how to gain influence at work? Enrollment in Make the Case, where you how to sell your ideas, ends in 5 days.

Kai Wong is a Design Educator and author of the Data and Design Newsletter. He teaches a course, Make the Case: How to Pitch Why Your Work Matters, on explaining why your design work matters to businesses.