Creating and Establishing a Design System for Your Enterprise

In the first blog of this series, “How to Make a Design System Work for Your Enterprise”, we introduced the concept of an enterprise-wide design system and discussed some of the key values that can be achieved by successfully implementing and evolving a design system across your organization. Today, let’s take a look at some of the best practices to follow as you kick off the effort to create and establish a design system.

Getting Started: Initial design system as standalone project? Result of an initial project?

The question that arises when undertaking the creation of an initial design system is: Do you create the design system as part of a specific project or do you start it as a “stand-alone” project?

Typically, it’s difficult to get funding approved for the creation of a design system on its own, so tying the initial creation phase to a specific project is a more practical approach. However, a single project doesn’t offer the wide lens necessary to provide awareness and understanding of larger enterprise-wide challenges.

The Answer Is Both…

The reality is that to succeed you need to have one foot in both approaches:

  1. Develop a quick inventory of existing components, patterns, and templates – This requires some basic familiarity of the universe of digital products currently offered. A quick inventory of components and patterns across your products will serve as the foundation that will inform future iterations of the design system.  Once the initial inventory is complete, your design team can refine these elements to ensure a consistent experience and include them in your “starter” or “minimum viable” design system.
  2. Tie the actual initial creation of the design system to a specific project – As you design and build the initial base components, try to approach them in the most generic way possible.  Aim to solve for the needs of the project at hand in a way that can be re-used for other projects.  You may find that you have specific patterns or components that need to be built for a purpose within a single product only.  Not every part of your design will be reusable across all products but the majority of your design will be reusable especially when it comes to common interactions such as buttons, lists, grids, drop down menus, form layouts and navigation patterns to name a few.

The key to these approaches is a shared understanding that the design system is iterative in nature and, as such, it will evolve over time. We’ll spend more time on key aspects of evolving the design system in the last blog in this series “Evolving the Design System”.

What Should Be Included?

As you start on the initial creation of this design system as part of a specific project there are several key foundational elements that need to be included:

  • Design Tenets – Guiding principles that provide the high-level design thinking that you will want to make sure is fully understood by all potential users of your design system. These will be different for each organization, but defining a set of six to ten core principles will set the stage for the proper use of the tools included in the rest of the design system.
  • Branding and Visual Assets – Include items like a refined color palette, approved icons, images and corporate logos, font families and semantic typographical hierarchies.
  • Patterns – Core sets of defined interactions that represent the specific user experiences you want to establish across your organizations. Examples of this might include search, pagination, navigational transitions, modes of interaction, animation, error handling and empty states.
  • Templates – Pre-defined layouts for the representation of common items like search interfaces, search results screens, customer profiles or product details.
  • Components – Building block items like data grids, cards, lists, tabs, form elements, headers, footers and more. These are the atomic elements on which the templates and patterns are constructed.
  • Working Code – This key piece can often be overlooked, but in order to maximize the value from the design system, all of the components, templates, patterns and visual assets must be built in working code. This code should be written in a way to elegantly transform the pieces of the design system across different form factors. This ensures that the design system is a living, breathing entity that can be easily extended across the enterprise with confidence and agility.

Establishing a Design System Team

So you now you have an idea of what to include, the next thing to define is exactly who will design and build your design system. Working with a partner to get the design system off the ground can be beneficial. An external partner can bring outside experience, expertise and proven processes to build momentum behind what can be a tricky project. At TandemSeven we have worked with large enterprise organizations across a number of different industries to create complex, configurable design systems to meet their specific needs.

Even if you start with an external partner, you will eventually want to develop the expertise internally to take ownership of the design system, provide internal direction on a project-by-project basis and evolve it over time.

What Roles Are Part of Your Core “Design System” Team?

This internal “design system” team should consist of a cross section of the following roles that work in collaboration with the wider business and development teams:

  • User Experience Architect(s) – Responsible for user research, journey mapping, ideation, interaction design and user testing.  This role will not only lead your design effort but will also work with the visual designer to identify patterns, components, and templates as well as to provide the framework for the design system tenets.
  • Visual Designer(s) – Responsible for visual design style, branding, and supporting front-end development with creation of visual assets.  This role will ensure that the patterns, components, and templates are visually compelling, consistent, and in line with and/or leveraging your visual branding standards.
  • Front-End Developer(s) – Responsible for translating the experience design into production quality UI code, creating all patterns, components, and templates as well testing to ensure browser, device and accessibility requirements are achieved.  This role will establish the basis for your design system that can be utilized across your enterprise.

