While it may seem like a new way of approaching digital workflow, the concept of a design system is not “new” to creative industries. At the core of any design system is a language of design patterns that solve common problems a designer might face.

The idea of a pattern language originated from architecture and urban design over 40 years ago and can be applied to just about any design discipline.

Design language elements quote from Christopher Alexander, author of A Pattern Language. The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over.

Design systems are a popular talking point in today's world of digital products, but using a systematized set of repeatable design solutions isn't a new idea.

Design systems like Material Design are a trendy topic, yet a systematic approach to design has been integral to magazine publishers for decades. While flipping through the pages of any major magazine, it is easy to see that each section is uniquely defined as a template with common layout, fonts, colors, etc.

The design patterns used for page sections allow text and images to be consistently and efficiently arranged in a way that complements a publication’s creative vision.

When looking at competitor magazines, it is easy to see how the design language of one compares to the other.

Magazine design system components

For decades, the magazine industry has relied on design systems to quickly format written and visual content with consistency.

If they haven’t already, designers from numerous industries will soon incorporate a design language and templates into their workflow. For digital product designers, this topic is evolving, and many are learning to design from pattern libraries within complex systems for the first time (or even help define them).

There is added complexity when aligning software design patterns with a front-end codebase, which can make learning a design language feel overwhelming.

Design Languages Are Holistic

A design language, as with any language, is intricate and contains nuances that may seem confusing to learn at first. This is why it helps to think of a design language as a complex system “composed of many components which may interact with each other.”

To understand a complex system, it is important to think about the design language holistically:

  • Start with a bird’s eye view of how design impacts a brand or business.
  • Then, contemplate the role of design with cross-functional teams and other designers.
  • Finally, consider how design affects the product and users at a particular moment.

This holistic perspective emphasizes a systematic way of thinking about design workflows, and it allows a design language to be easily applied when solving specific problems.

In practice, a design language is a resource used to help reduce redundancy and improve continuity in the way designers approach common design problems. For example, a common problem faced by product designers is, “I need to place a call to action for users to click.”

Amazon button design patterns

Design systems are particularly effective at solving recurring product design problems, like the need for a call-to-action button.

This is something that has been solved before, so instead of reinventing the wheel (or the button), the design language would define a reusable button “design pattern” with preset properties, such as color and shape, along with guidelines for best practices.

A digital product design language is usually a cross-functional resource with the goal of improving workflow efficiency and collaboration for teams.

In some cases, the language is extended to a live pattern library which is connected directly to the front-end codebase and metric analysis of patterns. This type of complex system with various dependencies makes a holistic approach to problem-solving quite necessary.

Complex design patterns quote by neuroscientist Miguel Nicolelis. With its billions of interconnected neurons, whose interactions change from millisecond to millisecond, the human brain is an archetypal complex system.

Depending on the product, team, and resources, there are varying degrees of design system detail and complexity.

The awesome thing about learning a design language is that teammates are typically quite passionate about the interface and interactions used to define a product. Learning a new language is generally a challenge, but it can also be an immersive experience that bonds a team!

Common Questions to “Design” Systems Thinking

Fluency with a design language will ensure the quality of the system through evangelism—which may include:

  • Training new designers;
  • Mentoring junior employees and managing contractors; or
  • Working directly with engineers to refine the product front-end prior to a release.

Through these collaborative efforts, a designer will be able to ensure that guidelines for the system are upheld or refined based on need.

Whatever the duty, there are a couple of common questions about design systems thinking that a designer may be held accountable for:

What should I think about when designing within a design system?

Depending on the complexity of the design system, it is important to start by taking a comprehensive approach to the problem being solved. Consider the button example from before.

If the color is preset to be #1f9efc and a designer makes it #1b3e9b without first consulting other designers using the same pattern library, this could cause a system error.

When working within a design system, think about how the problem being solved will impact the entire product development cycle. In many cases, there will not be, and should not be, much impact because the pattern library has already been validated.

If a problem being solved is new to the design system, there could be an opportunity to evolve the pattern library and help define a new design pattern.

When the system is evolving, it is new to a team’s workflow. Here, flexibility is needed because design patterns will iterate over time. However, while it is easy to change the color of a button, the greater system complexity must be considered at all times.

For this, it is helpful to define a taxonomy for organizing the design system and pattern library. The terminology used should be easily understood cross-functionally.

This diagram offers a high-level hierarchy for how the pattern library of a design system can be organized.

By grouping design artifacts into commonly understood topics, the pattern library allows the system to operate across team workflows and develop communication in the way that design patterns are spoken about.

How do I know when I need to break a pattern or create a new pattern within a design system?

The need to break or create a new design pattern usually depends on the maturity of the system. When a design system is evolving, the patterns frequently change. As the system becomes established, there should be a change request process in place to help ensure continuity and quality.

The complexity of a system is also important to consider. If changing a pattern impacts other designers and teams, the process may take longer to implement and often requires some deeper level of effort or resources (e.g., updating design language guidelines, pattern libraries, or the front-end codebase).

Generally, a pattern library is not meant to be rigid. Think of it as a toolbox that can solve problems and complete tasks. If all attempts to design within the boundaries of the pattern library do not achieve project goals, intuition may lead to the search for a new tool—or perhaps a change to the existing pattern.

Take a look at the diagram below. A general rule of thumb is that identity and elements, which are the basic brand building blocks, rarely change because they help define the brand and design artifacts.

Design system typography and branding

Most large organizations have separate style guides for brand related elements—especially logos, colors, and fonts, which don’t change frequently. For elements such as buttons, this may or may not iterate depending on the evolution of the design language, but these too have less frequent changes due to their connection to all aspects of the product.

