Design Systems Slack “Ask Me Anything,” September 2019

A question and answer session with Jina Anne and Dan Mall.

October 11 2019 at 05:43 AM

Multiple teams using a design system 🔗

Raj Vasikarla said:

How do you deal with multiple teams building their own version of components and avoiding a common set of existing components?

Jina Anne said:

Ah, already with an it depends answer.🙂

I think it’s common/natural to want to consolidate all these efforts. And a lot of the time, that makes sense.

But I’ve found in my experience, sometimes it’s necessary.

Simple Example: A company having a product design system and a marketing design system. In some cases that makes sense, especially if the editorial site needs are vastly different from what the product needs.

A more extreme example, Amazon has like 20 design systems. But that’s because the end user and the features are so different. The fullfillment factory workers using a device to scan boxes uses a very different design system from shopping on their website, versus AWS, versus Twitch, versus Zappos, etc. They might have a global language of type and color on most of the systems, but the component needs are so vastly different.

So for the case that you do want consolidation, I think it’s important to not do this:


In other words, don’t create a new standard and try to force it on everyone else. That never goes well. I think it’s better to get those different teams together and talk about where things might make sense to share, and what things should be prioritized — whether it even makes sense to do so.

Growing a design system team from scratch 🔗

Leslie Yang said:

We recently lost our main designer for design systems and we'd like re-staff this team to 2 roles. We have design tokens and a growing component library that our devs are increasingly contributing to. We're thinking a product designer and engineer experienced in design systems makes sense. We have a brand designer that's looking to step in one of the roles but I wonder about gaps in responsibility and experience. What roles or attributes are must-haves for regrowing this team? Specifically, what qualities should a designer have?

Dan Mall said:

It’s a good call to be sensitive to what skills team members should have! Before I add more, Leslie, what other roles already exist on the team? Or is the team now down to 0 members?

Leslie said:

We’re down to 0 😔

Dan said:

Ah, a tough situation! But there’s hope! I’d say the most crucial skill for the first (or first, again) role on the design system team is not tactical but political. The skill this person needs is to be able to make friends. So much of the success of a design system at an organization depends on how amenable product teams are to the idea of a design system.

If your brand designer is particularly surly, they might have trouble getting anyone to even give the design system the time of day. But if they’re good at building bridges, it’ll more easily expose what the design system needs more urgently than other things. Then, the “making friends” skill comes in handy again to delegate the production tasks for the things that need to be designed and built that the brand designer may not be personally equipped to tackle.

Leslie said:

should I advocate for a product designer in addition to the brand designer and UI engineer? I see design systems as a internal product and I worry a lack of technical understanding when working with product dev teams means some responsibilities falls heavily to other product designers not on the team.

Dan said:

Absolutely! This is from a deck I often share with teams, but this is typically what I’ve recommended for what a design system team ideally looks like. (No surprise: this looks like the structure for any great product team.)

A model design system team

But, no pressure to have this from the start. It’s totally fine to build up to it slowly.

Leslie said:

This is great, thank you!

If you had to choose between a product designer or brand designer joining a systems team, what would you do?

Dan said:

For me, it’s less about the role than it is the person. Which one plays more nicely with others? That’s the one I’d pick for this team 😉

What to do after making patterns 🔗

Tino Bedi said:

Our team is wrapping design system visual patterns, what should we consider next?

Dan said:

Make products! This is really one of the best ways to know for sure that your design system works. The faster you can put the patterns into practice, the more realistic data you’ll get about how well they’re working.

The design system reference site 🔗

Sam Anderson said:

What do you think is the most important part of a successful Design Systems website? We’re doing our 2.0 site now and would love to hear the pitfalls.

Jina said:

Ah and here I ask… do you even need the website? 😉 In all honesty, I think getting the process down to improve people working together should be prioritized over a site. But since you’re on v2, you already have one. In that case, and assuming you already have component docs in place… I think a really good release notes is crucial. If you can indicate what’s added, what’s changed, maybe even show that visually and reference where? That can be one of the most important things for devs, pms, etc to see.

Dan said:

Totally agree with Jina!

If I were to construct a hierarchy of needs for a design system site—hey, blog post idea!—it’d probably go something like this:

  1. Priority 1: what helps a design system user right now?
  2. Priority 2: what helps a design system user in the near future?
  3. Priority 3: what helps a design system user in the longer-term future?


What helps a design system user right now?

