From: "Celeste 'seele' Paul" <[EMAIL PROTECTED]> > Does anyone know of studies or other research that explicitly looks at how > developers are using design deliverables in practice? Particularly > integrating things such as wireframes in to functional specifications. Or > even if developers "get" the wireframes and mockups we give them. I've found > that developers prefer annotated slides or a big numbered list of issues to > having to read anything big, but those types of things don't look as nice as > a fully written final report for the project manager.
Some opinions/questions: 1. Why only have one deliverable? If you're convinced developers want something diferent from what the client liason wants, design your deliverables that way. Have a section in your spec marked "For developers" or create two seperate documents for the two different purposes. 2. By far the most common thing I've seen developers do with design documents, if anything at all, is hold up screenshots in the printed doc next to the screen and work to make 'em match. In fact I've had many programmers tell me they skip through the spec, and mostly focus on the screens. Like Rob suggests, make sure any screenshots you have are labeled with font names, Hex codes for colors, font sizes, pixel widths, etc. to make it as easy as possible to get those details right. The easier you make those precise details to understand, the higher the odds the developer will actually do them. 2+. Do an informal usability study on your deliverables - Seriously, have you ever watched someone actually use what you make? Or gotten feedback from them on how it could have been more useful? Or gone back later to see how much of what was in your deliverable actually made it into the final release? If you treat your delvierables like a user experience, you can apply tons of basic UX techniques to your specs, prototypes, wireframes, reports, etc. 3. Ask, early, to have at least one meeting with an actual developer, even if it's with the project liason from your client also there. That will give you a chance to ask the developer directly how they like to work, what they're most concerned about and what the best way is to help them with your talents. Even a 5 minute meeting will make it more comfortable to follow up later and ask questions. Design documents are worthless without a relationship behind them - there are always assumptions and interpretations and without a relationship there is no effective way to resolve them. Initiate contact, ask for feedback, and follow up later to ask if there are questions or problems. 4. Every consultancy and client are different - so if you're not sure how the stuff you make is being used on any project, go find out. It's entirely reasonable for you to ask your clients about this, since the more you know about how your stuff is used (even if it's being mostly ignored) the higher the odds you'll make something more useful next time. -Scott Scott Berkun www.scottberkun.com ________________________________________________________________ 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
