The first article in our four-part IoT UX series discussed the importance and complexity of UX in Operational Device Management (ODM). In our second article, we begin addressing this complexity with solutions we have found most effective here at Machineshop. The UX solutions described in this article will be grouped into three categories: designing for scale, intuition, and flexibility.
Designing for Scale
IoT is massive and rapidly growing. As blunt as it sounds, an IoT device management solution that can’t handle scale can’t handle IoT.
Device monitoring is a huge aspect of IoT which is why one of ODM's core functionalities is this ability to effortlessly monitor the health and goings-on of your devices. Take note that we said monitoring should be effortless. Monitoring a few devices is always trivial, but thousands of devices isn’t. Scale doesn’t always make information more complicated, but it does make it harder to digest. You’ll know your IoT management solution can handle scale if information grows in size, but the way that information is presented and consumed does not.
The way MachineShop EdgeIQ Platform solves this problem is by having a dedicated dashboard filled with widgets specifically designed with UX in mind. Our widgets have two priorities: give accurate impressions and lead the user into action. We’ll discuss the latter priority in the next section. Our widgets are also broken further into two different categories: totals and updates. The user doesn’t need totals on each data point or updates on each data point; using these two different categories can help your customers understand their information in a way that makes sense for them. Data like devices’ current online status is more important in terms of totals; whereas, errors that have recently occurred are more important to be viewed and handled as they happen, regardless of how many exist. Monitoring also requires specificity. If certain kinds of devices are not important to monitor or if certain error levels are non-critical, filters should be available to reduce noise in the monitoring process.
Monitoring devices allows for aggregation, but how does one configure devices at scale? No one has the time or resources to individually configure devices, especially if they’re located across the globe. The process of getting thousands of devices onboarded, configured, and then orchestrated to satisfy complex business requirements is laden with steps and tedious detail. One of our biggest priorities at Machineshop is to make this process simple. The first step is how we handle onboarding; getting thousands of devices registered can be tackled with a single CSV file. The user can list the unique ids in the CSV and upload the file; our EdgeIQ Portal will then walk them through a process to quickly identify the devices types, third-party integrations or other features of the devices. Once the user has determined the configuration details, their devices will be sent their configuration. That’s it. That’s why we call it a one-touch configuration.
Business requirements are always changing. If the customer needs to push more changes to their devices, they can do so without the need for another CSV file. Using filters to find the devices that need changes, they determine the configuration changes, and that’s it. One-touch for onboarding and one-touch for added configuration changes (when necessary). Our policy-based orchestration system also allows for devices to kick off complex sequences and change or add more policies in one step as well. Managing IoT requires managing at scale. An important principle in writing code is, “Don’t repeat yourself.” The same should be applied to how your customer gets their work done, and utilizing UX in your management process is crucial to making that happen.
Designing for intuition is tricky. What is intuitive for one user might be non-obvious for another. Despite this difficulty, taking intuition into account is still crucial. In this section, we’re going to tackle a few things that we think make systems intuitive for most users.
Information Alongside Interaction
In the previous discussion related to widgets, we mentioned that a widget should always lead the user to action. This follows for nearly everything in a ODM system. Information is only as useful as the ability to do something with that information, and that means interaction. A widget that shows offline devices should have a button that allows for running bulk troubleshooting operations. A list of recent errors should also have associated actions for running diagnostics or issuing relevant commands. Monitoring the actions triggered by policies should provide data on the actions that are carried out but also the policy and device that triggered the action in case they need to be configured. Intuition is intrinsically tied to motivation; providing information with interaction is an effective way to satisfy your user’s intentions.
Action with Feedback
As discussed in the previous article, action is only as good as the feedback generated from said action. A good user interface should have a balanced amount of feedback, just like a human conversation might include head nods of agreement. Configuring and managing IoT often means that actions take time to be carried out, so your ODM system should have UI elements that give nods to the user. Even things as simple as loading spinners, message pop-ups that convey status information or links that point the user toward more information make a big difference. Configuration capabilities in IoT are expansive, and each of these actions must be paired with feedback to keep your users aware and informed of what is happening with their IoT.
Information With Context
Management capabilities are diverse, but they can also be complex. Complication is often the result of improper context. Explaining to a child the purpose of a screwdriver would be ridiculous without the use of a screw. Context makes things simple. A principle of UX is to use appropriate context to keep your users informed. Your ODM solution should always do the same.
Information should come equipped with accurate labels. If the user wants to attach a policy to a device, the configuration form should suggest policies on each keystroke. Provide discreet but numerous “info blurb” icons that reveal more context should the user decide to click them. Separate configuration steps into logical groupings so as to ensure no step goes ignored, and so that the flow across the process feels intentional and transparent. IoT might be diverse and detail-oriented, but providing information with the appropriate context can enable and empower your users.
We’ve mentioned time and time again how IoT is diverse. It turns out that the needs and wants of IoT customers is too. Combine your customers’ needs with UX best practices, and you’ll end up with an ODM system that is customizable and adaptive to best ensure each and every customer has the IoT management experience their business requires.
Sometimes the user doesn’t need certain information. Managing IoT can be overwhelming, but your ODM system shouldn’t be. If any aspect of IoT management isn’t utilized by a customer, ensure their instance of the ODM system doesn’t visibly show it. The ability for your product to toggle the visibility of certain sections can make a world of difference for your customers. Content that isn’t necessary can be hidden and enabled whenever business requirements change. When a management system is catered to the exact needs of a customer, that customer will have a better experience. If a customer doesn’t use third-party integrations, hide that capability. If a customer doesn’t care about device cellular data usage, remove that widget from the dashboard. Toggling the visibility of content, especially widgets in the dashboard, can reduce noise and streamline your customer’s management and monitoring experience.
The devil is in the detail, especially when an overzealous display of detail is the reason a user is confused. If I were to explain the game of soccer to someone, I’d start by mentioning how a goal is scored. I would avoid describing the complexity of the “offside” rule until it was absolutely necessary. Drilling down into detail has a time and place, and the path to that detail should be readily available for the users that seek it out but obscured ever so slightly so as to avoid confusing users that don’t need it. Certain IoT management processes can become exceedingly granular, but those details shouldn’t overwhelm users.
For example, Machineshop’s orchestration system is powerful because of the wide array of capabilities our policy system supports. Do you want to send an HTTP request when a device’s online status changes? Want to schedule a report to be relayed to a third-party integration every other day? The list of capabilities is extensive and detailed, and something we learned early on in developing this policy-creation system is how these policies need to be created with a top-down approach. Is the policy scheduled or reactive? What is the scheduled date and time for this policy? Should the policy be activated more than once according to a time interval? Should there be a maximum number of scheduled activations? This path through scheduling policies is an example of how UX reveals detail only as the detail becomes necessary. Your ODM system is powerful, but it isn’t a blunt instrument: let your users paint with broad strokes first, and precise flourishes second.
Our final conversation in the flexibility section is about catering to your customers’ preferences. We’ve already discussed reducing noise and revealing detail only when it’s necessary, but we’ve yet to discuss the additive components of flexibility. How does your ODM system give your customer things? Is the dashboard configurable with widgets that customers can create and customize to their liking? Is the display of data itself configurable? In other words, can the user look at their list of devices in a table view, card view and graph view? Can the user customize the ODM system with their company’s branding details? Can the user create custom tags to group and organize their devices, and can they create aliases for common words that describe things like network settings? Your customer wants to manage and monitor their IoT, and they will undoubtedly have preferences in how that happens. An ODM system should do everything it can to make the user feel at home with their IoT.
We laid out three crucial areas of UX to keep in mind when building a ODM system. Each of the areas feature examples of solutions we’ve discovered and implemented at Machineshop, but they’re by no means the be-all end-all. These takeaways are best utilized as questions, not answers. Does your system handle scale? How does it make itself intuitive? How can it be more flexible? The answers you’ll discover are important, but asking the right questions is crucial.
Stay tuned for the next piece in this series on the future of IoT, and more specifically, how your ODM system handles maintainability, security, and more.