How to use the system. Getting started, installing the design system (is it copy and paste or package-managed, etc), stuff like that. Component documentation. Lots of on-the-ground, nitty-gritty, in-the-weeds, other-hyphenated-phrase stuff.

What helps a design system user in the near future?

Knowing what to do next. What if a component doesn’t exist? What if a component kinda exists but needs modification? (This flowchart from the Ubuntu team is awesome). What else can I do with this design system?

what helps a design system user in the longer-term future?

Becoming a better professional. Guidelines are incredibly valuable here. Developers can become better designers by using the design system, and vice versa.

Sam said:

Thanks to you both! Never considered not having one. 🙂 But I think it serves a purpose particularly for external adopters and contributors (we have external vendors who build stuff based on our system).

Editor’s note: our design system for The Cosmopolitan of Las Vegas was created almost exclusively for external vendor use.

Connecting design system teams to product teams 🔗

Michael Yom said:

What are some processes and/or tools to help product teams' designers connect with the design systems team? The design systems team could hover over every project, but we lack the capacity to have total awareness and we'd like to promote product teams to take initiative—particularly because we're at the early stage where the component library is being built.

Jina said:

Well, I think looking at the design system as a shared ownership rather than a DS team “hovering” is the first thing. team models are different, but it sounds like you have both a centralized team and product designers. Here is an article about how we handled that at Salesforce, which is based off the models Nathan Curtis wrote on.

Michael said:

Great point! I think we need to do a better job of advocating and communicating shared ownership. Thanks for the resources 👍🏼

Shared naming conventions 🔗

Ulises Siriczman said:

Do you use the same naming convention for elements as developers? I mean like BEM (block, element, modifier) or something similar. If you don’t, why not?

Jina said:

I definitely try to! Though I’ve been in a large organization where that was very difficult, so we explored a taxonomy that had “aliases” which could help our doc search. 🙂

Splitting time between product and system 🔗

Tiffany C Yu said:

What are the most important things to focus in the design system if you're a solo designer early in their career with little experience in design system? The relationship I should build with the front-end engineers and how much of a collaborative effort it should be, how to maintain while doing product design work, etc.

I'm part of a small startup where there are about 2-3 front-end devs and 9 engineers in total working on the product.

  1. Could you expand on how I should go about splitting product design work and design system maintenance? So far, I've done 4 days of product design work and 1 day for revisions for product design work and design system.
  2. It seems to me that it's always good to work on the engineer who is building it but often at a small startup that doesn't happen. Would this mean I need to evangelize the collaborative effort more and set time for it?
Dan said:

how I should go about splitting product design work and design system maintenance? So far, I’ve done 4 days of product design work and 1 day for revisions for product design work and design system.

That sounds like the right split to me. Design systems are about making better products, so a 80/20 product-to-system proportion seems appropriate. (The Pareto principle wins again!)

It seems to me that it’s always good to work on the engineer who is building it but often at a small startup that doesn’t happen. Would this mean I need to evangelize the collaborative effort more and set time for it?

Yes and yes! If you need some tips, Brad Frost and I made a video about why the designer-developer collaboration is important. We also talked about it with Aarron Walter and Eli Woolery on the Design Better podcast.

Contributing to design systems 🔗

Tino Bedi said:

Our team is 150+ engineering and we’re seeking process for others to contribute or implement to the system. Any resource you would recommend?

Rachel Sadres said:

adding to this, any tips for incentivizing contributors? How do I make it appealing for engineers across the company to contribute rather than wait for the 2 systems Engs to eventually do it for them?

Jina said:

I would definitely try to make contribution accessible to designers. If it’s all in a react codebase, that can be tricky. So maybe have some docs pull from a Quip or Google Docs folder. I’ve seen folks use APIs to pull this stuff in. Or if you’re using something like InVision DSM that has a style guide generated, you can pull things in from there.

On incentivizing — crediting contributors is probably the easiest thing. They can then show their managers how much they’ve contributed.

A silly thing but seems to work, when it comes to incentivizing contributors. If you have a team all hands meeting, you can shout out top contributors. Maybe even give them some fun trinket or gift card.

If you have the bandwidth and some sort of internal employee dashboard, you can add a leaderboard. I know, gamification is cliche. But you’d be surprised how much this can motivate folks.

Dan said:

I love the team model examples that Jina and Nathan Curtis have written about and continue to point back to them:

