Case study · B2B GPS tracking · Web and mobile · 14 weeks
PEEQ is a GPS tracking platform for business teams: see every device on a map, set location alerts and replay where things went. I designed how teams create geofences and manage their devices, for operators who are not mapping experts.
01 · Overview
PEEQ tracks devices (called POMs) in real time. Teams see them on a map, read sensor data like temperature and speed, set alerts, and replay movement history.
Mostly businesses. A typical account managed fewer than 20 devices, run by an operations person who knows the places that matter but not their coordinates.
I designed geofence creation, device management with groups and status, device details and alert settings, on web and mobile.
02 · Problem
Both problems came from the same place: the interface followed how the system stores data, not how people think about their work.
Gap 1, geofences. Alerts depend on exact boundaries, so the backend needs a precise latitude and longitude. Operators think in places: “the school and the streets around it.” A form that asks for coordinates makes them leave PEEQ, look the place up elsewhere, and copy numbers back.
Gap 2, devices. Devices were shown as a flat list. Each row carries a name, a status, a battery level and an address, and with similar rows people lost track of which device was which.
03 · Research
In observation, people spent unnecessary time searching for specific devices and struggled to read device status at a glance. With a small number of sessions, I treat these as strong signals to design around, not as measured rates.
| Insight | Evidence | Design rule |
|---|---|---|
| People work visually, not technically | Stakeholder sessions; places named, never coordinates | Set geofences by place. Address or map in, coordinates computed behind the scenes |
| Confidence comes from seeing it | Fear of wrong boundaries in high stakes alerts | Show the boundary before saving. The circle appears on the map as you type |
| Fewer steps feel safer | Product goal; alerts trigger real responses | One panel, smart defaults. Advanced settings stay out of the way |
| Flat lists lose orientation | Observed searching for devices | Group by context. School, home, route: groups people define |
| Recognition beats recall | Observed trouble reading status | Status on every row. Online state, battery and location without opening the device |
04 · By the numbers
PEEQ had no usage analytics for these flows during the project. So I used two methods that work from the design itself: a Keystroke Level Model estimate of task time, and a count of the configuration load the alert system creates.
The baseline is a coordinate only form, the direct translation of the backend requirement. Steps shared by both flows (name, devices, shape, save) are left out. The bigger win is not the 6.5 seconds: it removes two app switches and a copy and paste of numbers that can silently be wrong.
| Step | Coordinate form | Address + map |
|---|---|---|
| Decide where | M 1.35 | M 1.35 |
| Find the place | switch to a map tab, re-orient, type 15 chars, wait: P BB H M K×15 K R = 8.53 | click field, type 15 chars, wait: P BB H K×15 R = 6.90 |
| Get coordinates | right click, copy: H P BB P BB = 3.00 | pick suggestion: H P BB = 1.70 |
| Bring them back | switch tab, click field, paste: P BB P BB H KK = 3.56 | not needed = 0 |
| Check it | M 1.35 (no map) | M 1.35 (sees the circle) |
| Set radius | P BB H M K = 3.33 | P BB H M K = 3.33 |
| Total | 21.1 s | 14.6 s |
Operator times from Card, Moran and Newell: K 0.28 s per keystroke, P 1.1 s to point, BB 0.2 s click, H 0.4 s hand to keyboard or mouse, M 1.35 s mental preparation, R 1 s system response. A model of an expert user without errors; real users will be slower, and errors in pasted coordinates are not counted.
Each device has 9 alert types: light, temperature, speed, start moving, geofence entry and exit, low battery, Bluetooth proximity and power. Set one device at a time, a 20 device account faces 180 settings. That number is why groups and “apply to all” matter, and why the remaining per device setup is the first thing I would fix.
05 · Geofences
Location takes an address or coordinates, so experts keep their shortcut and everyone else types a place. The radius and shape draw a live boundary on the map before anything is saved. On mobile the map takes the full screen and the form gets out of the way.
06 · Devices
Each row shows a device icon, online status, battery level and last known area, so people can scan without opening anything. Search, filter by type and sort sit above the list. On mobile the list becomes a bottom sheet so the map stays visible.
Teams group devices by what matters to them, like a school route or home base, and act on a whole group at once: ping, refresh or set alerts. The empty state explains what groups are for before asking anyone to make one.
Info answers “where and how is it now,” Replay answers “where has it been,” Alerts answers “when should I hear about it.” Sensor readings and geofence status sit at the top, and the update interval can be applied to all devices in one tick.
A three step import, upload, verify, choose a plan, so a team can add a batch of devices from a spreadsheet instead of one by one. The individual path stays one click away.
07 · Expert walkthrough
I reviewed the designed screens as a first time operator setting up a geofence alert, and rated each issue on Nielsen's severity scale. This is an expert review of static screens, not a usability test.
| Screen | What the operator meets | Why it matters | Heuristic | Sev. |
|---|---|---|---|---|
| Device list | Online status shown only as a green or red dot | Colour alone fails for colour blind users (WCAG 1.4.1); add a shape or a word | Accessibility | 3 |
| Alerts | 9 alert types set per device; only the update interval has “apply to all” | Up to 180 settings for a 20 device account | Flexibility and efficiency | 3 |
| Device list | Rows with the same name and address in the design | Sample data hides the real recognition problem; test with realistic names | Recognition over recall | 3 |
| Geofence | Radius typed in km rather than dragged on the map | The map shows the boundary but can't be used to adjust it | Direct manipulation | 2 |
| Geofence | Only square or circle shapes | Real areas like a school campus are irregular; a polygon would fit them | Match with the real world | 2 |
| Device detail | “Last seen” in UTC −10:00 Adak while the device is in Florida | People have to convert time zones in their head | Match with the real world | 2 |
| Device detail | 49.3 °C shown with no warning state | Readings have no thresholds, so a problem looks the same as normal | Visibility of system status | 2 |
| Bulk add | Upload CSV with no template or format hint | People can't know the columns until import fails | Error prevention | 2 |
| Everywhere | “POM” used for devices | A product term people must learn first; “device” would read instantly | Match with the real world | 1 |
08 · What I'd test next
| Question | Task for 5 operators | Measure |
|---|---|---|
| Is place first faster in practice? | Set a 2 km geofence around a named address | Time, errors, against the 14.6 s estimate |
| Can people find a device fast? | Find the device that went offline most recently, out of 20 | Time to find, wrong taps |
| Is status readable without colour? | Same task in greyscale | Success rate, compared with colour |
| Do groups reduce setup? | Turn on geofence exit alerts for every school device | Clicks with groups vs one by one |
09 · Reflection