Designing SARGE: The AI Platform That Could Change Law Enforcement Forever

Not all projects are the same. Some projects are about making things easier. Better flows. Cleaner interfaces. Faster onboarding. You optimize, you polish, you ship.

SARGE was different.

SARGE is an AI platform for police officers. It provides real-time legal guidance, policy lookups, probable cause analysis, affidavit generation, Miranda compliance, and tactical planning — all from a phone, often during active incidents.

The moment we understood what this product actually did, we understood why it scared us.

In most AI products, a hallucinated answer is annoying. The user gets bad information, maybe wastes some time, and moves on.

In SARGE, a hallucinated answer can lead to:

• An unlawful search

• Evidence being thrown out of court

• A wrongful arrest

• A civil rights violation

• A lawsuit against the officer and the department

• A failed prosecution that puts a dangerous person back on the street

This wasn't a productivity tool. This was a decision-support system operating in environments where the consequences of bad information are measured in careers, convictions, and constitutional rights.

That realization shaped everything.

"In most products, the cost of a mistake is frustration. In this product, the cost of a mistake is a lawsuit — or worse."

How it started

The founder was a law enforcement industry veterans — someone who had spent years inside the system and understood a problem that most technology companies never see.

Police officers are expected to be walking legal encyclopedias.

During a traffic stop, an arrest, an investigation, or an interview, an officer is expected to recall — accurately and instantly — the relevant statutes, department policies, case law precedents, procedural requirements, and constitutional standards that apply to that specific situation.

The reality: nobody can do that.

Not consistently. Not under stress. Not at 2 AM during a contested vehicle search on the side of a highway.

Departments train officers extensively. But the volume of legal knowledge — and the speed at which case law evolves — creates an impossible gap between what officers are expected to know and what they can realistically recall in the field.

The founder wanted to close that gap.

Not with a search engine. Not with a chatbot. With an AI system that understood law enforcement scenarios well enough to provide reliable, cited, legally defensible guidance in real time.

He came to us because he had the legal knowledge and the domain expertise. What he needed was a product — a designed, usable, trustworthy product that officers would actually use during the most stressful moments of their job.

The design challenge we'd never faced before

We've designed AI products. We've designed enterprise platforms. We've designed complex workflow systems.

We had never designed a product where the UX itself carried legal liability.

Every design decision in SARGE had a second dimension that most products don't:

This wasn't a UX challenge. It was an accountability challenge wearing a UX hat.

Understanding how officers actually think

Before we designed anything, we needed to understand the mental model of a police officer during active duty.

And what we found contradicted the assumption baked into most legal technology products.

Officers don't think in legal databases

Legal tech typically organizes information the way lawyers organize information: by statute, by jurisdiction, by case citation, by legal category.

Officers don't think that way.

They think in scenarios.

An officer standing next to a vehicle during a traffic stop isn't thinking: "What does statute 42.065 say about probable cause for vehicle searches?"

They're thinking: "Can I search this car?"

An officer at a domestic disturbance isn't thinking: "What are the detention standards under Terry v. Ohio?"

They're thinking: "Can I detain this person while I investigate?"

The gap between how legal information is structured and how officers need it is enormous. Every existing legal database, every department manual, every policy document is organized for reading. Officers need information organized for acting.

This insight became the foundational design principle: everything in SARGE is organized around scenarios, not statutes.

"Officers don't ask 'what statute applies?' They ask 'can I search this vehicle?' The entire product was built around that difference."

The stress factor

Here's something we had to internalize early: this product would be used during the worst moments of someone's workday.

Not sitting at a desk. Not in a quiet office. Not with time to think.

SARGE would be used:

• During arrests

• During traffic stops with uncooperative subjects

• During domestic violence calls

• During active investigations

• During suspect interviews

• In the dark, in the rain, with gloves on, with adrenaline running

This meant every conventional UX assumption had to be questioned:

• Small touch targets? Unusable with gloves or shaking hands.

• Multi-step navigation? Impossible when you have three seconds.

• Dense text? Unreadable under stress and poor lighting.

• Subtle UI indicators? Invisible when cognitive load is maxed.

We weren't designing for calm users in comfortable environments. We were designing for trained professionals under operational pressure.

Three products, one ecosystem

SARGE wasn't a single app. It was an ecosystem of three interconnected products, each serving a different context:

1. The Mobile Application

The field tool. Used by officers during active duty.

