Sometimes pressure and time constraints lead to some interesting ideas. In September, with very short notice I prepared and ran a Design Thinking workshop for my team that paid for itself three times: my team learned a few new things, we worked on our product and we had a lot of fun.
Here is the recipe for the workshop
- Consider each of the user groups of your product
- Create a team for each user group (two people can be a group)
- Each team goes through the design thinking process for their user group
My team of eight was split into four groups of two, each team with the task of going through the design thinking process with one user group of the product we are building together. All resources where prepared so that the workshop could be done remotely.
Empathy + User Journey
The first step in the design thinking process is to observe and empathize with your users.
When building a product, you often focus on a few key players, those that interact the most with your application or do the most work. By looking at your product through all of your stakeholders you can view your product with fresh eyes and maybe identify hidden opportunities.
In preparation for the workshop, create user journey diagrams for each team as a simple x-y plot. The x axis lists the process steps of the product in sequential order and the y axis has a happy face (top) and a sad face (bottom).
In the “empathy” phase, each team should call a few members of their user group, ask them to share their experience when using our product and document the user’s feelings for each process step.
When doing this step with my team I did not to tell them to contact users. I forgot. The user journeys each group created were based on their impressions or personal experience. This is suboptimal and reminded me of how important it is that the team see the product from users’ eyes. Groups that had little to know idea of what their user groups went through, how they really felt, documented a user journey that was less closer to reality. If your observations are wrong, your perception of what the user thinks and feels is wrong, you will likely identify fictitious problems and create unwanted solutions. One team went completely off track.
Talk to your users, find out how they really feel when they use your product to do work and why they feel that way.
Problems as the root of all products
Thirst is a real problem. There are many solutions for the thirst problem, water, coke and beer, to name three. Each solution is a product. Finding real problems to solve is the first step in achieving product-market fit.
Armed with a user journey, you can see when a user is happy and unhappy and ask one question: why? What is causing this feeling?
Be careful to jump into solution mode. You are now in “problem hunting” mode. Look for problems then prioritize them. The more problems you find the better. Think of each emotion as the door to a hidden problem. If your users are impatient, what is causing a delay? If your users are worried, what is causing uncertainty? If your users are confused, what is unclear?
With a prioritized list of problems you are ready to go into solution mode. But… not so fast.
Problem diagnosis can be the difference between life and death for your product, similar to how a visit to the doctor can be a life and death situation. If your doctor diagnoses your head pain as a headache, you will be prescribed aspirin. If your doctor diagnoses a brain tumor, you will be prescribed surgery and chemotherapy. If you confuse a headache for a brain tumor, you will invest more resources than necessary because you over diagnosed the problem. If you confuse a brain tumor for a headache, you will underinvest and will have missed a more severe problem. In both instances, the chances that your product will significantly improve with your next experiment go down.
You have identified problems that point to real pain, now it’t time to find pain killers. There are two questions that I use to help develop ideas:
- How can I reduce or avoid pain?
- How can I enhance happiness?
The first question is obvious. You have been thinking about problems and problems cause pain. But why should I think about enhancing happiness?
When the first iPod touch came out it was a life saver for me. I had long commutes in the train and I wanted to watch TED and Stanford eCorner talks to learn about business. I got the first iPod touch as a Christmas present and to my surprise it had two additional things I was not counting on: a microfiber cloth to keep the screen clean and a transparent stand to put the iPod touch in and watch videos. Apple developed a product that solved a pain and then took an additional step to enhance the happiness I would derive from the product. Can you think of products you’ve purchased that enhanced happiness?
A note on brainstorming ideas: watch out how you brainstorm in a team. I first heard Shane Snow say most people come up with more ideas by themselves than in a group, which means brainstorming sessions lead to less ideas. Auch! This is not his idea, but the results of years of research (HBR Article). A silent brainstorming session is the solution for this. Give time to everyone in your team to come up with ideas individually and then present, consolidate and discuss the ideas in a group.
Be open minded. Most ideas suck at the beginning. Look for potential. Take a deep look into the merits of imperfect ideas and find the gems in them. Consider combinations of the best aspects of different ideas to identify super pain killers and happiness drugs that you can build into your product.
Watch out for vitamins. Vitamins, in contrast to pain killers, are features and changes that don’t make a product drastically better and likely do not represent the best opportunities for your product. If you ask users, they might say those are good ideas but will not pay for them or will not use them.
When you think you are done, look at your problem and look at your idea for a solution. Do they fit together?
Place emphasis on rapid prototyping, not beautiful or not perfect prototyping! For most situations a few hours or days should do. Take the essence of what you want to build and put it together ignoring the hundreds of details that make up a final product. The faster your are, the more prototype failures you can tolerate and the higher the chance that you will find the perfect solution for a design problem.
You have probably seen how architects build their sketches into small but scaled cardboard structures, read about how Watson and Crick built a scaled model of DNA that showcased the three dimensional structure of DNA or seen how car makers build models of their cars in clay. All these are examples of prototypes that make certain aspect of an idea visible and tangible.
The goal of the prototype is to have something real that you can talk about instead of different ideas scattered among the minds of your team and your users. When you have something tangible to talk about, you can experience your product, you can communicate more efficiently and effectively about it and you can get feedback from your users.
In building a prototype that you can have discussions about you can dramatically reduce the risk of building the wrong thing and ultimately having a failed project. The prototype will help you validate whether you have a pain killer or a vitamin in your hands. The happier your client is when they see the prototype, the sooner you know that you are on the right track.
A prototype is something your user can interact with and simulates the core aspects of your idea. Watch out that you do not confuse a prototype for a proof of concept, an architecture diagram, or marketing materials. A proof of concept has as a goal helping you and your team believe that you can build what your customer wants. An architecture diagram shows how your solution will be built and how it connects to other systems. Your landing page displaying mockups and attractive copy writing is great for market validation, but it does not let a user experience your product and it does not allow you too see whether it actually solves the problem you intended to solve.
Prototyping is a skill I highly recommend you apply in your personal life as well. Two years ago I built a scaled model of my house so that I could discuss with my family how we could rearrange furniture. In a few hours I had all rooms built our of cardboard and blocks of wood representing beds, wardrobes, desks and sofas. The scaled model helped us make decisions. It helped see how a longer couch would feel in a room. It helped us be more confident about designing our office. It took a lot of insecurity away from every decision we made.
Testing: Get out of the building
Testing your product with real users takes less time than you think. But it requires more will power, at least initially, than you might expect.
In our workshop, this was the first time when each of the four teams was asked to call a user, and test their prototype… in 8 minutes. None of the teams had a previous appointment to talk to their users. Some groups smiled at the challenge. Others had a blank stare as they came to the realization that they did not know who might use what they had just prototyped.
Off they went in search of users, the clock ticking.
Every team managed to have a conversation with a real user about their prototype and get feedback in 8 minutes. In my opinion, those were the most productive 8 minutes of that entire day. Some teams got positive feedback, which is nice to receive, but should be taken with some skepticism – no one wants to tell you your idea sucks. Some teams got mixed signals. One team got a straight – “I don”t need that”.
Let’s recap what just happened. In a big bureaucratic corporation where getting appointments can sometimes be challenging, one hundred percent of the teams got access to one member of their user group and got feedback about their last hour of work. Buzzwords that come to mind “user centered”, “agile” and “lean”.
The team liked it. They were happy and excited about what had just happened. The dreadful jump into the abyss of “feedback” turned into an exhilarating rollercoaster ride. They enjoyed the human connection, having a real conversation about something that matters, their ideas, with someone else.
Yes, COVID made 2020 unforgettable, but it is still possible to have real, fun and productive interactions with your team and with your users. It is possible to do a design thinking workshop remotely to grow your team, it does not have to take an entire day (we did it in two hours), work on your product and have fun through it all.
If you need help setting one up, get in touch.
Products play an important part in our lives. They save us time by automating tasks, they let us do impossible things and they can bring joy. Make yours a great one!