At DISCO, we have an extraordinary focus on giving our users and clients a “magical” experience. DISCO was founded on the principle of combining world-class engineering with a deep love and respect for the law, and we wanted to share the groundbreaking work done by our engineering team.
This installment comes from Sharon Cichelli, Senior Software Architect.
As a senior software architect, I feel it's my sacred duty to ensure that DISCO Ediscovery is fast, efficient, and serves our clients’ needs. Recently, our focus has been on optimizing DISCO’s workflow technology, which is our built-in tool to help clients seamlessly structure and manage reviews of hundreds of millions of documents every year. With workflow, clients have the ability to organize, track, and assign batches of documents, not to mention run AI-prioritized reviews, resulting in faster, high-quality reviews.
We’re constantly looking at how we can make workflow better and more impactful for our users.
But it’s not just that we make continued improvements; it’s the thought and intention behind every update that makes me proud to work at DISCO.
What do I mean by that? Well let’s look at the conditional coding feature we recently integrated into workflow.
Performance is paramount
In the world of competitive car racing, every new design change has to be evaluated against the potential impact on aerodynamics and performance on the track — not to mention the weight limit imposed by racing organizations. Similarly, at DISCO any new feature we add to the product has to be weighed against the potential impact on the speed and ease of use of the platform for our users. Our commitment to clients is there’s no speed that is “fast enough” for any aspect of our product.
Conditional coding provides guardrails for users and alerts them when they've made a mistake. Balancing the need to flag potential issues for users without bombarding them with notifications – and negatively impacting review performance as a result – was a tricky and exciting challenge to tackle.
Rather than just build what we thought would work, my team and I worked through a number of different technologies and designs varying where we would enforce the rules. Anything that slowed review down noticeably, or even measurably, was thrown out.
We ultimately landed on presenting the rule in plain English to the reviewer in the review panel so they could quickly and easily figure out what rule was not met and correct it. We hoped that while this might stop a reviewer for a few seconds one time, it would help them learn the rule to avoid making the same error in the future and therefore speed up the review.
Speed isn’t just about the performance of our platform. It’s also about how quickly our users can configure all of the features that will make them more efficient at reviewing documents. I've previously worked on similar projects for other products where the end result is so complicated, I might as well have asked the user to write software.
With conditional coding, we wanted to create an intuitive user interface that translates complicated software rules into simple sentences any user can understand. We built an interactive interface to walk users step by step through the setup of a rule. But then, we take an extra step by translating those choices in the application to show the logic in plain English. This makes it really easy for the user to verify that the rule’s configuration is correct.
Staying two steps ahead of potential problems
Have you ever been told to come in for an oil change or tune-up and let that appointment slip, only to have a much larger (and more expensive) problem rear its head? Your mechanic is thinking a few steps ahead to make sure these problems are avoided.
Before rolling out a new feature, our engineering team checks for problems that might arise for our clients. Conditional coding rules presented some interesting technical challenges to think through and solve beyond the typical interaction our users will have setting up a rule. Here are just a couple examples of the kinds of interactions our team thought about and engineered as part of the conditional coding development:
What if someone deletes a tag that is used in one of your rules? To keep the user experience “magical,” we designed the system to clean up the rules for our users — no additional administrative lift required. So if deleting the tag leaves a list empty, then that part of the rule goes away. And if it leaves a rule not making any sense, then we remove the whole rule because it doesn't apply.
Missing or inaccessible information
The easy way to create this would have been to create tag rules. Instead, we built something a lot more flexible and powerful by creating conditional coding rules that could apply to tags, fields, notes, redactions, and more. But this meant we had to deal with two sets of problems: what happens when the reviewer doesn’t have permissions to perform an action and what happens when a review manager sets up a rule but inadvertently omits the toggle for a particular decision from the decision panel?
Instead of dictating to users how to create rules, we designed warning systems to show up when users design a stage that includes work product that the review team doesn’t have access to, or when a rule includes requirements that have yet to be added to reviewers’ decision panel. This allows our clients to continue to reap the benefits of customizable systems while ensuring conditional rules are easy to set up and effective when used.
Being an engineer at DISCO always brings intriguing challenges — which is why we love working here! With DISCO’s focus on the macro and micro aspects of a feature, we ensure that our users experience “DISCO magic” with every click. As a team, we stand proudly behind our innovations, and I think that conditional coding is an exciting addition to the workflow feature set.
For more information about DISCO workflow and conditional coding rules, check out our recent article Reduce QC Before You Start Your Review.