Information Design for Humans at Work

THE OPERATING SEQUENCE

These Parts are dependencies, not a requirement to perform every possible method at maximum depth.

Start with what you genuinely know. Use the evidence, expertise, and testing the situation warrants. Calibrate the method to the uncertainty, stakes, and consequences of getting the next decision wrong.

When new evidence changes an earlier answer, revise that answer.

WAYS IN

READ THE SEQUENCE AS DEPENDENCIES  Use the evidence, expertise, and testing the situation warrants. When new evidence changes an earlier answer, revise that answer.

GUIDE MAP

The Guide Map answers “Where do I go to do this?”

ORIENTATION

INFORMATION PROBLEMS OFTEN ARRIVE AS SYMPTOMS

Phone calls, emails, support requests, frustrated public posts, repeated questions, stalled reviews, or the same internal expert being pulled in again and again.

Sometimes they arrive disguised as a solution request:

We need a page.

We need an FAQ.

We need a comparison.

We need better documentation.

Use this guide to follow those signals back to the people affected.

What are they trying to accomplish? What does the situation require of them? What must information enable? What does their current information environment actually enable? What could you change? Did the intervention help?

By information environment, this guide means the information people can encounter and use while trying to accomplish something: pages, documentation, search results, AI answers, systems, records, conversations, evidence passed between people, and the paths that connect them.

The people are the reason for the investigation.

The information environment is what you can change.

Questions to answer

1. Who is affected, what are they trying to accomplish, what does the situation require of them, and what happens if they get it wrong?
2. What must information enable for them to understand, judge, verify, act, or pass a finding, decision, or evidence onward appropriately?
3. What does their actual information environment enable now, and where is there a meaningful gap?
4. What could you change in the information environment to address that gap without weakening necessary judgment, verification, or scrutiny?
5. What should become better for the people involved, and how could you test that in a way you can interpret?
6. What happened when people used the intervention, and what does the result make more or less plausible?
7. What does the evidence actually support, and what, if anything, should happen next?

Use this guide when

Use this guide when:

• a sales page, product page, FAQ, comparison, documentation project, AI prompt, support question, stakeholder request, or other visible signal may point to a larger information problem;
• the same apparent question means different things depending on role, situation, version, configuration, constraints, or consequences;
• important information exists but is fragmented, stale, contradictory, difficult to verify, poorly sequenced, hard to encounter, or difficult to carry to another person;
• people repeatedly compensate for the information environment through expert calls, private spreadsheets, manual reconstruction, old PDFs, repeated meetings, Slack messages, or other workarounds;
• several people need to use the same underlying evidence differently;
• you need to decide whether the appropriate change is consolidation, clearer relationships, governance, routing, comparison, provenance, documentation, a new artifact, or no intervention yet;
• you need to know whether an information change actually helped the people it was intended to support;
• AI Visibility has established a change in the answer environment, but whether the information helps people remains unknown.

Formal field research is not required for every information problem; use enough evidence to make the next decision responsibly.

When the work is a purchase decision

Purchase decisions are one application of this method, not a separate method.

If your signal involves fit, comparison, verification, approval, rejection, implementation conditions, or evidence that must pass between people involved in a purchase, start with Part I as you would for any other information problem.

When you reach Part IV, see Info Design at the Bottom of the Funnel for purchase-specific intervention guidance.

For the earlier Citation Labs work that informed this application, see Part IX: Methods, Lineage, and Sources.

Evidence boundaries

Different observations tell you different things.

• A keyword, prompt, support question, complaint, or stakeholder request can establish a signal. It does not necessarily describe the full situation behind it.
• A public discussion can establish that a difficulty, question, workaround, or disagreement occurred. It does not establish prevalence by itself.
• An observed information condition – for example, several sources conflict or no canonical source exists – does not by itself establish what people need or which intervention will help them.
• A product or domain expert can establish technical truth, conditions, exceptions, and authoritative evidence. That does not make the expert a substitute for the people who must use the information.
• Someone who understands a review, approval, implementation, or professional process can establish what matters in that context. One person’s account does not establish how every organization or practitioner behaves.
• AI retrieval, citation, answer omissions, or query decomposition can point toward something worth investigating. AI behavior is not proof of human information need.
• Changing the information environment does not by itself establish that people became better supported.
• A demonstrated improvement for people does not by itself establish an organizational, commercial, or economic consequence.

Use an evidence state when the strength of a finding, requirement, interpretation, expected effect, or handoff matters to a decision. You do not need to classify every sentence.

Provenance remains separate. Record where the evidence came from, such as public human evidence, first-party records, information-environment inspection, domain expertise, process expertise, direct evidence from the people involved, AI-system behavior, analyst inference, or another source.

Prefer a sparse, evidence-grounded record to a complete-looking invented one.

One working record

Use one working record throughout the investigation.

Build the working record as the investigation develops. Add what each Part needs as you go.

Before the intervention, the record should eventually contain the starting signal, the people and situation that matter, important evidence and unknowns, what information must enable, what the current information environment enables, the material gap, the proposed intervention, the expected effect, the measures and guardrail, and the planned test setup.

After testing, add what was tested, who encountered it, what was observed, whether the guardrail held, what remained unchanged or inconclusive, your interpretation, the strongest supported result, important limits, the next decision, and any genuinely new question worth investigating elsewhere.

The complete printable working record appears in the Appendix.

THE CITATION LABS FIELD-GUIDE FAMILY

Start anywhere. The next unresolved question determines the guide.

AI VISIBILITY: DIAGNOSE, INTERVENE, RE-TEST

AI VISIBILITY: DIAGNOSE, INTERVENE, RE-TEST investigates the AI answer environment: what systems find, retrieve, cite, represent, omit, and recommend, and whether an AI-facing intervention changed those conditions.

INFORMATION DESIGN FOR HUMANS AT WORK

INFORMATION DESIGN FOR HUMANS AT WORK investigates human work and the information environment: what people are trying to accomplish, what information must enable, where the environment falls short, what should change, and whether the change helped.

TRACING BUSINESS IMPACT BEYOND THE CLICK

TRACING BUSINESS IMPACT BEYOND THE CLICK investigates whether a bounded information or human-work result produces a meaningful organizational consequence – or whether an observed business burden or opportunity has an information component worth investigating.

QUESTIONS, NOT ARTIFACTS  The guides own questions and evidence, not pages, resources, or systems. The same artifact may appear in more than one guide, but each kind of effect must be established separately.

HANDOFF RULE  When work moves, carry the established result at the strength already earned, together with its evidence state, evidence and provenance, material conditions, important limits, and the next uncertainty or hypothesis. Do not upgrade it on arrival.

ANOTHER DOMAIN  Product truth, Engineering judgment, Finance definitions, Legal or regulatory interpretation, formal causal estimation, and other specialist questions belong with the person or method closest to them.

USING THIS GUIDE WITH AN ASSISTANT

An assistant can help organize evidence, preserve distinctions, identify missing questions, test the logic of a proposed claim, and draft the working record. It cannot establish facts about people, systems, or the organization that its sources do not support.

When using more than one guide, ask the assistant to identify which guide owns the next unresolved question and to carry the established result forward without upgrading it.

FAMILY ROUTER PROMPT  “Here is what we know and the current Evidence to Carry Forward block. Which guide or specialist domain owns the next unresolved question? Separate the established result from the working hypothesis, preserve the evidence state and provenance, and begin in the receiving method without upgrading the claim.”

PART I – FOLLOW THE SIGNAL TO THE HUMANS AND THEIR WORK

Begin with whatever made the issue visible, then follow it to the people and work behind it.

An information problem may first become visible as a complaint, a support question, a repeated request for help, a stalled review, a sales objection, a public discussion, an AI finding, or a request for a particular solution.

Treat those as signals that something deserves investigation; the people and situation behind them determine the problem you need to understand.

A request such as “we need a security page” or “we need an FAQ” already contains a proposed intervention. Before accepting it, follow the signal far enough to identify the people whose responsibilities, judgments, or actions are actually affected.

At this stage, establish the people, situation, and stakes. The information change comes later.

1. Start with the signal and follow it to the situation

Name the signal that made the issue visible.

It might be the same question appearing in support again and again, an expert being pulled into routine calls, a review that repeatedly stalls at the same point, people publicly describing confusion or workarounds, a sales or implementation objection, an information source that produces contradictory answers, an AI answer that repeatedly omits an important condition, or a request such as “we need a comparison page.”

Treat the signal as evidence that something deserves investigation, then test what problem actually exists for the people and situation behind it.

For example:

Signal: Prospects keep asking Sales Engineering whether the gateway can operate without cloud connectivity.

The signal is useful because it gives you a place to begin.

But from the signal alone, you still cannot know whether the underlying problem is missing documentation, confusing terminology, version ambiguity, an unusual deployment requirement, poor routing to existing evidence, or something else.

Your next question is:

Who does this issue affect, and what are they trying to accomplish?

2. Locate the humans and understand what they are trying to accomplish

Identify the people who actually have to do something with the information.

Use ordinary field-native role names where possible: security reviewer, operator, clinician, procurement lead, implementation engineer, administrator, developer, parent, mechanic, teacher.

Use demographic characteristics only when they materially change what people need from the information.

A vague description does not tell you much:

Enterprise buyer researching security.

A useful description does:

An OT security reviewer at a regulated manufacturing company is deciding whether an industrial gateway can enter the plant architecture without violating security and operational requirements.

In the second description, there is a person doing specific work, under specific constraints, for whom some information will matter more than other information.

Ask:

• What are they responsible for?
• What are they trying to accomplish?
• What triggered the situation now?
• What do they have to determine, judge, verify, decide, explain, approve, reject, execute, or pass to someone else?
• What authority do they have?
• What constraints are real?
• What happens if they get it wrong?

The word decision should not narrow your view. People may need to understand, compare, diagnose, verify, rule out, approve, reject, execute, communicate, transfer, revisit, or coordinate something. A purchase choice is only one kind of consequential work.

Pay attention to stakes without inflating them. Relevant stakes and constraints may include safety, money, regulation, legal exposure, technical compatibility, implementation capacity, time, authority, dependency, policy, or reversibility.

Use those stakes later to decide how much evidence, expertise, and testing the problem warrants.

3. Include the other humans who materially matter

People often depend on one another.

A reviewer may make an initial judgment. An expert may establish what is technically true. Another person may challenge the evidence. Procurement may require proof that a review occurred. Legal may care about exactly what can be claimed. An implementation team may later have to act on what was approved.

Include the people whose contribution, judgment, approval, challenge, receipt, or use materially changes what information must enable.

For each relevant participant, ask:

• What do they own?
• What can they approve, reject, challenge, or require?
• What do they contribute that another person cannot simply assume?
• What do they receive from someone else?
• Where does information or evidence pass from one person to another?

The same underlying evidence may need to serve several roles. That does not automatically mean those roles need separate bodies of truth.

Example:

• Product Security may establish what is technically true.
• A buyer-side security reviewer may determine what evidence is sufficient for approval.
• Procurement may need proof that the review occurred.
• Legal may care about the exact scope and wording of a claim.

Include people and handoffs only as far as they materially affect what someone needs to understand, judge, verify, approve, or pass onward.

When the work is a purchase decision

Do not assume the person who found the page is the whole audience. The visible searcher may be one participant in a larger purchase system.

Ask who else must use, judge, approve, challenge, implement, or live with the choice. Then ask what each person receives, what they must establish, and what must survive when a finding or evidence moves to the next person.

Where the deal appears stuck is not necessarily where the information gap lives.

