May 2019 - August 2019
6 Developers: Tanya Tan, Jasmin Goh, Jason Doo, Nipun Jindal, Annie Liang, Ali Khamesy
Figma, Illustrator, Github, Adobe Premiere Pro
Product Designer in the Microsoft Garage
In the Microsoft Garage, our team was given the responsibility of working to improve Web Template Studio, an experiment sponsored by the Microsoft Developer Ecosystem & Platform team. As the only designer on a team of 6 software engineers, I touched all aspects of the product from crafting the UX writing and reviewing PRs to marketing. We needed to take the project and work on improving it to increase its lovability.
For many professional full-stack developers, it can take at least 8 hours to set-up their front-end framework and back-end framework by scanning documentation, video tutorials, and trying to figure out how to attach them together correctly.
According to professional developers, this doesn’t even include the amount of time it takes to set-up and attach a cloud service. Instead of getting to focus on developing their ideas, there is a lot of time wasted.
An open-source VS Code extension that provides a wizard-based experience to help developers get set up with reliable boilerplate code in minutes.
"I wish more extensions used this type of interface."
- Dan Vega, online programming instructor
"This is an impressive engineering effort and really just a cool project, but most importantly to Microsoft, it's an excellent sales funnel for Azure."
- ZeroCool2u, hackernews
Our team conducted over 30 usability tests in total to help us identify the major pain points within the system and constantly iterated through different prototypes to test out new features and changes to the system. This also included combing through GitHub issues to help us prioritize and address user pain points.
From our user tests, there was still a lot of opportunities to clean up the feel behind how developers progress through the wizard. They complained about how long it felt to go through the wizard and a lot of the UX writing was difficult to understand throughout the entire system (from the wizard to the post-generation experience).
One of the major pain points was knowing where to look and what to click on because of the amount of content on each step and the amount of redundancy as well. Many developers regarded a lot of content as noise on the screen since it didn't help them with their primary objective of completing the task in front of them in order to progress through the wizard.
After dozens of iterations and revisements to different parts of the system, shown below is the ideal shipped design of Web Template Studio 2.0.
Upon first using the initial version of Web TS, developers felt that the process took too many steps and "didn't feel right". They were content that it worked, but weren't impressed by the experience. For the amount of steps laid out, they were discontent by how long it took and how many clicks it took them to get to the end.
We shortened the user flow by removing “Project Type” from the steps since there was only one type of project available. This helped visibly improve the user’s experiences afterwards since it sped up the process. We also automated many steps so that the user doesn’t need to think about anything as they go through the system.
With the home page, we initially discovered that many students didn’t really feel inclined to use the extension upon first glance and found a lot of the information unnecessary/redundant on the first page. There were also many usability problems within this page as well.
To address these concerns, I aimed to make this page inviting and less technical, with the main focus on completing the fields in the middle to move onto the next step and create excitement when starting a new project.
For many developers, they already know what type of frameworks they will be using since they will be choosing the one that’s the most familiar to them. The right sidebar also provided redundant information and annoyed users.
As a result, we minimized the content on the page and focused on providing the version number to students. We also implemented a dependency checker to help users understand that they are missing these updates before they realize at the end when they’re trying to start their project and can’t do that.
With the Page Templates page, the most concerning part was figuring out how to let users know what the templates looked like.
We changed the UI writing to "Preview" instead of "Details". They were also confused by the amount of pages someone could add.
For many developers that we tested with, this was the most confusing interface and the page with the highest drop-off rate. After user testing with multiple developers, many didn’t realize that this step was skippable, they were intimidated by the “Sign In” button and they didn’t understand what the value proposition of the Azure services were.
I redesigned the information hierarchy on the page and housed information that we knew developers cared about such as what the service does, the price point, and how long it would take to set it up.
Once developers decided that they were interested in the service, they are prompted to log in or create an account in a streamlined flow.
"This looks like a test I'm going to fail." For developers who were completely new to Azure Services, adding a service is extremely intimidating for them. When they looked at this form, they felt dread and anxiety since they didn't know what to fill out or why it mattered.
A beginner-friendly Azure Services form that is automated and "just works" so that users can focus on figuring out other things that matter more. We also added labels to each section to help prompt developers to know what each section meant and its significance.
If a user wanted to make any adjustments in the final summary page, it was impossible for them to change it. Instead, they would click back and forth between the different steps to make adjustments.
Based on user research, we came to the conclusion that it would be more valuable to optimize the quick start experience through this panel and allow developers to get started as quickly as possible.
For many developers, this screen contains important information regarding their Azure services and informs them to read the "README" file. Due to the amount of content on the screen and lack of information hierarchy, users didn't read any information presented to them.
Clear information hierarchy with progress being shown visually to let users know what's happening with the program. We changed the primary call to action from "Close Wizard" to "Open Project" since we found most users accidentally closing the project and feeling frustrated afterwards.
4.5* on vs code Marketplace. 1,650* on Github. 20k+ installs.
Prior to the redesigned UI and UX flow, we had 0.01% of our average weekly users deploying cloud services. After we released the new Azure services redesign and improved the overall UX, over 10% of average weekly users were using Azure services.
As an open-source project, we also wanted to see this project thrive among the open-source community and ensure it was a loveable product. If developers loved the product, they will dedicate their time to improve the project. Since we’ve launched the redesign, there are multiple users adding their own touches and improving the code generated by WTS.
On average, we received an 8.8/10 satisfaction rating on the wizard experience from the developers we conducted usability testing with. To improve the user experience, they wanted to see more features being added and to see the project thrive by itself.
This project was unquestionably the most challenging yet rewarding product I’ve ever worked on in my career as a product designer. I learned to leave my comfort zone by taking on multiple tasks and collaborating with my amazing team of developers to improve the product together. This was the best summer of my life and I was able to take away so many learnings from this.
If I had more time...
The “Quick Start” feature that allows developers to get started quickly should be fleshed out further in terms of the design and execution.
I would have also liked to have worked on an “Advanced Settings” panel to help advanced Azure service users to customize their settings.
I would have liked to have more time to work on the systems design dictating the look and feel of the product and have the opportunity to investigate more into this side of the project.
What I've learned
I understand that working on UI/UX doesn’t always sound very exciting to software engineers who are expecting to work on technically challenging problems, so as the sole designer, it’s up to us to advocate for increasing the usability of products and convincing developers on how valuable this will fit in. I found that the most effective way of doing this was having the developers participate in design thinking activities with me so that they would feel inspired to work on improving existing features and making them even better.
One of the biggest blockers I faced on this project was learning how to design for Azure services when a lot of aspects of that system were out of my control. There was a learning curve for me to understand how these services were valuable to developers and how we could convince them to try them out. This required us to reach out to other Azure cloud experts who were more than willing to offer their insights and help us along our journey to improve the user experience. By collaborating with multiple stakeholders, we were able to arrive at a solution that we knew would deliver the most value to developers based on the insights we had already gathered and communicated to these other teams.
Since we were working in a very agile environment, our tasks and needs changed more than the weather. This meant having to deal with new information and figuring out as a team how to handle it. To combat this, our team had pow-wows whenever necessary to talk about how we would be approaching next steps. This allowed us to analyze what we knew, what we didn’t know, the risks, the amount of time it would take to change direction, and what the best possible solution we can execute would be.