ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Thanks for your interest in The Question!

Sign up to participate in future questions here.

This file is the raw data from Episode 008. You can check out the Episode 008 FigJam file, watch Episode 008 on YouTube, or read the Episode 008 Wrap-up Post!

Major thanks to zeroheight and Sparkbox for their sponsorship of The Question this week.

There are 47 answers. The question this week was:

-----

Jina and I were chatting about how much the landscape of digital design has changed since we got started in this business. Lately, there are so many incredible tools that require almost no coding experience and allow you to accomplish things that simply weren’t possible when the web was first coming into existence. That got us wondering, how are these tools impacting design system practitioners?

So, we formulated a few categories of common tools:
• Design tools (like Figma, Token Studio, Sketch, Zeplin, etc.)
• Developer tools (like GitHub, Style Dictionary, Storybook, etc.)
• Design system integration tools (like Supernova, Knapsack, zeroheight, Luro, etc.)
• AI tools (like CoPilot, ChatGPT, Dall-E, Bard, Midjourney, Adobe Firefly, etc.)
• No-code tools (like Webflow, Wix, Framer, Squarespace, MailChimp, Canva, AirTable, Notion, Zapier, etc.)

Certainly, there are many more (and new ones introduced every week). With all of this as context, here is the week’s question:

How many third-party tools are you using to streamline your design system workflow?

Tell us which tools you primarily use and share a story of a success or failure you experienced related to one of those tools.
2
Question 1: How many third-party tools are you using to streamline your design system workflow?Question 2: Tell us which tools you primarily use and share a story of a success or failure you experienced related to one of those tools.
3
3–6Figma. When a particular designer finally "got it" and started making their own component library based on our design system (a system from the system) and it accelerated her work.
4
1 or 2Most of the time we used Figma and Storybook. But there was a time when we used Sketch and InVision. I even had to ask my ex colleague the names of those tools, because I completely forgot.

Funny fact, that Figma was pushed by one of our new (at that time) designer. And we (developers) were really stubborn and didn’t want to change tools, because “Figma is crazy! I can’t find anything there! What is this white sheet of paper without an edge, a model of universe?” But this guy (the new designer) was also a pain in the ass, and he encouraged us to try it. Anyway, now I don’t even remember names of previous “very convenient” tools. Once our team had some understanding of Figma, it became clear that Figma was much more powerful.

Also, we used Storybook for developers. We created a site with compiled version of Storybook components for our design team, because they didn’t want to deal with code and github, but they wanted to see pure components without product.
5
7–10Figma, Tokens Studio, Adobe CC
GitHub, Style Dictionary, Storybook
Zeroheight
Jira


We've been busy doing a big tokens push of late. A few tooling problems arose. Figma/Tokens Studio was giving designers headaches because they were all working in one big file with all the components. Figma and TS were failing to sync effectively, so that they thought a task was finished only to come back to it and find half the tokens applied were missing. They've had to change process to work on each component in a separate file and then bring them together again to publish.

Also, our cloud based Jira access cocked up in the middle of this, running very slow or intermittently, and so we've had to supplement this with a good old fashioned spreadsheet to track which tickets/components are done in design and development.


6
3–6Figma and the biggest challenge/failure that we’ve come across is with implementation within the system. Our designers haven’t fully adopted components or variables and our engineers often copy values from Figma that should be tokens or props on an existing code component.
7
7–10My answer is boring - as the DS director/owner, I don't have first hand experience with many of our pipeline tools. I'm a consumer of Storybook and Figma (to a lesser degree), but the most exciting initiative we're working on is setting up our own ChatGPT for the DS, that will help our designers and engineers adopt quicker and easier.
8
3–6We used Figma, Token Studio, Style Dictionary, GitLab, zeroheight & Storybook.

Figma + Token Studio + Style Dictionary seems to be the best option for design token automation.

zeroheight and Storybook were used for a while by the team, but the feedback from the team was subpar: designers reported not liking zeroheight's WYSWYG editor; engineers reported not liking Storybook's story format in code. Eventually, the team decided to move to Knapsack for both (docs & coded components, or, storefront & workshop).
9
1 or 2Figma (of course). Incredible DS component mgmnt. Used to (forced to) use XD for this. Horrific and was never designed for it. Doesn't matter anymore.
10
7–10Figma, Storybook, Confluence, Jira, Miro, Stripo, Docusaurus.

