The Engineering Design Process for FIRST Teams

A successful FIRST team rarely reaches competition day with its first idea. Strong robots emerge through a repeatable cycle of asking questions, exploring options, building prototypes, testing evidence and making informed changes. This engineering design process gives students a practical way to turn a broad challenge into a machine that performs reliably when the pressure is on.

The same approach works across FIRST programs. A Jr.FLL team may investigate a simple mechanism, while a FIRST LEGO League team develops an autonomous solution. FIRST Tech Challenge and FIRST Robotics Competition teams work with more complex systems, including sensors, motors, software, fabricated parts and alliance strategy. The scale changes, but the habits remain consistent.

For Australian teams, planning must fit local conditions. School terms can be short, travel between regional towns and major cities can be lengthy, and access to specialist workshops varies widely. A team in Melbourne, Sydney, Brisbane or Perth may have different suppliers, mentors and event schedules from a rural club. A clear design process helps every group use its time and resources wisely.

Maryland FIRST supports teams, mentors, coaches and volunteers across several FIRST programs. Its resources can help Australian educators and community groups understand how teams operate, prepare students for events and connect engineering work with teamwork, creativity and STEM learning.

Understand the Challenge Before Building

The first step is to understand what the robot must do. Students should read the game manual carefully, identify scoring opportunities, study field dimensions and record restrictions on robot size, materials, motors and control systems. A team can lose valuable build time by designing a mechanism that is illegal, too large or impossible to operate within the match rules.

Turn the game into a list of engineering requirements. Separate essential functions from desirable ones. For example, an FRC team may need to collect, transport and score a game piece, while also climbing or balancing at the end of a match. Each function should have a measurable target, such as cycle time, reach, accuracy, weight or maximum current draw.

Teams should also investigate the operating environment. Ask what surfaces the robot will encounter, how much driver visibility is available and how alliance partners may affect its movement. Reviewing a first FRC competition can help newer students understand queueing, inspection, pit work, match timings and the practical realities of an event.

Assign students to gather evidence rather than relying on assumptions. A scouting group can examine videos and previous games, programmers can assess sensor requirements, and builders can identify likely materials and fabrication methods. This makes the problem concrete and gives every student a meaningful role from the beginning.

Generate and Compare Design Concepts

Once the requirements are clear, encourage several possible solutions. Quick sketches, cardboard mock-ups, simple CAD models and whiteboard diagrams allow students to compare ideas before committing to a complicated build. A brainstorm should welcome unusual suggestions, but the team must eventually assess each concept against the same criteria.

Useful criteria include reliability, speed, controllability, ease of manufacture, repair time, weight, cost and compatibility with alliance play. A technically impressive mechanism may be a poor choice if it jams after a few cycles or takes hours to repair. In Australian schools and community clubs, access to CNC machines or specialist suppliers may be limited, so designs should reflect the tools, budget and time actually available.

Design question	Evidence to collect	Decision it supports
Can the mechanism complete the task?	Prototype trials and cycle data	Whether the core function is viable
How quickly does it operate?	Timed repeated tests	Which strategy produces more scoring opportunities
Will it survive a match?	Stress tests and inspection	Whether the structure needs reinforcement
Can students build and repair it?	Manufacturing time and service checks	Whether the design suits the team’s resources
Does it work with alliance partners?	Driver practice and mock matches	Whether the robot contributes effectively in play

A decision matrix can make trade-offs visible. Give each concept a score against agreed criteria, then discuss the results as a group. Students should learn that engineering is rarely about finding a perfect answer; it is about selecting the strongest option for a specific set of constraints.

Prototype, Test and Iterate

Build the simplest prototype that can answer the next important question. A cardboard intake, 3D-printed bracket, wooden frame or temporary software routine may reveal more than a polished final assembly. Prototyping reduces risk because the team discovers weaknesses while changes are still inexpensive.

Testing should produce useful data. Rather than saying a mechanism “felt good”, record how many successful cycles it completes, how often it jams, how long it takes to reset and how much battery power it uses. Use a consistent test method so results from different versions can be compared fairly. A shared engineering notebook or digital log helps preserve decisions when students are absent or roles change.

Iteration means changing one or more design features in response to evidence. If a lift stalls, the team might examine gearing, friction, load distribution, motor temperature and software limits. If autonomous navigation drifts, students can check sensor placement, calibration, wheel slip and field references. Each test should end with a clear decision: keep the design, modify it, or replace it.

The cycle may feel repetitive, especially during a busy build season, but repetition is how a robot becomes dependable. A team that tests early has time to discover problems before scrimmages and official events. This is especially valuable when Australian teams face significant travel to regional qualifiers or state-level competitions, since a reliable robot reduces the chance that a small fault ruins an entire weekend.

Design for Reliability and Safety

Performance matters only when the robot can deliver it repeatedly. Reliability engineering begins with simple choices: protect wiring, secure fasteners, provide access to serviceable parts and avoid unnecessary complexity. Label connectors and mechanisms so students can diagnose faults quickly in the pit. A repairable design is often more valuable than a slightly faster design that is difficult to understand.

Use failure-mode thinking to anticipate trouble. Ask what could break, jam, overheat, disconnect or become unsafe. Consider loose chains, damaged belts, bent shafts, software crashes, depleted batteries and unexpected contact with field elements. Create inspection checklists for before a match, after a match and before transport.

Safety should be built into every stage. Students need clear rules for handling tools, batteries, moving assemblies and electrical systems. Test robots in controlled areas, use proper protective equipment and follow the event’s inspection requirements. Coaches and mentors should supervise riskier tasks while still allowing students to make technical decisions and learn from controlled mistakes.

Resource planning also affects reliability. Keep spare components for likely failures, record supplier lead times and avoid depending on a single hard-to-source part. A team in regional Australia may need to order components well ahead of a metropolitan event, while a school club may have to work around limited workshop access. Good engineering includes preparing for those realities.

Document, Communicate and Improve

A design is valuable when the whole team can understand it. Maintain records of requirements, sketches, test results, software versions, bill of materials, maintenance tasks and design decisions. Documentation supports handovers between school terms and helps new students contribute without starting from scratch.

Communication should be treated as an engineering tool. Builders need to tell programmers about encoder locations and mechanical limits. Programmers need to explain control assumptions to drivers. Scouters should share evidence about alliance needs so designers can prioritise useful capabilities. Short stand-up meetings and clear task boards can keep a large team aligned without filling every afternoon with meetings.

Students should also explain why their design changed. A design review might include the original goal, the evidence gathered, the problem encountered and the next action. This develops technical communication for judging presentations, strengthens the team’s engineering portfolio and helps students recognise that setbacks are part of professional practice.

At competition, collect observations rather than relying on memory. Record cycle times, failures, driver feedback and alliance outcomes between matches. Then use that information to make focused adjustments. A calm pit crew that can identify, communicate and repair a fault often contributes more to match performance than a last-minute redesign.

The engineering design process becomes powerful when it is visible, repeatable and shared. Start with the challenge, define measurable requirements, compare realistic concepts, prototype quickly, test honestly and improve with evidence. Maryland FIRST’s programs offer a strong framework for students aged 4–18, while local Australian teams can adapt the same methods to their school calendars, facilities and community partnerships.

Bring students, mentors and volunteers together around a real design problem, give them permission to test ideas, and document the learning at every stage. Explore FIRST team opportunities, connect with Maryland FIRST resources and build a programme where engineering is something young people do with their own hands.