In the tech sector, we’ve grown accustomed to certain processes when designing and building products, such as moving in a linear fashion from research to prototyping, to building live working software.

Following a series of predictable steps and processes has a lot of benefits: it might help teams secure funding, get stakeholder buy-in, or reduce complexity by giving teams a starting point. The problem might also be straightforward and a linear approach makes sense. On the flip side, universalisation, or a one size fits all approach, can narrow our field of attention.

Our products don’t exist in a vacuum, nor should our processes. From my perspective, there is an over-reliance on methods such as Agile, Lean UX and design sprints that rush product teams towards short term solutions when building technology. These rapid processes make it easy to forget that

problems shift based on our perspective and complexity increases at different scales.

Linear processes often simplify the types of questions asked and time spent unpacking the problem, making it difficult to design a product that can handle complexity at scale. It also becomes problematic when processes, like design sprints, become the default way for addressing a problem, acting as a checklist rather than a guide.

I’m guilty of falling into the alluring trap of ‘rinse and repeat’ when it comes to certain processes –– it’s easy to go into autopilot and forget to question the approach. It’s important to evaluate who, and how, problems are framed because there are consequences to singular authorship, when technology is not co-produced, designed with the wider system in mind, and problems are not understood from multiple perspectives.

Understanding the whole picture

When designing and building products or services, it can be easy to fixate on the individual parts of a system, rather than understanding the whole. The painting of the Blind Men and the Elephant is a perfect example to illustrate this point.

In the painting, each person is touching a different part of the elephant, forming their own opinions, not understanding the sum of its parts. The moral of the parable is to avoid claiming absolute truth based on subjective experiences.

Painting of The Blind Men and the Elephant by Hanabusa ItchõInstead, the painting asks us to accept that there can be more than one answer and more than one interpretation. It also makes me think of how we might share experiences and knowledge to better understand the whole. I think this is a great illustration and reminder for product teams to hold space for other perspectives and understand the relationships between things before acting.

Applying a system lens to our questions

Listed below are some of the questions we’ve been grappling with to understand the whole picture, the complexity, patterns, and connections between the parts before implementing a digital product.

The goal is not to answer all of these — some of them might not have answers, and that’s okay. I see these questions creating resistance, functioning as speed bumps so that teams pause and reflect before acting.

The wider system

• How does the problem shift depending on the scale (from an individual/ family/ community/ city/ nation/ to a global level)?
• What are the root causes of the problem (e.g. mental models and behaviour that reinforce the issue)?
• What has already been done in this space to address the problem? What worked and what didn’t?
• How will we leverage and contribute to existing community initiatives, rather than creating something new?
• What does the wider ecosystem look like (i.e. the power dynamics, processes, and technologies that underpin the current system)?
• What are the laws, policies, and system regulations in this space?
• What are the people, processes and technology processes that need to be in place to make a positive impact?
• What does positive impact look like at a local, regional and global level?

Context and intended impact

• What are the long term systemic goals we aim to contribute to?
• Who is framing the problem?
• Why is there a need to intervene?
• What is in and out of scope for this work?
• What evidence has been collected to define the problem (e.g. what qualitative and quantitative data exists and how the data was collected)?
• Who is the problem centred around?
• Who is excluded or isn’t using the service and why?
• What is the intended impact we hope to make?
• How might we design to consider the planet as a stakeholder?
• What are the technology constraints and aspirations? (e.g. who might not have access or who might be excluded based on certain tech choices?)
• What are the organisational incentives and goals for doing this work?
• What are the highest impact areas?

Anticipating negative consequences

How will we avoid perpetuating the problems we are trying to address?

• What are the risks of engaging in this space?
• Who might benefit from this product or service? Who might bear the cost?
• Which actors are wielding power?
• What are the potential and negative consequences of intervening?
• What are the risks of intervening to nonhumans?
• Who is going to be accountable when something goes wrong?
• How will we address the consequences of the decisions we make?
• How will we mitigate risks and who will be accountable?

Infrastructure and long term plan

• Who is best placed to intervene and why?
• What are the short term and long term costs of intervening?
• Who is part of the core team and who are the stakeholders?
• Who might be excluded from the core team and why?
• Who are the local experts who will be engaged throughout the work?
• Who will care and support the team doing this work?
• Who will actively prioritise inclusive design practices, and how?
• How will we prioritise what is designed and built, and who has the power to decide?
• Who will own and maintain the product or service?
• What might block collaboration?
• How will we measure impact in the short and long term?
• What governance is needed to support this work in the long term?
• What partnerships can be leveraged to create a more holistic approach?

What scaffolding do you need to have in place?

Asking these questions often requires the right environment and scaffolding for teams to have the time and space to unpack the problem before building a product. Not having the right scaffolding doesn’t mean that these questions shouldn’t be asked, but it does help when the following conditions are in place:

• Funding teams, not projects This allows for a longer-term approach, one that considers the wider context before intervening.
• Properly scoped work requires the right people and/or organisations to be in the room from the start –– it’s important to recognise whoever is in that room deciding the framing of the project, wields a lot of power.
• Diverse teams with agency Diverse teams need to have the right support and agency to be able to change course based on what emerges from the process of understanding the system.
• A culture that values slowness Not operating from a place of urgency, with longer timeframes, can help create a more sustainable pace for teams — one that isn’t constantly battling the tension of rapid delivery.

This blog post is an extension of some thoughts I’ve been exploring around how to create the scaffolding for teams to do their best work and how thinking in systems can help mitigate the unintended consequences of our design choices.

I’m not one to write weeknotes because I really need to digest things before I share my thoughts externally. However, I’m actively trying to share more of what I’m practising. I would love to hear how others are making space for these questions and processes that help unpack the problem more holistically.

Further reading

Resources for applying a systems lens to your work

Not to Scale by Jamer hunt

System practices from the field by School of System Change

Equity-Centred Community Design by Reactive Reaction Lab, which I learnt about in a workshop they did called How Traditional Design Thinking Protects White Supremacy.

Decolonizing design by Anoushka Khandwala

Governance — the overlooked route to transformation by Forum for the Future

Portals to Beautiful Futures by Omidyar Network & Guild of Future Architects