Profile Resources (VMware)
The goal of this project was to simplify the deployment and maintenance of settings which are common across multiple device platforms, instead of having to deploy them separately. It was undertaken as a proof of concept to test how we would restructure our old system to make it more adaptable.
Role: Interaction Design, User Research
Tools: Sketch, Axure, Balsamiq, Zeplin
Notable: 7 patents pending for my contribution to the concept and design of this project
I have omitted and obfuscated confidential information on this page to comply with my non-disclosure agreement, and the content does not necessarily reflect the views of VMware.
VMware AirWatch started as a Mobile Device Management (MDM) Solution. It enables our users (IT admins) to configure and manage different policies and settings for devices across multiple platforms.
Each platform is different and has their own categories of settings.
However, settings such as Wi-fi, VPN and Email exist across all platforms. These are like resources admins are giving to every device, irrespective of its platform. Hence, this project was known as 'resources'.
Understanding the Problem
The goal of the project was to simplify the management of resources in the console. To do that, I needed to understand what exactly the problem was and what we were trying to simplify.
Since this project started out as a proof of concept, the team decided to tackle the following problem statement first:
"Set up the same Wi-fi, VPN or Email resource across multiple platforms at the same time."
In the current system, users set up the wifi resources for each platform one at a time.
The flow was setting up one resource for one platform requires three distinct steps. The total effort for five platforms requires 15 steps.
To set up a wifi resource, users have to go through the same process 5 time, causing duplication of effort.
Later, to update that wifi resource requires users to go to 5 separate locations, causing maintenance issues and lack of consistency.
In the proposed system, we wanted to simplify the process for setup and maintenance.
To setup a wifi resource users should go through the entire process only once. This would reduce the number of steps from 15 in the previous version to only 3 steps!
Updating that wifi resource would require users to go to one single location rather than the five before.
Designing the Flow
After understanding the problem and the mental model of the system, we spoke to some of our users to confirm whether we were heading in the right direction. Based on their reflections, I proceeded with designing the flow. Here are some of the considerations and design decisions we saw along the way:
Step One: Resource Setup
Our users told us that selecting the resource was the first thing they wanted to do. In the current system, they had to select the platform and then drill down to the resource which was counterintuitive.
"If I want to give wifi, the first thing I want to do is select wifi and configure that."
This was exactly what we now allowed them to do. The first step would be to select the type of resource (from wifi, VPN, email, etc) and provide all the details required to set it up.
Step Two: Platform Selection
For each resource, there are some settings which are unique to that platform. After talking to users, I realized that
Most of these platform-specific settings have some default value and rarely are these updated
The design now allowed users to select platforms and applied default values to platform-specific settings. Users could edit these settings when necessary, and could revert to default easily.
The card interface in my wireframes was a new pattern to be incorporated into our old UI framework. This required me and the visual designer on this project to ensure that it could be applied to various other use cases in the console. After multiple iterations, we settled on a final design which was flexible to support all of them.
This card interface allows users to:
- Select multiple options
- Take small actions for each selection
- View auxiliary information
Feedback from User Testing
Once the flow was complete, it was time to test it and validate it with our users. We had a variety of participants:
- Admins familiar with the old flow
- New admins
- Clients who used multiple platforms
- Clients who used only one platform
We asked admins to set up resources for single platforms and for multiple platforms and then asked them about their experience and feedback in a semi-structured interview. Here is some of the feedback we received:
Profile Resources was a very important project for the future direction of the AirWatch Console. Profiles form the backbone of the system and this project laid the foundation for better designed workflows. This also led to a massive effort to overhaul technical debt associated with more than 100 pages in the system.
We have 7 patents filed for efforts related to this project!
This project started really small and straightforward but it was like an iceberg; I kept unearthing new UX issues because of associated technical debt. Since I was redesigning something that wasn't really ever designed in the first place, the process involved finding a lot of questions that didn't really have any logical answers.
I feel like I have never really stopped working on this project, since it has so many offshoots. Everything I have worked on since leads me back to questions raised during the design of resources.