MobileIron is a core component of an enterprise IT infrastructure, so it’s a mission-critical job to monitor the system health. With Monitor web app launched in Dec, 2016, we solved the problem in the context of at work in the office. But what about out of office and after-work? Customers asked us this question, and our competitors already had mobile monitor product offerings.
Our challenge was to explore and validate our assumptions that it's necessary to provide a mobile Monitor product for customers to empower them receive alerts and monitor their environment anytime and anywhere.
Users and Audience
Mobility IT admin/operation
They work with other functions inside the IT team, such as network admin, Active Directory admin etc.
IT managers, CIO and CFO
Does the CIO want to know that one server got a critical memory or CPU alert on Saturday morning? Does the CIO find it annoying or useful when he receives this notification on his iPhone? When we got started, we didn't have any clue.
At the Mobile First conference 2016, customers and internal sales team expressed continuous requests for a mobile product for Monitor. The product manager and I both liked this idea, but we didn’t have too much insight or data about what exactly the use cases should be for mobile experience. Our design strategy to move on was to quickly create a mobile prototype and validate the product-market-fit, and then iterated our design and product decisions.
Internal Usability Testing
In the enterprise context, it’s not that easy to meet an IT admin because of the deep layers inside the IT team and our customers’ strict rules & regulations. In order to get our design process move along faster to validate the product-market-fit, I managed to find the Sales Engineers who are knowledgable about our target users and use cases. Those two engineers are really hands-on and they work with IT admins on customer real problems in the field, so I received many valuable insights from these two testings. Below are the testing findings:
Mobile Value Proposition
The whole idea of building a separate Monitor app makes sense. Even though Monitor web app can integrate with other third-party IT tools like VictorOps, PagerDuty and Remedy, the dedicated Monitor app provides more context and real-time notification and data to help customers make decisions.
Mobile Dashboard Use Case
My design assumption is not all accurate for this part. The feedback is that admins are not interested in server stats if that server is running up normally. My observations for them using “Overview Dashboard” and “System Dashboard” tab is that they quickly scrolled up and down and moved away to the “Alerts” tab. Later I asked them why and they replied:
“The data charts look very nice, but they’re not that useful.”
Alert Use Case
Receiving automatic alerts is the main value proposition of this product. Native OS level notifications can ensure admins won’t miss it.
The sales engineers really liked Share Alert feature.
Report Use Case
Viewing a report doesn’t make a lot of sense on a small phone form factor. Also there's not a strong use case for that on a small cellphone.
However, it can be super useful to present a monthly security report on iPad for IT executives. And that will be a new form factor for me to explore.
Apple Watch value proposition
Two Sales Engineers were excited to see the Apple Watch concept.
“This kind of cool Apple Watch app gives us more confidence for storytelling when we do a pitch presentation in front of their CIO and IT team.”
Design Iterations After Testings
With these feedbacks above, I reviewed the testing summary with the product manager, and we quickly iterated and updated the design as the following below:
- Enhance and enrich the Alerts use case by designing search, severity filter, contextual behaviors and advanced filter experience. And make Alerts as the landing home page.
- In the Alert Detail page, provide a link to System Dashboard of a specific server to cross-link Alert page and Dashboard page.
- Apple Watch Experience: “Server alerts on your wrist” is what our sales and customers are excited about.
X-Code is too hard for me
Meng To is a talented designer and developer and I always admired his passion and design story. I tried to learn X-Code to build a Swift app prototype by following his tutorial, but I gave up and switched to Flinto and Principle.
For designers, I agree with his opinion that it is most efficient to use exactly the same tool and language as developers use. However, the learning curve for Swift is quite high and it takes time. For this product, we needed to quickly turnaround to get feedback and make design decisions, so I finally used non-programming tools to create prototypes and demos.
TEST ASSUMPTIONS EARLY AND OFTEN
As we first get started working on mobile, PM and I were not on the same page about the mobile product focus. The PM wanted to have feature parity between web and mobile, and preferred to use responsive web app approach to purse "time to market". However, I was not convinced that customers need all full features from the web app in a small form factor scenario.
We decided that the best way to verify our assumption is to test and gather feedback early. After testing with two sales engineers, we agreed on the main mobile product value prop and we should focus on Alerts.