{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-09-21T16:49:05.319Z"},"content":[{"type":"documentation","id":"67be41cc-46ac-4ec7-ab21-a9cde2e0060f","slug":"function-allocation-human-ai-research","title":"Function Allocation: Deciding What AI Should Do in Your Research and What You Keep (2026)","url":"https://www.koji.so/docs/function-allocation-human-ai-research","summary":"Function allocation decides which research stages a person performs and which an AI performs. The 1951 Fitts List treats this as sorting tasks by capability, but Dekker and Woods showed automation transforms the tasks you keep rather than leaving them unchanged. Allocate by stage and level instead, and avoid the tedious-versus-judgment seam because tedious stages often produce the judgment used downstream.","content":"Most teams allocate research work to AI the same way they would divide chores: list the tasks, decide which ones the machine is good at, hand those over, and keep the rest unchanged. That method has a name in human factors, a seventy five year history, and a well documented record of not working. The reason is not that the lists were wrong about machine capabilities. It is that handing over one task silently changes every task you kept.\n\n## The short answer\n\nStop asking *who does what*. Function allocation is not a one time division of a fixed set of tasks, because automating a stage changes the nature of the stages around it. Allocate instead by stage and by level: for each step in your research pipeline, decide separately how much the system does and how much of its work remains visible and reversible to you. And be suspicious of the most popular seam of all, *give the AI the tedious parts and keep the judgment parts*, because the tedious parts are usually where the judgment came from.\n\n## The 1951 list everyone still uses\n\n### What Fitts actually wrote\n\nIn 1951 Paul Fitts led a report on human engineering for air navigation and traffic control. It contained a table summarising the activities humans do better than machines and the activities machines do better than humans. Humans were credited with improvisation, judgement, and flexible pattern recognition; machines with speed, power, repetitive precision, and freedom from fatigue.\n\nThe table became known as the Fitts List, and later as MABA-MABA, short for *Men-Are-Better-At / Machines-Are-Better-At*. The MABA-MABA label first appeared in 1970 and came into regular use in the 1980s.\n\n### Why the list survived seventy five years\n\nThe list persists because it is genuinely useful as a description and genuinely comfortable as a procedure. It tells you something true about relative capability, and it converts an open ended design problem into a sorting exercise that can be finished in an afternoon.\n\nEvery generation of technology reruns it. In 2026 the table is being rewritten with *AI* in the machine column, and the new entries are mostly the old entries with a wider scope: the machine is better at reading 400 transcripts, the human is better at knowing which finding matters.\n\n## The substitution myth\n\n### What Dekker and Woods showed\n\nIn 2002 Sidney Dekker and David Woods published a paper in Cognition, Technology and Work with the title *MABA-MABA or Abracadabra? Progress on Human-Automation Co-ordination*. Their argument is that substitution based allocation cannot deliver what it promises, and that the lists themselves are part of the problem. Such lists, they wrote, give the psychologically uninitiated an illusion of understanding, *a mere fallacy of deeper access*.\n\nThe central claim is compact enough to quote in full: *Capitalising on some strength of automation does not replace a human weakness. It creates new human strengths and weaknesses* in ways that are frequently not anticipated. Their conclusion is that system developers should abandon the traditional *who does what* question of function allocation, and ask instead how the human and the automated system will coordinate.\n\nThe mechanism they identify is that it is not the technology that gets transformed while people carry on as before. People and their practice get transformed.\n\n### The three things that change when you automate one stage\n\nTake a concrete case. You automate transcript coding and keep theme interpretation.\n\nFirst, the input to your retained task changes. You are now interpreting a code frame you did not build, which means the interpretation stage starts with an assumption it previously derived.\n\nSecond, your competence at the retained task changes. This is the uncomfortable one and it is developed further in the literature on the ironies of automation.\n\nThird, a new task appears that nobody allocated: monitoring the automation. That task did not exist in your before picture, it was not on the list, and it typically lands on the most experienced person available.\n\nA division of labour that produces three unlisted changes is not a division of labour. It is a redesign.\n\n## The allocation space is bigger than two options\n\n### Four stages, ten levels\n\nIn 2000 Raja Parasuraman, Thomas Sheridan and Christopher Wickens published a model in IEEE Transactions on Systems, Man and Cybernetics that remains the standard framework. It decomposes any function into four information processing stages: information acquisition, information analysis, decision and action selection, and action implementation. Each stage can independently sit at one of ten levels of automation, from *the computer offers no assistance* up to *the computer decides and acts autonomously and tells the human nothing*.\n\nFour stages at ten levels each gives 10,000 distinct allocations of a single function. The binary question *should we automate this* selects between two of them.\n\n### Your research pipeline has eight stages\n\nWrite out the stages of a study honestly and you get something like: recruit and screen, ask the questions, probe the follow ups, transcribe, code, build themes, quantify and weight, and write the recommendation.\n\nCollapse the ten levels to three practical ones, since most teams cannot distinguish more than three: the person does it, the system proposes and the person decides, or the system does it and reports afterwards.\n\nEight stages at three levels is 3 to the power of 8, which is 6,561 possible configurations. In practice teams choose between two of them: everything manual, or everything automated. Two out of 6,561 is not a decision, it is a default, and the useful work is almost entirely in the configurations nobody considers. Platforms built for stage level control, Koji among them, exist to make that middle ground reachable rather than theoretical.\n\n### The configurations nobody considers\n\nThe interesting allocations are the mixed ones. Automating *probe the follow ups* while keeping coding manual produces a very different study from automating coding while moderating by hand, even though both are described as *we use AI for part of the research*. The first changes what data exists; the second changes only how existing data is summarised. Those are not comparable decisions and they should not share a label.\n\n## The seam that looks right and is not\n\n### Why tedious-versus-judgment fails\n\nThe most common allocation heuristic in 2026 is *automate the tedious parts and keep the judgment parts*. It sounds obviously correct. It is the substitution myth in its most persuasive form.\n\nThe problem is that the tedious parts are frequently how the judgment is produced. Coding 40 transcripts by hand is tedious, and it is also the process by which a researcher comes to know what is in the data, which quotes sit behind which theme, and which participants contradicted themselves. The judgment applied at the interpretation stage is not a separate faculty that was waiting in reserve. It was manufactured during the tedium.\n\nSo the allocation inverts its own intent. You keep the judgment stage and remove the stage that supplied the judgment. On paper you retained the important half. In practice you retained the label.\n\n### The stages are not independent\n\nThis is the deeper point and it generalises beyond any single example. Allocation methods work by listing stages separately, and a list implies the items are independent. The competence you bring to stage six is partly a product of having personally performed stage five. Hand away stage five and stage six degrades, even though stage six is still marked *human* on the diagram.\n\nAny allocation that treats the stages as independent will therefore look better on paper than it turns out to be, and the gap will not show up in the allocation review, because the review examines the same list that omitted the dependency.\n\n### The two requirements that replace the list\n\nDekker and Woods point at coordination rather than division, which in practice means two testable requirements. The automated stage must be *observable*: you can see what it did and on what basis, not only what it concluded. And it must be *directable*: you can change what it does mid-course rather than only accepting or rejecting the output. An allocation that fails either test is not a teammate, it is a black box with a job title.\n\n## How Koji helps\n\nKoji is designed around stage level allocation rather than an all-or-nothing switch, which is what makes the 6,561 configurations reachable instead of theoretical.\n\nAt the asking and probing stages, AI-moderated interviews and voice interviews let the system conduct the conversation and follow up on reasoning, at conversational scale, while the research brief you wrote sets what it is allowed to pursue. At the analysis stages, Koji performs thematic analysis across every transcript automatically, but the themes stay linked to the underlying quotes, so the coding stage remains observable rather than collapsing into a summary you have to take on faith.\n\nThe structured question types are the lever that keeps allocation explicit. Koji supports six: open_ended, scale, single_choice, multiple_choice, ranking and yes_no. The closed types move measurement to the system, which is a stage where machines genuinely dominate. The open_ended type keeps the interpretive stage available to you with the evidence attached. Deciding the mix per question is a per stage allocation decision, made at design time and written down, rather than an implicit one discovered later.\n\nCustomizable AI consultants address the directability requirement: you can specify how the consultant probes and analyses rather than accepting one fixed behaviour, which is the difference between an automated stage you can steer and one you can only switch off. Real-time reporting keeps the output continuously inspectable rather than delivered as a finished artefact at the end. Against traditional tools, the comparison is not speed. Legacy survey platforms automate stage one and stage four, collection and delivery, and leave stages two and three untouched. Koji lets you place each stage deliberately, which is the decision the Fitts List was always standing in for.\n\n## Common mistakes\n\nTreating automation as a single switch. The unit of allocation is the stage, not the study.\n\nUsing the tedious-versus-judgment seam without checking the dependency. Ask where the judgment for the retained stage is currently produced, and check that you are not automating exactly that.\n\nForgetting to allocate the monitoring task. Automating a stage creates oversight work that was on nobody list beforehand, and it lands on your most experienced researcher by default.\n\nAccepting an unobservable stage. If you cannot see the basis for an output, you cannot review it, and approving it is a formality.\n\nRewriting the Fitts List with AI in the machine column and considering the question answered. Whichever tool you run, Koji included, the allocation decision stays yours and belongs in writing.\n\n## Frequently asked questions\n\n### What is function allocation?\n\nFunction allocation is the process of deciding which parts of a task are performed by a person and which by an automated system. It originates in human factors engineering, most famously in the 1951 Fitts List. Modern practice replaces the one time division of tasks with a stage by stage decision about how much the system does and how visible its work remains.\n\n### What is the Fitts List or MABA-MABA?\n\nThe Fitts List is a 1951 table contrasting what humans do better than machines with what machines do better than humans. It became known as MABA-MABA, for Men-Are-Better-At / Machines-Are-Better-At, a label that first appeared in 1970. It remains widely used despite sustained criticism that it encourages treating automation as simple substitution.\n\n### What is the substitution myth?\n\nThe substitution myth is the assumption that automating a task leaves the remaining tasks unchanged, so a person plus automation equals the same work with one part done faster. Dekker and Woods showed that automation instead transforms the practice around it, creating new demands and new weaknesses that were not part of the original allocation.\n\n### Should I automate the tedious parts of research and keep the judgment?\n\nBe careful with that split. Tedious stages such as hand coding transcripts are often where familiarity with the data is built, and that familiarity is what the later judgment stage runs on. Before automating a tedious stage, check whether it is the source of the competence you apply downstream. If it is, keep a sampled version of it rather than removing it entirely.\n\n### How many ways can a research pipeline be allocated?\n\nMore than teams assume. The Parasuraman, Sheridan and Wickens model gives four stages at ten levels, so 10,000 allocations of a single function. An eight stage research pipeline at three practical levels per stage yields 6,561 configurations, and most teams choose between just two of them: fully manual or fully automated.\n\n### How do I tell whether an automated stage is allocated well?\n\nApply two tests. Observability: can you see what the system did and on what basis, not just its conclusion. Directability: can you change its behaviour while it is running rather than only accepting or rejecting the result. A stage that fails either test cannot be genuinely reviewed, whatever the diagram says.\n\n## Related Resources\n\n- [Structured Questions in AI Interviews](/docs/structured-questions-guide) - the six question types, and how the open and closed split maps onto stage level allocation\n- [The Ironies of Automation](/docs/ironies-of-automation-research-analysis) - what happens to the human stages after you allocate badly\n- [Automation Surprise in Research](/docs/automation-surprise-research-operations) - tracking which configuration your pipeline is actually in\n- [AI Over-Reliance and Automation Bias](/docs/ai-overreliance-automation-bias-research) - researching whether your users trust your AI too much\n- [Thematic Analysis Guide](/docs/thematic-analysis-guide) - the coding and theming stages in full, for deciding what to allocate\n- [Qualitative Research Codebook](/docs/qualitative-research-codebook) - building the code frame that automated coding would otherwise build for you","category":"Research Methods","lastModified":"2026-09-21T03:24:23.148553+00:00","metaTitle":"Function Allocation: What to Automate in Research","metaDescription":"The Fitts List asked who does what. Fifty years of evidence says that question is wrong. How to allocate research work between you and AI.","keywords":["function allocation","Fitts list","MABA-MABA","substitution myth","levels of automation","human-AI collaboration","research automation"],"aiSummary":"Function allocation decides which research stages a person performs and which an AI performs. The 1951 Fitts List treats this as sorting tasks by capability, but Dekker and Woods showed automation transforms the tasks you keep rather than leaving them unchanged. Allocate by stage and level instead, and avoid the tedious-versus-judgment seam because tedious stages often produce the judgment used downstream.","aiPrerequisites":["Familiarity with the stages of a research study from recruitment through reporting","Some experience using AI tools for transcription, coding or analysis"],"aiLearningOutcomes":["Explain why substitution based function allocation fails","Map a research pipeline into stages and allocate each one separately","Identify when a tedious stage is the source of downstream judgment","Apply the observability and directability tests to an automated stage"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}