Powerful Design OKRs: How to Really Build Shared, Creative Results

Design OKRs can set free your team’s deepest strengths.

 

Are you a designer or design team lead?  

Are you interested in focusing your team, but you're nervous you’ll constrain your team’s creativity (or your own, for that matter)? 

We’re about to tell you how design OKRs can guarantee results, encourage creative autonomy, and drive cross-functional collaboration for your design team, all at the same time. 

Too good to be true? That’s the power of OKRs. 

In this interview with Gtmhub’s Director of UX, Antoaneta Tsaneva, you’ll get real-world design OKR examples for your design team and learn how to set OKRs for alignment, transparency, and focus. 

 

The interview 

 

What are the most useful, real-world design OKR examples you can share with us? 

Last quarter, our goal was to ensure that our design system was on track. The design system OKR looked like this: 

Objective: Everything is magnetic 
Key Result 1: 70% of the UI components are part of the design system and are properly documented  
Key Result 2: 100% of the UI components are conformant with WCAG standards (level AA or AAA) 
Key Result 3: Zero screens created from scratch 
 

Right now, we have some inconsistency issues and we want to solve that. This quarter, we focused on aligning our design system by creating a shared OKR between our team and the engineering team.  

This is a design OKR for us right now: 

Objective: Be consistent and effective 
Objective v2: Cutting-edge is our comfort zone 
Key Result 1: Zero hardcoded color values in the product 
Key Result 2: 100% of the fonts used in the product UI are according to the guidelines in the design system  
Key Result 3: 100% of the tables are redesigned and implemented, according to the new design guidelines 
 

For the design team, this is a very important one. As for me, we succeeded in that we made this design OKR together with the engineering team.  

If we didn’t have these KRs, we would never know what we wanted to do or how we would achieve it, how many pages need love, how to give this to the developers, and so on. We’d do designs and nothing more than that.  

 

What has your role been in creating design OKRs for yourself or your design team? 

My role as the manager of the team is to drive design OKRs for our team. Of course, as part of the product organization, I also make sure we’re aligned with what they are doing. 

I organize the team to brainstorm together. I make sure we’re all aligned, and I make sure every teammate has their chance to contribute. We are all responsible as a team.  

My goal is to make sure we know and care about our objectives, and are transparent about how we achieve key results. 

 

What feels most important to consider when building design OKRs?  

The most important thing for me, as someone who leads the team, is that during the process of building and creating design OKRs for our team, we can’t create a good objective without understanding all the context around us and what everyone else is doing.  

When we sit and start brainstorming, we have to understand our role as a design team. We are not just making things pretty and making pictures and nice illustrations. As a UX team, our job is very closely related to what engineers and product are doing. In the end, we design the experience for our customers. We need to really have all this context and see the whole picture.  

Before working at Gtmhub, I had this experience where the design team had all their objectives, but the objectives had nothing in common with rest of the team. You have to ask, what's the data? What do we know about the users, the goals of the product, the vision of the product? How can we bring value, integrate our goals, and align our work with the rest of the team and company?  

 

Can you describe the team’s process for setting a design OKR, whether individually or together?  

It’s a simple process. With a team, we have meetings to discuss important things for the company. We go through leadership OKRs for the year or quarter, and explain or answer questions.  

We brainstorm a little bit on what’s important for us, how we can contribute. We open a Whiteboard on Gtmhub’s OKR software, we start adding notes there, going wild with all types of suggestions.  

And then, of course, we sculpt this down to 2 or 3 of the most important goals we want to pursue, and decide who will own jobs. 

The more difficult part is creating the best key results, and making sure that we will have all the information that's needed to track them and measure the process later. It's not just like, “we'll do 100% of this design,” or something like that. We use data and additional information to make sure that we're measuring what matters. 

“It's not just like, “we'll do 100% of this design,” or something like that. We use data and additional information to make sure that we're measuring what matters.” 

So, once we're happy with the objectives, we work a little more on the KRs. We come up with different iterations to make sure we're measuring our progress in the best way. For example, bugs and reports by customers were easy to track in Jira, so we knew we could track that automatically, which was helpful. For the design system, it was important to identify the different screens and performance we'd focus on so we could track them.  

Before that, I would never guess we'd have such specific design objectives, but here we are. 

 

