Microsoft Admin Center: Quoting, Cart, & Checkout
At a Glance
An enterprise shopping experience for purchasing product licenses for international companies.
My Role: Solo Lead UX Designer, Interaction & Visual Design, Prototyping
Timeline: 2 Months
Team: Immediate team: Quoting, Cart, and Checkout PM, Secondary team: Azure Team PMs, Quoting Center Pms, Dev Leads
Problem
Azure Build Health (ABH) is an internal dev platform at Microsoft that reduces the risk of bad code being pushed which can bring down Azure services. Currently, teams must be manually white-glove onboarded the platform due to the bespoke nature of each team's different data pathways and pipelines. Data pathways must also is manually added, modified, and removed by the ABH team.
Goal
Craft an onboarding experience that's flexible enough to support all Azure service team's data pathways so they can onboard and maintain their data pipelines and pathways without requiring manual assistance.
Impacts
Time Saved
Time for team to onboard to the platform from 1 month -> 3 hours
Time Saved
Time for team to onboard to the platform from 1 month -> 3 hours
Time Saved
Time for team to onboard to the platform from 1 month -> 3 hours
Product Utilization
Teams onboarded onto platform went from 40 to 1500 in 6 months
Product Utilization
Teams onboarded onto platform went from 40 to 1500 in 6 months
Product Utilization
Teams onboarded onto platform went from 40 to 1500 in 6 months
Financial Impact
Teams utilizing the platform will save the company $1B ARR
Financial Impact
Teams utilizing the platform will save the company $1B ARR
Financial Impact
Teams utilizing the platform will save the company $1B ARR
Pixel Preview
Azure Build Health's Test Tab comparison feature allows users to compare data between two separate builds quickly to spot regressions.
Each build pipeline can have bug and incident queries to establish automatic linking between builds and their issues without needing manual input.
Teams with advanced needs can customize "Release Views" on top of build pipelines so they can limit their view to only relevant data.
Act I: Creating an MVP to allow onboarded team's to add and maintain new test data and views.
The Azure Build Health (ABH) team wanted to create a self-service configuration hub to give their users that were already onboarded onto the platform the ability to add their test pipelines and Release Views.
Azure Build Health main users are Release Managers: senior-staff developers and technical Product Managers.
Test Pipelines
Contain tests that will be run against the build. Test Pipelines are constantly added overtime.
Test Pipelines
Contain tests that will be run against the build. Test Pipelines are constantly added overtime.
Test Pipelines
Contain tests that will be run against the build. Test Pipelines are constantly added overtime.
Release Views
Custom filtered views teams could save and add to let them view relevant data.
Release Views
Custom filtered views teams could save and add to let them view relevant data.
Release Views
Custom filtered views teams could save and add to let them view relevant data.
Building a Configuration Hub
With a delivery timeline in 2 weeks, this work was planned as a quick-fix as there were limited dev resources for a larger scope of work. I approached this focusing on short-term impacts.
I worked with the PM to understand their current white glove experience. This let me learn about the items that existed outside of the current planned scope of work and design for the bigger picture.
I broke down the onboarding configuration experience into two pages: Release Views & Test Linking.
Test Pipelines
Release Views
Act II: Creating a self-service onboarding hub to allow Azure's largest team's to onboard themselves onto the platform.
1 month later, Azure's EVP wanted the last 10 of Azure's bedrock teams (80-2000 people per team) onboarded onto ABH. I needed to add more features to onboard their own data in addition to the existing management features:
Build Pipelines
Build pipelines contain code, and new ones need to be linked to Azure Build Health.
Build Pipelines
Build pipelines contain code, and new ones need to be linked to Azure Build Health.
Build Pipelines
Build pipelines contain code, and new ones need to be linked to Azure Build Health.
Bugs & Incidents
Issues need to be associated with the correct build pipelines without needing to manually associated each time.
Bugs & Incidents
Issues need to be associated with the correct build pipelines without needing to manually associated each time.
Bugs & Incidents
Issues need to be associated with the correct build pipelines without needing to manually associated each time.
Combining Release Views and Build Pipelines
There was another delivery timeline of 2 weeks and planned again as a quick-fix from the UI side, as the more complex bespoke needs of the team's we needed to onboard were handled with backend-only work. Our existing customers were utilizing Release Views to quickly navigate Customers utilized ABH by All of customers were all using release views so I put that as the entry portal before seeing their applicable test pipelines.
Our customers were all utilizing Release Views to see relevant data inside of build pipelines, so we as a team decided we wanted to enforce the usage of Release Views. This created a singular system inside of the configuration portal and the Azure Build Health portal, making release views the first level of hierarchy.
Inside of each Release View, users most common action would be to link new test pipelines so I prioritized that action and which data users would need.
Act III: Suffering from Success, in which I create a configuration hub that grows the platform from 44 bespoke teams to 1500 in 6 months.
The new onboarding hub was constructed during December, at the same time as the annual code freeze. During the freeze there were far fewer Azure outages, showcasing the importance of ABH. This also influenced the EVP of Azure to want 1500 services, up from the 44 currently, to be onboarded onto the platform in 6 months.
Hol' up, Wait a Minute, Something Ain't Right
My team wanted to do another accelerated sprint to start dev work ASAP. Instead of rearchitecting each time, I proposed taking a bit of time to clearly understanding each part of onboarding and continual onboarding, so that the configuration hub would have a solid foundation. That way, when custom features were needed, there would be less dev and product work needed.
Drawin' with Devs
I lead three workshops and diagraming sessions with my PM and Dev Lead. As well as having a two heavily technical discussion and debates with other stakeholders, and from these discussions, I came up with a unified portal architecture.
Paradigm Lost and the Interaction Journey
Conducting more user research I found that the Release Views containing the Build Pipeline introduced friction for teams with less complex release processes. I swapped the hierarchy to be pipelines first, and the teams who needed more complex configurations could add a release view on top of the pipeline. I explored a variety of different interaction paradigms through this work.
Going Above and Beyond the Configuration Hub
While working on this project, I created several designs and discussed them with the larger Azure Build Health team to guide the product to work better for our users.
Integrated Flows at the Pipeline Page
I integrated Release Views into other areas of Azure DevOps to create more seamless and intuitive experience for our users.
Integrating Continual Onboarding into the main flow.
Onboarding new test pipelines was a common task for our developers. I built out a workflow where users could do so right from the Azure Build Health page without needing to go into the configuration hub, reserving it for more heavy technical tasks.
Validation for the Present and the Future
I tested the designs with several teams inside of Azure to make sure the new designs supported all of Azure team's data pathways and pipelines. I also went solo and guerilla tested with dev teams outside of the Azure org to validate if the designs worked for them.
Configuration Hub
Queries track issues related to each new build that passes through a pipeline, requiring only a single-time entry.
Team's with advanced needs can customize "Release Views" on top of build pipelines so they can limit their view to only relevant data.
Retrospective
Working closely with my dev and PM partners, I was able to navigate this complex world to guide the product to a solution that works for 1,500+ bespoke teams with different complex data pathways and pipelines.
I learned how to guide highly technical discussions with multiple stakeholders by creating designs to create alignment between stakeholders to clarify ambiguous structures and requirements.
Finally I learned that there are some times where you need to design for edge cases, other times you should focus on the golden, or simplest, path first, utilizing progressive disclosure for users who need additional complexity.
I received lots of positive verbal feedback from users, here's one written one from Alanna, the Lead PM of Azure Build Health:
