EXT Episode 19 Raw Data

	A	B
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 19, deep dive hosted on April 26, 2024 with Ben Callahan and Elyse Holladay. There are 26 answers. The question this week was: ----- Hello The Question community & Front-End Design Conf attendees! Welcome to The Question. The Question is a weekly, collaborative learning experiment. Here’s how it works: - I ask you a design system related question - You have until 6pm tonight to answer - We have a deep dive conversation about the answers tomorrow over lunch - We all get smarter! That’s it! The cost to participate is simply to answer The Question. This week, we’re hosting The Question LIVE at Front-End Design Conference in St. Pete, Florida. We’ll make the question public for anyone to answer, but only those attending Front-End Design Conf can attend the deep dive. And, we’re setting a limit of 30 attendees for this deep dive, so you’ll want to be first in line come lunchtime tomorrow. Here’s the context for this week’s question: There are about 1,000 things a design system lead could be working on at any given moment. From investigating how various product teams are handling layout to naming tokens to planning the communication strategy for a pilot program. All of it is important. And yet, if everything is important, nothing is. With limited time and resources, we have to become masters of prioritization. There are many approaches to figuring out what to work on next, but are those approaches appropriate for design system programs? With this as context, here’s The Question for this week: Do you have a clearly defined method for prioritizing work on your design system? Explain your process for prioritization of your design system work.
2	Question 1: Do you have a clearly defined method for prioritizing work on your design system?	Question 2: Explain your process for prioritization of your design system work.
3	Yes	If more than 3 projects request the same thing then it’s almost certainly prioritised. Everything is based on project needs
4	No	Gut feeling :sweat_smile: "Need it? Do it" - small team, no design system team. As a developer: you are the responsible person for collecting requirements, implementation. As a designer: usually depends on future plans for refactoring or new product features
5	Yes	It's clearly defined, but still flexible. We are most structured when it comes to identifying and prioritizing consumer requests. The unseen work we fill in around that and put on the roadmap so people can still see it. We gather requests from surveys, word of mouth, and office hours. We rank them by: 1. How many teams would benefit? 2. How much would it impact their work (Positively/negatively)? 3. What resources do we have available to work on this? There's always other factors, but those are the main questions we answer when deciding on consumer requests.
6	Yes	Design system goals are to support those building the product. We prioritize support requests over internal road maps. In fact, we specifically don't have road maps since we want to ensure we can be reactive with our time. The smaller the request the higher it jumps to the list. Just get it done.
7	Yes	Identify common user and product needs that the design system can support. It's been difficult to set some things aside, but aligning the (small) team towards a singular focus helps. Along the way, learnings and process are refined and the next effort benefits. I would love to be working on tracking component health, cleaning up the design system website, writing docs, or refactoring Figma components. All of those things are great, but they're all a few layers away from the end user where we learn the most about what is and isn't working. They probably don't care if you're using variables in Figma, they just want a reliable dark mode. Yes, it's important to support the teams building the product, and we should continue to do so and make improvements along the way, but the way still ends with the end user.
8	Yes	I work on any time sensitive tasks first.
9	Yes	JIRA tickets and dedicated PMs on our 2 UI Systems squads.
10	Yes	We have an overall process exists driven by the rule of 3, meaning we give priority to asks/needs that are beneficial to at least 3 products/projects… but it is not as simple when you have to also work on evolutionary needs of the system itself, also work that we better do before others from an strategic perspec, etc…
11	No	Not enough design system priority
12	No	Determined largely by product owners
13	No	it depends on the feature/function that is on deck for development/delivery/production.
14	Yes	Prioritise critical bug fixes over almost everything. Most impactful work comes next and then everything else gets put into the backlog and forgotten about
15	No	In short, we don't have one. Prioritizing work on our design system is perhaps it's greatest pain point. We do not have a dedicated squad that works on our design system, and instead, it's contributed to on a volunteer basis with a few devs and designers who sort of spearhead the project and evangelize it to others. Design system tickets for adding or updating components are constantly forgotten about in a sea of to-dos. The silver lining to the ad hoc nature of contributions to our design system, and their volunteer-based motivation, is that folks' contributions are always met with a ton of recognition and thanks. The obvious incentive of getting some cross-team shout outs and that looking good on the internal resume of sorts is for sure a leading motivation for engineers to contribute.
16	Yes	Priority is based on Impact, reach, and complexity. Components and patterns that have the widest reach within the app are prioritized first. In the event of a tie, components with high complexity are the tie breaker. If that doesn't work, then we we go full Thunderdome. Two components enter, one component leaves.
17		Doesn't apply to me
18		Keeping tabs in OneNote
19	Yes	We work in product increments so we make sure that the tasks we have are connected to features and their priority among the teams. We check every week to make sure we are on track on the stories to work on and we also prioritize bugs and important stuff in between but in general we try to be in sync with the product increments of the teams.
20	No	There were too many buttons... so we added buttons
21	No	Our system is currently reactionary rather than proactive.
22	No	No clearly defined method for work prioritization. I find we (team) gauges priorities day-by-day by measuring current needs against future risk. Sometimes, finding ways to satisfy current/future into a singular initiative.
23	No	When an update for a component is requested, the design file is updated and a ticket is opened for development updates. Do the dev work locally QA on dev Ship to production Documentation is not part of our current workflow so this is something we are working on integrating
24	No	Our first level of prioritization comes from a cadenced planning with our product manager. She brings us needs from the organization, and we bring items either we determined internally we need or that we've seen teams specifically struggle with. During the work week, defects, feature requests, documentation changes and live support needs arise. We often prioritize those requests based on availability of a workaround, severity of the issue, and complexity in solving it now (Support is rarely delayed). I'd be lying if the "embarrassment factor" doesn't play into fixing something quickly at times. We also take into account the impact (key product or initiative) or if it furthers our goals of adoption by handling the request sooner vs later. We are trying to get better at not being quite so reactionary even if the requested change seems simple – design changes rarely are "simple" once everything is taking into consideration.
25		Doesn’t apply to me, I’m a student learning web development:)
26	No	Most used elements across projects get higher likelihood of refinement/improvement.
27	While I don't work on the design system directly, I collaborate with them ans UX designers on adjacent concerns.	Prioritization tends to center around company needs, even at the detriment of the design system such as adding to code debt or locking into specific tool economies.
28	Yes	We rely on different types of inputs to help inform when our DesignOps team will begin prioritizing work. This may be data driven to add a new component to the DS, stakeholder needs raised through leaders and conversation, or a spike in dev support requests we’ve explored the root cause of. All of this is gathered and discussed on a quarterly basis which the team writes features and stories together with WSJF voting together with our stakeholders.
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
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