OKRs for design teams: measurable objectives without losing judgement
OKRs connect a design team's objectives with the company's through measurable key results. How to write them and measure outcomes, not deliverables.
What are OKRs and where do they come from?
According to Wikipedia, Andrew Grove popularized the method at Intel in the 1970s, where it was called iMBO, and documented it in his book High Output Management (1983). John Doerr, who attended a course taught by Grove, later brought it to Google. Google today describes it in its re:Work guide as a way to set ambitious goals and track progress, with annual and quarterly OKRs.
In its basic form, the objective answers what we want to achieve next quarter; the key results answer how we will measure progress. Tability uses the same questions in simple terms and adds a third: which projects are our best bets to get there.
Their value lies in alignment. If the company wants to retain customers, the design team can have an objective that contributes to that goal and that the rest of the team understands. Without that link, design works on whatever seems most urgent and nobody knows whether it helps.
Why is it hard for design?
Because design work is harder to quantify than sales or marketing work. Tability puts it this way: designers deliver creative assets that provide business value indirectly, and that is not always easy to measure.
The temptation is to write key results that sound like measurement but are really activity: “deliver 30 screens”, “run five tests”, “build a component system”. Those numbers say how much was done, not whether it helped.
How do you write a good design OKR?
A practical method has three steps:
- Start from the user or business outcome. Ask what should change for the design work to be worth doing.
- Write the objective in plain language. For example: “Reduce usability problems that reach production”. Weekdone suggests the objective should answer “what do we hope to achieve” and be inspiring and clear.
- Define a few measurable key results. Wikipedia speaks of three to five per objective; Google’s guide, of around three. They should be specific, measurable, achievable, relevant and time-bound (SMART, according to Weekdone). Illustrative example: “Bring usability problem reports from 40 to 20 per month before the end of the quarter”. Tability offers examples of the same kind, such as UX issues making up fewer than 20% of new bug reports.
Tability offers a useful test for each key result: would we do things differently if this result goes off track? If the answer is no, the OKR needs refining.
How are they scored?
Wikipedia describes a scale from 0.0 to 1.0. According to the same source, an aspirational key result aims for 0.7, while a committed one, such as delivering a product or meeting a deadline, should reach 1.0; Doerr recommends a target success rate of 70% for key results. Google’s re:Work guide agrees on the essentials: it uses a 0 to 1.0 scale, says the sweet spot is in the 60-70% range, and does not expect an average of 1.0, because goals are set just beyond what seems possible.
What matters is using one approach across the organization and reviewing at the end of the quarter what was learned, not only which score was obtained. Google adds that OKRs are not synonymous with performance evaluation.
What is the difference between an output and an outcome?
The most important distinction for design is this one. An output is what you produce: screens, prototypes, documents. An outcome is the change it causes in people or in the business. Both Weekdone and Tability present OKRs as a way to keep an outcome-driven focus rather than an output-driven one, so that the team is not measured by what it delivers.
This distinction is explored further in the note on outcomes versus outputs, which is worth reading before writing your first OKRs. To choose an indicator that can serve as a key result, see also the north star metric. If a key result sounds like a deliverable, it probably needs rewriting.
Example
Illustrative example: the design team of a digital bank has the objective “Customers complete account opening without calling support”. Its three key results are: reduce abandonment at the identity-verification step from 35% to 20% within the quarter, bring document-related support queries below 50 per week, and get 80% of test users to complete the flow without help. The screens the team delivers are the means, but they do not appear in the results. At the end of the quarter, the team reviews what worked and what did not, and decides the next objective.
For your team: review your current OKRs and mark the key results that describe deliverables. Rewrite them as changes in someone’s behaviour.
When should you NOT use them?
- When the team is very small and objectives change every week. This is practical judgment, not a measured fact: a quarterly framework does not fit goals that last days.
- When the company has no clear objectives and the design team tries to invent the strategy on its own.
- When OKRs are used to evaluate people instead of tracking the team’s progress. Google clarifies they are not synonymous with performance evaluation, and Wikipedia notes that most organizations no longer define individual OKRs because they tend to look like task lists and get conflated with performance reviews.
- When there is no reasonable way to measure the result. Then start with a provisional indicator and review it.
Common mistakes
- Using results that are activities, such as “run five interviews”.
- Having more than five key results per objective.
- Writing vague objectives such as “improve the experience”.
- Ignoring alignment with the company’s objectives.
- Not reviewing mid-quarter and discovering at the end that the result did not move.
- Using the scoring scale as an individual evaluation.