Progress Reporting
Turning Progress Reports into Client-Facing Links
External LinksClient Reports8 Client Companies·2024
Designing Proteus's first external reporting link, so project managers could prepare progress reports inside the product and share a controlled snapshot with their clients.
External Links·Client Reports·8 Client Companies·2024
TL;DR
Project managers were creating client progress reports outside Proteus by exporting data, rebuilding it in spreadsheets and sending static files. I designed the first Proteus experience that could be shared with external clients: PMs configure reusable datasets, compose a report from content blocks and publish a controlled snapshot through a link. The design had to make internal project data client-safe without giving external readers a Proteus account.
Details
Surface
Web based B2B SaaS platform
My role
Sole Product Designer
Team members
CTO · Business Analyst · Front and Back End Devs
Scope
Reporting Workflow · Information Architecture · UX Writing
CONTEXT
A progress report is not just internal data. It is something our users send to their clients.
Project managers report progress to their clients on a regular cycle. Before this work, that process happened around Proteus rather than inside it: export the numbers, reshape them in Excel, lay them out in Word, then email the file.
The report was based on Proteus data, but the final client copy was disconnected from the system that produced it. This project was also the first time Proteus needed to support an external link, which meant designing for people who would never log into the product.
THE CHALLENGE
The link changed the boundary of the product.
Proteus is a closed, account-based system. A client progress report is for the opposite audience: external readers who need a clear, trusted view of progress without seeing the working system behind it.
That created three problems to design around:
- External access. The report needed to be shareable without giving clients a Proteus account.
- Client-safe context. Internal project data had to be shaped into something a client could understand without knowing the product.
- Published version control. Project managers needed confidence that the link showed the version they had reviewed, not unfinished working data.
THREE PRODUCT DECISIONS
Decision 1/3
Turn Datasets Into Reusable Client-Safe Views
Configure once, report monthly.
One report usually needs several cuts of the same project: different work packages, different financial views and different levels of detail. The underlying data includes dozens of fields, and the useful column set can vary by client company.
I made the configuration itself reusable. A dataset is a named, saved view: which columns are visible, how they are grouped, whether the full component breakdown is expanded and whether internal work packages are included.
That last choice matters because the same project can produce an internal dataset and a client-safe one. The boundary is handled by configuration rather than memory.
Decision 2/3
Preparing Data and Composing a Narrative Are Separate Modes
Two tabs, two mindsets.
Deciding which numbers matter is analytical work. Deciding how to explain those numbers to a client is editorial work. Early on, trying to hold both in one screen made the workflow harder to understand.
I split the experience into Report Data for datasets and Reports for composition. A report is assembled from reusable components such as rich text, a dataset, an S-curve and a Gantt chart. This lets a PM follow the narrative order a particular client expects instead of forcing every report into one fixed template.
I also kept the published report tied to the saved dataset configuration. This made the external version predictable: what the PM configured is what the client sees.
Decision 3/3
A Snapshot, Not a Live Feed
Share reviewed data, not working data.
Because this was the first external link in Proteus, it was important to decide what the link represented. A live feed would have been convenient technically, but it could expose working figures a PM had not reviewed yet, such as a half-updated forecast or a variation waiting for approval.
I designed the link as a published snapshot. Saving the report updates the version visible to anyone with the link, and the interface makes that consequence explicit. The report page also carries a data last updated stamp, because an external reader needs to know when the numbers were produced.
OUTCOME
Reporting moved from a manual process around the product into a controlled product workflow.
The export, rebuild and email loop moved into Proteus. Project managers can prepare reports from system data, shape them for a client audience and share a controlled link without giving external readers product access.
It also gave Proteus its first client-facing surface. Reporting is currently controlled by a feature flag and is already being used by 8 client companies.
WHAT'S NEXT
Report structures are still built from scratch each cycle. The natural next step is templates that carry a client's preferred report structure forward. The shared report page also knows when it has been opened, but that signal is not yet surfaced to project managers. Showing it back to them could help PMs understand which reports are actually being read.