Design Thinking in Software Development: The Process That Makes Products Better

Design Thinking in Software Development

"We built exactly what was in the requirements." "Yes, but users aren't using it."

This conversation happens daily in companies. The problem: We build what's requested - not what's needed.

Design Thinking solves this problem. It puts users at the center and leads to products people actually want to use.

Table of Contents

1. What is Design Thinking?
2. The 5 Phases of the Process
3. Design Thinking vs. Agile
4. Practical Application in Tech Projects
5. Tools and Methods
6. Case Studies
7. Avoiding Common Mistakes
8. FAQ

---

What is Design Thinking?

Design Thinking is a user-centered problem-solving approach that leads to innovative solutions through empathy, creativity, and iteration.

The Core Principles

1. User-centricity: Understanding what people really need
2. Interdisciplinary teams: Bringing together different perspectives
3. Prototyping: Making ideas tangible early
4. Iteration: Learning fast, adapting fast
5. Experimentation: Understanding mistakes as learning

Where Does Design Thinking Come From?

The approach was developed at Stanford d.school and popularized by design agency IDEO. Today it's used by companies like Apple, Google, SAP, and Airbnb.

Why It's Relevant for Software

Traditional Development	With Design Thinking
Requirements → Code → Release	Understand → Ideate → Prototype → Test → Build
Assumptions about users	Validated insights about users
Late user feedback	Continuous user feedback
Expensive changes	Early, cheap corrections

---

The 5 Phases of the Process

Phase 1: Empathize

Goal: Understand the world from users' perspective.

Activities:

• User interviews (not requirements workshops!)
• Observation in real context
• Shadowing (accompanying users at work)
• Customer journey mapping

Questions:

• What frustrates users currently?
• What workarounds have they developed?
• What are their actual goals (not stated ones)?
• What emotions are involved?

Output: Empathy maps, persona drafts, journey maps, quotes & insights

Time investment: 1-2 weeks (at least 5-10 interviews)

Phase 2: Define

Goal: Formulate the right problem.

Activities:

• Synthesize insights
• Recognize patterns
• Formulate problem statement (POV)
• Develop "How Might We" questions

The Point of View (POV) Template:

[User] needs [need] because [insight].

Example: "A mid-sized company accountant needs a way to capture invoices in 10 seconds because they process 50 invoices daily and the manual process takes 3 minutes per invoice."

How Might We (HMW) Questions:

• HMW automate invoice capture?
• HMW eliminate data entry errors?
• HMW give the accountant time for strategic tasks?

Output: Problem statement, HMW questions, prioritized insights

Phase 3: Ideate

Goal: Generate as many solution ideas as possible.

Activities:

• Brainstorming (with rules!)
• Crazy 8s (8 ideas in 8 minutes)
• Brainwriting
• SCAMPER method
• Analogies from other industries

Brainstorming Rules:

1. Quantity over quality
2. No criticism during ideation
3. Build on others' ideas
4. Encourage wild ideas
5. Visualize

Idea Evaluation: After brainstorming, cluster and prioritize:

• Impact vs. effort matrix
• Dot voting
• Feasibility check

Output: 50-100+ ideas, clustered and prioritized

Phase 4: Prototype

Goal: Make ideas tangible and testable.

Types of Prototypes:

Type	Description	Effort
Paper Prototype	Sketches on paper	30 min
Clickable Prototype	Figma, Sketch, InVision	1-3 days
Wizard of Oz	Human simulates technology	1 day
Concierge MVP	Deliver service manually	1-2 weeks
Functional Prototype	Minimal code	1-4 weeks

The Golden Rule:

"If you're not embarrassed by the first version of your product, you've launched too late." - Reid Hoffman (LinkedIn)

Output: Testable prototype (as simple as possible)

Phase 5: Test

Goal: Learn what works and what doesn't.

Activities:

• Usability tests with real users
• A/B tests (if possible)
• Observe, don't explain
• Collect feedback

Testing Rules:

1. Stay neutral ("You're testing the prototype, not yourself")
2. Observe what users DO, not just what they SAY
3. Ask "why"
4. Notes visible to all
5. Iterate quickly

What You Want to Learn:

• Do users understand the concept?
• Can they complete core tasks?
• Where do they get stuck?
• What surprises you?

Output: Validated/invalidated assumptions, improvement suggestions, next iteration

---

Design Thinking vs. Agile

The Differences

Aspect	Design Thinking	Agile
Focus	Find & understand problem	Build & deliver solution
Question	What should we build?	How do we build it?
Output	Validated concept	Working product
Timing	Before development	During development

Combination: Double Diamond

