Multicolor Deposition Designations
This work is a reconstruction of annotation mechanics in the Case Builder deposition management platform. It reinvents highlighting, exceeding its original mandate by unlocking numerous workflows that continue to help generate millions in sales.
The problem
Case Builder lacked key support for color-coded designations, failing users close to trial. Its existing highlight mechanic had become stale, with users requiring more powerful annotations.
Why it matters
Litigators' relationship with tech is evolving alongside unprecedented legal outcomes. Amid this turbulence, crafting accessible and intuitive solutions for legal teams has never been more important.
My role
I owned this work end-to-end, including all discovery, research, interaction and interface design.
Impetus and overview
In early 2024, no players in legal tech offered well-rounded designation color-coding, let alone holistic management. This exacerbated a fragmented landscape that entrenched firms into niche, offline workflows. This presented a great opportunity to extend our functional lead over the competition with a sticky feature that lit support teams would love: transcript-compatible multicolor highlights.
What are trial designations?
Users needed to manage multi-party coding with a solution adaptable to court-mandated guidelines anywhere in the US legal system. I designed this feature to exceed that mandate, becoming a broadly useful annotation mechanism that supports numerous workflows.
The pace of reinvention in legal tech
Product context: Case Builder
Case Builder launched in 2020 to fill an industry gap — the vision was to offer litigators one central destination for managing case information, the raw materials associated with a given case (ie, depositions and exhibits), and analysis artifacts to support case strategy. I joined the Case Builder team in 2022, shifted to work on Ediscovery, and eventually returned to lead Case Builder design.
Trial designations context
Occasionally, the contents of depositions are used at trial—that's where designations come into play. Designations refers to the process of identifying strategically significant portions of deposition testimony for use at trial, then coordinating with opposing counsel and the court to approve their inclusion.
At a high level, the way designations fit into the litigation lifecycle is standardized throughout the US legal system. But there's tremendous diversity in the way that individual jurisdictions require firms to organize and document designations. This results in a fragmented process and tooling landscape. When I joined the team, none of Case Builder's competition had built solutions to properly support designation highlights, let alone full workflows. Legal teams were left to use custom offline workflows living in spreadsheets and Word documents.
Designations are critical in the litigation lifecycle, so this gap represented a great opportunity for Case Builder to extend its functional lead over competitive products. Multicolor highlights for designations would make Case Builder a much stickier product for litigation support teams.
The significance of highlights
Designation lifecycle
Extreme time constraints
Competing interests from multiple parties
Highly customized offline workflows
Understanding the multicolor gap
As a critical step in the litigation lifecycle, designations are an important use case for any deposition management tool. But at the time, no one in the industry offered well-rounded multicolor highlights for designation color-coding, let alone holistic designations management. This gap exacerbated an already fragmented tooling landscape and further entrenched firms into niche offline workflows.
At minimum, our users required the ability to manage multi-party designation color-coding. It needed to work well across digital and analog mediums. And it had to be flexible enough to adapt to court-mandated coding guidelines anywhere in the US legal system. Our current highlights were falling short.
DISCO's motivation (Sales / CSAT / Market Leadership)
Users' motivation (Workflow / Ease of Use)
Case Builder's product feedback was increasingly focused around this gap. Paralegals and lit support teams were voicing frustration through the chain of command, such that we were hearing directly about this gap from firm partners. Here are some snippets from anonymized feature requests the team received:
Partner — Mid-size regional firm
Partners — Full-service national law firm
Partner — Large regional corporate firm
Partner — Small boutique firm
Driving creative problem-solving
As often happens with well-intentioned user feedback, our customer signal contained prescriptive suggestions scoped to niche user workflows, such as:
Adding an option to configure additional highlight colors at the point of export
Allowing users to choose a different highlight color instead of yellow
Adding new 'parties' and 'designation' objects to our domain model, with dedicated management pages
These ideas didn't tackle the challenge holistically. And they favored pure addition rather than thoughtful implementation, carrying the risk of compounding complexity. Initially, this feedback pigeonholed the team's imagination. There was a strong temptation for Product to fulfill user requests exactly as prescribed.
When I joined the scene, I challenged the team on whether it was right to take these requests at face value. I sensed an opportunity to approach the work more holistically by exploring whether designations color-coding could also support non-designation workflows. By solving for multicolor highlights more broadly, we could offer users more value for a similar cost of implementation.
Initial design explorations
I wanted to experience user frustration firsthand, so I asked engineering to spin up a sandbox environment and used feature requests as a guide for exploring the status quo. I developed three theories for how we might resolve the gap, each representing a distinct approach to building multicolor highlights as a foundation for a future state with more comprehensove designations management.
I intentionally didn't mock the complete effects of each path throughout the product. Instead I represented each concept via the highest exposure user-facing touch point: creating an annotation in the transcript viewer. This kept mocks lean and timely while effectively communicating user impact.
Deep cross-functional collaboration is one of my favorite things about design—I love building creative, resilient solutions with people who think differently than me but share the same goals. At DISCO, I talked daily with product, engineers and legal experts about my ideas. We maintained feedback loops throughout a project's lifecycle and beyond. I pulled them into research. We assessed data together. We explored prototypes. These are some of the roles I collaborated with most:
Product management
Engineering
Legal domain SMEs
Other designers
Design systems team
I'd familiarized with the product, competitive landscape, and the user pain driving this work—and I'd developed some theories for how to resolve it. I'd brought the team to a high degree of confidence around Path #3, but my preference was still loosely held pending some external validation. Next, I convinced the product team it was time to gather feedback directly from users. I organized ten qualitative research sessions with users in six law firms, seeking out subjects in roles with designations experience.
To align the DISCO team and ensure these sessions would feel useful to attendees, I prepped a research spec detailing our goals, format, hypotheses, and logistics. I also wrote a series of research questions to serve as conversational 'guard rails,' workshopping it with my product team in anticipation of these conversations.
Excerpts from the Research Spec:
My research hypotheses
Objectives and deliverables
Participants and method
Guiding questions for internal reference
I was still new to the team, so these conversations would be my first with practicing litigators. One of my goals was to kickstart recurring research relationships with these subjects, so I tailored questions around their needs without sacrificing attention to DISCO's needs. In the years following, I'd continue the conversations with several of these subjects during feature development for multiple products.
Key research insights
Use cases beyond designations
Path #3 validation
Emphasis on exports
Visualization preferences
The role of visual accessibility
New usability considerations
Useful feature recommendations
Established feature constraints
It was time to build upon those early concept mocks for in-depth feature design. I identified the unique constraints and experiential boundaries that would shape the design, including but not limited to:
User-defined needs for multicolor highlights
Product constraints and limitations
I worked with engineering to determine that our pre-existing yellow highlights actually drove the appearance of the particular export we sought to modify. This meant that in-app multicolor highlights could simply be an extension of established logic with no need to reinvent the wheel.
"
Making the case for in-app parity
There remained disagreement within the team about the best way to build Path #3. Despite some users prioritizing only the export, I believed we should also support in-app multicolor highlights. This parity would allow us to serve many more use cases. And during high-pressure designations, parity would reduce the likelihood of errors by closing the mental gap between digital and analog.
Additional in-app multicolor use cases
App↔export parity would require greater investment, but the ROI would be disproportionately high for the level of work required. Beyond designations, it would unlock exciting new workflows. And DISCO would be able to market a much more powerful feature.
Some team members didn't see the vision. To convince them, I pointed to the value of serving additional use cases and built a case around the pre-existing link between annotations and yellow highlights.
I worked with engineering to determine that our pre-existing yellow highlights actually drove the appearance of the particular export we sought to modify. This meant that in-app multicolor highlights could simply be an extension of established logic with no need to reinvent the wheel.
Establishing feature nomenclature
Sharing a common language with team members is especially important when building a novel experience. I established these and other terms, then promulgated them among team and stakeholder syncs to help us all avoid confusion and improve collaboration.
Through a close working relationship with dev, I created interactions that manage myriad variables, feel intuitive to users, and work consistently between digital and analog mediums.
"
Highlight draw order and logic
While conceptually simple, highlight complexity compounds. To help the user maintain a sense of order via predictable interactions, I developed a series of behavioral guidelines which drive how highlights render in any scenario. Through a close working relationship with dev, I created interactions that manage myriad variables, feel intuitive to users, and work consistently between digital and analog mediums.
The Draw Order
The appearance of Highlight Bands is driven by the Draw Order: when Bands overlap, they fill Slots based on Start Location, then color rank. This render order of operations gave engineering implementation clarity—and it creates predictable app behavior for users.
Why this Draw Order?
Re-draw Events
Highlight Bands aren't constantly redrawn. Instead, they re-render upon completion of specific user actions. The Draw Order dictates Band appearance upon page load, then again whenever the user takes one of these actions to manipulate the appearance or visibility of Bands. This helps users develop an understanding of the impact of their actions on Band appearance, while ensuring that Bands abide by the Band behavioral guidelines detailed below.
Events that trigger re-draw
Behavioral guidelines
Rendering rules for visual elements wasn't enough—I identified the need for specificity around the behavior of UI elements themselves, relative one another. The behavior of Highlight Colors, Bands, and Slots are defined by these rules, working in conjunction with the Draw Order and Redraw Events.
Detailed rules
Tradeoffs and remedies
Given the number of variables affecting multicolor highlights, you might be wondering whether our solution truly allows user to accomplish any desired highlight configuration. The answer is no—but for good reason. This feature is designed to serve 99% of multicolor highlight use cases. With constrained space, there's always the potential for user to struggle in pursuit of niche configurations. I made sure that even in these unlikely scenarios, user can work around constraints using the following methods:
Methods to manipulate Highlight appearance
Detailed implementation collab
The expertise of my front-end engineering partners was priceless in crafting this system of multicolor highlight behavior. Together we worked through dozens of scenarios to finesse this functionality and strike a balance between technical constraint and ideal user experience. Here's one such example from my engineering guidance:
Annotation #2 (13:6-14)
Annotation #3 (13:12-20)
Summary and application touch points
Summary of functionality
Multicolor highlights were designed to be non-destructive and unobtrusive, but needed to be accounted for in several places throughout the app. Here are some of the high-level takeaways from its design. Read on below for more detail if you're interested!
🎨
16-color highlight palette
✍️
Non-destructive color ranking
📝
App and export highlight parity
🌈
Intelligent slot rendering
🥞
Colors stack rather than blend
📑
Partial line support
👩🏻💼
Zero customer rework
✏️
Highly customizable
👁️
Accessible colors in any medium
Tags management page
Because multicolor highlights are organized around tags, colors themselves are managed on the Tags page. Color management is an infrequent but critically important action for our users. My design offers frictionless, non-destructive and effective color management that supports any highlighting workflow.
Transcript viewer
We'd recently shipped a highlight visibility toggle that had the potential to complicate multicolor interactions. The toggle was created to show / hide all colors in the transcript. If the design of our new multicolor highlights feature had been unstructured, contending with this mechanism could have required significant rework for the team. But because my interaction design was considerate of the toggle and well organized around behavioral guidelines, the toggle fit neatly into our multicolor front-end logic. If you're curious, here are some of the interactive states associated with that toggle:
Export modal and output
When exporting a highlighted transcript, two simple but powerful features offer user the necessary control over output without imposing complexity. Highlight only tagged annotations omits all highlights from annotations that aren't tagged. More powerfully, Limit to specific tags lets user export highlights for only the tags they're focused on, for designations or any other workflow.
16
options for issue tagging, informed by usage data, and beating competitors
Exceeding accessibility standards
All colors achieve AA and AAA WCAG contrast compliance for normal and large text when the superimposed text color is black
Intentional, diverse color choices
Designed to support large litigation teams and meet wide-ranging court-mandated color code guidelines… all while emulating the industry standard of traditional highlighters
Yellow
Blue
Orange
Green
Red
Gray
Magenta
Aqua
Pink
Coral
Violet
Peach
Gold
Chartreuse
Cyan
Brown
Smart default ranks
Highest-contrast and highest-demand colors are ranked highest by default, for accessible configurations OOTB covering most use cases
"This is exactly what I need for designating..."
7
most common types of color blindness covered by testing
Accessible across mediums
Tested in-depth to ensure highest possible visual contrast in digital and analog mediums
Creating an accessible palette
Nothing about the highlight palette is arbitrary. The size and variety of the set (16 colors) offers more variety than our competitors. The colors themselves are carefully tuned and tested for maximum visual accessibility in the digital and analog formats most important to our users. And in the app, colors dynamically change to a 'muted' tone in the relevant interactive states.
Color quantity and selection
Tradeoffs with this palette
Ensuring visual contrast across mediums
22%
active case adoption
within 60 days of release, a resounding success given litigation timelines and the role of designations in litigation
"It's really intuitive and easy to use."
18%
of company billable logos using the feature within 60 days of release
0
bug reports, and zero subsequent FRs expressing negative feature sentiment
"I changed the color easily and it shows everything I need."
Post release success metrics
Building multicolor highlights in Case Builder was deceptively complex work. The unique blend of functional and technical constraints (paired with non-obvious, domain-specific user needs) required deep design consideration. Our shipped feature balances versatility with ease of use, made possible by thoughtful user experience design.
Usage metrics I focused on
Qualitative feedback
Multicolor highlights in Case Builder was made available to all users in July 2024. Here's some of the qualitative feedback we received shortly after release:
Associate — Mid-size civil trial boutique
Paralegal — One of nation's largest plaintiff firms
CSM / Management — csDISCO