Throw-away Prototyping

Goal

Throw-away prototyping exists to settle an open question about what should be built, at the lowest possible price and before the commitment is made. An artefact is built, it is put in front of people, they are observed, what was learned is written down, and the artefact is destroyed. The decision it supports is the one that costs the most when it is taken badly: the shape of the solution itself, at the moment when nobody yet knows it.

BABOK describes the element in a single sentence in which every term carries weight: the prototype is generated with simple tools, paper and pencil, a whiteboard or software, to uncover and clarify requirements, it may be updated and evolve in the course of the discussion and it does not become workable code and is not maintained as a deliverable once the final system or process is implemented. That last clause is the whole technique. It states what becomes of the artefact and it stops there: the medium, the fidelity and the size are left entirely open.

Zero residual value is the design goal, and it is what buys the speed. Because nothing will survive, the mock-up may legitimately do without architecture, error handling, security, persistence and tests. The bill it refuses is exactly the bill that evolutionary prototyping cannot refuse, since there the artefact is the delivered solution. The deliverable of throw-away prototyping is therefore written knowledge: a requirement, a decision, the option that was rejected and the reason it was rejected. The fate of the artefact, destruction, is what defines the technique.

Usage

When to use it

• An open question about what to build: a mock-up settles in days what a workshop debates for weeks.
• Functionality that is hard to elicit otherwise: showing it obtains what describing it does not.
• Conflicting points of view among stakeholders: the artefact moves the disagreement from words onto a shared object.
• Several design options to compare: building three and destroying two costs less than choosing badly.
• High design or feasibility risk, commitment imminent: a narrow yet deep vertical prototype, on the exact axis of the doubt.
• Contested rules or data: the technique reaches beyond the interface, into processes and business rules.

When not to use it

• The artefact must become the delivered solution: take evolutionary prototyping, which pays the quality floor from increment zero.
• No decision is waiting on the result: get the answer through an interview or a focus group and prototype afterwards.
• The disagreement is about the process, its roles and its timing: nothing to operate, model the workflow.

Description

Two independent axes

BABOK sorts prototypes on two distinct elements. The approach states what the artefact becomes: it is destroyed, or it is grown into the solution. The method states what it is made of and what someone does with it: a storyboard is read, a paper prototype is operated, a simulation is executed by a machine or workflows are modelled, a method borrowed from process modelling. Every prototype carries an answer on each of the two axes, and the two answers are free of each other. Throw-away prototyping is an answer on the approach axis: it fixes the fate of the artefact and leaves the medium entirely open. A throw-away prototype is a whiteboard sketch, a set of panels, a spreadsheet, a clickable screen or a piece of code, and it stays throw-away in every one of those cases. On the approach axis, the only comparison that means anything is this one: destroy the artefact or grow it. The routing between the two axes belongs to prototyping taken as a whole.

What the discard buys

Two properties follow from the discard, and they are the two reasons to choose this approach. The first is that the artefact is cheap to kill. Killing an option costs what the option cost, and the option cost almost nothing. That is what makes it rational to build several and destroy all but one, which is the most productive form of reasoning the technique allows: objects are compared, rather than opinions about objects.

The second is that the artefact is safe to criticise, and BABOK puts this among the technique's strengths itself: faced with a throw-away or paper mock-up, users may feel more comfortable being critical of it because it is not polished and release-ready. The word matters: it is the users, the person with the object in front of them who will have to work with it. The steering committee gives an opinion on an object it will never use. A finished screen invites politeness. A sketch invites contradiction, and contradiction is the product the team came for. The roughness of the artefact is its working surface.

Exploration or experiment

Christiane Floyd set out in 1984 the taxonomy that gives throw-away prototyping the internal structure the word throw-away does not hint at. She distinguishes three goals: exploration, experiment and evolution. The third produces an artefact that is kept and adapted to requirements that could not be anticipated, and that is evolutionary prototyping. The first two produce an artefact that is destroyed, and they are the two forms of throw-away prototyping. They are run differently, and above all they finish differently.

Exploration asks « what should be built? ». Alternatives are explored before a solution is selected, so the artefact carries several variants, it is as cheap and as low in fidelity as the question permits, and it is done when the ambiguity is gone: the option is chosen, the reason for the choice is written down. Its product is a decision.

Experiment asks « does the proposed design hold? ». A solution is already on the table and the job is to establish its adequacy before full-scale implementation begins. The artefact is therefore a single variant, built narrow and deep on the exact aspect under test: this is the vertical prototype BABOK lists among the technique's strengths, the one used for technical feasibility studies and proof-of-concept work. It is done when the proposal has been shown adequate or inadequate, and an honest experiment can return a negative verdict. Its product is a verdict.

