Design Language System

While in development, product, design, and engineering teams use a variety of project management methods. As projects and teams grow, management becomes increasingly difficult. Let’s examine how design language systems make life easier in such situations.

Presently, many companies with significant market shares are exclusively growing by producing software. For others, software is an essential part of their revenue. Moreover, big firms (Atlassian, Dropbox, Linkedin, etc.) increased their design teams by an average of 65% in last 12 months. (design in tech 2017)

Six major tech companies have doubled their design hiring goals in the last half-decade. (TechCrunch)

Consistency is one of the essential topics of user experience. Maintaining consistency in the big project is often a problem in itself.

While the scope of a project begins to grow, productivity and speed might encounter some problems that adversely affect it. Some of those include:

• Poor communication between product, design and engineering teams.
• Differences between design outputs.
• Lack of cohesion and structure in code leading to product performance issues.

Generally, engineering teams have specific methods for measuring productivity and standards. For example, Agile, code review, code coverage, unit/integration test, etc.

Design works differently. The management methods are more abstract, and there’s not much control or restriction on the development process. Pattern library or style guide are used to define some standards.

Thus, every new designer and every new part of the project increases chaos in the process and slows down velocity.

Yet, the engineering teams code in the direction of the design coming from the design team. This will repeat itself and will present to the user as animation, component, interaction with various features.

On the user side:

• Bad user experience
  Inconsistency in the product will affect the sense of confidence and familiarity in the product.
• Performance
  As mentioned prior, repetitive pieces of code that cause structure and performance problems.

Design language system

The design language is a collection of reusable functional elements (button, form, header, etc.). The more descriptive parts are icon, color, typography, animation, etc,. These elements of the interface are defined under certain standards. It can also be described as a form of expression of the product itself.

Design creates harmony on all platforms when a good design language system is used. Maintaining strict design standards can help to raise confidence and familiarity with users.

Fundamentals

We can assume that the design language is a real language. It can’t build suddenly; it develops step by step with the brand over time.

In the development process, it is necessary to see inconsistent parts. Then develop retrospective regulations or newly-applied elements. These must be consistent with the current structure. By following some basic principles and practical ways, teams can be confident that the system has evolved continuously.

Terminology

Various concepts are used by teams to create their preferred design standards.

• Functional pattern, Component: Reusable tangible elements. Buttons, form fields, navigation, etc.
• Perceptual pattern, Styles: This is more abstract than the functional pattern. It will emotionally enhance message perception. Color, typography, animation, etc.
• Pattern library: Documentation of functional and perceptual patterns.
• Style guide: Documentation of standards for using pattern library. This includes logo usage and space adjustments. It also includes examples of best practices, and information about the development process.

Shared language

Design language needs to be understood by all teams involved so that the project can progress holistically in a consistent way. Another way to look at this is to think of those who speak the same language. It is much easier to communicate what is needed to a person that uses the same language, than one who doesn’t.

The design language will answer the following questions. These are frequently asked by the design and engineering teams during the project:

• What shade of blue are we using?
• Can you redline this for me?
• Where’s our logo?
• Was this pattern used somewhere else?
• Can you rebuild this, it doesn’t match the design?
• What’s the latest documentation?
• How do we build this pattern?
• Where’re our components?

For a great design language system to succeed, a holistic style guide must be used. This guide includes product, design and engineering components and guidelines must be used. The following criteria must be observed for this:

• Efficiency
  Component, color, and, element definitions must be easy to understand. This can be done by naming with visual loudness or metaphors.
• Best practices
  The best practices for the use of tools should be determined by code samples.
• Brand feel
  The feeling that the brand wants to reflect on the user side. This could be lively and energetic, playful and friendly, decisive and certain, balanced and stable, calm and soft, etc,. This should be done accordingly with animations and color uses that will make things a little easier.
• Color & Iconography & Typography
  It is important to use color, typography, and icons to support the message to given visually. Designing icons suitable for brand sense will strengthen the meaning of the message.
• Pattern Library
  A pattern library is a collection of user interface design elements.
• Animation
  One of the fundamental topics of delivering the brand feel to the user.
• Accessibility for stakeholders
  The style guide must be accessible to everyone. If possible, it can be displayed in an easily visible place for everyone in the office environment. This can help them to see the missing parts and reinforce the familiarity with team members.
• Accessibility for user
  Once the color and component definition are in place, creating them according to a11y standards, which allows you to reach a wider audience.
• Guide
  How the team will contribute the processes must be explicitly stated.

How to start?

Everything sounds good until now, but if you do not plan your processes, in a short while you may have to deal with solving a complicated task.

While creating your design language system, it is beneficial to act according to your team culture. You must set criteria that everyone is ready and willing to follow.

Rules (Strict — Loose)

Strict rules: There are precise rules and processes in place that are rigorously followed.

Loose rules: Brand feel and the utility of the page take priority over perfect visual consistency.

For instance from Airbnb;

• Standardized specifications.
• The design is fully synchronized with the engineering team.
• Strict process for introducing new patterns.
• Comprehensive, detailed documentation.

From TED;

• Simple sketch over detailed specs.
• Simple documentation.
• Managing downsides and choosing a direction.

Organization (Centralized — Distributed)

Centralized model: Rules and patterns are managed primarily by one group of people.

Distributed model: Where everyone who uses the system is also responsible for maintaining and evolving it.

Parts (Modular — Integrated)

A modular structure offers the possibility to work with entire engineering teams. Thus it could quickly produce products suitable for all platforms. If you are creating conceptual designs from a message sense, the integration method will be more useful.

Styles come and go good design is a language, not a style — Massimo Vignelli

Conclusion

The design language system provides a standard for brand communication between teams. It also allows you to specify and make available the feelings or messages you want to give to the user.

Thanks to Turgay Mutlay for illustrations 😉

Resources

Design Language — Wikipedia
How to Monetize Happiness — Harvard Business School
Using Visual Loudness for Better Wayfinding — Tom Osborne
Animation in Design Systems — Sarah Drasner
Integrating Animation into a Design System — Alla Kholmatova
Building a Visual Language — Airbnb
Contrast Checker — Webaim.org
w3.org — Web accessibility initiative
Accessibility Developer Tools — Chrome extension by Google