One of the most challenging design problems I worked on was redesigning BrightHR’s reporting capabilities to support flexible, custom report generation for small and medium-sized businesses.
Figma, Pendo
Product Design, Quant/Qual Research
BrightHR's reporting was locked. Pre-defined reports with fixed columns, a handful of date filters, and no API meant customers were exporting entire company datasets just to answer a simple question about one person's absence. 962 Pendo votes had accumulated against the request for custom reporting. It had become the single most requested capability across the platform.
And some of those exports weren't just inefficient. Managers were pulling organisation-wide datasets to analyse a single employee's history. Sensitive data exposed unnecessarily, every time.
Non-technical HR users should be able to construct flexible reports from BrightHR's underlying data model. Select the fields they care about, apply filters for the employees or teams they need, preview the output live, and save it for next time. No spreadsheet manipulation. No data exposure. Just the right data, for the right person, in the right shape.
Research for the feature began in October 2022.
As Design Lead, I created a research plan to understand how customers were using reporting data and where the existing system was failing them.
Before writing a single requirement, I pulled the analytics for the existing reports section to understand what users were actually doing with the tool we had. The data covered January to October 2022 — the period immediately before custom reporting work began.
Key Metrics
Page views
788,749
Jan–Oct 2022
Avg. time on page
3m 9s
Significant friction before getting a result
Custom date interactions
447,456
DayPicker + Apply events combined
Multi-employee searches
130,715
Users trying to scope reports themselves
Most generated report types
1. Blip timesheet
2. Absence
3. Annual leave summary
4. Employee information
5. Employee details
6. Sickness
7. Rota
8. Overtime
The custom dates pattern
447K of the top report events were users attempting to customise date ranges. Combined with 130K multi-employee searches and 21K single-employee searches, it was clear that users were fighting hard against the constraints of fixed reports — and losing.
Artifacts
To ground the analytics in real behaviour, I mapped a representative user scenario through the old reporting system. Sarah is a receptionist at a local GP practice. She's worked there five years and looks after a group of doctors and nurses. The practice was going paperless, and Sarah needed to pull sickness data for the upcoming quarterly board meeting.
Sarah
Receptionist, GP Surgery
Scenario: Sarah needs to report on how many sicknesses each employee has had over the last quarter for the next board meeting
Sarah lands on the reports page. 18 fixed report types are listed. She needs sickness data but isn't sure which one to pick.
Two sub-report options with no clear explanation of the difference. Sarah has to guess which one she needs.
Preset date ranges don't include 'last quarter'. Sarah has to switch to custom dates and navigate a calendar month by month.
The date picker only shows one month at a time. Sarah clicks back through the arrows to reach July, then forward again to September.
After navigating back and forth, Sarah finally selects July 1 to September 30.
PDF is greyed out. Sarah doesn't know what CSV means but it's the only option available.
The CSV opens in Excel with columns Sarah didn't ask for, data for the entire organisation, and hash symbols where dates should be.
Context
Sarah's been at the practice for five years. She manages reporting for a team of doctors and nurses. The practice has new board members pushing to go paperless, but she often feels overwhelmed by technical interfaces and just wants to get information quickly without lots of clicking around.
I needed to understand the scale of the problem. I used Pendo to surface a short survey to admins and managers actively using BrightHR's reporting section. The goal was to move beyond the 962 feature votes already sitting in our backlog and understand the why behind them.
Pendo feature votes accumulated
962
Named employee filtering as top need
63%
Reformatted exports in Excel after download
71%
Needed recurring or saved report templates
58%
Survey Insights
What is your biggest frustration with BrightHR's current reporting?
Nearly two-thirds of respondents cited the inability to scope reports to a single person or team as their primary frustration — and many flagged the GDPR implications of downloading full company datasets just to answer a targeted question.
After downloading a report, what do you typically do with it?
71% were opening reports in Excel and doing significant data manipulation before they were usable. The export was a starting point, not an answer — which meant BrightHR wasn't actually saving anyone time.
Which single improvement would save you the most time?
Selecting your own fields was the most-requested capability by a significant margin. Saved templates came second — pointing strongly toward a builder model with persistent, reusable configurations.
Representative responses from the open-text field.
"Right now to check one employee's attendance record I have to run a report for the whole company, download it, filter and sort it. You should be able to select the employee you want."
"When running an absence report for one individual, having to include all subordinates too is inefficient and probably breaches GDPR. The absence report should be filtered by employee."
"I want to generate an absence report for sickness over the past 4 weeks and also their total absence over 12 months. Currently I have to populate two separate reports and then combine them myself."
"Filter options for customising reports and creating templates. It would be helpful to select the specific fields of data you want before exporting, and save it as a standard template for next month. At the moment Bright HR is not saving us time as the spreadsheet previously created."
"I would like the ability to subscribe to a report so that I am emailed it automatically. This would save myself and my colleagues a lot of time."
Key Insights
Artifacts
To move beyond the numbers, I ran moderated interviews with BrightHR customer advocates. Participants were recruited via the internal Advocates Programme, with sessions self-scheduled through Calendly across two weeks in November 2022. I selected people from different business sizes, industries, and HR functions deliberately. The survey told us what people wanted. The interviews told us why it mattered to them.
Key Findings
Sarah
Receptionist, GP Surgery
I'd like the sickness report to include the dates of each instance of sickness. It is very useful when submitting the information to the NHS.
Mark
Operations Director, Logistics (260 staff)
My managers are chasing me for data every week. I become the bottleneck because I'm the only one who can run the report.
Priya
Business Owner, Professional Services (28 staff)
I run the same absence report every month for our accountant. I rebuild it from scratch every single time.
Claire
HR Business Partner, Manufacturing (510 staff)
Pulling a full employee export to answer a question about five people isn't just inefficient — it's a GDPR risk.
In January 2023, I moved into a prototyping and validation phase.
Using my own coding skills in HTML, Tailwind, and JavaScript, I scaffolded a lightweight prototype that simulated the core reporting experience using mocked datasets. The prototype allowed users to select data fields, apply basic filters, and see how the reporting system would behave.
Although the dataset was limited, this prototype demonstrated the speed and responsiveness of the reporting concept and allowed customers to experiment with filtering and field selection in a realistic environment.
To validate the design further, I wrote a secondary research plan focused on testing key assumptions we had recorded in Jira.
Two forms of testing were conducted:
This testing allowed us to close the loop on several design assumptions and confirm that users understood the mental model of building reports from selectable data fields.
Alongside this, I collaborated with engineering to map data relationships across the platform, and ran card sorting sessions to group the available HR data fields into logical categories. Those sessions directly shaped the information architecture of the report builder.
I designed a custom report builder that allowed customers to construct reports dynamically rather than relying on fixed outputs.
The feature launched on 16 June 2023 in the UK, with Ireland, Canada, and ANZ following on 23 June 2023, completing the rollout across BrightHR's core international markets.
Users could select exactly which data fields to include in their report, effectively constructing their own dataset from BrightHR's employee and operational data. As reporting requirements evolved, additional fields could be layered onto the dataset without needing to rebuild from scratch.
A live report preview updated as users added fields or applied filters. Customers could iterate quickly, refine the dataset, and validate the structure before generating or downloading.
Reports could now be filtered by specific employees, teams, absence types, and custom date ranges -- directly addressing the most common requests identified during discovery.
Once configured, reports could be saved as templates. Customers who regularly generated the same operational reports could quickly regenerate them without rebuilding the dataset each time.
An additional benefit of introducing the new reporting engine was that we were able to retire the legacy reporting templates.
The previous fixed reports were effectively rebuilt using the new reporting system and provided as ready-to-use templates. Customers could use these as a starting point and then customise them further by adding fields, filters, or additional data columns.
This allowed the platform to support both quick access to common reports and fully flexible custom reporting, while simplifying the overall reporting architecture.
To support this level of flexibility and responsiveness, the reporting system was powered by a GraphQL query API operating against a replicated production database.
Running reporting queries against a replicated dataset ensured that generating reports would not impact the performance of the core application or other parts of the platform.
This architecture allowed customers to explore large datasets interactively while maintaining system stability across the wider product ecosystem.
The initial release was never the end point. The first version of custom reporting solved the core problem well, but there were obvious ways to extend what the feature could do once real usage patterns started to emerge.
On 17 August 2023, we shipped Calculated Fields (Part 1) across all territories. Instead of just surfacing raw data values, the reporting system could now perform computations directly in the report: absence occurrence counts, total shift and break durations from Blip (our time and attendance product), and proof-of-purchase receipt totals. That shifted reporting from a data retrieval tool into something more analytical.
On 5 October 2023, we added the ability to reorder fields within custom reports.
Small on the surface. But field order matters when a report is heading to a line manager or being shared outside the platform. Since launch, users had been doing that restructuring work downstream in Excel. The reordering feature meant what came out of BrightHR was already in the right shape for whoever was receiving it.
While Calculated Fields was in development, I started scoping what felt like the natural next evolution for custom reporting: automated scheduling and delivery.
The premise was simple. If a user was already running the same absence report every Monday morning, why require them to do it manually each time? A scheduling mechanism would remove that overhead entirely, delivering the right data to the right people automatically.
We already had existing feedback pointing to demand for something like this. But feedback is not the same as requirements.
In August 2023, I wrote a formal research plan and designed an unmoderated user survey to gather the specifics before any design work began. The survey targeted admins and managers across all BrightHR territories who were already using custom reporting, putting the questions in front of people who had a formed view of what the feature was missing.
The research was built around five questions:
Two working assumptions also needed validating: that notification via email and in-app was the right delivery mechanism, and that generated report artefacts would be stored in Azure Blob Storage.
The survey ran for approximately one week, with a link placed directly on the reports page to reach users at the exact point they would encounter this friction.
The feature saw strong adoption following its release.
User behaviour also validated the core design decisions behind the reporting builder. There were over 225,000 interactions with the "Add fields" function, demonstrating that customers were actively constructing custom datasets rather than relying solely on pre-configured reports.
Adoption was strongest in the United Kingdom, which generated approximately 2 million reporting events. Significant usage was also observed across Australia (166K events), Canada (136K), Ireland (127K), and New Zealand (16K).
Across the dataset, the average user triggered approximately 50 reporting interactions, indicating that reporting had become a repeat operational workflow rather than a one-off task.
BrightHR Customer
Love the custom reporting! Saving me time and providing me with the exact information I need.
Why It Was Challenging
This was one of the most complex design challenges I've worked on because it required solving problems across multiple layers.
It was fundamentally a data modelling problem, not just an interface problem. The reporting system needed to reflect complex relationships between HR datasets in a way that remained intuitive.
The system had to be accessible to non-technical HR users, many of whom had limited experience working with structured data.
Designing an experience that provided power without complexity was the core challenge. Too much flexibility overwhelms. Too little recreates the problem you set out to solve.
Signing off!
If I were revisiting this feature today, there are several ways I would extend the reporting system to make it even more powerful and accessible.
Allow users to generate reports simply by asking questions. Show me sickness absence for warehouse staff in the last six months. The system interprets the query, applies the relevant filters, selects the appropriate data fields, and generates the report automatically.
AI could generate suggested report templates based on common HR workflows or usage patterns within the platform, giving new users a head start without overwhelming them with an empty canvas.
Customers could pin live reporting tiles to a dashboard, monitoring absence trends, upcoming probation reviews, expiring right-to-work documents, and team-level attendance metrics at a glance. This would shift reporting from a static export workflow to a continuous insight experience.
This project is password-protected. Enter the password to view.