A BETTER WAY TO SHARE THE WORK
Make the important information impossible to miss
The same facts can serve different readers. Change what leads—not what is true.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
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.
01 / SEE THE DIFFERENCE
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.
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.
Open a complete fictional HTML example, with its source notes →
Create my reader-first briefing02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
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.
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.
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.
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.
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.
Adapt this to your work
Keep the same approach. Change the inputs and review checks for the job you need.
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 source notes: 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.
The matching instructions are included in the creation request below; your agent should use them only when relevant.
03 / TRY THIS PROMPT
Copy this into your agent. Add your source material.
Use the conversation where you already did the work, or start one with your notes. Replace the placeholders and supply any missing context; only attach information you are allowed to share with your agent.
Get the ready-to-copy creation request for guided questions, this task, and a draft review before anything is published.
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.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- 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.
FROM DRAFT TO A LINK
Make it clear. Make it yours. Then share it.
Keep creating and revising in the agent you already use. With a compatible connection, share/artifacts publishes the reviewed HTML so you do not have to rebuild it in another editor. Ask your agent to use your saved artifact style for headings, color, and tone; review the result before sending it.
Choose who should be able to open the page and verify the returned link. For corrections to the same deliverable, update the existing artifact without changing its link. Publish a separate artifact when the old edition needs to remain available.
These are static pages, not live apps: no scripts, forms, or automatic data refresh. Source collection and scheduling depend on your agent and its available tools, not on share/artifacts.
Make this with my agentQuestions before you start
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.