Explore raw product data with filters, saved views, dimensions, and enough context to move from question to evidence quickly. The screen connects Explore and Sources so product analysts can find the “Run query” action while checking rows scanned and queries.
Use this reference when you need to design this workflow inside an existing product. The example includes practical records such as workspace_id · 98% filled and plan_type · 100% filled, rather than an empty visual shell.

Analytics
Run query
Analytics
Default, loading, empty, error, permission, success
Adaptable product UI theme
Product analysts need a clear “Run query” action without losing sight of rows scanned, queries and the affected records. Keep the decision and its outcome clear before moving to the next task.
Explore → Sources → Run query → Review outcome
Analytics, Explore, Sources, Queries, accessible states, contextual actions
Make time ranges, filters and metric units clear. Show the data behind each trend so readers can test what changed.
In this design, people should be able to compare workspace_id · 98% filled with plan_type · 100% filled. Make rows scanned clear, then use queries 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 “Run query” action. The happy path alone is not enough.
Related UI examples: Reporting Builder, Metrics Catalog, Experimentation.
Design a data explorer screen for our existing software product. Use our real design-system tokens, components and product language. Show Explore and Sources, include believable records such as workspace_id · 98% filled, and make run query easy to find. Map loading, empty, failure, permission and success states before you create editable high-fidelity screens.