Turning "you can only run the reports we built" into build your own, on any object.
A self-serve custom report builder for a bankruptcy case management platform - letting business users construct reports across any object and its relationships, without a single line of SQL or a ticket to engineering.
Product Owner & Lead Designer
Requirementd
None given - defined in-flight
Fintech
12 Weeks
Overview
No spec. No backlog ticket. Just a gap everyone felt.
Business users across sales, fulfillment, and finance - the people working with orders, accounts, vendors, and payments day to day - could only see the data through a fixed set of pre-built reports. Anything outside that set meant a request to engineering and a wait. There was no requirements document for a fix; there was only the shape of the problem and a mandate to solve it. As both product owner and designer, I owned defining what we'd build as much as how it should work.
16
iterations, each one a negotiation with the business on scope and logic
01
builder, generalized to work against any object in the platform
03
step flow: Entities, Fields & Filters, Preview
Discovery
Design as the requirements-gathering tool.
With nothing handed down, wireframes became the way to ask questions the business hadn't thought to answer yet: what happens if someone changes their mind about the primary entity after they've already built out relationships? How many custom calculations is too many? What does a nested filter even mean to someone who isn't a query writer? Sixteen iterations were the record of that back-and-forth.
Map the data model, not the screens
Started by cataloguing the objects and relationships that actually exist in the platform's data - the report builder had to be generic enough to work against all of them, not just the obvious ones.
Wireframe the ambiguous parts first
nstead of starting with the happy path, early rounds focused on the edge cases - changing a primary object mid-build, removing a calculation, combining filters -because those were where stakeholders disagreed.
Review, redraw, repeat
Each of the 16 versions closed a specific open question with the business rather than polishing visuals - logic first, layout second.
Converge on a 3-step structure
What started as a single dense screen was decomposed into Objects & Relationships → Fields, Filters & Layouts → Preview & Save - a sequence that matches how a non-technical user actually thinks about building a report.
Step 01
Entities & Relationships
Every report starts with a primary entity - an order, an account, a vendor - and can pull in up to five connected secondary entities to bring in related data. The hard design problem wasn't the happy path; it was keeping the model consistent when a user backtracks, and giving non-technical users real control over how entities relate to each other.
Primary entity selection scopes which secondary entities are even valid to connect
Each secondary entity chooses how it joins - All Records, Matching Records, or Everything from Both - plain-language stand-ins for a left, inner, or full join
Explicit handling for changing the primary entity after relationships already exist
Edge Case
Swapping the primary entity after secondary entities are already attached is a destructive action - it can invalidate every relationship built so far. The flow surfaces this clearly, with an explicit confirmation step, rather than silently dropping the user's work.
Why it matters?
This is the kind of case that never shows up in a requirements doc, because no one thinks to write it down until a user does it by accident. Catching it took direct observation and iteration, not a spec.
Step 02
Fields, Filters & Layouts
This is where the tool had to earn its keep against a real Business Intelligence product without asking users to think like one. Field selection, custom calculations, filter logic, and layout & subtotal grouping all live in one step - sequenced so each choice narrows the next.
Field picker scoped to whatever entities were chosen in step one, with select-all / unselect-all for long field lists
Up to three custom calculations per report, with inline validation before they're usable downstream
Filters support nested groups - AND/OR logic a business user can build without knowing what a boolean is
Layout & subtotal controls to group and roll up results without a spreadsheet round-trip
Step 03
Layout, Preview & Save
Subtotal grouping happens right before preview, so a user sees the shape their choices produce before committing. The preview renders as a real spreadsheet-style grid - rows, columns, and computed fields exactly as they'll appear once saved - so there's no gap between what's configured and what's delivered.
Reflection
Being product owner and designer on the same project meant the hardest part wasn't drawing the screens - it was deciding what the product even was.
With no requirements to inherit, the 16 iterations weren't revisions of a known target - they were the process of finding it, one stakeholder conversation at a time. The result generalizes across every entity in the platform rather than solving one team's report request, which is the difference between a feature and a capability.
A Note on Language
The terms in this write-up are deliberately genericized.
To keep the underlying product confidential, the vocabulary shown here - entities, workspaces, relationships - stands in for the domain-specific language actually used in production. The interaction design and decisions described are unchanged; only the labels are abstracted.
Entity
A record type in the system - what step one lets you pick as the report's foundation
Primary Entity
The main record type a report is built around
Secondary Entity
A related record type joined in to bring in connected data
Workspace
The case a report is saved and scoped within