case study
OKRs for Goals
Context
Atlassian's Goals app had a basic implementation of OKRs, but it was built on a generic goal and sub-goal hierarchy. To create key results for an objective, users had to create them as sub-goals, a workaround that didn't match how anyone actually thinks about OKRs. An objective and its key results are a single unit: one outcome you're trying to achieve, measured by a few specific results. Forcing them into a parent-child structure created confusion creation, viewing, and reporting on progress.
This was blocking enterprise adoption. We were hearing directly from customers and from our enterprise sales team that the OKR experience wasn't good enough to adopt our app.
The resulting OKR experience after the redesign
Learning how customers actually structure goals
I ran co-design sessions with customers to understand how OKRs would cascade through their organisations. Rather than testing a specific solution, I wanted to learn how they thought about the relationships between objectives, key results, and the teams responsible for them. These sessions revealed the nesting patterns and hierarchies that customers needed to support, and confirmed that our existing goal/sub-goal model couldn't accommodate them naturally.
I also ran a workshop with internal stakeholders who had the expertise in OKRs and serving our enterprise customers, where we co-created archetypes and jobs to be done. The relationship with this team had become strained because of the perception that we were ignoring enterprise requirements, this session helped re-build trust.
The shared archetypes and use cases we created with our partner team
Exploring the range of options
I worked with PM across several product and design sprints to find the right direction. We explored a wide range of options from lightweight changes to copy and UI, through to several fundamentally different data models. The question was whether we could solve the problem at the surface level, or whether we needed to change something deeper.
To answer that, I worked backwards from the ideal user experience. I mocked up what the creation and reporting flows should feel like if there were no technical constraints, and then compared that against what the more superficial changes could deliver. I created task-based demos to walk stakeholders through the difference, and it became clear: unless we changed the underlying model, the core confusion around how to create a key result for an objective would remain. No amount of UI polish would fix a structural mismatch between the product and the user's mental model. That comparison is what built conviction across the team to invest in the deeper change.
An updated directory experience for goals, with a visual indication of the relationship between Objectives and Key results, and clear terminology in the UI
Redesigning the model and the experience
We created a new relationship in the system so that key results could be tracked directly against their parent objective, rather than existing as independent sub-goals. This fundamentally reshaped the user experience. With the new model in place, I was able to redesign how users create OKRs, how they view the relationship between an objective and its key results, and how they provide status updates, all of which now reflected the way customers naturally think about goal-setting.
I gave demos of the new direction to several enterprise customers, closing the loop on the feedback that had shaped the project. Their response validated the approach and gave the team confidence we were solving the right problem.
Before and after the updates to the relationship model
The resulting updates to the goal detail view for customers that use OKRs
Impact
This project is still in active development, but the results so far have been significant. The improved OKR experience has closed major enterprise deals with customers who previously wouldn't adopt because the framework didn't fit their needs. We've also seen a 2X increase in goals created per month, which signals that the new model isn't just unblocking adoption but making the experience genuinely easier to use.
I designed an admin experience that allows flexibility so that customers who do not use OKRs can still get value from Atlassian goals