;

January 30, 2020

Design at Scale – Mindset

Welcome to Design at Scale – this article will focus on the mindset and how implementing such a mindset can make a difference in Product Design Delivery. To understand the mindset definition, let’s borrow the description from the encyclopaedia:

In “the decision theory” and general systems theory, a mindset is a set of assumptions, methods, or notions held by one or more people or groups of people.[001]

On the other hand, a design mindset utilises the assumption around the concept that reflects the holistic answer to a specific problem under common understanding and well-communicated outputs (reflecting monetary/business purpose) to achieve desired outcomes.

These mindsets builts around professions. Historically, companies created teams and later departments. Departments that hold the functions are inevitably risk reversed [002]. Protecting knowledge is the mindset where only the department has the expertise and can execute it. The design department is responsible for all design in the company. The accounting department is responsible for the salaries. 

“New eras require a new mindset,
the mindset of scale.“
– Jiri Mcc, Greenwich, London, 2015

A challenge mindset creates a well-diverse product team where several disciplines collaborate on one specific outcome. Insight teams protect what they find. Researchers test what they think is essential for the imaginary user. Designers design what they believe is right, and developers build what they can and could work on in the next 3-6 months. Otherwise, no one from the above gets paid in the end – fun aside.

Figure 02: Knowledge base

Is there a different way?

Of course, there is always a better way. Whether you are using methods like oportunity management[003], Stage and Gate[004] or Phase gate[005], the most significant impact on the team and the delivery is transparency. Deciding to create a “knowledgebase” would be the most thoughtful way to capture, manage and distribute the knowledge within and outside the team. This allows all participants to create the “baseline” for making self-organised and well collective decisions without extra effort and waste chatter on communication software[006] [007] or another medium.

Mindset

A DaS™ mindset – can be seen as 

Figure03: Quote

A person's unique perspective or philosophy of project delivery allowing these individuals to act (thought process involving understanding, collaborating, learning, and staying flexible) to achieve high-performing results on a specific task, decision or outcome necessary to deliver an incremental value to the team and the customer. 

This mindset guides the team members and allows them to collectively adapt to change rather than struggle individually or in silos[008]. It prevents other chatter and loss of valuable information when concentrating on clarity throughout the process. 

Initially, this could sound rigid or hard to digest, and of course, there is a transition period for the team. Eventually, the team even make it or breaks it. Those who make it work less and more efficiently, those who don’t will complain about how “busy they are”. 

Figure04: The most expensive words in business:
“We have always done it this way.”

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this very article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that 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 and questions, please follow: @designatscaletm

January 26, 2020

Design at Scale – Manifesto

Welcome to the Design at Scale Method series. Today’s article has no more minor ambition than to connect, empower and unify all product designers under a simple Manifesto, which easily translates the value of design in the current complex environment.

The ultimate aim of a product designer is to deliver a complete experience. To close the loop of interaction, where the indispensable components work in the synergy of great composition:
Where the context exists without isolation. 
Where conscious, cooperative, self-organised effort of all crafts are equally recognised as an integrated function,
Where dedicated precision of one’s craft defines the character of a specific product or service,
Where the gravity of our intentions plays a vital role in meaningful connections contributing to a transparent and well-connected design industry,
The one that is here to inspire and educate future design generations. 

“The Mission Statement of Design at Scale” (2020)

Figure001: “The Mission Statement of Design at Scale” (2020)

Let’s break it down:

The ultimate aim of a product designer is to deliver a complete experience –  Completing the experience allows everyone in the team to celebrate the effort and satisfaction of delivering a quality product. The product or service where our ideas were transferred into tangible outcomes for the hands or use of others.  

To close the loop of interaction, where the indispensable components work in the synergy of great composition – Throughout the design systems, micro-interaction, colours, elements, components and patterns, we all concentrate on delivering the complete product that solves one particular use case.  

Where the context exists without isolation – our profound curiosity about user needs allows us to isolate specific scenarios through which our user goes to deliver delightful, useful and fully functional propositions.

Where conscious, cooperative, self-organised effort of all crafts are equally recognised as an integrated function – And we all do it as a team through research and service design activities empowered by design thinking in combination with a product design delivery.  

Where dedicated precision of one’s craft defines the character of a specific product or service – We are not superstars (even though someone might think we act like one) it’s perhaps our craft and precision define the very best we offer to the team, business, customer and society. 

Where the gravity of our intentions plays a vital role in meaningful connections contributing to a transparent and well-connected design industry – Well, our intention is to provide value in the form of MTP – A massive Transformative Purpose that helps innovation, invention and overall transformation of the design industry.  

The one that is here to inspire and educate future design generations – one ambition, one clean purpose and one vision for every designer in the current design industry to empower the change that changes the future. 

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 the above Twitter channel 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

