Episode 039 Raw Data

	A	B	C
1
2	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 39, deep dive hosted on December 5, 2024 with Ben Callahan and Diane Larsen. There are 80 answers. The question this week was: ----- Hello curious friends! In a recent article over on the Sparkbox blog, a few of us jotted down some of the uncomfortable truths about design system work. I chose to share something that’s been itching at me for a while now—the idea that the teams that need design systems the most are the ones who likely don’t have the necessary skills to use them well. This has come up quite a few times in our deep dives on The Question. We’ve had theoretical conversations about whether it’s our job to train product designers to use the more system-focused features of Figma, we’ve expressed some frustration with the amount of work doing so adds to our plates, and we’ve also shared some success stories about the strong relationships built when we take the time to work with consuming teams to learn these skills. As always, there are no easy answers. This week, Diane and I have been setting all that aside and thinking about ways that we can jump in and provide the training these teams need to be able to take full advantage of the systems we’re building. This week on The Question, we want to hear what approaches have worked for you and what challenges adding this education-focused effort can create. Welcome to The Question for the week of December 2, 2024! In your approximation, in order to take full advantage of what your design system offers, the designers using your design system assets need some training: • All of the time • 75% of the time • 50% of the time • 25% of the time • Never • n/a In your capacity on a design system team, have you attempted to offer training to the designers who are using the design assets you offer? If yes, what has and hasn’t worked? If no, why not?
3	Question 1: In your approximation, in order to take full advantage of what your design system offers, the designers using your design system assets need some training:	Question 2: In your capacity on a design system team, have you attempted to offer training to the designers who are using the design assets you offer?	Question 3: If yes, what has and hasn’t worked? If no, why not?
4			na
5	50% of the time	Yes	There were a few options on how the training would be delivered (dedicated Office Hours, Drop-in session, session just for the team) but there was resistance from the team to start using the DS anyway.
6	I’m newer to working within the design systems world - I have not yet had much experience in this realm to quantify a percentage.	Yes	We offer detailed documentation, but this is oftern overlooked. More direct support tends to be more effective.
7	75% of the time	Yes	We do live demos using our components in Figma at our fortnightly design community catch ups. These have been responded to really positively by consumer designers as it's a captive audience. Try to exploit time where you are all together and they can't escape! When putting in dedicated time for upskilling, this has also been receives well but requires quite a lot of planning on the Design System team's part to get right. It can take quite a bit of capacity out of our sprint. Generally there is enthusiasm from consumer designers for the change of pace. A lot of our consumer designers have 'improve figma skills' on their Personal Development Plans. Work with their line managers to get training with the DS team high on their list of priorities. We are also about to try user testing with a small section of our consumer designers for Variables in Figma. This is get a good gauge on how difficult this new feature will be for them to adopt. Generally speaking, chucking a Figma component library over the fence for designers to use without some kind of demoing of how properties work, how autolayout works, how these match up with the code props etc, hasn't been successful. They need some hand holding for adoption to be smooth.
8	50% of the time	Yes	We use a mix of recorded videos, office hours, a Slack support channel, demos, and DS designers dedicated to various portfolios
9	All of the time	Yes	Has not worked: assuming consumers will read documentation even when incorporated into onboarding. The most experienced designers and engineers will likely dive directly into the build/design. Has worked: - ensuring links and opportunities to train exist (synchronous and asynchronous), based on/in the context where they are needed - contact info for those who can help - removing the stigma of "not knowing", nobody knows everything and even the most experienced designers and engineers need institutional knowledge at times
10	75% of the time	Yes	Quick learning segments at the end of design crits or on all design team meetings work in varying capacity. Loom videos that can be referenced easily later worked as well.
11	75% of the time	Yes	Workshops on specific things worked but knowledge varies amongst Designers and it’s hard to align everyone on a certain level.
12	75% of the time	Yes	We’ve hosted office hour sessions for teams that reach out through our support channels and offer monthly instructional demos (self-registration) to guide users on accessing and using Figma assets. Some designers, already familiar with Figma, were able to jump in and start using our system right away. However, training remains a significant challenge. While our team has the capacity to grow and maintain the design system, we lack the resources to develop ongoing training programs or manage the enterprise-wide change management needed to accelerate the transition from legacy systems. In a government context of over 300,000 employees, many designers are not formally trained and have had limited access to prototyping tools like Figma. This is often due to departmental procurement constraints or reliance on outdated methods. To address these challenges, we are exploring scalable solutions, such as templates and patterns that reduce the learning curve, video tutorials, monthly meet-ups to introduce training concepts, and formal online courses in collaboration with our organizational training team. We are also working to improve our documentation and investigating ways to leverage training resources offered by our technology partners, such as Figma and StencilJS. Upskilling practitioners in both design and development will remain one of our greatest challenges, particularly in a highly decentralized organization.
13	All of the time	Yes	What has worked: not only taking the time to train a designer from scratch about design systems, atomic design, design tokens and documentation as concepts, but also applying all this knowledge to our design system while creating a couple of components. What hasn't worked: assuming that designers are ready after training without applying their new knowledge on creating components.
14	75% of the time	Yes	It's hard to answer for the existing system I'm on because it's failed twice and we're about to embark on a third try without the necessary planning or research. We don't really have a functioning system to answer the question about. So, I'll answer for the previous system I worked in tangent to at Scotiabank. Many developers and designers didn't fully use the design system and built components/designs that deviated from the system. The design system team offered open hours that were there to provide training (answer questions) about the design system, but it required knowledge of the system in the first place. That doesn't really answer the question except to say that in order to train people on the usage of the system, they need to know about it in the first place and consuming it needs to be part of their scope of work. Naturally, I would imagine that using it and being trained on it would need to come from their manager as a job requirement, especially, especially at a company where the only thing that matters is performance evaluations (which translate to promotions and salary bonuses).
15			I am not currently on a DS team / nor employed :-( Wishing I had more to offer for input here
16	75% of the time	I'm a Frontend Architect, and I don't work with design assets, obviously. I have, however, struggled with Product Designers lacking the understanding of what a Design System is, and how the workflows around their needs, requirements, and new designs within the product team should be brought to the Design System, or not. This has been a very painful process, and in some ways it has hurt the success of the design system within our organization.	n/a
17	All of the time	Yes	Our token naming convention is implicit rather than explicit. For instance, instead of "color-text: #000000/#FFFFFF", (an explicit name for the default color of text), where ours is 'ink-base: #000000/#FFFFFF", which stands for the default color of text, or icon/glyph. To imply use rather than explicity define reduced the number of tokens needed but requires some comunication.
18	50% of the time	No	We are exploring which opportunities would be the most effective, as well as achievable.
19	50% of the time	No	we have not, and we are paying for it now. some of our upper management feels that very particular training will come across as condescending or talking down to the designers. but, now developers frustrated becasue they are getting fed "non-standard" designs and component usage and things are taking longer
20	50% of the time	Yes	It was mostly done case by case as help during projects. The results were mixed and often what didn’t work is that designers wanted to create their own designs and not use premade components and templates. What I realized is that most designers especially those with the strong artistic background lack the understanding of system thinking and are not aware how components are technically built for the web. Trying to catch up on these things during projects is kinda like trying to teach a developer how to use a variable in code after noticing he is coding without. Ideally this things should be already part of a senior designer background.
21	50% of the time	Yes	Just an open announcement in multiple design meetings that if anyone has any questions to please reach out.
22	75% of the time	Yes	It's imperative to have buy-in from everyone involved — managers to the designers. Without it capacity won't be allocated and there won't be a willingness to learn or see the value in stepping away from daily tasks and responsibilities. If you see a weakness, go to leadership to ask for top-down help and prioritization leveling up. Share learning and examples where ICs spend the most time for bottom-up learning and encouragement. 1:1 works, but 1:many is better. The best way to clone yourself is through things that scale — whether it be a video walkthrough of concepts or how to apply parts of the system, links to courses or resources that already exist, or simply documentation. Chasing artifacts isn't helpful. Tools and technology change, but concepts, strategy, and methodology are more stable so focus on those so that design system subscribers can apply them in any circumstance and regardless of tools.
23	50% of the time	I'm one of the developers on our team, so I support the developer side of this. Our designers do offer training, mostly 1 on 1 but they have recorded at least one video series on a particularly complex component.	Answering based on observing the designers on our team: Intentional design reviews every couple weeks with some designers (1-on-1) seemed to yield fairly good results. Having the Director of Design (a separate unit from design system) supporting us has cut down on some of the support needed as he is able to reiterate best practices and encourage correct component usage in Figma. Simply maintaining detailed documentation on its own hasn't fully worked as designers have to be in the habit of reading the documentation, so the smaller group sessions or feedback have been still needed.
24	75% of the time	Yes	Live sessions, whether individual, during office hours, or in design meetings, have been the most impactful way to walk through training. While documentation will eventually be a big help and free up our team’s time, we’re not quite at the stage to release it yet. Our organization has many designers who are early in their careers, and for some, this might be their first experience working with a design system. Because of this, our training needs to cover the basics thoroughly to ensure the key concepts are clear. This also means we need to provide more guidance upfront, rather than relying solely on a quick reference sheet.
25	50% of the time	Yes	Different teams using our system have different levels of tool and sometimes even web basics proficiency (think responsive, flexbox, grids, etc.). Most of our product team are used to using or creating components but still need support creating recipes. Content designers are starting to use our system and we are finding that they need more close onboarding and more intensive support. For onboarding and support we have some self serve documents, hold office hours, have dedicated team support channels, and schedule collaboration sessions where needed. This has been great from an adoption point of view but definitely a time and capacity strain for our small team. We are hoping to move from a close support system to provide more self serve resources.
26	75% of the time	Yes	Designers although get an overall understanding initially but they require self exploration time with the assets to understand it better. Have also realised that it also depends on the designers whom you are training as well, their expertise and understanding of the design system plays a vital role in the success of these trainings.
27	All of the time	Yes	Demos, 1:1 paired sessions, Office hours. I notice a lot of the times it's not necessarily they need training on the components but rather lack the understanding of Figma's basic features.
28	25% of the time	Yes	The reception for training is always positive. But if I'm honest, I am not sure we did a good job reassessing people's tool expertise post-workshop to know it was effective.
29	50% of the time	Yes	It gets de-prioritized.
30	50% of the time	Yes	One-on-one design pairing sessions (co-designing), workshops, recorded video demos
31	75% of the time	Yes	When new designers are onboarded to the team, we go through our Figma libraries and assign required Figma training. When complicated components are added, we go through the component in a team meeting. For designers who are not as strong with Figma (usually designers on a different team), we'll set up 1-on-1 time to go over things.
32	50% of the time	Yes	Starting with Figma, we've seen a very uneven skill level. That includes not knowing about auto layout or branching, for example. We've put together a curriculum in 3 parts: Figma skills, how to best work with the DS, and how to create your own components that work with the DS. We've ended up only creating the first module. As for the other parts, we've decided to take a quicker approach - ad hoc video tutorials based on the commonly asked questions. That seems to go pretty well so far, though we've seen that repetition is key here. Our users sometime need repeated training in order to pick up some of those skills.
33	75% of the time	Yes	WRITING ROBUST DOCUMENTATION WORKS LIKE 2% OF THE TIME YET IT'S THE MOST POPULAR WHYYYY. For engineers–I think it makes more sense. They think in install guides and dev doc sites all the time. They know how to find what they are looking for in a robust doc site. Designers tend to be visual thinkers! I've found a lot of success with a "core" amount of design documentation and then video walkthroughs for new releases or commonly asked questions. Office hours is also a good way to time box designers that need help. On the topic of office hours, we've found that group call-style office hours has low adoption for real problem solving while admitting consumers into office hours one at a time works really well! If someone asks a commonly asked question we'll ask if we can record the session and share it with everyone. We get a lot more engagement this way!
34	50% of the time	Yes	Bi Weekly training session. One hour long recorded by one of our designers who also runs a YouTube Figma tutorial channel. He loves it. Consumers get so much value from the sessions.
35	50% of the time	Yes	Have done workshops during office hours, recorded videos (Loom), Figma slides, one-on-one pairing Most effective is surfacing the info when the designer has a need for it, so one-on-one pairing, and having links in docs to the recorded videos/slides
36	All of the time	Yes	Basic onboarding sessions give new joiners an understanding that the system exists, how to self-serve for more support, and a quick demo of the system in use. Responses are anecdotally positive, but there's no quality metrics on how useful these sessions actually are. It also only focusses on new starters, not those who've been here for a while. Even things which are purposefully demonstrated have clearly been forgotten by designers in the interim, as they ask for support on just those aspect which we demonstrated (composability/open slots).
37	50% of the time	No	Training is something we are in the middle of working on! We are looking to add high level training to introduce the DS, the theories behind it, and how to use the major features like theming and component variants that we set up already. Theres more complex slot strategies we do feel responsible for teaching more about, but we have been playing with the idea of first just providing more out of the box resources that require less configuration. Then, configs become something thats more of a higher level skill that we can teach when we have more resourcing and capacity to take the task on. We have not offered any more figma training at this time as we just dont have the capacity to take this on, and there are already incredible resources, both free and paid (we get an education stipend) that people can find on their own. I push my team to prioritize training for things that the team could not easily learn elsewhere. How our DS works in our org is unique to our company so we build training first surrounding how that affects how we build products and any peripheral knowledge needed to support that education path. Our teams could definitely benefit from more training and the DS team is well positioned to do it, but it really comes down to capacity & priority
38	All of the time	Yes	I have offered one on one training
39	50% of the time	Yes	We teach consumers how to use the tools we provide, and the places they should look/consider when making decisions. We share some responsibility with the DesignOps team in helping upskill them in Figma (in the sense that if we want them to use a shared library, for example, we take the opportunity to show how/where libraries are even though "figma training" isn't in our charter)
40	75% of the time	Yes	Screensharing on Zoom to talk through and orient them to certain features, usually followed by sharing links and resources (Figma YouTube videos, Figma docs, any other blog entries or resources on particular things including documentation in the design system itself!). Something about that combo does seem to work, but sometimes requires follow-up or reinforcement in subsequent sessions. Just expecting folks to read and understand on their own (even if I've done all of the above except get on a call) hasn't worked as well.
41	All of the time	Yes	The key thing was letting them ask questions to figure out where they were getting stuck. I've been in several organizations where a designer is usually excited to try the DS, and they start designing with it, but then they get hung up somewhere. And they show up at office hours or you find yourself having a 1:1 with them. Usually it's a misunderstanding with what they can/cannot do, and how to read your documentation. It's almost like they have to learn how the documentation is organized and then where in the Figma library they can find what they need.
42	50% of the time	Yes	While we have good documentation, people don’t always read.
43	50% of the time	This is something we are currently working on. Currently we have ideas for a running office hour session bi-monthly and plan to record a video series for more complex concepts.	IT hasn't been a priority for us as we've been working on releasing the design system over the last few months. The next few months will be focused on education and migration so lots to learn!
44	50% of the time	Yes	All the time. We have at least 1 quarterly training on what subject that have come up as needing more training as well as “snacks” kind of quick training we do at the beginning of open hours. Those have been super successful as they are more casual. The quarterly one do better now after approaching by smaller product design teams as opposed to the entire design team at once.
45	All of the time	Yes	I conduct weekly training sessions for designers covering a range of topics. Starting from any design system changes we are planning on making, Figma updates plus new features released, Question of the week which covers the most common question(s) I’m asked in a week to help others, component construction, how to manage file libraries etc If we’re looking at getting the most amount of information to the most amount of people where they can gain knowledge but also ask questions this is really an engaging method which feels personal and relevant in time. All sessions are recorded and uploaded to a confluence page which new and current users of the system can rewatch. However, when you have a large group of people, it is hard to always gage how many users have understood all of the information passed on. Especially those not willing to speak to others. I personally like the method of students being asked if they understood what was explained. If they say no, then I’ll re explain. If yes, then repeat the information back as if they are explaining it. But this is hard to do with a large group. Hence coming to the second method, 1-2-1 seem to be the best to ensure users understand how to use the system with their personal context in mind which is easier for them to know what to do. But the down side is the amount of time across many designers. In summary, I do both. Weekly training sessions so that everyone can get all the information they need, but being open to have on the fly quick calls on how to do something. Something I’d like to move towards is getting those who get the system to start teaching and being delighted to cover certain areas. This prevent me feeling like I am being a bottle neck whenever there is a question on something not working etc
46	25% of the time	Yes	Has worked: - Small workshops with Designers on how to use the (new) assets - Weekly meetings in design communities - Regulary communicating that the design system team is always available for questions during the week
47	50% of the time	Yes	Worked: • "Show & Tell" using actual design work examples • Detailed documentation with visual examples of DOs and DONTs • Design mobbing Not worked: • Only providing basic instructions, assuming people have the level of understanding and skills to figure things out themselves • Not using real work examples to show how things work • Lack of documentation and visual guides
48	75% of the time	Yes	Live in person training has worked well as it’s easy to ask questions in the moment and focus on the training. We have teams all across the world though so it can only get to a small amount. We have also tried self service learnings and live online trainings. This have the benefit of reach but for an individual we have less ability to know if they really understand the content.
49	50% of the time	Yes	Educational sessions are often well received, but it is difficult to ensure attendance. We often record them, keep them in our archive, and promote them in our newsletter. But it makes us wonder if we should continue investing in the effort to prepare them if people can't attend/consume the content.
50	75% of the time	Yes	the technical knowledge of participants are very diverse, the training can be boring and slow to some OR way more advanced to some (therefore, boring again)
51	All of the time	Yes	It has not been very effective, often times people don’t give the training the time and attention it needs - maybe due to busy schedules, lack of enforcement and/or they think they already know all of this
52	All of the time	Yes	I've received positive responses to having a half-hour workshop with a tiny participant group (3-4 people). I have examples on artboards so they can test-drive components or tokens. Less talking by me and more action for them. This allows people to try things out in an environment that is (hopefully) low-pressure and friendly. It also allows them to ask questions and provide feedback in a more personal setting.
53	50% of the time	No	Not enough time to do it, but planning to train them in the near future.
54	All of the time	Yes	Mixed bag. Some people are very interested in learning new skills and tools and leveling up, but many are either too overworked and burdened with deadlines to put the mental effort in OR they simply don't want to interrupt their established workflows to learn a new way. Most of the pushback I hear is that they "don't have time" to learn to use the new features, even though it would likely save them time and effort in the long run.
55	All of the time	Yes	Longer lessons and tutorials did not work since they took too long to produce and no one would watch them. Our contributions initiative turned out to be a great hands-on way to teach people how to use our DS and build for it. Short "Did You Know" sessions in our office hours meetings have also been successful and an org-wide Design Dash really opened people's eyes to how they can build quickly with our DS on a tight deadline.
56	75% of the time	Yes	A roadshow of the design system's history, current goals, and how to contribute helped provide more context around why people should use the design system and how to contribute to it. Before this level-setting, people weren't getting all the information, so they were forming reasons for why they should or shouldn't use the design system and creating their own contribution processes.
57	75% of the time	Yes	What’s worked: - Practicing empathy - meeting designers where they’re at! - Being approachable, supportive and helpful! :) - Fostering an environment where people feel empowered and excited by what they learn and look forward to the education because it makes their lives easier. - Being flexible and open to feedback and change - incorporating designers’ (one user type) ideas - Over communicating! Lol - Leveraging existing meetings to incorporate short trainings and education. - Incorporating demos of how to use components, nested components, instance swaps, documentation, etc…into our weekly DS meetings. - Sharing quick demo videos in our design team group chat for DS work. - Leveraging Figma component-level documentation for designers and showing them how to find/refer to it. - Using a portion of my weekly office hours time for training/education where designers can get help and training in an IC environment. Helps the shyer folks feel more comfortable. - Sharing short tips and tricks for designers using assets in weekly UXcellence meetings. - Focusing on specific topics has helped bring structure to the education each week and helps folks also prepare their questions. What hasn’t worked: - Education/knowledge sharing that only occurs during meetings. Sometimes people have conflicts or are out of office, so they miss out in important opportunities for training, and then there are gaps across the team(s). - One-on-one training can be intimidating for some folks. - Creating additional separate DS training meetings. - Training that is too technical or not applicable (ex: training for DS designers is different than for feature designers).
58	25% of the time	Yes	It’s ironic that as system makers, we excel at scaling tools, UI, and code but often fall short when it comes to scaling ourselves, our teams, and our support structures. While documentation and office hours have their place, they often reach only a small fraction of the audience. At The Post, we piloted an ambassador model—a "boots on the ground" approach. Instead of over-investing in the revolving door of office hours, we identified individuals within each team who were passionate about the system and empowered them. Through training sessions, dedicated mentorship, and embedding support into performance reviews, these ambassadors became extensions of the systems team. This model created feedback loops, fostered async and synchronous collaboration through "component sprints," and allowed us to address challenges earlier in the process. It didn’t solve everything, but it bridged gaps that office hours couldn’t, enabling system advocates to align with teams at the right moments—not just at handoff.
59	50% of the time	Yes	It’s very important to consider the motivations and domain of knowledge for consumers - designers or otherwise. It’s vital that consumers care about the system and its use.. a great way to build this investment is to invite collaboration.
60	All of the time	I'm a developer, so it wasn't my task to share knowledge about using DS with design team, but I know that our DS designers had meetings/discussions with product designers about it. At the same time we tried to share this knowledge with developers who didn't participate in implementation of DS and components based on DS	If I remember correctly the main struggle was lack of understanding of what DS is and why it's important to stick with the rules
61	All of the time	Yes	What has: small group, in person, practical workshops with exercises, tailored to skill level (intermediate or expert). Labour intensive, but we've found it is the best way to get attendance and attention vs larger, remote sessions.
62	All of the time	Yes	What has worked: Upfront research or interviews to identify system uses cases. For example, what are the most common design scenarios, how does the system need to flex when more exploratory work is being done. Using that research to inform training and being open to making adjustments informed by feedback from the training sessions. What hasn't worked: Trying to train on the entire system vs training in the context of an actual project or chunk of work.
63	Design team of one.	The largest team I have been in is a design team of two, and we inherited a design system. We had quite different approaches to working with layouts and new components.	I’ve experienced some disagreement on complexity of components. My approach was build for change and reduce manual work later, the other would be a lot of copy/paste and rebuilding screens upon changes. Would be great to have some best practice on level of complexity and building in interactivity in components.
64	All of the time	Yes	Internal YouTube Channel and office hours
65	25% of the time	Yes	Pair designing works best because it's hands on specific conversations. Hypothetical conversations don't cut it
66	All of the time	Yes	I feel like we have tried EVERYTHING, but in reality we haven't considered this problem deeply enough until now. 1. We have tried training DS Ambassadors picked from each product design team in weekly sessions, they didn't attend and the programme fell over 2. We tried open drop in sessions, but they are either too busy or nobody comes and was hard to keep the momentum going especially when there were many other meetings in the diary for team design reviews etc. In a large org it's literally death by meeting 3. One of our most successful sessions we run is called Figma Fridays (now fortnightly) where we basically teach the designers Figma, and decouple it from the design system - this is a very popular format and we get guest speakers at these too, and it does help upskill designers in using Figma properly and thus this positively impacts the DS too 4. I have successfully rotated a product designer into the design system for 6 months and upskilled him - he is now a DS advocate within his team 5. I have successfull rotated a design system designer out into the product team where he is now able to advocate for and teach designers of all levels in product on good figma practice and use of the design system Yet I feel we havent actually gone far enough or got deep enough into the barriers to correct/brilliant use of design system components within product design. Though we have a few hypothesis, we havent yet validated them: - Our designers lack the skill to use Figma correctly even before they pick up the DS components - Our designers lack the knowledge of engineering impact when using the DS incorrectly (or engineering feasibility of their designs at all) and therefore dont consider their design choices and the knock on impact - Our designers are too time poor to invest in their skills - Our designers lack the autonomy in the organisation to push back on product direction that directly, adversely affects the product and the use of the design system
67	75% of the time	Yes	What’s worked: walkthroughs shared over Slack and documentation living in Figma to try to meet designers where they are when they’re designing and not ask them to search for the info (which makes it less likely that they’ll look for and find it). What hasn’t worked: creating these tools means we have to update them and they become out of date, which takes time and a deep understanding of our resources (and when they need to be updated). It also relies on designers to take the time to watch or read them, which they don’t always do, especially when designers are under strict deadlines.
68	50% of the time	Yes	Training on figma best practices, showing how we build components so teams can consume them easier.
69	50% of the time	Yes	Conducting 1:1 usability sessions, preferably in person, on new features in the figma library to get direct feedback and learn how they are using it.
70	50% of the time	No	Our team is minuscule (I'm the only fully dedicated resource), so we don't have the capacity.
71	75% of the time	Yes	Not being mandatory - people don't do it since they don't feel the obligation; doing just a recording instead of live sessions - people need to feel some first human contact to take you more seriously.
72	50% of the time	Yes	We always put it as "we've got some really cool features that we want to share with you", and in the training, we mix in our newest feature offerings with basic component usage knowledge. Keeps the designers' egos intact and let's them know they have been detaching shit for no good reason. -Arko
73	50% of the time	Yes	What has worked: Workshops: Hosting hands-on workshops to walk through new components, design tokens, and workflows. These allow designers to ask real-time questions and better understand how to use Zest effectively. Documentation: Clear, centralized documentation (in Storybook and Loop) has been crucial for self-paced learning, with step-by-step guides, FAQs, and visual examples. Office Hours: Regular, informal office hours where designers can drop in with questions or for a quick demo have been helpful for ongoing support. Figma Component Usage Guides: Embedding usage tips directly in Figma files has been a great way to reinforce guidelines without requiring designers to look elsewhere. What hasn’t worked: One-Off Training: Single sessions for onboarding without follow-up didn’t stick as much as recurring support or resources designers could revisit. Assuming Uniform Knowledge: Designers come with varied levels of experience with design systems, so blanket training without addressing different skill levels wasn’t effective. We’re constantly refining our approach to make training more engaging and practical for the team.
74	75% of the time	Yes	Walkthroughs from code to execution in the browser have worked.
75	25% of the time	No	Still planning to roll ours out...
76	All of the time	Yes	Very basic figma overviews were necessary. How to add libraries, where the component panel lived and how it worked… we also had onboarding sessions with each team to teach them about design systems and show them our system. In our org, the office hour type of meeting didn’t work. We had to go to the teams.
77	75% of the time	Yes	1:1 works but takes a lot of time. Group workshops only work for a small percentage of people.
78	All of the time	Yes	I've tried lunch-n-learns and sending out weekly Slack updates. Lunch-n-learns have worked to some degree. However, I don't think anyone reads Slack.
79	75% of the time	Yes	I had office hours every week but nobody would ever show up.
80	75% of the time	Yes	We offer walk throughs and desk checks, but it’s not often something we can sustain with the rate of demand
81	25% of the time	Yes	Onboarding designers get a 1 on 1 traning session that walks throught the libraries, tools, and documentation, expressing the ethos we have specific to our DS. Outside of that we don't do "formal" training, but on a case by case basis. We do send out the occasional Loom video describing new features. This mostly works for our small-ish team of 30 designers with varying degrees of expertise within the tools. But I think we could improve with more regularly scheduled sessions or topic-driven videos posted to our docs site. (Or other tried and tested methods folks express here 😀)
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100