5 principles for navigating the most complex work in product design
If you've spent your career on consumer products, you have real skills. Solid instincts. Probably a strong portfolio.
None of that fully prepares you for internal tool design. Here's what does.
I spent years on the consumer side. Apps that had to earn attention, experiences that lived or died by their first impression. Then I joined an enterprise SaaS startup as their first design hire and helped transform a consumer field sales app into a full enterprise platform integrated with core business systems. That transition changed how I think about design.
The skills that make you good at consumer product design are necessary. They're not sufficient. Enterprise and internal tool design requires a different set of instincts, and a different kind of leadership.
Here are five principles I've uncovered the hard way.
1. Treat subject matter experts as co-designers, not just research subjects
The default design process is to extract insight from users, go away, and make sense of it. That model breaks down fast with internal tools.
The people using these systems are often deep domain experts. They understand the business logic, the edge cases, and the downstream consequences of any change better than you ever will. Treat them as interview subjects and you'll get surface-level feedback. Treat them as collaborators and you'll get the stuff that actually shapes decisions.
I learned this at a SaaS startup where we couldn't get direct access to our enterprise customers. Our workaround was our own sales team. Field sales executives and customer success managers who not only sold and trained on the product, but used it themselves. They became our proxies, relaying feedback and brokering access to the enterprise prospects they were working. It was imperfect. Feedback came through a relay, not firsthand. But it got us close enough to co-design solutions that scaled on our platform while feeling bespoke to each customer's needs.
Later in my career the constraint flipped... direct access to users. Associates in workshops, hands-on with prototypes, telling us exactly what works and what doesn't. Different context, same principle: find the closest possible source of domain expertise and pull them into the work, not just the research.
Don't ask "what do users need?" Ask "what do you know that I don't?"
2. Map the organization before you map the experience
Internal tools don't exist in isolation. They sit inside organizational structures, process dependencies, and political realities that determine what's actually possible to change. Designing without understanding that context produces solutions that look right on a whiteboard and fall apart in the real world.
Before you try to improve anything, you need to know who owns what, where decisions actually get made, and where the bodies are buried. Which teams have competing incentives? Where does the data model create constraints that no amount of design thinking can dissolve? Who has tried to fix this before, and what happened to them?
In a regulated industry, this mapping gets more complex and more important. Your stakeholder list doesn't just include product and engineering. It includes compliance, risk, cyber, and legal. Those teams aren't obstacles. They're a fundamental part of the design problem. The constraints they introduce are real, and engaging them early transforms what could be a late-stage blocker into a creative constraint that actually sharpens the solution. Some of the most interesting design problems I've worked on live right at that intersection, where user experience and regulatory requirement have to coexist, and the answer is almost never "pick one."
This isn't soft organizational politics. It's load-bearing design research. The org chart is part of the problem space.
3. Define "better" before you start designing
Consumer products have imperfect but legible success metrics: engagement, retention, conversion. Internal tools usually don't. That vacuum gets filled by subjective opinions and whoever has the loudest voice in the room.
Nail down a shared definition of success before design work starts. Work with operations, internal consultants, and business leadership to identify what actually matters: task completion time, error rates, process abandonment, the number of systems someone has to touch to complete a single workflow.
That last one has a name: swivel chair. It's when an associate rotates between multiple disconnected systems to do one thing. It looks like a workflow problem. It's a design failure. And it's one of the most measurable ones available to us, which makes it one of the most useful things to track when you're trying to demonstrate design impact in an environment where downloads and ratings don't exist.
Know what "better" looks like before you start. Otherwise you're just decorating.
4. Sequence change as carefully as you sequence design
Even a well-designed internal tool will fail if it's introduced wrong. The people using these systems have built their working lives around the existing experience, including its flaws. Change disrupts their competence, not just their workflow. That's a real cost.
Think as carefully about the rollout as the solution. What's the minimum viable change that proves the direction? Where can you show early wins that build credibility for bigger asks? Which users are most likely to become advocates, and how do you get them involved early enough to care about the outcome?
The organizations that get this right don't just ship better tools. They build the muscle to keep improving them.
And if you've applied principle 1, you're not starting from scratch when it comes to sequencing the rollout. The subject matter experts who co-designed the solution with you are your first and best advocates. They're already invested in the outcome. They can tell you where resistance will come from, which teams need more runway, and how to frame the change for people who weren't in the room. The co-design relationship doesn't end when the design does. It extends straight through to adoption.
5. Design systems are the multiplier
Individual screens matter. But in complex federated platforms, interconnected tools, multiple teams contributing, years of accumulated inconsistency, the highest-leverage design work isn't any single flow. It's the system underneath it.
I learned this backing into it. At the startup, we had no design system for years. We were moving fast, building for iOS, and leaning on Apple's design language as much as possible while slowly establishing our own patterns on top of it. By the time we had real enterprise customers, we had four or five years of design decisions that had never been formally codified. So we documented, refined, and codified them. Not a ground-up rebuild, just an honest accounting of what we'd actually built and why. The lift was manageable because the thinking was already done.
That experience taught me that design systems don't have to be built from scratch to be valuable. But they do have to be governed.
A well-constructed design system makes coherence the path of least resistance. But a design system alone isn't enough. In a federated enterprise platform, what actually closes the gap between "we have a system" and "our product feels cohesive" is a governed patterns library: a shared, maintained collection of solutions to the recurring problems your platform actually has. Not just components. Patterns. How data tables behave. How empty states are handled. How errors are communicated across different contexts.
Without that layer, teams default to solving the same problems independently. You end up with a product that technically uses the same design system but still feels disjointed, because the system answered the atomic questions and left the harder ones open.
Governance is the part that holds it together. Regular design critiques with leadership explicitly evaluating pattern consistency. A process for when new patterns get proposed, reviewed, and adopted. Accountability for drift. It sounds like overhead. It's actually what makes scale possible.
A design decision made once should propagate everywhere it should. That only happens if someone is responsible for making sure it does.
*
Why this is a leadership problem, not just a design problem
Individual designers can apply these principles. But most of them require conditions that designers can't create on their own.
Access to SMEs has to be negotiated. Credibility with stakeholders has to be earned. A seat at the table before a project starts has to be established. Design system investment has to be protected when timelines get compressed, and they always get compressed.
Design leaders are the ones who create those conditions. Or don't.
I've seen what happens when that investment gets made. Teams move faster. Work holds together under pressure. Design impact becomes legible to the business in ways it never was before. I've also seen what happens when it doesn't.
The quality of internal tool design in any organization reflects how seriously design leadership has taken the work. That's a real responsibility. It's also a real opportunity.
Don't leave it on the table.