Change Orders

Change Orders: Bringing a System of Record to a Feature That Had Failed Twice

Company: Lessen | Role: Design lead for Command Center (internal), leading two additional designers across the customer portal and Field PM app to ensure consistency | Timeline: April 2022 - Nov 2022, following prior failed attempts by previous teams

Impact summary

Led design of Change Orders, a system of record for scope changes across Lessen's internal Command Center, customer portal, and Field PM app, succeeding where two previous attempts had failed. This feature directly drove a 20% reduction in project completion time, reduced disputes, and kept project timelines accurate.

The problem

Scope changes, whether requested by a customer or mandated on-site by a Field Project Manager fixing a mistake, had no formal system of record. Everything ran through email, spreadsheets, and paper notes, costing real time and money, and showing up directly as customer complaints. The problem was significant enough to be escalated and prioritized at the request of the CTO, and it had already been attempted, unsuccessfully, more than once before I joined the team.

My role & the constraint that made it hard

I owned design for the internal Command Center as sole designer, while leading two other designers across the customer portal and Field PM app to keep all three environments consistent. The challenge wasn't one good flow. It was reconciling different user needs, a customer requesting an upgrade, a Field PM reporting on-site damage, into a system that felt coherent everywhere, on a feature that had already failed twice.

Process

Discovery: Talking through why previous attempts hadn't launched made it clear the earlier versions tried to do too much at once. Customer-facing change requests had been bundled into the original MVP scope, adding complexity before the core problem, accurately tracking money and time against project scope, was even solved.

Key decision: I designed two related but distinct flows sharing the same interaction patterns. Customer-requested changes came pre-populated with the requested line items; internal users could accept, decline, or adjust each one, adjust the timeline, and add items the customer hadn't requested to keep the job realistic. Internally-initiated changes followed the same pattern without pre-population. Approval was conditional, not one-size-fits-all: no cost impact meant no approval, a cost or timeline change required customer approval, and changes above a set dollar threshold also required manager sign-off.

Trade-off: I scoped the MVP down to internal tracking only, accurate money and time against project scope, deliberately deferring customer-facing requests to a later phase rather than repeating the earlier attempts' mistake. Getting the core system of record right first, instead of launching everything at once, is what let this version actually ship.

The solution

Change Orders gave internal users a single place to track scope changes with accurate cost and timeline impact, whether initiated by a customer request or a Field PM correcting an on-site issue, with conditional approval logic that only added friction where real money or timeline changes were involved.

Outcome

• Directly responsible for a 20% reduction in project completion time, tracked within Command Center.

• Reduced disputes by centralizing line-item requests and keeping project timelines accurate.

• Succeeded where two previous attempts at the same feature had failed to launch.