January 25, 2020

Methods behind Design at Scale.

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. 

Acknowledgement

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

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

January 20, 2020

Value Systems of Design at Scale.

Welcome to Design at Scale. This article will focus on the values that every designer who scales design propositions embodies and master while delivering incremental value to the team and the business – not even to mention the customer.

Aside from the company's fundamental values – other values like business, agile, design, or your own all of them define the approach to a specific problem. The following four pillars clarify the values that allow us, designers in the exponential era, to scale the design propositions.[001↘︎]

Figure02: Customer Collaboration

Customer Collaboration

Regardless of the design or development method used for our current delivery, customer feedback is proven to be an invaluable ally in decision-making. 

Whether we discuss small, medium or large design teams, the integration of Insights[002↘︎] and Research[003↘︎] function with a rigorous QAE [004↘︎] is one of the main pillars that drive and, in some cases, even dictates the collaboration within the team delivering the product.  

The objectives for customer involvement must be outcome-based rather than output-based. It allows the team to react without resistance and see the change as a particular step to fulfilling behaviour-based requirements [005↘︎].

This means the customer's involvement throughout the development process (before, during and after) ensures that business needs are fulfilled. All our designs are accessible, and development can test early throughout the development process.  

Figure03: An icon of the brain.

Continuous Iteration

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools” [006↘︎]. 

Valuing people's opinions in protective and corporate culture might lead to more complex verbal agreements rather than creating a written understanding of a feature or functionality that needs to be adopted globally. 

The continuous iterations allow all team contributors to do the same. By creating the shared knowledge in Confluence[007↘︎] (or any other form of wiki), we can obtain extensive documentation and build (a minimal) knowledge for anyone who is part of the product team. 

This strengthens responses between business and product teams and drives transparency across the company.

Figure04: An icon of the brain.

Prototypes and Software 

Designers were traditionally forced to build comprehensive documentation in response to an outsourced development. 

Enormous amounts of time went on to documents describing behaviours, mental models and navigational patterns. By the time the documentation reached the development team, it was already outdated. 

Nowadays, well-defined prototypes of various software (like Figma or XD) replaced the documentation and integrated with more OOD – Object Oriented Design[008↘︎] in the development process[009↘︎]. 

This allows designers to constantly iterate on the initial idea and, through the automation[010↘︎] is informing the business about changes made. Equally, building a strong alliance with development[011↘︎] by responding to their needs while documenting the process in the form of prototypes[012↘︎]. 

The knowledgebase[013↘︎] ensures design specifications (including fonts, colours, layout, imagery, design systems, site maps, behavioural and mental modes) are in one place.  The technical specifications (including technical requirements, technical prospectus, test plans, and approvals required for each) are accessible to all parties in one location – most certainly a form of WIKI (Confluence, Notes etc.)

The beauty of this approach is that there’s little to no extra effort necessary to document anything, as “the documentation” is created while designing, prototyping, programming and testing. This avoids extensive delays in development and reduces the refactoring of the code, especially when our engineering colleagues are part of the decision-making from the beginning to the end.

Figure05: Change and Response.

Change and Response

The design traditionally embraces a holistic approach rather than building from small increments. In software development, the design changes require bigger sacrifices that inevitably affect the user, budget, relationships and agreements. 

In order to prevent it, we develop behavioural outcome-based plans rather than output-based measurable deliverables that do not change behaviour or immerse the interaction. 

This structure helps us to navigate and elaborate on our plans, while prototypes allow us to test our hypotheses and crystalise outputs from the unknown to known outcomes. [014↘︎]

Automation plays a key role here. If your team spends the time filling the excel sheet and updating their daily tasks in multiple places while communicating the progress to other members of the teams by no means you aren’t responding to the change, and you are wasting a lot of time. 

DaS™ – Creates and maintains actionable communication uncontacted where the chatter can happen anywhere. The simply defined discipline soon brings the fruit its manifest. 

Let us know at @designatscaletm what your experience is and how you dealt with design at scale. If you have any questions, 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 that 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

January 15, 2020

Design at Scale – Principles.

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.
And second, it comes with the great responsibility to serve well-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 

Figure02: Experience Principle.

“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

Figure03: Simplicity Principle.

“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

Figure04: Communication Principle.

“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

Figure05: Adapribility Princiople.

“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

Figure06: Growth Principle.

“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

Figure07: Trust Principle.

“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

Figure08: Self-Organising Principle.

“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

Figure09: Design Excellence Principle.

“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

Figure10: Contribution Principle.

“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

Figure11: Prototypes Principle.

“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

Figure12: Sustainability Principle.

“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.

Figure13: Imperative Principle.

“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

January 10, 2020

History of Design at Scale™

