When the team can't agree what's wrong

When a problem is genuinely ambiguous — when a room of people can't even agree on what's wrong — the most useful thing I do is also the easiest to skip: before reacting, work out which altitude the problem is really on. PointClickCare is the clearest example I have. The brief was to redesign the site, and everyone agreed the navigation was the problem. It wasn't. The real problem was that the organization had no shared model of what it sold — put a room of stakeholders in front of one of their own core products, ask them to describe it, and no two answers matched. "Fix the navigation" was a real complaint that had landed at the wrong altitude: it sounded structural, but its cause was all the way up at strategy. The redesign worked because we solved the model first and let the structure follow — and the model held well enough that the organization kept building new pages against it long after the project wrapped.

That's the move, and it scales: the same instinct whether it's a seven-month repositioning or a single stray note in a Tuesday review. The rest of this note is where it comes from and what I built around it.

Where it comes from

The altitudes come from Jesse James Garrett's five planes — the model a lot of us learned UX structure from. His planes describe what the parts of a product are. What they don't do is tell you which altitude a confusing problem belongs to, what to do once you're there, or how to defend the call so it stays made. That's the part I added. My cut also collapses a couple of his middle planes, pulls interaction out on its own, and renames surface to something truer to what it governs:

1. Strategy — the goals (user and business), context, constraints, and the bet for how they get met

2. Capabilities — what the user and system must be able to do to serve that

3. Organization — how it's structured and labeled so people can understand it

4. Interaction — how the user moves through it, including how the eye travels a screen

5. Feel — how it looks and feels once the path is settled

PointClickCare is what the distance between altitudes looks like in practice: the complaint ("navigation") sat at Organization and Interaction; the cause sat at Strategy. No amount of work at the lower altitude would ever have reached it.

Finding the altitude

Problems rarely announce their altitude. They surface as whatever's most visible — a confusing menu, a cramped headline — and the visible thing is seldom where the cause lives. So I treat a named problem as a starting point, not a brief: follow it from symptom to cause, step by step, until I reach something that isn't a symptom of anything else. That's the altitude the work actually belongs to.

On PointClickCare the trace ran a long way down. "The navigation is confusing" gave way to users who couldn't orient in the product ecosystem, which gave way to a catalog of sixty products with no shared taxonomy or language, which came down to teams each describing their own products their own way — because the company had never agreed on what it sold. Two shifts in the business, products-to-platform and direct-sales-to-self-serve, were quietly forcing the question. The navigation was a real complaint; it was just the visible end of a much deeper problem.

What you do once you're there

Locating the altitude is half of it; the other half is the work, and at any altitude it's one of three moves. In practice they're far less formal than writing them down makes them sound:

• Understand — surfacing what's actually true and where people quietly disagree. Sometimes that's just a Slack thread where I'm pulling apart what's really being asked; sometimes it's putting a room of stakeholders in front of the same question and watching the answers not match. Most stuck projects are an understanding gap nobody named out loud.

• Make — the heads-down craft of building it and holding it to a standard. I mostly run this on instinct now, the checks in my head rather than on a list — which is exactly why it was the hardest part to make teachable.

• Defend — tying a decision back to what justifies it so it ships and stays shipped. On PointClickCare that meant opening every IA presentation with the taxonomy, not the sitemap — the model had to land before the structure could mean anything. Done right, a decision outlives the room it was made in.

Understand points at the world, Make points at the work, Defend points at the room.

And I didn't leave these as private habits — I turned each into something a team can pick up: a question set for pulling apart what's true and where people disagree, a short list of design criteria for pressure-testing the work before review, and a one-page tradeoff frame for defending a decision. Intuition became a shared language; the shared language became tools.

Why it's built this way

The honest answer to "why formalize it at all": work is only as valuable as its ability to survive the people who made it leaving. On PointClickCare the real win wasn't the redesign — it was that the taxonomy and templates kept getting used after we were gone, as the standing brief the organization built against on its own. That only happens when the thinking is explicit.

The same logic is why I wrote these tools down for my own team. I'm developing designers who report to me, plus writers and visual designers who want to get sharper about which kind of problem they're arguing — and shared language is what keeps a mixed, changing group aligned without me in the room. Giving everyone one way to ask "which altitude is this?" does more for a project than any amount of individual craft.

It's a thinking-and-communication habit, not a process. It makes the disagreement clear; resolving it is still the human part — the room, the relationship, the timing. But getting everyone arguing at the same altitude is most of the battle.