InVision presents

Design Systems Handbook


by Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield

A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt.


Go to Chapter
Introducing design systems
The power of scale

Repetition and reusability make scale possible. InVision’s Marco Suarez takes you back to the foundations of component-based design and the many ways design systems enable scaling. He also addresses a few common misconceptions about design systems.
 

Go to Chapter
Go to Chapter
Designing your design system
Step by step

Starting can be the hardest step. Design systems expert Jina Anne walks through what to consider as you start out. Involve the right people, find the right model, add the right pieces—and you’ll be well on your way to establishing a successful design system.

 
 
 
 

Go to Chapter
Go to Chapter
Building your design system
A strong foundation

Building a flexible, maintainable, stable, scalable design system creates a strong base for your product design team. Etsy’s Katie Sylor-Miller shares foundational knowledge learned building design systems across cross-functional teams.

 

Go to Chapter
Go to Chapter
Putting your design system into practice
Better together

Encouraging adoption of your design system forges connections and creates champions across teams. GitHub’s Diana Mounter lays out practical strategies for sharing design systems and growing adoption, including examples from her experience.

 
 

Go to Chapter
Go to Chapter
Expanding your design system
More than the sum of its parts

Components form the core of a design system, but teams can align around much more than components. Marco Suarez outlines how teams can round out their systems with vision statements, design principles, voice and tone guides, and more.

 

Go to Chapter
Go to Chapter
The future of design systems
To infinity and beyond

Design systems play a huge role in shaping our present, but we may only be scratching the surface. Airbnb’s Roy Stanfield explores a bold future of intelligent, adaptive, context-aware systems that could further accelerate design’s possibilities.

Go to Chapter
Go to Chapter
Appendix
More resources

Design systems continue to evolve, and every company’s system can offer something to our collective knowledge and understanding. We’ve curated a list of publicly available design systems and resources to help you continue your exploration. 

Go to Chapter
01

Introducing design systems

The power of scale


by Marco Suarez

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 utilize 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 1 of 3 things:

  1. Hire more people
  2. Design faster
  3. 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 enable teams to build better products faster by making design reusable—reusability makes scale possible. This is the heart and primary value of design systems. 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

You’re probably well aware that design systems have become a bit of a hot topic in the software industry these days—and for good reason. Design is scaling. Many businesses are investing in design as they recognize that the customer 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 will build 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 2 concepts with individual merit, making something more powerful than its separate parts.

Standards

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.

Lori Kaplan, co-author of the pioneering Macintosh Human Interface Guidelines (HIG), tells the story of their creation and impact on designers and developers.

Components

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.

Learn more about building components in Chapter 3: Building your design system.

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 painkiller for your growing pains.

Scale design

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 monuments like Shopify’s Polaris site—a design system site, built with the system, that documents all aspects of the system including the components, guidelines, and UX best practices. And because it is built with the system, it will always be up-to-date.

An internal design systems site is the best, most accessible source of truth for product teams. It provides the gravitational pull to 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 non-reusable and 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.

Design consistently

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.

Prototype faster

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 and variants 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.

Improve usability

Inconsistent interface conventions hinder usability. When CSS for countless unique interface elements and their interactions increase, so does cognitive load and page weight. This makes for a terrible user experience. It can also create conflicting CSS and JavaScript, potentially breaking your app. By using a design system, you’re able to avoid these conflicts by building a holistic library of components, instead of per page, which means you’ll spend less time in quality assurance.

Build in accessibility

Accessibility can be implemented at the component level by optimizing for those with disabilities, on slow Internet speeds, or on old computers. This is an easy usability win. In Chapter 3, Building your design system, Katie Sylor-Miller explains how design systems can help improve your product’s accessibility and compliance with your country’s 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 see qualities that may be different from other areas. Because of this, a universal system is perceived as being too limiting and might not serve the needs of these specific areas.

Reality: Designers often end up creating custom solutions to improve discrete areas of the 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 are restricted to using a design system, then designers will no longer be free to explore style. Front-end backlogs are often full of design style updates. Evolving the visual style of an app is typically no small task. This can also be a great risk, as it removes resources from new feature work and may negatively impact usability.

Reality: The components of a design system are interdependent. This means 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, meaning it will require ongoing maintenance and improvements as needs arise. Because your application is powered by the reusable components of your system, however, 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.

