BI Was Designed for Executives. It's Time to Redesign It for Analysts

Most BI tools are designed for the executive who views a dashboard, not the analyst who builds it, and redesigning BI for the builder changes what a good tool looks like. The viewer wants a clean, static, polished surface. The builder wants iteration speed, direct editing, and reproducibility. Optimize only for the first and you make the second slow, which is backwards, because the analyst's experience is what determines whether the dashboards are any good in the first place.

This is a case for BI built around the analyst's workflow. Not because viewers do not matter, but because the builder's loop is the thing that actually produces reliable analytics, and almost every BI tool treats it as an afterthought.

Two users, one tool, opposite needs

A BI tool serves two very different people who happen to share the same software. The viewer, often an executive or a stakeholder, opens a dashboard, reads the numbers, and leaves. They want it clean, fast, and trustworthy. They do not want to know how it was built. For them, the ideal tool is almost invisible.

The builder is the analyst or data engineer who created that dashboard. Their relationship with the tool is the opposite of invisible. They live in it. They are constantly changing things: tweaking a metric definition, restructuring a layout, adding a filter, checking whether last quarter's number still reconciles. For them the tool is not a surface to read, it is a workshop to work in.

These are genuinely opposite needs. The viewer wants stability and polish. The builder wants malleability and speed. And here is the problem: nearly every BI tool resolves that tension in the viewer's favor. The product is designed to make the finished dashboard look good, and the building of it is wedged into whatever menus were left over. We have spent two decades optimizing the read and neglecting the write.

Where viewer-first BI fails the builder

When a tool is designed viewer-first, the failures for the builder are predictable, and every analyst recognizes them.

The first is buried construction. To change how a chart is built, you click into it, open a config panel, hunt through tabs, find the field, change it, and click out to see the result. The thing you actually want to manipulate, the definition, is hidden several clicks deep behind a surface designed to look finished rather than to be edited.

The second is a slow loop. Every change requires a round of clicking, and the feedback is rarely instant. You make a change, wait, look, decide it was wrong, click back in, change it again. When the iteration cost is high, analysts make fewer iterations, and fewer iterations means worse analysis. The quality of the output is bounded by how many times you can afford to try something.

The third, and most damaging, is the absence of reproducibility. In a viewer-first GUI tool, the dashboard is a state inside an application, not an artifact you can read, diff, or roll back. When it breaks, you cannot ask "what changed?" because there is no history to inspect. This is the gap that BI version control was meant to close, and it is precisely the part of the workflow a viewer-first design ignores, because the viewer never needs to know what changed.

Designing for iteration speed

If you flip the priority and design for the builder, the first thing you optimize is iteration speed, because iteration speed is the analyst's entire job. Analysis is not a single correct answer arrived at on the first try. It is a sequence of attempts, each one cheap, each one teaching you something about the data.

Designing for iteration speed means the gap between "I want to try X" and "I can see the result of X" should be as close to zero as possible. That has concrete implications. The thing you edit should be the thing you see, not a panel two clicks away from it. The preview should be immediate, not a render-and-wait cycle. And reversing a change should be trivial, because most experiments are wrong and the cost of being wrong should be near zero.

This is the same instinct that makes a fast SQL notebook feel so much better than a heavyweight BI builder. Notebooks won analysts over not because they were more powerful, but because the loop was tight: write, run, see, adjust. A BI tool that gives analysts that same tightness, but for full dashboards and governed metrics, is a categorically better workshop than one built around the polished read.

Editable objects and direct manipulation

The deepest design choice in builder-first BI is making every object directly editable. In a viewer-first tool, only some things are editable through the UI, and the rest are locked away in configuration you reach through dialogs, if you can reach them at all. The mental model is "view the dashboard, occasionally edit a few exposed knobs."

The builder-first model inverts that. Every object in the project, the model, the metric, the dimension, the relation, the Insight, the layout, is something you can open and edit directly. There is no second-class category of "configuration you can only get to through a wizard." If it exists in the project, you can manipulate it, and the manipulation is direct rather than mediated by a menu.

Direct manipulation matters because it collapses the distance between intent and action. When an analyst wants to change how revenue is defined, the best experience is to edit the revenue definition, in place, and immediately see what it does. Not to open a settings modal, find the metric, change a value, and click apply. Every layer of mediation between the analyst and the object is friction, and friction is iterations not taken.

metrics:
  - name: net_revenue
    expression: "SUM(amount) - SUM(discount)"
    description: "Revenue after discounts, edited directly when the definition changes"

When the metric is a real, editable object rather than a hidden setting, changing it is one action, and the change is visible, reviewable, and reversible. That is what direct manipulation buys you.

The builder loop, end to end

Put the pieces together and the builder's actual workflow comes into focus. It is a loop, and a good BI tool should make every step of it fast.

1. Explore. Poke at the data. Ask a question you do not yet have a chart for. Often this starts in raw SQL or a quick view, before any definition exists.
2. Define. Promote what you learned into a real object: a metric, a dimension, a relation. This is where the throwaway becomes governed.
3. Preview. See the result immediately. Not after a deploy, not after a render queue. Now, so you can tell whether the definition is right.
4. Ship. Commit the artifact, open a pull request, and let it move through review like any other code change.

The reason to name the loop explicitly is that viewer-first tools optimize none of its steps and builder-first tools optimize all of them. Explore wants a fast escape hatch. Define wants editable objects. Preview wants instant feedback. Ship wants reproducibility and version control. A tool designed for the executive viewer cares about none of these, because the viewer is not in the loop at all. They only see the finished output, which is exactly why designing for them produces a workshop nobody wants to work in.

How Visivo designs for the builder

This is the principle Visivo is built on. The project is the source of truth, and every object in it, the models, metrics, dimensions, relations, and Insights, is directly editable rather than buried behind configuration. Because the project is code, the builder loop closes naturally: you explore, you define an object, you preview the result, and you ship it through a pull request with full history and the ability to roll back.

A recent direction in this work is making every object type editable directly, so the analyst manipulates the thing itself instead of a proxy for it, and the ongoing redesign of the Explorer is aimed squarely at tightening that build loop end to end. We will cover the specifics of the redesign in the release recaps as they ship; the point here is the philosophy behind it.

The bet is straightforward. The viewer's experience matters, but it is downstream of the builder's. A polished dashboard that was painful to build will be wrong more often and updated less often than a plain one that was fast to build and easy to change. Design for the analyst, and the executive gets better numbers as a consequence. If you want to feel the difference a builder-first loop makes, get started with a local project and look through the examples.

Previously in Visivo

In the previous post, where should your numbers live, we argued that one metric definition should travel across every surface that consumes it. This post turned to the other side of the same coin: the experience of the person who creates those definitions, and why redesigning BI around the analyst-builder is what makes the numbers worth trusting in the first place.