For example, Procurement may appear to be delaying a purchase because it is waiting for a security review. The security reviewer may be waiting because version-specific applicability cannot be established from the available evidence. The visible stall is at one seat; the information gap is at another.

A useful handoff question is: what does this person receive from someone else, and what do they have to produce for the next person?

Purchase Decision Support develops the buying-committee side of this problem in more detail.

4. Look for traces of how people are actually doing this

Begin with traces you can already inspect.

Useful traces often appear where people are already trying to resolve the problem:

• repeated questions;
• things people cannot find;
• things they discover too late;
• requests for evidence;
• version or applicability confusion;
• workarounds;
• repeated reliance on an expert;
• copied, forwarded, screenshotted, or reconstructed information;
• reasons people reject, delay, or escalate;
• contradictory answers;
• terms different people use differently;
• disagreement about what counts as sufficient evidence;
• points where published information and practitioner understanding diverge.

Possible sources include public discussions, professional communities, reviews, support conversations, technical documentation, implementation discussions, standards, practitioner material, support tickets, sales transcripts, CRM notes, customer-success records, site or internal search, win/loss material, implementation records, and existing user research.

Use each source for the kind of statement it can actually support.

A single support ticket or public thread can establish that a problem occurred. It does not establish how common the problem is.

A standards document may establish a formal requirement without telling you how people encounter it in practice. A vendor FAQ can establish what has been published without showing whether the relevant person can find, interpret, trust, or reuse it in the work that follows.

How to look

Search in the language people use while trying to solve the problem, not only in category language.

Useful formulations may include:

• “I can’t find…”
• “Does X actually…”
• “Which version…”
• “What happens if…”
• “The documentation doesn’t say…”
• “Support told me…”
• “How are you supposed to…”
• “Do I need…”
• “X vs. Y when…”
• “I wish I’d known…”

Combine that language with the product, role, failure, constraint, task, or situation you are investigating. For example, a field phrase such as “which version” might become searches like “gateway certificate rotation which version,” “firmware version certificate lifecycle,” or the equivalent language used in the domain.

Search where unresolved activity becomes visible.

As you learn the field’s language, search again. Save the useful query, source, person or role, situation, and the question it helped answer in the working record so the trail can be revisited.

Using AI during this work

A web-enabled AI assistant can help collect sources, extract relevant passages, surface contradictions, organize evidence, and identify questions that deserve a stronger check.

Use it to help find and organize evidence while keeping human need grounded in evidence about people and situations.

Ask it to preserve sources and context, distinguish source evidence from analyst inference, identify conflicting conditions, and leave prevalence or human need unresolved when the evidence does not establish them.

AI behavior itself may also be a signal. Repeated omission, retrieval patterns, or query decomposition can point toward something worth investigating.

Treat AI behavior as evidence about the AI system. Use it as a signal for human investigation when the people-side need is still unknown.

CALL AI VISIBILITY  Call when the unresolved question is specifically what an AI environment retrieves, cites, distinguishes, represents, omits, or recommends. Bring the human situation and the evidence requirements that the AI-mediated path must preserve.

Use the evidence needed to understand the people and situation

When something important about the people or situation remains uncertain, ask what evidence would help you understand it well enough for the next decision.

Different evidence may confirm, qualify, contradict, reveal a condition or branch, or leave the issue unresolved. For example, a technical manual may establish what is possible, a reviewer may establish what must be proven for approval, and observed work may show where the evidence is repeatedly reconstructed. No single source has to resolve the whole question.

Public and first-party traces may be enough when the intervention is modest or reversible, the consequences are limited, and uncertainty can remain visible.

Add product or domain expertise when technical truth, conditions, exceptions, standards, regulation, or professional judgment could materially change your understanding.

Add review, approval, or work-context expertise when you need to understand what actually matters in a professional process.

Add direct research with the people involved when actual behavior is highly contextual, public evidence is thin, experts may describe ideal rather than real practice, the consequences are high, or an expensive intervention depends on unchecked assumptions.

The governing rule is:

Use a method strong enough for the uncertainty, stakes, and consequences of the decision you intend to make.

You are ready for Part II when

You should be able to explain, in ordinary language:

• who is affected;
• what they are trying to accomplish;
• what situation makes the information matter now;
• what constraints, stakes, and consequences shape the situation;
• which other people materially matter;
• what evidence supports this account and what remains inferred, hypothetical, or unknown.

At this point, keep the intervention open.

You need a credible enough understanding of the people and situation to ask the next question:

Given this situation, what must information enable for them?

PART II – ESTABLISH WHAT INFORMATION MUST ENABLE FOR THEM

Once you understand the people and situation well enough to reason from them, establish what information must make possible in that situation.

Begin with what people are trying to accomplish and what the situation requires; treat the requested page, document, tool, format, or answer as one possible intervention rather than the requirement itself.

What must these people be able to understand, determine, judge, verify, explain, coordinate, or pass onward for the situation to be handled well?

Sometimes information should reduce unnecessary reconstruction or repeated clarification.

Sometimes it should make a distinction easier to see.

Sometimes it should make evidence easier to verify or preserve through a handoff into another person’s work.

Sometimes its job is to make an important condition or uncertainty visible so a person knows not to proceed without further judgment.

5. Translate what people must accomplish into information requirements

Translate the requested artifact into the human capability the information needs to support.

Weak:

Create a security guide.

Stronger:

The security reviewer must be able to determine which authentication and certificate capabilities apply to the product and software version being evaluated, verify those capabilities against authoritative evidence, recognize important deployment conditions, and preserve the finding and its conditions in formal review.

The stronger statement gives you something specific to design for.

You do not need to force every requirement into a fixed vocabulary.

Useful verbs may include understand, distinguish, compare, verify, determine, explain, transfer, or revisit, but the ordinary language of the situation is usually better than fitting the requirement to a taxonomy.

The test is simpler:

If the information were doing its job well, what would these people be better able to do?

Treat the question a person asks as evidence of how the need is expressed, then establish the fuller requirement from the situation.

Robert Taylor’s work on question negotiation is useful here: the question someone finally expresses may differ from the underlying information need. Use it when a prompt, support question, intake request, or stakeholder request risks being treated as a complete specification.

A question can reveal part of the requirement without expressing everything the situation demands.

Someone may ask:

Can this gateway run offline?

But the situation may require more than a yes or no. They may need to distinguish core local operation from remote-management functions, determine which version or configuration the answer applies to, understand prerequisites, verify the answer against an authoritative source, and know which conditions still require expert review.

A search query, support question, AI prompt, sales objection, or intake request may therefore be useful evidence of how the problem is expressed without being a complete specification of what information must enable.

A sales objection is a signal, not a requirements document.

CONSTRUCTED SERVICE EXAMPLE

Imagine a drug company deciding whether to bring in outside help to assess potential medicine safety signals. Its pharmacovigilance lead may begin with a simple question: “What signal-management services does this company offer?” The people involved may need to establish:

• which signal-management activities the engagement covers;
• what evidence and inputs are required;
• who reviews, decides, or acts at each stage;
• which responsibilities remain with the client or another specialist;
• what remains unresolved or conditional;
• what information and conditions must survive procurement and transition.

This is a constructed illustration, not an observed buyer case, a verified gap in any company’s current information, or pharmacovigilance guidance.

Close to a purchase, sales calls, win/loss notes, site search, AI prompts, product-page questions, and objections can provide a rich stream of expressed questions. Use them. But keep asking what the person must ultimately conclude, verify, reject, explain, or carry forward—and which other people or conditions make the requirement larger than the literal question.

The practical shift is from “What answer should we publish?” to “What must this person be able to establish well enough to do the purchase work responsibly?”

When you need more evidence to establish the requirement

You may know a great deal about the situation and still be uncertain about what good information must enable.

Use evidence suited to the unresolved question.

When technical truth matters, use people and sources capable of establishing applicability, conditions, exceptions, and authoritative evidence.

When review or professional judgment matters, learn what a person must establish before they can approve, reject, escalate, recommend, or proceed.

When actual practice matters, go directly to the people involved when formal process or expert description may not show how they actually proceed, adapt, compensate, or hand things off.

Prepare before asking experts. Bring the traces, apparent contradictions, current understanding, and specific unknowns so the expert can spend attention on corrections, conditions, exceptions, and authoritative evidence.

Ask questions capable of changing your understanding:

• What changes by version, configuration, geography, regulation, use case, or environment?
• What must be established before the person can proceed?
• What do experienced people check that may be easy to overlook?
• What causes rejection, delay, or escalation?
• What evidence is sufficient?
• What should remain uncertain because there is no universal answer?
• What conditions or uncertainty must remain visible?

Use expert and practitioner evidence to correct, qualify, branch, or overturn the requirement as needed.

6. Keep conditions, branches, disagreement, and uncertainty visible

An information requirement is often conditional.

A statement that is useful for one product version may be misleading for another.

A review requirement may change by jurisdiction.

An experienced practitioner may make a different judgment in a high-risk case than in a routine one.

Two credible experts may disagree because they are reasoning from different conditions rather than because one is simply wrong.

Preserve the differences when they expose conditions that change the requirement.

Ask whether the disagreement exposes a meaningful branch:

When condition A holds, information needs to enable X. When condition B holds, the requirement changes.

Keep corrections, exceptions, disagreements, and predictions distinct.

A prediction about what people will do if an information problem is fixed remains a hypothesis until it is tested.

When the evidence does not support a more specific answer, leave the uncertainty visible.

Record UNKNOWN when the available evidence does not support a stronger claim.

That records the current boundary of the evidence and identifies what may still need to be learned.

7. Support the judgment and scrutiny people must exercise

Information Design should reduce accidental effort while preserving the judgment, scrutiny, and responsibility the situation requires.

Some friction is accidental: searching six documents for one condition, repeatedly calling an expert for routine clarification, rebuilding a comparison by hand, or losing provenance during a handoff.

That is often worth reducing.

Other effort is necessary. A security reviewer may still need to verify a deployment-specific condition. A clinician may still need to exercise judgment. An approver may need to challenge the evidence. A high-risk exception may still require escalation.

Good information should help people perform that work well.

Ask:

• What judgment or scrutiny should the information strengthen?
• What unnecessary reconstruction could it reduce without weakening that judgment?
• What should become easier to notice, verify, challenge, or escalate?

A warranted no, delay, escalation, or request for more evidence may be a good information outcome when sound judgment requires it.

When omission matters, define what a competent answer must contain

When omission could make an otherwise correct answer unusable or misleading, define what a competent answer has to contain.

In those cases, define what a competent answer has to contain.

When someone may rely on an answer to make a consequential judgment, ask what has to be present for the answer to be usable rather than merely technically true.

That might include:

• the claim or finding;
• the applicable scope, service, product, version, configuration, population, responsibility, or condition;
• important prerequisites;
• exceptions or limitations;
• currentness;
• authoritative source;
• enough evidence to verify the answer;
• or a clear indication that further review is required.

A brand mention or citation may help, but adequacy depends on whether the answer includes the consequential conditions and evidence the situation requires.

8. Establish where the information must be usable and what must survive between people

Information helps when people can encounter and use it where the work actually happens.

Ask where people need to encounter, interpret, verify, or act on it.

That may be technical documentation, a product page, a support workflow, an internal system, a procurement tool, a meeting or review packet, an AI assistant, search, a sales conversation, an implementation environment, or another place where the situation actually unfolds.

If an AI assistant is one of those environments, record it as part of the information path. The person remains the reason for the design; the assistant is one way information may be retrieved, summarized, compared, or brought into judgment. Use AI Visibility when the unresolved question is specifically whether that assistant can retrieve, cite, distinguish, or represent the underlying evidence accurately. Part IV returns to designing the human-facing path.

