A prototype technical spike brief turns an uncertain product promise into a bounded engineering question. It states what the team needs to learn, the smallest investigation that could answer it, the evidence to retain and the decision that follows. It is useful when a clickable prototype looks convincing but its underlying behavior has not been established.
Start with the user-visible states in your interactive Mockitt prototype. Then separate the behavior the screens explain from the behavior engineering must investigate. A screen saying “Reserved” can communicate a state; it cannot prove that two simultaneous requests will not reserve the same item.
Use a spike for a question that blocks a decision
A technical spike is a short investigation, not an open-ended instruction to “research the architecture.” Atlassian's account of its engineering practice describes spikes as a way to learn about obstacles and scope before building a shippable product. The useful output is knowledge that changes a decision.
Suitable questions include whether an integration returns the state needed by the design, whether a chosen approach can handle a conflicting update, or which constraints an upload service imposes. “Make the whole app feasible” is too broad. “Determine how the reservation service responds when two customers request the final item” is narrow enough to investigate.
If the team does not yet know which uncertainty matters, use a prototype risk matrix to choose it first. The spike brief starts after that choice. It should not become a second risk register.
The case: two renters, one available item
Imagine a rental service with one camera remaining for Saturday. The interface shows availability and lets a renter submit a reservation. The design team has already represented an available state and a confirmation screen. The unanswered question is what happens when another renter submits a request at nearly the same time.
The product decision is whether the interface may promise an immediate reservation or must show a pending request until the service confirms it. That affects the text, loading state, recovery path and support expectations. It also affects implementation scope.
Write the question without prescribing the answer: Can the proposed reservation approach give one authoritative outcome for competing requests, and what state can the client reliably display? An engineer can then choose an appropriate investigation. A product brief should not demand a particular database mechanism merely because a diagram looks tidy.
Write a one-page brief with explicit boundaries
| Field | Example brief |
|---|---|
| Decision | Choose immediate confirmation or a pending-request experience. |
| Question | How does the proposed service resolve competing requests for the last available camera? |
| Scope | One item, one date range, controlled synthetic requests and a nonproduction environment. |
| Timebox | Agree a bounded investigation with the engineers doing the work; review at its end even if unresolved. |
| Evidence | Request and response sequence, resulting reservation state, relevant logs and unresolved assumptions. |
| Exit decision | Proceed with a supported design, change the promise, or define one narrower follow-up investigation. |
| Out of scope | Production rollout, payments, full load testing and a general guarantee of reliability. |
A timebox limits investment; it is not a promise that the answer will be positive. Choose its length after discussing the environment and access required. If most of the time would be spent obtaining test credentials, solve that dependency before pretending the technical investigation has started.
Agree what counts as useful evidence. A successful click-through is not sufficient for a concurrency question. Conversely, the spike need not include a polished frontend when a small controlled service-level experiment can answer the question. Match the evidence to the uncertainty.
Give engineering a visible-state contract
The prototype should show the possible outcomes that matter to the renter. For this example, represent four states: available, reserving, reserved and no longer available. Include a route back to alternative dates or equipment so the unsuccessful request does not end at a dead screen.
These screens form a proposed contract between the experience and the eventual implementation. They are design examples, not evidence that the reservation service already behaves this way. Discuss the meaning of each state before coding a prototype around an inaccurate promise.
- Available: the item was available when checked. Decide how the interface communicates that availability may change.
- Reserving: the request is being processed. Do not announce success before receiving an authoritative result.
- Reserved: the service has confirmed the reservation and the interface can show its reference.
- No longer available: the request did not obtain the item; explain what the renter can do next.
Add a separate unresolved state if the response is lost or times out. A client-side timeout does not prove that the server rejected the reservation. The brief should ask how the application will discover the actual outcome before inviting a potentially duplicate attempt.
Design an investigation that can disprove the assumption
Ask the engineer to specify the setup, attempted sequence and observable result. A possible investigation uses two synthetic clients requesting the same item, then checks the authoritative reservation state. The precise implementation belongs to the engineering team and the architecture under review.
Include at least one sequence that stresses the proposed promise. Competing requests address the last-item question. A repeated request addresses accidental retries. A lost response addresses the difference between “the interface did not receive confirmation” and “nothing happened.” These are distinct observations and should not be collapsed into one green check.
Record what the environment leaves untested. A controlled test against a sandbox may establish a response format without establishing production performance. A small sample of requests cannot prove that a race condition is impossible. If the conclusion depends on a service guarantee, retain the relevant documentation and have the team verify that it applies to the chosen configuration.
Keep the investigation isolated from customer data and live transactions. Use synthetic item identifiers and a test setup that the team controls. This makes it easier to repeat the sequence and distinguish the behavior of the implementation from unrelated production activity.
End with a decision, including an inconclusive one
A good readout separates the question, observation and consequence. Avoid “Spike complete” as the only result. For the rental case, a useful record could take one of three forms:
- Supported for the tested scope: the observed responses and authoritative state support the proposed confirmation flow. List the tested conditions and remaining work before production.
- Design change needed: the integration initially returns a request acknowledgement, not a completed reservation. Replace immediate success with a pending state and define how status will be obtained.
- Unresolved: the environment cannot exercise competing requests or the relevant behavior is undocumented. Explain the missing evidence and the next bounded action.
Do not present these illustrative outcomes as test results from Mockitt or a real rental system. In your own brief, include the actual evidence links, the person responsible for interpreting them and the decision date.
When the behavior is agreed, convert it into prototype acceptance criteria and delivery tasks. For example: “An uncertain reservation outcome remains pending until its state is resolved; a network timeout alone does not display rejection.” The implementation and its test plan still need engineering review.
Avoid turning exploration into unplanned production work
A small demonstration often attracts requests for a proper account system, polished screens or a production release. Check each request against the original question. If it does not help answer that question, move it into the follow-on work rather than extending the spike silently.
Similarly, do not assume experimental code should ship because it already exists. Capture what can be reused, what was deliberately simplified and what needs to be rebuilt. The purpose of a throwaway prototype is to make learning affordable; keeping every line can make that learning unexpectedly expensive.
Close the loop with the design file. Update the confirmed and uncertain states, remove promises the investigation did not support, and retain the relevant decision next to the flow. The next reviewer should be able to see both what the renter experiences and why the team believes that experience can be delivered.