Enterprise UI standards

Question

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?

Any other guidance would be appreciated.

Answer 1

This would probably be called UI Style Guide or UI Guidelines but there is no 'correct' name. Apple calls theirs 'iOS Human Interface Guidelines', Microsoft calls theirs 'Windows User Experience Interaction Guidelines'.

Both covers pretty much everything that needs to go into a document like this. More examples are:

http://www.webstyleguide.com/wsg3/index.html

http://bitkb.appspot.com/?p=27001

Answer 2

A lot will depend on how mature UX is in your organisation. Consider:

• Key areas where UX can make the most impact - focus on those first
• User testing your standards: who are they aimed at, and do they work for those people?
• Having standards that work across multiple channels - e.g. printed literature as well as online
• Getting buy-in from senior people who can champion the work
• Having worked examples available to show the standards in context
• Working with developers to make the standards easy to implement (e.g. if you have CMS authors, building the standards into common components)
• Working with Brand to give your standards a louder voice
• Version control: being clear which version of the standards should be applied to any given piece of work

Answer 3

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:

1. Navigatioin
2. Controls
3. Forms
4. Audio and video
5. Typography
6. Windows, dialogs and layers
7. Advertising
8. Social features
9. Layout and grids

More about working with humongous web project could be read in the book "Modular Web Design: Creating Reusable Components for User Experience Design and Documentation" by the talended Nathan Curtis. http://www.amazon.com/Modular-Web-Design-Components-Documentation/dp/0321601351/ref=sr_1_1?ie=UTF8&qid=1358333546&sr=8-1&keywords=modular+web+design

Answer 4

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

2. 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.

3. 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.