Design Around Decisions, Not Abstract Entities

After working on a lot of data migrations and system redesigns, a pattern keeps showing up.

Many projects start by asking leadership what they want, building toward that vision, and then wondering why adoption struggles. Technically, the system works. But day to day, users fight it.

The issue usually isn’t the technology. It’s a mismatch between the system’s structure and how people actually think about their work.

What tends to work better?

Spend Time with the People Who Live in the Data

Do this not just to gather requirements, but to understand how they make decisions. What decisions are they making? What information do they need in that moment? What is the cost of getting it wrong or getting it late?

Design Around Decision Pathways, Not Abstract Entities

Reduce cognitive friction. If users have to translate between multiple mental models just to do their job, the system will fail no matter how clean the schema is.

Good architecture should feel obvious. If users are fighting the system, the system is wrong.

Build Discipline into the Structure

Clean data is rarely a training problem. It’s an architecture problem.

Validation rules, defaults, and constraints should make the correct action easier than the incorrect one. Don’t ask people to maintain discipline that the system should be enforcing.

Then Automate What’s Already Clear

When the structure matches how people think, automation stops being guesswork. You’re not inventing workflows; you’re encoding patterns that already exist.

This also tends to produce better analytics. Not because the system was optimized for algorithms, but because it was designed around human meaning first.

The result is straightforward: systems people actually use, data that survives leadership changes, and architectures that can explain themselves when someone asks why things work the way they do.