A Case Study: Design Thinking

Design thinking starts not with solutions, but with deep listening. In the original project, the designer had empathized with the stakeholders — but not the end users. When interviews were finally conducted with actual learners, a very different picture emerged.

Senior staff disliked the gaming mechanics entirely. Time-constrained employees couldn’t sustain engagement across extended gameplay. Some learners preferred reference materials they could consult on the job rather than a course they had to sit through. And for younger employees, the simulation’s consequence framing — where you could “lose” data — felt more punishing than motivating.

The lesson here isn’t that games are bad. It’s that the design was built on assumptions instead of evidence. Empathy is about replacing your assumptions with what your learners actually experience, need, and feel.

Once you’ve gathered real input from learners, you can define the problem with precision. In this case, the problem wasn’t “how do we make cybersecurity training more fun?” — it was “how do we help a diverse, time-pressured workforce quickly recognize and respond to security threats in their actual jobs?”

That reframe changes everything. It shifts the focus from novelty to utility. It acknowledges that a senior manager and a junior staff member might need different entry points into the same content. And it surfaces the real constraint: people don’t have time for a 60-minute game. They need something they can use and return to.

A well-defined problem statement is the compass for everything that follows. Without it, you’re just building features nobody asked for.

Here’s where many instructional designers shortcut the process: we move from “problem” straight to “solution” without exploring the middle. Ideation is about deliberately generating a range of options before committing to any one direction.

In redesigning this course, the team explored a spectrum of formats: scenario-based learning without game mechanics, short modular lessons that could stand alone, job aids and quick-reference guides, branching simulations without win/lose framing, and role-specific learning paths. Not all of them made the cut — but generating them opened up possibilities the original brief had closed off.

Ideation also gives you something valuable to bring back to stakeholders: not one answer, but a conversation about which approach best serves the learners they’re responsible for.

The redesigned course went back to a prototype — but this time, a much lighter one. Instead of a full 60-minute module, the team built a short scenario-based module: direct problem-solving, no extended narrative, reward points for correct choices rather than penalties for mistakes. Straightforward. Respectful of the learner’s time.

This is the heart of prototyping in design thinking: build the smallest thing that can answer your most important open question. You’re not trying to impress anyone at this stage. You’re trying to learn.

A prototype doesn’t have to be polished. A storyboard, a paper mockup, a single Storyline scene — whatever gets real feedback fastest is the right prototype for the moment.

Testing in design thinking isn’t the same as a final review or a QA pass. It’s putting your prototype in front of real learners — not just stakeholders — and watching what happens. What do they struggle with? Where do they disengage? What do they actually walk away knowing?

For the cybersecurity course, the revised prototype tested well across the learner groups that had rejected the original. The scenario-based format felt relevant. The reward structure felt fair. Senior managers didn’t feel talked down to. The content was accessible without being dumbed down.

That’s the goal: a design that works for the people it’s built for. Testing is how you know whether you got there — and it always surfaces at least one thing worth improving before you build the full thing.