The same screen separates the two goals. A school that does not yet know whether its students compose their semester by module or by timetable slot builds two cheap mock-ups and watches which one holds: that is exploration, and it is finished on the day the question is settled. The same school, having settled on the slot-first design, wanting to know whether a student can fill a weekly grid unaided in under five minutes, builds one mock-up, narrow and deep on the grid alone and watches it until the proposed design has been judged adequate or inadequate: that is experiment. Same cheap artefact, same discard, a different definition of done.

A practitioner who does not know which of the two they are running cannot tell when to stop, cannot say whether the prototype succeeded and will go on polishing an artefact that has already done its job. The confusion costs in the other direction too: eight users are convened for a technical feasibility question a single developer would have settled in a day, or one architect is left to choose a screen layout only real users could have judged. The goal governs the room as much as it governs the artefact. Naming the goal is therefore the technique's first decision, before the medium and before the fidelity.

Fidelity is the control variable

BABOK gives both ends of a single axis. At one end, the unpolished mock-up is freely criticised. At the other, a prototype that is deeply elaborate and detailed gives stakeholders unrealistic expectations for the final solution, on completion dates as much as on performance, reliability and usability. The same slider produces both effects.

Fidelity is therefore a cost, and it is charged twice: once to produce it and once in the credibility it lends an artefact that must remain killable. The rule that follows is short. Take the lowest fidelity that answers the question. Every point above that buys commitment where the team meant to buy information.

Buying the risk down before the commitment

The throw-away prototype has a theory, and the theory has a name: the spiral model, published by Barry Boehm in 1988. In it the prototype holds a named role, that of an instrument for buying risk down, and the reasoning unfolds in three moves. At any moment a project carries one dominant uncertainty, the one whose wrong answer would cost the most: the screen nobody knows how to draw, the business rule two departments state differently, the load nobody knows the architecture will carry. The team then builds the cheapest artefact that can settle that uncertainty alone. Once the risk is resolved, and only then, the next level of elaboration is committed to. The rule the spiral imposes fits on one line: nothing is committed on an assumption. Throw-away prototyping is how that rule is kept, and this is the reasoning that turns an artefact built to be destroyed into an investment. The spending buys information, and information obtained before the commitment is worth more than the same information obtained after it, because it can still be acted on. A throw-away prototype is the price a team pays for not discovering its question at the moment when it is too late to answer it.

Brooks and his 1975 retraction

The line that gave the approach its name is Frederick Brooks's, in 1975: « Plan to throw one away; you will, anyhow. » His analogy is the pilot plant: a chemical process that works in the laboratory cannot be moved into a factory in one step, an intermediate plant is built first, in the knowledge that it will be scrapped. His framing of the decision has aged well: a system that gets thrown away will be built anyway. The question is whether that was planned for or whether the throwaway was delivered to the customer.

Twenty years later, Brooks withdrew that advice: « This I now perceive to be wrong, not because it is too radical, but because it is too simplistic. » The retraction is part of what a practitioner needs in order to use the 1975 line at all, because it fixes its scope and says where it stops applying.

What he withdrew reads precisely: building the whole system twice, under the waterfall model, a first complete system nobody will use. What he embraces instead is the incremental growth of the product. What he never withdrew is building something cheap in order to learn from it before committing, and that is what throw-away prototyping is. Brooks's pilot plant was an entire system. A mock-up is a question given a shape. Brooks therefore lets himself be enlisted by neither approach, and what he leaves the practitioner is more useful than a verdict: the first thing built will be wrong, whatever happens, and it remains to be decided in advance who pays for it. The team that deletes it or the customer who runs it. Throw-away prototyping is the answer that deletes it, and that answer is given before the first line.

Running a throw-away prototype

1. Write the question, in one sentence, before drawing anything
   With it goes the decision that waits on the answer. « Do students choose by module or by timetable slot? » is a question. « Show what the registration screen could look like » is not: it has no acceptance criterion, so the artefact can never be finished, so it will never be destroyed.
2. Name the goal: exploration or experiment
   This choice governs the acceptance criterion, the number of variants and the fidelity, and it is made before them. Exploration: several cheap variants, in breadth, done when the ambiguity falls away. Experiment: one variant, narrow and deep on the aspect in question, done when the proposed design has been judged.
3. Treat fidelity as a cost and take the lowest that answers the question
   The whiteboard before the wireframing tool, the wireframing tool before code. Going up a notch is a decision.
