In the first newsletter in this series on decision intelligence for L&D, I made the case that learning analytics only earns its place when it is built around decisions rather than around reporting. In the second, I argued that most organizations already hold more decision-relevant data than they realize, and that a bottom-up inventory combined with a top-down conversation about what decisions matter is the place to start.

If you have done that work, or even thought seriously about it, you will have arrived at the same place most organizations arrive at: a data gap.

This newsletter is about how to close it. And the answer is not what most people expect.

Some of the decisions that matter most to you cannot created because you do not have the data. Either the data does not exist, or it exists somewhere but is too fragmented, too inconsistent, or too inaccessible to be useful. The inventory revealed what is there. The conversation with leadership revealed what is needed. And between those two things, there is a space that needs to be closed.

We design things to deliver learning, manage administration, or support HR operations. Data is often an afterthought, if it was thought about at all.

The result is that organizations end up with tools that generate enormous volumes of data that is inconsistently defined, poorly structured, and practically impossible to connect across sources. And processes that pay zero or limited attention to making sure data is captured consistently and accurately.

You can buy the best analytics platform in the market and point it at that data, and what you get back will still be incomplete and unreliable.

Closing the data gap sustainably requires going upstream. It requires designing the conditions that make the right data possible in the first place. That is what I mean by designing for data.

Design for data is a more of mindset shift than anything else. It means that when you make decisions about technology, processes, learning programs, and roles, you consistently ask one additional question alongside all the others:

That question sounds simple. In practice it changes a surprising number of decisions.

When you are selecting a learning technology, you not only ask whether it delivers a good learner experience or integrates with your existing stack, but also

A platform with a beautiful interface that locks your data in a proprietary format or makes extraction difficult is a much worse choice than it appears on a demo.

When you are designing a learning program, you ask not just what participants will learn and how they will experience it, but what signals the program will generate that tell you whether it is working. Not just completion and satisfaction scores, but behavioral indicators, performance markers, and evidence of transfer during the program and back to the workplace.

When you are designing an L&D process, whether that is an intake process, a design process, evaluation process or delivery process, you ask whether the process is generating data at the points where it matters, whether that data is being captured systematically, and whether it will be available in a form that connects to the broader data landscape.

When you are defining roles, whether inside L&D or in partnership with HR, you ask whether the people in those roles are generating and working with data as a natural and strategic part of their work, or whether data activity is treated as a separate administrative burden that gets deprioritized under pressure.

Each of these is a small shift in emphasis. Cumulatively they produce an organization where data is generated by design rather than by accident, and where the gap between the data you have and the data you need closes steadily over time rather than persisting indefinitely.

The learning technology market is large, noisy and full of platforms that make bold promises about analytics and AI capability. Cutting through that noise requires a clearer set of evaluation criteria than most organizations currently use.

The questions that matter most from a design for data perspective are not the ones that typically dominate technology selection. They are not about interface quality, content library size, or the sophistication of the recommendation engine. They are about data architecture.

How is data structured within this platform? Are events and interactions captured in a consistent format and a solid model, or are they buried in summary reports that cannot be disaggregated?

Can we configure the platform to capture company specific data, via custom fields or other means?

How easy is it to get data out? Does the platform offer a well-documented API, clean data exports, or integration with standard data infrastructure? Or does accessing your own data require submitting support tickets and waiting for vendor cooperation?

What does the platform do with your data? Is it used to train shared models that benefit the vendor's other customers? Is it available to you in a form that you can take elsewhere if you change platforms?

How does the platform define the things it measures? What counts as a completion, an assessment attempt, an engagement event? Are those definitions compatible with how your other systems define the same concepts?

These questions are less exciting than asking about AI features or content partnerships. But they determine whether the platform will contribute to closing your data gap or to deepening it. A platform that generates rich, accessible, well-structured data in a consistent format is worth considerably more, from an analytics perspective, than one that generates impressive-looking dashboards but makes it impossible to connect that data to anything else.

One of the most underused levers for closing a data gap is learning program design itself. Most programs are designed to deliver an experience. Very few are designed to generate evidence.

Designing for data at the program level means being explicit, before design begins, about what the program needs to demonstrate in order to justify its existence and guide its improvement. Not just whether participants found it valuable, but

That clarity changes design decisions in concrete ways.

It means for example building in structured checkpoints rather than relying solely on post-training surveys. It means designing assessments that test application rather than recall, because application scores are more predictive of transfer than knowledge scores. It means creating moments in the program where participants connect learning to specific work situations, producing qualitative data that complements quantitative signals. It means designing manager touchpoints that generate structured observations about behavior change, rather than leaving post-program support entirely to chance.

