share/artifacts
PricingSign inConnect your agent
← All guides

From one source to two reader-specific briefings

Same facts. A different first question.

Information design arranges evidence around what a reader needs to understand or do, using hierarchy and reading order without changing the facts.

Make this with my agent

Bring your notes. Review a draft before sharing.

Explore the method
  1. 01
    Change what leads

    The sponsor sees the scope choice; the delivery team sees Maya’s next action.

  2. 02
    Keep the same evidence

    Both versions retain four guides planned, three reviewed and the blocked policy answer.

  3. 03
    Don’t manufacture readiness

    September 14 remains a target, not approval; no impact or adoption result is supplied.

THE REAL HTML · FICTIONAL EXAMPLEView on its own

A worked example, not a customer result. September 2026 dates are sample facts.

Now make it about your work

Your facts. Your agent. Their next step.

Compare the same source arranged for a sponsor’s decision and a delivery team’s next action.

Start with three things

  1. The approved source facts and their limitations.
  2. The reader and the decision or action they need.
  3. Approval boundaries, dependencies and audience-safe detail.
Make this with my agent

You review the facts and access. Nothing is published without your approval.

The method behind the information design briefingAsk your agent to propose the reading order first, then use layout to emphasize each reader’s task while preserving every material fact.

How do I ask my agent to make a report easier to understand?

Tell your agent who will read it and what they need to decide or do. Ask it to put that answer first, keep supporting evidence nearby, and move background detail further down. Then check that clearer presentation has not changed the facts. A saved style can keep your work recognizable; information design makes this particular page useful.

What to give your agent

  • The approved source material, its date, and definitions for any figures. Keep private material in your own agent conversation.
  • The intended reader and the decision or action they need to take. If you have two audiences, describe both jobs.
  • Risks, uncertainties, deadlines, and approval boundaries that must stay visible—not disappear into an appendix.
  • Which details are safe for the audience, plus optional saved style preferences. A style is not permission to share source material.

  1. Start with the reader’s job

    Ask what the reader should understand or do next, before choosing colors. A sponsor deciding scope needs the choice first; a delivery team needs owners and actions. Start with what the reader needs to accomplish, rather than everything you could say.

  2. Agree on the reading order before the look

    Ask your agent for a plain-language outline: main answer, supporting evidence, then background. Give the most important message space and a clear heading. Keep material limitations beside the claims they qualify. Use size, contrast, and grouping to reinforce that order—not to compete with it.

  3. Give color a specific job

    Use one accent for the principal decision or action and quieter treatment for routine context. Write labels such as ‘Blocked’ or ‘Decision needed’ instead of relying on red and green. W3C requires information beyond color alone; ordinary text needs at least 4.5:1 contrast and qualifying large text 3:1. Check the actual combinations, including notes and links.

  4. Group detail instead of shrinking it

    A decision summary can lead into evidence. An action list can group each owner with their task and deadline. Move lower-priority background down the page, but keep it readable and easy to find. A short source bundle does not need a chart or tiny type just to look designed. Check that the phone reading order still makes sense.

  5. Audit the facts after the redesign

    Compare the draft against the source line by line. Three reviewed guides out of four does not establish launch readiness, impact, or approval. Ask the agent what it emphasized and why, then verify its answer. Review accuracy, accessibility, and audience-safe details before giving separate permission to publish.

Keep creating and revising in the agent you already use. Start with a saved artifact style and learn how to update HTML without changing its link.

Use the full promptReady for your agent and your notes

Use the conversation where you already did the work. Only attach material you are allowed to share.

Get the ready-to-copy creation request →
Use only the source material I provide to create a clear static HTML briefing for [audience]. Their main task is [decision or action]. First propose the reading order in plain language. Put the most important supported answer first, keep evidence and material caveats beside the claims they qualify, and group background detail lower down without concealing it. Preserve names, dates, quantities, definitions, uncertainty, and approval status. Do not turn completion counts into readiness scores or invent a recommendation that the sources cannot support. Use restrained color with text labels, readable type and spacing, and a sensible mobile reading order. Use my saved artifact style if available without letting it override clarity. Ask for missing essentials and flag contradictions. Produce static HTML without scripts, forms, or live-data claims. Show me the draft and explain what you emphasized and why. Do not publish or change access without separate explicit approval. For a document-to-reading-page adaptation, first inspect the supplied text and tables, identify the reader's question and map each retained claim to its source. Preserve table definitions, caveats and approved links. Flag unreadable or missing content rather than guessing. Do not promise file-format fidelity or alter a required formal original.
Check before you shareAccuracy, clarity, and permission
  • Can the intended reader find the answer and next step without reading everything?
  • Are every number, date, owner, and approval status still supported by the source?
  • Are material caveats visible near their claims, rather than buried as background?
  • Do text labels preserve meaning without color, and do all text/background combinations have sufficient contrast?
  • Are supporting details still readable on a phone, with a logical heading order and keyboard-accessible links?
  • Have you approved the facts, wording, intended audience, and sharing settings separately from the design?

