01 · Problem
A single motion can eat 15 to 20 hours.
Immigration attorneys lose entire days to work that is necessary but not the actual lawyering: drafting, reformatting, and triple-checking documents against USCIS standards.
This one started as a problem that found us. Four of us were looking for a capstone, a lot of ideas were on the table, and this is the one that pulled us in because it was real.
Immigration attorneys run fifteen to twenty cases at once. Every case needs motions filed, every motion is six or seven documents, and all of it has to meet USCIS formatting standards exactly. A single motion exhibit packet can take 15 to 20 hours to assemble. Declarations and affidavits add hours of their own, and one small inconsistency can mean a rejection or a delay that costs the client real time.
So the most expensive hours in the practice go to formatting and proofreading instead of to the people the attorney represents. That is the gap PleadAI was built to close.
02 · Approach
Design thinking as the spine, an AI layer on top.
One attorney, thirty minutes, a hard deadline. So I set up the work to keep a real user in the room even when we could not reach one, and to move fast without losing the rigor.
The double diamond, with AI in every phase
The discover, define, create, test arc stayed the spine. The AI layer ran through every phase, from empathizing with the simulator to prototyping the build, with human validation as the deliberate interruption before anything shipped, and the whole thing looping back to iterate.
I led with research. One of us had a relative who is an immigration attorney, and he gave us thirty minutes. We listened, mapped every pain point, and built one persona so all four of us were designing for the same person instead of four different guesses.
That one call was also the constraint. One attorney, thirty minutes, no network of lawyers to go back to. So I took everything we heard from him, his history, his pain points, his frustrations, and turned it into a user simulator I could interrogate any time. Between the rare moments we could reach the real attorney, the user was still in the room. I would ask it where it would stop and double-check, what it would not trust, and it kept pushing the design forward.
From one interview to an agent I could talk to
I loaded the persona, his history, pain points, and frustrations, into an agent I named Marcus. He became a user I could interrogate at build speed, generating edge cases and pressure-testing flows between the rare calls with the real attorney. A technique, not a replacement.
On the method. A simulator is not a replacement for real research. It is a way to keep one real interview alive at build speed, so the persona generates edge cases and pressure-tests flows in the long stretches between the times you can reach the actual user.
You can see that pressure in the flow itself. The first version was a mostly linear best guess. After enough rounds with Marcus, where it would hesitate and what it would not sign off on, the flow grew the branches and checks the real work actually needed.
The first-pass flow, mostly assumptions
My early end to end flow, before I stress-tested it. One mostly linear path from first touchpoint to motion packet, built on guesses about where the lawyer would stop and double-check.
The flow after Marcus pushed back
The same journey after the simulator pressure-tested it: a returning-user path that skips onboarding, the iterative loops inside the drafting canvas, and a verification step before anything exports.
I had run sprints at Leapfrog, so I scoped this build the same way, in visible sprints. Nothing got built in one heroic overnight, and everyone could see what was in scope and what was not. That is how we kept the rigor while still moving fast.
Underneath all of it was one principle: save time while keeping the lawyer in control. The AI does the heavy lifting on the first draft and the formatting. The lawyer stays the one who reviews, edits, and signs off. We did not want a generic writing assistant pointed at legal text. We wanted a tool that understands the specific structure and requirements of immigration filings, so its output starts close to correct instead of close to plausible.
03 · Inside the product
Automate the drafting. Keep the lawyer in control.
PleadAI covers the full arc of a filing: it drafts the documents, formats them to USCIS standards, and validates the result before anything leaves the attorney's hands. Here is the drafting flow, end to end.
A filing does not start with a blank page. It starts with the case.
Start from the case, not a blank page
A filing begins with the client's Alien Registration Number. PleadAI pulls the case so the lawyer never re-keys what the system can already find.
The case file, assembled
Client details, court, judge, and the upcoming hearing land in one place. This is the context every document downstream is built from.
The drafting canvas
Six documents in the sidebar, the active draft in the center, and an AI assistant on the right that asks case-specific questions before it writes a word.
Templates that match the filing
Each document offers standard, detailed, and simplified structures, so the draft starts from the right shape for the motion instead of a generic one.
All six documents, complete
The packet reaches 100 percent with every document drafted and marked done. The lawyer reviewed each one. The AI did the assembling.
At a hundred percent, the packet is assembled and every document is marked done. The attorney reviewed each one. The AI did the assembling. Work that took 15 to 20 hours comes down to about 40 minutes, with the attorney still reviewing every line.
On the build side, this is a React and Next.js front end, and I owned the design system that holds it all together. That system is where the harder craft problem lived.
04 · Built with AI
One designer, an AI, and a design system that had to hold.
When you build a front end with AI generating components across a whole semester, the real risk is drift: the visual system pulling slightly off course every session until the codebase feels like three different products.
I owned the design system, and that is where the interesting craft problem lived. With AI writing a lot of the component code, every session is a chance for the system to slip. The AI would generate its own version of a component instead of reusing ours, and over a few weeks you get twelve slightly different shades of the same purple.
That is not hypothetical. A few weeks in, the deep purple on the document upload card looked a touch lighter than everywhere else. The AI had eyedropped a near-match value in one session instead of reaching for the token. Harmless once. Corrosive if it keeps happening.
When you build with AI, does the design system hold, or does the codebase slowly become three different products? Writing the conventions down once, where the AI reads them every session, was the difference.
My answer was to write the design conventions down once, in a place the AI reads automatically every session. I built the design system, then a Claude Code skill file that teaches the AI the system: the rules, the references, and documentation for every component. Tokens became the single source of truth, one place per color, spacing, radius, and shadow value, referenced everywhere. That is what makes consistency something you can actually enforce instead of police.
The file Claude reads before it writes a line
The Claude Code skill file for the design system. A mandatory first step points the AI at source_path.md, so every session it pulls real components and tokens from what already exists instead of generating its own. This is the file that makes the system the single source of truth.
The most valuable part of the skill file turned out to be the anti-patterns list, written as plain rules. Never hard-code a color. Never hard-code spacing. Never import an icon package directly. Never rebuild a component that already exists, check the catalog first. A catalog of more than forty components documented every one, its props and variants and usage, so the AI pulled from what we had instead of reinventing it, and flagged when something genuinely new was needed so we could decide together whether to add it. A setup script made the system installable into any project and wrote the real import paths, so the AI imported correctly from the start.
More than forty components, one .jsx each
Every component lives in design_system/components as its own .jsx module, from Accordion and Button to DataTable and Drawer, with CaseCard.jsx open here. Splitting them this way keeps the system stable: the AI checks the catalog and reuses what is here instead of rebuilding a twelfth slightly different version, and one component can change without breaking the rest.
We started monolithic, one big design system file, because that let us iterate fast early on. Then we went modular for production: a folder per component, logic and styles split, a clean barrel export. The division of labor was clear across the four of us. I owned the rules, the token decisions, the anti-patterns, and the catalog. The system had to stay coherent not just in my screens but everywhere the AI-integration and backend work surfaced in the UI.
The insight that made AI consistency enforceable
Tokens are not a nice-to-have when you build with AI. They are the mechanism. With one source of truth per value and a skill file the AI reads every session, the visual system starts from the same foundation each time instead of drifting a little further off with every generated component. You define the rules once and let the AI enforce them.
05 · The turn
The real problem was never time. It was trust.
Right before we tested with the real attorney, the simulator caught something we had missed, and it reframed the whole project.
Our entire promise was fifteen to twenty hours down to minutes. I ran the full flow past the simulator one more time, and it pointed out the hole. The attorney would still have to check every document by hand, and that re-checking would eat the time right back. It even suggested the fix: add a quality check at the end, before the packet downloads.
That reframed everything for me. The problem was never just time. It was trust. A non-expert was being asked to put his name on probabilistic output, and saving him hours meant nothing if he could not trust it without redoing the work. I had been designing for speed. The actual job was trust through verification.
One check across the whole packet
Before anything downloads, PleadAI runs an automated review across all six documents to catch the inconsistencies that get filings rejected.
The two places the AI shows its work, up close: the questions it asks before drafting, and the report it returns before download.
How the assistant opens
Before drafting, it asks the questions that actually shape a motion to reopen: what new evidence emerged, why it wasn't available earlier, how it changes the case.
What the check returns
Each rule passes, warns, or errors, with a one-line reason and a Fix with AI shortcut. Name consistency passed. The A-Number mismatch did not.
Fixes the lawyer approves
When the check flags a missing A-Number, the AI proposes the exact edit and shows where it goes. Nothing changes until the lawyer hits Apply Fix.
Clear to file
Errors block the download, warnings do not. Once the packet passes, the download opens up, with the remaining warnings still visible for a final judgment call.
Export, formatted to standard
The finished packet exports as a single combined PDF or one file per document, named and formatted to USCIS standards.
I did not want to assert the quality check was better. So I built two versions, one with the check and one without, and compared them on real working code. I also grounded the drafting in real motion examples, so the AI was matching formats that actually get filed instead of inventing them.
The day before the expo, we put it in front of the same attorney. The version with the quality check landed, because he could verify it. And he pushed us one step further. He wanted to tweak the AI's wording without regenerating the whole document, so I added inline editing: select a sentence, give it a prompt such as make this more standardized, and it changes just that. We tested again, and it held.
06 · Outcome
Coherent by design, and shown to the people it was built for.
PleadAI is a working product, validated with the attorney it was built for and presented at our Capstone Expo. We built it as a capstone, on purpose, and we were honest about where it stops.
We built this as my capstone at San Francisco Bay University and presented it at the Capstone Expo. People resonated with the problem immediately and appreciated how specific the focus was. A tool that does one hard thing well, for one profession, tends to land.
You can try it today, but we were clear-eyed about what it is. None of us had the go-to-market experience or the strategy to take it further, so we scoped it as a capstone instead of pretending it was a startup. We are not claiming usage numbers we do not have. What we can claim is a real product, grounded in a real attorney's workflow, that he could verify and trust.
The design system technique paid off in a way that is easy to undersell. Writing the skill file forced the four of us to agree on our conventions explicitly, out loud, instead of each carrying a slightly different version in our heads. The system held. And the discipline that kept it coherent is the same discipline I would bring to any product team.
The team. PleadAI was a semester-long capstone built by a team of four at San Francisco Bay University, advised by Prof. Ahmed Banafa. Saurav Bhatta led backend and integration, Nyan Wai Phyo led AI integration, Ali Khalilabadi led database and testing, and I led UX and front end and owned the design system. Shown at the Capstone Expo, 2026. I wrote up the design-system technique behind this build in my article Stop Re-Explaining Your Design System Every Session.
07 · What I learnt
The lessons that stuck.
The parts of this build I keep coming back to, less about the screens and more about how I set the work up.
The real problem was trust, not speed. I designed for hours saved. The simulator showed me that hours saved mean nothing if the attorney cannot trust the output enough to skip re-checking it. The quality check exists because of that reframe, and catching it before our user did is the part I am proudest of.
A persona is more useful alive than on a slide. Turning one thirty-minute interview into a simulator I could interrogate kept the user in the room between the rare times I could reach the real attorney. It is not a replacement for real research, and I would say that plainly. It is a way to keep one real interview alive at build speed.
Building with AI drifts unless you govern it. The design system was the mechanism, not a nice-to-have. Tokens as one source of truth and a skill file the AI reads every session is what kept the product one coherent thing instead of a slow slide into three different products.
Proving a call beats asserting it. Instead of claiming the quality check was better, I built both versions on real code and let the attorney feel the difference. The comparison did the convincing.
Knowing what not to chase is its own skill. We built and showed a real product, and we were honest that none of us had the go-to-market experience to take it further. Scoping it as a capstone, instead of pretending it was a startup, was the right call.