4

It seems like only the larger companies working on development and design frameworks are producing interactive documents that provide information about the visual and interactive design components/elements. I am making this assumption because in projects where I have advocated for the creation of such assets, it is usually met with much resistance due to the perceived effort required to create them, and the perceived value of such assets in guiding the design and development effort. That's not to say other companies don't create them and maintain them internally, but certainly they are not see out in the wild.

With the relaunch of Google Design (including Material Design guidelines), changes to the Atlassian Development Guide and even Uber's new brand guide, shouldn't we be moving towards a web based and interactive form of documentation because it suits the way that UX design and standards evolve?

Some interesting references that people might like to have a look at as well:

http://patternlab.io/resources.html

http://livingstyleguide.org/

UPDATE: Styleguidist and Storybook have definitely popularized the more interactive types of style guide / design systems being published on the web as part of the design and development process

Improve this question
2
  • 2
    While your question is really interesting, I don't think it's possible to answer other than with personal opinions. My humble opinion is that those big companies are offering these guides to the public (guidelines, APIs, etc) while most of us work in closed environments where the guidelines are the documentation. But even then, I guess more or less any team has these guidelines. As a PM, I need to preserve consistency between projects (specially design) or the coders will go nuts, so we have some rules and guidelines set. I assume any team has this kind of guidelines
    – Devin
    Jun 5 '15 at 0:12
  • @Devin Based on your comment, I think my question is asking firstly why these guides are not produced more frequently, and secondly why these guides are not of a more interactive format. Most teams that I have seen working in an 'agile' environment appears not to consider documentation at this level to be necessary or important, and so I would like to understand why this is the case.
    – Michael Lai ♦
    Jun 5 '15 at 0:18
4

I think the answer is simple: smaller design teams don't have the time to do it. Everyone wants to put out their own style guide. Uber's is pretty good. Google has a new style guide for Android M. The big players have them, and they have them for two reasons: to promote their styles (which is an extension of branding) and to publicity. Even design teams, that love to share their work, get little out of it except for exposure. But if you're Google or Apple or Uber, then you're willing to let your extensive design teams work on a public style guide? Why not.

The other thing is that plenty of companies don't want to share their style guides. Big companies do it because they want people to use their styles used. It makes the difference between an app made for Android or...well, just an app.

Real teams don't have the luxury of tidying up their style guides for perfection. They don't have the luxury of 'finalizing' them either because nothing ever fully finishes. Eventually you just have to ship, and if you're lucky then it was close to what the style guide had at the time of delivery. Only for a big company that can put the resources and time into making a perfect style guide...that's why they're the only ones who put out style guides usually. The rest of us are just struggling to get good products out.

Improve this answer
3
  • Whether it is shared or not is a different issue to if the guide is useful or not. It is easy for small teams to think that time is better spent on something else, and in some cases that's probably true. But my experience in most projects is that if you don't have time to do something now, chances are it won't be done later either; also, if something is worth doing then it is worth doing from day one. What's your experience and why would you advocate or not advocate its use for your organisation/team?
    – Michael Lai ♦
    Jun 5 '15 at 1:04
  • Not quite, but I'll edit my answer. When I make style guides, they're never fully complete. There are missing pieces, there are small discrepancies, there are deprecated flows. The list goes on and on. A style guide that you don't update is a style guide that you didn't finish, unless you work for a company that has no plans for growth or change.
    – Jamezrp
    Jun 5 '15 at 1:14
  • Point taken. But an even better reason why it should be interactive instead of being static. In fact, you should almost be able to derive the style guide from the product, the same way you should be able to derive documentation/API from the code (I think).
    – Michael Lai ♦
    Jun 5 '15 at 6:05
1

As Devin says in his comment, this question will get answers based on personal opinions and observations. These are mine.

In my experience there is a difference between a brand guidelines(like Uber's) and overall design guidelines. There are a lot of public brand guidelines out there and most of them to allow third parties to use their brand and while doing so they should do it the right way.

Overall design guidelines or product design guidelines is another thing. The questions answer by those is how the general look and feel of a product in a specific environment or ecosystem should be.

A great example of "complete" design guidelines is Atlassian's. It consists of three main features; product design, brand and user interface. It's used by their own teams for developing new features and products but also to help the plugin developers to build their plugin with the "Atlassian look and feel". This will help the end user transition between an official Atlassian product and a third party plugin.

The same arguments could be applied to Apple's iOS guidelines or Google's material design guidelines. They all want the transitions to be as gentle as possible and keep an unified feel of the ecosystem.

A thing to remember though, these guidelines should not restrain a developer or a designer - they should help and be looked as what they are, guidelines.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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