Document Crunch · Q3–Q4 2024

Cutting PDF download bloat for contract reviewers.

Choosing daily users over the loudest CX complaint, and shipping granular controls before smart presets.

UX Strategy Interaction Design Sole Product Designer

The Document Crunch PDF selection modal in its initial state, showing checklist toggles and a live preview of the resulting document

The selection modal users see when they hit Download — checklists toggled on or off, with a live page-count preview that updates as they make choices.

Document Crunch is an AI-powered platform used by construction-industry legal teams to assess risk and review complex contracts. Users apply checklists, leave notes, and mark up contract PDFs directly inside the app — replacing a manual, error-prone review process that previously happened in Word, email, and Adobe.

After a multi-checklist feature launched, a quiet but expensive problem surfaced: every download carried every checklist, note, drawing, and markup attached to that contract — even the ones the recipient didn't need. Files ballooned. Email clients rejected them. Recipients scrolled past pages of internal annotations to find the clauses that mattered.

The problem behind the problem

A surface complaint masking three distinct jobs-to-be-done.

Customer Operations was fielding repeat complaints, but the surface complaint — "the PDF is too big" — wasn't the real one. I worked through the inbound feedback with CX and ran short interviews with five power-users to understand why people were downloading in the first place. Three jobs-to-be-done emerged.

Sharing the contract with someone outside the platform — a partner, a subcontractor, opposing counsel. Printing a specific section for offline review. And quickly re-reading their own checklist or markup work in a single document. Each job needed a different slice of the document. The current export bundled all three.

The real problem wasn't file size — it was that the system gave users no way to express intent.

Strategic Considerations

Three tensions shaped how this work got framed to product and engineering.

Scope — frontend solution vs. backend rewrite

The cleanest version of the fix was a backend rewrite to make selective export a first-class capability of the PDF pipeline. That was off the table for the timeline. I had to make the case that a frontend-only solution — wrapping the existing pipeline in a smarter UI — would still solve the problem credibly, and that the deeper backend work could be sequenced into a later quarter. Once we agreed to that framing, the design space tightened in a useful way.

Audience — daily users vs. the loudest complaint

The original brief came from CX as a customer complaint, but the users actually downloading PDFs were running multiple contracts a day. Designing for the loudest complaint risked over-correcting toward simplification; designing for the daily workflow meant accepting some configuration complexity in exchange for control. I sided with the power-users. That decision is what shaped the modal-with-preview pattern rather than a simpler "lite" download button.

Defaults vs. control — when smart presets become guesses

I made the explicit decision not to ship smart presets in v1, even though they tested well in concept. Without telemetry on real download patterns, the presets would have been guesses dressed up as defaults — and would have anchored future product thinking on those guesses. Shipping the granular controls first generated the data that would later make presets actually useful. That's the v2 work now in flight.

Constraints

What we couldn't change.

The export pipeline already existed — backend rewrite was off the table for the timeline.
Users are in the app daily — any new step in the flow had to feel faster, not slower, than what they had today.
The feature had to work for users with one checklist and users with twenty without two different UIs.

Process & Decisions

Three directions prototyped. One shipped.

I synthesized CX feedback alongside FullStory session replays to confirm the pattern wasn't anecdotal — users were repeatedly downloading, opening the file, and re-downloading after they realized the file was too big or too messy. That gave me confidence the problem was worth a dedicated flow rather than a settings toggle.

I prototyped three directions. A pre-export settings panel was the first — rejected because it added a step without giving users confidence the output would be right. Smart presets based on download intent was the second — promising, but parked for v2 because we didn't yet have the telemetry to define good presets. The direction that shipped was a focused selection modal with real-time preview.

The preview was the unlock. Once users could see the page count update as they toggled checklists and annotations on or off, the feature stopped feeling like configuration and started feeling like editing. I tested the prototype in Maze with seven users — the preview loop cut decision-time in half compared to the settings-panel direction.

The expanded selection modal showing per-checklist toggles for question status (Yes, No, Review, No Answer) and information type (Subquestions, AI Summary, Notes) — The expanded modal — per-checklist toggles for question status and information type. The granularity exists because users were already doing this work manually after downloading, deleting pages in Adobe before forwarding.

The expanded modal adds a second layer of control: per-checklist toggles for question status and information type. I went back and forth on whether to expose this granularity at all. The deciding factor was that power-users had been doing this manually post-download. Better to give them the controls than pretend the work didn't exist.

Selection modal showing a contract with multiple checklists, demonstrating the toggle controls per checklist — The modal with multiple checklists — users toggle each checklist individually. Defaults are preserved per user, so repeat downloads of the same contract are one click.

Selection modal with annotation controls visible, showing options for drawings and markups — Drawings and markup controls. Each annotation type can be included or excluded independently — the same granularity that was impossible before this redesign.

What Shipped

A modal, a preview, and the data to build what comes next.

A modal that opens from the existing Download button, where users select which checklists, notes, drawings, and markups to include — with a live page-count and thumbnail preview that updates as they toggle. Defaults are preserved per user, so the second download of the same contract is one click.

A clean exported PDF page showing project details — only the relevant contract context, no buried annotations or irrelevant checklists — Resulting PDF — project details page. Focused on what the recipient needs. No buried markups, no irrelevant pages from another reviewer's checklist work.

A clean exported PDF page showing a focused checklist assessment — only the checklist results the user selected, clearly laid out without irrelevant content — The second output page — focused checklist assessment. Only the results the user selected. Compare this with the kitchen-sink document the old flow produced.

I worked closely with two engineers to keep the preview performant on long contracts and to make sure the toggle state mapped cleanly to existing PDF generation logic. Post-launch, I ran follow-up usability sessions to confirm the modal didn't introduce new confusion — it didn't.

Outcome

The redesign shipped and stuck.

A few signals I can speak to directly:

Files became sharable again

Where the previous export routinely produced PDFs too large to send via standard email, the redesigned flow lets users opt out of the content their recipient doesn't need — bringing typical exports back under common attachment limits.

Customer Operations stopped seeing the same complaint on repeat

The download-related inquiries that drove the original brief faded from CX's weekly recurring issues list. Not because we masked the problem — because we solved the job.

The preview earned user trust

In post-launch usability sessions, users repeatedly pointed to the live preview as the reason they felt confident downloading without re-checking the file. Users had stopped opening every export to verify it was right — which was a behavior the old flow had quietly trained into them.

The work seeded what came next

The toggle structure is now the foundation for the preset work originally parked in scope-cutting. The questions raised during testing pushed visual hierarchy improvements within long checklists onto the team's roadmap.

Granularity is seductive. My first prototype gave users toggles for individual notes and individual drawings — and it tested badly.
From the project retrospective

What I'd Do Differently

Start at the coarsest grain.

My first prototype gave users toggles for individual notes and individual drawings — and it tested badly. Users wanted control, not every possible option. I should have started one level higher — checklist-level toggles — and only added finer granularity if testing demanded it.

I now default to asking "what's the coarsest grain that solves the job" before adding controls. This project made that reflex concrete.

Next Steps

Three threads in motion.

Default presets for the three jobs-to-be-done are now in design — built on the toggle-usage telemetry the v1 release generated. Batch export across multiple contracts is on the engineering roadmap. And the visual hierarchy improvements within long checklists — which kept coming up tangentially during preview testing — have become their own small initiative.

Tools: Figma · FullStory · Maze · Jira