Ask first:

Where must this information be usable for people to do what they need to do?

Then identify the relevant surfaces, systems, conversations, and handoffs that make up that path.

A useful answer names where the information has to work, not merely where it could be published.

Different people in the same situation may encounter the same underlying evidence in different places.

When information passes between people, decide what must remain attached to the finding or evidence.

Depending on the situation, that might include source, condition, version or configuration, date or currentness, limitation, rationale, confidence or uncertainty, or evidence needed for independent verification.

A finding can be correct at first and still fail the situation if source, condition, or limitation disappears before the next person can use it.

Different people may also need different things from the same underlying evidence. Product Security may need technical precision. A buyer-side security reviewer may need applicability and verification. Procurement may need evidence that approval occurred. Legal may need the exact scope and limitation of a claim. Implementation may need the conditions translated into configuration requirements.

Different uses can be supported from one coherent body of underlying evidence.

Paul Carlile’s work on knowledge boundaries is useful when information crosses professional or organizational contexts. The problem may require information to be transferred, translated, or transformed rather than simply handed off.

Design the requirement so different people can use the evidence for their work without losing coherence, source, conditions, or meaning.

Keep question expressions connected to the people and situation they came from

Once the requirement is clear, you may collect or generate the different questions people use to express it.

Those may come from observed human questions, support or sales language, public discussions, expert phrasing, direct work research, analyst reformulation, or AI-generated variants.

Record the provenance of useful question expressions in the working record: where the expression came from, which person or role used it, the situation it belonged to, and whether it is observed, expert-provided, analyst-reformulated, or AI-generated.

That connection lets you distinguish a field expression from an analyst convenience and revisit the human situation it represents.

Information Design can establish that a question expression represents some aspect of the situation. It does not establish how much demand that expression has or whether it belongs in a tracked AI prompt set. That is a separate question.

You are ready for Part III when

You should be able to state, in ordinary language:

• what information must enable for the people involved;
• what important conditions, exceptions, or branches change that requirement;
• what evidence supports your understanding and what remains uncertain;
• what must a competent answer contain when omission would matter;
• what judgment, scrutiny, verification, or escalation information should support rather than remove;
• where the information must be usable;
• what must remain intact when evidence or findings pass between people.

A useful Part II result might sound like this:

For the security reviewer, the information must make version and configuration applicability clear enough to judge fit, verify consequential claims against authoritative evidence, recognize when deployment-specific review is still necessary, and preserve the resulting evidence, source, conditions, and limitations in formal review. The approver must then be able to use that preserved context to judge what was established without reconstructing the review.

This is the requirement against which you will inspect the current information environment.

It keeps the people and their work visible before an intervention is selected.

Part III now compares that requirement with the environment people actually have.

PART III – IDENTIFY THE INFORMATION GAP

By the end of Part II, you should have a grounded description of what information must enable for the people involved.

Now compare those requirements with the information environment they actually have.

Here, the information gap means the consequential difference between what the people and situation require information to enable and what the current information environment actually enables.

Inspect that difference directly:

What does the current environment enable for these people in this situation?

Then compare it with the requirement:

Where does the environment fall short, create unnecessary reconstruction, lose important conditions, or otherwise fail to support the work that matters?

That consequential difference is the information gap an intervention may address.

9. Inspect the actual environment against the requirements

Inspect the environment requirement by requirement, using Part II rather than a generic list of content defects as the standard.

Return to the requirements you established in Part II and inspect the environment against them one by one.

If a reviewer needs to establish which product capability applies to a particular version, inspect whether the available information actually lets them do that.

If someone needs to verify a consequential finding, inspect whether an authoritative source, currentness, applicability, and important conditions can actually be established.

If the situation includes a handoff, inspect whether the source, conditions, limitations, and meaning needed by the next person remain usable after the transfer.

If the situation requires comparison, inspect whether the meaningful criteria can actually be compared rather than merely found separately.

Useful inspection questions include:

• Does the information exist at all?
• Is there an authoritative source?
• Is it current?
• Is the applicable product, version, configuration, population, or condition clear?
• Can it be verified?
• Can the relevant person reach it from a plausible entry point?
• Can they interpret it without unnecessary reconstruction?
• Can it be compared, preserved through a handoff, or revisited where that matters?

Before treating a source or path as something to replace, change, or retire, inspect what it already supports.

Ask:

• Which established information requirements does this source or path already serve?
• Which people, tasks, or handoffs depend on it?
• Does it reflect an earlier intervention or decision that still matters?
• Who currently owns it?
• What would become harder to find, verify, interpret, or carry forward if it changed?

The same source may work well for one requirement while contributing to a gap elsewhere. Preserve that distinction in the diagnosis.

A missing comparison table is an observable feature of an information environment. It becomes a human-relevant problem only when we have evidence that people need meaningful comparison to accomplish what the situation requires.

Wang and Strong’s information-quality work is useful when “better information” is too vague to diagnose. Accuracy, completeness, relevance, timeliness, interpretability, and accessibility can fail independently.

10. Compare requirement by requirement and across the people involved

Inspect requirement by requirement rather than reducing the environment to a defect list.

An information environment may support one thing a person needs to do very well and another poorly.

The information may be technically correct but difficult to verify.

It may be easy to find but ambiguous about version.

It may allow one person to reach a sound judgment while making the evidence difficult for an approver to verify without reconstruction.

It may provide the right answer eventually, but only after several documents have been combined manually.

It may provide an apparently complete answer while hiding a condition that should trigger further scrutiny.

Or it may already support the situation adequately.

Describe the current condition before deciding whether it is a problem.

A better inspection statement sounds like:

The current environment gives the reviewer authoritative evidence of certificate support, but establishing which lifecycle conditions apply requires moving between several sources.

That gives us a concrete description of what the environment enables and where its support stops.

It is more useful than:

The documentation is fragmented.

When the situation involves more than one person, the same information environment may work differently for different people.

When more than one person matters, inspect how the same environment works for each of them and across the handoffs between them.

Those are related information problems, but they are not the same gap.

Judge support across all materially relevant people and handoffs, not only the first person who can complete a task.

At the same time, preserve the distinct information needs of different participants rather than forcing one representation on everyone.

Separate the information condition from its consequence for people

This distinction is essential.

You may be able to observe directly that there is no canonical source, version applicability is distributed across three documents, or conditions disappear when the information is copied into another system.

Those are observations about the information environment.

What they mean for people is a separate question.

For example:

Observed information condition: Version applicability has to be reconstructed across several sources.

You may then have evidence that:

Observed human consequence: Reviewers repeatedly consult Product Security to resolve routine version questions.

Or you may only have:

Hypothesis: The distributed evidence creates avoidable reconstruction and expert dependency during review.

Keep the observed condition and the human consequence as separate statements so the strength of evidence remains visible.

A gap can be established from several kinds of evidence working together. Public traces may show a recurring difficulty; inspection may show the information condition producing it; domain expertise may qualify the technical condition; direct observation may reveal a workaround or handoff failure. Record what each source establishes.

Act when the combined evidence is strong enough for the next decision and the remaining uncertainty is acceptable for its stakes. If the remaining uncertainty could change the decision, investigate that uncertainty first.

WORK ACROSS EXPERTISE AND AUTHORITY BOUNDARIES

An investigation may lead into a process, system, or specialist domain you do not own.

You can identify the signal, gather corroborating cases, describe the affected task, and frame the question that needs validation. Crossing that boundary does not give you authority to establish specialist truth or assign another team an intervention.

Enter as a guest and remain a collaborator.

Lead with what you observed and what remains unknown:

“We noticed these instances and their effects on the task. We do not yet know the cause or whether a change is warranted. What context or counterexamples are we missing?”

Invite the people closest to the work to explain constraints, definitions, prior decisions, and relevant evidence. Agree how to inspect the process or records needed to resolve the question.

Keep separate:

• what was observed;
• the suspected cause;
• what remains unknown;
• what the relevant owner or specialist establishes;
• any observed burden on the work;
• any broader consequence that remains a hypothesis.

Do not describe a person or team as the problem. Do not treat forwarding the issue as resolution.

Pay attention to shadow systems

A private spreadsheet, checklist, copied document, unofficial comparison, saved chat thread, or community resource may look like a workaround. It may also be the thing making the work possible.

Before replacing it, learn what capability it supplies that the official environment does not: visibility, portability, comparison, directness, provenance, confidence, control, or something else. The workaround may reveal what people have had to build for themselves in order to keep the work moving.

The workaround may be evidence about the requirement.

Do not assume the shadow system should survive unchanged. First understand why it exists; then decide whether the useful capability should be preserved, governed, connected to authoritative sources, redesigned, or deliberately retired.

11. State the gap

Once you have compared the requirements with the actual environment, state the gap in ordinary language.

A useful gap statement makes four elements visible that you have been building throughout this Part:

the people and situation -> what information needs to enable -> what the environment actually enables -> the consequential difference between the two.

For example:

Security reviewers need to determine whether a security capability applies to the product and software version under review and carry supporting evidence into formal approval. The current environment contains authoritative information, but applicability and important conditions are distributed across several sources and do not always remain attached when findings are transferred. Reviewers therefore have to reconstruct applicability and provenance during review and handoff.

The statement is useful because it describes the consequential difference before selecting an intervention.

It still leaves several responses open:

a governed security evidence path;

restructured documentation;

new routing or provenance support;

or another change that directly addresses the established difference.

The gap remains independent of whichever response you eventually choose.

Sometimes the gap is straightforward absence: information the situation requires simply does not exist.

Often the information exists but cannot be reached at the right time, distinguished by condition, verified, compared, interpreted without unnecessary reconstruction, preserved through a handoff, kept current, or trusted at the level the situation requires.

A gap may also be the failure to make an important uncertainty or boundary visible enough for responsible judgment.

If the responsible action is to escalate because applicability cannot be established confidently, an environment that produces an apparently definitive answer may be worse than one that clearly exposes the unresolved condition.

In that case, the requirement may be:

Make what is established, what remains uncertain, and what requires further judgment distinguishable at the point of use.

That can support responsible escalation without pretending that more information is always the answer.

The gap statement should make that boundary explicit when it is consequential.

Stop here when no material gap is established

Stop here if you can observe an imperfection in the information environment but cannot establish that it materially matters to the people and situation you are investigating.

An inspection can legitimately end with no material gap established.

Sometimes inspection shows a structural imperfection without evidence that it materially affects people. Sometimes a workaround is mildly inconvenient but adequate for the consequences involved. Sometimes the environment already meets the requirement. Sometimes you still do not know whether the observed condition matters.

The next step may be a small human check rather than an intervention. Or the responsible conclusion may be that there is no meaningful problem to solve.

You are ready for Part IV when

You should be able to say:

People need information to enable ____. The current environment enables ____. The material gap is ____.

If the statement is not yet supportable, resolve the uncertainty that prevents you from stating it before designing a change.

If you can, the next question is:

What could we change in the information environment to address that gap?

PART IV – DESIGN THE INTERVENTION TO ADDRESS THAT GAP

By the end of Part III, you should be able to describe a meaningful difference between what people need information to enable and what the current information environment actually enables.

Now decide what could change.

Use the established gap as the design constraint.

Begin with the gap and the people it affects.

WHEN ANOTHER TEAM OWNS THE ENVIRONMENT

A diagnosed gap does not automatically assign an intervention to the person or team that owns the affected environment.

When another owner or specialist is involved, separate three decisions:

1. Validate the finding. Ask the relevant owner to confirm, qualify, reject, or request more evidence about the gap.
2. Examine possible changes together. If the finding holds, explore which information changes could address it and what constraints or prior decisions matter.
3. Agree ownership and priority. Decide who, if anyone, will own, authorize, prioritize, implement, and maintain the intervention.