This was the product's heart — the AI assistant, voice interaction, legal guidance, Miranda compliance, perimeter planning, and affidavit initiation all lived here.

Every design decision for mobile optimized for: speed, clarity, and minimal interaction under stress.

2. The Web Affidavit Editor

The desk tool. Used after incidents for reviewing, editing, and finalizing AI-generated probable cause affidavits.

This was a precision environment — detailed editing, version tracking, legal review, and document generation.

Every design decision for web optimized for: accuracy, completeness, and defensibility.

3. The Marketing Website

Not a marketing website in the traditional sense. This was a trust-building platform — explaining the product's capabilities, security posture, compliance standards, and agency adoption process to department decision-makers.

Every design decision for the website optimized for: credibility, clarity, and institutional confidence.

Three products. Three contexts. One design language. One trust threshold.

Designing the AI assistant

The core of SARGE's mobile experience was the AI assistant — a conversational interface where officers could ask natural-language legal and policy questions and receive cited, authoritative answers.

This sounds simple. It was the hardest thing we've ever designed.

The trust problem

Here's the fundamental tension: officers needed to trust the AI enough to act on its guidance, but the AI could never be presented as infallible.

If the interface felt uncertain — littered with disclaimers, hedging language, "this is not legal advice" warnings on every screen — no officer would use it. They'd go back to guessing or calling a supervisor.

If the interface felt too certain — presenting AI outputs as absolute truth without nuance — it would create liability. Legal questions often have nuanced answers that depend on jurisdiction, department policy, and specific circumstances.

We needed to find the space between authoritative and honest.

How we solved it: citations as trust architecture

The answer was citations.

Every AI response in SARGE includes its supporting authority:

• Relevant statutes — the specific legal code that applies

• Case law — controlling court decisions that shape interpretation

• Department policy — the officer's own department's standards

• Legal bulletins — current interpretive guidance

The citations aren't decorative. They're structural. They allow officers to:

1. Verify the AI's guidance against primary sources

2. Reference specific authority if challenged

3. Document the basis for their decisions

4. Defend their actions in court or administrative review

The AI doesn't say "you can search the vehicle." It says "based on [statute], consistent with [case law], and per your department's [policy section], the following conditions would support a vehicle search..."

Trust wasn't designed through visual polish. It was designed through evidentiary transparency.

"We didn't design the AI to look trustworthy. We designed it to prove trustworthiness — with every response, every citation, every source."

Designing for liability without creating liability

This was one of the most nuanced UX challenges in the project.

SARGE helps officers make better decisions. But it cannot — legally, ethically, or practically — make decisions for them.

The language throughout the product was carefully calibrated:

• Never: "You can arrest this suspect."

• Instead: "Based on the facts you've described, the following elements of probable cause may be present..."

• Never: "This search is legal."

• Instead: "Under [statute] and consistent with [case law], the following conditions support a lawful search..."

This wasn't about adding disclaimers. It was about designing an interaction model where the AI provides analysis and the officer retains judgment.

The AI is a partner, not a commander.

Every screen, every response, every interaction reinforced this dynamic. The officer always makes the call. SARGE makes sure they have the information to make it well.

Voice-first: because officers can't always look at a screen

One of the most critical — and most underappreciated — design decisions: SARGE needed to work through voice.

An officer conducting a traffic stop can't pull out a phone, unlock it, open an app, navigate to the AI assistant, and type a question. They need to speak.

"Can I search this vehicle if I smell marijuana but the driver says it's from a legal CBD product?"

That's a real question. Spoken naturally. While managing a situation.

SARGE's voice interaction was designed to handle exactly this:

• Natural language input — officers speak the way they think, in scenario-based questions

• Structured audio responses — the AI responds with clear, parsed guidance that's comprehensible by ear, not just by eye

• Hands-free operation — the entire interaction can happen without touching the screen

• Ambient noise tolerance — designed for roadside, outdoor, and chaotic environments

Voice wasn't a feature. It was a survival mechanism for the product's usability in real field conditions.

The voice design problem nobody talks about

Designing voice responses for AI is fundamentally different from designing text responses.

When you read a cited legal response on screen, you can scan, skip, re-read, and reference. When you hear a cited legal response, you get one pass. If the response is too long, too dense, or too unstructured, the officer misses critical information.

We designed voice responses with a different information hierarchy than text responses:

1. Lead with the answer — the actionable guidance first

2. Follow with the authority — the primary legal basis

