Design Parameters
The mission, intent, goal, or objective of any given development project is worked out through an initial list of high-level feature requirements. These requirements are what designers call parameters, and we use these parameters to constrain and focus the design process.
Parameters for a vehicle might include gas mileage, production cost, appeal to certain types of buyers, conformity to government standards, and the number of doors and seats. For a toaster oven parameters might focus on safety, basic styling, and ease of use. For a telescope the features might include internet access and required optical performance.
The central goal is used to organize parameters – for example, a central goal might be transporting people, toasting bread, or observing stars. Parameters break goals into greater detail – like the size of a vehicle, the power requirements in a toaster heating coil, or the diameter of a telescope mirror.
Design is very much a matter of this sort of hierarchy – deriving an increasingly specific list of design objectives from higher-order requirements. Where parameter-generation ends and design begins is not the point. What matters is how the central goal and the highest-level parameters lay a foundation for detailed design work to follow.
Requirements must remain consistent – a telescope big enough to do the job, a toaster oven that cooks as expected, a car with features needed to attract the targeted consumer. The central goal is the final arbiter for what belongs. If the parameters are fundamentally conflicted, the conflict must be resolved before design work can begin.
For example, there’s likely a major market for a full-sized SUV offering a 50-mile-per-gallon fuel economy. Yet using current technologies a vehicle this big can’t achieve that sort of mileage, and in such a case a compromise is needed to resolve the conflict among parameters. What fuel economy might still meets the basic intent? Can we make the truck a little smaller and still call it ‘full sized’ to help save on fuel? If the conflict among parameters can be resolved the parameters are considered aligned with the project goal. When no compromise is possible, a project is considered over-constrained, and the conflict must be resolved – or the project scrapped.
To illustrate the point, here are some extreme examples of over-constrained project goals…
- a sports car that can carry seven passengers
- a school bus that can drive to the top of Mount Everest
- a commuter helicopter that can be folded into a lunchbox
- a 3D computer game database including every room, roadway, animal, blade of grass, and rotten tomato in the entire world.
Making matters difficult for those who design for living – there are successful product launches where goals and parameters were poorly defined, and yet the endeavor succeeded anyway as customers defined the product’s usefulness on their own – like play-doh. Other times a project was pursued in the face of a definition that was theoretically impossible, yet succeeded in a lesser form with few people noticing the discrepancy – such as the Space Shuttle. In very rare instances technology has arrived in the nick of time to make a bad idea work – like early notions of horse-drawn railroads rescued by the arrival of steam locomotives.
These are not useful illustrations to students of design because, like lottery winners, those who succeed by accident might not see a need for conscious goal-setting and careful parameter-definition.
In practice, half-baked ideas almost certainly turn into half-baked products because success via happenstance is the rare exception, not the everyday rule, and nobody trying to turn a profit should ever roll the dice on that sort of serendipity.
