The Frame: how to build a knowledge layer for what your company knows about its users

Part six of UXR for AI-native teams, now a seven-post series (Why I decided to extend it? Cause I can).

Over the past few months I’ve had more meetings and questions about the Frame, and how to build one, than my calendar can handle. That makes me sound busier than I am. My calendar just gives up easily.

This post is the general idea. Every Frame ends up shaped by the team that builds it, so if you want more than a blog post can give you, write to me at cpapas@thevoiceofuser.com.

What is the Frame?

Most research reaches an organization as an event. A study runs, someone presents the readout, a team makes a decision, and what the study learned starts to fade as soon as the meeting ends. The next team with a related question starts from scratch. I’ve written before that the readout is an event and knowledge is a state. The Frame is the state.

The Frame is an organization’s actively maintained model of its users. It holds what the organization knows about who its users are, what they are trying to get done, why, what gets in their way, and how they decide. It is kept current, so it describes the users you have now, not the ones someone studied years ago.

Every part of it carries four properties. Coverage is which questions have answers. Freshness is how current the evidence is. Confidence is how strong the evidence is. Ownership is who keeps that part current. A part nobody owns stops being updated, and a part with old evidence keeps getting cited anyway.

The Frame is not the research repository, which stores past studies. It is not a persona set or a journey map, which are pictures of users drawn at one moment. And it is not the research strategy, which says what to study next. All of those should feed the Frame and draw from it.

Research stewards the Frame, but it does not own it alone. One person keeps the standard for the whole thing, each part has a named owner, and anyone whose work produces evidence about users can contribute, as long as that evidence meets the standard from last week’s post.

The Frame answers a question about users with the claims behind it, how sure they are, and what nobody knows yet

A PM types a question into the team's Frame web app (or Slack app): do new users read the verification explainer before they start uploading? A minute later she has this answer. (The details here are made up to show the shape.)

That answer is what the Frame produces. It cites its sources, says how sure it is, and names what is missing. It does not tell her what to build, because that decision is hers.

The last three posts each described one piece of this: the claim, the lookup, and the standard for what counts as evidence. This post puts the pieces together and shows how the Frame is built, because next week's post, about agents, depends on it.

Most teams don't have the Frame yet, and a repository is not one

Most of the teams I talk to don't have the Frame. They have a drive full of decks, a wiki, or a research repository, sometimes with AI search on top. Ask any of them the PM's question and you get documents back, or a confident paragraph stitched from them, with no dates and no way to tell which parts still hold.

A repository keeps documents whole and keeps adding more. Nothing in it expires, and nobody owns any piece of it. The Frame is written down as claims, organized around the questions the organization needs answered, owned piece by piece, and checked and pruned as the evidence changes. A repository can tell you none of the four properties above.

I've built one, and it is made of five parts that fit together

I've built the Frame and run it for real. It takes in research studies, and also market research, data science work, product metrics, and what customers say in feedback and in public. People ask it questions on the website or in the Slack app, and agents query it while they work. It is still growing.

What follows is the architecture in broad strokes. The details depend on what data a team can reach, how its organization treats evidence, and what tools it already has.

The Frame has five parts. The claim is the unit everything is built from. Intake turns studies into claims. The structure organizes claims around standing questions. Upkeep keeps the claims true. Access lets people and agents ask. Data that other teams track sits beside all of it, and the Frame queries it when a claim needs it.

The claim is one sentence about users, and everything else in the Frame hangs off it

A claim is one sentence about users that evidence could prove wrong. It carries its evidence, where that evidence came from, whom it covers and whom it doesn't, how sure the organization is, whether it still holds, when it was last checked, and who owns it. Part three made the case for the claim as the unit. Here is what one looks like with everything attached.

Two of those fields do most of the work. Confidence says how strong the evidence is, on one scale of three levels. A claim is strong when independent sources agree, or when a measurement was built for it. It is moderate when one study's design fits it. It is weak when the evidence doesn't quite reach it.

A belief with no evidence at all is not on the scale. It is an assumption, and it goes on a list of gaps.

Status says whether the claim still holds: current, contested, due for a check, or retired. Keeping confidence and status apart matters, because a strong claim can be contested, and a weak one can sit there unchallenged.

Recommendations stay out. "The explainer should be shorter" is a decision, and decisions belong to whoever makes them.

Intake turns each study into claims, with AI drafting and a person approving every one

A readout written for people has three parts: the claims, the details of how the study was done, and the story that made a team care. The claims go into the Frame. The details travel with each claim as its source and scope. The story stays with the readout, where it did its job for one decision.

AI does the first draft. It pulls candidate claims from the readout, each with the excerpt that supports it, suggests where each one belongs, and checks whether the Frame already holds the same claim. When it does, the new study's evidence is added to the existing claim instead of starting a new one. That is how confidence rises over time.

Two checks follow. Every excerpt is matched word for word against its source, because a model will happily paraphrase evidence into existence. Then the researcher who ran the study accepts, edits, or rejects every drafted claim.

