How Do You Design an Annual Report for the Web?

How do you design an annual report for the web?

Treat it as a site, not a document. Break the report into sections that each stand alone, give every section its own URL, design the data to be read on a phone, and drop the print grid entirely. The instinct to reproduce the PDF layout is the single biggest cause of bad web reports.

We built the GEO 2025 Annual Report for Grantmakers for Effective Organizations, as a complete design and development project, redesigned from the previous version. It runs as eight report sections with a 2.9 second load time, and those numbers are on our work page.

The interesting part was not the visual design. It was deciding what a report becomes when it stops being a document.

Why does a PDF fail as a web report?

Because it was designed for a page size the reader does not have. A PDF assumes a fixed canvas, usually A4 or letter, with a fixed column width and a designer controlling exactly where every element sits. A browser gives you none of that.

On a phone, a PDF designed for print becomes a pinch-and-zoom exercise. The reader has to scroll in two directions to read a single paragraph, which is precisely the failure the accessibility standards were written to prevent.

It also fails at discovery. A PDF is one URL containing everything, so no individual finding inside it can be linked, shared, quoted or found in a search. For a report whose whole purpose is to be cited, that is a strange choice.

What structure actually works?

One section per page, with a persistent way to move between them. Each section gets its own URL and its own title, so someone can send a colleague the part that matters rather than the whole report and a page number.

Then a contents view that shows the shape of the whole thing. Readers of a report are almost never reading it front to back. They are looking for a specific figure or a specific theme, and the contents page is the tool they use to find it.

Keep the section count honest. A report split into thirty micro-pages is as hard to navigate as one long PDF. Our GEO build settled at eight sections, which is enough to give each theme room without making the reader hunt.

How should the data be presented?

Simplified, one idea at a time. The chart that works in a print report is often too dense for a phone, because print gives you a large canvas and a reader holding it still. Split a complex chart into two simple ones rather than shrinking it.

Give every number its sentence. A figure with no interpretation makes the reader do work the report should have done. A short line saying what the number means, next to the number, is worth more than a bigger chart.

And make the underlying data available as text, not just as an image of a chart. A chart rendered as a picture is invisible to screen readers, to search engines and to AI answer engines. Our notes on designing data tables for the web cover the mechanics.

What does accessibility require here?

More than a colour contrast check, though start there. The criterion that bites report layouts hardest is WCAG 2.2 Success Criterion 1.4.10 Reflow, at conformance level AA.

It requires that content "can be presented without loss of information or functionality, and without requiring scrolling in two dimensions," specifically for vertical scrolling content at a width equivalent to 320 CSS pixels and horizontal scrolling content at a height equivalent to 256 CSS pixels, except where a two-dimensional layout is required for meaning.

The intent section explains the cost plainly: when text extends past the viewport, users have to scroll back and forth horizontally, which raises both physical and cognitive effort and makes them lose their place. Wide tables and fixed-width chart images are the usual offenders. Our WCAG guide covers the wider set.

How fast does a report site need to be?

Faster than most are, because reports are image-heavy by nature and often built in a rush at the end of a long editorial process. Performance is usually the thing that gets dropped.

For context on the bar, the 2024 Web Almanac performance chapter found 43 percent of websites had good Core Web Vitals on mobile and 54 percent on desktop. On individual metrics, 59 percent of mobile pages achieved a good Largest Contentful Paint against 72 percent on desktop, 79 percent had good Cumulative Layout Shift on mobile, and 74 percent of mobile sites had good Interaction to Next Paint against 97 percent on desktop.

The mobile LCP number is the one to watch for a report, because the hero of each section is usually a large image or chart. That is the element the metric measures, and it is the one most likely to be oversized.

What about the print version?

Still make one, and stop treating it as the primary artefact. Many organisations genuinely need a document to hand to a board, a funder or a regulator. That need is real and it is separate from the web experience.

The mistake is designing the print piece first and deriving the website from it. Design the web version for reading and the print version for handing over. They share content and a visual identity, not a layout.

If budget only allows one to be designed properly, choose the web version. It will be seen by more people, for longer, and it is the version search engines and AI answer engines can actually read.

How do you handle the editorial process?

Lock the content before design, and mean it. Annual reports have more stakeholders than almost any other project: leadership, programme teams, finance, communications, sometimes a board. Every one of them has late changes.

Build the content model early so late changes are cheap. If each section is a structured entry with known fields rather than a bespoke page, a change to one figure does not require a designer. That is the practical argument for building a report in a CMS rather than as hand-built pages.

And set a single editorial owner who can say no. In our experience this matters more than any process document. Without one, the report grows by accumulation and the design absorbs the cost.

What makes a web report feel like a report rather than a microsite?

Typography and pacing. A report reads as a report because it is set for sustained reading: generous measure, clear hierarchy, consistent rhythm between headings and body. That is the opposite of a marketing page, which is built for scanning.

Restraint with motion helps too. A report is a document of record, and heavy scroll animation undermines that. Small, purposeful movement is fine. Anything that delays reading is working against the piece.

And a visible sense of progress. Knowing where you are in a long document is part of what makes a report navigable. Our piece on designing for skimming applies here more than it does to most content.

Where should you start on your next one?

Start by writing the contents list before anyone designs anything. If you can describe the report as a clear set of named sections, the site structure is already decided and the design brief becomes concrete.

Then decide the one figure from each section that a reader should leave with. Those figures drive the design of each section, and they give you the shareable moments that make a report travel further than the PDF ever did.

If you have a report coming up and want to talk through how to make it work on the web, we are happy to walk through it. Come and find us at phoenix.studio.