Engineering design and problem solving

Lesson 1 introduced the design process as a loop: define the problem, generate concepts, choose, develop, test and improve. This lesson looks at each stage closely, because design is where engineers add most of their value and where most avoidable failures begin. You will learn how to turn a vague request into a clear problem statement and a measurable specification, how codes and standards enter a design, how to generate many concepts rather than settling on the first, how models and prototypes reduce risk, how verification differs from validation, and how design reviews catch mistakes before they are built. A running example follows a student team designing a solar-powered water pump for a remote community, and the same habits apply to a bridge, a circuit board, a chemical process or a piece of software.

Engineering problems are open-ended

Textbook problems have one correct answer, all the data you need and nothing you do not. Engineering problems are different. They are open-ended: many solutions can work, and the job is to find one that is good enough on every count and best on the counts that matter most. They are ill-defined: the client may not know exactly what they need, and important facts are missing. And they are constrained by money, time, physics, law, safety, the environment and what people will actually accept and use.

Good engineers approach such problems systematically, not because a procedure guarantees a good design, but because it guards against the most common mistakes: solving the wrong problem, fixing on the first idea, overlooking a requirement, and discovering too late that something does not work. The stages below overlap and repeat; a test result often sends a team back to revise the specification or try a new concept.

Defining the problem

The most important stage is the first. A design team should be able to state the problem in a sentence or two that describes the need, not a solution. "Design a solar pump" names a solution; "Provide a reliable supply of at least 4,000 liters of water a day from a well 25 m deep to a community with no grid power" states a need and leaves room to consider other answers.

To get there, engineers ask questions. Who are the users, and who else is affected? What do they need, as distinct from what they asked for? What happens now, and why is it not good enough? What are the limits on cost, schedule, size, materials and maintenance? What would success look like, and how would we measure it? Visiting the site, watching people use the existing system and talking to the people who will maintain the new one regularly reveal requirements that nobody thought to mention.

Requirements, constraints and specifications

The problem statement is then broken into a list of requirements, each of which can be checked. Engineers distinguish:

• Functional requirements: what the design must do (deliver 4,000 L/day; lift water 25 m plus pipe losses).
• Performance targets: how well it must do it, often with a minimum and a target (operate at −35 °C; run on three cloudy days from storage).
• Constraints: limits the design must not cross (budget, mass, available space, a law or a code requirement).
• Objectives: things to maximize or minimize once the requirements are met (lowest life-cycle cost, least maintenance, lowest emissions).

Each requirement should be specific, measurable and testable. "Easy to maintain" is a wish; "a trained operator can replace the pump motor in under two hours with hand tools" is a requirement that a prototype can be tested against. Each should also carry a reason and a source (the client, a code, a safety analysis), so that when requirements conflict later, the team knows which ones can bend.

A specification is a living document. It is agreed with the client before serious design begins, placed under change control (any change is recorded, justified and approved), and used at the end to decide whether the design is finished. Many project disputes come down to whether something was in the specification.

Codes and standards

Engineers do not design from first principles alone. Codes and standards record the profession's accumulated knowledge about what is safe and what works. A code is a set of rules that becomes law when a government adopts it; a standard is a technical document describing a method, a product or a level of performance, which may be voluntary or may be referenced by a code or a contract.

In the United States, most states adopt the International Building Code and related model codes from the International Code Council; the National Electrical Code (NFPA 70) governs electrical installations; and organizations such as ASTM International, ANSI, ASME, IEEE and international bodies such as ISO and IEC publish thousands of standards on everything from concrete (ACI 318, ASTM C94) to solar equipment (UL 1703, UL 61730). Public water systems must meet the EPA's Safe Drinking Water Act regulations, administered by the states.

Codes set minimums, not targets. Meeting the code is necessary but does not guarantee a good or even an adequate design for an unusual situation, and the code of ethics (Lesson 4) holds engineers responsible for the public's safety even where the code is silent. Engineers must also use the edition of the code that is legally in force for the project, which may not be the newest.

Generating concepts

