Dear (none)Designer,

Welcome back to the sixteenth Design at Scale™ Newsletter – focusing on innovation and how Design drives change in a large organisation or an agency.

When people ask how we can scale our business, most of the time they are seeking investment and hiring more people to do more work. More work means more outputs, which in turn lead to more outcomes, resulting in more sales, which ultimately translates to more money, and ultimately, a larger scale.

With the arrival of the 21st century, we have realised that more people are not crucial to scale; more importantly, they sometimes prevent the scale. It has been well-documented that companies with between 80 and 1000 people face significant challenges in documenting design decisions that translate business requirements into source code deployed to the server, which then serves as a product or service in an online or app environment.
 
The majority of Startups and small-scale ups have proven that a design-to-code approach is the best way forward. Small teams have far more flexibility than big and robust teams, which often suffer from over-bloated project management and extended client services.
 
Self-managing teams have now reached a point where the gap between the design idea and code is minimal, often nonexistent. It is because design decisions have been documented through prototypes, which are already implemented in the code that can be consumed by engineers and tested in the real development environment.

I would not speak for the engineers. My limited understanding of code allows me to appreciate the work they do. Always encouraged to define components, elements and modules in such a way that the source file of the React component or the app in Swift is concise and has a solid foundation for an application.
The era of documenting design decisions in 1,200 to 12,000 pages in InDesign is far behind us. We now have a solid pipeline, from user stories written by the Behaviour-Driven Development approach to design to code.

Understanding that the onboarding for any customer in the application or online service will be relatively the same, the documentation hasn't changed over the decade. Therefore, we can assume that 80, if not 90% of the documentation, can be prevented as a standardised pattern. Only the nuances of the changes shall be applicable as a customisation layer, whether we are building the onboarding for an airline, healthcare service, transportation or a financial institution.

It brings the emphasis to the design systems, whereby defining modules, we often describe the behaviour that is prescribed by the user journey, and therefore it's applicable for development and testing.

In 9 out of 10 cases, AI can be fully automated when combined with Figma and Atlassian. This powerful trio enables today's designers to translate business requirements into war-friend-driven solutions, leveraging the design system white label framework, to which we can later apply the UI and thereby translate any brand for the final implementation.

Feel free to reach out for more details about the power of one or read one of our articles, which are part of the Grid Magazine, as well as Design a Scale Academy.