EXT Episode 023 Raw Data

	A	B	C
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 23, deep dive hosted on May 30, 2024 with Ben Callahan and Nathan Curtis. There are 92 answers. The question this week was: ----- Having the word “design” in “design systems” has, perhaps, led to a lot of confusion about what a design system actually is. Last week, our conversation on failure surfaced that one of the major reasons design systems fail is because they aren’t built cross-functionally. In other words, a design system is more than only designer assets, just like it’s more than only coded components. One of the biggest challenges in this work is maintaining parity between the assets a system offers. This week, Nathan and I are considering how necessary it is for design libraries (Figma, Sketch, etc.) and code libraries (React, iOS, Android, etc.) to align. Libraries can differ quite a bit in the details: • What tokens and components they have • How they are named • What features they provide • What props and options they support (and how those are named) • And many more… We’re interested in understanding what you do that leads to that alignment as well as what happens to prevent it. With this as context, here is The Question: Ideally, how much should design and code libraries be aligned? How much do your design and code libraries align? What practices does your design system focus on to ensure designers and developers collaborate effectively to align their library outputs?
2	Question 1: Ideally, how much should design and code libraries be aligned?	Question 2: How much do your design and code libraries align?	Question 3: What practices does your design system focus on to ensure designers and developers collaborate effectively to align their library outputs?
3	Mostly aligned	Mostly aligned	Try to name components and tokens on Figma as they are in Storybook. However, color styles can be overwhelming for designers that dont use tokens daily.
4	Mostly aligned	Mostly aligned	Clear, direct lines of communication and quite a lot of care/manual labour. The idea is that design assets are representative of code assets - not a 1to1 match as there’s no need, unless you’re testing something that would be hugely costly to build.
5	Mostly aligned	Mostly aligned	Where possible, as many human intervention points in the lifecycle of bringing a component or token (etc.) to production. Ideally there’d be more automated synchronisation so that this is more enforced, but we’ve not got to that point yet.
6	Mostly aligned	Somewhat aligned	Developers rely heavily on the specifications files to build the component as is intended. Other than that, we have slack chats and meetings.
7	As perfectly aligned as possible	Mostly aligned	We're have always worked towards parity between the two libraries. Our design library was fairly advanced when we began work on the code library, so last year we worked mostly towards closing that gap, especially since engineers expect the code to match what they see in the designs. What makes this relatively easier for us is having a cross-disciplinary team, including designers, UX engineers, and software engineers, and baked-in approvals from all disciplines to our release process.
8	As perfectly aligned as possible	As perfectly aligned as possible	Context: - code is more flexible than design tools and should be the Source of Truth if possible -different platforms have different capabilities and many token libraries can be partially adopted if correctly built - design is, when possible, ahead of Eng Practices for calaboration include: MANY asynchronous methods of communication (the most common being an slack and linking to Figma) Several touch points in the design and build that are usually aligned to org standards (sprint or kanban) with as much cross-functional knowledge available applied by partners prior to cross-functional touch points.
9	As perfectly aligned as possible	Not aligned	Mostly communication as our design system serves as more of a reference than source of truth, sadly.
10	As perfectly aligned as possible	As perfectly aligned as possible	We call it design conformance, it was the major source of bugs reported in V1 and the beginning of V2, to fix it I developed the conformance framework of touchpoints, it goes like this: 1. Any design change or new design created for the DS, once ready, is delivered in a meeting with the assigned developer and tester, explaining both the UX justification behind it - sometimes based on immediate feedback some changes can happen at the figma level - the changes are not yet componentized. This figma is linked in the Jira issue tracking this change. 2. Once the developer implements it, they come back to the designer and show off that change, especially interactions, designer signs off on it by marking the Jira appropriately. Also if there are any decisions taken during development that impact the design, they need to be signed off on by the designer and the figma updated accordingly. 3. Once it goes to the tester, if any mismatches are found that require designer's clarification, they can affect the design and/or it's sent back to stage 2 with the dev. 4. Once it's past the tester and ready for release, The Jira is set by the tester as release ready and conformance tested. The designer takes the figma and actually releases the changes in the component library. The figma library updates are never too far ahead of the code library. The code library then releases at the end of the sprint. Overall, it can be summarized as the figma and the code evolve hand in hand and are released close to each other with the same version number and release notes. The result is that they're pretty much pixel perfect clones in terms of looks and behaviour. Once we started this, our design conformance issues dropped by 90% In V3 we rarely had any conformance issues at all. -Arko
11	Mostly aligned	Mostly aligned	Our design system aligns 100% when it comes to The tokenization work that we do. Our tokens are automatically extracted from figma variables which makes this an absolute necessity and also a little easier-no alignment means the pipeline doesn't work. When it comes to components, we try to align architecture of the components as much as possible, but it doesn't always make sense given figma limitations or tool specific features so we bend where necessary and try not to stress over it. But the reason why I push so hard for this is because my theory is that it will make education for non-systems designers a bit easier. If a designer can understand how a figma component is constructed and that aligns with how the development component is constructed, then my hope is that they will be able to more easily have conversations with developers when and if they need to affect change on a specific element of their design- even if they have little engineering knowledge. In order to do this, we bake in architecture, alignment and discussions at the top of our component creation process. Once we have a set of requirements recorded for what the component needs to account for, we discuss all the different ways in which we could construct this component to make it atomic and flexible, using layers of abstraction to make sure any future updates are not a hassle. This process is really just based on communication though and leaves a lot of room for small errors
12	As perfectly aligned as possible	As perfectly aligned as possible	My design system exists only as code, so it is perfectly aligned.
13	Mostly aligned	Previously I've had varied success. I am just at the beginning of planning my next one and determining the requirements.	Currently a very small team setting the groundwork for a larger team, so constant communication is key, but also a lot simpler and built into our daily work.
14	As perfectly aligned as possible	Mostly aligned	I think for the most part this is taken care of through multiple checkins between delivery, design, and development.
15	Mostly aligned	Not aligned	Just starting to define / test / build our design system operations formally; creating structure that has a designated facilitator for design and dev to chat about specific alignment need e.g. component, build, etc. Trying this out. At the very least wanting the space to create awareness of the other's build process; but having a common language / framework as to why this conversation is happening, and the facilitator to prevent the convo from slipping into design does this vs dev does this, instead to dive into the why and link it to consistency / user needs (or any shared design / dev goal) has been important and the trickier part.
16	Mostly aligned	Mostly aligned	A definition of "done" for our component development process that includes both a published Figma component and npm package with corresponding React component. There is also cross discipline collaboration involved during a discrete "API Design" step during component development.
17	Mostly aligned	Somewhat aligned	Having a flowchart and getting the management to buy into that. Without doing that, the teams are incentivized to bypass the design sytem and do design system-like behaviors which end up creating yet more code and stray design assets.
18	As perfectly aligned as possible	As perfectly aligned as possible	We closely work together designers and developers during the whole concept process and during development we make sure that our Figma specs and the code match match. We are dedicated design system team which helps with our communication in the team and allows development and design to go hand-in-hand. For us it’s very important that the two align 100%
19	Mostly aligned	Somewhat aligned	I implemented an API-first spec approach in Google Docs, based on Nathan's "Crafting Component API Together" post. It worked for a while, but uncontrollable forces (the company opening up contributions to 600+ engineers) and a lack of communication between design and engineering led to API decisions that were made in a box, resulting in the same mess that was in product shifting from product to the design system.
20	Somewhat aligned	Not aligned	We have style references set up in the code. For react native this is a dot notation such as color.success, or size.padding.lg. For other environments we unused css variables set up in the same manner. Alignment across the board is difficult since we have .net, .jsp, angular 1 & 2+, backbone, and jquery.
21	Mostly aligned	Somewhat aligned	Design was and bug feedback
22	As perfectly aligned as possible	Mostly aligned	We've failed in this regard. Our company culture doesn't prioritize collaboration; it established a hierarchical flow of design -> engineering. Design leadership minimizes any contact between designers and engineers because engineers will get in the way. This has caused massive rework, confusion, and an uncertain future for the product.
23	Somewhat aligned	Somewhat aligned	N/a
24	Mostly aligned	Mostly aligned	The few things we ensure are similar are: 1. Component name (with proper library prefix since we have several libraries) 2. Visual outcome of variants However, since design and code libraries serve (typically) two different audiences —designers vs developers — and these folks have different goals, are design and code libraries are built to serve the goals of the consumer. For designers, we try to ensure the best possible, or most common, variant is the first one inserted. And that all other variants are "good" use cases of the component. But designers typically find a way to alter the component through layer swaps or completely detaching, so we ensure that developers don't get stuck by providing many possible combinations of props and "escape hatches" so that they don't feel they have to create new components. If we tried to keep the code and design libraries in full parity, the design library would become unwieldy and overwhelm designers to make good decisions. Since we're design-led, most of the decisions are being made by designers so we attempt to give them only what they really need and push them towards proper configurations, while keeping the code side as flexible as possible to support product needs.
25	Mostly aligned	Mostly aligned	Core libraries should align as much as possible. This makes sure teams get the efficiency benefit of reusing code and easy translation between design mocks and coded apps. We make sure to build understanding that if you see something in the design lib it will be in the code libs within one sprint. There may be extended design libs for concept or template work that are not built into code, at least not yet. Those could be coded in the future but need flexibility until ready to publish.
26	Mostly aligned	A little aligned	We don’t (yet). There’s a shared UI library and several teams have implemented components in their framework, but nothing on the dev side is shared across the enterprise. Every team does their own framework- and business-specific implementation.
27	Mostly aligned	Somewhat aligned	We focus on doing user journey maps together to understand needs for consumers. In addition we aim to coordinate design work followed by code work in following sprint when possible.
28	As perfectly aligned as possible	As perfectly aligned as possible	Design token stored in a JSON file as the single source of truth and using figma DevMode plugin to support web component code snippets.
29	Mostly aligned	Not aligned	Very little or no support across functions to align
30	As perfectly aligned as possible	I am a freelancer, so it depends on the compant	Having a product oriented mindset for the design system with more or less the same process as implementing new features inside our product. With issues, ticket, backlog, nice to have, must have, ect.
31	Mostly aligned	Somewhat aligned	It’s a big painpoint, but it’s mainly about hand-off tooling such as Zeplin or Figma dev-mode instead of real collaboration.
32	As perfectly aligned as possible	A little aligned	Setup token names
33	Mostly aligned	Somewhat aligned	From a designer's perspective, I'm unsure, other than we try to have the same naming conventions.
34	As perfectly aligned as possible	Mostly aligned	Gated process
35	Mostly aligned	Somewhat aligned	Documentation and design language.
36	As perfectly aligned as possible	Not aligned	we are just starting this process so we are not yet aligned.
37	Mostly aligned	As perfectly aligned as possible	Our component and pattern creation process includes a cross-func kickoff and multiple checkpoints where design, dev, and content stakeholders review work and provide feedback. We also are starting to write a component scope doc in the very beginning to keep us from jumping straight into Figma and “designing” the thing.
38	Mostly aligned	still building	regular review sessions, and the handoff step to ensure alignment
39	As perfectly aligned as possible	Somewhat aligned	Weekly meeting to align the work upfront
40	Mostly aligned	A little aligned	The design system practitioners spent a lot of time advocating for alignment and taking on a lot of the design overhead to ensure that design assets were aligned with code assets. Because of our culture, the code counterparts are always a few steps ahead of the design assets. This made the effort to stay up-to-date monumental, and often, the design asset alignment effort would get deprioritized in favor of other "hot" work.
41	A little aligned	Mostly aligned	Attempting to coordinate early discovery with both design and engineering. Engineering follows suit in naming and uses token values that start in Figma.
42	Mostly aligned	Mostly aligned	Our design system team is cross-functional, and our developers work off a design spec document and create an RFC when composing a new component, so we're both starting from the same foundation. We also encourage reports when folks notice that Figma is not aligned to code, and try to make timely updates there. We're not perfect though - in our experience, Figma has limitations in perfectly mimicking complex components so there are some gaps. Also, this approach has limitations because it makes it hard for us to have WIP in Figma now that our users have come to expect design:dev parity - we end up keeping WIP things in separate (non-library) files
43	Mostly aligned	Mostly aligned	Collaboration, reviews, sync sessions for discussion.
44	Mostly aligned	A little aligned	We use Shape Up for our cycles and do weekly share outs as well as a soon to be added daily coworking sessions.
45	As perfectly aligned as possible	Mostly aligned	I try to overly communicate in every step that we take from discovery all the way through to release of a component. We handle most of our communication via one off calls, scheduled meetings to review work, or message threads. I, a developer, try to ask a lot of questions to the designers to make sure they are following the context of the status of a dev build and if i need something from them i try to be explicit in what im looking to change. When i feel design is not following via messages or even in calls, i will share my screen and start to visually run through my issue. I try to show as little code as possible when speaking directly to designers as i do feel i lose them when i do that.
46	As perfectly aligned as possible	Somewhat aligned	Zero. Zilch. Nada.
47	Somewhat aligned	Somewhat aligned	We align first to platforms, THEN to our own design system for a few reasons: 1. meet customer expectations for apps to look like the platform they choose 2. take advantage of native components vs. re-buliding them ourselves That means for example that our date pickers are very different in iOS and Android, because their native designs are different.
48	Mostly aligned	Somewhat aligned	We have them collaborate together throughout the process starting with research until releases.
49	Mostly aligned	A little aligned	Our current way of working isn't working so we are changing all our components to be out-of-the-box MUI components so that the naming and functionality are the same and so that the development time is less. Hopefully, this will help us collaborate more effectively to align on our outputs.
50	As perfectly aligned as possible	Mostly aligned	We focus on prop alignment for our components across Figma and code to create a shared language for our designers and engineers.
51	Mostly aligned	Mostly aligned	A component level naming convention; Figma assets cross reference to Storybook entries; Simultaneous release in Figma/React; and we want to move towards: versioned Figma libraries, in lockstep with the codebase versions.
52	Mostly aligned	Mostly aligned	Over-communicating of changes/updates, and using consistent language/names. I've occasionally seen the names of things change at a point where concepts really should be solidified, and I think it creates a lot of confusion and undermines the sense of confidence in what direction a task is going, and what is trying to be accomplished. A concept should be defined enough to name it correctly before dev/design collaboration happens (unless the point of the collaboration is to flesh out initial options). I know it sounds trivial, but having a stable name for something means it's at a place where designers and developers can start collaborating on it.
53	Mostly aligned	As perfectly aligned as possible	In the beginning we tried to generate the design assets from code (for Sketch). For some time we aligned simply by working closely together, and of course with a solid set of design tokens. Now there are experiments to generate code from Figma.
54	Mostly aligned	Mostly aligned	The design system team is its own team–DS designers are in constant communication with DS devs. Both sides are cross-functional and familiar with both code and design tools.
55	Mostly aligned	Mostly aligned	- Unified ceremonies - review of each other documentation - shared office hours
56	Mostly aligned	Somewhat aligned	Start by defining requirements and properties together in a document that everyone can find and edit. Keep that documentation fresh throughout component creation and then review design and code together to make sure we're setting up consuming teams to collaborate effectively and speak the same language. Also, simplify where possible on both sides.
57	Mostly aligned	Mostly aligned	During handoff, we integrate Figma designs into Jira tickets and use Dev Mode annotations to relay necessary functionality. As the system evolves, we continually check and update a Data Structure spreadsheet to ensure alignment between design and development. This document contains functionality notes for WordPress components. When updates are made in Figma or WP, the individual contributors are responsible for checking and updating this document. We have a Data Structure doc for the "core" design system as well as each of our client instances. The "core" Data Structure file documents the basic functionality that all clients will receive when they onboard to our system. Client Data Structure docs only contain custom components and functionality for their own instance. If a client requests an update to a basic component and we determine it is necessary for other clients as well, we will add the request to our product backlog as well and make the improvement accessible to everyone in our ecosystem at the next release.
58	Mostly aligned	Somewhat aligned	The practice that makes us struggle the most is Versioning. Our DS is always at the most recent version, while our applications are sometimes behind 2-3 versions. I’m finding little support in winning over people to “we need to version the design assets” to match teams’ realities.
59	Mostly aligned	Somewhat aligned	Not sure yet in my current role (as I am on day 2). Previously, I partnered my designers with an engineer on projects. They were to start talking together and ideating before starting the Discovery phase of their work. They were responsible for presenting their ideas, questions, and final deliverables to the larger group. This was an effective way of working together as it flushed out assumptions and edge cases early on. Benefits of this way of working led to more innovative deliverables, simplified journeys, and faster delivery. Engineering and design were completely aligned but also invested in the ideas from the very beginning.
60	Mostly aligned	Mostly aligned	Co-creation of APIs during component design stage.
61	Mostly aligned	Not aligned	note: please don't use my name or company in conjunction with this answer My current team is very inconsistent. We have a mix of designers who work cross-functionally, conversing with engineering at all stages of a project, and others who don't talk to engineering at all until a dev picks up the work. I'm in the former group and think x-functional collaboration is EXTREMELY important. I create detailed specs and usage guidelines that outline all the component variations and props and run this by eng before I create tickets for them so nothing is missing and we are all in agreement about the approach. On the other end of the spectrum, I have a colleague who doesn't believe engineering should impact design decisions at all and they make new Figma design assets and component adjustments without any consultation. They also don't write guidelines or specs so if the work gets picked up, engineering usually doesn't have enough details to implement. This has created tons of inconsistencies between our design and code libraries as well as confusion from product teams who assume a component is available in code when it is only in design. We also have documentation in different tools (Notion vs github) and ios, android, and web eng often pick up work at different times so when there isn't clear guidance they name things and structure components differently from one another. At my previous company we were very x-functional and we did all our roadmapping, sprints, and governance together. This was really helpful as we were very in sync. We also developed naming conventions so props and tokens were aligned across platforms and function. We shared a documentation site so there was a single source for all guidelines. And we did social things together (happy hour, onsites, hackathons). My current company is working to be more collaborative but it is VERY slow and some folks are reluctant to adjust. Changing culture is tough.
62	As perfectly aligned as possible	Mostly aligned	There are team principles that design components are not released until code component are ready, and vice versa. Design are also involved in the QA process, testing more than just the visual aspects. Engineering are involved in the early design stages to make sure the ideas are possible and informing on the expected on each platform. Design has also been involved in providing Engineers with examples in the engineering documentation, so the examples used in the system docs are similar across all roles.
63	Mostly aligned	Mostly aligned	1. Early dev consultation during discovery or design explorations where we align on the API, accessibility details, and general feasibility. 2. Design QA
64	Mostly aligned	A little aligned	Right now our lack of parity is a core problem. Figma components have been built pre-variables/other features, and not touched for a year+, whereas code components have evolved. We are working to update Figma to be in parity with code to a reasonable extent. A reasonable extent = prop/variant names are the same, colors/spacing are the same. We do not expect every single code prop or option to exist in design. While we believe code, aka the shipped product, "wins," and I don't want designers to waste time building pictures, it's also a handoff issue when engineers are trying to replicate mocks that differ from what the eng see in code/storybook. What "wins" — code or mocks? For many eng, mocks win, because the designer "made design choices". What we should be doing / intend to do in the future, so we don't get out of parity — coordinate changes in design and eng to land at the same time — take advantage of figma features that make it easier to have parity, e.g. variables/theming — have design/eng agree that "if there are differences, what's in code wins unless specced/annotated"; corollary to teach designers to trust that code is 'right' and the mocks don't have to be exact
65	Mostly aligned		Frankly, I am not sure. As a content designer, I don't have visibility into that area. But I'm excited to learn on Thursday!
66	Mostly aligned		This is an interesting question because very often the design system used by the UX teams I have been in are not directly associated with the code libraries the dev teams would use. Discrepancies occur.
67	Mostly aligned	Somewhat aligned	Dev consultations throughout the lifecycle to align on API early in the process, design QA on dev PRs
68	As perfectly aligned as possible	A little aligned	We have the designers review the completed components to verify they follow the designs created in XD. If discrepancies are found then issues are added to the code repository to make the fixes.
69	Mostly aligned	Mostly aligned	Lots of communication, responsible team members and a desire to help each other and develop the system really helps, even if no specific processes are established. Of course, this won't work for large teams, it's impossible to communicate through every change.
70	As perfectly aligned as possible	As perfectly aligned as possible	Communication communication communication! I quiver at the term "hand off" because it implies (and often turns into the practice of) creating a thing and simply leaving it at the doorstep of the next person. We have specific steps in our "process" for designers and engineers to discuss, debate, collaborate, decide, and then codify decisions of every magnitude. We also don't deliver assets to one discipline without a. a paired cross discipline resource, b. explicit clarity as to why its a resource/fix/etc for only one group, or c. a clear, committed plan on when the paired resource will be delivered. If you're working on a "system", it has to be "systematic" and cross disciplinary--otherwise, you're just building a UI kit, or a component library, or a written style guide.
71	As perfectly aligned as possible	As perfectly aligned as possible	Our Ds is small enough for us to have control over this kind of parity (for now). We make sure we are not documenting and publishing components and their respective variations, props, etc. if they are not already available in code. There are exceptions, of course, and for those we ensure that we clearly call out if something is currently ready on the design/Figma side only.
72	As perfectly aligned as possible	Somewhat aligned	Clear documentation, Slack channels, cross-functional audits...
73	Mostly aligned	Mostly aligned	Design tokens (using the token plugin for figma to export seamlessly a json) Shared documentation using storybook Design can be ahead or even offer a lot more components and patterns as long as the principles and architecture are agreed on by the engineers.
74	Mostly aligned	Somewhat aligned	– Strong handoff collaboration, both as a provisional agreement moment and ad-hoc and asynchronously through refining iteration during library production – Involving developers early during exploratory design that establishes models – Involving designers later in not just VQA but also aligning final Figma asset API with the finalizing code API – Strong specs documentation for libraries on other platforms or frameworks produced by teams less / not connected with the design system core team – Audits of existing libraries to prioritize needed parity and alignment
75	As perfectly aligned as possible	Not aligned	None, so far. The design-dev dynamics are different when either of the teams are consulting or are “service providers”. In that scenarios, if processes aren’t set, evaluated and improvised, the design-dev dynamics will be imbalanced creating a design system of broken components. Not to forget, poor documentation of components and context
76	As perfectly aligned as possible	Mostly aligned	The main aspects we include in our process is making sure that the UX and development teams have multiple stops to review and provide feedback for the others' work. The UX team will first design out the components with all necessary documentation, and then the development will follow. Often development feedback will take priority over design feedback, unless the design includes any accessibility requirements.
77	Mostly aligned	Somewhat aligned	We have regular design/tech syncs to ensure Design API and tech are aligned - properties, naming, etc - as much as possible. We try to discuss any intentional misalignments due to restrictions on framework naming, etc that may differ from the most familiar name of a component (e.g., toggle, switch). We try to align our variants in Figma to the properties in Code. As we have separate Android, iOS, and Web tech teams - we find differences in adherence and approach across them. As we've been at it for awhile, we're doing a refreshed audit on properties and APIs, etc to make sure that our libraries are as consistent as possible and if any updated approaches need to be implemented.
78	Mostly aligned	Somewhat aligned	We have a UX Developer on our team who helps to bridge that gap. Things are manageable enough that we can get away with this setup, but if we had to scale to multiple other products/sites, it might break down or require more headcount.
79	Mostly aligned	As a DS consultant, this varies widely with the clients I work with.	Regular working sessions. Dedicated time to align on component architecture and principles above focusing on a single thing. Testing with product teams.
80	As perfectly aligned as possible	Mostly aligned	Discuss naming, even prop naming, during handoffs.
81	Somewhat aligned	Somewhat aligned	1. We're on the same team so this helps in tackling issues and making decision from the same front 2. Try to share access and building connections between our tools as much as possible and what makes sense to the respective teams 3. Trying to align on nomenclature, it doesn't happen as well in practice but we're getting there
82	Mostly aligned	Mostly aligned	A designer will collaborate with developers and spec out a proposal for a component. This proposal includes the component's initial purpose and any additional features. The component in the proposal uses tokens. The developer decides on the best API approach based on the proposal. Props and categories of variants can be mentioned in the spec but there may be better approaches or ideas from the developer. Once the developer has a drafted build, the designer then QAs the component in a dev environment and creates tickets (minor, major, critical) for fixes for the component. After or close to when the engineer releases the component, the designer will create a simplified version of the component in Figma, depending on the complexity of the component. Props aren't necessarily aligned but may be included. The DS designer needs to ask themselves, can a designer quickly find what component variant are looking for?
83	Mostly aligned	Not aligned	Unfortunately, we are not there as a team. My team doesn't have a dedicated engineer so we haven't had a chance to collaborate in this way. Also, there haven't been any updates to our design system in 2 years so we are slowly trying to get back to rebuilding and modernizing our design processes to ensure consistency and efficiency in our projects.
84	As perfectly aligned as possible	Mostly aligned	We have a dedicate team and an engineer dedicated to each platform we support. We maintain a strategy for each library and a PM who plans for parity from design to code by managing our backlog. In engineering, we have an innersource movement that encourages reuse and contributions into the system. We have a ticketing system in place that allows us to track new features or enhancements and make sure the corresponding tickets are generated to maintain parity. Refining the backlog is super important to stay on top of important and relevant work that needs to be done. We build trust by offering what people need, when they need it.
85	Mostly aligned	A little aligned	Communicate early and often, strive for alignment, and document intentional discrepancies so we can easily reference why we’re not aligned in design and code.
86	As perfectly aligned as possible	Mostly aligned	Collaborate early and often in the design process. Designers do desk checks with dev, and also participate in a design QA process prior to formal QA. Also deliver functional and ADA annotations as needed.
87	Mostly aligned	Somewhat aligned	We always write the documentation before coding the component. This ensures the API can be reviewed and compared against the API of the Figma component in isolation while it's still easy to change course.
88	As perfectly aligned as possible	Somewhat aligned	Communication and clear specifications
89	Mostly aligned	Mostly aligned	Up front cross-disciplinary collaboration, working sessions Establishing clear naming conventions Documenting those conventions Exploring automation and tooling Regular cross-disciplinary checkins as part of workflow
90	As perfectly aligned as possible	Mostly aligned	Our team is relatively small so designers and developers work closely when developing or changing existing components. We have weekly meetings to go over designs/implementation details and we use testing to ensure design and dev is in sync. We have yet to expand our design system to other platforms like iOS, Android, etc. I assume once we start including those frameworks we will need to take a closer look at how we intend to keep parity between the different environments and how to communicate this with our users.
91	Somewhat aligned	Mostly aligned	Visual parity alignment and props are important, but depending on the platform and the number of platforms you have, it should always be okay to diverge where it makes sense for the OS or build, especially around naming and even design in some instances (where you want to prioritise native experiences over cross-platform alignment) In our teams, we try to maintain parity alignment as much as possible to make the system usable for product teams. Where it diverges, we have guidance and alternatives. It's definitely not perfect, but maintaining 3 platforms always comes with it's own unique set of challenges.
92	As perfectly aligned as possible	Mostly aligned	Unified Documentation: Maintain a single source of truth with comprehensive and well-organized documentation that is accessible to both designers and developers. This documentation should include guidelines, component usage, design tokens, and code snippets. Component Consistency: Define and enforce consistent naming conventions, properties, and behaviors for components. Both designers and developers should work together to create and maintain a shared component library. Cross-Functional Teams: Form cross-functional teams that include both designers and developers. Regular collaboration and communication between these teams help ensure alignment and understanding of each other’s workflows and constraints. Design Tokens: Use design tokens to store design decisions such as colors, typography, spacing, and other styles in a platform-agnostic way. This helps bridge the gap between design and code, making it easier to update and maintain consistency. Regular Reviews and Feedback Loops: Implement regular review sessions where designers and developers can provide feedback on each other’s work. This helps catch discrepancies early and ensures that both perspectives are considered. Prototyping and Testing: Encourage prototyping and user testing at different stages of the design and development process. This helps identify potential issues and ensures that the final product meets user needs and expectations. Version Control: Use version control systems for both design files and code. This allows for better tracking of changes, easier collaboration, and rollback capabilities if needed. Automated Workflows: Implement automated workflows and tools that integrate design and development processes. For example, use plugins that allow designers to export components directly into the development environment or tools that generate code from design files. Education and Training: Still working on onboarding and training.
93	As perfectly aligned as possible	Somewhat aligned	Rituals that force collab on new components with dev as soon as a rough concept is developed, then synchronization of component development props and structure for both Figma and code. Publish both simultaneously.
94	Somewhat aligned	A little aligned	Reoccurring check-ins and DS reviews. Collaborative demo-focused work (some-what hot-potato process). Shared QA across both design-centric artifacts and code-based components.
95
96
97
98
99
100