Conclusion

Design systems are not a fad or even an untested hypothesis. For design to find the scale necessary to match the rapid growth of technology, component-based design and development is a proven and dependable solution.

Now that you’ve seen the true value of creating a design system, let’s dive into the actual design process in the next chapter.

06

The future of design systems

To infinity and beyond


by Roy Stanfield

I find it exciting to see design systems empower design teams to scale and consistently produce solid products, but I know we’re only scratching the surface of our potential. There’s so much more we can accomplish.

At Airbnb, we’ve been pondering how we might push our design system in new directions, and we’re inspired by design-forward companies that share our desire to craft the future of design systems.

In this chapter, I want to introduce you to a new way of thinking about design systems. Design systems can transcend the walls of a single company to exist as shared standards and customizable tooling with help from the open source community, which can accelerate development and eliminate the need to start systems from scratch. If we’re really bold, we could be creating adaptive, intelligent systems that are context-aware and compose themselves—reducing our workload and ultimately unlocking AI-powered design.

But, I’m getting ahead of myself. Let’s start with nuts and bolts.

Building a common foundation

In his 1998 essay Interchangeable Parts, Tim Sheiner examined the historical standardization of parts for physical products, and predicted how this will play out for digital products.

A designer’s familiarity with the concept of a design system is based on the systems they’ve encountered, what platforms they’ve been tasked to support, and where they’ve worked. Books like this one help us converge on a high-level definition for design systems, but a more rigorous definition will ensure the utility and flexibility of our work.

Finding a standard that supports shared goals will involve decoupling a design system from its implementation, cataloging common UI and associated states, and more strictly defining design primitives and components. This could then be expressed in a file format that’s able to define a component or design system more completely.

An example of differing goals

Currently, existing systems reflect the specific needs of the companies that created them. Since each company is building an entirely independent system, design system development starts from scratch—possibly with help from a web toolkit like Bootstrap, relying on the internal knowledge of the team, and only focusing on top-level needs. As a result, even the best systems contain flaws and lack the necessary tooling to speed development and track results. And if a company’s priorities shift, its design system must shift, causing another section of the design system to be built in the same limited way.

For example, one of the reasons Airbnb created DLS was to minimize and sync differences in UI between our supported Android, iOS, and web platforms. In The Way We Build, VP of Design Alex Schleifer writes, “Universal and Unified define the system’s approach we apply when defining patterns. Is it part of a greater whole? Does it work across devices?”

In our idealized vision, a mockup easily ports between platforms—creating a better design and development experience. This cross-platform UI would give Airbnb guests and hosts alike the same end-product experience as if they jumped between mobile app and desktop web.

In contrast, supporting multiple device platforms was initially less of a concern at Etsy, where the main priority was to scale its web platform. During my time there, the team built the web toolkit with the core website as its primary focus. Later, Etsy expanded upon its toolkit to support different branding elements for other internal web initiatives. Karyn Campbell describes what it was like modifying the Etsy design system while making Etsy Studio. “While we made a conscious decision to depart in some instances with the etsy.com UI in order to birth this new brand, we also retained many underlying components that our design systems team had created.”

A priority at Airbnb was having the same functional and visual voice across platforms. A priority at Etsy was to support multiple web products with varying brand initiatives. Both were valid needs. A shared standard for design systems would need to ensure a solid foundation so that both these and other real-world priorities could more easily be achieved.

Gathering examples of different design system priorities will help create a checklist to make sure your design system standards address real concerns. Any company adopting these suggested standards could be assured their design system development focuses on immediate company needs, as well as adhering to standards they plug in to a growing body of open source code and tools that support most operational transformations that could be encountered.

But what should be in the design system standard?

Imagine a tool that can specify which design primitives, (e.g., fonts, spacing, color—more on that below), components (and their states), platforms, and what documentation and testing are needed to have a fully formed design system. The tool would also allow the designer to specify which components were not yet needed and which platforms could be added later. With this tool, a designer would have a framework stating what aspects of the design system were completed or outstanding. A product manager could export documentation, and a developer could easily export UI and UI tests—no longer needing to translate UI from Sketch to code, or from web code to native implementation.

