Engineering Design Project Guide

Design projects are where engineering stops being a set of equations and becomes a craft. You get an open problem with no single right answer, limited time and a team that must agree. For many students, this is the first taste of real engineering.

This guide walks through the design process step by step and offers practical advice for working in teams, documenting your work and presenting results.

What makes design different

In many courses, problems have one right answer. In design, there are many acceptable answers and trade-offs among cost, performance, safety, manufacturability and time. Your job is to explore options, justify choices and deliver something that works. Good designers also know what they do not know and plan tests to find out.

The design process

Textbooks describe slightly different versions, but they share a pattern. Think of it as a loop, not a straight line.

1. Define the problem.
2. Research and understand the context.
3. Set requirements and constraints.
4. Generate concepts.
5. Evaluate and select a concept.
6. Develop the detailed design.
7. Build and test a prototype.
8. Evaluate, improve and iterate.
9. Document and communicate.

The engineering design process guide offers another description if you want a second view.

Step 1: Define the problem

Many projects fail because the team solved the wrong problem. Spend time asking:

• Who is the user or client?
• What need are we meeting?
• What does success look like?
• What is outside the scope?

Write a problem statement in one or two sentences that does not prescribe a solution. For example, "Help elderly users open jars with limited grip strength" is better than "Design a jar opener."

Step 2: Research

Learn about the user, existing solutions and relevant standards. Interview potential users, observe how they handle the task, study competing products and read patents or technical articles. Note what works and what does not. Research prevents reinventing weak ideas.

Step 3: Requirements and constraints

Translate needs into measurable requirements.

• Functional: what the design must do.
• Performance: how well, with numbers.
• Constraints: budget, size, weight, materials, time, regulations.
• Safety and environmental factors.
• Manufacturability and maintenance.

Rank them as must have or nice to have. For example: "Must open a standard jar with 20 N of user force or less. Must cost less than 15 dollars to produce. Should be dishwasher safe."

Step 4: Generate concepts

Aim for quantity first. Use brainstorming, sketching, functional decomposition (breaking the problem into subfunctions) and morphological charts that combine options. Defer judgment while generating ideas. Aim for at least five distinct concepts, not variations of the same one. Sketch each so the team can discuss it.

Step 5: Select a concept

Compare concepts using a decision matrix.

1. List criteria from your requirements.
2. Assign weights to show importance.
3. Score each concept on each criterion.
4. Multiply and sum.
5. Discuss the results, not just the totals.

Use the matrix to structure the conversation, and test its sensitivity by changing weights. Choose a concept, and note why others were not chosen.

Step 6: Detailed design and analysis

Develop the chosen concept. This is where your engineering courses come in: calculate loads, size components, select materials, simulate behavior and check safety factors. Create drawings and models with computer-aided design. Document assumptions, formulas and sources. Check manufacturability and cost.

Step 7: Prototype and test

Build the simplest prototype that answers your key questions. Early prototypes can be cardboard, foam or 3D printed. Plan tests tied to your requirements, with a clear procedure, measurements and pass criteria. Record results carefully. For ideas on presenting test data, the guide to making scientific graphs is useful.

Step 8: Iterate

Compare test results with requirements. Identify what failed and why. Change the design, rebuild and test again. Iteration is not a sign of failure but of good engineering. Keep a log of versions, changes and results.

Step 9: Document and communicate

Your documentation should let someone else understand and reproduce your work. Typical deliverables include:

• A design report with problem, requirements, concepts, analysis, test results and conclusions.
• Drawings, a bill of materials and cost estimate.
• A user guide or assembly instructions.
• A poster or presentation.

How to write an engineering lab report covers writing habits that carry over.

Teamwork

Teams make or break design projects. Agree on a charter early: roles, meeting times, communication tools, decision rules and how to handle disagreement. Use a shared task board and a shared folder. Hold short weekly meetings with notes. Review each other's work. If someone is struggling, offer help early.

Planning and time

Create a schedule with milestones: problem definition, concept selection, design review, prototype ready, testing complete, report and presentation. Add buffer, because building takes longer than expected. Track progress and adjust.

Budget and procurement

Many projects have a small budget. Estimate costs for materials and tools, buy early because shipping takes time, and keep receipts. Use free resources such as campus makerspaces. Cost awareness is a real engineering skill.

Safety and ethics

Follow lab and shop safety rules. Wear protective equipment. Consider how your design could be misused or fail, and plan mitigations. Be honest about performance claims and test results. Engineering codes of ethics place public safety first.

Presenting your design

A good design presentation tells a story: the problem, the user, the requirements, the concepts considered, the chosen design and why, the test results and lessons learned. Use diagrams and photos, show the prototype if possible and be ready to discuss trade-offs and what you would change.

A worked example: a simple device

Suppose a team is asked to design a device that helps a person with limited hand strength open jars. In the problem phase, they interview three users and learn that the main difficulty is gripping the lid, not twisting. They write requirements: opens common lids with a hand force under 20 newtons, works on lids from 50 to 100 millimeters, costs under 15 dollars and is dishwasher safe.

They sketch eight concepts: a strap wrench, a rubber cone, a lever, a suction cup, a gear-driven turner and others. A decision matrix weights cost, ease of use and size. The strap with a lever handle wins. They model the forces, choose a nylon strap and aluminum handle, 3D print a prototype and test it with five users. Two users cannot hold the handle comfortably, so the team redesigns the grip, retests and records the improvement in force required. Every step is documented with data.

Design reviews and feedback

Seek feedback early. Show sketches to classmates and users before building. At formal design reviews, bring specific questions, such as which of two options reviewers prefer or whether a safety factor is adequate. Write down every comment, decide which to act on and note why you decline others. Feedback is cheapest before you have built something.

Choosing materials and manufacturing methods

Match your build method to your goals. For early prototypes, favor fast and cheap methods such as cardboard mockups, laser-cut parts, 3D printing and off-the-shelf components. For later prototypes, choose materials that match the real application and test at realistic loads. Consider how the product could be made in volume, including tolerances, assembly and cost. Ask shop staff for advice, since they know what is easy to make and what is not.

Learning from existing products

Take apart or study similar products when allowed. Notice how they handle assembly, safety and user needs. Ask what they do well and where users complain. This benchmarking gives you ideas and keeps you from repeating known mistakes, while your design can add something new.

Common mistakes

• Jumping to a solution before defining the problem.
• Vague requirements.
• Considering only one concept.
• Skipping analysis and relying on guesses.
• Building late and leaving no time to test.
• Poor documentation.
• Unequal teamwork.
• Ignoring cost and safety.

Final thoughts

Design projects teach skills that exams cannot: working with ambiguity, making trade-offs and building real things with others. Follow the process, test early, document as you go and treat failures as information. Do that, and you will have both a strong project and the habits of a working engineer.