Write a design rationale that explains the choices in your submitted prototype
Write a design rationale from a documented prototype, using an original fictional version record and clear distinctions between intention and evaluation.
About 5 min read · Allow extra time for the practical checks
Explain the choices a reader can actually see in your prototype, connect them to the project’s stated requirements, and identify the evidence behind your explanation. A design rationale should make the submitted version understandable. A list of attractive features does not explain why you chose them or what you gave up.
Follow the assessment brief and the kind of design record your project requires. This guide concerns writing about a documented student prototype. It does not establish engineering feasibility, safety, accessibility performance, cost or successful use by an audience.
Start with the version you are explaining
Identify the submitted artefact and the decision you need to explain. Keep the draft, screenshot, drawing or other record that shows the relevant feature. If your project changed during development, distinguish the earlier version from the submitted one rather than writing as though the final choice existed from the start.
Separate a requirement in the brief from your preference and from feedback you received. A requirement can explain why an option was unacceptable. A preference needs an argument about its relevance. Feedback may suggest a change, but the fact that someone requested it does not establish that the change worked.
MIT’s design and feasibility report guidance connects discussion of a design choice with the criteria used to evaluate it. Apply that general relationship to your documented project. The relevant criteria and evidence come from your own brief and records, not from the guidance’s historical technical example.
Work through an original fictional version record
Everything in this example is invented teaching material. The exhibition, cards, brief and development records describe no real project, participant feedback or usability test.
Imagine a capstone prototype consisting of printed exhibition entry cards. The fictional brief requires an entry number beside each title and an image credit on the same face as the image. It does not specify where on that face the credit must sit.
The writer’s fictional record contains:
- An early card with the image on the front and its credit on the back. That version fails the stated same-face requirement.
- A revised card with the image and credit on the front. The credit sits directly below the image, leaving a shorter area for the interpretive caption.
- A considered alternative with the credit in a separate strip on the same front face. Both revised layouts meet the stated placement requirement; the record contains no reader test comparing them.
- A design note selecting the directly adjacent credit to keep the image and its attribution visibly together. The note also records the reduced caption area as a trade-off.
This record supports explaining the move from a non-compliant early version to a compliant revision, then explaining the choice between two compliant layouts. It does not establish that readers noticed the credit more often or understood the exhibition better.
| Part of the fictional rationale | Evidence available | Claim that would overreach |
|---|---|---|
| Why move the credit? | The stated brief and early card put image and credit on different faces | Every exhibition requires this layout |
| Why place it directly below the image? | The selected layout and design note show an intended visual association | This position improves actual reader comprehension |
| What was the alternative? | A same-face credit strip was considered in the record | The alternative was unusable |
| What was sacrificed? | The revised layout leaves a shorter caption area | Shorter captions necessarily work better |
| What remains untested? | No comparative reader test is supplied | The prototype has been validated for its audience |
Do not make the preferred layout win by inventing a defect in the alternative. The credit strip also meets the fictional brief. The rationale needs to explain the narrower judgement about placement while retaining the fact that its effects on readers have not been assessed.
Link the feature, reason and trade-off in prose
A possible explanation, limited to the fictional record, is:
The submitted card places the image credit directly below the image. This meets the brief’s same-face requirement and follows the design note’s intention to keep the image and attribution visibly together. A separate credit strip on the front was also considered. The selected arrangement leaves less caption area, and the project has not tested whether readers find either compliant layout easier to use.
Each sentence has a different job: identify the actual feature, explain the requirement and intended reason, acknowledge the alternative, and state the cost and evidence limit. Your rationale need not follow this wording or order. It does need to make these relationships inspectable where they matter to the assessed design.
Avoid retrospective certainty. If you only recognised a reason after making the first version, say how the later review changed your explanation or design. Do not invent an early planning process merely to make the project appear more orderly.
Keep design intention separate from evaluation
A feature can be intended to help readers without evidence that it helped them. Documentary inspection may show that the prototype meets a stated requirement. A usability claim needs suitable evidence about use, and a broader claim needs evidence that fits its scope.
Describe the checks you actually completed and what they establish. Do not treat a supervisor’s approval of the project scope as validation of every design choice. Do not attach invented participant comments, cost estimates or test results to fill a missing evaluation section.
Use the capstone scope guide when deciding what the project will deliver. Use the appendix guide to place supporting version records without hiding the reasoning the report itself needs. Recommending a future response to report findings is a separate task from explaining the choices embodied in a submitted artefact.
Before finalising, check the rationale against the version you will actually submit. Remove claims about features that disappeared, explain relevant changes and keep unresolved evaluation questions visible. The reader should be able to locate both the design choice and the basis for the judgement you make about it.
