Reporting Builder

Assemble a reusable report by choosing metrics, dimensions, filters, ownership, and sharing rules before publishing it. The screen connects Builder and Metrics so product analysts can find the “Build report” action while checking widgets and metrics.

Use this reference when you need to design this workflow inside an existing product. The example includes practical records such as Active users by plan and Activation by source, rather than an empty visual shell.

Reporting Builder
Use this template in Figr

Template facts

Screen

Form

Primary action

Build report

Pattern

Form

State

Default, loading, empty, error, permission, success

Design system

Adaptable product UI theme

What this screen helps users do

Product analysts need a clear “Build report” action without losing sight of widgets, metrics and the affected records. Keep the decision and its outcome clear before moving to the next task.

Key elements

  • Primary action: Build report is clearly available where the task happens.
  • Main view: Builder keeps the starting point obvious.
  • Connected view: Metrics supplies nearby context.
  • Metric: Widgets is visible with a meaningful value.
  • Another signal: Metrics helps people judge what to do next.
  • Representative record: Active users by plan makes the example specific.
  • Second record: Activation by source shows the pattern works beyond one item.

States worth designing

  • Missing required details; show what people can do instead of leaving a blank panel.
  • Loading builder without changing the layout unexpectedly.
  • Invalid or conflicting entry; explain the problem and preserve work.
  • Permission denied for metrics; clarify who can continue.
  • Success after choosing Build report; confirm the result and the next step.
  • Network or data refresh failure; offer a retry without losing context.

Where this screen sits in the flow

Builder → Metrics → Build report → Review outcome

Patterns used

Form, Builder, Metrics, Dimensions, accessible states, contextual actions

Why these choices work

Put requirements beside each field and show validation near the source of the error. Keep entered details if saving fails.

In this design, people should be able to compare Active users by plan with Activation by source. Make widgets clear, then use metrics to explain whether the next step needs attention.

Before handing this to a designer or engineer, check keyboard focus, error copy, permissions and what happens after they choose the “Build report” action. The happy path alone is not enough.

Related UI examples: Experimentation, Data Explorer, Retention Cohorts.

Start from this in Figr

Design a reporting builder screen for our existing software product. Use our real design-system tokens, components and product language. Show Builder and Metrics, include believable records such as Active users by plan, and make build report easy to find. Map loading, empty, failure, permission and success states before you create editable high-fidelity screens.

Open Figr