Design Step 1: Defining the Problem

Introduction

The design process begins when somebody, whom we will refer to as the customer, expresses a need and so enlists the services of an engineer. The customer can be an individual, an organization, or the consuming public. Most customers are not engineers. It is up to the engineer to translate the customer’s need into engineering terms. The result is cast in the form of understanding a need, developing a problem definition, and producing a list of design specifications.

Identifying the Need

The basis of a good engineering project depends on identifying a viable “need” or “want” that can be satisfied. Failure to identify, understand, and validate the need, prior to designing, is one of the most frequent causes of failure of the entire design process.

The success of the project then depends on whether or not the customer(s) are satisfied with the result. Ideas for a new engineering project often come from listening to potential customers.

• What do they want?

• Where do they want it?

• When do they want it?

• What price are they willing to pay?

Then you investigate key issues such as

• How large is the market? This is usually determined by conducting a “consumer analysis” through surveys.

• Is anyone else supplying this market? This is usually determined by conducting “competitor analysis” through market studies. If so, can you determine if there are any needs not met? CAN YOU DO BETTER?

• Is the market realistic? “I want to go to Mars next week” is not realistic

• What are the financial and legal risks? Research existing patents to see if you risk any violations.

• Finally, can you make a profit by designing and producing a product for this market?

Defining the Problem

The customer’s statement of need does not typically take the form of a problem definition. For example, consider the following statement of need from a fictitious client:

Need: "People who work at the Empire State Building are complaining about the long waits at the elevator. This situation must be remedied."

An engineer might translate this need into the following problem definition:

Problem Definition: "Design a new elevator for the Empire State Building."

But, is this really a good problem definition? Is the main concern of the management at the Empire State Building to reduce average waiting times or to eliminate the complaints? When turning an expressed need into a problem definition, it is important to eliminate assumptions that unfairly bias the design toward a particular solution. A better, less-biased problem definition might be:

Improved Problem Definition: "Increase customer satisfaction with the elevators in the Empire State Building.

This would admit such solutions as a mirror on the elevator door or free coffee on the busiest floors."

As another example of an inadequate problem definition, consider the following: "Design a device to eliminate the blind spot in an automobile." This proposed problem definition also contains an assumption that prematurely limits the designer. The word "device "rules out one solution that achieves the design goal (eliminating the blind spot) by simply re-positioning the front and side mirrors.

A third example occurred in a design competition named Blimp Wars. The goal was to "design a system to retrieve Nerf® balls from an artificial tree and return them to the blimp base." Inclusion of the word blimp in the problem definition biased the students toward blimp designs. The alternative of an extendable arm that spans the distance between blimp base and the target balls was not considered.

Blimp Wars

List of Design Specifications - demand (D) or a wish (W) List

After translating the need into a problem definition, the next step is to prepare a list of design specifications (or requirements) that enforce the voice of the customer. The list of design specifications includes both “demanded” design characteristics that must be present for the design to be considered acceptable by the customer and “wished for” design characteristics that are desirable but not crucial to the success of the final design. It is the usual practice to classify each specification as either a demand (D) or a wish (W). Don’t confuse the two. If you treat a wish as if it were a demand, your design may become more complicated than is necessary.

Whenever possible, use numbers to express specifications. For example, instead of merely requiring that weight must be low, state, “Weight must be less than 10 pounds.” Sometimes use of numbers is impossible. A quality such as “aesthetically pleasing” is difficult to quantify. However, use numbers wherever possible, even if at this early stage they seem like guesses. The numbers can be refined later on as the design begins to take shape.

The specifications should be solution independent to avoid bias. For example, if you are designing a small mobile device, requiring that “the wheels must be made of rubber” will bias the design in two respects: in the use of wheels and in the choice of materials. Such decisions are reserved for later in the design process after careful consideration of alternatives.

Specifications come in the following categories:

• Performance

• Geometry

• Materials

• Energy

• Time

• Cost

• Manufacture

• Standards

• Safety

• Transport

• Ergonomics

• Environment

These categories can also be used as headings by which to organize the list of specifications. Here is an example:

Example 1

The following problem definition was posed to three competing design teams.

"Design and build a RC portable device that will play nine holes of golf at a local golf course with the fewest possible number of strokes."

The instructor also supplied the following list of demands. It was left to the students to develop a complete list of specifications.

Demand (D) Specification:

• Must cost less than $600 (not including radio).

• Must be remotely triggered.

• Total number of radio-controlled servos is eight.

• Device cannot be touching the golf ball prior to remote triggering of the shot.

• Entire device must form a single unit.

• Must be portable.

• Design must pass a safety review.

• Ground supports must fit within a 3 ft. circle.

Solution

The first step was to organize the demands under each heading. Then, using the headings as a guide, additional demand (D) or wish (W) specifications were formulated after talking further with the course instructor (their customer). The results follow:

Performance

D—Must be remotely triggered.

D—Device cannot be touching the golf ball prior to remote triggering of the shot.

D—Driving distance must be adjustable with a range of between 15 and 250 yards.

D—Putting distance must be adjustable with a range between 0 and 15 yards.

D—Must operate on inclines of up to 45°.

W—Must sink 95% of short putts (less than 3 ft.).

W—Driving accuracy of ± 5 yards.

Geometry

D—Total number of radio-controlled servos is eight.

D—Entire device must form a single unit.

D—Ground supports must fit in 3 ft. circle.

Materials

W—Materials must not degrade under expected range of weather conditions (including rain, snow, 30 °F < T < 90 °F).

Time

D—Must be designed and manufactured in less than 14 weeks.

Cost

D—Must cost less than $600 (not including radio).

Manufacture

D—Must be manufactured using tools available in the machine shop.

D—Must be manufactured using machining skills available within the team.

W—Off-the-shelf parts and materials should be readily available.

Standards

D—Radio must adhere to FAA regulations.

Safety

D—Design must pass a safety review.

Transport

D—Must be portable.

W—Must fit in a car or small truck (for easy transport to the golf course).

Clarifying the Problem

1. Start with what you know. People can be asked in advance to write down what they know about a problem. A brainstorming session is useful in generating the most information.

2. Decide what information is missing. Information is the key to effective decision making. If you are designing a replacement bridge, do you know how many people will use the bridge? When will they will use the bridge—all the time or mainly in the morning and evening? If that's the case, your problem statement might be “Design a four-lane highway bridge to accommodate 400 cars per hour at peak usage.”

3. Gather information on the problem (Research). You might collect several types of information. It will generally fall into one of the following categories:

• Facts (15% of the people do not use the bridge at all)

• Inference (a significant percentage of drivers bypass the bridge)

• Speculation (many trucks use the bridge)

• Opinion (I think a new bridge will be too expensive)

When you are gathering information, you will probably hear all four types of information, and all can be important. Speculation and opinion can be especially important in gauging public opinion.

For example: if you are trying to reduce the waiting time to pay for products purchased in a large department store you might find that most people have the opinion that the store should open more checkout lanes. Others may speculate that the store manager does not want to pay for more checkout clerks. However, if you observe the checkout line throughout the day and interview the store manager you may find relevant facts that either support or contradict these opinions and speculations.

Define the problem. With the information in front of you, you’re ready to write down a “problem statement”—a comprehensive definition of the problem. Define the problem in terms of needs, and not solutions. If you define the problem in terms of possible solutions, you’re closing the door to other, possibly more effective solutions.

For a General Design Project (Version A)

Assignment:

(1) Prepare a typed list of specifications for your project.

Tips

• Avoid any temptation to bias the requirements toward a particular solution or strategy.