Approach
How I think about complex systems.
A working philosophy built across a decade of designing for ERPs, BI tools, and enterprise dashboards — where complexity is the rule, not the exception.
Most enterprise systems are built by people who deeply understand the business — but rarely the psychology of decision-making under pressure.
The result is what I call architectural inversion: the system optimises for completeness when its users need clarity. It captures everything, displays everything, and trusts the user to figure out what matters.
For a sales manager at 8 am, scanning a dashboard of 20 KPIs, this isn’t help. It’s homework.
Information is not insight. Insight is not action. Most enterprise tools confuse the three.
My work sits in this gap — between what a system can show and what a user can act on. Between the data that exists and the decision that needs to be made.
I don’t redesign dashboards. I redesign the relationship between a person, their tools, and the choices they have to make every day.
The framework
The Decision Compass
A three-layer model for designing decision-ready interfaces. Used across consulting engagements, refined through hundreds of user interviews, and now the foundation of how I approach every enterprise project.
01
Information
The foundation, available on demand.
Layer 1 is everything the system knows. Numbers, tables, transactions, KPIs. It’s the raw material of any enterprise system, and it must remain accessible — but not foregrounded.
The mistake most ERP designers make is treating Layer 1 as the destination. They put the database in front of the user and call it a dashboard.
Layer 1 should be the floor of your interface, not the surface. Users descend into it when they need proof. They don’t live in it.
02
Insight
Where data becomes meaningful.
Insight is what happens when raw data is placed in context. A number on its own says little — it has to be compared, situated, weighed against a baseline before it begins to mean anything.
This is the layer of comparisons and deviations. Period over period, region against region, expected against actual. It’s also the layer that names the anomaly: not “sales: 1.2M”, but “sales down 12% versus last quarter, concentrated in the Eastern region”.
Most teams have the data needed to build this layer; what’s missing is the architecture of attention — the editorial decisions about which comparisons matter and when.
When Layer 2 is done well, the user stops asking “is this normal?” and starts asking “what should I do about it?”
03
Action
What the user should do next.
Action is the layer most enterprise systems never reach. It’s where the dashboard either prompts a clear next step, or surfaces a decision that needs to be made — explicitly, in the language of the user’s job, not the language of the database.
Done badly, this becomes “recommendations” that no-one trusts. Done well, it sounds less like an algorithm and more like a competent colleague: “Eastern pipeline is slipping; here’s what changed; here’s the call you might want to make today.”
The point is not to take the decision away from the user. It is to make sure the user is making the decision that actually matters — and that the system has done the work of framing it for them.
When this layer exists, the lower two layers stop being the focus. They become evidence. The dashboard becomes decisive.
In practice
What this looks like in your work
If…
Your team uses Excel more than the ERP
Layer 1 is too loud, and Layers 2 and 3 don’t exist. Users have rebuilt the missing meaning layer in spreadsheets — because the system didn’t.
If…
Onboarding takes more than two weeks
The interface is teaching the database, not the job. New users are memorising what each metric means, instead of being shown what to do with it.
If…
Decisions still happen on WhatsApp
Layer 3 is missing entirely. The dashboard reports the world but never names the choice; the choice ends up wherever the team is already talking.
Writing