ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Thanks for your interest in The Question!

Sign up to participate in future questions here.

This file is the raw data from Episode 33, deep dive hosted on September 19, 2024 with Ben Callahan and Maya Hampton.

There are 54 answers. The question this week was:

-----

Hello, curious people!

Thank you for taking some time out of your day to share your experience here on The Question. Recently, Maya was sharing a bit about how her current design system team is smaller than in previous years and yet the complexity of the work is growing as larger, more composed experiences become part of her team’s scope. This is a sentiment I’ve heard recently from a few others and was a topic of conversation at Symmetry last month. 

This week, we want to share strategies for doing more with less. Have you been through a reorg? Are you on a design system team of one or two? What has worked for you in seasons where you’ve had fewer people? 

With this as context, let’s dive in!


How many people are dedicated to your design system team?

What is the largest number of people that have been fully dedicated to that same design system team?

In seasons when you’ve had a smaller team, what strategies have worked to accomplish more with less? Be specific!
2
Question 1: How many people are fully dedicated to your design system team?Question 2: What is the largest number of people that have been fully dedicated to that same design system team?Question 3: In seasons when you’ve had a smaller team, what strategies have worked to accomplish more with less? Be specific!
3
00We don't have a design system team. It's just me.
4
01- Scale back design system to have fewer tokens and possibilities
- Focus on updates that align with pod or business goals
- Create processes for engineers and designers to contribute from within their pods
5
00We’ve never had a dedicated design systems team, and it’s been a challenge. We’ve operated by having product designers and product teams pitch in, but that’s been challenging because product goals are different than design system goals.
6
01Trying to make very minor updates over the course of an entire sprint that directly facilitates itself into the work that particular team would be doing anyways.
7
00We are a very small team - total 2 designers. We are very ambitious though :) As a design lead, I’m finding gaps and opportunities to enable my designer make progress. We prioritize items projects that have to be done asap and have an ongoing track for design system. At certain times, that designer is able to dedicate about 70% of his time - which is best we had. When something else comes up we have to refocus.
Ideally I’d love to be able to have this designer working at least at 70% capacity on design system at all time; or in an even better scenario - expand the team by 1-2 more designers.
8
01Being flexible, keeping scope as low as possible, encouraging contribution, staying close to the product teams who have resources and passion to contribute and make things better for everyone.
9
12Getting dev volunteers, leveraging existing work in progress and familiar frameworks, getting brand involved
10
16–10na
11
16–10— Be VERY clear about what work is tied to business-related outcomes, and prioritize that.
— Create and keep a backlog of work that other folks can pick up, and don't be shy about asking for those contributions. Guide people in contributions!
— Track progress and be loud about it. Metrics are great but it's even better to say, "business needed X, we said we'd do Y to support X, here's the progress we've made/what we did and how it helps you."
— Practice your own ruthless prioritization skills. What is "good enough"? What REALLY is important? Why? Why now? What can you live with even though it's not perfect?
12
13–5radical compartmentalization + squeaky wheel advocacy for more support. Its often not pretty TBH.

This has been the space i've been operating in for the past year (and some in the past). I find the difficult part to be not turning into a reactive fire-person rushing to put out every fire. There's obviously an aspect of keeping the lights on, really mixing my metaphors here, but sometimes the lights that are on are the fires that you're fighting i guess.

In the leanest lean times i try to divide my time between the 30k' (proven-value) work that needs done or set up (anticipating what we need next), while carving out specific 3' customer/stakeholder relationship management support.

I try to position myself as an optimistic bridge builder to a more efficient (hopefully near) future, laying ground work so people to trust and want to use the system and work with me. Being very practical about where i can be tactically most effective at the moment but not lost in it. Working on what can i get roughed in to place that will be strategically significant next steps to collaborate on when stakeholders or partners have the capacity. I feel like if you dont have that ready to go you're only positioning your self as a production technician and this erodes the longterm value or vision you want to provide.
13
12N/A
14
13–5Our design system team is currently small, with myself as the only fully dedicated member (I am a designer), supported by a couple of junior developers working part-time.

We’re strategically leveraging our product development workflow, ensuring that designs handed off to developers are built using tokens and atomic components. Figma's Dev Mode then helps developers simply pick the required tokens and implement them.

(Initially, we had dedicated developers who helped establish our token architecture and some basic atomic components in code.)

Our present focus is on achieving 100% token adoption across products while part-time developers continue to build atomic components at a manageable pace.

The progress we’ve made toward token adoption has yielded some meaningful wins. Designers and developers now share a consistent vocabulary (even if only for colour tokens primarily), and we've significantly streamlined our design tokens, reducing our colour palette from roughly 250 to just 18, along with similar reductions in other areas. This level of consistency has been particularly appreciated by developers.

