The challenges explored so far lead to a central question: How do we navigate organisational complexity and deliver value every day - especially when the full impact of our actions is not yet visible?
After analysing 274 design methods across start-ups, agencies, SMEs, and global organisations, several patterns emerged: the mindset designers bring into the work, the techniques used before exploration, the quality of early documentation, and how effectively knowledge is shared across the organisation. These patterns shaped the structure of the Design at Scale™ framework.
This understanding led to a formalisation of the proposition shaping stage. This is where teams align on what is being built, why it matters, and how it will create measurable value. Once the business confirms the proposition is shaped - usually via a brief, RFP, or project identification document - the work transitions into design shaping. This marks the first formal milestone: agreement on feasibility, timelines, resources, and expected outcomes.
Design shaping then explores and tests all known unknowns. It reduces risk by validating behaviour, prototyping early, pressure-testing assumptions, and translating guidelines into a functional design system. Both stages rely on a Kanban approach; the work is discovery-led and therefore less time-dependent than later phases.
The second part of the framework covers design delivery, product delivery, show and tell, and integration.
Design delivery expands earlier explorations into detailed scenarios, specifications, and user stories. Designers move into an engineering mindset - focusing on clarity, accuracy, and technical feasibility to enable smooth partnership with engineering. Tasks are broken into releases, epics, and stories that align with Scrum delivery.
Product delivery then runs in parallel, with engineering progressing the build while design supports refinement. Some organisations still avoid parallel delivery and finalise designs upfront, particularly when development is outsourced. These adoption challenges are covered in Section 3.0.
A recommended but optional step is Show and Tell, where teams share work in progress, align expectations, and ensure organisational visibility. It creates a lightweight mechanism for leadership to track progress without being embedded in day-to-day delivery.
Finally, integration brings all prior deployments together into a cohesive release. While development and QA test iteratively throughout sprints, integration ensures the full proposition is aligned, stable, and ready for customers. Here, design collaborates closely with engineering and QA to close final gaps before launch.
