A Design Framework for Human-AI Collaboration
About this report
AI is becoming a routine part of industrial work. It can support decisions, automate routine activities and assist people. But whether AI adoption succeeds depends on more than what the technology can do. It also depends on how people experience and work with it.
This white paper presents a practical framework for designing human-AI collaboration (HAC). It considers the human, the AI system, the task, the organisation and the wider society. It explains what effective collaboration looks like, which conditions influence it, which requirements must be met, and which design decisions organisations should consider.
The report also includes a use case: a human-AI collaborative assembly system with a cobot. The use case shows how design requirements can be translated into specific collaboration features and evaluated in a participant study.
Key findings
Seven messages from the report.
AI can improve productivity, creativity and performance, but it can also create distrust, anxiety, job insecurity, role ambiguity and loss of autonomy. Favourable outcomes depend on deliberate design, not technical capability alone.
Collaboration depends on the interaction between the human, AI system, task, organisation and wider societal environment. A change in one domain can affect the others.
Effective HAC should support positive human experiences, strong collaboration and task performance, and sustainable organisational and societal outcomes.
Human capabilities, AI reliability, task demands, organisational support and societal expectations shape which requirements and design decisions matter most.
HAC should support autonomy, competence, relatedness, safety and privacy, while enabling shared goals, coordination, communication, adaptability, calibrated trust and appropriate human control.
Fairness, transparency, safety, privacy, security, accountability, training and ongoing support should be built in from the outset rather than added after deployment.
As people gain experience and technologies or tasks change, requirements may change too. The framework treats design and evaluation as an iterative process.
Chapter 1
The same AI can be seen as an assistant or as a threat, depending on whether users trust it, have prior experience, and are supported through the change. Management support and implementation strategy decide whether AI is accepted or resisted. At the technology level, reliability, transparency, controllability and safety shape how AI is perceived and used.
A technically capable system can therefore still fail in practice. This is why the report treats human-AI collaboration as a socio-technical design challenge.
It is also a national question for New Zealand. In 2024 Cabinet agreed a national strategic approach to AI. It identified mistrust of AI, together with low uptake across the economy, as key barriers. Trust must be earned through how AI is introduced and experienced, in a single workplace or across a national economy. How HAC is designed is therefore not only an organisational concern.
Effective human-AI collaboration must be designed, not assumed.
Chapter 2
The framework starts from two inputs: the desired outcomes and requirements, and the preconditions of the human, AI, task, organisation and society. Together they inform the design principles. Once deployed, the system produces actual outcomes, which are compared with the desired ones to close the loop.
The five interconnected domains of the socio-technical system.
A system is not effective just because task performance improves. Effectiveness is assessed at three levels.
Achieving the desired outcomes is not automatic. Three layers of requirements must be met.
Drawn from the “Big Five” model of teamwork. Human-AI teams differ in one respect: the human needs a more authoritative role over the AI, for safety.
Aligned with the OECD AI Principles, which New Zealand's Cabinet strategy also adopts:
The aim is not to decide whether an organisation is “ready” or “not ready”. It is to find where strengths, constraints and risks lie, so the design can respond to them.
AI and technical literacy, prior experience, confidence, motivation, adaptability.
Assess with: skills and literacy audit, worker survey
Reliability and accuracy, robustness, transparency and explainability, usability, safety and privacy protection.
Assess with: system validation and testing, edge-case testing, safety and privacy audit
Complexity, physical and cognitive demands, observability, time pressure, uncertainty and risk.
Assess with: workflow analysis, workload assessment, risk assessment
Leadership, culture, management support, training, change management, resources, incentives, technical support.
Assess with: readiness assessment, culture survey, resourcing review
Legislation, standards, ethics, labour policies, public expectations and trust, technological maturity.
Assess with: regulatory and compliance review, stakeholder consultation, industry standards review
Chapter 3
The principles turn the framework into action. Each is a set of questions that connect design choices back to the requirements. They are not a fixed checklist: their relative weight depends on the use case. A safety-critical application may need more human control and transparency, while an experienced workforce may need less onboarding and more personalisation.
Treat the steps as a loop, not a one-off sequence. As users gain experience, tasks change or AI capabilities evolve, the preconditions and requirements shift, so the framework can be revisited.
Identify the preconditions across human, AI, task, organisation and society.
Decide which needs, teamwork and deployment requirements matter most.
Make context-specific design decisions.
Translate them into task allocation, interfaces, safety mechanisms and support.
Assess against the outcomes defined earlier, then refine and repeat.
Chapter 4
To show how the framework works in practice, the team designed and evaluated a collaborative assembly system. The task was a sequential assembly of the BV704 ball valve, manufactured by supporting partner Oasis Engineering. The worker assembled the valve, while a Franka Research 3 collaborative robot acted as an assistant and supplied the right tool at each stage.
The system combined an RGB-D camera with an action-recognition model to detect the current assembly step, plus voice recognition, audio output and a monitor for two-way interaction. The design decisions were turned into configurable features: who initiates the tool handover (worker by voice, or robot automatically), whether the robot asks for confirmation, and how much it explains (detailed, brief or none). The worker could override or stop the robot at any time, and researchers supervised every session.
In Runs 1 to 3, participants were assigned different configuration combinations. In Runs 4 to 6, they chose their own.
The study illustrates human and task-level outcomes. Organisational and societal outcomes are beyond the scope of a single laboratory study.
Findings
Results from 30 participants across six runs each. Survey scores are on a 1 to 7 scale.
Mean self-reported trust and reliance (1–7), Runs 1–6. Axis shows 4 to 6.
| Run 1 | Run 2 | Run 3 | Run 4 | Run 5 | Run 6 | |
|---|---|---|---|---|---|---|
| Trust | 5.47 | 5.40 | 5.37 | 5.87 | 4.60 | 5.83 |
| Reliance | 4.77 | 5.03 | 5.43 | 5.50 | 5.20 | 5.77 |
One visible error was enough for trust to drop, and one run of correct behaviour was enough to restore it. This is what appropriate trust should look like: workers adjusted it to the robot's actual performance. Reliance rose steadily from 4.77 to 5.77 as participants became familiar with the robot, because the task was built around the robot delivering every tool.
Mean completion time per run, in seconds.
Completion time fell from 174 s to 123 s by Run 4, rose to 157 s when participants handled the wrong tool, and reached its lowest, 118 s, in Run 6. Mental demand also fell across runs, from 3.13 in Run 1 to 1.87 in Run 6.
Mean perceived control (1–7).
These participants rated human-led handover as giving more control, yet 23 of 30 chose robot-led. Being able to choose the configuration also raised perceived control. Once a baseline of control is met, people will trade some for efficiency.
Share of 30 participants, by their final preferred configuration.
Overall preferences settled quickly, but only 23% of participants kept the same configuration across all three self-selected runs. The system supported every change, because participants could reconfigure before each run.
The same feature can create both benefits and costs, which is why deliberate design matters.
Improved efficiency
Reduced perceived control
Supported oversight
Added interaction burden
More information
Slower performance
There is no single universally optimal human-AI collaboration configuration.
Chapter 5
Organisations should treat human-AI collaboration as a socio-technical design challenge, not simply a technology implementation exercise.
Behind the report
Lead Researcher
Department of Mechanical and Mechatronics Engineering, The University of Auckland
Researcher
School of Psychology, The University of Auckland
Researcher
Department of Mechanical and Mechatronics Engineering, The University of Auckland
Graduate Researcher
Department of Mechanical and Mechatronics Engineering, The University of Auckland
Graduate Researcher
Department of Mechanical and Mechatronics Engineering, The University of Auckland
Graduate Researcher
School of Psychology, The University of Auckland
Supporting partner: Oasis Engineering.
Financial acknowledgement: This report is proudly brought to life with support from the Transdisciplinary Ideation Fund at the University of Auckland.
How to cite: The University of Auckland, “Working with AI: A Design Framework for Human-AI Collaboration,” HAC White Paper, September 2026.
Licence: This report is licensed under CC BY-NC-ND 4.0 (Attribution-NonCommercial-NoDerivatives).
43 pages, with the complete framework tables, the detailed use case, references and the post-task survey.