This article is based on a presentation made for the Service Design Network (SDN) Switzerland in December 2019.
How To Design In Large And Complex Organizations.
I work in the financial & banking technology industry (aka FinTech) as a Senior Designer consultant, currently helping to improve the Experience of Compliance solutions at Pictet Bank. If large global organizations are usually complex, banks & financial companies are probably amongst the top. Compliance is one aspect of this complexity, as rules & regulations apply to markets at more or less local levels, with, on top of that, the company’s risk tolerance strategy. Beyond compliance, regulations, and rules, there are real people –human beings– ensuring that the company (and its clients) follows the regulations (therefore reducing its risks), and in general, a lot of people that are impacted at many different levels.
This makes interesting challenges, as you may guess: How do you transform something which is mandatory –and experienced as such– into something that feels necessary, useful, meaningful, and transparent? Something that adds value to the end services?
Some really good questions…
To be honest, one year ago I didn’t know much about Compliance. And when approaching a new environment, it is tempting, in general, to rely on our known tools, methods, process, and personal experience. As designers, we really love to talk a lot about our tools, methods, and processes. The Internet is full of articles and discussions about this topic. However, I think that it creates several issues in general:
- An unnecessary focus or “lens-effect” on tools & methods. This can give the illusion that this is all what matters the most.
- A disproportionate reliance on such tools and methods as a by-product of this “lens-effect”.
- A false-sense of standardization of our methods as a process of reduction to the most “popular” ones. Standardization is nowhere near these criteria.
- A false-sense of “shared understanding”, as the tools/methods are supposedly known to everyone in the same way. Except they are not.
Moreover, focusing on tools when we don’t understand the environment we are in gives an illusion of being in control, while in reality, we are just blind towards how the system works and what leads to certain outcomes (e.g. success or failures).
A Recipe For Pancakes

The recipe analogy is a recurring one (i.e. here, here, and here) in our domain (aka the Design Sprint), so let's use it to illustrate my point.
All recipes contain at least two main basic elements: a list of ingredients and a list of instructions explaining how to use the aforementioned ingredients, how to prepare them, in which order, etc… (note that it can be presented in various ways, but you get the idea). It’s deterministic and linear by nature as each step, executed as instructed with the listed ingredients causes the predicted result. Therefore, this process brings a sense of certainty to the outcome — while in reality, it increases probabilities/likelihood (at each step) upon the belief (intent) of what good (expected) outcomes should be. But more on that later.

A recipe is a formalized process –in other words, a method. It's a tool to reach a desired predetermined result. And because of its very formulation, a tool implies some prerequisites to reach the intended result.

Here, it implies that you have access to such ingredients and that you are able to perform such instructions. This also means that diverting from either the required ingredients or the instructions threaten the very point of using a recipe, by removing its certainty.
A tool is a means toward a goal.
Design, innovation, change, (etc.) are mainly about navigating uncertainty to move from a given observable state to a yet-to-be-uncovered one. Yet, we see that framing our work around our tools is about the opposite.
Let's extend a bit further the recipe analogy by looking at the “chef/cooking” domain to see its limitations. If you ever worked with a chef, you should know that:
- A chief's kitchen is an extremely controlled environment, not an uncharted territory. In fact, it has been designed for that very purpose.
- It's all about mastering the process. When you have dozens or hundreds of clients waiting in the restaurant, it's no time for doubts, questions, change in plans or improvisation.
- In a chief's kitchen, there is no place for uncertainty or exploration. Everything has been devised and tested beforehand.
- It's about delivering outputs at the right rhythm and in a qualitative manner.
That doesn’t mean chefs don’t innovate. But they are usually not doing it while serving clients*. They instead have dedicated time to test new things, with space for failures & learnings. And when they do so, they don’t follow existing recipes. They are creating new ones that fit their goals and context.
To an extent, look at the fast-food industry, like McDonald’s to see these elements taken to an extreme.
*Note: a bit of context is needed here. I did research the topic a bit and discussed it with people in the field, but I'm clearly not an expert. From my understanding, all chefs work in different ways, but they also share a lot of common practices/methods. Creativity is obviously an important component (i.e. combining known things in new ways) but clearly not required all the time. As explained, creating new dishes is usually an upstream process, which can be quite organic. If the result is satisfactory, it is refined and scaled to the restaurant's capacity. If you're interested in “food & cooking innovation”, there are interesting research articles available (see also the article's references section). Spoiler alert: no mention of any recipe for innovation... 🤔
The World Is Complex. So Are Large Organizations.

“A recipe implies that you have access to such ingredients and that you are able to perform such instructions.”
In complex organizations, the prerequisites necessary for ready-to-use recipes, methods, or processes are not guaranteed. Sometimes you don't have all the ingredients. Sometimes, you can't perform all the instructions. And quite often, it's a bit of the two. In fact, in such environments, it is impossible to control all the variables that lead to a desired state. Our tools, methods, and processes are, by design, ignorant of this reality.
Complexity theory shows that systems with apparent simplicity (few rules) can become unpredictable (from the original standpoint) over time through emergent behavior: this is system entropy. Emergent behaviors may display coherent patterns: this is self-organization. Other examples here and here.
Focusing on the tools here would require first to address the problem of “ability”, which leads to the problem of “change in mindset”, which eventually loops back to the need for tools to bring the change, etc... It’s a never-ending quest for the “right” or “perfect” tool.

