Get Started

Design systems are empowering teams and organizations

Today’s design systems are the culmination of decades of experience in building digital products collaboratively. They have become the leading paradigm for organizing, evolving, and extending the component libraries underpinning modern apps and platforms. An effective design system unites product teams around a common vision and design language. It represents a trusted single source of truth, provides us with battle-tested, reusable components, and defines the processes and responsibilities governing its ongoing development. It allows engineers and designers to communicate effortlessly and enables them to deliver consistent experiences at any scale. An accessible and well-documented design system also simplifies onboarding processes, as it makes tacit knowledge explicit and standardizes workflows. In summary, it’s a game-changing concept that can truly empower digital product teams when implemented properly.

So, where’s the catch?

Design systems appear to be an optimal solution to achieve both scalability and consistent design quality. A solid component library can prevent technical and design debt accumulation and help teams build realistic prototypes very quickly. However, the risks and costs associated with building complex systems often deter smaller, resource-constrained teams and solo devs. A dedicated design systems team is a luxury we can rarely afford. Also, additional governance processes may quickly overburden a young organization lacking any buffers. And lastly, even if the required resources are in fact available and the decision is made to build a design system, it may very well take months—sometimes even years—before it reaches a state where it’s ready to be rolled out. Only then will it become apparent whether its components and processes can actually deliver the expected value.
Lean Design System aims to alleviate these concerns. Even as small teams or solo devs, we want to be able to start with a minimum viable design system today, at little cost and risk, and grow it incrementally as our work does.

Lean Design System methodology

Lean Design System provides a modular and evolving set of 12 tactics (organized in 4 layers) aiming to allow any kind of organization, and even solo devs, to dip their toes into design systems and more strategic design approaches. Every tactic is designed in such a way that it works in isolation, but is also linked to other tactics supporting it. This means that the library can be explored at any pace and in a piecemeal manner. The methodology is driven by the idea that any digital product team can cultivate a naturally emerging design system by following a proposed set of principles and behaviors. The right infrastructure and a solid understanding of the artifacts that are to be maintained aim to provide a reliable and scalable framework for emergent systems—which brings us to the 4 layers structuring the 12 tactics of Lean Design System:

• Principles: Tactics on the Principles layer describe the methodology’s guiding principles and foundational concepts.
• Infrastructure: Tactics on the Infrastructure layer describe what kind of organizational and technical structures can be derived from the Principles layer.
• Behaviors: Tactics on the Behaviors layer describe how action can be taken on the individual level at any time. They also describe behaviors that should be actively fostered to ensure steady improvement.
• Artifacts: Lastly, tactics on the Artifacts layer describe the actual artifacts organized in the design system’s libraries and repositories.

How tactics are structured

All tactics follow the same template: each starts with an introduction outlining a challenge, an obstacle, or an opportunity, followed by an in-depth description. Finally, they conclude with a section explaining where they fit into the larger methodology, listing other tactics they’re directly supporting as well as tactics they themselves receive support from.

How does agentic AI affect our practices around design systems?

As I outlined in the foreword, working with agentic AI (potentially) affects everything about how we create, maintain, and use design systems. However, two aspects stand out to me:

1. Opportunity: Now that we have an eager team of agents at our disposal, we can (and should!) create design systems even for smaller solo projects. A lot of the tedious work around documentation and plumbing can now be automated. If we already have a rudimentary design system, we can plug it into our codebase. If we have an existing app, but nothing is properly documented, we can generate documentation on it. We can now enjoy all the benefits of having a design system at a fraction of the original cost.
2. Necessity: We will also become much more dependent on documentation that’s accessible to both humans and AI. Working with agents and moving at a much faster pace than before will amplify misunderstandings and produce mountains of technical and design debt — unless we are able to establish a shared language and make sure we stay on the same page. To fully leverage the potential of agentic AI, we have to build a foundation for trust, so that we don’t have to double-check every color value, every border radius, and every motion variable the AI is documenting or applying. With the paradigm shift driven by AI, code-oriented design documentation has evolved from a valuable concept into an absolute prerequisite for modern product development.

How to use this documentation

The main goal of Lean Design System is to make the concept of design systems accessible to anyone. Accordingly, there are only 2 requirements for adopting any of the proposed tactics:

1. Teams and individuals have sufficient autonomy to experiment with new tools, workflows, and approaches.
2. Short lines of communication allow for the quick evaluation of results and experiences.

Working on our own, we meet both by default. In teams where the required room to experiment isn’t there yet, it is usually easier to win it on a small, low-stakes project than to argue for it in the abstract.
Beyond that, there is no prescribed way through this library. Every tactic works on its own, so we can pick whichever one speaks to the problem in front of us, try it on a real project, and judge it by what it actually changes. If it helps, we keep it. If it doesn’t, we have spent an afternoon rather than a week.

Before we get to the tactics themselves, Core Values explains why they are shaped the way they are, and closes with a few suggestions on how to work through the library at our own pace.