The initial focus of the ADP was the map and geospatial data to help our users visually inspect their assets. We then shifted focus to Per Property Reports – the vehicle for extracting that data from our platform. Shortly after, it became clear that a focus on assets was the missing piece. Our users do care about geospatial data, but they only care about it because of how it impacts their assets. Shifting our focus to support asset management could be the key to helping our customers extract the most value, while simultaneously making the product stickier – ultimately increasing the lifetime value of the platform.
User Goal
Users want to search, sort, and filter their assets based on key attributes to easily sort, prioritize, and assign during triage.
Business Goal
We want to provide value and insights about the things that are users care about the most.
How might we help our users search, sort, & filter their assets?
Currently we let our users import their assets via csv. We require that they provide a latitude, longitude, and an asset name, but outside of those attributes we have limited visibility into what our customers are uploading. Even if there are shared columns across datasets, our current process for importing data prevents us from establishing any relationship between related fields. We created groups as a workaround, but I don't believe this is a scalable solution. This impacts sort, search, and filter capabilities because the data is unstructured and lacks consistent formatting. This also has an impact to the ui/ux because there is no way to consistently present inconsistent data.
Hypothesis 01
If we build more robust data mapping functionality our users will have more granular control over how they triage and assign assets. We hope this will increase the speed of the triage process and improve overall customer satisfaction.
Hypothesis 02
If we build more robust data mapping functionality we will gain a better understanding of what our users care about and discover new ways to add value to our customers. We hope that this will expose opportunities for new features and product offerings – exposure reports, asset reports, etc.
Simply offer more options our users can map to. We don't necessarily know which attributes matter most to them but based on a review of sample data sets we can safely conclude that there are at least a few key attributes that would make sense (see below). Our understanding is that customers typically export their data from a single source therefore their data, in most cases, should be consistently formatted. With this in mind we believe the addition of some sort of "Auto Mapping" functionality, which would automatically detect column headers and map them to their respective attributes, should result in a fairly seamless asset import experience.
Level of Effort
Medium
Asset Attributes:
Automatically appended by:
uuid
date created timestamp
address
Possible Requirements
n/a
Wireframes
In this view you will see the additional attributes that the user can map to. You will notice that only the lat and long are required (asset name should be too). This gives the user full control over how they build their database. If we do a good job of demonstrating the value of mapping additional attributes then the additional work required to map theses fields shouldn't be an issue.
We can also mitigate the amount of work required to map additional attributes by implementing "Auto Mapping" functionality. Detecting column headers and remembering user preferences will prevent the user from having to manually map each time. In this mockup POLICY_NUM_USA should always map to Policy #.