A design tension is when making one design requirement better makes another worse. Putting two different demands on the same constituent often gives a design tension, e.g. when castle walls that protect against attacks have to have a gate to get supplies in, that entrance reduces security. Likewise computers that aim to deny virus attacks may still need plug-in software hooks. These contrasts are not anomalies but built into the nature of systems.
Early in its development, a product can be easily improved in many ways so there are few design tensions, but as requirements are met the performance area increases, i.e. the system gets better. This improvement increases design tensions – one can imagine the lines between the requirements tighten like rubber bands stretched as the web of performance gets bigger. In developed systems, the tension is so “tight” that improving any one performance criteria will pull back one or more others. This gives the Version 2 Paradox, where designers spend years “improving” an already successful product to give a Version 2 that actually performs worse!
To improve a complex system one cannot just improve one criteria, i.e. just pull one corner of its performance web. For example, in 1992 Apple CEO Sculley introduced the hand-held Newton, claiming that portable computing was the future (Figure 2.4). We now know he was right, but in 1998 Apple dropped the line due to poor sales. The Newton’s small screen made data entry hard, i.e. the portability gain was nullified by a usability loss. Only when Palm’s Graffiti language improved handwriting recognition did the personal digital assistant (PDA) market revive. Sculley’s portability innovation was only half the design answer — the other half was resolving the usability problems that the improvement had created. Innovative design requires cross-disciplinary generalists to resolve such design tensions.
In general system design, too much focus on any one criterion gives diminishing returns, whether it is functionality, security (OECD, 1996), extendibility (De Simone & Kazman, 1995), privacy (Regan, 1995), usability (Gediga et al., 1999) or flexibility (Knoll & Jarvenpaa, 1994). Improving one aspect alone of a performance web can even reduce performance, i.e. “bite back” (Tenner, 1997), e.g. a network that is so secure no-one uses it. Advanced system performance requires balance, not just one dimensional design “excellence”.