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 :)
Answer
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.
No comments:
Post a Comment