Welcome to the Design at Scale Method articles. Today we’ll be looking at Methods combined that help Design and Scale to deliver value in complex propositions and thrive in environments of constant change. 

While both sides of this process – design[001↘︎] and development[002↘︎] will continuously evolve in their way, the ultimate value between them lies behind the combination of strengthening daily handovers while monitoring the big picture (eyes on the release). A smooth and very effective flow of routines creates stability. 


Before we dive deep into a simplified model that can solve complex design propositions in product development, please allow me to clarify the following:

“This model is not for one product or feature; this model works for a team of teams that collaborate to deliver the design proposition at scale within the Agile Development Cycle (ideally dual-track agile). It is built on a well-known “stage and gate product development method” – yet opens up to more flexible and responsive adjustments using – Design Sprint, Lean UX, Integrated research, and BDD, to name a few.”

Figure02: Proposition Shaping

1.0 Proposition Shaping 

Manly business-oriented discipline [003↘︎] supported by the design and development to support (better say to shape) the proposition. This stage aims to set the OKRs[004↘︎], ROIs[005↘︎] and DoRs[006↘︎] + DoDs[007↘︎] for each function, allowing each contributor to be flexible yet accountable for delivering their part of the experience. As the process of this exercise is more linear, we tend to use the Kanban board and prioritise the sequence. After a team reviews the DoD for the Proposition Shaped – “good enough”[008↘︎], the team will move to Design Shaping.  

Figure03: Design Shaping

2.0 Design Shaping 

To test the proposition hypotheses for both design and development functions, we work side by side to shape the constraints around the design definition (first set of outputs), helping both parties move from the assumption to more tangible outcomes that can be measured. In design, we’ll have the schemas, prototypes and early concepts that communicate MTP – massive transformative purpose[009↘︎] and its integration for Alpha or Beta Release[010↘︎]. Where in development, we set the environment and start testing the data and flexibility of integrated elements.
The outcome of this stage is the prototype that most of the team agrees on, where DoR (a good enough) represents the attempted release of products or services.

Figure04: Design Delivery

3.0 Design Delivery 

This stage predominantly focuses on robust design delivery. Based on previous learning, we create design systems, copy, translation, robust branding exercises etc. At the same time, development prepares daily drops and other increments for the design, strengthening the ongoing delivery and minimising the refactoring, including asset delivery, handover and so on.  

Figure05: Product Delivery

4.0 Product Delivery

Meanwhile, the design function was busy visualising the proposition; the development team was continuously working on the prototype. At this stage, the development becomes the leading party and design moves in a supportive function. It's important to mention that these two stages are often combined in smaller organisations that require fewer approvals or supervision from the central team. This simple split of roles creates the opportunity for designers to be in the making/decision seat regarding the experience and, on the other hand, developers in the making/decision seat regarding technology/development – aiming for smooth and frictionless delivery. 

Show and tell

Important for centralised teams or big corporations. One of the best practices is to present the feature, product or service increments to a broader coalition to receive vital feedback. Publicising the feature means the CX, UI, and Code can be available to other departments in the business.  

Running “show-and-tell sessions” to galvanise the team and tribes around a specific function. It also opens up opportunities to widen the impact of the feature in the overall business. (Show and tell is after each sprint)  

Figure06: Integration


This stage is seldomly overlooked. However, it significantly impacts customer adoption and has a consequential economic impact on product definition and further development. Unlike the other creates constant feedback on the product and represents the customer voice in following iterations. 

Tailoring this stage with solid KPIs and good QA can bring invaluable business insights that can prevent spending in the areas that brings less revenue and focus on those which generate greater impact on the business – whether we talk about customer acquisition, better or smoother operation of faster delivery.      

Figure06: Whole composition of Design at Scale Method™

Final note

Please take the above text as a high-level guide for the method. We’ll embark on the journey explaining the challenges and opportunities behind these stages that leads to smooth and transparent delivery in the following series of articles.

Let us know at @designatscaletm whether you found this helpful article.
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm