|
|
Project: From 2016-2019 I was brought on as the Design Lead for a new Mobile Device Management (MDM) product Quest Software was adding to their KACE product portfolio. The project would start as a standalone product and eventually act as the foundation for KACE Unified Endpoints Solution (UEM). Here is the last release update. Here is the official product datasheet. |
|
Results:
- Project MVP was designed and built on-schedule at the end of the first year
- The product features the most robust search design and system in the MDM market
- Appeared on Gartner’s industry Magic Quadrant (2018)
- Localized in multiple language regions (AMER, EMEA, APJ)
- Growing roster of paid corporate subscriptions
My Role on this project:
Project Beginnings: Identify our usersA Mobile Device Management solution has been missing from the KACE UEM portfolio ever since the divestiture from Dell/EMC.
Every year, a KACE user convention is hosted in Europe, Asia and North America so much of our user insights are gathered from our existing KACE users who are currently using other MDM solutions. Due to the specific nature of our product and existing customer base, we easily established our users are device administrators in a medium-large organization. |
|
Let's talk to these usersWe interviewed a series of existing KACE customers gathered from the conferences and asked them to walk us through how they currently manage mobile devices to identify opportunities and pain points.
Here is an example of a pain point:
We use this unsorted dump of insights as a starting point, grouping them into potential product features or ideas that could address them.
|
|
Sorting that dataIt turns out that similar to many Enterprise IT solutions, most of the users needs are very closely linked to feature sets.
We found the level of abstraction between their goals and simply successfully completing tasks is much less than many consumer UX products. Therefore we decided to approach this project from a feature-first strategy. We would research what features best satisfy user needs and build in that order. |
|
Feature Requirements Research
|
With a list of features in mind, we start looking at many public case studies to speed up requirement gathering for the features or "groups" we identified.
This tactic is possible as we are building a product with very mature competitors who publishes some of their research content. This allowed us to move quickly to user validation and business approval on feature requirements to figure out what features should be prioritized to rush the product to market. The results of this research is condensed and shared with Product Management. |
Confirming Requirements
|
In a perfect world, UX gets to decide product direction. Our unfortunate reality was the sales teams establishes the general direction of the project based on the needs of a few large business contracts. Luckily enough, it happens that the features they need to sell the product aligned pretty well with what our users are asking for.
I reconcile their insight with our preliminary research to produce initial base requirements. Once an initial set of features are determined, ideas are floated out to current KACE customers considering a new MDM solution - via stories and storyboards. We iterate on these until we land on stories that our users agree "is an accurate depiction of their pain points".
|
Here we see a story where an IT admin is looking for an automated way to manage multiple device settings in the form of a "plan" or "profile" on a defined group of devices. This would include the "provision in-house apps across all my devices" sticky note from above.
Feature ReportsNext I distill findings into preliminary reports (that evolve with the team's help into user stories) that connects validated user problems to product requirements. These reports are then reviewed by the development team for technical feasibility.
Upon approval these requirements are all inventoried under Epics on JIRA, assigned story points and preliminary flow design starts.
|
|
