Field Observation, Design Workshop, and Multiple Assign Feature

Summary

After conducting field observations and interviews, it became apparent that the way we had originally set up Active Oversight (AO), was not viable in the real world. Our projects demand the flexibility of multiple people working together to complete their tasks. I found that our field users worked on teams with foremen and crew chiefs both assigning tasks in tandem.

Discovery: User interviews, field observations, and inviting our customers into our office for a workshop broadened our understanding of the field users’ working environment and workflow.

Solution: The solution included understanding the ability to assign multiple people to a task and the ability to assign on mobile.

Design: Design workshop, two rounds of ideation, and two rounds of testing.

Outcome: One month after launch, there had been over 1,200 tasks assigned to multiple people.

Overview

Team: Product Manager, Co-designer, Developers, Customers

Role: Research, Facilitation of Design Workshop, Wireframes, Design, Prototype & Usability Testing

Outcome: Ability to assign on mobile and the ability to assign more than one person to a task.

Timeframe: 4 Months

Research: 12 users

Discovering the problem

Interviews

When I started interviewing users to better understand their workflow, the challenges became obvious. Our users couldn’t make AO work in with their old work flow, so they weren’t using it as prescribed. Our software was causing frustration in the field, and a low product adoption – not good. The following were the items I discovered.

Project Managers Still Doing the Work

When conducting phone interviews with field users, I discovered they were doing the work the same way they always had. AO was just one more step for them. The crew members were taking photos on a point and shoot camera and handing off the camera to their crew chief. The crew chief would then go back to their hotel and upload documentation into folders within a central file system. Their project manager would then put them into the associated tasks within Active Oversight. This posed a huge problem.

The company contracting for our software wants the vendors to conduct all field work on site and in real time, so that they have the ability to review and approve tasks as they were being completed. Minimizing review delays is one of the main selling features of our application. Separate tools and processes were redundant, slow, and literally making AO have no added value to our customers. We needed to solve this problem ASAP!

Users are Afraid of Losing Contracts

In previous phone interviews, when I asked our users how they were documenting their work, they all said that they were using their phones. But, when I checked out Google Analytics, I could clearly see that all their work was being completed from a desktop. After a few discussions with our implementation team, I learned that the vendors of our paying companies had to sign a contract that said they were using AO in the field from their mobile devices. If they weren’t using the software correctly, they wouldn’t be getting any more work. No wonder they didn’t want to fess up to not using their phones!

Field Observation

Because we were hearing and seeing that a lot of our users were not doing the work the way our paying costumers are requiring, I asked to do some field observation on how the work was being done by users in a pilot program. The following were the things I observed:

Crew Chiefs are Sharing Login Information or Their Phones with Their Crews

I arrived at cell tower climb site just as work was being started when I saw the crew chief handoff his phone to one of the crew members. When I asked him why he did that he said, “I don’t want to give them my login information and they don’t want to use their phones.” The next site was a crew that was working on the ground and not on a tower. I noticed that before the crew went on to another task, they had their crew chief come take a photo of the work. They also had to ask their crew chief what was next on the list before they moved on.

The Wrong Person Being Assigned to the Task

Another issue I found was that a crew chief would log into AO and have to call his project manager because he wasn’t assigned to the task. On projects that had two or more vendors, they couldn’t get a person from another vendor company removed from the task without calling their company super user.

Design Workshop & the administrative Side of the problem

We wanted a better picture of how vendor companies of our customers worked, so we invited project managers (PM) and company admin (CA) who hire and work with vendors to participate in refining our design using their insider expertise.

I invited all the local PMs, CAs, and small business owners I had met through past interviews to a three hour design workshop at our office.

Design Workshop Details

Affinity Groupings

Each participant wrote down all the steps a user had to go through from getting assigned a project all the way to completion onto sticky notes. We grouped stickies into groups and then created a centralized theme for each step and agreed on the order they belonged in.

Journey Map

After we had our timeline in place, I had each person vote on if the item in the timeline was “happy,” “sad,” or “neutral.” Then, we talked about the sad items to decide on what we were going to try and solve for. Most people wanted to work on “fixing punch list items” as the most frustrating pain point in the customer’s journey.

Defining a Solution

We wanted our subject matter experts to help us understand what a punch list was, why it was frustrating, and how they saw our software mitigating them, so we had some focused conversation around it. We found out that a lot of the items that were missed or completed incorrectly could have been avoided if teams were able to work together in the field and use AO as a check list.

We decided as a group to solve the problem of allowing multiple people to be assigned to a task, so field users could both use AO as check list while working together. This was super exciting for us, because it fell in line with what we had been hearing in the field.

How Might We Statements

Each participant came up with three “how might we statements” on how we could allow users to work together on a task, which informed the sketches they would create next.

Three Sketches Each

They then made some quick, and simple sketches on how it would work based on their how might we statements. It was really cool to see how our participants translated this step. Some of them sketched the scene and how users would communicate with one another and others sketched what an interface would look like. At first, I was a bit nervous that we weren’t doing the exercise “right” but it actually really helped our team understand how teams are working together in real life.

Partner Work

For each sketch, I had participants work with a partner and explain their ideas. Then, they took at least one idea from their partner and sketched another idea.

Silent Voting

Each person took their idea and taped it to the whiteboard. We then voted on some of our favorite ideas to include in the next round of sketches.

Sketching and Presentation - Take Two

With some fresh, new ideas in mind each participant made a new sketch and then presented it to the group. These finalized sketches would be what informed us of our design direction.

Feedback and Parking Lot

During the workshop, some really great ideas came up, but in an effort to keep conversation focused on what we were solving for, I made note of the topics that came up and put them in the “parking lot.” I save about 30 minutes at the end of our design workshop to talk about these items. We got some really great information on other items we were interested in learning about!

Workshop Agenda

Workshop Deck

What went well

I’m learning that our users are pretty resilient, and if they can work around something they will. I am so happy with the process of this feature. We wouldn’t have known or even considered this on our roadmap if we wouldn’t have been doing field observations or our design workshop.

Learning from the Dashboard, I feel like we did a really good job not over designing this feature and kept it simple from the beginning.