Designers are Scarce Resources — how to scale design
Scaling design in large organisations is a hot topic in the community. In this article, we look at software teams and this question of scaling from an engineering standpoint.
In engineering, we have long since been scaling many of our favourite services — among those are certainly internet pages, database queries and delivery systems for cat photos. Can the technique for scaling these services offer an inspiration to scaling design?
We propose a new way of combining the two disciplines — Design Thinking and Software Engineering. One where the designer has the opportunity to pass the design context and the empathy for the end user onto the engineering team. And prepare the team for a situation where designers are no longer part of the assignment. A setup where the design lives on.
In large organisations, many teams work simultaneously on products and services. In these environments, it’s not strange to come across teams working on only a small part of a large and complex service, not always knowing the complete context or its dependencies. With digitisation of products and services, most teams are engineering teams and they focus on shipping working software to production.
Product Backlog & Agile Software Development
Agile software development practices and tools have made continuous improvements possible with small increments. Practices like DevOps have merged software development and operational responsibilities within one team. Frameworks like Scrum offer engineering teams the structure to deliver working software frequently, bringing down the delivery time from a couple of years to a couple of weeks as compared to the older waterfall model.
At the heart of this way of working is the Product Backlog; a prioritised wish list of tasks for the team to work on.
Feature-Driven Product Backlogs
The most common entries on a Product Backlog are product features. These drive the development of the software product and reflect what is to be done in the future. The product backlog is owned by a Product Owner who is responsible for formulating these features.
Product features are typically technical solutions that get created from user feedback, A/B tests, bug reports, market research or talking with stakeholder. They range from user interface changes, like adding a dropdown list to reworking the layout. Also API updates to including a new response or database modifications frequently make the cut.
An example of a typical product backlog feature is — ‘Add a dropdown list to adjust font sizes on the front-end.’
Loss of Design Context
With a Product Backlog filled with technical features, the original context and empathy gets lost. The challenge to solving the features becomes about execution and assembly. With the solution pre-decided, creativity in such teams revolves around choosing the right software language, embedding the latest toolkit or picking the killer platform to run on.
In course of time, a team that is only exposed to features, gets skilled in pushing features to production. But at the same time, the team starts to depend on others to supply the solution. The distance between the user and the builder widens. And with this widening, it becomes difficult to verify whether a suggested solution is optimal or if there are others that might be better suited.
Design Lifetime
The legacy of Design means that several Design Thinking assignments often are thought of as projects — with a begin, middle and end. In large organisations, these get rolled out as Accelerator Programs or Innovation Design Sprints and usually result in a MVP.
Most of the time this MVP is a ‘Minimum Viable Pitch’, ‘Minimum Viable Powerpoint’ or a ‘Minimum Viable Prototype’. Seldom the MVP is a ‘Minimum Viable Product’ — working software in production with just enough features to gather validated learning about the product and its continued development.
More than once Design Thinking sadly ends, where Agile Software Development begins. Products and services that have a longer history and are considered maintenance, go merrily operating without ever hearing of Design Thinking.
Even with the best intentions, it is often not feasible to add a full-time designer to every team. Designers are scarce resources!
Given this state of affairs, the question becomes;
- How might we introduce Design qualities to Engineering Teams that maintain products or services?
- Or in a broader sense, how might we bring Design qualities to everybody in our organisation?
Solving for Scale & Trade-offs
In this question, we’re essentially solving for scale. Computing faced similar questions, not too long ago — how do we distribute scarce resources to an increasing demand?
Distributed computing introduced: horizontal scaling — next to vertical scaling. Horizontal scaling means that you scale by adding more machines as opposed to vertically increasing the size of a single machine.
However, horizontal scaling comes with its trade-offs. These trade-offs are best explained by the CAP theorem. The CAP theorem states that a distributed computer system can have at most two of the three desirable properties: Consistency, Availability and Partition Tolerance.
Consistency (C) is equivalent to having a single up-to-date copy of the data. Availability (A) is getting an answer each time you ask a question. And Partition Tolerance (P) is the ability of the system to function even when some of its parts have failed.
You cannot guarantee all three properties and scale horizontally; you need to pick two.
Eventual Consistency — the obvious option
Since no distributed system is free of network failures, network partitioning (P) has to be tolerated. Sacrificing availability (A) is not an option either as it disrupts user experience. This gave rise to the idea of loosening the consistency and create a system with Eventual Consistency, thereby guaranteeing Availability (A) and Partition Tolerance (P).
It is important to note that a system with Eventual Consistency does not mean no consistency. It only suggests that multiple answers must be tolerated and that conflicts are resolved later in time.
If we apply the CAP theorem to our design scaling questions, we can redefine them as -
- How do we achieve eventual consistency in Design and thereby scale it to all engineering teams?
Question-Driven Product Backlogs
What if we take the linchpin — the Product Backlog and change it ever so slightly? And instead of technical features, have it contain a set of questions.
Questions that include the context: of who has the problem, what are they experiencing, what do they see as a fix, how many are facing the same, etc. This preserves the design context and invites more than one solutions.
An example of a Product Backlog Question is — ‘The elderly have trouble reading the small font on our website. How might we help them?’
This moves the creativity of the engineering team from creative assembly to creative problem solving with increased empathy for the end user. And encourages inquiry to understanding the problem. In course of time, a team that is exposed to question, gets skilled in answering them.
Creative problem solving and empathy are cornerstones of design, and it’s this language that gets passed on. The trade-off here is Consistency (C). There will be situations where the engineering team crafts a different solution than the one the designer came up with. And those need to be resolved on agreed moments in time. And yet, we guarantee Design Availability (A) for the lifetime of the software and Partition Tolerance (P) even after the designers leave. Trading consistency to horizontally scale design in large organisations!
Opportunity Space
We hope the next time you look at a Product Backlog, you’ll see it differently. You will see it as an opportunity to infuse the wonderful language of design by framing Product Backlog Questions. And that this new and different sight is designful!
