I'm in the process of creating a set of UI standards for a large enterprise, for multiple overlapping services (websites, mobile apps, internal systems and extranets).

This is the first time I've attempted something on this scale and would appreciate some guidance on:

1) Naming
What is the 'correct' name for such a document / process? I've sold it as 'UI Standards' but I'm not sure if that is the common term? Is another name more commonly recognised?

2) Content
This will apply to a number of B2C, B2B and internal interfaces. What are the appropriate subjects to cover and level of detail e.g. for forms, validation messages, colours etc

3) Format
The obvious output format would be a PowerPoint with examples. Is there a better way? I'm anticipating this will be a regularly updated and growing document, so some sort of Wiki might be better?

Instead of PowerPoint a Word Doc with a proper table of contents and plenty of prose to explain things beyond screenshots is probably preferable.
–
jlarsonJan 14 '13 at 17:07

1

Why not Google Docs? It can be properly formatted and it's way of sharing ensures that everyone gets the latest copy.
–
CristianJan 15 '13 at 20:13

Cristian, yes that's a great idea, the kind of thing I was thinking. Sadly our IT department has seen fit to bar anything Google 'Drive' so Google is a no-go. Perhaps something similar though.
–
Chris ReynoldsJan 15 '13 at 21:53

1

Concerning point 3), have you thought about pdf? it is way more portable. Personally, I rejoice when a company sends their project specific guidelines in pdf format. Another way to go might be an online documentation on your intranet or other private area that you can share to people involved in those projects.
–
konturJan 17 '13 at 6:37

iOS Human Interface Guidelines is a good one. I also like BBC User experience guidelines in which they not only show the standard UI controls but also the bigger picture. The document is also selling the idea behind a common component library. http://www.bbc.co.uk/gel

Nike named their component library "NikeOs". You could view small parts from it on this portfolio site: http://www.publichue.com/

Power point could work as an initial delivery but consider if the approach of the Twitter bootstrap project isn't better. Everything is explainad with live front-end code. This is a much more convincent way as a final delivery. The client could interact with the components and getting a great understanding of how it will behave and the programmers could just grab the pieces that they need. If you need to present it you could just grab a sceen shot or do a screen recording without the need to recreate the stuff. http://twitter.github.com/bootstrap/

When we have done digital identity manuals we have divided the document into these chapters:

There is no "correct" name. There are multiple guides out there with differing names. "UI Standards" is a perfectly reasonable name for this document.

There is no "correct" information to include. The information that you should include depends on the maturity of user experience in your organization and how well-defined each of these items are. After all, just because you have a document doesn't mean that everyone is magically going to follow it. If UX is a small part of your company or doesn't have a lot of traction yet, start the guidelines small with content that everyone can agree on, and grow it over time to include more content and more depth. Don't let the perfect be the enemy of the good -- it's better to release good information now rather that wait until you get all of the information that you think you want in there. Once you've established a standard and have released it out to the wild, you're going to get feedback about it (cases you didn't cover, unintentional ambiguity, requests for additional examples, changes in supported devices, ... ), so being prepared for feedback will help you update it in ways that better meet the needs of the users of this document.

A static PowerPoint or Word or any other type of document is definitely not the right way to format your output. As you've already identified, you want this document to be updated in the future. Using a static document runs a high risk of someone getting out-of-date information because they got an old version of the document emailed to them. Instead, your guideline should have a home somewhere on your internal network that everyone who needs it has access to it, and you should send the link to this location to anyone who asks for it. A wiki or an internal website or other method can meet this need. For my current team, our method for sharing standards is a website sitting on a Drupal backend, since such a content management system allows for easy updating. Since this is an enterprise document that could contain sensitive information about your company's future plans, you should make sure that its home is one that meets your enterprise security guidelines, which probably precludes anything in the public cloud like Google Drive or Dropbox. Also, wherever you store it should be searchable within your company's intranet, so its home should include ways of finding it by names that aren't necessarily the one that you ended up giving it ("UI guidelines", "UX guidelines", "website standards", ... ); this also likely precludes its home being in the public cloud.