Design thinking for software: skip the Post-its, build the product

Design thinking has a branding problem. Mention it to a founder and they picture a conference room full of consultants sticking Post-it notes on a wall, generating “ideas” that go nowhere. Two days of workshops, a 60-slide PDF, and zero shipped product.

That’s the corporate version. The version we’re talking about is different: a 5-step process that reduces development waste by 40% by making sure you build what users need instead of what you assume they want. It’s the difference between spending $50,000 on a product nobody uses and spending $5,000 to find out before you write a line of code.

Every product we’ve built that skipped user research required at least one major pivot after launch. Every product that started with design thinking shipped closer to right the first time. Not perfect — closer. And “closer” saves $15,000-$30,000 in rework.

The 5 steps, applied to real software projects

Step 1: Empathize — talk to the humans who’ll use this

Interview 5-8 potential users. Not your friends. Not your investors. The people who have the problem your product solves. Ask them:

• How do you currently solve this problem?
• What’s the most frustrating part of your current process?
• What have you tried that didn’t work?
• How much time/money does this problem cost you?

Do NOT ask: “Would you use an app that does X?” People say yes to hypothetical products. They say yes to be polite. The data you need is about their current pain, not their opinion of your solution.

One founder we worked with was building a booking system for hair salons. She assumed the main problem was “clients forget their appointments.” After 6 interviews, she learned the real problem was “salon owners spend 3 hours every Sunday managing next week’s schedule in a spreadsheet.” The product pivot saved her $25,000 because the appointment reminders feature she would have prioritized was worth $2,000. The scheduling engine was worth $35,000.

Step 2: Define — turn pain into a problem statement

Take your interview data and write one sentence: “[User type] needs a way to [do something] because [pain point].”

Not: “We need to build a marketplace.” That’s a solution disguised as a problem.

Instead: “Freelance designers need a way to find clients without spending 15 hours/week on cold outreach because they lose 30% of their productive time to sales.”

This sentence becomes the filter for every feature decision. Does this feature help freelance designers find clients faster? Yes → consider it. No → cut it. The product-market fit validation process starts here — with a problem worth solving, confirmed by real users.

Step 3: Ideate — generate solutions, then kill 80% of them

Brainstorm solutions to the problem statement. Not features — solutions. “What if we…” not “we should add…”

The goal is quantity, then ruthless filtering. Generate 15-20 ideas in 30 minutes. Then filter by three criteria:

1. Does it solve the defined problem? (Not a different problem. The one from Step 2.)
2. Can we build it in 8-12 weeks? (If not, it’s too big for V1.)
3. Does it require technology that exists and is proven? (If it requires AI that doesn’t work yet, save it for V3.)

Most teams end up with 3-5 viable ideas. These become the feature set for the prototype. Not a 40-feature product — a focused solution to a validated problem.

Step 4: Prototype — build it in days, not months

A prototype is not an MVP. An MVP works. A prototype demonstrates. It can be a clickable Figma file, a no-code tool, or a hardcoded demo — whatever communicates the concept fastest.

Budget: $2,000-$5,000 and 3-5 days. If your prototype takes more than a week, it’s too detailed. The goal is to test a hypothesis, not ship a product.

We use Figma for most prototypes. Clickable screens, realistic data, transitions between pages. Users tap through it on their phones and we watch where they get stuck, what they misunderstand, and what delights them.

A wireframe is the skeleton. A prototype adds skin — enough for someone to react to it. Not enough to confuse a demo with a finished product.

Step 5: Test — watch 5 users break your assumptions

Sit 5 users in front of the prototype and give them a task: “Book an appointment with Provider X for next Tuesday at 2pm.” Don’t guide them. Don’t explain the interface. Watch.

Jakob Nielsen’s research (NNGroup, confirmed across 83 studies): 5 users find 85% of usability problems. Not 50 users. Not a survey. Five people using your prototype while you take notes.

What you’re watching for:

• Where do they tap first? (If it’s wrong, the hierarchy is broken)
• Where do they hesitate? (That’s a clarity problem)
• Where do they make errors? (That’s a design problem)
• What do they say out loud? (“Wait, where do I…” = redesign that screen)

After 5 tests, you’ll have a prioritized list of fixes. Apply them. Test again if the changes were significant. Then — and only then — start building.

The 5-day design sprint format

For projects under $50,000, we compress the full design thinking process into 5 days:

Day	Activity	Output
Monday	User interviews + problem definition	Problem statement, user profiles
Tuesday	Ideation + feature filtering	3-5 solution concepts
Wednesday	Prototype design — screens and flows	Clickable Figma prototype
Thursday	Prototype refinement + test prep	Polished prototype, test script
Friday	5 user tests + debrief	Validated concept, prioritized fixes

Total cost: $3,000-$5,000. The output: a tested prototype that tells you exactly what to build, what to cut, and what to change. This becomes the input for your product requirements document and development scope.

When to skip design thinking

Not every project needs the full process.

Skip it when: You’re building a standard CRUD app with clear requirements. A client portal. A content management system. An admin dashboard. The UX design principles still apply, but the discovery phase isn’t necessary — the problem space is well-understood.

Don’t skip it when: You’re building something where user behavior is uncertain. A consumer app. A marketplace. A product in a competitive space. Anything where “will people actually use this?” is a real question.

The cost of a 5-day sprint is $5,000. The cost of building the wrong product is $30,000-$80,000. That’s not a close decision.

---

Want to run a design sprint before writing code? We facilitate the entire 5-day process — interviews, prototyping, testing — and hand you a validated concept ready for development. Start a sprint.