One tool we use currently for documentation is Docusaurus. This is mainly focused on development documentation for components but also includes all accessibility guidelines.
It was a success story at first as it allowed the design system team to get a lot of documentation available to our users very quickly- as the library was growing quickly this was essential. However after almost of year of having it in place we realised it wasn't an ideal tool selection for long term use- it uses standard coding methods to create the content so cannot be used easily (or at all) for non-technical members of the team- so it is not possible to scale this to become our consolidated platform for the design system.
As a result, we are now looking into both Zeroheight and Supernova as potential suppliers for a new DS website for us.
I'd actually love to get feedback from anyone answering the question this week if they have used either of these tools!!!
11
NoneFigma
12
3–6I don't think what comes to mind stands out as a story, but here are at least a few things that come to mind.

Figma success: More transparent design practice. FigJam and Figma cover a ton of ground and so many disciplines from PM to engineers can work in the same space.

Figma failure: User admin nightmare (not on Enterprise so no SCIM). Temptation to make broad decisions based on tool capabilities rather than best practices.

Storybook success: Introducing accessibility tests. Ability to test configuration.

Storybook failure: Updates often leave inconsistencies and tech debt when methods and processes change. Fighting with the UI.
13
3–6Figma, Git, Jira
14
1 or 2Figma
15
1 or 2We primarily use Figma as the design tool. Everything else is done in house!
16
1 or 2We use Figma. We can’t seem to get consistent use of css frameworks across 30 products. We have multiple design systems.
17
3–6Figma: quick way to share components!
18
3–6ChatGPT, VSCopilot, GrammarlyGo, Github. Figma
19
1 or 2Figma, Storybook and Zeroheight. Currently starting setting up everything. Hoping it works
20
7–10Figma, Storybook, Confluence, Docusaurus (Terra Docs), Stripo (newsletter), Miro, Jira.

We have a love hate relationship with Figma.

Figma is a very powerful tool but we have encountered major bugs that affected our components that would set us back up to 10 days on trying to find a work around. We found the figma support team inefficient - the were one step behind on offering solutions that we had already come up with and tested (and dismissed as a solution). At the end we were the ones finding the work around, not them...

One of the biggest blockers that we find on our figma component usage is that designers are still struggling with the concept of autolayout. That has an impact in components that use slots as they need to create their local components using autolayout. Instead, they decide to build their custom solutions or even detach our components.

As a result we are having to set figma training sessions with designers which are time consuming.

Figma is a wonderful but complex tool and our designers don't have the time to learn the endless list of amazing features that they build. I also find that they rush on building features and release them when not ready and still buggy, and then they jump into the next feature... an example of this is branching.
21
7–10Figma, Google sites and Storybook for docs, Jira, Vessel (email), Github,...

Our doc site has been a story of many lows. We started off trying to use and internal CMS tool, which ended up not being ready for our use case and just took way too much time to port content. So, we looked into WebFlow, which was popular with some folks, but had security risks based on our company's standards. We ended up with Google Sites, which is pretty easy to use, however, based on risk management, we can't share it to external agencies. We have been investigating a new solution AGAIN. Gatsby came up, but the team using it is using a huge amount of their tech team's capacity to populate it. And, we have the core belief that all contributors should be able to contribute without needing to code or know mark up(i.e., CMS needed). We'll likely integrate w/ Storybook since the tech teams are using it so heavily.

So, stilllllll on this journey.
22
3–6I have used Figma, Token Studio, Storybook, GitHub, Zeplin a long time ago, Webflow for my personal website, and Notion for team organization. I think my preferred stack would be Figma, Token Studio, and Storybook. I think Zeplin is no longer necessary with the output that Figma has now. Some other tools I’ve used outside of this list are Contentful, Bootstrap, and Script based custom libraries.
23
3–6Figma
Token Studio
ZeroHeight
StoryBook
Azure DevOps
24
More than 20Storybook has been a success story, but one that has raised a lot of interesting questions about what its role should really be. Is it an engineering reference? A design reference? A source visual source or one that should contain detailed documentation? Should that documentation cater to both design and engineering audiences? Or perhaps simply put, can Storybook serve as a comprehensive doc source?

Overall, I am a fan. But I am also an engineer first, so the ease of creating an interactive code example in a tool-rich web application is an easy win for me. Plus I've used it for 7 or 8 years now, so I've been with it since it was a baby. Also the static site generation makes it easy to host, which is a great way to get timely design and a11y reviews.

But as noted in my first paragraph, this has raised some concerns and questions about what should exist within it.

