Don’t look stupid like I did when this buzzword inevitably comes up in your next meeting
It’s the latest buzz. I hear it all the time as the latest panacea for all work related problems. “Why don’t you apply design thinking to this?” comes up way too often. Not so long ago, the equivalent would have been: “Project delay? Why not take an agile approach instead?”
What the heck is it? How do you do it? And why is it that when you perform YouTube or Slideshare searches on it, you get so many different variations of it that talk about it but rarely explain what it is?! If you’re tasked as a facilitator to run such a session it can become quite daunting.
I am not an expert in Design Thinking (sure, you can stop reading now). But I have gone through it enough to realize that it is yet another repackaging of an old concept in a modern context (much like how sensors that capture data have been around for years yet have a modern context with IoT — I know, I know, there are differences).
So what is Design Thinking really? It’s a process to come up with a solution to a problem with a given persona in mind rather than other approaches which may be to come up with a solution first and then find a problem to apply it to. The challenge is that everyone seems to have their own variation of it — and I’m not going to help here as I’m going to include my own. However, what I hope to do is to cover a broader set of pieces of the processes so you can decide what to include and what not to.
Typically, the Design Thinking process goes something like this:
- Inspire: Prior to a session, it really helps to give some examples of innovative solution within your problem space to get warmed-up. There are tonnes of examples on YouTube.
- Determine your persona(s): Design Thinking is often labeled as an ‘outward-in’ approach where the focus is on letting the customer needs guide your offerings/solution (alternative inward-out approach is where you leverage your organization strengths to define a given solution). Hence, the first step is define that persona, e.g. lets take an example of ’an IT manager working in the retail industry’
- Deep dive into your persona: This is where Design Thinking defers from traditional approaches as here you define granular details of your persona. You aim to identify details such as what does the persona believe in, what do they do in their spare time, what do they purchase with their disposable income (in one session I had, my team went down to the details of determining what podcasts our persona listened to — yes you can get carried away). From the example in #2, the following could be the deep dive of our IT manager: a tech savvy 35 year old; is very much overworked; has a demanding boss; has a colleagues who are competing for a promotion; reads lifehacker blog; and so on..
- Identify SWOT (Strengths, Weaknesses, Opportunities, Threats): Some Design Thinking sessions I’ve partaken in include this, some don’t. It’s just as the description highlights and is a variation to again deep dive in to your person. In some ways though, it is also a good way to warm-up to the brainstorming steps as it helps you determine what to anchor in on. So building on our example e.g. again our IT manager: Strength — has an ability to explain complex tasks in simple terms; Weaknesses — struggles to get enough visibility; Opportunity — has a strong network outside of his work; Threats — his colleagues competing for a promotion
- Define problem(s): Here is where you clearly state what problem that you’re looking to solve from your detailed persona. One crucial step here is to ensure that you are familiar enough to the persona to define the problem. If not, it is highly advisable to validate this with someone that does. E.g. our IT manager struggles to maintain and engage his network connections which he relies on heavily for things like sharing problems, comparing solutions, identifying good vendors.
- Brainstorm: The latest buzzword for this is ‘ideation’. It is just brainstorming in my mind. Regardless of label, the required task is to shamelessly generate ideas for the problem. If you’re doing this in a group, it is highly advisable to perform brain writing and not brain storming (i.e. generate ideas in isolation without collaboration at the beginning to avoid anchoring the first idea from others which may influence subsequent ideas). I’ve found it helps to ask the idea generators to come up with at least 3 ideas that are totally out there and would be near impossible to implement. This helps to at least force the creative process in a different direction which can help anchor the thought process to come up with a more achievable idea after the crazy idea. Another variation is to have a list of keywords handy and use them to spark ideas.
- Objectively review: This is one of the most difficult steps. You need to shortlist the best ideas. The trouble is, believe it or not, you will likely have fallen in love with your own ideas no matter how crazy they are. Hence, it is best to objectively review each of your team mates ideas instead of your own to avoid biases.
- Test solutions on paper: This is maybe done outside of the design thinking session or as part of the session itself. The approach is to come up with a paper-based Minimum Viable Product and then test it out (or simulate testing it) with your persona to get sufficient feedback. Once you get your feedback, loop back to step #5 above.
- Communicate: This is a crucial step that is often missed! The reality is that the Design Thinking process happens with a small team and often a solution is derived which requires a broader set of stakeholder or teams to help implement. Hence, it is crucial to spend time to communicate your persona, problem, and solution succinctly. In one session I was in, we ended up creating a short video which explained the narrative beautifully and everyone got it within minutes rather than listen to a 30 minute presentation.
That’s it. Depending on the scope, you can run these sessions for as short as 3 hours all the way to a full day.
So what is it about this process that helps generate those new ideas? Why is this so effective? And why is this different to how we generally solve problems?
One key difference is the fact that you’re almost designing a solution for one persona and their specific problem rather than coming up with a hypothetical solution for the masses.
Although this may feel that the solution will be too specific, but in fact, adding this constraint helps to design a solution that not only has a higher chance of succeeding but ironically ends up being relevant for the masses. Part of the reason may well be due to the solutions being transferable across demographics, part of it may be that the solution is just for that demographic, but I think a great deal is due to the solution being defined for someone who will naturally become an early adopter. They will have a higher success of getting value out of your product as it is specifically designed for them. This successful initial customer/set of customers can then be leverage or will voluntarily promote the solution to others. Designing for someone will lead to at least one person happy, designing for everyone will likely make no one happy.
So now that you know what it is, give it a shot. It may seem rather unimpressive, but you have to go through a few sessions to see the value. If you’re going to be a facilitator, it can become rather daunting. All I can say is: Trust the Process. Prior to running Design Thinking session you may want to consider to run a compressed trial session with a set of confidants to build up confidence and also to get the logistics right.
It certainly is a useful tool to solve problems, but make up your own mind to see if it is a fit for your situation.
Thanks for reading! I’d really appreciate it if you recommend this post (by clicking the ‘Recommend’ button below) so other people can find it. You can also find me on Twitter