Unlearning the habit that quietly dissolves design’s authority
Once upon a time, I was a young designer in a meeting that could have been an email.
The problem was straightforward: a support team covering 30,000+ knowledge base articles across 14 countries needed a better way for people to find answers to common problems. Employees couldn’t find answers fast enough — losing time, making mistakes, escalating tickets that should have closed in two minutes. The proposal was clean, even elegant. A guided help feature layered on top of the existing knowledge base. Better search. Better surfacing. Faster answers.
This is when the meeting stopped being an email and became a war room.
Because I could see the problem. The knowledge articles were self-authored. No standards, no review process, some months out of date, some contradicting each other. A few were just wrong. The real fix was an audit — a slow, tedious, unglamorous crawl through every article before a single line of the new feature got built. And nobody in that room wanted to hear that. The timeline was set. The solution was decided.
My job, as far as the product leader was concerned, was to make it look good.
I was barely invited to that room in the first place. So when the product leader pointed to usage data and like/dislike counts as a way to weed out the unhelpful articles over time, I looked at it and thought: “Ok. Good enough.”
The feature shipped. Support volume went up — by a lot.
Here’s what I’ve had to sit with: I didn’t fail to see the problem. I saw it clearly. I made a calculation, decided the partial solution was close enough, and let it go. That’s a different kind of mistake. Harder to name. Harder to defend. Because “good enough” is always a choice — and at a certain point in your career, it’s the most expensive one you can make.
Sound familiar?
The hard part isn’t recognizing the story. It’s recognizing that what felt like strategy was a habit. A well-dressed one. The kind that convinces you you’re reading the room when you’re actually just repeating a pattern you learned so early it stopped feeling like a choice.
That’s the part nobody names. And unnamed habits don’t get examined, they just get more expensive.
What took me years to understand: this wasn’t a problem title could solve. It cropped up again and again — different companies, different teams, different products. Studio designers, agencies, in-house or even freelancers. The context doesn’t matter. The problem wasn’t one of seniority, politics, or “we just need a seat at the table” — thought God knows we said that enough.
The issue wasn’t always just getting into the room, but also using design to own the altitude of the problem.
Altitude ownership is the refusal to let your discipline become optional — by naming what you own, defending what the work requires, and holding the stake even when the room would rather you didn’t.
The inverse of altitude ownership is abdication, because silence in a room where you hold influence isn’t neutral — there is a cost.
Knowing the cost means knowing where you stand
Design careers have altitudes. But altitude isn’t a ladder.
You don’t have to climb. Plenty of exceptional designers spend their entire careers at one level and do extraordinary work there. The principal designer who has spent fifteen years perfecting interaction craft at the interface level is not someone who failed to climb. They’re someone who chose mastery over altitude. And that choice produces something irreplaceable — the foundation that everything else gets built on.
The difference between levels isn’t seniority, salary or title. It’s one thing: the ability to produce quality decisions under increasing uncertainty.
With each altitude, the uncertainty doubles. And the cost of being wrong scales with it. At the interface level, a bad call means you or your team has a bad day. At the product level, it means a feature fails and a roadmap shifts. At the systems level, it means something breaks that nobody saw coming — and people are scrambling to find out why. At the organization level, the wrong design bet doesn’t just cost a sprint. It can cost people their jobs. Their livelihoods. And you have to make that call anyway, with incomplete information, under pressure, in real time.
That’s what altitude actually means. Not where you sit in the org chart. How much uncertainty you can hold — and still make the call.
The manual ends here
At the beginning of most careers, there are manuals for everything. Any designer worth their pixels has probably wondered if they actually knew what they were doing or were just really good at searching Google. Say hello to imposter syndrome.
Heuristics. Accessibility standards. Design systems. Best practices. Entire libraries dedicated to helping you make good decisions. These are at the tips of our fingers when starting out, and most designers assume mastery means learning all of them
It doesn’t. Mastery is what happens when the manuals stop providing answers.
At some point, if you’re good enough, you’ll find yourself staring at a problem no manual can solve, no search can answer, and no expert seems particularly interested in solving for you. In that moment, the question isn’t whether you know the answer — it’s whether you’re willing to make a decision without one. This is the fork in the road that nobody talks about.
Some go deeper, becoming exceptional practitioners who master a discipline so completely the rest of us study their work. Others decide to operate where the manuals end, making decisions before certainty arrives — building the patterns and frameworks everyone else eventually adopts. Neither path is wrong. But they are fundamentally different altitudes of the same work.
The judgement gap
When I say altitude, I’m not talking about title, authority, or job level. I’m talking about scope — the combination of responsibility and uncertainty. The higher the altitude, the fewer correct answers exist. Most assume that intelligence, expertise, or experience alone are what help people succeed at these higher altitudes — and yes, intelligence helps, and yes, you want a boss who actually has more experience. But those things alone aren’t sufficient. What separates people who make altitude transitions successfully from those who don’t is judgment. Not judgment as in being judgmental — judgment as in knowing what to do when the answer is incomplete, the information is conflicting, and the consequences are real.
Most designers assume advancement comes from acquiring new skills. Learn research. Learn facilitation. Learn business strategy. Learn AI. Learn whatever LinkedIn is excited about this week. Skills matter — but after watching designers successfully make altitude transitions and fail to make them, I’ve become convinced that skills are rarely the thing holding people back. It’s judgment. And this isn’t unique to design. Michael Watkins argues in “The First 90 Days” that one of the most common reasons leaders fail at transitions is because they continue doing the work that made them successful at the previous level. They aren’t failing because they’re incapable. They’re failing because the job changed and they didn’t.
Noel Tichy and Warren Bennis take the argument a step further. In Judgment: How Winning Leaders Make Great Calls, they argue that what separates effective leaders from ineffective ones isn’t intelligence or experience — it’s the ability to make quality decisions when the answer isn’t obvious.
Designers do this too. The interface designer keeps optimizing screens after becoming responsible for outcomes. The product designer keeps optimizing outcomes after becoming responsible for systems. The systems thinker keeps optimizing systems after becoming responsible for organizational risk. They’re solving yesterday’s problem at today’s altitude — because every altitude transition asks the same thing: what do you do when no one knows the answer?
Four Altitudes in a Design Career
The answer is different at every altitude. In design careers, I’ve found there are largely four, each commanding their own scope of accountability and ownership: interface, product, systems and organizational.
At the interface level, someone has to own the experience details, and that someone is design. Design owns the experience details not because it was assigned, but because it’s what the discipline requires. The moment a tradeoff forces those details to get cut, your job isn’t to accept the cut quietly. It’s to name who is now accountable. Who owns the corner that just got cut. Because if you don’t name it, you’ve answered the question by default — and the answer is nobody. When nobody owns it, design didn’t lose the argument. Design forfeited its stake entirely.
What doesn’t always exist is the authority to enforce it. A junior designer can flag a contrast ratio that fails accessibility standards and still watch an engineer ship it anyway, because nobody in the room outranks the deadline. That’s not a failure of ownership, because ownership and authority are two different things.
You can own the standard intellectually — it’s already written down, already documented, already true before you walked in the room. What you can’t always do is stop the cut. What you can always do is say it out loud. Name what’s being thrown away and who signed off on throwing it away.
Ownership at this altitude isn’t about having the final call. It’s about knowing what the work requires and refusing to let the decision get made silently.
This is also where the habit forms — see the problem, document it, wait for a better moment. This is not because interface-level judgement is weaker, but because it’s often the first place a designer learns that naming what the work requires can cost you the room. Amy Edmondson’s research on psychological safety helps explain why — environments that punish the wrong kind of friction train people to stay quiet, and that training doesn’t disappear when the title changes.
Design doesn’t lose ownership at this altitude because the work is easy. It surrenders it, one quiet deferral at a time — and that can happen to a principal designer with fifteen years of craft just as easily as someone six months in.
Product altitude: Knowing how to own the outcomes
The leap from interface to product is the leap from owning details to owning outcomes. The work stops being “is this screen right” and starts being “did this bet pay off.” And here is where most designers hit the same wall: the moment you try to define what “paid off” means, someone tells you that’s not your job.
It is your job. Just not in the way most designers think.
I once watched a designer run usability testing on a signup flow. The results were good — over 80% task completion. I asked one question: did they know what they were signing up for? Did you ask them to find a button, or find a solution? The designer stalled. The test measured whether people could complete a task. Not whether they understood what they were committing to. Those are not the same outcome, and nobody had decided which one mattered before the test was built.
I saw the same gap at a much larger scale years earlier, leading design at Walmart. There was a program that let employees bundle several existing perks if they opted to use their personal phone instead of a company-issued one. Most employees were already eligible. They just didn’t know it, because the perks were run by three separate teams that had never been stitched together. The product team wanted to measure how many people chose to bring their own device — that was the number that mattered to the bottom line. But that metric only captured a fraction of the actual problem. The real question wasn’t how many people switched devices. It was how many eligible employees ever found out they qualified for something they already had access to. I pushed to measure conversion into the bundle, not device adoption — because device adoption was the side effect, and the unclaimed benefit was the actual failure.
Neither room handed me the authority to define success. Someone had already decided what the number was supposed to be before I said anything.
The power wasn’t in overriding the metric. It was asking what the metric was a proxy for — because every number in that room was already a proxy for something nobody had bothered to define out loud. Roger Martin calls this “integrative thinking” — the capacity to hold two opposing ideas simultaneously rather than defaulting to the easier one. In this case, the easier idea was the metric already on the table. Once you voice what the real number is hiding, the room can’t pretend it didn’t hear you.
That’s the unnamed power at this altitude. You may not own the final call on what gets measured. But you almost always have the standing to ask whether the metric on the table is measuring the real outcome or a comfortable proxy for it. Most designers never ask. They assume that’s a product question, not a design one. It’s both.
Systems altitude: Making the invisible cost visible
Design changes rarely live in isolation. There’s a cascading effect hidden in your working file.
A few years ago, before AI became what it is today, chatbots were the shiniest silver bullet for company problems. Long service desk wait times? Call center traffic jammed with the same question from 1,000 different users?
“Just throw a chatbot on it!” Is something I literally heard a VP in engineering say in a meeting.
But good designers know that designing a chatbot isn’t a surface change, it is a workflow triggering event. Adding a chatbot changes what gets logged, who reviews what, how escalations flow and what needs legal review if it fails “safe guardrails”.
None of that shows up in a design file. All of it shows up eventually, usually as someone else’s emergency, three months after launch.
The power here is making the invisible cost visible before it becomes someone else’s emergency. That sounds simple. It rarely is — naming a dependency means naming it to someone who doesn’t report to you, in a system you don’t control, before there’s any proof you’re right.
It gets harder once you have actual authority to act on what you see — because then the temptation isn’t silence. It’s speed.
I once owned the vendor relationship for a usability testing platform inside a heavily regulated financial institution. Designers on my team would ask me to approve plugins — small things, the kind that would have made their week meaningfully easier. I could approve them. Nobody was stopping me.
But greenlighting a plugin without first routing it through cyber and risk review wasn’t a shortcut. It was a decision to absorb liability that wasn’t mine to absorb alone, because a faster recruiting workflow for a usability study could just as easily become an unreviewed data practice that violates a “no contact” privacy law — and that’s not a design problem anymore. That’s an SEC-level problem wearing a design request as a disguise.
At each alititude, the most expensive design problems rarely look like design problems.
Organizational altitude: where uncertainty becomes the work
In a more recent meeting — one that could not have been an email — I got asked the question design leaders dream of and dread in equal measure.
“How will this research change what we planned for our Q2 roadmap for X product?”
That is not a design question. That is a capital allocation question and political landmine masquerading as a design question. Executives with honest answers come prepared with math, not design.
My honest answer in that meeting meant showing the cost of hiring a contractor versus reallocating a staff designer to the project, all at the assumption of what revenue the feature could unlock.
At an organizational altitude, design leaders are making very few design decisions. The decisions become capital allocation, talent bets, org restructuring, board narratives — and design is the lens you bring, not the subject.
You’re not arguing for design anymore. You’re pricing it — translating a research finding or a craft instinct into the language the rest of the room actually allocates against: cost, time, population served, return.
The unnamed power at organizational altitude isn’t vision. It isn’t even risk tolerance. It’s the discipline of making a call you can’t personally verify — and building enough trust that the people who can verify pieces of it will move on your word instead of waiting for proof.
The cost of waiting
There are times when waiting is the right call. Trust takes time to build. Credibility compounds with slow purposes. Relationships take time before your word alone becomes evidence enough to decide.
That is not the type of waiting I’m describing.
I’m describing hesitation that abdicates the one thing design is actually for — figuring out how something works, not just how it looks.
In the knowledge base story, waiting caused service tickets to spike. That was probably the cheapest consequence available at that altitude. Moving higher means the cost accumulates exponentially.
At the interface level, it costs a sprint, maybe two — something gets fixed and the team moves on. At the systems level, when naming the dependency before it’s on fire is key, hesitation might mean a legal review was missed or a key workflow wasn’t redesigned in time. Operating at the organizational level means hesitation might cost a market window or a competitive edge because your competitor built the thing you were still getting permission to study.
Decisions not made are still decisions. Accountability still lands somewhere — the only question is whether it lands on you now when you speak up about a tradeoff, or in three years when you scramble to explain why nothing happened.
The moment you see the problem — not the moment you’re given permission to speak — is the moment your leadership begins. That is the moment you have a choice. What you do next is the answer to every altitude question this piece has asked.
This piece was originally published on www.jessaparette.com.
Jessa Parette is Head of Design at Byte by Yum! and an advisor to design and product leadership teams. She works at the intersection of AI-driven systems, organizational complexity, and experience design at scale.
Own the room, or leave it was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.