> > > > On Tuesday 04 March 2008 16:02:55 Ari Feldman wrote: > > 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. > > > I totally agree unless they are handed an 80 page report of 6 months of > research. And a cup of coffee. And some aspirin.
Size does matter but it should be gauged according to the complexity and type of project. I've generated some specs that are 500 pages and many are easily dozens. With the correct process in place, you can determine the right size to convey your deliverables in as well as the fidelity. It must be appropriate to the task/project. If size becomes an issue, you can always break it up into modules. This is how programs are written and the same logic can be applied to deliverables as often, multiple developers may share parts of a given development project. Some programmers will follow deliverables to the letter (both good and bad) while others will question what you've delivered either due to the lack of clarity or an unforeseen case or limitation. Your deliverables need not be cannon (unless you're Boeing) or have the luxury of time. Rather, deliverables must deliver the intent, outline the desired results and be flexible enough to be thorough without being overwhelming to peruse. Good communication between team members is a must regardless of your approach. > There are lots of things that "should" happen in a project -- clear > product > goals and documentation, communicating with developers, writing perfect > reports, lots of extras to tape on the wall -- but they don't always > happen. > Maybe it is just the capacity I work in (aka miracle worker) that nothing > goes as planned. I usually get called in to the middle of a project which > is > in serious trouble and get caught between backfilling necessary user > research > and "fixing it now". It is really about making the best of what you got > and > hoping your message gets across. And being thankful the client is > thinking > about these things at all. Welcome to my world. If I followed every formal step, we'd never release anything. With practice (and success as well as failures) you live, you learn and figure out how to make the best use of your time and resources to deliver the best documentation and deliverables you can while meeting your desired goals. Like many things in these disciplines, this is part art and part science with a little voodoo in-between. Is there a SIG for Guerrilla Design? > > > -- > 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