When HTML fits

A reviewed snapshot that readers need to understand, compare, or act on. HTML lets your agent arrange the explanation around that task, then revise it through conversation.

When another format fits better

Keep live task tracking and source-of-truth records in their established tools. A static briefing does not update itself, establish approval, or replace a required formal document. Do not hide a material risk just because it complicates the layout.

What we started withThe same facts, as an email

Fictional project email

Harbor support-guide pilot — scope and next actions

Update for the sponsor and delivery team, September 7, 2026:

Four guides are planned, and three have passed editorial review. Account recovery, the fourth guide, is blocked on a Support policy answer. Maya owns that answer, due September 9. Luis will update the guide after the answer arrives; his completion date is not confirmed.

The sponsor needs to choose by September 10 whether to run a three-guide pilot or wait for all four. The four-guide pilot target is September 14, not an approved launch date. There are no impact or adoption results yet, and these facts do not establish which option is better.

For the sponsor, the next question is pilot scope. For the delivery team, it is how to unblock the guide. Both groups need the same facts and qualifications.

Inspect the HTMLOne self-contained file

The example is sanitized and isolated from this site. No scripts, forms, or live data.

<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Harbor pilot · Same facts, two readers</title><style>
*{box-sizing:border-box}body{margin:0;background:#f8f6ef;color:#172520;font:17px/1.65 system-ui,sans-serif}main{max-width:1000px;margin:auto;padding:clamp(20px,5vw,56px)}h1,h2,h3,p{margin:0 0 18px}h1{font:500 clamp(32px,5vw,54px)/1.14 Georgia,serif;overflow-wrap:anywhere}h2{font:500 clamp(27px,4vw,36px)/1.2 Georgia,serif}h3{font-size:20px;line-height:1.4}.label{font-size:12px;font-weight:700;letter-spacing:.09em;text-transform:uppercase}.note{font-size:15px;color:#40584d}.version{margin:38px 0;border:1px solid #8e9f93;background:#fff;padding:clamp(20px,4vw,36px)}.lead{background:#153e32;color:#fff;margin:24px 0;padding:24px}.lead p:last-child{margin-bottom:0}.facts{margin:26px 0}.caveat{border-left:4px solid #153e32;padding-left:18px}footer{border-top:1px solid #8e9f93;margin-top:36px;padding-top:22px}a{color:#153e32;text-underline-offset:4px}a:focus-visible{outline:3px solid #153e32;outline-offset:4px}@media print{.version{break-before:page}.lead{break-inside:avoid}}
</style></head><body><main><header><p class="label">Fictional worked example · September 7, 2026</p><h1>Same facts. A different first question.</h1><p>Harbor support-guide pilot: two complete briefings from one source bundle. The palette and type stay the same; the reader’s job changes what leads.</p><p class="note">Read the sponsor version first, followed by the delivery-team version below.</p></header>
<article class="version" id="sponsor"><header><p class="label">Version A · Sponsor · Snapshot September 7, 2026</p><h2>Choose the pilot scope by September 10.</h2></header><aside class="lead"><p class="label">Decision needed</p><p>The sponsor must choose by September 10, 2026: run a three-guide pilot or wait for all four.</p><p>Neither option is approved by this briefing.</p></aside><section class="facts"><h3>Evidence for the choice</h3><p>Four guides are planned. Three have passed editorial review.</p><p><strong>Blocked:</strong> the fourth guide, account recovery, is waiting for a policy answer from Support. Maya owns that answer, due September 9, 2026.</p><p>Luis will update the account-recovery guide after Maya’s answer arrives. His completion date is not yet confirmed.</p></section><section class="caveat"><h3>Target, not approval</h3><p>The four-guide pilot is targeted for September 14, 2026. It is not approved for launch.</p><p>No impact or adoption results are available yet.</p></section><p class="note">Why this leads: the sponsor needs a scope choice. The blocked guide, owner, and unconfirmed completion remain visible below the decision.</p></article>
<article class="version" id="delivery"><header><p class="label">Version B · Delivery team · Snapshot September 7, 2026</p><h2>Unblock the account-recovery guide.</h2></header><aside class="lead"><p class="label">Next action · Maya</p><p>Provide the Support policy answer by September 9, 2026.</p></aside><section class="facts"><h3>Work and dependency</h3><p>Four guides are planned. Three have passed editorial review.</p><p><strong>Blocked:</strong> the fourth guide, account recovery, is waiting for a policy answer from Support. Maya owns that answer, due September 9, 2026.</p><p>Luis will update the account-recovery guide after Maya’s answer arrives. His completion date is not yet confirmed.</p></section><section class="facts"><h3>The scope decision still matters</h3><p>The sponsor must choose by September 10, 2026: run a three-guide pilot or wait for all four.</p></section><section class="caveat"><h3>Target, not approval</h3><p>The four-guide pilot is targeted for September 14, 2026. It is not approved for launch.</p><p>No impact or adoption results are available yet.</p></section><p class="note">Why this leads: the delivery team needs the next action and dependency. The sponsor’s choice and the launch caveat remain visible, not omitted.</p></article>
<footer><p><strong>What changed:</strong> the first heading and accent panel answer a different reader’s question. Every source fact appears in both versions. Color reinforces written labels; it does not establish status.</p><p class="note">Fictional worked example by share/artifacts. Names, dates, and facts are invented for demonstration. Static snapshot; no live tracking, automatic updates, or approval mechanism.</p></footer></main></body></html>
The original worked scenarioThe source scenario, step by step

One support-guide pilot. Two reader needs.

Fictional Harbor support-guide pilot, September 7, 2026. Both audience versions keep every source fact, the same typography, and the same palette. Only their reading order and emphasis change.

The original notes

Four guides are planned; three passed editorial review. Account recovery is blocked pending Maya’s Support policy answer, due September 9. Luis updates it afterward; completion is unconfirmed. The four-guide pilot targets September 14 but is not approved for launch. The sponsor must choose by September 10 between a three-guide pilot and waiting for all four. No impact or adoption results are available.

Sponsor lead

Choose the pilot scope by September 10: start with three reviewed guides or wait for all four. This is a decision request, not a recommendation or an approval.

Delivery-team lead

Maya: provide the Support policy answer by September 9. Luis updates the account-recovery guide afterward; his completion date remains unconfirmed.

Evidence in both

Four guides planned, three reviewed, account recovery blocked. Both versions retain the complete owner/action sequence and the sponsor’s decision deadline.

Caveat in both

September 14 is the four-guide pilot target, not launch approval. No impact or adoption results are available. Neither version claims ‘on track’ or invents a readiness score.

Visual change

The sponsor’s choice gets the accent panel in one version; Maya’s next action gets it in the other. Labels carry the meaning as well as color. All remaining facts stay readable below.

Better information design does not require more impressive facts. It makes the right existing facts easier for a particular reader to use.

Questions, adaptations & sourcesGo deeper when you need to

Is this the same as saving an artifact style?

No. A saved style preserves reusable preferences such as typography, palette, and tone. Information design decides what this reader needs first in this particular artifact. You can use the same style for two audiences and still organize their pages differently.

Should I remove detail to make the page clearer?

Remove irrelevant repetition, not material evidence. Put background after the main answer and keep it readable. A decision-changing limitation belongs beside the claim, even if it makes the headline less tidy.

Does a more visual page need charts?

No. A well-labeled action list or a concise comparison may explain the source better. Use a chart only when a verified relationship becomes easier to understand. Never invent percentages, scoring, or unsupported certainty to fill a visual slot.

Turn a document into a reading page

Change the reading order for the audience, not the evidence. Work from authorized source text and checked tables. If the recipient needs an unchanged fixed file, use that format instead; this is an editorial adaptation, not a promise of automatic file-import fidelity.

Fictional inputs: Fictional source document: a background section precedes a table showing four guides planned and three reviewed. A later note says the account-recovery guide is blocked on a policy answer, launch approval is absent, and no adoption results exist. Source links are available only in the authorized original.

A clearer result: Lead with the outstanding decision and blocker. Retain the four/three table values, lack of approval and absent adoption evidence beside that summary. Move background lower and keep only audience-approved source links. Do not turn the review count into readiness or drop the caveat because it was in an appendix.

Further reading

By share/artifacts · Published · Updated