The Audience Is Part of the Dataset

What if the most important variable in a data project is not in the table at all?

It may be the person looking at the result.

A chart, notebook, catalog, or model does not exist in isolation. Each one is an interface between evidence and a human being. The moment data is collected, organized, or visualized, someone is being asked to interpret it. That person brings a goal, a vocabulary, a level of expertise, and a set of consequences attached to being wrong.

This creates a neglected design problem: data work is never only about representing reality. It is also about representing reality for someone.

That distinction becomes especially powerful when we connect two seemingly separate practices: designing around an audience, and drawing data directly inside a computational workspace. One concerns whom the work serves. The other concerns how easily people can shape and inspect data. Together, they reveal a broader principle:

The quality of a data system depends not only on the accuracy of its contents, but on the distance between those contents and the people who must use them.

The shorter that distance, the more opportunities people have to notice errors, contribute knowledge, and ask better questions.

The hidden variable in every data product

Imagine two teams examining the same customer data. The first team consists of statisticians investigating whether a campaign changed purchasing behavior. The second consists of sales managers deciding which accounts need attention this week. They may use the same rows and columns, yet they do not need the same representation of the information.

The statisticians may care about sampling, confidence intervals, missingness, and causal assumptions. The sales managers may care about recency, account ownership, unusual changes, and what action to take next. A data product that satisfies one group may frustrate the other without containing a single incorrect number.

This is why audience is not a cosmetic consideration. It changes what counts as useful, visible, and even meaningful.

A catalog entry written for a data engineer might emphasize storage location, schema, refresh frequency, and access permissions. An entry written for a policy analyst might need plain language, definitions of key measures, known limitations, and examples of appropriate use. Both descriptions can refer to the same dataset. Yet the second may prevent a serious mistake that the first leaves entirely possible.

The mistake is often described as a communication problem, but that is too mild. It is a translation problem. Every time data moves from its original context to a new audience, some of its meaning is compressed, renamed, or silently discarded.

Consider a column called active_user. To one team, it means a person who logged in during the last thirty days. To another, it means a person who completed a meaningful action. To an executive dashboard, it may appear as a simple growth metric. The number can be calculated perfectly while the meaning remains unstable.

A useful mental model is the translation tax. The translation tax is the amount of interpretation a user must perform before information becomes actionable. It includes questions such as:

• What does this field mean?
• Who created it?
• When was it last updated?
• What does a blank value represent?
• What should I do if two sources disagree?
• Which parts of this display are facts, and which are assumptions?

When the translation tax is high, users either abandon the system or invent their own explanations. Both outcomes are expensive. Abandonment hides valuable data. Improvised interpretation creates inconsistent decisions.

The audience, then, is not merely the final consumer of data. The audience helps determine whether the data can function as knowledge at all.

Why drawing changes the relationship with data

Most data tools assume that people should express questions through formal structures. They write code, select variables, define filters, construct queries, and then wait for a result. This is powerful, but it favors users who already know the language of the system.

Drawing offers a different entry point.

When people can sketch points, curves, clusters, or boundaries directly in a notebook, they are not just decorating a visualization. They are expressing an intuition in a form that can become analyzable. A rough shape can serve as a hypothesis. A hand drawn separation between two groups can become a prompt for classification. A few marked examples can reveal what a user thinks the categories should be.

This matters because many questions arrive before their formal vocabulary.

A researcher may suspect that a dataset contains two unusual populations but not know which features separate them. A teacher may want students to explore the idea of a decision boundary without first requiring them to master a machine learning library. A domain expert may recognize meaningful patterns that are difficult to encode in code because the recognition depends on experience, context, or visual memory.

A drawing interface lowers the cost of making that knowledge visible.

Imagine a public health analyst examining a map of reported cases. Instead of beginning with a complicated query, she circles several neighborhoods that appear to share a pattern. The system can then ask: What do these areas have in common? Are they connected by transit, income, age distribution, or reporting practices? The drawing does not prove anything. It makes a question concrete enough to investigate.

Or imagine a student working with two numerical variables. The student draws a line separating points that seem to belong to different groups. The line may be inaccurate, but its inaccuracies are instructive. They expose assumptions that would otherwise remain vague: which points are ambiguous, whether the relationship is linear, and whether the chosen variables are sufficient.

In both examples, interaction is doing more than improving usability. It is creating a conversation between human judgment and computational feedback.

The person proposes a pattern. The system tests, visualizes, or transforms it. The person revises the proposal. This cycle is much faster when the cost of expressing an idea is small.

The audience should be allowed to shape the evidence

There is a common hierarchy in technical work. Experts produce the data and models. Everyone else consumes the results. This arrangement seems efficient, but it often separates knowledge from the people who possess important context.

A field worker may know that a sensor fails under certain weather conditions. A customer support specialist may know that a category label is misleading. A teacher may know that a visualization invites a predictable misunderstanding. If the system only permits formal input from technical specialists, these observations remain outside the data workflow.

That is where audience centered design becomes more ambitious. It does not merely ask, “How should we explain the result?” It asks, “What can this audience contribute to the process of making the result meaningful?”

An interactive drawing tool is one answer to that question because it gives users a lightweight way to annotate, classify, challenge, and hypothesize. It treats users not as passive recipients but as participants in the construction of an analysis.

This suggests a three layer model for data systems:

1. The evidence layer

This is the recorded material: measurements, observations, transactions, images, text, and events. Its central question is: What was observed?

2. The interpretation layer

This includes labels, definitions, groupings, annotations, explanations, and models. Its central question is: What might the observations mean?

