Designing Interfaces for Engineers, Not Executives

Context

A few months ago, we were brought in to help a data platform team overhaul their internal admin console. It was a critical tool used daily by engineers, analysts, and DevOps, but it hadn’t seen a proper UX pass in years.

The original UI was functional, but it had slowly accumulated complexity. New pages were bolted on. The state was hard to manage. Tables were dense and slow. The result was a confusing interface that tried to appeal to everyone: product leaders, support teams, engineering, and executive stakeholders.

Our mandate: improve usability, reduce misclicks, and modernize the feel.

But early in the project, it became clear we had a framing problem.
The UI wasn’t designed for anyone, as it aimed to satisfy everyone.

The Problem

The admin console suffered from what we now call “executive creep.”
What started as a heads-down tool for engineers had gradually absorbed more features to serve adjacent audiences:

• Executives wanted dashboards and visual rollups

• PMs wanted usage analytics and customer search

• Support wanted access to manual override tools

• QA wanted to simulate edge cases and trigger test flows

To accommodate everyone, the interface became cluttered. Dropdowns multiplied. Tooltips turned into documentation. And critical engineering functions were buried three clicks deep to make room for graphs no one used.

What was once fast and sharp had become slow and safe.

When we interviewed real users (mostly engineers), the complaints were consistent:

• “It takes too long to get to the thing I need.”

• “I’m always double-checking what I’m about to click.”

• “It’s trying to be too friendly, it just needs to work.”

That told us everything.

The Task

Our goal was to redesign the console for the people who used it most: engineers.

That meant stripping back everything that didn’t serve execution. The new design wouldn’t be visually bloated, optimized for stakeholders, or built for demos. It would be:

• Fast

• Clear

• Focused

• Minimal

A tool, not a tour.

The Actions We Took

1. Ran zero-stake workshops with the real users
We invited engineers to sit with our design team, not for requirements, but to walk through their day. We asked:

• What tasks are repetitive?

• What do you dread opening this tool for?

• What’s the one thing you wish it could do better?

These sessions gave us more than feature ideas; they gave us tone. We learned which words felt “overwritten,” which controls caused hesitation, and which flows deserved shortcuts.

2. Re-centered navigation around use cases, not org structure
The original console was organized by system area (e.g., “Accounts,” “Billing,” “Logs”), but engineers worked by workflow.

So we rebuilt the navigation around actions:

• Search and investigate

• Manage resources

• Run test scenarios

• Trigger automation

We de-prioritized “business” views and turned them into collapsible, read-only pages.

3. Removed UI decoration and prioritized affordance
The older console had gradients, modals, icons, and pill colors for everything. Instead, we moved toward a stripped-down visual system:

• Monospace fonts for query inputs

• Plain buttons with keyboard bindings

• Emphasis on legibility, not brand consistency

• Fewer colors, more spacing

It felt like a terminal, but with just enough visual hierarchy to guide the eye.

4. Reintroduced complexity through progressive disclosure
Some features were inherently complex, like editing raw JSON payloads or viewing multi-step transaction logs. We didn’t hide that. But we hid it initially.

We used drawers, tabs, and collapsible sections to reduce screen load. Engineers could dive in when needed, but weren’t greeted with a wall of dense UI on first load.

5. Added lightweight feedback mechanisms
Engineers can now mark UI elements as “confusing,” “slow,” or “broken” using inline reactions. These weren’t bug reports; they were experience signals.

This gave the team data to iterate without needing long feedback sessions.

The Results

• Time to complete common tasks dropped by 30 to 50%

• Support requests fell because engineers weren’t getting blocked as often

• Stakeholder feature requests decreased once people saw a clear boundary: “this tool is for execution”

• Engineers became advocates, suggesting future improvements organically

No one asked to see a pie chart again.

Takeaway

You don’t have to make every internal tool look like a marketing site. In fact, you shouldn’t.

Designing for engineers means reducing cognitive overhead, not adding layers of polish. Use fewer icons. Avoid empty states with clever puns. Stop optimizing for screenshots.

Instead:

• Design for speed of interaction

• Favor density over decoration

• Ask your power users what they actually do, not what they say they want

And most of all, be honest about who the tool is for.

Because when everyone is the audience, no one is the user.