Summary

After conducting field observations and interviews, it became apparent that the way we had originally set up Active Oversight (AO), with one person being assigned to a task, was not viable in the real world. I found that our field users worked on teams with the person being assigned to the task the foreman or crew chief.

Discovery: User interviews, field observation, and inviting our customers into our office for a workshop were used to understand our 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 were 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 at task.

Timeframe: 4 Months

Research: 12 users

Discovering the problem

Interviews

When I started interviewing users to understand their workflow, it became apparent that there was something wrong. I kept hearing that users were still taking photos on a point and shoot camera, giving the camera to their crew chief, and then the crew chief would upload the images into AO from their hotel or home, creating more work for the crew chief than necessary. The following were the items I discovered:

Project Managers Still Doing the Work

When interviewing users to understand their workflow, I realized that they were doing the work the same way they always had. Take the photo and upload it into a central file system, so they Project Manager could attach photos to the proper task in AO. This posed a huge problem, because the company paying for our software for the vendors to use in the field want all work to be done real time and in the field. The other goal our purchasers have the ability to review as the work is being completed, mitigating the chance that crews have to deploy back to the site to fix any rejected tasks. Users appeasing the employers was literally making AO have no added value to our customers. We needed to solve this problem ASAP!

The phone debacle

When asking how our users got the information into AO, they would tell me that a guy on their crew would climb the tower, take the photo onto a point and shoot camera that was supplied by the company, and then the crew chief would download the all the images at the end of the day or even at the end of the project, which could be up to a few days after they had completed the work. When I asked those people why they didn’t use their phones, they said that they couldn’t afford to drop their phones 400 feet. On further investigation, I learned that the only people who have their phones paid for are Crew Chiefs and above in rank. I also learned from these interviews that some crew members are still using flip phones.

Users are afraid of loosing contracts because of AO

Another item I discovered is that our users were not being truthful about how they are conducting their work. When I asked our users how they were documenting their work, they all said that they were using their phones, which was understandable. But, when I checked out Google Analytics, I could clearly see that all their work was being completed from a desktop. This was puzzling me. After a few discussions with our implementation team I learned that, starting in November, the vendors of our paying companies were made to sign a 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.

Field Observation

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

Crew Chiefs are sharing log in information or their phones with their crew

I arrived at cell tower climb site, just as work was being started, and I saw the crew chief hand his phone to one of the crew members. I asked him why he handed his phone to his crew member. He said, “ I don’t want to give them my log in information and they don’t want to user their phones.” The next site was a crew that was working on the ground and not in a lift. I noticed that before the crew went on to another task, they had their crew chief come take a photo of the work. The 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

The other 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. And, 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

Because we wanted a better picture about how the vendor companies of our customers ran, we invited Project Managers (PM) and Company Admin (CA) who work with and without AO.

Over two months, I contacted all the local PM’s, CA’s, and small business people my sales team had leads to, in hopes we could some folks in the door that weren’t tied to the current workflow. Over a month’s time, I was able to get two current customers and three potential customers who all work in the wireless space to come in for a three hour workshop.

Design Workshop

Affinity Groupings

I had each person write down on individual sticky notes all the items a user had to do to get assigned a job all the way to project completion. We grouped everyones stickies into groups and then created a centralized theme for each step and agreed on the pagination of those items.

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 voted on the red items to decide on what we were going to try and solve for. Most people voted on “fixing punch list items” as the most frustrating pain point in the customers journey.

Defining a solution

Because we had our subject matter experts in a room with us, we wanted them to have some focused conversation about what was stressful about the go backs. Some of our participants were contractors of our paying clients, so it was so cool to see how they were feeling hamstrung in the field based on only being able to assign one person to a task when there were multiple people working on it.

We decided as a group to solve the problem of allowing multiple people to be assigned to a task, which fell in line with what we had been hearing in the field.

How Might We Statements: Each participant came up with three written how might we allow users to work together on a task statements.

Three Sketches Each: Then, they made a simple sketch on how it would work in the field. It was really cool to see how some of them sketched the scene and how users would communicate with one another and some of them sketch 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 these teams are working together in real life.

Partner Work: For each sketch, I had each participant work with a partner and explain their ideas. Then, they took at least one idea from their partner and sketched one idea each to present to the group.

Presentation: Each person took their idea and taped it to the whiteboard and talked about their idea and why they thought it was a good solution.

Voting: After everyone presented their idea, people voted on their favorite ideas.

Sketching and Presentation - Take Two: With some fresh, new ideas in mind, each participant made a new sketch and then presented their new sketches and why they took certain ideas from other sketches from before.

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 a bunch of sticky notes of the things 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, and we got some really great information on other items we were interested in learning about!

Workshop Agenda

Workshop Deck

Feature Retro

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 outcomes of what we wouldn’t have known or even considered if we wouldn’t have been doing field observations or invited our users in for our Design Workshop.

Learning from the Dashboard, I feel like we did a really good job not over designing this feature, and keeping it simple from the beginning. There are some improvements I’d like to make in the future to add more features on mobile that are available on web, when it comes to this feature, but for right now, I’m super happy with the outcome.

What could have been better

1. We used a web-based design for our tab navigation, which wasn’t tested with users. During our usability test, we learned that the tab navigation was a little confused, but we were a little hamstrung with the design.

2. Having a better understanding of what our users are being told by sales, and understanding the mandates they are being faced with would have changed how I started communications with our users.

What we’re doing different

1. We have redesigned and tested the original tab navigation on web and mobile. That design enhancement should be coming out in the near future.

2. Before I start any interview, I make sure that our users know that we’re on their sides and that what they tell us is confidential. I feel like it’s been making them speak more candidly and more willing to ask for the things they want, and not just figure out a way to work around it.

3. We are conducting a quarterly Design Workshop with our users.