What to put into your Enterprise Design System

So, you’ve taken the decision to start a Design System and you're now ready to implement it. Good on you. However, don’t be surprised if at this point you start to feel slightly daunted by the sheer magnitude of the task at hand.

Rome wasn’t built in a day (day and a half, maybe).

Agreed, there’s plenty to consider and it’s imperative to get the foundations nailed down in the first place as, believe me, it can save any amount of heartache further down the road.

At the very outset, a Design System owner must bear in mind:

• Components

• Patterns

• Roll out

• Maintainability

• Any other business

Components

Components are the basic building blocks of user interfaces. Think of these as individual Lego blocks that you can use to create any design possible.

Examples of these would be text inputs, radio buttons, checkboxes and the like. These range in complexity from basic elements such as buttons to more complex instances such as cards. By taking a component-based approach to design and development you will be able to leverage a lot of time-saving in the whole creation process by utilising reusable design elements and code.

Because the components you design will eventually be created in working code, it’s vital to describe each one in your Design System documentation both visually and functionally, for example, specifying hover and active states for buttons and how activated menus will appear for dropdown menus. For effective component design, I like to work with the principles of atomic design in mind.

Patterns

Many people think patterns and components are the same thing. Wrong. The idea of a design pattern was introduced by architect Christopher Alexander. In his book "A Pattern Language", Alexander gives the following description:

“Each pattern describes a problem which 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, without ever doing it the same way twice.”

Patterns, by definition, solve the same common problem using a combination of components. They empower designers, and allow people to use their previous experience when interacting with a product. Because many design patterns are familiar to users, especially in the eCommerce space, they will enable a product to be understood intuitively.

Roll out

It's now the moment of truth and time to give your Design System to the rest of the team. Some applications such as Sketch and InVision allow for the creation of cloud symbol libraries, so if you're all using the same tool then it's potentially as easy as sharing a link. Before you do so though, just check that your symbols all resize in the way intended, if that's an option, and that all overrides are named sensibly. I would even go so far as to lock elements that can't be altered, such as specific icons.

The more cast-iron you can make this, the better, as you don't want designers having to break components or patterns away from the master instance too much, if at all, as that pretty much defeats the object of having a cloud library!

There will always be occasions where a pattern needs to be broken but think to yourself before you do so... am I using the right pattern/component anyway and if so, is this an update that could be made to the master or does it require a brand new pattern to be added to the library?

For non-designers, or people outside of your organisation, there's a multitude of options out there to share your Design System. I'm a big fan of the wiki, or microsite, where you can showcase every pattern and component visually with accompanying code snippets and functional descriptions.

Get your developers to develop a code library on the side and you can pretty much allow anyone to grab your code and build applications in the exact same visual & functional style (plus it's easy to update, but more on that later). What's not to like about that?

Maintainability

A Design System will never be set in stone, no matter how much you intend it to be. Like an ever-evolving organism it will change, mutate and develop as you begin to build and design real-life products and applications, so be prepared to adjust your patterns and components over time.

You may find during user testing that something doesn't quite work as intended, so you'll need to be nimble and adapt accordingly. Likewise, you may have overlooked a common component or find a new pattern that will come in handy down the road. Be prepared to add those elements in and potentially re-design others to make them sit comfortably together.

A good Design System owner should be prepared to receive requests from their team and incorporate or debate accordingly. A monthly or bi-monthly review session would be an excellent time to moderate these requests in an informal setting where designers can bring new or updated elements to the party.

Any other business

So now, we're nearing the end of the process. You've designed all your components, developed those into patterns and documented how they will work and interact in real life. You've a solid process for distributing the system to everyone concerned and a plan to maintain updates and enhancements. There's now a few personal additions to any Design System that I like to make before I let it out to my wider team...

Artboards

You want everyone's designs to look the same right? So why stop at just giving them the individual elements. Artboards with a pre-defined grid can be a massive timesaver across organisations and save users having to set them up from scratch every time, or even worse, copying from incorrect previous projects. Create a master artboard with columns and baseline grid for all of your major breakpoints and house them somewhere accessible to everyone.

Colours

Yes, yes, everyone should know your brand's colours off by heart (in both hexadecimal and RGB) but it doesn't hurt to include them as colour swatches in your Design System in case anyone needs to quickly sample a colour. It's all about making life easy for everyone, so play the game.

Icons

You may be using a third party icon library such as FontAwesome so in order to maintain icon sizes it's pretty cool to include an icon symbol (perhaps at predefined sizes and in the correct colour) with an override allowing users to paste in the corresponding icon's keystroke. Saved someone five minutes? Imagine that extrapolated over a year.

Logos

The same rule applies to logos; you may have a master repository of EPS files, but can everyone place the logo at the right size with the correct amount of white space around it every time? Some pre-built symbols would help enormously, no?

Typography

Most UI design packages allow for the saving of text styles so do yourself a favour and generate the most common occurrences for your team. I'm thinking at least all header, paragraph and meta styles along with any other common typographical styles your product or application might employ.

Vertical spacing

Sometimes it's not the notes you play, but the notes you don't play that make a design sing. Specifying to designers how much space to allow above and below a paragraph of text, around form elements, around images, all of these things can play in a designer's favour and allow for the creation of a coherent visual style across teams. I like to include a few standard spacing symbols in my component libraries, just as a helping hand and companion to the standard baseline grid.

Conclusion

Bingo, you've done it. A fully formed Design System ready for release into the wild. You've considered every small detail you might need to develop consistent applications across a wider design team, envisaged how to get it out into designers and developers hands and how any updates and improvements would be handled.

And if you're still not convinced as to whether you actually NEED a Design System or not, maybe you want to have a read of this.

Happy UX-ing! :)