I've recently started a major redesign for a large web-based financial tool. To aid future development, I'm planning on generating a UX style guide that outlines best practices for things like forms, page layouts, animations, etc...
The existing application is a big jumble of forms with little grouping or organization. I can see a few major categories, (Object CRUD forms, static data, user session management controls, etc...) but there's a lot of very custom functionality that doesn't fit the mold.
The company I'm working with does it's development overseas, and this documentation is intended to support future development. I'm not looking to design the most amazing UX ever, I just want things to be functional. What's the best way to communicate designs to remote teams?
Here's my question:
What's the best way to approach a big messy project like this? (Major groups first, then focus on each custom function? Do you even include the custom functions in the documentation?)
Answer
Example Style Guides
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. 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. There’s also guidelines for web sites, (e.g., usability.gov), but these will generally be less useful for applications.
What to Include
For 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). I cover both in a style guide.
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. However, you may want to include components or abstractions of the function that are commonly used throughout the tool or suite.
The Deliverables
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. A style guide should make their job easier, not harder. 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. 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).
This implies the product may employ multiple media. Chances are the “main” product will be some sort of hyperlinked document, which has obvious advantages for reference material. 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. Frankly, creating the guidelines is only the start. Most of the work is promoting and enforcing the guidelines. Try to get the time, budget, and organizational support for that.
No comments:
Post a Comment