The originating practitioner may remain involved by gathering cases, clarifying the information requirement, testing an agreed path, or revisiting a roadblock. Their proposed solution does not assign another team a task.

If the owner gives a different account, requests more evidence, defers the work, or concludes that no change is warranted, keep that response and rationale in the inquiry record.

Example: Marketing observes repeated reconstruction during a service handoff and brings the cases to Operations. Operations may confirm the gap, identify a different cause, request more evidence, or decide that another priority takes precedence. Marketing can continue supporting the inquiry, but Operations retains authority over its process and intervention priorities.

If competing priorities prevent action, make the consequence and decision visible to the appropriate sponsor. Escalation makes the tradeoff visible; it does not override domain expertise.

The intervention is a change to the information environment intended to help the relevant people better accomplish what the situation requires.

That may mean creating something new.

It may also mean consolidating existing information, clarifying relationships, exposing provenance, improving routing, changing sequence, retiring stale sources, governing currentness, making evidence more portable, or giving different people useful views over the same underlying evidence.

Sometimes the right intervention is primarily structural. Sometimes it is editorial. Sometimes it changes a workflow or handoff. Sometimes it is five deletions and one governed source instead of a seventh page.

You should be able to answer a simple question about the intervention:

Why does this particular change make sense for the gap we established?

Use the established gap as the design constraint and keep the people it affects visible.

For example:

Security reviewers need to establish version-specific applicability and preserve supporting evidence in formal review. The necessary technical evidence exists, but applicability and important conditions require reconstruction across sources, and those conditions do not always survive the handoff.

That gap does not yet tell you whether the answer is a page, structured data, new navigation, a governed evidence object, revised documentation, an internal workflow, or some combination.

That is intentional.

The gap describes the problem independently of your preferred solution.

The gap deliberately leaves the form of the intervention open.

And:

What should remain unchanged because the relevant people can already do what they need to do with it?

That second question matters.

Preserve functioning parts of the environment unless changing them is necessary to address the gap.

Part III may have shown that the environment already meets an important requirement, that an observed imperfection does not materially affect people, or that you still lack enough evidence to know what should change.

In those cases, the next action may be another evidence check, a bounded decision to leave the environment unchanged, or no intervention yet.

You may need another check with the people involved. Or the responsible conclusion may be that the issue does not warrant a change.

An Information Design investigation can legitimately end without producing a new artifact.

CHECK OWNERSHIP AND AUTHORITY BEFORE DESIGNING THE CHANGE

Before committing to an intervention, identify:

• who can establish the underlying truth;
• who owns the affected information environment, system, workflow, source, or handoff;
• who can authorize the proposed change;
• who will be responsible for maintaining it.

You may identify a gap and propose a possible information change without owning every part of the environment involved.

When a finding depends on specialist knowledge or falls outside your authority, frame it as a request for validation rather than as an established implementation requirement. The relevant owner or specialist may confirm it, qualify it, reject it, or identify a different constraint that changes the intervention.

When validation or implementation depends on another owner, treat that person or team as a partner in the investigation rather than the recipient of an assignment.

Record their response and whether the proposed intervention is accepted, changed, deferred, rejected, or still awaiting evidence.

If the owner cannot act or a roadblock remains, keep the issue open. Record the blocking condition, the next evidence request or check, and the appropriate escalation path.

The originating investigator may stay involved by gathering additional cases, clarifying the information requirement, testing an agreed path, or revisiting the issue when new evidence appears. A handoff alone does not resolve the investigation.

CHOOSE THE SMALLEST COHERENT CHANGE

Before creating something new, decide which form of change best addresses the established gap while preserving what already works.

The intervention might:

• revise an existing source;
• add or restructure part of an existing source;
• create a distinct page, view, or resource when the requirement genuinely needs separation;
• connect existing sources through routing or handoffs;
• retire or redirect stale information;
• leave an existing source unchanged while improving the path around it.

Ask what the proposed change preserves, duplicates, separates, supersedes, or makes harder to find.

Where an earlier intervention or decision already affects the same source or path, determine whether the new change extends it, conflicts with it, or replaces part of it. Do not assume that a new investigation overwrites the earlier one.

A new governance system is not automatically required. Use the ownership and maintenance path appropriate to the change.

For the constructed pharmaceutical-services example, a governed signal-management scoping-and-handoff resource could sit beside the existing service page, with the service page remaining an entry point.

Its job would be to make scope, required inputs, responsibilities, unresolved conditions, review points, and handoffs usable without creating a conflicting second account of the service.

The test should include whether the appropriate people can reach and use the resource from a realistic entry path and whether the new resource remains consistent with the information they encounter elsewhere.

13. Match the change to the gap

Different gaps call for different kinds of change.

The possibilities below are not a taxonomy you have to fit the gap into. Use them to widen the design space.

Use the possibilities below to widen the design space rather than as a taxonomy the gap must fit.

The design problem is to choose a credible intervention that addresses the material gap without creating unnecessary complexity elsewhere.

Info Design at the Bottom of the Funnel

Do not assume the sales page is the intervention.

Close to a purchase, the relevant information environment often crosses owned, third-party, machine-mediated, and interpersonal surfaces. The useful change might be a stronger comparison, clearer qualification or disqualification guidance, a governed proof source, a version/applicability table, implementation prerequisites, evidence a buyer can carry to a gatekeeper, or better routing among sources that already exist.

Think in evidence paths, not asset lists.

One useful design lens is the evidence path: can a person move from a claim, to applicability in their situation, to authoritative proof, to important conditions or limits, and then to a finding they can carry forward without unnecessary reconstruction?

The claim and the proof do different jobs

A sales claim can orient, frame, and persuade. Consequential purchase work may still require evidence a buyer or gatekeeper can independently check. Treat the claim as an entry point to proof, not as a substitute for it.

Ask whether the person can tell what the proof actually supports, what product, version, configuration, or condition it applies to, how current it is, what limits matter, and whether the evidence can travel with the finding into the next person’s work.

CLAIM  →  APPLICABILITY  →  PROOF  →  CONDITIONS / LIMITS  →  PORTABLE FINDING

That path may cross a product page, documentation, comparison resource, third-party source, AI assistant, sales conversation, and approval packet. The design problem is not to force everything onto one page; it is to make the necessary relationships usable across the path.

Sometimes stronger disqualification is the most useful bottom-of-funnel intervention. Making non-fit, meaningful limitations, viable alternatives, or “not yet” conditions clear can help the wrong buyer stop early and help the right buyer proceed with better evidence. A lower conversion rate could therefore coexist with a better human result. Whether the business benefits is a separate Business Impact question.

Design the information path the purchase work requires.

14. Design across the humans and conditions that matter

Part II established that several people may use the same underlying evidence differently.

Part III may have shown that the environment works for one person and breaks during another part of the situation.

Part IV is where you design for that reality.

Suppose Product Security maintains the authoritative technical source. The buyer-side security reviewer needs to determine applicability and verify the evidence. An approver needs the reviewer’s finding with enough context to judge whether the evidence supports it. An implementation engineer later needs the relevant conditions to survive into deployment.

One coherent evidence base can support several people through different views, contexts, or handoffs.

Ask:

• What underlying information needs to remain coherent?
• Several changes may plausibly address the same gap; choose one that addresses the material difference without creating unnecessary complexity elsewhere.
• Where would duplication create competing versions of truth?

The intervention may need to support several people differently while keeping the underlying information coherent.

Public information has to travel farther on its own

External users usually cannot rely on your internal context, tribal knowledge, private shortcuts, or easy access to the person who knows what a statement really means.

When information has to work outside the organization, make consequential conditions, provenance, limitations, currentness, and routes to further judgment explicit enough that the information remains usable without invisible internal context.

Self-sufficient does not mean eliminating expert interpretation. If expert review is genuinely required, design the information so the person can recognize that boundary, arrive with the right evidence, and know how to escalate appropriately.

Can people check what they need to rely on?

When information will materially shape judgment, keep enough of its basis and conditions attached for people to use it responsibly.

Ask what someone would need in order to understand where the information came from, what it applies to, how current it is, what conditions materially change it, what limitations remain, whether it can be checked independently, and where uncertainty or further judgment still belongs.

Sometimes that means attaching evidence directly to a specific claim. Sometimes it means representing a source relationship, version condition, disagreement, confidence, or unresolved status. Sometimes the most important design move is to make clear that the available evidence does not support a definitive answer.

A short answer becomes less useful when it drops the condition that makes it true.

A portable summary needs a durable connection to its source.

A confident presentation should still expose meaningful uncertainty when that uncertainty affects the work.

Can the information remain trustworthy as the underlying truth changes?

Some information problems can be solved once. Others cannot.

If usefulness depends on product version, policy, regulation, inventory, support status, security guidance, evidence validity, organizational process, or another changing condition, then maintenance is part of the design.

Ask:

• Who owns the underlying information?
• What event should trigger review?
• Which source is authoritative?
• How are outdated or superseded sources handled?
• How is currentness visible?
• How do downstream representations inherit changes?
• What happens when authoritative sources disagree?
• Who is responsible for resolving or exposing that disagreement?

A new artifact can reduce friction today and still increase ambiguity tomorrow; design maintenance and ownership with the intervention.

If the necessary evidence already exists in governed sources, consider whether the intervention should connect, expose, translate, or provide a view over those sources rather than duplicate them.

Can people actually encounter and carry it where they need it?

Encounter and routing are part of the intervention: a correct artifact only helps if the relevant people can plausibly reach it.

Check plausible entry paths to make sure they lead to the evidence people need.

Place useful comparison or evidence early enough to support the decision it is meant to inform.

Ask:

• Where do the relevant people encounter the information?
• What path brings them there?
• If information moves with a person or passes to someone else, identify what must remain intact.

When an AI assistant is part of the information path

An AI assistant may search, retrieve, summarize, compare, or draft from the same evidence a person would otherwise inspect directly. When that happens, the person remains the reason for the design. The assistant is part of the information path.

Treat AI mediation like any other consequential handoff: ask what must survive between authoritative evidence and the person’s use of it. That may include source, version or configuration, applicability, conditions, currentness, limitations, uncertainty, and the evidence needed for independent verification.

Design the underlying evidence, not special “AI copy.” Favor explicit relationships, stable terminology, canonical sources, accessible authoritative evidence, currentness, clear boundaries, and enough provenance that a person can verify what the assistant presents.

If the AI-mediated path materially affects the task, include that path in the test. A realistic test may involve the person, the assistant, and the governed evidence environment together rather than forcing the person to work without a tool they normally use.

Define the human situation independently of transient model behavior. When the unresolved question is specifically whether the AI environment retrieves, cites, distinguishes, or represents the evidence accurately, use AI Visibility to investigate that machine-facing part of the path.

LANE GUARD  Information Design establishes what the human situation requires and whether the information path supports it. AI Visibility owns the machine-facing measurement of a particular AI environment.

15. Write the intervention logic plainly

Before designing the artifact in detail, write the logic of the intervention in ordinary language.

A useful intervention statement connects:

what people need information to enable -> what the current environment enables -> gap -> proposed change to the information environment -> expected effect for the relevant people

For example:

Security reviewers need to establish version and configuration applicability and preserve supporting evidence in formal review. The current environment contains the necessary technical evidence, but applicability and conditions require reconstruction across several sources and do not always survive transfer. We will create a governed reviewer-oriented evidence path that connects each consequential finding to applicable version/configuration, conditions, current authoritative evidence, and a portable reference. We expect this to reduce avoidable reconstruction and improve evidence transfer while keeping environment-specific scrutiny and escalation intact.

