Sedaru Fieldforce

Background

Sedaru builds software solutions for the municipal space. They have a product called Outage that allows workers to track reports and repairs of leaks or breaks in municipal water supply systems. A key feature of Outage is the ability to show on-site field workers which valves need to be closed based on the location of the leak or break. If a valve is inoperable the software will run a simulation and show the next available valves.

Interface showing a map with work order map pins and list on side panel

The challenge

  1. Outage was originally built for large cities. These large cities required field workers to work step-by-step completing all the items in a task before proceeding. What Sedaru found when approaching smaller cities was this strict workflow was not always feasible for their smaller teams. The smaller cities preferred to complete only necessary steps so service could be restored quickly, then return and enter more details if needed.
  2. The current product was browser-based, but Sedaru had another product called Fieldforce that had native iOS and Windows applications. The Product Owner suggested that the functionality of Outage could be added to Fieldforce to take advantage of this product’s mobile capabilities.
  3. Sedaru also had a form builder product that the Product Owner wanted to take advantage of to allow customers to customize the fields that Outage included.

Approach

Because of the large scope of the design challenge, I recommended a design sprint. I facilitated and set up a Miro board for collaboration. This was Sedaru’s first time participating in a design sprint and I was happy to guide them through the process. The sprint team included a Product Owner, a UX Designer Intern, a Product Developer and a Support Specialist. We interviewed one internal expert and four industry professionals (two managers and two field workers).

Sedaru Miro board with user testing interviews

From our expert talks we learned that field workers most often start work in the field, but also pick from work items assigned to them. When choosing assigned items, priority was most important, followed by proximity and location. We made sure to include these elements in the design.

I proposed a work order-style workflow with a minimum of required forms to get work started quickly in the field.

Start a work order

The items in the task list were kept optional, to accommodate smaller cities workflows. I included checkboxes (check circles) so tasks could be marked as complete without having to enter all the details.

Tasks are check marked as they are completed

After testing with our users we learned that multiple field crews could be working on one work order at a time. For example, one field worker could be closing a valve at one end of a main line, while another is closing the valve further down the line. As a result of this feedback we plan to add more collaboration features in the next iteration to help indicate which worker is on what task.