Hi Celeste, I work with an in-house dev team and find they are truly grateful when I document a handful of details in addition to the general broad brush-strokes of wireframes, layouts, etc:
- Error and status messages, especially when a consistent word order format is used. - Dimensions of images and graphical assets. - State charts of complex controls (you click this here and that lights up there, except when this other deelie is held down). What these have in common is they're all head-scratchers that take the poor developer out of flow and make them puzzle over what really ought to happen in a situation. They have to stop being a developer and start being a designer. I know (from trying to switch back the other way sometimes) that this is a difficult leap to make quickly. Some simple web forms get total documentation of a quickie Visio wireframe drawing and a page of accompanying text and that's it, everybody's happy, but more complex rich client components may end up with many pages of detailed docs plus some sort of prototype to play with. Oh one other thing I've noticed is that product managers and marketing folks love to extract high-level feature lists from development requirements docs and use them for their own nefarious purposes. So I've been putting this information in tables lately in an intro section to make it easier for them. Michael Micheletti ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
