Trimble is a long-established and well respected company in the geospatial and surveying spaces. Their hardware and software is used by people all over the world to collect location data about the world that surrounds them.
The team at Trimble was in the process replacing a legacy twenty year old solution that relied on custom hardware and software. The new version supports modern mobile devices and tablets, paired with a multitude of hardware configurations.
I was enlisted to design a major feature: allowing field workers to capture physical features they are not able to get close to using a laser rangefinder.
Some of the different hardware configurations available
I worked with product owners and managers to understand the previous implementation of laser rangefinder support. During the process we realised that we were no longer constrained by the technical limitations of 20 years ago (e.g having to use a stylus) and that this opened the opportunity to do things differently. As the discovery phase progressed, I discussed my findings and assumptions with the development team to understand the technical feasibility of proposed solutions and to be aware of any potential limitations.
Understanding the users
During the discovery process three main findings emerged:
- Field work is hazardous work. In some cases users are unable to get physically close to the features they have to capture because of a physical barrier or a dangerous animal. Instead, field workers can make use of a laser rangefinder and use triangulation to capture the location of a feature.
- Field workers are not technical staff and don't have (nor need to have) a deep understanding of the technicalities of GIS.
- Depending on the setup, users might not be hands free or have their movement constrained by the gear they are carrying.
These generated the following insights:
- Any proposed solution had to be self-explanatory.
- Efficiency is important for field work users. If they have no hands free we should minimise interactions with the UI.
Different gear, different use cases
Laser rangefinders use different methods for data collection, and this has implications for a user workflow. Some models capture the distance to the target and the compass direction of the target; others capture only the distance, often requiring two measurements to get an accurate result.
The two main types of laser rangefinders
Based on the two different types of laser rangefinders, I identified two main workflows we have to cater for and documented their steps. The flowcharts below were shared with the managers and development team to ensure my assumptions were correct.
User interface & experience challenges and solutions
During the research phase managers and I agreed that we should be using the map for interactions and feature selection. One of the UI challenges was how to integrate this new piece of functionality into the existing map view. The solution was to abstract the new functionality into a new step-by-step component that was triggered from the map view. This allowed for more flexibility in the UI and also future reusability.
Guiding the users
From a UX point of view, we wanted to guide the users during each step of the workflow without overwhelming them with instructions. The solution is a small description, at each step, of what action(s) users need to take. We also proactively guided users on how to physically position themselves to get the best location accuracy, as low accuracy increases the number of steps needed to capture the location of a feature.
Recovering from errors
The team and I identified a few scenarios where users might not be able to capture an offset due to external factor for example, when they are near a large metal object that interferes with the GPS signal reception. These scenarios require user input, so I came up with an unobtrusive solution a warning message that can be tapped to reveal more information where we inform users something is not quite right and provide guidance on how to fix it.
Onboarding the new feature
We wanted users to get the most of the new functionality and inform them of the different options available. I suggested onboarding users to the feature by having a set of swipeable cards that only appears when they are about to capture their first offset.
Testing assumptions with interactive prototypes
To test assumptions, I created an interactive prototype of both workflows and shared it with managers and developers. This proved invaluable to catch some edge cases and to guide the development team with their development efforts. This prototype was also used as an early demo of the feature at a Trimble gathering that included upper management and sales consuŌtants.
Screen recording of the interactive prototype.
The new functionality helped to seal a deal even before the official release, with an existing customer deciding to upgrade their software and hardware after experimenting with an early release. Internally, the feedback was very positive and speaks for itself.