Microsoft

My Role at Microsoft

I was a Designer II, in a team of twelve, namely, three designers, one product manager, and eight engineers. The goal of our team is to centralize all the processes & procedures in all the supply chain teams inside Azure. How we usually work is: we get design requests from any of the supply chain teams at Azure. The requests can be anywhere from small bug fixes, to redesigning an entire feature to building an app from scratch. So these requests come from product owners to our PM, we discuss the requests all together as a team during the weekly sprints and decide collectively which designer is responsible for what parts of the design requests. As designers, we further breakdown the requests into multiple steps of the design process and give an estimate for time. Our team likes to split the UX Research and UX design of the same design project with different designers as much as possible to eliminate bias. Scroll to bottom for live prototype.

So far we brought 12 apps into the centralized cloud platform in Azure supply chain teams.

Half of my team at Microsoft. From left, Sunaina, Juan, myself & Will.

Disclaimer

I changed all the names in this case study. I used dummy data in mock-ups. I also used percentages instead of actual numbers. For discreet purposes.

What is Project A?

Project A is a ticketing system that deals with the supply chain management system of Azure cloud servers’ hardware parts. This supply chain system is extremely time-sensitive. For instance, they need to rent out a secure warehouse space to fix all the parts together. Then they hire contractors to fix them. If the parts shipment is delayed by the trucks, for example, the tens and thousands of dollars spent on space and contractors are wasted. So if there is any change in any of the milestones, everyone upstream and downstream in the supply chain needs to be informed so they can take the appropriate action to accommodate the change.

Survey Results

System Usability Scale (SUS)

In general, understanding the users is essential for solving any solution for a product. So before I jump to fixing those UI Bugs, I surveyed the usability of the current app. It turns out that from the two main types of users of Project A, the power users had a very low, 40% usability score and the novice users had an average 77% usability score. JCAB doesn’t seem to serve its power users as it is rated “not useful” by them. And the overall user sentiment was also very negative for the power users. But the novice users seem to be okay with the current app.

Research Plan

So I created a research plan for this project. The scope of this project is 2 months, split equally between research and design. Firstly, I reviewed and understood the business process. Then I reviewed the current app design and understood how it's used. Then I analyzed the rationale for change, created a roadmap for the product, listed goals/objectives in a comprehensive table, and grouped pain points in organized clusters. Then I spoke to Project A forum members to understand how they use the tool. I also attended & observed a Project-A meeting to understand the approval process. I then performed a heuristic analysis of the current design. I then designed wireframes using a stylus in OneNote on a SurfaceBook. I tested and revised the designs with the users. I then created several versions of click-able prototypes using Axcure and performed usability testing. I presented the finished prototype to the customer. And delivered the final prototype with redlines & CSS to engineering.

Interviews

I interviewed 3 teams. 3 to 4 users from each team.

I summarized the large interview screening into pluses points and pain points in the above image. The SCOM team is in charge of coordinating the inventory, build, and delivery to the server. The Pre-Dock team is in charge of monitoring all preparation activities before the server lands at the data docking center. And the Capacity Planning (CP) team responsible for forecasting and planning what server/network hardware is needed and by when to meet customer's demand.

Pain Points

Summary of the heuristic analysis performed and ranked by Nielsen Norman's Severity ratings.

I consolidated the interview findings and categorized the paint points with Nielsen Norman's heuristics and rated the severity of each using Nielsen Norman's severity guidelines, which is useful to prioritize design features. There are 12 pain points but I’ll focus on the top 5 pain points here.

Before Redesign

Project-A app's screenshot of the home page before the re-design

This is how the app looks like before the re-design. The large gird you see is a list of Project-A Tickets. It has 34 columns and more than 1000 rows. Each column represents a detail of the ticket, in no particular order. The tabs you see above the table-grid are still the same tickets but have different states. One obvious pain point I can demonstrate here is how the user goes about looking up a ticket. They have to click on the 'Search Archive' Tab, wait for it to load, manually search through the non-helpful, partial details from the grid. Then find what they are looking for, memorize the ticket's Demand-ID -- because copy-paste doesn't work on this implementation of the grid. Memorize the ID, come back to the home page, hover over the Demand-ID column to reveal a more button, click on the very tiny 'more' button before it disappears, scroll down to 'filter' option from its dropdown menu, and type the Demand ID that was just memorized. All this just to click on the right ticket. The small text that reads 'View' would open the details view of the ticket.

Project-A app's screenshot of the details page before the re-design

This is the details view of the ticket. As highlighted, there are two main actions that an admin user can take, either "Approve" or "Reject" the ticket. This is not necessarily ideal because there are sates that are neither of these two actions, but in between. Also, the details you see on right are not related to the actions that need to be taken on this page at all. I have observed users accessing emails, large macro excel files, and third-party applications to get the information they are looking for.

A staging photo of a war room meeting that happens every week, which lasts for 2 to 3 hours.

So it's extremely important that the Project-A application is efficient as possible because the admins have to go through on an average of 600 tickets and make decisions on the spot, while discussing with 30 different people in a combination of conference and live call. Hence it is appropriately named: 'War-room meeting.'

