November 2026
The Design Decision Hierarchy: How I Keep Moving When Everything Is Unclear
Nobody hands you a clean brief in enterprise. Not once in 15 years has someone walked up to me and said, “Here’s exactly what we need, all the research is done, stakeholders are aligned, and the timeline is generous.” That has never happened. It’s not going to happen. And honestly, if it did, the role probably wouldn’t need a senior designer.
The reality of working in large, complex organizations is that ambiguity is the default state. Requirements shift. Stakeholders disagree. The data you need doesn’t exist yet. There are four competing priorities and a roadmap that was outdated before the ink dried. Most of the designers I’ve worked with, good ones included, hit a wall when this happens. They stall. They ask for more research. They schedule another alignment meeting. They wait for someone to tell them what to do.
I don’t wait. I do the next right thing.
That’s not recklessness. It’s a system. Over 15 years of building things from nothing at companies like Ecolab, Thomson Reuters, UnitedHealth Group, and Best Buy, I’ve developed a practical hierarchy for making design decisions when the picture is incomplete. It’s how I keep moving when everything around me is fog.
The Hierarchy
Think of this as a decision tree, not a rigid process. When I’m stuck, I work down this list until I find the level where I can take action.
Level 1: Do you have direct evidence?
User research, analytics, usable data. If yes, follow it. This is the easy one. Most of the time in enterprise, though, you don’t have this, or what you have is stale or incomplete. Don’t pretend bad data is good data.
Level 2: Do you have adjacent evidence?
Maybe you don’t have research for this exact problem, but you have research from a related feature, a comparable user segment, or an analogous product. Use it. Name your assumptions explicitly and move.
Level 3: Can you talk to someone who knows?
A subject matter expert, a support rep who hears complaints every day, a sales engineer who watches users struggle. These conversations aren’t formal research, but they’re a hundred times better than guessing in a vacuum. One 20-minute call can unblock a week of indecision.
Level 4: Can you apply a well-established pattern?
Heuristics, platform conventions, accessibility standards, your design system. When you have no evidence at all, lean on the collective knowledge baked into proven patterns. This is not “just copy what everyone else does.” It’s recognizing that defaults exist for good reasons.
Level 5: Can you make a small, reversible bet?
Ship something narrow. Test it with five users. Put a prototype in front of a stakeholder and watch their reaction. Make the decision small enough that being wrong costs almost nothing, and you’ll learn faster than any planning exercise could teach you.
Level 6: Use your judgment and move.
Sometimes you have nothing. No data, no experts available, no clear pattern. You have a deadline, a blank screen, and your experience. At this level, you make the best call you can, document your reasoning, and keep going. Fifteen years of pattern recognition counts for something. Trust it.
The key to this whole hierarchy is that every level ends the same way: you move forward.
What This Looks Like in Practice
At Ecolab, I built the company’s first design system. There was no precedent, no existing component library, no established design culture to build on. Nobody could tell me what the “right” design system for Ecolab looked like, because one had never existed. So I started with what I could observe directly: which components were being rebuilt repeatedly across products, where inconsistencies were creating real usability problems, what patterns the engineering teams were already gravitating toward. For the gaps where I had no data, I leaned on established systems like Material Design and Carbon as foundations, adapted them to Ecolab’s product needs, and iterated from there. Waiting for perfect requirements would have meant waiting forever. The system exists today because I started building it.
Thomson Reuters gave me a different kind of ambiguity. I was brought in to build an AI-powered contract analysis tool from zero. Zero users. Zero existing product. Zero historical data about what lawyers actually needed from an AI tool, because the technology was new enough that nobody really knew yet. I spent time with legal professionals early, not running a formal study but sitting with them, understanding their workflow, watching where contract review actually broke down. That gave me enough to make informed bets, prototype narrow use cases, test them, and iterate. The tool didn’t come from a perfect spec. It came from a willingness to start building before all the answers were in.
At UnitedHealth Group, the ambiguity was more personal. I was designing a health coaching platform, and the question wasn’t just “what features do we build?” but “how do people actually experience health behavior change at home?” You can’t answer that with analytics dashboards. So I did in-home research. I went to where the users were, observed their real lives, and brought that context back to the product team. That’s Level 1 work, getting direct evidence, but it required the initiative to go get it rather than waiting for someone to hand it to me.
Best Buy was an exercise in adjacent evidence and judgment. When I redesigned employee scheduling, I didn’t have months for discovery. I had adjacent knowledge about retail operations, strong heuristics about information hierarchy for time-sensitive tasks, and the judgment to synthesize those into a direction. The redesign shipped, and it worked, because progress on solid reasoning beats paralysis waiting for certainty.
Why Progress Beats Perfection in Enterprise
Enterprise design has a dirty secret that nobody talks about enough in portfolio case studies: the cost of inaction almost always exceeds the cost of imperfection.
When you stall, you’re not just delaying a design. You’re holding up engineering timelines. You’re burning sprint capacity on re-planning. You’re losing the window where stakeholders actually care about the problem and have budget allocated. In large organizations, momentum is a resource. Once you lose it, getting it back takes twice the effort.
A good-enough design that ships and gets feedback will almost always outperform a perfect design that arrives three months late. I’ve seen it happen over and over. The teams that move, learn. The teams that wait, get reorganized before they ship anything.
Progress over perfection isn’t about being sloppy. It’s about being strategically courageous.
Sailing Through Fog
There’s an old saying: a smooth sea never made a skilled sailor. I come back to this constantly, because it captures something true about the kind of designer I’ve become.
Fifteen years of enterprise work means fifteen years of fog. Unclear requirements, misaligned stakeholders, impossible timelines, emerging technology nobody fully understands yet. Every single project I’m proud of started in conditions that could have justified doing nothing. Building from nothing at Ecolab, inventing a new AI tool at Thomson Reuters, going into people’s homes at UHG to find the real problem, redesigning critical workflows at Best Buy under pressure.
The fog never lifts completely. You don’t wait for clear skies. You check your instruments, trust your experience, pick the best heading you can, and sail.
That’s the skill. Not the ability to execute when everything is clear. Anyone can do that. The skill is making sound decisions and maintaining momentum when the path forward is uncertain. It’s knowing which level of the hierarchy you’re operating at, being transparent about it with your team, and moving anyway.
The designers who thrive are the ones who move anyway.