The Federated and Cyclical models resemble pieces of something a lot of us are more familiar with: an Open-Source model. If you think about how a product like WordPress is managed between Automattic employees, WordPress core members that don’t work and Automattic, infrequent contributors, and the masses that use WordPress but never contribute to it (and likely never will), there are some really good parallels to how a design system grows (or doesn’t).

Thinking about it that way, I love the guides that exist at Open Source Guides, especially the ones about Starting an Open Source Project and Building Welcoming Communities.

Component documentation and responsibility 🔗

Penelope Singer said:

What should design/UX be documenting in terms of accessibility for individual components, and what should be left to dev or other areas to determine?

Jina said:

I would never consider anything in accessibility to “be left to dev.” i think anything and everything you can do from the design/ux perspective can and should be done, and then in every step of the process as it gets into production. it should be a shared ownership.

Dan said:

Not sure if this was intentional, Penelope, but the way you phrased your question made me wonder if your frame of reference is that the designers/UXers job is one of documentation. I believe it’s everyone’s job to document. We all have different experiences and expertise in our heads, and one of the great promises of a design system is to extract and collect that expertise in one place so it can be better distributed. So, designers can document what they know about accessibility (typically things like color contrast, type sizing, etc) while developers can document what they know about accessibility (typically code-related things like how to properly use aria- attributes and manage focus states). Accessibility specifically is something that many disciplines can equivalently contribute to!

Penelope said:

I agree that it’s got to be a shared responsibility. My challenge (and why I asked this question) is that accessibility wasn’t baked into our culture—though it is growing—so it’s often a matter of it either being overlooked, added on, or having to be retrofitted. When I started here, I began championing accessibility, and as a result, I am often viewed as the expert and expected to know it all, but also expected to not “tell people how to do their jobs.” So I guess I’m really looking for guidance on how to get all the teams on the same page, speaking the same language, and I was hoping to use the design system we’re building to start that.

Dan said:

I’m really looking for guidance on how to get all the teams on the same page, speaking the same language, and I was hoping to use the design system we’re building to start that.

Ah, gotcha! Thanks for sharing that context, Penelope. (Warning: I’m gonna get all quote-y here.)

The Salesforce team (I think?) shared the mantra, “Make the right thing to do the easiest thing to do.” And I’m a big fan of the George S. Patton quote, “Don’t tell people how to do things. Tell them what to do and let them surprise you with their results.” So, to your comment…

When I started here, I began championing accessibility, and as a result, I am often viewed as the expert and expected to know it all, but also expected to not “tell people how to do their jobs”

…perhaps the role you might play is to tell a developer (either in a conversation or through documentation) that, for example, when a page changes state, anyone using the page should know what changed. That leaves some room for a developer to explore focus management, aria- attributes, etc. I know there might be right-er and wrong-er approaches to this, but perhaps let the developer discover that in their journey to the solution, even if you know the “right” answer. Then, encourage that developer to document their solution so that others can benefit from it. I think that kind of inclusive design process builds ownership in people and motivates them to be more involved and invite others into a welcoming space too.

Working with remote teams 🔗

Penelope Singer said:

What if a portion of the dev teams are contractors and also remotely located? How would you approach the ownership aspect differently, or does it really matter?

Dan said:

I think the ownership model still applies, though the dynamic of executing it might change a little. Sometimes, remote team members are only physically distant but mentally engaged and invested. Other times, remote team members are both physically and mentally distant. Mandy Brown has a really great article for making remote teams work.

What’s next for design system teams 🔗

Matt Walker said:

Given your experience working with lots of different teams, answering questions, giving talks. What do you believe is an aspect of systems work that design systems teams aren’t thinking about at all or enough about yet?

Jina said:

I think people get fixated on the style guide website. The website you create is not your design system. It’s a representation of your design system. So i’d rather see folks get their processes and methods right. The site is just one part of that. remembering that it’s not about the artifact (though it’s nice to have one to rally around) but about the people and how they work together.

Dan said:

I wish designers were thinking more about what else they could help with organizationally if they weren’t bogged down with the details of design components. I think designers’ thoughts and approaches are more valuable than the pixels they push, and it bums me out to think about all the things designers haven’t done because they’re too busy designing a table for the 800th time in their career.

Like Josh Clark says, “The most exciting design systems are boring.” If designers could quickly get through the boring stuff, put it in a design system once and for all, imagine all the good they might do with the newly found free time!

Where do UX guidelines belong in a design system 🔗

Donna Vitan said:

Where do you share (if at all) the overall content architecture/writing and UX playbook type guidelines that help provide structure and definition to creating user experiences that are not component specific?

