A Systems View of Innovation

How might we describe innovation as a system as apposed to a process? Thinking in systems about innovation is not new, innovation hubs and ideas around biomimicry take a systems view.

In a systems view of innovation events happen simultaneously, and for the most part uncoordinated. A systems view of innovation ups the odds for chance and luck to play its part in the emergence of new ideas and solutions. Thinkers like Nassim Taleb and Daniel Kahneman ascribe more agency to luck and randomness than to individual decision making and skill in stories of success. A healthy innovation system needs to spark randomness, building on a solid skills bedrock, to increase the likelihood of lucky events.

A first stab at an innovation systems model could look something like this. It all hinges around a sense of opportunity that attracts people. Next, buildings provide physical space for people to interact. But more importantly, buildings and location give context that inspire people to take action. People bring skills and new opportunities. All these components need the right proximity to each other – if the friction becomes too great the system will fail. If the proximity is optimal it becomes a virtuous cycle.

We need new skeletons

New systems can be conceptualised as new skeletons, with the aim of attracting new cells to eventually grow new muscles. Our current skeletons are outmoded remnants from the industrial age. Our aim should not be to change them, we need to create new ones while slowly disinvesting in the old ones. The purpose of innovation hubs is to create new skeletons. 1

A systems view of innovation.

In this model no single entity can own innovation, players choose where to participate and what to contribute without certainty of outcome or payback.

Organisations eager to join the innovation game need to make radical culture and mental model shifts, because they’ll need to become more open and outward focused. For big companies this means more risk. But without risk there can be no chance or luck, and no innovation.

  1. The skeleton analogy is from a workshop I attended by Elizabeth Dostal

Thinking about emotions and relationships when working in big teams

The working title for this piece was Working with difficult stakeholders. But I changed my mind, for three reasons: Firstly, I once referred to a stakeholder as ‘difficult’, but a colleague on the same project had a different experience. Secondly, when asked in a job interview how I’d deal with difficult stakeholders I realised that up to that point I hadn’t really given it much thought. And thirdly, ‘difficult stakeholders’ has a faceless ring to it and it sets the scene for othering.

On the back of a recent project I made a list to help me next time I work with a big group that hold divergent and often apposing views:

  1. Draw a map of all the people on the project.
  2. Make the interrelationships between them visible.
  3. Identify everyone that will be impacted positively.
  4. Identify everyone who will be impacted negatively.
  5. Identify what people need form the project, and understand why.
  6. Ask yourself: What am I not seeing?
  7. Start with your own emotions. Look at your feelings and take ownership of them.
  8. Acknowledge that change is emotional for people about to gain, or loose something.
  9. Back up observations and recommendations with evidence.
  10. Talk is work – be on the lookout for opportunities to start conversations.

Another way of looking at it is that the interrelationships between people on a project is the project. A project will fail to reach its potential if working effectively with others is not seen as a key deliverable.

Intro to systems thinking for designers

The film Mindwalk and the book The Turning Point by Fritjof Capra switched me onto systems thinking. When I studied it formally I was surprised by the overlaps between the theoretical concepts of systems thinking and the practical methods that I was using in my work as a user experience designer. When a colleague asked me to explain systems thinking I realised that I didn’t have a simple explanation. Here are a few systems thinking concepts (as I understand them) that I find helpful in my design work.


What is the difference between a human rights system and a transportation system? When thinking about a transportation system it is easy to name what is part of the system and what is not. When thinking about a human rights system the boundary of the system is not that clear. But what is similar for both systems is that we make decisions about what to include and what to exclude in our understanding of the system. These are called boundary decisions, it is a key concept in systems thinking.

Systems are models

Systems only come into view when we make boundary decisions (implying personal responsibility), they do not exist ‘readymade’ out there. We make decisions based on a range of emotions, values, and prejudices shaped by our individual backgrounds and contexts, hence no system can be thought of as objective. This explains why there are more than one ‘system’ for understanding and improving climate change and other wicked problems. Systems are models created by people to understand situations better, to either exploit or improve them.

Systems thinking is design

Systems thinking is a method of arranging named phenomena to learn, understand, and plan action to improve something – it’s an opportunity to design better systems (models).

A response to the question: What is Design? could be:

“Oh, so design isn’t about this pixels thing. It’s about systems thinking.” I’m a systems thinker. “Oh, so it isn’t just about the appearance.”

The quote is from an interview with John Maeda on why senior executives must understand design.

Testing systems

There are many schools of thought in systems thinking. Understanding and experimenting with systems thinking is not easy, it’s the reason why it has failed to get traction outside academia. I do think that systems thinking provides useful conceptual frameworks for designers. Maybe systems thinking should take its place in the Design toolbox, alongside design thinking and user centred design – methods that are successful because they make it easy to experiment with, and test your models (systems) in the real world.

For a short introduction to systems thinking read the How-To Guide by Daniel Kim.

Google Ventures Design Sprint

We ran our first Google Ventures design sprint recently. It’s a 5 day sprint where we work together with our clients to shortcut:

the usual endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, teams get great data from a prototype.

Design Sprints are versatile, they can be used to explore almost any idea:

the first version of new mobile apps, to develop new features for existing products with millions of users, to define marketing strategies, to design reports for medical tests, to create the personality of a hotel delivery robot – the list goes on.

The Process

Sketching ideas on Tuesday

Choosing the best ideas and refining them on Wednesday

What we learnt

  • It’s good for us because we get to put our skillset to the test in one week. From creating personas and journey maps to prototyping and usability testing, and we’re doing it with our clients joining in. It clears the cobwebs and makes us think on our feet again.
  • It’s good for clients because they get to test a concept in five days. Investing in a one week sprint is a win-win for clients because bad ideas can be discarded or changed, and good ideas can be validated and iterated faster before writing code.
  • Committing to strict timeboxing improves productivity. By the end of the week we were in agreement that we had achieved much more than we usually do.
  • It’s OK to admit that you don’t know the answer. Provided that you keep exploring ideas that you can test. And being in a group that admits to vulnerability builds trust which is essential for teams that do good work.

Making a prototype on Thursday

User testing on Friday

  • Client participation is key. Although we could have run the sprint without clients, the consequence would have been designs based on our assumptions and incomplete information, which means we lose the ability to move fast in the ideation phase.
  • Don’t try to do everything. Knowing which parts of the idea to test on Friday will help prioritise where to focus the ideation phase. And it protects the group from being overwhelmed by the enormity of the task at hand.
  • Clients have good ideas. And they sketch them out much better than they think.
  • It sets up a project with the right focus. By testing with customers and iterating early on, the principle of continuous improvement is built into the process. The distinction between evidence and assumption is understood by everyone, and the team is less likely to implement designs that have not been tested with customers.
  • No need for lengthy documents. Stakeholders are part of the exploration team and contribute to all design decisions. And by co-creating the prototype and the test plan they know what is going on and why.
  • Don’t shortcut the process. If ideas flow on Day 2 don’t be tempted to jump ahead and start Day 3, allow ideas to incubate overnight and start again the next morning.
  • It builds design stamina. The process is both exhausting and exhilarating, because you have to continually make decisions and justify why you are making them. Developing this skill makes everyone better designers.

After the sprint: analysing the test results before planning what to do next

There is nothing complicated about running a design sprint. So why aren’t we doing it more often? Maybe because doing the simple things are the hardest things to do. Try it out, chances are you may not want to go back to the old way of working. We don’t.

Icons from the Noun Project: Márcio Duarte, Konrad Michalik, Takao Umehara, Ainsley Wagoner, DTE MEDIA.