3. The decision layer

This is where a person chooses an action, asks for more information, or changes course. Its central question is: What should happen next?

Many systems focus heavily on the first layer and automate parts of the third, while neglecting the second. Yet interpretation is where audience knowledge becomes essential. A system can store millions of observations and still fail if users cannot connect them to the decisions they face.

Drawing is valuable because it can act as a bridge between the evidence and interpretation layers. It lets someone say, “These points seem related,” “This region matters,” or “This is the boundary I currently believe in,” before those claims have been converted into formal schema or code.

The same principle applies to catalogs and documentation. A catalog is not simply an inventory of assets. It is an interpretive layer that helps people understand what the assets are for, how they were created, and when they can be trusted. Its success should be judged not by how many datasets it lists, but by whether the right audience can make a sound decision with less confusion.

The danger of making data too easy to use

Lowering the barrier to interaction is not automatically beneficial. A drawing tool can make it easy to express a mistaken belief. A simplified catalog can hide important caveats. A polished chart can create confidence without understanding.

The goal is not to eliminate friction altogether. It is to remove unproductive friction while preserving productive friction.

Unproductive friction consists of obstacles unrelated to the quality of the question: obscure syntax, unnecessary configuration, inaccessible terminology, or a requirement to understand the internal architecture before exploring an idea.

Productive friction is the pause that prevents overconfidence. It may take the form of a visible uncertainty range, a reminder about missing values, a request to define a label, or a comparison between a user’s sketch and the underlying observations.

This distinction leads to a practical design rule:

Make expression easy, but make interpretation accountable.

Suppose a user draws a boundary around a set of points. The system should not simply reward the gesture with an impressive score. It might show which points fall outside the boundary, how the result changes under different scales, and whether the apparent pattern survives when another variable is introduced. The user remains free to experiment, but the system resists turning an intuition into a fact too quickly.

Likewise, a data catalog should make discovery easy without pretending that discoverability equals trustworthiness. A prominent dataset might still have unclear ownership, stale updates, inconsistent definitions, or a population that excludes exactly the cases a user cares about.

A mature data system therefore exposes not only answers but also the conditions under which those answers are reasonable.

From audience awareness to audience feedback

The most important shift is from designing for an audience to designing with feedback from an audience.

Traditional audience analysis happens before creation. A team identifies users, anticipates their needs, and builds an interface or explanation. That is useful, but incomplete. People often cannot state what they need until they encounter a representation. Their confusion, annotations, corrections, and workarounds reveal requirements that no planning meeting could fully predict.

Interactive tools create a feedback channel. A user’s drawing, filter, annotation, or rejected result becomes evidence about the system itself.

For example, if many users repeatedly mark the same region of a chart as important, that may indicate an overlooked category, a missing feature, or a confusing visualization. If users consistently rename a field in their own notes, the official definition may not match the language of practice. If analysts export data and rebuild the same view elsewhere, the system has learned that its current representation is not serving the task.

This turns interaction into a form of measurement. The system is not only measuring the world represented by the data. It is also measuring the gap between its representation and the user’s mental model.

We can call this gap the interpretive distance. Interpretive distance grows when the system’s categories, visual grammar, and assumptions differ from the user’s context. It shrinks when users can ask questions in familiar forms, receive immediate feedback, and see how their assumptions affect the result.

The objective is not to make every user interface identical or universally simple. Different audiences need different levels of detail. The objective is to make the distance visible and adjustable.

A beginner may need a guided visual interaction. An expert may need direct access to code and metadata. A domain specialist may need annotation tools. A decision maker may need a concise explanation of uncertainty and consequences. These are not competing demands if the system treats representations as layers rather than as a single final view.

Key Takeaways

1. Define the audience as part of the data model. For every important field or metric, specify not only what it measures, but who will use it, for what decision, and with what level of context.

2. Measure translation tax. Watch where users pause, ask for definitions, create private spreadsheets, or misinterpret labels. Each repeated workaround identifies meaning that the system has failed to carry.

3. Give users a low cost way to express hypotheses. Drawing, annotating, sorting, grouping, and marking examples can reveal valuable domain knowledge before it has a formal technical representation.

4. Separate exploration from validation. Let people experiment freely, but show uncertainty, edge cases, missing values, and sensitivity to different assumptions before presenting an intuition as a conclusion.

5. Treat interaction as feedback about the system. User behavior is evidence about what categories, explanations, and representations are missing or misleading.

The audience is not waiting at the end

We often imagine a data pipeline as a one way journey: reality becomes records, records become analysis, analysis becomes a report, and the report reaches an audience. In that picture, the audience appears only at the final stop.

A better picture is a loop. People decide what is worth recording. They interpret incomplete observations. They add context, challenge categories, and propose patterns. Tools then transform those contributions into new evidence and new questions.

The audience is present at every stage.

This reframes the purpose of accessible data tools. Their value is not merely that more people can operate them. Their deeper value is that more kinds of knowledge can enter the analytical process before decisions are made.

A small drawing in a notebook, a carefully defined audience, or a plain language description of a dataset may seem modest compared with a sophisticated model. Yet these practices address the same fundamental problem: how to reduce the distance between information and understanding without disguising uncertainty.

The best data systems do not force people to choose between human intuition and computational rigor. They create a disciplined exchange between them. They let people begin with a hunch, make that hunch visible, test it against evidence, and revise it in public.

The question is not simply whether a system contains the right data. It is whether the people who need that data can recognize themselves, their questions, and their responsibilities in the way it is presented.

Until then, the audience is not outside the dataset. It is the missing field.