Looking forward, once we reach 100% token adoption, our plan is to quickly ship product-wide style updates in the upcoming quarter—covering typography and colour refinements in both light and dark modes.

This initiative aims to showcase the design system's value to the leadership and secure more dedicated resources in the future.
15
1I don't know, or not applicable to meIdentifying where I can make the most impact in terms of design/dev efficiencies.
16
13–5We prioritize less work during sprint and quarterly planning. We also manage stakeholders' expectations (UX manager and designers) by making it clear that less will be completed.
17
11N/A.

This is a brand new design system "team", and I'm working with the client and a product designer to help scope what we need going forwards.

Tangentially, I've prototyped a Storybook UI component lib for the front-end devs, as they currently have no UI lib at all!
18
11As a lone designer, I have continually shift myself to the highest priority items which is usually driving leads (I get to be on marketing as well).
19
12I don’t know, this was the team at a past job, so I got laid off at the same time that the team shrunk.

I can say that we were utilizing MUI and had been working on customizing it for about 3 years, so there was a good base to work with. I assume they pulled the designer or a dev in as needed to address bugs and new components. I imagine no one is fully allocated to it any more as the company only has 1 designer total, and cut their tech team in half.
20
11I had to craft a roadmap that could be done piecemeal and highly leverage partners across the organization. I kept starting Design System Champions programs to recruit part-timers into the effort and I worked hard to get my priorities on other people's roadmaps. That way I had a legitimate reason to start using other team's time and leadership saw how the design system was intrinsically linked to all of the UI efforts.
21
23–5This is a pertinent question because the lead developer left about two months ago, leaving one full-time and one part-time developer. The designer is pulled between multiple projects.

What we seem to implement is shipping more slowly. We try to automate as much as we can. Some of us wear multiple hats. For example, I'm primarily a developer, but I'm also the accessibility specialist on the team and I try to compensate for not having a content strategist by writing content guidelines and writing documentation.
22
22I’ve seen design system teams do biweekly critiques with product designers and have set open office hours for questions. It worked incredibly well. Product designers were directly contributing to the design system. DS team would adopt features already built and adapt them for the whole. Product designers needed direct feedback for when they broke the system. DS team would offer alternative ways of using the system. I thought it was fantastic and seamless.
23
221) In the past I worked on Federated teams, it made a big difference when I successfully advocated for myself being able to dedicate specific work days to design system work.

