Go to any airport, and you’ll see dashboards everywhere. Flight status boards showing arrivals, departures, and delays. You glance at them, get the information, and move on. There’s nothing you can do about any of it. That flight is still up in the air — literally.

Now picture the pilot in that same plane. They see the speed, the altitude, the heading. But the difference is that if something’s wrong, they can course-correct. They have controls right there. That’s a cockpit.

dashboard-cockpit.png

The Dashboard Obsession

There’s an obsession with dashboards in software. Every application seems to need one. Revenue numbers, user counts, order statuses — all rendered in nice charts and cards. And dashboards are great for what they are: a way to see what’s happening.

But here’s the thing I keep running into: a dashboard without controls is showing information that doesn’t matter. Or rather, it might matter, but the person looking at it can’t do anything about it from where they’re standing.

It’s like giving a flight attendant a display that shows airspeed. If the airspeed drops, what should they do? Walk to the cockpit and tell the pilot? That extra step — that indirection — is exactly what happens in most applications when someone sees a problem on a dashboard and has to navigate elsewhere to act on it.

What Makes a Cockpit

A cockpit goes further. It shows you the information and gives you the tools to act on it — right there, without leaving the screen.

Imagine an application where the business owner logs in and sees their numbers. Revenue, orders, inventory levels. But the question quickly becomes: what do they do when something’s off?

Say revenue is down. Or a supplier is sending bad product. Or the sales team oversold something that’s not in inventory. The dashboard tells you there’s a problem. But does the tool let you do something about it?

That’s where the cockpit comes in. Instead of just showing the data, it surfaces the next actions:

  • Quality alerts — flagged right on the screen. You see there’s a supplier quality problem, and from that same view you can drill into which supplier, which products, and whether you need to reach out.

  • Oversold inventory — the cockpit shows what’s oversold and suggests the supplier you last purchased from. Want to create a purchase order? Do it right there.

  • Configurable thresholds — that big revenue number on the screen, is it good or bad? The user sets thresholds, and the cockpit tells them. No mental math, no guessing.

The pattern is always the same: see the information, understand what it means, and act on it — all without leaving.

dashboard-cockpit-laptop.png

It’s About Making It Actionable

The word that comes up is actionable. A dashboard shows you data and information. A cockpit makes that actionable.

There’s a subtlety here, too. It’s not just about bolting action buttons onto a dashboard. It’s about asking: what is the person’s next question? And then answering it before they have to go looking.

When a salesperson sees their top ten items sold this month, their next question is likely: Who bought those items? So the cockpit brings that information into the same view. And if there’s too much data to show inline, it takes them directly where they need to go — not back to a main menu, not through three clicks of navigation, but right to the relevant screen.

Different Workflows, Different Cockpits

One thing I’ve been leaning into: cockpits should change based on what you’re doing. It’s not one-size-fits-all.

Think about Batman. In the Batmobile, chasing the Joker, he needs one set of instruments and controls. Back at the Batcave, analyzing data, he needs something completely different. Same (fictional) person, different workflows, different cockpits.

In practice, this means the cockpit adapts to your role and your current task. A seller’s cockpit looks different from the owner’s cockpit. And even within the same role, the cockpit might shift depending on the workflow — reviewing orders, managing inventory, or handling customer issues.

batmobile-batcave.png

The Litmus Test

Here’s a simple test I’ve been using: when someone looks at a screen in your application, ask two questions.

  1. Does the information on this screen lead to a decision? If not, the person will become blind to it. They’ll skip right past it every time.

  2. Can they act on that decision from here? If they have to leave the screen to take action, you’ve built a dashboard. If they can act right there, you’ve built a cockpit.

Dashboards aren’t bad. They have their place — like that flight status board at the airport. But if you’re building something for the people who are actually flying the plane, give them a cockpit.

Leave a Reply

Trending

Discover more from Claudio Lassala's Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading