Dear (none)Designer,
Welcome back to the thirty-eighth Design at Scale™ Newsletter – focusing on innovation and how design drives change in a large organisation or an agency.
Every organisation in the world strives to grow. Every business would expect the operation of delivering goods, digital products, and services, or simple groceries, to scale eventually. At this point, business operation became a development operation, let alone a design operation of some sort.
You don't have to work in a design agency or lead a design business to experience the integration of a design operation within your organisation. Quite rightly, it is expected that these logistical parts will eventually have to speak the same language and allow all participants to see the trail record of the decision-making process, empowering them to navigate the complexity of product design development.
Arguably, numerous articles reflect on business or technology operations, detailing how technology shapes the businesses and delivers value, while overlooking the fact that between these two giants is a quiet Design that shapes both. Despite the dominance of these parties, the greater benefits to any organisation come with the automated workflow in the design function. We can easily overlook the century-proven fact that design shapes the business and drives technology innovation. Yet, DesignOps is still something that agencies and businesses spend the least time perfecting. A well-documented fact where an integrated design function creates unexpected ROI by translating, maintaining, and integrating "the design in code" – strengthening the organisation from inside and enforcing a collaborative culture that is driven by design.
We often explain it as: "If you want to connect two things, do not use glue them, simply weld it." The ultimate connection between two points is a joint or overlap.
Quite rightly, the very first question here is: "What is the role of design in your organisation and how well is it integrated across the business?". If the answer for whatever reason is no, then the immediate follow-up will be "Why not?" There is no need for every department to have a designer. However, there is a need for the organisation to standardise the elementary principles of design delivery, so that when integrated with the rest of the world, it has a way to communicate in verbal, non-verbal, and functional ways.
To evaluate the proposition, the design leadership team has to understand the briefs, SOWs and PIDs, adding the necessary caveat that drives the experience across the proposition. Therefore, the organisation's System Level Agreement (known as SLA) must be extended to accommodate the design specifics, including the necessary information on how and where the handover affects the design. Equally, having a redistributed design team adds a specified requirement for the design team to deliver to multiple parties for approval prior to sharing the design with engineering colleagues.
At the heart of the designer, unity and quality control drive the interest in access to UAT and testing to ensure that the product is not only shippable but also stripped of all nuances that prevent a good customer experience.
It's wrongly assumed that what works in one team can be franchised to another team. That is why many large organisations fail to adopt a startup mindset for their unit or department, while observing that a set of particular individuals (usually contractors) have achieved something remarkable in a fraction of the time. The other teams struggle to replicate the success of the previous team and deliver the value proposition at all.
This often fails for two reasons: one of which is the comfort and the stability of "we have laways done it this way" syndrome. The second is, no time to invest in operational excellence and true integration of design and operation within the organisation.
.
Small and progressive teams often focus on progressive development by reducing the documentation to a minimum. The code is the key to delivering the functioning prototype. Arguably, this often leads to a higher cost of integrating such a proposition into a larger or more complex infrastructure.
On the other hand, the larger propositions have multiple teams that are forced to collaborate from the beginning. Informing themselves about the changes they are making and how they might/will influence each other in the upcoming delivery.
The clash of the models comes down to design. Design function is often under seemingly high pressure in a complex environment, often due to insufficient support, clarity and integration with development. When small design units deliver fast code, so to speak, big design teams often deliver bad design with more code.
Ultimately, both teams operate at scale. One scaling the small proposition and the other integrating design is a large proposition. Design at Scale™ looks at the operation from a rather pragmatic perspective, what makes sense in the long run – we want to build principles that guide business at least for 5 years, design patterns that can be reused to build new UI and code (language) that can be evolved over time. This leads to one thing, which is the reduction of waste and refactoring – in other words, operational excellence.
Over the years, we have collected more than 90 case studies across the vast majority of the market, finance, multimedia, transportation, education, healthcare, and retail, where flexible units translate the knowledge to bigger teams by laying down the foundation of lean startup / agile mindset referenced in Matthew Keegan's product model.
For more information, please visit Designa at Scale™ – GRID Magazine, where you can find additional relevant articles that explore high-performing teams, self-organising teams of 001, teams of 010, and teams of 100 that deliver the value proposition within a product-led environment.
