Fieldwire

Introduction

Fieldwire is a web-based construction project management tool used to track and document projects both out in the field and in office.
I focused on designing new as well as improving existing features on both web and mobile by providing flows, mockups, and prototypes while working closely with product and engineering in an end-to-end process within a squad.

Role
Product Designer

Tools
Figma, Miro‍

Timeframe
September 2021 – December 2022

Background

Customer problem

As a construction company uses Fieldwire, their list of projects grows over time. Keeping track and organizing this growing list can be a problem as contractors could have hundreds of projects in just a few short years. There was consistent user feedback from hundreds of individual complaints via Zendesk that they had trouble finding, grouping, and organizing projects.

Our target users are project managers and office staff working in a mostly offsite environment. These users are the most involved in top level organization and resource management.

Business problem

Among other things the ability to organize projects and group them led to some potential leads to choose our competitor Procore over Fieldwire meaning a loss of potential growth— there was a rising need to quickly fill in that capability gap.

The low findability from the lack of visual differentiation often made discoverability of certain projects in a high volume environment difficult.

Solution

Create an easy-to-use and flexible system to help aid organization for high level decision makers; it would also have to be straight-forward to implement and scale with limited available engineering effort and resources.

Research

Competitive Analysis

Searching through similar project management and construction apps with similar organizational goals and capabilities focusing especially on how they handle grouping and organization.

Please rollover to zoom below.

Lessons learned so far...

  1. Tags and labeling focused more on organizing the tasks within projects and not the projects themselves.
  2. There was a lot of attention given to customization but with lack of clarity of how to change those labels or customize them.
  3. Don't reinvent the wheel— features that worked and were familiar were prioritized over a system that allowed for extreme customization.

Wireframes

The team explored early concepts to measure development feasibility and overall resource cost for engineering. Looping in engineering personnel early in the design process allowed us to cut down on overall time and allowed them to discuss the best path forward for solving the problem while fitting the new feature within the existing framework.

From here, engineering team leads often run more technical discussions with product and design often acting as the liaison and offering design solutions to any potential development issues.

An early mid-fidelity wireframe to help visualize the concept especially useful for engineering and leadership.

Validation & A/B testing

Armed with an idea and some mid-fidelity wireframes we were able to leverage our existing relationships with long time users and conduct a handful of A/B testing sessions while conducting short interviews as well.

We A/B tested slightly different project cards with different kinds tags

Lessons learned from A/B testing...

  1. What I learned was that color offered a greater degree of variation while allowing for us to reuse the same form factor of the existing project card. It offered enough differentiation to allow for quicker visual identification and the ability to filter to the exact project.
  2. All users that were interviewed required only a handful of tags at the most while also stating that having a least one additional (tag) would help in organizing their resource management.

Final designs

A video walkthrough of the prototype design!