Incrementally overcoming UX challenges of rural and urban addresses
Using context to increase the amount of work not done by users
The software platform we’ve been working on for the past few months supports delivery of services to clients in their homes. As such, knowing that the platform has a valid home address for each client is critical to our success.
We’re fortunate to be building software to support a user base that is entirely located within Australia, where Geoscape (the trading name for a public company owned by Australia’s governments) regularly publishes a geocoded national address file (G-NAF) under a permissive licence.
Making best use of this high-quality, freely-available data is no different to any other UX challenge:
- users benefit from appropriate context to interpret data, make decisions and complete their tasks;
- the best context is not always immediately apparent to us or to our users;
- users seek out enjoyable user experiences over plain ones; and
- as we make features available to users, they will be more able to provide us with direction.
To start this virtuous feedback loop as soon as possible, we aim to get something workable to users as quickly as possible.
In this article, we are going to explore how we approached incremental delivery of features related to client addresses and were able to incorporate feedback from our users to make sure we were delivering something truly useful.
Increment one: a single line of text
Our first shippable version was to setup an integration with a geocoding service that supported an autocomplete feature in our address input form. This meant that almost every residential address in our platform also had GPS coordinates for less effort than filling out the separate address fields by hand.
Once we had consistent addresses in the database rendering them in the UI is simple.
Simple as this is, this implementation meets the core business needs. It captured enough information to deliver services to the client at their home and provides some feedback as the whether the address supplied by the user is present in the G-NAF dataset.
What happens if the address is a little bit wrong?
Take this address for example:
130b Rowan St, Wangaratta VIC 3677
LGTM 🚀!
It’s well formatted, it’s as specific as it needs to be to uniquely identify a location, and the location does exist. It is a perfectly “valid” address.
It just also happens to be the address of the a local post office with PO boxes. We can’t deliver our services to the client using this address.
We could solve this in a number of technical ways: we could add another data source with these kinds of points of interest and exclude them from searches, or issue warnings if the location is “too close” to a suspected bad address; the burden of maintaining a complete list or an automated classification engine would be overwhelming. We could add a call to a point of interest API; then we’re still stuck making decisions with really fuzzy boundaries.
Historically, making decisions with really fuzzy boundaries is something computers are relatively bad at compared to people who are given enough context.
Increment two: a marker on a map
We opted to provide that context in the form of a Slippy Map with a marker placed at the location defined by the GPS coordinates returned from our geocoding service provider.
This was the first iteration on the plain text representation. It provides a significant amount of local context. Even in the static view, it’s much easier to tell that this is a plausible residential address than by the street address on its own.
With the interactive features, the user can zoom out to gain more context.
The user is now able to see the location of the address in relation to the broader region as well. With this view the user can now use spatial reasoning to determine if this client is within the serviceable region of the depot that this client is registered with.
When the map is sparse, and shows highways, rivers and administrative boundaries, it is a potential indicator that this address is outside the service area and warrants follow up.
Returning to the problematic address from earlier…
With the basic features provided by the OpenStreetMap Carto tiles, the user can see, at a glance, that this address is unlikely to be a place of residence. With this information, the user is now able to prompt the client to clarify their address, before sending a driver there for the first time.
The salmon coloured polygon under the maker may prompt the user to want to check this placement. Just using the map, the user is able to zoom in and see…
Yep! That’s a corner store with a local post office.
As these examples show, we’ve shipped an increment that provides a significant amount of context for a user to check that supplied addresses can be used for deliveries. It can answer whether this is a plausible residential address and whether it’s in the right area.
However, it requires the user to orient themselves using the landmarks of the map. Each of the depots using the platform operate out of a fixed location which we were recording location details for already. When the product owner was reviewing tickets that exercised this feature, she remarked that she didn’t know where the depot was, which she needed so that she could relate the client’s address to that of the depot.
Increment three: adding a marker for the depot
Knowing where the client’s address was relative to the depot wasn’t something any of the existing tools our clients were using could tell them, so it wasn’t obvious that this would be a valuable feature. After the one small addition to the platform in our previous increment, the product owner was able to envisage and express new stories about the context the users’ need to perform their work efficiently.
With this change, the user now has a fixed, consistent reference point. It’s also rendered with the same icon, in the same colour with the same tooltip on every map there’s a depot so it’s easy for the user to pick it out.
The user can now answer questions about the relative distance and direction of the client from the starting location of each delivery run.
Barriers to serving the client like highways, rivers or train tracks, are much easier to spot. The example of the rural location from earlier is much starker.
The large road is more imposing in this view with both the depot and the client location marker.
On the other side of town, the urban fringe may still be in the serviceable area. If there was a cluster of users in that region north of the road out of town, the user can easily anticipate which delivery runs are most likely to be appropriate.
This increment allows the user to answer a lot of questions about the client’s address. The user can now anticipate where the client fits in to the broader picture.
These individual increments have improved how the user understands the information they have entered and the likelihood that they are valid residential addresses. However, there are some residential addresses that are valid but the coordinates returned by the geolocating API are not valid for the system that calculates the route a delivery driver should take to reach the address.
The issue of unrouteable addresses was picked up during internal quality assurance on the route planning and scheduling feature which typically happens days after we’ve recorded the address for the client.
If it isn’t possible to route to the address, we can’t know when in the route that client should be served, how far the the driver will have travelled, or how long it will take them to complete their deliveries. These are critical data points for understanding whether all safety guidelines will have been met.
Increment four: checking routability and distance
The final change we’ve made is to call to the driving route API to test that the location is usable by other features in the system. Importantly, this allows us to provide that feedback when the user is still in the process of setting up the client, not several days later when they (or another user) is trying to complete another task which depends on this information.
By providing the distance to the client and driving time, we also support the user in assessing whether it will be feasible to deliver to that client from the selected depot and meet all safety guidelines.
Wrapping up
The progression of this feature as separate shippable increments and the value they deliver can be broken down in to four stages:
By delivering small useable changes, each of which provided a separate piece of additional context on a critical piece of data, not only did we make the users’ work easier and more enjoyable, it provided the entire delivery team with additional experience to lean on when discussing users’ needs. This new experience allows the team to envisage and prioritise further improvements to the user experience.
Each time we improve the user experience by providing additional context, we reduce the amount of time users have to spend understanding the data we are presenting, allowing those users to focus on their core business.
