User interface (UI): content scrub
UI scrubs are now my favorite part of the product cycle. I joined the DPM team too late to participate in the UI scrub for DPM 2006, so this is my first experience with it. It's not quite as much fun as puppies, but close.
The approach our content team took was to divvy up the new UI sections and work through them individually, then meet to review each section and the suggested changes as a team. Redundant? Not at all -- the extra eyes in the group review notice much more than one person can, but the work done in the individual review provides the group with an "expert" who has already thought through most of the issues, looked questions up in the specification, researched applicable standards for an item, and so forth.
We look for much more than grammar and spelling, of course. The whole reason for user interface design guidelines is to achieve a consistent interface approach that works best for users. So our discussions included the order of check box options, for example, and the placement of imperatives, and what goes beneath the name of a wizard page.
We've done two UI sections so far as a group, and each one took about four hours. The only thing I can think of that would make the scrubs even more fun would be to have the program manager or developer in the room to explain things when we get in a muddle, or have it all wrong...
Comments
- Anonymous
February 09, 2006
At what point in the product cycle do you do your UI scrub? It sounds like you're working with a product that's pretty far along in the development process. Is this before or after beta? - Anonymous
February 12, 2006
This is still fairly early in development, Harry, and way before beta. It's one of those delicate balances -- scrubbing early enough so that usability tests and beta get feedback on a more polished UI also means that we probably have to redo work later on as code changes dictate changes in the user flow. But I think it's worth it. Plus it forces us to think through a lot of scenarios and interactions and how we'll expose them to the user, how we want to present it, how we want to position terms, all before we really get the documentation going.