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, we solved the problem in the context of at work in the office. But what about out of office and after-work? It makes sense to provide a mobile Monitor product for admins to enable them receive alerts and monitor system KPI anytime and anywhere.
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
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? It is still an open question whether this target user group needs mobile alerts or not.
After we tested the prototype with our sales engineers, we knew that CIOs should be interested in viewing reports with this product on their iPad.
Team & Stakeholders
– One designer
– One product manager
At the Mobile First conference, 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 use that to validate the product-market-fit, and then iterate based on feedback.
With my previous domain knowledge, I assumed that the primary value proposition of this product is real-time alert notifications, and our admins would love to have all the same features as they can do with the web app. So my initial design direction is to present all the same features from web to mobile by solving the UX problem from a big form factor to a small form factor.
Internal Usability Testing
Right after I had a clickable interactive prototype(Flinto) on iPhone, I found two Sales Engineers from Singapore Sales team for usability testings.
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.
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 data to help admins 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.
When viewing the alert information, it would be helpful to provide the related server context, for example, to provide a link to redirect to the System Dashboard KPI page.
Report Use Case
Viewing a report doesn’t make a lot of sense on a small phone form factor. Also there's not a 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.”
In Southeast Asia market, large amounts of admin use Android phone even if iOS dominates the whole enterprise mobile devices market. It would be ideal to launch both iOS and Android products and provide support to both platforms at the same time.
With these feedbacks above, I quickly iterated and updated my 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.
More testing and iteration
It’s a right time to continue testing the V2 prototype with some real customers and internal sales people. I would like to have more feedback about the newly updated design, the wearable experience and CIO tablet use case (view reports).
Product platform strategy
I’m pretty confident of the market-fit for this product, but I didn’t involve with engineers throughout my design process. Native app or hybrid app? Can a hybrid app give real-time native-like notification? What about Android? What about Apple Watch?
All these kinds of questions are still up in the air, and we need to balance and decide in aspects of technology, business and UX.
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.