by Varun Chawla
What Design Thinking Actually Is?
Design thinking is a way of working that puts the user’s actual experience – not your assumptions about it – at the center of what you build. It has three defining features: you gather evidence before you decide, you generate many options before you pick one, and you test cheaply before you commit engineering time.
The last part is what makes it non-linear. You will define a problem, prototype against it, learn you defined it wrong, and go back. That’s not failure; it’s the mechanism working. Teams that treat the stages as a checklist to clear once get the paperwork of design thinking without the payoff.
The mindsets that matter. Empathy means understanding why users behave the way they do, not just logging what they do; analytics tells you 60% abandon at checkout; talking to ten of those users tells you it’s because the shipping cost appears there for the first time. Creativity means separating idea generation from idea evaluation, because judging an idea the moment it appears kills the ones that need development. Iteration means treating your first solution as a hypothesis rather than a plan.
Pick a framework and stop shopping. Stanford d.school uses five stages: empathize, define, ideate, prototype, test – documented in its freely downloadable Design Thinking Bootleg. IDEO’s approach emphasizes deep observational immersion. The UK Design Council’s Double Diamond splits the work into two divergence-convergence cycles: first, find the right problem; then, find the right solution, now sitting within its broader Framework for Innovation. They’re substantially the same process with different labels. The Double Diamond tends to suit startups best because it makes explicit what founders often skip: the first diamond, where you confirm the problem is real before designing for it.
Empathize With Your Users
The goal of this phase is a specific one: replace guesses with evidence about what your users are trying to accomplish and what stops them.
Talk to people, and talk to them badly on purpose. Interview 8 to 12 users in your target segment. Ask about their last experience with the problem, in detail, chronologically — “walk me through the last time you had to do this” beats “would you use a product that does this?” Users are unreliable predictors of their own future behavior and excellent reporters of their recent past. Never ask a question that lets them be polite. If everyone likes your idea, you asked the wrong questions.
Watch instead of asking, where you can. Screen recordings, session replays, support tickets, and sales call transcripts are empathy data you already own. A week of reading your own support inbox will usually surface three problems no one on the team knew existed.
Immerse yourself in the context. Building a fitness app? Train at the gym you’re designing for, at the hour your users go, on the equipment they use. Building for warehouse staff, nurses, or field technicians? Spend a shift there. Context explains behavior that looks irrational in a spreadsheet. The nurse who won’t use your tablet app because there’s nowhere to set the tablet down; the technician who works with gloves on.
This is also how you avoid designing for a market that no longer exists. The reason physical retail came back in India as a trust layer while in-chat checkout died isn’t visible in any trend deck — it shows up when you watch someone hesitate before paying for something they haven’t touched.
Name the pain points precisely. “Onboarding is confusing” is not a finding. “Users can’t tell whether their account was created because the confirmation email takes four minutes and the screen shows nothing” is a finding, because it points at a fix.
For each pain point, record how often it happens, how much it costs the user, and whether they’ve built a workaround. Frequent problems with expensive workarounds are your best opportunities – and they’re usually the shortest route to product-market fit.
Define the Problem
The output of this phase is one written problem statement your team agrees on. Without it, ideation becomes a debate about which problem you’re solving, conducted in the vocabulary of solutions.
Synthesize before you conclude. Put every observation on its own card or row. Cluster them by similarity, not by the interview they came from. Patterns show up when the same frustration appears in the words of five people who don’t know each other. Aim for three to five clusters; if you have fifteen, you’re clustering too finely.
Write the statement in the user’s terms. A workable format: [User type] needs a way to [accomplish goal] because [insight], but [obstacle]. The insight is the part that earns the research. If you could have written the statement before doing any interviews, you learned nothing.
Reframe deliberately. Ask what the problem would look like if the obvious explanation were wrong. A transportation app team assumes users want faster rides; the interviews say what users actually can’t tolerate is not knowing when the car will arrive. Speed is an engineering problem with a hard ceiling. Uncertainty is a design problem you can solve with an accurate ETA. Same data, and the second frame is the one you can act on.
Beware the reframe that’s just a rewrite. A genuine reframe changes what you would build next. If your new statement leads to the same roadmap, you haven’t reframed anything.
Ideate Solutions
Generate first, judge later, and enforce the separation. Run a timed round – 15 minutes, silent, individual, writing or sketching. Research on brainwriting consistently finds that writing ideas down before discussing them produces more ideas, and more unusual ones, than open verbal brainstorming – it removes anchoring on whoever speaks first and the status effects around who that person is. Then share, cluster, and build on each other’s work.
Force volume. Set a target – 40 ideas, not “some good ideas.” The first ten will be things you’ve already considered. Useful ideas tend to arrive after the obvious ones are exhausted and the room gets uncomfortable.
Use constraints as prompts. What would we build if we had one week? If we couldn’t build software at all? If our biggest competitor had already shipped the obvious version? If the user had no internet? Constraints break the default solution loose.
Then evaluate on stated criteria. Score the shortlist against three things: does it address the defined problem, can we test it in under two weeks, and what happens if we’re wrong? Cheap-to-test ideas beat impressive ones at this stage, because you’re buying information, not shipping a product.
Challenge the convention that’s load-bearing. Every category has an assumption everybody shares — that this kind of software needs an admin dashboard, that the free tier needs a credit card, that onboarding requires a tutorial. Pick one and ask what happens if it isn’t true. Most of the time the answer is nothing interesting. Occasionally it’s your entire product.
Prototype
A prototype’s job is to answer a specific question at the lowest possible cost. Before you build one, write down the question. If you can’t, you’re building a demo.
Match fidelity to the question. Will people understand the concept? A landing page or a one-page sketch. Will they choose this flow over that one? Clickable screens in Figma. Will the workflow survive real use? A concierge version where your team does the work manually behind a simple interface. Will the algorithm hold up? A spreadsheet with real data. None of these is an MVP — a prototype answers a question; an MVP is the smallest thing you’d charge for. The concierge and Wizard of Oz variants are the cheapest of the lot and the most underused: you do the work by hand while the customer experiences a finished product.
Keep it deliberately rough. Polished prototypes get polite feedback, because testers assume the decisions are already made and they’d be rude to question them. Rough prototypes get honest reactions. Roughness is a feature.
Build the risky part, not the easy part. Teams prototype what they know how to build. Prototype the assumption that would hurt most if it were false.
Iterate in short cycles. One week per loop: build, test with three to five users, decide. Longer cycles let you fall in love with a version before you find out it doesn’t work.
Test and Refine
Test with people who aren’t in the room. Jakob Nielsen’s case for five users still holds for qualitative testing: a small round surfaces most usability problems, and past that you’re re-hearing the same issues. The part people forget is the rest of his argument — spend the saved budget on more rounds, not more participants. Five users three times beats fifteen users once. Add participants only when you’re serving genuinely distinct user groups, who need their own small rounds.
Give them a task, not a tour. “Set up a project and invite a teammate.” Then stop talking. Silence is data. Every time you explain how something works, you’ve found something that needs to work without explanation.
Separate what they say from what they do. Note where they hesitate, backtrack, or misread a label. Behavior is more reliable than commentary. “This is nice” from someone who took four minutes to find the button means the button is the finding.
Refine, then re-test. Fix the issues that blocked task completion first, cosmetics last. If the same problem survives two rounds of fixes, your model of the problem is wrong, which sends you back to Section 3 — this is normal, and it’s cheaper here than after launch.
Set a stopping rule in advance. Something like: three consecutive users complete the core task unaided. Without a rule, you either ship at the first encouraging session or refine indefinitely.
Implement
Write the plan as decisions, not activities. What ships in v1 and what explicitly doesn’t. Who owns each piece. What date. What you’ll measure in the first 30 days and what number would tell you to change course. A launch plan without a kill criterion is a launch plan you can’t learn from.
Carry the research forward. The findings that shaped the design should travel with it into engineering, or they get quietly optimized away — the confirmation state gets cut for scope, the four-minute email problem reappears. Attach the why to the ticket.
Handle the unglamorous requirements early. Accessibility, DPDP consent handling if you’re holding customer data in India, payment and tax compliance, localization, support documentation. These are cheapest to build in and most expensive to retrofit. If you’re building a company where impact is part of the product rather than a report at year-end, the same logic applies to measurement; what B Corp certification actually took us was mostly evidence we should have been collecting all along.
Ship narrow. One segment, one use case, done properly. It’s easier to expand from a product that works for a small group than to rescue one that half-works for everyone.
Making It Stick Culturally
Design thinking fails in startups for organizational reasons far more often than methodological ones. Some things that make it hold:
Everyone talks to users. Engineers and founders included, on a fixed cadence – one session each per month is enough to change how a team argues. Secondhand research doesn’t transfer conviction, and conviction is what makes teams act on findings.
Decisions cite evidence. Make it normal to ask “what’s that based on?” and normal to answer “nothing yet, it’s a guess.” A team that can say the second sentence out loud is a team that will go get data. This is culture work, not process work — it depends on whether being wrong out loud is survivable. It also gets easier with outside pressure-testing: the assumptions you can’t see in your own company are obvious to a founder eighteen months ahead of you, which is most of the value of a dense founder community.
Cross-functional from the start. Design, engineering, and whoever talks to customers in the same room during define and ideate. Handoffs lose the reasoning and produce solutions that are elegant and unbuildable, or buildable and pointless.
Protect the divergence. In a startup, the pressure is always toward the first plausible answer, because shipping feels like progress. Someone senior has to hold the space open long enough for a second and third option to exist.
9. The Predictable Obstacles
Not enough time. The real trade-off isn’t research versus speed; it’s a week of research versus a quarter building the wrong thing. Compress rather than skip – five interviews in two days is not rigorous, and it’s dramatically better than zero. Forced compression is also most of what a good accelerator program does to a team: a fixed cohort deadline makes the discover-define loop happen in weeks instead of never.
Founder conviction. The intuition that got you started becomes the thing that stops you from learning. Write your assumptions down, explicitly, as claims that could be false. Written assumptions can be tested; unexamined ones just get defended.
Feedback that contradicts the roadmap. Sort it: is this one user’s edge case, or the third time you’ve heard it? Frequency and severity decide, not who said it or how loudly. And when the evidence says the roadmap is wrong, changing the roadmap is the whole point of having gathered it.
Theater instead of practice. Workshops, sticky notes, and a persona deck nobody opens. The test of whether design thinking is real in your company is simple: name a decision in the last month that user evidence changed. If you can’t, you have the vocabulary and not the practice.
Measuring Whether It’s Working
Outcome metrics. Task completion rate, time to first value, activation, retention at 30 and 90 days, support ticket volume per active user. These tell you whether the product works. Watch the direction over releases rather than the absolute number, and tie them to your north star metric rather than reporting them loosely.
Satisfaction, with a caveat. NPS and CSAT are useful trend lines and terrible diagnostics. They tell you something changed, not what. Pair every score with the open-text response, and read the text.
Market signal. Conversion, expansion revenue, referral rate, churn reason codes. Churn reason codes are the most underused dataset most startups have: the exit interview you never conduct.
Process metrics. Cycle time from problem statement to tested prototype. Number of user conversations per month. Percentage of shipped features that hit their stated success metric. Expect this to be sobering, and expect it to improve. A team that finds out it’s wrong in two weeks beats a team that finds out in two quarters, and that gap is the entire return on doing this properly.
