What is Design Thinking?
According to the Interaction Design Foundation Design Thinking is:
…a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test. It is most useful to tackle ill-defined or unknown problems and involves five phases: Empathise, Define, Ideate, Prototype and Test.
(Thanks to the Interaction Design Foundation for the info.) The five steps are iterative, meaning you don’t stop at 5 but you go back to 1 and repeat:
- Stage 1: Empathize—Research Users’ Needs
- Stage 2: Define—State Users’ Needs and Problems
- Stage 3: Ideate—Challenge Assumptions and Create Ideas
- Stage 4: Prototype—Start to Create Solutions
- Stage 5: Test—Try the Solutions Out
Feel free to read the above links to take a deep dive. What I want to talk about now is my experience using this system. The two keys to using it successfully are 1. Company buy-in and 2. Co-worker buy-in. With these DT can work wonders! Without, it fizzles out.
Company Buy-In
A couple of years ago I got to experience a “Digital Transformation” which was the company changing Agile approaches and incorporating Design Thinking. This effort came from our leadership team and so it was widely adopted. This was the crucial first step and is part of the UX Culture I talk about. It’s much faster, and easier, to implement any initiative with the buy in from the C-suite execs.
With this buy in, and overall acceptance on the part of the rest of the team, we started using DT. I was on the Platform work stream as part of the Architecture Team and I got to work seeing where I could apply DT. API Design First methodology was one of the obvious initiatives where we could really dig in to DT. With a user persona and a journey, an API can be designed and it’s ultimately more useful – stripping out any unnecessary information.
Dev team buy-in
It was very gratifying to have a teammate on the Architecture team say to me, “I wish we had been doing DT a lot sooner!”
We started to work ahead of the backlog and the road map, but we were quite busy at first. You tend to move slower when you are learning as you go, but after a while everyone started to understand it, and see their role in it. Not only that, but everyone started thinking this way from the start.
A key part of UX Culture is having it ingrained in every step of the development process. After a while, everyone knew what was expected at these workshops, and brought their particular expertise. We could meet and make decisions even if some key stakeholders were there, simply because anyone could watch the recording later and read the Miro board to observe the decisions and info.
Co-worker buy-in
I’ve already touched on this, but to repeat, everyone got in the groove of DT and as everyone got more experienced we could then get more accomplished.
It wasn’t perfect – some of our group wondered what was the point when they had other deliverables they had to create that were separate to DT; well, that is understandable, and it’s also a signal to us facilitators to say why not bring that external process in; how can we solve it during the workshop? Why is it being done separately?
DT can be used on design challenges small and large
Another concern is can you use DT on smaller questions that need group input? Of course! You only have to go as far as you need to through the steps which to me look a lot like this:
Design Thinking steps
- What is the problem to solve? (This in itself is half the battle!)
- Figure out the user persona/s
- Figure out the user journey/s
- Start verifying that journey and then start prototyping while removing any information that is not relevant to solving for the user journey
- Put prototypes in front of SME’s, C-Suite execs, and stakeholders to confirm alignment
- Test, test, test
Sometimes we would brainstorm internally rather than meeting with everyone, usually around systemising our design processes which was something not everyone cared about, mainly the Design and Development Teams.
Some of the questions covered in these smaller sessions:
DT questions covered in smaller sessions
- Is this design system component working properly?
- Are our notifications worded in a way that’s easy to understand?
- Are we following our design system?
- How do we build APIs and can that be improved?
- As an Architecture Team how do we analyse and move forward with long term Roadmap changes?
You can go as heavy or as light as you want with DT. In some cases you will create new DT artifacts to grow with your collaboration style. One thing I came up with for API design discussions was a converation tracker; a row of names at the top as sticky notes, then track each persons comments as they talk; this was easier than trying to track these comments in the User Journey board, and we could go back and do affinity mapping of those comments later to find common themes.
Design Thinking sets a solid and flexible framework for discussions and you can go as deep or as shallow as you need to in order to solve problems, large or small. I’ve had a lot of success with it, what’s your experience with it?