Case study coming soon — this project is still being written up. Check back for the full story.
Company Details
Document Crunch is an AI-powered contract review platform built for the construction industry. It helps general contractors, subcontractors, and owners identify risk in contracts and project documents quickly and accurately.
The platform helps legal, risk, and operations teams review contracts at scale — surfacing critical clauses, obligations, and red flags so teams can make faster, more confident decisions.
As a product designer, I worked across the full product lifecycle — from discovery and user research through design, front-end development, and QA — to ship features that directly impacted how users engage with contract documents.
The Team
- 1 Product Designer
- 1 Product Manager
- 3–4 Engineers
My Role
UI/UX Design, User Research, Prototyping, QA, Cross-functional Collaboration
The Challenge
Every contract review generates action items: get the insurance certificate before project start, flag the indemnity clause for outside counsel, follow up on the payment terms before signing. Before the Task Management System, none of those action items lived anywhere near the contract. They went into Asana, Slack threads, email chains, or a legal pad on someone's desk — disconnected from the document that created them and invisible to everyone else on the team.
The result was predictable: obligations got missed. Not because reviewers were careless, but because the tool that surfaced the obligation offered no way to act on it. The ask from enterprise customers was consistent: "I need to be able to create a task from this clause and assign it to someone without leaving Document Crunch." Building that workflow was both a core user need and a meaningful product stickiness driver — if action items lived in the platform, teams had a reason to come back every day, not just at the start of a new review.
The Process
Iterate
Deliver
Research
User Interviews
I interviewed project managers, risk officers, and legal ops leads at GC and owner-rep firms — teams where contract review was a team sport, not a solo activity. The focus was on what happened after a provision was flagged: who owned the follow-up, how they tracked it, and how often items fell through the cracks during handoffs.
The picture that emerged was consistent: the most experienced reviewers had personal systems (a running Notion page, a weekly Asana filter, color-coded email flags) that worked well for them individually but were completely opaque to everyone else. Junior team members had no system at all. What everyone wanted was visibility: "I want to see, in one place, everything that's open, who owns it, and when it's due — and I want it to know which contract the task came from."
Key Findings
Follow-up tasks from contract reviews were tracked in at least 3–4 different external tools per team (Asana, Slack, email, and spreadsheets were the most common combination), with no single source of truth.
The clause-to-task link was critical: users needed to see which contract clause created the task in order to act on it confidently. Tasks without a source felt untrustworthy.
Cross-portfolio visibility was the primary manager ask. Individual reviewers wanted task lists; managers wanted dashboards across all active projects and all open obligations.
Due dates tied to contract milestones (start dates, signing deadlines) were more meaningful than absolute calendar dates — users wanted tasks to say "due before project kickoff," not just a date that had lost its context.
AI-suggested action items were welcomed — but only if users could verify the obligation in the contract text. "The AI told me to do this" was not sufficient justification for anyone we interviewed.
Task creation needed to be fast — ideally one click from a flagged provision. Multi-step task creation forms were used once and abandoned. Every additional field reduced adoption.
Design & Iterate
Wireframes & Key Design Decisions
The biggest structural decision was where tasks lived in the information architecture: embedded per-document (visible only when reviewing a specific contract) or in a global workspace (visible across all projects from a top-level dashboard). User research pushed strongly for both — reviewers wanted to create tasks inline while reviewing, and managers wanted to see everything in one place. The final design supports both: tasks are created in-document and surface in a global Task Inbox accessible from the main navigation.
The creation flow went through significant iteration. Early wireframes included title, description, assignee, due date, priority, and linked clause fields — six fields before a user could save a task. Usability testing showed completion rates dropped sharply after the third field. We cut to three required fields (title, assignee, due date) with an optional clause link auto-populated from context, and adoption in testing improved immediately.
Before & After
Before, there was no task surface in Document Crunch at all — a flagged provision led nowhere unless the reviewer manually noted it elsewhere. After, a single click on any provision surfaces a task creation panel with the clause pre-linked, and every task created in the platform rolls up into a shared team inbox with assignee, due date, status, and source contract visible at a glance.
Develop & Deliver
The Final Design
The Task Management System integrates action item tracking directly into the contract review workflow. Reviewers create tasks from any flagged provision with a single click, assign them to team members, and set due dates — all without leaving the document. Every task carries a link back to its source clause so recipients can verify the obligation in context. A global Task Inbox aggregates all open tasks across every active project, giving managers and legal ops leads the cross-portfolio visibility they need without requiring a separate tool.
Clause-Linked Task Creation
Any provision, checklist item, or annotation in Document Crunch can become a task in one click. The task creation panel pre-populates the clause link automatically, so the person receiving the assignment can jump directly to the source text to understand the obligation. The form is intentionally minimal: title, assignee, and due date are required; everything else is optional. Tasks created this way carry their contract and clause reference permanently, even after the contract's review is complete — so when a follow-up lands six weeks later, the context is still there.
Global Task Inbox
The Task Inbox is a cross-portfolio view of every open task across all active contracts — accessible from the main navigation and filterable by assignee, due date, contract, and status. For legal ops managers overseeing multiple project teams, this is the daily driver: a single view that answers "what's open, who owns it, and what's at risk of missing a deadline" without clicking into individual documents. Tasks can be reassigned, updated, and marked complete directly from the inbox, making it a full task management surface rather than a read-only summary.
AI-Suggested Action Items
When the AI detects contract obligations that commonly generate follow-up tasks — insurance certificates, required notices, approval deadlines, negotiation items — it surfaces suggested action items alongside the flagged provision. Each suggestion includes the obligation in plain language, the clause it came from, and a one-click "Create task" button. Suggestions are advisory, not automatic: users review and approve before any task is created, and can edit the title or reassign before saving. For reviewers building a task list from scratch, AI suggestions dramatically reduce the time from "review complete" to "team has clear next steps."
Project Takeaways
A note on impact data: the Task Management System is still rolling out across our customer base, so we don't yet have post-migration metrics to quantify how the new design compares to 1.0. The takeaways below reflect the design and build process; comparative data will be added once adoption matures.
Adding task management to an existing product forces a question most feature roadmaps avoid: does this belong here, or are we just building a worse version of a tool people already have? The answer for Document Crunch was clear: because tasks needed to carry contract context that no external tool could provide, the clause link was the differentiator. Without it, we would have been building a worse Asana. With it, we were building something that actually closed the loop between "identified a risk" and "acted on it."
The friction-reduction work on the creation flow had a bigger impact than any visual or structural decision in this project. Going from six fields to three — and auto-populating the clause link from context — wasn't a design insight, it was a user research finding that took three testing rounds to surface clearly. The teams that had the highest task creation rates weren't the ones with the most complex workflows; they were the ones where creating a task required the least thought. Minimum viable input for maximum follow-through is a lesson I've carried into every task-adjacent surface I've designed since.