Smart Search

Contracting officers manage massive document libraries: contracts, amendments, renewals, line items, procurement records. Their job depends on finding the right information quickly, but a search that just returns a list of file names doesn't help much. Someone still has to open each document to check if it's the one they need. And in government contracting, getting it wrong isn't a minor inconvenience. It can mean a compliance gap, a delayed audit, or a missed FAR clause.

I designed Smart Search to close that gap. Give users enough context in the results themselves so they know what they're looking at, without losing the exact language and legal detail their work depends on. Balancing fast orientation against precise verification ended up being the thing I kept coming back to throughout this whole feature.

Before designing a single screen, I mapped out the end-to-end user flow so I could see the whole journey at once: setting up a search, scanning results, drilling into a specific document, all the way through to the moment a contracting officer confirms compliance. Laying it out this way made the decision points obvious and gave me something concrete to align product and engineering around before anything got built.

I also didn't map just one flow. I mapped a couple of different options I wanted to put in front of users. The flow branches at the result-exploration step into two paths: Option A, where clicking a result opens a sidecar preview with an AI summary and PDF viewer, and Option B, a denser list view that surfaces the same key information inline without a sidecar. Diagramming both routes side by side let me test each one against the same real tasks, so "which layout is better" became something I could actually validate instead of argue about.

This feature was originally scoped as a small, single-record-type search within Contract Writing. But I saw a bigger gap: the platform had no way to search across procurements, documents, and award data in one place. Users were bouncing between disconnected areas of the system just to find something they already knew existed.

Expanding the scope meant dealing with real disagreement, not just getting people excited about a good idea. An adjacent team building a separate acquisition platform pushed back. Their view was that search shouldn't live in Contract Writing at all, it belonged in their solution, for the sake of one unified experience in the future.

I got product managers, stakeholders, and designers from both teams into the same room and reframed the conversation. Instead of "our solution vs. theirs," it became "what do our users need right now, and what's the best path to get them there." The other team's roadmap didn't have room for this work anytime soon, and asking users to leave Contract Writing entirely just to search within it felt like the wrong tradeoff to make them wait on. I proposed building Smart Search inside Contract Writing now, in a way that could integrate into the broader platform later once that team was ready. That gave both sides something real: our users got the capability right away, and the other team's long-term vision didn't get steamrolled in the process.

We got alignment and shipped it. Feedback from users was unanimous that Smart Search meaningfully improved their efficiency in contract writing, which made the harder conversation worth having.

Internal reviews later confirmed people wanted an even bigger version of this: a single search spanning the entire suite, not just documents. But defaulting a search to pull every data type at once raised real performance concerns, and we were already up against a timeline. So we made a second tradeoff and shipped Smart Search for documents first, proved out the pattern, and pushed the full suite-wide search to a later phase. I'd rather ship something solid that earns trust than something ambitious that breaks under load.

Before I could design a layout, I needed to answer a simpler question: what does a contracting officer actually need to see about a result before they commit to opening it?

I went through a handful of mid-fi explorations testing different combinations of information: match reasoning, similarity scoring, contract value, vendor, contracting officer, tags, quick actions like opening a procurement directly in CW. Some combinations felt comprehensive but cluttered. Others felt clean but kind of useless. This exploration is what fed the two directions I eventually tested with real users.

The two testers split cleanly, and the reasons behind that split mattered more than either individual preference.

One tester, who reviews contracts as part of her daily work, preferred Option A. She could scroll a document preview and tell in seconds whether it was relevant, without leaving her search session. The upfront detail saved her a click and a context switch every time.

The other tester pushed back on Option A's centerpiece, the AI summary. In contract writing, he said, a summary just isn't enough. Contracting officers need the exact legal language, the surrounding paragraph, and often a specific FAR clause. Not a paraphrase of one. He preferred Option B's denser, more scannable layout because of that.

A lot of this feature comes down to one idea: never let the AI's confidence exceed what it's earned. The similarity score tells people how sure the match actually is. The AI summary sits next to the real document instead of replacing it. The AI Chat only shows up where it's scoped to answer honestly, and every answer it gives links back to the source it came from, so nothing has to be taken on faith. None of these are flashy decisions on their own, but together they're the actual guardrails, the thing that keeps an AI feature trustworthy instead of just impressive in a demo.

Designing search for people who verify legal compliance for a living taught me something I want to carry into any AI-powered tool I work on. Speed and precision aren't really competing with each other, they just show up at different moments. People want to move fast to find the right document, and then they want to slow way down and read the actual words once they get there. My job wasn't to pick one over the other. It was to design a system that respects both moments, and to build enough trust into the AI parts that people never have to wonder if the summary is hiding something the real document would've told them.

That's the kind of problem I want to keep working on. Not just adding AI somewhere it seems useful, but making sure the people using the tool are never worse off because the automation is there.