Design Process

Pre-Design

Good design starts before parts are selected or CAD is opened. The purpose of pre-design is to define the outcome, understand the constraints, and make the order of the work visible. This creates a stable foundation without deciding too early what the final solution must look like.

Define the Outcome

The process begins with a clear description of success. For a MATE ROV project, that means more than building a vehicle that moves underwater. The finished system must perform the required tasks reliably, satisfy safety and competition requirements, fit the available budget and schedule, and be understood well enough to present and defend.

I treat this description as the project thesis. It becomes the filter for later decisions. A feature, requirement, or design choice that does not support the thesis should be challenged before it consumes time or money.

Reference Class Forecasting

Reference class forecasting provides an outside view of the project. Instead of estimating only from the planned design, it uses the actual costs and timelines of similar completed projects to establish a realistic range.

Reference Class Forecasting | MATE ROV

Completed projects already contain the effects of mistakes, delays, cost overruns, redesigns, and unexpected work. Those outcomes make a stronger planning baseline than a best-case estimate. The forecast does not replace detailed estimates; it is a check against optimism and a way to set credible initial expectations.

Backcasting

Backcasting works from the final outcome toward the present. If the goal is a reliable competition system, the next question is what must be true immediately before competition. That may require a tested vehicle, trained operators, completed documentation, spare parts, and a practiced presentation. Each of those outcomes can then be broken down again until the result is a sequence of achievable work.

This right-to-left view keeps the final purpose visible. It also exposes work that is easy to overlook when planning begins with the first part that seems interesting to build.

Design Requirements

Requirements translate the project thesis into specific conditions that the design must satisfy. They should describe the needed function or performance rather than prescribe a solution.

For example, “the ROV must have lights” defines a solution. “The operator must be able to identify mission objects in the expected lighting conditions” defines the actual need. The second version leaves room for lights, low-light cameras, image processing, or another approach.

Useful requirements are measurable whenever possible. Each one should have a clear reason for existing and a practical method of verification. Safety rules, mission tasks, environmental limits, budget constraints, and presentation expectations can all become requirements when they directly support the final outcome.

Functional Architecture

A functional architecture describes what the system must do before deciding exactly how it will do it. A mind map or block diagram can show major functions such as structure, propulsion, power, sensing, control, communication, and manipulation, along with the relationships between them.

Keeping this view functional prevents familiar solutions from becoming invisible assumptions. It also provides a shared picture of the system and creates a natural starting point for dividing the design into subsystems.

Work Breakdown Structure

The Work Breakdown Structure turns the system architecture into the work required to deliver it. The important information is not only the list of tasks, but also the dependencies between them: what must be finished before another task can begin, what can happen in parallel, and where several paths must come together.

Selecting a microcontroller may need to happen before its production software can be completed. Selecting that microcontroller and evaluating frame materials may happen at the same time. Making these relationships visible helps reveal the critical path and reduces avoidable waiting between subsystems.

Risk and Uncertainty

Some parts of a project carry more uncertainty than others. A simple risk register records the concern, its likely effect, how it will be detected, and the action that reduces it. The most useful entries are tied to decisions: prototype the uncertain mechanism early, order the long-lead component first, or keep a proven fallback available.

Risk work should change the plan. A list of concerns without owners, tests, or mitigations is only documentation.

Timeline

Tasks, dependencies, and estimates can be organized into a Gantt chart or another shared schedule. A useful timeline shows milestones, handoffs, review points, integration windows, and deadlines rather than only start and end dates.

The first schedule is often longer than the available season. That mismatch is useful. It identifies unrealistic assumptions, low-value scope, and tasks that need earlier decisions or parallel work. Reference class forecasting can provide a reality check, while schedule buffers protect the integration and testing time that is usually lost when early work runs late.

Interface Control Documents

An Interface Control Document defines how subsystems connect. It can establish communication protocols, electrical connectors, voltage levels, mechanical mounting patterns, coordinate systems, data formats, or any other boundary that multiple designs must share.

Interfaces should be strict enough to support independent work and reliable integration, but not so prescriptive that they prevent better internal designs. They are living documents: when an interface changes, the revision and every affected subsystem need to remain aligned.

Design

The design stage turns requirements and functions into physical and software solutions. Clear ownership allows work to move quickly, while reviews and shared interfaces keep independent decisions connected to the complete system.

Ownership and Coordination

Subsystem ownership works best when success is already defined. A lead can then decide how to meet the requirements, organize the work, and involve less experienced members without guessing what the rest of the project expects.

Ownership should create both autonomy and accountability. The subsystem lead owns the design and its evidence, while system-level reviews protect the interfaces and final project thesis. This keeps decisions close to the people doing the work without allowing subsystems to drift apart.

Concept Generation

The first workable idea is rarely the only good option. Concept generation deliberately creates alternatives before the design narrows. Sketches, analogous mechanisms, morphological charts, quick calculations, and small experiments can all expose approaches that would otherwise be missed.

The goal is not to create a fixed number of ideas. It is to explore the design space far enough that the final choice represents a decision rather than an assumption.

Trade Studies

Trade studies make design considerations visible and defendable. A weighted decision matrix can compare concepts against criteria derived from the requirements, while calculations and test data can replace subjective scores where evidence is available.

