Multicolor designation highlights
This work is a reconstruction of annotation highlight mechanics in the Case Builder deposition management platform. It reinvents highlight workflows for the legal domain for the first time in sixty years. But… it's about far more than some interesting UI. The work builds upon institutional knowledge to exceed its original mandate and unlock myriad workflows to help generate millions of dollars in sales.
My role in this work
I owned this work end-to-end—including all discovery, research and design. I worked closely with cross-functional peers throughout.
Why this work matters
The legal domain's relationship with tech is rapidly evolving, while consequential legal outcomes are dramatically reshaping society. As such, design decisions at DISCO carry potential for seismic impact. Amid this turbulent landscape, crafting accessible and intuitive solutions has never been more important.
Good design requires context
In my case studies, I pass that context along. There's probably more info here than you need, so most of it is collapsed by default. Expand the elements you care about. Reach out with any questions!
Case study contents:
Initial design explorations
Understanding the multicolor gap
User demands in context of DISCO's business needs
Driving creative problem-solving
Encouraging a more holistic, less reactionary team disposition
Initial design explorations
Identifying three broad paths for resolving our gap
Cross-functional collaboration
Good design isn't made in a vacuum; good designers don't operate in a silo
Designed feature
Making the case for in-app parity
Serving more use cases (for much greater ROI)
Feature nomenclature
Aligned teams need shared language
Highlight draw order and logic
The front-end rules driving highlight visualizations
Application touch points
Feature implications throughout the app
Creating an accessible palette
Balancing functional and interactive accessibility demands
Updating search and find hits
Example of an interaction hurdle resolved thru deep collaboration
Feature summary and success
Summary and gauging feature success
Impetus and overview
What motivated this work?
Legal practice is loaded with time-consuming workflows that would be considered archaic in most industries—but which serve the important function of maintaining friction in legal strategy. Lawyers are (famously) strategically risk-averse, and hesitant to embrace new technologies. Doing things slowly helps maintain intentionality, reduces the likelihood of errors, and enables highly customized multi-party workflows that most collaboration tools aren’t designed to support. All this friction results in a lot of legal tooling ripe for reinvention—including multicolor highlights.
This work began as a pursuit of improved designations support in deposition review. Designations refers to the process of identifying strategically important moments in depo footage, then making the case to use them at trial. It's a nuanced, multi-party process with outsized impact on legal outcomes.
I evolved this feature from its inception as a narrowly scoped gap fix… to a thoughtful, broadly useful mechanism that supports myriad use cases beyond its original mandate. This case study is about developing a deep understanding of user needs, creating custom digital highlights that work across mediums, and the fun of solving for complex technical and interactive minutiae along the way.
Product context
Overview of relevant Case Builder functionality
Case Builder launched in 2020 to fill an industry gap — comprehensive case management. 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. Case Builder is highly complementary to DISCO's larger Ediscovery platform.
I've worked on Case Builder both in a supportive capacity and as design lead. Over the years, the team consistently shipped value, eventually evolving the product beyond its original mandate. Today Case Builder is positioned as Timeline and Depo Management modules inside a broader DISCO legal tech platform.
Broader feature set
Case Builder is much broader than deposition management. I was heavily involved in its design across various facilities. If you're curious, here's more of what our product offered users.
📹
Deposition management at scale
🔄
Automatic depo transcript syncs
⏳
Strategic fact timelines
📝
Detailed work product tooling
🤖
AI timeline generation
👩🏻⚖️
DISCO Ediscovery integration
👥
Witness management
📄
AI depo summaries
Trial designations context
Why did we need to build multicolor highlights?
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 lit support teams. Here's more info about designations if you're interested to learn more:
Designation lifecycle
Designation complexity varies by case. Let's consider a relatively simple case with two parties, each represented by one legal team... the designation workflow would look something like this:
Identifying affirmative designations: Each party conducts depositions, then references depo transcripts to designate portions of testimony for use at trial. They document designations by color-coding them (highlighting the transcripts) based on party or theme.
Initial designation exchange: Before trial, both parties must share their depos and designations with opposing counsel. Legal teams coordinate the parameters and methods of designation exchange. Multicolor highlights are used to color-code designations, but historically legal teams were forced to use Acrobat or physical highlighters because legal software overlooked their niche highlighting needs. This created huge time waste and added confusion to the tension between legal teams.
Counter designations: Each team has the opportunity to identify counter-designations as responses to opposing designations. Legal teams sometimes back down on their affirmative designations as a result. Negotiation and bargaining can occur. Separate highlight colors may be used to represent affirmative and counter (or counter-counter!) designations. The back-and-forth quickly becomes complex.
Designation objections: Teams can also object to the use of designated testimony, thereby involving the court to make a ruling on designation admissibility. When the court is involved this way, a third party enters the picture with their own color-coding demands which supersede those of the litigators. When this happens, legal teams must adjust their highlight colors to abide by the court's instruction.
Additional rounds and resolution: The back-and-forth around designations is tedious and high pressure. Through it all, multicolor highlights are used to organize and communicate which party is claiming which testimony for use at trial. Rework and wasted time are the enemy of progress in this process, so Case Builder's historical support for only one highlight color needed to be remedied.
Documentation: For posterity and legal defensibility, both parties maintain a record of all affirmative and counter designations, as well as objections, struck down designations, redirects, and various rulings.
Extreme time constraints
Depositions occur after document discovery, but before trial start dates—in that short window, legal teams face high pressure to orchestrate designations. Fragmented workflows compound the time pressure placed on this important step in trial prep.
Competing interests from multiple parties
The interests of the court don't always mesh with the interests of counsel—often, courts will mandate designation formats that are inconvenient for litigants.
And the interests of counsel certainly don't mesh with the interests of opposing counsel. In fact, litigants are highly incentivized to complicate designations for other parties. This tension is held in check by court guidance and legal standards, but it places added importance upon good designation management.
The significance of highlights
Most courts enforce unique color coding rules and formats for designation documentation and exchange. When preparing designations for exchange with opposing counsel, highlighted transcripts are typically the required format. The court often decides which highlight colors are used to represent which litigants and which designation types. Our multicolor highlight solution needed to be flexible enough to support a wide variety of highlight configurations.
Highly customized offline workflows
The complex nature of designations and the tension they inspire between litigants has led to disparate designation workflows throughout the US. Few case management tools were attempting to solve for designations, so most legal teams I spoke with had resorted to custom offline workflows using spreadsheets or Word docs. Although our multicolor highlights wouldn't solve for the entire designating workflow, it would lay a strong foundation for building out that more comprehensive support.
Understanding the multicolor gap
User demands in context of DISCO's business needs
As a critical step in the litigation lifecycle, designations are an important use case for any deposition management tool. But in 2022, 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 existing yellow highlight treatment was woefully inadequate.
DISCO's motivation:
For Case Builder, lack of proper designations color coding was becoming a sales blocker and harming expansion revenue. The team overlooked this use case initially—but as more long-term cases approached trial, customers began to demand resolution. Eventually, this omission would negatively impact every Case Builder user during a notoriously high-stress pre-trial period.
User motivation:
As adoption increased, top users and advocates were identifying 'paper cut' gaps the launch team hadn't foreseen. Among them, lack of designation color coding was creating the most pain. Our existing feature forced users to apply multicolor highlights outside the app, with Acrobat or literal physical highlighters… this was cumbersome and untenable. Case Builder's competition was also starting to message around this gap—despite having clunky implementations, they at least offered more colors than Case Builder. Our users deserved better.
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:
Can they highlight the transcript in multiple colors? The court oftentimes is asking for a copy of the highlighted transcript, with the court's rulings, and the designations from both parties with annotations. Are they able to print out a transcript that has everything I just listed?
Partner, mid-size regional firm
The defendants want to do a color coding system for the deposition designations. Is that something we can do in Case Builder?
Partners, full-service national law firm
The product is working great. We are doing deposition designations now, and one of the requirements is to use particular colors for highlighting ... we’re supposed to use blue and the enemy green. Would it be possible to work color selection into the platform? (Specific colors are frequently required by courts for deposition designation.)
Partner, large-size regional business firm
Driving creative problem-solving
Encouraging a more holistic, less reactionary team disposition
As often happens with well-intentioned customer feedback, the signal we were hearing contained prescriptive suggestions scoped to the specific feature gap users were struggling with, 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. Instead, they catered toward a given firm's unique workflow. And they favored functional addition rather than simplification or finesse—which always carries the risk of compounding complexity unnecessarily.
Initially, the sheer volume of feedback with these themes pigeonholed the team's imagination. In pursuit of unblocked sales, there was a strong temptation for Product to fulfill user requests exactly as prescribed.
But when I joined the scene, I challenged the team on whether it was right to take these requests at face value. The need clearly had to be fulfilled, but I sensed an opportunity to approach it more holistically. I wanted to explore whether our designations color-coding could also be designed to support non-designation workflows. If we could solve for multicolor highlights more broadly, we could offer users more value for a similar cost of implementation.
Initial design explorations
Identifying three broad paths for resolving our gap
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.
Path 1: Split designations into a distinct domain object
This would introduce a new type of work product, creating a foundation for my long-term vision of holistic in-app designation support. This path was broad and idealistic but incorrect given our constraints—we needed to fill the multicolor highlights gap asap. This approach was also semi-duplicative of Case Builder's existing annotations, and would have required active users to migrate designation annotations. I also wasn't convinced that users shared my vision of transitioning the full designation workflow to Case Builder. The topic needed research.
Path 2: Create a unique type of tag for designations
This approach would lean upon our existing tagging feature, introducing a new designations tag. It would require less investment than Path #1 while serving the majority of known use cases. But there were tradeoffs—it would:
Place even higher functional burden on tags (a common SAAS trend I sought to avoid)
Create a tagging functional gap between DISCO products, muddying mental models for cross-product users against our goal of a singular unified platform
Force introduction of 'party' entities to our domain model, presenting new management challenges
Force actively designating teams (~40% of users) to migrate designations to the new tag type (or pay for services)
Fail to consider how multicolor highlights could serve users beyond designations
Path 3: Add multicolor highlights to existing tags
I wanted to take a more fundamental approach—I theorized that we could deliver user needs without complicating our information architecture, and without imposing a steep learning curve for new users. By imbuing existing tags with multicolor highlights, we could serve a wider variety of use cases than designations. No new objects or entities, no migrations, no new pages. Allowing any tag to be assigned a unique highlight color would be a flexible, workflow agnostic solution that actively designating users could easily adopt.
Cross-functional collaboration
Good design isn't made in a vacuum; good designers don't operate in a silo
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
My dynamic with Product is constant and has greater impact for my team than my dynamic with any other function. I rely upon product partners for collaborative ideation, to orchestrate our team's resources effectively in support of a shared vision, and as an equal partner when conducting research.
Engineering
Collaboration with engineering also starts early and continues beyond release. Engineers are often the people I learn the most from—I return the favor by pulling them into design and research, and providing thorough specs and documentation. I don't subscribe to the outdated notion of design handoff as a static phase in feature development. Instead, engineers are consistently in the loop and our work tends to blend more often than not. I cherish good working dynamics with engineering.
Legal domain SMEs
Being new to the legal domain, I leaned on the expertise of my peers to shape up my initial product opinions at DISCO. The team had many former litigators—I maintained years-long feedback loops with some of these domain experts and my work was stronger as a result.
Other designers
Labs are DISCO's version of design critique. They played a crucial role in my design process across all teams, especially during early-stage discovery. Quality feedback is the lifeblood of design—I loved Labs and used them often. I also kept biweekly pair design and feedback sessions with several designers on the team.
Design systems team
There are a handful of filters through which I assess any new design challenge… is the challenge motivated by the right strategic disposition, or is it purely reactionary in nature? Has the organization previously solved this problem? How can the problem be resolved in a way that benefits every team and not just those directly involved? At DISCO, every design decision I made was shaped by — or helped shape —the design system that defined our user experience. I collaborated constantly with the design systems team to ensure alignment on vision, aesthetics, heuristics, and guidelines.
Conducting external research
It takes many forms, but good design always requires research
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:
Objectives and deliverables
Product and Business Objectives:
The purpose of this scoped research exercise is to determine whether the ‘critical path’ prototype would adequately resolve user pain in service to larger business objectives.
We do not yet know whether we will invest in Case Builder’s designation functionality beyond the ‘critical path’ concept in the future—we may choose to conduct further research to find out.
Deliverables:
Recording and transcription (via Zoom and Chorus, respectively) of qualitative, conversational feedback
Qualitative analysis of user feedback surrounding specific UI elements
Key insights identified and documented, then elevated to Ares Pizza Hut members and the organization’s research repo
Research hypotheses
We believe we can help users by automating the process of creating a highlighted transcript and streamlining the overall process of selecting and exchanging designations.
We anticipate feedback to suggest that the proposed ‘critical path’ concept will resolve ~85% of user pain around designations in Case Builder today.
We believe that the proposed ‘critical path’ concept establishes a foundation for further investment into designations-adjacent feature sets, but that those additional investments may be unnecessary in the near-term.
Participants and method
Participant pool
We're aiming to connect with a minimum of five users to discuss the ‘critical path’ concept. The need for multicolor designation highlights in Case Builder is a fairly well-understood problem, but validation remains a critical element of the design process, and it’s important that we check our own assumptions on this topic.
Overview of methods
These sessions will be lightly moderated and fairly conversational in nature
Assuming participant’s consent, these sessions will be recorded
Design (Joe) will guide participants through a series of baseline questions to understand their needs and perceptions around designations in Case Builder today. The conversation will then shift into an on-screen design share with guided questions to understand the efficacy of our proposed solution
Recording and transcription (via Zoom and Chorus, respectively) of research sessions will be produced following each session; these will be elevated to the Ares dev team for optional review/visibility
As a backup to recording in case the subject prefers not to record, one cross-functional partner will join each call and take notes as needed
Guiding questions for internal reference
These considerations aren’t necessarily direct questions we’ll be asking users, but they help shape the moderated content further down in this doc.
How do users feel about designations as they exist in the platform today?
How do they manage / organize designations amongst other tags?
Roughly how many different designation tags do they use in a typical case?
What pain points have they encountered while designating in Case Builder?
How useful do users find the current ‘Designations’ export artifact?
What’s missing / how would they change it?
What value does this offer their current designations workflow / what pain does it introduce?
What manual elements of their designation workflow might we fold into this artifact?
Does our prototype sufficiently resolve the pain points users are feeling around designating in CB?
Do the proposed export configuration options meet their customization needs?
Do the proposed export highlight treatments meet the needs of document recipients?
Do the proposed color choices meet their needs in terms of variety and recipient color reqs?
Would users find value in being able to reset/change highlight color on the export modal?
Is setting up export highlights acceptable as a global setting (as seen in prototype), or would they prefer to do this on a per-export basis?
Are there highlighting / designating techniques they use in trial prep that could be brought into the CB UX to help their workflow?
Examples of additional guiding questions:
How would the ability to use multicolor highlighting inside the application influence their workflow?
Does their team have alternative (non-designations-related) use cases for exporting multicolor highlights?
How do users currently work with objections inside of Case Builder? How do they track objection types? How would they leverage an option to export margin notes, alongside a highlighted transcript?
When thinking about multicolor highlighting in designating, how would colors typically be organized?ie, would a color usually correlate to a party, type of objection, etc?
Discuss these areas of potential investment to gauge their value to the user
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.
Excerpts from actual session rails:
Intros and setting context
Introduce attendees / roles
Participant introduction / Title and primary role (for confirmation)
Explain purpose of design discussion
My goal is to understand their goals to design the best solutions for them and their team
This is exploratory discovery and not guaranteed to make it into the product
These are explorations — please feel free to be brutally honest!
I’ve got questions, but this is also relatively informal, please share what’s on your mind!
Ask for recording permission; record
Current designations workflow
Thinking about designations, how would you describe your role in the designating process?
Follow: Roughly how long doing designations?
What does your typical designations workflow look like (either inside or outside CB)?
Follow: Clip selection / creation / management?
Follow: Running exports?
Follow: Who receives the exports?
Follow: Are there specific formats that you like your designations in?
Which designations tasks occur inside of Case Builder; which outside?
What does the cadence and order of designations usually look like?
ie, one party at a time, one type at a time, all at once, etc.
Feedback on current CB designations UX
Inside the app
Roughly how many types of designations do you use in a typical case?
How do you feel about the current experience of doing designations in CB?
Follow: Do you encounter any challenges while designating in Case Builder?
What would your ideal designations experience look like inside of Case Builder?
Exports (show tab with examples of current exports)
When you think about exporting designations from Case Builder (highlights or table), which exports do you use, and why?
Follow: how useful are these exports?
Follow: Is there anything you would change about them?
Follow: what feedback have you received from recipients about designations exported from CB?
If you received these exports from another party, what feedback would you have for them?
If they don’t use CB for designating: Discuss the formats they use and the deliverables they create. Are they willing to share an example?
How do you currently handle highlights that overlap?
Prototype walkthru questions
Configuring export highlight colors on Tags
Notice the addition of the ‘Export highlight’ column — what do you think is the purpose of this column? How might I interact with it?
Change colors on two designation tags
I’ve just changed the colors associated with these tags. Why might I want to do that?
Expand color dropdown
How do you feel about the color options in this dropdown? Sufficient?
Configuring export options on export modal
Open export modal to default
From here, how would you go about exporting the designations that we set colors for?
Select option 2, limit to designation tags
Looking at the options configured here including ‘highlight appearance’ section, what would you expect this export to look like?
Switch to ‘blend’ option
How do you expect this would change the appearance of the export?
Exporting ‘stacked’ artifact
Switch back to ‘stack’ option; select 'export'
We’re looking at one page from the exported transcript. What is your perception of what we’re seeing?
What do you think these orange/blue (stacked) lines indicate?
What do you think these chips in the bottom margin indicate?
Would this artifact meet your designation export needs? Why/why not?
Does it meet the needs of a typical export recipient? Why/why not?
Exporting 'blended' artifact
Back to the modal; switch to ‘blend’ option; select ‘export’
What is your perception of what we’re seeing?
Something different in this export design is the inclusion of these margin bars — what do you think these indicate?
Another different element is these inline chips here — what is your perception of these?
Would this artifact meet your designation export needs? Why/why not?
Does it meet the needs of a typical export recipient? Why/why not?
Do you have a preference between this and the ‘stacked’ export we looked at; why?
Walkthru wrap-up
Back to Tags screen
How would the proposed changes we’ve looked at impact your designation workflow?
In this prototype, export highlight colors are set globally. Would you benefit from these highlight options being modifiable on a per-export basis?
Before we finish this portion, do you have any additional feedback about these screens we’ve looked at?
Key research insights
The most impactful learnings on my feature design
Path #3 validation
With visual representation of the paths, users overwhelmingly preferred Path #3. They weren't sure yet about the idea of a full designations workflow transition into Case Builder, but felt strongly that Path #3 would solve their immediate multicolor needs and could lay the groundwork for such a transition.
Use cases beyond designations
These conversations inspired new ideas from users about how multicolor highlights could serve a wide array of workflows outside of designations. This was a big unlock that shaped my approach to designing a configurable, non-prescriptive highlight feature to suit diverse workflows.
Emphasis on exports
A central theme among research subjects was expedience — many users were actively designating for trial or would be soon, so they considered multicolor transcript export more important than in-app multicolor highlights.
Visualization preferences
I gauged users' reception to different color visualization methods (ie stacked vs blended highlights) as well as visualization aides (ie margin bars). They overwhelmingly preferred stacked highlights over blended. They found little use for margin bars because margin solutions don't communicate partial line designations.
The role of visual accessibility
Across digital and analog mediums, multicolor highlights needed to be visually accessible for viewers with color blindness. This is table stakes. I learned that the legal domain demographic has disproportionately high rates of color blindness, further emphasizing the importance of visual accessibility in this feature.
New usability considerations
These conversations yielded insights about some of the more niche industry considerations for exports. Examples include the role of court-mandated Velobinding for prints (which affected the layout and design of our export) and the growing role of tablets for PDF review in the courtroom.
Useful feature recommendations
Users brought great ideas around export configuration, like the option to "export only pages containing highlights." This element didn't make the cut for this work—but it did release later that year as its own feature, saving countless paralegals from tedious post-export manual page removals.
Established feature constraints
Experiential boundaries identified via research
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:
Ability to assign multiple highlight colors to represent parties or causes
Designations often overlap, so highlights need to 'overlap' without sacrificing legibility
Highlights have to be easily discernible from one another and visually accessible in analog formats
Highlights must be flexible enough to support color coding changes without requiring rework
Most teams care about in-app highlights; some care exclusively about the export
Users have a relationship with pre-existing yellow highlights that needs to be honored
We should strive to maintain users' established annotation mental models
Product constraints and limitations:
Transcript lines have constrained vertical space and cannot change pages
To achieve analog parity, multicolor highlights cannot rely upon limitless digital vertical space in the app
The viewer renders pre-existing yellow highlights on a per-character basis to support partial lines
Any changes cannot interrupt customers' ongoing designation workflows
Changes cannot reduce the fidelity or contents of pre-existing annotations in customer cases
Making the case for in-app parity
Serving more use cases (for much greater ROI)
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.
🎨
More powerful issue coding
✏️
Work product color assignments
🎥
Highlighted transcript presentations
🤝
Inter-team coded exchanges
🧠
Intra-team strategy and review
👩🏻🎓
Trainee color assignments
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.
Feature nomenclature
Aligned teams need shared language
Sharing a common language with team members is especially important when building a novel experience. I established these terms and promulgated them among team and stakeholder syncs to help us all avoid confusion and improve collaboration.
Highlight draw order and logic
The front-end rules driving highlight visualizations
While conceptually simple, this feature's complexity compounds quickly. 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 which 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?
Any order of operations for rendering Highlight Slots could possess tradeoffs for the user, depending on their task at hand. Some of the many variables at play include use of colors, user-defined color ranking, annotation density, and overlapping interactive states in the transcript viewer.
This Draw Order achieves the best balance across states. Drawing first by Start Location allows for the most efficient use of Slots and the greatest possible amount of color information to be displayed.
This order also possesses fewer tradeoffs than its inverse, for which the logic quickly breaks when there are extensive overlapping Bands. And it eliminates potential for wasted empty Slots due to overlapping higher-ranked Colors that don’t appear until later.
Depending on color use and rank, the Draw Order can technically result in scenarios where a lower-ranked Color fills the Primary Slot. In this or any other circumstance, user has a few options for ad hoc manipulation of highlight renders. More details below!
Redraw 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 the app to re-draw Bands
Page load / refresh
User turns ON/OFF the highlight visibility toggle:
With the highlight visibility toggle OFF, user hovers over an annotation card
With the highlight visibility toggle ON or OFF, user selects a specific annotation card to enter annotation edit mode
While in annotation edit mode, user removes or adds a tag(s)
If this did not trigger re-draw: user would lack visual cue that their tag has been applied
If this did not trigger re-draw: upon user deleting all tags, the app would not display any Bands, leaving no visual affordance of the annotation’s range
User exits annotation edit mode (ie, deselects an annotation)
This allows the user to adjust an annotation’s start/stop point using our draggable toggles, then see the impact of that change in the appearance of Bands
Band 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
Overlapping Bands of the same Color merge into a single visible Band—when they overlap, we are not concerned with distinguishing between multiple same-Color Bands
Newly drawn Bands fill the lowest available Highlight Slot, as determined by the Draw Order
Once a Band has started being drawn, it does not shift Slots or hit its Stop Location until complete, regardless of its surroundings, unless there is a re-draw event
For example, the start of Band B has no impact on the Slot position of Band A
When Bands are re-drawn, they may shift Slots or disappear altogether—but they never shift location without a re-draw event
When Slots become available because previously overlapping Bands reach their Stop Location, Bands that were previously pushed out of view may fill the lowest available Slot, as permitted by the Draw Order.
Providing detailed implementation guidance
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.
Example scenario from specs
This scenario explores how Band Behavioral Guideline #4 drives complex color renders for an ideal user experience despite overwhelming visual information.
In this mock, you can see two different examples of how Band Behavioral Guideline #4 can play out differently within a single page:
For Annotation #2 (13:6-14):
On Line 8, Blue and Orange Bands from Annotation #1 hit their Stop Location
Gray and Magenta Bands continue in their Slots until their Stop Location on Line 14—they do not shift Slots (per Behavioral Guideline #3)
On Line 9, Gold would fill the newly available lowest Slot—but per the Draw Order, it cannot because it is lower-ranked than Gray and Magenta.
This does result in ‘unused’ Slots, but that is preferable because the Draw Order respects user-defined color ranking.
For Annotation #3 (13:12-20):
On Line 14, Gray and Magenta Bands from Annotation #2 hit their Stop Location
Yellow and Orange Bands continue in their Slots until their Stop Location on Line 20
On Line 15, Green does fill the newly available lowest Slot
This is because Green rendering in that position is permitted by the Draw Order.
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
Select an annotation to focus its Bands
This will trigger a re-draw of the Bands associated with that annotation, which will stack based on rank
Adjusting annotation start/stop points to better suit desired Band appearance
Exiting annotation edit mode initiates a re-draw
Changing use of Highlight Colors, either by:
Changing the Color associated with a given tag, or
Adjusting Highlight Color ranking for the case
Application touch points
Feature implications throughout the app
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.
All tags retroactively assigned Yellow
When users received this feature, all pre-existing tags in a given case were retroactively assigned Yellow. This way, we forced no change for actively designating users. Any tag's highlight color could then be changed at will.
Setting highlight color rankings
To support eleventh hour court-mandated color changes in trial designations, I designed the ability to easily configure a given color's rank relative the rest of the highlight palette. This offers them greater control over how colors render relative one another in Highlight Slots. It allows for frictionless, non-destructive, case-wide color coding updates with no rework necessary.
Changing tag highlight colors
Once user's matter has the feature enabled, they can easily assign any case tag one of the (16) highlight colors. This workflow agnostic approach supports the widest variety of use cases for multicolor highlights. It keeps user in control rather than imposing a highly opinionated color treatment.
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:
Toggle off: Annotation hover
Relevant Bands are visible while hovering an annotation.
Toggle off: Annotation selection
While annotation is selected:
Relevant Bands are visible
User can drag handles to adjust highlight start and stop points
In this example, Yellow is not highly ranked. But per our behavior guidelines, it cascades to the Primary Slot because there are no competing Colors.
Toggle on: Annotation hover
While annotation is hovered:
Relevant Bands render normally
Irrelevant Bands render with the muted palette for de-emphasis
This keeps emphasis on relevant Bands without fully obscuring others; here we assume user wants the context offered by irrelevant Bands since the highlight visibility toggle is enabled
User can easily hide irrelevant Bands by (1) selecting the annotation or (2) disabling the highlight visibility toggle
Toggle on: Annotation selection
While annotation is selected:
Relevant Bands are visible
User can drag handles to adjust highlight start and stop points
Irrelevant Bands are hidden to avoid handle drag conflicts, because per our rules, Bands can never be allowed to superimpose
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.
Highlight export options
Recall that Yellow is the default highlight color for all annotations. These two settings allow our feature to maintain that precedent without complicating exports. In this example, user only wants to export highlights for three designation tags—these features make it easy! In our research, some users wanted to manage colors at this touch point… instead, we built them a simpler but more powerful solution, much to their delight!
Creating an accessible palette
Balancing functional and interactive accessibility demands
Additional details forthcoming
More details will be added to this section on 07.15.2026 — reach out with any questions!
Updating search and find hits
Example of an interaction hurdle resolved thru deep collaboration
Throughout build, we encountered interesting constraints unique to Case Builder and its users. One such example was the potential for conflicts between multicolor highlights and Case Builder's existing search and find hit treatments. This section details how I worked through this specific interactive challenge.
Additional details forthcoming
More details will be added to this section on 07.15.2026 — reach out with any questions!