Any enterprise solutions without a monitoring or reporting features is not a complete enterprise-ready solution. Our competitors are far ahead of us for these two features for a while.
It’s a long-time pain point for our customers to use our products without any monitoring capabilities. One of the typical complaints from our customers is:
We recently had our Core crash due to running out of hard drive disk and we had no warning alerts...
Most of our customers use Splunk as a third-party tool to generate reports for their MobileIron deployments. However, it needs extra configuration and testing, and Splunk cannot provide EMM-specific information, such as MDM certificate expiry date.
Design for scale
MobileIron customers usually have large-scale complex deployments. For example, Eli Lilly has about 30 Core servers and 70 Sentry servers. Designing a UI system which can facilitate all all kinds of enterprise-level monitor data and actions for about 100 servers is a design challenge. The average number of servers we estimated is 50 servers (20 Core, 30 Sentry).
We planned to introduce this new product to our Platinum bundle to keep the existing Platinum customers' renewal rate high, and help other customers expand and upgrade.
Users and Audience
Mobility IT admin/operation
For large enterprise companies, there’re usually a few dedicated IT admins focusing on mobile, such as MobileIron admin. They work with other functions inside the IT team, such as network admin, Active Directory admin etc.
IT managers, CIO and CFO
High-level executives don’t have time to do hands-on IT daily job, but they care more about the holistic MobileIron ROI.
Team & Stakeholders
Product Manager: 1 product manager
Designer: I’m the sole designer for this product, so I am responsible for all the end-to-end design process and deliverables.
Engineers: There’re about 8-people engineer team.
Customer Support and Professional Services team: We worked together to understand customers' pain points and feature requests.
Since Alerts, Reports and Settings are standard components for enterprise apps, and we have established patterns for List View / Detail View, the design process for these pages was quick and smooth.
The chaotic design process is Dashboard. The design intention is to provide a simple UI for admins to accommodate KPI status for average 50 servers, and there’re also lots of other data for each single server. I quickly realized that I should break down the Dashboard to 2 levels: Overview and System.
Overview Dashboard Design Iterations
We did 2 rounds of testing during our design process. I worked with the product manager and customer advocate to do a few remote online usability testing after I designed the early versions of mockups. In MobileFirst conference in June 2016, we also conducted a few on-site testing sessions with with our customers using a work-in-progress dev build.
Overview Dashboard Primary Use Case
The average number of servers to show here is about 50, so search and sort features are really important to help admins find a specific server. I added a search box to the list, and provided more sorting options, such as sort by Location, Latest Core Versions etc based on feedback we received from the WebEx testing.
Another idea to solve this problem is Mark as Favorite since the fundamental customer request is to have a flexible and customizable way to display all servers in this page.
Detailed KPI to show in each card
I designed an intermediate state for each server card to expand to show more detailed KPI data, such as Disk Space, Process CPU, Total Memory etc, and to use a bar chart to indicate its current status. I assumed it’s useful for admins to quickly check and scan the server health so that they don’t have to leave the Overview Dashboard page and come back.
However, customers don’t find its usefulness when we showed this concept in our testing. They said they didn’t care a server KPI until there’s any critical problems with that server. Also they thought using the bar color/length to represent a KPI severity is quite ambiguous and confusing.
So I simplified the UI by removing that extra state and interaction behavior.
My initial design are based on the card pattern and standard traffic-light colors in the IT system. I tried to apply the red-orange-green colors as the card filled color. After internal review with the UX team, I received the feedback that those cards are not visually consistent with our MobileIron styleguide, and the readability of white texts on colorful background is a potential accessibility issue, so I changed the visual style to only use red, orange and green icons to represent the severity.
Meanwhile, another visual designer in our UX team worked with product marketing team to define the product branding color as purple.
The System Dashboard also had a few rounds of design iterations based on my review and discussions with PM and developers.
I changed the background from purple to white to make the whole design clean and simple, so that admins can focus on the data and charts.
Later in the design implementation process, developers gave me the feedback that some server names can be super long, so we have to use “…” with truncation, and that will hide the severity icon. I took the feedback and reverted the display order of icon and server name text.
I tried different visual treatments for the top cards, and finally decided to land on the design using circle icons on the white background. The icon color for each KPI should be changed based on the actual KPI data number.
Product Release Impact
We released the product to the market in December, 2016. (MobileIron official announcement)
More than 70 of the strategic MobileIron customers have proactively showed interest and joined the beta program for this product. By the time we launched this new product, we already had a few reference customers using it with beta program, which is really a fantastic achievement for our team. Here’s a feedback from an IT architect from one customer:
Once our server team provided the VM space we were able to get the Monitor server up and running very quickly. We’ll look more into the other functions like alert notifications etc. Overall great job — I see this tool being widely used by our Ops team.”
Many customers really love the simplicity and intuitiveness of the UI for this product, although they also found some minor UI bugs such as scrolling bar with browser compatibility issue.
Retrospective & Lessons Learned
Getting feedback directly from customers is key
We did a great job of getting feedback with customers throughout the whole design process for this project. We knew exactly what the customers’ pain points and expected features, and we got valuable UX feedback from them by showing my design iterations. Some customers really love doing this kind of usability testing sessions with us, and we built a good UX relationship with them. And we launched this new product with a few reference customers after they used it in the Beta program.
The launch of a product is just the beginning
Right after the Beta program, we received UI bugs and feature requests like LDAP integration, more Sentry traffic data integration, cross-associate server group and admin group etc.
What’s most interesting is that they requested a mobile experience for MobileIron Monitor, so I took the idea and proposed a native iOS app design concept. You can see my next project for more info.
Being a remote designer is not easy
Three locations for the multi-discipline teams and three time zones (India, Singapore and Mountain View). It is my first time to handle this kind of challenge as the sole designer, and the initial design white-board discussions over the phone were not that efficient. Not until I paid a visit to meet the engineering team in India, did I build the teamwork chemistry and personal trust with the two UI developers. The trip made our design process move to the right track.