An all-in-one hub for device management
Bridging a gap
In the past, Windows device management features were reserved for devices that were enterprise-managed - or, in other words, reserved for entities that could pay lots of money. Enterprise-managed devices are devices, such as desktop computers, are managed by another entity, usually the company you work for. These management features include WiFi settings, device performance and health, factory reset and more.
In 2017, these features were open-sourced to the public through the Windows IoT Azure Device Management Client Library. This library allowed developers to add these aforementioned device management features to their Azure-connected Windows 10 IoT Core devices.
However, at that time, there was no scalable, out-of-the-box interface or platform for using this library. Developers had the options of 1) working only in JSON or 2) using a Dashboard tool that can only operate one device at a time.
Developers could only use either one of these tools for their device management needs, neither of which were ideal solutions.
Bringing it together
Because this library was ideal for cloud-connected devices, it didn't make sense to keep these device management features in their own ecosystem. So when the idea to integrate these features as part of Azure's Remote Monitoring service came up, I was picked to lead design from the Windows device side for this project.
Our high-level goals were to:
Save developers the trouble of hacking together their own IoT device management solution.
Allow developers to manage their devices all from one platform.
Allow developers to create profiles, or saved instances of their device management settings, in this portal. Doing so would allow developers to fix multiple device issues by modifying just one profile
I led the design of this experience and collaborated with a designer from the Azure IoT team to make sure that my designs aligned with the overall look and feel of the Remote Monitoring platform.
I also worked alongside the lead developer for the client library and two product managers.
Even before thinking about how these device management features would integrated into the Remote Monitoring platform, I needed to understand the functionality of each option. I used the Dashboard sample to help me understand the intent and requirements of these features (i.e. device information, diagnostic logs, etc.) as well as their associated actions. Once I did that, I laid them out in a way that I could understand them (versus the Dashboard sample).
Wireframes showing the different interactions and functionalities to consider for each of the 11 different device management features.
When it came time to think about integrating these features into the Remote Monitoring platform, I added a "Profiles" tab, which would allow users to modify respective profiles which could help modify devices at scale.
Leveraging the Remote Monitoring toolkit, I made the decision to design this integration in high-fidelity, as lower fidelity mock-ups were not translating well to stakeholders. The toolkit helped to solidify a number of design decisions.
A pop-up wouldn't work with the Remote Monitoring toolkit, so I replaced the connector and provider add functionalities with toggling options, which scaled much better than a pop-up.
With the upfront work, research and iterations, the profile tab came together.
View the prototype here.
Errors surfaced in two forms for this feature. The first form was errors caused by profile configurations. The second form was errors that resulted from memory constraints in the device twin.
1. Errors caused by profiles
2. Device twin memory constraints
With errors caused by profiles, a developer could either update or create a new profile.
And from the devices tab, devices could be either individually selected or selected in bulk (from the filters) and have a new profile added, removed or modified.
Memory errors were constraints from the development side where only a certain number of features could be added before a threshold was reached. Initial explorations are shown below.
A bar near the bottom would be able to give developers a rough estimate of how much space was still available on the device twin.
A toast notification would show when the device(s) are not in sync with a device twin.
Other errors could derive not from lack of memory, but from something like incompatible app packages.
A good effort
Unfortunately, due to factors outside of our control (e.g. collaborators leaving the company), the project ultimately did not ship, even though - through different customer interviews - it was validated as a helpful new feature.
Had the project been on its way towards shipping, I would've:
Put together a task-based usability test to make sure that developers knew how to navigate profiles and understood the concept. This test would include error handling as well.
Based on the results of the usability test, I would see how we could improve error handling, both from engineering and design perspectives.
Not all was lost, however. This was one of the more technically-complex projects I've worked on to date. From this experience, I've learned to trust my instinct when it comes to asking questions - to not just assume anything, especially for a project like this one.