Design thinking is a human-centered approach to exploring problems and possible solutions. It draws on a broad history of design practice rather than one invention or one fixed recipe. In UX work, it helps a team investigate what people need, make ideas concrete and revise them using evidence.
This article follows five familiar modes: empathize, define, ideate, prototype and test. The Stanford d.school Bootleg presents methods for these modes. Other frameworks include implementation explicitly; the names and number of stages can vary. Here, a bicycle-repair booking example shows what each stage contributes and when a team might return to an earlier question.
Solution-Based Thinking of Designer
Design thinking is iterative and user-centered. It encourages a team to investigate the problem while exploring possible responses, rather than accept the first requested feature as the solution. It is useful in many settings, but it is not a process that every company follows or a guarantee of innovation.
For a UX designer, the framework provides ways to observe, frame a question, explore alternatives and learn from prototypes. A useful result may be a simpler form or a clearer service explanation, not necessarily an entirely new product.
The five modes are connected rather than strictly sequential. A prototype can reveal that the problem was framed too narrowly, and a new research finding can change the ideas worth exploring. Keep the decision behind each activity visible.
The Five Phases of Design Thinking
Empathize
Begin with the people and situation. For the repair service, learn how customers decide whether to book, what they know about the bicycle problem and what they need to plan around the visit. Interviews can reveal concerns, while observation can show practical constraints that people may not mention. Do not substitute imagining yourself in someone’s position for speaking with or observing them.
Separate observations from assumptions. “A participant asked how long the repair would take” is an observation; “customers need instant repair estimates” is an interpretation. Record the source and context so the team can challenge the interpretation rather than silently treat it as a requirement.
Choose further research based on the uncertainty and the range of people affected. A few conversations can identify questions worth exploring, but they do not establish how common a problem is across every customer. Include relevant differences, such as a commuter who needs the bicycle daily and someone booking a nonurgent service.
Define
Use the evidence to state a problem without embedding the preferred solution. For example: “Customers need to understand what can be promised before a bicycle assessment so they can plan a drop-off.” This leaves room for an explanation, a service change or a booking-flow revision.
Keep user needs central while acknowledging business and technical constraints. A shop may be unable to quote a repair duration before inspection; asking the interface to promise one would create a new problem. Record that constraint alongside the question.
Refine the statement when new evidence changes it. If customers understand the assessment but cannot find a suitable time, the next design question concerns availability rather than the explanation of repair duration.
Ideate
Explore different responses to the problem. The team could clarify what an assessment includes, let a customer describe the issue, offer a callback, or show the next available drop-off times. Sketching, mind mapping and role-play can help reveal alternatives that a single feature request would miss.
Separate generating options from selecting them. Give ideas room initially, then compare them against the user need, feasibility and constraints. Choose a small number to investigate and record why each was selected. There is no requirement to commit to one final solution at this stage.
Prototype
Create a representation that can answer the next question. It might be a paper sketch, a service script or an interactive screen. Limit the effort to what the review needs; do not build a polished product before testing the uncertain part.
For the bicycle-repair example, prototype a booking screen that separates the drop-off time from the eventual repair duration. In Mockitt, show “Duration estimated after assessment,” an optional description of the issue and a way to choose a drop-off time. Connect only the screens needed to explore whether that distinction is understood.
Treat an unsuccessful prototype as information about the idea or the question. Record what caused difficulty, then decide whether to change the wording, the interaction or the underlying service proposal. Repeating the same test without a clear revision is not useful iteration.
Test
Give representative participants a task and observe how they interpret the prototype. For the example, ask them to arrange a repair assessment around a workday, then ask what they expect the selected time to mean. Avoid explaining the distinction before they encounter it.
A prototype review can reveal misunderstandings and missing information. It does not by itself prove demand, technical feasibility or a business outcome. Use the findings to decide what needs revision and what requires a different form of validation.
Let participants attempt the task without unnecessary coaching. Ask neutral follow-up questions about what they expected and record behavior alongside comments. If the misunderstanding starts before the screen, return to the earlier problem definition rather than polishing the wrong interaction.
Why Use Design Thinking in UX?
The approach helps a team maintain a connection between a user problem and the work it produces. It makes room for research before solution decisions and for revision after feedback.
User-centered work still needs to consider the service, the organization and the technology that support it. The aim is to find a response that people can use and the team can responsibly deliver.
Design thinking overlaps with UX design; it is not a separate mechanism that invents a solution which UX merely decorates. Both can involve understanding needs, structuring information, exploring interactions and evaluating an experience.
Its value comes from making assumptions discussable and testable. That can expose a weak idea before larger implementation work, but it does not guarantee a revolutionary innovation or a particular return on investment.
The benefits of Design Thinking at work
The best thing about design thinking is that it is not a linear model, so you are not bound to follow a straightforward process. And you can come again to a certain point to refine your idea or problem to identify the issues and downfalls in the product design.
The potential business benefit depends on what changes and how it is implemented. In the repair example, clearer booking expectations may be worth investigating, but the team should measure the relevant outcome after release rather than promise savings from the workshop itself. Possible questions include:
- Can customers complete the relevant booking task and explain what they have booked?
- Does the implemented service meet the expectations created by the interface?
- Are support questions about assessment time or repair duration changing, and why?
Wrap Up
Use the five modes to keep learning about the problem while making the design tangible. A clearly framed question, a small prototype and a reasoned revision are more useful than treating the diagram as a mandatory sequence. Once a proposal is supported, plan implementation and evaluate the real service too.
