Jan 2026
Jan 2026
Jan 2026
IBM
Repository Scan Progress Indicator
overview
overview
A progress tracking experience for IBM Concert's Developer Quickstart to give users real-time visibility into their repository scans as they run in the background.
A progress tracking experience for IBM Concert's Developer Quickstart to give users real-time visibility into their repository scans as they run in the background.
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 backend to ensure a seamless experience
designing progress indicator and working with backend to ensure a seamless experience
what is the "Developer Quickstart" experience?
what is the "Developer Quickstart" experience?
what is the "Developer Quickstart" experience?
In the "Developer Quickstart" experience for IBM Concert, first-time users can upload their repositories.
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.
In the "Developer Quickstart" experience for IBM Concert, first-time users can upload their repositories.
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.
In the "Developer Quickstart" experience for IBM Concert, first-time users can upload their repositories.
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.
problem
problem
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.
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.
what are the issues with this process?
what are the issues with this process?
The director flagged this after going through the Developer Quickstart herself and raised a task for this. To see the problem, I ran the flow from the perspective of a first-time user and documented where it broke down, then walked the existing experience through with our UX architect to display what I'd found before starting the redesign.
The three main issues were:
no sense of progress
no sense of progress
Users were told that their submission had been completed but there was no visibility into what was actually happening after this.
Users were told that their submission had been completed but there was no visibility into what was actually happening after this.
Users were told that the their submission had been completed but there was no visibility into what was actually happening after this.
misleading automatic redirect
misleading automatic redirect
The automatic countdown before the redirect implied that the scan was done.
Instead the users were redirected to the event log with some scans still in progress and others completed, and with no further direction.
The automatic countdown before the redirect implied that the scan was done.
Instead the users were redirected to the event log with some scans still in progress and others completed, and with no further direction.
no exit
no exit
Users also had no way to exit the developer quickstart mid-flow.
Users also had no way to exit the developer quickstart mid-flow.
scoping the design
scoping the design
Would this replace the existing "View scan status" button?
Yes. It would be replaced by an exit button, giving users the option to leave the Developer Quickstart and return to the homepage while scans continue in the background.
Would there be an overarching progress indicator alongside per-repo progress?
Initially yes: the idea was a top-level indicator showing overall progress, with each repo showing its own progress, something like "3/10 operations complete" beneath it.
This constraint became the central design problem, and shaped the decision to move away from determinate progress entirely.
Would this replace the existing "View scan status" button?
Yes. It would be replaced by an exit button, giving users the option to leave the Developer Quickstart and return to the homepage while scans continue in the background.
Would there be an overarching progress indicator alongside per-repo progress?
Initially yes: the idea was a top-level indicator showing overall progress, with each repo showing its own progress, something like "3/10 operations complete" beneath it.
This constraint became the central design problem, and shaped the decision to move away from determinate progress entirely.
design iterations
design iterations
The design went through two distinct structural approaches before landing on the right pattern. Throughout these iterations, it was assumed that the backend capability was working as it should and the data was fetched as soon as the scan was submitted.
The design went through two distinct structural approaches before landing on the right pattern. Throughout these iterations, it was assumed that the backend capability was working as it should and the data was fetched as soon as the scan was submitted.
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.
For example, "3/10 operations done", with child events shown inline beneath each repo.
The first approach displayed each repository's scan operations as a flat list in the chat, incrementing numerically as they completed.
For example, "3/10 operations done", with child events shown inline beneath each repo.
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.
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.
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.
This design solved these issues:
Users had a high-level answer to "how far along is this scan?" without needing to go through individual repo details
Parallel bars correctly implied processing was happening at the same time rather than sequentially.
This became the structural foundation moving forward, though a technical constraint would later shift how the progress bars themselves behaved.
This design solved these issues:
Users had a high-level answer to "how far along is this scan?" without needing to go through individual repo details
Parallel bars correctly implied processing was happening at the same time rather than sequentially.
This became the structural foundation moving forward, though a technical constraint would later shift how the progress bars themselves behaved.
With the approach confirmed, I moved into implementing this in the interface.
With the approach confirmed, I moved into implementing this in the interface.
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 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.
I proposed a third and final design iteration that solved the problem within the constraint rather than worked against it:
While child scan data is being fetched: display an indeterminate progress bar that communicates that work is happening without implying a specific completion point
Once data becomes available: display a determinate progress bar that shows actual state (number of operations completed out of the total), only resolving to 100% when all child scans reach completion
I proposed a third and final design iteration that solved the problem within the constraint rather than worked against it:
While child scan data is being fetched: display an indeterminate progress bar that communicates that work is happening without implying a specific completion point
Once data becomes available: display a determinate progress bar that shows actual state (number of operations completed out of the total), only resolving to 100% when all child scans reach completion
I proposed a the third and final design iteration that solved the problem within the constraint rather than worked against it:
While child scan data is being fetched, display an indeterminate progress bar that communicates that work is happening without implying a specific completion point
Once data becomes available, display a determinate progress bar that shows actual state (number of operations completed out of the total), only resolving to 100% when all child scans reach completion
exiting from the experience
exiting from the experience
There was a side effect of the indeterminate progress bar:
Because the backend took a while to fetch child scan data, users would find themselves waiting for a period of time before the progress bar converted to a determinate one, all without a way to leave.
A "Go to developer focus" button that let users exit the quickstart without waiting for scans to complete.
Underneath it would be a subtext that would clearly state that the scans would continue to run in the background and that the user would be notified once all of them were complete / if any had failed.
There was a side effect of the indeterminate progress bar:
Because the backend took a while to fetch child scan data, users would find themselves waiting for a period of time before the progress bar converted to a determinate one, all without a way to leave.
A "Go to developer focus" button that let users exit the quickstart without waiting for scans to complete.
Underneath it would be a subtext that would clearly state that the scans would continue to run in the background and that the user would be notified once all of them were complete / if any had failed.
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