That is stronger than:

Make a better security page.

Use the final sentence of the intervention statement to name the expected mechanism: why this change should improve the human work you identified.

That mechanism becomes the bridge to Part V, where you define an observable effect and a test capable of challenging it.

For example: clearer applicability relationships may reduce reconstruction; better routing may reduce unnecessary expert mediation; evidence that retains source and conditions may improve the reviewer-to-approver handoff.

Part V turns that mechanism into an observable expectation.

You are ready for Part V when

You should be able to explain:

• which established gap the intervention addresses;
• what part of the information environment you propose changing;
• why that change follows from the gap rather than from a preselected artifact;
• how you expect the intervention to help people;
• which people, handoffs, or encounter environments materially matter;
• what evidence, conditions, uncertainty, or necessary scrutiny must remain intact;
• what ownership and governance are necessary if the underlying information can change.

Define what better support would look like for the people involved and what observations would let you judge it.

PART V – DEFINE HOW YOU WILL KNOW IF IT HELPS

By the end of Part IV, you have designed a change to the information environment intended to help particular people accomplish something in a particular situation.

Before putting that intervention into use, decide what you would need to observe to believe it actually helped.

Evaluate the intervention by what changes for the people and situation it was designed to support.

Ask:

Did the change help the relevant people understand, judge, verify, act, or preserve information through the work more effectively in the situation we designed for?

You do not need a formal experiment for every intervention.

A small, reversible change may justify a modest practical test. A consequential intervention, a subtle expected effect, or a decision that depends heavily on the result may justify a stronger design or help from someone with relevant research expertise.

Use enough rigor to make the next decision responsibly.

ISO 9241-11 provides a useful anchor for usability: evaluate specified people pursuing specified goals in a specified context. When you need a more formal usability test, established usability-testing methods can help with realistic tasks, observation, and interpretation.

START WITH THE NEAREST OBSERVABLE EFFECT

Your first useful test does not have to establish every downstream effect. Start with the nearest thing that should become better for the person doing the work.

For the constructed pharmaceutical-services example:

People and task: A pharmacovigilance lead and an appropriate reviewer use the proposed scoping-and-handoff resource to scope a realistic hypothetical signal-management engagement.

Expected improvement: They should be better able to identify the activities in scope, required evidence and inputs, unresolved responsibilities, conditions for the next review, and where appropriate expert help is still required.

Guardrail: The information must not hide or replace necessary specialist scrutiny.

First test: Give them a realistic task using one identified version of the resource. Observe what they can establish, where they hesitate or reconstruct information, what conditions they preserve through the handoff, and where they still need expert review. Record the version they encountered.

A one-version task test can reveal usability failures and show where the information path breaks. It does not establish that the resource improves on the previous path. That claim requires a meaningful comparison.

16. Say what should become better for the human

Return to the expected effect from Part IV and make it observable.

A useful starting form is:

If we change X, [person] should become better able to do Y because Z.

For example:

If we make version applicability, important conditions, and authoritative evidence usable together, security reviewers should become better able to establish routine applicability and carry supported findings into formal review because they no longer have to reconstruct those relationships across several sources.

This names the change, the person, the expected improvement, and the reason you expect it to help.

Treat the because as a hypothesis that the observations can support, qualify, or overturn.

Stay close to the human effect

Measure the nearest meaningful effect the intervention was designed to produce.

If you changed information so a reviewer could establish applicability more reliably, start with whether the reviewer can establish applicability more reliably.

Stay with the nearest human effect first. Downstream outcomes such as sales, support volume, approval-cycle time, capacity, revenue, or organizational performance become separate questions once the human result is established.

A downstream measure can matter later, but it does not by itself establish whether this intervention helped the person it was designed for.

Likewise, if another person materially matters to the result, include them. If the first reviewer needs to carry evidence to an approver, better support may include whether the evidence remains usable after that handoff.

If the expected human improvement is still unclear, refine the intervention logic in Part IV before selecting measures.

17. Choose the smallest useful measures and a guardrail

Ask:

What would we actually observe if this improvement were real?

Choose measures that stay close to what people need to do.

Choose measures that represent the improvement you care about; easy-to-count proxies can supplement them when their limitations are clear.

Page views may show exposure. Clicks may show an action. Time may show speed. None of those alone tells you whether someone understood an important condition, made a sound judgment, verified the evidence, or carried it correctly to another person.

Use a proxy when it is the most practical measure available, but keep clear what it does and does not establish.

Support or sales patterns, stakeholder accounts, task-specific feedback, usage signals, CRM activity, and similar traces can help corroborate a problem, locate where it occurs, or identify something worth testing.

Keep the claim matched to the evidence. A helpfulness click can show that someone clicked. CRM movement can show that a record or commercial state changed. Neither establishes by itself that the person understood the information, completed the task soundly, or made a better-supported judgment.

Use the smallest set of observations that can establish the expected effect and protect the important guardrail.

Protect what must not get worse

Check whether an apparent improvement is accompanied by a meaningful deterioration elsewhere.

A reviewer may finish faster because an important condition became less visible.

Someone may ask fewer questions because the intervention made them falsely confident.

One person may save effort because the intervention shifted reconstruction onto another.

Ask:

What could look better on one measure while making the people, judgment, or handoff worse?

Then choose a guardrail.

For example:

Expected improvement: Reviewers establish routine applicability with fewer reconstruction steps.
Guardrail: Accuracy and appropriate escalation do not deteriorate.

A warranted no, delay, request for evidence, or escalation can be a good information outcome when the situation calls for it.

Aim to improve support for the work while preserving necessary judgment, verification, scrutiny, and each person’s ability to do their part.

When the intervention affects customers

Do not improve an internal process by quietly transferring effort, uncertainty, or restriction to the customer. A change can make the organization easier to operate while leaving the external person’s work harder, less legible, or less controllable.

Did this make the person more capable of doing the work—or merely make the organization’s process easier to enforce?

Where that risk exists, include a customer-side guardrail: can the person still understand what is happening, verify what matters, recognize their options and limits, and choose, stop, or escalate appropriately?

18. Choose a test setup you can interpret

Knowing what you want to measure is not yet a test design.

Before testing, decide:

• who will use the information;
• what they will be asked to accomplish;
• which version of the information environment they will encounter;
• what you will compare, if anything;
• which conditions need to remain similar enough for the result to mean something.

A laboratory experiment is only one possible test setup. Choose a design that matches the question and consequence of the decision.

You should be able to explain why the observations are informative about the information change and what important differences in people, scenario, instructions, or access could still affect interpretation.

First decide what kind of question you are asking

If you need to know:

Can people use this intervention successfully, and where does it break?

a focused task test may be enough.

If you need to know:

Does this help people more than the environment they had before?

you need some meaningful basis for comparison.

Those are different ambitions and support different conclusions.

Common practical setups

Choose the lightest setup that can answer the question with enough credibility for the decision at hand.

Give people a realistic situation without giving away the answer

Give them enough context to understand what they are trying to accomplish.

Keep the scenario realistic: provide the context people normally have, while withholding hints that would reveal which source, condition, or conclusion you intend them to find unless those hints would exist in normal work.

For example, instead of:

Use the security evidence page to determine whether version 4.2 supports certificate rotation.

try:

You are reviewing this gateway for an environment that requires certificate rotation. Determine whether the version under consideration can satisfy that requirement, and show what evidence you would carry into the review.

The second version allows the information environment to help, or fail to help.

Keep important conditions reasonably comparable

When comparing conditions, keep the factors that could change the result reasonably similar and record meaningful differences that remain.

Pay particular attention to differences in relevant experience, scenario difficulty, instructions, available help, entry path, information access, and prior familiarity.

Perfect equivalence is rarely possible; interpret the result in light of the meaningful differences that remain.

Watch for learning

If the same person uses both versions, the first attempt may teach them about the subject or task.

That does not make the test useless.

Where practical, use different but comparable scenarios, vary which version people encounter first, and do not always pair the easier scenario with the same version. If learning is still likely to influence the result, keep that limitation visible.

Try the test before relying on it

A small pilot can reveal problems with the test itself.

Check that the instructions make sense, the scenario does not accidentally give away the answer, the information needed to complete the task actually exists, and the things you intend to observe can in fact be observed.

Resolve test problems that prevent the task, evidence path, or planned observations from functioning as intended before using the test to judge the intervention.

Choose participant count for the question you are asking

A small number of appropriate participants can reveal important usability, comprehension, or information problems; there is no universal participant count.

Problem discovery and estimating a comparative effect are different purposes.

If you need a reliable estimate of how much better one condition is – or reliable subgroup comparisons – sample size depends on the expected effect, variability, desired precision, test design, and subgroup needs.

If you need a causal claim about the information change rather than a practical comparison between tested conditions, participant assignment, confounding, sample size, and analysis require stronger design.

Bring in research, human-factors, or statistical expertise when the decision depends on that stronger claim or when the team cannot design or interpret the test credibly on its own.

Match the test design to the decision you intend to make from the result.

19. Decide beforehand how you will read the result

Before testing, describe the result patterns that would change what you believe about the intervention.

EXPECTED / SUPPORTIVE

The predicted improvement appears under the planned conditions and the guardrail holds.

For example:

Reviewers identify version applicability more accurately, use fewer disconnected sources, and continue to escalate the cases that still require environment-specific judgment.

NO MEANINGFUL CHANGE / NULL

The expected improvement does not meaningfully appear under the tested conditions.

Record no observed improvement under the tested conditions, then use Part VI to locate which part of the reasoning may need revision.

CONTRADICTORY / COMPLICATING

Some observations weaken, redirect, or complicate the expected mechanism.

For example:

Reviewers become faster but miss consequential conditions.

Or:

Reviewers use fewer sources but become less able to verify their conclusion.

Or:

The first reviewer finds the information easier to use, but the evidence loses important context when passed to the approver.

ADVERSE / GUARDRAIL FAILURE

Something important becomes worse or the guardrail fails.

INCONCLUSIVE / INSUFFICIENT EVIDENCE

Sometimes the evidence simply does not support a clear answer.

The people or scenarios may differ too much. A measure may vary too widely. The test setup may have failed. Or some observations may point in different directions.

Leave an inconclusive result inconclusive and identify what prevented the test from answering the question.

Defining these possibilities before testing gives you a stable basis for interpreting the result that appears.

You are ready for Part VI when

You should be able to answer five practical questions:

• What should become better for the relevant people?
• What will we observe?
• What must not get worse?
• What test setup can tell us something credible?
• What results would support, weaken, or complicate our expectation?

Stay with the effect the intervention was designed to have for the relevant people.

If the next question becomes whether that established human result changes an organizational process, commercial result, or economic outcome, that is a different investigation.

PART VI – INTERVENE, TEST, AND INTERPRET

Part V decided what you expect to happen and how you intend to find out.

Put the intervention into use and run the test you planned.

Record material departures from the setup and interpret the observations against the expectations established in Part V.

Start with the measures and conditions you said mattered.

In this Part, confirm that people encountered the intervention as intended, observe what happened, compare those observations with the plan, and identify where the intervention logic holds or needs revision.

First establish what happened; then interpret what the pattern means.

20. Run the intervention and test as planned

Confirm that the intervention people encountered is the intervention you intended to test.

Did the revised information ship?

Did the routing change?

Are the authoritative sources current?

Are the intended relationships and conditions present?

If a person is supposed to encounter the intervention through a particular entry path, include that path.

If one person is supposed to carry information to another, include that handoff when it is material to the expected result.

A usable evidence resource still fails if the people it was designed for cannot reach it.

