Solve Business Problems Creatively with Design Thinking

Most expensive business mistakes aren’t bad solutions. They’re good solutions to a problem nobody checked.

A bakery loses wholesale accounts and assumes it’s price, so it cuts margins. The real reason was arrival times drifting into the middle of the lunch rush. The discount didn’t help, because the problem was never price, and nobody had asked.

Design thinking is a structured way to avoid that. It’s a human-centred process for understanding a problem from the perspective of the people experiencing it, before committing to a fix. Five stages: empathise, define, ideate, prototype, test. The heavy lifting happens in the first two, which is the opposite of how most businesses spend their time.

This guide covers how to run each stage in a small business without a design department. Design thinking sits at the front of the wider agile approach to managing operations and deliveries; it’s the method for problems you can’t name yet.

The Bottom Line

• Design thinking’s five stages are empathise, define, ideate, prototype, test, and they loop rather than run once (Nielsen Norman Group).
• The output of the first two stages is a specific problem statement. If you can’t write one, you’re not ready to choose a solution.
• Watch what people do, not what they say they do. The gap between the two is where the useful findings live.
• Prototype cheaply enough that abandoning the idea costs you nothing.

The five stages of design thinking, and what each one produces

Each stage has an output. If a stage doesn’t produce its output, moving on just carries the guesswork forward.

Empathise. Understand the experience of the people involved. Output: notes from real observation and conversation, not assumptions.

Define. Narrow what you found into one specific problem statement. Output: a sentence naming who has the problem, what it is, and why it matters to them.

Ideate. Generate options without filtering. Output: a list of possible approaches, including the unreasonable ones.

Prototype. Build the cheapest possible version of the most promising option. Output: something a real person can react to.

Test. Put it in front of the people from stage one. Output: evidence, and usually a return to an earlier stage.

The stages aren’t strictly linear. Testing frequently reveals that the problem was defined wrong, sending you back to empathise with better questions. That’s the process working, not failing.

The common shortcut is to jump from a vague complaint straight to ideate, because generating ideas is enjoyable and interviewing customers isn’t. That shortcut is how businesses end up with the discount that didn’t fix the delivery-time problem.

How to run customer interviews that tell you something

The empathise stage is mostly watching and asking. Both are harder than they sound, because people are unreliable narrators about their own behaviour. Not dishonest, just imprecise and inclined to be polite.

Three rules cover most of it.

Ask about the past, not the future. “Would you use a Saturday delivery slot?” produces a courteous yes. “Walk me through what you did the last time an order arrived too late to use” produces facts. Past behaviour is observable; future intentions are imagination.

Ask why, repeatedly. The first answer is the polished one. “The deliveries are unreliable” becomes, three whys later, “they arrive between 11 and 2, and I can’t take a pallet in during service.” That second sentence you can act on. The first you can’t.

Watch rather than ask where possible. Go to a customer’s back door at delivery time. Ride along on the route. Stand in the kitchen while an order is unpacked. Fifteen minutes of watching routinely surfaces things nobody thinks to mention, because to them it’s just how things are.

Six to eight conversations is usually enough to see patterns in a small business. You’re not surveying; you’re looking for the thing three people mention in different words.

Talk to the people who left, too. Churned customers know something your happy ones don’t, and they’re often willing to say it plainly.

Include your own staff

Drivers, packers and counter staff are inside the problem all day. They’ve usually diagnosed it already and either weren’t asked or weren’t believed. Start there, because it’s the cheapest research available.

Writing a problem statement you can act on

The define stage turns a pile of notes into one sentence. It’s the highest-value step and the one most often skipped.

A usable problem statement names three things: who, what, and why it matters.

Weak: “Our delivery service needs improvement.”

Usable: “Wholesale customers can’t receive pallets between 11am and 2pm because they’re in service, but a third of our drops land in that window, so stock sits on the pavement or gets refused.”

The second version is testable, narrow enough to solve, and immediately suggests where to look. It also rules things out, which is most of its value: it tells you the answer probably isn’t a discount.

Two tests for a problem statement. Does it describe a problem rather than a missing solution? “We need route optimisation software” is a solution wearing a problem’s clothes. And is it specific enough that you’d know if you’d fixed it?

