How Do You Talk About the Impact of Scrapped Design Projects?
How to avoid telling a story that has no ending
“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.
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.