Design systems focus on the artefacts and component library, but there's so much more to designing a single page view or user flows. Aside from page templates, you still need to provide guidance on the content.

Jina said:

I would suggest that when you say “Design systems focus on the artefacts and component library,” it’s not that design systems do that. it’s the practitioners. i mentioned this in another question, but the website (and ui kits and other artifacts) are only a representation. so when you say “but there's so much more to designing a single page view or user flows. Aside from page templates, you still need to provide guidance on the content.” i totally agree with you. if you do have a website, you can certainly include these. But the information architecture can get tricky. I like how Material has clear guidelines around navigation patterns or when to use a notification with the anatomy, behaviors, usage, etc.

Dan said:

Design systems focus on the artefacts and component library, but there’s so much more to designing a single page view or user flows. Aside from page templates, you still need to provide guidance on the content.

That’s right! Design systems ultimately exist to help teams make better products, so guidance about UX and content is certainly not out-of-bounds.

Polaris navigation

Jina’s right that it becomes a taxonomy challenge. I love the way that Polaris deals with this by calling Content out right up front, and first. That’s a heck of a line in the sand they’re drawing about what they believe is important to the product experience.

Should startups have design systems? 🔗

Krista McDonald said:

Do you think that setting aside or hiring dev resources to create a design system for a start up that's in a high growth stage has value? I am struggling to be more nimble in our design/dev processes. I feel like that having a common design system between design and dev with a common component library could be the answer. But I'm having trouble rationalizing the amount of work against large business opportunities that are coming up. Any tips or advice?

Jina said:

this is another “it depends” answer — as in what all are you thinking about when you say “a design system”? i don’t think you need to hire them to build a beautiful, gorgeous website on par with lightning or material or carbon. especially if you’re in a growth stage. but i certainly think there’s no time that’s too early to think about your design and UI engineering in a systemic way. you can build as you go, when the need arises (not creating just to create but only adding to the system when there is a need). in that case, i argue it’s not a lot of extra work because it’s work you’re already doing to build the product. 🙂

Dan said:

I’ll be more hard-lined on this. (Jina’s always so nice 😉 )

Do you think that setting aside or hiring dev resources to create a design system for a start up that’s in a high growth stage has value?

No. Build products. A design system is both an optimization and an investment, neither of which a typical startup has in excess. Any good engineer knows that too much pre-optimization is a waste of time. And when I talk about investment, I mean “a short-term loss to get a long-term gain.” Short-terms gains are more important to most startups than long-term gains, especially at early stages. Build products that your customers can use, find market fit fast, hone your value proposition. Then you can make a design system as you start to stabilize.

KPIs for design systems 🔗

Tino Bedi said:

I struggle with setting good KPI’s, any suggestions which kpi’s we could measure as we roll out our very first design system that we could share with org, engineers, teams and or leadership?

Jina said:

so a lot of people might jump into talking about tracking lines of code deleted, colors consolidated, performance benefits — and all those are good and you should track. but i get really interested in the team communication part, and how the metrics you’re tracking align with your principles. I wrote about that a little bit [on Playbook].

Dan said:

The most talked about benefits of design systems tend to be around more efficiency and better consistency, so the surface level KPIs I’ve seen tend to center around those. Things like (all of these compare before having a design system to after having one):


  • Speed to market
  • QA time
  • Github issues
  • Bugs filed


  • CSS redundacy via tools like CSS Stats
  • Customer complaints

There are also more great articles that people are writing about this topic.

Where I think it gets really interesting is when you think about your specific organization’s KPIs. For example, if you work for a healthcare company, you might tie your design system efforts to a larger company-wide effort to, say, book more doctor’s appointments or book doctor’s appointments in less time or less clicks. That’s the stuff that gets me excited.

Snowflake components 🔗

Donna Vitan said:

How do you track and measure, re-evaluate snowflake components that were built by contributors that originally don’t meet the robust requirements of being a core component? When is the right time to re-visit, improve, or deprecate?

Jina said:

so one of my mantras is that not everything has to be in the system, and not everything has to be from the system. it’s totally okay to have special snowflakes. but they don’t need to be in the system. now if you’re in a situation where it already went in, then depending on your situation it might be trivial — or not to remove it. at salesforce, it definitely was not easy because we had an open source framework that like a gazillion third party devs were using. so we had to have a deprecation strategy. we created a tool called Sass-Deprecate to help with this, but even still, it’s hard. It takes lots of support and coordination. However, if you’re not open source to a huge community like we were, and you have control over where it’s being used, then hopefully it’s a lot easier to remove it from the design system (but keep it in the product if it’s needed). 🙂

