Design systems

Introducing an inbound feature request and/or contribution process in the org? Betting it’ll help the core design system team make the design system and all its users more successful? I’d been there, I’d made a few mistakes, and I’d like to share them — no sugar,

One thing I’ve found very valuable for platform-level teams, including design system teams, is having a communication plan. One that describes topics, preferable level of detail, frequency of push/pull updates, and people/roles involved. Such a simple document can save a lot of frustration for the people involved

When you start building a design system, the team is new, the topic is new, people in the organization are hopeful but mostly unaware of the challenge, and it’s important to pick a strategy in the beginning. Two options are “do things right” and “do things fast”. I chose

A design system team is in the organization to serve the entire organization. With this mindset, I started running a design system team and very soon found myself debugging the organization, where that team was being declared as a “dependency” or, occasionally, a “blocker” to most other teams. What happened?

Go out and listen to what people say about your design system and what you could be doing better.

Design system work involves lots of people. How do you measure your team’s productivity in this chaos?

If a design system is a product, inbound requests from the developers is direct customer feedback.