Field Observation, Design Workshop, and Multiple Assign Feature
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.
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
We believe that allowing for users to assign multiple people to a task will result in better usage from our field users because it will allow them to maintain their current workflow and have less interruptions due to Active Oversight.
Discovering the problem
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!
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
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.
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.
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.
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!
deciding on what to develop
After the workshop, we compiled all the ideas and compared them with our field observations to come up with our MVP.
Our top priority and biggest lift for this feature was to allow users the ability to work on the same task at the same time. This would allow PMs to observe the work being done in real time and help our field users complete work as they did before AO. All the other ideas were amazing, and we hope to integrate crew communication, live feed, and streaming video, but we focused on the team being able to complete the work as they did before AO.
Design Iterations and Testing
Quantitative: One month after release there were more than 1,200 tasks with multiple users assigned.
Qualitative: Two months after release, I reached out to five project managers who have been assigning multiple users to tasks. They all said that this was positive change to the software and that it was easy to use.
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.
What could have been better
We used a web-based design for our tab navigation, which hadn’t been tested with users. During our usability test, we learned that the tab navigation was confusing to our users, but we didn’t have the ability to make changes at the time of development.
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
We have redesigned and tested the original tab navigation on web and mobile. That design enhancement should be coming out in the near future.
Before any interviews, I make sure that our users know that we’re on their side and that what they tell us is confidential. This explicit privacy has improved communications and allowed interviewees to speak candidly and be more willing to ask for features that make their job more efficient with AO instead of ways to work around it.
What I Loved About Working on This Feature
I love being in the field observing behavior and bringing findings back to my team. Being able to couple field observation with a design workshop with our users was even better! I think the icing on the cake was that I had the opportunity to reach out to all the participants involved and announce that we had released something they asked for. I loved how full circle that was, how everyone benefitted and how happy it made our users.
What I Will Do Better Next Time
While the design workshop was amazing, I fee like it was a bit rushed. For our next session, I’d like to set up a full day work shop in order to allow us the time to really brainstorm solutions to even more challenging circumstances.