CircleCI redesign
Redesign of a platform for continuous integration and delivery
CircleCI V1
CircleCI UI was created with jobs in mind.
Jobs were originally virtual machines with CPU and memory and they run Linux commands.
UI was tweaked to include different kinds of executors such as mac and windows. Introduced are workflows as envelopes for jobs.
The introduction of pipelines as envelopes for workflows was the place where design reached the point where it was too complex to scale.
In terms of the codebase, CircleCI was a giant monolith with a bunch of html, css, js and closure code. It was extremely hard to add new features and new developers who are familiar with Closure.
Redesign Goals
- Create UI that is going to enable CircleCI to scale product
- Unblock delivery teams by creating a new codebase that developers are going to love and which is going to enable them to add new features quickly
- Focus on speed rather than perfectionism (limitation to using existing API)
Team
- Few product designers changed over time
- Product manager
- Engineering manager
- Several developers
Process
Discovery
Mapping out current product flow
To get a birds-eye view of the product and understand better how and where content and actions connect into the bigger picture I created a map of all pages, their contents and actions.
We used analytics data to figure out primary journeys, how people get to the product, how they navigate and what parts of the product are most used.
The goal was to discover opportunities to simplify and restructure the product.
Jobs to be done
- Developers want to see what failed and fix failure as soon as possible
- Developer experience people want to see what fail in general, improve tooling and process, and optimize pipelines for speed and success
- Engineering managers want to scale projects and teams, plan, optimize and justify costs
Reviewing current design
Opportunities for improvement that we detected:
- Structure
- Hierarchy
- Spacing
- Navigation (top bar and sidebar acted both as primary navigation)
- Combining metadata with actions
- Adding things randomly on pages
- Overuse of fixed position
Wire-framing
We wanted to try as many different directions as we could think of, review them together and see what works.
Display pipeline status
Display pipeline and its metadata
Connecting pipelines with workflows and jobs
Design prototype
Initial design prototype was created and validated by design lead at that time who left the company shortly after the process has been completed. There was no detailed documentation about why things were done the certain way and what were the outcomes of user validation.
Execution
Decide where to start
We had option to start from the point where user lands after log in to CircleCI (dashboard) and move through the journey through workflow and job.
Other option was to start from the page which is being used the most, at that time it was the job page and users commonly got to that page directly via VCS pull request or email notification. We decided to go with this option.
Since we needed to create new code base decision was made to make completely new page on a separate subdomain and opt in experience for the user.
Splitting design into phases
WAFL - Well architected, functionally limited
Since we could not deliver entire design at once we had to simplify design and split it into phases.
Pipelines MVP
Delivering WAFL to customers
Initial feedback was bad
-
Important functionalities were missing
- CMD + F did not work
- Data streaming did not work
- Color coding of step / test output was broken
- Rerunning workflow option was missing in first itteration
- Sidebar with metadata execution was buggy. It included only few metadata and it was obsolete.
- Going between "new" and "old" experience was messy
- Experience was slow
Feeling customer's pain
PM on the project and I teamed up, reached out to customers who were leaving feedback and talked with them.
For the missing functionalities I did design demoes and asked for feedback.
We had opportunity to learn more not just about what customers need, but why they need it and how does that fit into their workflows and ecosystem.
We learned that negative feedback via social networks can change into constructive and positive feedback once you reach out and talk to the people.
We shared takeaways from each user session with the broader audience in the organization which was great way to start internal conversation and motivate people to solve customer problems.
Later we used this form of conversation as a blueprint to discover more about our users. Like exploring they daily workflows and looking for ways to become better daily dashboard.