Legal case managementLegal case management

PRD rewritten from scratch for publication. The work is real; the client isn't named.

Context

A large Argentine law firm put the replacement of its case management system out to tender. The document mixed two things: the functionality the current system already covered, and ten new developments the firm wanted to add.

Fidelity note: we had no access to the real system. The screens representing "the old" are a reinterpretation of the functionality described in the tender, not a capture of what exists. This is a redesign, not a replica.

The problem

A tender with sixteen functional requirements and ten developments is a document two vendors will read two different ways. The risk is building something other than what the firm pictured while writing it.

The prototype exists to settle that before signing. It turns the tender into concrete screens, and the conversation moves from "did you understand the requirement?" to "this screen — is this it?".

Scope

Case management only. No time and billing, no accounting, no CRM, no HR: those are separate modules, and including them would have diluted the proposal.

Multi-case with internal tabs. A lawyer works several matters at once. The system keeps open cases in their own tabs inside the application, so you can move between them without losing context. It replaces the legacy system's awkward window handling, one of the most cited frustrations in the tender.

Intelligent case intake. Opening a case from its initial document: the system recognises the data, proposes it pre-filled, and the lawyer confirms or corrects. The manual intake path still exists alongside it.

Court portal inbox. Updates from the judicial portals land in a single inbox with a review state, instead of forcing someone to check portal by portal.

Flexible fields by case type. A probate and an employment claim don't need the same record. The configurator defines which fields each type carries, without touching code.

Calendar and deadlines. A calendar and board of procedural deadlines, with state semantics kept consistent across the whole system: on track, due soon, overdue, closed, in progress.

Client reporting. Generating the case status report the firm sends its own clients, which today is assembled by hand.

Drafting assistant. Assisted drafting of filings on top of the case data.

Prototype screens

1. Home / My tasks — summary cards, today's items, a mini-calendar and alerts.
2. Case search — multi-criteria search across the whole book.
3. Case record — the central screen, tabbed: data, procedural stages, filings, assignees, documents.
4. Manual case intake — the traditional path, in full.
5. Intelligent intake — document-driven entry, with mandatory human confirmation.
6. Court portal inbox — portal updates with review state.
7. Calendar and deadlines — hearings and due dates, in calendar and board views.
8. Field configurator — defining the record per case type.
9. Report generator — assembling the report for the firm's client.
10. Drafting assistant — writing on top of case data.
11. Assignment panel — distributing matters across lawyers.
12. Procedural stage configuration — the state engine, editable.
13. Reference table admin — courts, jurisdictions, matters.
14. Users and permissions — roles, superusers and per-profile scope.

The six hero screens were mocked first, to settle the visual language and validate it before generating the rest. Generating fourteen screens in one pass lowers the quality and consistency of all of them.

What it excludes

• Time and billing, accounting, payables and receivables.
• CRM, marketing and HR.
• Authentication screens.
• Productivity metrics per lawyer, hour rankings or revenue charts.
• A mobile version: this is a desktop tool, used intensively and dense with data.
• Automatic filing upload to the court portal: the firm dropped that requirement during the tender, and it appears as a secondary action at most.