Does Your Project Need Design Thinking? A Simple Test.

Not every project needs a designer in the room. I know, shocking thing for a design person to admit, but it’s true – nobody needs a journey map for a database migration that no human will ever click through. Some projects are pure plumbing. Let the plumbing be plumbing.

But many projects that need design thinking quietly skip it, only to realize it months later in a very awkward all-hands meeting.

So, here’s a quick, unscientific but genuinely useful test. Ask these questions before you scope the work, not after the thing ships and nobody uses it.

1. Does a human have to adopt this, or just receive it?

There’s a big difference between a system that gets installed and a system that gets used. If success depends on people choosing to engage with something – logging in, updating a record, trusting a recommendation – you have an adoption problem waiting to happen, and adoption problems are, without exception, human problems.

2. Is anyone going to build a workaround?

Workarounds are the most honest feedback your project will ever receive, and it’s usually ignored because it doesn’t come through the official channel. If your new system launches and people start keeping a shadow spreadsheet “just to be safe,” that spreadsheet is a five-alarm fire dressed up as a minor inconvenience.

3. Are you measuring adoption, or just deployment?

“We rolled it out to 100% of the team” and “100% of the team are using it” are two different sentences that get treated as one in far too many status updates. If adoption is a success metric on your project, someone needs to be actively designing for adoption – not just hoping it shows up after the ribbon-cutting.

4. Does this touch decision-making?

Anywhere a human has to review information and make a decision – approve, escalate, ignore, act – you have a UX design problem, whether it’s labeled that way in the project charter or not. Data without clarity doesn’t create better decisions. It creates confident guessing disguised as analysis.

5. Is there a “before” and “after” for how people work?

If you’re changing a process, not just a piece of technology, you’re asking people to unlearn something. That’s genuinely hard, and it doesn’t happen just because the old system got turned off. Users need to understand what the old workaround was actually solving for, or the new one will just grow a fresh one in its place.

If you answered “yes” to two or more of these, congratulations: you have a design problem hiding inside what looked like a technical one.

That’s not a bad thing – it just means the work isn’t finished when the code is. It’s finished when the humans on the other end of it are actually better off, and that part doesn’t happen by accident.

Don’t Let a Design Problem Masquerade as a Technical One

It’s also not something you have to catch alone. We’ve spent years answering exactly these kinds of questions, watching where adoption quietly breaks, where a workaround is trying to tell you something, where a decision point needs more clarity than data alone can give it. That pattern-recognition is most of what design thinking actually is.

If you’d like a second set of eyes on a project before it ships, our UI/UX team at Bridgenext is always glad to think it through with you, not as a vendor dropping in at the end, but as a partner helping you get ahead of what’s next.