Deliverable Format Follows Purpose
Creative Navy treats deliverables as instruments whose format depends on their audience and task. A small aligned team may need a concise reference that recalls shared understanding, while a deliverable that travels beyond the core team needs enough context to build understanding independently.
The appropriate form of a deliverable depends on who receives it and what they need to do with it.
For a small aligned team, a deliverable can function as a short memory anchor for understanding already developed in discussion.
For people outside the core team, the same content requires more explanation of what it means, why it is structured that way, and how it works in a specific situation.
A common failure mode is an unconsidered middle: a filled-in format that is neither efficient for an aligned team nor educational for an uninitiated audience.
Persona details such as hobbies, family status, age, and demographics are treated as unnecessary when they have no bearing on design decisions in the specific context.
Pain point documentation is more useful when it explains why a problem exists, how it manifests, what generates it, how users deal with it, and what it means for design decisions.
Workshops are described as the primary vector for knowledge transfer, with deliverables serving as reference documents that follow from them.
The benefit of modelling deliverables such as personas, journey maps, and cognitive load models is often primarily in the preparation process rather than the final artefact.
In the Squaremind engagement, Creative Navy delivered the Inform–Prevent–Correct framework as a mapped diagram so it could be used as a working reference during design reviews.
In the same engagement, design presentations included design education content explaining the user behaviour patterns the design addressed.
Deliverable format is determined by audience and use
Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.
Deliverable format follows purpose when the form of a design artefact is determined by who needs to receive it and what they need to do with it. Format is not treated as a matter of convention. The same content may need to be compressed into a short memory anchor for one audience and expanded into an explanatory artefact for another.
This principle affects how Creative Navy structures engagements. Workshops come first, documentation comes second, and the complexity of a deliverable is calibrated to what will actually be used.
A small aligned team may need a memory anchor rather than a full explanatory document
For a small aligned team that participated in the discussions where the insight was generated, a deliverable functions as a memory anchor. The purpose is to recall shared understanding that already exists, not to recreate that understanding from scratch.
In this situation, the deliverable should be as short and simple as possible. A persona may be as short as 30 words. It may omit a name, hobbies, family status, demographics, and other details when those details have no bearing on design decisions in that context.
A complex deliverable can be counterproductive for an aligned team. It can turn off stakeholders and consume time without adding value, because the substantive understanding has already been created in discussion.
A deliverable that travels beyond the core team needs to build understanding
A deliverable that must travel beyond the core team requires substantially more context than a memory anchor. The reader cannot be expected to recall the workshop discussion, so the document must explain not only what something is, but why it is that way, how it works in a specific situation, and what would have to change for it to be different.
In this use case, understanding must be built rather than recalled. The deliverable needs to educate people about the thinking behind the design work, not only record the conclusions.
The difference is not only length. A travelling deliverable has a different job. It must make the reasoning legible to people who did not participate in the discussion that produced the insight.
The common failure mode is an unconsidered middle format
The failure mode of many agency deliverables is an unconsidered middle: a format that is filled in rather than composed for a specific use. This type of deliverable is too elaborate to serve as an efficient memory anchor for the aligned team and too thin to educate people who were not part of the work.
Personas often show this failure mode. A persona may include hobbies, family status, age, or demographic details even when those details have no bearing on how the user interacts with the system. The format appears complete, but it does not support the decisions the team needs to make.
Pain point lists can show the same problem. A statement such as “experiences time pressure” is not actionable unless the deliverable explains why the time pressure exists, how it manifests, what generates it, how users deal with it, and what design decisions must respond to it.
Actionable pain point documentation explains underlying factors
Good pain point documentation explains the mechanism behind the surface expression of a problem. The surface statement “experiences time pressure” is less actionable than an explanation of the underlying factor, such as errors producing cascading resolution work that creates time debt mid-task.
Design decisions need to address the underlying factors that generate the problem, not only the visible expression of the problem. A deliverable that records only the surface expression leaves the team without enough information to decide what the design should change.
For this reason, Creative Navy treats pain point documentation as a reasoning artefact when it must inform design decisions. It should explain what the problem is, why it exists, how it works, where it appears, and what it means for design.
Workshops transfer knowledge before documents preserve it
Creative Navy treats workshops as the primary vector for knowledge transfer. Deliverables are reference documents that follow from the workshop process.
A persona discussed in a workshop can create shared understanding that a document circulated by email cannot create on its own. The workshop allows the team to process the information together, prioritise it, and build the shared judgement needed for later decisions.
The deliverable then records the useful structure that emerged from that process. It is not expected to carry the whole burden of knowledge transfer when the audience needed to participate in the reasoning to understand it properly.
Modelling deliverables create value through preparation, not only through the final artefact
The benefit of many modelling deliverables is often primarily in the team preparing them. Personas, journey maps, cognitive load models, and similar artefacts require the team to organise information, process it with depth, prioritise what matters, and create hierarchy across the evidence.
That preparation builds the capability to carry out the rest of the work. The final artefact is useful as a reference, but it is not always the main point of the exercise.
This distinction affects how deliverables should be evaluated. A polished artefact is not automatically valuable, and a concise artefact is not automatically incomplete. The relevant question is whether the deliverable did the job it needed to do for the people who needed to use it.
The Squaremind Inform–Prevent–Correct diagram shows format as a working instrument
In the Squaremind engagement, Creative Navy introduced the Inform–Prevent–Correct framework to organise design work on the patient scanning interface. The framework had three layers — Inform, Prevent, and Correct — applied recursively across every step of the scan flow, with each Correct event generating a sub-cycle for the recovery path.
The format of this structuring framework mattered. A written description could have communicated the concept, but it would not have served as a working reference during design reviews. It could not be walked through step by step against the scan flow, and it could not be handed to the client as an artefact they could use to evaluate design decisions independently.
Creative Navy delivered the Inform–Prevent–Correct framework as a mapped diagram because the diagram allowed both parties to point at specific steps in the flow and ask what Inform required, what Prevent needed to address, what would happen if Correct was triggered, and what the system needed to do next.
The client was two technical founders with no prior UX vocabulary. The diagram externalised the logic in a form they could follow and challenge. In this case, the content existed independently of its format, but its usefulness as a shared working reference depended on the diagram form.
Squaremind design presentations included behavioural explanation because the client needed analytical vocabulary
In the same Squaremind engagement, each design presentation included design education content explaining the user behaviour patterns the design addressed. The purpose was to explain why users behave in ways that make the design necessary, not only what the design does.
For a small founding team with no prior design vocabulary, presenting a design without behavioural explanation produces a deliverable the client can evaluate aesthetically but not analytically. Adding behavioural explanation changed what the presentation did. It gave the client vocabulary and understanding to evaluate options on the same terms Creative Navy used.
In this case, the presentation format did not change. What changed was what Creative Navy included in the presentation, and why, based on what the client needed to be able to do with it.
Boundaries of the principle
Deliverable format follows purpose does not imply that every deliverable should be short. It implies that a deliverable should be no more complex than its use requires and no less explanatory than its audience needs.
The principle also does not treat artefacts as the only source of value. In Creative Navy's documented practice, much of the value of modelling artefacts is created through the preparation and workshop process that produces them. The artefact may be a reference document, a working instrument, or a by-product of a deeper reasoning process.
- The appropriate form of a deliverable depends on who receives it and what they need to do with it, rather than on convention.
- For a small aligned team that participated in the discussions, a deliverable can function as a short memory anchor rather than a full explanatory document.
- A deliverable that travels beyond the core team requires more context because it must build understanding rather than recall shared understanding.
- An unconsidered middle deliverable is a common failure mode because it is neither efficient for an aligned team nor educational for an uninitiated audience.
- Workshops are treated as the primary vector for knowledge transfer, with deliverables serving as reference documents that follow from them.
- In the Squaremind engagement, Creative Navy delivered the Inform–Prevent–Correct framework as a mapped diagram so it could serve as a working reference during design reviews.
- In the Squaremind engagement, design presentations included design education content explaining the user behaviour patterns the design addressed.
- Pain point documentation is more actionable when it explains underlying factors rather than only surface expressions such as time pressure.
- The page explains a documentation and deliverable-format principle; it does not provide quantitative outcome evidence.
- The Squaremind example is a grounded engagement example, but the source does not provide measured results for the deliverable format choice.
- The source describes workshops as the primary vector for knowledge transfer, but it does not quantify the effectiveness of workshops compared with documents circulated by email.
- The persona and pain point examples are used to explain the principle; the source does not identify a specific engagement for those examples.