{"id":134,"date":"2015-05-18T21:57:13","date_gmt":"2015-05-18T13:57:13","guid":{"rendered":"http:\/\/yushengteo.com\/blog\/?p=134"},"modified":"2015-05-31T12:50:41","modified_gmt":"2015-05-31T04:50:41","slug":"3-mistakes-6-lessons-from-conducting-a-design-thinking-session","status":"publish","type":"post","link":"https:\/\/yushengteo.com\/blog\/3-mistakes-6-lessons-from-conducting-a-design-thinking-session\/","title":{"rendered":"3 Mistakes, 6 Lessons from Conducting a Design Thinking Session"},"content":{"rendered":"

\"design-thinking-mistakes-lessons-FI\"<\/p>\n

The Stanford d.school (a.k.a. Stanford Design School, for the less pretentious) is well known for its “design thinking” methodology in problem-solving. For those who aren’t lucky\u00a0enough to visit their campus, they’ve created a 90-minute, video-guided virtual crash course<\/a> that brings participants through the 5 stages of their design thinking process.\u00a0Last week, I conducted a session of the d.school’s\u00a0virtual course\u00a0for my colleagues in office.<\/p>\n

Here are the 3 mistakes that I made (rephrased as tips) and 6 lessons that I learnt in that 1.5-hour-long session.<\/p>\n

<\/p>\n

Wait, what’s this “design thinking” thing you’re\u00a0talking about? Is it, like, edible or something?<\/h2>\n

\"let-me-explain2\"<\/p>\n

Oh, right. Right. Well, it’s kinda awkward, because design<\/a> thinking<\/a> has<\/a> become<\/a> quite<\/a> a<\/a> buzzword<\/a>.<\/p>\n

But here’s what I think it is. It’s a specific approach to solving any given problem, with 2 factors that make it unique:<\/p>\n

    \n
  1. It’s highly focused on the user<\/strong>. An integral part of this approach is getting feedback from your users about your prototype or product.<\/li>\n
  2. It’s highly iterative<\/strong>. Another crucial aspect is the fact that you’ll tweak your product after getting user feedback, and get more feedback after tweaking, and then tweak your product again (and the cycle repeats).<\/li>\n<\/ol>\n

    Stanford’s Design Thinking Approach<\/h2>\n

    Stanford Design School’s own set of design thinking approach consists of 5 stages:<\/p>\n

      \n
    1. Empathise<\/strong> (a.k.a. understand your user and their problems)<\/li>\n
    2. Define<\/strong> (a.k.a. define your user’s problem)<\/li>\n
    3. Ideate<\/strong> (a.k.a. brainstorm as many ideas as possible)<\/li>\n
    4. Prototype<\/strong> (erm, this one’s pretty obvious)<\/li>\n
    5. Test<\/strong> (a.k.a. get feedback from your users, then tweak your prototype)<\/li>\n<\/ol>\n
      \"5
      5 stages of the d.school’s design thinking process<\/figcaption><\/figure>\n

       <\/p>\n

      What happened in the 90-minute session<\/h2>\n

      The crash course was a\u00a0paired activity, so the 8\u00a0participants involved got into 4 pairs.<\/p>\n

      The main task of the course was to redesign the gift giving experience for your partner, by focusing on the last gift that he\/she gave to someone else. To do so, each partner\u00a0took turns to interview the other\u00a0partner, build a problem statement for their pain points, develop multiple prototypes, get feedback from the partner, and then develop the\u00a0prototypes further. We were basically brought through Stanford’s\u00a05 stages of\u00a0design thinking.<\/p>\n

      Time was short, but\u00a0most of us\u00a0felt that the pace was ok.<\/p>\n

      The 6 Key Lessons Learnt<\/h2>\n

      #1:\u00a0Talk to users before fully committing to any one solution.<\/h3>\n

      This applies to almost any product that you’re working on. Talking to users about our ideas means that\u00a0we get to know which work, and which\u00a0don’t\u00a0(for that\u00a0user). It\u00a0prevents us from wasting time and effort on something that eventually wouldn’t work anyway.<\/p>\n

      #2:\u00a0You don’t hit the sweet spot on the first try (duh).<\/h3>\n

      \"duh\"<\/p>\n

      This is related to #1 above, but is\u00a0worth mentioning as a separate point.\u00a0There’s always something in your product that wouldn’t\u00a0work quite as you’d expect. Because of that, iterating based on user feedback almost always results in better products (for that user, at least).<\/p>\n

      #3:\u00a0Adopt\u00a0a right frame of mind when showing an unfinished prototype to a user.<\/h3>\n

      Some of us might feel squirmy about\u00a0showing half-baked ideas to\u00a0others.\u00a0The key when doing it to potential users, is to focus on getting feedback<\/em> and improving<\/em> the product, and not think that you’re somehow being evaluated<\/em> by your user.<\/p>\n

      #4:\u00a0We are not our users, so don’t design for ourselves.<\/h3>\n

      One thing stood out during the session: some of us had significantly different gift giving problems than our partners.<\/p>\n

      One could be concerned with giving gifts that really benefit the recipient, while\u00a0the other might be concerned with\u00a0giving affordable\u00a0gifts that don’t look too cheap. This highlights the problem of designing a product based on what we<\/em> think is important (i.e.\u00a0without actual user feedback).<\/p>\n

      #5:\u00a0Some users might not even know what their problems are.<\/h3>\n

      Some of us didn’t\u00a0really know what our own gift giving problems were, because we’re not used to thinking like that. We don’t often stop in our tracks and analyse the problems that we face day-to-day.<\/p>\n

      That’s why\u00a0asking the right questions is crucial: we need to know the whys<\/em> of our users’ problems. If an answer doesn’t quite make sense, probe deeper and\u00a0get to the root problem or motivation.<\/p>\n

      #6: But it’s\u00a0tempting to not ask why<\/em>.<\/h3>\n

      When users try to explain their decisions or problems, it\u2019s easy to just take what they say and move on to ask them something else. For some of us, it takes conscious effort to probe deeper and find out why they did\u00a0(or\u00a0felt) what they did\u00a0(or\u00a0felt).<\/p>\n

      \"oh-i-see\"
      *Nods and pretends to fully understand what the user is saying*<\/figcaption><\/figure>\n

       <\/p>\n

      3 Tips on Conducting a\u00a0Better Design Thinking Session<\/h2>\n

      If you’re thinking of conducting your own session of Stanford’s design thinking crash course, here are some tips that’ll make your session (much) better than the one I conducted.<\/p>\n

      #1: Do the course yourself first (you’ll need a partner, of course).<\/h3>\n

      Doing so has 2 important implications.<\/p>\n

      First, you’d get familiar with the course (and trust me, watching the video alone isn’t enough). That way, you’ll know which parts are potentially tricky (e.g. the interview portion, because some people\u00a0won’t\u00a0know how to ask the right questions), and you’ll then be able to\u00a0provide prompts to better facilitate the session. You’ll also likely find some parts slightly irrelevant (like the prototyping stage, which many of us\u00a0felt was redundant,\u00a0because\u00a0we just finished sketching our\u00a0ideas on paper at that point), and can play them down in your session.<\/p>\n

      Second, doing the course prior to the session also means that you won’t be participating in it. In other words, you’ll be free to move around and facilitate<\/em> the session, which is what you should really be doing.<\/p>\n

      #2: Don’t use Stanford’s\u00a0video in your session.<\/h3>\n

      I know, it’s tempting to just let the video do the\u00a0job for you. But there are reasons why you should\u00a0conduct the session\u00a0yourself.<\/p>\n

      First, using the video makes the session\u00a0feel that much\u00a0lamer (it’s true, I relied on\u00a0it\u00a0and\u00a0it felt like we’re just going through the motion). More importantly, giving instructions yourself allows you to make sure that everyone in the session clearly understands what they have to do, and are able to clarify things that they’re not certain about.<\/p>\n

      If you need a timer for the different stages in the session, Google<\/a> has a great one (in fact, you can just google “timer”\u00a0to get to it).<\/p>\n

      \"temptation\"
      Must. Resist. Temptation.<\/figcaption><\/figure>\n

      #3: Go through everyone’s problems and solutions at the end of the session.<\/h3>\n

      Do it if your group is small enough (say, less than 10\u00a0pairs).<\/p>\n

      This not only increases the level of engagement in your participants (which is always good), but also allows them to share their biggest takeaways or stumbles during the session. On top of that, your participants are also likely curious about what other participants went through during the hour-and-a-half session.\u00a0Going through a round of sharing also prevents the session from ending abruptly (which was what happened to mine).<\/p>\n

      And that’s all!<\/h2>\n

      I hope you found this post useful! Let me know what your key lessons and mistakes were in the comments below, after you’ve conducted your own design thinking session!<\/p>\n","protected":false},"excerpt":{"rendered":"

      The Stanford d.school (a.k.a. Stanford Design School, for the less pretentious) is well known for its “design thinking” methodology in problem-solving. For those who aren’t lucky\u00a0enough to visit their campus, they’ve created a 90-minute, video-guided virtual crash course that brings participants through the 5 stages of their design thinking process.\u00a0Last week, I conducted a session… <\/p>\n

      Read more 3 Mistakes, 6 Lessons from Conducting a Design Thinking Session<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[11,12,13,14],"class_list":{"0":"post-134","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-ux-lessons","7":"tag-design-thinking","8":"tag-lessons","9":"tag-mistakes","10":"tag-tips","11":"entry"},"_links":{"self":[{"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/posts\/134","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/comments?post=134"}],"version-history":[{"count":21,"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/posts\/134\/revisions"}],"predecessor-version":[{"id":167,"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/posts\/134\/revisions\/167"}],"wp:attachment":[{"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/media?parent=134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/categories?post=134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yushengteo.com\/blog\/wp-json\/wp\/v2\/tags?post=134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}