Design as a repeatable process
Engineering design is the work of turning a need into something that can be built, tested and used. It is not a single flash of insight. Most teams follow a loose sequence of stages, and they expect to move back and forth between them. Different industries name and order the stages differently, and formal programmes in regulated fields add their own steps, so treat the outline below as a general model rather than a rule.
The usual stages are:
- Understand the problem and write down requirements.
- Generate several concepts.
- Evaluate and select a concept.
- Develop the chosen concept in detail.
- Test it against the requirements.
- Iterate, then hand over to manufacture or use.
Start with the problem, not the solution
Many design failures begin with a solution chosen too early. A useful first step is to describe what the product must do, for whom, and under what conditions, without describing how. A statement such as “the user must be able to carry the unit up a flight of stairs” is more helpful than “the unit shall have two handles”, because the first leaves room for better ideas.
Requirements usually cover function, performance, size, cost, safety, environment and the expected life of the product. Good ones are specific enough to be checked later. A requirement you cannot test is really a wish. The practice of writing requirements engineering material in a structured way exists because vague needs are one of the commonest sources of expensive rework. It also helps to separate what the product must do from the qualities it must have, which is the distinction behind functional and non-functional requirements.
Talk to the people who will use, build and maintain the product. They often know constraints that are not obvious from the brief.
Generate concepts before judging them
Once the problem is clear, produce several different ways of meeting it. The aim at this stage is range, not polish. Sketches, simple block diagrams and rough physical mock-ups are usually enough. If you only develop the first idea you thought of, you have no way of knowing whether it was a good one.
Some habits that help:
- Break the overall function into sub-functions and look for ideas for each.
- Ask how the same function is achieved in other products or other fields.
- Hold back criticism until you have a reasonable list.
- Record rejected ideas and the reasons, so the team does not revisit them without cause.
Evaluate and choose
Concepts are compared against the requirements and against each other. A common tool is a weighted scoring table. Its strength is that it makes the criteria visible; its weakness is that the weights are judgements, and small changes to them can change the winner. Treat the result as a way to structure a conversation, and check the ranking by asking whether it still holds when the weights move. The mechanics are covered under decision matrices.
Early evaluation can also use quick calculations, order-of-magnitude estimates and cheap experiments. If a concept cannot possibly meet a key requirement on the back of an envelope, there is no need to model it further.
Risk belongs in this stage too. Ask what could go wrong with each concept and how bad it would be. A concept with a hard unknown at its centre may deserve an early test before you commit to it.
Detailed design
Detailed design turns the chosen concept into something that can be made. This is where dimensions, materials, tolerances, interfaces and component choices are fixed. Drawings or models, bills of materials and manufacturing notes are produced. Computer-aided tools are used heavily here; the basics are explained under CAD software, and good working practice is described under CAD modelling habits.
Several things are worth keeping in mind:
- Choose components with the operating conditions in mind, and leave margin rather than designing to the limit. The idea is explained under design margins.
- Check that parts can actually be made, assembled and serviced. General guidance sits under design principles.
- Pay attention to interfaces between sub-systems, since mismatched assumptions there cause many late problems.
- Record the reasons for important choices, so later changes are made knowingly. Short decision records are a lightweight way to do this.
Analysis during this stage may include hand calculations and computer models. Their value depends on how well the model matches reality, a point developed under engineering simulation.
Testing and verification
Testing asks whether the design meets its requirements. It is helpful to separate two questions: did we build the product correctly (does it match the specification), and did we build the right product (does it meet the real need)? The first is verification; the second is validation. Both are needed.
Tests can be run on parts, sub-assemblies and the complete system, and early prototypes are usually less complete than the final product. Plan tests from the requirements so that each requirement has a way of being checked, and write down the pass criteria before you run the test, not after. Careful handling of prototype testing helps you learn the most from limited hardware.
A failed test is information, not a disaster. The cost of finding a problem rises as the design progresses, which is a good reason to test early and to keep early tests cheap.
Iteration
Real projects loop. A test result may expose a weak requirement, a detail problem may force a change of concept, and a customer comment may alter priorities. Iteration is normal and healthy as long as it is controlled. Keep track of which version is current, record what changed and why, and re-check the requirements affected by each change. Without that discipline, changes accumulate unnoticed and old assumptions linger in the design.
Regular design reviews give a team a fixed point at which to step back, ask hard questions and decide whether to proceed.
Responsibility and limits
Design decisions can affect safety, the environment and the people who use the product. Rules, standards and expectations differ between countries and industries, and this article is general information, not engineering advice. Follow the standards, regulations and professional guidance that apply to your field, and rely on qualified engineers for decisions that affect safety.
A last practical point: the process is a means to an end. Teams that follow every step on paper but never talk to users or test early can still produce poor designs. Use the stages to ask better questions, and adapt them to the size and risk of the project in front of you.