Until recently, a report had one kind of reader: a person, usually short of time, scanning a page for what needed attention. Today the same page is also read by AI assistants. Leaders ask Copilot in Power BI to summarize a report before a meeting, to explain what a visual shows or to point them to the report that answers their question. To do that well, the assistant relies on what the report says about itself: page names, titles, labels, units and descriptions.
The two readers have more in common than it seems. Both read literally. Both struggle with a page that tries to say everything at once. Both misread a number whose unit or period is missing. The design rules that help an assistant produce a correct summary are, almost without exception, the rules that make a report faster for people to read.
One message per page
Give each page one question to answer and name the page after it. “Revenue against plan by region” is a page; “Sales overview” is a drawer. When a page mixes revenue, headcount and customer complaints, a person has to work out what matters, and an assistant’s summary turns into a list of unrelated facts.
Move the supporting detail one click away, to a detail page or a separate tab, instead of crowding the main page. The leader gets the message, the analyst still has the detail, and the assistant has a page whose purpose is unmistakable. A short pack of focused pages also beats a long one, for both readers. Order the pages the way the conversation should go: the headline first, then the drivers, then the detail.
Titles that state the finding
A title such as “Revenue by region” describes the chart. A title such as “Most regions are ahead of plan; Quebec, Texas and Mexico trail” tells the reader what to take away, before they have to work it out for themselves. Use the subtitle for what the title leaves out: the measure, the unit, the period and the comparison. The title argues; the subtitle defines.
An assistant asked to summarize a page tends to lead with what the title says, so a title that states the finding makes the summary right as well. Where the finding changes with every refresh, compute the title from the data so that it stays true. A static title that contradicts its own chart is worse than no title at all.
One notation, everywhere
Decide once how actuals, plan, forecast and prior year will look, and use that everywhere: the same colours, line styles and abbreviations on every page. Show every variance with a sign, and colour it by whether it is favourable rather than by whether it is positive; higher costs are bad news even when the number goes up. Use the same scale for charts that are meant to be compared side by side.
Consistency lets a reader, human or machine, move from one page to the next without relearning the code. It also means an assistant comparing two visuals is comparing like with like, because the labels mean the same thing on both. Write the notation down in a short standard, so that new report authors follow it from their first page.
Units and periods on every visual
A number without a unit or a period is an invitation to misread it. Say “USD millions” or “% of sales”; say “quarter to date” or “last full month”. If the page is filtered to one region or one business unit, say so on the page, not only in a filter pane that nobody opens. And show how current the data is. Use the same period labels everywhere, so that “last quarter” never means the fiscal quarter on one page and the calendar quarter on the next.
Assistants are literal readers. If the unit is not written down, an assistant may report revenue in thousands as if it were in dollars, or describe a quarter-to-date figure as the full quarter. People make the same mistakes, only more quietly.
Describe each visual for a reader who cannot see it
Every visual can carry a short text description, written for people who use screen readers. Use it. Say what question the visual answers and what it shows, in a sentence or two, and give pages and visuals meaningful names instead of the defaults the tool generates. Describe the report as a whole as well: what it covers, who it is for and which decisions it supports.
The same text serves both readers. A person using a screen reader learns what the chart says; an assistant asked which page explains the margin decline has something to match the question against. Descriptions also impose a useful discipline: if the author cannot say in a sentence what a visual is for, it probably does not belong on the page. Review descriptions together with titles, so that when a visual changes, its description changes with it.
Test the page by asking for a summary
Before publishing, ask an assistant to summarize each page and compare the result with the message you intended. If the summary misses the point, leads with a minor number or confuses periods, the page is unclear, and people will struggle with it too. Fix the page, not the summary. The check takes minutes and catches problems that a review of the numbers never will.
Build this check into the review every executive report already goes through, alongside reconciling the numbers to certified figures. Keep the summaries of the most important pages and read them again after major changes; a summary that suddenly reads differently is an early warning that something on the page has moved. Packs reviewed this way tend to get shorter, their titles sharper and their summaries more useful.
The bottom line
Designing for AI does not call for a new kind of report. It calls for the discipline good report design has always asked for, applied without exceptions: one message per page, a title that states it, one notation, explicit units and periods, and a description for every visual. Reports built this way are faster for leaders to read and safer for assistants to summarize, and they need no separate version for AI. Start with the pack leaders read most often; the rest can follow page by page. It is the standard we apply to our own Power BI work.