Two Words reports that Finkraft’s build followed a high-fidelity clickable prototype that served as the developer specification. This first-party account does not prove that a rewrite was prevented. For a leader approving development, the useful distinction is between a shared reference for what to build and evidence that engineering can implement it.
Separate the build approval questions
Treat agreement on the intended workflow and confidence in its implementation as separate approval questions. Ask design and product to distinguish tested workflow decisions from assumptions. Ask engineering which decisions depend on unverified technical constraints. Use those dependencies to set the scope of the build commitment.
Finkraft: the prototype became the specification
Served as the developer specification.
Followed that prototype rather than a separate specification.
Source: Two Words’ first-party delivery account.
Finkraft’s reported specification-to-build handoff.For your own delivery, ask engineering to inspect the prototype as a working specification. Identify who acts, what information they use, which state follows and what happens when the expected path fails. Separate decisions visible in the flow from rules that need accompanying documentation. Assign disputed rules to an accountable owner.
Test the workflow, not the presentation
GOV.UK’s service-design guidance recommends exploring, sharing and testing designs before committing to build. Its moderated usability-testing guidance describes observing participants attempting specific tasks to identify issues such as unclear language or layout. These recommendations give a clickable prototype before development a concrete purpose: investigating how people understand and navigate the proposed workflow.
We recommend giving participants meaningful tasks without walking them through the preferred route. Examine understanding as well as completion: whether they recognise the current state, understand the consequence of an action and know who takes responsibility next. Include relevant exception paths.
Record where the facilitator has to explain the interface. Decide whether the difficulty calls for an interface change, clearer content or a business decision about the workflow itself. Retest the affected task after revision. This is our recommended method, not a description of testing performed for Finkraft.
Review technical feasibility separately
Do not accept successful prototype tasks as evidence that integrations, security, performance or operations are ready. Run a feasibility review alongside workflow exploration, with named engineering owners. Bring technical constraints back into the design while its decisions are still open.
Can participants understand the current state and choose the next action? Observe tasks.
Can systems supply authoritative data and enforce permissions? Review integration contracts and access controls.
Can users understand the recovery path, and can the system execute it? Check each separately.
What operating conditions must the service support, and who handles failures? Define tests and ownership.
Recommended review questions. A finding in one review does not settle the other.
Match each uncertainty to the review that can address it.Make the engineering review specific enough to act on. Identify who owns the data and resolves missing or conflicting records. Specify where permissions are enforced and what audit records are required. Define acceptable response times and recovery behaviour. Name the operational owner for unresolved work and the engineering owner for changes to shared behaviour.
For each unknown, choose a check proportionate to the risk: an integration-contract review, focused technical experiment or operational walkthrough. Set acceptance criteria first. Record the finding and its limits rather than closing the question with a label such as “integration reviewed”.
Make the handoff a shared decision record
The 2023 Relay research publication identifies a handoff risk: design decisions can be lost when developers struggle to interpret and implement the designer’s intent. We recommend pairing the clickable flow with a concise shared decision record, rather than asking engineering to infer every rule from the screens.
- Behaviour: starting state, permitted actor, action, governing rule and resulting state.
- Interface detail: content, relevant edge cases and recovery paths.
- Decision basis: what testing showed, what the team agreed and what remains an assumption.
- Open issues: unresolved technical decisions, their owners and the evidence needed to close them.
Review the record with design, engineering and the operational owner. When a technical constraint changes a workflow decision, update both the record and the affected flow. Keep implementation choices under engineering ownership, including maintainability. Use the prototype to make intent inspectable without treating it as a specification of the entire system.
Commit when the remaining uncertainty is visible
Base the build decision on evidence and ownership. Require workflow testing proportionate to the consequences of error, named owners and checks for technical unknowns, and explicit acceptance of remaining risks. If an unresolved dependency could change the workflow or architecture, narrow the build commitment until it has been investigated.
Before committing, can your team name what the prototype has tested and what engineering still needs to prove?
