IBM’s Enterprise Design Thinking
I was intrigued by the idea of scaling design thinking within an organisation. We’ve all been there — stakeholders want a solution and they want it now! Design thinking is a core process for any designer but it can be super tricky to find a balance because the design process can be seen as slowing things down. Granted, there are ways around it — including stakeholders in the process, working in the open and providing the right level of detail at the right time, etc but I curious about how IBM got around it. Turns out, I like it!
Let’s go through the framework and I’ll tell you a bit about my reflections along the way. This is just my interpretation and could be completely off the mark but I enjoyed taking the practitioner course.
The Framework
The framework is based around a loop of continuous observation, reflection and making, rather than the traditional double-diamond. It almost seems like a bit of Design Thinking + a bit of Agile = constant form of iteration at scale.
Overall, I could see many similarities with the traditional model with some new opportunities that came thinking about them differently. IBM’s Enterprise Design Thinking is based on a few principles and a common understanding which is why I think arguably Design Thinking leaves a lot of room for interpretation. In my experience, many organisations seem to have a different definition, teaching and practice of Design Thinking. What the framework does is have a sense of constant iteration.
Observe — IBM speaks of being immersed in observing people and empathising with them, understanding their context, uncovering needs and hearing honest feedback.
“This understanding isn’t gained by sitting at our desks and conference tables. It’s gained by getting out of the building and meeting our users where they are”.
It’s about more than looking at existing pains and solving for them but looking for behaviour you can’t explain — digging for reasons why and solving for those types of insights. When summed up like that, it doesn’t seem very different to Empathise phase, there is however an active space for reflection which is means we share observations and findings giving team members the space to work openly.
Reflect — Throughout the project, you learn new information and this could be through observation at the start or after you’ve made something. IBM mentions how reflecting as a team brings the team together and aligns them much as Agile ceremonies do. Reflection is where the team get to know each other, share what they’re learning, plan ahead or make decisions and these don’t seem to be time-bound the way Agile suggests. It happens when the team is ready and could happen quicker than a 2-week cycle.
Make — As a Service Designer, I know all about analysis paralysis and depending on how risk-averse the organisation is, this can take it’s a toll on the team. Agile is all about failing fast and this felt familiar when IBM mentioned that “the earlier you make, the earlier you learn”. This is the fun part of the loop — for me anyway. This is where the team get to explore new opportunities, prototype something and then reflect on it and observe whether it solves real problems for real users.
Where it wins my vote — it makes the process feel like a team sport and I am all for the team. People who are aligned with the space to learn and iterate as they go are happier and create better outcomes for their users.
There’s the opportunity for things to gain momentum — Organisations can be large unwieldy spaces and it takes ages, often getting stuck in discovery/empathy and rarely moving past into the next phase.
All for the user, moving quicker and adapting to what we’re seeing as we’re seeing it.
If you’re keen to give it a go, you can find out more here
