Prototype On Paper

A ProcessPattern.

Scenario: You are working on a GraphicalUserInterface application, or web site, and business wants a new feature which changes the user interface. In general, it's not enough to say "Alice clicks on FOO" in the UserStory. Development needs to know where the FOO button goes. For non-trivial features, someone in Business decides to use homesite, frontpad, or whatever else to sketch up the interface they intend.

Forces:

1. Business is tempted to e-mail the HTML file to Development in an effort to communicate the vision clearly. However, Development may then feel overly constrained by the prototype, for it contains detailed information beyond the essential message intended by Business. This results in great difficulty refactoring or testing the UI. Furthermore, Business now has an unreasonable expectation about the time it will take to implement the corresponding feature, because the tangible part seems mostly done, despite having absolutely no sensible connection to a totally non-existent back end.

2. Paper, pencil, and sticky notes never need batteries. They're tangible, but do not appear to run. They convey essential ideas easier, and nitpicky pixel-pushing with more difficulty.

THEREFORE: Get stakeholders in the habit of communicating about GraphicalUserInterface design through the medium of paper, or something equally non-functional. If there's a strong element of GraphicDesign to the project, such as with heavily branded web sites, then let the graphic designer be part of Development, not Business. Use paper's tangible benefits to Business as selling points.

Resulting Context: Business doesn't inappropriately try to "help" with implementation. You can add widgets to the interface as the function behind them begins to work, and daily release builds showing visible progress corresponding to actual progress. You control the way widgets get to the screen, which means you can obey the rules of your development process and/or refactor and/or internationalize and/or whatever other systemic change might be just around the corner. In short, you have more agility.

HOWEVER: You may wind up with a tricky interpersonal problem. You may get more milage out of phrases like "softcopy composition art" to try to shift awareness to the idea that a screen design is not an application.

Note that prototyping on paper works well at the technical level for planning computations or batch systems based on dataflows. It allows you to identify common semantic patterns early that would ordinarily require a ton of refactoring to arrive at, thus saving time in the process of finding the true nature of the SimplestThing that could possibly work.