© Gary Swift

Inventing the Future with Structured Planning
Systems Design Methodology for Software Products

Version 2.1, June 6, 1995


4.1 Sources of Design Insights

As noted repeatedly in this document, there is a wealth of information about software design requirements, including user feedback, findings of usability and competitive labs, the directives of the quality improvement teams, and insights from individual engineers. All of these contribute to software interface and design expertise.

4.2 The Methodology Problem

Without a unifying strategic design program ... features evolve piecemeal from vaguely defined or unjustified requirements.
Although these various initiatives capture good data for design insights they are often disjoint and abortive. Results are presented in ways that are hard to translate into engineering directives, and there is virtually no methodology (apart from intuitive executive decision making) to relate the various design insights of one group to those of another. Hence, user satisfaction with quality and performance is reduced to an ongoing firefight as major customers complain, and lab studies are presented, applauded, then shelved as interesting academic exercises, while potentially profitable breakthrough engineering solutions and tools sit in programmers' personal directories. Without a unifying strategic design program, basic functionality, hardware support, user interaction methods and other features evolve piecemeal from vaguely defined or unjustified requirements. We can do better.

The problem is not that companies are not aware of the problem or that they do not try to uncover good design insights. They do and they are getting better at that. The problem is that they lack the methodology to systematically translate those various insights into comprehensive design initiatives that their engineers can implement.

4.3 The Methodology Solution

The solution is a systems-oriented design process that begins with hard-core information from a host of sources, then works backwards to specify the requirements of the product to serve the needs of real and potential customers. This process would involve methods for: (1.) reducing data from a variety of sources into real information, i.e., design insights about software products; (2.) correlating these design insights to identify where they reinforce or conflict with one another; and (3.) translating the insights into creative solution concepts, action directives, and specifications that are practical to implement.

Such a process exists. It is called "Stuctured Planning", and companies that adopt it for strategic design initiatives will find themselves climbing the right mountains while others battle over crowded turf.