I am reading Lean UX right now, and there is an idea inside I have never read before.

It is about style guide.

I would like to implement that but with as small a foot print as possible for the beginning.

I am a software developer. I usually work with a graphic designer who has no experience with HTML/CSS. He usually produces a design either in psd or ai.

How do I create a style guide that is easy for a non-tech graphic designer and myself to use for collaboration?

I want the style guide like a living documentation. Preferably it should also include some HTML/CSS code of the elements that I can easily copy paste.

Do I

  • go find a server and install a wiki?
  • use Google docs?
  • use something else?

I read this UX style guide techniques but I want something for a small team of 2-4.

  • 1
    Put it on paper in a very big font and post it on the wall. If you find your style guide doesn't fit on the wall in a font easily readable from each designer's desk, consider that you may have too many rules and/or too many details... – Marjan Venema Jun 8 '13 at 9:50
  • related and interesting, google's new visual asset guidelines: behance.net/gallery/Google-Visual-Assets-Guidelines-Part-1/… – obelia Jun 9 '13 at 1:09

I have experience of three different tools for creating style guides:

Confluence The first style guide I implemented was built using Confluence. It was more a design pattern library, containing patterns and best practices for the most common UI design problems. Each pattern contained an example image, description how it works and why it should be used, and related design files. It was mostly used by designers, devs didn't find it that useful as there were no code samples on how to implement them.

WordPress blog with Pea.rs theme At some point we evaluated pea.rs, an open source WordPress theme that makes WordPress blog a pattern library tool. Devs somewhat liked it as it uses CSS & HTML for the pattern examples that developers can use in the code. However, it didn't support using Twitter Bootstrap in the examples not jQuery, and designer didn't like it because it lacked some key features that she'd need like file upload for design

Patternry Now we're using Patternry, a hosted style guide tool. What we like in it especially is the ability to use Twitter Bootstrap in the pattern examples, ability to customize the pattern templates, and live editor for markup & styles, making it easy to mockup designs in the browser. What we don't like is that the product is still a bit immature, some of the features don't work as you'd expect, it doesn't have version control and it doesn't integrate to any external version control system.


Based on my experience of producing a few style guides in various formats (html, wiki, pdf, doc), I found simple static HTML pages provided the most flexibility. It's usually developers who are driving creation of web style guides, because they are the primary beneficiary. Consequently, the burden of creating and maintaining one will likely fall on you initially, so you should start with the simplest method, which is static HTML pages.

As you get buy-ins from other stakeholders down the road, it's not difficult to transfer all the content onto Wiki or Confluence for non-developer contributors.

Starbucks' style guide proves that you don't really need a fancy wiki/collaboration software. http://www.starbucks.com/static/reference/styleguide/

  • I'm a fan of live style guides as well. You can actually see, right there on the page, what the elements will all look like, and get access to the underlying code either via a textbox, or just viewing source. – Dave Luciano Jun 8 '13 at 22:54

I personally like to use wiki (we use Confluence) for this. I prefer using the name "Design Guide" rather than "Style Guide", because it is more broad, and our guide has pretty much everything that you need to use our widget library.

  • We have a wiki page with all the UI components listed, each described in detail in their own page that anyone can edit or comment
  • In the page we have overview, design comp with measurements, interactions defined, recommendations when to use the component, related components, dev instruction for using the component (the API for the widget library), and the more detailed implementation described for reference.
  • In addition to this, since we use JIRA for Dev tickets, we list all the tickets that link to this page. The Dev tickets do not describe the design, they refer to the Design Guide or pages describing individual designs (which are more disposable, where as the Design Guide is always kept up to date)
  • We started building the Design Guide gradually, when ever we need new components in the UI

I hope this helps you to get started. We use this in our team where we have one UX desinger/PM (me), two front end devs, and a gfx designer. The design guide helps the branding and other parts of the company also to keep track of what is going in the front-end development and our new UIs

  • Thank you for your answer! So basically you started off using Confluence? – Kim Stacks Jun 10 '13 at 3:06
  • Yes. I must stay that Confluence is really good, especially if you are using other Atlassian products with it. In general, it is good value compared to the time that you would otherwise be using with hacking through a free-to-use Wiki solution (been there done that!). – Skuirrel Jun 11 '13 at 18:15

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.