Keep this group tight and small at first – in fact, we’ve seen this work successfully at larger global organizations with a core team of as few as five full-time members.

Single Approach or Product Families?

Depending on the breadth and depth of your organization, you may want to present a single design system for all digital products, or you may want to introduce the concept of product “families” as a way to provide some flexibility and configurability into your design system.

For example, the way you might present information for an internal productivity tool used for a back office team that focuses on loading and reviewing trade data will undoubtedly be different than how you might want to present information for an event microsite geared towards your external clients. Having a version of the design system dedicated to “internal tools” and a different design system for “event microsites” will allow you to have different design tenets, a more focused set of components, color palettes, icons, patterns and more.

By slicing and dicing your design system according to the product “families” that are germane to your organization, you can increase adoption and optimize the use of the design system.

Summing It Up

Creating and establishing an enterprise design system can be tricky. While it might easiest to create the design system from the ground up, it’s not usually a realistic approach given the time costs and weight of legacy applications that need to be supported. Establishing your design system within the context of a specific project – while being informed by having a wider view of the needs and challenges of the larger digital application landscape – will often prove to be a more successful path. Include the foundational elements in the first version of your design system, but count on adding and altering aspects of it with each use. Even if you start this process with an external partner, you will want to develop internal expertise and ownership of the design system in order to ensure adherence and proper use across the organization.

In the next blog “Communicating the Design System”, we’ll discuss ways to ensure awareness and adoption of your design system across the enterprise, including:

  • Ideal delivery methods
  • Naming and internal branding
  • Defining the audience segments for consuming the design system

In the first blog of this series, “How to Make a Design System Work for Your Enterprise”, we introduced the concept of an enterprise-wide design system and discussed some of the key values that can be achieved by successfully implementing and evolving a design system across your organization. Today, let’s take a look at some of the best practices to follow as you kick off the effort to create and establish a design system.

Getting Started: Initial design system as standalone project? Result of an initial project?

The question that arises when undertaking the creation of an initial design system is: Do you create the design system as part of a specific project or do you start it as a “stand-alone” project?

Typically, it’s difficult to get funding approved for the creation of a design system on its own, so tying the initial creation phase to a specific project is a more practical approach. However, a single project doesn’t offer the wide lens necessary to provide awareness and understanding of larger enterprise-wide challenges.

The Answer Is Both…

The reality is that to succeed you need to have one foot in both approaches:

  1. Develop a quick inventory of existing components, patterns, and templates – This requires some basic familiarity of the universe of digital products currently offered. A quick inventory of components and patterns across your products will serve as the foundation that will inform future iterations of the design system.  Once the initial inventory is complete, your design team can refine these elements to ensure a consistent experience and include them in your “starter” or “minimum viable” design system.
  2. Tie the actual initial creation of the design system to a specific project – As you design and build the initial base components, try to approach them in the most generic way possible.  Aim to solve for the needs of the project at hand in a way that can be re-used for other projects.  You may find that you have specific patterns or components that need to be built for a purpose within a single product only.  Not every part of your design will be reusable across all products but the majority of your design will be reusable especially when it comes to common interactions such as buttons, lists, grids, drop down menus, form layouts and navigation patterns to name a few.

The key to these approaches is a shared understanding that the design system is iterative in nature and, as such, it will evolve over time. We’ll spend more time on key aspects of evolving the design system in the last blog in this series “Evolving the Design System”.

What Should Be Included?

