Case study 01 / Litigation Technology & Information Architecture

Patterson Buchanan Fobes & Leitch

The platform wasn't the problem.
The information was.

The records existed. The platform contained substantial capability for organizing and retrieving them. But legacy identifiers and incomplete contextual metadata meant a person could still need to open a record simply to understand what it was.

Environment
Litigation technology
Role
Contract Consultant
Focus
Information architecture, metadata, retrieval, repeatable methodology
Platform
Everlaw
Status
Active engagement
Evidence
Confidential professional work. Public examples are completely fictionalized where necessary.

Turn a collection of records into a usable information system.

Debra was working with a large collection of legacy litigation records being organized within Everlaw. The practical need was to make records easier to understand, recognize, compare, retrieve, and prepare for downstream review while preserving source identity and provenance.

The work was not simply filling in metadata.

What information does someone need in front of them to understand what a record is before they should have to open it?

The behavior gap / 02

The platform could expose useful information. The information first had to exist in a usable structure.

Intended

Recognize and retrieve from the working view.

A person should be able to use table views, metadata, filters, search, and other existing platform capabilities to identify and retrieve relevant records efficiently.

Actual

Open the record just to learn what it is.

Legacy source identifiers preserved identity but often communicated little about a record's contents. When contextual metadata was incomplete or absent, opening individual records was sometimes necessary simply to determine what they were.

Constraints / 03

Design inside the system that already exists.

The constraints shaped the method. They were not details to work around after the design was finished.

  1. 01Source files could not simply be altered.
  2. 02Source identity and provenance needed to remain intact.
  3. 03Legacy material included older scanned records.
  4. 04Duplicates could carry different source or Bates identities.
  5. 05Contextual metadata was incomplete or missing.
  6. 06The solution needed to work within the existing platform.
  7. 07The method needed to be repeatable by someone other than Debra.

The design criterion / 04

If I can look at the table view and understand what a document is without opening it, the information architecture is doing its job.

The goal was not to eliminate opening records. It was to stop requiring people to open them merely to establish basic identity and context that the information system could expose directly. This was a design criterion, not a measured KPI.

Investigation / 05

What makes a record recognizable?

Different fields answer different questions. Together, they help someone recognize, distinguish, filter, and retrieve records without asking one label to do every job.

Title
Provides a concise human-readable identity for the record.
Subject
Communicates what the record concerns.
File or document type
Distinguishes the nature and expected use of the record.
Date
Places the record in temporal context.
Bates start and end
Preserve source identity and provenance even when they are poor human-readable descriptions.
Author
Helps establish who created or sent the record.
Recipients
Shows who was directly involved in the communication.
CC and BCC
Adds relevant communication context where those fields apply.

Recognition patterns / 06

Consistency does not always mean treating unlike information identically.

A repeatable system can contain different patterns when the information serves different recognition needs.

Conceptual pattern

General documents

type - author - recipient - case context - subject - date

Communication context helps distinguish who is involved, what the record concerns, and when it belongs in the sequence.

Conceptual pattern

Court-filed documents

date - case context - type and party/context

Filing date, matter context, document type, and relevant party information carry greater recognition weight for this kind of record.

These patterns describe information relationships. They do not expose confidential production naming or reproduce actual records.

Fictional transformation / 07

From source identity to recognizable information.

The simplified example shows how contextual information changes what a person can understand at a glance. The deeper transformation is from a collection of records into a usable information system.

Completely fictional illustrative example

Before

Opaque source identifiers

  • ABCXYZ_1234
  • ABCXYZ_4321
  • ABCXYZ_2413

After

Human-readable context

  • 2010-01-24 - ABC v XYZ - Complaint
  • 2010-01-24 - ABC v XYZ - Amended Complaint
  • Letter - Smith - Doe - ABC v XYZ - Statement of Representation - 2010-01-24

What becomes visible

  • Document type
  • Relevant parties or case context
  • Subject or purpose
  • Date

Source identifiers can remain available for provenance while titles and metadata provide the context people need for recognition and retrieval.

Fictional illustration. All names, identifiers, dates, case information, and document examples are completely fictional and created solely to illustrate the information transformation. Any similarity to an actual person, matter, document, or record is purely coincidental. This does not reproduce confidential Patterson Buchanan or Everlaw data.

The intervention / 08

Design a method for using the platform's existing capabilities more effectively.

Debra developed a repeatable information-architecture method using metadata, retrieval structure, naming, classification, and documentation.

The work included deciding:

  • which information should be surfaced
  • how records should be titled or described
  • which fields supported recognition and retrieval
  • how different record types should be treated
  • how source identity should remain intact
  • how the method could be applied consistently

This did not change Everlaw's underlying product architecture. It created a structured way to use capability that was already present.

Operationalization / 09

The deliverable wasn't only better records.
It was a repeatable way to make records better.

The method was documented so the work could be understood, applied consistently, and continued rather than remaining dependent on Debra's memory.

Capability beats dependency.

Outcome and evidence / 10

Evidence that can be supported.

  • The method was used during trial preparation.
  • No usability complaints were reported during that use.
  • The approach established a repeatable structure for making records more recognizable and findable.
  • The information transformation can be demonstrated with completely fictional examples.

What this demonstrates / 11

A new tool is not always the answer.

Sometimes the needed capability already exists. The work is understanding why people cannot effectively access that capability and building the information structure, method, or workflow that lets them use it.

This work brought together information architecture, retrieval thinking, business analysis, human-centered systems reasoning, documentation, and operationalization within real constraints. It also required learning an unfamiliar domain by working with the people who knew it and the material itself, rather than pretending to begin as the domain expert.

All Work