Work expands to fill the time available for its completion. In interfaces, tasks expand to fill the space and freedom given. Constrain the container and you constrain — and focus — the effort.
In 1955, British historian Cyril Northcote Parkinson published an essay in The Economist that opened with a deceptively simple observation: “Work expands so as to fill the time available for its completion.” He was writing about bureaucracy — specifically, the tendency of organisations to grow regardless of the actual work to be done — but the insight describes something far more universal about human behaviour and effort.
When people are given two hours to complete a task, they use two hours. When given four hours for the same task, they use four hours — and the task rarely improves. The same dynamic operates in space, in words, and in interfaces: give a user a blank 500-word text field for a bio and they will wrestle with it. Give them a 160-character field and they will write something crisp and publish it in ninety seconds.
For designers, Parkinson's Law is less a warning than a design tool. The size of an input signals the expected size of the output. The structure of a form signals the structure of the thinking required. An unconstrained prompt field doesn't give users freedom — it gives them paralysis, and the cognitive overhead of defining the task before they can begin it. Constraints are not restrictions. They are the shape of the job.
“Work expands so as to fill the time available for its completion.”
— C. Northcote Parkinson, The Economist, 1955
The profile bio is one of the most consistently under-designed inputs in social and professional products. The common pattern is a large textarea with a placeholder that says something like “Tell people about yourself” — which is essentially no instruction at all. Users sit in front of that field, unsure how long their bio should be, what it should contain, or how it will be displayed. Many leave it blank. Many write too much. Very few write something they're happy with on the first try.
A character-limited bio field with a live counter and a live preview of how the bio will appear does three things: it sets a clear expectation about length, it shows the output context so users know what they're writing toward, and it creates a satisfying constraint — filling the counter to exactly 160 is a small completion goal in itself.
The live preview is doing more than showing output — it is reducing the cognitive distance between writing and publishing. Users who can see exactly how their bio will look while writing it make better decisions about what to include, how to phrase it, and when they're done. The constrained field gives them a finish line. The preview gives them a destination. Both together make the task feel tractable rather than open-ended.
One of the most common and most damaging applications of the unconstrained textarea is the project brief. A form that asks “Describe your project” in a single large text field is not being open-minded — it is delegating the structure of the brief to the user, who now must decide what a brief should contain, how to organise it, how long it should be, and whether they have covered the right things. This is the work before the work.
Replacing the one large field with three or four targeted questions — What problem does it solve? Who is it for? What's the one thing it must do? — converts an open-ended writing task into a series of answerable questions. Each question is small enough to answer quickly. Together they produce a brief that is more useful than the one most users would produce from a blank box, and they produce it in less time and with less anxiety.
The placeholders in the structured version are not decoration — they are examples that model the format, length, and specificity of a good answer. Users who read a placeholder that says “e.g. Our checkout flow loses 40% of users at the payment step” immediately understand what level of specificity is appropriate. The example does more instructional work than any instruction could.
The blank AI prompt box is Parkinson's Law at its most extreme. “Ask me anything” is the least helpful instruction a product can give. It places the entire burden of task definition — what to ask, how to phrase it, what context to provide, what format to expect — on the user, before they've received any value from the tool. Users who don't know how to prompt well get poor results and blame themselves or the AI. Neither is true: the interface failed to structure the input.
A structured prompt scaffold replaces the blank box with a small set of fields that cover the things a good prompt always needs: the task, the context, the tone, the format. Users who fill in four small fields produce a prompt that would have taken them ten minutes to write from scratch — and the output is better because the input is better.
The scaffold is not the only way to interact with the AI — users who want to write their own prompt can still do so. But the scaffold lowers the floor dramatically for users who don't know how to prompt well, and it improves the output for everyone who uses it, because it ensures that the three or four things a good prompt always needs — task, tone, format, context — are always present. The blank box provides no such guarantee.
The practical question Parkinson's Law asks about every input in your product is: what does the size and structure of this field communicate about the expected output? A large blank textarea says “write a lot, and figure out the structure yourself.” A small, labeled, focused field says “write something specific and concise.” Neither is wrong in every context — but the choice should be deliberate, not the result of defaulting to a generic input.
The structured form approach is particularly powerful for anything users find difficult to start — project briefs, performance reviews, feedback forms, AI prompts, onboarding questionnaires. The difficulty is almost never in the writing; it is in defining the task. Structured fields define the task in advance, which is what the system should be doing rather than the user.
Parkinson, C. N. (1955). Parkinson's Law. The Economist. November 19. · Nunes, J. C., & Drèze, X. (2006). Your loyalty program is betraying you. Harvard Business Review, 84(4), 124–131.