The report that rebuilt itself
Designing a faster, more flexible daily media requests reporting
A report, rebuilt from scratch, every day
At the end of each day, communication teams across the BC Government send a report to executives so they can see what media requests came in, what was asked, and how the team responded.
The system could export the requests, but only as a plain-text list. Teams still had to turn that export into a report by hand.
As the product designer on the team, I had four weeks to design a faster way to generate the report with less manual work.
Tracing the manual process
I started by asking communication teams to show me how they actually built the report and I found the export was only the starting point. After that, teams still had to select the right requests, group them by status, count totals, format the report, review the details, and send it out manually.
The manual process showed me where the friction was. I started to wonder if the system could take care of the repetitive setup work, so users could spend less time formatting the report.
The first version tried to automate too much
I used Figma Make to quickly prototype the concept and validate it with users before spending more time on higher-fidelity designs.
My first idea was simple: choose a date and generate a finished report. The concept worked, but testing showed me that I was missing the human judgement part. Every ministry had its own reporting preferences, and users still needed to reformat the content and decide what deserved executive attention.
The first iteration taught me that the value wasn’t just in generating a finished report faster. It was about creating a strong starting point that reduced the manual work, while still giving users room to shape the report before sending it.
Try clicking "Generate report" button!
Automate the routineKeep the human call.
I stopped trying to finish the report for them.
Instead, I focused on designing a better starting point: an editable report builder that handled the repetitive structure while leaving the final decisions to the team.
Automating visibility
From talking to users, I found the main purpose of the report was to give executives visibility into how media requests were handled over a certain date range. That's why communication teams were manually grouping requests, counting totals, summarizing activities and organizing the report before sending it. So I redesigned them as a part of the auto build.
12Executive summary
Users could add a short summary to frame the day's key highlights before executives reviewed the details.
I kept the summary editable because users still needed to decide what deserved executive attention, not just generate a report automatically.
Aggregated overview
I looked at what users grouped most often and found the same patterns repeated: status, topic, and media outlet.
I added them to the report overview and visualized the data to give executives a quick snapshot before diving into the details.
Automating the report structure
Since the report existed, communication teams had to manually sort what was done from what was still in progress. Grouped by status made sense to anyone reading it — it was one of the most time-consuming steps in the process, and it happened every single day.
The builder now groups requests by status automatically, giving editors a clear starting point and letting them work through the full list without reading from top to bottom first.
The team decides what leads
The first iteration showed me the risk of making the auto-built report too rigid. Not every office needed the same level of detail, and if users couldn’t control what was included, they would still have to edit around the system after the report was generated.
So I added controls that let users decide which requests appeared in the report and which fields were shown on each card. This gave each office more flexibility to build the report around what they actually needed.
Scope management
Once the requests were pulled in, users still needed to make judgment calls about what belonged in the final report. Scope management help this by removing anything unnecessary, and keep the report focused.
Report contents sidebar
Because the report pulled in every request from the selected date range, users still had to decide what belonged in the final version and manually remove anything that didn’t.
I designed the report content sidebar to work like a table of contents, giving users one place to scan every request and hide anything that didn’t need to appear in the final report.
Removing the daily rebuild
The goal was to reduce the time teams spent rebuilding the report every day.
Once a report structure was set up for a ministry, it didn’t make sense for users to recreate the same setup again and again.
So I added scheduling, allowing teams to carry the same structure and recipients forward instead of rebuilding the report from scratch each day.
What shipped, and what still matters
Not every part of the prototype made it into the shipped product. Granular filtering and scheduling were descoped as timelines tightened and priorities shifted toward the first iteration: generating the report automatically. The shipped version solved the most immediate problem, but it did not include the controls that helped users shape the report around their own judgment.
I still think there is more to solve. The product should take care of the repetitive work without taking away the decisions people still need to make. I hope to return to this in a future iteration, test the prototype further and close the gaps between what was shipped and what users actually need.