Dear (none)Designer,

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

One of the greatest challenges for all design teams is not scaling up, but scaling down. In many respects, we face budget cuts, people leave the team, work is doubled up, or leadership changes the complete direction based on new requirements that need to be fulfilled in a short period.

How can we scale down and still meet all deadlines on time? Have you ever heard about the doctor operating on your knee or an eye, and instead of having four hours for the surgery, he suddenly had only twenty minutes because there were three other patients in critical condition that needed to be treated.
In product design delivery, we often write briefs that specify the functionality, expected behaviour, objectives, and KPIs. We specify the level of effort, but we soon realise that from the three months' work, we only have three weeks to deliver all our tasks in high quality, because the rest of the team didn't consider how much time we need for delivery.

I often hear it's a product problem or project management problem, or it's a development pressure that we constantly need to fulfil the feature factory scenario, so no developer stays without work. We need to utilise the time better. In all these cases, it's always the outside force driving design, and it's often considered that only an outside function can drive the design efficiently.

Let me tell you a short story of a team that, through the project specification allocation and resource management, was defined as a 16-person team for an 18-month project and ended up being delivered in nine months with only three people. You would rightly ask how this is even possible. Without going into too much detail about the organisation, our function is usually defined by allocation and the budget. Resourcing has correctly defined that our delivery will need a 16-person team in order to deliver the transformation if we do it feature by feature in sequence. As the complex project goes, they only get simpler once we start designing and building. It becomes evident that some of the features were redundant and do not have to be fully designed, as the other better feature replaces them. The planning and sourcing have no way of knowing that, as they are not developers or designers. By stacking our knowledge, we realised that our small team is capable of turning 21 story points in a week. Giving us the capability to almost triple the speed of delivery.

The definition of the project took almost 3 months before design was even a call in the room. This way, we didn't have any impact on how the project was shaped and what foundation it was based on. Three weeks in, we have three features fully deployed and nine features designed.

Understanding that the derisking project is important and should not be underestimated. Yet we often see that the majority of big risk assessments are based on a very poor brief that does not have any specifics.

Upon reviewing all the requirements, we realised that several features can be combined as multiple functions in a single release. Our team includes a UX/UI and design system architect, all of whom contribute to the same set of files that deal with the proposition.
In the first months, we have heard that we need more UI design, including buttons, colours, and tiles. Our designer created a little library that's going to be easily adjustable and produce a very quick turnover of different artefacts that can fulfil product/feature-driven delivery. This allows us to build an interactive prototype in the form of white frames, which we can call a white-label product. It not only replicates the existing environment but also simplifies and streamlines the journey between different interactions.

To be specific, for example, a payment between two businesses or a payment from one organisation to multiple businesses, such as suppliers, is essentially the same feature. However, the bulk payment needs to have an additional four steps for verification. This way, we can have a function that allows us to communicate a single payment. Once we reach the fully functional white label, we can then demonstrate how simply and easily we can implement this feature across multiple different products.
At the end of the first month, when we present the white label prototype, our engineering colleagues spot that they can optimise the code and start with a schema to bring these interactions to life without actually asking us for a detailed design. Meanwhile, our engineers have started supplying the correct code for the proposition, and a month later, we received new updated branding for three banks.

For more information, please visit Designa at Scale™ – GRID Magazine, where you can find additional relevant articles that explore hyper-performing teams, self-organising teams of one, teams of 10, and teams of 100 that deliver the value proposition within a product-led environment.