Design thinking & its implication in IT projects
Design Thinking has become very relevant in today’s software development. I’m lucky enough to lead great teams where we used this method for different projects and got great results.
Here I would like to share my experience, lessons learned and how could it help you in your development efforts. I believe we could create a better product if we involve a Design Thinking mindset in our development culture.
>> Follow me on Medium so you will get quality content faster than others
Design Thinking
In simple words, it’s a process that helps us understand the customer's (user) needs & wants and then uses that understanding to explore different options to meet to needs & wants, building the simplest solutions (prototypes) and testing those proposed solutions by getting quick feedback from customer and refine it based on feedback in an iterative way.
It’s not just about solving problems for your customers, but about identifying and solving the right problems for them.
Design thinking can assist in the creation of desirable products by helping us to gain a deep understanding of the customer and their problems within the problem space.
Here the key word is ‘the Process’. Design thinking is known as a process for creative problem-solving and innovation. Here problem or ‘problem domain’, in most cases, is a business situation, or business challenge and the solution is the agreeable flow of information that satisfy different stakeholders' needs.
Steps
Design thinking involves a series of steps, starting with understanding the problem and ending with testing and refining the solution.
- Empathize: Understand user needs and perspectives.
- Define: Clearly articulate the problem or challenge.
- Ideate: Generate a range of ideas for solutions.
- Prototype: Create a representation of a solution to test.
- Test: Gather feedback and review the solution.
- Iterate: Refine and improve the design based on feedback.
It’s a mindset
Design thinking is a mindset that involves a certain way of thinking and approach to problem-solving and without understanding that mindset it’s hard to get the required result.
If design thinking is a philosophy, companies need to develop a recipe or process for applying it with right mindset.
In this mindset, the customer or user is the center part of the process and is involved in all phases from problem definition to solution proposal to testing. we find and finalize the best solution, under given circumstances, together will the customer or user.
It encourages a mindset of continuous learning and improvement and encourages cross-functional collaboration and a holistic approach to problem-solving.
From problem domain to Solution
I found design thinking a creative problem-solving that is a tool that is key in the analysis phase of software development. I also believe that the first step to solving a problem creatively is to understand it in a creative way.
I found is very useful to keep reminding ourselves that “Are my efforts focused on comprehending the issue at hand or seeking out a resolution??”
It is important to distinguish between the problem and solution space because it helps us to be aware of where we are directing our efforts. It can be tempting to start by focusing on solutions and trying to solve a problem by creating and releasing a solution to customers. However, this can lead to creating a solution that does not effectively address a significant customer problem.
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions” — Albert Einstein
Design thinking is a great tool to spend valuable time in the problem space, define the problem, or in many cases redefine the problem, get into the user or customer’s shoes, and understand the world (the problem domain or problem space ) from their point of view. It helps translate the business need into interfaces and user flows etc that make it easy to use for customers via iterations of research, synthesis, prototyping, and usability testing.
The goal of the design thinking process is to move from the problem space to the solution space in order to generate innovative and effective solutions to the problem. This involves empathizing with users or customers to understand their needs and challenges, defining the problem in a clear and concise way, brainstorming and prototyping potential solutions, and testing and refining these solutions to improve their effectiveness.
Steve Blank (father of lean startup) emphasizes the importance of leaving the office, Get Out Of the Building (GOOB), talking to the customer and users, and actively seeking out an in-depth understanding of our customer’s problems, rather than relying on assumptions. The most accurate understanding of our customers’ problems can only be found by engaging with them directly. Design thinking can be useful tool for gathering these insights and developing solutions that effectively address customer needs.
Design thinking vs conventional
Design thinking focuses more on problem understanding while the conventional approach of software development focuses on a solution.
Traditional approach (Solution-oriented)
As a software developer, you are likely familiar with the traditional approach to problem-solving, which involves breaking down a problem into smaller pieces, analyzing those pieces, and then implementing a solution. In addition, we don’t analyze all the information that is available to define the problem. Instead, you use solutions to navigate the problem space. While this approach can be effective, it can also be limiting, as it may not take into account the needs and wants of the users of the software.
Design thinking approach (Problem-oriented)
Design thinking is a problem-solving approach that is focused more on problem understanding, creating innovative and effective solutions that are aligned with the needs of the users. in contrast, a conventional approach to problem-solving may be more focused on finding a solution that meets the requirements or specifications that have been defined upfront, without necessarily considering the needs and desires of the users.
Although it is very tempting to jump to the fun part and find the solution to whatever problem we understand in the initial phases but we found it very fruitful to stay in the problem space bit longer.
“Seek first to understand, then to be understood” — Stefan R. Covey
Our Implementation
Now Let’s dive one step further and let me share my experience and how we implemented this method in our projects.
Of course, each project and application is different and our design thinking implementation varies depending on the nature of the business, project, environment, and other factors. Here I’m explaining our way of working, in a general way, that we adopted based on specific project needs.
Great tool for analysis
We use design thinking mainly in the phase of analysis and requirement engineering. At the project start our team usually consists of business analysts (BA) and UX designers (who is usually also an expert in frontend development), developers, and a project manager.
I must mention here that it's not a one-time activity. We run a design thinking process for all unexplored business areas where we have uncertainty at any phase of the project. With that said, Of course, we don’t do it for every user story or requirement as its simple overkill.
Empathize with user/client/stakeholders
Here we mainly focus is on the What and Why part of the problem domain.
Here our main aim is to understand the problem area, empathize with users, and see the world from their angle, not only what users want but more importantly why they want it.
We kickstart our design thinking process by arranging a workshop with different stakeholders from the customer side including the product owner. The main agenda of this workshop is to understand the overall business domain at a higher level and find out the main business areas, business flows, and goals and objectives of the project. This workshop is usually led by different stakeholders from the client side. One of the main outputs of this workshop is different business areas and their prioritization that need to be addressed in the solution (target application).
Later we schedule separate workshops for each business area where we invite related stakeholders of that specific business. In these workshops, we take one specific business segment and invite domain or subject matter experts to give us a detailed introduction to that segment and current challenges. Using these workshops we try to learn as much as possible about the business domain (problem area) and ask all types of questions to get into the user's shoes.
In many cases, we also conduct individual interviews to understand the current system or way of working and the user’s needs and wishes.
In many cases, users know soo much that even she/he does not know what they know. Spending time at their workspace helps to get that knowledge that is hard to put into words. We also found it really valuable to spend time in the user or customers’ workspace and watch them working, shadowing & observing, and getting a first-hand experience from the problem domain.
“The highest form of knowledge is empathy.” — Bill Bullard
Define/redefine the problem
As the next step, we define the problem domain based on the output, our understanding, from Empathize phase. We usually write higher-level user stories as the outcome of our understanding. Later we discuss these stories with stakeholders, including product owners, to get their feedback and improve user stories based on that feedback. Usually, here our strategy is to teach it back what we learn from a domain expert, as the best way to learn is to teach ;-)
During this phase, we often learn a great deal and are surprised to realize that our initial understanding from the empathizing phase was incomplete. We usually discover that we had a limited understanding of the topic and end up learning much more.
An important point to note is that we always timebox these activities as it's very easy to get involved in too many details.
“If you define the problem correctly, you almost have the solution“— Steve Jobs
Ideate on possible solutions
Here we mainly focus is on the How part of the problem domain.
Here our main aim is to run an ideation process together with stakeholders based on our initial understanding and user stories.
Taking the valuable output from Empathize (understanding) and Define phases (high-level user stories), we enter into the ideate phase. Here we usually enter into the solution space and try to come up with different options based on current understanding and past experience.
It is one of my favorite phases as here we usually work together with our stakeholders using a very basic strategy of ideation called sketches. Our first few sketches are usually very simple as we normally start from a whiteboard sketch in front of related stakeholders and invite them to give quick feedback. It helps to trigger some brainstorming sessions and open discussions. It is usually a very interactive and fun exercise. Of course, depending on the situation and project need we also draw business flows and information models, etc.
The quality of the solution usually depends on the quality of questions we ask and the quality of the problem definition.
After brainstorming, discussion, and sketches workshop, we go back to our desks (office) and try to digest the material and come one with new sketches based on initial feedback, and this time it is on white paper. The main reason to do it on paper is speed and quick correction based on feedback.
“I begin with an idea, and then it becomes something else” — Pablo Picasso
Prototype the potential solution
We used the prototyping phase to demonstrate what we understand from the brainstorming and discussion session.
Once we get some initial agreement with stakeholders, we move to the prototype phase where we usually use some graphical tool like Figma to draw the proposed solution in a more nicer and colorful way. As part of the prototype, we draw one page or the whole user flow depending on the specific scenarios. Here our aim is to build something close to the final product but cheap and faster and one that is easy & fast to change or update.
We show the prototype to the customer and get feedback, update the prototype based on feedback and show it again for new feedback and iterate on this until the user is satisfied.
Here our goal is to learn not to produce code that we can keep so we are ready to throw it if we are wrong and ready to keep it if we are right.
As a lesson learned, the keys in the design thinking process including sketches is the speed, iteration and continuous interacting with customers. Usually, our golden role is to do ‘good enough’ to move to next phase of ideation and do fast iterations.
Once the user or stakeholder is satisfied with the prototype we move to the next version of the prototyping which is a ‘frontend only’. We build this interactive prototype using HTML, CSS, or some other frontend technology like Angular or React depending on the technology stack chosen by the team. We always get extra feedback on the interactive prototypes where users/stakeholders feel it more close to the real-world solution and could think of many other scenarios that were not clear at the beginning. So we go through some iteration here before the user is satisfied and now wants to play with real data.
It has always struck me as odd that the things you learn while making prototypes & getting feedback are not seen in other phases.
“Prototype as if yo are right and listen as if you are wrong” — Diego Rodriguez
Test — Feedback sessions
We usually don't run the Test phase as a separate phase in our implementation of design thinking. The rationale for this is that testing is embedded in all our activities and we have very close customer or user interaction on all phases of design thinking.
The main goal of story writing, user flow, sketching and other tools is to understand problem and find optimized soution but NOT DOCUMENTATION
Important Note
I think it's very important to mention that although I have listed and mentioned different tools and techniques we used under different phases of design thinking BUT we don't necessarily use all of them in every situation. Although we intentionally try to follow all phases but the length of each phase varies greatly. In some cases, we may even merge phases together based on the specific needs of the project. It is important to be flexible and adaptable in the design thinking process in order to effectively solve problems.
For example — On a project where we faced a complex domain, multiple stakeholders, and a high level of ambiguity, we turned to design thinking to help us understand and address these challenges. During the “Empathize” we conducted multiple workshops to gather insights and ideas and used the resulting information in the “Define” phases to write user stories and create user and information flow diagrams. These tools and techniques allowed us to better understand the needs and perspectives of all stakeholders involved, and helped us to clearly define the problem we were trying to solve.”
I could also think of another relatively simpler project, we had a simple domain so we were able to move quickly through the design thinking process. After conducting a few workshops during the “Empathize” phase, we moved on to using Figma sketches for multiple iterations to ideate and prototype. In other words, we merged or run in parallel the “Define,” “Ideate,” and “Prototype” phases. This allowed us to efficiently move through the design process and arrive at effective solutions.
More
Follow me on Medium so you would get quality content faster than others.