Historically, the design was defined as the stage-gate iterative process. To paint a portrait, wall or cathedral, we all understand the task and what can be measured and sized in some ways calculated. They require a certain shape and size. Also, the emotional part of the experience is delivered through the artist or architect's expressive[015↘︎] innovation[016↘︎].

This article aims to map design as a scaling technique or process across 300+ years to the present day, where design delivers, connects, and enhances business wider and deeper than we know it.  

Figure 02:  Show the product lines aka Bata

Production lines

The relationship between design and technology has always been very prominent. By influencing one another, we have witnessed several inventions, such as steam-powered engines and manufacturing lines[017↘︎], that changed the world as we know it. 

In early 1900 the car manufacturing facility at the River Rouge Plant [018↘︎] of Henry Ford [019↘︎] pioneered time productivity. Soon European shoe manufacturers observed product lines between 1920 and 1928 and successfully experimented with the assembly lines in Bata [020↘︎] shoe factories[021↘︎]. Lines relied on a verified concept where each part of the delivery was broken down into a sequence of tasks. This specific output allowed the business to assemble products faster.[022↘︎

Fast forward 60 years or so, and big agencies used the same model in print production, breaking tasks into different departments (photography, illustration, typography, and so on). Print design flourished as a result in the 70s and 80s, impacting billboards[023↘︎], the boom of advertising[024↘︎] and print magazines[025↘︎], especially TV.[026↘︎] 

Figure 3: Horizontal integration   

Early Design Software Development 

Incremental and adaptive software development[027↘︎] opened up a new era of development. This directly impacted project management[028↘︎] (later known as agile), influencing design delivery from the early 1970s. 

During the 80s and 90s, we saw more and more designs start using HTML to build simple pages. Soon enough, agencies adopted software development methods[029↘︎] in reaction to client demands — campaigns that represent services and services moving to digital products. Within less than two decades, we moved from horizontal[030↘︎] through vertical[031↘︎] to functional integration.[032↘︎]

Growing digital studios have to adopt development methods demanding rigorous evolutionary project development. For centuries, agencies have been selling the stage and gate.[033↘︎] Clients adopted the horizontal integration approach to design delivery because it was easy to understand. Project managers (also known as PMs) had to handle the development demand of these solitude experiences while using so-called heavyweight methods (often referred to collectively as waterfall) that critics described as overly regulated, planned, and micromanaged. This inevitably led to extensive overheads with the delivery. 

Figure 04: Horizontal integration   

Advanced Software Development 

The Agile Manifesto publication was created in February 2001.  It combined various agile software development methods into one comprehensive proposition.[043↘︎] Seventeen software developers crystallised the very essence of software development – “with a remarkable achievement”. 

Ever since, design delivery (often referred to as UX and UI) has been utilised in the form of a peripheral delivery [044↘︎] (outsourcing). Until very recently, design delivery gained its dominance and became a part of Agile in the form of Dual-Track Agile[045↘︎] as an integrated or central function. One of the many critiques of early Agile development methods comes from not considering other disciplines (including Insights, Research, Copy, CX, UX and UI) as vital contributors to reflect (better say to have an impact) on Agile-based delivery.

Opportunity ahead 

Understanding the above gives us a great opportunity to intentionally challenge businesses to understand that over the last two hundred years, all disciplines have evolved so has the process and ways of delivery. By carefully observing, listening and interviewing clients, colleagues and coworkers, we can ask a very simple question to every product team out there:

“How could we integrate design better to deliver consistent value to the business as well as their loyal customers?” 

Soon, we’ll realise that there is not such a thing as one process that fits all. Especially when our communication pattern has changed completely, when our teams are so diverse, and the function is so specific that we all have to adapt. Where the technology changed so fast before we implemented Beta, there are ten of new APIs we need to adapt to. It is no wonder that the operation will be the key to tailoring this into a comprehensive, healthy, flexible, scalable and well-functioning product team that delivers value to the business. 

With over two decades of interviews and analysis methods, we are bringing the Design at Scale™Grid publication

The medium where we meet to connect, discover, share and challenge design functions within an organisation as a primary pillar strengthening transparent communication across the business and creating a resilient and well-functioning design team that utilises the technology in the centre and challenges the operation models that work for particular situations.

Our ambition is to bring stories, case studies, and research papers analysis from this variety of unique and well-rounded sources that deserves our attention.  

Stay tuned; thanks for reading!
Thanks to all contributors, especially Matt Press, 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 that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories
@designatscaletm. For direct messages and questions, please follow: @designatscaletm

January 5, 2020

The ambition behind the DaS™

We are starting with a clean sheet of paper and pencil. 

That’s where all designers begin. 

For centuries creatives and many different disciplines it has always been a piece of paper pencil that visualised the idea – a good enough state that can represent an ambition. 

From ambition, we move to process, tools, time and resources, and that’s where it gets a little complicated. Design (or any creative venture) was always under the demand of a budget, time, or immediate need to solve a specific problem. That is why the design was always under someone else direction. 

Business creates the plan, road map, delivery schedule and so on – design does not unless the proposition is complex enough to track all of these things together under one roof. Even then, the design was not the one that decided under which condition these specifics would be actioned and delivered.    

There is so much ambiguity, significant (static) pine charts, slides and graphs explaining the process (copied from early 20th-century manufacturing lines), workflows or delivery methods that surpassed its creators. 

But when it comes to practical execution in a specific environment, one method does not allow integration of the other. Not even mention that mental models of the majority of our processes are categorically different and look at the problem from entirely different perspectives. This creates tension and confusion within the team and all surrounding contributors. 

Our ambition for the magazine is to question and stress-test these methods under the delivery while providing alternative options, suggestions, and case studies representing a unique point of view on integrating design function. 

Via practical examples, we help individuals and teams to integrate the DaS™ method by connecting the dots and allowing all participants to get what they need throughout the flexible and transparent product design delivery[00].

Let’s look at the history of Design at Scale™ from the perspective of individual designers, design teams or a design function or department within a big organisation. Then we’ll be able to see the impact of Design at Scale on how individuals transform businesses through the design.

Stay tuned; thanks for reading!
Thanks to all contributors, especially Matt Press, 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 that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories
@designatscaletm. For direct messages and questions, please follow: @designatscaletm

January 1, 2020

Welcome to Design at Scale™

Thank you for stopping by and dedicating your time to learning something new about design. Design at Scale™ – is an ambition to unify all designers under the umbrella, offering clarity, stability and transparency for complex design propositions.

Every day, we hear about new quotes, methods, processes, or software that enhance a designer’s life or improve the business. Yet, after reaching a fully remote era, we discover that a newly established design team is under constant pressure on how all the above works together in synergy within a broader context of the already established or new business.

Design at Scale™ is not a magic formula, quick win, or something you can get off the shelf for a few bucks. It’s a comprehensive method that takes time to master and embrace internally as a team or business. However, once we all reach the point of mastery, the scale and impact go far beyond what we know. 

Figure02: Shelf in the store in perspective.

We often ask:

What is the ultimate design value to the business and the customer? What is the intersection of skills, techniques or understanding design needs to possess and succeed in the current constantly demanding and changing markets?

Far too many teams suffer the consequences of poorly integrated design functions in current organisational structures. Inadequate methods are used in the usually wrong context where plans and ambitions are judged by an ambiguous output instead of measurable outcomes.
We are here to change that:

After 25+ years of designing and collaborating in both agency and product-led environments, we’ve distilled – Design at Scale™. DAS™ – is the method that orchestrates all greater integrations of a design as a function that helps businesses to thrive in the era of constant change.

Figure03: Design at Scale grid of +

Welcome to Design at Scale™ – the Grid Publication you entered right now has been set up to focus on the design that scales up. The design function within an organisation is primarily defined by clear and transparent communication and building a resilient and well-functioning design team that utilises the technology in the centre and challenges the operation models that work for particular situations.

Our ambition for this publication is to bring stories, case studies, and research papers analysis from various unique and well-rounded sources that deserve our attention. After almost a year of organising two decades of research, we have settled on these four categories:  

Figure04: Four pillars.

Categories

Communication

This category focuses on how we designers communicate as individuals and within larger teams. We‘ll look at the case studies that help design teams break the silos and create a transparent product team. 

Team

The second category is about team and team building. There are some specific to each design team and each company. However, building the design functions within the company and its successful integration with product Delivery lies in the design team itself. Equally, how does the design team of teams operate under a different implementation of the Agile development framework? 

Technology

Designers have created static graphics for over two decades representing dynamic, responsive environments. We’ll look at the technology and software solution that helps the team deliver design at scale in this category. The criteria here is quite simple can scale my design (system, mockups, test, prototypes) from 30 to 3000 without losing control over the design delivery.

Operation 

Finally, all the above becomes a comprehensive delivery system that can be easily understood, translated, and scaled. More importantly, it integrated with any other team that requires the updates, insides or directly depends on the feature, project, or product to be shared. 

Stay tuned; thanks for reading!
Thanks to all contributors, especially Matt Press, 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 that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories
@designatscaletm. For direct messages and questions, please follow: @designatscaletm

Your Story
Matters.

Contribute.

We're sorry you haven't found what you were looking for. Let us know your story, and we'll ensure it's broadcasted to the world.

All brands and trademarks presented on the DesignatScale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners.
Do not copy or publish any of the projects shown here without approval from 9V™ + GIVE™ + Design at Scale™ and/or relevant companies and agencies.

View