Use the people, scenarios, information versions, instructions, and comparison conditions from Part V as closely as practical.

If something material changes, record it rather than quietly treating the result as though the original test occurred.

Perfect control is rarely necessary for a practical test. Preserve enough comparability, and record enough about differences, to understand what the result can support.

21. Start with what you said mattered

Return first to the measures and guardrail you chose in advance.

If the intervention was intended to help reviewers establish applicability more accurately with less reconstruction, begin there:

Did applicability judgment improve?

Did reconstruction decline?

Did the guardrail hold?

Read the planned measures before surrounding metrics that were not part of the expected effect.

If a handoff was part of the expected effect, inspect the handoff too.

Did source and important conditions survive?

Could the receiving person understand or verify what was transferred?

Judge the intervention across the material handoffs as well as the first person’s experience, so an apparent improvement does not simply shift work downstream.

22. Keep observation separate from interpretation

Write down what happened before explaining it.

For example:

Observed

• Reviewers using the revised evidence path identified the applicable version more accurately.
• They used fewer disconnected sources.
• Review notes retained authoritative source and important conditions more consistently.
• Appropriate escalation remained similar.
• Task time varied too much to support a clear conclusion.

Interpretation

The pattern is consistent with the revised evidence path helping reviewers establish applicability and carry supporting evidence with less reconstruction while appropriate escalation remains intact.

Write observations as what happened. Write interpretation as what those observations make more or less plausible and what uncertainty remains.

Keeping them separate lets you revise the explanation without rewriting what was observed.

23. Use the result to learn where your reasoning holds or needs revision

Return to the expected, no-improvement, contradictory/adverse, and inconclusive patterns you defined in Part V.

If the expected pattern appears, record where it appeared, whether the guardrail held, what did not improve, and which people and conditions were actually tested.

If no expected improvement appears, use the sequence below to locate the next uncertainty.

Ask, in roughly this order:

• Did the intended people actually encounter the changed information?
• Was the intervention implemented as intended?
• Did we actually change the information condition we meant to change?
• Could people find, distinguish, verify, or carry the information as intended?
• Was our explanation of why the change should help wrong or incomplete?
• Did our measure actually represent the improvement we cared about?
• Did we misunderstand what people needed information to enable?

When the result is contradictory or adverse, report the apparent improvement and the deterioration separately before deciding what the combined result supports.

Ask:

What tradeoff or downstream cost accompanied the apparent improvement?

A faster task that misses an important condition is not an unqualified improvement.

Fewer sources with worse verification is not an unqualified improvement.

A better experience for the first person accompanied by a worse handoff to the next person is not an unqualified improvement.

When the result is inconclusive, identify why the evidence cannot yet support the decision.

Choose the lightest next step that could resolve the material uncertainty: a better-aligned scenario, a clearer measure, more comparable conditions, another participant group, additional evidence, or a bounded decision to stop.

Revisit earlier Parts when an earlier decision no longer holds

The seven Parts express dependencies, so an unexpected result can send you back to the intervention, gap, information requirement, or understanding of the people and situation.

Use testing to challenge and revise the intervention logic when the observations do not fit it.

You are ready for Part VII when

You should be able to state clearly:

• what intervention was actually tested;
• which people encountered it and under what conditions;
• what happened on the measures chosen in advance;
• whether the guardrail held;
• what remained inconclusive;
• what you infer from the pattern about the intervention and the reasoning behind it.

Keep observation and interpretation separate.

The next question is:

Given what we actually observed, what is the strongest conclusion the evidence supports, under what conditions, and with what limits?

PART VII – STATE WHAT THE EVIDENCE SUPPORTS

By the end of Part VI, you should know what happened, what remained unchanged or uncertain, whether the guardrail held, and how you interpret the pattern.

Now state the strongest useful conclusion the evidence supports.

Make it specific enough to inform a real next decision and bounded enough that someone else can understand what was and was not established.

24. Report what changed, did not change, and remains uncertain

Start with the result before compressing it into a conclusion.

Record:

• what changed;
• what did not;
• whether the guardrail held;
• what was contradictory or adverse;
• what remained inconclusive or unknown.

For example:

• Reviewers identified version applicability more accurately.
• They used fewer disconnected sources.
• Review notes retained authoritative source and important conditions more consistently.
• Appropriate escalation remained similar.
• Task time varied too much to support a clear conclusion.

This is more useful than:

The new experience performed better.

What did not change helps define the result just as much as what did.

For a mixed result, report what improved, what did not, whether the guardrail held, and what remains uncertain before compressing the result.

The readout preserves the result, its conditions and limits, and the uncertainty that still matters so the next person can use it without reconstructing the reasoning.

25. State the strongest supported result with its conditions and limits

Now compress the result.

A useful statement usually tells the reader:

who was tested + what changed + under what conditions + the important guardrail or boundary

For example:

Under the tested scenarios, security reviewers using the revised evidence path identified version applicability more accurately, used fewer disconnected sources, and preserved conditions and authoritative evidence in review more consistently while appropriate escalation remained stable.

The supported statement works because it names the tested people, the actual change, the measured effects, and the guardrail.

Broader claims require additional evidence:

“The new security experience is better” would be too vague to identify what improved.

“Security review became more efficient” would go beyond the inconclusive evidence about time.

“The intervention reduced Sales Engineering cost” would require downstream evidence that this test did not collect.

Keep the supported result at the level the evidence can establish. If a broader organizational or commercial effect now matters, treat it as the next question.

The strongest supported result is the most informative statement that stays within the evidence.

Sometimes that will be an observed result:

Reviewers using the revised path made fewer applicability errors in the tested scenarios.

Sometimes the evidence supports a cautious interpretation:

The pattern is consistent with the revised path helping reviewers establish applicability with less reconstruction.

Sometimes the responsible statement is:

The test did not provide enough evidence to determine whether the intervention improved the intended result.

All three can be useful.

The strength comes from the fit between the statement and the evidence.

Keep conditions and limits with the result

A result often becomes misleading after it leaves the person who conducted the test.

Someone remembers:

reviewers performed better

and forgets:

under these scenarios, with these participants, against this comparison, while this guardrail held.

Keep the material limits with the result so the next person does not have to reconstruct them.

Keep enough context with the result to answer:

• Who did this apply to?
• What intervention did they actually encounter?
• What were they asked to accomplish?
• Compared with what?
• What important test conditions matter?
• What did not change?
• What remained uncertain?
• What evidence state does the statement actually deserve?

Keep only the conditions that materially affect the result’s meaning.

26. Decide what happens next

Use the result to decide what to do.

Continue only when an unresolved question matters to the next decision.

Possible next decisions include:

• Keep the intervention in the tested context. The result is sufficiently supported and no important guardrail problem appeared.
• Revise the intervention and test again. You identified a design problem or a failed guardrail.
• Return to an earlier question. You may conclude that the gap, requirement, or understanding of the people was incomplete.
• Test another important situation or group. The result is useful in the tested context, but you do not yet know whether it transfers to another materially different one.
• Stop. The evidence is sufficient for the decision you needed to make, and further investigation would not materially improve it.
• Ask a genuinely new question. A further uncertainty matters and Information Design itself does not establish the answer.

Treat a possible further effect as a new question and establish it separately if it matters.

27. Pass a bounded result into the next question

When another investigation is warranted, pass forward what has been established, at the strength at which it was established, together with the conditions and limits that make it interpretable.

For example:

Established

Under the tested scenarios, reviewers using the revised evidence path identified applicability more accurately, used fewer disconnected sources, and preserved important conditions through handoff while appropriate escalation remained stable.

Possible next question

Does that improvement reduce routine Sales Engineering clarification during comparable live security reviews?

The second statement is a new hypothesis requiring different evidence; it does not follow automatically from the first.

Keep the established result intact when it becomes the starting evidence for another investigation.

Use AI Visibility when the unresolved question concerns how the changed information environment is represented in AI answers.

Use Business Impact when an established result for people raises a meaningful question outside the immediate human-information effect.

CALL BUSINESS IMPACT  Call when an established human/task result raises a meaningful question about organizational work, burden, risk, capacity, customer economics, or another business result. Carry the supported human result unchanged; the downstream effect remains a new uncertainty.

The guides can hand established results to one another, but none is required to follow another.

An Information Design result may be complete and useful on its own.

When people become better able to understand, judge, verify, act, or preserve information through the situation that mattered, and the observations support that conclusion, that is a legitimate Information Design result.

Before you finish

You should now be able to leave someone else with a compact, defensible account:

• We changed ____.
• For these people, in these conditions, we observed ____.
• We did not observe / could not establish ____.
• The strongest result supported by the evidence is ____.
• The important limits are ____.
• The next decision is ____.
• Any further effect we are considering remains a new question until separately established.

That completes the Information Design investigation.

PART VIII – WORKED EXAMPLE: INDUSTRIAL GATEWAY SECURITY REVIEW

SECOND LEG — HUMAN WORK

CASE SPINE  This teaching case follows one possible route through the family. The guides do not require this order and can be used independently.

This is an illustrative worked example, not a client case or a description of a real product. It continues the industrial-gateway teaching case so the relationship between the guides is visible, but it can be read independently.

The research and test choices shown here are examples, not a required sequence or universal design.

Part I – Follow the signal to the humans and their work

The starting signal

An earlier AI Visibility investigation has already changed and re-tested a set of security information.

Under its measured conditions, the targeted security evidence is used more consistently and product/version representation becomes more accurate on the targeted technical prompts.

Recommendation does not materially change, and broad category prompts show little movement.

That is a useful AI-system result.

That AI-system result becomes the starting signal for a different question about the people who use the information.

So the signal is:

The security evidence is represented more accurately in the measured AI environment. Does the information environment also support the people who actually have to use that evidence in security review?

Locate the people and situation

The primary person is an OT security reviewer at a regulated manufacturing company.

The company is evaluating an industrial gateway for deployment in a segmented plant environment. Security approval is required before procurement and implementation can proceed.

The reviewer is trying to determine whether the gateway can be deployed without violating security and operational requirements.

That includes determining fit or non-fit, verifying security capabilities, identifying deployment conditions, checking current authoritative evidence, carrying findings into formal review, and escalating unresolved issues appropriately.

Other people materially matter:

• implementation engineer – evaluates architecture and configuration feasibility;
• Procurement – requires approved evidence and commercial readiness;
• vendor Product Security – establishes current technical truth and authoritative sources;
• Sales Engineering – often mediates unresolved technical questions.

In this example, public and first-party traces include recurring questions about certificate and authentication support, loss of cloud or WAN connectivity, firmware and update behavior, security documentation, standards applicability, and version-specific capability.

What Part I establishes

The signal resolves into a concrete work situation:

An OT security reviewer needs to determine whether a particular gateway, version, and configuration can satisfy the security and operational conditions of a particular deployment – and produce evidence another person can review.

The next question is:

What must information enable for this reviewer and the other people who materially matter?

Part II – Establish what information must enable for them

In this example, Product Security establishes several important technical conditions:

• core gateway operation can continue without active cloud connectivity after required local provisioning;
• remote management and some update workflows require connectivity;
• certificate behavior varies by software version and deployment configuration;
• a generic “offline capable” description would be incomplete;
• current technical manuals and the security-advisory process remain authoritative for several findings;
• certificate lifecycle, rather than mere certificate support, matters to a complete security description.

In this example, an experienced buyer-side OT security reviewer contributes a different kind of evidence:

• the review is not simply “is this gateway secure?”;
• a technically correct statement can still be insufficient if applicability is unclear;
• a marketing summary can orient the reviewer without providing sufficient proof;
• evidence needs to be citable or attachable to the formal review;
• the reviewer needs enough context to recognize where Product Security or other expert escalation is still appropriate.

