Legal Reproductions
Production errors make and break legal cases every day. Distributing docs involves a litany of process and format considerations that demand accuracy. Legal teams often need a "redo," which is where reproductions come in. This work unlocks massive value amid complex constraints.
The problem
Litigation teams increasingly needed to alter previously created productions, for a wide variety of reasons. DISCO Ediscovery lacked any reproduction support, and the pressure was mounting.
Why it matters
Reproductions are critical to DISCO's core customer base. Every single day there are court cases won and lost because of the way document productions are managed or mismanaged.
My role
As Productions design lead, I drove design for this initiative from early discovery. Before release, I used the work as an opportunity to onboard a junior designer.
Overview and project motivation
Legal teams face enormous pressure to avoid errors when producing documents. A bad production can easily spoil an entire case, so the stakes are high. When errors do happen, it's important that legal teams can reproduce documents quickly and accurately.
What are productions?
In addition to error resolution, there are dozens of reasons a legal team might wish to re-create a previously run production. DISCO's Ediscovery product historically overlooked the need for a dedicated reproductions feature, instead encouraging users to create new original productions ad hoc.
But as our largest customers scaled their business, their reproduction needs grew alongside them. Formal support for reproductions became the most requested feature of my team. I set about investigating how we might build a reproductions feature that gracefully serves a wide range of use cases without disproportionately consuming our team's bandwidth given competing business priorities.
Product context: DISCO Ediscovery
DISCO Ediscovery is an advanced Ediscovery platform designed to serve the needs of leading law firms and corporate legal teams. It offers expansive document ingest, review, and production functionality to enable robust ESI ("electronically stored information," a legal industry term) management at scale.
Ediscovery is a sprawling platform on the bleeding edge of legal tech innovation—it offers more than productions. For the purposes of this case study, here's some context specifically about the status quo of productions at the time I began working on this feature:
User motivation for reproductions
As our most advanced customers scaled their teams, production complexity began to compound. We began receiving strong market signal that relying on creating new original productions simply wasn't cutting it. Users were running into a handful of problems with this workaround, including:
Bates number inconsistencies
Clawback urgency
Production Sharing conflicts
Lack of production hierarchy
SOT dilution
Time spent opportunity cost
Our users required the ability to create a reproduction directly shaped by the original. Reproductions had to possess a hierarchical relationship with that original. And crucially, creating reproductions had to be faster than creating new original productions. As an entity, reproductions needed to support the same nuance as original productions, without imposing a complex creation flow. Here are some anonymized snippets from feature requests the team was receiving:
There needs to be an ability to reproduce a document, or small set of documents, from a production without re-running the whole thing. For example, I had to re-run a very large tif/text production when I only needed to update a small group of documents that didn’t have the appropriate confidentiality tag. Similarly, I have had to adjust redactions on a document and then reproduce with the same bates number… there has to be a better way to do this.
We see this request from clients almost every day. They want to reproduce documents with the same bates number from a prior production. Usually it has to do with changes in redactions. Completing this task in DISCO is almost impossible and extremely painful. We must get a fix for this soon. Messaging on this is also challenging. We try to lead clients to handing out new bates numbers, but they often don’t want that.
Currently, to keep the same bates, we can only reproduce the entire production set or reproduce each document separately. For example, it’s time consuming when only needing to re-produce 100 documents out of a production set of 100,000. Also, after re-running the whole set or creating multiple separate productions, there is the additional task of post prod work from ops. They need to either combine the multiple production sets or remove documents and update dat files.
As an entity, reproductions needed to support the same nuance as original productions, without imposing a complex creation flow.
"
Understanding use cases
I connected with a breadth of productions experts to develop a better understanding of reproduction use cases. In my conversations, it quickly became clear that "reproductions" was an overloaded industry term comprising a wide variety of use cases. Users sought a reproductions feature for reasons ranging from the trivial to the absolute case critical.
They were also constantly pushing the boundaries of our existing productions facility in pursuit of more diverse utility than we officially supported. Their creativity in leveraging productions for all sorts of data out needs was admirable, but they constantly ran up against the functional boundaries of original productions. I recognized an opportunity to serve these more diverse interests with our reproductions—we could unlock massive value without compromising the integrity of our system.
Some reproduction use cases:
䷉
Field formats aren't human readable
⬆
OC encountering import errors
📊
Accidental metadata omission
👩🏻⚖️
Court-mandated field changes
🤝
Counsel workflow changes
🧑🏽💼
New parties join litigation
📝
Need to produce new redactions
👨🏼⚖️
Court-mandated doc productions
🏙️
OC requires image remediation
🔏
Slipsheet rules too vague or stringent
📄
Accidental doc omission
🧠
Strategy changes
🎼
New natives needed
䷉
Stamps interfere with doc content
📂
Produced incorrect format
❌
Need to claw back docs produced in error
🗂️
Need to reproduce a subset
🙅🏻♂️
Accidental excess production
🔎
New saved searches will fix scope
✏️
Need to edit load files manually
💿
Offline storage for posterity
📊
Batch print lacks metadata context
🧑🏽💼
Production accuracy disputes
... and many more
Breaking down JTBD
To communicate the breadth of user demand, I organized use cases into categories using the Jobs To Be Done framework, breaking them into consumable lists with clear product implications. This framing helped me convey the scale of user need so our team could prioritize this work alongside competing interests.
“I need to reproduce previously run productions because...”
JTBD category #1
"I need to modify a completed production’s metadata or load files"
JTBD category #2
"I need to change the document treatments in a completed production"
JTBD category #3
"I need to alter the scope of included documents without changing Bates numbers"
JTBD category #4
"I need to retrieve production-related information without creating a whole new production"
Each category represents a host of use cases, each with unique implications for the settings a user might wish to modify from the original production. These categories don't represent a need for distinct workflows, but they help form a picture of necessary reproduction boundaries.
The reproductions feature couldn't become a vector for unpredictable platform behavior or production output. It had to offer the right level of reconfiguration, without opening up the user to risk of new errors and workflow degradation.
"
Reconfiguration constraints
I'd determined that the majority of reproduction use cases could (in theory) be served by 're-opening' an original production's configuration to allow user adjustments. But I wanted to be cautious about this approach, because more is not necessarily better.
Unnecessary modifications could strain the platform's document model
Creating new produced doc versions has implications for upstream workflows and should be intentional
Saved search queries drive review stages; new doc versions influence queries and can create chaos
I was wary of inadvertently training users away from caution in original production configuration
Some settings could be used to increase doc scope—thereby breaking the original's bates
Some settings aren't technically feasible to re-open and would require a new original production
I worked with Product and domain experts to assess all production configuration settings. The goal was to determine which settings could (and which should) be editable in a reproduction scenario. Some settings could easily be modified. Some could be modified but shouldn't be. Some others added little value relative the risk of error they'd incur. And some others were technically infeasible to re-open at all.
Original Production Setting
Potential Repro Availability
Name
Name
Reason for reproduction
Documents
Produce documents by Tag
Produce documents by Saved search
Produce documents by Search history
Stamps
Bates prefix
Starting number
Bates stamp position
Confidentiality or other stamps
Document format
Default document format
Produce the following file types as natives
Also produce as native, documents tagged
Native slipsheet
Produce redacted Excels as
Unless redacted Excels are tagged
Slipsheet format for redacted Excels
Withhold and slipsheet documents
Slipsheet rule: Include documents tagged
Slipsheet rule: contents (Header, Subheader, Body)
Metadata load file
[ Full control of load file configuration ]
Date format
Time format
Duration format
File size output
Other options
Deduplication level
Sort by
Starting volume label
Volume break
Omit document redactions
Omit metadata redactions
Blank metadata redaction reasons instead of displaying them inline
Also include natives for all images (unless redacted)
Store OCR text file in same folder as images, instead of in a separate OCR text folder
Do not apply Bates stamps to images
The reproductions feature couldn't become a vector for unpredictable platform behavior or production output. It had to offer the right level of reconfiguration, without opening up the user to risk of new errors and workflow degradation. I believed we'd strike the right balance using the above boundaries.
Production file structures
Along with a critical perspective on original production settings, I needed deeper familiarity with production output files. Paired with my understanding of user needs and system limits, file structure knowledge would help me design a practical and effective reproduction workflow. I worked with domain experts to get the rundown on why files are structured this way, and the implications for reproductions.
Like others in the space, DISCO's production volumes are semi-standardized and structured to be interoperable with other Ediscovery platforms. If you're curious, here's a breakdown of a typical production volume structure, containing only a handful of produced docs for the purposes of this example:
Metadata Load Files
System instructions for stitching together documents and their metadata, once imported to a new ediscovery platform. You can think of these as the glue that pulls together all the files in this production volume, to make them useful for legal teams.
.DAT File
Metadata from produced files
.OPT File
Contains image file paths
.LFP File
Load file used for IPRO systems
Additional metadata files
Some platforms output slightly customized load files, but they remain interoperable
Produced Doc Files
Reviewed documents produced from an ediscovery platform, shared with other parties to be imported into their respective ediscovery systems.
PDF File
Rendering file for the .DOC below
PDF File
Rendering file for the .JPG below
PDF File
Rendering file for the .PPT below
Word Processor File
An example produced .DOC
Image File
An example produced .JPG
Powerpoint File
An example produced .PPT
.TXT File
Links database records and doc image files
Direct and Artifact Reproductions
Armed with the knowledge that reproductions mean many different things to our users (and crucially, armed with team consensus about the implications of that reality), I set about shaping the boundaries and flow of our reproductions offerings. Reproductions needed to:
Fit neatly into our existing information architecture
Be faster to create than a new original production
Offer a high degree of original production setting re-configuration
Avoid user overwhelm and minimize opportunity for errors
…and replace myriad offline workarounds to which users had grown accustomed
It was clear that a degree of workflow agnosticism was necessary, rather than attempting to build bespoke functionality for every use case. This meant our reproduction flow needed to strike a balance between non-prescriptive configurability and thoughtfully placed guardrails that prevent user error. I theorized that all of our known use cases could be served by two broad reproduction types.
1. Direct Reproductions
2. Artifact Reproductions
Flow and placement explorations
I moved through a series of explorations around Direct and Artifact Reproductions, establishing answers to these and other sprawling platform questions:
How well do they fit into our existing information architecture?
Where does the user need to reference them throughout other ediscovery facilities?
How should they render in the production list relative original productions?
Where in the platform do we need to denote when documents have been reproduced?
I explored different approaches with less and more rigid boundaries. Initial directions felt too prescriptive. Through conversations with users, it became clear that they didn't require granular progressive disclosure, nor did they require in-depth guidance when original production settings were being locked for the purpose of maintaining original Bates. Production specialists intuitively understood these constraints—a strong signal that we were headed in the right direction.
Direct Reproductions refinement
Direct Reproductions would technically serve fewer use cases than Artifact Reproductions—but they'd solve more of the critical needs, thereby satisfying the vast majority of demand. User research and flow explorations shaped my vision for the workflow, which I shared continuously with the team. By the point of higher fidelity mocks, we'd already reached consensus about how we'd build the feature.
Let's walk thru the prototype
This link is made available during live sessions.
Our first release would tap into users' established mastery of pre-existing production configuration.
The flow would initiate from a production list card representing a given original production
A modified configuration UI would explicitly detail constraints shaped by the need for Bates consistency
Everything that could be configured would be made available to user
This approach offered production experts wide-ranging flexibility to serve wide-ranging jobs
UI is table stakes… I'm equally focused on executing a long-term vision with my product partners. As a strategic design partner, I'm involved in ideation and roadmap planning at every phase.
"
Collaborative roadmap development
UI is table stakes… I'm equally focused on executing a long-term vision with my product partners. As a strategic design partner, I'm involved in ideation and roadmap planning at every phase. For Reproductions, worked closely with Product and SMEs to develop a detailed milestone sequence organized around:
High-profile customer demand which threatened to translate directly into lost revenue
Broader prioritized reproductions use cases and their expected long-term revenue impact
Gaps in the competitive landscape creating market leadership opportunities for DISCO
Workflow and implementation interdependencies with other Ediscovery teams
Sense of technical feasibility and build timeline, shaped by conversations with engineering
Some things can't be shared
Although I can't share roadmap details, I'm more than happy to talk in-depth about my general approach to strategic design partnership in product development.
Being a team player
Product teams are constantly evolving. For designers, org chart shifts represent an opportunity to sharpen some of our more fundamental creative collaboration skills:
The tactical skill of crafting strong documentation for posterity
The creative discipline of being flexible and detaching ego from one’s creative output
And the collaborative muscle of ramping other team members to pick up your work
After laying strong groundwork for Reproductions, my focus was needed elsewhere, so my priority became ensuring the success of my successor. Another designer was joining our team. As they ramped up, I worked closely with them to enable their success in bringing the feature to market.
Reproductions is a rare example of an initiative I didn't have the chance to carry beyond release. I chose to share it here anyhow, because the purpose of case studies is to understand how I think at any phase of product development. The highly valuable Reproductions feature shipped shortly after my departure, with design rollout overseen by that new designer, whom I was proud to support. This dynamic represented a different type of success… rooted in collaborative design, and the skill of prioritizing teamwork.