If your notes produce three problem statements, pick one. A business that fixes one specific thing well beats one that addresses three vaguely.

Prototyping and testing without a budget

A prototype is anything that lets a real person react to your idea before you’ve committed to it. For a local business that’s rarely a physical object.

Cheap prototypes that work:

• Run it manually for a week. Want to test a 7am delivery window for the three affected accounts? Do it by hand for a week before rebuilding the schedule.
• Mock up the artefact. A sample delivery-notification message, a redesigned order form, a one-page delivery agreement. Show it to three customers and watch where they hesitate.
• Walk through the scenario aloud. Sit with a customer and narrate the proposed process step by step. They’ll interrupt at the point it breaks, and that interruption is the finding.
• Change one route for one day. Cheap, reversible, and real.

The rule is that abandoning the prototype should cost you nothing. The moment a prototype becomes expensive, you start defending it instead of learning from it.

Testing means putting it in front of the same people from the empathise stage and watching. Not asking whether they like it, but watching whether it resolves the thing they described. Liking is not the metric.

When the test says the idea works, the next question is whether it works at a price and volume that sustains it, which is a different method: Lean Startup’s build-measure-learn loop exists for exactly that commercial question.

Where design thinking fits alongside the other methods

Design thinking answers “what is the actual problem?” Once you’ve got that, three other methods take over, and using the wrong one wastes the diagnosis.

If the answer is a new offering whose demand is unproven, such as a new zone, a new service or a new day, that’s an experiment, and Lean Startup tests it before you buy capacity.

If the answer is a defined project with an end state, such as rebuilding the schedule or migrating the ordering process, that’s Scrum: a prioritised backlog, fixed sprints, a review at the end of each.

If the answer turns out to be a flow problem, where work piles up in one stage, that’s Kanban: put the work on a visible board and cap what’s in each column.

Design thinking is also the one to reach for when a problem keeps coming back after being fixed. Recurrence usually means the original diagnosis was wrong, not that the fix was executed badly.

A worked example: late deliveries

Take the common complaint that deliveries are unreliable.

Empathise. Ride along on two routes. Call four customers, including one that left. Ask each to describe the last time a delivery went badly. Ask the drivers what makes a day go wrong.

Define. The notes converge: wholesale accounts can’t receive between 11am and 2pm, and a third of drops land there because the route is ordered by geography rather than by when each customer can take stock.

Ideate. Reorder routes by receiving window rather than distance. Split into a morning and an afternoon run. Give customers a two-hour notification so someone’s ready. Move three accounts to a different day.

Prototype. For one week, reorder one route by receiving window. Nothing else changes.

Test. Count refused and re-attempted drops that week against the previous month, and call the three affected accounts.

The finding might be that it worked, or that reordering by window added forty minutes of driving that cost more than it saved, which sends you back to ideate with a better-understood constraint. Either result is worth more than the discount nobody asked for.

Tooling helps here mostly by making the test cheap. Metrobi’s route optimisation and customisable automated notifications on dispatch and progress mean reordering a route or giving customers advance warning is a change you can try for a week rather than a project you have to commit to.

Frequently asked questions

What are the five stages of design thinking?

Empathise, define, ideate, prototype and test. They loop rather than run once, and testing often sends you back to redefine the problem (Nielsen Norman Group).

How many customers do I need to talk to?

Six to eight is usually enough for a small business to see patterns. You’re looking for the same issue described in different words by several people, not for a statistically representative sample. Include at least one customer who stopped buying from you.

What makes a good problem statement?

It names who has the problem, what specifically happens, and why it matters to them, and it describes a problem rather than a missing solution. “We need better software” fails both tests. “Customers can’t receive during service hours, but a third of drops land there” passes.

Isn’t design thinking just for designers?

No. The stages describe a general approach to diagnosing problems from the perspective of the people experiencing them, and it’s applied across healthcare, education and service businesses. The only requirement is access to the people affected, which a small business has more of than a large one.

Start with the complaint you’ve stopped hearing

The problems worth running this on are usually the ones that have been normalised: the recurring complaint everyone has learned to work around, the account that’s been “difficult” for two years.

Pick one. Go and watch it happen. Then write one sentence naming who has the problem and what specifically goes wrong. You’ll often find the fix is smaller and cheaper than the one you were about to buy.