Service Tree moving a service
Service Tree is a directory of all internal services across Microsoft’s Azure.
The metadata for each service is referenced across many internal tools and Service Tree is accepted as the source of truth for each service. Due to this, it’s important that each service is kept up to date with any changes.
Occasionally with re-orgs or team changes, Services must be moved and information needs to be updated accordingly.
Joining the team
After a re-org, Service Tree was added to our team charter. I was assigned to partner with the Product team to improve the user experience of Service tree.
In addition to specific design work, I also had a goal to improve the UX maturity on the team and implement a stronger partnership with the Product and Dev team.
The Service Tree teams design maturity was “Emergent” based on Nelson Normans 6 levels. I aimed to improve the stage of maturity as much as possible.
UX Process
There was a lack of trust in the value and efficiency of the previous team’s UX process. Despite it’s value, critical research and validation was skipped in order to meet aggressive timelines.
To help fit the UX process to the team’s needs, I introduced a streamlined process built on Jake Knapp Design Sprint methodology. This time-boxed process enabled collaborative alignment across the team and delivered validated learning in days, instead of weeks. The end result was higher quality, more validated designs that did not sacrifice speed of delivery.
Old engagement timeline
Sprint based engagement timeline
Project Goals
Business Goals:
Create a simple experience to easily “move a service”
Before this work, Product Management would spend hours a week helping teams move their service.
Eliminate confusion around service ownership
UX Goals:
Create an experience based on user feedback
Validate our design assumptions
Move fast
Build a strong relationship with Product stakeholders
Designs
New entry points
The entry point to move a service was non-discoverable, due to it being nested inside an accordion menu on a secondary tab (roughly 3 clicks away.) Many questions in the team’s office hours boiled down to “How do I move my service?” To address this issue, I decided to create two, more accessible entry points. One location was on the landing page of a service. The second was in the service’s metadata. Using two locations helped address user’s existing workflows.
Editing ownership
Understanding ownership of a service was the biggest pain point. Users were unable to determine if an owner was “valid”.
Invalid owners occur when a service is re-orged to a different organization, or if an owner leaves a team. To check this, users would have to manually reach out to each owner. This took several days to complete.
To reduce the manual time, I included a new step for editing ownership. This would show if a user is invalid or valid, and give the corresponding actions (add or remove) to update the service.
Reducing errors
If ownership was not properly validated or the Service location was incorrect, an error would be shown that did not properly describe the issues. Users were unsure which section was incorrect and how to move forward. To reduce errors and help users check validate their changes, I broke up the experience into three steps.
Choosing the new location for the service
Checking to make sure that owners are updated
Reviewing and confirming your selections
Each step would have it’s own validation, and provide actionable errors if needed.
Validation & testing
With the help of a User Researcher, we conducted two sessions with 3 service owner. The first round of sessions were to get an idea of the problem and show initial design ideas. The second round we ran a comparative study and validated the designs.
Outcome:
We were able to define a problem, iterate over design, and then validate the design in a weeks time. 3 out of 3 users agreed that the new experience would be an improvement.
We also received user sentiment of the process.
“This is fantastic. I want to thank you so much for reaching out sharing early with me and giving me an opportunity to help shape the future here. This is this is tremendous. I really do think this is going to help a lot of the folks like me across Microsoft.”
Post Deployment
Once the experience was released to all users, we were able to gather positive indicators that the new UX engagement model was a success and the new experience was working as intended.
Increased Operational Efficiency
Reduced hours spent by Product Managers helping service teams by 50%.
Processes improvements
Developed a successful, fast paced UX engagement model that was standardized and replicated across future feature development cycles.
UX Maturity
Strengthened stakeholder trust in the value of the design process, leading to earlier UX involvement and improved collaboration on future initiatives.