This is a great example of the way I think it should be done. On the style guide I'm currently working on we do it very similar fashion. We have the general overview for global items and then individual components broken out with visual examples as well as code samples.<p>I also have been working on a sandbox where you can bring in each component on the fly and test it in a sand boxed environment. This allows us to quickly prototype new views and components. Also let's us catch more of those browser specific bugs as mentioned in the article.<p>The style guide and sandbox share the same components, so when you add a new component it appears in both. Then there are the master LESS files which are also shared, that can easily be moved into production.<p>It's our job to make it as easy as possible for the team to come up with an idea and move that vision to reality. Having a strong style guide with consistent standards I think is really important to that.<p>Thanks for sharing the article!
I totally agree with the idea of having a style guide. How do you educate non-technical people (customers) on style guides? Style guides seem technical in nature so I'm not too sure how to succinctly explain to a customer that UI/UX decisions should be based around guidelines instead of "what feels good"