Designing an Interactive Validation Report

Overview

A validation session generates far more than a recording.

Metricon captures screenshots, performance data, application logs, user notes, marked moments, and session metadata. The challenge was to turn that collection of technical data into something people could actually investigate, understand, and share.

Instead of designing a static report, I treated the report as an interactive SaaS workspace.

Users can explore the session, change what data is visible, zoom into specific moments, correlate telemetry with screenshots and notes, edit evidence, and move from broad session context to detailed technical information without leaving the report.

The report is not the final output of the testing process.

It is the workspace where the evidence is interpreted.

The Challenge

The original reporting experience exposed a large amount of useful information, but it behaved primarily like a diagnostic dashboard.

Performance results, screenshots, metrics, annotations, and logs were presented simultaneously.

This created a common problem:

The product collected a lot of evidence, but users still had to figure out where to look.

The redesign focused on creating a clear analytical progression:

What happened?
↓
How did it perform?
↓
Where should I look?
↓
What evidence supports it?

This required more than visual cleanup. The underlying interaction model had to change.

From Static Report to Interactive Workspace

The new report is structured as a progressive exploration of the session.

Session context

The report starts with the essential context:

• tested device,
• application,
• person who recorded the session,
• date and time,
• duration,
• session ID,
• captured data,
• report state,
• storage location.

A separate diagnostics summary immediately highlights signals worth investigating, such as warnings, errors, telemetry anomalies, marked moments, notes, and captured log events.

The first level answers:

What happened during this session?

Performance Results

Performance is one of the central reasons for running the validation session, so FPS analysis remains visible at a high level.

The Performance Results section combines:

• measured FPS,
• expected thresholds,
• average,
• median,
• minimum,
• maximum,
• a visual comparison chart.

The expected values can be edited directly from the table by hovering over the relevant cell.

This keeps configuration close to the data it affects instead of hiding it behind a separate settings screen.

The result is both analytical and interactive:

Measured performance → expected threshold → visual comparison

Dynamic Metrics Summary

The report also preserves the statistical summary of the collected telemetry.

The table contains:

• Average,
• Median,
• Minimum,
• Maximum,
• Last value.

Metrics include values such as:

• FPS,
• System CPU,
• App Memory,
• System Memory.

The important change is that this summary is context-aware.

When the user selects a specific range of the telemetry timeline, the summary can be interpreted in relation to that selected period rather than only the entire session.

This creates a direct relationship between:

Chart selection → calculated summary → detailed investigation

Screenshot Timeline

Screenshots are treated as evidence rather than decorative previews.

The Screenshot Timeline gives users a visual overview of the recorded session.

Users can:

• resize thumbnail previews,
• click a screenshot to navigate to its timestamp,
• identify screenshots associated with notes or marked moments,
• open screenshots in a lightbox for detailed inspection.

The thumbnails therefore act as both visual evidence and navigation controls.

Instead of searching through a long recording chronologically, users can visually locate the state of the application they want to investigate.

Telemetry Timeline

The Telemetry Timeline is the core analytical interaction.

It synchronizes technical measurements along a shared time axis.

Depending on the selected data layers, users can compare signals such as:

• FPS,
• battery temperature,
• system CPU,
• system memory,
• app memory,
• graphic memory,
• Java heap memory,
• native heap memory,
• code memory,
• stack memory,
• other memory.

Rather than displaying every possible metric by default, the interface provides a Data Layers control.

Users can turn individual layers on and off using interactive chips.

This keeps a potentially complex telemetry environment manageable without reducing the depth of the underlying data.

Data Layers as an Interactive Filter

The Data Layers panel works as a visibility control rather than a static legend.

Each layer is represented by a selectable chip with a persistent color identity.

Clicking a chip:

activates the layer

Clicking it again:

hides the layer

The color remains consistent whether the layer is active or inactive, allowing users to build a stable visual mental model of the data.

This becomes particularly valuable as the number of telemetry streams grows.

The product can therefore expose technical depth without forcing all of it into a single view.

Exploring Time Instead of Choosing a Fixed Window

The original interface relied on predefined time-window controls.

The redesign removes that constraint.

Users can select a range directly on the timeline.

Selecting a region allows them to:

• inspect a specific part of the session,
• zoom into that period,
• compare metrics within the selected range,
• reset the view when finished.

This interaction is more natural for investigative work because the user does not have to predict the appropriate window in advance.

Instead:

Find something interesting → select it → investigate it.

Trim as a Separate Operation

Selection and trimming are intentionally different actions.

Selecting a range is an exploratory interaction.

