Design shaping validates and de-risks the proposition. It tests hypotheses, builds prototypes, explores mental models, and evaluates behaviours in realistic contexts. Every idea is treated as a hypothesis requiring evidence.
This phase begins with another workshop. At this point, senior leadership steps out and mid-to-executive management - department heads, programme managers, delivery leads - steps in. Their role is to break down the PID into high-level requirements and define acceptance criteria for both business and customer needs.
The team gathers insights, design guidelines, and relevant business cases, then stress-tests the proposition. Knowledge gaps are surfaced and resolved quickly so the team can move from outputs to outcomes. All actions are recorded in Jira, linked to epics and user stories.
Not every step requires documentation, but regulated industries (finance, insurance, healthcare) require formal traceability. Key decisions - those with material impact on outcomes - must be recorded to satisfy compliance and risk controls.
The outcome of the first workshop is a refined business case, agreed high-level requirements, and structured epics.
Tools and techniques used in this phase include:
— Design shaping workshop
— Service or product journey definition
— Key design questions
— Personas
— Target audience definition
— Validation of landscape analysis
— Prototypes
— System-level agreements
— Architecture mapping
— Feature lists
— Backlog creation and prioritisation
— Documentation in Confluence linked to Jira
—Test strategy
— Success criteria
— KPIs and OKRs
These steps form the service backlog proposition - a functional map of what must be built. It becomes the foundation for prioritisation and release planning. This backlog is evidence-based, shaped by validated learning rather than assumptions.
A shape review follows next. This is the organisation’s first formal handshake on the proposition. It reviews the backlog, design stories, dependencies, required integrations, and differences in business processes across teams.
Architectural design dependencies - content model, layout, content strategy, and hierarchy - receive particular focus to ensure consistency and feasibility.
The team then establishes test criteria and prototypes that demonstrate the required behaviour and mental model. This continues until we reach definition readiness: high-level functional and non-functional requirements are clear, definitions of ready and done are agreed, and all disciplines align around a shared product manifesto.
At this point, the shape is defined. The work is ready to move into design delivery.
