A human-centered product design leader with 23 years of experience focusing on practical innovation while delivering transformative user experiences — currently at Capital One.
My leadership ethos is grounded in servant leadership, mentorship, and creative direction.
The first question I usually get after making the case for internal tools is a fair one: okay, but how?
How do you design well when the problem statement is buried under years of technical debt and organizational history? How do you lead a team through work that doesn't have the clean feedback loops of consumer products? How do you know if you're making progress?
Most design education doesn't cover this. Because for a long time, nobody thought it was worth covering.
I came to this work from the other direction. I spent years designing consumer products — apps that had to earn attention, experiences that lived or died by their first impression. Then I joined an enterprise SaaS company 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 keep coming back to.
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.
In practice that means bringing users into synthesis, not just research. Co-authoring problem definitions instead of presenting them. Being genuinely willing to have your framing challenged by someone who's been doing this job for fifteen years. The best internal tool designers I've worked with don't ask "what do users need?" They ask "what do you know that I don't?"
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. And those teams aren't obstacles. They're 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 — all of it — is part of the problem space.
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.
So nail down a shared definition of success before design work starts. Work with operations, finance, 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.
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 here's the thing — 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.
Individual screens matter. But in complex internal 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.
A well-constructed design system makes coherence the path of least resistance. But a design system alone isn't enough. 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.
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.
There's an unspoken hierarchy in product design. Consumer-facing products sit at the top — the apps millions of people download, the interfaces that win awards, the work that fills portfolio case studies and gets shared on Dribbble. Internal tools sit somewhere near the bottom. Unglamorous. Inherited. Tolerated.
I'd like to make the case that this hierarchy is wrong — and that the designers willing to work against it are doing some of the most important, most complex, and most undervalued work in the field.
Consumer products are visible. They're measurable in downloads, ratings, and revenue. They're the thing a company shows the world. Internal tools, by contrast, are the thing a company shows only itself — and for a long time, the standard was simply "functional enough not to cause a revolt."
Design culture followed the money and the visibility. The best portfolios were full of consumer apps. The best jobs, we were told, were at companies whose products you'd actually use. Internal tools were what you worked on when you couldn't get the other job.
But something has shifted. The most sophisticated organizations have started to realize that the experience of the people inside the company is inseparable from the experience of the people outside it. If your associates are navigating twelve different systems to answer a single client question, that inefficiency doesn't stay internal — it shows up in every client interaction, every service delay, every moment where an agent has to say "let me look into that and get back to you."
Here's what most people outside this work don't appreciate: internal tools are genuinely harder to design well than most consumer products.
Consumer products have the luxury of a relatively clean slate. You're designing for a broad audience, optimizing for intuitive first-time experiences, and working within established mobile and web conventions that users already understand.
Internal tools have none of that. You're designing for experts — people who use these systems for eight hours a day and have deeply ingrained workflows, workarounds, and muscle memory built around broken experiences. You're working within the constraints of legacy systems, data models, and organizational structures that predate your involvement by years or decades. You're navigating stakeholders who have conflicting definitions of what the tool should even do. And you're trying to introduce change to people whose jobs depend on stability.
The design challenge isn't just UX. It's change management, systems thinking, organizational alignment, and craft — all at once.
When a consumer app has a confusing flow, users drop off. That's bad. When an internal tool has a confusing flow, the people who can't drop off — because it's their job — develop workarounds. They maintain spreadsheets alongside the system. They copy data between applications manually. They build tribal knowledge that lives in their heads and nowhere else. And that's worse than bad.
This is what's called swivel chair — the phenomenon of an associate rotating between multiple disconnected systems to complete a single task. It's expensive, error-prone, and demoralizing. And it's almost entirely a design failure.
The inverse is also true. When internal tools are designed well — when they're coherent, intuitive, and actually reflect how people work — the effect compounds across every person who uses them, every day. The efficiency gains aren't marginal... they're structural. And they flow directly into the quality of the experience a company can offer its customers.
Designing internal tools well requires something that consumer product design doesn't always demand: a willingness to go deep into a domain you didn't choose and may not have expertise in. You have to understand the business well enough to know what "better" actually means — not just visually or interactionally, but operationally.
It requires humility. The users of internal tools are often subject matter experts who know things you don't. The best internal tool designers treat those users as collaborators, not just research subjects.
And it requires patience with ambiguity. Internal tools rarely have a clean problem statement. They have a history, a politics, and a set of constraints that you have to map before you can meaningfully improve anything.
I came to internal tools from consumer products. I spent years designing things people chose to use — apps that had to earn attention in a crowded marketplace, experiences that lived or died by their first impression.
What I found when I turned toward enterprise and internal platforms was that the design problems were harder, the organizational impact was larger, and the opportunity to do something that genuinely mattered to people's working lives was more immediate than almost anything I'd done before.
The person who no longer has to re-enter the same data into three different systems isn't just saving time. They're getting back cognitive space. They're able to focus on the judgment calls that actually require a human — the nuanced client conversation, the creative problem-solving, the work that can't be systematized.
That's not unglamorous work. That's the work.
The organizations that will win the next decade aren't just the ones with beacon customer experiences. They're the ones that have figured out how to make their internal operations as sophisticated as their external ones — where the tools associates use are held to the same standard as the products clients see.
Design has a central role to play in that. But only if we're willing to take the work seriously.
Charles is the kind of kickass designer that all the other teams want to work with. I’ve worked with Charles for many years and was always impressed with his leadership, designs and his positive impact on the team. He was always interested in moving the team and the project forward while maintaining the cohesion that made the team special in the first place. I’d love to work with Charles again in the future, and I’m sure you’ll feel the same!
– Matt Toohey, Chief Software Architect @ Tact.ai (worked together at Tact.ai)