Liz Young
← Selected work
01 / Trek Health · Price IntelligenceProduct architecture · 0→1

Five reports.
One analytical language.

At Trek’s Austin product offsite, I proposed consolidating several overlapping Price Intelligence reports into one flexible analysis model. I then shaped the architecture and interaction system that made that direction usable.

Role
Product Designer
Contribution
Original proposal · Product model · UX/UI
Team
Product, design, and engineering
Status
Internal testing before my departure
Pivot interface reconstructed from a supplied final-state screen. Organization, NPIs, and rates are synthetic.
01 / Fragmentation

The product had multiple reports.
The users had one repeated job.

Rate Research, Benchmark Report, Competitor Analysis, and Query Builder looked like separate products. Underneath, they repeatedly asked for the same payer, provider, and billing-code inputs and rearranged much of the same data.

Product research showed the behavioral cost: users tended to learn one report and stay there. Query Builder remained the most-used report, and users often exported its data to Excel or BI tools to reconstruct views the product could not flexibly provide.

Before: each analytical task began as a separate report destination. Saved-report names and account data are synthetic.
The product taught users to choose a report before they could ask a question. Saved-report history is synthetic.
02 / Reframe

I reframed a reporting suite
as one flexible system.

At our Austin product offsite, I proposed consolidating the overlapping reports into one analysis model and explored the direction in Figma. The work that followed turned that proposal into a shared product definition and an end-to-end interaction system.

  1. 01 / Austin offsiteI proposed one system instead of separate reports.

    I mapped how Trek’s overlapping Price Intelligence reports could share one flexible analysis model and explored the idea in Figma.

  2. 02 / Product definitionThe team translated the direction into requirements.

    The product manager documented the shared data model, familiar reports as templates, performance targets, edge cases, and acceptance criteria.

  3. 03 / Product designI made the model understandable and usable.

    I shaped the architecture and UX across scope, templates, the flexible builder, hierarchy, aggregation, filters, hover behavior, and report actions.

03 / Product model

Stop designing reports.
Define what makes a report.

The central shift was to treat each existing report as a remembered configuration of one analytical system. Most users worked within one data scope tied to their organization, so that scope could remain stable while the table changed around the question.

Load the relevant scope once.
Change the question many times.
Before / Destinations
01Rate Research02Benchmark Report03Competitor Analysis04Query Builder
After / Configurations
Define scope onceShared analysis engineTemplates ↔ Custom analysis
01

Scope

Payer · providers · billing codes

One bounded dataset
02

Template

A familiar report configuration

A useful starting point
03

Structure

Rows · columns · filters

The question being asked
04

Measure

Average · median · count

The form of the answer
Surviving Figma notes / workflow transcriptionScope became the stable layer beneath repeated analysis.
  1. 01Pull scope

    Load the selected payer, provider, and billing-code dataset.

  2. 02Create a working table

    Hold one reusable dataset for templates and custom analysis.

  3. 03Build the pivot

    Choose rows, columns, values, and filters; then generate.

  4. 04Keep exploring

    Refine the scope or create another pivot from the loaded data.

The board preserves the developing workflow from scope selection through repeated pivot analysis.

04 / Experience

Opinionated enough to begin.
Flexible enough to continue.

01 / Set the boundary

Choose the organizational scope once.

Payer, provider, and billing-code selections establish the data relevant to an organization. Keeping that scope loaded reduced repeated backend work and let users move between analyses without starting over.

A bounded dataset separates the heavier query from the faster analysis interactions. Added organization and provider details are synthetic.
02 / Start familiar

Make old reports useful without preserving old silos.

Query Builder, Rate Research, Benchmark Report, and Competitor Analysis became starting configurations. A saved custom setup could live beside them.

Templates preserve learned workflows while exposing the shared system beneath them. The account and custom-template name are synthetic.
03 / Shape the question

Let structure communicate intent.

Rows establish hierarchy, columns create comparisons, values define the calculation, and filters narrow the loaded data. The zones use the same visual grammar as the resulting table.

Fields can move directly into the analytical structure. NPIs and rates are synthetic.
Filters refine the loaded dataset without redefining the report. NPIs and values are synthetic.
The configuration remains visible beside the answer so users can understand and revise what they built. Data is synthetic.
05 / Interaction rules

Flexibility only works when
the rules stay legible.

01 / Hierarchy

Order changes the question.

NPI → Billing Code groups services under a provider. Reversing the order answers a different question.

Reconstructed from the documented row-order behavior. Data is synthetic.
02 / Measures

One field can answer several questions.

Average, median, and count can appear together without duplicating the underlying field or dataset.

Reconstructed from the documented multiple-measure behavior. Data is synthetic.
03 / Guardrails

Offer calculations that match the data.

Negotiated Rate supports sum, minimum, maximum, median, average, and count. Identifier fields default to distinct counts.

Reconstructed from the aggregation options in the product specification.
04 / Trust

Make hidden math visible.

A corner marker identifies cells that combine multiple rates. Hover reinforces interactivity without filling a dense table with icons.

Reconstructed from supplied corner-marker and hover references. Data is synthetic.
06 / Complete the loop

A useful analysis should
survive the session.

Save reportScope + configuration

Return to the same data and analytical view.

Save as templateConfiguration only

Reuse the analytical logic with another scope.

DownloadCSV or Excel

Continue the work outside Trek when needed.

Save the current report, create a new report, or preserve the configuration as a template. Reconstructed from supplied menu states.
Export remains available without making it the primary analysis workflow. Reconstructed from supplied menu states.
07 / Outcome

One adaptable system—ready to replace
a family of fixed reports.

At internal testing
  • A shared model connected the core Price Intelligence reports
  • Templates preserved familiar starting points while enabling custom analysis
  • One loaded scope could support multiple questions and saved views
  • Interaction rules covered hierarchy, aggregation, filters, and data confidence
  • Performance, correctness, and usability were defined as measurable criteria
System performance criteria
≤10 sec

Initial medium-complexity data load

1–2 sec

Reaggregation after data is loaded

≤0.1%

Variance against Benchmark output

Internal research in progress
Mixed group

Internal participants brought different levels of product and domain familiarity.

Persona-led

Each participant received a distinct user persona and tested the table from that perspective.

Scenario-based

Tasks examined whether the flexible model supported different analytical goals. Testing had begun when I left.

Conclusion

A flexible system built around
the way analysts actually work.

Most customers analyze rates within a consistent universe of payers, providers, and billing codes tied to their organization. Pivot kept that scope loaded while letting users change the table’s structure, measures, filters, and starting template.

That decision connected user value with backend efficiency. Familiar reports became useful entry points into one system, custom analysis could stay inside Trek, and a single data query could support many views.

By the time I left, the concept had become a coherent product architecture with defined interaction rules, measurable performance criteria, and persona-led internal testing underway.

Next / Scope

Productizing a process without losing the humans inside it.