A practical look at design thinking: where it comes from, what designers actually do when they reason through problems, and how it pairs with engineering work.
If you've spent any time around product teams, you've probably heard someone drop the phrase "design thinking" into a meeting. Sometimes it means sticky notes on a wall. Sometimes it means user interviews. Sometimes it just means "we should care about users." The term gets stretched in a lot of directions, which is part of why it's worth pinning down.
At its core, design thinking refers to the set of cognitive, strategic and practical procedures used by designers in the process of designing. It also refers to the body of knowledge that has been built up about how people actually reason when they engage with design problems [Source 1]. So it's two things at once: a way of working, and a field of study about that way of working.
That dual nature matters. When a designer sketches three versions of a checkout flow before committing to one, that's design thinking in the practical sense. When researchers study why designers do that (and whether it produces better outcomes than jumping straight to a solution), that's design thinking in the academic sense. Both feed each other.
Where the idea comes from
Write for sansxel
Want your work in the Learn library? Apply for a hardlocked byline.
Design thinking grew out of attempts to describe what designers do that's different from what, say, engineers or analysts do. The short version: designers tend to work with problems that aren't fully specified. You don't get a tidy requirements document. You get a vague sense that something isn't working, or an opportunity nobody has shaped yet, and your job is to figure out both the problem and the solution at the same time.
The knowledge base around design thinking captures patterns in how designers handle that ambiguity [Source 1]. Things like reframing the problem, generating many options before narrowing, prototyping early to learn cheaply, and checking ideas against real human needs rather than assumed ones. None of these are exclusive to designers, but they show up reliably in design practice, which is why they got studied and named.
The human-centered part
The label that gets attached most often is "human-centered." Design thinking is treated as a human-centric working mode, and that's exactly why it has drawn attention from fields outside of design proper, like software engineering [Source 3].
Human-centered means you start with the people who'll use the thing. Not with the technology, not with the business case, not with what's easiest to build. You try to understand their context, what they're actually trying to accomplish, and where current solutions fall short. Then you work outward from there.
In practice this looks like: talking to real users, watching them work, building rough prototypes you can put in front of them, and iterating based on what you learn. It sounds obvious when you write it out. It's surprisingly rare in actual development.
Why software teams started paying attention
Software development has always had a problem with requirements. You ask stakeholders what they want, you write it down, you build it, and then it turns out what they wanted isn't what they need, or the thing you built solves the wrong problem. Requirements Engineering, the discipline that deals with eliciting and managing what a system should do, is a crucial activity in software-intensive projects [Source 3].
Design thinking has been pitched as a powerful complement to Requirements Engineering, especially when the goal is to design innovative systems rather than incremental ones [Source 3]. The reasoning is straightforward. Traditional requirements work tends to assume the problem is reasonably well understood and the job is to specify a solution. Design thinking assumes the problem itself needs investigation. Put them together and you get a way to handle both the fuzzy front end (what should we even build?) and the rigorous specification work (how exactly should it behave?).
Research has spent real effort showing the benefits of bringing Design Thinking into Requirements Engineering. The trickier question has been how to actually combine them in practice [Source 3]. It's one thing to say "do user research before writing user stories." It's another to define which artifacts feed into which, who owns what, and how the handoffs work.
What the integration actually looks like
Work on this integration suggests there isn't one right answer. Researchers have proposed artifact-based models that connect Design Thinking and Requirements Engineering, with multiple strategies for tailoring the combination to a given project [Source 3]. In earlier work, three approaches were sketched out for integrating the two, each with its own synergies and trade-offs [Source 2].
The practical takeaway: how you blend design thinking with engineering work depends on what you're building, who's on the team, and how much uncertainty you're dealing with. A team building a new product for a market that doesn't exist yet needs more discovery, more prototyping, more reframing. A team adding a feature to a mature system might just need a couple of user interviews to sanity-check assumptions before writing requirements.
The research also points at open challenges that haven't been solved [Source 2]. Things like: how do you measure whether design thinking actually improved the outcome? How do you train requirements engineers to think like designers, or designers to produce artifacts that engineers can work with? These aren't rhetorical questions. They're active areas where practice is ahead of theory in some places and behind it in others.
The artifacts question
One of the more useful framings in this research is comparing what design thinking and requirements engineering each produce [Source 2]. Both are activities, but both also leave behind artifacts: documents, diagrams, prototypes, specifications, personas, journey maps, user stories, and so on.
When you compare the artifacts side by side, you start to see where they overlap and where they don't. A persona from a design thinking workshop and a stakeholder description in a requirements doc are cousins, but not the same thing. A clickable prototype and a use case specification both describe behavior, but at different fidelities and for different audiences. Mapping these out is what makes integration concrete instead of hand-wavy [Source 2].
This is also where the work gets unglamorous. Figuring out that your design team's journey map should feed into the requirements team's process model, and that the developer-facing user stories should reference the personas from research, is exactly the kind of plumbing that determines whether the two practices actually reinforce each other or just run in parallel.
What design thinking is not
A few clarifications worth making, because the term gets misused.
Design thinking isn't a methodology in the sense of a fixed sequence of steps you follow. It's a body of practice and knowledge about how designers reason [Source 1]. The five-stage diagrams you've seen (empathize, define, ideate, prototype, test, in various orderings) are teaching tools, not laws. Real practice loops back on itself constantly.
It isn't only for designers. The whole reason it's been studied as a transferable mode of working is that the patterns generalize. Engineers, product managers, and researchers all benefit from learning to reframe problems and prototype before committing.
And it isn't a replacement for engineering rigor. The point of integrating it with Requirements Engineering, rather than substituting it, is that you still need the careful specification work to actually build software [Source 3]. Design thinking helps you figure out what's worth building. Engineering helps you build it correctly. Skipping either side leaves you with a product that's either well-built and useless, or visionary and broken.
How to start using it
If you want to bring more design thinking into how you work, you don't need a workshop or a certification. You need to change a few habits.
Before you write a spec, go talk to two or three people who'll actually use the thing. Watch them work if you can. Take notes on what surprises you.
When you have an idea, build the cheapest possible version that lets you test the riskiest assumption. A paper sketch is fine. A throwaway script is fine. The goal is learning, not shipping.
When the problem feels stuck, try reframing it. Write the problem statement three different ways. Often the second or third framing is the one worth solving.
Keep the artifacts you produce in design mode (personas, journeys, prototypes) connected to the artifacts you produce in engineering mode (requirements, specs, tests). If they live in separate worlds, the integration falls apart [Source 2].
None of this is exotic. It's mostly the discipline of taking the people you're building for seriously, and doing the cheap learning before the expensive committing.
Why it sticks around
Design thinking has been written about, taught, and rebranded enough times that you'd expect the field to have moved on. It hasn't, and the reason is simple. The problems it addresses (ambiguous requirements, untested assumptions, solutions that miss what users actually need) are still everywhere in software work. As long as teams are building things for humans, there's value in a working mode that puts humans at the center and treats the problem as something to discover, not just something to solve [Source 1][Source 3].
The interesting frontier now isn't whether design thinking is useful. It's how to weave it into the rest of how software gets made, so it stops being a separate workshop activity and becomes part of the everyday practice of figuring out what to build.
