It sounds like a useful analogy, but it's incomplete. I imagine that an architect knows both how inhabitants interact with a building and how the component parts of the building come together (steel, wood, nails, etc.). Also, an architect still will need an HVAC engineer, a landscape architect, an electrician, etc., to design the other systems that the inhabitant doesn't really see/think about/interact with.
I've found that some designers expect that software developers are like those 3D printers -- the designer writes the CAD file and the developer just robotically "prints out" the software. No doubt, more software gets outsourced to incompetent development teams because of this misconception. In software, there's also another layer in there, because interaction design is separate from software design. Your completed design doesn't tell a developer exactly what architecture, what database, what application platform, what programming language to use. It doesn't tell him what database objects to model, or what classes to define. A great deal of design takes place after the "design" is complete. So, your whole collection of design artifacts work together to create a vision of the completed product, and they should all be used together (in addition to formal requirements for things that the user doesn't see) to communicate with your customers and your developers. Designers then need to stay involved during the development process to reformulate portions of the interaction design as conflicts with the software design arise. I would suspect that architects, too, stay involved during construction ;) Best, Jon Abbett [email protected] On Wed, Oct 7, 2009 at 8:02 AM, Siegy Adler <[email protected]> wrote: > Here's my definition... > > A functional spec is a document that describes, in non-technical > terms and illustrations, what a Website, or Web-based application, > will look like and how it will function. A good functional spec, > which should be based on stakeholder requirements, provides > developers with the information they need to code the application. > > When asked to describe what a spec is, I often use the following > construction analogy: > > 1) The property owner (i.e., stakeholder) meets with the architect > (i.e., spec writer) to describe the structure (i.e., > Website/application) they want built > 2) The architect drafts the blueprint (i.e., spec) > 3) The contractor (i.e., developer) builds the structure based on the > blueprint > Do you agree? > ________________________________________________________________ > 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 > ________________________________________________________________ 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
