A Visual Studio Code extension that quickly provides web developers with boilerplate code, easy to use templates, and automates the Azure deployment process.
As the team’s only designer, I led the overall design vision of the project conducting user research, producing mockups for implementation, and creating weekly slides to showcase the team’s progress.
Team: Kai Bailey, Imho Traore, Trevor Ngo, Kelly Ng, Sahil Tara, Danish Dua, Amr Sharraf
Role: Product Designer
Type: Garage Internship Project
Length: 16 Weeks
At the Garage Internship program at Microsoft in Vancouver, a group of 8 interns (6 developers, 1 program manager and 1 UX Design Intern (Me!)) embarked on a project sponsored by Microsoft’s Developer Ecosystem and Platform team. With support from our sponsors, my team and I built a Visual Studio Code extension that allows web developers to quickly scaffold up web projects with Azure cloud services.
After speaking to over 40 developers and putting out a survey that reached hundreds, we have identified that scaffolding a web application that uses cloud services is very complex and time consuming.
The most experienced developers spend over 8 hours developing the scaffolding for their web application, and many beginners don’t know what framework combinations work well together, what order to organize technologies in, and find it difficult to connect to cloud services.
Our solution to this problem is by providing web developers with boilerplate code, easy to use templates and the automation of the Azure deployment process, all within an interactive wizard on Visual Studio Code.
Web Template Studio is great at:
Providing a deployable foundation for developers to build off of with code to-dos.
Helping web developers quickly generate reliable boilerplate code that is validated by influencers and framework core team members.
Automating the Azure deployment process by providing a familiar experience for industry professionals, while making options straight forward for beginners.
To conduct user research in our project, we used multiple forms of feedback including interviews, a survey, and testing within the community and internally at Microsoft.
Interviews: 40+ Interviews
Many of the initial interviews we had were to iron out what direction we wanted to take the product in. Some of the information we were looking for included:
What is the flow of creating a new web application? (to find out the logical order in which we should organize our wizard)
What are the major pain points people face when scaffolding a web application?
What are the most popular front- and back-end framework choices?
What is the main target audience for our project?
What services do people include in their web applications? (database, CDN, server-less compute, authentication)
Notable interviewees within the open source community and Microsoft include:
Scott Hanselman, John Papa, Anthony Chu, Burke Holland, Sarah Drasner, Josh Holmes, and Brian Holt. By interviewing prominent members of the community, we were able to come to gain insight many of the questions we had. Doing so then helped us frame the questions in our survey.
Survey: 200+ Responses (Survey Link)
In preparation of conducting the survey, the team laid out many assumptions that we wanted to validate about our users. At this point, the majority of people we interviewed were experienced professional developers. Since this was only one part of our target audience, it was important to get data on students, novice web developers, experienced developers and everyone in between.
The main things we wanted to know from respondents were experience, pain points, types of web applications they build, preferred IDEs and frameworks, as well as popular web app components.
Novice web developers currently find it difficult to quickly get started when creating web applications and deploying them. While intermediate and advanced developers need a better way of prototyping and developing proof of concepts. Some of the most popular products in the web development space are products that interconnect components of web applications. However, the biggest gripes with these products are that some are not intuitive enough for beginners, or that they provide developers with too much code that ends up needing to be deleted.
Working with my team, I helped identify a list of competitors such as Google Firebase, React-Boilerplate and others in the space and analyzed what their strengths and weaknesses were. This research helped us plan out what features we needed to focus on to achieve maximum impact on launch.
One of the challenges of this project was identifying a flow that would make sense to all developers. In order to make sure we had the flow right, we took our iterations into every meeting and every interview. We reviewed the flows with our sponsors, developers of all skill levels, instructors, students and Microsoft cloud advocates. Below are two of the many revisions we had.
In the final flow, developers will navigate a wizard which provides them with framework choices such as a front-end framework, back-end framework, pages, services, and the option to deploy. The wizard generates a template which includes boilerplate code to start working from, along with educational prompts in the form of in-line to-dos, and documentation to help them build their application.
1. To make the wizard as developer-friendly as possible, I am numbering the steps in the navigation. I also have it listed from top to bottom to show the direction of movement and distinguished the current step from how many steps are left.
2. The first step in the wizard is to let developers select a project name as well as an output path. This provides clarity as to where the generated files would be placed after the developer hits generate.
1. Once the developer has finished a step in the wizard, that particular step gets updated with a check mark and the blue highlight proceeds to the current step. This movement within the wizard signals progress which is an important morale factor in preventing drop-off.
2. As developers make selections, they are updated under the project details on the right-hand side of the interface. Like a shopping cart experience, developers can add technologies to their basket and choose to swap out their selections at any point in time. We need to note however, changing selections may require the developer to redo some steps.
1. In our previous iteration, we had separated front-end and back-end frameworks into two screens. But after further user research, we found out that some frameworks work well together and some don’t. Here we can make recommendations to developers who want to learn a new tech stack. Another positive from this is that it shortens the perceived amount of steps in the wizard.
2. Throughout the wizard we have be having defaults. This can liberate the developer from having to make a selection because every click counts.
4.1 Page Details
1. Some feedback that we got after running through the wizard with developers was that they wanted to see what the pages looked like. So when you click on details, we have a description page with an image of the template for developers to look at. We have also included important information such as documentation links to external resources if they wish to learn more.
4. Page Selection
1. Pages are the templates that we would be generating. Through research, we have found that beginner developers prefer a template that they can learn and build off of. Advanced developers prefer just a blank canvas and so we provide that option as well.
2. Developers have the option to add as many pages as they like. Developers can also rename, re-order and remove any pages after adding them. One problem of adding too many pages is that the list can seem endless, to help with this; I have added a minimize feature so that if developers add services to their project, they can see and access those more easily.
4.1 Page Details
3. Some feedback that we got after running through the wizard with developers was that they wanted to see what the pages looked like. So when you click on details, we have a description page with an image of the template for developers to look at. We have also included important information such as documentation links to external resources if they wish to learn more.
5. Azure Portal
1. We have leveraged the Azure extension within Visual Studio Code and brought it into our wizard. Immediately I knew that alot of people are not going to have Azure accounts and/or subscriptions. Therefore, we are making it clear that this step is optional and users can choose not to attach services to their project.
2. For security reasons as well as our time constraints, we will be directing developers to the Azure portal where they would have to sign-in there, then return back to the wizard once they have done so. This was one of the technical limitations of our project and if we had more time we would definitely look to add authentication to our wizard.
5.1 Azure Services
1. After obtaining your subscription or simply just signing in if you already have one, you are met with the two services that our product currently supports. As we are planning on adding more services to this list, it was important that these components were modular. This makes it easier for development to add in new cards and services on the front-end interface.
2. It is important to note that we do not want to force people into Azure. The next button is there to let them to skip onto summary is there so if they choose to not proceed.
6. Services Modal
1. When users click on the “add resource button”, I implemented a modal type popup with a dark backdrop. I did this so that the modal itself would stand out, making the screen look less cluttered allowing developers to focus on the task at hand.
2. Right now, we have implemented a server-less Azure functions and a database CosmosDB. I didn’t want to reinvent how people would normally attach Azure services through the portal. One thing that I did do was to disable the steps to completion in a top to down order. Doing this helps guide the developer and reduces cognitive overhead by having all the fields open at the same time.
7. Summary Page
1. Once developers reach the summary page, they can see a list of all the selections that they have made up until this point. This is to help them double check that they have all the right components for their project.
2. One of the challenges of designing this screen was to be able to surface important information like version numbers and dependencies but keep it organized and scannable. I have made a general component layout to address this with a technology icon, and dependencies and version numbers below that. Over to the right, I have a list of all the licenses the developer is taking on before they click the generate button.
1. Once developers click the generate button, we update them on the status of their project. We do this to provide feedback and a sense of how long the project will take our extension to create.
2. We are separating CosmosDB and Azure Functions into two different lines underneath the services header because they take different times to complete.
3. Once the template has finished generating, the developers can open the file in Visual Studio Code and view the readme file that will show them next steps.
9. Post Generation
1. Once the services have been deployed, we update the string with a link to the Azure portal. This makes it easier for developers to find out exactly where their services are on Azure.
2. We also implemented a “Report an issue” button in case generation fails. This links the user to our Github page where they can easily file the bug.
Near the start of my internship, I spent a lot of time getting to know my team. I did this to resolve ambiguities about how we’ll work together upfront. This way both parties can be direct about how we’ll help each other do our best work. I asked questions like:
What do they expect at hand-off?
How do they like to communicate?
What were their past experiences working with designers like? what was difficult? why did it end up a certain way?
What energizes them about their work?
I found that having answers to these questions can optimize both of your processes. For example, some engineers like designs to be redlined before implementing. Others like to be more ad-hoc and sit down with designers to get the design pixel perfect. Figuring out what worked best early helped us break down barriers between design and engineering.
When I asked my engineers about their previous experiences working with designers, a lot of them had said that they were given the hand-off documents once design was finished and told to build it without given any context on why things were designed the way they were.
After hearing about this, I wanted to make sure that I involved the people that’ll actually be building the product I was in charge of designing. Engineers provide a unique perspective to design. For example, engineers are trained to spot chokepoints in a code base which could affect a users’ experience. Having their input early would help me prepare for such technical limitations. What’s more, including them in the process will make them better product- and design-thinkers.
Designs don’t need to be complete for engineers to start work on them. Sharing incomplete designs lets engineers get a head start on building. My engineers told me that this was an incredibly valuable skill that allows developers to always feel comfortable with the development workload.
Throughout the project, I kept a list of features that were mentioned in discussion with our sponsor team and user research sessions. However, due to time and resource constraints our team had to prioritize the feature set and focus on delivering the best ‘minimum lovable product’. This product is set to go open source, but here are some of my ideas for the future.
Scale services to support Amazon Web Service, and Google Cloud Platform.
Set up a profile experience where developers can save their favourite tech stack selections.
Ability to interact with templates within the wizard (Squarespace editing experience).
Further prototype and exploration into data form and data grid templates.
Lastly, I am interested in how the product would scale in terms of the number of permutations. It would especially be a tough challenge to create templates that work across many different frameworks.
My experience in the Microsoft Garage internship was unlike any other. During this project I was able to develop my skills in designing for a field that I had no previous experience in. I had to learn the many different interface guidelines and constantly adapt to the constraints of the project. I embraced the agile workflow and delivered designs at a rapid pace. Finally, as this was only a 16 week project, I wanted to keep a future vision of an ideal product but prioritize the most valuable features to get built within a timely manner.