31 Oct Design Thinking, Explained With a Real Project
Part 7 of UX Foundations for Small Business Websites — a series on the UX principles I use in client work, and this one is about design thinking.
“Design thinking” is one of those phrases that sounds like it belongs in a boardroom with sticky notes and a facilitator. I’ll be honest: I rolled my eyes at it for years. Stanford’s d.school publishes a starter kit of design workshop activities and templates you can run through yourself.
Then I watched my own process honestly and realized I’d been doing a version of it on client sites all along — just without the name. It’s not a ceremony. It’s a discipline for not solving the wrong problem beautifully. Here’s how it works, the way I actually run it on website projects.
Step 1 of design thinking: Understand the people first
Everything starts with paying attention to the humans on the other side of the screen — what they’re trying to do, what frustrates them, what their situation looks like. Interviews, observation, the research habits from the previous post in this series: that’s this step.
For a festival site like NC Freedom Fest, that means thinking past “attendees” to the real moments: the parent checking the lineup in the car, the veteran’s family looking for what’s accessible and where to sit, the sponsor deciding whether this event is worth putting their name on. If I skip this, I’m designing for a crowd in my imagination.
Step 2: Name the actual problem — in one sentence
This is the step everybody rushes, and it’s the most valuable one in the whole process.
Clients usually arrive with a solution already in mind: “we need a new homepage.” “we need an app,” “we need a bigger donate button.” Sometimes they’re right. Often, the sentence underneath is different: “people can’t find the schedule, so they message us on Facebook all weekend.” Or: “guests visit our church site, but they can’t tell what a Sunday morning actually looks like, so they don’t come.”
A good problem sentence names a person, their goal, and what’s standing in the way. Get that sentence right and the design gets dramatically easier — and cheaper — because half the arguments about taste just evaporate. We’re not debating blue vs. green. We’re fixing that.
Step 3: Generate more than one way to fix it
Once the problem is named, I deliberately come up with several possible answers before falling in love with any of them. Different layouts for the schedule. A different structure for the service-times page. A simpler registration flow vs. a shorter form on the existing flow.
The rule I give myself here: quantity first, judgment later. The first idea is usually just the most obvious one, and crossing it out too early — or marrying it too early — both cost you. Some of the best fixes I’ve shipped started as the third or fourth sketch, the one that only showed up because the first two were allowed to be mediocre.
Step 4: Build a rough version, on purpose
A “prototype” sounds technical. It isn’t. It just means a version cheap enough to be wrong.
A clickable mockup. A draft page. A staging site that looks 90% real and is 0% launched. The point is to give people something concrete to react to, because humans are terrible at judging an idea described in a meeting and excellent at judging a thing in their hands.
Rough is a feature here. The moment a draft looks expensive, everybody — client included — starts protecting it instead of improving it.
Step 5: Put it in front of people and learn something
Finally, real users try the rough version on the real errands: find the schedule, register the kid, make the donation, find the service time. I watch where they hesitate. I note every place I have to explain something — because an explanation in the test is a defect in the design.
Then the important part: loop back. Test results send you to Step 2 or 3 with a sharper problem and better ideas. That’s not rework; that’s the method. Design thinking isn’t five steps in a line. It’s five steps in a circle you go around until the thing works, each lap cheaper than fixing it after launch.
Why a small business should care about design thinking
Because the alternative is the most common project story in America: a business pays for a full website built on assumptions, launches it, discovers the real problem six months later, and pays again to fix it.
This process spends the cheap effort up front — conversations, a one-sentence problem, sketches, a testable draft — where mistakes cost hours instead of invoices. You don’t need the phrase “design thinking” to get the benefit. You just need a designer who refuses to decorate a problem he hasn’t named yet.
That’s the job. The pages come after.
Have a website problem you can feel but can’t quite name? Naming it is literally step two of how I work. Starter packages from $699, Business sites $1,999–$3,999. See recent work or get a free quote.
Previous in this series: UX Research Without the Guesswork · Next: What Is a Design Sprint?
This article is my own take, in my own words, on UX principles I use in client work — informed in part by completing Google’s Foundations of User Experience (UX) Design course on Coursera. It is not affiliated with or endorsed by Google or Coursera.