Having worked both as a Senior Software Engineer developing web applications and as a Design leader establishing the design program from the ground up in a SaaS organization, I find myself in an intriguing position. I’ve been privileged to understand the constant tensions between two groups. On one hand, designers aim to push the limits of product development to enhance user experience, often facing obstacles with scope decisions that slash rich UI interactions they’ve spent weeks or months researching and designing. On the other hand, software engineers juggle delivery deadlines, writing clean maintainable code, and scaling applications with distributed system architectures like microservices. If time and money were limitless, everything desired could be achieved. Unfortunately, resources are finite and must be managed and focused in the most productive way for the highest return.

Design systems help bridge this constant tension.

Understanding Design Systems

A design system is defined by some as:

“ A collection of reusable components, standards, and guidelines for managing and scaling design.”

I would expand this definition to “…for managing and scaling design and application front-end development.”

It’s irrelevant how amazing and useful the design system is if the front-end developers aren’t equipped with the right tools to quickly execute the design across parts of the system. This underscores the vital necessity for teams aiming to scale a system to create a partnership between UX Design and the Front-end Engineering team.

UI Components are the code implementation of all the following parts of a design system: design guidelines, principles, patterns, accessibility guidelines, usability, and best practices. They empower software engineers to implement the design vision while reducing implementation timelines, bugs, and cost. 

As teams grow and become fragmented to focus on key features and decentralize the system’s architecture, sharing code becomes more difficult and chaotic than when the application was a monolith. This often leads to duplication of UI component code with similar functionality, more bugs, and inconsistencies in the user experience, not to mention that it violates the principle of Don’t Repeat Yourself (DRY). This scenario is magnified if the organization has multiple products, each with its own design team.

The Shared UI Component Library Of A Design System

Reusable UI components enhance the precision of implementing design. This precision ensures uniform user experience and UI across different parts of the application, creating consistency across the Product(s). It also improves development efficiency by reducing redundancy in design and development efforts, speeding up the product development lifecycle.

Maintaining consistency in the UI across distributed systems is a significant challenge, especially if teams work mostly independently or are spread across locations. Fragmented teams tend to set different standards and might build with different technology stacks, leading to discrepancies in how the UI is implemented. Without a centralized UI component library or design system, teams might end up creating similar components independently, leading to variations in appearance and behavior for components that should be consistent. It makes governing the design vision across the organization impossible.

A UI component library acts as a single source of truth for both design and development teams. It simplifies the governance of design principles across products and fragmented teams. A design system fosters a common language and understanding between the teams, enforced for Front-end Engineers through the library. UX Designers can benefit from a UI design kit that aligns with the UI components using their design software of choice, such as Figma or Sketch. A UI design kit is the equivalent of a UI component library for designers. Both reduce cost, increase consistency, and speed up time-to-market for both designers and engineers.

Implementing a Shared UI Component Library

Brad Frost popularized the concept in his book “Atomic Design,” which eventually led to the popularization of Design Systems. In his book, he outlines a clear path to start creating one for your organization. My experience, influenced by Frost, follows a simple approach:

1. Inventory your UI for all UI components across your system. Identify variations of the same components.
2. Start by building one component to be used in one project, then build on that foundation for the next project.

It’s that simple. Know the current state, build in increments. Every new component built by one team is a net gain for all other teams. Over time, the value of the system will become evident, but it will need your help to share and convince teams to adopt it in their projects. Most stakeholders won’t see the value until they start seeing the return because many are focused on delivering features and see this as a short-term distraction of resources. Begin small and iterate.

I won’t go into technology-specific implementations because those decisions should ideally be made by you and your teams, based on what works best for your system. Personally, I’ve found that building UI components with Native Web Components offers an excellent solution for teams working across diverse technology stacks. In the past, I’ve utilized StencilJS to construct a library that seamlessly integrates with both modern front-end frameworks and traditional web applications. Consulting with the teams can increase the likelihood of adoption. 

Communicating the Value to Stakeholders

I once had a conversation with a CTO about why it was time for the organization to take UI seriously. After sharing the reasons and challenges our teams faced in the past implementing user experiences, his response was unexpected. He said, “I am not in the business of building UI Component Libraries,” which is true. For a moment, I was at a loss for words, questioning whether I had failed to communicate the value, yet still convinced this was the right direction. He wasn’t wrong; leading the company’s technological vision and ensuring technology strategies align with its business goals is his primary mission. I believe that an investment in a design system is in the best interest for many companies because they are about scaling.

Here are a few benefits to communicate to your stakeholders if you believe the organization can benefit from a design system:

• Increase Development Efficiency and Speed: A design system reduces redundant efforts in designing and coding similar components across different projects. Teams can rapidly prototype and iterate, leading to quicker product launches and feature updates.
• Ensure Consistency and Improve User Experience: A design system ensures consistent application of the brand across all digital products. A unified component library can lead to more intuitive and cohesive user experiences.
• Facilitate Team Collaboration and Communication: A design system acts as a shared language between designers, developers, and stakeholders, fostering better communication and collaboration.
• Cost Savings in the Long Run: While there’s an upfront investment in creating a design system, it pays off by decreasing development time and effort in the long run.
• Stay Competitive and Innovative: A design system is not just about building UI components but about positioning the company as a leader that values user experience and design innovation.

These are just a few of the benefits of a design system. But what if, after considering all these points, stakeholders still prefer to use an open-source UI Component library? This is a scenario you may very well encounter. Indeed, open-source projects offer significant advantages, including the ability to kickstart projects quickly, robust community support, and ongoing updates. This approach works well in many cases, but it’s not without its challenges and limitations.

Challenges and Limitations of Open-source Projects. 

• While open-source libraries lay a solid groundwork, they frequently necessitate significant customization to align with your distinct brand identity and user experience standards. For instance, although you can modify Material Design colors, ultimately, it embodies Google’s brand, not yours.

• Open-source components may not consistently meet specific business needs or objectives. An in-house design system, tailored to precisely accommodate the requirements of the business, users, and developers, can provide a more unified experience that directly supports the company’s goals.
• Additionally, open-source projects often introduce unnecessary code, potentially impacting the application’s performance. An in-house design system permits the creation of more streamlined and optimized components, delivering exactly what’s needed without excess.
• Relying on an open-source library means depending on external entities for updates, security patches, and new features. Constructing an in-house system affords full control, ensuring swift and secure adaptations to meet emerging needs or address security concerns.

Final Thoughts

Ultimately, whether to build a design system hinges on several factors: your organization’s growth phase, size, product complexity, commitment to UX, budget, engineering capabilities, and leadership support.

Assess your organization’s collaboration methods, pinpointing redundancies. Apply the DRY principle across both engineering and design to enhance efficiency.

Instead of aiming for a comprehensive system from the start, collaborate with stakeholders, designers, and engineers on a pilot project. Embrace incremental development to deliver value to multiple teams progressively.

There’s a common misconception that design systems must be elaborate, open-source projects showcased to the world. While commendable, not all organizations have the resources for such undertakings.

Do all design and engineering teams need a design system? Absolutely. But does it need to be a widely publicized project? Not necessarily. It’s more about adopting a modular, iterative mindset in your work—this applies to developers, designers, product managers, and yes, even CTOs skeptical about investing in UI components.

Begin with modest initiatives, evolve through iteration, and gradually realize significant value.