Jan 2026
Jan 2026
Jan 2026
IBM
Building trust through transparent progress indication
Building trust through transparent progress indication
overview
overview
In order for users to develop trust in IBM Concert, the Developer Quickstart at the beginning has to be honest and accurate in its repository scan progress tracking.
In order for users to develop trust in IBM Concert, the Developer Quickstart at the beginning has to be honest and accurate in its repository scan progress tracking.
In order for users to develop trust in IBM Concert, the Developer Quickstart at the beginning has to be honest and accurate in its repository scan progress tracking.
In order for users to develop trust in IBM Concert, the Developer Quickstart at the beginning has to be honest and accurate in its repository scan progress tracking.
When users first open the product, users upload their repositories for scanning. The system then kicks off a scan process that runs multiple child scans in the background, each of which analyzes a different dimension of the repository at different speeds.
When users first open the product, users upload their repositories for scanning. The system then kicks off a scan process that runs multiple child scans in the background, each of which analyzes a different dimension of the repository at different speeds.
role
UX designer + developer
UX designer + developer
team
UX Lead, PM, Backend engineers, Director
UX Lead, PM, Backend engineers, Director
product
IBM Concert (AI-driven observability platform)
IBM Concert (AI-driven observability platform)
focus
designing progress indicator and working with the backend team to ensure a seamless experience
designing progress indicator and working with the backend team to ensure a seamless experience
problem
problem
The existing experience left users without visibility into scan progress, creating confusion about whether processing was complete. An automatic redirect to the event log implied completion even when scans were still running, while offering no clear direction or way to exit the workflow.
Users were told that the their submission had been completed but there was no visibility into what was actually happening after this.
The original experience goes as follows:
User uploads a repository and submits it for scanning.
The system confirms the submission with a "Your scan has been submitted" message, but the scan is already running in the background.
A "View scan status" button appears after a short delay.
Clicking it, or waiting for an automatic countdown, redirects the user to an event log, where individual child scan statuses could be seen.
design iterations
design iterations
Iteration #1: Flat list of operations per repo
Iteration #1: Flat list of operations per repo
The first approach displayed each repository's scan operations as a flat list in the chat, incrementing numerically as they completed.
The first approach displayed each repository's scan operations as a flat list in the chat, incrementing numerically as they completed.
Problem was cognitive load. Users presented with several expanding lists with no way to gauge overall progress at a glance.
Problem was cognitive load. Users presented with several expanding lists with no way to gauge overall progress at a glance.
PROBLEM: Cognitive load. With multiple repositories processing in parallel, users would be presented with several expanding lists simultaneously, with no way to gauge overall progress at a glance.
Understanding how far along the entire job required mentally adding up numbers.
Iteration #2: The proposed design
Iteration #2: The proposed design
Per-repo progress bars with an overall indicator
The second and decided approach was a two-level structure:
An overarching progress bar at the top showing overall scan completion, with each repo underneath displaying its own progress bar.
The second and decided approach was a two-level structure:
An overarching progress bar at the top showing overall scan completion, with each repo underneath displaying its own progress bar.
The second and final design approach was a two-level structure:
An overarching progress bar at the top showing overall scan completion, with each repo underneath displaying its own progress bar.
backend capability constraints
backend capability constraints
When I began implementing, a core backend constraint surfaced.
Detailed child scan data wasn't available immediately from the backend, making accurate real-time progress tracking difficult to implement.
When I began implementing, a core backend constraint surfaced.
Detailed child scan data wasn't available immediately from the backend, making accurate real-time progress tracking difficult to implement.
The proposed solution was a percentage-based bar that filled intermittently and jumped to 100% once the overall status flipped to complete.
I pushed back on this because scans start and finish at different times, so any number shown mid-process would be an estimate at best and fabricated at worst.
For a first-time user going through the developer quickstart, watching a progress bar jump unexpectedly to 100% doesn't just feel jarring, it breaks trust in the tool at exactly the moment when trust matters most.
The proposed solution was a percentage-based bar that filled intermittently and jumped to 100% once the overall status flipped to complete.
I pushed back on this. Since scans start and finish at different times, any number shown mid-process would be an estimate at best. For a first-time user going through the Developer Quickstart, watching a progress bar jump unexpectedly to 100% doesn't just feel jarring, it breaks trust in the system at the moment when the user's trust matters the most.
impact
impact
This feature shipped as part of IBM Concert's 2.2 release.
For first-time users going through the "Developer Quickstart" experience, the most impactful changes were visibility and control: a process that previously ran invisibly in the background was now clear in real time, and users had an exit path.
The indeterminate-to-determinate indicator also established an honest baseline for the team to build on. As backend capabilities mature and more real-time scan data becomes available, the experience can evolve incrementally, without needing to adapt to a misleading pattern.
This feature shipped as part of IBM Concert's 2.2 release.
For first-time users going through the "Developer Quickstart" experience, the most impactful changes were visibility and control: a process that previously ran invisibly in the background was now clear in real time, and users had an exit path.
The indeterminate-to-determinate indicator also established an honest baseline for the team to build on. As backend capabilities mature and more real-time scan data becomes available, the experience can evolve incrementally, without needing to adapt to a misleading pattern.
Kavya Verma
Contact
kavya.verma@gmail.com
Kavya Verma
Contact
kavya.verma@gmail.com
Kavya Verma
Contact
kavya.verma@gmail.com