Design systems for agencies 🔗

Jordan Frank said:

I am working on pioneering design systems for an consulting agency that I work for. This has meant 1-1s with principles and giving lunch and learn talks to give awareness to the company and gain feedback on how we can implement design systems into our company. Our clients are normally in the field of B2B and most products that we ship are dashboards.

What are the pitfalls that we should look out for when creating a “micro” design system, duplicating that when we get a new project and using it as a foundation for the clients deign system?

Jina said:

i’m brand new to the consulting world so i should let dan take this one. but my initial gut answer if you’re trying to use a system for all your clients is to consider having a “skeleton” system of just your bare bones parts to pick and choose from for each client, with just the required structural, interactive bits to make it usable/accessible, with nothing in there that’s opinionated (art directed). then tailor that to your clients through design tokens and additional css to extend on it? curious to see if dan has a different answer!

Dan said:

Totally with Jina here (no surprise)! I think it’s useful to distinguish a boilerplate from a design system. There’s certainly good overlap between the two, but they are separate.

An important question I’ve seen many agencies face is whether or not they want to be known for a “house style.” Some agencies pride themselves on doing unique things for each client; others agencies relish doing the same kind of word repeatedly to gain efficiencies. An agency design system wouldn’t really be that useful in the former scenario, but it’d be incredibly valuable in the latter.

I love Dave Rupert’s thoughts on this. Rather than having one agency-wide monolith of a design system that you use on every project, use the same amount of effort to delivery “tiny bootstraps for every client.”

Getting buy-in 🔗

Andrew Cianci said:

We have buy in from EVERYONE at the company except for the CEO, who says that we’re still too small for a Design System (series A, 35 employees), but the product and website are becoming more and more fractured and distant in their presentation and the dev-led design that started with this company is really starting to get stale. How do you get C-Level buy-in? is it just a case of completing a UI inventory and setting up an MVP on our own time to show how much quicker devs and designers can iterate with it in place?

Dan said:

How do you get C-Level buy-in? is it just a case of completing a UI inventory and setting up an MVP on our own time to show how much quicker devs and designers can iterate with it in place?

In order to get someone to listen, you have to speak their language. Interface inventories and higher quality iteration is the language that designers and developers speak. The language that C-level folks speak—and please forgive the overgeneralization—is money. Show them how not having a design system means the organization is hemorrhaging money or wasting resources. Show them how that MVP you made on your own time can save them money, especially when it happens at scale.

One of my favorite examples of literally showing the pain is when Brent Hardinge printed out thumbnails of every website made by hand, put them on mounting boards, and walked into an executive meeting. That really drove the point home.

Also, Josh Clark, Brad Frost, and I talked a bit more about selling design systems to the C-suite in our Design System video series.

Jina said:

Another answer: go rogue. 😉

Outreach and materials for design systems 🔗

Stephanie Eckles said:

What types of outreach materials and support offerings have you found to be successful for an enterprise with a variety of products and stakeholders? Things like ways to communicate updates, or present the visual materials, or to offer trainings and workshops, or other methods? Basically - how do you keep the system top of mind, and offer “hooks” to keep fragmented teams looking to the DS team for guidance? (Sorry, that kind of ended up being two related questions, thanks!)

Jina said:

as many as you can humanly do! i’ve done office hours, advisory boards (with folks represented across different disciplines or features or products) and documenting what’s discussed and distributing, brown bags/workshops, documentation, email/slack/whatever other internal messaging tool updates, definitely release notes… at salesforce i even worked on a dashboard design that showed a very visual diff (token diffs, html diffs, css diffs)… we even made a chrome extension for our engineers to show a “grade” on implementation…

i’ve seen some even do a newsletter. some of the design systems teams at amazon did. i think shopify’s polaris does too.

and one team at amazon even did a video of “what’s new”. those were fun to watch

VR & AR in design systems 🔗

Jina said:

ooh i’ll ask Dan a question. 😀 have you explored other less-discussed areas of design systems yet like voice UI or AR/VR? if not, do you have interest in doing so?

Dan said:

have you explored other less-discussed areas of design systems yet like voice UI or AR/VR?

