3 Answers
3

There are four source of information to integrate to make a style guide:

Existing Applications and Organization Documentation

Review applications your organization currently produces as well as other products used by your users. You are looking for two things:

Similarities and differences among applications. Identify things that are de facto standards (e.g., an icon for a particular function) that should become a guideline and also things that need standardization (e.g., the same function having two different icons depending on the app).

Obvious and suspected bad design. Identify repeated design features that you think would cause usability problems that you want your guidelines to eliminate. Also keep an eye out for clever designs that help users.

This also includes reviewing corporate documentation and meeting with marketing personnel to identify purely aesthetic features that need to be standardized to establish a brand.

Existing Design Standards

Your guidelines can cite existing standards or design patterns, such as the Windows UX Guidelines, but you can’t count on everyone reading them or even using them. Nonetheless, you should only cite, not reproduce, existing standards in your guidelines except for serious blatant violations you uncovered in your applications review that warrant special attention.

Mostly you want to interpret relevant guidelines for the kinds of applications your organization makes. For example, the web guidelines at Usability.Gov say to “Put important, clickable items in the same locations, and closer to the top of the page, where their location can be better estimated.” In your guidelines, you can specifically state whether a side-bar or top-margin menu will be used, what links (or kinds of links) go in the sidebar menu, and what order they should have.

Platform and Technical Capabilities

Your guidelines need to be consistent with the technology your organization uses. Particularly for web apps, what you can do depends on what exact development platform your developers are using. For example, there’s no point specifying when and how to use expanders when the developers’ library doesn’t include expanders. If you’re unfamiliar with the details of the technology, then meet with developers and discuss what is and isn’t feasible. You might be surprised at what they can do.

User Research Results

You may need to do some research and usability testing for certain guidelines. These could be things you suspected would be problem in your initial review of applications, but weren’t sure, or things that are difficult (but not impossible) to implement –you want to be sure it’s worth the effort. Observe users using existing applications or test them on prototypes or demos for new applications or technologies.

When writing up the guidelines, consider the usability of the guidelines themselves:

Provide a short summary of highlights (e.g., an annotated illustration of a typical window). Almost no one is going to read your entire guidelines, so provide something quick they can look through to get the most important points.

Organize, link, and/or index it like designers and developers think. For a given design or development task, your readers should be able to get to the relevant guidelines quickly and go through them like a checklist. Look at how your organization divides work for clues on how to organize the guidelines.

Provide plenty of illustrated examples. This draws the readers attention, informs with a quick glance, aids interpretation of text, and, let’s face it, it’s easier to copy something than make it up yourself. Given you can expect designers and developers to copy the examples, make sure your examples are fully compliant with all your guidelines, not just the guideline you want to illustrate. Make sure bad examples are clearly labeled as bad examples.

Test it on designers and developers. Give some a simple design task and see if they can find and use all relevant guidelines. Get feedback from them on how useful and helpful they find it. If it isn’t easy to use, they won’t use it.

Be on hand to answer questions about it when it comes time for developers and designers to get to work. Advertise yourself as the Guideline Guru.

I think that Michael's answer is excellent. One word of caution though: evolving and changing an organization's culture is just as important as establishing guidelines. This can only happen slowly, over time, e.g. by emailing colleagues occasional screen snapshots of bad design (preferably others, not your own colleagues'), holding a brown bag lunch with a presentation, etc. You really want them to be on-board with you and to not feel like the guidelines are some constraints coming from Mars.

This may or may not apply to your organization, but I thought it's still worth mentioning.

Sure, you can find more item for the list but this is the way i've followed. Also keep in mind that "corporate identity" docs are also helps a lot. World famous companies and universities shares their docs on web.

This comment is completely tangential, but, you don't need to put radio buttons inside of a label tag in order to make the text trigger a state change. If you use the for attribute on a label and specify the radio button id attribute value, then it will do the same thing.
–
jessegavinSep 27 '11 at 15:52