As you start on the initial creation of this design system as part of a specific project there are several key foundational elements that need to be included:

  • Design Tenets – Guiding principles that provide the high-level design thinking that you will want to make sure is fully understood by all potential users of your design system. These will be different for each organization, but defining a set of six to ten core principles will set the stage for the proper use of the tools included in the rest of the design system.
  • Branding and Visual Assets – Include items like a refined color palette, approved icons, images and corporate logos, font families and semantic typographical hierarchies.
  • Patterns – Core sets of defined interactions that represent the specific user experiences you want to establish across your organizations. Examples of this might include search, pagination, navigational transitions, modes of interaction, animation, error handling and empty states.
  • Templates – Pre-defined layouts for the representation of common items like search interfaces, search results screens, customer profiles or product details.
  • Components – Building block items like data grids, cards, lists, tabs, form elements, headers, footers and more. These are the atomic elements on which the templates and patterns are constructed.
  • Working Code – This key piece can often be overlooked, but in order to maximize the value from the design system, all of the components, templates, patterns and visual assets must be built in working code. This code should be written in a way to elegantly transform the pieces of the design system across different form factors. This ensures that the design system is a living, breathing entity that can be easily extended across the enterprise with confidence and agility.

Establishing a Design System Team

So you now you have an idea of what to include, the next thing to define is exactly who will design and build your design system. Working with a partner to get the design system off the ground can be beneficial. An external partner can bring outside experience, expertise and proven processes to build momentum behind what can be a tricky project. At TandemSeven we have worked with large enterprise organizations across a number of different industries to create complex, configurable design systems to meet their specific needs.

Even if you start with an external partner, you will eventually want to develop the expertise internally to take ownership of the design system, provide internal direction on a project-by-project basis and evolve it over time.

What Roles Are Part of Your Core “Design System” Team?

This internal “design system” team should consist of a cross section of the following roles that work in collaboration with the wider business and development teams:

  • User Experience Architect(s) – Responsible for user research, journey mapping, ideation, interaction design and user testing.  This role will not only lead your design effort but will also work with the visual designer to identify patterns, components, and templates as well as to provide the framework for the design system tenets.
  • Visual Designer(s) – Responsible for visual design style, branding, and supporting front-end development with creation of visual assets.  This role will ensure that the patterns, components, and templates are visually compelling, consistent, and in line with and/or leveraging your visual branding standards.
  • Front-End Developer(s) – Responsible for translating the experience design into production quality UI code, creating all patterns, components, and templates as well testing to ensure browser, device and accessibility requirements are achieved.  This role will establish the basis for your design system that can be utilized across your enterprise.

Keep this group tight and small at first – in fact, we’ve seen this work successfully at larger global organizations with a core team of as few as five full-time members.

Single Approach or Product Families?

Depending on the breadth and depth of your organization, you may want to present a single design system for all digital products, or you may want to introduce the concept of product “families” as a way to provide some flexibility and configurability into your design system.

For example, the way you might present information for an internal productivity tool used for a back office team that focuses on loading and reviewing trade data will undoubtedly be different than how you might want to present information for an event microsite geared towards your external clients. Having a version of the design system dedicated to “internal tools” and a different design system for “event microsites” will allow you to have different design tenets, a more focused set of components, color palettes, icons, patterns and more.

By slicing and dicing your design system according to the product “families” that are germane to your organization, you can increase adoption and optimize the use of the design system.

Summing It Up

Creating and establishing an enterprise design system can be tricky. While it might easiest to create the design system from the ground up, it’s not usually a realistic approach given the time costs and weight of legacy applications that need to be supported. Establishing your design system within the context of a specific project – while being informed by having a wider view of the needs and challenges of the larger digital application landscape – will often prove to be a more successful path. Include the foundational elements in the first version of your design system, but count on adding and altering aspects of it with each use. Even if you start this process with an external partner, you will want to develop internal expertise and ownership of the design system in order to ensure adherence and proper use across the organization.

In the next blog “Communicating the Design System”, we’ll discuss ways to ensure awareness and adoption of your design system across the enterprise, including:

  • Ideal delivery methods
  • Naming and internal branding
  • Defining the audience segments for consuming the design system
Interested in partnering with us?

Send a message and we will work with you to understand your needs.

UX360 - Enterprise Journey Mapping Platform

Power Platform

UX360 - Enterprise Journey Mapping Platform
Related Insights from Our Experts

2017-05-31T08:34:26+00:00