A Design OKR Check-In Template That Doesn't Turn Into a Crit

I've run OKRs for design teams for about a decade, and the check-in is where they live or die. The hard part with design isn't the work, it's keeping the weekly check-in from collapsing into a critique session where everyone argues about a corner radius and nobody looks at whether the thing got used. So I built this template around two signals: adoption and usability. Here's the exact set of questions, how I score it, and how I run the whole thing without a standing meeting.

By Max Bondarenko · Last updated June 2026

The template, up front

I'm not going to bury this. A design OKR check-in is different from an engineering or growth one, because the work is half measurable and half taste, and the taste half is where check-ins go to die. The trap is letting the meeting turn into a crit. So I keep the design check-in pointed at two things only: adoption signals (is anyone actually using the thing we shipped) and usability signals (can they use it without bleeding). Craft progress rides along, but it never becomes the agenda. Here's the exact set of questions I ask every cycle.

The 5 questions

01What's the number now versus where we started and where we're headed? (e.g. task success from a 72% baseline to a 90% target, component adoption from a 40% baseline to an 85% target)
02What did real users do this week that we can point to, not what did we ship?
03Where is the craft still rough, and is that roughness blocking the metric or just bugging us?
04What did we learn that says the target itself is wrong?
05What's the one thing that has to move before the next check-in, and who owns it?

Why each question is there

The first question is non-negotiable and it has three parts on purpose: now, start, target. A design team will tell you "component adoption is up" and feel great. Up from what? If you went from a 40% baseline to 47% and the target's 85%, you're not up, you're stalled with a nice slope. Forcing the baseline next to the target every single week kills the false comfort. Same with task success. "Most people can complete it" means nothing. A 72% baseline against a 90% target means something, and it tells you 28 of every 100 people are still failing the flow you're proud of.

Question four is the one most teams skip, and it's the one that's saved me the most pain. The whole point of a weekly check-in is to revise a wrong target early, in week 4 not week 12. If your component adoption goal assumed three product teams would migrate and only one had bandwidth, the target's broken, and pretending otherwise for two more months is just slow lying. Catch it in week 4 and you re-baseline while it's cheap. I'd rather lower a number in week 4 with a reason than miss it in week 12 with an excuse.

Here's the aside. A team I ran spent a whole quarter polishing a settings redesign that everyone loved in review. Beautiful. We never once asked question two: what did real users do. Turns out adoption of the new flow sat at an 11% baseline against a 60% target, because the entry point was buried two clicks deep. We'd been grading our own homework in the crit for eleven weeks. Now question three explicitly separates "craft that's blocking the metric" from "craft that's just bugging us," because designers will burn a cycle smoothing a corner radius nobody's stuck on while the real funnel leaks. Rough is fine if it's not the thing in the way.

Scoring without turning it into a critique meeting

I score on the metric, never on the artwork. The state of an OKR is about whether the number's moving at the pace it needs to, full stop. Whether the screen is pretty is a separate conversation that belongs in design review, not the check-in. Three states, and each one comes with a single action so nobody leaves the meeting wondering what happens next.

On track	Number is moving at or above the pace the target needs (e.g. task success climbing from a 72% baseline toward a 90% target on schedule). Action: leave it alone, protect the team's focus, do not add scope.
Behind	Moving in the right direction but too slow to hit target (e.g. component adoption at 55% against an 85% target, baseline 40%, with time running short). Action: name the single biggest blocker and reassign one person to it this week.
At risk	Flat, dropping, or the target itself looks wrong. Action: stop and decide in the meeting: re-baseline the number, cut the scope, or kill the key result. Don't carry it another week to be polite.

How to actually run it

Async by default. Each key result owner posts the five answers in writing before any call, with the now-versus-start-versus-target number at the top. Most weeks that's the whole check-in and nobody meets at all. Writing it down forces honesty in a way a verbal "yeah we're good" never does, and it gives you a paper trail when you re-baseline in week 4.

You only pull people into a room when something's "at risk" or two owners disagree on whether a number's real. Keep the live version to 25 minutes, owners only, no audience, no screen-sharing the design file. The moment someone pulls up a mockup to defend a pixel, you've lost the meeting and turned it into a crit. I skip the live check-in entirely on any week where everything's on track and the writeups agree. A green week doesn't need a meeting. Save the calendar time for the week something's actually on fire.

Questions people actually ask

How do I measure design craft if I'm only scoring metrics?

You don't score craft in the check-in, you score whether the metric's moving. Craft lives in design review, where it belongs. If the craft is genuinely blocking a number, like a confusing layout dragging task success below its 90% target from a 72% baseline, then it shows up as the blocker behind a 'behind' or 'at risk' state, which is the honest way to surface it.

What design metrics actually belong in an OKR check-in?

Adoption and usability, almost always. Things like component adoption going from a 40% baseline to an 85% target, or task success from a 72% baseline to a 90% target, because they're observable and they tell you if the work landed. I stay away from satisfaction scores as primary key results; they move slowly and they let everyone feel good while the funnel quietly leaks.

Won't an async-first check-in let problems hide?

It's the opposite. A verbal 'we're on track' hides problems; a written 'task success is 74% against a 90% target, baseline 72%, here's the blocker' can't. The async writeup forces a real number next to the target, and the moment one looks soft you pull that owner into a 25-minute room. Hiding is harder in writing, not easier.

When is it too late to change a design OKR target?

If you're changing it in week 11 of a 12-week cycle, you waited too long and you're just managing optics. The right window is week 3 or 4, when you've got real adoption data and re-baselining is cheap. That's the entire reason question four exists: catch the wrong target while there's still time to do something about it.

Stop running check-ins in a spreadsheet

Okiar is free during beta. Voice check-ins, AI projections, team health — live in minutes.

Start free →