On Wed, Mar 5, 2008 at 3:52 AM, Stew Dean <[EMAIL PROTECTED]> wrote: > On 04/03/2008, Celeste 'seele' Paul <[EMAIL PROTECTED]> wrote: > > > 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. > > > > Thoughts? > > > > ~ Celeste >
I found the book "Communicating Design <http://www.communicatingdesign.com/>" to be useful. In our company, during initial brainstorming meetings, we involve the developers and discuss the design. They are also the product experts and will usually have a lot of feedback to give us. Based on the discussions and feedback, we develop screen designs and get an agreement on the design. We then use the screen designs and create html mockups and include detailed documentation that lists how the links will behave, what components are disabled, what page will launch when a button is clicked, is it a action button, how a show/hide button helps the user and so on. Documenting the decisions we made is important so we can look back at the end of the project and recollect where we made important decisions and why the design looks and behave in a certain way. We made it a practice to even document the original design and alternate designs we came up with and why it was rejected by the product development team. This helps us to recollect what tasks need to be tested or answer any questions that executives/users have during or after the release. Finally, before handing the document off to the developers, we review the document with a teammate or with a member in the development team who we can trust. This will help us to make sure if the design is explained clearly and information is organized well. In our company, the QA uses this design spec to test the product interface. If there are multiple audiences for the document, organizing the content in to different sections and indicating who should care about this section (using visuals cues like different people icons for developers, project managers and so) will help people to ignore stuff that is not relevant to them. ________________________________________________________________ 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
