A self-service reporting tool, designed in two weeks

I joined Behavox in May 2020 and was put straight onto the Report Wizard: a way for customers to generate data exports shaped to their own needs. There was a hard commitment to a specific client and a very tight deadline. Designs had to be final in two weeks.

Until then, the only way to create or change a report, even cosmetically, was to edit the code behind it. Almost no client could do that, so every request went to the internal data insights team. Two things followed. That team spent its time writing custom scripts instead of strategic work, and every request travelled from client to account manager to data insights and all the way back. As the client base grew, this was heading somewhere unsustainable.

I was given a PRD listing the building blocks, derived from the legacy reports. Two report types, Alerts and Reviewers, each with roughly fifteen to twenty data columns and a set of filters for narrowing the dataset. Four explorations followed.

1. The wizard. The name suggested the answer, so I sketched it: guide people one step at a time. Rough sketches exposed the flaw immediately. Splitting the flow into steps separates building the report from seeing it, and adds friction exactly when people want to tinker and preview before saving, which is what everyone does the first several times.

2. Everything on one screen. Fine in rough sketches, overwhelming in hi-fi. Too much at once, and it treated unequal things equally: you name a report once and never think about it again, while choosing columns takes real time.

3. Vertical layout. This combined the two: scannable and guided, but with everything on a single screen, and a collapsible data columns section for smaller displays. It ran into a technical wall. The platform's standard filtering panel could not be reused here, so each filter needed its own select field. Ten of them for Alerts, seven for Reviewers.

4. Converging. Ten selects forced the filters into a vertical stack, so I went back to the second exploration and split it into two tabs, Basic Information and Filters. Stakeholders approved that version for testing.

Usability testing. Client access was extremely hard to get, so I was advised to test with account managers, who work closely with clients and know what they expect from reporting. Any testing beats none. There was no research team at the company then, so I wrote the plan and ran five sessions myself. Tasks: create a report template, reorder and rename columns, delete a template.

What testing changed. Three participants tried to rename columns directly in the table, because Excel taught them that is where renaming lives, so editing and sorting moved into the table headers with drag and drop. Four wanted an AM or PM signifier. The platform used a 24 hour format I could not change, so an info icon gained a tooltip spelling out the time zone and the format.

After implementation, Jira filled up with requests for more and more data columns. Some clients found browsing through chips difficult, and the filters tab was hard to find at all. The design had held for the launch and was now bending under its own success.

Discoverability. I merged the report name and description into the page header, which saved space and let the name default to something sensible, and moved the scheduling parameters into a horizontal strip above the report preview.

Scalability, settled by an A/B test. Two approaches, tested with ten internal users in Maze. A kept the two-tab structure and moved column selection into a tab, which was simpler to build. B moved "Add columns" into the table preview itself, following the pattern people already know from Notion, Google Tables and Excel.

B won clearly. One participant failed the third task in A, and the ease scores were far better for B, 2.1 against 4.0. We shipped B with one change: the filters section expanded by default, since several people could not find it collapsed, while keeping the ability to collapse it.

Spend more time in discovery. I joined at the ideation stage, missed the discovery interviews and had to work from the requirements I was handed. Interviews later surfaced pain points that had never come up.

Test with end users, not internal ones. Testing with internal users is a reasonable quick and dirty option for features that need no subject-matter expertise. Reporting is not one of those features.

• SUS score of 96 with a 100% task success rate, on a design finalized in two weeks.
• The data insights team stopped writing custom report scripts and got that time back for strategic work.
• A second round eight months later, decided by an A/B test with 10 users, made the layout scalable as the number of data columns kept growing.
• Two lessons I still carry: get into discovery earlier, and be honest about when internal testers are not a substitute for real ones.