The comparison is only as useful as its criteria. A characteristic should receive weight because it supports the project outcome, not because it is easy to measure or makes a preferred concept look stronger. The final record should show the alternatives, assumptions, evidence, and reasoning behind the choice.

Prototyping and Iteration

Prototypes should answer specific questions at the lowest useful cost and fidelity. Early iterations may be paper sketches, cardboard models, CAD studies, simulations, or isolated proofs of concept. More complete prototypes become worthwhile only after simpler versions have answered everything they can.

This progression protects time, money, and material. A problem found in a sketch is inexpensive. The same problem found after manufacturing can force a redesign across several subsystems.

Iteration works best as a disciplined cycle:

1. Identify the most important unknown.
2. Build the smallest test that can answer it.
3. Record the result and what it changes.
4. Revise the design or requirement.
5. Repeat at the next appropriate level of fidelity.

Think slowly, then act fast.

Design Reviews

Design reviews are decision points, not presentations created after the decision has already been made. A review should show the current requirements, interfaces, alternatives considered, calculations, prototype evidence, remaining risks, and the work required before the next stage.

Small reviews throughout development are more useful than one large review immediately before manufacturing. They catch incompatible assumptions while changes are still inexpensive and create much of the reasoning needed for later technical documentation and presentations.

Manufacturing

Manufacturing begins when the design is understood well enough that physical mistakes are less likely to become expensive redesigns. The transition should be deliberate rather than triggered by schedule pressure or the arrival of an exciting idea.

Manufacturing Readiness

Before ordering and fabrication, the design should have an approved revision, resolved interfaces, complete drawings or models, a bill of materials, identified suppliers, and a build sequence. Remaining risks should be visible, and any part that can block the schedule should have a clear procurement or fallback plan.

This readiness check does not require perfect certainty. It establishes that the important uncertainties have been addressed and that manufacturing is now the most efficient way to learn what remains.

Build Planning and Configuration Control

A short, controlled manufacturing window depends on preparation. Fabrication tasks should have owners, required tools, material, inspection points, and an expected order. Parts and assemblies should be checked before later work makes problems harder to correct.

Configuration control keeps the physical system, CAD, software, drawings, and documentation on the same revision. When something changes during the build, the record should explain what changed, why it changed, and which interfaces or tests are affected.

Integration and Verification

Integration proves that individually successful subsystems can operate as one system. Verification proves that the result satisfies the requirements established during pre-design.

Requirement Verification

Every measurable requirement should connect to evidence. Depending on the requirement, that evidence may come from inspection, calculation, analysis, demonstration, or testing. A verification matrix keeps the relationship visible by pairing each requirement with its method, result, and supporting record.

This closes the loop between the original project thesis and the finished design. A feature that works impressively but does not satisfy a requirement is not a substitute for one that does.

Controlled Integration

Subsystems should be integrated in a planned sequence rather than assembled all at once. Power can be verified before sensitive electronics are connected. Communication can be tested before closed-loop control is enabled. Mechanisms can be operated at reduced load before full mission conditions are introduced.

At each step, expected behavior, observed behavior, and configuration should be recorded. When a failure appears, this creates a smaller search area and makes the result reproducible.

Reliability and Fault Recovery

Passing once is different from working reliably. Repeated mission runs, endurance tests, environmental tests, and deliberate fault cases reveal intermittent problems and weak operating procedures.

Testing should also examine recovery. Operators need to recognize failures, place the system in a safe state, and restore operation when possible. A design that fails predictably and recovers cleanly can be more useful than one that performs better only under ideal conditions.

Competition Readiness

A finished machine is only one part of a competition-ready system. Operators, procedures, tools, spare parts, documentation, and presentation material all contribute to the final result.

Operations

Checklists make repeated work consistent. Setup, pre-dive inspection, launch, mission execution, recovery, charging, and shutdown can each have a short procedure developed from actual testing. Practice should use the same equipment, roles, and timing expected at competition.

Performance data from full mission runs provides a more useful readiness measure than intuition. Completion rate, average task time, common faults, and recovery time reveal where additional practice or design work will have the greatest effect.

Spares and Contingencies

Spare parts should reflect observed failures, repair time, and consequence rather than convenience alone. Critical fasteners, seals, connectors, tools, software backups, and preconfigured replacement assemblies can prevent a minor problem from ending a run.

Contingency planning also identifies the minimum useful operating state. If one subsystem fails, the remaining system should still pursue the highest-value achievable outcome safely.

Technical Communication

The engineering presentation and documentation should emerge from the design record rather than being reconstructed at the end. Requirements, trade studies, calculations, test results, failures, and revisions already contain the story: what mattered, what alternatives existed, what the evidence showed, and why the final system looks the way it does.

Clear technical communication is another form of verification. If a decision cannot be explained, its assumptions and evidence may not yet be understood well enough.

Review and Reuse

The process ends by preserving what the project taught. A short retrospective records what worked, what failed, which estimates were inaccurate, which risks appeared, and what should change in the next season.

Final costs, hours, test results, drawings, software, interface documents, and decision records should be archived in a form that another person can use. This creates the reference class for future forecasts and prevents the next project from paying to learn the same lessons again.