In the 1960s, computer technology began outpacing the speed of software programming. Computers became faster and cheaper, but software development remained slow, difficult to maintain, and prone to errors. This gap, and the dilemma of what to do about it, became known as the “software crisis.”
In 1968, at the NATO conference on software engineering, Douglas McIlroy presented component-based development as a possible solution to the dilemma. Component-based development provided a way to speed up programming’s potential by making code reusable, thus making it more efficient and easier to scale. This lowered the effort and increased the speed of software development, allowing software to better use the power of modern computers.
Now, 50 years later, we’re experiencing a similar challenge, but this time in design. Design is struggling to scale with the applications it supports because design is still bespoke–tailor-made solutions for individual problems.
Have you ever performed a UI audit and found you’re using a few dozen similar hues of blue, or permutations of the same button? Multiply this by every piece of UI in your app, and you begin to realize how inconsistent, incomplete, and difficult to maintain your design has become.
For design in this state to keep up with the speed of development, companies could do one of three things:
- Hire more people
- Design faster
- Create solutions that work for multiple problems
Even with more hands working faster, the reality is bespoke design simply doesn’t scale. Bespoke design is slow, inconsistent, and increasingly difficult to maintain over time.
Design systems, however, enable teams to build better products faster by making design reusable—reusability makes scale possible. This is the heart and primary value of a design system. A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
For more than 50 years, engineers have operationalized their work. Now it’s time for design to realize its full potential and join them.
Scaling design with systems thinking
Design systems have become a bit of a hot topic in the software industry—and for good reason. Design is scaling. Many businesses are investing in design as they recognize that the experience of their products offers a competitive advantage, attracts and retains customers, and reduces support costs.
Here are what things usually look like inside a company that’s investing in design:
- The design team is growing.
- Design is embedded in teams throughout the company, maybe in multiple locations.
- Design is playing a key role in all products on all platforms.
If you’re a designer, this sort of investment in design may sound exciting, but with it comes many challenges. How will you design consistent UIs across platforms when many teams own various parts of your products? How will you empower all of these teams to iterate quickly? How will you maintain the inevitable design debt that builds up as many designers create new and tailor-made designs?
To understand how creating a design system can address these challenges, we must understand what design systems are. Design systems marry two concepts with individual merit, making something more powerful than its separate parts.
Understanding not only the what, but the why, behind the design of a system is critical to creating an exceptional user experience. Defining and adhering to standards is how we create that understanding. Doing so removes the subjectivity and ambiguity that often creates friction and confusion within product teams.
Standards encompass both design and development. Standardizing things like naming conventions, accessibility requirements, and file structure will help teams work consistently and prevent errors.
Visual language is a core part of your design standards. Defining the purpose and style of color, shape, type, icons, space, and motion is essential to creating a brand aligned and consistent user experience. Every component in your system incorporates these elements, and they play an integral role in expressing the personality of your brand.
Without standards, decisions become arbitrary and difficult to critique. Not only does this not scale, it creates an inconsistent and frustrating user experience.
Components are portions of reusable code within your system and they serve as the building blocks of your application’s interface. Components range in complexity. Reducing components to a single function, like a button or a drop down increases flexibility, making them more reusable. More complex components, like tables for specific types of data, can serve their use cases well, but this complexity limits the number of applicable scenarios. The more reusable your components are, the less you need to maintain, and the easier scale becomes.
Component-based development reduces technical overhead by making code reusable. Standards govern the purpose, style, and usage of these components. Together, you equip your product team with a system that is easy to use, and you give them an understanding that clearly links the what with the why.
The value of design systems
Let’s take a detailed look at the many ways a design system can be a much-needed remedy for your growing pains.
As teams grow, it’s common for designers to concentrate on discrete areas of an app like search and discovery, account management, and more. This can lead to a fragmented visual language—like a Tower of Babel of design—with each designer speaking her own language. This happens when designers solve problems individually and not systematically.
With no common design language to unite the product, the user experience starts to break down, as does the design process. Design critiques become unproductive when there’s a dearth of design conventions. To create alignment within teams, there must be a shared source of truth–a place to reference official patterns and styles.
Most often this is a static artifact, such as a design mock, but a static reference will almost immediately become outdated. That’s why teams build things like Shopify’s Polaris–a site that documents all aspects of the design system including components, guidelines, and UX best practices. It is built with the system, so it will always be up-to-date.
An internal design systems site is the best, most accessible source of truth for product teams. It can keep team members aligned and in sync.
Manage your debt
As applications and their teams age, they build debt. Not financial debt, but technical and design debt. Debt is acquired by building for the short-term. Design debt is made up of an overabundance of nonreusable, inconsistent styles and conventions, and the interest is the impossible task of maintaining them. Over time, the accumulation of this debt becomes a great weight that slows growth.
The act of creation does not inherently create debt–just like spending money doesn’t inherently create financial debt. But using a design system will keep you on budget by keeping your design and code overhead low, while still allowing you to grow and evolve your application.
Standardized components used consistently and repetitively create a more predictable and easy to understand application. Standardized components also allow designers to spend less time focused on style and more time developing a better user experience.
Working within an existing design system allows you to piece together flows and interactions as quickly as pulling Lego blocks from a bin. This allows you to build an endless amount of prototypes for experimentation, helping your team gain insights and data fast.
Iterate more quickly
Whether evolving the style of your UI or making UX changes to a flow, using a design system reduces effort from hundreds of lines of code to as little as a few characters. This makes iterations quick and painless, and experimentation much faster.
Build in accessibility
You can optimize for those with disabilities, on slow internet speeds, or on old computers at the component level. This will make your product more accessible and help you comply with your country’s accessibility laws.
Myths of design systems
Even with all their benefits, buy-in for creating a design system can still be a hard sell internally. Designers can feel limited or restrained, but often these perceived weaknesses are the greatest strengths of a design system. Let’s debunk common myths you’ll hear as you sell the idea of creating a design system.
Myth 1: too limiting
Myth: Designers embedded in discrete areas of an app may see a universal system as being too limiting. They may feel it doesn’t serve the needs of their specific area.
Reality: Designers often end up creating custom solutions to improve discrete areas of an app, adding to design and technical debt. With a design system, new solutions can be created and fed back into the system making those improvements available to everyone.
Myth 2: loss of creativity
Myth: If designers have to use a design system, then they will no longer be free to explore new styles.
Reality: They can explore all they want. The components of a design system are interdependent. When a change is made in one location, the change will be inherited throughout the whole system. This makes style updates within a system trivial in effort but much greater in impact. What once was weeks–if not months–of work, can now be accomplished in an afternoon.
Myth 3: one and done
Myth: Once the design system is designed and built, the work is complete.
Reality: A design system is living–it will require ongoing maintenance and improvements as needs arise. Because your application is powered by the reusable components of your system, the application automatically inherits improvements to the system, lowering the effort to maintain the application. This is the power of scaling that a design system offers.
Marco Suarez works on design systems at InVision. This article was adapted with permission from InVision’s Design Systems Handbook. Read the full text here.