|
|
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.
|
|
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
For portfolio brevity I will focus on a single feature: Search filters
Exploratory ResearchBecause 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. |
|
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.
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
|
Elastic-Styled Search
Pros
|
Usability TestingPlease 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 FeedbackAside 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 RepeatFor this project, faceted searching won after over 10 rounds of testing and revisions.
Why Faceted filtering won:
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. |
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 FeaturesHere 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.
|
