Start with the task.
Not the robot.
First principles
A robotic arm is a compelling place to start a conversation. It is not necessarily the best place to start a project. Begin with the thing that needs to happen.
Describe the moment that matters.
What needs to move? What makes one placement different from another? Which part of the environment changes? Describe the task in language that everyone involved can challenge and improve.
A specific description is more useful than a broad ambition to automate. It turns “we need a robot” into a question about an object, a movement, a decision and an intended result. That gives the team something concrete to explore.
Look before and after.
A task sits between other tasks. Something arrives, information is exchanged and someone takes responsibility for what comes next. The handovers can be as important as the movement at the centre.
Walk the whole sequence. Ask how an object is presented, how its destination is known and what happens when the next step is not ready. This does not make the brief unnecessarily broad. It makes its boundaries explicit.
The machine follows the task.
Never the other way around.
Make assumptions visible.
Does the tooling suit the object? Does the object behave consistently? Which changes in the environment matter? How are exceptions noticed and handled? A concept becomes useful when it helps a team name the assumptions that need testing.
Write down what is known and what remains uncertain. Then define the smallest useful step that could answer the next important question. The goal of an early prototype is not to look complete. It is to make the key uncertainty easier to understand.
Define the outcome before the equipment.
A performance target needs context. The operating conditions, variation, interfaces and validation plan shape what a useful result means. A number detached from those conditions is not a project brief.
Let the intended outcome guide the choice of technology. When the task is clear, the discussion about motion, sensing, tooling and control becomes more meaningful — and the reason for each part of the system becomes easier to explain.
An AXIOM design perspective, not a customer case study or a product specification. Any application requires project-specific engineering, assessment and validation.