Organizations As Beliefs Systems
Another aspect of this complexity is something I really find amazing: how systems create beliefs that impact decisions, impacting in turns the systems and the beliefs themselves
Here's an example of organization's belief system:
Looking at organizations this way helps realize that beliefs are not inherent properties of people but rather observable expressions of the interactions between parts of systems. Acknowledging this helps also in the realization that fighting the people holding the beliefs may be a waste of time. Changing behaviors, minds, and beliefs is more about changing the context than changing the people.
“Making the familiar strange, and the strange familiar.”
– Deborah Rowland, Lead like an anthropologist – and lead change well
An Approach To Design In Complexity
Far from a linear process or deterministic method, here is my approach to complex organizations. These are its components, not required in this specific order neither mandatory, even if I found them useful and quite efficient as listed below.

People And Their Contexts
As said earlier, understanding the environment you’re in, its components and interactions, is key to understand how problems arise/evolve, how people experience them, how they talk about them. You also want to capture their aspirations, their goals, hopes, and meaning of what they’re doing. Make it visible, so that everyone shares that overview and understanding.
Vision And Strategy
From a shared understanding of this “current state”, accompany the people in drawing their vision of a desirable future, for them and their environments. A vision is not fixed and rigid. It should contain uncertainty, unclear components, and room for better definition. And it should evolve over time. It’s an ever going work in progress.
A vision gives you a direction on the map, but not how to go there. Devise strategies grounded in reality and shows possible paths. You should have a “portfolio of strategies” that you can test and maybe follow in parallel. But such as your vision, your strategies should evolve as your environment reacts and “mutates” due to your actions — remember that you’re part of the system.
Also, ethical considerations should happen here, as you want to explore the potentialities of your actions. What could happen if I’m wrong about this? Would I be okay with this if I was the one impacted? etc.
Goals And Metrics
Your strategies should help devise clear goals. Metrics must inform on your progress toward these goals. This is generally difficult to do well, but it can be really detrimental if done wrong: mind the focusing effect. Yet, useless, meaningless and often unnecessary metrics are legion in large organizations.
Good metrics are based upon your goals and should help you assess their credence: in other words, aim to measure how wrong they are.
On a broader aspect, monitor the effects and changes in the system. Look-out for emergent behaviors —also called “weak signals”.
Tools And Processes
These goals inform on which tools, methods, and processes to use. It's really important, so let me repeat this: tools, processes, and methods should be considered in regard to the goals you're trying to achieve. Not the other way around.
Shifting The Burden Of Understanding
As designers, we should learn about as many and various things as we can. But Designers should not hold a “sacred position” of lone geniuses. Instead, we should remain in a position of “humble & curious learners” as long as possible. Our role should be more one of facilitators that one of genius creators.
“Everyone Is A Designer, You’re A Facilitator.”
It is important to realize that design doesn’t happen in a vacuum and that we don’t “own the design”. Working in large organizations means working with tons of different people which make tons of decisions every day that impact the design and the experience of what an organization brings to the world, whatever it is. In a sense, they are designers as much as we are.
This perspective invites us to shift the burden of understanding, to be more humble, more empathic, and actively listening to others. You cannot possibly be involved in each decision ever made. You cannot even control every aspect of an organization that brings to life things as they are. But you can act as an enabler to ensure that people act as designers, share a common understanding of the problems, the people, their contexts, and ultimately trust them to make informed decisions about it.
Critical Thinking
Being a humble & curious learner means asking pretty good & respectful questions. And this is what critical thinking & skepticism are about. But, it is often seen as a “skill”. To me, it is more a set of tools and a mindset to ask better questions –key to properly discover problems and deeply understand them.

Bayesian Thinking
As explained, beliefs are everywhere. And as much as you need to understand the systems you are in, you need to acknowledge the biases people will start from working with. Yes, the illusion of starting from a “blank page” is probably one of the most detrimental designer’s false-belief.
Everyone hold beliefs, either it is about the problem, the solution, the outcomes, etc.
Bayesian thinking, roughly speaking, allows people to assess and give certain credence to the beliefs they hold about a topic, turn them into hypotheses, find actual evidence, and reassess the beliefs in the lights of the evidence.

Interestingly, the Bayesian approach does not refute beliefs but instead weights them on a scale of likelihood (credence), taking into account prior weight in the result, making it an inclusive approach.
Evidence-Based Design. Because Faith Isn't Reliable Method.
Our tools should help us toward our goals. So I created a set of canvases to help me.

Formulating good –testable and measurable– hypotheses from beliefs are really hard but fun to practice. People can gain agency and empowerment from such practices, leading to better shared-understanding, better decision-making, and eventually better design as a whole.
Thanks for reading!

References
1. Original slides
2. 'Haute cuisine' innovation research



3. Systems Thinking




4. Critical Thinking




5. Bayesian Thinking






6. Miscellaneous
- Critical Thinking: Concepts and Tools – The Foundation for Critical Thinking
- Ethics and Morality – Psychology Today
- Moral Philosophy – Ethics Unwrapped | The University of Texas at Austin
- Moral Philosophy – ScienceDirect
- Systems Theory – Wikipedia
- Chaos Theory – Wikipedia
- Complex Adaptive Systems (CAS) – Wikipedia
- System Innovation Academy
- An Introduction to Complex Systems Science and its Applications – MIT
- The application of systems thinking in health: why use systems thinking? – Health Research Policy and Systems, BioMedCentral (BMC)
- Credence – using subjective probabilities to express belief strengths
- Cassie Robinson on Medium
- In Search of Leverage – Exploring the most powerful climate actions
- Humantific – Helping People Make Sense of Complexity and CoCreate Positive Change
Discussion