A UX-mag article raises the issue of whether prototypes can replace documentation as client deliverables, and concludes that that's hardly a choice any more as prototype deliverables are increasingly popular, practical, agile, and inevitable. But the real question is when, not whether, prototypes can be used in place of user documentation. That's a question about high/low fidelity, and the relative value of different kinds of prototypes, with paper sketches at one end of the fidelity "spectrum" and detailed documentation at the other.
Pencil -paper sketches are great for initial, investigatory wireframes assuming that in early design stages, the emphasis is not so much on the proposal but on the conversations the proposal generates among the development team and the client. Fundamental elements of design such as function, behavior and form can be represented with sketches, but software captures them in an explicit way, and that makes software efficient at an engineering level, but cumbersome for design conversations. Unlike sketches, digital prototypes can show design relationships to other elements beneath the visual layer e.g. a navigation link on a global/master layer. Axure can be used to create both prototypes and documentation, and even has some built-in collaboration capability.
Prototypes will always be faster, leaner, more agile than any sort of documentation. But prototyping, much like designing and documenting (and just plain working), can't be separated from its project management. Nobody likes that (or do they?), and everybody knows that nothing can replace face to face dialogue among designers, developers and clients. From a project management perspective, the prototype vs. documentation issue is an issue of perceived sunk costs. How much, or rather, how little fidelity can be efficiently, not just effectively, invested ("sunk" in PM terms) into the client deliverables?
Pencil -paper sketches are great for initial, investigatory wireframes assuming that in early design stages, the emphasis is not so much on the proposal but on the conversations the proposal generates among the development team and the client. Fundamental elements of design such as function, behavior and form can be represented with sketches, but software captures them in an explicit way, and that makes software efficient at an engineering level, but cumbersome for design conversations. Unlike sketches, digital prototypes can show design relationships to other elements beneath the visual layer e.g. a navigation link on a global/master layer. Axure can be used to create both prototypes and documentation, and even has some built-in collaboration capability.
Prototypes will always be faster, leaner, more agile than any sort of documentation. But prototyping, much like designing and documenting (and just plain working), can't be separated from its project management. Nobody likes that (or do they?), and everybody knows that nothing can replace face to face dialogue among designers, developers and clients. From a project management perspective, the prototype vs. documentation issue is an issue of perceived sunk costs. How much, or rather, how little fidelity can be efficiently, not just effectively, invested ("sunk" in PM terms) into the client deliverables?
