UpKeep is an asset operations/CMMS software designed to help maintenance teams keep their assets running and reduce downtime through preventive and reactive work orders. The web app is used by administrators to track activity, organize information, and view analytics, while the mobile app is primarily used by field technicians to record work and input data.

While working at UpKeep, I was one of two designers on the larger product team; hence I was involved in projects in every product area. This would often include brainstorming, prototyping, design review, and both internal and external discovery. Each project I worked on consisted of one product manager and several engineers. The following case study is a project I undertook with the mobile squad, involving one product manager.

Project Details:

• Duration: 3 months/ongoing

• Team: 1 product manager, 3 customer success/implementation managers, 1 designer (myself)

• My role: User research, wireframing, prototyping

• Tools: Figma

• Deliverable: mobile designs with new features

How can statuses be expanded to account for more specific scenarios, in order to maintain an uninterrupted technician workflow?

Background

The UpKeep mobile app has allowed users (the majority of app users being technicians) to set work orders to one of four available statuses: Open, In Progress, On Hold, and Complete. A consistent feedback item was that these statuses were too broad to accommodate the additional information needed for the proper context and reporting, resulting in wasted time typing and looking in form fields. Therefore, this presented a functionality gap.

Process

The process of solving this problem was split into three phases. The design was developed based on feedback received at each phase. From the beginning, we kept in mind the need to balance the best solution possible with the potential level of effort required. 

Some initial questions:

• How are customers currently bridging the functionality gap with statuses in UpKeep?

• How do custom statuses need to work in reporting? Should they map to the default ones or should they be represented separately?

• What are the most common types of custom statues that customers want today?

• Do users think of substatuses as statuses or details/reasons to the main status?

Phase 1: Problem Space Discovery (Internal)

The first thing we did was talk to three members of our customer-facing implementation and success teams, to get a pulse on what customers have been saying. The goal of this phase was to fully understand the problem before thinking about solutions.

“[InShape] has 60,000 parts... A big part of their workflow is being able to give a report to their procurement team of the parts that they need to be ordered. They list parts that need to be ordered on the work order. It’s a really big blocker for the customer.” - Rachel Wittlin, Implementation Manager

One of the key findings from this phase was that the main problems to be solved are downtime and lack of visibility. The general nature of the existing statuses often resulted in a technician’s workflow being interrupted due to having to jot down notes and @mention other teammates. Also, anyone needing to look back at existing/past work orders had no way to filter and sort more specifically, and would not be able to see potentially crucial information unless they drilled down into each work order’s notes section. 

We also found out that adding additional independent statuses and/or allowing custom status creation would benefit enterprise customers. However, adding these capabilities would greatly increase complexity.

Other software that customers integrate with UpKeep, such as SAP, sometimes require more specific reasons why work orders are On Hold. The current four statuses do not account for these other reasons. Some deals have even been lost because of this.

“It gets confusing because there are not enough details around how when putting a work order into an On Hold status, people have to rely solely on the internal communications tool and then double check it to see why the job is on hold... it creates more work for them... the most common example I’m hearing is that customers are looking to mark a work order as On Hold because parts are on order.” - Todd Junker, Customer Success Manager

Finally, it became clear to us that based on the vast majority of cases, only the On Hold status required additional statuses. Solving for just On Hold would allow purchasing to filter and see which parts, work orders etc. need attention.

At this point, we came up with a potential solution of providing options for the most common reasons a work order would be on hold, and “Other” as a catch-all for everything else. We also considered rolling out an MVP with an option to opt-in to this feature.

An outstanding question that persisted was whether statuses should be arranged in “buckets”, meaning that each could theoretically contain substatuses, or just treat every individual status as equal.

Phase 2: Prototype Validation (Internal)

Using the feedback gathered from phase 1, I put together three prototypes showcasing different ways to select additional statuses relating to On Hold, then walked through all three with the same teammates we spoke to earlier. The goal of this phase was to learn how each variation fits into customers’ needs and workflow.

The following prototypes are interactable. Please expand each into fullscreen view for the best viewing experience.

It became clear to us that too much customization was a very real possibility. Therefore, we resolved to identify the most common reasons why a technician would put a work order on hold, and limit the options to those, rather than allowing for any customization. In order to account for any edge cases, we also decided to add an “Other” option.

Also, based on feedback received during this phase, we ruled out variation C because the visual clutter of displaying all statuses in one menu had the potential to be confusing, and create more room for error.

Phase 3: Prototype Validation (External)

My main goal in this phase was to narrow down the choices to just one variation and identify the best specific statuses to include.

We showed variations A and B to two customers, which yielded similar feedback to what we heard from the internal team, and over the course of those conversations, we made the following key findings:

• Substatuses instead of custom would solve ~80% of use cases

• Awaiting Parts is the biggest blocker for work orders.

• We were able to identify the next most common reasons that technicians put work orders on hold (Awaiting Labor and Awaiting Operations) thus accounting for the vast majority of cases.

• Including the “On Hold” prefix as well as its icon was enough to associate the new statuses with the existing one.

Therefore, we defined the following scope for this project moving forward:

• On Hold substatuses should be added

• The substatuses should be easily seen and filtered in the work order list

• The logic for on hold should also be applied to substatuses

Conclusion

Conducting both internal and external discovery in an incremental way succeeded in getting us the data we needed for this project. Because I was making changes to the designs at every phase, once we concluded the last one, I had a design and prototype that was ready to be handed off to developers. As of the date of this writing, this feature has not been put into production yet.