2) On my current team (hybrid model with dedicated DS team), it’s really helped to have both the front end engineer and I in the same time zones, especially as much of our company is in CST or EST (we’re in PST, so this often gives us meeting-free afternoons that allow us to collaborate in a very agile way on work in flight.

Leveraging AI in assisting with writing documentation helps me to “do more with less” as well - it can help provide structure and foundation which I then can build upon and add specific context & details to.

Getting the teams using Dev Mode has also been another huge time saver with preparing/updating specs (yay for dynamic annotations!) and communicating component changes cross-team with the ready for dev status updates and view!
24
11–1511–15None. We do less with less.
25
11–15I don't know, or not applicable to meYou have to find ways to scale your expertise and hope your previous cultural training has changed how people work. That way people come to you, rather than having to spend the time going to them. Smaller teams also create the opportunity to get more of the consumers involved to contributing to the system.
26
11–1511–15People working to their expertise and experience rather than their role. Everyone pitching in where they can to help the team advance its goals.
27
21–3021–30We are at the biggest our team has ever been, across functions and at the leadership level. It's likely easier for me to think of the growing pains we've had versus what we did intentionally to be efficient w/ our smaller team - it just was more efficient. But, we're now handling a lot more diverse types of DS work.

I think less people meant fewer ceremonies and more focus time.

We were a little less consensus-driven, so could be more efficient.

Fewer eyes were on us, so we got fewer extraneous requests for decks and changing priorities and swirl.

Our goal was to work design and tech in alignment; however, now that we have iOS, Android, and Web teams - we can't seem to align our roadmaps or releases - so its forced us out of our ideal. We now have different product folks across Native and Web.

It was easier to keep track of the work because there were fewer folks to check in; there was less strategy work and feedback/research, less focus on migration guidance and adoption. We were starting components from scratch, now we're working on new and revisions.
28
3–53–5Internally, we had a laser focus on the highest value deliverables. Saving the most time was priority 1.

Externally, we established trust with other teams by holding open office hours and getting into discussion early and often to provide guidance.
29
3–511–151. Grab partial bandwidth from some designers/devs.
2. Whine to products that we don't have sufficient bandwidth - so they tell leadership.
3. Move the backlog cutoff to higher and higher priorities.
4. Use more AI for documentation.
5. Shift focus from improvement to maintenance.
6. Try to use 3rd party products for DS management (step down from maintaining dedicated portal)

The list might read pessimistic, but what we've found is that there are some minor tweaks and workarounds that can improve output marginally, but there's no accounting for lesser hands on deck. Most measures that let the team survive are to hunker down and focus on not letting the DS die.
30
3–53–5My issue was more that my team size stayed the same (well, I gained one, then that person got placed on another team after a reorg) but the teams around me grew by a lot! We started supporting 20 designers, and that number grew to 80+.

With fewer resources and more work, the #1 strategy is making sure you use your precious resources properly by being in the know about overall company business priorities. This can be accomplished by talking with stakeholders across teams and staying tuned in to executive communications.
Next, you use this knowledge to create a super tight roadmap that aligns with those priorities.

So, it's not that you end up accomplishing more with less per se but that you work on the things that matter most to the largest group of people, and deprioritize or time box things that are less impactful or only affect one or two teams. Creating an impact/effort matrix really helps with determining which items fit that bill.

Then when you're asked to do things, you can bring that matrix and your road map to your conversations to discuss where the new asks its compared to the other things on your team's plate. Stay flexible, and be prepared to reprioritize as needed!

One thing that I learned the hard way, which is a bad strategy, is to try and keep up with doing everything by working evenings and weekends. A: no one is going to praise you for it, and B: I was told I was the victim of my own success. Leadership was under the impression that we could handle the extra work and therefore did not need to hire more design systems designers.
31
3–53–5Having an agile workflow where there is transparency between design and development, and you can see in a birds eye glance at how other people's work intersects with yours, making it easier to delegate and share.
32
3–53–5Agile workflows using kanban boards bring transparency and makes delegation a lot easier
33
3–511–15Funding got reallocated to another department
34
3–53–5Getting ruthless with prioritization. We get really clear on what belongs in our backlog and what doesn't, as well as the timelines that we realistically can tackle something. We've also leaned more on the "Community"/recipe layer of our design system, which prevent our smaller team from being a bottleneck for product teams.
35
3–56–10As the manager of the DS team, I work really hard to defend against having to accomplish more with less. That being said, we are currently only one person smaller (5) than our largest team size (6), so it wouldn't be that drastic of a change.
36
3–511–15Just here to support Maya!
37
3–56–10By asking the development team not to add features to components which 1) have not been designed 2) Finding a solution to a problem we don't have at the moment. Trying to state that an empty container of components will bring maturity to development teams to then start asking and requesting features in components, or designing a federated system so contributions could take place.
38
3–56–10We focused as a team on prioritization. And we aligned our design systems initiatives with product OKRs so that we could integrate design systems work into prioritized tracks of work.

We made a bigger upfront investment in documentation, tokens and patterns to reduce support requests and enable more DIY.

We shifted to more of an advisory capacity for non-prioritized work.
39
3–56–10Instead of building in-house, is there any open source resources we can use.
40
3–53–5When we the team was smaller we had a lot of rush to be honest, but at the same time it felt we were more productive and the decision making process took less time comparing to current situation when we have more people dedicated to DS (I’m talking specifically about designers).
41
3–53–5My team of 3-5 people supported an organization of 48,000 people.

We worked closely together and often blurred lines across disciplines. Developers gave design feedback, designers helped write API docs, and I stretched across people leadership, product leadership, technical leadership, and design leadership both at a high-level and as a hands-on contributor.

I advocated for headcount and budget based on the demand on our small team and made sure we were not committing to anything we couldn't achieve.
42
3–53–5Unfortunately, we've always been a small team (2 designers, 3 developers). We try our best to prioritize all of the many tasks we need to accomplish, but our flow is continuously interrupted by ever-changing priorities passed down from the top. We all work very hard and I am proud of what we've accomplished as such a small team, but I feel that if we just had two more people we could accomplish so much more, and in a shorter time frame.
43
3–53–5We adjusted our product dials. We toned down the dials like documentation, automated QA, or exhaustive featured components. And we focused more on partnering with teams to ship component for upcoming initiatives.
44
6–1011–15A flavor of Single Journey Owners was introduced to the team in an effort to centralize some efforts and decisions.

We focused more on methods of raising our work efforts to higher levels of awareness e.g. everything goes in a JIRA ticket, no matter how “unimportant” it seems.

Less meetings with more focus on team building when we have the ability.

