EXT Episode 006 Raw Data

	A	B
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 006. You can check out the Episode 006 FigJam file, watch Episode 006 on YouTube, or read the Episode 006 Wrap-up Post! Major thanks to zeroheight and Sparkbox for their sponsorship of The Question this week. ----- One of our regulars (Hi, Ness!) has written a great piece explaining how the existing contribution models just don’t sit well with her. In the article, she explains that “a contribution to a design system is a way for those not directly responsible for the system to give back and evolve the system.” She goes on to explain that “this can include any number of things, including but not limited to—components, patterns and guidelines.” With this as our shared understanding of what contribution is, Ness calls out that contributions exist on a spectrum. On one end there are minor contributions which don’t require a lot of work to integrate. On the other end, there are major contributions which often “require a lot more work, including cross-disciplinary changes with multiple touchpoints.” With all of this as context, here is the week’s question: On average, how many major contributions do you receive each month? How might we encourage major contributions in a lean way that doesn’t interfere with the existing product development process? (Be creative—anything goes!)
2	Question 1: On average, how many major contributions do you receive each month?	Question 2: How might we encourage major contributions in a lean way that doesn’t interfere with the existing product development process? (Be creative—anything goes!)
3	Our design system hasn't been accepting contributions for a while - mostly because of the work on our visual refresh. The additional noise while the teams were laser focussed just didn't make sense. We've (Ness) has opened that back up again, but just recently and so the numbers of contributions can't be used to make a clear picture at the moment	Let people do what they need to do. And figure out what impact a contribution will have before picking it up.
4	More than 10	Oh Ben, this is the million dollar question... On my experience this is the best way to make contributions work (although I am not sure is the right way): 1. Dev Contribution: One core design system designer gets temporarily embedded into the scrum team of the dev doing the contribution. They deeply collaborate until the story is done. In terms of technical guidance, the technical lead of the design system will offer support while the story is on going. 2. Design Contribution (controversial!) designers are allowed to be part of the Design System learning group / AIM where they get closer to the system. Once they gain deeper knowledge on the system, their rules and processes, they are ready to do design contributions. I know the start of this process doesn't seem very "lean" but I believe only when they gain that knowledge the can be autonomous enough to be lean. Design and Technical members of DS core group will offer advisory support if needed. Either way, contributions are a struggle... they really are, but they are also amazing to improve adoption...
5	1 or 2	Communicating the value of those major contributions paired up with education on the advantages/impact those changes can have, in a comprehensive piece of documentation and guidelines. By integrating user feedback to validate it before committing significant resources. Break it into smaller manageable chunks that can be gradually integrated into the existing system. Regularly review and discuss the progress of those contributions to address any concerns or challenges early on.
6	1 or 2	Providing contributing teams or members the autonomy and the trust that they understand the topic fully goes a long way. Of course, major contributions will never be as easy to implement as minor contributions but in both autonomy and trust should remain constant. Part of getting contributions efficiently is not getting in the way of the work. Provide the contributors with the space to do what's needed and allow them to reach out when they need it. I've found creating stage gates to hinder the process and often add complexity to the work they are doing outside of the contribution.
7	Between 3 and 5	As our designer does not have a dedicated designer, we heavily rely on contributions from product designers. The head of design is bought in on the importance of the design system, and ensures/has advocated that these contributions are considered during the designers' performance reviews. Conversely, we have never had a major contribution from an engineer outside of the dedicated design system team. These contributions are not recognized by their engineering managers, so taking the time to submit major contributions actually negatively impact their perf. Getting the same buy-in and support from engineering leadership could help better align the goals of individuals with the design system and encourage more contributions from engineers.
8	None	From an engineering perspective our code bar is very high. We would need to write extensive documentation on how to setup and work in our development environment as well as provide as streamlined a process as possible. we're thinking of creating a light weight development experience to contribute to a separate codebase for a "community" version of our components. This way our customers can share with each other in an unofficial (read, not supported) library and we can take the most used from this community edition into our official library.
9	Between 3 and 5	I think it's important for leadership to make contributions a regular practice and create available time for it to happen. We have regular hackathons and migration efforts, and teams are encouraged to contribute back to the system during regular feature work.
10	None	Make sure that design system reviews are part of the product delivery process. That gives the DS team legitimacy to snoop around. Ask people in regular front end guild meetings to demo their new features; follow up after the meeting with questions on how teams can contribute back. Then highlight the contributions in your monthly DS newsletter! TL;DR detect big changes, encourage contributions through celebration.
11	Between 3 and 5	We're actually in the midst of redefining this for our org. We have a contribution model that is perceived as too long and convoluted. We've conducted contribution retros with designers and engineers, and we're planning a co-creation workshop with our users to create a process that works better within their own daily process. It's important to us to create this with them, instead of at them, and also let them understand what goes on behind the scenes and have that context of why things need the time they need.
12	I'm a contributor of content guidance.	From my perspective as a content designer contributing to a design system, get us in early. We can support naming and organization as we help with documentation and create guidance.
13	None	I think the main question is what is the format of the handover. I believe development teams should contribute just as much as they are able to and design systems team has the freedom to polish the work to reach the acceptable quality for them. This can be partial design guideline or component code.
14	None	This is mainly due (hopefully) to our system still being in its infancy. Ideally we communicate, encourage and market contribution requests (major or minor) to the business well enough it becomes part of our process.
15	None	I still think the jury is out on the efficacy of major contributions based on the typical structure/incentives of today's software teams. Sometimes some things are broken because they haven't worked to begin with. I'm not against contribution models per se, but I don't think it's something to dive head-first into. In my experience, the best contributions come less from sharing design/engineering cycles and more around helping the design system team understand customer/business needs, sharing the context for what purpose their request would serve and acting as a stakeholder who provides feedback on proposed solutions. If time permits, even a few explorations of their own to stir the pot could help. But I'd argue the domain knowledge is far and away the most unique and valuable contribution they can make.
16	More than 10	Contributions...whooo boy, do I have some stories. Once upon a time, an org opened up contributions to all of engineering, completely disregarding the system team's feature workflow. Product engineers opened MR's, system engineers merged MR's, UX never got eyes on them...resulting in component API chaos. Over on the design side, product engineers opened up the Figma Tokens tool for designers to create and name tokens at their own whim, again no feature workflow...and design token naming chaos ensued. In a fantastic webinar with Dan Mall, Amy Hupe and Nathan Curtis, a few very relevant quotes can be found: On the topic of quality, Amy says: "Less than perfect isn't the same as unacceptably bad", to which Nathan replies: "...sounds like a leak in quality". On the topic of contributions, Amy states: "...the idea of contribution as a solution to speed", as Nathan quickly adds: "Such a false promise". (ref: https://www.youtube.com/watch?v=IaQcyN66e58&t=2536s) Leadership should be made aware that contributions are not a tool to speed up design systems, and without proper an established feature workflow practice in place, will actually contribute to the downfall of the system, in that the same sins of product will be recreated and redistributed from the system team.
17	1 or 2	In my experience having some dedicated contributors that learn how to contribute major features to the system (and learn what is required to do it) has been proven the best way. For the designers it is hard to have to apply system thinking outside their product and for developers it is hard to deliver the quality of code needed and considering all the accessibility requirements as well as the responsive bahaviors. It takes time but the investment pays dividends later.
18	It depended on the size of the company, team, and scope of work happening.	This is a difficult question for me to answer given that I haven't been on the Design Systems dedicated team for a large company. I have contributed to one and helped build several but I wasn't on that team, if that makes sense. My team contributed a lot of major contributions but within a contract period and we weren't sure how many of them ended up getting implemented. On my smaller company design systems teams, some months we had 1-2 major contributions (especially getting started) where others we had none. This depended on what was being prioritized that quarter.
19	None	Work on turning product development stakeholders into primary users or consumers of the system. Find ways to position the system as a solution for their upcoming business objectives.
20	1 or 2	make a contest of it?
21	Between 3 and 5	- Simplify the process for submitting contributions. Use online forms or dedicated channels within a project management tools. Ensure the submission process is intuitive. - Provide detailed guidelines and documentation on how to make contributions. - Keeping the team informed about upcoming changes and the design system's roadmap. Understanding the big picture might help contributors align their major contributions with the overall strategy of the product.
22	1 or 2	There should be a strict minimum standard for contribution submissions, so that if the submission is accepted into the design system, very little has to be rebuilt. Such as: • making sure that property names in Figma match our guidelines • every style is consuming a design token • accessibility annotations have been created • a link to a coded version in its repo, and live on a site We're looking for anything that can reduce the amount of work needed by the design system team later on. The team who created the submission knows this contribution better than anyone else, so should be the one driving it. This has an additional benefit of that team gaining empathy for how hard it really is to make design system updates.
23	Were still working on V1 of the system so we havent approached this yet - but will when we get there! below is how i would propose we tackle this as a trial	We should allow for short and long term tracks that support product design delivery and major system growth in parallel. When a team wants to make a major contribution, they can involve the system team where we share directional feedback on the best way to execute within in a scoped instance for speed that might also allow for longer term growth & adoption in the system. The product design team that wants to ship something new then becomes unblocked - but its important to note the work cannot stop there. (this is often where i see contributions fail. the narrative is that the product teams are finished once only their goals are reached) At this point, we can learn from the data we get on the thing thats been shipped. This helps to inform the next (more abstract) version of the contribution that can flex to other use cases, making it a better system candidate. The system and product designers would collaborate on this (who takes point can be worked out by capacity/desire) until they reach a consensus for the major contribution with all parties on board. The last step in this process is then re-integration of the system contribution to the product that it originally came from. Overall i see major contributions as a three step process that allows product teams to realize their goals at a speed that works for them, while allow systems teams to vet contributions at a speed that works for them. 1. unblock product design by ensuring high level guardrails are in place to enable the thing to grow at a system level 2. do the necessary work to abstract the thing enough to fit into the system for wider use 3. reintegrate and release
24	1 or 2	Communication will always be key which requires you to engrain yourself in as many movement teams as you can. While I currently act alone in or org's systems role; engineering knows that I am an asset that can be relied upon when their headcount will not suffice. In many cases that comes as a feature request for a particular initiative they are working on. They will ask for my assistance in building out a particular asset (e.g., a chat module for an SMS service) which in turn removes strain from their day to day. All the while allowing me to envelop the component in such a way that it can be reused elsewhere down the road. As a result, I build out our system's offerings all while being the saving grace to many of the ICs that are already strained for time as it is.
25	1 or 2	Our organization is small, but built on being open source. Teams coming in and wanting to contribute is a normal part of how we work. We have intake processes that involve bug reports and places where they can prototype components and features just for their product areas. This allows them space to work and then space for us to catch them where they're at when they're ready for feedback.
26	None	What we are evaluating is to train design advocates that will be responsible for external teams contributions so we can just do a final review and add to our lib.✨
27	1 or 2	1. Not all creating has to happen in DS Office hours or DS channels. We should be able to decentralise 2.Ideation workshops that help solving key business problems outside of the day-day - split into groups. No limits to stick to the DS 3. Recognition & sharing impact of those that did make contributions through the course of a whole year. 4. Temporary working groups to solve common but immediate problems 5. A full DS Sprint dedicated to a DS hackathon - where people can help solve their development problems instead of only outwardly focused business problems.
28	1 or 2	Do those major contributions as part of the product's ongoing tasks. The product team can implement a new component that they need at the moment and put it into the design system. Same time, same effort. And then the design system team can polish the component to make it more generic, but keeping in mind the team needs.
29	6 to 10	In our context, we have a guild that we call the "Ambassadors" of our Design System. The primary objective is not to directly contribute to the libraries served but to assist us in mapping out patterns across the team and coordinating actions and decisions.
30	We dont have a contribution model in place and the team is very protective of new additions	Giving creative freedom, including best practices that are validated with users. Help out with documenting where needed
31	None	We receive only a handful of major contributions a year. We're actually focused on getting more range of contributions to reduce the "barrier to entry", to get folks more engaged in a manageable way for them and us. For the next year, we are hoping to spin up a component registry - where folks can register and share the components/patterns/etc they have made themselves. These potential contributions would then be findable and viewable through a search function - a sort of market place. We can track the usage and determine if it should get elevated to the design system. We're hoping this marketplace encourages more contribution in a variety of ways. It could end in a full contribution of the full component/pattern, or we could see that an added variant is valuable to users and enhance our offerings, etc. This "registry" feels like a way to remove the request portion of contributions (like, having to ask permission). It allows them to make and use and we can evaluate/provide feedback and/or leverage the submission for contribution.
32	1 or 2	A
33	We’ve been in redesign mode and haven’t been accepting contributions at this time.	There has been one successful contribution model that I’ve envisioned but never fully seen implemented. Probably because it doesn’t feel like a contribution model. It’s a tiered design system. There would be the top tier that is the full blown global design system. Then there would be a tier below that that is a product or team level system. These systems leverage components from the global system to build out other components and patterns that are specific to that team and product but not widely used outside of that team or product. Then there would be another tier below that. It would just be like a dump all shared library. A library where any design can put anything. It’s like a shared playground. No guidelines in this tier. Okay so how does this help a contribution model. It takes the pressure off of the design teams to formally contribute to the system. It gives them a structure where they can use the global system, make anything the global system doesn’t yet support for their individual needs and have a shared creative space to experiment with new ideas. The key is for the design systems team to have insight into all of these libraries. There is no need for the DS team to manage these libraries in any way. But having sight into them will allow the systems team to spot consistencies across team libraries that may warrant those components being upgraded into the global system. You will also get the unfiltered creativity in the lowest level library that can also provide great ideas and insights for the system. That’s my take
34	None	It's difficult when the design system is more prescriptive. Since our design system has been introduced as the "standards expert," I think people feel unable to contribute. If we want people to give major contributions to our system, then we would have to find a way to still establish the expertise of the system (to keep leadership buy-in), but lower the barrier to entry for others. (i.e. if project team has done a great job making a pattern they re-use on their specific platform, it would be great if they felt they could show it to our team and see if it's something we want to put in the system.)
35	None	A component creation sprint has worked for my organization in the past. The design system team partners with a product team (or whoever is interested) for a sprint, and we create a component together. This, however, is dependent on the culture of the organization. In my organization, there was an "innovation sprint," the end of the iteration allowed designers and developers to work on innovative ideas (theoretically). So, we used that time to partner with a team and guide them through the process of creating a component. If the org has the structure, or depending on the maturity of the design system, it could scale to a "component champion program" where small teams are spun up to contribute to the design system on a regular cadence. I believe the Airbnb design group did this a few years back. It's lean in a way because it only allows the team two weeks to contribute to the system.
36	None	We're still in early phases of the design system work, so we don't have any formal contribution model. But we're very interested in learning more about what kind of contribution models make the most sense, especially when the product landscape is so varied (platforms, technologies, etc.)
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100