When every legal product needs the same files, why store them in different places?

I led this end to end: framing the three problems above from patterns across the products I'd already worked on, the research that grounded the case for owning storage instead of integrating another vendor, the information architecture and permission model, the full UI system, and the integration points, like the "Import from LitBox" pattern used inside other Omnis AI products, that make LitBox a layer the rest of the ecosystem actually plugs into, not a fourth silo next to the other three.

Dropbox and Box are the two tools that showed up most often as the "first stop" before a file ever reached an Omnis AI product: general-purpose drives with no concept of a legal matter, built for a different job entirely.

Built with the ux-flow-designer methodology used across this case study. The flow traces one client file from a lawyer's hands to three different Omnis AI products. Every red note marks friction that existed only because the ecosystem didn't own its own storage layer, and the second strip shows the same file inside LitBox.

Once research surfaced dozens of individual findings (module ideas, competitor features, stakeholder asks), the next problem was turning that pile into a navigation structure a firm could actually use. The diagram is an illustrative reconstruction of that card-sorting pass, not a literal transcript of the exercise, grouping raw findings into the categories that became LitBox's actual sidebar IA (Section 09).

Lawyers aren't just choosing security software out of caution; a real ethics rule requires it. ABA Model Rule 1.6(c) says a lawyer must make "reasonable efforts" to stop a client's information from leaking, on purpose or by accident. A companion rule says a lawyer has to understand the tools they're using well enough to know the risk. Neither rule names a specific product or certification, just "reasonable" and "informed." That's a lower bar than "encrypted" or "fully compliant," which is exactly why I'm not putting either word on LitBox without proof behind it.

Legal-software vendors (Clio, Sync) and incident write-ups from CloudLex converge on the same short list. This describes their own practices, not independent research, but the list is a useful checklist against a consumer drive:

• Encryption, while a file moves and while it sits in storage.
• Multi-factor login: a password alone isn't enough to get in.
• Per-person, per-file roles, not one link anyone can forward.
• A record of who did what, not just that a file was sent somewhere.

Sync's own material is blunt about the gap: consumer tools are "designed for a broad audience" and usually skip the access controls and audit trails a firm specifically needs.

The internal-beta scope covers the core file-management loop end to end (upload, organize, preview, share, request, restore and delete, search, and audit) plus the confirmed ecosystem connections: AutoDoc via File Requests, OmnisProof via in-document e-signature, and embedded search live inside MedChron and AutoDoc itself (Section 15). A conversational AI assistant, deeper CasePro matter-linking, and broader third-party integrations are explicitly out of MVP scope; Section 13 shows what that AI question actually looks like.

More than two dozen empty, error, and permission states were scoped this same low-fidelity way before a single one shipped. Section 10 shows the built result.

Upload favors clarity over cleverness. Restore stays quiet: reversible, one click. Delete inside the retention window costs a second's friction on purpose, so nothing sensitive disappears silently.

Section 03 named the problem: a public link has no idea who still has it. LitBox's answer is that sharing a file means picking named people and giving each one a specific role (Owner, Editor, or Viewer) instead of generating a link. There's no "anyone with the link can view" option to reach for.

Every upload, download, share, rename, permission change, and restore is written to a single timeline, filterable by action type, with the file, the user and role, and a timestamp on every row. Alongside the roles above, this is the concrete answer to "how would a firm know who touched a file": not a proposed capability, something actually built.

Storage Management is a separate surface for firm admins (total usage, storage by file type, per-user breakdowns, and quota alerts) rather than a setting buried inside the same view every attorney and paralegal sees. Keeping it separate meant the day-to-day workspace never had to compromise its simplicity to accommodate governance features most users will never open.

The Dashboard is data-dense on purpose: storage usage, file and folder counts, and recent activity at a glance, so a firm admin isn't hunting for that information in a separate settings screen. Opening any file surfaces a detail drawer with two tabs: Document Details (who has access, folder metadata, description) and Document Activity (a timeline of edits, renames, and inline comments from the team).

Rather than one public link everyone gets the same access to, sharing a file assigns each person a role (Owner, Editor, or Viewer) by email, without overclaiming a password and expiry system that isn't in the shipped file yet. The reference alongside it shows what a fuller privacy and password layer looks like in a mature product, and the direction the sharing model is headed.

A separate permission tier, not a hidden toggle in the same screen everyone sees. Firm admins get organization-wide storage totals, a breakdown by file type, and a per-user table with quota usage: the same screen that would back the "Export Report" a firm's IT lead needs for a compliance review.

Colored tags that work across file types (a document, an image, and a video can all carry the same tag), closer to macOS Finder tags than to a folder-only scheme. A file can carry more than one tag, so "matter" and "document type" don't have to compete for the same folder slot.

Search scoped to All Modules, Files/Documents, Folders, or Recent Files, with a clear empty state rather than a blank screen when a query comes back with nothing. Section 12 covers what a populated result looks like (path, page, and highlighted snippet) once AutoDoc has extracted a file's text.

"Search inside documents" sounds like a checkbox feature until you consider what it required: LitBox's search only works this way because AutoDoc had already extracted text from the file. Search got meaningfully better specifically because LitBox and AutoDoc share a file, not because of anything search-specific LitBox built on its own. Section 15 shows that sharing from the other direction.

The module-architecture research behind LitBox sketches use cases like "find all medical records related to this matter" or "summarize these documents": a conversational layer on top of content search. That thinking has since moved from research notes into concept screens, covered next in Section 13. None of it is shipped or built into the product today. Any answer would need a source citation back to the exact file and page, retrieval would need to respect the same permission model as manual search, and it would sit on top of the existing search index rather than replace it.

A File Request isn't just "share a link and wait." It has a title, a description, a destination folder, an optional deadline, password protection, and a defined recipient, and when that destination folder is an AutoDoc-connected folder, submitted files are positioned to be picked up for processing without anyone manually forwarding them.

Opening a document that needs a signature surfaces a "Continue to e-signature" action that hands off directly into OmnisProof's signer setup (general info, signer list, extra fields, and distribution) without exporting the file and re-uploading it into a separate tool.

Still proposed, not implemented: CasePro matter-linking and a shared permission model spanning the whole ecosystem. MedChron and LitDraft, it turns out, are further along than that; see the next section.

OmnisProof needs a document to attach a signature workflow to, the exact dependency named in Section 02. Rather than build its own upload flow, it opens the same kind of "Select documents" picker, scoped to the workspaces and matters the signer already has access to.

None of this makes LitBox "done." It makes the third problem from Section 01, an ecosystem that wasn't actually one, no longer true by default. That's the specific claim this case study is willing to make.

I owned LitBox's product design end to end: the competitive and module-architecture research that scoped what "parity with Dropbox and Box" actually required, the information architecture, the full UI system across file management, sharing, search, audit, and admin, and the design of its live ecosystem connections into AutoDoc, OmnisProof, MedChron, and LitDraft. The empty-state, error-state, and permission-state documentation (more than two dozen scenarios specified before a single one shipped) was mine to define, not a gap engineering had to fill in later.