Trucks were disappearing. Operators had no way to know until it was too late. Designed a geofencing system from scratch — for a global user base.
Fleet operators couldn’t monitor large fleets continuously. Route deviations and vehicle thefts were going undetected for hours — sometimes until trucks had already crossed borders.
A map-first geofencing system built from scratch — draw a zone, set alert rules, assign vehicles. Alerts fire across all channels simultaneously the moment a boundary is breached.
Real-time breach detection replaced hours of lag. Manual timesheets eliminated. Driver-operator calls reduced. Adopted across the client base and expanded beyond its original scope.
For fleet operators managing large vehicle fleets across multiple countries, route adherence is not just an efficiency concern — it’s a financial and security one. Fuel siphoning during unauthorised detours was a documented and widespread problem. In several markets, particularly across Africa, truck theft was rising sharply. By the time operators became aware of an incident, vehicles had already crossed borders.
The existing platform gave operators visibility into where vehicles were. What it couldn’t do was tell them when something had gone wrong — proactively, in real time, without someone actively watching a map.
Geofencing — virtual perimeters that trigger alerts when vehicles enter or exit defined zones — was the solution the market was asking for. This feature needed to be designed from scratch, for a global user base, with no prior design reference to build from.
Fleet operators couldn’t monitor large fleets continuously. Manual tracking was feasible for 10–15 vehicles; for fleets of 50 or more, it was effectively impossible. The gap between “something went wrong” and “we found out something went wrong” was measured in hours — sometimes days.
The business opportunity was direct: a well-executed geofencing feature would address the single most-requested capability from enterprise clients, differentiate the platform from competitors, and open new use cases around route management, client SLA compliance, and time-at-location reporting.
The risk of getting the design wrong was real. A complex creation flow would mean operators wouldn’t use it. An imprecise drawing tool would produce geofences that triggered false alerts or missed genuine breaches — eroding trust in the feature before it had a chance to prove its value.
I was the only designer on this project, responsible for the complete experience from research and goal setting through to visual design and engineering handover.
I worked alongside a team of four engineers led by a senior architect, with business analysts providing user insight and product and project managers driving delivery timelines and stakeholder coordination. All design decisions were mine to own and defend.
This was also my first experience designing for a genuinely global user base — fleet operators across Europe, the Middle East, and Africa — with meaningfully different operational contexts and infrastructure realities.
The feature had to work across variable infrastructure. Fleet operators in markets like Africa were operating on unreliable internet connections, using basic hardware. The geofence creation flow had to be tolerant of latency and simple enough to complete quickly — every unnecessary step was a risk.
The map interaction model presented a precision problem with no obvious solution. Drawing a geofence by dragging on a map sounds intuitive — but specifying an exact radius or boundary using a mouse on a standard monitor was frustratingly imprecise. This wasn’t a known problem at the start of the project. It surfaced during user testing and required a design response mid-process.
Scope was actively managed. Border geofencing was identified as a high-value use case but deferred to a later phase. Shipping shape and route geofencing first allowed the team to deliver core value without compounding the interaction complexity of the initial release.
The core assumption was wrong — and the design depended on correcting it. The team had assumed fleet managers were actively tracking vehicles throughout the day, checking in with drivers regularly. The reality for large fleets was the opposite: operators were largely reactive, dealing with issues after they had already escalated. The entire value proposition of geofencing rested on this insight — alerts only matter if you’re not already watching.
Precision mattered more than simplicity in creation. Initial user testing of the drawing interaction revealed that operators couldn’t reliably create geofences of the right size or in the right location using mouse-drag alone. The solution — surfacing radius, latitude, and longitude as editable fields immediately after drawing — added a step but transformed the accuracy and confidence of the creation flow.
Geofencing unlocked use cases the product team hadn’t fully anticipated. Beyond theft and deviation alerts, operators identified time-at-location tracking, route adherence reporting, and client SLA verification as immediate applications. These weren’t edge cases — they were core business needs that the feature addressed as a byproduct of its primary design.
The design was structured around the CRUD model — Create, Read, Update, Delete — as the operational framework for geofence management. Every interaction decision was evaluated against whether it made these four operations as fast and error-tolerant as possible.
The creation flow was the most critical to get right. The initial approach — draw, name, save — was clean but insufficient. Post-testing, a precision layer was added: after drawing, operators see the exact parameters of the geofence (radius, coordinates) and can modify them numerically before saving.
Alert configuration was built directly into the creation flow rather than housed in a separate settings section. Separating alert rules from geofence creation would produce a two-step process that operators would frequently abandon at step one, leaving geofences without any active alert logic.
The final solution gave fleet operators a map-first geofence management experience with three shape types — circular, rectangular, and polygonal — and a dedicated route geofence mode.
The creation flow guided operators from drawing to configuration in a single continuous interaction: draw the geofence, confirm and adjust precise parameters, set alert rules, assign relevant vehicles, and save. A geofence list view enabled ongoing management without returning to the map.
Alerts triggered across all available channels simultaneously — web app notifications, email, SMS, and mobile push — ensuring operators received breach notifications regardless of what they were doing.
Business analysts were the primary bridge to the user base. I worked closely with them throughout research and testing phases, using their client relationships to validate design decisions that couldn’t be tested directly with operators.
With engineering, the precision interaction update — adding editable coordinate fields post-drawing — required a mid-process negotiation. I presented the user testing evidence clearly, framing the change as a risk-reduction measure rather than a scope addition. The architect and I worked through the implementation approach together before the decision was formalised, which meant the change was absorbed into the sprint without significant disruption.
Stakeholder presentations were structured around use cases and business outcomes. Framing geofencing in terms of theft prevention, SLA compliance, and fuel savings — rather than UX improvements — ensured that commercial and product leadership remained aligned on the value being delivered.
The most important design decision on this project was the one made mid-process: adding the precision layer after user testing exposed the problem. The temptation when a user test surfaces an issue late in wireframing is to minimise it or defer it. Here, the evidence was too clear to ignore and the cost of getting it wrong was too high.
Designing for a global user base for the first time sharpened my thinking about infrastructure assumptions. Features that work smoothly on fast connections in modern offices can fall apart in the real operational environments of the users you’re designing for. That awareness now informs how I frame design requirements at the start of any enterprise project.
The geofencing feature surfaced use cases — SLA tracking, time-at-location reporting — that the original brief never mentioned. Staying close to operators throughout the process meant we caught these early enough to design for them. It’s a reminder that the best product decisions often come from listening, not just executing.