With those inputs, we can state what information must actually enable.

Necessary scrutiny remains: architecture review, verification of deployment-specific assumptions, and escalation of unresolved or high-risk issues.

The Part II output can be stated in one sentence:

For this reviewer, information must make it possible to establish version- and configuration-specific security applicability, distinguish connectivity-dependent behavior, verify consequential findings against authoritative evidence, and carry those findings into formal review without losing the conditions needed to interpret them.

Part III – Identify the gap

Within the teaching case, the earlier AI Visibility intervention has already made one part of the environment clearer: version applicability is more explicit than it was before.

So this is not a case where everything is broken.

When we inspect the example environment, we find something more specific.

Certificate support is stated, but important lifecycle details – such as provisioning, renewal or rotation, revocation, and auditability – are not equally easy to verify.

Local core operation and remote-management dependence are described, but reviewers still have to move between the revised evidence resource and deeper technical documentation to establish some deployment conditions.

Authoritative links exist, but source and condition information do not always travel cleanly when a finding is copied into formal review.

Some plausible pre-purchase paths still take the reviewer to a general product page before the reviewer-oriented evidence path.

Those are information conditions.

We can state the gap by comparing those conditions with what the reviewer needs to accomplish.

The reviewer needs information to enable version- and configuration-specific applicability judgments, distinguish connectivity-dependent behavior, verify consequential findings, and carry those findings into formal review without losing important conditions.

The current environment contains much of the necessary technical evidence, but reviewers still have to reconstruct some applicability and lifecycle conditions across sources; important context can drop during handoff; and likely entry paths do not consistently lead to the evidence in the form needed for review.

The material gap is therefore not simply missing security information. The available evidence is not consistently usable, verifiable, and portable for the responsibilities the reviewer has to carry out.

That gap is specific enough to design against.

Part IV – Design the intervention to address that gap

The intervention should not create a second independent body of security truth.

Instead, extend the governed evidence base with a reviewer-oriented path over the same underlying evidence.

The revised intervention includes:

• claim-to-version and claim-to-configuration relationships;
• clearer certificate-lifecycle information;
• explicit distinctions between local operation and remote-management dependence;
• authoritative source and currentness attached to consequential information;
• portable evidence references that carry important conditions and limitations;
• routes from likely product/security entry paths;
• signals or redirects for stale sources;
• governance that keeps the reviewer view aligned with authoritative evidence.

The intervention logic becomes:

Reviewers need information to enable reliable applicability judgments and portable verification.

The current environment contains the evidence but still requires avoidable reconstruction and loses some context across paths and handoffs.

Therefore, create a governed reviewer-oriented path that makes applicability, conditions, source, currentness, verification, and portability usable together.

The expected effect is that reviewers can establish routine applicability more accurately with less reconstruction and carry better-supported findings into formal review.

The mechanism is not “make the page easier.”

It is:

Reduce avoidable reconstruction, ambiguity, and provenance effort while making important conditions, verification paths, and situations requiring escalation clearer.

Necessary security review remains.

Appropriate escalation remains.

Part V – Define how you will know if it helps

What should become better

The prediction is:

Security reviewers using the revised evidence path should become better able to establish routine version/configuration applicability, recognize important deployment conditions, verify the supporting evidence, and carry the finding into formal review with less unnecessary reconstruction.

What to observe

The most useful measures stay close to that expected effect:

• correct version/applicability determination;
• correct recognition of important conditions;
• number of disconnected sources needed;
• ability to identify authoritative evidence;
• whether source and important conditions survive into the review finding.

The guardrail is equally important:

Accuracy and appropriate escalation must not deteriorate.

A reviewer who becomes faster by missing a consequential condition has not been helped.

Test setup

Use reviewers who are appropriate to the security-review situation. Have them complete comparable scenarios using the existing information path and the revised reviewer-oriented path.

When the same reviewer sees both conditions, use equivalent rather than identical scenarios, vary which condition comes first, and do not always pair the easier scenario with the same condition so learning or scenario difficulty does not automatically favor one version.

Pilot the scenarios before relying on them to make sure the instructions do not reveal the answer and that the necessary evidence is actually available.

A small practical test may be enough to find important problems. If the decision depends on a reliable estimate of how much one condition improves performance, sample size and analysis should be planned for that purpose, with appropriate research or statistical expertise where needed.

Decide beforehand how to read the result

Expected: applicability and evidence transfer improve, reconstruction declines, and appropriate escalation holds.

Null: the revised path is available, but the intended improvement does not meaningfully appear.

Contradictory/adverse: an apparently desirable measure improves while important judgment degrades, for example reviewers use fewer sources or finish faster but miss a consequential condition or fail to escalate a case that still warrants expert review.

Inconclusive: the test cannot credibly distinguish the expected difference on one or more measures.

Part VI – Intervene, test, and interpret

Assume the intervention is implemented as designed and reviewers complete the planned scenarios.

The interpretation is:

The observed pattern is consistent with the revised evidence path helping reviewers establish applicability with less reconstruction and carry more complete supporting evidence into formal review without suppressing appropriate escalation.

We cannot support a conclusion about speed.

And we have not yet established what happens to Sales Engineering activity during live reviews.

Part VII – State what the evidence supports

What changed

Reviewers identify version applicability more accurately, use fewer disconnected sources, and carry source and important conditions into review more consistently.

Appropriate escalation remains stable.

What did not become established

The available observations do not justify a confident conclusion about task time.

The test also does not establish anything about end-to-end approval time, Sales Engineering capacity, commercial progression, revenue, or further AI-answer improvement.

Strongest supported result

Under the tested scenarios, security reviewers using the revised evidence path identified version applicability more accurately, used fewer disconnected sources, and preserved conditions and authoritative evidence in review more consistently while appropriate escalation remained stable.

Next decision

A reasonable next Information Design decision is:

Keep the reviewer-oriented evidence path for the tested use, maintain its governance, and do not make a speed claim from this test.

Nothing requires another investigation.

But two genuinely different questions could now become useful.

AI Visibility, if AI remains an important encounter environment:

Does the reviewer-oriented refinement change retrieval, citation, accuracy, or answer adequacy for the relevant tracked prompts?

Business Impact, if the organization needs to know whether the human result matters farther downstream:

Does the observed reduction in reviewer reconstruction lead to less routine Sales Engineering clarification during comparable live security reviews?

Neither possibility strengthens the Information Design result in transit.

And neither is mandatory.

PART IX – METHODS, LINEAGE, AND SOURCES

A reasonable next Information Design decision is:

The method in this guide draws on established disciplines concerned with people, situations, information needs, information environments, and evaluation.

It assembles those disciplines into a practical operating method for consequential information work while preserving boundaries between evidence types.

Use established methods at the depth the problem requires.

Understanding people, questions, and situations

Information need and question negotiation

Robert S. Taylor described four levels of information need – visceral, conscious, formalized, and compromised – showing that the question finally presented to an information system can differ from the need as first experienced.

The practical lesson here is that the question someone manages to ask may not be identical to the information condition that generated it.

Use this lineage when prompts, search queries, support questions, intake questions, or stakeholder-specified expressions are being treated too literally as complete needs.

Sense-Making / Dervin

Sense-Making emphasizes the person’s situation, the discontinuity or gap they encounter, and what helps them move through it.

Use it more deeply when the information problem is contextual, changing over time, or poorly captured by topical descriptions.

Berrypicking / Bates

Marcia Bates’ berrypicking model treats information seeking as evolving: people learn, reformulate, move across sources, and change the question as they go.

Use it when a single-query model obscures the actual path through the information environment.

Contextual inquiry / Contextual Design

Contextual Inquiry, developed within the Contextual Design tradition, gathers data from people while they are doing the activity being studied rather than relying only on abstract reports or hypothetical preference.

Use them when public evidence and expert accounts are insufficient to explain actual behavior, or when tools, interruptions, workarounds, collaboration, and environmental constraints matter.

Naturalistic Decision Making / Critical Decision Method

Naturalistic Decision Making examines how people make decisions in complex, time-pressured, ambiguous, and changing settings. The Critical Decision Method is one established interview approach for reconstructing important incidents and the cues, goals, expectations, and knowledge involved.

Use it when expert judgment, time pressure, risk, rare but consequential incidents, tacit cues, or branch conditions are central.

Cognitive Work Analysis

Cognitive Work Analysis provides methods for understanding constraints, functions, tasks, strategies, and worker competencies in complex sociotechnical systems.

Use it when the situation is safety-critical, technically complex, distributed, or strongly constrained by the environment.

Situated action / Suchman

Situated-action research is a reminder that real activity does not simply execute an abstract plan. People improvise and adapt to local circumstances.

Use it when formal process maps diverge from what people actually do.

Distributed cognition / Hutchins

Distributed cognition examines how cognitive activity can be distributed across people, tools, representations, and environments.

Use it when the “decision maker” is really a system of people and artifacts and no single person’s information need adequately describes the situation.

Designing information environments

Information Architecture

Information Architecture is the principal design discipline behind the guide: organizing, structuring, labeling, relating, retrieving, governing, and maintaining information so people can orient, understand, and act.

Go deeper when content models, taxonomy, metadata, navigation, search, provenance, reusable information objects, canonicality, governance, or cross-channel information environments are central to the intervention.

Knowledge boundaries / Carlile

Research on knowledge boundaries helps explain why information sometimes needs to be transferred, translated, or transformed as it crosses professional or organizational contexts.

Use it when Security, Legal, Procurement, Operations, Engineering, clinical roles, or other communities of practice need to use the same underlying evidence differently.

Information quality

Information-quality research emphasizes that quality is multidimensional. Wang and Strong’s consumer-oriented framework includes accuracy, completeness, relevance, timeliness, interpretability, and accessibility among important dimensions. In this guide, provenance and currentness are also treated as practical verification properties when the situation makes them consequential.

Use it when “better content” is too vague to diagnose what is wrong.

Evaluating whether the change helped

Usability testing / HCI / human factors

ISO 9241-11 frames usability as an outcome of use by specified users pursuing specified goals in a specified context. Usability testing and empirical HCI provide established ways to observe representative people doing representative tasks and, when needed, compare conditions.

When the same people use more than one condition, order and learning can affect results; when different people use different conditions, differences between the groups can affect results. Realistic task scenarios, pilot testing, and appropriate sample-size planning help reduce avoidable ambiguity.

Use these methods when the test requires stronger task design, error analysis, workload measures, comprehension testing, accessibility evaluation, controlled comparison, or statistical inference.

Value Sensitive Design

Value Sensitive Design provides a systematic way to consider human values in the design of technology. This guide draws on that tradition to keep a practical correction visible: reducing effort or increasing persuasion is not automatically beneficial when agency, informed choice, safety, fairness, consent, professional responsibility, or other values matter.

Use this tradition when interventions influence consequential choices, vulnerable populations, safety, consent, regulated decisions, or meaningful tradeoffs.

Program evaluation / theory of change

Program-evaluation traditions connect an intervention to the activities and mechanisms expected to produce shorter- and longer-term outcomes, and distinguish evaluation designs with different abilities to support causal conclusions.

Use them when the test becomes more complex or when an observed human effect is carried into Tracing Business Impact Beyond the Click.

Citation Labs practice lineage: purchase decisions

We’ve been circling one recurring problem for years here at Citation Labs: how to make commercially important information genuinely useful to practitioners doing real purchase work.

What survives in the parent method

The durable question is simpler than the richer apparatus that preceded it: what must information enable for the people doing consequential work? The parent guide keeps the practitioner, the situation, the other people who materially matter, the handoffs, the evidence requirements, the information environment, the gap, the intervention, and the test.

