Legal Reproductions for Modern Firms
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 shapes our legal landscape, unlocking massive value amid complex constraint.
Productions in DISCO Ediscovery
DISCO Ediscovery is an advanced platform serving leading law firms and corporate legal teams. It offers expansive ingest, review, and productions to enable robust document management at scale.
What are legal productions?
When I began working with the Productions team, I ramped on the history and current state of our productions facilities:
User motivation for reproductions
Legal teams face enormous pressure to avoid errors while producing millions of documents. Famously, errors can make or break a case. Because complex productions are high-stakes, teams often need a "redo" — that's where reproductions come in. A good repro process enables quick, accurate revision.
I sensed an opportunity to exceed the industry standard for complex, report-driven reproductions. Digging into the subject via deep research and conversations with legal experts, I discovered that demand for reproductions was actually more pervasive than we'd recognized. Numerous seemingly unrelated data export challenges could be addressed with one well-executed repro feature. Done well, repro could solve an unprecedented breadth of user pain around these subjects:
Bates number inconsistencies
Clawback urgency
Production Sharing conflicts
Lack of production hierarchy
SOT dilution
Time spent opportunity cost
Legal teams face enormous pressure to avoid errors while producing millions of documents. Famously, errors can make or break a case. Because complex productions are high-stakes, teams often need a "redo…"
Business motivation for reproductions
As customers scaled their business, direct and indirect demand for reproductions was growing. Several high-impact customer accounts made contract renewal contingent upon the ability to re-run previously created productions, with a variety of opinions about how we should build such a feature.
In addition to serving those customers and resolving numerous other data export challenges, I recognized that reproductions could serve the critical business goal of improving Ediscovery's reputation as a source of truth for litigation support teams. Internally, I framed a broader repro vision that would deliver greater value than leadership had expected. I shaped and disseminated this vision to drive alignment and investment in the team.
Understanding use cases
I connected with a breadth of productions experts to develop a better understanding of repro use cases. It became clear that "reproductions" was an overloaded industry term—users sought a repro feature for reasons ranging from trivial to case critical.
They were also constantly pushing the boundaries of original productions as they sought more diverse utility than was officially supported. I admired their creativity in using productions for a variety of data out workflows, but they were constantly hitting walls because productions were not designed to be 're-done.'
These are some of the repro use cases I identified—many were not expressed as productions challenges, but I recognized the opportunity to address them with reproductions anyway:
䷉
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 more
Reproductions needed to support the same nuance as original productions, without imposing a complex creation flow.
Using JTBD to drive alignment
To communicate breadth of user demand, I organized those use cases into consumable lists with clear product implications. I then used this framing in executive conversations to convey the scale of user need and further advocate for repro prioritization amid competing interests. This framing was also useful for generating excitement among engineers, since the work wouldn't be low-profile… there was real impact to be made here.
“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.
Creating a theory of change
Rather than jumping into UI at this stage, I shaped a theory of product change for the feature and its implications beyond our team. From the user's perspective, no feature exists in isolation—we shouldn't think about reproductions in isolation, either.
Ediscovery's modules are interconnected, with everything naturally leading to productions as the 'end phase' of legal discovery. This means that a thoughtfully executed repro feature would be deeply considerate of other teams and facilities.
At the feature level, good reproductions would:
Be directly shaped by the configuration of an original production
Possess a hierarchical relationship with the original
Be faster to create than a new original production
Allow user to easily reconfigure the original's settings
Be flexible without introducing new space for errors
And at the platform level, they would:
Fit neatly into our existing information architecture
Remove pressure from other product facilities by consolidating workflows to the point of production
Avoid adding complexity to our backend document processing system
As much as possible, avoid dependencies upon other teams, and avoid adding to their plate
Replace users' custom offline workarounds to simplify workflows while increasing time in product
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 exposing users to risk of new errors or workflow degradation.
Defining settings constraints
I determined that the majority of use cases could be served by allowing users to reconfigure an original production's settings. I wanted to be cautious with this approach, because more isn't necessarily better:
Unnecessary modifications could strain the platform's document model
Creating new produced doc versions has implications for upstream workflows
Saved search queries drive review stages; new doc versions influence queries and can create chaos
I was wary of training users away from caution in original production configuration
Some settings can increase document scope—breaking the original production's bates numbers
Some settings aren't technically feasible to re-open
I worked with Product and engineers to assess our settings, establishing guidelines for what could or should be editable in a reproduction scenario. Some settings could easily be modified. Others added little value relative the risk of error they'd incur.
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 exposing users to risk of new errors or workflow degradation. I believed we'd strike the right balance using these settings boundaries.
Understanding production file structures
I also needed deeper understanding of production output. File structure knowledge would complement my understanding of user needs, helping me shape an effective holistic repro solution. I worked with engineers to understand why files are structured as they are.
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
I theorized that all of our known use cases could be served by two broad reproduction workflows, and I drove stakeholder alignment around this concept of a two-phase approach.
Direct and Artifact Reproductions
A degree of workflow agnosticism was necessary, rather than building bespoke functionality for multiple use cases. This meant our repro feature needed to strike a balance between non-prescriptive configurability and well-placed guardrails to prevent user error. I theorized that all of our known use cases could be served by two broad reproduction workflows, and I drove stakeholder alignment around this concept of a two-phase approach.
Phase 1: Direct Reproductions
Phase 2: Artifact Reproductions
Flow and placement explorations
I then 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 user conversations, it became clear they didn't require granular progressive disclosure. They also weren't confused when encountering original production settings that were locked to protect original bates numbers. Production specialists intuitively understood how their preferred boundaries had translated into the feature's design—a strong signal that we were headed in the right direction.
Direct Reproductions would technically serve fewer use cases than Artifact Reproductions—but they'd address more critical need, thereby satisfying the vast majority of demand.
Direct Reproductions refinement
Direct Reproductions would technically serve fewer use cases than Artifact Reproductions—but they'd address more critical need, 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
Good design is table stakes… I'm equally focused on executing a long-term, cross-team vision. As a strategic design partner, I drive ideation and help shape the roadmap at every level, throughout product development.
Collaborative roadmap development
Good design is table stakes… I'm equally focused on executing a long-term, cross-team vision. As a strategic design partner, I drive ideation and help shape the roadmap at every level, throughout product development. For Reproductions, I worked closely with Product and various 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.