Design System

Design systems are an amazing tool to enable teams to design and build consistent, scalable products quickly and efficiently. During my time at City National Bank, I led the Roxbury Design Team, and we evolved Roxbury from a static single brand single platform design system to a multi-brand multi-platform design system.

This was the first project I was assigned at Herbalife. My task was to evaluate and make a recommendation for a unified style guide.

Summary

A design system is essential to the success of an organization’s brand as well as its user experience. It facilitates thoughtful, intentional design by providing checks and balances between content structure and content itself. A design system provides consistency and cohesion to an interface and user experience. From one designer to ten, anywhere in the world, it is scalable, intuitive, and efficient. It provides a common voice in which cross-functional teams can effectively communicate. To build a proper design system, User Experience is recommending the adoption of Brad Frost’s “Atomic Design” methodology.

Process

  1. Interface Inventory
    • Everyone helps outs
    • ½ hour to an hour screenshot your vertical
    • Synthesize data, determine default patterns
    • Present back to group
  2. Determine common language as a group
    • This helps provide a unified front as well as the start of training the organization on terminology we use
  3. Determine what is in and out
    • Some patterns are not in, some are old we need to find out what is what
    • People may be using old patterns, this helps unify team, as well as inform team of new patterns they may not know about
  4. Set up review process (formalize it)
    • If we don’t have consistent reviews, we won’t be able to effectively communicate to each other or the rest of the organization. We are building a living document, not a set it and forget it one. It is the origin story to the rest of our story as a team
  5. Set up submission process (formalize it)
    • Great ideas come from everywhere. We should welcome them all. Even the not so great ones, because it helps confirm what we are and are not
  6. Version it
    • Versioning is critical to communications as well as providing an historical document. It helps us refer the team and the rest of the organization to current and perhaps deprecated patterns. As we make awesome new stuff, we have a sunset feature baked in to the process
  7. Show it off
    • This is something our team should be proud of. We should show it off to everyone we can. Making it public will also help keep us in check and give us incentive to actively maintain this
  8. Maintain in parallel with verticals.
    • Content informs design, and vice versa. The design system should reflect that
    • Once adopted, the system should be a living entity. In order to facilitate this, the system must live in parallel to production. This includes versioning like sunsetting deprecated patterns as well as enhancement promotion
  9. Regular review and evaluation of submitted patterns
    • In order to ensure our design system reflects our products and vice-versa, regular reviews of the system and products must be done. This interval and specific criteria will be determined as well as a product owner
    • Criteria for adding a pattern to the system should be determined by a governing body, not just a single owner

Naming Conventions

As a way to start speaking a common language in code, IDs and classes should be standardized. There are many options available. For example, separation of presentation layer, javascript classes and targetable HTML elements with the use of IDs could look like this:

  • thisIsAnID
  • _thisIsAJSClass
  • this-is-a-style-class

It is recommended that IDs are used for javascript only, and not used for styling. (See this article for reasons this is a good practice.) BEM model? (May be too heavy for our purposes.) What are the current naming conventions? Is there a system in place? How do we train people on this naming convention? What if it changes?

Versioning

The UX team recommends the “Semantic Versioning 2.0.0” system for versioning the design system. This is an industry standard, and is the generally accepted versioning system for software, application, and web development. Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes
  2. MINOR version when you add functionality in a backwards-compatible manner
  3. PATCH version when you make backwards-compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. All patterns should be labeled with version added as well as version updated.

Future Facing

Currently, Design and development work from separate code bases. We share design resources when we can, but development is not required to use these. This is inefficient. The design system should become the source of truth for all products, as well as be robust enough to be used in production. The eventual goal of the design system is to be used by both design and development.

  1. Phase 2 – add patterns to system, design review, figure out submission approach, version initial design system, finalize training approach.
  2. Phase 3 – Start training approach, rollout to organization, evaluate ways to integrate in to development.
  3. Phase 4 – Development integration

Training

The design system is the origin story of our brand and product stories. Since this is the case, everyone in the organization should be aware of it and know how to use it. To accomplish this, a training program should be put in place. This training should encompass design assets like personas, journey maps and user research data in to a UX research database. It should also include the pattern library, use cases and additional documentation relevant to UX.

Users

  • UX Designers
  • Dev UI
  • Developers
  • Third Party Vendors
  • Project Managers
  • QA

Potential User Stories

  • As a [UXD, DUI, Dev, TPV], I want to look up a pattern to see if it is in use.
  • As a [UXD, DUI, Dev, TPV], I want to get the html, css and js to a specific pattern for use in my project
  • As a [] I want to see how a pattern is used.
  • As a [], I want to see if patterns I am using in my projects are old and not used anymore.
  • As a [], I want to see what Herbalife’s branding is.
  • As a [], I want to be able to speak the same language as [] when referencing specific patterns.
  • As a [UXD], I want to have my design prototype code match every other designer’s code as closely as possible.
  • As a [], I want to have design prototype code match production code as closely as possible.