SuperFriendly’s pitched it a few times, but so far, no client has taken us up on it yet 😉 . (Most of them have answered something to the effect of, “Let us at least get all of our buttons in order first and then we can talk.“)

if not, do you have interest in doing so?

For sure! I think there’s a lot of ripe area here, especially as a lot of voice interfaces are improving from better machine learning. Not only can products get better by incorporating voice interfaces and AR, but AR can also improve the collaboration process. Airbnb opened the door with their whiteboard-to-code demos, and I think AR + AI + Machine Learning can help us turn this into a more explorative state.

Now, to find a client that’s willing to try it out. Minority Report, here we come!

One framework or multiple? 🔗

Daniel Miller said:

For mid-sized organizations with multiple frontend web development teams and a fledgling design system, do you think the flexibility of allowing teams to choose their own preferred web component framework ever outweighs the benefits of standardizing around one?

Jina said:

i’m a big fan of agnostic design systems work, personally. especially with frameworks coming and going all the time. but there are pros and cons to that, as you’ve implied in your question. it is easier to just deal with one framework. so if you’re starting from scratch, by all means do that. but if you have existing products in existing frameworks, it may not be worth the effort to consolidate. unless you can make a really good business case for it, keep things agnostic. design tokens are one small piece that can certainly help with that.

Dan said:

I think it depends what your organizational priorities are, and what types of technical debt tolerance the organization has. Generally, I’m a fan of how Brad Frost describes managing tech-agnostic design systems.

Totally agree with Jina that one framework is easier. But sometimes the path to getting to one framework is too steep and is worth the technical debt and variance that an agnostic system with different flavors can bring.

Systematizing animations 🔗

Josh Compton said:

How do you systematize animations? *Bonus points for transitions between glyphs in your icon system?

Donna Vitan said:

Also, what’s your definition of reduced-motion?

Jina said:

full disclosure, i’ve not worked on this, but rather with people who have worked on this. putting things into a vocabulary like “pop, duration instantly” is easier to discuss across design/engineering than getting into the milliseconds, especially if you have various platforms. i’ve seen design tokens help with this. but most orgs i’ve worked with have also worked alongside a library like lottie. i wish i had better answers for this. val head and sarah drasner are the experts on this for sure. 😜

hmm. as for the reduced motion question, my intuition says if they’re turning it off, they don’t want motion… so i’d probably have no motion at all if possible for that scendario

Dan said:

The way my teams have done it is similar: establish a set of presets that can be modified when applied. I like how the Carbon Design System team explains it. They have 2 styles of motion: productive and expressive, and they’re applied as parameters to a motion method: motion(entrance, productive).

If I could get animation philosophize-y here, there’s something… dissonant… about the idea of “systematizing animations.” Animation (especially as compared to “motion”) is about “bringing something to life,” and “systematizing” and “bringing something to life” feel at odds a lot of the time.

So, the way I tend to approach motion is to try and understand the “world” of the interface. Is this a 3D or a 2D space? Do elements follow normal physics? What are the rules for how elements supposed to interact with each other, and when are we free to break those rules?

In the work we did with Khan Academy, we talked a lot about the rules of the “world.” If you look at the hero illustration, the red dot has inertia when you move your mouse closer or farther away. That set up a metaphor for how to animate other elements. It was less about making sure they used the same mixin than it is that they should follow the same concept.

Another way to describe that is that what I mentioned ☝🏽 is a very “designer-y” way of thinking about animation, while “systematizing” is a very “developer-y” way of thinking about animation.

Shifting priorities for maturing design systems 🔗

Matt Felten said:

In my experience, starting a design system is about focusing on process, adoption, and scale. Do you have any insight into how priorities shift once a system has stabilized and matured a bit?

Jina said:

for sure. this definitely happened for us at salesforce based on the adoption. we were targeting designers and third party engineers first, with the goal to target our own production engineers later (since they all said they weren’t ready for it and it’d be 2 years or so before they even adopt a button). but once we got the design system going and people saw it, our product engineers started using our stuff anyway — and not in a way we wanted them to (they were copy/pasting code). so we shifted our priorities to focus on supporting and enabling them to adopt it in a maintainable, scalable way.

also, i think the priorities should always be revisited. Nathan Curtis wrote about a worksheet he uses to help with this. i actually ran it with my team at salesforce even though we were already a year and half into things, and it helped us either modify or validate our priorities. there are other methods to do this too. but the point being it’s always good to revisit.

Read this next

Clarity Conference 2019

A recap of the 2019 quintessential conference about design systems.