User-Centered Design

At first glance, identifying customer requirements would appear to be a marketing issue. In practice, the process requires much more interaction between clients and service or product providers. To do it properly, developers have to have the capability to see how features would be used and valued by customers through observation or querying. Those observations, in turn, affect the total system design.

It is important to produce a complete Design Document before any development begins. Some prototyping may be needed, but starting on the development too soon constrains your perspective. Also, once you start to develop something, you hesitate to throw it away even if a new idea seems better. Obviously, making a change to a developed product is much more expensive and time consuming than changing a mock-up or a prototype of a product.

The final result is a detailed Design Document and design prototype. This document includes the COMPLETE user and functional requirements, task flows, the product design, and the logic of the product's behaviors. The Design Document becomes the "playbook" that everyone will follow to develop, document, market, and support the product.

Having this document also provides a powerful means of curtailing "feature creep". Any proposed changes to the design must be in writing explaining the need for the change and any potential impacts on the rest of the design. The design team should meet to review these proposed changes, sign off on them if approved, and incorporate them into a revised Design Document that is then distributed to all those involved (i.e., documentation, developers, marketing, etc.).