The engineering design process

Design is what engineers are paid for. Analysis (the statics, circuits and chemistry of first year) tells you whether a proposed solution will work. Design is how the solution gets proposed in the first place. It is the process of turning a need, often stated vaguely by someone who is not an engineer, into a specific, buildable, tested thing.

ENGG-100 introduced the design cycle and the weighted decision matrix. This course goes deeper and makes the process practical. Through all five lessons we will follow one project: making the entrance of an older community centre accessible to everyone. This chapter covers how to frame the problem, find root causes, generate many concepts, screen and select them, test whether a decision is robust, and use prototypes and testing to learn before committing.

Why a process at all?

Experienced designers sometimes seem to leap straight to a good answer. In reality they are running through the same steps quickly and from memory. A deliberate process helps in three ways. It stops the team from falling in love with the first idea, which is rarely the best one. It makes the reasoning visible, so a client, regulator or reviewer can see why a choice was made. And it scales: a five-person student team and a five-hundred-person aircraft program both need a shared idea of what stage the work is at.

Many models of the design process exist. They differ in the number of boxes but share a core sequence: understand the problem, generate options, choose, develop, test and deliver, with loops back whenever something learned later changes an earlier decision.

The double diamond, popularized by the UK Design Council in the mid-2000s, captures an idea that the simple cycle hides: good design alternates between diverging (opening up, generating many possibilities) and converging (narrowing down, deciding). Teams get into trouble when they converge too early, picking a solution before the problem is understood, or never converge at all.

Large engineering organizations formalize the same idea as a stage-gate process: work proceeds in stages (concept, preliminary design, detailed design, construction) separated by gates where a review board decides whether to continue, revise or stop. You will see this in practice as design reviews, covered in Lesson 5.

Stage 1: frame the problem

The single most expensive mistake in design is solving the wrong problem. Clients usually describe a solution, not a need: "we need a ramp", "make the pump bigger", "add another lane". The engineer's first job is to dig underneath the request to the need it is meant to satisfy.

A good problem statement is solution-neutral. It describes who has the problem, what they cannot do, and what success would look like, without naming a particular solution. That leaves room for answers the client has not thought of.

Notice the phrase "year-round". It came from asking the board follow-up questions, and it will matter: a ramp that ices up in January fails the need even if it meets every dimension in the building code.

Finding root causes

When the problem is a failure or a recurring complaint, the visible symptom is rarely the real cause. The "five whys" technique, developed at Toyota, asks "why?" repeatedly until you reach something you can actually fix. Five is a rule of thumb, not a requirement.

Research before inventing

Most problems have been partly solved before. Before generating concepts, look at how others have handled similar needs: competitor products, published case studies, codes and standards (which encode lessons from past failures), and patents. A patent search can reveal both good ideas and protected ones you must not copy. Benchmarking, the systematic comparison of existing solutions against your requirements, turns that research into a table you can learn from.

Stage 2: generate many concepts

Quantity first. Studies of design teams consistently find that teams who generate more concepts early end up with better final designs, partly because good ideas often come from combining or modifying weak ones. Two habits help.

• Brainstorming with rules: defer judgment, aim for quantity, build on others' ideas, welcome odd ones. Writing ideas silently first, then sharing (sometimes called brainwriting), stops the loudest person from steering the group.
• Functional decomposition: break the problem into the functions the design must perform, generate options for each function separately, then combine them.

The second habit leads to a powerful tool, the morphological chart. List each function as a row and the ways of achieving it as columns. Any choice of one option per row is a candidate concept.

Stage 3: screen, then select

With dozens of candidates, evaluating each in detail is impossible. Selection usually happens in two passes.

Screening with a Pugh matrix

The Pugh method, developed by Stuart Pugh, compares each concept against one reference concept (the datum), criterion by criterion: better (+), same (0) or worse (−). There are no weights and no fine scores; the point is to discuss each comparison, drop clear losers, and spot ways to combine strengths.

Weighted selection and sensitivity

For the final few concepts, a weighted decision matrix (from ENGG-100) puts numbers on the comparison. Each criterion gets a weight reflecting its importance, each concept a score on each criterion, and the weighted sums are compared.

A lead of 0.20 out of 10 is well inside the uncertainty of the scores themselves. Before recommending the walkway, the team should ask whether the ranking survives reasonable changes in the weights. That check is called a sensitivity analysis.

This is how numbers should serve judgment rather than replace it. A decision matrix does not make the decision; it makes the assumptions behind the decision explicit, so the people who own those assumptions can check them.

Stage 4: prototype and test

A prototype is any model built to answer a question. The skill is to build the cheapest prototype that answers the question you have right now.

• Low fidelity: sketches, cardboard mock-ups, tape on the floor. Quick and cheap, for questions about size, layout and how people use something.
• Medium fidelity: 3D-printed parts, foam models, computer simulations. For questions about fit, motion and performance.
• High fidelity: a working unit made with production materials and methods. For final verification, certification testing and manufacturing trials.

For the entrance, the team marked the regraded walkway's outline in chalk on the sidewalk and watched members walk, push strollers and use wheelchairs along it. They learned in one afternoon that the planned turn near the door was too tight for a mobility scooter, something no drawing review had caught.

How many testers?

Usability testing with real users finds problems that designers cannot see. A widely used model from Nielsen and Landauer assumes each tester reveals a given problem with probability \(p\), typically about 0.31 in software studies. The fraction of problems found by \(n\) independent testers is then

Take the exact numbers lightly. The value of \(p\) varies a great deal between products and user groups, and accessibility testing in particular needs testers with a range of disabilities, since one wheelchair user cannot represent everyone. The lesson that survives is the shape of the curve: early, small, repeated tests pay off.

Stage 5: iterate, then deliver

Every test teaches something, and much of what it teaches sends you back to an earlier stage. James Dyson famously built 5,127 prototypes of his cyclonic vacuum cleaner before he had one he was happy with. That is extreme, but the principle is universal: iteration is not a sign that the first design failed; it is how design works. The cost of a change rises steeply as a project moves from concept to detailed design to construction, so iterate hardest early, when changes are cheap.

Delivery means more than building the thing. It includes the drawings and specifications that let someone else build it (Lesson 3), the report that explains and justifies it (Lesson 4), the commissioning tests that show it works, and the operating and maintenance information that keeps it working. For the entrance, that includes the new downspout routing found by the five whys, and a clear assignment of who clears snow.

Design for X

Beyond working at all, a design must work across its whole life. Engineers use a family of "design for X" checklists to keep those other goals in view:

• Design for manufacture and assembly: fewer parts, standard fasteners, parts that can only go together one way.
• Design for maintenance: access panels, replaceable wear parts, nothing that needs a crane to change a light bulb.
• Design for accessibility: usable by people of all ages and abilities, which is the whole point of our project.
• Design for sustainability: lower embodied carbon, longer life, reuse and recycling at end of life (ENGG-100, Lesson 5).
• Design for safety: hazards removed by design first, guarded second, warned about last (the hierarchy of controls from ENGG-100).