LinkSquares · AI
I inherited an engineering proof of concept that proved the model worked, but put six setup steps between the user and the answer. I used research, prototype testing, and a rapid redesign to reframe the product around the user's real job: ask a contract question, get the answer, verify the source, and save it only when it's worth reusing.
01 · Overview
LinkAI is the intelligence engine behind LinkSquares, a contract platform used by more than 1,200 customers. For our core market, lean in-house legal teams inside much larger companies, a credible AI experience was becoming a retention question. The first interaction had to feel like leverage, not setup work.
I led design end-to-end, from reframing a vague brief, through reworking what engineering had built, to a redesign that shipped to production.
02 · Problem
I was asked to design a feature called "Custom AI Values," a way for LinkSquares' AI to extract answers from contracts that didn't exist as structured data. The brief was vague. The team knew it involved AI extraction and that the results would become searchable, but nobody could articulate what the top use case actually was.
To find the missing user need, I went to the evidence we already had. Our UX researcher had a pipeline of beta users in an AI research tool, so I reviewed screen recordings and chat transcripts, queried the research corpus directly, and used Claude to help sort repeated behaviors into an intent taxonomy. The synthesis sped up the analysis. The categorization and the product interpretation were mine.
Two findings shaped the direction. Users were asking answer-shaped questions the product couldn't answer, like "what is the termination notice period?" And verification sat underneath every category: whatever legal users asked, they needed to see where the answer came from before acting on it.
I brought the taxonomy to the PM, EM, and data science team, and we aligned on extraction-powered Q&A as the first bet. It addressed the clearest demand, extended the search experience we already had, and used our contract corpus as an advantage. We consciously deferred risk assessment, playbook compliance, obligation management, and reminders. Extraction had to work before the product could responsibly recommend or act.
03 · Discovery
Without a clear use case, engineering built around their own guess: users would want to save custom AI values as permanent searchable fields. Part of that gap was mine. I was supporting another team at the same time and left the direction too broad. And with token limits, pricing, and expected usage still unresolved at the leadership level, the POC optimized for cost control.
The result put saving first. Six steps stood between a user and an answer: ask, search, confirm extraction, edit instructions, review five previews, give feedback on each. Before a single result hit the screen.
I ran a demo of the POC with our internal legal team. The tool had a ton of usability issues, but buried in that meeting was the moment that changed everything. Someone on legal asked about logo usage permissions across their contracts. Their reaction to the multi-step flow was immediate.
That reframed the whole problem. Engineering had designed for saving. Users needed the answer first. The save could come after, if they even wanted it.
The session made the problem visible, but it didn't immediately change the launch plan. Engineering had months invested and reasonably wanted to release and learn. I documented the trade-offs and escalated the launch risk: a poor first experience could teach customers the AI was cumbersome before we had proved its value. Objection alone wasn't enough, so I paired the escalation with a concrete alternative. When broader company changes moved the launch by two months, I used that window to build and test an answer-first prototype in under a week, using Claude and Figma Make to compress work that would normally take several weeks.
04 · Process
My audit of the existing build came back with three problems.
The team had months in the existing build. Scrapping it would slip the AI roadmap. So the redesign had to keep the backend and only change what users saw. I mapped what was movable with the lead engineer and data scientist.
Two changes drove the most discussion. We cut the "preview five examples" step: the data scientist confirmed the model could classify scope on its own, which made the gate redundant. And we moved from batch results to streaming with a stop button, which addressed engineering's cost concern and gave users a sense of progress.
Answer first, save later. Flipped the flow so users see results before being asked to configure anything.
Cut the 5-preview review step. The model could handle scope on its own; the user shouldn't have to.
Streaming results with a stop button. Users see progress as it runs; engineering keeps its cost control.
05 · Outcome
With the redesigned prototype, I ran moderated usability tests with external legal professionals. The scenario: marketing pings legal because the website has logos from companies who aren't even customers anymore. They need to know which logos they can use, by end of day.
The good news: the renamed two-mode search landed. Every participant understood the distinction between "basic search" and "deep analysis" immediately, and saw the value in having both options.
But I also learned things I wasn't expecting.
Impact
Impact on the user
Impact on the team
Impact on the business
The redesigned flow reached production in March 2026, after my role ended in a company reorganization, and LinkAI is publicly live today. I left before post-launch data was available, so I don't claim adoption numbers. The measurement plan I left behind tracked query completion and abandonment, citation opens as a signal of verification behavior, and conversion from one-time answers to saved AI Values.
06 · Reflection
From the usability findings, I designed a second iteration. I added a thought process component showing what the AI searched for in plain language, renamed "save prompt" to "save AI Value" with a first-time explainer modal, and pushed the PM to prioritize clause-level source linking, which every participant had asked for independently. I also designed the library screens with a live table of results.
Three things I'd carry forward. Define the user journey before a technical POC grows into the product; I should have left the team with a clearer use case when my attention shifted. Feasibility is not the same as user value; the POC answered "can we extract this?" but not "why would a legal user do this?" And escalation works best when it comes with a path forward. The decision changed because I brought evidence, a reframe, and a working prototype, not just a critique.
The result I'm proudest of: recognizing that a technically successful POC was solving the wrong job, and helping the team change course before launch.
