This text is a translation of an article originally published on DOU.ua.
My name is Denys Yarovyi, and I’m a Payments Product Manager at Plarium Ukraine. Before moving to my current position, I was a UX designer for 6 years working on internal services for employees. In that role, I designed an admin panel for player support agents, a system for launching in-game events, and tools for things like processing player feedback and launching push notifications.
In this article, I want to talk about design thinking. Regardless of your position or profession, design thinking will help you take a more conscious approach to work tasks, avoid having to redo them multiple times, and achieve results to drive you forward in your career.
Before I joined Plarium, I worked as a developer for an outsourcing company. At a certain point during my time there, I realized I wasn’t satisfied with the results of my work – I felt that I was writing nice code, but the final product turned out to be not so nice at all. What I actually wanted was to see my work go toward something worthwhile.
That’s when I realized that I wanted to work with design, and create products that look attractive. At that time, I thought that’s what design is for.
But three things changed my mind: my own experience, the book The Inmates Are Running the Asylum, and a Coursera design course. While taking the course, I experienced a real design cycle. This is the process by which you start with an understanding of the problem, and then go through each design stage step-by-step. I'll elaborate on each of those steps later on in this article. Having experienced this approach, I realized it was all I wanted to do.
Before I expand on the topic of design thinking, I’ll tell you about another approach to solving problems that we unconsciously use every day. This is the trial and error method.
It consists of choosing ways to perform tasks one by one. You try one way to solve a problem, and if it doesn’t work, you keep trying other ways until you find an effective solution.
This is a natural thought process for many living beings. A behavioral experiment by Burrhus Frederic Skinner confirms that even pigeons use the trial and error method.
During Skinner’s experiment, pigeons were placed in a box with an automatic feeder – when the bird pecks a button, food is dispensed. Then the conditions are changed, and the food stops being dispensed at the push of a button. The pigeon presses the button – and nothing happens. The pigeon then begins to repeat the actions it took before pressing the button. Because the new conditions are incomprehensible to it, the bird begins to ponder: "What if I stand on one leg?", "What if I turn my head?".
Thus, this method is the most common tool for solving various problems – it’s used in everything from pigeons obtaining food, to you and I accomplishing tasks at work.
The trial and error method is not perfect and has a number of drawbacks, which are as follows:
When it is applied, it is impossible to make any predictions. We cannot predict how and when a problem will be solved, because results can be achieved on anything from the second try to the two hundredth attempt.
With this approach, it is impossible to choose the best and most effective way to solve a problem, because usually we choose the one that works first.
There are complex and multidimensional tasks that are practically impossible to perform using the trial and error method. In such cases, there can be thousands of options, so it would simply take too much time.
This is a method that mankind has been using for centuries. We automatically apply it to solve any issue, from inserting a USB drive into a laptop, to developing scientific concepts.
However, there is a method that deals with problems more efficiently and with less resource consumption. And that method is design thinking.
Design thinking is a mental framework that can be used to solve problems. The best definition of this approach, in my opinion, is provided by Tim Brown, CEO of IDEO:
"Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success."
This approach consists of three main stages.
When a person comes to me with a task or an idea, the first thing I do is ask the question: "What for?". The answer makes it possible to understand what benefit solving this issue will bring, and perhaps if it’s necessary to work on it at all.
After all, sometimes the client will come up with a ready-made solution, but this solution may not attack the real problem. On the other hand, it may not be a full solution. In this case, it’s necessary to look for the root cause of the problem requiring your attention.
To answer the question “What for?”, it is necessary to define the users and their needs. In my previous line of work, the users were people from within the company, as we did a lot of internal product development. So, I just went to the task provider and asked them questions. Lots of questions.
First of all, I ask: Why are we doing this? What profit can it bring? How will it help you? And then I try to understand how it will affect the company in general.
For example, the team will be able to do something faster or it will now be necessary to allocate one person instead of three to complete the work. In such cases, it’ll save on working hours. As a result, it’s good for business, while those carrying out the work have a new, efficient way of doing things.
But in other cases, you need to go deeper and ask further questions to find less-obvious benefits. Here, you’re looking to “treat” the root cause, not just the symptoms.
For example, at an interview, I gave an abstract task to candidates for the position of designer.
You work in a company on an internal product for accountants. And one of the accountants gives you a task: to add a button to the interface above a table that will compile the data and allow you to download the table in .csv format. What will you do?
Some designers might say: "I'll see if this button fits", or, "I'll see what style I can make a button in". They immediately start thinking about how this feature can be added.
But we might ask: why is it needed at all?
“Clients” say the button is needed to download the table.
And now it becomes clearer that it is not the accountants who need it, but the managers. They need to see specific indicators within a dataset, and adding a button doesn't seem like the best solution anymore.
Yes, it kind of solves the problem that accountants need to manually rewrite this data and cannot download it. But the solution is quite imperfect. Ideally, the manager could immediately see these indicators in a dataset and not burden the accountants with this work. It can be, for example, an automated solution that will immediately email graphs based on these indicators to the manager.
It’s important to understand that those who give tasks are often not experts in formulating them. Therefore, they may need your input to better understand the benefits of the task, how it will affect users and business, and whether their way is really the right one to solve the problem.
Surprising as it might sound, anthropological studies also help to understand tasks. Anthropologists are scientists who directly observe how people live and operate in the ‘real world’ – for us, such a method grants an understanding of how the end-user will use whatever it is you’re working on.
When we worked in the office (so, pre-Covid), I liked to visit the colleagues who would be users of the service I was working on. We talked, I asked questions, and looked at the environment in which the person worked – and this provided some interesting insights.
For instance, one time we were tasked with making a new product for system administrators. After collecting detailed information about the task, I came to their workplace and saw a large whiteboard on the wall, tracking product releases and their statuses. So, when we were developing the product, I took the tracking table from the whiteboard and digitized the concept – it helped ease the transition to the new tool. The work was clearly applicable to the user’s needs because it was taken from real life.
Here’s a handy tip: try formulating the task you’re faced with in one sentence so that it is clear how it benefits users and the business. After that, we move on to putting ideas into practice.
As soon as the task is clearly described, a person automatically begins to think about a solution: "What if we try this? Or this?". This is, ultimately, trial and error, the drawbacks of which we have already explored.
According to design thinking, you should start solving a problem by generating as many solutions as possible to create a pool from which to choose. This helps to avoid the thinking trap created by the trial and error method: if the solution worked, then it is by default correct and relevant.
At this stage, it’s not that important to focus on how realistic the options you generate are, so there's no need to filter anything out just yet. Of course, it’s better to come up with working solutions that can actually be developed – but if you have some high-tech or fantasy ideas, that's fine too. At this point, it’s quantity over quality. This approach is called divergent thinking, or defocusing attention.
There are many methods of generating solutions. I will tell you about the two that I most actively use at work.
This is a collective method that consists of refining each other's ideas.
Let's say you have five people and a specific problem. You draw a 5 × 5 table and you have 5 minutes to each write in your cell in the first row the solution to this problem.
When it’s done, start the next phase: the next 5 minutes will consist of going down one line, taking the person on the left’s idea, and improving it. In this way, people enhance each other's ideas and a matrix is obtained that starts with five ideas and ends with finalized solutions.
This allows you to quickly and efficiently generate lots of ideas, gather criticism, and locate improvements without creating a discussion at all. After this, you can have an open discussion to talk about ideas.
Source: author’s own
I also actively practice brainstorming at work. And it’s possible to do so successfully even while working remotely, as we are now using Miro boards.
For example, I have a concretely worded question on the board that starts with "How can we...". I’ll keep this in mind as I verbally convey the details of the task.
My colleagues' task is to come up with at least three ideas on how we can do this. They have 10 minutes to brainstorm.
When the timer starts, I always write the first idea myself. I take a sticker and write something, not necessarily a perfectly working version. Why do I do this? It helps others overcome the fear of a blank page. Because when you have an empty board, it's scary to be the first to pull out a piece of paper and write something there. So I take that “burden” upon myself, and so the process begins.
It works better when there are not that many people (up to five is ideal). After all, it’s harder to hide among 5 members than it is amongst a group of 20. I also try to engage people who are willing to participate, though there are often individuals who find it difficult to join a discussion.
At the next stage, we narrow our focus as much as possible, set clear selection criteria, and choose the way forward. This is convergent thinking.
We evaluate our options according to two criteria:
Impact is evaluated with the help of the experts in the industry or department for which we’re making the product. If we’re developing a feature for support, we need to involve the people who use it.
Effort is best handled by developers because they can give a preliminary estimate of the work effort. Maybe something is impossible to implement at all, or perhaps it’ll take years of work.
My colleagues and I then select solution options, based on impact and effort criteria. When I gather the team together, I take an idea, voice it, and ask, "How effectively do you think this option would solve our problem?" This is how we evaluate the impact. Then I ask: "How labor-intensive is the implementation?". Thus, we evaluate the effort.
Consequently, we discuss each others’ ideas in turn. After that, we visualize all options in a 2 × 2 matrix. For example, this is what the impact/effort matrix looks like:
Source: adapted from build.co
This allows you to immediately see what is worth doing: i.e.,you’re looking for something that has a high impact and low effort. We also see what cannot be done at all, and what needs to be further evaluated and discussed, because there is always a gray area in which both impact and effort are only moderate.
This stage ends when we choose one option that meets all criteria more than the others.
That the solution we chose as the best option for solving the problem is itself a hypothesis. If it's possible and if it's a new and unique tool, it's better to create a prototype to see if people even understand how to use it.
It is necessary to test hypotheses and do prototyping before your chosen solution enters the development stage.
Let's imagine the following situation: you’re working on an online store, and you hypothesize that adding reviews to your product page will improve conversion.
How to test this idea without developing the backend? You can ask for real customer reviews, or make fake ones on this page, and just create a block without a system for adding real reviews. Then, you’re able to measure whether it affected the conversion. This way, you can check if the reviews are working or not.
The company EveryPlate has an interesting example. It all started when businessmen from the USA decided to start delivering cooking recipes along with ready-made ingredients. There was a hypothesis that home cooks often don’t know what to cook. Specialists of what would become the EveryPlate company thought: "What if we provide a list of recipes for the week, as well as pre-prepare the ingredients for cooking according to these recipes?"
Before starting to develop a mobile application for this service, they tested this hypothesis. They approached potential home cooks in supermarkets and asked if they would use such a service. Then they took the survey participants’ phone numbers, contacted them, and delivered the products to their homes. The number of orders grew – clearly, people liked the idea.
If your hypothesis is disproved, go back to the previous stage, choose another option with high impact and low effort, and test it.
IDEO's website about design thinking. Here, you’ll find a detailed description of this approach, a history of its development, FAQs, and a large list of useful resources. If you want to delve into the theoretical component of design thinking, there’s no better place than IDEO.
A selection of useful design thinking articles from the Nielsen Norman Group, a design and UX company. They also have an interesting format on their site: in short 3–5 minute videos, they cover topics related to design thinking.
Design Thinking 101 – this podcast will help you to understand how design thinking works in various areas of business. Listen to hear interesting case studies and useful tips for applying the approach.
Design Thinking Handbook – a book by Eli Woolery, Director of Design Education at InVision that delves into design thinking details.
I provide here a design thinking problem-solving checklist that can help you get your work done more effectively, no matter who you work for.
What do we want to achieve? Here you can also use the "5 why" method – ask "why" until you find out the root cause. This may lead to the realization that you need to solve a completely different problem!
What’s the business benefit? What will it bring to the company?
Find out the needs of users via any available means. If you’re able, conduct in-depth interviews with, and observations, those who require your solutions. If you can’t, then such information can also be obtained through reviews or support requests.
Get all the answers and formulate the task in one sentence.
Generate the maximum possible number of solutions to the problem. You can do it alone, or with the team working on the task with you.
Select the best options from this pool of solutions according to the impact and effort criteria. For clarity, it can be visualized schematically.
Choose the one solution that seems most appropriate according to the indicators and, if possible, make a prototype to test the hypothesis.