If created today, not only would this tool provide industry-wide savings, but it would start to standardize the low-level definition of a design system. Working backward, let’s now imagine what kind of definitions such a tool would need in order to exist.

First, decouple the design system from any specific implementation. We’re not creating React components (nor other web implementations), nor Android UI, iOS UI, or even Sketch files. Instead, our system is an abstraction that can be deployed to any target implementation. We’re going to need a file format to describe this abstracted design system. The exported format could be rendered into views by open source modules specific to each target implementation.

Next, codify the definitions of design primitives and components so they are fully expressed in the design system format. Dang, .dsf extension is already in use! Guess we’ll have to settle for the .dang file extension!

Design primitives are the building blocks of a UI. These include specific predefined colors, fonts, spacings, and more. They are foundational visual elements that can be combined into components. Changing primitives is echoed throughout a given design system’s components, and doing so changes the overall feeling of a brand. Additionally, what are components? We’ll also need to codify those. Components are mostly views composed of design primitives and smaller components whose minimal internal logic is mapped exclusively to state and state change. Benjamin Wilkins, Design Lead on the Design Tools team at Airbnb, describes the difference between primitives and components in minute 7:00 of his talk, Thinking in Symbols for Universal Design.

Next, we’ll need to catalog all of the common UI components in use today. Just as a typeface may have its unique take on the letter “A” (the letter’s visual appearance may vary between typefaces while its meaning is maintained), a .dang file would have a text input component that varies in visual representation but not functionality. The catalog will need to group components with their accompanying states (selected, focus, on-tap, error, etc.) and detail interactions to distinguish between mobile, desktop, and TV UI.

What are the benefits of this catalog? To start, functional tests for common components could be easily automated through contributions from the open source community. In many cases, UI engineers would no longer need to write their own tests. The cataloged components would also enable a marketplace of boilerplate design systems that can be installed interchangeably, and against which custom UI can be built and substituted. This means bootstrapping the creation of every design system is no longer necessary.

Lastly, we need to allow for the evolution, growth, and extensibility of design systems built upon the shared standard. Just because we’re aware of which components are needed today doesn’t mean that we’re able to predict all the elements needed for future innovation. A process for modifying existing components or creating wholly new ones is in order. Thoughtfully standardizing our collective knowledge will produce a more consistent user experience, accelerate development, decrease investment needed from individual companies, and enable open source and collective development of next-generation design tools that conform to shared conventions.

Creating a single source of truth

The elements that make up a design system—principles, UI components, patterns, and documentation—create the human-computer interaction layer for our apps. Product designers and system designers are directly responsible for this layer, and therefore should own the design system and its representation in the codebase.

There are 2 hurdles to achieving a single source of truth. First, our current design tools are inadequate. Most only allow us to produce images of UI and prevent designers from achieving product level fidelity. Second, if the implementation of a design system is spread across multiple repositories (Android, iOS, React Native, React, etc.), collected in a Sketch file, and documented on a website, then there really is no single codebase to represent a truthful account of the system. Lacking a single source of truth, the design system—spread out over multiple codebases—becomes an amalgam of sources that easily fall out of sync.

Our tools

Designers use tools like Sketch, Illustrator, or Photoshop to draw pictures of UIs, yet these are actually just representations of interactive components that look different, behave differently, and contain different data depending upon the state of the app at a given time. As Colm Tuite notes in the article Design tools are running out of track. Here’s how we can fix them, “Think of the number of simple interactions which are commonplace in almost all of our products yet cannot be communicated through our design tools.”

Tuite then mentions interactions and states such as hovering over a button, focusing an input, checking a checkbox, and identifying scroll areas. He points out that our design tools aren’t prompting designers to think with product level fidelity, and so a designer’s work is usually missing some of its most important details.

Sketches of apps are then handed off to developers who have to translate them into working UI. Between the designer and the 4 developers that it takes to convert the design into Android, iOS, React Native, and React, it takes 5 different members of the team begin to bring the design up to product-level fidelity. Since the original sketch was missing details about state and interactions, a back-and-forth conversation between designer and multiple developers is needed to make the designs production-ready. And because the implementation is coded by 4 different humans, it’s likely that unwanted variation creeps into each implementation.

