As the Internet of Things (IoT) is expanding in accessibility and decreasing in cost per solution, the industry is seeing an influx of requests for outdoor asset tracking use cases. If you can think of an industry, there’s probably an asset tracking use case. Health care? Tracking ambulance fleets. Cold chain? Tracking shipments through delivery. Education? Tracking university shuttle buses or maintenance carts.
The majority of outdoor asset tracking projects rely on GPS to transmit asset locations. GPS already exists everywhere in consumer IoT. Applications such as Uber and Find My Friends use GPS to track your smartphone’s exact geolocation. There are trade-offs to using GPS for asset tracking applications, but it’s the most ubiquitous type of location technology.
With more companies developing outdoor asset tracking platforms, we can see the beginnings of user experience (UX) best practices forming for product designers in IoT. While designers can pull best practices from other solutions that involve mapping, they often don’t cover the complexities that IoT pulls into the equation. Take Google Maps for example–there's no question that it's a fantastic mobile and web application, but it doesn’t track moving assets, nor do locations have physical sensors reporting their whereabouts.
Another piece we must take into consideration is the user base. Often, the most impactful IoT solutions are in traditional industries, such as manufacturing and automotive. Product designers in IoT must also be cognizant of the difficulties in designing for industries and users that are not always tech-forward. Features should always be discoverable, but common UX practices may fall flat for audiences that don't use many modern platforms.
Product designers are not unfamiliar with asking questions. It is part and parcel of the job. If product designers are not asking questions to understand user needs and goals, they aren't doing their job.
Specifically for outdoor asset tracking applications, there are a few key user experience questions designers should ask to best assess how the solution should be designed. It’s not enough to just throw icons onto a map. This list of questions is not wholly encompassing of everything that should be asked during the discovery phase of a project, but rather are key ones I’ve distilled from experience after working on numerous outdoor asset tracking applications.
Nearly every tracking use case requires the use of a map, whether it’s a primary feature or an “only if needed” feature. Using Find My application by Apple as an example, we can break down where maps are and aren't as important. The only time a user needs the Find My map is if they’ve lost or misplaced their device in a different location from where they currently are. Perhaps their phone was stolen. The user could potentially track down the phone using the map on the application. If the user misplaced a device in their own home, the map isn’t useful as the location isn’t accurate to rooms, making the “Play Sound” feature the most important.
When in doubt, a designer should include a map, as there is usually some use case within the platform that warrants a location visualization.
To illustrate the importance of this question, we turn to a large parking lot, such as at an airport, for example. When a driver parks their car in a large lot, they usually look to a posted sign for the zone or aisle name they parked in. It's also common to search for the parking space number, if available, so they can find the exact location where they parked their car at the end of their trip. The driver knows their car is parked in the Purple zone in space 302, rather than vaguely remembering that they parked near the northwest corner of the lot in space 302.
From this example, we can extrapolate how in some outdoor asset tracking applications, these zones allow a user to pinpoint, rather than estimate, where their assets are. If zones are determined important, a designer should include a zone-drawing feature to allow administrative users the ability to add, name, edit, or delete zones.
To figure out this answer, a designer must look to the project specifics. The first clue usually comes from looking at the hardware the project will use and learning the elements necessary to build a location based solution. In this case, we’re focused on a project using GPS. GPS is one of the proven technologies to calculate exact locations outdoors, though it can also be used to calculate approximate locations. This shows that locations technologies don't necessary limit the decision.
Next, a designer must narrow down what the user goals in interacting with a map element on a platform are. Is the goal, “I want to use the map to show me exactly where I can find the asset so I can retrieve it?" Or is the goal, “I want to use the map to see how many assets are in a specific zone?”
If location tracking needs to be exact, it’s important to use iconography to indicate the location of each asset. Depending on the number of assets on a map, a designer may choose to cluster icons and expand when the map zooms in to avoid server load issues. Iconography should be well thought out–some projects need different icons for different categories of assets while some may take the approach of using the same icon but displaying the differences elsewhere.
In the specific case of IoT projects, icons may also change if issues arise that may impact the communicated location, such as low battery or devices not communicating.
If locations are to be approximate and rolled up into zones, it’s important to have a different map UX that doesn’t rely on the exact location of individual assets. What does this mean? Individual assets should not each have an icon, because the icon’s placement will likely be inaccurate. Aggregate numbers and expandable lists can be attached to zones and used in place of individual asset icons.
For enterprise applications in this space, it’s important to include the map data in a tabular format. This allows for intricate filtering and searching, as well as exporting to CSVs to build data visualizations or manipulate data in Excel. If the map has hover interactions, data can appear on tooltips about the asset or zone in question, but the amount of data shown is limited. Tables allow designers to surface more data about each zone or asset to take action upon without overwhelming a user.
If the locations of an asset are being stored historically or there are actions a user can take on the application such as changing a status, there may be a need for a drill down page to reveal more details about the asset.
Finally, some applications may include analytics views, especially if users are looking for trends over time or rollup counts to see the “system operation health.” It’s important for designers to work closely with users or user advocates to understand the most important analytics to surface if the feature is being included. Charts and graphs can boost the wow-factor of an application, but if they're useless to users, it detracts rather than adds from the experience.
I want to reiterate that these questions don't make up an exhaustive list for a designer working on a new outdoor asset tracking project. Rather, these are larger guiding questions to determine basic principles about the project at-hand. Designing in this space is complex and rewarding. Outdoor asset tracking has the potential to impact a wide range of industries, and therefore a wide range of users. By focusing on user needs in this space, product designers have a great opportunity to influence future UX patterns.