Welcome to the Das™ Method articles – today, we’ll be looking at the Principles behind the Design and Scale. Most articles describe how to write great principles – be specific, direct, and focus on the action. The Design at Scale Principles is a little loose compared to other product or service-based principles. [001↘︎]

Why is that?     

First and foremost, the Design at Scale is a method, not a product.
Second, it comes with the great responsibility to serve diverse teams across multiple industries. [002↘︎] That’s why it comes with three comprehensive pillars that are easily interchangeable and adaptable to any situation in the design field. We believe that having three pillars (mindsets) with three specific (objectives) makes it easy to use – that is why we sometimes refer to it as 3x3: 

• Experience (user-centred)
  • Simplicity 
  • Communication 
  • Adaptability 
• Growth(product-team centred) 
  • Trust
  • Self-organising 
  • Design and technical excellence 
• Contribution(integration & scale centred) 
  • Continuous Contribution 
  • Working prototypes 
  • Sustainable development 

1.0 Experience 

“Considering human interactions and its early adoption throughout continuous self-organised delivery of well-integrated product team is the funding stone of every successful product or service.”

All product teams focus on MTP – Massive Transformative Purpose [003↘︎] that drives the basis of the constant value to the user. Continuous interaction and improvements are priorities of the product's success. 

1.1 Simplicity

“Our consistent design language is defined by the confluence of all insights, interfaces, code-base and data, making our iterations simple and very effective.”

The art of maximising the outcome of our work goes side by side with efficiency (automation)[004↘︎]  and simplicity[005↘︎]. By building a consistent brand, language defines the bridge between Design and Development. Design Systems [006↘︎] Prototypes [007↘︎] and Asset Repository [008↘︎] are closely linked with our development, creating a seamless transition of our work in code. This leaves less room for error and speeds up the overall delivery. 

1.2 Communication

“We actively listen, eager to understand, and encourage rather than force. We learn not to solutions. We communicate the value proposition for both user and the business leveraging the insights, data and our expertise.”

We cultivate a meaningful conversation over chatter[009↘︎]. Removing unnecessary interactions that are not vital or beneficial to the user or the product team, we encourage a knowledgebase and task-oriented workspace [010↘︎] that works for the in-house and redistributed teams.

1.3 Adaptability

“We tackle problems together. We debate, challenge, and test to finally adapt our ability to resolve the issues in the context of the mental model, not a balance sheet.”

With our development colleagues, we embrace the change of requirements[011↘︎] – as it all benefits the user. This comes down to implementing the best prioritisation methods in place [012↘︎].

2.0 Growth

“As a team, we regularly reflect to prevent certain situations, which make us more flexible, accountable, and approachable to different challenges.”

To serve, we encourage the growth within over traditional passing down [013↘︎] the information. Peer-to-peer education has proven to be one of the most impactful learning methods over the centuries. 

2.1Trust

“We imbue accountability over responsibility – relying on respect and enhancement and empowerment of ownership over hierarchy control.”

We build the projects around motivated individuals. The C-level teams never deliver A-level results. We teach to trust [014↘︎] and rely on tribal leadership[015↘︎] over top-down structures.    

2.2 Self-organising

“We embrace some failure and setbacks. Yet, we learn (and document), iterate and grow as a team with an equal contribution to each other.“

Empowering tribal leadership[016↘︎] where designs emerge in the technology and work in embedded, well-functioning teams that support each other as a family/tribe instead of random individuals put together to deliver desired outcomes. 

2.3 Design and technical excellence

“We open design decisions to other disciplines to achieve consistency across all facets of the brand language implantation to make it better, easier to use, and practically invisible.”

In today’s product development industry, there is more overlap between technology and creativity. With continuous attention to detail, we teach our engineering colleagues to see our side of the picture where they spell a bit of their knowledge so that our designers are well integrated into their development life cycle[017↘︎]. (we welcome creative technologists, designers that like to code and full stack engineers that love to design – we are a collective of likeminded people)

3.0 Contribution

In order to build a great product and service, we embrace the experience and growth confluence of a continuous contribution[018↗]. Rather than delivering in chunks, we support ongoing delivery where everybody commits their daily increment at a specific time[019↗].

Continuous Contribution

“We add the value through daily increments to all team members to stay in the known – to be part of the design-led development journey.”

Our designers open their design boards[020↘︎] to a broader audience and every day share the increments[021↘︎] through a specific yet very efficient mechanism, automatically informing the wider team about the progress of the feature or behaviour that takes days, weeks, rather than months to build.  

Working prototypes

“We build accessible, responsive and inclusive prototypes. We create to express instead of impress.”

This brings us to a primary measure of progress. A well-integrated prototype [022↘︎] showing where our thinking is and what is outstanding from the specific release[023↘︎] to be delivered. 

 

Sustainable development

“We test hypotheses, learn and improve our ideas with data. We embrace data-driven decision-making.”

A well-intergrated prototype creates and maintains a constant pace of sustainable development[024↘︎]. Each side of the process understands what the other does.
The transparency between design and development proves to build a more solid code base. Less refactoring on both ends leads to frictionless and regular releases.

One more thing.

“Design is imperative. We listen to user feedback and make data-driven decisions to refine and improve our product.”

Our design never stops – we constantly iterate and debate the better way of building things. In close partnership with our creative technologists, we improve the experience daily.  

Let us know at @designatscaletm what your experience is and how you deal with design at scale. 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