Design Process

Pre-Design

Pre-design is where the main direction of the project is decided. It is not about choosing every part or locking in a final design. The goal is to understand what the project needs to accomplish, what work will be required, and how the different parts of the project will connect.

I think most of these decisions should involve the whole team. Bringing more perspectives into the beginning of the project creates a better foundation and gives everyone a clearer understanding of what the final product is supposed to become.

Reference Class Forecasting

Reference class forecasting is a useful way to create an initial budget and timeline for a project. Instead of estimating only from what the current design appears to require, it looks at similar completed projects and uses their actual costs and timelines to build a realistic range.

Reference Class Forecasting | MATE ROV

I created a tool that applies this method specifically to MATE ROV projects. I like this approach because manually calculated estimates tend to undersell what the final product will cost. No estimate can account for every what-if or every problem that might come up.

Completed projects already include those realities. Their final costs and timelines contain the mistakes, delays, redesigns, and unexpected work that are easy to leave out of a new estimate. That makes them a stronger starting point than a best-case estimate based only on what is expected to happen.

Backcasting

Backcasting, or right-to-left thinking, starts by creating a clear picture of the final goal. In a MATE ROV competition, the rightmost box might be winning the competition. From there, the process works backward by asking what has to be true immediately before that.

To win, the project needs an ROV or another device that performs reliably, meets the requirements, and can be presented well. Each of those outcomes can be worked backward again until the final goal becomes a chain of achievable work.

Some writers use a similar process. They may spend months writing and perfecting the short summary that will eventually live on the back of a book. They are defining what the final product should become before writing the rest of it. Amazon is known for a similar working-backwards practice that begins with a proposed press release and FAQ.

I think a project thesis serves the same purpose. It becomes the reference point for the decisions that follow. If something does not support that thesis, it is worth asking whether it belongs in the project.

Design Requirements

Once the final outcome is clear, the next step is deciding what must be true for the project to reach it. This is where design requirements come into play.

I think the first focus should be the minimum viable product requirements: the things that absolutely have to be achieved for the project to succeed. For a MATE project, these might come from the safety rules, mission tasks, or engineering presentation rubric.

Every requirement should connect directly to the end goal. Removing requirements that do not support that goal creates a simpler, more focused, and more purpose-built product.

A common problem is writing solutions into the requirements. For example, someone might say that an ROV is required to have lights. Lights are a solution, not the actual requirement. Writing it that way locks the design into one answer before the alternatives have been compared.

To find the real requirement, I like to zoom out and ask every engineer's favorite question: “Why?” The answer might be that the operator or camera needs to see in low-light conditions. Written that way, the design can still consider lights, low-light cameras, night vision, or another solution that has not come up yet.

Mind Maps

Experienced team members usually have a general idea of what an ROV looks like and understand its common systems. That knowledge can be combined with the design requirements to sketch a rough functional picture of the vehicle.

A mind map, or another version of the same tool, can show the main subsystems and how they relate. It might include a frame, control system, propulsion, and a manipulator.

I try to keep this picture open and functional instead of locking in solutions. It should describe what each subsystem needs to do, not exactly how it will do it. This avoids the same problem as writing solutions into the requirements.

Work Breakdown Structures

Once there is a basic picture of the ROV, the outcome can be broken into the work required to reach it. This is the Work Breakdown Structure. I usually build it from right to left, although it can work in either direction.

The important part is showing the dependencies. Some work has to be completed before something else can begin, while other work can happen in parallel. A microcontroller may need to be selected before software can be written for it, but choosing the microcontroller and selecting a frame material might happen at the same time.

The goal is to make the order of the work visible.

After the order is in place, each task needs a rough time estimate. I have never found a perfect way to do this, and nothing I have tried works especially well. My first full timeline is often two or three times longer than the time actually available.

One thing I have not tried yet is bringing reference class forecasting into this part of the process. It may help ground the individual estimates. For now, I use the longer first timeline to find the most unrealistic assumptions and then scale the plan to the real deadline. It is not perfect, but it has worked well enough.

Creating a Timeline

Once the tasks, dependencies, and time estimates are known, the work can be turned into a Gantt chart. A useful timeline shows more than dates. It makes the sequence, milestones, handoffs, and deadlines visible.

This gives the project a shared schedule and creates a clear deadline for each task. It also makes it easier to see when one late task is beginning to hold up the rest of the work.

Interface Control Documents

I have only used Interface Control Documents a couple of times, but they have been very helpful on larger teams where work is divided among subteams. Communication is usually one of the weakest parts of a large project, and these documents reduce some of the ambiguity and repeated discussion.

