A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 20, deep dive hosted on May 9, 2024 with Ben Callahan and Tarunya Varma. There are 68 answers. The question this week was: ----- Tarunya and I were chatting the other day about just how sprawling design system work can be. There are so many areas to focus, all needing to evolve at the same time. On often small teams, how do we stay focused on the things that really matter to the organization? One approach Tarunya has had success with is in writing OKRs for her design system team. “OKRs have two important parts: The objective you want to achieve and the key results, which are the way you measure achieving the objective.” ~ from Atlassian’s guide to OKRs She shared with me that, in her situation, “OKRs have been a powerful instrument to make ourselves valuable to the business.” But how should we approach defining these in a collaborative way with our teams? How do we take the larger goals of the organization and filter them down into meaningful objectives? Maybe more importantly, how does the use of OKRs change when the objectives we identify are design system related? With this as context, here is The Question for this week: Do you use OKRs to drive and measure objectives for your design system? If yes, how are they helping or hurting your design system progress? If no, what other approach do you take to prioritize and measure specific design system objectives? | |||||||||||||||||||||||||
2 | Question 1: Do you use OKRs to drive and measure objectives for your design system? | Question 2: If yes, how are they helping or hurting your design system progress? If no, what other approach do you take to prioritize and measure specific design system objectives? | ||||||||||||||||||||||||
3 | No | We don’t and we’re struggling with understanding how best to measure (and then be able to demonstrate) value from the design system. | ||||||||||||||||||||||||
4 | No | Sadly this is the first I have heard of okrs. My team was just building the next thing that the developers needed for the apps they were creating. | ||||||||||||||||||||||||
5 | No | It does feel where the wind blows. Squeeky wheel gets the grease. | ||||||||||||||||||||||||
6 | Yes | 1/2 yes: the dev side of our DS team uses OKRs, but the design side doesn't yet. We're working on aligning. | ||||||||||||||||||||||||
7 | Yes | I haven't been on my current team long enough to answer this well. | ||||||||||||||||||||||||
8 | Yes | Yes, and I think OKRs have been hurtful and helpful. I imagine most product teams have changing objectives and goals within a year (like the ones I've been a part of), so OKRs have sometimes been hurtful where a design systems team may have objectives that are no longer prioritized or impactful for the product org that year. More generic, agnostic, and foundational objectives were proven helpful for a design systems team, primarily for projects that needed to be done regardless of the product team's changing priorities (token systems, infrastructural changes, Figma updates, etc.) I think a healthy approach for design system objectives is to identify objectives that are relevant and impactful to the org regardless of possible future priority changes, and leaving space for short-term future objectives so design systems teams can be as flexible and impactful as the product org needs them to be. | ||||||||||||||||||||||||
9 | still building this system up | n/a | ||||||||||||||||||||||||
10 | Yes | OKRs have been extremely helpful, since we intentionally created them to do just that. We have a KR around level of adoption on the Design Org level, and we managed to have Product and Engineering share it. That was a huge win, since we can at least point to it when talking to products about getting adoption on their roadmaps. For the DS team, we have 3 objectives - establish the DS as the gold standard for digital products, build a vibrantand inclusive community of practice that embraces and owns the DS, and develop a world class DS team. All 3 objectives align to the strategic themes we have for the year, and help keep the team focused on the most important tasks. | ||||||||||||||||||||||||
11 | I’ll join for learning but our design team does use OKRs | N/A | ||||||||||||||||||||||||
12 | I consult with teams on their design systems, but do not manage one of my own. | For teams I work with, everything we do with the design system needs to ladder up to org and company-level priorities. We haven't seen much success with teams investing in the design system for the design system's sake. On the contrary, when we can trace what we're doing to priorities that everyone in a group/team/org/company can say "this is really important," and articulate how we will accelerate or de-risk those priorities, it's so much easier to gain support from everywhere. | ||||||||||||||||||||||||
13 | No | We prioritize using the urgency and impact of each change as jointly decided by us and the product teams. The latter part being the same import but not the same structure as OKRs. It's served us fine, especially since the major driver of prioritization is product team urgency. -Arko | ||||||||||||||||||||||||
14 | Yes | Helping. It's really important to show concrete value of the DS and if you don't use OKRs you are not using the lingua franca of the rest of the company---you risk becoming unheard and irrelevant. Use OKRs that actually are *dependencies* of other teams' OKRs! This ensures that when a project is being evaluated that they see the role that your DS plays. e.g. "New Configurator UI" feature depends on "DS responsive autosuggest picker" and "DS icon toolkit". | ||||||||||||||||||||||||
15 | No | We're still early in establishing our design system. Right now, we're focused on foundations (color, typography, spacing). However, we will shift priorities to help support the feature team when asked upon. | ||||||||||||||||||||||||
16 | No | OKRs seem like a great idea. They can help align our efforts to the business goals. The challenge I see is applying them to regular DS support and maintenance efforts. How do you quantify that part of the work? | ||||||||||||||||||||||||
17 | Yes | This is the first year I'm introducing DS OKRs so I can't speak to their impact just yet but they have been a tremendous help in assisting me with prioritizing the work that we're doing across the design system. We have a lot of current state and future State initiatives going on, so I define the objective, the key result, the area of focus that relates to the design system that this needs to be executed through, the lead designer, and then tasks related to that line item. This helps me to provide a picture to my design team and broader organization of what we're working on and why and what's priority for us this year. I'm hoping to use these okrs at the end of the year to show the progress we've made and to help others get excited about our Design systems team and the work that we're doing both with developers and components and with the design team, more specifically in terms of support and figma libraries to help drive consistent and more efficient product design | ||||||||||||||||||||||||
18 | Yes | While our design system does have official OKRs around it (produced twice a year, H1 and H2), I'm honestly not sure how closely they are tracked. Contributors to the design system for sure do not have the OKRs top of mind when making decisions on how to prioritize work. Since we do not have a dedicated squad to our design system, the OKRs are a good effort to have general planning on what we want to accomplish, but they aren't held to any scrutiny / performance review by a specific higher-up that I'm aware of. | ||||||||||||||||||||||||
19 | No | For us, it was did the design system decrease the amount of time to implement a new screen? | ||||||||||||||||||||||||
20 | No | We aren't using OKRs yet to the best of my knowledge, but super interested in learning more about how they help! | ||||||||||||||||||||||||
21 | Sadly, improvements to our design system are not broken down this granularly - or have ways of measuring quantitative success. | There’s an unofficial tally of most used elements. The ones with the most usage are more likely to get improvements and refinements, but it blinds us to when we might be better suited building a new component over adding options to an existing one. | ||||||||||||||||||||||||
22 | No | Currently our design system is not measuring true OKRs but instead leverages the business OKRs to demonstrate how well we’re supporting the design teams. We are a fairly new system so hopefully this will evolve in the future. | ||||||||||||||||||||||||
23 | Yes | They help us have clear goals to work towards during a quarter, to help measure our "success". However they require us to know the goal/work before starting the quarter and so do not play well with the reactive nature of a design system. We tend to sacrifice OKRS mid-quarter to focus on the new requirements and needs of our consuming teams. This is fine for us as a team, and great for those teams with the new asks, but bad for any team affected by the reprioritisation and reflects poorly on our team when leadership see this. | ||||||||||||||||||||||||
24 | No | Taking inspiration from other designers and design systems to understand the key result that we want to achieve with respect to the problem that we are trying to solve for the users. | ||||||||||||||||||||||||
25 | No | We just wing it | ||||||||||||||||||||||||
26 | No | We prioritise design system components in a unplanned way | ||||||||||||||||||||||||
27 | Currently I’m not aware of the OKRs | |||||||||||||||||||||||||
28 | Trying to get our system off the ground so this is a great consideration but I think we are in alpha stage | n/a | ||||||||||||||||||||||||
29 | Yes | Company simply doesn't understand the value of Design System, trying to bridge the gap. | ||||||||||||||||||||||||
30 | Yes | They help by establishing and tracking missions that we deliver to success. | ||||||||||||||||||||||||
31 | No | We prioritize work based on upcoming features or initiatives. Supporting those helps us gain trust, adoption, and traction in building out a backlog of components. Customer-facing products get the priority at the moment, as that's what the business feels brings in the most value. Measuring can be complicated, especially from platform to platform. So we haven't been able to focus on that yet. | ||||||||||||||||||||||||
32 | No | We have objectives... we have results we hope to see from our work... We track analytics so we can back up what we do... But I wouldn't say we have OKR's. That's not how we think about it anyway. We mostly react to our consumer base: What do they need? What's blocking them? What capabilities do they want/need? We could easily flip those into OKR's to communicate our work to business, but our business partners already see the value in the system and see it as a stable force that sustains itself and scales the company. They mostly want to know if consumers are getting what they need out of it. They tend to be happy with that level of detail (story-telling and numbers without formal OKRs). | ||||||||||||||||||||||||
33 | No | We tried OKRs- the problem we ran into was the individual agreement and understanding on what an OKR is. We decided to focus only on the objective as a tool to align and test our proposed work against. This has proven a resilient approach to internal reorganization and shifting needs of our stakeholders and our systems. However, our metrics and communications of data-oriented success do suffer for this. I’d like to hear from those who were able to land in OKRs to have a stronger gauge on my team’s potential need to revisit the conversation. | ||||||||||||||||||||||||
34 | No | We make goals for the half as designers and work on achieving those goals. I approve those goals incorporate those goals into the roadmap, leaving about 50% of the time available for support work | ||||||||||||||||||||||||
35 | Yes | The biggest benefit I see is when multiple teams are involved. Objectives help set vision from a leadership perspective, and Key Results help teams brainstorm and communicate how they'll move everything in the right direction. They help leaders get expectations down on paper and teams to work out in the open. | ||||||||||||||||||||||||
36 | Yes | The intention is for them to help. | ||||||||||||||||||||||||
37 | Yes | They are helping. Where we run into trouble, the best way to frame an objective. Our PMs tend to clash with Agile on varying POVs. | ||||||||||||||||||||||||
38 | Yes | I think OKRs negatively impact my team's ability to adapt based on feedback from our consumers - we've missed several opportunities to make a big impact because we couldn't de-prioritize work we had committed to in our OKRs | ||||||||||||||||||||||||
39 | Yes | They are helping point out some major gaps we currently have in tracking our design system. There's many things we could have KRs around but it makes it difficult when you don't have something to measure against (ie lack of component tracking, lack of CSAT scores, etc). | ||||||||||||||||||||||||
40 | Yes | It helps aligning business outcomes and DS improvements | ||||||||||||||||||||||||
41 | No | Prioritising depends on complains around and new features in the product roadmap - customers` complains first to solve - if there is a task around problematic places, then those places can be changed in one go - if the product roadmap depends on new or updated DS parts, then it is planned - if a developer need some changes in a DS, then maybe it can be fixed at some moment In general no prioritising, no OKRs, the one who is louder and more annoing wins resources for changes | ||||||||||||||||||||||||
42 | Yes | Helping so far. We are establishing v1, so having metrics and milestones defined to work against for v1 completion / success have been good for the team and stakeholder visibility. Let’s see how it develops as the landscape gets more complicated. | ||||||||||||||||||||||||
43 | Yes | The #1 reason OKRs will help/hurt you as a goal-setting measure is simply whether or not your company is good at setting OKRs. Good OKRs are hard as hell to write, and bad ones can be so much worse than "regular" goal-setting. As the xkcd comic reminds us (https://www.explainxkcd.com/wiki/index.php/2899:_Goodhart%27s_Law), setting a metric that becomes a target is a problem. Adoption as an OKR ("Increase adoption by 20%") means that all the focus becomes on adoption, usually to the detriment of other things. Here are some OKRs and metrics I've set in the past: - Designers from at least 10 priority teams test out a beta version of the new library and give feedback on its viability and velocity, within 2 weeks of its delivery. - 80% of SWEs from at least 10 priority teams consulted are aligned on the chosen technical delivery approach for a design system solution. - Send and set a baseline on the Design System survey, so that NPS is measured at a regular cadence. - 100% of team members observe a customer team using the system (design and dev). - Reduce the number of teams using +1 major version back by 10% helping them migrate to the new library [10% here being ~2 teams] Currently, I have DS OKRs, but they're really todos, e.g. "Ship theme improvements." A binary done is not really an OKR, but that's the work I have right now, so it goes on the list, because it can connect to business goals that way. (For example, "ship theme improvements" is actually a critical piece of work that rolls up to "ship this new project" which has some real OKRs around it.) Additionally, DS KRs MUST roll up to business OKRs, otherwise the whole thing is silly. | ||||||||||||||||||||||||
44 | Yes | We use OKRs at a rather high level and so often they don't impact the entire team. They're also aspirational with the expectation to hit 70% so sometimes that can feel like work isn't complete before moving on. I'm a bit neutral on their impact. | ||||||||||||||||||||||||
45 | Yes | Somewhat, we have a set of broad year-long OKRs which have projects as the measurable results. However we don't have project specific OKRs. We are a team without a PM, so you could say this is a gap we are facing as a result. | ||||||||||||||||||||||||
46 | Yes | Writing DS OKRs brought more visibility for us in the org. It pushed us to get very clear on our objectives, baselines and measure of impact. Within the DS team it has helped ground our efforts and made conversations with business a lot less vague. | ||||||||||||||||||||||||
47 | I mostly operate as developer, and I am not longer directly involved with implementing DS at the moment. | |||||||||||||||||||||||||
48 | Yes | I said yes, but I wouldn't say we follow them where I currently am. I feel like this has a lot to do with the fact that our system is already established, and we're trying to understand what we should measure to keep growing. Sometimes, when you set clear OKRs and your focus shifts within your team, if the objectives you've set are too specific, you immediately appear as though you're failing on your objectives, despite the fact that you're focusing on something else. Given how volatile systems can be at scale, this happens a lot. At my previous company, we used them, were held accountable to them, and really benefitted from having them. I feel this was because we were establishing a new system and wanted to ensure we held ourselves accountable for building something sustainable and scaleable with high adoption. Our OKRs were geared towards the number of components built, the percentage adoption increase per component, and the number of contributions. This worked well in our favour and gave us the impression that we were progressing and improving. We noticed early on that these were very different to measure compared to a standard product team, as a design system has different users, so it was a mindset shift and a clear departure from what the rest of the business was measuring. OKRs work well so long as you have someone guiding the process and ensuring others are working towards them. This can be very difficult when you don't have a programme/product manager on your team, which, as we know, can definitely be a luxury for a design system team. | ||||||||||||||||||||||||
49 | No | Our team is building a new multi-brand design system at this moment. I´m responsible for implementing a process to measure it. | ||||||||||||||||||||||||
50 | Yes | They've been helping us think more precisely about what initiatives should fall under those "buckets" when prioritising any upcoming work and keeping us aligned with the business goals and objectives, leading to delivering more meaningful and impactful work. | ||||||||||||||||||||||||
51 | Yes | I’ve found the OKR framework to be helpful in leading design systems. Typically our KRs are a mixture of outcomes and outputs and we have two types of OKRs. Ones that are self-directed and ones that directly support org or product OKR/initiatives. That gives us some flexibility to prioritize and also infer and apply KPIs to our work from the wider product initiatives. | ||||||||||||||||||||||||
52 | Yes | Building them now | ||||||||||||||||||||||||
53 | No | We haven’t defined the specific OKRs at the moment but this is something we are looking into and we want to do in the coming year. Our company defined OKRs For the product teams but in the design system team we haven’t yet define specific objectives but we do have a yearly roadmap where we define which features and capabilities we want to implement in the design system. | ||||||||||||||||||||||||
54 | No | We are currently in the state of aligning our design system with the templates that our Dev team uses. We are using Jira tickets for this alignment process. When it comes to which tickets need to be done first, that depends on the business. If one product is selling more than the others, we focus on that design systems alignment first, because Dev will be using it more and more. When it comes to objectives, the objective is to sure up the most used template. When it comes to key results, that relies upon how many of that product we sell. The positive note, is when the product is being sold the most, that design system is always worked on. The downside is, the other products that don’t, get pushed to the wayside until they start becoming popular, then the cycle continues . | ||||||||||||||||||||||||
55 | No | we need them, but not sure how to determine them | ||||||||||||||||||||||||
56 | Yes | We recently switched to this approach, it is helping the team to be more focused and giving priority to work that is aligned to our outcomes. | ||||||||||||||||||||||||
57 | No | To prioritize objectives, we base our approach on the product roadmap and needs, with measures taken from the product's success. | ||||||||||||||||||||||||
58 | No | I want to use them (and we do actually have some established) but it’s been difficult to figure out realistic objectives that our small design team (and even smaller design system team) can actually get buy-in from other areas of the organization. We have objectives that we can achieve on the design side, but struggle to get beyond us. | ||||||||||||||||||||||||
59 | No | Direct feedback but that'd be far less "structured" than something like OKR. | ||||||||||||||||||||||||
60 | No | Unfortunately, my company doesn’t prioritize design system work. | ||||||||||||||||||||||||
61 | Yes | My concern is that we tend to be reliant on adoption, but it doesn't add up to $ | ||||||||||||||||||||||||
62 | No | Currently, we discuss client needs and make adjustments to align with their expectations. We are now experimenting with a plugin that will tell us how often each component is used across all of our clients' websites. We have not set OKRs for the base set of components, but I would like to learn how this process is beneficial for our product team and how we can implement OKRs moving forward. | ||||||||||||||||||||||||
63 | Yes | Yes, I have used Okrs to drive the design system progress. As someone who has helped set company wide okrs, it’s important to break those down for the Product Team so that each individual contributed understands how they are contributing to the business. This way makes it easier to justify time spent on the design system which gives me buyin from leadership and support from engineering. I also find that the okrs help the team focus on aspects of the design system that will help the other teams reach their goals as well. | ||||||||||||||||||||||||
64 | No | We are currently tracking priorities through sprint planning and our backlog. We also just released a major update to our design system so right now we are busy prioritizing any issues found with that release. This approach isn't really scalable and we know that. We are working to better define what our process will be and how we can identify and track our objectives going forward. | ||||||||||||||||||||||||
65 | No | Because our design system is still small and we do not have a dedicated team, we have a weekly sync with our key players to discuss system requests, visible needs, and general "where do we want/need to take it next" type of talks. From here we plan our roadmap and then it is up to me to ensure the goals align with the larger project objectives. It's not a very formal process because our system isn't a formal project yet, although we're working on that. | ||||||||||||||||||||||||
66 | No | Fortunately our leadership is pretty invested in design so we can use anecdotal evidence to highlight how we've advanced. | ||||||||||||||||||||||||
67 | Yes | I find that they OKRs are rarely referenced after they have been written. When they don't change behavior, they are mostly useless. | ||||||||||||||||||||||||
68 | Yes | There are so many competing interests when it comes to running a design system team, OKR's are a powerful way to create focus and formalize a goal. I've seen all members of a design system team benefit from the clarity of mission that an OKR provides. But on the other hand, the adage "you optimize what you measure" is also very true. Sometimes the journey is as important as the destination. Take for example adoption. Adoption driven by value and education is good. Adoption driven by managers forcing product teams to use a tool they dislike and hinder performance is bad. | ||||||||||||||||||||||||
69 | No | We are in the midst of building a new design system leveraging strong ORKs. | ||||||||||||||||||||||||
70 | Yes | In past projects, we've structured our OKRs around three pillars: consistency, efficiency, and innovation. We set clear objectives to drive and measure key results for each pillar. This approach not only improves the design system, but also helps track our team's progress. It provides a clear roadmap for our direction and how we can measure our goals, even though many of those goals may have qualitative aspects. | ||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 |