Deep research is the exception. When a study is meant to rebuild the organization's understanding of who its users are and why they do what they do, the researcher writes the claims by hand.

Each study ends with a short record of what it changed: which claims it confirmed, revised, contested, added, or retired, and which questions it answered or opened. One person who keeps the standard for the whole Frame approves that record, and then the Frame changes.

Reports from teams that work like research, such as market research studies and support analyses, come in the same way.

The structure organizes claims around standing questions, and the open questions become the gap list

Each part of the Frame covers one group of users and one problem area, and each part has a named owner. Every part carries the same short set of standing questions, such as who the users are, what they are trying to get done, what gets in their way, and how they choose between options. Each question has a current answer built from claims.

The questions with no answer, plus the beliefs the organization relies on that no claim supports, make up the gap list. The gap list is what tells a team what to study next.

Because every claim says how sure it is and how current, you can see at a glance which areas are well studied, which are thin, which are going stale, and which are empty. Lay that map next to the roadmap, and the empty areas sitting under a big bet are your first research priorities.

Work on a single feature stays outside the core. A team working on one bet keeps its own working notes, and only the claims that hold beyond that bet get proposed to the Frame when it ends. That keeps the Frame small enough to maintain.

Upkeep keeps claims true by checking, contesting, and retiring them, and nothing is ever deleted

A claim is due for a check when the condition its study set for expiry is met, when it reaches the review age set for its topic, or when a metric tied to it moves outside its usual range. The check goes to the claim's owner, who confirms it with new evidence, narrows it, or retires it.

When two sources disagree, both claims stay, and the disagreement is written down with its likely reason: a different method, a different group of users, or a different year. A retired claim stays in the history with what replaced it. Every change is logged, and every change can be undone.

AI does the clerical part here too. It flags claims that are due, pairs of claims that contradict each other, and duplicates to merge. A person decides each one.

Access lets anyone ask, and every answer cites claims, names the gaps, and never recommends

Anyone can ask a question to the Frame, by searching it or by asking an assistant that reads it. The answer cites the claims it rests on, says how sure they are, and names what is missing, like the answer earlier in this post. It opens with a short summary in plain words, and the summary keeps every claim’s confidence and adds nothing the claims don’t say.

It never recommends, for the same reason recommendations stay out of the claims. A question the Frame cannot answer goes to the owner of that part. Over time, the questions people ask show where the demand is and where coverage is thin.

An answer from a thin part of the Frame reads just as fluently as one from a well-studied part. That is why every answer shows its confidence and its gaps.

The same access works for agents, which is next week's post.

Data other teams track stays where it lives, and the Frame queries it from the claims

Research comes first. Other data comes in only once the loop works: a question leads to a study, the study to reviewed claims, the claims to decisions, and the decisions to new questions. Adding data to a loop that doesn't work yet only makes the pile bigger.

Telemetry, product metrics, and experiment results are never turned into claims. They stay where they live, owned by the teams that keep them. A claim from interviews suggests a question to ask of the data, and the answer comes back as evidence on that claim, with its date and the query behind it.

Here is the kind of thing this makes possible. Take a survey item like "Verifying my identity was easy." The survey tells you whether people feel it was easy. Behavior tells you whether they finished, how often they retried, and where they dropped off. Support tickets tell you whether camera problems keep coming up.

When all three agree, the claim gets stronger. When they disagree, the claim is marked contested, and the disagreement is the interesting part. People who say verification was easy but retried several times are a different problem from people who say it was hard and gave up.

A person still decides what each result means. A correlation in the data does not turn the reason people gave in interviews into a cause.

You can start the Frame in a spreadsheet, and most of the work is reading what you already have

You don't need my system, or anyone's tool, to start. One row per claim in a spreadsheet works, with the columns from part three.

Start with one working session. Write down what the organization believes about its users, how sure it is, and who owns each belief. Draw the grid of user groups and problem areas, and give each part an owner. Then have AI draft claims from the last few years of studies, review every one, and place them under the standing questions.

The gaps show up quickly. Run the first new study on the emptiest area that sits under a big bet, put every study after it through intake, and add other teams' data only once that loop works.

Two limits apply. The Frame that takes in everything turns back into the archive it was meant to replace, so the core keeps only claims about users that answer the standing questions. And query results expire like any other evidence, because they have a date and a scope too.

Next week

The Frame answers people well. Its most demanding reader is not a person at all. Agents building your product settle questions about users dozens of times a day, and right now they settle them from nothing.

The final post covers how to give them what the Frame knows: the form it has to take, the two ways it can reach them, and the rules they follow once they have it.

If you've built something like this, or tried and stopped, my email is open, and I mean that. I'd like to compare notes.

See you next week.

🎯 This is part six of UXR for AI-native teams, now a seven-post series. Subscribe, and the rest arrives as it publishes, no algorithm required.

📖 If the fast-research layer underneath this series is the part you need first, that's my book: AI-Powered UX Research, the operating manual for running research at the speed your team actually needs. This series is what I've been thinking since.