Balancing Flexibility and Structure in Design Systems
I’ve worked on design systems in some capacity throughout my career as a product designer, and initially, it was tempting to think of a system as simply a collection of components that could always be approached in the same way, but that couldn’t be further from the reality. There are so many different ways to build, iterate on, and maintain a system, and the capabilities and requirements of a system will differ based on a team’s maturity, the organization’s willingness to invest in a system, the different products the system supports, and countless other factors. And though every system is wildly different in terms of scale, foundational methodologies, resourcing, etc., I’ve found one rule to be pretty consistent: don’t overbuild.
The dangers of excessive complexity in design systems
Overbuilding is the most common mistake I’ve seen designers make when building a system for the first time. It’s a mistake I made on the first system I worked on. The thought process behind it goes something like this, “If I componentize every UI element, and write the most thorough, detailed, and prescriptive documentation possible, then there will be no ambiguity in the system and thus no problems.” Unfortunately, this just isn’t how it works in the day-to-day realities of a design system, and this is especially true at small to mid-sized companies with less mature design processes. Maybe new requirements arise that make the component that you so painstakingly crafted and documented obsolete. Maybe a designer detaches and alters your component because they think it should work differently. Maybe Figma changes how it handles variants and now future updates have to be done manually. The point is, overbuilt systems that try to enforce meticulous, rigidly defined rules and components can’t flex under the stress of evolving products and unpredictable people, so they break. The systems quickly become bloated and unmanageable, resulting in a sprawling, sporadically used system with gaps between design and code that grow over time.
When creating components and writing documentation, it’s necessary to understand the flexibility that your organization needs given its maturity level and investment in a design system, and to create components and write rules based on those factors. What works for a system like MUI may not work for a startup.
As I mentioned earlier, I made this mistake on the first system I worked on. At Progressive Leasing, we conducted extensive research and testing to understand how our designers would consume documentation.
I then helped design, write documentation for, and even illustrate a full design system website that documented every existing foundation and component, housed a regularly updated design system roadmap, and provided quickstart guides for designers and developers to start building with the system.
This website even had a full identity, including a logo, a unique palette, bespoke iconography, and a custom illustration style.
For the record, this is work I’m still very proud of, but it was more complicated than the problem actually called for. We didn’t need a custom identity and illustrations. The design system team wanted to create a site that was reflective of the quality of the system and the care with which it was built, but that wasn’t what our users needed at the time. They just needed a central location to view components and read documentation.
It may seem relatively harmless to overbuild a design system site, but after I and other core members who originally built the system had left, its complexity became an issue. In discussions with a developer, I learned that the system, now with fewer resources, became too difficult to maintain and collapsed under its own weight. Its use is far more sporadic now than it used to be. While there were many factors at play, I’m convinced that had we built a more basic but still comprehensive site with shorter iteration cycles, we could have created a more sustainable structure that future designers and developers could have managed.
Based on my previous experiences, I decided to handle the documentation at ProducePay similarly to how we did at FullStory. Given the startup environment that we were in, I used a simple documentation template in Figma with assets that could later be ported into Storybook when we had the bandwidth.
The documentation was still robust and detailed, but its implementation was lightweight and nimble. The components we chose to build were reflective of this philosophy as well. We chose the most high-usage components across our products and invested in making those flexible and comprehensive. These core components covered the majority of components used across our products. This meant that our system was sturdy at its core while remaining highly flexible for the diverse needs and strained resources of a startup.
In short, an effective design system is not a static entity; it’s a living, breathing organism that must be tailored to the specific environment in which it exists. It evolves in response to its surroundings, adapting to meet the ever-changing needs of the organization and its users. This adaptability is crucial for creating a sustainable system that continues to serve its purpose effectively over time.
