EXT: Episode 15 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 15, deep dive hosted on March 21, 2024 with Ben Callahan and Erin Potter. There are 38 answers. The question this week was: ----- Have you ever felt like decisions around your design system are taking way too long? Like you’re spinning your wheels but not going anywhere? Perhaps you’re working toward consensus rather than commitment. Erin and I were chatting the other day about a common challenge we’ve both experienced with design system teams—paralysis without consensus. We design system folks tend to think of ourselves as collaborative, but collaborating is not the same as getting along. We agreed, we need to be driving toward commitment more than consensus. This week, we’re diving into strategies to move people toward committing to a decision, even if they don’t feel it’s necessarily their preferred choice. Tell us your stories, explain your decision-making frameworks, share how you keep things moving forward even when there isn’t consensus. With all of this as context, here is this week’s question: In the context of your design system, how often does consensus-building get in the way of progress? Share why you answered the way you did and any strategies that have helped you stay both collaborative and productive.
2	Question 1: In the context of your design system, how often does consensus-building get in the way of progress?	Question 2: Share why you answered the way you did and any strategies that have helped you stay both collaborative and productive.
3	Usually	I'm extremely frustrated that our team doesn't have a universally acknowledged leader, or first line global decision maker. We have different disciplines in the team (design, product and engineering) and a common manager. The manager expects us to come to consensus decisions and flag disagreements which are significant/important to her - but this is not an efficient strategy as she is not in the context enough to make a call without significant time investment to lay out all the nuances, details, pros and cons. This means that when issues arise which are outside of my (product) acknowledged realm of influence (i.e. I think the design for a particular component is just poor/not at the level we should settle for, from a visual design perspective), I have to write an email to the manager setting out my concerns and why I think they are worth being concerned about, and just suggesting that she step in. If she does not, my course of action will be to disagree but commit, and just live with the poor design until such time as some of the anticipated defects are brought to light by stakeholders. This feels like the ideal of 'collaboration/consensus' actually undermining our ability to work to high quality as an autonomous team, and encourages an unhealthy strategy (banking 'I-told-you-so's).
4	Occasionally	When first deciding to productize our component system for clients, we started by compiling all of the components we had built in the past. From there, we streamlined the list into the most commonly used, which was a fairly simple exercise. We have occasionally run into scenarios with leadership that have stalled our progress - leading our teams to reassure and reeducate them re: why are we doing this? why not use the basic Gutenberg WP components vs our highly performant custom components, etc.
5	Occasionally	Particularly with Component APIs, we try to timebox feedback via a RFC (request for comments" period so we can get people's feedback but they can't give it indefinitely :)
6	Usually	This is something the team really struggled with in the beginning and got better as time went by. I think the main reason is lack of psychological safety. People don't feel like they are allowed to make mistakes, so they are reluctant to make decisions. That leads to endless rounds of decisions by committee, ensuring everyone agrees, and discovery spikes. What worked best to start changing it was essentially forcing them to release something. Giving them a deadline where something, anything, has to go out. When that happened and the world didn't end, they not only learned that it's possible, but also gave them a sense of pride.
7	Usually	Many people still think of design decisions as "preference" and therefore they can be made based on opinion. I work to counter this through two ways: Requiring justification of design decisions based on research/best practices Establishing a core set of design principles/values unique to our context that we return to and check against as we make decisions.
8	We're still building the team for this	We have a specific hire prepared to lead this team with the hope that they will manage our stakeholder expectations and with my help push to ship in a sprint release cycle
9	Usually	There aren't many people who have enough experience building design systems to have confidence in their leadership and decision-making abilities in this space. Our team initially spent a long time creating consensus, and it didn't result in a better product. Our organization structure also gets in the way at times, with design leadership and development leadership not collaborating effectively. The key to moving forward is continuing to create business value. That gives you the buy-in needed to gain commitment. Don't get focused on grand architectures, spend your time on achievable and easily understood patterns that make your products better.
10	Half of the time	I chose half the time although I don't have hard numbers to back that up. But it feels like half the time, especially as we embark on a hybrid model with a lot of new community design contributions. I think for my team consensus building has been a complicated one. The inception of our system started out as an authoritarian model, so much of the consensus necessary was internal with an exclusive audience. Then we introduced engineering (and along with that myself) and consensus building has gradually increased to include those insights and opinions. But now as we address our needs to scale to a larger organizations needs, consensus gathering is quite different. Our priorities are informed by deciding what we own as the core team and what we can help facilitate as community contributions. And to compound the level of nuance we need to be aware of, there are the cross-platform web and native apps conversations that also need to be had! Needless to say, being a collaborative and productive design system at this point is still just exiting the forming phase and entering the norming phase. It means a lot of Slack conversations and office hour meetings, but as we clarify our identity to the larger org our collaborators are getting a better sense of how they fit in. This is making tough conversations easier, but there is definitely not a single playbook we can follow when it comes to how closely we get involved with each new component that gets proposed.
11	Half of the time	Our design system supports multiple brands so alignment is not always easy. We continue to prioritize system updates that benefit the system as a whole versus any one particular brand.
12	Currently looking for my next design opportunity.	N/A
13	Half of the time	The DS team needs to be (and feel) empowered to make (the hard) decisions when necessary. They sit at an elevation beyond individual project needs and have to consider all parts of the whole. Personally, I use the HFWNW Exercise (https://www.youtube.com/watch?v=ihdvLizFzJY) to gather initial sentiment, then cascade that into a roadmap. Having core team and community critique and discussion sessions, respectively, allows for decisions to be vetted with the consumers in the community who need those resources while allowed the core team to inform those decisions by both individual community needs AND the bigger picture.
14	Occasionally	This is coming from the perspective of a development team who owns the code for the Design System: my team is very small - only two devs. We work closely with a designer but they are not embedded into our team (I wish they were). More often than not, when progress comes to a halt it's because there's misalignment between our understanding of what the purpose of the DS is and what the design team believes the purpose is. Usually we're being asked to make an addition to the DS that we believe isn't agnostic enough to live in a DS (purpose for the component is very specific). When this happens we try to pinpoint the particular problem that design thinks should be solved vs what problem us (the DS team) thinks should be solved, and that way we can identify what work can be split out and managed separately (ie maybe by a different, feature-driven team) and what we should be focusing on. Trying to find the common ground is more helpful than focusing on what we're disagreeing on.
15	Half of the time	Our company has so many teams and within those teams so many contributors with different opinions. Sometimes I worry we are creating a design system that no one will implement because one person on one team has concerns. We are also trying to create consistent functionally across products that were built at different times with different goals in mind. Many teams are unwilling (or not staffed enough) to make changes to their product that would allow for the goal of consistency to be met and we struggle to please everyone who feels they should be involved in these decisions. If the company is pushing for functional parity but the individual products are unwilling to make any changes in service of that goal it feels like our hands are tied.
16	Half of the time	Our company has acquired so many products and every product is used to the way they have set up elements within their products. This gets in the way of our progress as it is difficult to create components that meet most of our product needs (i.e., provide some flexibility, but also guidelines).
17	Occasionally	Getting teams to agree is like herding cats, we try hard, but it occasionally it ends up going in circles. The following techniques have helped. 1. Set a deadline, get the teams together, give them the proposal, and tell them that it's going to go live in x days. They fight tooth and nail, but near the end of the deadline they suddenly become more compromising. 2. Pre-expose, talk to the leads from the teams, pre-circulate an ideas before the official meeting. 3. When we are stuck between two adamant teams who want components to go two ways - we give up, make variants. 4. When talking about standards, there's that fine line between flexible permissiveness and strict enforcement - it's hard but one needs to find that line every time, and that can often mean a lot of discussion, as long as it's not going in circles, it needs to be had.
18	Half of the time	We usually try to have a look at research and best practices in order to build consensus without ending up in judging personal opinions. That said the interpretation of best practices and personal opinion often makes it so that reaching consensus gets tricky. I don't think I have good strategies for this so the call will be very helpful ;)
19	Occasionally	Keeping in mind we _must_ have a point of view, and a solid reference back to our mission/vision/polestar, design principles, and product values
20	Half of the time	Our organization is unfortunately in general a consensus building organization and for a design system team that can be a trap because we need to talk to EVERYONE. We need to know when something is a bigger decision and needs those conversations, or when we can just make the change and be empowered to make it. As a manager of my team I try and make that distinction and apologize for mistakes later if they really happen. So far this method works but it's also challenging. We use a 2 hour working session on Wednesdays to review work as a team and talk about problems we're trying to solve and then after conversation and debate I empower the owner of the task to make the decision or talk to more people to gather missing info. We also do the same in office hours. We don't want people walking away with more problems then solutions every single time.
21	All of the time	Consensus-building is essential as it ensures diverse perspectives are considered and fosters inclusivity within our design system. However, when it becomes our primary focus, its lead to prolonged discussions and delays, hindered our progress. On the other hand, minimal collaboration without considering different viewpoints resulted in perception of creating components in isolations. Finding the right balance is crucial.... We've started setting clear goals and priorities and even established a decision-making frameworks called the community of practice, which encourages open communication in a weekly.
22	Havnt had opportunity to yet	I don’t have much experience in design systems yet and haven’t encountered this particular situation yet
23	Occasionally	We have a framework for making decisions that includes a disagree, commit, disagree policy. "At GitLab, DRIs can make decisions that other team members disagree with. We say that collaboration is not consensus and people are not their work. A DRI may make a decision that results in (and is hence the cause of) negative feelings, but the DRI isn’t expected to make the popular decision and the person, the DRI, is not the decision that has been made. The DRI should consider input and make an informed decision, but the DRI is not responsible for how people feel. Once a DRI has made a decision, team members are asked to disagree, commit, and disagree." https://handbook.gitlab.com/handbook/leadership/making-decisions/
24	Half of the time	Our team has done a ton of work in a collaborative way - we've spun up coalitions and working groups galore. Times its worked: When we had one accountable person who took in the perspectives of the group and made a decision they could justify and aligned to the majority of the group. But, ultimately they were the defined call. We're doing this on a Brand Refresh currently and we did this in a DS Coalition to inform the requirements/designs for a unified enterprise system (the coalition being made of leads of the other systems and invested products). Times its not worked: Our tech team tried to do an RFC (Request for Comment) process that required near 100% alignment and a robust document that seemed to be iterated for months...on one component. It was an example of letting perfection get in the way of good. One squeaky wheel could hold the whole thing up. The coalition above got the DS folks on the ground aligned to unified designs, however the execs at the top couldn't commit and therefore didn't put in any framework to have folks converge to the new system. In fact, some folks built new code to our designs. So, while consensus occurred on the ground, missing commitment at the top failed us. Strategies: We now push for Leadership commitment to support our work. We define clear leads for work, the ultimate decider. We can prove we've gotten consensus, don't aim for 100%. Forget perfection. We've also gotten clearer OKRs from leadership that help enforce the need for timelines and decisions in the face of input swirl. But we still have some leadership commitment issues....
25	Occasionally	I get the overall impression that our design system skews toward less collaborative plus more authoritative and therefore more productive. The design system consumers are either tuned in and hanging on our every word, waiting to hear the official stance on how something ought to be done or they're tuned out. I did a recent analysis and found that only 19.86% of people in a Slack channel for a local branch of our design system are in the Slack announcements channel for global design system updates. We enable collaboration with Design Reviews, Design Office Hours and other formats where our consumers can preview and influence in-progress work but those are not always well attended. On the other hand, we are participating in our consumers' work through Design Reviews and governance checkpoints that often become a format for grading designer's work against the gold standard of our design system.
26	All of the time	Teams that are highly collaborative tend towards consensus because I think that it emotionally feels better. The system doesn't have emotions though and getting to a better system is about trying thing early and often. My opinion is that we want consensus because we know it won't change soon after implementation. So we want something that will last a long time and work well. Unfortunately, systems work better through trial and error. We should be trying things, testing them, and iterating on them to improve the experience.
27	Half of the time	Our team tends to move very fast, our company operates with a lean mindset: test, fail fast and iterate. However, the speed of the process depends on the reach of the project: when there's a component which touches every division, the requirements take much longer to gather then when it is only used in a single flow.
28	Occasionally	In the past, when our DS was very much new, consensus building on both design and development took much longer. There were times when certain design and technical decisions were made and implemented when not enough due diligence / consensus building was done. Later on, those actions came back to bite us as it resulted in either a refactoring effort or lack of trust / reputational damage and often both. (For the record, due diligence was not intentionally bypassed, it was just a result of lack of maturity on design system processes and awareness of exactly what needed to occur before a change was introduced into the system). So certainly we learned the hard way in some cases. Eventually as adoption grew and teams began to actually enjoy using the system because it worked for them i.e. no issues integrating components into their projects, their continued needs met, contributing was not seen as "too much" of a blocker etc., consensus building has become a more natural process and not a checklist of items- though often we still do "check ourselves" during refinement sessions to ask questions like- "what are the dependencies on this component / change, is this going to cause a breaking change" and so on. We also introduced sessions like office hours and more active polling in our dedicate slack channel to surface ideas for new component, variant, pattern long long before they become a reality and this means consensus can be reached more more easily than it was in the past.
29	Occasionally	The design system team has a roadmap and internal processes that bypass the collaboration stage. Where we see progress get held up is in requests from teams, both in new items and in changes to existing items. Finding the balance between product and systems thinking is usually the culprit
30	Half of the time	We had a ton more issues in the beginning of our design system journey than we do now - largely imo because roles were not clarified. There was no clear alignment on how we make decisions, and because of that consensus was required for things that it should not have been. The best way i have led our teams out of this problem is to clarify roles and expectations by putting together proposals, and showing those to stakeholders who i knew we would actually need consensus with. With a stake in the ground about what it is we are and arent doing and who is responsible for leading and making decisions (ex: we ARE trying to bring consistency and necessary accessible updates to UI, we are NOT trying to make arbitrary visual updates), we can make decisions even when we dont all agree. Aligning on outcomes is a tool i find useful in consensus as a whole. A past manager, Peter Lewis, wrote a great article about outcome based product definition: https://medium.com/@thispeterlewis/value-mapping-6203c997c463 This framework is a tool i use in my work all the time to get a group to align on what it is we want to enable, leaving the solutions up for debate and allowing us to align on which solution actually achieves those outcomes. Its actually easier to build consensus this way but it also helps to move fwd without it. If we can all agree that two solutions are likely to achieve our outcomes, then even when not aligned on which we should choose, the group feels comfortable moving forward and feeling like the problems will be solved.
31	Occasionally	We had 5-6 teams using DS, so finding consensus wasn't hard. Usually we discussed a task with a maximum of 2-3 teams.
32	Half of the time	It seems to be so hard to get people involved, get collaboration going on, be able to be in sync with product teams and their schedule, so little collaboration happens. That's why only "half of the time" consensus building get in the way. :D
33	All of the time	We’re a team and org that is used to built in silo’s (dev and design) and for that reason we’ve been trying to come together as a team. However the team has been stuck in their way of designing first and developing after and the communication for the process is the same way. Design always decides without development input and afterward we’re finding out development did their complete own thing and we’ll end up having to reverse some stuff or make decisions on the spot when everyone has a different opinion. Speaking to eachother at the start of the process helps but we’re still lacking a good starting point and theres too many opinions which causes indecision.
34	Half of the time	Delegating decision ownership. Referencing your design system principles as a guidance.
35	Occasionally	Our design and dev customers are building out a super app that is getting unprecedented exec scrutiny (they're being held accountable to make it super after all) and many of these execs are new to design. We're seeing some design patterns go through multiple rounds of redesign as our customers get changing feedback from their execs. I'm meeting today with a design partner and my manager to discuss how we could create a clearer feedback loop for execs and clarify their expectations for their feedback (is it just a question? a suggestion? a mandate even if it delays time to market?)
36	Never	Having a process defined up front for decision making and a clear hierarchical structure for who approver is tends to mitigate the need to get a consensus. Our focus tends to be more on gathering input and then incorporating that, but also realizing we can’t please everyone.
37	Never	Our system was based on material ui so our job was to match that ux.
38	All of the time	Our IT Department has a very different vision or set of priorities than the brand and design teams. This often makes it nearly impossible to get consensus on an an approach to both large and small thing because our overarching priorities aren't aligned. This blocker doesn't stop us (design team) from being productive - directly...we've just being moving ahead as best as we can with out it, but it does cause us to carry a LOT of anxiety with us daily - thinking about all the potential risks of building piece after piece on top of each other without being truly aligned on the most foundational things. Creates a little bit of a house of cards that has a negative impact on morale.
39	Occasionally	In our team a lot of time the product designers and engineers rely heavily on the design system team to ‘finish’ the component creation work. As we are a small team we don’t get an opportunity to react and close bits as often as we’d like so some conversations just end up open ended until a product needs to actually implement it. What also blocks us and slows us down is deliberating over UX decisions which a lot of times have been solved many times over. Thinking back to Brad Frost’s ideas on a global design system… I do believe if some patterns were taken as universal truths we’d actually save time. Going back to the question on consensus. What we do is try to careful who we need in the room to deliberate with us and how new/impactful this work will be, does it come from a live product context or not. More often if it’s backed by a product need it inevitably pushes us to move along so we’re able to match timelines.
40	Occasionally	We tend to run into this the most as scope creep. We try to keep things as minimal as possible at first and we continually re-visit the idea that there's a lot of iteration to happen in the future and our system will always grow and evolve. Our product team tends to prioritize and document well enough that we can continue building and revisit those features/iterations in the backlog at a later date.
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