4. Announce the discard out loud, at the start, to everyone who will see the artefact
   Say what is missing as well: no architecture, no error handling, no security, no persistence, no tests. That sentence is what licenses the shortcuts, and it is the same sentence that makes the artefact safe to criticise. Left unsaid, it remains a private assumption, and the first person who asks why this cannot just be shipped will contradict it.
5. Run the session with real users, on a real task
   Observe, do not sell. The artefact is there to be attacked, and a demonstration is the one format in which nobody attacks it. The facilitator's job during the session is to bring the room back to the question written down at the start.
6. Capture the learning while the artefact is still alive
   Write the requirement, the decision, the rejected option and the reason for the rejection, into the place where the specification lives. The prototype produces knowledge and nothing else: whatever is not written down before the discard is destroyed with the artefact.
7. Destroy the artefact and say so
   The discard is an explicit act, on the plan like any other. Deleting the mock-up is what keeps the whole arrangement honest: nothing it contained was a commitment, and nobody can come back three months later and ask why it is not being put into production.

What makes a throw-away prototype fail

The throw-away prototype that never gets thrown away

This is the major failure mode. A manager sees an artefact that looks as though it works and asks why it cannot just be shipped. The shortcuts that bought the speed, no architecture, no error handling, no security, no tests, then become the foundations of the real system. Shipping the mock-up does not save the bill: it defers it to the moment when it is heaviest, once the shortcuts are load-bearing and everything sitting on top of them has to come off before they can be corrected. The mock-up skips the production groundwork for one reason only: it is not going into production. Remove the discard and the licence for the shortcuts disappears retroactively, while the shortcuts themselves stay.

The prototype with no question

Built « to show something », to occupy a steering committee, to release a budget. It has no acceptance criterion, so it is never finished, so it is never destroyed, so it is still there on the day somebody asks why it is not being shipped. The failure above almost always starts here.

Creeping fidelity

The mock-up is tidied up for the next audience, and each round of polish takes away a little of the freedom to criticise it. The trap is that polishing feels like progress, and it is the one form of progress this technique has no use for. Fidelity is bought against the question alone.

The learning that dies with the artefact

By construction, nothing survives. If the requirement is not written down before the deletion, the discard destroys the only product the technique ever had. The discipline states its own order: capture first, delete second.

The session that slides from the « what » to the « how »

The first limitation BABOK states: on a complex system the discussion becomes bogged down in the how rather than the what, which costs considerable time, effort and facilitation skill. A mock-up that looks like software accelerates the slide, and the question written down at the start is then still unanswered at the end.

The mock-up taken for the specification

BABOK puts it bluntly: stakeholders focus on the design specifications of the solution rather than on the requirements any solution must address, which then constrains the design; and developers come to believe they must provide a user interface that precisely matches the prototype, even where more elegant technology and interface approaches exist. The artefact was there to ask a question. It ended up answering questions nobody had asked.

AI considerations

The entire economics of throw-away prototyping rests on two terms: what an option costs to produce and what it costs to destroy. Generators attack the first term head on, and this benefit is particular to this technique. Producing several variants in minutes rather than days loosens precisely the constraint that limits the exploration goal: the number of options a team can afford to build and destroy. The more a team can kill, the better the decision that remains. To that add the chores that make a mock-up legible while teaching nobody anything: fabricating the dummy data set, the twelve plausible modules, the credible names, the timetable; writing the throw-away code when the question genuinely requires execution, the code being destined for deletion, which is the one context in which its provenance matters least; and recomposing the session's observations against the question written down at the start.

Judgement does not delegate: naming the question, choosing the acceptance criterion, deciding that the artefact is finished and reading what users actually did rather than what they said. A model will produce a screen for any prompt, including a prompt with no question in it, which makes it an excellent manufacturer of question-free prototypes, at scale.

The most important point lies elsewhere, and it inverts the intuition. AI makes throw-away artefacts so cheap to produce that they come out looking production-ready, which makes the pressure to ship them worse. A pencil sketch announces its own disposability. A generated application compiles, runs, has styling and a plausible database and announces nothing at all. The artefact that now looks the most shippable is precisely the one whose shortcuts are the least visible. And the shortcuts are still there: a login screen that authenticates nobody, a data schema nobody has reviewed, no threat model, no legal basis for the processing, no error path, no tests. None of that is visible from the surface, and the surface is all that the person asking why this cannot be shipped is looking at: they see a screen that opens, a button that responds, a list that fills, and they conclude that the substance is done. The substance is precisely what was never built. The discipline this technique demands, announce the discard, capture the learning, delete the artefact, therefore becomes more necessary as the artefact gets cheaper. Production cost used to be the friction that enforced the discard on its own. It has fallen, and the discard must now be enforced deliberately.