Also raises another question I would love to ask The Question community: how may designers are comfortable writing in markdown?
25
3–6— Figma for design, a few Figma plugins
— GitHub for code, CI checks
— Storybook
— Starting to add in AI tools to help write Stories, code
— Exploring Figma-to-code tools

Failure:
It's unclear to devs whether or not Storybook is a sandbox for developing any/all standalone UI React "components" or a documentation site for DS components. We now have two Storybooks, one for "DS components" and one for "other shared stuff," and within each one, some of the components have working Stories/controls and others don't, and none have docs. Tools are only as valuable as the way they get used, and if you don't have a clear process/value prop, folks will just use it to get their job done. That's useful info (here's what the teams need!) but also makes for difficult communication.
26
3–6Figma, Storybook, Style dictionary, ChatGPT.

I think the biggest thing we expected from switching from Sketch to Figma, is that subscribers were gonna be more engaged with the design system just because Figma offered that many more features to bring the UI library to the next level in usability. We’ve also experienced we were sort of wrong and sort of correct… Just hopping over to Figma wasn’t a magic spell that would drive up adoption overnight, but we took the opportunity to build up the UI library in Figma from scratch with the help of our subscribers so that it became a collaborative process and shared responsibility across the designers in the design system team and the designers (subscribers) who use the system.
27
1 or 2The tool we primarily use is Figma, our team had proposed to onboard Supernova in the past but the effort didn’t get aligned and buy-in.
28
3–6Figma and GitHub are our primary tools. We are looking into others for tracking and adoption and have recently started to use Tokens Studio with it's Figma plugin and will use Style Dictionary as a transformer in the future.
29
3–6Figma, token studio, gitlab, style dictionary, storybook, zeroheight
30
3–6Figma, storybook, style dictionary as a dev. Success: automation of transformation of tokens in css using style dictionary.
31
3–6Figma, Github, Frontify, etc.

Frontify doesn't have too much specs that allows a smooth edition and sharing updates, so it's a bit annoying.

Figma is really good on updating components and see what's been update or what not.
32
3–6Figma for design work and VS Code with an onslaught of extensions for development. Everything is version controlled either on Github or Gitlab. When building out larger prototypes I'll sometimes use Codekit to create my local environment as it easily compiles assets and allows you to reuse snippets of code with one origin when you need to make a change.
33
3–6Figma, Design Tokens, Style Dictionary, Storybook.

Once we get the tooling to the proper place, I think we envision a big win for color palette seasonality. Where our design and UX teams could push new seasonal color tokens and have an automated visual regression and release of a new palette without the need for developers. That could be a fun success.

We've had wins already in terms of consistency and less duplicative code for values input for the majority of our CSS declarations.

We've recently started using a Storybook extension, addon-designs, that allows us to iframe in our figma documentation that UX builds. So we easily have both design and developer docs available in storybook and published publicly.
34
3–6Figma, Storybook, GitLab, Google Sheets, Gist.

I realized that a UI kit is not a design system and I needed to learn to use VSCode and run storybook locally.

Google sheets is great for tracking components and has helped me get a Birds Eye view of what I need to work on
35
7–10At our company, the DS integration tool zeroheight has been a game-changer, especially when it comes to engaging stakeholders who aren't well-versed in our design or development tools. Its intuitive interface and integration with Figma make it easy for us to keep external teams informed of changes, and we can add notes to documentation and showcase new component releases in only a few minutes (where deploying to a tool like storybook could take whole release cycles depending where it lay in the process). While we're not exclusively tied to zeroheight (we recently have started assessing a few other major players in the space) - the integration tool itself has been monumental and we now have a permanent space for it within our system. It’s the first tool to make our design system's journey visibly accessible to everyone, not just those actively searching for it. This has been a significant win in our design system narrative.
36
3–6Figma + Storybook
Many successes, including designers having an easy avenue to view the “source of truth” for our DS - what lives in code. Previously designers couldn’t tell from viewing live applications what all variants of a component were available, or how they should be used.

Also several failures, including automated syncing of certain values like design tokens and icon assets. We’ve just started to look into options, so I’m excited to hear what y’all have to share on the topic!
37
3–6Figma for published DS Libraries, Asana for Khanbhn process, Slack for DS User Support, we use Slack to automate Asana ticketing
38
3–6I primarily use Figma, and have found it most successful to get people outside of UX/UI into the design stage. I used the principles of design systems to create a scalable accessibility annotation kit that accessibility professionals can use to provide drag and drop components so that people can info on design intent for their prototypes. Using the component properties to indicate what should and shouldn't be modified.

Data reliability is important for those components, and badly created updates made in the library caused consumer complaints due to instance data-loss. However, adding visual regression testing (VRT) in the library update pipeline has provided the library maintains the ability to push changes confidently and reliably.
39
3–6I primarily use figma, chatGPT, Mid Journey, Squarespace. I’ve also used mail chimp before in a previous role. I would say the great thing of mail chimp is you can pretty much figure out how to dissect an existing newsletter template if a previous designer left and didn’t show you around mail chimp and how the organisation uses it for their newsletters. I had to learn on my own.
40
1 or 2Tokens Studio.
Working at a bank, it’s a long process to get 3rd party tools approved for use.
41
3–6Figma (paid), Token Studio (paid), GitHub (paid), Storybook (free), Lit/Stencil (free)
42
3–6Figma, Supernova, GitHub, Storybook.

Success story: A two-designer design system team was able to use Supernova to deliver design tokens to a new Flutter app we were tasked with supporting. Saved tons of time for development team and communication time between disciplines.
43
3–6For us, we probably use one from each category, but I'll focus on the ones that we tend to use the most: Figma, Storybook, and Tailwind. With any design system, the hardest part tends to be keeping everything in sync. Do the components in as they're defined in Figma match up to their implementations in code? Are both the Figma components as well as their code counterparts built-in a way that a change to the design language is applied consistently though the design system? And equally important and overlooked is whether or not the Figma and code implementations are built in a way where the change can applied to both in a similar fashion.

It's not particularly hard to start off strong here, but where it gets a little more nuanced is how do you keep this up over time. The Universe is trends towards entropy. Tight deadlines, late night bug fixes and the like tend to exacerbate this. It's always fun to try to set up processes to assuage this, but usually the answer is better tooling, which is far less glamorous—and arguably tedious.

Do you generate your components from their Figma representations? Do you generate Figma components from code? Do you write linting rules to enforce best practices? Does visual regression testing add more noise than it does value? There is rarely a right answer and everything from the size of your team and organization to the breadth of the design system are important factors to consider.
44
3–6I'm Adobe and Microsoft (mostly) free design team of one. I primarily use Sketch but also use Keynote to produce PDFs, OmniGraffle for general diagrams, and Pixelmator Pro for photo editing.

I also design in HTML/CSS using VS.Code as the tool, or is HTML/CSS the tool?
45
3–6Figma, Tokens Studio, Style Dictionary, Storybook, Notion, Google Sheets.

Success story: Style Dictionary. It allowed us to entirely refactor our tokens, deliver dark mode in a rather short time and do more complex things like generating custom Sketch files.
46
3–6We primarily use Figma, Azure DevOps, Style Dictionary, and Docusaurus to design/develop our design system at the State of Michigan.

One tool that has been both a success and failure has been Docusaurus for our documentation site. It has allowed us to quickly get a site up and running but has lead to some headaches. We are trying to have the documentation site represent what is possible with our design system but have ran into instances where we are forced to utilize the Docusaurus component so we can inherit some specific functionality.
47
3–6Figma, Tokens Studio, Gitlab, Style Dictionary, and Storybook are the ones we use regularly.

Recently, Figma released variables, an excellent capability for design tokens. However, they cap the available themes at four. To unlock even one more theme, the price per seat goes up by $30 monthly. It was a hard sell to convince leadership to make the cost upgrade, so we're stuck at four themes cap despite needing more. We'll have to rely on a third-party dead plugin to change themes.

It makes me weary when the apps you rely on do things like this. It's not a great feeling as a user. It puts pressure on designers to convince stakeholders of the importance of their tools. When you're forced to ask for more upgraded accounts, it can feel really disheartening because the app has now made me feel powerless as a user.


48
3–6Figma success
• Easy migration process from XD, crazy amount of tutorials for everything
• Easy to manage who has access to library
• Easy to push updates

Figma failure
• No native process for working with JSON design tokens if the repo lives in GitHub (there are plug-ins, but some companies cannot use plug-ins)
• Auto layout still confusing or hard to use for some users

GitHub success
• Entire docs website is run from GitHib (11ty skeleton)
• Automatic build links after submitting PRs

GitHub failure
• File type discrepancies make it difficult UX to update docs
49
3–6Figma and Zeroheight are our primary tools. Zeroheight is great for adding content guidance to the system. So many small errors are caught early, since it's a single source of truth.
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