Design pattern changes or new patterns often arise at the component and interactions level because these define user flows and feature sets. It is common for new user flows to be defined in a product roadmap, especially when rolling out features.

New design patterns will have properties that are similar to patterns already defined in the library (such as fonts and colors) but may require interface updates or interactive states that are in addition to the design language.

The product manager or product owner working with a designer will provide requirements for new features which align with business goals. When deciding to break or create a new design pattern, remember the theory of complex systems, and ensure the solution is a shared decision.

Design system pattern language library

An example page from a design system style guide.

Here are a few steps to consider when thinking about how to break or change a design pattern:

  1. Ensure Quality Control and Continuity

    Remember that quality is a shared product goal. Everyone is responsible for ensuring the design system is doing its job.

    Always take that holistic approach, and think through the potential impact of breaking a pattern or creating a new pattern.

    Ask yourself:

    • Is breaking a pattern the only way to solve my problem?
    • How would other teams be affected if I break this pattern?
    • What would happen to the pattern library if I break this pattern?
  2. Communicate with Collaborators

    Talk to designers and cross-functional team members to see if anyone else is having the same restrictions. Learn everything about platform requirements and how a proposed pattern would work across the entire product family.

    Ask yourself:

    • Who else has worked on this product or platform?
    • What are the best practices of the platform I am designing for?
    • Who can I talk to that may be able to help with my decision and recommendations?
  3. Understand Front-end Capabilities

    Learn what is possible for front-end implementation. If the change is simply an update to HTML/CSS/JavaScript properties, it usually doesn’t require breaking a pattern or creating something entirely new.

    Rather, it could be a simple update to the design language guideline. As a designer, it is important to work closely with front-end and potentially find ways to collaborate weekly or daily.

    Ask yourself:

    • Has the front-end team been looped into this design update?
    • Is the change I am considering a front-end update?
    • Is there something missing from the best practices guidelines?
  4. Validate the Decision

    If it is determined that a new pattern is needed, the decision should be validated with collaborators and end users and aligned with business goals.

    If front-end components are tied to metrics, a quick A/B test will assist with validation. If not, conducting usability tests will work great.

    Ask yourself:

    • Does our team have a change request process for validating new design patterns?
    • What do I need to do to validate my decision?
    • Does this decision create a new user flow, or is it an added feature?

Same Work, Different Mindset

When designing within a system, it’s crucial that product designers adopt the big-picture mindset that is required for decision making. The principles of a complex system and systems thinking will help designers as they grow in their careers. The same is true for the process of building from a pattern library.

UI design patterns

From Mailchimp to Mozilla, the mindset and methodology used to create a pattern library can be applied to a diverse range of digital products and applications.

These approaches are useful for starting a new design language or contributing to an existing one because once the mindset is in place, the systematic methods become, well, “systematic.”

Knowing that other industries and design disciplines have used similar methods of streamlining workflows for many years provides product designers with an excellent point of reference for best practices.

At the end of the day, designing within a system will not completely transform the way work gets done. Sure, there will be some new tools for connecting and managing complexities, but ultimately, it is a shift to a holistic mindset that will truly help improve workflows.

• • •

Further reading on the Toptal Design Blog:

Understanding the Basics

What is meant by design pattern?

A design pattern explained simply is a reusable solution to a common design problem in design systems. For example, a common UI design pattern might define the shape, color, and style of a call-to-action button.

About the author

Darcie G. Fitzpatrick, United States
member since February 10, 2017
Darcie is a design leader with a couple decades of experience and a knack for building something out of nothing. She has a passion for user-centered methods and iterative Agile processes, an innate sense for business strategy, an affinity for customer-friendly journeys and intuitive user experiences, and an aesthetic eye for polished visual design. She facilitates the research, validation, direction, and branding of greenfield products. [click to continue...]
Hiring? Meet the Top 10 Freelance UX Designers for Hire in December 2018

Comments

arsalan
Design Systems and Pattern Libraries Increase UX design quality, consistency, and designers’ efficiency Design Systems—also known as 'pattern libraries' or 'component libraries'—promote quality, consistent UX design across products; and expedite the work of designers, developers, and anyone else working on a website, application, or any digital design. This course teaches how to create, manage, communicate, and govern component libraries for maximum success. Topics Covered Introduction—What is a design system or pattern library? Terminology UX design Front-end code Benefits Optimized designs Faster design Faster development Shared vision with designers and stakeholders Consistency of design Organization When is the right time to begin a design system? Adaptations for teams of different sizes and compositions Staffing and skill sets Strategy and Tools Leverage libraries available on the web Customize existing libraries available on the web, or at your organization Use existing tools to build a library Build a library from scratch Atomic design How to build from the atomic component level up to pages and systems Determining technology stack Frameworks: Angular, React, and more Software management Optimization tools Deploying a component library Designing Internal and external feedback Communicating Training Ensuring success and avoiding failure Maintaining a component library Governance Managing roles and responsibilities with application engineering Updating Retiring Adding and editing patterns Roles and access When to update a pattern Rules for updates Usability testing patterns Code review Organizational model for team Component team centralized v. decentralized: pros and cons Front-end work centralized v. decentralized: pros and cons
comments powered by Disqus
Subscribe
Free email updates
Get the latest content first.
No spam. Just great articles & insights.
Free email updates
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Relevant Technologies
About the author
Darcie G. Fitzpatrick
Designer
Darcie is a design leader with a couple decades of experience and a knack for building something out of nothing. She has a passion for user-centered methods and iterative Agile processes, an innate sense for business strategy, an affinity for customer-friendly journeys and intuitive user experiences, and an aesthetic eye for polished visual design. She facilitates the research, validation, direction, and branding of greenfield products.