Leafsight~4 min read

A proposal had to be done before the next job.

Six weeks, one PM, one engineer, and a ninety-second target set before any design.

  • Role: Product strategy and design
  • Timeline: 6 weeks
  • Team: 1 PM, 1 engineer, me
  • Impact: $300k ARR
  • Platform: iOS, Android
0%

Proposal acceptance

up from 8%

0%

Traffic on mobile after launch

$0k

ARR run-rate

Product figures come from Mixpanel, read over the week after launch. The 70% is mobile’s share of traffic after the mobile launch. The $300k is booked revenue, annualised to a run-rate, not extrapolated from the one-week read. Acceptance is measured across roughly 100 proposals, against a user base moving from 20 to 75 accounts. Both are small numbers, and 38% of about a hundred proposals is a real result on a small denominator.

Overview

I rebuilt a proposal tool around a ninety-second completion target, for people writing estimates in driveways.

Owner-operators write 4 to 8 estimates a day from job sites with poor connectivity. The existing web app was built for a desk. Proposal acceptance sat at 8%, and 18% of proposals went out with wrong line items.

Worked with: 1 PM and 1 engineer; field workers who tested three navigation options.

What I owned

I owned

  • The ninety-second completion budget, set before any design, and the decision to let it arbitrate scope rather than sit alongside it
  • What the budget cut: photos, notes, tags, and the AI features, with the rule for earning them back
  • Field research: watching estimates get written on job sites rather than in a room
  • Product strategy and design across the six-week build
  • The navigation decision, and the field testing that settled it

Shared with the PM

  • Scope against six weeks and one engineer
  • What got deprioritized, and what went to the roadmap

Before

0%

Proposal acceptance

0%

Proposals with incorrect line items

0 mins

Time to create a proposal

Research

Nobody complained about the tool. They went back to paper.

I watched estimates being written on job sites rather than in a room. Owners abandoned the app without filing a ticket, so usage was the only signal. One partner said: “If I can’t do this in under 2 minutes, I won’t use it.” I set the budget tighter than he asked.

What was scarce on a job site was decision capacity, not screen size. A responsive layout would ask the same questions in a narrower column.

A field worker’s day mapped from 7am through the evening, showing when proposals get written.
A day on site, 7am to 7pm. Proposals get written at the end of it, by someone already out of decisions. This is what set the ninety-second target.
A three-part diagram: on the left, portraits of five clients under the heading Meet clients; in the centre, a highlighted column headed Under 90 seconds containing three stacked steps reading Estimate, Create proposal, and Share/Send; on the right, a photograph of a proposal being signed on a tablet under the heading Work.
Estimate, create, send. Ninety seconds is the budget for all three together, which is why nothing in the shipped flow asks a question that can be answered later.

Decision: ninety seconds sets the scope

A time budget, not a layout, decided what stayed.

I rejected speeding up the existing flow and adding a mobile view to it. Under ninety seconds for a complete proposal meant cutting photos, notes, tags, and the AI features, including things owner-operators eventually want. If the wrong parts were optional, the bet would have lost badly.

Cut features come back only if people are observed reaching for them. None has cleared that bar yet.

Decision: navigation

Field workers rejected the stepper, so I shipped hub and spoke.

I tested a stepper, a single form, and hub and spoke with field workers. They knew the task and were on their sixth estimate that day. “It’s faster because I’m not clicking next, next, next.”

A hub does not force every field to be filled, which matters with 18% of proposals already wrong. So it shows completion state for each section.

Stepper prototype for proposal creation.
Rejected: stepper. Predictable, and slow on site.
Single-form prototype for proposal creation.
Rejected: single form. Fast to build, heavy to scan.
Hub-and-spoke prototype for proposal creation.
Shipped: hub and spoke.

Redesign

Common services are one tap, and secondary actions moved to a bar instead of being cut.

Shortcuts cover recently used services, because partners reuse the same few. Client and address collapse into one row. Photos, notes, and tags moved to a bottom bar, one tap away and out of the main list. An accepted proposal becomes a job on the same screen shape.

The proposal form with every action as a row in one list: Add Client, Add Operation, Add Items, Add Notes, Add Photos, Add Tags.
Before: six equal rows. Notes, photos, and tags sit between the rep and the only two fields a proposal actually needs.
The same proposal form with the client and address merged into a single row above the operation, a full-width Add Item button, and Photos, Notes, and Tags moved to a bar pinned along the bottom of the screen.
After: client and address collapse into one row, Add Item takes the width, and the three secondary actions move to a bar. Demoted, not cut.
The proposal flow before it was shortened, with many steps.
Before: dense, multi-step, desk-shaped.
The shortened proposal flow after redesign.
After: the same job, reshaped around ninety seconds.
A Create sheet sliding up over the day’s calendar, offering four options: Lead, Proposal, Active Job, and Client, each with a one-line description.
One entry point over the day’s schedule. Four things a rep can start, named for what they are.
A Proposal screen with the client Charles Bikowski, a Seattle address, and the Treecare operation filled in, above a green Add Item button and four shortcut chips: Tree Removal, Structural Pruning, Stump Grinding, and Crown Thinning.
The shortcuts are the ninety seconds. Four services cover most of what this crew sells, so the common case is a tap. Searching is the exception.
The proposal with a Tree Removal line item at $1,500 and its scope note, followed by a subtotal of $1,500, Seattle tax at 10.2% of $165, a total of $1,654, and links to add a discount or require a deposit.
Tax by jurisdiction, computed rather than remembered. 18% of proposals had incorrect line items before; the available record doesn’t say which items were wrong.

Scope

A mobile-first flow shipped, and notes, photos, tags, and AI features were deprioritized.

I set targets before designing: completion under ninety seconds, task completion above 80% from 45%, and return usage within 24 hours above 60%. Of those, the study records only that task completion rose above 80%.

Results

Acceptance rose from 8% to 38%, on a small base.

I have no recorded case of someone who wanted the stepper or the cut features back

Every field quote pointed the same way. That absence is not evidence those people were missing.

The target made notes and photos deliberately expensive. That works for one operator doing 4 to 8 estimates a day, and a crew on larger jobs needs them. I do not know where that line falls for this crew.

Sam Cusano