EXT Episode 18 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 18, deep dive hosted on April 19, 2024 with Ben Callahan and Robin Di Capua. There are _ answers. The question this week was: ----- Over the last 10 months, Robin and I have spoken several times about a common challenge faced by design system teams. Here’s the scenario: you’ve worked hard to build a system that solves many problems for your subscribers. You also recognize that your design system will never solve all problems for all products, so you’ve enabled product teams to build solutions themselves when they have a need specific to their domain. Over time, you see that product teams are taking a lot of liberty with this flexibility—the solutions they are building are not in line with the guidelines and principles you’ve established at the system level. Of course, there are many ways to solve the same problem, but it’s so easy to negate the benefits of a system if product teams don’t align philosophically. With this as context, here is The Question for this week: Does your approach to design systems allow for subscriber teams to deviate from the system's components and guidelines? How have you successfully navigated (or how do you plan to navigate) these kinds of scenarios?
2	Question 1: Does your approach to design systems allow for subscriber teams to deviate from the system's components and guidelines?	Question 2: How have you successfully navigated (or how do you plan to navigate) these kinds of scenarios?
3	Yes	To modulate the answer, it's "Yes, but not officially!" We always have the systems building/thinking hat on, and will state our view about what should/shouldn't be done both with our React components, and general design foundational principles. This will often be "we don't support using X like that", or "In this context, we think it would be best for you to do Y instead." But we have to be realists in understanding that we are not the ultimate arbiters of what should be built - That is the responsibility of the Design Leads, Engineering Managers and Product people within our Tribes and Squads. We don't have the authority to tell anyone what not to do; we can only please our case to the design leadership - but this is best done sparingly. There is a general lack of an overall design-unifying force or process in the Business. We really need a general editor or upholder of UI, UX and Brand best practices from Design, who does have that authority from the Directorship. But that's not formally in place at the moment. We do have enough clout and buy in with the leadership that if we ever had cause to flag up really egregious deviations from the system - (making their own buttons, etc) that we could confidently throw our weight around get adoption of those aspects enforced. But our overall Design Direct does seem to vacillate between valuing system adoption, and not wanting to 'limit creativity'. Our argument is the creativity should be exerted in the direction of the things that really matter, and if they want changes to the UI, they should lobby for those in the system but otherwise use what's there unless even _we_ would agree that doing something custom is better.
4	Yes	The teams have to agree the deviation with design systems team and the solution is reviewed by a design system designer. In many cases it might even mean that we will adapt the component, as it's a sign that a component has been built with too strict constraints.
5	No	Currently, our design system is in its infancy when it comes to governance and how to handle deviation. Our current preference is for folks to deviate only a small amount of the time. However, people tend to deviate because they don’t believe following the system, outside of the foundations, allows them to be creative. As a result, we haven’t successfully navigated this and are looking for help in doing so.
6	Yes	Our design system relies heavily on a contribution model to scale and meet the needs of our customers. We assess contributions based on generality and ability to be reused by more than a couple teams. We ensure an atomic approach and allow the teams to extend logic into the components as they need.
7	Yes	In the past, we've tried many things, that are very process oriented. The best way to ensure that things are too wild is to require a design team member to work on the exception with the product team.
8	Yes	Patience and transparency. We don't want to block work, but we also want to create awareness that can lead to connecting it more strongly with the design system. We're a small team, so we know we can't handle all of the requests to help teams adopt the design system — ultimately, they are responsible for the outcome. At the moment we're aiming to create more definition between what Dan Mall calls "the canon, and the 'extended universe'." By defining the edges we hope to have better ways to support different types of work, while understanding what those types of work are and what the design system means for them. There's also a bit of improve's "yes, and" rather than "no, but" to foster collaboration and keep things on a positive trajectory — healthy friction. Something that has helped me in the last several months is the concept of pace layers. Using a bike wheel analogy, the design system lives near the center hub where rotation feels slower than it does at the tire, yet both are in sync and complete a revolution in the same amount of time. I've had to realize that some teams are closer to the design system and change happens slower, and others are farther and moving faster. The design system has to support both, but in different ways. We aim to bring stability to both (and everything in between). As Stewart Brand once said, “The fast parts learn, the slow parts remember.” It's beneficial for the design system to have different teams experimenting and trying new things that may be wildly different that what they would be had they originated from the design system. If it's successful and beneficial to users, then we have a great opportunity to consider what other layers might benefit. If it makes its way into the "canon" then it becomes something stable that all other layers can benefit from. Sometimes I think we can over index on a team using the system, instead of learning why a team did something different and how it may be more beneficial to users.
9	No	We are early into our design system, so we have some tolerance for deviation. It's an iterative process. But for the most part, we intend to show the value of using the system, so that it's an apparent winning scenario to use it.
10	still in the process of designing the system	Hope to allow at least some customization to the components, but guidelines should be adhered to unless absolutely necessary to deviate
11	Yes	We are currently planning for a request, approval and contribution process for system deviations. This would include set timelines for delivery feedback/approval, and transparency on progress of assessments. Some requests/contributions may be escalated to a stakeholder panel for greater approval if required.
12	Yes	We haven’t and don’t necessarily have a plan to. There is a dream of achieving full adoption and then that the designers and engineers will build in a similar way. The odds are low without a plan so I’m eager to hear how others are handling this.
13	Yes	a big agency was hired by our leaders to design this process; TBH we're still trying to get it to work
14	Currently not on a team	I plan to have a really strong relationship with the other designers and developers on my team. We would have checks and balances in place, with a team mindset of trying to use the existing design system component first. If you want/need to stray from the DS components a case would need to be made to the team or DS gatekeepers. For teams that have regular design reviews, and treat them like developers treat code reviews, I imagine over time being repeatedly told "please replace this with XYZ from the DS" would get old and adoption would increase.
15	Yes	Deviating is always an option. It just depends on how difficult updates will be for developers. One way that we support deviating from standard components is de-coupling foundations out into their own "package." That way some subscribers that have a lot of customization can at least get the latest foundations package without as much headache to their components. It's not perfect... Still a lot of "1px problems" are posed for our consumers when they update.
16	Yes	This is an interesting question because I have found that many of my designs are actually "Design System Adjacent." They have components that are within the system, but often, require the construction of a new component that is not in the system. The way I have always navigated this, as a subscriber, is to surface my design to the people who are gatekeeping the system and get buy-in. For variations of the design system, there should be sign-off from someone who has some level of responsibility with the design system.
17	Typically we build design systems for clients and them hand them off to them. There is no cross system building at that point. The system is owned entirely by them. We have no control over anything anymore. Of course, we prep and document, but adhering to those ideals are their prerogative.	N/A
18	Yes	To me this is an opportunity that clearly defined governance can help increase consensus that this great power (build the thing you need) comes with great responsibility (do it in alignment with the system standards and philosophy). When deviations are permitted they should be understood as permission to innovate/experiment not an excuse to blatantly disregard the system. The product responsibility is to do so in a coordinated manner. Transparency, collaboration and trust are of critical importance, specially for the deviations proven successful that can then be added to the system. And back to the question, NO, our design system team has not completely solved this scenario.
19	Yes	It is more important to me that we uphold design system Values than it is to have total consistency and control. My approach has been to: 1) Create a design review checklist that all designers have to Pass, or I flag them with Pass With Fixes or Fail 2) Working with QA teams to also create their checklist to be on the lookout for things like a) contrast issues b) font too small issues c) wrong icon issues d) broken tab navigation issues My goal is to continually nudge people into seeing the Design System as the best way to do things. If people decide to go rogue, they accept the consequences of this: a) I can't guarantee support b) you risk breaking other components c) you may expose yourself to public liabilities.
20	Yes	Officially, any deviation from the DS should be done with good reason. Realistically, to quote Depeche Mode, "people are people", and we don't want to police them. If we do our job right, and our users see a need to deviate for good reason, we would like to have that fed back to the DS so we can keep improving our components. We're also creating training material for designers on designing components according to the DS philosophy and approach, hopefully that can help them understand how we approach that.
21		Doesn't apply to me
22	Yes	We recently created a Council where designers can come in and propose new ideas for components (new or existing) and patterns. We discussed having a core library for the DS as well as local libraries (kind of like IBM hub & spoke model) for snowflakes or product specific components that have no place in the core DS. We are discussing what kind of governance process to adopt and who has the final design decision regarding the design of such components for both the core and the local libraries. We have not successfully navigated this issue, at the moment product teams come with many new wishes into the council meeting and they clash with the feedbacks of the design team. It is not clear who should have the last word when an agreement can be reached in the council.
23	No	Haven't figured that out yet.
24	Yes	When building a design system, component architecture is very important! In order to reduce detached components, thereby avoiding possible inconsistencies, I'm designing all my components in an atomic way. Each atom and foundation (Design Tokens) is connected to the design system. To mitigate the risk of inconsistency that could harm the user experience for users using different solutions within the same family, a usability pattern library is needed!
25	Yes	Some deviation from a central design system is to be expected, and in many ways it's necessary. While a central design system can establish and maintain the standards, there's no cost-sensible way to optimize for every scenario. By doing a lot of the repeatable heavy-lifting through a design system, that frees up product teams to focus on more local problems. They can then use their direct access to users and their closeness to the subject matter to make measured and sensible deviations to the design. I'd say, if the strong foundations and guidance of a design system is being followed by a team as the baseline, then it's time for them to grow beyond what the current design system offers. Explore areas where further research and refinement can be done, to more precisely fit user needs for their particular product. And hey, if a product team discovers some places where their changes or research could benefit a whole bunch of teams, then make it easy for them to feed it back to the design system! By harnessing the talent, time, efforts, research, and closeness to users that a product team has, a central design system can get even better contributions. All that's great in theory, but rarely works perfectly in practice. Guidelines and guardrails will still be valuable tools for a design system, because no organization has 100% perfectly resourced and supported product teams. So perhaps identify a couple champion product teams that really get it. Reward their commitment to the design system guidance and their reliance on evidence! Encourage them to grow beyond the baseline offered in the design system.
26	No	Our design system does not allow for deviation mainly because it is informing a content management system that does not have flexibility in itself. Outside of that, when a project intake comes in, the product owners, managers, UX, and development teams come together and figure out if (1) the work can follow a design system element already created and if not we ask if a design system ticket is required. Very rarely will we decide to move forward with a deviation or snowflake design. Some questions we ask are (1) does design adhere to existing components? (2) can you change your design to match an existing component? (3) is your design similar to an existing component? If the answer to question (3) is no then we challenge with the following prompt: Annotate all possible use cases and reduce it to it's base form. Challenge yourself to reduce complexity as much as possible, and reduce mods from the base as much as possible. Try to think holistically for any untouched parts of the site to create a pattern that reduces the amount of components needed in the future. Are you confident you have created the most simple but robust version of this component?
27	Yes	Clear guidelines on deviation: Establish clear criteria for when deviations are acceptable. These could include: Severity of the need: Is it a critical product-specific issue not addressed by the system? Maintainability: Can the custom solution be maintained efficiently without creating long-term issues? Communication and collaboration: Encourage open communication between the design system team and product teams. Discuss needs proactively and explore potential system enhancements before deviations are implemented. Track deviations: Monitor how often and why deviations occur. This data can inform future system improvements to address common pain points. Refine the system: Use insights from deviations to identify areas where the design system can be expanded to offer more flexibility within its core principles.
28		N/A
29	Yes	If you have a design system, you will have this challenge because teams will always try to explore new directions and you don't want the DS to prevent exploration or innovation. The DS team should keep track of these branches and meet with the team at a strategic point in the timeline. There is a balance here, where you don't want to clamp down and stop them too early where you hamper the exploration, but you also don't want them to live on a separate branch for too long, where its a ton of work to get them re-aligned later. The DS needs to continually evolve, so the DS team can take the learnings from these explorations and improve the system standards. Other parts of the exploration may be product-specific only, and wont be brought into the core system. Having a good relationship with product teams doing explorations like this will make this coordination work well over time.
30	Yes	Step 1 - Discourage deviation. Step 2 - Understand the case, strongly discourage deviation. Step 3 - If still needed, come up with a plan to allow the deviation in the interim and incorporate it within the DS as a variant or new theme/style/version ASAP. -Arko
31	Yes	It's yes, cause it's possible technically, but not allowed. Some components have "styles" property. Theoretically, the subscriber can add any css on top of the component, but the agreement is that it should be used only for specific parent container styles related to the component (e.g. add margins around the component) and not for styles of the component itself (e.g. background or colors).
32	Yes	The system I am currently working on solves this problem by having weekly reviews and checkins with the design system team. This prevents complete deviation and allows for feedback if components that exist might actually work better than the deviation.
33	Yes	In prior design systems built we made overwriting the DS be a very explicit pattern (e.g. a consistent prop) so when done, it was something the developer had to be intentional about. This approach also made it very easy to find when people did it so we could track how often people were doing it which provided a learning mechanism for us to see what features we should consider adding. We also had this prop documented with disclaimers around the risks associated with using it to help discourge developers from using it constantly.
34	No	No, but yes, but also kind of?! As we all know, if we don't provide enough flexibility in our systems, teams will deviate from the system regardless. This is harder in practice, though, as systems are designed to be at least somewhat rigid. One of the ways we're looking at tackling this is by embracing custom components and making sure our system infrastructure supports it; at the same time, we're also trying to set ourselves up to have visibility of these customisations so that we can make changes to our system when they're needed. As part of our new collaboration processes, we've also made proposing changes to the system as simple as possible so that these little tweaks are also integrated back into the system. By leveraging what teams are already doing, we're also streamlining these processes so that we don't need to own every single change, just oversee and guide them. This is very much a work in progress, but has proven to be somewhat successful so far.
35	No	We plan to make our components more flexible so that they can be used as recipes for approaches that are slightly different from the standard. But we’re very wary of how much you can stray from the standard. We need some sort of baseline for every component and set boundaries.
36	No	When I've encountered front-end devs deviating from component library markup/behaviours/etc, I've done 1 or more of the following: 1. Asked questions. - Why were components modified? - Lack of understanding how components should behave? - Lack of understanding of process? - Didn't meet specific needs? 2. Reviewed Design System instructions & processes. - Do docs need improving? - Do components need additional functionality/configuration? 3. Demo'd Design System components versus modified examples. - Highlighted accessibility issues, or any other regressions (e.g. responsive behaviour).
37	No	I work in client services so we typically hand off a base design system to the client before our work is done. We've found some clients coming back to us asking to modify or expand for a particular department or team. I think the best solution is to have a central team that looks at the system, looks at the specific needs that are requested and then helps make the decision collectively to create a subsystem. It's more maintainable if they use as much as they can from the base system to inform the subsystem so that's what we always typically recommend. Basically, the base system is the parent of the specific departments/teams subsystem. Now the question is when you have several teams that have subsystems, how do you maintain or communicate? Do you really need 10 different versions of a unique approach to a card? And what if one team wants to use a "product card" that another team has in their subsystem but wants minor modifications? How do all the systems feed into each other? Or do they even need to?
38	Yes	Since we still have a small system with few external team users, we situate our design system as a foundation; stating that it is here to help w the core elements that make the site seem related, but it is not supposed to be used to create clones. We value the creativity and needs these teams have and don’t want to stifle them, but also want to emphasize the usefulness of having a consistent brand and elements across landscapes. If a team has deviations we simply have the conversation - is there something in the system that can be used or extended instead; what value is the change adding to the site? Sometimes they were just uninformed or unaware and there is a better solution in the system, other times the change is needed and then we go down path 2 - is this innovative or reusable enough that it should be added to the system for others, or is it a one-off? In the end it’s just a lot of communication. We are the experts so we should be there informing the decisions, but if a team really needs something the system should never be a blocker.
39	Yes	In my previous position our team was small, so good communication and the whole team's buy-in on the DS allowed us to move fast and break things. Then we'd circle back around to fix any deviations as we got time. Now that I'm at GitLab as of a few months ago I am learning that the team size and product complexity increase make the former approach a non-starter. I'm really looking forward to Jeremy Elder's response on how we handle our collaborative efforts around GitLab's DS.
40		Even thought my organisation isn’t large enough, the system itself cannot be too rigid. I work at a startup and the product is constantly evolving. Sometimes the system evolves with it. Other times, the system has to allow for new approaches to enable improved ux and customer success. The rigidity is mostly around colours and their use, and basic components. The flexibility is in the patterns (combination of components) and there is full flexibility at a page level (for now). I imagine this will become less flexible as the direction becomes clearer.
41		I haven't successfully done this yet. I was working on a design system revamp at my last job (with more strict rules & guidelines) before getting laid off, so I was never able to complete the project. Looking forward to see how others are doing this.
42	Yes	The team is redeveloping the design system to be componentized which was not an option when it was first created. We're also looking at other ways to standardize
43	Yes	As the contributor of content guidance to our DS, I build in a few places where writers can deviate from the guidance. They all relate to marketing content.
44	Yes	No, it's almost always a mess. You try to give guidelines, but teams want components, not guidelines. The one partial success is when a member of our team split off and created a component library for a specific business unit. They follow the guidelines, but maintain their own component library. Every other promise of harmony across teams has not worked out.
45	Yes	We’re still in the weeds of this. Our goal is to have “official” local libraries that build their patterns or unique-needs components with our system as the base. And then we would have a community with those local system leads to share and keep things as aligned as possible. We can dream, right?! We already have some folks changing our components in their features but not elevating the needs to our system. Which means it remains bespoke in their own private area. So, we’re outlining that it’s not enough to just release a component. We need to add in a lot of change management and training to change how our designers work. We need folks to shift to a community mindset when considering deviations.
46	Yes	I think we're in the middle of this challenge right now. In our next major version, we're opening up styling flexibility. Hopefully this will encourage more teams to stick with our components vs building their own just to achieve a slightly different look. This added flexibility is definitely a double edged sword.
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