The word 'design' - it’s such a crowd puller. You attend a
session titled 'design thinking' with the expectation of getting close to a breakthrough idea.
Or simply for serendipity. And Mukesh Gupta didn’t disappoint, on both counts. And it turns out that I was not the only one who thought the session was really insightful. It's got a five star rating on the meetup.
Venue
The venue itself was a ‘beehive’, even at 7 in the evening. There
was a lot of activity. BHive Workspaces is an incubator for entrepreneurs who need office
space and everything else that comes with it (including coffee!), without actually having to make a
capital investment. The idea of renting out cubicles/office space on a small
scale isn’t new. But there is a certain excitement and energy about the place that you couldn't possibly miss. I came to know about the event when a friend shared information about the meetup on a social network.
A Plug
Before the presentation started, there were a couple of 'part-time' entrepreneurs looking to test and solicit feedback for their app called ShareCard. The mobile app is designed to help you connect with people with similar interests during events/conferences. It’s got a simple interface and uses Linkedin credentials for authentication. What’s the idea behind the app? It’s to help you identify and connect with people without going through all that trial and error. And of course, for all those OCD folks out there, that’s that much less hand sanitizer to use in between! So the app uses bluetooth to connect to other folks who have also downloaded the app and are on the 'lookout' to connect.Interesting stuff. Should be piloted in a larger event.
And finally - Design Thinking
Mukesh is Director - Customer Advocacy at
SAP, and has conducted several workshops on design thinking (among other topics). I loved the way he answered questions - pretty convincingly and passionately. He came across as being very well read, and had the articulation necessary to be that really engaging story teller. He certainly makes the list of speakers I'd listen to even if I didn't know what they were going to talk about.
The session started with a round of introductions. Almost everyone attending seemed to have either been involved in a start-up or were seriously thinking about it. Or were somewhere in between. There was even one guy who was serving his notice period and another who had quit corporate life a couple of days back.
The session started with a round of introductions. Almost everyone attending seemed to have either been involved in a start-up or were seriously thinking about it. Or were somewhere in between. There was even one guy who was serving his notice period and another who had quit corporate life a couple of days back.
To help us understand the concept, he started with a
problem. Bangalore’s problem - garbage. He described the issue; there’s a pile
of garbage outside his house and he asked the audience what to do. Some of the
creative answers included taking pictures of offenders and posting large cut-outs
to embarrass them! There was another one that introduced gamification into the
equation. Make it a competition because sometimes the pain of loss is greater than the pleasure of gain! And then there was the idea of fighting the notion of garbage itself. Make people see the value of recycling, reusing and reducing. And that’s when Mukesh brought us back to the real problem. He asked us what we were trying to do. Everyone had jumped right into providing solutions even before first understanding the problem.
It was like a smack on the back of the head!
So the first step to design thinking is not to solve but to
understand the problem. You can understand it by at least two ways. Observation and interviews.
He said we should ask questions like ' Why does it happen, how does it happen, when does it
happen, who are the folks impacted by it… etc. to gather insight into the
problem. Insight. An excellent definition for insight was when someone has an ‘ah
ha’ moment when trying to understand the problem. So you watch the problem happening and you ask questions to everyone involved.
Point of View: The next stage is to identify a point of
view. From whose perspective are you trying to solve the problem? This is a
very important phase to the problem. Actually the most important. Your insights and solutions will vary
significantly depending on whose POV you take. This was explained very
beautifully with the garbage example. If you look at it from the house owners
point of view (outside whose house the garbage is dumped), the problem is very
different from the person who is dumping the garbage. Similarly, the government
agency who not only has to pick it up, but also needs to dispose it off safely.
So you are basically creating a persona. Yeah, familiar territory :). Like explained above,
the needs of each persona are also different.
So in short, POV = insight + persona + need.
Ideation: Once a POV has been established, it’s time to
ideate. How have others solved the same problem? How does industry handle it?
We simply make a brain dump or use any of the brainstorming methods to list out whatever we can.
Get a list of things you can do. Don’t categorize or rate any idea just yet. Use triggers to find different routes. Some people even use a dictionary to randomly choose a word and then by association, try and thrash out a few ideas. Once you have a bunch of ideas, toss a coin to select the best one. Kidding :) It's going to be a tough task. How do you make sure you are selecting a great idea and not just a good idea? How do you select a breakthrough idea as opposed to an interesting one? One way is to go against your intuition and select an idea that seems to be difficult. The idea you select also depends on the problem you are trying to solve. Don't select the first idea that you get. Mukesh drew a graph that plotted ideas against time. The graph showed how ideas started slowly, then peaked and then after a time, starts to drop as ideas start to dry up and then after a little struggle, starts to build momentum again. It's the ideas in the second peak that usually lead to breakthroughs. Usually. Sometimes it just takes an apple :)
When you design anything, you either design it for yourself or for a very particular set of people. As you start to broaden your criteria, you end up trying to please everyone, and that's not had very pleasant endings. So how do you ensure success? Mukesh talked about a thumb rule. Try to build a product that satisfies 5 percent of your early adopters.
He also suggested that brainstorming should be done while on one's feet if you want better ideas. It's got something to do with the fact that for creative solutions, most people look up/throw their head back to 'look' for inspiration. One tries to reach the creative part of the brain. You use a divergent method for creative solutions where you create many options and choose and expand in an iterative manner. However, when you are seated, you tend to put your head down. The 'head down' or convergent approach is also useful sometimes, where you are reaching out to the other side of the brain. Which approach you use really depends on the problem. We continued with the garbage problem and we took up the idea of making garbage valuable. The audience was then told to build the idea. Any idea that took the value proposition forward was accepted and those that didn't, were ignored.
Prototype: The science behind why a prototype brings an idea to life is what it does to the five senses. The moment someone can touch, see, hear your idea, you've already done most of the selling, without the need to say a lot. You've brought something to life. It's alive! Your prototype doesn't have to be anywhere near perfect. In fact, it shouldn't. The primary purpose of your prototype should be to solicit feedback. And this prototype-feedback iteration is done at least a couple of times, till you are confident to make a Beta launch.
Feedback: The most important aspect of seeking feedback is that you should never use the opportunity to defend your design. It's extremely difficult. The ShareCard folks were seeking feedback for their app and one could see the difficulty in keeping quiet and listening without saying anything in defense of their baby. Listen carefully to everything your user is saying. And also remember to listen/hear what they don't say about your product. What they don't say usually tells you more. Videotaping the feedback is highly recommended so that you can revisit it again to garner your 'insight'.
Avoid using questionnaires, especially those that narrow down observations to what you think their answers should be. Your survey essentially should have 3 parts. What they like, what they wish for and then Questions/Comments.
The most innovative solutions lay at the intersection of desirability (appeals to the emotions), Viability (can it be done) and Feasibility.
Design thinking is about using a mindset (that involves people) and a toolset (that involves the process discussed above) in a suitable environment.
When you design anything, you either design it for yourself or for a very particular set of people. As you start to broaden your criteria, you end up trying to please everyone, and that's not had very pleasant endings. So how do you ensure success? Mukesh talked about a thumb rule. Try to build a product that satisfies 5 percent of your early adopters.
He also suggested that brainstorming should be done while on one's feet if you want better ideas. It's got something to do with the fact that for creative solutions, most people look up/throw their head back to 'look' for inspiration. One tries to reach the creative part of the brain. You use a divergent method for creative solutions where you create many options and choose and expand in an iterative manner. However, when you are seated, you tend to put your head down. The 'head down' or convergent approach is also useful sometimes, where you are reaching out to the other side of the brain. Which approach you use really depends on the problem. We continued with the garbage problem and we took up the idea of making garbage valuable. The audience was then told to build the idea. Any idea that took the value proposition forward was accepted and those that didn't, were ignored.
Prototype: The science behind why a prototype brings an idea to life is what it does to the five senses. The moment someone can touch, see, hear your idea, you've already done most of the selling, without the need to say a lot. You've brought something to life. It's alive! Your prototype doesn't have to be anywhere near perfect. In fact, it shouldn't. The primary purpose of your prototype should be to solicit feedback. And this prototype-feedback iteration is done at least a couple of times, till you are confident to make a Beta launch.
Feedback: The most important aspect of seeking feedback is that you should never use the opportunity to defend your design. It's extremely difficult. The ShareCard folks were seeking feedback for their app and one could see the difficulty in keeping quiet and listening without saying anything in defense of their baby. Listen carefully to everything your user is saying. And also remember to listen/hear what they don't say about your product. What they don't say usually tells you more. Videotaping the feedback is highly recommended so that you can revisit it again to garner your 'insight'.
Avoid using questionnaires, especially those that narrow down observations to what you think their answers should be. Your survey essentially should have 3 parts. What they like, what they wish for and then Questions/Comments.
The most innovative solutions lay at the intersection of desirability (appeals to the emotions), Viability (can it be done) and Feasibility.
Design thinking is about using a mindset (that involves people) and a toolset (that involves the process discussed above) in a suitable environment.
When to use design thinking
- Ambiguous situations
- Issues where there are multiple possibilities
- Complex problems
When not to use design thinking
- When the objective is clear.
- When you already know what needs to be done. You just do it.
- When the solution is simple and your need is to use the most obvious fix
Another Formula
Your problem statement could use the following structure
How might we __(state issue)__ for __(whom/POV)__.
The Deck
He probably took lots of help from a creative 4 year old to get these slides together:)
And that garbage problem? Here's a spark that seems to be turning into wild fire.
And that garbage problem? Here's a spark that seems to be turning into wild fire.
Must read books:
- Predictably Irrational by Dan Ariely
- Thinking Fast and Slow by Daniel Kahneman