For boutique learning programs, the kind of high-quality, deeply contextual experiences I wrote about in the vision series, this is especially important. Boutique learning is more expensive, and that investment needs to be justifiable. The only way to justify it credibly is to design the evidence of impact into the program from the beginning, not to try to retrofit measurement after the fact.

Some of the most decision-relevant data available to L&D and HR does not come from learning systems at all. It comes from the operational processes that surround learning: needs analysis, learning deployment processes, design processes, and even budgeting processes

This data is often hiding in plain sight. It exists in emails, documents, local spreadsheets. But it is rarely connected to learning data, and it is rarely designed to generate the signals that would make it useful for learning analytics.

Designing for data at the process level means identifying the moments in learning processes where relevant signals naturally occur and ensuring that those moments are captured systematically. When someone makes notes during a learning needs analysis workshop, that is data. When a request comes in for training, that is data. When you manage a development project, you generate a lot of data. When you approve 3rd party offers, that is data.

Most of these signals require new technology to capture. They require process design that treats data capture as a first-class consideration rather than an administrative add-on. And they provide the means to all L&D employees to take the necessary time to ensure the data is captured accurately and completely

Once you have begun designing for data across technology, programs and processes, you face a new challenge. Data is being generated in more places, more consistently, and in better formats. But it is still distributed across multiple systems, defined in slightly different ways, and stored in formats that do not naturally connect.

This is where the architecture question becomes unavoidable. And it is where a concept I introduced in the vision series becomes practically important: the Learning Data Pond.

The Learning Data Pond is an intermediate data layer that sits between your individual learning tools and systems on one side, and your broader enterprise data infrastructure on the other. Its job is to collect data from all learning-relevant sources, resolve inconsistencies in definitions and formats, clean and structure that data into a coherent model, and make it available in a form that analytics and AI can actually use.

Think of it as the place where the outputs of all your design for data decisions come together and become genuinely useful. Data that was designed to be captured flows into the pond. Data that was designed to be consistent is easier to reconcile there. Data that was designed to be accessible arrives in formats that the pond can work with without heroic engineering effort.

The pond does not replace the need for good data design upstream. If the data flowing in is poorly structured, inconsistently defined, or practically inaccessible, the pond cannot fix that. What it can do is take well-designed data from multiple sources and create the unified, clean, analytics-ready layer that makes decision intelligence possible in practice.

And once that layer exists, something important becomes possible that was not possible before. Learning data can flow onward into the enterprise data lake, where it can be connected to business performance data, operational metrics, financial outcomes, and workforce data. At that point, learning data stops being isolated in its own silo and becomes part of the broader intelligence infrastructure of the organization. Skills connect to performance. Learning investment connects to business outcomes. Evidence replaces assumption.

This is not a small ambition. But it is a reachable one, and the path to it runs directly through the design for data decisions described in this newsletter.

Designing for data is not a transformation program. It is a habit. And like most habits, it is best started small and built incrementally rather than launched as a big initiative.

The most practical starting point is to pick one upcoming decision and work backwards from it. Choose a technology selection, a program redesign, or a process review that is already on your agenda. Before you proceed with it in the usual way, add the design for data question explicitly to the brief: what data should this generate, what decisions should that data inform, and how will we ensure it is captured in a form that is clean, consistent and accessible?

That exercise will feel slightly unfamiliar the first time. It will feel slightly less unfamiliar the second time. By the fifth or sixth time, it will feel like a natural part of how decisions get made. And at that point, your data landscape will be visibly different from what it was when you started, not because of a platform purchase or a transformation initiative, but because of a consistent shift in how you think about the work.

The gap between the data you have and the data you need does not close all at once. It closes one well-designed decision at a time.

What comes next

The first three newsletters in this series have built a foundation. Decision intelligence as the purpose of analytics. The data inventory as the starting point. Designing for data as the path to closing the gap.

The fourth and final newsletter brings a dimension into the picture that changes the stakes considerably. Organizations are already making decisions with AI, and that shift is accelerating. The quality of those AI-supported decisions depends directly on the quality of the data and decision intelligence infrastructure that sits beneath them. L&D teams that have done the work described in this series are not just better at analytics. They are positioned to lead in an AI-driven organization in ways that most of their peers are not yet thinking about.

That is where we go next.

Peter Meerman SLT Consulting — Learning Analytics Made Easy