Examples

A Swiss university of applied sciences is rebuilding the screen on which students compose their semester from the elective modules. One question governs everything that follows, and the room does not agree on the answer: does the student choose by module or by timetable slot? The two answers produce two screens, two data models and two ways of handling clashes, and the choice cannot be reversed cheaply once it is built. The prototype exists to settle that.

The session brings together eight students on a real task: « compose your semester, 30 ECTS credits, you work on Wednesdays and Thursdays ». Half the cohort studies while employed, which is the ordinary situation at a Swiss university of applied sciences. The facilitator watches which variant each student reaches for and where each one stalls. Nobody is given a demonstration.

The full-time students work happily in variant A and treat the timetable as a consequence. Those who work two days a week abandon it: it lets them invest in five modules, then tells them in red that three of them fall on a day they are not on campus. In variant B they finish in four minutes and produce no clash at all.

Both variants are deleted the same day. No panel is kept, no markup is reused, the twelve fake modules go with the rest. What survives is one requirement, and it is written down before anything is erased:

The registration screen collects the student's unavailabilities before presenting the catalogue and never offers a module that cannot fit into their timetable. The clash is prevented as the catalogue is displayed.

To that are added the rejected option and the reason it was rejected, which are the second half of the product and the half that gets forgotten. This prototype pursued the exploration goal: the question was « what should be built? », and it was finished the moment the ambiguity disappeared.

Visualizations

The discard figure has a second use. Set beside a real prototyping plan, it works as an instrument of control, and three questions can be read off it.

• Is the bin on the plan, with a date? A prototype whose discard is not planned is a first version, and it will be treated as one.
• Does the surviving arrow have a named destination? Which document, which section, who writes it and when. An arrow pointing at « the specification » in general points at nothing.
• Is the goal written down anywhere, exploration or experiment? If it is not, nobody can say when the artefact will be finished, and an artefact that is never finished ends up being shipped.

The two-axis grid is read down a column, and it is the fastest check to run against the same plan. If nobody on the team can say both what the artefact will become and what someone will do with it, one of the two decisions has not been taken, and it is almost always the first.

Cost

Tooling

One rule governs the choice of tool: take the cheapest medium that can answer the question.

Paper, pencil, whiteboard

BABOK names these as the technique's tools itself. They are the fastest, the cheapest and the most criticisable: nobody is intimidated by a whiteboard. This is where an exploration prototype should start, absent a reason not to.

Wireframing tools

Figma, Penpot, Balsamiq, Excalidraw: several variants, easy to share, easy to throw away. They cross the fidelity line quickly, and the closer the artefact gets to a real interface, the harder it becomes to kill. Staying on the sketched-line side of that boundary is a decision of method.

Slides or a clickable PDF

When the question is about the sequence of screens.

Spreadsheet

When the question is about rules or data rather than a screen, which is explicitly inside this technique's scope: BABOK notes that these prototypes are an inexpensive tool for uncovering or confirming requirements that go beyond an interface, into processes, data and business rules. A spreadsheet is a throw-away prototype of a rule set.

Throw-away code

A script, a single page, a notebook. Reserved for the case where the question cannot be faked and the behaviour has to execute: that is the experiment goal, and it is the shape of the narrow yet deep vertical prototype. This code is deleted without ever being merged. The reflex to keep it grows exactly in proportion to the effort it cost, which is why the discard is declared before the first line is written.

AI-assisted generators

They produce the variants in minutes, and they carry the fidelity trap in its sharpest form, since what they produce looks like finished software without being it.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: the throw-away element (simple tools, an artefact that does not become workable code and is not maintained as a deliverable), the strengths (users criticising an unpolished mock-up freely, the narrow yet deep vertical prototype, requirements that go beyond an interface) and the limitations (bogging down in the « how », the unrealistic expectations a deeply detailed prototype creates, the interface developers believe they must reproduce).
• Christiane Floyd, A Systematic Look at Prototyping, in Approaches to Prototyping, Springer, 1984, pp. 1-18: the three goals of prototyping, exploration, experiment and evolution, of which the first two produce an artefact destined to be destroyed.
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, ch. 11 Plan to Throw One Away, Addison-Wesley, 1975: the pilot plant and the question of whether the system you throw away was planned for or delivered to the customer.
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, ch. 19 The Mythical Man-Month after 20 Years, Addison-Wesley, 1995: the retraction of the 1975 advice and the incremental growth of the product he puts in its place.
• Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5), 1988, pp. 61-72: the risk-driven cycle, the prototype as the instrument for resolving risk and the commitment made only once the risk has been bought down.