Atlas - Multiple Deployments
Building a key feature under extremely tight timelines and ambiguity
Information Architecture | UI Design | UX Design
December 2020 - January 2021
What is Atlas?
Atlas is an internal developer tool that allows software engineering teams to automate the build and deployment process for their existing applications / software. It is composed of the user interface, and a configuration file where developers can make changes to their build/deployment pipeline.
Atlas is also built on top of existing DevOps tools/services.
Background & Challenge
Currently a developer may need a project to be deployed to production. They currently go into Atlas, look for the pipeline for that specific project, send that link to the approver or deployer, and manually coordinate the deployment.
However, there is no streamlined way for them to deploy multiple applications or services at once. If the developer needed multiple projects to be deployed in one go, they would be sending many links to that approver or deployer.
Ideally, a solution would be able to help approvers save time and perform actions in a streamlined way, but also help developers work in an efficient enough way so developers would adopt this new flow.
Hurdles
This feature was extremely challenging due to a few reasons:
Priorities shifting multiple times in a short timespan. I worked on initial research for this feature, but priorities shifted very quickly and we needed to design this multiple deployments feature for another type of application (which was significantly more complex).
Creating a final design and test in 2 weeks. While working on the design for the different type of application, priorities shifted again and we were given 2 weeks to finish the initial design we conducted research for.
Onboarding a new designer. A new designer joined right before work started on this feature. This meant onboarding the new designer onto the team, product, and this complicated project.
Solution
A way for the developer to create a “request” and send it off to the approver / deployer. Any member of Atlas can see an overview of all the requests.
I was the lead designer for the feature, and coordinated all the research and testing. I worked on the design to create the request, and another designer worked on the approval and deployment process. I will only be focusing on the side of the feature I designed for.
What I learned
Users were unfamiliar with the term deployment requests and needed a lot of additional context
A deployment request and snapshot (multiple artifacts) name was the same. However, users got confused about the terminology between the two.
What users said they liked, and what they found more usable were different.
What I did
Added in tooltips and ensured empty states provided more information on what a deployment request is
Separated out the deployment request and snapshot name into two separate values
Focused on exploring versions what I saw users do instead of what they said they liked.
Final Output
Developers can view and create a deployment request. In the deployment request overview, they can see all the artifacts inside them, filter and perform additional actions.
However, since this feature is a completely new way to do deployments, we will be needing to spend more time on documentation and determining how to position this in the application. As this is still a MVP, we will be continuing to add functionality in the upcoming months.
Full Design Process
Discovery & Initial Research
I wanted to validate the problem statement around needing to perform multiple deployments at once.
After talking with 3 developers, I learned that having multiple deployments is important in scenarios where users need to deploy multiple services in a microservices architecture. The idea that applications are structured into a collection of smaller services, instead of one big monolith means that users may want to deploy and test these services together.
I also learned that developers would need to talk to the approvers manually and coordinate developments together, so the deployment process is dependent on 2 different personas. Currently the developer would send multiple links to the approver, and the approver would then approve and deploy the services / projects.
However, was this flow always dependent on 2 users? I wanted to see if an approver could deploy without working with a developer.
After speaking with a few developers and approvers, I learned that it would be very difficult for an approver to create the deployment since they wouldn't have context into the projects created, and would need the developer to give them guidance on which project to use.
I created a second user flow where the developer would select the artifacts to deploy, and create a deployment request. The approver would then approve the request and deploy the projects. This made much more sense to the developers and approvers.
Design
Design Goals
The goal of the developer flow was to design an intuitive way for someone to create a deployment request so that they would continue to adopt this new flow.
We decided to design a separate flow from the existing Run Details screen. We found that users would like to see specific information in an easy view, and I would be coming back to this design later on.
I worked closely with the developer leads to design a few different variations, before landing on a version to test with users.
I also looked into terminology and found certain words that were used across existing DevOps tools:
- Projects / services -> Artifacts
- A locked collection of projects -> Snapshots
Deployment Request Flow V1 (Mid-fidelity)
I first explored the idea of a sidebar that allowed users to perform all actions, which was similar to a watchlist concept in some platforms.
In V1, a developer creates a request by seeing a "history" or artifacts (projects) and snapshots (collection of projects) that are deployed, and then adds them to a request. The user can view this request and its contents in a sidebar, and add more artifacts from the sidebar or from the table.
A request is "completed" when a user creates a link and sends it out.
Saving snapshots to a request
Created request
Deployment Request Flow V2
In V2, I thought of a flow where the user would still create a request by selecting from a history of artifacts (projects), but there would be the option to save deployment requests, and see multiple ones.
Users could mark these as "draft" and send it once all artifacts have been added.
Creating a Request
Deployment Requests Table
After sharing this flow with the team, I still noticed some confusion surrounding this flow. The team was concerned about the ability to show a deployment history of all artifacts since some applications may have hundreds of them.
There would still be concern about the logic that would need to be created to check if a user is selecting the right artifacts for deployment.
Deployment Request Flow V3
In V3, I came up with a straight-forward way to create a deployment request.
The user would land on a deployment request page, click on a button to create a request, which would lead through a series of steps. Since artifacts are tied to a repository and environment, this would limit the number of artifacts we would have to call.
Creating a request
Selecting a project
Testing
Testing Goals
I tested this feature with 5 users to learn if this feature was intuitive, and where friction points existed.
Top Findings
Understanding a Deployment Request
Users originally were confused about the steps that would happen within a Deployment Request. While users generally understood what a request was, they looked for more upfront context.
Aside from detailed documentation, I made sure to add a tooltip to the feature, and a description of the feature in the empty state.
Deployment Request vs Snapshot
Originally, a deployment request and snapshot (multiple artifacts) name was the same. However, users got confused about the terminology between the two. Users asked questions like "What is a snapshot? How does it relate to a deployment request?" and confused the two.
It made more sense to have a separate Deployment Request and Snapshot name. Due to the separation between the request and the "snapshot" getting deployed, I made sure to separate out the request and deployment statuses as well.
Deployment and Snapshots - Original
Deployment and Snapshots - Updated
Multiple Repositories
For a multiple deployment, users may choose to deploy from 2-5 repositories, and one repository could have 10-20 artifacts. I designed two different versions of this flow.
Version 1 has a long list of accordions per repository on one screen, and if an user selects an artifact to deploy from one repo, the list collapses, next repo is then shown.
Version 2 had various tabs for each of the repos, and when an user selected a project, they could navigate to the next.
I asked users which one they preferred, and 4/5 said they preferred seeing a long list, since it meant less clicking and viewing everything in one page.
However, when actually seeing what users did, 2 of them made errors when selecting repositories, and found it confusing to have to reopen the navigation again, and find their repository, and then navigate to the next one manually. Due to the fact that version 1 was less user-friendly when users made an error, I went with version 2. However, some users expressed that they would like some sort of visual indication shown when they have selected a project from a repo.
V1 - Accordion per Repo (Expanded)
V1 - Accordion per Repo (Collapsed)
V2 - Tab per Repository
Next Steps & Retrospective
As part of beta, I created a Slack group with 7 select teams to determine how they would use this feature in real life before launching to GA. The plan was to conduct contextual inquiry and determine how often the product was used (adoption) and task completion time and rate. Unfortunately, I left the company before this could have been conducted.
Looking back, due to the time constraints on this feature, I conducted just enough research to understand what needed to be built. However, if we had more time, I would have conducted more brainstorming and co-designing sessions with developers, to see if there were better ways to visualize this flow.
On the plus side, I made tons of iterations for this design, and worked with the the lead developers on an almost daily basis to get feedback and ensure I was on the right track. It was rewarding to be able to work with them, improve our working relationship, and get valuable insight.