Prototyping
Prototyping builds an early model of the final result in order to elicit and validate needs, and that model makes two things visible that no document shows: the missing requirements and the unsubstantiated assumptions. BABOK files prototypes under two distinct elements, so the question « which prototype do I build? » hides two. The approach says what becomes of the artefact: it is thrown away, or it grows into the delivered solution. The method says what someone does with it: it is read, it is operated or a machine executes it. Every prototype carries an answer on each of the two axes, and the two answers are free of each other.
Goal
Prototyping builds an early model of the final result, while a change still costs little. BABOK gives it four jobs: to elicit and validate needs through an iterative process that produces a model of requirements or of the design, to optimise the user experience, to settle competing design options and to be the basis for developing the final solution.
The family reaches well beyond the screen. A prototype is a non-working model, a working representation or a digital depiction. It mocks up a website, it stands in as a partially working construct of the product or it describes processes through a series of diagrams. BABOK also names business-rules and data prototypes, which serve to discover the intended process flow and the rules that govern it, and data prototyping, which serves data cleansing and transformation.
What the whole family returns comes down to two discoveries, and no method has a monopoly on them. A prototype shows what the product looks like and how it acts, and that exposure surfaces what a document leaves in the dark: the missing or improperly specified requirements and the unsubstantiated assumptions. A stakeholder rereads a specification and approves it. The same stakeholder, put in front of the object, says what is missing. That gap is what you are buying.
The underlying reason is set out by a standard. ISO 9241-210 treats the production of design solutions and their evaluation with users as a cycle. That cycle is human-centred design. A prototype is one turn of that cycle. A design that takes no turn at all remains a hypothesis.
HERMES, the Swiss Confederation's project management method, makes prototyping a standard task, 5.4.3.37 Carry out prototyping, whose activities cover the whole family: develop the objectives, the concept and the methodology for the prototype, create it, evaluate it, document the outcomes and conclusions and feed them into further planning, then destroy the prototype or ensure its reusability. Whatever the approach and the method chosen, the task produces two outcomes, 4.4.3.15 Prototype realized and 4.4.1.38 Prototype documentation; the latter records the background, the parameters, the requirements, the concept, the summary of test results, the conclusions and the recommendations. The first names the same approach axis in the method's own terms, "a distinction can be made between disposable prototypes and reusable prototypes", where reusable takes the place of evolutionary.
Which leaves the question the practitioner brings: which prototype do I build? It hides two. The first fixes the fate of the artefact, the second fixes what someone does with it, and both need an answer. What the session or the run returns depends on the second. What the artefact costs and what is left of it depend on the first. The requirement itself is written down and tracked in every case, whatever the fate of the paper or the code that revealed it.
Usage
When to use it
- Requirements nobody states cold: the object shown draws out what a direct question does not get.
- Unsubstantiated assumptions about use: the prototype puts them to the test before they become code.
- Competing design options: building both costs less than arbitrating between two opinions.
- A future state to be made visible: the prototype gives stakeholders a representation they can criticise.
- Technical feasibility in question: a narrow, deep prototype exercises the whole stack on one path.
- Subject hard to state, opinions in conflict: the object moves the debate to what can be seen.
- Feedback wanted early: criticism arrives while a change still costs a pencil stroke.
When not to use it
- Business rules to be specified precisely: the screen shows the effect of the rule and does not state it, prefer business rules analysis.
- Highly complex system or process: the session drifts into the how, establish the what first through interviews.
- Mock-up requested to endorse a decision already taken: the session measures buy-in, prefer the focus group.
Two independent axes
BABOK files prototyping under three lists. The first gives two approaches, the second gives forms of prototype, the third gives four methods. Approaches and methods are two independent axes of choice that govern everything else.
The approach: what the artefact becomes
The approach fixes the fate of the artefact. It is thrown away, and nothing of it survives into the delivered solution: that is throw-away prototyping. Or it grows into the delivered solution: that is evolutionary prototyping. Growing has a precise sense: the requirements are further defined through the stakeholders' use of the artefact, the approach produces a working solution and it usually calls for a specialised prototyping tool or language.
Christiane Floyd set out in 1984 the taxonomy that makes this axis legible, and she counts three goals where BABOK counts two: exploration, experiment and evolution. The first two produce an artefact destined to be destroyed, the third an artefact you keep and adapt. BABOK's list is hers, with the first two goals merged into one, and the merge is justified by the axis: what separates the two approaches is the fate of the artefact, and both reasons for destroying it fall on the same side.
The method: what someone does with it
The method says what the prototype is made of and what someone does with it. A storyboard is read: you follow a sequence of panels and you move forward in time. A paper prototype is operated: a user performs a real task while someone on the team plays the computer. A simulation is executed: a machine runs the model and returns measurements. BABOK names a fourth method, workflow modelling, which depicts a sequence of operations while focusing on the human part. Its home is process modelling.
The forms: a third question
BABOK further enumerates forms of prototype: the proof of principle or proof of concept, the form study prototype, the usability prototype, the visual prototype, the functional prototype. They answer a third question, that of purpose: validate a design, test ergonomics and bulk, test the interaction, test the appearance, test software functionality. The form states the purpose, and it leaves the other two answers entirely open: the fate of the artefact and the use someone makes of it both remain to be decided. That is what places it beside the two axes.
The word functional appears in BABOK on two of these lists: it names the evolutionary approach among the approaches, and among the forms it names the functional prototype, which BABOK also calls a working model. The two senses live on different axes, and one and the same prototype can be functional in the sense of the form and throw-away in the sense of the approach.
The three rules of the crossing
Both questions must be answered, and the two answers are free of each other. A reader who asks "is it throw-away or is it a simulation?" has asked a question that has no answer: those are the answers to two different questions.
A method can close a cell on the approach axis, and the reverse never happens. Paper does not ship, so a storyboard and a paper prototype are throw-away, always: the method closes the evolutionary cell by itself. A simulation occupies both cells. A throw-away prototype, for its part, often does without all three methods: it is code, a wireframe, a whiteboard.
Neither the medium nor the fidelity settles anything. Storyboarding and paper prototyping are both pencil on paper, both low fidelity, both throw-away. Only the method axis separates them: one is read, the other is operated.
Choosing the approach and the method
The routing comes down to two questions.
What becomes of the artefact?
This question is settled before the first stroke, and it is not replayed cheaply. In software the default answer is throw-away prototyping. Evolutionary prototyping becomes the honest answer when the artefact does not execute, persists no data and exposes no attack surface, that is, when it is a design rather than a running system.
What does someone do with the artefact?
This question is settled next, and it stays free of the first. The verb decides, and BABOK names four of them.
The two answers combine freely, with the single reserve that paper imposes: choosing to read or to operate is already having answered throw-away to the first question.
| Axis | The question | The answer | It leads to |
|---|---|---|---|
| Approach | What becomes of the artefact? | It is destroyed. Nothing of it survives into the delivered solution, and that zero residual value is the design goal. | Throw-away Prototyping |
| It grows into the delivered solution. | Evolutionary Prototyping | ||
| Method | What does someone do with the artefact? | It is read: a sequence of panels that moves forward in time. | Storyboarding |
| It is operated: a user performs a real task while a person plays the computer. | Paper Prototyping | ||
| A machine executes it and returns measurements. | Simulation | ||
| The workflow is modelled: a sequence of operations, focused on the human part. | Process modelling, which is its home |
AI considerations
A language model produces a presentable artefact in minutes: screens from a requirement, a sequence of panels from a scenario, a first model from a process description. The service is real, and it bears on the making.
The consequence lands on the first axis. The strongest argument for evolutionary prototyping has always been the cost of discarding: you refuse to throw away because rebuilding is expensive. When rebuilding costs an hour, that premise weakens. The right question to put to the tool concerns the cost of the next prototype, the one the machine has changed.
The danger is symmetric, and it is already written into the limitations BABOK states. A generated artefact is finished, aligned, clean. A prototype that is too polished invites politeness rather than criticism, then it sets expectations of delivery date, performance and reliability that nothing supports. It therefore aggravates the family's principal defect, the one BABOK describes precisely: stakeholders fix on the design specifications of the solution rather than on the requirements any solution must address, and developers believe they are bound to reproduce the mock-up stroke for stroke. Roughness was a sought-after property, and a machine erases it for free.
The two questions stay out of the tooling's reach. The fate of the artefact is a decision of engineering and economics: it commits a quality floor, a debt and a lifetime, and it is taken with the people who will pay for it. What someone does with the artefact is a decision about who is in the room: a real user in front of the object or a machine in front of a model. A synthetic user returns the model's prior, where the whole family exists to obtain an observed behaviour.
The data, finally. A prototype filled with real data is a processing of real data outside its own system, and the revised Federal Act on Data Protection (revFADP) applies to the draft as it does to the product. A prototype's test data is built synthetic and plausible, with names, postcodes, dates and CHF amounts that read like the real ones.
Cost
The cost of prototyping is fixed by the answers to the two questions, and it spreads over an order of magnitude.
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low to high | This item depends on the answer on the approach axis alone. To which BABOK adds a cost of entry: the underlying technology may need to be understood or assumed before prototyping can begin at all. |
| Execution | Low to high | The answer on the method axis commands this item: what is read and what is operated fits in one session, what is executed calls for a model, input data, a validation and replications. |
| Documentation | Low to medium | The established requirement and the decision taken are written down in every case. The evolutionary artefact, for its part, enters maintenance and carries the cost of a product in operation. |
Tooling
The tooling follows the method. Paper, a pencil, index cards and a whiteboard are enough for what is read and what is operated, and that poverty is an advantage: the technique then presupposes no licence, no environment and no design system. What is executed calls for an engine, a model, input data and the time to validate the model, and the cost of entry changes in kind.
The approach, for its part, commands the tool. A throw-away answer leaves the choice open, down to a pad of sticky notes. An interactive design tool holds a particular position: it produces an artefact that does not execute and persists nothing, and that is what makes the evolutionary answer honest in the one case where it is, that of design.
What the prototype establishes is filed somewhere other than in the prototype. The requirement is written down, and the corrections that become change requests go to item tracking. The artefact, for its part, follows the fate the first question set for it.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: the purpose of prototyping, the two approaches, the forms of prototype, the four methods, as well as the strengths and limitations of the family, including the risk that the design takes the place of the requirement.
- 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, the merging of the first two of which yields the approach axis.
- ISO 9241-210:2019, Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems: the production of design solutions and their evaluation with users as an iterative cycle, which makes a prototype one turn of that cycle.
- Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, task 5.4.3.37 Carry out prototyping, outcomes 4.4.3.15 Prototype realized and 4.4.1.38 Prototype documentation: prototyping as a risk-minimising measure, the five activities of the task, the two kinds of prototype (disposable, reusable) and the content of the documentation, including the summary of test results.