It just didn't tell me what to do, how to do things in practice. I know there's an accepted answer, and I usually do quite agree with Michael, but still this does bug my mind for two days. Try to get the time, budget, and organizational support for that. Most of the work is promoting and enforcing the guidelines. Frankly, creating the guidelines is only the start. However, there may also be a summary quick reference guide or checklists, printable posters to promote the guidelines and highlight key features, a library of style-guide-compatible templates / patterns / CSSs, and seminars and workshops (possibly conducted remotely) for you to personally introduce the guidelines and show their advantages for the designers and developers.
Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. This implies the product may employ multiple media. You can apply your UX skills to making the guideline deliverables by interviewing and observing your designers and developers to find out what will work for them (in your case, you may be limited to phone interviews with your developers better than nothing). If it’s too hard for your users to find the right guidelines for a particular case, or learn and understand them, or implement them, they’re not going to. A style guide should make their job easier, not harder. Ideally, the ultimate form of the style guide should be what works best for your users –not the tool/suite users, but the developers and designers that will use the styled guide to make the tool. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite. The idea of a style guide is to avoid you having to design everything yourself, so if a custom function only exists in one form, don’t include it in the style guide. There’s also guidelines for web sites, (e.g., ), but these will generally be less useful for applications.įor the basic approach, see answers to How did you create design guidelines for your organization? To answer your specific question, I make a distinction between “elements,” or pieces of a UI (records, fields, layout, forms, command, and feedback), and “functions” (what some might call “patterns”), which assemble multiple elements into a standard UI for a common step in the user’s tasks (e.g., login, query, reports, undo, sort, zoom, help).
Many topics in these guides are not relevant to form-oriented UIs, but most of the guidelines for controls, messages, and dialog boxes have compliments for forms. For example style guides applicable to applications, you can leaf through with the usual platform style guides (e.g., Windows, Apple, Gnome) for the organization, issues, and topics you may want to have.
0 kommentar(er)