Trim changes the portion of the session retained for reporting.

This distinction is important because a user may want to inspect a section without modifying the session itself.

When trimming, Metricon shows the selected range and lets the user explicitly confirm the operation.

This provides flexibility without turning exploratory analysis into a destructive interaction.

Session Notes and Marked Moments

The report introduces a lightweight evidence system for tester observations.

Mark moment

A marked moment is deliberately fast.

One click creates a timestamped marker on the session timeline.

No form.
No interruption.
No required description.

The goal is simply:

Don't lose this moment.

Notes

A note can be attached to a moment when additional context is useful.

Notes can be created, edited, deleted, and moved to another point on the timeline.

A marked moment can also receive a note later.

This creates two complementary levels of evidence:

Marked moment → something important happened here.
Note → this is what I observed about it.

Session Notes Panel

The Session Notes panel is a persistent side workspace that can be opened independently of the telemetry controls.

It covers evidence from the whole report, not just one chart.

Users can filter the panel by:

• All,
• Notes,
• Marked moments.

They can also:

• edit notes,
• remove notes,
• move notes to another timestamp,
• open the related point on the timeline.

The timeline and notes panel therefore work as a synchronized system.

Selecting a note can move the user directly to the corresponding moment in the recorded session.

Interactive Evidence Correlation

The key interaction principle across the report is synchronization.

A timestamp is not an isolated piece of information.

A single moment can connect:

Screenshot
+
Marked moment
+
Note
+
Telemetry
+
Logs

This allows users to move from:

“Something happened here.”

to:

“This is what the application looked like, these were the performance values, and these logs were recorded at the same moment.”

That relationship is what transforms the report from a collection of charts into an analytical workspace.

Logs

Logs are intentionally placed at the end of the report.

They represent the deepest technical level of investigation and are therefore not allowed to dominate the initial experience.

The log table focuses on three essential fields:

Users can filter log levels and correlate entries with the selected point in the timeline.

This creates a deliberate progression:

Summary → Performance → Evidence → Logs

rather than showing every diagnostic detail at once.

SaaS Product Characteristics

The report is designed as part of a broader SaaS workspace rather than as a static exported document.

Persistent report identity

Every report has an editable name and a consistent location within the product hierarchy.

Users can organize reports into Projects without changing the underlying report functionality.

Local and cloud states

Reports can exist as:

Local only

or

Synced to Control Hub

The storage state is visible directly in the report header.

Collaboration

The Share action is context-aware.

A local report can be synchronized to Control Hub as part of the sharing flow. Once synchronized, the same report can be shared with other users through the Hub.

This keeps the user's goal—sharing the report—more important than the underlying infrastructure step.

Persistent workspace

The report is not simply consumed once.

Users can return to it, rename it, move it between Projects, edit notes, inspect different data layers, explore different time ranges, and share the resulting analysis.

That persistence is a core SaaS characteristic.

Information Architecture

The final report follows a deliberate depth model:

What happened?

Session details
Diagnostics summary

How did it perform?

Performance Results
Metrics Summary

Where should I look?

Screenshot Timeline
Telemetry Timeline

What evidence supports it?

Notes
Marked moments
Telemetry
Logs

This hierarchy allows technical depth without exposing every layer of complexity at the same time.

Design Principles

Progressive disclosure

Advanced telemetry and technical details remain available, but they do not compete with the primary information.

Evidence over decoration

Screenshots, markers, notes, metrics, and logs are connected through a shared timeline so that each piece of information has contextual meaning.

Direct manipulation

Users interact directly with the data:

• click screenshots,
• select ranges,
• zoom,
• trim,
• toggle data layers,
• add markers,
• edit notes.

Context preservation

The user does not need to move between unrelated screens to understand a single event. The report keeps the evidence synchronized within one workspace.

Analysis without overload

The interface exposes depth progressively rather than presenting the entire diagnostic system simultaneously.

Outcome

The redesign turns the Metricon report from a static result page into an interactive investigation environment.

Instead of simply answering:

“What happened?”

the report supports the entire analytical journey:

What happened?
→ session and diagnostics

How did it perform?
→ performance and metrics

Where should I look?
→ screenshots and timeline

What evidence supports it?
→ synchronized telemetry, notes, markers, and logs

The result is a SaaS report that behaves less like a document and more like a persistent product workspace—one where evidence can be explored, reorganized, enriched, and shared.

The report is not where the testing process ends. It is where the evidence becomes useful.

© Zofia Szuca 2024
Brand and product designer

LinkedIn - Dribble - Behance

Privacy Policy | Terms of Service