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 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.
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.”
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.
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.
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.
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.
Here are a few steps to consider when thinking about how to break or change a design pattern:
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.
- 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?
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.
- 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?
Understand Front-end Capabilities
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.
- 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?
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.
- 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.
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
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.
Designers identify and solve problems that clients and end-users have using a repeatable process: 1. Define the problem. 2. Gather information. 3. Generate ideas. 4. Develop solutions. 5. Test and gather feedback. 6. Improve the design.
A good problem statement clearly and succinctly defines the problem(s) to be solved. Problem statements are important because they help everyone involved in a design project work towards a common solution.
Ideation (also called brainstorming) is the third step in the design process, and it simply means to conceive ideas that could potentially turn into solutions. It’s important to generate many ideas during ideation, even far-fetched ones, as they could prove helpful later in the design process.
A design language is a resource used to help reduce redundancy and improve continuity in the way designers approach common design problems. Within a design language, a range of UI and UX components are defined, such as tables, typography, lists, and form elements.