A few questions on style guides / systems and pattern libraries such as https://www.lightningdesignsystem.com or http://rizzo.lonelyplanet.com/styleguide/design-elements/colours.

Style guide are the talk of the UX/UI town, benefiting these teams in allowing them to focus on solving wider challenges away from day to day governance.

I'm making the case for such an approach right now but meeting some resistance from multiple parts of the company I work for so would like to argue the case on a few fronts including UX and IxD.

So my questions.

Style guides how do they support and inform your front end development and practice?

What makes for a solid guide, what should it include and outline, importantly what looks good but actually proves quite useless?

When working with such guides what benefits and savings are commonly seen in your area of responsibility?

In a collaborative workspace who manages or commits change and updates?

2 Answers 2


In my experience, usefulness of style guide / UI component documentation will hinge on a number of factors:

  1. Size of your development and design organizations
  2. Number of web-based products they build and support
  3. Diversity of designs required for these products
  4. How centralized or de-centralized product development teams are. (Governance model)
  5. Quality of development team, turnover rate, and offshore
  6. Politics

Something like the Lightning Design system can bring tremendous benefits. It is great for organizations that need to support large, but few applications-based tools, has large number of development staff spread across multiple time zones, low designer-to-developer ratio, and tight, centralized governance model.

I work for a Fortune 50 company and manage something similar for our internal applications, and I would find the Lightning Design system too restrictive. It is heavy and too much to take in for building smaller applications quickly.

So we built a system that does the following:

  1. Gets the product, design, and development team up-and-running quickly without reinventing wheels.

  2. Enforce consistency in design and coding patterns, but not slavishly so.

  3. Allow applications that use the patterns to 'lag' behind, and not break when there is significant update to the patterns.

  4. Built in allowance for design and development team to customize if the project requires it.

We built a two-tier system: Global level + App level. The global level styles and components are light, and contain just basic things like form layouts, grid (optional), header, paragraph, base tables, etc. App level styles and components have more specificity, and can differ from project to project. This structure allows teams to be not 'stuck' with globally mandated patterns for everything. Instead, they can pick and choose best patterns from library from other applications, or create a new one. (most end up doing former).

Flexibility is key. Unless it's the CEO/CIO/CTO directly maintaining and enforcing the standards and patterns, not everyone is going to be happy with them. So to drive adoption and remove reservation, having a flexible system with governance model is key. Start small and scale up.

  • Thanks for the answer, a couple of further ideas to incorporate. Jan 20, 2016 at 8:26

More than anything else, style guides provide a vocabulary. Words like "menu" have a rather ambiguous definition, while "list inside a Material Design navigation drawer" is very clear. Having a common vocabulary means better, faster, cheaper communication. It also means there's something you can type into a search engine or ask about on a message board.

A lot of style guides have a lot to say about helping inexperienced users, but fall short when it comes to experienced users. You don't want to create an excellent experience only on the first day; you want the product to continue to delight users as they get deeper. Experienced users need filterable and sortable reports, charts, spreadsheets, HTML entry widgets, and many other complex widgets. I would look for style guides that go deep.

Perhaps the best way for you to get traction with your idea is to create and promote a common vocabulary within your company based on both the style guides and any particular components your company often uses. You will hopefully be able to communicate better as a result.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.