Field Relevance

Enhancing accuracy & completion rates inside Checklists

When encountering irrelevant fields, users may resort to inputting inaccurate or missing information. This project explores solutions for enhancing the accuracy and completeness of data within Checklists.

Platform

Web / Mobile

Role

Product Designer /

Researcher

Delivery Time

6 Weeks

Not My Job: Irrelevant tasks lead to bad or missing information inside Checklists.

Our team repeatedly hears asks for ‘Conditional Logic’, or the ability to hide or show certain fields based on prior inputs or perceived relevance.

From our user interviews, we've made several key observations:

• Field users, when confronted with tasks that don't apply to them (for example, roofing tasks when they're there to work on gutters), take random photos (hands, cupholders, shoes, etc.) to fulfill the photo requirements. This leads to a collection of irrelevant data that can mistakenly appear in official reports unless deliberately removed by office staff.

• Alternatively, users may leave these non-relevant fields empty, which creates confusion about whether certain Checklists have actually been completed. For those that rely on Checklists as a lite-CRM, this is particularly problematic.

They’ll just put in a picture of a vent from one of the trucks, you know, because they have to put something in. My crews won’t get credit for the job unless it’s 100% complete.

They’ll just put in a picture of a vent from one of the trucks, you know, because they have to put something in. My crews won’t get credit for the job unless it’s 100% complete.

How might we enhance the accuracy of that input data?

At this point, I was considering a few things:

• How will Checklists & Tasks play together?

• If we dramatically alter the way Checklists are handled, what kind of backwards compatibility are we looking at?

• Are we targeting customers who create ad-hoc checklists? Checklists from Templates? Both?

Early exploration bundled existing tech debt in with proposed solutions.

I was initially thinking very broadly about how we might want to tackle conditions holistically inside of Checklists.

One of the things that's been highlighted internally as an area of debt is how we handle adding subtasks (or Questions as they're called in the product) into fields. Currently, a field/task has to first exist for a user to add a 'sub-task', such as a rating scale, yes/no, etc. We believe this 'nesting' is one of the contributing factors for uncompleted (yes, that's a word) fields.

Because of that nesting, it would have made adding 'conditions' complicated for users, and even more so for developers. That being the case, the bulk of my exploration revolved around each task/field existing as its own entity as opposed to being nested together.

Another area of exploration here is how fields are added in the first place. Currently, a user has to go through two steps: using the 'Add' button to add a field, and then another 'Add' button revealing a dropdown to add a 'subtask.' Based on the data and relatively limited usage of subtasks, the thought here was to surface them more visibly in a sidebar where a user could simply drag and drop them into place.

This gif is one of my favorite mid-fidelity examples trying to wrap my head around how the interactions might work, specifically exploring how it would work when adding new conditions and dragging/dropping new fields into those conditions.

Ultimately that proved to be too much, so we switched gears to a ‘seemingly’ less risky solution.

Following extensive iteration and dialogue between the Product and Engineering teams, it was decided that incorporating conditional functionality into Checklists would require a significant refactor on the backend. Consequently, and because we weren't ready to invest in something that was experimental, we decided to explore a seemingly less risky alternative to achieve a similar result.

What if we allowed users to hide fields they found irrelevant, rather than automatically showing or hiding them based on preset conditions? Essentially, categorizing 'skipped' fields into their own distinct section where they wouldn't contribute uncompleted checklists.

Note to future self

In fact, 'skipping' or marking entire sections as Not Applicable turned out to be very complicated and was no less risky than the original exploration. Too late in the game, we ran into complications regarding another teams' efforts to make checklists available offline, as well as performance-related issues related to the counting complete vs. 'skipped' fields.

Here's the idea: What if users could effectively SKIP entire sections and effectively mitigate the problem altogether?

Mark and the crew are in the field, tasked with installing a new roof. They're using one of their existing Checklist Templates to ensure they're following the correct steps for roof installation, and documenting their process along the way for liability & any institution (like banks) that need proof of correct install.

One of the sections within their template is for gutters and soffit - work they won't be doing on this job, as another different crew will be following behind them at some point later down the line.

If they skipped the gutter/soffit sections entirely, the checklist will look incomplete. If they take random pictures to complete the fields, the checklist will look finished but will have inaccurate data.

That's where marking sections as Not Applicable comes in.

For an office admin/manager to designate sections as optional, they navigate to the template and turn off the requirement. Note: This is an example of intended functionality, but Checklists don't update live as shown here and would need to be regenerated to see the change take effect.

Marking sections as Not Applicable

To mark a section as Not Applicable, users are able to tap the button to the right to essentially mark that section (and the fields inside) irrelevant.

At the top left of the screen, you can see how this impacts the count where fields marked N/A are deducted from the total count.

Restoring sections

We try to build in as much error prevention as possible within Checklists. To prevent accidental usage of this feature, we build in the ability for users to Restore sections if need be.

From web, users can see who marked a section as Not Applicable.

Edge cases and other considerations we were thinking about.

Other considerations that went into this work…

  • What happens if a field already has content inside (attached photos/answered subtasks for example) before a user marks it as Not Applicable? To account for this occurrence, we built in a check that a) determines if there is in-fact content inside a field, and if so, surfaces a popover confirming a user wants to mark a section as Not Applicable following the implications. (e.g., photos will still be saved to the project, but they along with subtask answers will be removed from the field.)

  • Customers have the ability to export Checklists into a PDF. We built in a toggle that allows them to either show or hide fields that've been marked as not applicable.

  • Admin/Manager permissions have the ability to edit Checklists created from a template. To reduce complexity and scope, we disabled the ability to drag Fields to or from sections that've been marked as not applicable.

Note to future self

Towards the end of the cycle, we ran into an issue where, when checking to see if fields had content before marking them as N/A, the performance of the Checklist became problematic. To resolve this issue, we gave users a popover every time before marking sections as N/A indicating some content may be lost.

Final thoughts

This was a very complex project with many moving parts. From edge cases to performance concerns, it was a doozy from beginning to end.

At the time of this writing, the feature is mostly complete but not yet rolled into production. Just like any new feature, we don't fully know how it'll be received by users, and I'm hopeful, but if I had to do it over again, I may advocate against doing this project again.

Here's why.

The ask we originally heard from both users & internal departments was for conditional logic, or the ability to conditionally hide fields that weren't relevant while surfacing the things that were. It made sense, so people in the field weren't being confused by things not relevant to them, and people in the office were able see accurate completion statuses of various Checklists across dozens of projects.

Early on, we made concessions with development based on the need to refactor the entire backend of Checklists to accommodate that functionality. At that point, 'skipping' entire fields or sections seemed like a quick & easy solution to validate the underlying user need. What we couldn't have known at that point was how many possible edge cases there would be, despite significant planning in advance, and the performance implications of running so many checks.

In addition to the technical implications, we knowingly created more debt within Checklists by adding a completely new convention of N/A in addition to the existing version that existed within subtasks. Effectively, we have two ways of marking content as Not Applicable and they both behave differently.

If I could go back in time, I would advocate for a new, lightweight experiment built from the ground up (similar to what we did with Tasks) that wasn't bogged down by existing debt and constraints baked into the foundation of Checklists.

Kudos to the entire team and especially our developers, who made such a complex project happen in the first place.