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↘︎]

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.  

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.

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.

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.