Adobe. 10,000 people. One OKR system. One missing concept.
Everyone needed to see
the strategy. Not everyone should own it.
A feature designed from discovery to handoff for Adobe's leadership teams — separating visibility from accountability inside Quantive Results, an enterprise OKR platform.
Problem
Adobe's leaders had to become OKR participants just to monitor strategy — adding unwanted accountability to 10,000-person workflows.
What I did
Defined the Watch participation state from scratch — real data model change, self-serve toggle, bulk panel. 7 days, solo, discovery to handoff.
Outcome
+40% OKR visibility among leadership, −28% unnecessary participant additions. Shipped to Adobe, zero revisions after handoff.
01 / Context
The brief
I was a Product Designer at Quantive, a company that built Quantive Results — an enterprise OKR (Objectives and Key Results) platform used by large organisations to align strategy across hundreds of teams. Adobe was one of those organisations, running Quantive Results across a 10,000-person workforce.
The ask from Adobe was intentionally broad: they had a problem with how visibility worked in the platform, and they needed it solved. That was the brief. No wireframes, no feature spec, no reference design. Adobe's program managers and leadership were being pulled into OKR structures they had no part in — and they needed a way out. Everything from discovery to solution to handoff was mine to define.
7 days. One designer. The feature shipped and is in use today.
02 / Problem
Visibility was the same as ownership
"In Quantive Results, you either owned an OKR or you couldn't see it. There was no middle ground. Adobe's teams were drowning in accountability for OKRs they had nothing to do with."
Quantive Results had two participation states: you were a participant in an OKR (with all the accountability, notifications, and responsibility that carries) or you were invisible to it. In a company of 10,000 people running hundreds of OKRs across departments, this binary created a real operational problem.
Program managers and leadership at Adobe needed to monitor OKRs across teams they didn't directly own — to spot blockers, track cross-functional dependencies, and stay informed on strategy execution. But the only way to see an OKR was to be added as a participant. Which meant they were receiving accountability emails, appearing in responsibility reports, and being treated by the system as owners of work they had nothing to do with.
The system was conflating visibility with ownership — and Adobe's teams were paying the operational cost every week. What the platform was missing wasn't a feature. It was a concept.
03 / My Process
Discovery to handoff
Adobe gave me a problem, not a solution. That's the ideal brief — but it requires a sharper process. Here's what the 7 days actually looked like.
Discovery — understand the system before touching the problem
Before designing anything, I needed to fully understand how Quantive Results modelled participation. What did "participant" mean in the backend data model? What notifications did it trigger? What reports did it feed into? I worked with engineering to map the current participant system — because any new participation state would need to be genuinely separate, not just a UI mask on the same role. This was the most important day of the 7.
Define — name the missing concept
The design problem wasn't "add a read-only mode." It was: define a new participation state that carries no accountability weight. I named this the Watch state. Watchers have full visibility into an OKR — progress, updates, status, commentary — but don't appear in responsibility reports, don't receive accountability notifications, and don't affect the contributor list. Naming it clearly shaped every downstream decision.
Design — explore the interaction options
With the concept defined, I explored how users would enter the Watch state. Two main paths: owner-managed (a Stakeholders section where owners curate their audience) vs. self-serve (a Watch toggle anyone could activate independently). I prototyped both, stress-tested them against Adobe's actual use cases (a VP watching 40 OKRs, a PM monitoring cross-functional dependencies), and evaluated where each broke down.
Validate — test against the real use case
The owner-managed approach added work to OKR owners — they'd need to manage an audience, which still implied some ownership of who could see their work. Self-serve matched how Adobe's teams already behaved in Jira and GitHub. I chose self-serve as the primary pattern, added a watcher management panel for owners (for the bulk-addition use case), and validated the placement with a round of internal feedback before finalising.
Handoff — present to Adobe's product team
Final Figma delivery included the full interaction spec, all states (watcher vs. non-watcher, OKR owner view vs. participant view, notification preferences), the watcher management panel, and annotated edge cases. Presented directly to Adobe's product team. Feature shipped within the quarter.
04 / Design Decisions
4 decisions that defined
the Watch feature.
Each decision was a trade-off between power and simplicity — in an enterprise system where the wrong choice has real operational cost.
Separate visibility from responsibility — in the backend, not just the UI
A new participation state that carries zero accountability weight.
The temptation was to build a UI mask — show the OKR, but hide the notification triggers. That would have been fragile. The right answer was to work with engineering to define the Watch state as a genuinely separate entity in the data model: a Watcher doesn't appear in responsibility reports, doesn't receive accountability notifications, doesn't affect the contributor list, and isn't surfaced when OKR ownership is audited. The UI followed from the data model, not the other way around. This is the hardest part of designing inside an existing system — getting the concept right before you draw anything.
Self-serve Watch toggle over owner-managed stakeholders list
Match how Adobe's teams already behave — in Jira, GitHub, and every tool they use daily.
Option A: a Stakeholders section managed by the OKR owner. Option B: a self-serve Watch toggle anyone can activate. Option A gives owners control but creates a management burden — they'd need to curate an audience, which implies they're responsible for who sees their OKR. That's the exact dynamic we were trying to eliminate. Option B matched how Adobe's teams already operated. A VP who wants to watch 40 OKRs shouldn't need to contact 40 owners. I chose self-serve as the primary pattern, and kept an owner-facing management panel for the bulk-addition use case.
Eye icon in the OKR header — a preference, not an action
The placement tells the user what kind of thing this is before they click it.
Early explorations put the Watch button in the primary action bar, alongside Edit and Share. It tested as too prominent — it made watching feel like a core workflow rather than a lightweight ambient preference. A Followers section below the OKR description tested as too buried — users missed it. The OKR header — where you'd find metadata like owner, time period, and status — was the right level of prominence. It says "this is a preference about how you relate to this OKR" rather than "this is something you do to this OKR." The eye icon made it instantly scannable without demanding attention.
Watcher management panel for bulk administration
A VP watching 40 OKRs across departments can't do it one toggle at a time.
The self-serve model works perfectly for individuals. It doesn't work for leadership at scale. A chief of staff adding a VP as a watcher across every relevant OKR in a quarter — that's 20-50 OKRs, one-by-one, manually. I designed a watcher management panel for OKR owners that showed who was currently watching and allowed bulk additions. This was the feature that made the Watch layer actually usable for Adobe's most senior users, who were precisely the ones the whole feature was built for.
The hardest part wasn't the UI. It was defining a new participation state inside a system where every existing state carried accountability weight.
— On designing the Watch feature for Quantive Results
05 / The Feature
The Watch layer —
what it is and how it works.
Read-only visibility
Watchers see everything a participant sees — progress, updates, status, comments — with no ability to edit, update, or affect the OKR in any way.
Zero accountability
Watchers don't appear in responsibility reports, aren't included in accountability notifications, and aren't surfaced when OKR ownership is reviewed or audited.
Single-action toggle
An eye icon in the OKR header. One click to start watching, one click to stop. Fully reversible, zero management overhead, no owner action required.
Notification preferences
Watchers choose their update frequency — real-time, daily digest, or weekly summary. Eliminates inbox noise for people watching multiple OKRs.
Owner visibility
OKR owners see a list of current watchers in the management panel. No privacy concerns — watching is transparent to the owner by design.
Bulk watcher management
OKR owners and chiefs of staff can add watchers in bulk via the management panel — critical for the leadership use case of watching 40+ OKRs across a quarter.
06 / Outcome
Measured at 8 weeks post-launch
The metric that mattered most wasn't in any dashboard — it was the drop in support tickets tagged "wrong participant added." That was the human problem the feature solved, and it showed up in the first month.
+40% increase in OKR visibility among Adobe leadership roles — tracked via Quantive's analytics on OKR views by non-participant users.
28% reduction in unnecessary participant additions — compared week-on-week before and after launch.
Feature presented directly to Adobe's product team, shipped within the quarter, no design revisions required after handoff.
07 / Reflection
What I'd do differently
"The best designs solve the problem you can see. The best designers also solve the problem that will appear three weeks after launch."
The notification design for watchers was the weakest part of V1. Watchers received the same update digest as participants, just with accountability language removed. In the first two weeks, several users who were watching 15+ OKRs had noisy inboxes — they were getting event-triggered notifications every time any watched OKR had an update, which defeated the "lightweight ambient awareness" the feature was supposed to provide.
In retrospect, I'd have designed a separate watcher digest from the start — a weekly summary format rather than event-triggered notifications. One email on Friday morning: "Here's what's changed across the OKRs you're watching this week." That would have made watching feel genuinely lighter. The feature solves visibility without ownership — the notifications should have felt the same way. This is the lesson: the participation state was right. The communication model should have matched it better.
Want to see the Figma?
7 days leaves a lot of
work off this page.
The full Figma file has every state, every edge case, the watcher management panel, the notification spec, and the annotations I presented to Adobe. If you want to walk through it, I'm happy to.