With the problem defined, the team generates many possible solutions before judging any of them. Research on design consistently shows that teams who fix on their first idea produce weaker designs; the best concept is rarely the first one thought of. Useful methods include:

• Research: how have others solved this or similar problems? Patents, product catalogs, technical papers and site visits all help.
• Brainstorming: a group generates as many ideas as possible in a short time, with criticism postponed. Quantity leads to quality, and wild ideas often prompt practical ones.
• Functional decomposition: break the overall function into sub-functions (collect energy, store energy, lift water, store water, protect from freezing) and find options for each.
• Morphological charts: list the sub-functions as rows and the options for each as columns, then combine one option from each row into complete concepts.

Evaluating and selecting

Concepts are compared against the specification. Any concept that fails a requirement or a constraint is eliminated, however attractive. The rest are compared on the objectives, often with a weighted decision matrix like the one in Lesson 1, supported by rough calculations, cost estimates and, increasingly, a life-cycle cost and carbon comparison (Lessons 10 and 11).

Before committing, good teams test the decision. A sensitivity check asks whether the ranking changes if the weights or scores change slightly; if it does, the decision deserves more data. A risk review asks what could go wrong with the leading concept and whether those risks can be managed. For the pump, concept A wins on cost and maintenance; its main risk is freezing of the elevated tank in an extreme cold snap, which the team addresses by insulating the tank, sizing it so the water turns over daily, and adding a low-level drain.

Modeling, analysis and prototyping

Once a concept is chosen, the team develops it in detail: sizing components, selecting materials, producing drawings and specifications, and checking that everything works together. Analysis uses models, from hand calculations to computer simulations, and every model rests on assumptions that must be stated and checked (Lesson 1).

Prototypes make ideas physical. Early, rough prototypes (cardboard models, breadboard circuits, a pump test in a barrel) are cheap ways to learn and to show users something they can react to. Later prototypes test performance, durability and manufacturing. Each prototype should answer a specific question: Will the pump prime from 25 m? Can an operator reach the motor? Does the insulated tank survive a week at −35 °C in a cold chamber? Simulations are prototypes too, and digital twins, detailed models updated with data from the real system, increasingly support design and operation.

Verification and validation

Two questions must be answered before a design is released:

• Verification: did we build the design right? Does it meet each written requirement? Verification is done by test, analysis, inspection or demonstration, and a verification matrix lists every requirement with the method and result.
• Validation: did we build the right design? Does it actually meet the users' needs in real conditions? Validation involves users and the real environment, such as a field trial of the pump through one winter.

A design can pass verification and fail validation if the specification missed something important: a pump that delivers 4,000 L/day in the test lab but is too noisy to install near homes, or a control panel whose labels the operators cannot read in winter gloves. That is why users should be involved from the beginning, not only at the end.

Design reviews and documentation

At key points, a project holds design reviews in which people outside the immediate design team examine the work: a conceptual review before detailed design, a preliminary review, and a final review before construction or manufacture. Reviewers check calculations, question assumptions, compare against the specification and look for what is missing. Independent checking of critical designs is a professional obligation in many fields; structural designs are routinely checked by a second engineer, and some jurisdictions require independent peer review of important buildings.

Throughout, engineers document decisions and their reasons: the specification and its changes, calculations with their assumptions, test results, review comments and how each was resolved. Good records allow others to check and maintain the design, protect the engineer if something goes wrong years later, and are required by professional regulators (Lesson 3). The communication skills this demands are the subject of Lesson 8.

Human-centered and inclusive design

Designs are used by people with different bodies, abilities, languages, cultures and levels of training. Human-centered design puts those people at the center: observing them, involving them in generating and testing ideas, and designing for the full range of users rather than an imagined average. For the community pump, that means co-designing with the operators who will maintain it, choosing controls and labels that work in cold weather and in the community's language, and respecting how the community wants to manage its water. Inclusive design benefits everyone: curb cuts made for wheelchairs help people with strollers, carts and bicycles. Lesson 11 returns to the engineer's responsibilities to communities.