We’re rolling out a new UI with a pipelines-centric dashboard, an improved jobs details page, and an updated configuration view for easy debugging. Opt-in to try out the new UI now, before it goes live for all users in spring 2020!
Over the last year, our team has overhauled our frontend with the help of extensive user feedback. By this spring, we plan to have all users on our new UI.
As we built the new UI, we consistently asked ourselves, “what is the Job to Be Done here?” Or, what are our users’ goals and how can we help them achieve those goals?
In pursuit of answers, we conducted nearly 100 interviews, read 12,174 in-app survey responses (and counting), engaged with a number of CircleCI Discuss posts and tweets, and put our MVP-alternative approach, WAFL– Well Architected, Functionally Limited, to the test.
What follows is an overview of the major areas of change in the new UI and an explanation of the thought processes behind them.
Why are we rebuilding the UI?
The old UI was designed for the jobs-based world and container-based usage model of CircleCI 1.0. The navigation between the various levels of run hierarchy were confusing to many users.
But perhaps more importantly, our codebase had gone through so many generations of developers and frameworks that it was becoming difficult to iterate at a high velocity. Making even minor changes required an outsized amount of time.
So, we formed a team to start fresh on both our user experience and codebase architecture simultaneously.
What are the major changes to the UI?
The main Job to Be Done for CircleCI users is to locate and fix errors in their application, with a related Job to Be Done to enable every good, validated change to be shipped to users seamlessly. These are a big, broad objectives, and we could only address them by breaking each down into specific functional jobs (the practical requirements on the way to the main job), all while working within the constraints of our backend and APIs.
To better support our user’s most common goals in our app, we’ve made three major improvements to the UI.
1. Created a pipelines-centric dashboard
For users that interact with the CircleCI dashboard, the three most common goals are to:
1. Navigate from a specific CircleCI job to the most recent run of that same job.
2. Navigate from a failed run to the most recent passing pipeline run.
3. Get a quick gut-check understanding of whether the project at hand is healthy or not.
Our former jobs-centric dashboard created unnecessary problems when users tried to accomplish these three goals.
For instance, if you had 20 jobs in a workflow and other users in your organization were constantly running their own jobs, runs would get spread out quickly and it would become hard to find the exact job (within the exact run) that you were looking for.
It was also hard to scan for whether the project was healthy. Say, for example, that 9/10 jobs in each run were passing. In the old UI, it may have looked like a mostly healthy project if you glanced at the dashboard, when in fact every pipeline (the envelope around those jobs) might have been failing.
Our new UI embraces a pipelines-centric dashboard instead. A pipeline represents the entire configuration that is run when you trigger work on a project, which could include multiple jobs contained in multiple workflows.
With all the jobs in a single pipeline packaged together, it’s easier to navigate to your most recent run or most recent passing run. It’s also easier to scan for whether most runs are passing or failing within a project.
2. Designed a more efficient Job Details page
A core goal for almost all of our users is to figure out why a specific job is failing and fix it. To do this, users typically navigate directly to the Job Details page to figure out what went wrong.
As we designed the new UI, we wanted to make it easier for users to read the step output or test summary of a job to better identify the source of error. Here are some of the ways we’ve made it easier to find and fix errors from the Job Details page:
- Moved the STDOUT or test output further up the page. We’ve reduced the screen real estate at the top of the page before the STDOUT, which is frequently the only information users need to see to identify the source of an error.
- Removed less relevant and scarcely used information. This includes queue time, the parameters tab, the timing tab, the banners at the top of the page, and more. While a limited number of users found that information important, the vast majority did not.
- Made the STDOUT box jump to the bottom of the output. Most of the time, the information the users need is at the end or near end of the STDOUT. This helps them get to it faster.
- Included a limit on screen height for long STDOUT boxes. Previously, we noticed that during observed user sessions, some users would go so deep into the a STDOUT that they would forget which step they were working on. Limiting the height of the STDOUT loads the page faster and helps keep the page more manageable.
- Highlighted Bash commands and error codes. Bash commands and error codes can now be found in a small grey box to help users distinguish it quickly.
- Added a pop-out tab to view the STDOUT full-screen. This helps users scan with no distractions and easily link to the failing step when sharing with others.
- Added rerun-from-failed to the Job Details page. Whereas before users could only rerun the entire workflow from the Job page, they can now rerun a workflow from the job that failed.
- Set the selection tool default to only show failed parallel runs. Users rarely looked at passing parallel runs, so we decided to make the selection tool only show failed parallel runs by default, to help users find the information that they’re looking for faster.
- Unnested artifacts from folders. We watched many users click through multiple folders to get to a single artifact, sometimes forgetting which artifact they needed by the time they clicked through all of it. Developers love CNTL+F, and by unnesting the artifacts we empower them to use it directly.
3. Rebuilt the configuration view for debugging
We identified two main user goals on the configuration tab in the old UI:
- The primary user goal on the configuration tab is to compare the most recent passing run with the most recent failed run to identify changes and debug an error. This is typically done from the pipelines list.
- The secondary user goal is to create a mental map between the config and the output, and compare expected outcomes with real outcomes to debug an error. This is best done from the Job Details page.
Because users depend on two different locations to accomplish these goals, we’ve changed the configuration from a tab on the Job Details page to a full-screen, module-like view that can be opened from any level in the new UI. In the future, we’d also like a “compare configs” functionality to jump to fixing these errors more directly.
Also of note: Users almost always debug via the source config (what you write) and rarely the compiled config (post-processing).
And yet, the Job Details page previously showed the compiled configuration first and the source config underneath, greyed-out. We changed this up entirely in the new UI. Now, in the pop-out configuration page, there are two buttons up top to change your view from source to compiled, with source set as the default. This helps users easily view the most relevant information and also view their source and compiled config without scrolling.
Ready to opt in?
Over the next couple of months we will be incrementally rolling out the new UI to all of our users.
We encourage you to opt-in to test the new UI and share your feedback with us throughout this process.
You can opt-in to the new UI by navigating to the Job Details page of any pipelines-processing-enabled project and clicking on this banner at the top of the page: