[Sigia-l] Elements of Documentation

[christina wodtke]

> If you could create functional prototypes in roughly the same timeframe
> would you bother with any of the other stuff?


While I agree with where most of this discussion has gone-- prototypes as an
end unto themselves, not as a code starter, and prototypes as a
communication device I still want to address this issue.

We often get so caught up in talking about drawing for communicating and
drawing for documenting that we forget about drawing for thinking. A site
map, user flows and wireframes may not be needed in a formal documentation
scheme (though they can useful for updating, reviewing past design decisions
and for QA to work from), they are definitely needed to avoid tunnel vision
in the design process. They give you a useful overview of the entire system,
and help root out ignored corners of a site and promote systems thinking.
These deliverables were produced through parallel evolution-- multiple
studios came up with them more or less at the same time because this
produced good thinking and thus good work.

I think a functional prototype could be made after this thinking was done in
a shorter timeline than doing a prototype without this thinking, since you'd
have to keep updating it as user testing, engineering, design and QA would
keep raising the question "What if this happens?" If you think well, those
questions will be "is this the best solution?" or "this doesn't really
work... can we modify it?" which not only shortens the project timeline, it
also produces better work.

It's up to the individual company to decide where they want to spend their
energy, making clean illustrator versions of the IA, or building prototypes:
but the thinking must happen.

IMO, as ever.