Thread by @sarah_federman

The longer I do design systems the more I feel like seeing a lot very flexible APIs in your tools is a red flag. It's another thing in Decision Debt land. Thread:

APIs get flexible for 3 reasons. 1) is devs love that shit and it's a creative challenge for us to support as many possible uses. 2) is because there's an actual validated need for it that's been sparred w/ products and design, which happens sparingly and w/ awareness.

3) is because it's *easier* to open it up than validating w/ products and design that the right options exist and are being used correctly. Here's where it gets super hairy.

Knowing who is overriding things and why is HARD. Having conversations about why they do is HARD. Deciding whether the solution is to change the standard, add another variation, or make it more flexible is HARD. Tracking those changes is HARD. Deciding who does the work is HARD.

But that's the job, y'all. It's hard. I would say that this is the primary function of design systems teams even. Opening things up means supporting endless variations. It means it's harder to evolve without breaking products. It makes it harder to type and test.

The best way to mitigate this is with relationships. Make sure that product teams feel empowered to come to your team and have productive conversations about their needs.

Have API design meetings w/ DESIGN INCLUDED before a line of code is even written. Same with API changes.

Manage your workload in a way that if you see things getting made flexible without a conscious decision, there's a way to pause and circle back w/ the relevant parties. It's WAY easier to add flexibility than it is to take it away later, and that's if it's even tracked.

Remember that company design systems are not the same as open source libraries. You have the power and incentive to make decisions about what and who to support and why. Less is more.

Anyway, that's my tweetstorm for this Monday. Peace ✌️