3. Offer detail on demand — "Would you like me to explain the case law?"

Text responses could be comprehensive upfront. Voice responses had to be layered — essential first, depth available.

This dual-mode response architecture — one for eyes, one for ears — was one of the most technically demanding UX challenges in the project.

The Probable Cause Affidavit Builder

If the AI assistant was SARGE's brain, the affidavit builder was its backbone.

Probable cause affidavits are the documents officers write to justify arrests, searches, and warrants. They're legal instruments that can be challenged in court. A poorly written affidavit — one that's missing key elements, contains inconsistencies, or fails to establish probable cause clearly — can result in evidence suppression, case dismissal, or civil liability.

Officers spend enormous amounts of time writing these documents. And most of them aren't writers. They're trained in law enforcement, not legal drafting.

SARGE's affidavit builder changed the process entirely.

How it works

Instead of staring at a blank document, officers walk through a guided conversation:

1. Dictate the facts — speak or type what happened, in natural language

2. AI identifies gaps — the system analyzes the narrative and identifies missing elements that a complete affidavit requires

3. Smart follow-up questions — instead of a generic form, the AI asks only the questions that are relevant to this specific incident

4. Structured output — SARGE generates a formatted, legally structured affidavit from the collected information

5. Review and refine — the officer reviews, edits, and approves the final document

The magic was in step 2 and 3: smart follow-up questioning.

Why smart follow-ups changed everything

Traditional affidavit tools use forms. Fixed fields. Every officer fills out the same template regardless of the incident type.

The problem: incidents are wildly different. A DUI stop has different probable cause elements than a burglary arrest. A domestic violence call requires different documentation than a drug possession case. Fixed forms either ask too many irrelevant questions (creating fatigue) or miss critical ones (creating legal vulnerability).

SARGE's follow-up system was dynamic. It analyzed the officer's narrative and identified what was missing for this specific incident.

If an officer described a vehicle search but didn't mention what established probable cause, the system would ask: "What did you observe that led you to believe contraband was present?"

If an officer described a detention but didn't address reasonable suspicion, the system would ask: "What specific behavior did you observe that aroused your suspicion?"

Every question was contextual. Nothing was generic. The system understood what type of incident it was dealing with and asked only what was needed to make the affidavit legally complete.

This was one of the most significant UX innovations in the entire platform — and one of the hardest to design, because the interaction model had to feel like a conversation, not an interrogation.

"The affidavit builder didn't ask officers to fill out forms. It asked them to tell their story — then made sure the story was legally complete."

The Web Affidavit Editor

Field-generated affidavits needed a second life — a desktop environment where officers, supervisors, and department reviewers could examine, refine, and finalize documents before they became official legal instruments.

The web editor was designed for precision:

• Full-text editing with legal formatting preserved

• Section-by-section review with AI-highlighted areas that might need strengthening

• Version tracking so every edit was documented

• Approval workflows for supervisory review

• Export and generation — producing court-ready PDF documents

The mobile app captured the story. The web editor made sure it held up in court.

The Dynamic Perimeter System

This was the feature that surprised us the most.

When we first heard "dynamic perimeter planning," we assumed it was a mapping tool. Drop pins on a map. Draw a circle. Done.

It was far more complex than that.

In law enforcement, establishing a perimeter during an active incident — a fleeing suspect, a barricaded subject, an active pursuit — requires calculating:

• The suspect's last known location

• Direction of travel

• Time elapsed

• Speed estimates

• Number of suspects

• Available units

• Geographic obstacles

• Entry and exit points

Officers do this mentally, under extreme time pressure, with incomplete information.

SARGE's perimeter system took the inputs an officer could provide — location, direction, timing, suspect count — and generated tactical perimeter recommendations. Not static. Dynamic. As new information arrived, the perimeter updated.

From a design perspective, this was one of the most visually complex features in the platform. We had to present geographic information, tactical recommendations, unit positioning, and real-time updates in a mobile interface that an officer could comprehend in seconds.

Miranda Compliance

Miranda warnings are constitutionally required before custodial interrogation. Get them wrong — wrong language, wrong timing, missing documentation — and statements become inadmissible.

Most departments use laminated cards. Officers read from them. There's no documentation that the warning was given, understood, or acknowledged.

SARGE digitized the entire Miranda workflow:

• Adult warnings — standard Miranda language

• Juvenile warnings — modified language required for minors

• Multilingual support — Miranda in the subject's primary language

