7 min read · 1,384 words

Proposal Writer

role

Product Designer

skills

0-1 Product Design
Customer Research
Enterprise UX
AI Product Design

Outcome

Proposal Writer went from a two-person, three-week prototype to a workflow Usul's defense-contracting customers use to turn a solicitation into a compliant first draft, grounded in their own past proposals instead of generic AI output. The team's shorthand for it in customer demos was getting users "80 to 90% of the way" to a submittable draft.

I owned the design end to end. I scoped the MVP, ran discovery with proposal writers across several companies, and iterated the interface through live customer demos until the product answered the objection every AI writing tool hits in this space, whether it could be trusted not to invent information. Proposal Writer's adoption surfaced the next gap in the workflow, the review and coordination happening around the document itself, which became Capture Space.

Challenge

Government proposals don't have a dedicated writer role at most small contracting companies; often, everyone's the proposal writer. The idea for this feature surfaced out of market research the team was running on Usul's contract inbox. Two competitors, GovWins and GovSignals, already had proposal writing, and what came back from customers was that support through the actual writing process, after they'd found a contract, was where the value would be.

The problem looked simple: help people draft a response. It wasn't. Every solicitation asks for something slightly different, page limits, font sizes, spreadsheets versus PDFs versus PowerPoints versus quad charts, submission through a portal versus email versus a standalone URL, SBIR filings with their own numeric structure instead of a standard outline. And the real bottleneck wasn't writing ability. Teams already leaned on ChatGPT heavily for structure, they just didn't trust it. It produced run-on, jargon-heavy sentences, and it couldn't tell them whether a requirement it surfaced actually came from the solicitation or was invented. One customer put the bar plainly during a later demo, asked what he'd want any AI proposal tool to get right:

It's just like not making up facts or at least be able to cite back where it got some information from.

User Research

I ran discovery directly with proposal writers to understand the actual process, not the stated one. The pattern was consistent. People assessed whether an opportunity was worth pursuing, pulled the solicitation documents, opened a blank Google Doc, pasted in the requirements, asked ChatGPT for a template, and started answering, switching constantly between three open screens, the doc, the original solicitation, and the chat window, because nobody trusted the AI-generated structure enough to stop checking it against the source.

That number told me where the real leverage was. Not in generating better prose, but in surfacing the right past content automatically.

Formatting requirements came up unprompted in nearly every interview, too. A team could get most of a proposal right and still lose on a technicality, wrong font size, wrong page count, because the specification lived in a different document than the one they were actively working from.

Solution

Scoping a three-week MVP

I worked from an early build a developer teammate had put together and broke it down into a redesigned three-panel concept, a table of contents on the left, the document in the middle, supporting information on the right. Success was measured against proposals actually reaching submission, not draft completion. From research, I narrowed the MVP to three recommended features: parse the solicitation to extract requirements, compliance details, page limits, and formatting specs into a checklist so nothing gets missed; analyze the solicitation's language to flag which terms and priorities the agency repeats, so users know what to emphasize; and an evaluation-criteria breakdown showing how proposals get scored.

That last one needed a custom report layout to be useful, more design effort than a two-person, three-week build could absorb for a feature that improved the experience without changing whether the proposal got submitted, so it shipped in the first build and was cut. The first version was intentionally bare, an empty document with section headers, per-section guidance pulled from the solicitation, and citations, built on TipTap Pro so we could turn it around fast. It answered the compliance problem. It didn't answer the blank-page problem.

From outline to library

About a week after shipping the outline, it was clear infrastructure alone wasn't enough. I designed the Proposal Library. Users upload past proposals and match them to a specific product, and the system extracts structured content, key personnel, technical performance, past performance, company overview, UEI and CAGE codes, NAICS codes, and automatically pulls the relevant blocks into a new outline whenever it matches that product. This directly answered the 75% reuse pattern from research. Instead of hunting through SharePoint or Drive for the right paragraph from a past win, the system surfaced it, in the team's own words, not a generic AI rewrite.

Customers validated this independently. A proposal lead at one of our customers described wanting something "almost like a notebook LLM," where he could drop in past non-CUI proposals and get a tailored first pass, the exact shape of what the library already did, scoped and black-boxed to a single customer's workspace.

Designing for how teams already work

The interface went through a real iteration cycle, not a straight line. The initial three-panel layout simplified down to two panels with a collapsible table of contents, plus a slide-out panel for citations so users could confirm a source without losing their place. Once research made clear teams were leaning on chat-based AI throughout their process no matter what we built, I reintroduced a third panel as a live editing agent. It rewrites a highlighted section on request, prompts for confirmation before applying changes instead of silently rewriting the whole document, and lets users toggle between chat, document, or both depending on how they want to work.

I added version history so people could see and revert to earlier states, and let them reference the opportunity's original documents alongside anything of their own while they worked. That confirm-before-applying behavior addressed a specific complaint I'd heard about other AI tools:

One of the issues I've had with AI agents in the past is you say, hey, I want to update this one section for this reason, and it just randomly changes everything else.

Lessons Learned

The clearest signal came from a customer who laid out exactly what he needed from an AI proposal writer before I'd shown him anything: cite every technical spec instead of inventing one, avoid the tics that make AI writing obvious, em dashes, run-ons, passive voice, and keep AI-generated text visibly separate from what a human wrote.

Proposal Writer already met most of that bar. What it didn't do yet, learn from a user's edits so it writes more like them over time, became a logged product direction instead of something I tried to force into an already-tight MVP. That's the judgment call this project kept coming back to: knowing which piece of feedback was core to trust, citations, no hallucination, and which was a real but secondary improvement.

The other lesson came from a different customer, whose proposal process runs through a formal, multi-week Shipley color-team review, blue, gold, and red team passes, closing with a white-glove review before submission. What they wanted most wasn't more writing help, it was visibility into who owned which section and when each review milestone was due.

That request sat outside what a document tool should own, but it pointed straight at the next problem, everything happening around the proposal, assignments, reviews, deadlines, still lived in scattered tools. That question became Capture Space.