Usability issues

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.

Solution

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.

Usability issues

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.

Solution

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.

Usability issues

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.

Solution

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.

Usability issues

With the Page Templates page, the most concerning part was figuring out how to let users know what the templates looked like.

Solution

We changed the UI writing to "Preview" instead of "Details". They were also confused by the amount of pages someone could add.

Usability issues

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.

Solution

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.

Usability issues

"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.

Solution

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.

Usability issues

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.

Solution

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.

Usability issues

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.

Solution

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.