Crowdtasks must be decomposed to a granularity requiring no background knowledge

What it is

For tasks addressed to the general crowd, the test of decomposition granularity is not "can a person finish it" but "can a stranger with zero project context do it correctly in tens of seconds." Participants are transient, non-professional, and free to leave — they will not invest learning effort to understand your context. Each unit must therefore be self-contained: a microtask carries all the information needed to complete it, and its output is a standard result that can be merged. The counterexample is posting a data-cleaning job as one block: only someone who knows the source schema can do it, and that person is not in the crowd.

Why it happens

The granularity constraint follows from three features of participation. First, no-commitment entry and exit: joining and abandoning cost nothing, so any task requiring "understand the background first" loses most participants in the first minute — the steeper the cognitive ramp, the higher the abandonment. Second, the crowd's priors cannot be assumed: the designer cannot know what participants know; jargon, project acronyms, and domain conventions all fail, and the only reliable shared language is the instruction itself. Third, quality control presupposes atomicity: only small, standardized units admit redundancy, agreement checks, and spot audits (the subject of the quality-control group); when a large task fails, the failing step cannot be located and the whole must be redone. Granularity simultaneously determines who can do the work, how long it takes, and how failures get repaired.

Studying it

• Paradigm: task-publication experiments on crowdsourcing platforms — the same work posted at different granularities (whole block / partially split / microtasks), comparing completion rate, unit cost, and output acceptance rate; much of the practice base comes from annotation, transcription, and verification platforms.
• Variables: unit duration, self-sufficiency of instructions, and the type and amount of required background knowledge as independent variables; acceptance rate, completion rate, abandonment-position distribution, and cost per accepted output as dependent variables.
• Use in interface research: task editors and publishing flows for crowdsourcing systems — granularity checks (estimated duration, instruction length, jargon scan) can warn before publication.
• Methodological caveat: granularity and instruction quality are tightly coupled (small tasks are naturally easier to write instructions for), so single-variable manipulations are rarely clean; "requires no background" must be tested with genuinely naive participants — designers always find their own instructions clear, the curse of knowledge at its most toxic in task design.

Where it stops holding

Smaller is not better: over-decomposition pushes each unit's information content toward zero, while participants' startup costs (reading instructions, learning the interface) dominate total time, unit pay looks insultingly small, and abandonment rises again. A cost-optimal middle granularity exists and shifts with task type. The constraint also targets open crowdsourcing of anonymous masses; decomposition for professional communities (open source, wikis) or internal staff can assume background knowledge as an asset and cut much coarser — imposing microtask standards on professional collaboration produces fragmenting busywork.

Applying it

• Accept granularity by the "stranger test": three people with no context, no extra explanation offered; can each complete one unit correctly within a minute? Wherever they stall is the decomposition or instruction defect.
• Scan instructions for domain jargon and project-internal abbreviations; replace everything with expressions or legends defined inside the instructions.
• Show "estimated duration × unit price" in the pre-publication checklist; anything beyond a few minutes goes back to decomposition.
• Attach minimal context to every unit (one line of background plus one completed example) — context travels with the task, not with the participant.
• Verification: log abandonment position per unit (instructions page / first submission / midway); concentration at the instructions page or first item flags granularity or instruction overload, while an acceptance-rate collapse on one unit flags a self-sufficiency problem needing re-splitting.

Related

• Same group: V9.04.2 Ambiguity in instructions converts directly into noise in results · V9.04.3 Boundary examples unify judgment better than abstract rules · V9.04.4 Unit duration determines mid-task abandonment · V9.04.5 The decomposition determines whether results can be reassembled
• Nearby: V9.05 Quality Control and Redundancy in Crowdsourcing · V9.06 Contributor Motivation and Payment
• Search terms: task granularity · microtask · crowdsourcing decomposition