Stop Reporting What Your Team Did. Start Reporting What Changed.

You already know your work is good. That was never the problem. The problem is that the numbers you bring to a budget review don't sound like the numbers your CFO tracks. This quarter gave us a few clear ways to fix that, plus a warning about what happens when "easy" becomes the only goal. Let me catch you up.

The language gap that gets you cut

When you report "24 interviews and 3 usability studies," leadership hears money spent with nothing to show. When you report a SUS score jumping from 62 to 74, a finance chief has no idea if 74 is good. Those are two different languages, and Lola Famulegun at NN/g is blunt about the cost: teams that can't connect work to business outcomes get filed as cost centers and cut.

The fix is to measure further down the chain. Task success rate is upstream. Support contact volume, conversion, and churn are downstream, and downstream is where the dollars live. "Contacts about this feature dropped 30% after the navigation change" travels in a budget meeting. A SUS score does not.

One catch: this only works if you can get the data. If your team isn't wired into product analytics, customer support, or finance reporting, that's your first conversation, not your last.

The five questions behind every yes

Leaders judge any spend by five things: does it grow revenue, cut cost, lower risk, ship faster, or keep customers. Your job is to plant your work under one of those, with a before-and-after number attached.

Cost is the easiest win. Every support call has a price. Confusing error states and broken onboarding create what operations teams call "failure demand," contacts that exist only because the product failed the user. Redesign a flow, then show the drop in contacts about that flow. Speed is another one. Catch a problem in Figma and it's cheap. Catch it after build and you're paying for engineering time, QA cycles, and a slipped date.

Even directional data works if you're honest about it. A McKinsey finding NN/g cites is the whole reason this matters: more than half of companies had no objective way to judge their design teams' output. When you don't hand them a number, they use gut feel, or they trust the team that did hand them one.

When easy is the wrong target

Here's the warning. Optimizing one interaction is not the same as optimizing the system it lives in. Michael Buckley walks through job applications to make the point. Ten years ago about 15% of applications led to an interview. Now it's 2 to 3%, and recruiters see over 300 applicants for a single opening.

What happened? One-click apply and AI-written resumes dropped the cost of applying to almost nothing. Great for the individual applicant. Terrible for the pool. Recruiters had to lean on screening bots, so employers now find the candidates who best game the filters, not the best candidates.

Sometimes friction serves a purpose. It signals real intent and protects a scarce resource, which in hiring is human attention. Before you strip friction out of a flow, ask what that friction was quietly doing for the wider system. You may just be moving the pain somewhere you can't see it.

One AI explanation does not fit the room

If your team is shipping enterprise AI, NN/g's Hayley Mortin and colleagues draw a useful line. The people approving and building an AI system need different explanations, sorted by their job to be done.

Governance leads work at the system level. They want global explanations: audit trails, failure modes, where confidence scores fall below the acceptable line. A single answer tells them nothing. Builders work at the input-output level. They want local explanations that double as debugging, like why one output happened and what to change. Their example: password-reset requests kept getting escalated to a human when they should have been self-service, and the builder needs to know if the fault is in the prompt, the integration, or the confidence threshold.

Map the explanation to the role, or you build trust with nobody.

The handoff that still has no memo

Everyone's seen the demo: connect Figma, type a sentence, get a working screen. Then it breaks on your real project. Christine Vallaure explains why. The demo shows one clean layer. Your work needs three or four stacked, and nobody shows you the stack.

An MCP is the wiring that lets a tool like Claude read your actual Figma file instead of a screenshot. But it copies your button's color and corners while ignoring the real reusable button in your codebase, so it builds a fresh lookalike every time. Markdown files hold your rules and reasons, but they're guidance the AI reads, not a rule that runs, so it can drop them when a screen gets complex. Code Connect is the real wire, pointing each Figma component at its exact file in code. That last layer needs developers.

The deep cut

The outcome argument and the Figma-to-code map are the same fight. Both come down to owning the parts your work touches downstream. You can't claim a 30% drop in support contacts if you never linked your redesign to that data. And AI can't reuse your real components if nobody built the Code Connect wire between design and code. The credit and the quality both live in the plumbing, not the pixels. So the move this quarter is unglamorous: get access to the downstream numbers, and get your design system mapped to the codebase. Do those two, and both arguments get easier next review.

Three questions for your team

1. For each project we shipped this quarter, what downstream number moved, and do we actually have access to prove it? If not, who in finance, support, or analytics do we need to call first?
2. Where in our product did we strip out friction that was doing a real job, and what got worse somewhere we're not measuring?
3. Is our design system wired to the codebase with Code Connect, or is AI rebuilding lookalike components every time a designer hands off?