Design Thinking — everything you wanted to know and was too shy to ask…
So, you’ve probably heard this term a lot and may have wondered, “What is this Design Thinking thing that everyone’s talking about lately?”
Well, whether you have or haven’t heard this term, I’m here with years of experience to present to you the Design Thinking methodology. I’m here to:
- Design, tailor and implement this methodology in several organizations.
- Mentor and coach key persons while adopting the methodology in your organization.
- Facilitate Design Thinking workshops.
This is the time to learn how the Design Thinking methodology works, why it’s so efficient, and the steps taken to make it the most popular methodology today!
But before we jump in, let’s start with the basic theoretical explanation:
Design thinking is a method for practical, creative resolution of problems. It is a form of solution-focused thinking with the intent of producing a constructive future result.
Design thinking identifies and investigates both known and ambiguous aspects of the current situation in an effort to discover parameters and alternative solution sets which may lead to one or more satisfactory goals. Because design thinking is iterative, intermediate “solutions” are potential starting points of alternative paths, allowing for a redefinition of the initial problem, in a process of co-evolution of problem and solution.
Now, let me take you step-by-step through the Design Thinking process using a case which I’m sure everyone can feel connected to.
Let’s assume your company is working on the next feature list for its consumer application.
Building the next feature list
Building the next feature list may be tricky.
You may ask your users for a “wish list” and they might give you a long list of features they would like, but then you can find yourself either:
- Tailoring your application to a subset of your users, while others may think otherwise.
- You may choose the wrong features from this long long list because users usually say what bothers them right now (hot cases), or what made them or their bosses angry, and not what could bring the best ROI (return on investment). This may result in hard work for your development team, while the features ultimately released may be hardly used, or offer you the lowest revenue.
- Getting a defined list of features from your users or from your product management team usually brings with it the implementation style and user experience, or at least gives hints that interlock development and design teams on specific solutions, without the freedom to innovate.
- Thinking of solutions before fully understanding the user, the environment, feelings and work processes (a.k.a. empathizing with the user), may result in bad user experience or solutions that do not solve the real problems, or partially solve the problems, both make the solution unusable for the user.
Design Thinking to the rescue
This is where the Design Thinking methodology comes in to solve these problems. How? I hereby offer you the skeleton process:
Empathize with your user
Duration: in a dedicated workshop.
1. Identifying the users you would like to focus on for the next release.
2. Imagine their environment, their daily work processes, and feelings/thoughts while working with your application.
Identify the user journey & pain points
Duration: in a dedicated workshop & ongoing (with feedback for improvement)
1. Define the phases the user goes through while working with your application and focus on your desired flow.
2. Define what the user does, thinks and feels during each phase, trying to be as granular as possible.
3. Identify the pain points on the definitions from (2). Mark with red the pain points and with green the success points.
4. Draw an experience chart to identify the phases you need to focus on to solve the user’s pain points first.
5. Prioritize the pain points.
Find solutions for the prioritized pain points
Duration: in a dedicated workshop & ongoing (with feedback for improvement)
1. Find solutions for the highest prioritized pain points.
2. Foster innovation by each one of the participants of the team, not only by the users or by the product management team. Everyone can innovate and bring value: testers, developers or any business persona.
3. Draw a prioritization graph and put each solution on the scale of “development efforts” vs. “customer value”.
4. Pick the solutions with the highest customer value and lowest development efforts and prioritize them as the next features.
Add the Technical Foundation
Duration: in a dedicated workshop & ongoing throughout the release.
In each release, there should be a list for Technical Foundation.
Things that development/business/support/product management wants in such a way to be able to compete in benchmarks, improve support capabilities, and improve infrastructures while looking ahead 5 years or more.
Prioritize them together with the key persons in the company representing business, management line, product and so forth, and add them to the feature list.
The recommended ratio for the feature list is 70% for solutions (from previous steps) and 30% for technical foundation tasks.
Define the vision
Duration: in a dedicated workshop & ongoing (with feedback for improvement)
After prioritizing the feature list, work on identifying the vision of the release — what are the user’s values in this release? Consider the persona + what is going to be solved + the “wow” factor as one goal of the release’s vision. You need 3; no more than 3! (3 values keep you more focused and are easy to characterize and explain).
Review & Approve
Duration: offline, while workgroups start to work.
Go to your Business development, Management line, VPs, CEO, etc. and several customers; build a presentation showing the work you did with the team in the previous steps and present the vision you want to conquer in this release. Get feedback from them and then go back to the drawing board, if needed, to sharpen your vision or change it.
If needed, gather the group once again to re-think together. You may even need to go back to the “pain points” identification and re-start from there.
This step is super important as it avoids running forward with the wrong vision from your customer or business perspectives…
Agile — Development
Duration: ongoing during the development and test phases of the release
1. Form workgroups for each of the solutions, conducted by developers, testers, architects, designers, etc. — all the personas needed to design and implement the solution. They will work together during the development lifecycle of the solution.
- Developer/architect — will design the architecture and develop the code.
- Tester — will build a test plan and test.
- Designer — will design the solution and export design materials.
They will work in a great synergy and review each other work, brainstorm together, empathize with each one’s limitations and by that feel committed not only to the tasks they responsible for but also to their workgroup member’s tasks.
This will make them run faster forward with high efficiency and less waste.
2. Have an internal demo at the end of each iteration (usually two weeks) — each task force should show the Product Owner, Product Management, Support and the Management line their work progress, and get early feedback.
There MUST be something to show.
3. Have an external demo once in two iterations (usually once a month) for the user and get early feedback.
4. Create a digest of the feedback by each of the task forces and re-design/re-implement, if needed. Sometimes, there needs to be a re-prioritization and then go back to “Find solutions for the prioritized pain points” step.
5. Repeat steps 1–4 until you get great feedback!
Design Thinking Process Diagram
