Fix the Right Problem: Design Thinking for Lab Workflows

The Solution Came First

A lab has a slow sample intake. Someone suggests new software. Someone else suggests another technician. A third person wants to rewrite the intake SOP. Everyone has a fix before anyone has watched intake happen for a full morning.

Sometimes the fix works. Often it solves a different problem than the one that was actually slowing things down.

The Design Thinking Playbook by Michael Lewrick, Patrick Link and Larry Leifer (Wiley, 2018) is a guide to a method that starts from the other end: understand the problem first, then decide what to build or change.

The Design Thinking Cycle, Briefly

The book lays out a cycle that moves in a set order: define the problem, understand the needs of the people involved, build empathy for their situation, focus on what matters most, then generate ideas, build a quick prototype, and test it.

The order is the point. Ideas and solutions come after the understanding steps, not before.

The book also treats a good problem statement as a step of its own. Writing the problem down clearly, in one sentence, and checking that it is the real problem is not paperwork. It is where most of the value comes from.

What This Looks Like in a Lab

Here is a lightweight version for a small lab.

1. Write the problem in one sentence.
Not "we need new software." Something like: "Samples received after 3 p.m. often are not logged until the next morning."

2. Watch the work.
Spend an hour at the bench or the intake counter. Where do people wait? What do they write down twice? What do they look up somewhere else? Talk to the analysts, the sample custodian and, if possible, a client who drops off samples.

3. Name the need behind the complaint.
"Intake is slow" might really mean "the person logging samples also answers the phone," or "chain-of-custody forms arrive incomplete."

4. Generate a few options.
Now brainstorm. A form change, a schedule change, a checklist, a software feature. Keep options small and cheap to try.

5. Prototype and test.
Try one option for a week or two on a small scale. Did the one-sentence problem get better? If not, go back to step 2 with what you learned.

Why Small Steps First

The book grows from individual projects out to whole organizations and beyond. Its argument is that the method only pays off at a larger scale once a team is genuinely practicing it on everyday problems. For a small lab, that means starting with one workflow, not reorganizing everything at once.

It also pairs design thinking with data. Watching the work tells you what people experience. Your records, such as turnaround times, reruns and missed holding times, tell you how often it happens. Both together give you a clearer picture than either alone.

Using This When You Choose Software

If you are evaluating a LIMS, including ours, do the understanding steps first. Write down the two or three workflow problems you most need to fix, watch how they happen today, and then ask each vendor to show exactly how their system would change those specific steps. A demo of every feature matters less than a clear answer to your real problem.

---

Based on Michael Lewrick, Patrick Link and Larry Leifer, The Design Thinking Playbook (Wiley, 2018), its three parts: Understand Design Thinking, Transform Organizations and Design the Future. This post paraphrases the book's approach and does not quote it.