The purchase-decision application adds emphasis, not a second method. It reminds you that fit, comparison, proof, rejection, approval, implementation conditions, and evidence transfer can all be bottom-of-funnel information work.

Where Decision Architecture still adds something useful

Decision Architecture remains published as an adjacent, deeper research and operating note. Its role-specific citation and co-citation analysis is especially useful when you want to compare what an AI environment consults and cites for different buyer roles, where cited source sets overlap, and where a decisive role appears isolated from the source world serving the rest of the committee.

That is not the same as establishing a human information requirement. Use the analysis as a lead: if a security reviewer’s prompts draw from a source world the brand never reaches, investigate whether that reviewer is actually underserved, what they must establish, and what information must enable for them. The machine-side finding remains an AI Visibility result; the human-work question belongs here.

This is an active specialization area for Citation Labs. The parent method stays broad by design; purchase-decision and bottom-of-funnel work can deepen without requiring every Information Design investigation to adopt a buying-committee model.

Source starters

These sources are starting points, not a complete canon.

• Taylor, Robert S. “Question-Negotiation and Information Seeking in Libraries.” College & Research Libraries 29(3): 178-194, 1968. DOI: 10.5860/crl_29_03_178.
• Dervin, Brenda; Foreman-Wernet, Lois; Lauterbach, Eric, eds. Sense-Making Methodology Reader: Selected Writings of Brenda Dervin. Hampton Press, 2003.
• Bates, Marcia J. “The Design of Browsing and Berrypicking Techniques for the Online Search Interface.” Online Review 13(5): 407-424, 1989. DOI: 10.1108/eb024320.
• Beyer, Hugh; Holtzblatt, Karen. Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, 1998.
• Klein, Gary A.; Orasanu, Judith; Calderwood, Roberta; Zsambok, Caroline E., eds. Decision Making in Action: Models and Methods. Ablex, 1993.
• Klein, Gary A.; Calderwood, Roberta; MacGregor, Donald. “Critical Decision Method for Eliciting Knowledge.” IEEE Transactions on Systems, Man, and Cybernetics 19(3): 462-472, 1989. DOI: 10.1109/21.31053.
• Vicente, Kim J. Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work. Lawrence Erlbaum Associates, 1999.
• Suchman, Lucy A. Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press, 1987.
• Hutchins, Edwin. Cognition in the Wild. MIT Press, 1995. DOI: 10.7551/mitpress/1881.001.0001.
• Rosenfeld, Louis; Morville, Peter; Arango, Jorge. Information Architecture: For the Web and Beyond. 4th ed. O’Reilly Media, 2015.
• Carlile, Paul R. “Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge Across Boundaries.” Organization Science 15(5): 555-568, 2004. DOI: 10.1287/orsc.1040.0094.
• Wang, Richard Y.; Strong, Diane M. “Beyond Accuracy: What Data Quality Means to Data Consumers.” Journal of Management Information Systems 12(4): 5-33, 1996. DOI: 10.1080/07421222.1996.11518099.
• ISO 9241-11:2018. Ergonomics of Human-System Interaction – Part 11: Usability: Definitions and Concepts. International Organization for Standardization, 2018.
• Rubin, Jeffrey; Chisnell, Dana. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. 2nd ed. Wiley, 2008.
• MacKenzie, I. Scott. Human-Computer Interaction: An Empirical Research Perspective. 2nd ed. Morgan Kaufmann, 2024.
• Faulkner, Laura. “Beyond the Five-User Assumption: Benefits of Increased Sample Sizes in Usability Testing.” Behavior Research Methods, Instruments, & Computers 35: 379-383, 2003. DOI: 10.3758/BF03195514.
• Sauro, Jeff; Lewis, James R. Quantifying the User Experience: Practical Statistics for User Research. 2nd ed. Morgan Kaufmann, 2016.
• Friedman, Batya; Hendry, David G. Value Sensitive Design: Shaping Technology with Moral Imagination. MIT Press, 2019. DOI: 10.7551/mitpress/7585.001.0001.
• Kidder, Daniel P., et al. “CDC Program Evaluation Framework, 2024.” MMWR Recommendations and Reports 73(6): 1-37, 2024. DOI: 10.15585/mmwr.rr7306a1.

Use the literature appropriate to the specific mechanism you are invoking. Do not cite an adjacent field merely to make the guide look more theoretical.

APPENDIX – WORKING RECORD

Use this as the running record for an Information Design investigation.

Build this record as the investigation develops. A short answer is enough when the situation is simple; use deeper evidence, expertise, or testing only when uncertainty and consequences justify it.

Not every field is required for every project.

UNKNOWN is a legitimate entry when the available evidence does not support a stronger claim.

If you change an earlier answer in light of new evidence, revise the earlier section rather than forcing the rest of the record to remain consistent with something you no longer believe.

For important findings, keep evidence state and provenance separate.

Use that table when it helps. You do not need to classify every sentence in the record.

A. Signal, people, and situation

Starting signal:
What brought this to your attention?

Proposed solution, if any:
What are you already being asked to make or change?

Primary person / role:

Other people who materially matter:

Situation / trigger:

What is the primary person trying to accomplish?

Important constraints:

What happens if they get it wrong, cannot proceed, or cannot establish what they need?

Evidence available so far:

Important unknowns or assumptions:

What, if anything, would justify deeper research before proceeding?

You are ready for Part II when

You should be able to say:

These are the people who matter, this is what they are trying to accomplish, and this is why the information matters in this situation.

B. What information must enable

For each important requirement, ask:

What must information enable this person to understand, judge, verify, do, or pass onward?

Required elements, where omission matters:

Relevant information environments / entry points:

What must remain attached through the handoff:

Necessary verification, judgment, review, escalation, or other scrutiny:

Current requirement statement:

For [person/people], in [situation], information must enable ____________________.

C. Current environment and gap

Compare the requirements with what people can actually encounter and use.

Keep condition and consequence separate.

Observed compensations / workarounds:

Current gap statement:

People need information to enable ____. The current environment enables ____. The material gap is ____.

Stop here when no material gap is established

You can observe an imperfection in the information environment but cannot establish that it materially matters to the people and situation you are investigating.

An inspection can legitimately end without an intervention when the observed imperfection cannot be shown to matter materially to the people and situation.

D. Intervention

Gap being addressed:

Affected source(s), path(s), system(s), or handoff(s):

Current owner:

Requirements already served by them:

Existing intervention, decision, or change record, if any:

Proposed form of change: new / changed / connected / retired / unchanged:

Conflict or dependency with existing sources, paths, or prior decisions:

Specialist or domain question requiring validation:

Receiving owner / specialist:

Owner response / rationale:

Status: open / validating / accepted / changed / deferred / declined / resolved

Nearest observed burden, if established:

Hypothesized downstream or business consequence, if any:

Blocker or dependency:

Next evidence request or check:

Appropriate escalation path, if needed:

Disposition / follow-through:

Proposed change:

Relevant surface(s), system(s), path(s), or handoff(s):

Why this should help:

Because the current environment ____________________, changing ____________________ should help [person] ____________________.

Important conditions, evidence, scrutiny, escalation paths, or other things the intervention must not weaken:

Authoritative source / person who can establish underlying truth, if relevant:

Owner of the affected environment / source / workflow:

Who can authorize the change:

Maintenance owner:

What triggers review or update:

How will stale or conflicting information be handled?:

Important dependencies:

Current intervention statement:

People need information to enable ____. The current environment enables ____. The material gap is ____. We will change ____ because we expect it to help ____.

E. How we will know if it helps

Expected effect

If we change X, [person] should become better able to do Y because Z.

Expected effect:

Measures

Guardrail – what must not get worse:

What question must the test answer?

• ☐ Can people use the intervention successfully, and where does it break?
• ☐ Does the intervention appear to help compared with the current environment?
• ☐ Another question:

People / roles participating:

Scenario or activity they will complete:

Information condition(s) they will encounter:

Comparison, if used:

Why this setup can answer the question:

Differences between people or scenarios that could affect interpretation:

Learning / order effects to consider:

How will the information be encountered realistically without giving away the answer?:

Pilot changes, if any:

Does this test require research, human-factors, or statistical expertise beyond the team running it? Why / why not?:

Decide beforehand how you will read the result

F. Test and interpret

Intervention version / condition:

People involved:

Scenario / situation:

Relevant entry paths or handoffs included:

Material departures from the planned setup:

Observed changes:

Observed non-changes:

Inconclusive / insufficient evidence:

Guardrail result:

Contradictory / complicating observations:

Adverse / guardrail failure:

Interpretation

Keep this separate from the observations above.

What does the pattern make more plausible?:

What does the pattern make less plausible?:

Alternative explanations that still matter:

Important evidence limits:

If the expected result did not appear

Where might the reasoning need revision?

• ☐ People did not actually encounter the intervention as intended.
• ☐ The intervention was not implemented as designed.
• ☐ The information condition was not actually changed.
• ☐ The intervention still did not make the needed information usable.
• ☐ The expected mechanism was wrong or incomplete.
• ☐ The measure did not represent the improvement well.
• ☐ What we thought people needed information to enable was incomplete or wrong.
• ☐ Our understanding of the people or situation needs revision.
• ☐ Other:

If an earlier assumption no longer holds, return to the Part where it was established and revise it.

G. What the evidence supports

What changed:

What did not change:

What remains UNKNOWN or inconclusive:

Strongest supported result:

Under ____________________, [people] ____________________.

Important conditions / limits:

Evidence state:

Provenance:

What happens next?

Choose what the evidence actually warrants.

• ☐ Keep / maintain the intervention in the tested context.
• ☐ Revise the intervention and test again.
• ☐ Return to an earlier Part because our understanding changed after reviewing new evidence.
• ☐ Test another materially different person or situation.
• ☐ Stop – the evidence is sufficient for the decision we needed to make.
• ☐ Investigate a genuinely new question.

Next decision:

EVIDENCE TO CARRY FORWARD — IF NEEDED

HANDOFF RULE  A handoff begins a new question. It does not add another conclusion to the originating investigation. Copy the established result without rewriting it; enter the hypothesis as an uncertainty to investigate.

Minimum useful record

If the full record feels unnecessary for a modest problem, the minimum useful version is:

Decision this investigation must help make: What will someone decide differently depending on what we learn?

Signal: What brought this to our attention?

People + situation: Who is affected and what are they trying to accomplish?

Information must enable: What must information make possible for them?

Current environment: What does it actually make possible?

Gap: What meaningful difference have we established?

Intervention: What are we changing, and why should that address the gap?

How we will know: What should become better, what will we observe, and what must not get worse?

Test: What happened?

Supported result: What does the evidence justify saying?

Next decision: Keep, revise, investigate further, or stop?

If that is sufficient for the consequences of being wrong, stop there.

Use the fuller record when uncertainty, consequences, multiple people, difficult handoffs, technical conditions, or stronger conclusions make the extra discipline useful.

Garrett French

Garrett French is the founder of Citation Labs, where he helps brands stay visible in AI answers and search through citation optimization and relevance-led link building at scale. His team studies how buyers use AI tools to shortlist purchases and deploy campaigns designed to increase client citations in recommendations.

He also built Xofu, a platform that tracks brand visibility across AI-generated recommendations, benchmarks competitors, and surfaces the pages AI references. And he leads ZipSprout, which builds sponsorship links by connecting businesses with nonprofits, events, and local organizations.

Garrett’s current explorations focus on decision efficiency and AI response behavior: how buyers decide, how AI systems “decide,” and how comparison assets influence what is cited for high-intent selection prompts.