A team of people who want to help one another but expect documentation of why something could not be done as planned, especially when it was due to being over capacity.
45
6–106–10We were trying to establish contributions when possible and also be very strict with prioritizing the tasks to do and work on things that were more important for the team. With less people we were also really thinking more about trying to build less new stuff and really try to focus on reusing as much as possible and also we had to make clear to teams that some stuff they will need to build themselves and we will build it later.
46
6–106–10Collaborating with product design teams to help do audits/discovery and design explorations and with other Eng pods to develop a component partially for us to take it through the finish line.
47
6–106–10Setting clear expectations is key so everyone knows exactly what our bandwidth and priorities are - this way, there’s no wasted effort on things that don’t make an impact.

With product designers, it’s about getting them involved early and often. I make sure they understand how much their input matters at each stage, from ideation to refinement. When they see how their work directly impacts the product, they contribute more frequently and with real purpose, even if the team is small or stretched thin.

And AI - total game changer. I use it to automate repetitive tasks or gather insights faster, freeing up the team to focus on the work that really needs their creativity and expertise.
48
6–106–10Making sure that work is adequately scoped to be reasonable and achievable. Remembering that there is always a future sprint/iteration for other things. Remembering that less is actually more in our world. And to celebrate those incremental wins so they don't get forgotten (or unrealized by leadership).
49
6–1011–15We have actually accomplished less, with less - surprise suprise!

But there is always a need to be very rigorous about 'What is a DS thing' and what is an implementation, which should live outside the system and be built and maintained by others.

Saying 'No' or 'Not us' is very hard, but essential. However, it is admittedly not always possible. One strategy is to say "We agree to do it, but want it noted for the record that this is not as it should be/will be in future (if we have our way) and is us doing you (team X) a solid to help you out for the sake of the overall business."

One thing that has happened (and I don't like this at all) is that quality of scope of DS features is reduced. I am actively combatting this response that some members of the team have.
50
6–106–10• Focus on things that scale rather than trying to fix or polish the inconsequential.
• Documentation is a good way to clone yourself (and the team's decisions). As a bonus, it's also much easier to have documentation take the hit instead of an individual. When you're a small team, having documentation to reference can be much more efficient than trying to use valuable time trying to answer everything. Get in the habit of documenting decisions as you go and be sure to not only include the what, but also the why.
• Lean into what consumers want rather than what you think they need. This is a tough one, but getting them to trust that you understand what they need to effectively do their job is critical in being able to do other things later.
51
6–106–10Picking up less initiatives and ensuring that we finish what we have committed to in 6 month cycles.
52
6–106–10Sorry, not much to share. Don't really have that much success stories. Lowering quality, hoping to have time to get back at things. Finding few good allies outside of the team. Should have focused on less things.
53
I don't know, or not applicable to meI don't know, or not applicable to meN/a
54
I don't know, or not applicable to meI don't know, or not applicable to meAs always, it depends on the org. But in most cases, be open about downsizing as much as possible. While it is a sensitive topic, there's often a sense of guilt and stress when you are part of the team that is left. Being able to address what's changed and how the team is expected to handle that change can take some of the up-front stress off the team. Try to answer the burning question on all of your team's mind: "What are we supposed to do now?"

When more expectations have been added to the team, it's worth taking a look at the other priorities and asking if they are still on the table. Instead of thinking all new requests are on top of what you always used to do, ask yourself if the business' priorities for your team have changed.

Reorgs can give your team leverage to reprioritize work and bring concerns to stakeholders. It's not a bad thing to utilize a reorg for your team's benefit (especially when it has already caused such a negative impact).

Be honest about workload with your stakeholders. Example "Due to the downsizing of our team, our output will be significantly reduced. We would like to review our roadmap and trim it down to the most impactful items for the business and our product teams." From there, I would show the before and after of what the roadmap looked like pre-layoff and what the new proposed roadmap is. If possible, get a couple willing participants from the business side and the product side to give early input to what would be the most impactful from their perspectives.

Dedicated up-front effort to deal with the impact of downsizing goes a long way. Although you may feel anxiety about a pause on "real work" getting done, you shouldn't. Doing the same thing you've always done but faster with less people with more responsibility and anxiety about what's next for you and your team isn't very productive either.
55
More than 30More than 30The team started small and grew, so we haven't had the opposite experience (yet). No matter the size, we are always conscious of how much we can actually take on, and ruthlessly prioritize accordingly.
56
More than 30More than 30When I arrived at US Bank to take over the design system, we were already 30+ between design, dev, content/documenters, and agilists. It was a challenge trying to figure out how to keep everyone busy. While keeping things efficient and simple. I'm still struggling with this.
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