Your Design Portfolio Can Show Impact Without Perfect Analytics

A designer I was talking with had done meaningful work at an early-stage company. She had helped the team clarify the product, improve onboarding, and make a complicated workflow easier to understand.

Then we reached the result slide in her portfolio.

The company had limited analytics. There was no clean funnel, no research repository, and no reliable before-and-after dashboard. She knew the work had changed the product, but she could not attach a confident percentage to the change. The case study suddenly sounded smaller than the work.

This pattern repeats across portfolios. Designers are told to show impact, so they go looking for a conversion number that may not exist—or may not be theirs to claim.

Perfect analytics would help. Their absence does not mean the work had no impact.

A strong design portfolio can show a credible chain between the problem, the decisions, the observable change, and the outcome the business cared about. The goal is not to manufacture certainty. It is to make the available evidence legible and be honest about where it ends.

Impact Is Not One Number

The portfolio version of impact often gets compressed into a formula: I redesigned this flow, and conversion increased by 18 percent.

That is compelling when the measurement is sound and the relationship is defensible. It is also a narrow picture of how product work creates value.

A design decision may reduce the time employees spend correcting an order. It may help more customers complete setup without support. It may give a product team enough confidence to stop debating a direction and test it with real users. It may expose a risky assumption before the company invests in building the wrong thing.

Those outcomes sit at different distances from revenue, retention, or cost. They still matter.

The important question is not, “Do I have the biggest possible metric?” It is, “What changed, what evidence do I have, and how close can I responsibly connect that change to product or business value?”

The key word is responsibly.

A company may have grown after a redesign. Marketing, pricing, seasonality, sales, engineering improvements, and the redesign may all have contributed. A portfolio becomes less credible when it assigns the entire result to one person because the number looks good on a slide.

Build an Evidence Ladder

When the final business metric is unavailable, move through the evidence you do have.

Think of it as a ladder:

1. Decision evidence: The work changed what the team understood, prioritized, or chose to build.
2. Experience evidence: Testing or observation showed that people could understand or complete the workflow more successfully.
3. Behavior evidence: People adopted the feature, completed the task, returned, or needed less assistance.
4. Operational evidence: The change reduced handling time, rework, errors, support volume, or another cost of delivering the experience.
5. Product or business evidence: The work contributed to activation, retention, conversion, revenue, risk reduction, or strategic progress.

The highest rung is not automatically the only valuable one. It is simply closer to the outcomes the organization ultimately needs.

Your job is to reach the highest rung your evidence supports without stepping over the missing ones.

If usability testing showed that five of six participants completed a previously confusing task, say that. If support heard fewer questions after launch but nobody tracked the volume, describe it as directional feedback and name the source. If the team shipped the work but never measured adoption, shipping is part of the story—not proof that the customer outcome occurred.

This is close to how I think about the signals that tell you design is working. Some signals appear before a dashboard can confirm the result. They become useful when the team treats them as evidence to investigate, not as permission to overstate the conclusion.

Reconstruct the Evidence You Already Have

Early-stage teams may not have formal telemetry, but they usually leave traces.

Look through the material around the project:

• research notes, usability sessions, and prototype feedback;
• support conversations and recurring customer questions;
• release notes, issue trackers, and quality reports;
• sales or onboarding feedback about objections and confusion;
• product reviews where the team made a decision;
• implementation changes that removed steps, dependencies, or manual work;
• follow-up conversations with the people who used or supported the product.

None of these should be turned into a number they cannot support. Together, they can show what the team observed before the work, what changed in the product, and what happened afterward.

For example, “Improved onboarding” is vague. A more credible account might be:

> Customer calls repeatedly stalled at account setup because administrators did not know which information they needed. I mapped the failure points with support, reorganized the sequence, and tested the new flow with six representative users. Five completed setup without prompting. The team shipped the flow, but did not have reliable post-launch activation data, so I cannot claim a conversion change.

That result has a boundary. It also has evidence.

The boundary makes the claim stronger because the reader can see the difference between what was observed, what was shipped, and what remains unknown.

Separate Contribution From Attribution

Portfolio case studies also get tangled when designers try to prove individual impact inside collaborative work.

You should make your contribution clear. You do not need to make the product look like a solo project.

Name the decisions you led, the evidence you brought into the room, the people you worked with, and the tradeoffs you helped resolve. Then describe the team outcome at the team level.

A useful structure is:

• The product needed: the user, operational, or business change the team was trying to create.
• The team decided: the direction chosen and the meaningful tradeoff behind it.
• I contributed: the research, framing, design, facilitation, or implementation work you specifically owned.
• We observed: the strongest result the available evidence supports.
• We could not determine: the missing measurement, unresolved risk, or longer-term outcome.

This keeps ownership visible without rewriting collaboration as individual heroism.

It also shows judgment, which matters more than a polished sequence of artifacts. As I wrote in When AI Makes the First Draft, Your Portfolio Needs to Show Your Judgment, the useful story is not only what you produced. It is how you understood the problem, used evidence, made tradeoffs, and changed the direction of the work.

Use Proxies Without Pretending They Are Outcomes

A proxy is an indirect measure that gives the team some reason to believe it is moving toward an outcome.

Task completion may be a proxy for activation. Reduced setup time may be a proxy for lower service cost. Fewer repeated questions may suggest that an interface is becoming clearer.

Proxies are useful. They are not interchangeable with the outcomes they point toward.

Name the relationship instead of collapsing it:

• “We reduced the number of required steps from nine to five, which we expected to reduce abandonment.”
• “In moderated testing, participants completed the revised task with less prompting; post-launch completion was not instrumented.”
• “Support reported that the new status language resolved a recurring source of confusion; ticket volume was not categorized well enough to quantify the change.”

The language stays direct while preserving what the team actually knows.

If you do have several measures, organize them rather than filling the case study with numbers. Google's HEART framework is one useful reminder that user experience can be examined through happiness, engagement, adoption, retention, and task success. Not every project needs every category. The framework helps reveal which kind of evidence fits the change you were trying to make.

Let the Missing Measurement Show Maturity

Don't hide what the team did not measure. Make it visible—briefly, and without turning the case study into an apology.

You might write:

> If I continued this work, I would instrument setup completion by step, establish a baseline before release, and compare activation by customer segment. During this project, those events were not available.

That sentence tells the reviewer three things: you understand what stronger evidence would look like, you know the limit of the current claim, and you can improve the way the next team learns.

For current projects, move that thinking earlier. Before the work ships, write down the intended change, the leading signal, the outcome measure, and who can help collect it. Even a small measurement plan is better than trying to reconstruct impact six months later.

This is also how design gets closer to product outcomes without pretending every decision maps directly to revenue. The connection becomes explicit enough to discuss, test, and improve. The portfolio is then documenting a real operating habit, not adding business language after the fact.

Credibility Is the Result

A portfolio does not need to prove that every project transformed the company.

It needs to show that you can recognize the value the team was trying to create, make decisions that move toward it, and evaluate what happened with the evidence available.

Sometimes that evidence will be a clean product metric. Sometimes it will be a usability result, an operational change, a decision the team could finally make, or a risk avoided before launch. Sometimes the honest result is that the product shipped and the team failed to measure what followed.

Say which one it was.

The absence of perfect analytics is a constraint. Inventing certainty is a credibility problem. A strong case study makes the chain of evidence clear, stops where the evidence stops, and shows that you know what the team should learn next.