UI Sketching

UI Sketching is done on OneNote with a Surface Book

I have re-constructed some of the design considerations that I explored before coming to the final solution. On the top left, you'll see a horizontal splitter design. The reason I tried this design first is that there are previous apps in the cloud system that already use this pattern. However, this design doesn't work in our situation because there is too much info and it's too busy. To the right, we have a vertical splitter layout. This layout works a lot better for the type of information-heavy interface. However, I had to experiment with the navigation of the left panel. I started with a grid on the left, which doesn't work too well because of space. Grids work better with a full horizontal space, no vertical splitters. Next, I tried the tree navigation on the left panel, which is a lot cleaner but our data for this project is not organized in a parent-child relationship.

On the bottom left you see a vertical split-screen with cards inside the left panel. This works perfectly for our project's information architecture. However, there will potentially be thousands of cards in the left panel, if each card is divided by a border and shadow, that will be visually very cluttering. Therefore in the next layout, you can see I removed the cards and barely separated with the list item with a one-pixel grey line. And drew attention to the most important info visually. I still kept the information labels, made the labels a lot smaller, and the information bolder and more prominent. I also categorized the different states of the data into statues, visualized by the different coloured dots that you can see on the bottom right corner design. I also got rid of the multiple tabs on the top, which were taking up the main real estate and made the navigation very confusing. Instead, I added a universal filter component form the Stratus Common controls library.

Wireframes

Low fidelity wireframes for the layout of the prototype, which features a new component, the vertical splitter.

Low-fi wireframes for the left panel.

Here are some low fidelity wireframes for the vertical splitter and the left panel of the prototype that I discussed earlier. Here you can see I tried many variations of the list component inside the left panel. Text, that is left-aligned, right-aligned. One to three lines of data per list item. With and without icons. Different typography for each text inside each list item.

After Redesign

Final Visual Design is done in Sketch.

This is the visual design of the prototype done in Sketch. As I've discussed earlier, you can see the list items on the scrollable left panel. Each list item provides a vivid summary of the ticket's details at a quick glance. The six details that are shown for each list item: Status, Issue code, Demand ID, Requestor, Supplier, & Data Center were carefully analyzed and selected to be shown as top details. Now the user can quickly search through the thousands of items by searching, sorting and quickly glancing over the top details to select which item they want to look at. Bear in mind that we have several types of users. They all care about different details, that is why the gird was so huge before the redesign.

On the right-hand side, you can see a lot of information displayed in different accordions. All of the details in the huge grid before the redesign are shown here on the right side now. I re-organized the data so that the most important information is displayed in the most prominent real estate of the screen. Therefore at the top, the first accordion has the most recently updated details. Also, in this industry, there are multiple dates to keep track of. The dates are so critical and essential to the user's actions. Some of our users always have a calendar open just to manually calculate the number of days or weeks between each crucial date. So to simplify this process I made a new time-line component that intuitively shows the exact distance between dates, any expiries, or delays, the current status all in a very simple - easy to build HTML timeline component.

The second accordion displays the most important details. Since we have all the different teams in the supply chain process using this application, each user considers a different set of details to be most important. I interviewed fourteen different people and analyzed their workflows and synthesized what information they deal with on a regular basis. Based on all of their priorities, I determined these top twenty details to be the most frequently used details.

The third accordion is action items. Sathya Nadella said in the 2018 all-hands meeting that he wanted all the teams to move towards digitalization. Hence our team was geared towards transforming all applications and data into the Azure cloud and making all manual processes seamless and automatic. Before the redesign, users of Project-A used to download the application grid to Excel and make manual notes of all the edits that they performed and read other people's notes in order to find out what to do next. Which defeats the entire purpose of the application, if most users never use any of its features except download-to-excel. In the spirit of digitalization, I created a new section called Action Items which will automatically update any user about their to-do items and next steps; it also has a column that shows who is accountable and you can email them from that section itself with a single click.

Results

The increase of efficiency in the user task flow before and after the redesign.

This flow chart shows the workflow of an admin before the redesign. As evident, there are a lot of tasks that the admin needs to accomplish in this single application. Most of them are manual, inefficient, and repetitive.

Admin Workflow

After the redesign, I was able to reduce the admin workflow to 50%

After the redesign, I was able to reduce the admin workflow to 50%. All the blocks in pink have been eliminated from the admin's workflow after the redesign.

Requestor Workflow

The requestors don't use the application much so their workflow was straight-forward, to begin with.

The requestors don't use the application much so their workflow was straight-forward, to begin with. The requestor workflow has been reduced by 20% after the redesign.

Live Prototype

Here is a live mid-fidelity prototype make in Microsoft Axure.

Conclusion

In conclusion, I reduced work time for admins by 80% and requestors by 20%. I received heartwarming thank you emails from users. Error management is now 50% more efficient. In the spirit of digitalization, I increased automation by 40% by replacing repetitive, tedious & manual tasks. I also integrated Project A with Power BI and 3 other internal apps. In the future, I would like to expand Project A to other platforms such as mobile, for updates on the go. Also working on automatic reports to be generated to track the tickets