Atlas - Library Pipelines

Expanding the scope of onboarding projects into Atlas

Information Architecture | Interaction Design | UX Design
June 2020

 Full Design Process

Discovery & Initial Research

Due to the ambiguity of many features, I worked with technical and business stakeholders to determine the problem statement, feature requirements, and technical limitations.

I learned that development teams are looking for a way to build a library, but the Product Owner wanted to position this feature as a “CI-only pipeline”.

This is because the team who had requested this feature expected that future users won't be familiar with the term library. While the term "CI-only" is technically correct (it is an automated build and test pipeline), it is ambiguous and does not elude to the fact that the feature only works for libraries.

I learned what libraries are, and heard that other developers refer to libraries with various other terminology (packages, components, modules).

• I could explain libraries in a concise way when writing the copy

• Learned that packages and modules were adjacent-terms to "libraries". While developers understood what "packages" are differently, I was still able to validate that it was still a correct term in the context of the feature.

The developers I talked to believed that most other developers should be familiar with the term "libraries", but some may not understand what “CI-only” means

• This means it's important to test out different flows with different copy

The onboarding flow should be similar to the existing flow for applications, but there will be certain parts that are tweaked for libraries

• This helped me prioritize what to design

Design

Design Goals

The goal of the design was to create an intuitive and clear way for user to onboard a library into Atlas, with accurate and descriptive language. There also needs to be a way for a user to distinguish between a library pipeline and any other pipeline.

I designed two versions of the onboarding flow.

Onboarding Flow A

A version where the library onboarding flow is embedded into the existing application onboarding flow. This version doesn’t explicitly call out libraries, but uses the CI-only pipeline terminology.

Onboarding Flow B

I created some mid-fidelity designs of some ideas I had and tested V3 and V4.

Due to the space constraints limiting the design, the Product Owner and I decided to remove the "create a repo card" and continue using the vertical card layout (version 2).

The only other difference between Onboarding Flow B and the existing application onboarding flow is the removal of the runtime and platform cards.

Pipeline

Once a library is uploaded, the CI-only (build and upload) pipeline is created. The library pipeline is much shorter, so I added in a couple of additional elements for a user to distinguish between different types of pipelines.

A pipeline label was added, along a stage that shows when a pipeline is complete.

Projects Overview

I focused on the onboarding flow and pipeline view for this feature. After presenting my final designs to the Product Owner, he mentioned an important use case that was an oversight.

Once a library has been uploaded, the artifact is added added to Nexus (a repository for artifacts). There needs to be a way for an user to find the library artifacts in one place.

While applications artifacts are shown per environment they're deployed to, libraries do not follow the same information architecture. designed two variations.

Prototypes & Testing

Prototypes

Testing Goals

I tested the onboarding flow and pipeline design with 5 different users, 3 who had requested this feature before, and 2 who had no context of this feature. All 5 users have used Atlas in the past, and have various degrees of work experience.
‍
I wanted to see which onboarding flow was less confusing, and whether or not users actually did have trouble with the terms library or CI-only.
‍
My hypothesis was that the flow that Flow B would be less confusing but this needed to be validated. I also wanted to determine if there any additional points of friction.

Top Findings

4/5 users found Onboarding Flow B less confusing, and preferred the library terminology.

‍I worked with the Product Owner so we could reposition this feature to be a "library pipeline" feature.

• In Flow A, 1 user did not see the updated copy that suggested this option supported CI-only pipelines for libraries. He got stuck on the first page

• 2 user found that the “N/A” radio buttons for Runtime and Platform selection confusing and second guessed what to choose on that page

• These 4 users liked how Flow B explicitly showed a new flow for libraries

• However, one user did not know what a library was, but was familiar with the term CI-only

• 3/5 users did like the fact that CI-only was still part of the copy, since it explicitly calls out the type of pipeline. I decided to keep the term CI-only in the copy, although it was less prominent

Retrospective

There were three challenges that arose from working on this feature:

• This is the first time I designed a feature that spanned the whole platform. In future projects I made sure to take into consider every aspect of the feature, and discover how it would impact the whole product.

• The product owner and the team who requested this feature had a different opinion from the vast majority of users. The requirement and information I was given needed to be validated. This allowed me to work and learn from multiple people in order to validate the language and flow.

• This feature had tight timelines. In less than 4 weeks, and many of the features that get released are “MVPs”. The biggest impact I can make post-release is to persuade the product team and lead developers to take user concerns into their roadmap and work on iterating the feature whenever possible.