• Digital acknowledgment — signatures captured on-device

• Refusal documentation — if a subject refuses to sign, that refusal is documented

• PDF generation — court-ready documentation produced immediately

This wasn't a flashy feature. It was a compliance feature. The kind of thing that doesn't make a demo exciting but prevents cases from falling apart.

"The Miranda feature will never make a marketing highlight reel. But it might be the feature that saves the most cases from being thrown out."

The visual language of trust

The visual design of SARGE was one of the most intentionally restrained systems we've ever created.

We had to resist every instinct to make it look like a modern AI product.

What we avoided

No glowing gradients. AI products love luminous, futuristic color treatments. For a law enforcement tool, that aesthetic communicates "experimental" — exactly the wrong signal.

No playful illustrations. The subject matter is serious. Illustrations that work in consumer apps feel trivializing here.

No chatbot personality. SARGE doesn't have a name, an avatar, or a conversational personality. It's a system, not a character. Officers need a tool, not a companion.

No consumer-app patterns. Rounded cards, bouncy animations, casual typography — all of it signals "this was designed for everyone." SARGE needed to signal "this was designed for professionals."

What we chose instead

Professional authority. The visual language borrows from institutional design — government systems, military interfaces, operational dashboards — while being dramatically more usable.

High contrast, high legibility. Text needed to be readable in patrol cars, in direct sunlight, in the dark, on screens covered in smudges. Contrast ratios weren't just WCAG-compliant; they were field-tested for operational reality.

Deliberate color use. Color carries meaning, not decoration. Status indicators. Alert levels. Action hierarchy. Every color in the system maps to a functional purpose.

Large touch targets. Every interactive element was sized for gloved hands, for shaking hands, for hands that just wrestled a suspect into handcuffs. Standard mobile touch targets weren't enough. We increased them across the board.

Minimal animation. Most transitions are instant. In a high-stress environment, waiting for a animation to complete — even a 300ms fade — feels like the system is slow. Speed is trust.

The design needed to communicate one thing above all else: this is a serious tool for serious work.

The marketing website — selling trust, not features

The SARGE website had a different job than most marketing sites.

It wasn't selling a product to individual users. It was persuading police departments — risk-averse, procurement-heavy, compliance-driven institutions — to adopt an AI system for their officers.

That's a fundamentally different sale.

Department decision-makers care about:

• Liability reduction — "Will this reduce our legal exposure?"

• Compliance — "Does this meet federal and state standards?"

• Security — "Where does our data go? Who can access it?"

• Policy alignment — "Can this be configured to our department's specific policies?"

• Evidence defensibility — "Will the outputs hold up in court?"

• Officer adoption — "Will our officers actually use this?"

They do not care about:

• Gradient backgrounds

• AI buzzwords

• Startup energy

• "Powered by machine learning" badges

The website was designed as a trust document, not a landing page.

Every section answered a specific institutional concern. Security architecture was explained clearly. Compliance standards were documented. Use cases were illustrated with operational scenarios. The tone was direct, professional, and evidence-based.

We designed it to survive a procurement committee meeting.

"The website wasn't designed to impress. It was designed to survive a room full of skeptical police chiefs asking hard questions."

What made this project uniquely difficult

The liability razor.

Every piece of language — every label, every tooltip, every AI response format — had to walk a razor-thin line between helpful and prescriptive. "You should" became "the following conditions may apply." "This is legal" became "under [authority], the following standard applies." We spent more time on language design than on visual design. In a product where words become legal evidence, copywriting is architecture.

Designing for users who don't trust technology.

Law enforcement culture is pragmatic and skeptical. Officers have seen technology promises before — systems that were supposed to help but created more paperwork, more complexity, more liability. SARGE had to overcome not just usability challenges but cultural resistance to AI-assisted decision-making. Every interaction needed to demonstrate value immediately, not after a learning curve.

No room for progressive disclosure.

In most products, you can introduce complexity gradually. Show the basics first. Reveal advanced features over time. In SARGE, an officer's first interaction might be during an active arrest. There's no time for tutorials. No tolerance for hidden features. The system had to be instantly comprehensible — on the first use, under pressure, with no prior training assumed.

Voice and text had to work independently.

Most apps treat voice as an input method — speak instead of type. In SARGE, voice was a complete interaction mode. The entire AI experience — asking questions, receiving answers, following up — had to work purely through audio. This meant designing two parallel interaction architectures: one visual, one auditory. Both had to deliver the same quality of information with different constraints.

