PlanGrid

Participatory Research & Wildly Complex Workflows (2016-2018)

PlanGrid was a cloud-based construction document collaboration platform launched in the W12 cohort of Y Combinator. The service allowed contractors and architects to view, share, and collaborate on blueprints, project plans, markups, photos, specifications, and reports from their desktops, tablets, and other mobile devices.

In November 2018, PlanGrid was acquired by AutoDesk and rebranded as AutoDesk Build.

Introduction

Case Study: Submittals on PlanGrid

In an almost 15 year career - 1 year of which was spent working on a mortgage origination platform - digitizing the “Submittals” process for a large-scale construction project remains the most complicated UX/UI challenge that I ever encountered.

To wrap our arms around the problem, our team decided to undertake a novel participatory research program that turned out to be the most unique and useful that I’ve experienced in my career, and which has informed my approach to research and design ever since. Before we dig into the details, though…

What is a Submittal?

A submittal is a set of precise specifications required for each and every element of a construction project, from the building’s foundation to the screws in the bathroom door. Each of the 3 main participants in the build - the General Contractor, the Subcontractors, and the Architect, have to collectively determine and agree upon what all of this will cost, where the materials will be sourced, and when it will all get done. Very roughly speaking, the process goes something like this:

  1. Architect publishes a gigantic project spec book as a PDF

  2. GC carves spec book into PDFs of each separate item required from their subcontractors, then distributes the items back to the correct subcontractors

  3. Subcontractors assemble product drawings, specs, and samples to meet their assigned requirements, then bundle them into a Submittals package (more new PDFs!) which they submit to the GC

  4. GC reviews, marks up, and sends the Submittal on to the Architect for review

  5. Architect reviews, marks up, approves/rejects, then sends back to GC

  6. GC sends back to subcontractor for revision or distributes to the team

  7. Work begins!

Note that at each review point in this process, it’s possible for a Submittal to be sent back to the previous step for a round of revisions, which, when completed, will require fresh approvals from all other parties. Further complications to the process include:

  1. Every GC has a slightly different Submittals process and toolset

  2. Potential users were already doing redundant data entry on fragmented and/or contractually-mandated toolsets, managing some parts of their process in spreadsheets, others in PDF/doc-management tools (Bluebeam, Submittals Exchange), and much of it in regular old email. How would another tool help this?

  3. Many essential participants in the workflow will not have PlanGrid - a paid service primarily targeted at GCs - and so will need to be able to manage and work with sensitive documents in a logged-out state

  4. By industry tradition, it is Forbidden for Subcontractors and Architects to speak with each other directly. The GC must always act as intermediary.

  5. During every interview session we held during the preliminary research - whether with GCs, Trades, or Architects - every single subject said that Submittals was the most frustrating and dreaded part of the building process.

The more we learned, the more clear it became that we needed some direct experience if we wanted to build a tool that was worth our user’s time.

DIY User Empathy
One of the benefits of designing for a subscription-based SaaS company is that they tend to come with a deeply invested client base who are more than happy to participate in feedback and usability testing sessions.

At PlanGrid, we maintained steady monthly check-ins with several such clients, some of whom become trusted sources of high-quality product insight. Taking advantage of that, our process began with more than 20 interviews with GCs, subcontractors, and architects.

One of them was Nashville-based GC firm Batten | Shaw. Given our established working relationship, we asked if we could take our research one step further and take a shot at tracking all the actual Submittals for their next real world project ourselves.

All they needed to do was run their own process as usual and cc us on all their Submittal-related emails. On our end, we would read the emails each morning and input the relevant data into our own tracking spreadsheet, where we planned to experiment with layout and macros to construct a prototype of our eventual MVP concept. Every 2 weeks we’d sync up with Batten | Shaw to compare our results and provide them with various experimental metrics and visualizations that we built to get a sense of their accuracy and utility.

They agreed to the plan, and we got started.

Research Synthesis
After running our Submittals pilot for a month, we felt ready to pull together everything we’d learned and determine the core feature set and scope of the beta. Shortly after, we wrote up the official PRD and user stories.

Next, we created our traditional “Risks Dashboard,” which I always found to be one of the most clarifying parts of our process. The idea was to identify all the assumptions we were making in our approach to the product, and then assigning each assumption a “risk” grading as to how catastrophic it would be if that assumption turned out to be wrong. This is a great way to gut check everything from smaller decisions about UI microinteractions all the way out to deciding whether an entire new feature is worth building at all.

After reviewing everything as a team, we decided to build the following:

  1. Automatic spec extraction tool

  2. Table-based submittal tracker

  3. Dashboard showing users which submittals need their attention

  4. Simple metrics/data viz for weekly OAC (Owner/Architect/Contractor) meetings

  5. Workflow tracker

  6. Reporting tool

ASL: Automatic Spec Log
The automatic spec extraction tool removed all manual parsing from the spec book extraction process and automatically created a log of all submittal items for a project. The extracted items would then be directly loaded into the PlanGrid Submittals management tool.

Submittals: Dashboard MVP
The Submittals Dashboard provides a high level overview of an entire project’s submittals, focusing on submittals in need of immediate attention and segmenting them by responsible party. A dashboard export tool provides a visually-oriented high-level document for use in weekly Owner/Architect/Contractor meetings, where it brings all parties up to speed on progress and outstanding tasks without getting bogged down in unnecessary detail.

Submittals: Workflow Management
The detail page for each individual submittal breaks down its lifecycle into 4 clear steps. Each step has an option to send the submittal forward to the next step or back for revision and resubmission. We also included a history log of every action taken on the item to ensure accuracy in reporting and potential legal engagements.

Submittal Management for Logged-Out Subcontractors
To account for subcontractors who would have to use the system without PlanGrid accounts, we built a system combining email notifications with a logged-out file management system.

Submittal Management for Logged-Out Architects
Architects, like most Subcontractors, tended not to have PlanGrid accounts, and needed their own version of the logged-out experience.

Submittals: Distribution
After a submittal item receives approval from all parties, the user publishes the finalized submittal to the team so work can begin