The Double Diamond model shows how both fit together:

         Discover → Define → Develop → Deliver
             ↘         ↙        ↘         ↙
              Diamond 1          Diamond 2
           (Design Thinking)      (Agile)

Integration in Scrum

Sprint Phase	Design Thinking Activity
Refinement	Bring in user research insights
Planning	Prototypes as requirements basis
Sprint	Usability tests parallel to development
Review	Integrate user feedback
Retro	Reflect on design learnings

---

Practical Application in Tech Projects

Use Case 1: New Feature

Without Design Thinking:

1. PM writes user story
2. Developer builds feature
3. Users complain
4. Redesign needed

With Design Thinking:

1. User interviews: What's the problem?
2. Define problem: What exactly are we solving?
3. Generate ideas: What solutions exist?
4. Build prototype: Low-fidelity test
5. Test: Does it work?
6. Only then: Development

Use Case 2: Product Restart

Situation: Existing product isn't being used.

Design Thinking Approach:

1. Empathize: Why aren't people using it?
2. Define: What's the actual problem?
3. Ideate → Prototype → Test: Iterate until solution

Use Case 3: Internal Tools

Common Mistake: Building internal tools without Design Thinking because "we know the users."

Reality: Internal users are just as demanding - and if the tool is annoying, workarounds emerge.

---

Tools and Methods

For Empathize

Empathy Map:

        SAYS           |          THINKS
  What does user say?  | What do they really think?
-----------------------|----------------------------
        DOES           |          FEELS
   What does user do?  | What do they feel?

For Define

Jobs to be Done (JTBD): "When [situation], I want to [motivation], so I can [outcome]."

For Ideate

Crazy 8s:

1. Fold paper 8 times
2. Sketch 8 ideas in 8 minutes
3. No censorship
4. Share and discuss

For Prototype

Paper Prototypes: Fast, cheap, no software needed

Figma/Sketch: Clickable prototypes in hours

For Test

5-Second Test: Show prototype 5 seconds, ask: "What's it about?"

Task-Based Usability Test: "Find feature X and use it."

---

Case Studies

Airbnb: From Bankruptcy to Billions

Problem: In 2009, Airbnb was almost bankrupt. Nobody was booking.

Design Thinking Approach:

• Founders visited hosts personally
• Realized: Bad photos of apartments
• Solution: Offer professional photography

Result: Bookings increased immediately. Today: $80B valuation.

IBM: Enterprise Design Thinking

Problem: IBM built products nobody wanted to use.

Solution: Enterprise Design Thinking program

• 10,000+ employees trained
• Design studios in every area
• User research mandatory

Result:

• 75% faster time-to-market
• 300% return on investment

---

Avoiding Common Mistakes

Mistake 1: Design Thinking as Workshop Event

Problem: A 2-day workshop, then back to normal.

Solution: Design Thinking as continuous process, not event.

Mistake 2: Starting with Solutions

Problem: "We want to build an app. Do some Design Thinking."

Solution: Start with the problem, not the solution.

Mistake 3: Not Really Asking Users

Problem: "We know our users" (based on assumptions).

Solution: Real users, real conversations, real observation.

Mistake 4: Staying in Process Too Long

Problem: Endless Empathize phase, never get to building.

Solution: Timebox. 2 weeks Empathize, then move on.

Mistake 5: Only Designers Do Design Thinking

Problem: Developers get "finished" concepts.

Solution: Cross-functional teams from the start.

---

Conclusion

Design Thinking isn't a replacement for good development - it's the prerequisite for it. Before writing a line of code, you should know:

1. Who has the problem?
2. What's the actual problem?
3. Why is it important?
4. Which solution works?

The investment in these questions saves months of development time for features nobody uses.

At Balane Tech, we start every project with the user, not with code. Contact us for more information.

---

FAQ

How long does a Design Thinking process take?

Minimal 2 weeks (sprint format), typically 4-8 weeks for complex problems. Can also run as continuous process.

Do I need a professional designer?

Not necessarily. Anyone can learn the methods. For high-quality visual prototypes a designer helps, but for paper prototypes common sense is enough.

Does Design Thinking work for B2B software?

Especially well. B2B users often have more complex problems and more workarounds. The insights are gold.

What if users don't know what they want?

That's normal - and exactly why Design Thinking. You don't ask "What do you want?" but observe problems and test solutions.

How do I convince my management?

ROI arguments: Less misdevelopment, faster time-to-market, higher user acceptance. IBM reports 300% ROI.

Is Design Thinking only for new products?

No. Existing products also benefit: Feature prioritization, redesigns, problem analysis for poor adoption.