Tread – Polygonal Sites

I led product design at Tread, a construction technology startup that offered trucking companies a dispatching and driver app. When dispatchers originally input construction sites into Tread, the geofence defaulted to radial. In collaboration with my product team, we conducted research and implemented customizable geofences to better represent the shapes of construction sites on Tread.

User research

End to end product design

Visual Quality Assurance

8 weeks

Project Context

To better understand why site geofences are important, it's helpful to understand how a "cycle" works in trucking. Picture a dump truck, it's bed is empty, and it's driving into a rock quarry to get loaded up with material. This is the start of a cycle. The truck idles under an excavator while the excavator lifts and dumps crushed rock into it's bed until the truck is full. The truck then drives to an on-site scale house to get weighed, and a ticket is printed off indicating the weight of the material being hauled. The driver leaves the pick up site and drives to the construction site. Once there, the truck dumps the material off and gets her ticket signed off by one of the project supervisors. The truck then exits the construction site and drives back to the pick up site; completing a cycle and ready to do it all over again.

A cycle, as a unit of data, contains a lot of actionable information for people connected to a construction project. Not only are cycles used for payment and billing purposes, but the time stamps associated with a cycle are used to understand how a project is progressing against it's timeline. Armed with real time cycle data, supervisors and project admin know exactly when a project starts falling behind and can take action: for example, calling trucks that are lagging and telling them to pick up the pace, or calling in more trucks to hit the deadline.

A few months before, my team and I had conducted remote contextual inquiries with a handful of dispatchers. We had mapped out their process and the gaps between what they did versus what's in Tread. We heard how sites were input, and how it fit into a dispatcher's overall workflow. I also relied on past insights captured in our research database, internal stakeholder interviews and a benchmark analysis to better understand the problem.

The first iteration of site input let customer's set up radial geofences around a site. They were able to define the size of the radius: for example, they could input a site with a 500 meter geofence radius around it. A lot of our customers took issue with this: radial geofences do not match the shape of most construction sites. Additionally, for large sites radial geofences were more likely to skew the cycle times because they had to input a very wide radius to cover the site. For paving jobs, the paver units operated on roads, often side by side with other paving units.

Geofence accuracy is used to determine which trucks go to which paver, and radial geofences might overlap between pavers and skew the data. Besides the problem with inaccurate geofences, a second, workflow based issue with site creation in Tread came up in our research. The Tread app had one section for dispatching, and a separate section for site creation. Dispatchers could type in a site address while dispatching, but they could not configure a geofence; that had to be done on a separate page called Sites.

Based on these problems, we narrowed our focus down to two problem statements to guide the design exploration: (a) How might we let dispatchers create site geofences that matched a site's actual outline? (b) How might we enable dispatchers to set up sites with geofences in context to creating a new job?

Me and my product manager held joint sketching sessions to generate some ideas against her list of product requirements for Sites. We then measured each concept against the objectives of what we thought would make for a successful design. We prioritized speed of site creation and clear, surfaced actions and/or labels.With a prototype in hand, we validated the concept we landed on with 6 customers. We chose to meet with dispatcher's from our enterprise, mid-market and small business segments to understand how their feedback changed based on the size of their operation.

One problem we heard was that explicitly selecting an address: whether that's by searching on an address or dropping a pin, didn't work well for a lot of sites. Construction sites usually didn't have an address at the time of job creation. A job site might be an open field, where work is scheduled to take place but hasn't, and specifying where that field can be was challenging. One customer talked about how he could use nearby landmarks; "Two blocks north of the Walgreen's at John Street." Another one of our customers, a Texan, joked about how sometimes his site guys would just tell him the job site is "Over yonder."

We considered polygonal sites a successful release if it checked off each of the three goals we had set for it at the outset of the project: increase the number of new sites created with geofences, increase dispatcher efficiency by keeping site creation in context to job creation, and unblock sales opportunities with new verticals like paving companies. Initial feedback was mostly positive after release. I noticed a pattern where we'd receive a compliment, and then shortly after a new fix request. For example, from one of our customers: "This is really cool. I'd like to see the mobile version in action as well to get an impression of how site personnel would place orders. Being that most people would be using an iPad, and being that the iPad versions of Tread hasn't been optimized yet, it may create some issues."

We heard positive things from our sales team as well. We had signed a new paving customer, and the first site that they created used a long rectangular geofence to capture the outline of the roadway (see above). Before release ~50% of all jobs created in Tread used sites with geofences. After release 80+% used sites with geofences. With the increased usage of site geofences, this meant our cycle time reporting data was more thorough. With thorough data, cycle time reports could be interpreted more accurately and with a more holistic picture of how a project progressed.