The Lean Design System: Maximising value for smaller teams

For smaller teams starting out in the world of design systems, it’s all too easy to look over the garden fence, see the complex, mature design systems that everyone else appears to be building, and think “Righto, that must be what we need to do…”

Where this ‘keeping up with the Jones’ mindset can lead to problems is when smaller teams mistakenly think that building a complex, enterprise-level design system will solve more problems than it creates. Complexity and ability are of course relative; what’s perceived as complex relative to any one team’s ability and experience level can vary greatly, which is where it gets tricky when modelling your own system on what you see others doing. If you build a system that’s too complex for your team to manage, then that system will inevitably fail; instead, success lies in teams working to build a system with complexity that’s proportionate to their specific size, experience, and ability.

The majority of teams I work with are looking for a Design System to help them reduce complexity, duplication, and effort, in order to deliver valuable product enhancements with greater speed and regularity. This is a sound reason to build a design system, however, you can’t hope to reduce complexity and effort by building an overly complex system. In order to be successful, the system’s complexity has to be proportionate to the ability, size and capacity of the team using it, and this is where The Lean Design System mindset comes into play.

So what do I mean by The Lean Design System mindset? To achieve this, for smaller teams of less than 10 designers this means accepting that you can’t have everything right now, and that you need to start lean, and prioritise immediate value. Sounds pretty obvious right? In a way, yes, but this means picking your battles when it comes to the facets of your design system, and being comfortable in the early stages of building your system, to put on hold some aspects that could bring you greater value in the future than in the present. Comprehensive documentation such as guiding principles, DO's and DON'Ts, detailed component anatomy diagrams for example, are important facets of a mature design system, but does your team need those things right now? And furthermore, is it realistic for your team to create and manage those facets right now? Remember, maturity is something that’s acquired over time, so with this in mind, don’t be afraid to embrace immaturity as your starting point.

The most effective way to start demonstrating the value of your new design system, is to get some reusable styles, components, and patterns built, and into use. That’s why I advocate for smaller or inexperienced teams to start by building the winning combination of a robust pattern library alongside a concise style guide and design tokens, as the starting point for their organisation's Lean Design System.

While these things alone do not constitute an all-singing, all-dancing design system, they can be easily managed by a smaller cross-functional team whilst being incrementally scaled into that full blown, all-singing all-dancing design system over a longer period of time. A lean, functional Pattern Library and Style guide will give your team a modular library of reusable components and elements to work with, demonstrating value through faster, more consistent, and more abundant prototyping and optimisation of your products.

How much documentation is enough documentation?

Comprehensive documentation is a highly valuable facet of a design system, creating clarity on how to use the system, and reducing misuse of components, assets, and styles. However, comprehensive documentation takes a great deal of effort for a small team to create and manage. So instead of looking over the fence at Google’s Material Design, and trying to recreate its level of documentation, instead ask your team to identify what’s the absolute leanest documentation required for your designers to successfully use a component, and for your engineers to build it. You can create placeholders for any nice-to-have documentation that you’d like to add in the future, ensuring the scalability of your design system’s structure to accommodate more, richer content.

What about governance?

The same mindset can be applied to your Lean Design System’s governance processes. Never undervalue the importance of your system’s governance processes, as they’re the secret sauce that turns a well organised set of components and styles into a usable, scalable system. That being said, this is another area where finding comfort with immaturity is the smart approach to complexity. When you’re starting out, put perfection to one side and aim to create governance processes that are acceptably imperfect whilst being perfectly manageable for your team on a day-to-day basis. If you’re a small team, you can afford to be a bit more scrappy in your approach to governance, so try to define processes that enable you to move quickly, and avoid design and Tech debt, without too much bureaucracy or red tape.

In the Pattern Library Playbook I described governance as a framework that outlines roles, responsibilities and decision-making for maintaining and updating a design system, and this still holds true. My recommendation for the most valuable facets to focus on first for small teams, is points 3 and 4 from the Pattern Library Playbook, which cover modifying the system and tracking changes to the system. As a small team you should look to answer the following set of questions with the leanest workable documentation and processes that you can define, keeping in mind a view to future scalability.

• What’s the process for assessing whether to modify an existing pattern?
• What’s the process for assessing whether to create a new pattern?
• What’s the process for assessing whether a new pattern is reusable or a Snowflake?
• Where do Design and Engineering practitioners come together to review updates?
• What’s the process for merging new/updated patterns to the Library?

Answering the above set of questions will help your team to define their lean process for getting components and updates into the design system and handed over to engineers, so that your team can start using and contributing to the system while your organisation can start reaping the benefits of having a design system in place through increased efficiency.

Building for scalability

The mindset of starting lean, to prioritise immediate value is a sound one, however, it’s essential that while you’re embracing immaturity today, you have a clear idea of what growing into maturity should look like in the future. What this amounts to in simple terms is planning ahead, in order ro reduce the risk of designing your system into a corner, so to speak. Before you reach for your crystal ball, let’s agree that while no one can be certain what the future might be, certainly when it comes to digital products and services, every team is capable of identifying how they would like the future to be.

As you might already do when defining a strategy for the products your system supports, have your team define a North Star for your design system, and a roadmap to get there. This approach will ensure that with every step you take towards that ideal North Star state, you’re avoiding short sightedness while creating the structures and space required for future scalability.

At this point it’s important to reflect on something we covered at the beginning of this article; small teams often think that building a complex, enterprise-level design system will solve more problems than it creates. Don’t fall into the trap of planning a future that’s beyond your team’s capabilities. This means that your North Star must still reflect the size and ability of your team. If your North Star is a system that will ultimately be too complex for your team to manage, then you’re building towards failure.

Today, tomorrow, next year, and beyond, the complexity of the system must be proportionate to the size of the team.