EXT Episode 13 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 13, deep dive hosted on March 8, 2024 with Ben Callahan and Ness Grixti. There are 60 answers. The question this week was: ----- Ness and I were chatting about a pattern we’ve both seen emerging in our conversations with other design system practitioners. Maybe this sounds familiar to you? The conversation goes like this: Ben or Ness: Hey—tell me a little more about your design system! DS Practitioner: Sure! I’m really proud of what we’ve accomplished! Our design system team has spent a lot of time on our token naming and structure. Our color system is a little unique, but we have some special cases to account for. We have 50 components so far and they look so good! Ben or Ness: Amazing! How do your subscribing teams feel about the system? DS Practitioner: Well, they aren’t using it just yet… Ben or Ness: [silence] Now, the last thing I want is for anyone to feel overly seen in this scenario. But I’ve had a conversation like this at least four times in the last month. If you are the DS Practitioner in this conversation, you are not alone. When we were discussing this, Ness said she had been there, too. In the opening section of her new book (which you should pick up immediately!), she shared this sentiment: “[After we delivered v1 of the system], I had no conviction that each application [of the components] was the right one for our product…and neither did those who had to use it. As a result, every time someone asked me about a component or pushed back on a design decision…I either had to yield, or get defensive over a decision I didn’t make…” Nobody wants to be in this situation—trying to convince people to use something when you don’t already have their trust. With all of this as context, here is The Question for this week: Do you have a clearly documented process for creating or updating design system components? Do you follow a consistent process when creating or updating a component? If you have a process, share a bit about that process (especially how it’s impacting your system’s adoption). If you don’t, why is that and what would you like it to look like?
2	Question 1: Do you have a clearly documented process for creating or updating design system components?	Question 2: Do you follow a consistent process when creating or updating a component?	Question 3: If you have a process, share a bit about that process (especially how it’s impacting your system’s adoption). If you don’t, why is that and what would you like it to look like?
3	No	No	it is WIP
4	No	No	I would like us to have a process, and have attempted to establish and implement one in the past - but it has only every been poorly or haphazardly implemented, and as the Product Manager, not the Design Lead, this isn't a key responsibility of mine and there's pushback when I try to establish this more formally, and inaction when I've left it to the designers - Catch-22. One of the biggest problems is design system designers seemingly designing components in isolation, without enough attention paid to the likely or anticipated contexts of use; and presenting only the finished thing in isolation (which then actually you find isn't finished, as it's not covered all the edge cases), and not showing the process or decision points; there's also a fear of being too opinionated, and leaving too much up to the implementing designers using or configuring the components in their journeys. When designing an update or improvement to an existing component, designers aren't appreciating that our outputs should be constrained by the bias of only introducing breaking changes to components when absolutely necessary - when I try to bake these considerations into the Jira tickets, they either don't read the detail, or push back at feeling constrained by engineering feasibility/adoption considerations.
5	No	No	Our team was small, so everything came down to personal communication, and not to creating any processes. The process was: “Go to this person and ask if something can be done/changed/created.” We didn't have a ton of changes, so it was usually faster than any process. In any case, not all people were open to discussion, so from time to time during design/code reviews we just had to grumble at each other. Not ideal.
6	Yes	Yes	For creating, there is a research/discovery phase. If the component is specific to one part of the journey we collaborate with the team that owns that portion of the journey. At a certain point we will bring the component in front of a broader group as part of a larger design review and get any additional feedback from other squads before handing off to development.
7	No	No	The team is not aligned the overall design process as the process itself is broken. Therefore, the design system exists at a component library level wherein components are created by individuals needs in the project. I would strongly advice against this practice.
8	Yes	No	We have a clearly documented process that we don't follow. Our most senior designers can add (not remove, thankfully) steps as they see fit. While many times this leads to minor improvements, it has the side effect of severely bloating the timeline per component. Our process is meant to document the "definition of done" for the component creation lifecycle, but those stages are not respected as we could have to jump around depending on how our "top" designers feel about it at any given time. I think critiques are great and should happen, but we would be closer to hitting our deadlines if those critiques were scoped to the stage we were in.
9	We do not have the design system in place and are currently in the planning phases for it	No	We're looking to get information from the industry on what is a best practive for creating this process and how to best apply it.
10	No	Yes	Designers discuss and design the component. We document the specs. We share it with developers for development. We QA it before it is published live.
11	No	No	I don't have much to contribute, but I would love to hear the discussion. My situation may be somewhat unique in that I maintain the design system and can affect changes to the components.
12	Yes	Yes	Our team builds marketing websites for tech companies. We have a core set of components for all clients and customize/build bespoke components as needed for each. Our current team is small, so the process isn't super strict. This is our current documentation... When a new component/customization is requested or needed, follow these steps: 1. Collaborate with team members to determine use cases and viability of the new component.  See if you can leverage/make enhancements to existing components or identify a solution for another client to build from.  2. Wireframe and prototype functionality of the new component. Add comments in Figma to outline your approach/design thinking. Highlight any functionality needed for the new component. Draft a new tab in the client’s Data Structure document. Include all fields necessary. 3. Review both wireframe/prototype and data structure draft with the development team prior to sharing with the client. Once functionality is approved, apply design using existing styles as much as possible. If a new token/style is needed, alert the development team so they can prepare any questions and documentation needed. 4. Share designs with internal stakeholders and developers (schedule a Review Session if needed). Once internal stakeholders have approved, share with the client (schedule a Review Session if needed).  5. Upon client approval, prep your files for handoff (checklist). Be sure to update the Component Library and Data Structure document with final design notes. Add all new color tokens, text styles, or effect styles to the Component Library. Add a description and data structure link to the Component Properties panel. Submit the component for approval or publish the library with a short description of the updates. Alert team members of the new component addition (meet with the larger team to discuss if needed).
13	Yes	Yes	Our system has evolved over the last 5 years, it's crucial to adoption. 1. It starts with a bug report or a feature request in Jira, sometimes a product designer reaches out to us directly, we still insist on the jira to serve as the anchor of the update. 2. The DS team reaches out to the reporting team to understand the context. 3. We try our best to figure out if an existing component or pattern solves the problem. This is a bilateral discussion. 4. If not, then we start brainstorming the feature/component needed to solve it. 5. We reach out to other product teams which might have expressed similar needs/hardships or we know them to work in the same context. This often uncovers synergistic needs, and multiple products buying into it pushes the priority up. 6. We design our solution, validate the design and the variants/properties with the teams in question, make sure it doesn't conflict with any existing bits, then handoff to dev team, standard design/dev/test process follows based on that jira report. 7. We update the documentation to include the new update, then finally launch the Figma and Code library updates. The jira is closed. 8. We demo the new feature/component in the release demo. 9. We keep a higher priority on bug reports on that one for a couple months, to help with teething pains. 10. Ten is a good round number, but otherwise we pat each other's backs and celebrate. Risks - If the system is not mature, it can take a huge amount of time, we have fine tuned it to an art and science and have produced features in 3 weeks flat from request to launch, but the usual turnaround time is around 8 weeks or longer when the priority is low. Also, making sure it doesn't conflict with existing implementation is a major thing, it can throw us for a loop if it comes up too late in the design process.
14	Yes	No	We have a component lifecycle (https://design.gitlab.com/get-started/lifecycle) that I think worked well early on when there were less contributors. As time has gone on, and decisions come from more places, we've become aware that it needs to be revisited. The process is designed so that work can come it at any phase of it, and independently for design and development. That means changes happening that aren't always synced up and questions about what the source of truth is. The process feels a bit removed from adoption, so I don't know the impact. We are working on a related effort to learn about component health, and some of that learning will likely feed back into process revisions.
15	No	No	Thanks Ben for doing this first of all. Building a community is hard and a labor of love. Idea: Pretty much all of the meetings I've been to have been philosophical in nature, which is not bad, there are a lot of beautiful minds in the meets. I wonder though if it might be interesting to the group at large (esp. those newer to DS practice like me) to do more hands-on, tut's/demos time to time for all us visual learners?
16	No	No	We don’t have a clear process because our team struggled a lot with earning trust from our potential users. We launched our system and we’re basically telling everyone to use it and policing every design decision they made that didn’t include the system. This led to people deviating from the system more and more because none of their feedback was heard. In the middle of all this a process drawing was attempted but was ultimately very complex and made sure that every decision was to include the design system team, which you do want ideally, but at the time nobody even trusted the design system team; let alone want to work together. New designers were onboarded to the team and the designers at the time were offboarded recently. The new designers, me included, had a radically different vision on governance and first tried to regain/develop trust with our potential subscribers. And right now were at a stage where we have a design system with a lot of components but not a standardized process for updating them or creating new features/components. Ideally our process involves teams actively reaching out with requests (knowing beforehand what requests would likely be accepted - by knowing the guidelines for requests). From there we would be able to work together on finding the best solutions. Right now though, we’re trying our best to promote collaboration, but we’re mostly gathering all the input ourselves and proving the worth of the system, one component/feature/pattern at a time.
17	Yes	Yes	We used a few different Slack channels to communicate all updates to the design system components. The Engineers were members of the channel, and as soon as they are messaged, they scheduled time to make the updates on their side.
18	Yes	Yes	We HAD to have a process. I'll explain - when we just started out the team was plagued by analysis paralysis and inability to make decisions. They were waiting to release "perfect" components, and as a result released nothing. To address that, we went to design teams and asked them to define what would be the minimum level of component content and quality they'd be ok using. That fed into a DS team workshop where we planned a new process to that lead to "ready to use" components, and allowed the team to be "okay" with releasing, because now they had a checklist of tasks and agreed upon goal to work towards. The process also helped us set expectations with future adopters and ensure they felt comfortable using the components, because they knew the DS met a specific level of quality.
19	Yes	Yes	Just introduced it, so we're still working out the process, but basically it starts with open discussion until moving to a more formal proposal and assignment. More details here: https://designsystem.digital.gov/about/contribute/#suggest-a-new-component-2
20	No	No	Process and documentation has been a struggle internally with the makeup and amount of team members shifting constantly that having a single process (implementation, documentation, etc) is kind of a pipe dream.
21	One team has a pretty clear process but their system is oriented at internal platforms. We don’t have a comprehensive external facing DS yet. Looking forward to learning in support of the larger effort!	One team has a pretty clear process but their system is oriented at internal platforms. We don’t have a comprehensive external facing DS yet. Looking forward to learning in support of the larger effort!	Weekly meeting where individuals bring feature requests and DS team discusses existing components and weighs need for new variant or component.
22	Yes	Yes	Our process begins with discovery and builds discovery in through the whole process. Setting up requirements for a component is fueled by what the community needs through internal audits, stakeholder interviews and external competitor research. We start creating requirements and check that against the rest of our system and our consuming team's needs. When we have the component 80% of the way there, we invite consuming teams in as early adopters to validate what we've made, catch bugs and refine any rough edges. They learn how to use the new component and become experts. We get higher confidence in what we're shipping. That clearly improves adoption because teams are already using the pieces, and because we work through resistance before launch (not totally, but more and more). Not to be too self-promo-y, but I wrote an article about how we made our component creation process and shared the process itself on Medium: https://medium.com/@beauulrey/making-a-system-to-create-a-system-55be9df418b4
23	No	Yes	Much of the process now is how I work with my engineering counterpart. We use the Hot Potato process and have a robust system for QA. Ideally I like to try using the Pattern Canvas -- a workshop facilitation tool when starting a component. The workshop helps get everyone whos on the project started on the right page and it can involve other champions as well. I hope it helps with adoption as it brings awareness to what's being worked on as well as start a small group of champions who had a say in the direction of the component design.
24	No	Yes	We have an MVP process for adding to and updating the design system that has been paused because of organizational prioritization and staffing. This change comes just as we get our product teams to begin using the design system—so our MVP process didn’t get off the ground. In the interim, we have a sort of rogue process for change management that isn’t ideal, with lots of opportunities for misalignment and system misuse-intentionally and accidentally. Not exactly the best foot forward. As the lead for the design system, I’m working to be the best steward and advocate at this time to lay a foundation for when priorities shift back, so we ideally end up with as little debt as possible. Plus, as this is new infrastructure and process for my org, I want to help set expectations and set good examples for how this work is managed (without being too rigid or anyone’s bottleneck). I worry that this sets precedents that will be difficult to walk back, bad habits difficult to break, etc., time will tell.
25	Yes	No	I am not sure if I should go high or deep with this question. On a high level, I have an outside in approach where I document the system that already exists. Look for common patterns that run across multiple processes and that will have the biggest impact. Design a component that will work with the needs of the people using the system. Work with engineering during the entire process to make sure we are thinking big and small enough. Then get the component in the code. This is usually my process when the design system is still getting started. As the system matures, components should also mature and meet more needs becoming more adaptable and specific at the same time.
26	Yes	No	Engineer instructions in how to clone the repo, a good example component as a starting point, how to preview and tests, and what the reviews process looks like. On the design side, it was a little bit looser however ideas came in during design crits and then we could make a 1:1 to discuss finer details.
27	Currently looking for my next role.	Yes	N/A
28	Yes	Yes	We do have weekly calls where we discuss new ideas for new components coming most of the time from our teams. After some workshops where we refine the idea further together with our devs we then move to design and development following a checklist we use to make sure we think of everything when designing a new component or updating an existing one.
29	No	No	We haven't had a process in the past, because we had a team that managed all the DS work, at first, and then no team at all. There's written docs buried in Confluence somewhere but nobody knows about them. One of my goals is to create one! The process for contribution is pretty standard across every DS I've ever seen or worked with. The hard part(s) are: — Does everyone know about it? — Is it too big of a lift? A checklist of things you have to do is great, but if that list is fifteen items long, many product eng/designers won't have/take the time away from their other important work — Are they rewarded for doing that work? Spicy take: I don't think contributions from consuming teams is always as much of a holy grail as we think it is, and it's often too big of an ask to get them to do the level of quality of systems work. What if we were okay with ANY edits as contributions and were able to shore up the quality from there, rather than setting such a high hurdle?
30	No	Yes	The first thing is to talk with product team members, to understand what do they need (not want) and how we can phase that delivery. Then move to benchmarks and the concept itself. We always try to iterate as much as possible while delivering something useful to the users, but not as complex that would make the learning curve too drastic.
31	No	No	Our lack of a process is impacting adoption!
32	No	No	Still new to DS and havnt had the opportunity to work on a design system. Mainly UI kits so far.
33	Yes	Yes	Component updates or new components can be requested through a form. UX and engineering have been trained how to use it, but the design system team often encourages people to fill it out after a conversation on our Support chat in Teams. Component updates and requests are triaged at a standing weekly meeting. The meeting is canceled as necessary. If a component update or request cannot be fulfilled due to our governance guidelines, the requester is notified via email. The product team is encouraged to build a component themselves If the update or request is accepted, we move it into the backlog and prioritize accordingly. The governance process was built two years ago and is documented “publicly”.
34	No	Yes	My answer of "yes" is a soft one. Our design system did not start with a consistent process, but we are getting there. Getting alignment between engineering and design has been itself been an ongoing. With different leaders in design and engineering, shared prioritization has been a challenge. That being said, our process has two entry points: core and community. Core components are meticulously built by the core team. Design provides an initial draft of a component and engineering iterates on that, maintaining a tight feedback loop with design. This is the slower process, and one I liken to discovering a new element in the periodic table- not every new pattern is atomic enough to deserve a place on it. Community is our newer, emerging component process. The core design team serves more as a support team. It is an effort to create a commons where teams can share ideas and consolidate efforts. At this level, speed of delivery is critical. The most important part of this two pronged approach to me is establishing responsibility. Core team is fully responsible for supporting core components. The Community has champions responsible for their contributions. In time, I hope to see the lines between core and community start to blur. I expect community members to offer support for core, and vice versa.
35	No	No	-
36	No	No	I feel like our team is too small, but would love to have a process!
37	I’m on a consuming team, but we don’t have a clearly documented process in the design system docs	I’m on a consuming team. I do believe that they have internal processes that are followed but I’m not sure how consistent it is	I’m on a consuming team, so I’m mostly interested in hearing how others handle this so that I can provide feedback to our design system team
38	Yes	No	We are standing up our system and our process reflects a ton of investigation up front that has to be done for us to fully understand what components we need to build and the best way to do so. The investigation phase involves the DS core design and dev team as well as the subscribing teams so theres visibility of what we expect when they integrate. Once we have alignment on the what, we dive into design where we align on what the component looks like and try to unify the inconsistencies we have today without changing the existing UI too much. From there we build the component in figma and set up its tokens and then it moves to DS development. The DS core dev team takes on the component build and works through their best practices. Sometimes we have to go back to design during this phase if alignment was done properly during investigation, but sometimes its just answering additional interaction questions. Once the component is built and released, the subscribing teams are beginning to integrate. Our initial POC for the design system didnt have this process in place and it meant that the core DS team wasnt aligned, causing a bit of rework. Additional rework was caused by not involving subscribers as we were unaware of some use cases or how to build in a way that would allow for easier adoption. This process is generally working well though it hasnt been executed end to end flawlessly..yet! Each component we create, we have been getting better and we are onboarding more subscribing teams to this process over the next quarter.
39	Yes	Yes	We have detailed guidelines from discovery in the design phase and handoff standards, through engineering discovery and build phases. We also have request forms and guidelines for contribution to the system and collaborate with teams contributing through the entire process.
40	No	No	2024 Year of documentation. I'm actually not sure what it would look like.
41	No	Yes	Our team is doing a redesign at the same time as creating a design system and we are still struggling to get collaboration with IT. But in the design space adoption is excellent at least for our Figma components - even designer that don’t need to use them have started to. We start by “charting” the components that we think we will need based on lo-fi wireframes, to get an estimate of how they might need to build upon each other in atomic order. It’s a rough diagram, but helps us with planning and creating shell cards in Jira. Component go through 3 phases in design - 1. Visual design exploration, 2. building the functional component and variants; creating and/or applying tokens 3. Q.A. = User (a second designer) testing and feedback; Running annotations for Developers. Our process for updating components is a checklist that exists in our component library file where we note issues or additional needs we might come across while using them in page designs, and our PM uses it to create maintenance cards in our backlog.
42	Yes	Yes	I wrote the curriculum for Designing Brand Experiences during my tenure at Cooper Interaction Design. This rigor has influenced full adoption by designers and developers in how the product looks and behaves.
43	Yes	Yes	Backlog of requests that we prioritize based on need, we have a checklist for creating new or updating existing components, work in a Figma branch and create development task for this branch, once developed, we merge the branch and communicate the updates to product teams. The design system is highly adopted by teams already, so we don't need to do stakeholder management to convince teams to use components.
44	No	No	We have a definition of done and other mechanisms like templates and design and code specs but it’s far from consistent or clear. We work fast and slow sometimes. Fast to get a v1 out the door by passing processes to prioritize feedback instead. Or slow and follow our process to the letter often showing us lots of pain points and holes in the process.
45	Yes	No	...
46	No	No	I was hired to work on the DS but inherited one that was built and maintained with federated resources for a long time. This meant inconsistent creation, build and documentation and what ultimately ended up being a system that doesn’t feel very systematic.
47	Yes	No	We have a pretty consistent process for creating new components, although it's more of a framework as each person on the team executes it differently. There is no process for updating components which has led to data loss in Figma when consumers accept update, or sometimes design does not communicated properly to engineering so updates are never made to the coded components. Depending on how you measure adoption, you could argue our process has impacted adoption both positively or negatively. Our slower, in-depth process has helped create a smaller set mature components which are loved, meanwhile many other needs for the system have not yet been made and so teams are remaking items that should be in the system at some point.
48	Yes	Yes	I ran a 2-day FigJam workshop with a past team looking at the design system team's feature workflow (https://medium.com/eightshapes-llc/system-features-step-by-step-e69c90982630). It worked for a while, and eventually was supplanted by engineering wanting to implement a "CDLC". Oof. Josh Clark has perhaps the most practical explanation in his recent blog post around how to handle communication with product team requests: "The design system team should communicate that product teams will have the best results with the design system team if they share new-feature wants and needs in advance. When product teams do annual or quarterly feature roadmapping, they should keep the design system team up to date on anticipated needs for features and components. If it aligns with design system roadmaps and timing, then the design system team can prioritize that work accordingly. If the feature doesn’t fit the plans or capacity of the design system team, then the product team can plan for building it themselves. No surprises." https://bigmedium.com/ideas/design-system-pace-layers-slow-fast.html
49	Content designer, so not privy to that process	Yes	As the content designer: I know there is a process, but I come in to help on documentation once the component has been established.
50	No	Yes	So we’re in the in between stage on my team. We’re in the process of redesigning our design system and as a part of that we’re rethinking all of our team processes. With that we’re experimenting with new ways of working and constantly trying to improve our process to work more effectively. With all of that context. Here is our current process. We start every component build with a design plan. This is a document where we define the work needed for this component. What component are we designing. What problem is this component solving. Who are the users and what impact with this component have. What functionality do we want to support with this component. Ava a few other questions. It’s not about having a solution but trying to fully understand the breadth of this particular component our pattern. Next we use the information we gathered in that design plan to scope and groom this body of work. Then we get into the design process. We have a Figma template that we created that takes you through all of the steps that’s we’ve defined for our process. It includes usage research, accessibility, motion, dev check points, etc. After that we have a spec template that we have specifically created based on what our engineering team needs from us to build a component. We populate that spec and hand it off to engineer. After we hand it off the engineer we then take that component and create the component set in our Figma library.
51	Yes	Yes	As usual, our YES comes w/ some caveats... Our designs were crafted in the context of a Design System Coalition, a recurring session to review the versions of a component inside our company and outside (audit). From there we discussed the requirements needed to accommodate most of the teams' needs and went into design ideation. We had additional changes for feedback, then through accessibility and tech syncs and then ready for build (library and code) and documentation. We have found that process has garnered a lot of support from folks on the design side. Our tech counterparts were not able to achieve that level of engagement and support. They were also pulled into other work, etc. So, we find our enterprise system in a funny place where folks love the designs, weren't getting the code they needed and therefore started to build their own versions of our designs. So....our misalignment has caused some additional splintering of the enterprise system goal.
52	No	Yes	Our design system follows a process that we’ve refined over time, but it isn’t well documented for new folks onboarding to the team. I think our process for building net new components is proven to work, though other aspects of the process like sharing how we came to the released component iteration or providing coaching to help designers adopt the new component confidently are lacking. I think the lack of outward communication and time spent with teams to aid adoption is preventing the design organization from trusting the system and readily adopting our product.
53	No	Yes	On the engineering side, we try to work with designers early in the process as they're doing user testing, gathering information, and drafting initial designs and documentation. That's the ideal, anyway. Once we start coding, we loop back with design and iterate on any technological/interaction issues/questions that come up that we may not have anticipated. Once complete (or if there are questions/concerns during the dev phase), the component is reviewed by a11y engineering. When the component is released, we try to follow up quickly on any issues the early adopters run into through our support channels. None of this is documented, but it's usually the way it plays out.
54	Yes	Yes	-
55	Yes	Yes	Use tokens to create and document components. If you need to break and rebuild, explain why. Pitch to the DS team to see if it needs to be ported to the DS or could/should be a standalone implementation. This speeds up the process of review and lets everybody work in the same way, maintaining consistency and improving speed.
56	Yes	Yes	Every designer on the team contributes to the design system. If there is a new need it’s evaluated to see if it’s a reusable component. The design systems team will do further research on the component, discover use cases from other designers, and then build documentation. New components tend to get an MVP treatment approach & then expand as needed.
57	Yes	No	Our team has a very heavy process for component additions and updates that - unfortunately - very much resembles waterfall. This leads to our team doing a large amount of discovery work ahead of any given component, and similar to what Ness shared, I am not completely convinced that we are actually "discovering" what the user needs. On the engineering front, we lean more towards an MVP model (i.e., get this to the user ASAP so they can tell us what sucks, and we can fix it!), but of course, these two approaches have their own pros and cons and weigh on each other in different ways. While I marked "Yes" for having a clearly documented process, I marked "No" for following it consistently because it feels like we have to break out of the aforementioned discovery process where, IMHO, trying to "know everything" could actually be more limiting to the component build than letting your users give you feedback to iterate on in real-time. I would like to see my team continue continue leaning into the "we know that there are things we don't know" as part of the process, and aim for lighter weight discovery with the goal of delivering value into our users hands ASAP, and iterate from their based on feedback and real metrics rather than conjecture.
58	Yes	Yes	Our design system team utilized Jira to create tickets for components managed by our unfederated team, comprised of both developers and designers. This collaborative effort enabled the creation of centralized Lit components library with the goal of supporting our product verticals cross platforms.
59	No	No	We've never really had the design system take off in a formal manner. It has been a pet project that we try to find time to work on in-between more pressing initiatives with the hope that we can incorporate some system thinking into those prioritized projects. As such, it's basically still the wild west with regard to process.
60	No	Yes	Our component process starts off with reviewing ongoing projects to log new potential components and patterns, track the use, and consider if the component should be contributed into the system (usually once it hits 3 uses). In other circumstances our team decides to refactor a pre-existing component due to design and eng debt. Our System’s team completes a Shallow Dive to create an initial scope of the component, audit current inserts + make note of edge cases. Our system designers proceed with draft 1 mockups of the components. Conversations are also had with stakeholders or the contributors to ensure they are bought-in and considered with our suggested iterations. The Systems team reconsolidates for a Deep Dive, where we proceed to discuss and document scope expansion based on the mockups and conversations. This is where we would vet out architecture, component properties and ensure all can be as closely aligned between Design + Engineering instances. Once the component is fully functional in Figma, we write documentation for usage guidelines and proceed with handoff to Engineering. We also release the component to designers at this time. We communicate the new component through a Slack announcement that is paired with a Loom walkthrough video. We will be beginning Office Hours to share these updates live and demo new components to encourage quicker adoption and iterations from designers during the early phase of the components. Contributions tend to get more adoption than component refactors. I hypothesize that it’s due to the fact that designers are more involved with that process and have an immediate need for the new component. Whereas component refactors require the subscribers to forget what they know about the current component and learn something new.
61	No	No	We are still working to get out our first full version of the design system so we haven't come up with a documented process just yet. My team is discussing this topic in the coming weeks so I'm excited to hear how other teams tackle this process.
62	No	Yes	Looking at the roadmap, we decide what's next. Then that's sent through the design process until released and updated and socialized to the public. (PS I am a bit removed from the process as I am more of a business consultant to the team but that is my understanding.)
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