The practice and art of style guides

27 Apr 2010 - 9:32pm
4 years ago
6 replies
872 reads
Michelle Bacigalupi
2009

I have the opportunity and task to create a style guide for our existing product. Our company is set to double in size this year and as the only (so far) XD person scale is an issue. I've started research style guides but thought I'd ping the expertise of this group as well. So here are a few questions...

 

  • What organization, in your experience, has worked best? 
  • What pitfalls do you wish you had avoided?
  • How did you go about getting participation and buy in?
  • How did you set it up? 
  • Did you make it printable?
  • Is including a place for comment / annotation useful?
  • Any other thoughts...

 

Tks!

Michelle

Comments

27 Apr 2010 - 11:16pm
Krystal Higgins
2008

Ah, style guides.  They can get very complex, very quickly.  There's no one right way to do it, but if it helps:

Historically, I've organized my style guides in a multi-page PDF because I've needed to print somewhat high-quality books, while supporting section/appendix links for people viewing electronically. 

Depending on the project (site vs. app, etc), I'll break the guide down into sections that are based on one screen, state or scenario.  The first page(s) of each section show plain, un-annotated screenshots of the subject matter ("Overview").  Any text introductions are placed on a preceeding page.  Sometimes, though, at the beginning of a section, I'll include a "big picture" image showing where that particular page/state/scenario falls in a larger sitemap or flow.

Subsequent pages keep these screenshots in the same location on the page, but with ~25% opacity (on a white background).  I then layer design/specs/content guidelines/behavioral guidance on top of the semi-transparent screenshots (for example, a structural wireframe).  The effect for someone viewing this is similar to flipping sheets of marked-up vellum over an original image.  It's proven good for quick reading because readers don't have to grapple with constantly-shifting page elements--they have an anchored frame of reference based on the "Overview" page.

If some behavioral guidelines are best done by showing one of my prototypes, I'll provide a link to them from the document.  I do the same for any references to prior research/etc. 

I generally set up a "master" document that contains all the spec types on separate pages in each section.  However, I export a a smaller document for each disciplinary group using only the pages that are relevant to their needs. For example, I will only export the content specs for the content owners.  This has overcome one of the biggest pitfalls that I've seen when creating style guides: trying to make one document work for everyone.  I just don't think it's sensible.  Especially since the one document could be a good 120 pages.  Good table of contents or not, nobody is going to bother to read that. 

Best of luck!

28 Apr 2010 - 1:15am
ofilippelli
2010

I have implemented a Wiki document  "Style Guide" It works great! Start fleshing out the bigger sections first, then the individual widgets.  Having a smart TOC helps a lot, use the main page to list all the main sections in your style guide such as "home page", "About Us", etc. then create individual pages for each asset in this list and link them. Each individual page gives you the chance to show the UI with all the necessary callouts, such us Font size, color, background, etc.  Also allows you to give a summary explanation of the functions and details of this UI.  I have created links from the individual parts of the UI to the actual CSS code that defines it.  Developers have very little questions.  Between this Style Guide and the Requirement document we have reduced communication problems and conflict. Suerte! :-)

28 Apr 2010 - 11:41am
William Hudson
2009

Michelle -

My experience of style guides as documents (electronic or printed) is that they tend not to get read. Consider instead providing a prototype web site/web app/desktop app in the style that is wanted with explanatory text in place. For web-based approaches, developers can actually copy and paste from the style guide as necessary (possible, but not quite so easy with desktop solutions).

Regards,

William Hudson Syntagm Ltd Design for Usability UK 01235-522859 World +44-1235-522859 US Toll Free 1-866-SYNTAGM mailto:william.hudson@syntagm.co.uk http://www.syntagm.co.uk skype:williamhudsonskype

Syntagm is a limited company registered in England and Wales (1985). Registered number: 1895345. Registered office: 10 Oxford Road, Abingdon OX14 2DS.

-----Original Message----- From: ixdaor@host.ixda.org [mailto:ixdaor@host.ixda.org] On Behalf Of Michelle Bacigalupi Sent: 28 April 2010 03:51 To: William Hudson Subject: [IxDA] The practice and art of style guides

I have the opportunity and task to create a style guide for our existing
product. Our company is set to double in size this year and as the only (so
far) XD person scale is an issue. I've started research style guides but
thought I'd ping the expertise of this group as well. So here are a few
questions...

 

  • What organization, in your experience, has worked best? 
  • What pitfalls do you wish you had avoided?
  • How did you go about getting participation and buy in?
  • How did you set it up? 
  • Did you make it printable?
  • Is including a place for comment / annotation useful?
  • Any other thoughts...

 

Tks!

Michelle

(((P

28 Apr 2010 - 8:35pm
John Judy
2009

Our UI is primarily used as embedded software on custom hardware.  So in order to maintain some consistency, I've developed variations of the design for use on the different combinations of hardware and software capabilities.  Up till now, all  of our style guides have been in the form of PNG's or PDF's but I really like Apple's UI development guide or the Wiki idea.  The difference in hardware / software also helps distinguish different brands that might use the same underlying architecture.  Since we only share this internally with our parent company, there are no print restrictions.

john

28 Apr 2010 - 8:29pm
John Judy
2009

Our designs primarily for embedded hardware / software scenarios so the style guide is based on the capabilities of the various combinations.  Typically, we've done the PNG images or PDF but I like the idea of a more interactive version such as Apples wonderful developer guidelines and the Wiki page. 

john

29 Apr 2010 - 8:15am
philipbrook
2008

Hi Michelle

Best leave what and how until you know more about who and why...

Define your audiences and demands of their role  - e.g. a brand manager doesn't need the kind of detail that a front end developer would because the tasks they perform to achieve successful outcomes in their respective roles are different.

Defining what a successful outome is for someone in a job role will help you formulate a simple and persuasive argument as to why budget should be apportioned to create something. e.g. to maintain the updates to site X over the next 2 years, CSS team Y need to be able to manage A. B and C sections of the site. To do this they will require markup to the pixel level of templates, modules and elements as follows (list goes here). The risks of not doing the guide for CSS team Y are (list goes here).

Define the context of use, then define an appropriate delivery mechanism and create a level of detail  that is appropriate - e.g. a designer in Brazil may want to download example comps from an intranet hosted by the head office in Frankfurt but his/her creative director may simply need a 3-screen powerpoint deck with examples of style usage in situ that they can refer to or share with the accoun team they work with.

Remember the old saying: a stitch in time saves nine? Fundamentally, style guides are preventative managment tools so make sure the budget holder knows that implications of not doing the work. If you can articulate that in terms of money at risk, that's good because they will listen all the more intently. Sometimes saving someone personal hassle at work will be a key: "to help you manage your brand across 3 regions we think solution X will reduce phone calls and emails to you simply by (insert ideas here about what content in the styleguide will answer the questions people always phone about)."

PB

Syndicate content Get the feed