As a newly hired UX specialist, I'm planning to create design guidelines for developers and QA testers in my organization.
The problem is I'm not sure what's the best way to approach this. Shall I start writing it from scratch? or maybe collect stuff from design pattern libraries? I'm not quire sure.
Any suggestions?
Appreciate your input :)
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.
Eric Schaffer of HFI has written an excellent step-by-step guide aptly titled How to Develop an Effective GUI Standard.
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.
I've just created such a doc for my company. At the beggining it was really hard to find out where to begin.
I searched for samples but found nothing useful. Then I start thinking about how was I designing. Then wrote down as a list... (For web apps)
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.
Hope it helps.
for attribute on a label and specify the radio button id attribute value, then it will do the same thing.
Sep 27, 2011 at 15:52
To me a good design guideline, this is borrowed from the google sprint booklet, should answer the question:
what do we, as an organization, stand for in terms of design?
If you notice, every successful app out there such as airbnb, uber, gmail, twitter... they have an authentic and recognizable style that users can unmistakably identify with and that serves the purpose of the service being provided. For example, Uber, a black nifty upscale feeling suits "for those for which time is more important than money". Airbnb: a feeling of warmth, cleanliness and safety, gmail...
In my opinion, the first page of a guideline book should answer that fundamental question, otherwise, no matter how good the UX or how detailed is your UI guideline is described (here is Apples'iOS Human Interface Guidelines for ref.), your designers will not know in which direction to go.