For similar reasons, many designers have focused on sharpening their coding skills for at least 1 platform. There are many advantages to this, but if you’re a systems designer creating components for cross-platform use, coding those components for a single implementation is not yet enough.

Multiple implementations

The attempt to reach a single source of truth is further complicated when working on cross-platform design systems. Jon Gold identifies places where Airbnb’s DLS workflow could be improved in Painting with Code.

At Airbnb, Gold has taken some exciting first steps toward solving this problem with his project React Sketch.app. With this tool, layered Sketch files can be generated from the React codebase. This means components in the Airbnb React repo, which already have product-level fidelity, can be populated with real data and rendered to a Sketch file. It’s another reward for those adventurous designers willing to learn React!

It’s also a touchstone technology, pointing us toward understanding mockups not as the source of truth, but instead as another target for automated output. With these generated files, we get a clear picture of which components are sitting in the repo. Best of all, a product designer relying on Sketch does not have to change their workflow and can use more accurate files (generated by the codebase, not by hand) to compose their work. At last, we can have confidence in how the components look at product-level fidelity and in how these components behave with real data.

React Sketch.app is great because it syncs the React and React Native repos and Airbnb’s design system Sketch files. But what about the Android and iOS implementations? How can designers make sure these are in sync? React Sketch.app points the way, but we’ll have to go further.

Here, we can learn from tools and WYSIWYGs of the recent past like Dreamweaver and Interface Builder. Tools in this category allow users to combine elements of UI, hook the UI up to data and interaction, and then export deployable code. Unfortunately, these software produce code that’s not maintainable by humans, and so few companies use them as an official part of their process. Did these tools promise too much and deliver too little?

Luckily, design system components are simple views with minimal logic. (Learn more about views and MVC architecture here and here.) Unlike the promise of tools like Dreamweaver and Interface Builder, components are easily exported view files that developer partners can incorporate into existing workflows.

Solving 2 problems with 1 tool

To create a designer-controlled source of truth, we’ll need next-generation design system tools to enable the composition of components and to automate the output of the design system to any number of target clients (codebases, vector files, and documentation sites).

As outlined in the section above, if we standardize an export format that contains production-level fidelity for components, then other interpreter modules can be freely built to compile a single component file into all the various flavors of production code. Then, varied implementations of any given component would flow from a single source of truth and would plug right into existing workflows—saving resource-intensive and error-prone human interpretation of mocked UI. Product designers and design system designers would finally control the UI they have always been responsible for.

At Airbnb, we’re tackling this challenge in a variety of ways, including with Lona, our tool for defining design systems and using them to generate cross-platform UI code, Sketch files, images, and other artifacts. A highly experimental prototype, Lona represents our exploratory approach to discovering what’s next for design at scale. Taking a research-based approach to the future of design systems encourages experimentation and collaboration.

Intelligent systems compose themselves

If you’ve not heard of Alan Kay, make sure to look him up. He’s credited with inventing the graphical user interface, Object Oriented Programming, and—with his concept of the Dynabook—even the tablet. Given that design systems fit firmly inside of the world that Kay and his peers built, it’s worth listening to him.

Once the magic of design system standards enables both private and open source development for cross-platform use, design systems will most likely reach new heights of functionality and popularity. Whereas siloed development requires talented people to reinvent the design system anew for each employer, standards-based design systems might easily plug into a passionate community that will add capabilities to our nascent tools.

Taking inspiration from Kay and the PARC maxim—“The best way to predict the future is to invent it”—I’ll sketch out a stretch goal for the future of design systems and tools in the paragraphs that follow.

Virtuous cycle—plugging into the feedback loop

Often, our design systems contain components that aren’t tracked in any special way. Without special consideration and considerable development effort, the design systems team is blind to the usage statistics and performance metrics directly associated with the system. To gain insight into design systems, teams must manually track which components each product team uses, and then try to glean usability information from product team UX research and performance metrics.

At Airbnb, we see data from the large proportion of our native apps, which now use design system components. Connecting these stats to user metrics lets us know which components might be underperforming and deserve special attention.

Similar metrics also have an internal benefit. Dashboards containing usage data aid the internal perception of the system among product designers and engineers alike. It’s easy to imagine that tracking the use of a design system can go beyond recording end-user impressions (views) and interactions. Even analyzing the usage of documentation, design files, and other internal tools can lead to insights that better enable product teams.

