Episode 48 Raw Data

	A	B	C	D	E
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 48, deep dive hosted on March 7, 2025 with Ben Callahan and Carlos Bàez. There are 53 answers. The question this week was: ----- Hello system thinkers! Design systems are biased by the background and expertise of the people who build them. I see this most when a DS program is owned and funded by one discipline. When design leadership funds the design system program it tends to be Figma-heavy in the assets and documentation delivered When engineering pays for the system it tends to be primarily code-based This seems obvious, but without intention in the way we approach the work, our biases creep in and impact our way of thinking. The result is that DS consumers from other disciplines can feel like the system wasn’t really intended for them—this discourages adoption. I’m excited to welcome my friend Carlos as co host! He and his team have been working hard to alleviate discipline bias in their design system work. For their team, that has meant the shift toward using a Product Requirements Document (PRD) as a way of creating alignment between all disciplines. Here’s how he described it: “We work to remove as many waterfall moments in our DS process as possible, and that's by design. Our designers don’t really hand off to engineering, we all work from a shared source of truth—a PRD doc—where we make decisions, resolve open questions, align on behavior and details, and then use matrices to align component properties across our four platforms (iOS, Android, Web, Figma).” This week, we’re going to try to unpack our own biases. We want to know what your real source of truth is as you’re building new design system assets and how that shifts once those assets are in use. With all of this as context, let’s answer The Question! How many “platforms” does your design system provide assets for? (This is a complicated question, but here’s how to think about it: If your design system has a button component, what are all the different assets you offer to use that button in product work? Maybe you have a Figma button component, a React button component, and you offer CSS button classes for the marketing team’s CMS—that would be 3 “platforms” which you provide button assets for.) What is the source of truth for your design system assets while they are being planned and created? What is the source of truth for your design system assets once they have been released and are in use? Do you feel there is some kind of discipline bias baked into your design system assets, documentation, or processes? What has worked for you to prevent bias in your design system asset creation process?
2	Question 1: How many “platforms” does your design system provide assets for? (This is a complicated question, but here’s how to think about it: If your design system has a button component, what are all the different assets you offer to use that button in product work? Maybe you have a Figma button component, a React button component, and you offer CSS button classes for the marketing team’s CMS—that would be 3 “platforms” which you provide button assets for.)	Question 2: What is the source of truth for your design system assets while they are being planned and created?	Question 3: What is the source of truth for your design system assets once they have been released and are in use?	Question 4: Do you feel there is some kind of discipline bias baked into your design system assets, documentation, or processes?	Question 5: What has worked for you to prevent bias in your design system asset creation process?
3	2	Figma only	Both code and Figma (aka there is no real source of truth)	Yes	Still trying to figure that out, but we’re having collaborative sessions to scope the ambitions of design and development for that exact reason. I’d love to learn more about this PRD method!
4		Figma	internal documentation system	n/a	Consciously review edge cases
5	3	Figma is our single source of truth during the design phase and during the implementation phase	At this stage the code becomes the single source of truth	Yes	in order to prevent bias we always made sure to work iteratively together with the developers and the designers and always have both points of views during the design phase as well as the documentation phase as well as the implementation phase
6	More than 5	Figma spec files	Figma Design kit, Guidelines site, Code, Developer Docs	Yes	design has been w/o tech partners at times, so design has been the bias for setting the tone for the system we have try to remediate that w/ our web offering (which started later than native) and have design/prod/tech work through components at same time, leveraging something that sounds similar to the PRD we are trying hard to get our native back in sync, but reality seems to be that design is ahead of dev, making it not as even ownership
7	3	Figma	Storybook	Yes	Early feedback & open dialogue across the two disciplines. If you're the coder implementing something first, and it feels like Design did something unsustainable in Figma... etc. We also encourage designers to familiarize themselves with conventional names in open source DS's and reuse where appropriate.
8	4	We are shifting towards a shared spec/blueprint between design and engineering.	At that point it becomes the respective libraries - Figma and code. Technically it's our documentation (including the specs) but not everyone goes there.	No	Planning our work as one entitiy, across design, UX engineering, software engineering (and content design and a11y). Everything has to be reviewed by all functions.
9	2	All components are named and published in Airtable with description, data, and status columns.	Same place! Airtable. Also provides direct links to Storybooks, Figma, and Confluence pages (or anything else). A long-term plan was to populate the Airtable but serve in a home-grown DSM web page.	No	Responsibility for the design is in the hands of the designer, much like an architect of a building. Engineers collaborate with designers to create what was drawn/spec'd. Therefore, we think of a delta between design intention (Figma) and code execution (React). For instance, if the background of a component is themable in Figma, but must be manually adjusted in code at app layer, that is poor alignment and should be improved. Design is also responsible for communicating to engineering via developer handoff and use of design tokens, which we have automated into a publishing pipeline.
10	4	A mix between visual artifacts in Figma and draft merge requests.	Code.	Yes	To be honest, I think we want a bit of bias. We want our system to be closer to the users and how they experience it, which means code. On the UX and product design side of our system (where I also sit) we've made intentional decisions to shift design closer to code. Since we use our product to build the product, I know that influences these decisions too. Most, if not all designers in the org have some level of coding skills. // Wish I could make it on Friday, but will be traveling. Have a great session!
11	5	Figma	Figma	Yes	We have not implemented anything to prevent bias; our system is very biased. 🙃
12	2	SketchApp	Code/Styleguide	No	In this case, bias is too strong of a word, but there is a viewpoint. Design systems are not real unless they've been implemented. As such, a design system bias is towards the happy path scenarios. When application designers take the design system, they will think about less happy paths, or have their own happy paths. When components are developed, they take on a new path. But this path has to account for all of the situations that the component can be used in and is probably a different viewpoint than the original as conceived.
13	2	Figma and React component	Figma and React component	No	Having the core design system designers and developers sit on the same team.
14	1	It depends. In the context of a component (or component redesign), the source of truth might be a Figma file, or it might be a draft PR. Over the past few years, our team evolved to a place where either might be true.	The code is always the source of truth. When a lack of alignment is noticed between outputs, the debugging would start at code. From there we figure out where the mistake resides. Even if the mistake was made during implementation, the mistake is canonically correct, until it's discovered to be incorrect.	Yes	The team has improved their collaboration over the past couple years. There's a greater recognition that the outputs are a process of collaboration, rather than design playing catch-up, which was more the norm in the early days of the team. Co-creating PRDs or design direction documents, having detailed discussions about APIs have also helped to remove a certain amount of bias.
15	2	Figma	Storybook. Back when we first started, we had a Sketch-based documentation for all the components that was maintained by the design team. We realized no one was really using it, and that Storybook was the real source of truth. The downside of this is that the design team can’t organize or add any documentation to Storybook. No one really owns our Storybook documentation.	Yes	I’m not sure we’ve done a good job with this. I am curious to hear more about these PRD docs.
16	2	Figma	Figma > Storybook	n/a	Not too much so far. This is gonna sound arrogant, but my bias on component UI + IxD as a 30 year HCI vet, has been incredibly difficult to successfully challenge. lol
17	3	It's supposed to be Figma but it's not. There is no good source of truth.	That would probably be our CMS Adobe Experience Manager. We don't have a clear documented space for that.	Yes	We've used what we call a Design Plan to try to do this. It's a new concept but so far it's been great. Basically, it's a document where we break down the functionality, UI, and accessibility that we plan on baking into a component or pattern.
18	4	PRD in Confluence	Docs/Figma/Code	Yes	Consulting and prototyping with engineers during the discovery and development process, and gathering feedback from consumers in the weeks before shipping.
19	3	Figma is where we plan and share. We get visual alignment before we move to production.	Our CMS is the source of truth. This is where we build everything that we publish live.	Yes	I don't think we've landed on a successful process. In my efforts to reach out to other areas to make sure what we build is useful them, I've been unable to get engagement with answering that question. I think I'd have to do a lot of intentional outreach and research to get participation.
20	4	PRD's!	Platform documentation -- sometimes edge cases need to be solve differently across platforms and we use the documentation on each platform to explain those nuances.	Yes	PRD's!
21	4	PRDs.	Zeroheight.	Yes	Comparing component properties across platforms and listing out pros/cons when we see a bias kicking in on one or more platforms.
22	3	A FigJam document created during the discovery phase for a new component is the source of truth for DS designers working in Figma and in code. During the design phase, a Figma "pattern sheet" with design specs is created for developers to follow while first building the component.	If discrepancies our found once a component it released, the whole Design System team, comprised of both designers and devs, will get together to track down the decisions that led to the discrepancy and determine if Figma or code needs to be updated to maintain sync between the two platforms.	No	Our Design System team was built from the start with equal weight given to design and dev. While the current DS team manager has a stronger dev background then a design background, they have worked in both disciplines and work to maintain a balance to prevent bias.
23	4	Figma — but both engineering and design contribute to this asset. I sit with my engineers to groom the assets, figure out edge cases, they often ask questions that I as a designer have not considered. We integrate all of this into the final Figma asset. Then we can successfully write an implementation ticket, having previously agreed on the design and function of the work.	Both Storybook and Figma — Storybook for what's released and available in production, and Figma as a reference and changelog of what enhancements may be coming but have not yet been implemented.	Yes	Definitely communicating early and often with both the people building and consuming the design system. As the only dedicated resource for design system, I don't really have a choice. I can't make my decisions in isolation. I rely on conversations with the wider design team to guide our implementation choices, and I rely on conversations with engineers to cover holes that I can miss as a designer.
24	3	Figma designs are source of truth for things being planned and created.	Once released to production, code is the source of truth as that is what product teams use when they are building their products.	Yes	Our designers tend to lean on the designer persona and our engineers tend to lean on the engineer persona. My job as product manager is to call out these biases and help everyone see and understand all users so we can build our DS in such a way as to serve our broad user base.
25	3	Jira tickets, informal product requirement docs	Doc site, Figma library, code repo	Yes	Having a balanced team. We are short on design capacity now so we’re skewing more towards engineering bias then when we had more designers
26	3	Figma. Our system originates in design libraries.	Storybook, GitHub. The code base is our sot once it’s built.	Yes	Inclusion, making sure the right people are brought to the table, ideally in a planning phase, but sometimes it’s as a result of a retro.
27	3	Mixture of Figma and code as we investigate what's available out of the box from what we use as the base of our system and if it provides everything the product needs.	Code, always the code. That's how it's going to show up to the end user!	Yes	Education and research. There's a lot of swirl in the design system community at my enterprise and while it's gotten better what's really helped is having people who have deep understanding of the products and customer needs being involved with the system. They are responsible to bring proposals and work through feedback to get through a solution. This way it can take the feelings about pixels and who moved them around to getting back to the root of the experience we're creating.
28	2	Figma and FigJam	Code	Yes	Open collaboration between design and engineering.
29	3	Figma	Supernova	No	Collaborative work with Engineering to align on functionality, props, naming across platforms.
30	3	We work similarly to what you described and call it architecture alignment and requirements gathering. the req help to dictate the goal of the component and the asked scope of what it should cover from a product and design POV. the architecture alignment is where we bring product and design req to tech to check what kind of build will make the most sense. maybe theres a reason to have slots in the design vs variants, maybe we are talking about something that should be two components vs one. this is where we high level agree the path to go down when building these can and should always evolve as we learn more and progress with making the assets, but it serves as a thing for us to go back to, making sure when we get in the weeds either as systems people or as design vs dev, we can go back to what was agreed upon for scope and approach.	we have a figma file that is aligned with the component build. for design, figma is that source of truth, but in reality its just a tool they use, not the "truth". if something is not available in figma, but is available in the coded components, code is the truth. we sometimes make options attainable through code but dont surface them in figma bc theyre just workarounds and we wouldnt really recommend them. much of our product execution is design led so if design cant find it, the usage ends up being much lower. for designers who dont use storybook to look things up or who dont know how to inspect code, figma is their truth because they can only use what they know and can see. but it all depends who you ask. the source of truth for our design system assets for our users for example, is whatever ends up showing up in the product. for them thats all they can see, not what we intended, so the output of ds and product collab (however good or bad) is their truth. for a dev who doesnt know about the flexibility we add via some workarounds or who doesnt know how to stretch the code, the out of box component is their truth. who gets the REAL truth? imo, probably those who are most plugged into the DS, and understand it to be an enabler - not an end all be all of what they can do, but a guide for maybe at times what they should do, and what has been solved for at scale. the real source of truth reveals itself to those most equipped with knowledge and drive to find solutions to problems. (sorry this got philosophical, this question caught me in some sort of mood 😂)	Yes	ensure were looking at it from the required angles - EMPATHY in short tbh. if were going so far down a component rabbit hole before dev has been involved, were at risk for bias. if we are only talking to one of our products, another risk for bias. ensuring we design with empathy for those that might use our assets makes us consider if a discipline or area has been left off the convo. increasing transparency of what were working on and our decisions also helps a ton. those who have a vested interest in DS can then opt into more convos if theyre already really busy and they can flag things to us with low effort. absent of any of that, a clear process and checklist of considerations has worked but a lot of the times for us it jsut has felt too process heavy. theres a lot of moving parts to our days and checking boxes for the sake of it can be a time suck, but it helped us at the beginning to work this way while we all got on board with what we need to be covering and why.
31	1	A Testing/ section within the Figma library	Storybook, but ideally SB, Figma, and documentation are all telling the same story.	Yes	Keep pushing for design to be flexible for engineering and vice versa. Consistency in narrative across design, code and docs.
32	2	Figma — we include pre-configured examples, lightweight usage guidance, and design specs via Dev Mode annotations. This is everything our engineers (as well as our consumers) need at that time. We also maintain a status system for each component: in progress, under review, ready for release, ready for use, and deprecated.	Currently: Storybook (implementation guidance) and zeroheight (design guidance) Near future: custom reference site (guidance for all in one place)	No	Being a well balanced, centralized team with no direct ties to a single discipline. Our team consists of members from design, engineering, and QA.
33	3	We do our best to centralize the source of truth in our design system documentation site.	Our doc site. But ultimately its our react code library. We try to keep our doc site always pointing to the latest.	Yes	I've felt like there has to be a bias, or another way of saying it, grounded in some common understanding... what do we agree as a design system community, is ultimately the source of truth?
34	4	Figma, but actively audited by engineering for feasibility	Figma + storybook	Yes	Culture the elements across as many disciplines as possible before baking things in.
35	3	Figma	GitHub/Storybook	Yes	I am half of a recently formed design system team at my company. Previously, the design system was pieced together by a subset of the product designers and engineers with very mixed results. It was clearly started and driven by design, and Figma files are often overbuilt and full of "updates" that haven't actually been committed to code (resulting in dozens of backlogged engineering requests to be done "when there is capacity"). By creating a dedicated team — myself as a product designer and my teammate as a full-stack engineer — with extensive DS experience, we are now working to align design and code and implement a new process where the two sides work in tandem instead of in sequence. Some of that change comes from agreed team norms and process, some comes from using our existing tools and available plugins in a smarter way to cut back on the manual work.
36	4	Figma	Code	Yes	I haven't tried anything in particular because my team in my previous and current org haven't discussed this or thought about it as a whole. 😅
37	5	specs from Figma	Still Figma, because we invested heavily in reaching parity across platforms	n/a	As a PM, I ask my team to empathize with the different types of customers we have to ensure they can collaborate effectively by using the design system. As such, we also need to collaborate closely across all disciplines in our team during the creation process. The responsibility of making decisions about, say, properties and variations in components, can't fall only on the design team. We need engineering input as well to ensure we are anticipating needs on that end as well.
38	3	Figma file	Figma file and Storybook	n/a
39	3	Figma	Figma and our Component Library	Yes	We commonly have conversations where each side of the team discusses their bias about a "thing" and we provide other insight from our background view. For example, our design team is very passionate about how variables and components are created and organized in figma due to how they are used to working. The dev's and many of our consuming teams, however, use those assets differently, so instead of saying one way is right, we have many open conversations to provide insight into each perspective to allow a proposal to be decided upon collectively.
40	2	For simple components, the Figma ideation documents are the source of truth. Occasionally a code spike is done around the same time which own parts of the "truth" for complex pieces.	The design system documentation details the final outcome of decisions taken. If a pattern is particularly complex in code, the design documentation may only detail the pattern at a high level. If any tweaks are made during development, the design documentation and figma components are updated to match.	No	It never crossed my mind that this is a risk, so we've not taken any intentional steps to avoid it. We have two designers and two developers, so perhaps just keeping those roles balanced is sufficient to offset this bias?
41	2	Who will be taking it over once I pass it off and how the team will use it, knowing they usually don’t have a designated design or dev team.	What the data says; which button/page is actually getting the most traffic, if the work flow is manageable for the internal team, if they’re noticing an increase in traffic as a result	Yes	Tough and thoughtful question! I’m not really sure. I have a lot to learn as a designer and business owner still and looking forward to it. Hurdles and all. So looking forward to seeing other designers responses!
42	4	currently a partners Figma design system and their doc site.	Ideally our doc site	Yes	I am probably pretty biased but my guess would be to keep nomenclature and semantics as neutral and as close to code as possible, although you could argue that engineering bias…?
43	3	Figma	Code and documentation site.	Yes	Cross-functional training and working sessions. Educate designers about code and vice-versa. AI has helped lower the barrier for uninitiated designers.
44	3	Figma	Figma and Storybook	n/a
45	4	Design / Figma	Both design and code	Yes	Co-creation of assets and shared understanding of use cases from consumers
46	3	While bring created, the source of truth is Figma.	Once released after being tested, the source of truth is now code.	Yes	We also use PRD, a lot of intentional interviewing and partnering in other disciplines to make sure we are keeping their needs in mind when creating an artifact. Not surprisingly, when leadership supports an OKR for teams around DS adoption, all disciplines are more inclined to reach out for their unmet needs, and less likely to create a divergent artifact, however that also shows that there are opportunities to improve education and even trust in some cases.
47	3	I think this might be a loaded question considering the source of truth is always the code. It's what the user finally sees. Design is often planning the concept and we'd typically like to align but it's not the "truth". Same goes for difference between the blueprint and the house. You can have a plan, but the final thing is the truth.	Code.	Yes	First step is knowing that bias exists. Next step is simplifying the problem and relating it to a legit user need.
48	1	Brand guidelines, UX Design principles and other company related guidelines.	I am not sure.	Yes	Hmm… I guess for me I’d rather not eradicate bias but try to define it more to make it obvious so that we can always check ourselves while we work.
49	More than 5	Figma	In theory Figma, but in practice storybook	Yes	We try to have the engineering and Product work as closely as possible to give real world examples of how components would be used, and what experiances are needed
50	2	The mockups are the source of truth in most cases during development. Sometimes there might be an inconsistency with the design and the system patterns, in which case the system takes precedence.	The developed components are typically the source of truth. Meaning that if there is a change discovered while integrating into product, dev would consult with design and if it is a smaller change design would describe what to do. This would usually align with following existing patterns. The mockup would then be updated after that change has settled. However, larger changes would be designed first.	No	We separated out our design and development documentation into their own sites. This gave a dedicated space for consumers of the system to get the information they needed in the right context. It removed the irrelevant clutter.
51	3	Given that the artifact generates in Figmas first, that is our source of truth.	The component as seen in Storybook becomes the source of truth once in use.	Yes	Peer review from both the design side and development side.
52	4	Figma	We don't have a single source of truth and it has caused lots of problems. We have some assets in a Figma library, but we also have illustrations on an internal website.	Yes	One of the key ways our team works to reduce bias in our design system asset creation process is through collaboration and thorough documentation. When we begin developing a new component, we start with exploratory testing—both within our product and across the industry—to understand best practices and emerging UI/UX trends. This ensures that our components are modern, accessible, and adaptable while maintaining efficiency in execution. A critical part of our component lifecycle is our “Show and Tell” meetings, where we present prototypes to the design team early in the process. This collaborative approach allows designers to provide feedback that helps refine and shape the component before it moves further into development. Additionally, we document our decisions in Product Requirement Documents (PRDs), outlining the component’s purpose, required properties, and test cases. These PRDs serve as a shared source of truth across disciplines, helping to align expectations and reduce misalignment between design, engineering, and product. I should also note that I work with Carlos, the guest speaker, so he will likely discuss our process more deeply.
53	4	PRD	Zeroheight	No	Hands-on collaboration and parallel working across all platforms at the same time to ensure that components are built based on the actual constraints or needs of each platform.
54	5	a PRD	Figma	Yes	Open communication throughout the process between both design and engineering in our Design Systems. One discipline does not own it, but instead for DS to work properly it must be a collaborative and continuing effort.
55	5	Figma specs	DS documentation site and code repos per platform	Yes	Because our DS is managed by the design org, that adds bias. We try to be good partners with close collaboration with platform engineers building the assets (who report to a different org unfortunately). We still have inconsistencies in decision, naming, application when things are built in code. We run audits to try to improve alignment over time.
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