What is main difference between individual and shared OKRs for your team? 

Last quarter was the first quarter we used shared OKRs. Before that, there was only one owner. I think it was much better than when we didn’t use them. Shared OKRs helped us as a UX design team, especially in the context of the design system. We were able to build a relationship and awareness with the engineering team because we shared the design system OKR with them.  

It gave us more time to design things, gave us more responsibility, and helped us understand the importance of design work as it impacts product as a whole. 

You might think because they are shared OKRS, no one is actually responsible, but I would like to say that it was quite the contrary. There is not one owner but multiple owners, so there are more people who feel responsible for the objective. We sync. We take turns one after another to update the key results, and we know we are all responsible together on that. That’s the main difference.  

Since this quarter is almost over, going forward, I will definitely want to use more shared OKRs. I am happy to have individual OKRs on my team, of course. There are things you will have to do on your own and be responsible for. But it’s very important to share between teams, and for more specific initiatives and joint cross-functional team efforts, based on my personal experience from the last quarter, I’m a huge fan of shared OKRs. 

 

How have design OKRs helped shape the team’s processes or outcomes? 

OKRs help us focus on and better prioritize our design work. 

Say I have a roadmap, let’s say by the end of next year. But still, where should I start, where’s the foundation?  

When you have a big team, there can be so many things we want to do. “I would like to redesign this and that and the other,” “I would like to add more color here,” “I would like to change this experience,” “I would like to redesign the navigation.” We don’t know where to start.  

When you’re making your design OKR and you’re asking, what’s the most important thing to focus on? Then, you can easily decide and prioritize and know that, okay, based on all the information we have, all the context, company goals, product vision, and so on, you can say these are the top three things to focus on. 

And really, when you have to commit to something like the objective in front of everyone—and everyone can see your OKRs in Gtmhub, that’s the beauty of it—you're very careful with what you commit to.  

That doesn’t mean you lower the expectations; it means that you’re really committed. This is how you say, yes, this is the most important thing for us this quarter, and that’s it.  

And then we don’t have to have the conversation about why you’re doing this instead of something else. We already had the conversation, and we know what your decisions are based on.  

Thinking through what’s important and what to do matters, because people will ask you, and you have to provide the answer and defend your decision.  

An OKR makes you ask, how do you approach things amongst everything for the next period of time? The process helps us stay responsible and understand that we are part of the same machine, we bring value, and our work can be aligned with everything the rest of the team is doing. 

 

What’s the biggest mistake you have made or seen in the OKR process? 

One thing is, and it’s applicable for everyone—starting late with the process of creating OKRs. 

When you start late with this process and you're pressed for time and you don't have time to think it through, ideate, get some data—it's never good to start late. It’s always good to start on time and make sure you're ready before the next period starts, when you’re under pressure.  

In the past, before Gtmhub, I saw situations such as lack of involvement or missing context. When you don’t understand the role of your team or yourself as an individual contributor, that's when you start inventing OKRs without knowing why and just for the sake of it. And this makes the whole thing less important than it is.  

Before Gtmhub, we used to make our OKRs using Excel spreadsheets. It was hard to see the full picture, who is doing what, and how to align your efforts. It was also difficult to navigate and see more than three things at once. I always wanted to have something like a tool or a place where I could see the full picture, how people align, what their OKRs are.  

The fact that I can go and read other teams’ OKRs makes me happy and helps me a lot. Being inspired by the rest of the organization’s curiosity helps me to better navigate ours. I’m interested to see what the engineering or the marketing teams are doing. Seeing their progress, but also how their OKRs are formulated, how the team created their objectives, is great and something I never had before. It gives me more confidence that the design OKRs we create as a team will make more sense.  

 

What advice would you give someone who is new to design OKRs? 

Look at the data. Make sure you have the full picture and understand the context. By knowing your audience and your business goals and measuring what really matters, you will make the process of creating design OKRs smooth and clear.  

Sit back and think about how to improve the user experience, and the metrics you track. With the data and the knowledge you have, what can you commit to in front of leadership which, after three months, shows you moved the needle as a design team? 

Once you have all the context of where the product is going, the vision, where your team should be, and really what you want to achieve— be it something new, improved or changed, some KPIs for example—the design OKR will come.