But why should such insights be limited to just a few companies with the resources to create similar tooling? A module could be built for just this purpose. It would track where canon components are used in product and then apply a flag to that component. These flagged components could be polled, and usage stats could come straight back to the design systems team. The insights would then be used to improve internal tools and the system itself.

Layout aware

Another promising direction would be for our components to become somewhat layout aware, and then declare their intended use to both the system at large as well as sibling components. Given this new super power, design system components could now communicate where they should generally be used and then share information about what types of data they generally contain. Even a simplified implementation of this functionality would help designers instantly swap abstracted data sets to, for instance, see how translation might affect the layout of a particular component given a longer language like German or a right-to-left language like Arabic.

This awareness might even go a step further with a given component stating the kinds of screens or interactions preceded by its own display, and again which kinds of interactions or screens should follow upon user interaction. This awareness would enable predictive assembly.

Predictive assembly—a pattern tool

Because each component now sends messages about where it’s typically used and what type of data it usually contains, we should also be able to see existing components predictively assembled into screens. A future tool might allow the product designer to view a particular component, click a randomize button, and see the component in situ with other components arranged in an order that more or less semantically makes sense.

By allowing designers to up-vote particularly useful component groupings (or patterns), a layout aware tool featuring predictive assembly—perhaps better described as a design system pattern tool—could become an instrumental way in which product designers quickly discover repeatable patterns in the system. With just a single click, a designer would be able to compose an effective solution made of many components and export the basic design for any project. Moreover, with the advent of standardization, design systems could become plug-and-play with compositions composed by predictive assembly, allowing for a quick way to assess the integrity of a given design system.

Predictive assembly would enable the product manager, developer, or product designer to provide a set of data and ask for a menu of pre-assembled screens that display the data. We could then choose the best option, only correcting the layout if needed.

It’s worth noting that if we get particularly good at predictive assembly and consult the right minds to take it further, we will soon find ourselves in a world where machine learning provides artificial intelligence for plug-and-play design systems. Among many other things, we might witness the birth of a world where phone users could eliminate branded apps, preferring a locally installed design system that could spin up UI without needing to load templates over the network.

As designers, we continue to rely on intuition, performance metrics, and user research to create products. If a large percentage of our users can complete a task and proceed to the next stage in the flow, then we generally call the design successful. We use templating languages to add options to a design so even more users reach their goals. But by connecting design systems to artificial intelligence, we could achieve a step change in customizable UI. Instead of designing products that work for most users, systems design and AI will apply specific solutions for specific individuals.

Designers should prepare now by discovering a bit about machine learning, reading about the breakthroughs enabling AI today, and finally, thinking about how ML could impact design tools.

Conclusion

As digital product designers, we’re asked to ride the waves of change in our industry. People just like us helped small development teams create apps for desktop computing in the 1980s. In the late 1990s, other designers formed a coalition that pressured large software companies to unite front-end web development through the web standards project. In the mid-2000s, we focused on communication and user-generated content while developing patterns for creating web apps, and just a little later, all our work was available in mobile form factors like the iPhone. Now, after nearly 4 decades of designed computing, design systems and AI are shaking hands—presenting us with new opportunities for innovation at scale.

Every designer will now be asked how they might change custom, one-off design solutions into reusable components that grow the system. We’ll have to think more holistically, and work collectively to develop and learn a new set of tools.

How can we work together to improve our workflows and better scale design? What should be in a design system standard, and what kinds of tools could be built if such a standard existed? How will design systems and AI combine to create extremely customized interactions for end users? There are many questions, and each answer points to a possible future. What I love about design is that it enables each of us to explore the ideas we feel may have the biggest impact, and project our ideas outward and into the future. Innovation is certain.

About the Authors

Marco Suarez
Product Designer, InVision
Katie Sylor-Miller
Staff Software Engineer, Etsy
Roy Stanfield
Design Lead, Airbnb
Diana Mounter
Design Systems Manager, GitHub
Jina Anne
Design Systems Pioneer, Independent
Design Systems Handbook
Design Systems Handbook

Design better. Faster. Together.

Transform your products with the world's leading digital product design platform

GET STARTED NOW