| 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 072, deep dive hosted on April 9, 2026 with Ben Callahan and Doug Neiner. There are 49 answers. The question this week was: ----- Hello, system thinkers! What happens after the tokens are defined, the components are built, the documentation is written, and your adoption is solid? A design system that sits unused cannot be successful, but product teams that don’t feel supported can be just as detrimental. The most mature design system programs help consuming teams succeed with the assets they offer. Of course, that kind of deep design system support looks different depending on your organization. This week, we want to understand how design system teams are showing up for the people they serve. Welcome to Episode 072 of The Question! Note, everyone is welcome on The Question—if you aren’t actively working on a design system, feel free to answer with “N/A” or “Other” or respond with the context of your most recent design system work! How would you describe the support your design system program currently offers to consuming teams? (check all that apply) • We publish written documentation • We publish video documentation • We offer async support channels (Slack, GitHub Issues, etc.) • We offer office hours or open doors • We do hands-on sessions or pair programming • We have access to dev environments to help debug • We embed in consuming teams • Other or N/A (please explain) With no constraints, how would you change your design system support program? What are the constraints that keep you from implementing this level of support? (check all that apply) • Headcount/bandwidth • Unclear ownership (Is support our job?) • Lack of access to consuming codebases or design files • The scale of the organization makes it impractical • Competing priorities • Other or N/A (please explain) Describe a time when going above and beyond in supporting a consuming team had a meaningful impact on adoption, relationships, or the system itself. | |||||||||||||||||||||||||
2 | Question 1: How would you describe the support your design system program currently offers to consuming teams? (check all that apply) | Question 2: With no constraints, how would you change your design system support program? | Question 3: What are the constraints that keep you from implementing this level of support? (check all that apply) | Question 4: Describe a time when going above and beyond in supporting a consuming team had a meaningful impact on adoption, relationships, or the design system itself. | ||||||||||||||||||||||
3 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | More hands on and partially embedded support. | Competing priorities,Headcount or bandwidth,Lack of access to consuming codebases or design files,The scale of the organization makes it impractical | Every personal involvement helped. It expedited adoption. At the very least it increased the openness of the consuming team to consider working with us. | ||||||||||||||||||||||
4 | We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | I would introduce trainings for designers and developers during company onboarding phase. On top of that I would try to develop tools (plugins, skills, etc.) to meet the consumers where they are (Figma, IDE...) and offer them support in the form of linting tools documentation tools and easy access to information about the design system. | Competing priorities,Headcount or bandwidth,The scale of the organization makes it impractical,Unclear ownership (Is support our job?) | |||||||||||||||||||||||
5 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | Organize a way to let teams find each other better. Like teams using alternative testing frameworks or additional component libraries (eg data tables) that could be conflicting or need more configuration to be compatible with our design system. | Competing priorities,Headcount or bandwidth,Lack of access to consuming codebases or design files,The scale of the organization makes it impractical | For design we have more capacity to give more hands-on support, and we see that this works quite well for adoption and receiving more feedback instead of issues becoming a negative sentiment in a team. For development this is harder to organize due to different reasons. | ||||||||||||||||||||||
6 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | I'd extend out to partners and adopters to place a person along side the developers and designers in the product team | Headcount or bandwidth,The scale of the organization makes it impractical | We've stayed very close to our releases and keep our adopters up to date as much as possible, frequently solving their issues quickly. | ||||||||||||||||||||||
7 | We publish written documentation | I would have an additional design system lead team member that reviews our live app production files each week, then surfaces areas to correct for cohesion, sets up time to discuss additional use cases needed in the system. That person then closes the loop to either make sure the correction is implemented live or adds the new use case and documentation in the design system. | Headcount or bandwidth | Na | ||||||||||||||||||||||
8 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | Currently, we're making it as self-serve as possible by hooking it up to all of our documentation and resources. I'd keep doing this, but at a faster scale with more people pitching in. | Competing priorities,Headcount or bandwidth,Lack of access to consuming codebases or design files | Some team members have been heavily involved with showing a very anti-DS product team how to adopt a DS and how it can benefit them by working directly with designers and engineers on their team. This has helped that product team learn that a DS can really speed up their design and engineering workflow. They're currently advising on a new theme so they can fully adopt the DS when we roll out theme-ing features later this year. It's been a slow process, but we'll get there with having them adopt tokens AND components! | ||||||||||||||||||||||
9 | Maybe have them interact more with customers | Here to support Doug! | ||||||||||||||||||||||||
10 | We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | I’m the only dedicated design system person, and I’m doing my best, but I can’t cover everything and I don’t know everything. I wish that we had more dedicated resources, but right now we are kind of a federated model. | Headcount or bandwidth | I’m trying hard to address people’s concerns with our system, at least partially to establish that they can come to us with concerns and that we will in fact address them. I’ve been going around and getting feedback from designers and developers and am trying to prioritize this feedback into my workload. We are early enough in the design system that we are still building it and things are flexible. Which is a nice stage to be in. | ||||||||||||||||||||||
11 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | I think we could offer a lot more pair programming and be able to have a rotation model for our "support" role so that there was less context switching for the design system team | Competing priorities,Headcount or bandwidth,Lack of access to consuming codebases or design files | When we've been able to pair with a specific team and help troubleshoot their issues, it has typically meant that those people not only become adopters but also advocates for the design system. My favorite thing is when I see design system users answering questions in our support slack channels before the design system team has to | ||||||||||||||||||||||
12 | We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | Hands-on sessions or pair programming as an addition would be ideal but not realistic | Competing priorities,Headcount or bandwidth | It fueled curiosity and brought more attendance to the open hours | ||||||||||||||||||||||
13 | N/A | N/A | N/A | N/A | ||||||||||||||||||||||
14 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | Automate much of the Slack support channel with a bot or AI that asks refining questions about the ask and/or points users to existing documentation. | Competing priorities,Headcount or bandwidth | Embedding with a designer working on a core product update helped influence not just new components but also fostered goodwill toward adopting the design system (both design and engineering teams) | ||||||||||||||||||||||
15 | We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | Ideally we would run way more targeted support around specific topics we know people struggle with. Would also like to run training sessions on tooling like Figma. Would love to do pre recorded video classes to. Would save time long term but just don't have the time to do them. Right now obvs if we release a breaking change or are using a new feature something like that has it's own dedicated sessions outside of office hours. | Headcount or bandwidth | Currently we are in the process of onboarding a new franchise within our org So that's weekly sessions with them to discuss and prioritise any bugs. I'm also basically embedded into the team to head of any issues or answer questions they have. | ||||||||||||||||||||||
16 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | Embedding in consuming teams would be great. It's the one box I didn't check here, mainly because we haven't officially launched the system yet. However, embedding is something we're definitely going to try to do. | Headcount or bandwidth,The scale of the organization makes it impractical,"Other" is what I mentioned above: we haven't launched yet. Once we do, we'll see how everything goes and exactly how much (and what kind of) support we can provide. | During our Pilot phase, we each (each DS team member) spent about a month scheduling 1-on-1 sessions with individual product designers and developers. This is what seemed to move the needle the most. Not only did the participants appreciate the personalized attention, it increased utilization with those who were already experimenting with it and actually got many of those who were holding out to at least give it a try. | ||||||||||||||||||||||
17 | We offer office hours or open doors,We publish written documentation | Video documentation, more office hours with increased attendance, educational workshops and trainings | Competing priorities,Headcount or bandwidth | I'm new to my employer so haven't had many opportunities for supporting consuming teams | ||||||||||||||||||||||
18 | We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | I only get to see how it's being used after it's already in production. In an ideal world there would be more designers to help guide front end development before it's live. | Competing priorities,Headcount or bandwidth | N/A | ||||||||||||||||||||||
19 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation,A few other things we do/are doing: 1) We are working on some AI solutions to help our users get answers to their questions or help with using our system where they need it (what component to use, how to compose components correctly, proper token use, etc.). We are looking at AI as an extension of the support we already provide but are limited with capacity as we only have four engineers and two UX designers. 2) Our UX designers meet with enterprise designers (within each vertical portfolio) every week to learn about what they are designing and help with some consultation and also gather product insights/feedback. These meetings then act as a place to inform the DS team of needs of our consuming products (there are hundreds) and learn about pain points or creative solutions these implementation teams have. 3) Because we have a smaller team, we consistently encourage contribution from our community. User reports a bug...our usual response is "Yep, that looks like a bug, we may not get to it right away but if you're interested, we'd love your contribution!" User asks for a new feature..."That's a great idea! We don't have that on our roadmap currently but if you're interested in contributing..." Not only does this help us support our users by getting more solutions out the door but it also builds a collaborative community and buy-in at the user level. We take on the maintenance and support of all community collaborations but for the most part that is minimal compared to the work they are contributing to fix a bug or add a feature. | If I could have an embedded solution in Figma and Code that checked for proper usage and automatically reported bugs/issues/feature requests to the right people (UX, A11y or ENG) and into our backlog already prioritized correctly, that would be magical! We have so many products that use our design system, and not all of them have UX support so sometimes they guess at the right solution or component. It would be super helpful to have automatic governance at the place where users are using our system. There are times we have teams that come to us for support or help and we have to tell them, "Ope! You're not using that correctly." Depending on the scenario, that can be disruptive to them, their product and their users. If we could intercept those things at the moment of creation and set them on the right path from the start would lighten our support load. Included in this magical solution would also be reasoning and best practices for the recommended "correct" solution. Maybe someday with advancements in AI we'll get closer to this. | Headcount or bandwidth,Lack of access to consuming codebases or design files,The scale of the organization makes it impractical,I don't know that there is technology to support something at this scale currently. I think there are pieces of this that could be done but not as a whole solution. That points back to headcount, bandwidth and scale as well. | Recently we released a new major version of our DS. We provide code mods to help automate that migration for teams to make things go more quickly. However, there is one large enterprise product that even with the code mods would have to do more work than most - given the size of their product and some custom implementations. They dedicated two sprints for all of their UI engineers to upgrade their entire product. We offered one of our engineers to join their daily stand up meetings and also be their point of contact for all questions for those sprints. We allotted some capacity for her to support that team/product to fix any small bugs as they came up so they would get quick turn around on fixes. This product is also directly tied to enteprise objectives so it has high-visibility in the company. Success for this upgrade was important on a number of levels. This approach worked really well because it helped identify some edge-case bugs that we were able to quickly fix, it got their product upgraded fully in a shorter amount of time than if they had to wait for support to help, it contributed to building relationships between the DS and that consuming team, and it paved the way making things a bit easier for other consumers that upgrade later in the year. We can't always dedicate a person so every team but when we are strategic about it, the return is worth it. | ||||||||||||||||||||||
20 | I'm a one-person team -- design, design system, product, engineering (with help), content. I make and consume the design system. | Support for design system will come largely from agentic tools. For that reason, it's imperative that my design system is optimized to be read and parsed by those agentic tools. | Quality control of agentic tools. Time required to stay current on agentic tools | NA | ||||||||||||||||||||||
21 | We do hands-on sessions or pair programming,We embed in consuming teams,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation,We also host discipline-specific "jam" sessions to vet ideas and provide deep support | I'd have 2 more engineers and I would try to lead some internal culture changes that would help consumers really understand the tool that's in their hands. | Competing priorities,Headcount or bandwidth,Lack of access to consuming codebases or design files,The scale of the organization makes it impractical | |||||||||||||||||||||||
22 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | More people on the team to help with the growing responsibility. | Competing priorities,Headcount or bandwidth | As a consumer of the work that Doug and his team at Planview, it is hard for me to think of a time when he and the team are not going above and beyond to support our multiple teams. How our entire product vision has gone from an experience of multiple different product UIs to the company investing in a new experience... I just will say that as I can't say too much more at this time. But the design system and the adoption across the organization is making a huge impact on how our customers experience and perceive our product and business. | ||||||||||||||||||||||
23 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | I would like to offer regular "office hours" that allow folks to drop-in for support needs. I would also love to create a custom GPT that can help point users down the right path of thinking when they need to go beyond simple revisions. | Headcount or bandwidth | n/a | ||||||||||||||||||||||
24 | We do hands-on sessions or pair programming,We embed in consuming teams,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | More people to do it (was down to just me) | Competing priorities,Headcount or bandwidth | I think pairing/embedding is the only way adoption would happen in some cases, it wasn't getting prioritized otherwise. But, we got whole apps converted to be responsive and support dark mode by using the design system. There was a bit of a snowball effect where one team demo'd their updates and others wanted to replicate it. People I paired with tended to be interested in design systems and ended up advocating and contributing. Some larger components happened by embedding on teams who would help build and pilot them. | ||||||||||||||||||||||
25 | We embed in consuming teams,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | More self-help at the point of use. Right now, consumers have to take a step or two away from their work to get help. It'd be much more useful in context. We are moving towards more AI options to fill the gaps. | Competing priorities,Headcount or bandwidth,The scale of the organization makes it impractical | It always helps build relationships when we provide support, but more often than not, supporting teams has been part of larger efforts to move the needle on things like dark mode, accessibility, and layout updates so it's more like table stakes than going above and beyond. | ||||||||||||||||||||||
26 | We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | I would have a person or agents doing that 100% of the time. In fact I want to build a team of agents to help with these tasks. | Competing priorities,Headcount or bandwidth | We’re in the process of creating docs for all components, patterns, etc. they didn’t exist before. We’ve felt really good when we can provide help to the best use case of components that aren’t documented. We help to co design with feature team designers. | ||||||||||||||||||||||
27 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | We are a fairly large design system team for a smaller sized company so we may fall in the category of extreme support. I think sometimes I wish more designers and engineers self serviced instead of asking so I hope to build more tools to help with that. | Competing priorities | I think a high level of support is what has gotten us the adoption we've had. We do intakes with teams when they start a new project to onboard them in using the components and tokens and that helps new areas learn about our system as well. It's very high touch and I think sometimes it burns out design system team out though. | ||||||||||||||||||||||
28 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | We have started to streamline our documentation, but it could be much more "just in time" and focused. Early efforts from the team produced usage guides that are EXTREMELY robust but also very long and hard to navigate, and often buried on the artboard inside of Figma libraries, which isn't where the team is actually working. | Competing priorities,Headcount or bandwidth | Design and engineering teams at our company are quite small and very siloed, and consistent expectations for more and more speed without more resources led to a lot of work arounds to just get things done. Sometimes, this meant cutting corners and skipping steps that might have prevented errors and rework later in the process. Without shared resources, teams were often rebuilding the same things over and over and getting close but not actually consistent with styles. When we took over and implemented a token infrastructure as a first deliverable, there was a lot of resistance to the addition of anything that might "get in the way" of the processes they relied on to get work out the door, despite the flaws. We launched office hours and a Slack support channel, a new shared codebase, updated in-place documentation, and basically ran an internal marketing campaign hyping the launch. We also developed a roadshow-style presentation and met with each domain team to ensure they had a small forum to ask specific questions, make suggestions, and raise concerns. We created a new project ticketing intake process so teams could easily submit requests and get DS support, and we often sat in on kickoffs and critiques to ensure that users understood what was available and how to use it, and could quickly make requests we could help complete. We were only a two person team (design + eng), but giving the team as many channels as possible to be heard and get quick support helped us push early adoption and lower resistance, which was a huge positive marker to leadership. | ||||||||||||||||||||||
29 | We do hands-on sessions or pair programming,We embed in consuming teams,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | More focus on how we use AI to support the design system. Using AI tooling to handle migrations across consumer codebases. Take the pain from users. | Competing priorities,Headcount or bandwidth | Several times, we embedded DS team members directly within a consuming team to help them deliver features or adopt new components. Directly from here, we saw a change in sentiment and relationship with those teams. Adoption increased. | ||||||||||||||||||||||
30 | We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | More 1:1 consults and demos. Embed in teams to help up skill them and familiarize with how the system works and makes decisions. | Competing priorities,Headcount or bandwidth | Embedding our designers in a large redesign project happening outside day to day work really helped capture future needs from the design system and develop a perspective on design decisions. But any time we help a team out by fast tracking a bug fix or feature request it helps build trust which goes a long way for building relationships. | ||||||||||||||||||||||
31 | We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | I'm working on getting our team to a place where the Design System developers are embedded on adopting teams and designers are engaged in product design, but that is a major culture shift (at least the developers part) due to the split between UX/XD and product/development teams. I'm trying to get a foot in the door through hands-on/pair programming sessions. | Lack of access to consuming codebases or design files,A culture where UX Engineers are separated from "full stack" developers working on product teams. | UX Engineers pair-programming with product developers is currently considered "above and beyond". We had a situation where a dev team was trying to use our code components in a Next.js app and running into "window is not defined" issues. We set them up with a Next.js boilerplate repo with design system components ready to use that other teams now have access to. | ||||||||||||||||||||||
32 | We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | More outreach, more team building so people feel confident coming to you | Competing priorities,Headcount or bandwidth | |||||||||||||||||||||||
33 | We embed in consuming teams,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | Addition of multi-modal documentation like videos, pre-planned, regular information sessions, and official office hours. Some of these exist in theory but find little use, but we also aren't really pushing people into those spaces. | Competing priorities,Headcount or bandwidth | I would argue we haven't yet gone "above and beyond" in a way that qualifies. We've struggled to maintain what I would consider the minimum due to a cyclical lack of buy-in, lack of trust when there are integration efforts, and reduced team sizes fighting and incredibly full backlog of competing priorities that don't prioritize quality over output quantity. | ||||||||||||||||||||||
34 | We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | I'm not sure I would change anything. I would like more people have on the team or know the system enough that they can support the system. | Competing priorities,Headcount or bandwidth,Unclear ownership (Is support our job?) | Anytime we make it seem like we go above and beyond in supporting a consuming team always has a positive impact in those areas. Personalities on the design system has more impact than programs or process for support. | ||||||||||||||||||||||
35 | We offer async support channels (Slack, GitHub issues, etc.),We publish video documentation,We publish written documentation | We would have our small dev team proactively reach out to product dev teams and train them on how to use the design system properly. | Competing priorities,Headcount or bandwidth | |||||||||||||||||||||||
36 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | It would be amazing to embed someone when a new product is onboarded to spearhead the upgrade and conversion process, giving hands on details to the new team to get them up to speed. | Headcount or bandwidth | In one particular case, a significant product at our company had already determined they couldn't use our design system due to technology limitations. So we spent time learning about the product, getting provisioned equipment from IT so we could run the full thing locally, and then a couple months (part time) working with and educating the team on how they could incrementally adopt design system components into their application. Not only did this build a lot of trust, but also removed a presumed roadblock in adoption for that product. | ||||||||||||||||||||||
37 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | There are two things I know we'd like to do if possible. 1. Would be great if the onboarding process included a short apprenticeship with the design system team to help learning how to use the system for implementation purposes but also to help with contribution. This could also help with any product level systems work. 2. We struggle with contribution and it would be great if we could enable that better. The apprenticeship idea above would help but I'm sure this could take many different forms. | Competing priorities,Headcount or bandwidth,The scale of the organization makes it impractical | We’re partnering with several product teams to help them adopt our design system. Each team typically follows a phased plan to migrate from their existing components to ours. During this process, we collaborate closely for several months—answering questions, refining features to match their current functionality, and sometimes even introducing new components along the way. | ||||||||||||||||||||||
38 | We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | More roadmap visibility, less about fixing bugs | Competing priorities,Headcount or bandwidth | |||||||||||||||||||||||
39 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | We'd offer: - tooling for self-service to meet users in their tools (figma, VS code etc); collaboration sessions with feature teams (embedded DS reps in the feature development for bigger pieces of work) | Competing priorities,The scale of the organization makes it impractical,We are working in a constantly changing structure. It makes it next to impossible to improve something. | Our most impactful adoption "move" was a UI refresh project. we drove it through the design system. That gave huge push even after project was complete | ||||||||||||||||||||||
40 | We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors | N/A | N/A | |||||||||||||||||||||||
41 | We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | I would move the support channel from a meeting chat that remains open, to an actual channel that lives within a larger team, alongside other active channels. I'd also have clear and accessible documentation about the support processes to help manage expectations when it comes to different types of issues and requests. I'd also want to test out how we could leverage AI to allow consumers to ask component usage questions (and similar), | Competing priorities,Headcount or bandwidth | I've stepped in to fix front end bugs when my engineering counterparts have higher priority/complex tasks. Being able to help triage issues to more quickly provide resolutions while taking pressure off of teammates has lead to great relationships between our team and our consumers. | ||||||||||||||||||||||
42 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We publish written documentation | We would have the capacity to go from a part-time team to a full-time dedicated DS Team allowing us to offer office hours and even embed on the product teams. | Competing priorities,Headcount or bandwidth | Taking time to huddle to understand the actual problem and then pair-program is definitely appreciated and goes a long way towards a product team's DS adoption. | ||||||||||||||||||||||
43 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | Have a lot of the documentation and support queries that handles by a Bot except the ones that need manual intervention. Have an automated method for sharing and tracking contribution highlights from support calls so less manual management is needed. | Headcount or bandwidth | Every conversation with a DS user is a learning opportunity for both sides. At lest the way I look at it. When the tone of support conversation is curious and collaborative rather than defensive and superior you end up having much more trust, fun and desire to engage with the systems team. | ||||||||||||||||||||||
44 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | I would love to provide more hands-on workshops, perhaps more extensive onboarding, a camp for all you need to know about components and accessibility, more component UX research. | Competing priorities,Headcount or bandwidth,Lack of access to consuming codebases or design files,Unclear ownership (Is support our job?),Not only does the DS team have competing priorities but also our users do too. They have fast timelines where they need to get something out the door now, and sometimes because of legal or other factors they can't change their design even though it doesn't follow the design system's best practices or our coded components. | I believe providing on-hands support and collaboration with Design system users does strengthen the relationship between the design system and their consumers. Consumers feel heard and want to continue using the design system when the team actually listens to their input. | ||||||||||||||||||||||
45 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish video documentation,We publish written documentation | not sure | Headcount or bandwidth,The scale of the organization makes it impractical | |||||||||||||||||||||||
46 | We embed in consuming teams,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | Shift to agent-friendly instructions that is good enough to generate accurate and contextual answers, pulling from many sources (content, layout, token, component guidelines) for more relevant and comprehensive results, where people need it (slack, Figma, docs page etc) | Competing priorities,Headcount or bandwidth | |||||||||||||||||||||||
47 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish video documentation,We publish written documentation | One ask that I've seen from developers is how to take an existing Figma comp from a designer and somehow translate that to use components created that follow our design system. I'm not sure if a training session is the best for this or maybe some type of MCP server that has a deep understanding of Figma, our design system, and our React library that implements the design system. | Competing priorities,Headcount or bandwidth | |||||||||||||||||||||||
48 | We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | Be more present in teams daily work, like having a buddy team or something, so that issues, hardships and things that are frustrating (yet not frustrating enough to contact us) gets to the surface. | Competing priorities,Headcount or bandwidth | once I heard that someone struggled with different form-components needing to be implemented differently, this sounded weird so I asked them to show me how they implemented our components. I was mindblown, it was complicated, even if each component was easy to use on its own, together it was a mess. Which led to a new component which makes implementation identical and enforced identical validation handling. Did it have a great impact on adoption? Nope, people used it equally much when it was hard and messy. Did it improve the design system teams understanding? Yes! Did we improve developer experience? Yes! Was it some of my best work? Yes! | ||||||||||||||||||||||
49 | We do hands-on sessions or pair programming,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | I would have more people on board of the design system team and we’d be running regular office hours sessions, as well as show & tell sessions on design system and what’s new. We’d have a support channel and a dedicated person. We’d establish an elaborate design system wiki space with documentation, video tutorials and other learning materials. | Competing priorities,Headcount or bandwidth | I’m a single designer working on our design system and consistent effort to support the DS users across teams results in better understanding of the system among designers and engineers, as well as willingness to align with it. On multiple occasions I went above and beyond to support component and designs delivery, as well as worked closely with the engineering team, which allowed for delivering on time and enforced cross-team collaboration. It also contributes to better communication between design and dev, as I’m working towards both teams mutual understanding and speaking the same language. | ||||||||||||||||||||||
50 | We do hands-on sessions or pair programming,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We publish video documentation,We publish written documentation | I would (and am, one by one) rebuild every component to provide functionality and good defaults, prebaked compositions for common use cases, and build in more control for product teams to modify and extend these components for more specific needs. I trust teams to make good choices and only go off the rails when it benefits the craft of the product experience. I also expect them to reach out when they choose to do so, so we can advise along the way. | Competing priorities,Headcount or bandwidth | |||||||||||||||||||||||
51 | We do hands-on sessions or pair programming,We embed in consuming teams,We have access to dev environments to help debug,We offer async support channels (Slack, GitHub issues, etc.),We offer office hours or open doors,We publish written documentation | More embedding in consuming teams | Competing priorities,Headcount or bandwidth,Unclear ownership (Is support our job?) | Embedding on a consuming team allowed us to truly dogfood, unfiltered, and build a better system to empower designers and engineers to do their jobs better | ||||||||||||||||||||||
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 | ||||||||||||||||||||||||||