Why Navigation UIs Should Borrow from Stellarium, Not Apple

The best data visualization tools don't look like iPhone apps. They look like instruments built for experts who need to process complex information fast.

A stellar navigation chart inspired by Andy Weir's Project Hail Mary, as Hacker News reported, perfectly demonstrates this principle. The interactive visualization maps stars in 3D space around our solar system, letting you navigate between stellar positions with the precision an interstellar traveler would actually need.

But here's what caught my attention: the interface doesn't try to hide its complexity behind friendly rounded corners and hamburger menus. It embraces the fact that navigating 3D space requires 3D controls. And that's a lesson most enterprise software teams are getting completely wrong.

The False Promise of Consumer UX in Enterprise Tools

We've been sold a lie about enterprise software UX. The story goes like this: if consumers can use Instagram without training, then enterprise users should be able to use complex data tools the same way. Just make everything "intuitive" and "user-friendly."

This thinking has infected everything from database administration tools to network monitoring dashboards. Teams spend months simplifying interfaces that were actually fine when they matched the mental model of the work being done.

I've watched this play out at AgileStack clients. A logistics company wanted their route optimization tool to "feel more like Google Maps." Sounds reasonable, right? Except Google Maps is designed for single-destination navigation by casual users. Route optimization requires comparing dozens of variables across multiple stops simultaneously.

The "Google Maps-ified" version hid critical data behind progressive disclosure. What used to be a single-screen decision became a five-click investigation. Dispatch efficiency dropped 30% because the friendly interface made the complex work harder, not easier.

Domain Expertise Demands Domain-Specific Interfaces

The stellar navigation chart gets this right. Look at how it handles 3D positioning:

• Star positions are shown in true 3D space, not flattened into a 2D approximation
• Multiple coordinate systems are available (galactic, ecliptic, equatorial) because astronomers think in these terms
• Distance scales are logarithmic because stellar distances span orders of magnitude
• The camera controls match spacecraft navigation, not web browsing

Each of these decisions would fail a traditional usability test. The interface has a learning curve. It requires domain knowledge to use effectively. And that's exactly why it works.

When your users are domain experts, you're designing for people who already have sophisticated mental models of their work. Your job isn't to hide complexity. It's to make complex operations efficient.

The Performance Cost of Generic Design Systems

This isn't just about user experience. Generic design systems carry real performance costs when applied to specialized visualization.

Most enterprise design systems optimize for forms and content pages. They assume you're rendering lists of text with occasional images. When you try to build a 3D stellar chart or network topology view using Material Design or Carbon, you're fighting the system.

We rebuilt a network monitoring dashboard that was originally implemented with a popular React component library. The generic data table components couldn't handle the real-time updates efficiently. They were designed for paginated CRUD operations, not streaming time-series data.

The custom implementation dropped render time from 300ms to 40ms for typical network updates. More importantly, it exposed network relationships visually instead of hiding them in table rows. The operations team started catching cascade failures 60% faster because they could see the network topology, not just read about it.

Code for Context, Not Just Conventions

Here's how this plays out in implementation. Most teams reach for established patterns without considering whether they match the user's mental model:

// Generic approach: hide complexity
const NetworkView = () => {
  return (
    <Card>
      <CardHeader>Network Status</CardHeader>
      <CardContent>
        <DataTable rows={networkNodes} columns={columns} />
      </CardContent>
    </Card>
  );
};

This looks clean. It follows design system conventions. And it completely obscures the fact that networks have topology, not just tabular data.

Compare to a domain-specific approach:

// Domain-specific: expose the structure
const NetworkTopology = () => {
  return (
    <TopologyCanvas>
      <NodeLayer nodes={networkNodes} />
      <LinkLayer connections={networkLinks} />
      <MetricsOverlay metrics={realTimeMetrics} />
      <SelectionTools onNodeSelect={handleSelection} />
    </TopologyCanvas>
  );
};

The second version requires custom components. It's harder to implement initially. But it matches how network engineers actually think about infrastructure.

When to Break the Design System

The stellar chart succeeds because it prioritizes domain fit over design consistency. But you can't just abandon all UX principles. You need to know when domain-specific interfaces are worth the extra complexity.

Break generic patterns when:

• Users are experts in the domain: They already have mental models that don't match consumer app patterns
• The data has inherent structure: Networks have topology, time-series have trends, geographic data has spatial relationships
• Speed matters more than learnability: Expert users will learn complex interfaces if it makes their daily work faster
• Generic components create performance bottlenks: Real-time dashboards and large datasets often need optimized rendering

Stick with generic patterns when:

• Users are occasional: They won't invest time learning domain-specific interfaces
• The operations are actually generic: CRUD operations, form submissions, content browsing
• Development speed trumps usage optimization: Sometimes good enough is better than perfect

The Implementation Strategy

You don't have to choose between generic design systems and completely custom interfaces. The teams that get this right use a hybrid approach.

Start with your design system for standard operations: login, settings, user management, basic data entry. These really should feel familiar and consistent.

Then identify the core workflows where your users spend 80% of their time. These are candidates for domain-specific optimization. Build custom interfaces that match the mental models and performance requirements of expert usage.

At one AgileStack client, we kept the standard admin interface using their existing design system. But we built a custom trading dashboard that showed market data in ways that matched how traders actually think about positions and risk. The generic version required 12 clicks to execute a complex trade. The domain-specific version did it in 3.

What This Means for Your Team

The stellar navigation chart isn't just a cool visualization project. It's a demonstration of what happens when interface design serves domain expertise instead of fighting it.

Most enterprise software teams are over-indexing on consumer UX patterns. They're trying to make complex professional tools feel like mobile apps. But your users aren't consumers browsing social media. They're experts trying to do sophisticated work efficiently.

The next time someone asks you to make your network monitoring tool "more like Slack" or your data analysis platform "as simple as TikTok," show them the stellar chart. Point out that astronavigation software doesn't look like a mobile app because astronauts aren't casual users.

Your database administrators, network engineers, financial analysts, and logistics coordinators aren't casual users either. They're experts who will gladly learn sophisticated interfaces if those interfaces make their work faster and more accurate.

Stop apologizing for complexity when complexity serves expertise. Build tools that match how experts think, not how consumers browse. Your users will thank you, and your performance metrics will prove the point.

---

Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.