This is something I deal with nearly every day - especially as we have 2
week dev cycles between product releases.

Everyone who has replied to the thread already has provided sage advice.


Let's put it this way...


most developers never get more than a few bullet points for specs or as
inputs while many others still work in environments of "oral history" where
deliverables are verbally explained but never written!


So, when a developer gets design docs and/or functional specs - even
imperfect ones, they are often happy.


The more you involve them in the process and the better you are in
communicating with developers as part of your deliverables, the smoother the
experience will be but to actually have something written that illustrates
what the desired output should be and explains what happens if 'user X
clicks on a button' and man, you'll be ahead of the game.



On 3/4/08, Celeste 'seele' Paul <[EMAIL PROTECTED]> wrote:
>
>
> One of the things I am interested as a designer is how we can work better
> with
> developers.  If you are lucky enough to work as part of an in-house team
> you
> probably (hopefully) have a stronger relationship with developers than
> those
> of use who only come in as consultants.  Often as a consultant, the only
> contact we have with the development team might be through the project
> manager or technical lead.  So we must rely on our design documents to
> deliver our message.
>
> Although we would all like our deliverables to be developer-friendly, they
> don't always turn out that way.  Many of the guidelines I've read for
> creating client deliverables focus on impressing the client and not
> necessarily getting work done.  Sure, they also try to present the
> information in a way that readers can understand them, but project
> managers
> are a much different audience than developers who are actually doing the
> work.
>
> 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
>
> --
>
> Celeste 'seele' Paul
> www.obso1337.org
> ________________________________________________________________
> 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
>



-- 
--------------------------------------------------
www.flyingyogi.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

Reply via email to