Most product leaders can recite the five stages of the design thinking process: empathize, define, ideate, prototype, and test. Far fewer can point to a single decision last quarter that changed because of what happened in stage four. And scaling companies quietly lose quarters, budget, and goodwill because of the gap between vocabulary and reality.
Teams are shipping more, faster, and breaking more in the process. According to the 2025 DORA report, 90% of nearly 5,000 surveyed technology professionals now use AI at work, and more than 80% say it increased their productivity. However, while there's a positive relationship between AI adoption and delivery throughput, there's also a negative relationship with delivery stability.
When execution gets cheap, judgment becomes the constraint, and that's the argument for treating the design thinking process and the engineering design process as one continuous system rather than two departments with a handoff. This article covers what each process actually does, where the engineering and design process breaks at scale, and how to build an optimized process design that pays for itself in avoided rework.
What is the Design Thinking Process in Software Development?
Design thinking is a human-centered, iterative method for solving ambiguous problems around empathizing, defining, ideating, prototyping and testing stages. In software, it reduces the cost of being wrong before engineering capacity gets committed to a direction.
IDEO's Tim Brown frames it as an approach that "draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success," as documented on IDEO's design thinking hub. The hub also prioritizes a three-part test of desirability, feasibility, and viability above the known five stages.
Design thinking also has formal standing, with human-centered design codified in the international standard ISO 9241-210:2019 that specifies design activities across the full lifecycle of interactive systems. This standard codifies what mature teams already practice: explicit understanding of users and context, iteration driven by user-centered evaluation, and multidisciplinary teams rather than sequential specialists.
The business case is equally well documented, as evidenced by McKinsey's Design Index, which tracked 300 public companies over five years and found that top-quartile design performers delivered 32% higher revenue growth and 56% higher total shareholder returns. The second, third, and fourth quartiles were barely distinguishable from one another: the market rewarded genuine outliers and ignored incremental effort. Supporting this statement, Maze's 2026 Future of User Research Report found that 66% of practitioners reported increased demand for research, up from 55% the prior year, and that organizations treating research as essential at all levels of strategy nearly tripled, from 8% to 22%.
How Does the Engineering Design Process Differ From Design Thinking?
The engineering design process begins with a defined problem and converges on a buildable, testable solution, while the design thinking process begins with an undefined human need and deliberately diverges before converging. One optimizes the answer, and the other interrogates the question.
The canonical sequence is laid out in NASA JPL's engineering design framework: identify the problem, brainstorm solutions, select a design, build a prototype, test and evaluate, then either share the solution or cycle back to building and testing. The loop between build, test, and refine is the point, and engineering design never assumes a first attempt would hold.
Both the engineering design process and design thinking involve prototyping, testing, and iterating against evidence. The meaningful difference lies in what's put at the front: while design thinking focuses on establishing that the problem is worth solving and that the proposed solution is desirable, engineering design assumes the work is complete and optimizes for feasibility, constraint satisfaction, and reliability.
At the business level, problems arise when an organization relies on a single process. Teams that run pure engineering design build beautifully engineered answers to questions nobody asked; teams that run pure design thinking generate compelling concepts that collapse on contact with load, latency, compliance, or cost. A functioning engineering and design process connects the two so that desirability evidence and feasibility evidence arrive close enough in time to influence the same decision.
Frequency of contact is not the same as shared understanding. Figma's design research found that 91% of developers and 92% of designers believe the handoff process could be improved, even though 84% of designers collaborate with developers at least weekly.
The Stages of the Design Thinking Process for Digital Products
Design thinking maps cleanly onto digital product work when each stage is defined by the artifact it must produce and the decision it must unblock.
- Empathize: Direct exposure to the people who use the product, in their context, doing their actual job. Output: an evidence log of observed behavior.
- Define: A single problem statement, written jointly by product, design, and engineering. Output: a one-page framing that all three functions sign.
- Ideate: Divergent option generation with an explicit rule that quantity precedes judgment. Output: at least three genuinely different approaches, including one that solves the problem without building software.
- Prototype: The cheapest artifact that can produce a real signal. Output: something a user can react to inside days rather than a quarter.
- Test: Structured evaluation against pre-set criteria, with the authority to change scope or stop the initiative. Output: a decision with a date on it.
There are two structural conditions that determine whether these stages compound or evaporate. The first condition is a governed design system, which turns cycles' learning into reusable material. The 2026 Design Systems Report found that only 7% of design systems reach full adoption across all teams, 61% of design system teams feel understaffed, and just 5% measure return on investment at all. The second condition is for product and UX discovery to run continuously so evidence arrives while decisions are still reversible.
Engineering and Design Process at Series B
The engineering and design process breaks down at scale because the informal coordination that worked for 12 people stops working for 60, and most organizations replace it with ceremony rather than structure. Three failure modes account for most damage.
- Proxy users replace real ones. As companies grow, the distance between the team and the user widens. Sales anecdotes, support tickets, and executive intuition replace direct evidence, but the substitution is invisible because it produces confident decisions.
- Throughput gets mistaken for progress. An analysis of 623 million code changes found that block duplication reached 81%, copy-and-paste climbed to 15.7% of changed lines, cross-file function calls dropped 35%, and error-masking constructs rose 47%. Output went up, but adaptability went down. A codebase that cannot be changed cheaply cannot support an iterative design process, regardless of how much research sits upstream of it.
- Structure arrives without governance. Teams recognize the drift and reach for artifacts (a design system, a discovery ritual, a new framework), but then they under-resource the thing they just adopted. Data shows satisfaction with leadership buy-in for design systems dropping to 32% from 42% the previous year. An unadopted system is a second source of truth, which is worse than no source at all and compounds the risk of rework.
How To Build an Optimized Process Design for Product Teams
Optimized process design is the practice of tuning the engineering and design process so that the cost of learning remains consistently below the cost of being wrong. It's a calibration exercise that rests on five decisions a founder or product leader can make:
- Set a rework budget and instrument it. Treat rework percentage as a first-class metric with an owner and a target. Nothing else survives a budget conversation without it.
- Move the decision point upstream. The engineering design process should receive a problem statement, not a solution specification. When engineering inherits a predetermined answer, feasibility feedback arrives too late to be of any value.
- Attach a kill criterion to every significant bet. Define in advance what evidence would make you stop. Teams that cannot articulate this are running commitments with a research budget attached, which is a costly way to buy confirmation.
- Protect refactoring capacity explicitly. Reserved capacity for structural work is what keeps the iterative design process economically viable in year three.
- Govern the design system like infrastructure. Named ownership, a documented contribution path, versioning, and adoption metrics. Coverage without governance is drift with extra steps.
Gartner projects that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. Interaction models are being redrawn, while most roadmaps assume the current ones remain. Organizations that can run a tight learning loop will absorb that shift. Operationally, this is where ProductOps earns its keep by making the loop repeatable across teams rather than dependent on individual discipline.
How To Measure the ROI of a Design Thinking Process?
To measure the design thinking process, track changes in decisions and rework avoided. Output metrics tell you the machine is running, but decision metrics tell you it is running in the right direction. Four measures cover most of the ground.
- Rework as share of capacity: The cost of decisions made without evidence.
- Feature adoption against pre-set threshold: Whether desirability was validated or assumed.
- Time from user signal to shipped response: Speed of the full engineering and design process loop.
- Decision reversal rate on new evidence: Whether the organization can actually learn.
There's a fourth metric that separates mature organizations from performative ones: a reversal rate of zero almost always means the organization has quietly agreed to ignore inconvenient findings.
Only 5% of design system teams measure ROI at all, and 61% worry about the quality of AI-generated design output, yet lack the instrumentation to detect it. Meanwhile, treating engineering design and human-centered design as a single measured system outperforms by wide margins, and everyone else clusters indistinguishably in the middle.
When the design thinking process and the engineering design process run as one measured loop, clarity stops being a workshop output. It becomes the mechanism that keeps a product adaptive as it scales. Shaped Clarity™ is the difference between a roadmap that survives new evidence and one that resets every quarter. Learn how to scale with purpose.
Conclusion
The design thinking process and the engineering design process are two halves of the same question: one asks whether a thing should exist and the other asks whether it can be built to last. An optimized process design captures returns by keeping the cost of learning lower than the cost of being wrong and by ensuring evidence can change decisions.
Cut rework and build a product process that holds as you scale: contact us or book a call.