The follow-up question problem.

The smart follow-up questioning in the affidavit builder was elegant in concept and brutal in execution. The questions had to be specific enough to gather what was legally needed, but they couldn't feel like an interrogation. Officers are trained to be the ones asking questions — being questioned by a system creates psychological friction. We went through multiple iterations on tone, pacing, and framing before the follow-ups felt like professional collaboration instead of bureaucratic grilling.

The design system underneath

A platform spanning mobile, web, and marketing — with requirements for extreme readability, stress-tested usability, and institutional credibility — needed a design system that was as disciplined as its users.

Principles

Clarity over cleverness. No interface element exists for aesthetic reasons. Every component communicates function.

Speed over polish. Transitions are minimal. Loading states are informative. Nothing delays an officer who needs an answer now.

Consistency across contexts. The same interaction patterns work on mobile and web. The same color meanings apply across all three products. An officer who learns the mobile app intuitively understands the web editor.

Scalability for departments. The system needed to accommodate department-specific customization — policies, procedures, branding — without breaking the core experience.

Key components

Citation cards. The atomic unit of trust. Every AI response references authority through citation cards — tappable elements showing statute numbers, case names, and policy sections. These had to be scannable in a list, readable when expanded, and functional in both voice and text modes.

Status indicators. Active incidents, pending affidavits, Miranda status, perimeter updates — the system has dozens of states. Each one needed to be instantly recognizable through color, icon, and position. Ambiguous status in this product isn't a UX issue — it's an operational risk.

Affidavit sections. Structured document components that maintained legal formatting while allowing in-line editing. These bridged the gap between the mobile capture experience and the web review experience.

Map components. Custom-designed for the perimeter system. Standard map UIs (Google Maps, Mapbox defaults) weren't sufficient — they're designed for navigation, not tactical planning. We built overlays for perimeter zones, direction indicators, unit positions, and dynamic boundary updates.

Input components. Oversized, high-contrast, clearly labeled. Every input — text, selection, voice activation — was designed for imperfect conditions: gloves, darkness, distraction, urgency.

Reflection

SARGE was the most consequential product we've ever designed.

Not the most complex. Not the most visually ambitious. Not the largest in scope.

But the most consequential — because the distance between good design and bad design, in this product, is measured in legal outcomes and human rights.

A few things this project permanently changed about how we think:

Design carries weight beyond the screen.

In most products, design affects satisfaction, engagement, and conversion. In SARGE, design affects whether an officer makes a lawful decision, whether a case survives court, whether someone's rights are protected. That weight changes how you approach every decision — from color choice to word choice to information hierarchy.

Trust is the product.

SARGE could have the best AI, the most comprehensive legal database, and the most accurate citations in the world. If officers don't trust it, none of that matters. Trust isn't a feature you add. It's the cumulative result of every interaction, every response, every visual signal telling the user: "This system is reliable. This system is on your side. This system will not get you into trouble."

Designing for stress is designing for honesty.

When we stripped away everything that wasn't essential — animations, decorative elements, progressive disclosure, subtle interactions — what remained was a more honest product. No hiding behind polish. Every element had to earn its place by being genuinely useful under pressure. That discipline improved everything.

Language is the most important design material.

In a product where AI responses become part of legal records, where interface labels guide life-altering decisions, where the difference between "you can" and "conditions may support" is the difference between guidance and liability — language isn't content. It's the primary design material. We spent more time writing than wireframing. That was the right call.

Some products don't get to fail gracefully.

Most products can ship with rough edges and iterate. Users forgive. SARGE didn't have that luxury. An officer using the platform during an arrest can't encounter a confusing flow and "try again later." A probable cause affidavit with missing elements can't be patched in the next sprint. The product had to work — clearly, completely, correctly — from the first interaction. That constraint made the design process slower, more deliberate, and ultimately better.

What SARGE became

SARGE became something that doesn't have a clean category.

It's not a chatbot. It's not a legal database. It's not a report writer. It's not a tactical tool.

It's a decision-support ecosystem — a platform that gives law enforcement professionals access to the legal knowledge, procedural guidance, and documentation tools they need, exactly when they need them, in a format that works under the worst possible conditions.

An AI system designed for a world where "close enough" isn't acceptable.

Where every answer needs a source.

Where every interaction needs to be defensible.

Where the design itself becomes evidence of whether the system helped an officer make a better decision — or a worse one.