In my last blog I chronicled the roadblock we faced while building our app. A well-structured design thinking approach helped us in freezing the features, UI, UX and backend of the first version of Augment app. Reuven Cohen rightly point out in this article that, “design thinking” is a a human-centered, prototype-driven process for innovation that can be applied to product, service, and business design. Companies and especially startups need to have a strong foundation of innovation, without which they are truly headed towards a roadblock sooner or later. Design thinking is an approach which will build ‘innovation’ right inside the DNA of the product.
I extend my heartfelt thanks to Soaib and Asmita from BOLD Ventures for helping us in structuring our thoughts.
Key takeaways from design thinking session that helped us:
1. Involve the team
Everyone can bring a fresh perspective irrespective of who he/ she is. We have found key insights coming for team members which were never thought about before. Founders think about the product day-in and day-out, which might saturate their thoughts. A fresher perspective from the team can lead to out-of-the-box thinking and leads to a creative approach to solve the problem.
2. Outline the flow of discussion
To begin with, have some structure or format to the sessions. For example, allot the first 2 hours to freeze the problem statement, second 2 hours session to propose solutions, etc. The more specific this structure is, the better the chances of a fruitful session.
3. Avoid ‘Because I said so'
Healthy debates are good but more often than not debates turn into a display of opinions and biases which are far from facts. As a result, a lot of productive time would be wasted in beating around the bush. How to avoid debates? That brings me to my next point.
4. Have a moderator
Have someone external or from the team who acts as a moderator. Ideally the moderator should be someone who is neutral in terms of perspective towards the product, he should contribute less to the discussion and be more of an observer. But then again, finding such a moderator is difficult in every day product development reality. If you have a moderator from within the team, he could participate but he should be the one who puts his foot down and stop the team from running around in circles.
5. Find things that you agree upon
Countering each others’ points is a negative way of trying to reach conclusions. Instead, try and figure out those common things that you agree upon. Let everyone note down the points they want to put forward regarding a specific ‘point of discussion‘, put all of them on the white-board and then ask the team to point out the top three points in the list he/she agrees upon. We see a pattern emerging, a pattern of most accepted aspects. That is what we need to come to conclusions and not discarding others’ opinions. And if the team couldn’t come to any visible pattern of acceptance, I guess the team needs a hug and a vacation. 😃 Just saying.
6. Draw stuff out
Now, put down the thoughts and points on paper prototypes, wire-frames or whatever is the quickest possibility. Make alternate versions for the things that you disagreed upon. Most of the stuff which triggered disagreement would be sorted out by visual representations. As visual representation eliminates the aspects of imagination and thereby a level of personal bias that we had while we disagreed. Still no good? Talk to users.
7. User knows it all
Talking to users with something to show and having their feedback on the same is invaluable. Speak with enough number of your probable user profiles and they will tell you what you need to know, validate or invalidate assumptions and so on. Here is a word of warning, if you try to explain the concept to the user without something to show, more often than not you will have responses which are far from what you need to know. I’ve done this mistake before and suffered, shit that was depressing. Also, speak with your target users and not just the first person you can find, just to have the most accurate feedback.
That did the trick for us but there are downsides to this approach. A core techie would sometimes not relate to this approach of thinking as this is counter intuitive to them. For example, my co-founder and CTO Madhu would typically start his thinking process from the product-tech aspect, which would be followed by a data-structure visualization, then framework definition and so on. With too much ‘Design Thinking‘ approach you might sometimes end up owing your friends coffee. Be aware!
For the curious ones, this online course on design thinking will be useful.