An Interface Control Document defines how parts and subsystems connect. It might establish communication protocols, electrical connector standards, mechanical mounting points, or other boundaries between systems. With those interfaces written down, each subteam can work independently while still knowing that its part will integrate with the rest of the machine.

At the same time, the document should not impose unnecessary solutions. It needs to be strict enough to make sure everything fits and works together, while remaining flexible enough to leave room for a better or more optimized design.

It is also a living document. Designs change and problems come up, so the interfaces may need to change with them. The important part is making sure those changes are understood by everyone they affect.

Design

By the design stage, the subsystems should have clear requirements, an informed budget, a timeline, a due date, and an Interface Control Document showing how they fit with the rest of the machine. This gives the people responsible for each subsystem a clear definition of success without telling them exactly how to reach it.

Project Structure and Ownership

I think subteams should have a leader, usually a returning member who already has a strong understanding of that system. Once the expectations are clear, that leader should have the freedom to decide how the subsystem will meet them.

The lead can also bring newer members into the work and give them meaningful tasks that help the subsystem reach its deadline. The requirements define what success looks like, while the subteam lead owns how to get there.

The goal is to create both pride and accountability. A subteam leader helped shape the design, helped make it, and is responsible for getting it across the finish line. That means leaders should be selected carefully and given the support they need to succeed.

This is not very different from the way many teams already work. It adds enough structure and accountability to keep the work moving without having everyone step on each other's toes.

Design Considerations

I want to see evidence that the important design choices were actually considered. Each subsystem should be able to show its alternatives, its reasoning, and why the final idea was selected. This helps make sure every stone was turned while searching for the best solution, and it creates useful material for the engineering presentation later.

Design considerations can take several forms, but they usually come down to comparing a handful of ideas, often around seven. Weighted decision matrices and trade studies can make the comparison visible and defendable. The exact tool matters less than showing that real alternatives were considered instead of settling on the first workable idea.

The difficult part is deciding what “best” actually means. That always comes back to the project thesis and how each option helps achieve it. The design requirements can become the metrics for the comparison. Ideally, those requirements are written with a SMART-goal mentality so they can be measured.

If the comparison is between apples and the requirement calls for a softer apple, choosing the green one simply because green seems better does not help. Green does not matter to that specific problem. The best solution is the one that best supports the goal.

Prototyping and Iteration

Choosing a good idea is not always enough to get it across the finish line. People learn through iteration and repetition, and designs rarely work perfectly the first time. They have to be tested, understood, and revised before they become reliable.

The way those iterations happen matters. Jumping straight into manufacturing a complete working prototype can burn a lot of time, money, and material, especially when the schedule already feels tight.

It is usually cheaper and faster to spend more time iterating on paper, in CAD, through simulations, or with simple models before committing to the final build. The fidelity of a prototype should increase only after the cheaper version has answered everything it can.

Iteration might look like CAD modeling and simulation, lab tests and proofs of concept, or something as simple as sketches, cardboard, and Play-Doh. I like to think that every design has a certain number of iterations it needs to go through before it becomes viable and efficient. The goal is to complete as many of those iterations as possible while they are still cheap.

Finding and fixing a problem on paper is much faster than discovering it halfway through manufacturing. Think slowly so it is possible to act fast later.

Widgeting

Widgeting is another way I would approach prototyping. Instead of building a complete prototype, I would build a small prototype of one critical feature and test it by itself.

This isolates that feature and the variables around it. The test can measure what is actually important without the rest of the system making the result harder to understand. If something needs to change, the widget is small enough to edit and test again without rebuilding the entire design.

This makes the process more cost effective and makes each test more useful. Once the critical feature is understood, the result can be brought back into the larger design with more confidence.

Writing and Presenting

The iterations can follow an agile-like method where each weekly meeting produces feedback that shapes the next round of changes. Another method can work too, as long as it supports a disciplined cycle of building, testing, learning, and improving.

This is also where most of the writing and presenting should happen. Reports can be written at major milestones to explain the reasoning and the “why” behind the work. This should lead to a final design presentation where every part of the design, down to the bolt heads, can be explained and approved before manufacturing.

Manufacturing

Once the designs are approved, parts can be ordered and money can be spent. The project has already moved slowly and carefully through the iterative design process. Manufacturing is the point where it should be possible to act quickly.

This is also where mistakes become expensive and costs can skyrocket, so I think the manufacturing window should be kept as short and controlled as possible. Before reaching this stage, the design should be understood in detail: how every part works, how it goes together, how long it will take to build, and what the day-by-day plan looks like leading up to the first full test.