Every time you create software, you’re creating and using a design system. So the question isn’t “should we create a design system”, but rather, “should we be intentional about the design system we’re creating?” You can create a bunch of code that’s really complicated and terrible to use, and that’s still a design system — it’s just not a very good one!

Since design systems happen whether we want them to or not, our task is not to decide whether or not we need one. We need to decide if we’re better served by being intentional about our design system decisions or letting the design system drift to see what emerges from real-world use.

In this post, we’ll dive into what that means, what design systems actually are, and how we can create effective design systems for ourselves without spending too much time or creating too much internal process.

Heads up!_ This post is part one in a three-part series that expands on a conversation with Dan Mall about design systems on Learn With Jason._

Before we start: what is a design system?

In general, it’s useful to have a more general, inclusive definition of what design systems are:

A design system is the smallest set of components and guidelines that an organization needs to make digital products better.

This definition leaves a lot of room for interpretation — and that’s very much by design.

Don’t put design systems in a box.

Avoiding specifics isn’t an attempt to evade the question; it’s an acknowledgment that each design system is a unique product of its environment.

Any attempt to create a rigid definition of design systems inevitably requires exceptions and caveats that add complexity and, ultimately, don’t actually matter. What matters is that the design system is improving the baseline of the organization’s effectiveness.

#drift #machine-learning #learn design systems