Kace MDM

Client: Quest Software
Role: Lead Interaction Designer
Product: KACE Cloud Mobile Device Manager

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.

A screenshot of the product when it released in 2017.

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 users

A 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 users

We 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 data

It 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 Reports

Next 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.

Feature Design Example:

Search Filters

During my time on this project, we designed, built and shipped over a dozen standalone features. For portfolio brevity I will focus on a single feature: Search filters

Exploratory Research

Because of the importance of search, it was one of the first requirements that was tackled on this project.

First we gather as many pieces of "inspiration" as possible and examine what our competitors and similar applications do.

Next I start translating our list of requirements into some possible components and explore different design options.

Researching competitor products by consolidating screenshots and annotating key components.

Looking into some different solutions for complex searching.

Creating an inventory of the fields that are "must haves" for the first iteration of the search filters based on user research. This was later expanded to include almost 3x more options.

Exploring layout concepts for search for our identified needs

Settling on some options

After researching and concept-testing many search options, the final decision was between an elastic-styled search or a faceted search.

Both options were prototyped and tested via facilitated remote sessions. Participants were directed through multiple scenarios that were mapped to fully functional prototypes built with Axure's conditional logic.

Faceted Search

Pros

Easy to discover search criteria
Better for procedurally narrowing down criteria

Cons

Takes up significant vertical screen space
Requires scrolling to browse
High importance on proper IA and grouping of search criteria

Elastic-Styled Search

Pros

Less scrolling and takes up less space as options are mostly hidden
Faster for power users who know the syntax

Cons

Higher learning curve as user needs to understand the syntax
Less discoverability as options don't display until user starts typing something close to the search criteria
Harder to troubleshoot errors

Usability Testing

Please ask me in-person if you are interested in how we conducted user studies specific to prototype testing. While I cannot divulge the details of our metrics testing process at Quest, I can walk you through my personal prototype on-boarding, testing and follow-up procedure in detail.

Here is a sample script I write for myself before conducting prototype-studies. This ensures I follow the same procedures with each participant.

Results of the tests are documented in Confluence.

Collecting Feedback

Aside from collecting metrics (usually in the form of a likert scale survey between tasks) in our facilitated sessions, I also like to collect free-form comments and probe into why the user is making certain choices.

Rinse and Repeat

For this project, faceted searching won after over 10 rounds of testing and revisions.

Why Faceted filtering won:

Users new to the product can scroll through the list of options and browse to see what they would like to filter on
By organizing the facets under expanding and collapsing sections, we are able to group them by workflow and mental models and also reduce some of the vertical scrolling
The different sections makes it easier for cross-platform searching
The design scales out well to advance query building with the possibility of adding wildcards, negating and stack-grouping criteria
No need to learn any syntax

A good 30+ alternative designs were tossed in the archives as we moved forward with this design concept.

Onwards to deliverables!

Static Deliverables

Interactive Deliverables

High-fidelity mockups are finalized and and I work together with the front end team to ensure they are implemented correctly.

For complex interactions, I would modify testing prototypes and produce a screen recording like the one below to demo a sample flow.

Design Documentation

Deliverables are posted on Confluence with their change notes and linked back to their respective versioned JIRA requirements and tasks. As features are developed, I am assigned review tickets to inspect the PROD instance. Here are some examples of what supporting artifacts may look like attached to tickets.

These are to be used in conjunction with the static mockups, demo videos and the live full-feature prototype.

Recommendations for borrowing a piece of filter design from existing KACE app

High fidelity design mockup for a feature: Viewing detail of a policy

High fidelity design mockup for a feature: Associating a label with a policy

Implementation, UAT and Live Beta

I worked closely with the senior front end developers to ensure the implementation is in line with the designs. As pieces are built out, they are tested by the offshore QA team to weed out general bugs. As you can see above, many of our users (IT Admins) have large monitors, so this screenshot of the live product looks very nicely spaced out.

New features are released in a beta version to volunteer customers who receive a small subscription discount in exchange for their assistance with usability tests and their feedback. We rinse and repeat a similar testing cycle to the ones above but on the fully built product, just to work out the final knots. Notable issues and feedback are logged in a backlog and assigned story points through a grooming process.

Additionally I am assigned tickets if we receive any bug reports or usability-related feedback from the support team. Product management would author stories, reference the correct people to follow up with and assign them to me.

Completed Features

Here is a list of features I designed that are currently live in the product.

Though the course of the product design I have defined and refined design guidelines and best practices that direct the design and development of all future features.

At the time I left the project, feature designs had been tested and completed approximately six months ahead of production at the current development rate.

In Conclusion

This was an intense project with a tight deadline. I was lucky enough to be trusted with the responsibility to make all the design decisions on a very senior team of ~15 engineers, a brilliant UX writer, and an amazing Project Manager who wrangled all the politics with dozens of business stakeholders.

Outside of our product team I got to work with a great localization team, legal support and internal design org full of wonderful designers that I consulted for general UX process advice and mentorship.

We shipped this product on time, releasing the beta in less than one calendar year, following up with the GA for KACE users half a year later, opening the product to paying customers.

To end it off, here are two testimonials given to me when I left the project from my PM and a lead engineer.

“Yichen is a thoughtful, articulate champion of the designs she proposes. She carefully considers alternatives and always comes to design meetings prepared with new and useful work. She takes time to understand the market, her audience, and the impact of her designs on the people who will be using them. She listens well to feedback from her teammates and seamlessly incorporates it back into her work product.“

February 2019 -- Rodney Willis, Project Manager for KACE Cloud MDM via LinkedIn

Yichen has been instrumental in designing a consistent, powerful user interface for the KACE Cloud MDM product. She is always open to team opinions and works effectively. With her, it will be designed, hashed out, and ready for implementation on time. She is a valuable asset to any software product team.”

February 2019 -- Will Webb, Software Development Principal Engineer for KACE Cloud MDM via LinkedIn