When the team can't agree what's wrong

Before reacting to a problem, I work out which altitude it belongs to. PointClickCare is the clearest example I have. The brief was to redesign the site, and everyone agreed the navigation was broken. But the navigation wasn't the problem.

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 2 answers matched. "Fix the navigation" was a real complaint that had landed at the wrong altitude: it sounded structural, but its cause was at strategy.

The redesign worked because we solved the model first, let the structure follow, and showed the connection well enough for the organization to continue building against it long after the project wrapped. That's what finding the right level of problem does: it helps you figure out what you're really solving. This piece is about how I find it, what I do once I'm there, and the tools I built so the team can do it without me.

The altitudes framework

The altitudes come from Jesse James Garrett's 5 planes, the model a lot of us learned UX structure from. His planes describe what the parts of a product are. They don't 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. I've recut his middle planes and renamed a couple, but the lineage is his.

1. Strategy — what you're trying to do and why: the user's goal and the business's, the context and constraints you're working inside, and the bet for how those goals actually get met. Everything below answers to it; if it's wrong, nothing lower down can be right.

2. Capabilities — what the product and the person each have to be able to do for that strategy to work: what the system gives, and what the user can accomplish with it. This is where scope gets set, what's in, what's out, what waits for later.

3. Organization — how all of it is structured, grouped, and named so someone can build a mental model of what this is and how its parts relate: information architecture, categories, labels, the words you use. When people can't agree what something is or where it belongs, you're here.

4. Interaction — how a person moves through it: getting from intent to done, what happens in what order, what's reachable from where, and how the eye travels a screen. A move belongs here when it changes what someone does or understands, a button enlarged to mark the primary action, a color used to set a link apart from plain text.

5. Feel — how it looks and feels once the interaction is settled: visual style, type, color, spacing, tone, expressive motion. The very same moves belong here when they only change the look, the button enlarged to balance the layout, the color chosen to stay on brand. So the altitude turns on whether the change touches what someone does and understands, or only how it looks.

Strategy and Capabilities settle what you're building and why. Organization, Interaction, and Feel are where design actually operates, and where my subtlest calls live. 2 are especially easy to miss:

• At Organization, what I watch for is coherence: whether the whole holds to one organizing logic or several stitched together. A structure can be sensible category by category and still be unlearnable as a whole, each section quietly teaching a rule the next one breaks, a failure that shows up only when someone tries to learn the thing whole.

• Between Interaction and Feel, the call matters most with brand and marketing partners. A lot of what they bring looks like Feel — a bigger logo, a hero swap, a louder headline — but is quietly an Interaction change: it moves what gets noticed first, what reads as clickable, what the page seems to be for. Naming it, "this isn't a styling preference, it's changing the primary action," turns a standoff over taste into a conversation about what the page needs to do.

Finding the altitude

Whatever gets reported — a confusing menu, a cramped headline, "the navigation is broken" — is just where the problem showed up, often at an altitude it doesn't belong to. So I follow it: symptom to cause, step by step, until I reach something that isn't a symptom of anything else. Wherever that lands is the real altitude, and it can be anywhere; a complaint about how something looks can trace back to strategy.

You know you've reached the root when asking why one more time produces a given you design around rather than a problem you could fix. At PointClickCare, Why no shared product model? traced back to the company's history. Products had always been sold standalone, so a shared story was never needed; the shifts to platform and self-serve only made its absence start to bite.

You can't redesign a company's history, so that's the floor. And you can trust it's the real one because everything above converges on it: the nav, the inconsistent language, the orphaned products are one missing model, not 3 separate problems. From there the question shifts from where the problem is to what to do about it.

What you do once you're there

At any altitude, the work comes down to 3 moves, far less formal in practice than writing them down makes them sound. There's understanding what's really being asked, often just a Slack thread where I pull the question apart. There's the heads-down craft of making the thing, which I mostly run on instinct now, the checks in my head rather than on a list, which is exactly why it was the hardest part to teach. And there's defending the call afterward: tying a decision back to what justifies it so it ships and stays shipped, the kind that outlives the room it was made in.

Most of this lived only in my head; eventually I wrote each move down as something the team could pick up — a question set, design criteria, a decision framework. Intuition became a shared language; the shared language became tools. What makes them more than generic frameworks is that each one runs on the altitudes, adapting to wherever a problem sits rather than holding everything to a single bar.

Outcomes

Sharper reviews, sturdier decisions
Not every call sticks the first time, since this is a direction, not a guarantee. But reviews catch more before it's expensive to change, and decisions hold up better. The ones that do get reopened tend to reopen at the altitude the challenge is really coming from: a productive disagreement at the right level rather than a stalemate over taste.

A UX team that's leveling up
The designers who report to me are the direct beneficiaries, as the ones actually running the tools. The question set, the criteria, and the tradeoff frame give them a way to catch holes before review and to calibrate what "sound" looks like at each altitude, which is most of what I used to coach case by case. I still see calls that miss, but the floor keeps rising.

Language that travels beyond UX
For the writers and visual designers I work with, the payoff is the vocabulary. They borrow the altitudes to pin down where a disagreement actually sits. The clearest sign it's working is overhearing one of them use the language unprompted, like when they push back that a Feel request is really an Interaction one. When that vocabulary turns up in rooms I'm not in, even with brand and marketing partners, it's doing its job.

None of this resolves a disagreement on its own. That's still the human part, the room and the relationship and the timing. Getting everyone arguing at the same altitude is most of the battle.