Design Process Documentation

The design process section is usually one of the highest-weighted parts of your portfolio. This is where you show judges how your team went from identifying a problem to actually solving it.

The Engineering Design Process

Engineers everywhere use this process to solve complex problems step by step. What matters for your portfolio is showing how your team actually applied it throughout the season to improve your robot.

Here's the process:

Problem Definition

Start by clearly stating the challenge you're addressing:

Our robot needs to launch game elements 54 inches high while staying within the 18" x 18" x 18" starting size constraint.

Include:

• Game requirements
• Constraints (size, weight, rules)
• Success criteria

Iterations

Document multiple design ideas, not just the final one. Create a graph, decision matrix, or table to compare results:

Document Your Iterations With Measurable Outcomes

Don't just show different versions - back up your design changes with real data. Track actual metrics across your iterations so you can prove each change made a measurable difference. This turns your design story from "we tried a bunch of stuff" into "we systematically improved performance."

Example: Tracking Shooting Time Across the Season

Here's how you could document iteration outcomes with real performance data. By measuring shooting cycle time at each competition, you can show judges the direct impact of your design changes:

What This Shows: Starting at 10 seconds per 3 artifacts shot at LM1, we made minimal improvements by LM2 (9.5s). However, between LM2 and League Tournament we achieved a major breakthrough, dropping to 3 seconds through a fundamental design change. Continued optimization led to 1.5 seconds at Semifinals and finally 0.5 seconds at State.

• LM1 (10s): Initial design with static launch
• LM2 (9.5s): Minor tuning of PIDF
• LT (3s): Added a second motor to the flywheel
• SQ (1.5s): Implemented automated firing sequence
• CMP (0.5s): Increased flywheel weights

Why Judges Care: This kind of documentation proves you understand the connection between design decisions and actual results. It shows real problem-solving, not just luck. Numbers are always stronger than vague descriptions.

Document Your Iterations

Show your iterative process with each version: