PlanGrid — 2016–2018
Getting our hands dirty to understand one of construction's most dreaded processes — and building the tool that made it manageable.
Introduction
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, and reports across desktop, tablet, and mobile. In November 2018, PlanGrid was acquired by Autodesk and rebranded as Autodesk Build.
In an almost 15-year career, digitizing the "Submittals" process for large-scale construction projects remains the most complex UX/UI challenge I've encountered. To get our arms around the problem, our team undertook a novel participatory research program — one that turned out to be the most unique and useful research approach I've experienced, and which has informed my work ever since.
01 — Submittals on PlanGrid
What is a Submittal?
A submittal is a set of precise specifications required for every element of a construction project, from the building's foundation to the screws in the bathroom door. The General Contractor, Subcontractors, and Architect must collectively determine and agree on costs, sourcing, and timing for all of it. Very roughly, the process goes:
Architect publishes a gigantic project spec book → GC carves it into individual items and distributes to subcontractors → Subs assemble and submit their packages → GC reviews and sends to Architect → Architect reviews and approves/rejects → Work begins. At every step, rejection means restarting from the previous stage.
During every interview session we held — whether with GCs, Trades, or Architects — every single subject said that Submittals was the most frustrating and dreaded part of the building process.

Submittal detail — workflow state, file management, and history log
02 — DIY User Empathy
Running Real Submittals
One of the benefits of designing for a subscription SaaS is a deeply invested client base. At PlanGrid, we maintained monthly check-ins with several trusted clients, and 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 relationship, we asked if we could take our research one step further — and track all the actual Submittals for their next real-world project ourselves. All they needed to do was run their own process normally and cc us on all Submittal-related emails. We'd read them each morning, input the data into our own tracking spreadsheet, and experiment with layout and macros as an MVP prototype. Every two weeks we'd sync with Batten | Shaw to compare results and share experimental metrics.
They agreed. We got started.

Our live tracking dashboard — the spreadsheet that became our MVP prototype

Notes from our Batten | Shaw onboarding session

The raw submittal log — 82 packages, real data from a live hospital construction project
03 — Research Synthesis
From Pilot to Product
After running the pilot for a month, we pulled together everything we'd learned and determined the core feature set for the beta. We wrote the official PRD and user stories, then created our "Risks Dashboard" — one of the most clarifying parts of our process.
The Risks Dashboard identifies all the assumptions we're making in our approach, then assigns each a "risk" grading: how catastrophic would it be if that assumption turned out to be wrong? It's a great gut-check for everything from UI micro-interactions to deciding whether an entire feature is worth building at all.
After reviewing as a team, we decided to build: an automatic spec extraction tool, a table-based submittal tracker, a priority dashboard, simple OAC meeting metrics, a workflow tracker, and a reporting tool.

Submittals: Risks Dashboard — assumptions ranked by severity

PRD hypotheses and submittal flow by actor
04 — Automatic Spec Log
ASL: Automatic spec extraction removes days of manual work
The ASL removed all manual parsing from the spec book process, automatically creating a log of all submittal items for a project. Extracted items loaded directly into the PlanGrid Submittals management tool. Previously, a GC would spend days reading a specification PDF and entering items by hand.

Step 2: Choose extraction options

Step 4: Processing spec

Step 5: Processing complete
05 — Dashboard MVP
Submittals Dashboard
The Submittals Dashboard provides a high-level overview of an entire project's submittals, focusing on items needing immediate attention and segmenting them by responsible party.
A dashboard export tool generates a visually-oriented document for weekly Owner/Architect/Contractor meetings — bringing all parties up to speed on progress without getting bogged down in detail.

Submittals Dashboard — prioritized by responsible party and urgency
06 — Workflow Management
Submittal Detail & Workflow
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 stage or back for revision and resubmission.
A history log of every action taken on the item ensures accuracy in reporting — and protects all parties in potential legal engagements.

Submittal workflow detail — 4-step lifecycle with action triggers and full history
07 — Logged-Out Subcontractors
A full workflow without an account
Most Subcontractors would not have PlanGrid accounts — a paid service primarily targeted at GCs. To account for this, we built a system combining email notifications with a logged-out file management interface, giving subs full workflow participation without requiring account creation.

Email notification to sub

Select submittal items (logged-out)

Create and submit package (logged-out)
08 — Logged-Out Architects
Architects: review without registration
Architects, like most Subcontractors, tended not to have PlanGrid accounts and needed their own version of the logged-out experience. By industry tradition, Architects are forbidden from communicating directly with Subcontractors — the GC must always act as intermediary. The Architect's logged-out flow was designed to respect these contractual constraints while keeping the review process moving.

Email notification to architect

Download submittal for review (logged-out)

Upload reviewed submittal and set status (logged-out)
09 — Distribution
Submittals: Distro
After a submittal item receives approval from all parties, the user publishes the finalized submittal to the team so work can begin. The distribution step closes the loop — creating a clear record of approval, notifying all relevant parties, and officially unlocking the work it governs.

Submittal detail post-approval — all reviews complete, ready to publish