Comments on: What is Design Thinking? https://www.theagileelephant.com/what-is-design-thinking/ innovation | digital transformation | value creation | (r)evoloution Fri, 23 Feb 2018 00:04:51 +0000 hourly 1 https://wordpress.org/?v=6.9.1 By: Jon Reed https://www.theagileelephant.com/what-is-design-thinking/#comment-19480 Fri, 23 Feb 2018 00:04:51 +0000 http://www.theagileelephant.com/?p=3536#comment-19480 Hi David as promised my comment. This is a great reference piece on design thinking and not just for those new to it. “You don’t have to be a designer to think like one” is the essence of it.

I do have a couple of caveats. These don’t apply to the hackathon context. For hackathons, I like design thinking because it usually pulls in different sensibilities besides coding and gets coders thinking towards the big picture. The only downside on the hackathon use of design thinking is that being user centric does require some research legwork and you can’t always get that right in a weekend. But – you can at least learn some of the principles of it.

But for those reading this looking to use design thinking beyond a hackathon context, my issues with design thinking are as follows:

– many of the principles of working on prototypes alongside customers have existed long before design thinking became a thing. Some folks just intuitively seem to understand this type of collaborative process.

– too often “design thinking” is used as a label to validate a decision or process that actually wasn’t very inclusive at all.

IMO to do design thinking right requires two variables in addition to the methods you’ve laid out:

1. Involvement of external stakeholders, from customers to partners to influencers. Sometimes you can get over that with extensive user research but usually, when design thinking derails, it’s because there isn’t a diverse enough group of interested parties and a climate where they can openly participate.

2. Use of design thinking early in the process with a willingness to question EVERY business model assumption if need be. Too often, “design thinking” is brought in too late when certain assumptions have already been made. E.g. “Let’s design a new mobile app” versus “how do we get closer to our customers.”

Bringing in “design thinking” too late in the process when parameters have already been set can be disempowering to the participants and then it feels much more like a bland rubber stamp than an energizing session.

I think the reason these two mistakes are made is because incorporating them takes effort and often requires a change in decision making behavior. The advantage is you can emerge from this type of approach with real buy-in if the right folks are included. I

I think design thinking is only powerful if these two factors are in place. Otherwise it’s just another buzzword to take or leave.

Good luck at the hackathon!!!

– Jon

]]>