At a Glance
Problem: Legal services in most enterprises run on email, phone calls, and institutional knowledge. Employees do not know what to ask for, who to ask, or whether anyone received their request. Up to 70% of employees bypass legal entirely when the process feels too hard and the organization quietly absorbs the risk.
Approach: Build a product that works for two fundamentally different users at once. The overwhelmed employee who needs a way in, and the skeptical legal professional who needs a reason to trust it. Across intake, triage, fulfilment, and reporting.
Key decisions: Intake designed for orientation not data capture. ML-assisted triage with human confirmation rather than automated routing. Deliberate workflow simplicity where adoption mattered more than comprehensiveness.
Result: More than 90% of licensed customers have successfully implemented and are actively using the product. Unusually high for enterprise software, and especially for this category. The customer base more than doubled in a single year once dedicated sales investment met a product built to hold up at scale.
My role: Design Manager, hands-on across the employee portal, intake, triage, fulfilment, reporting, and the ML and AI opportunity lens applied in the product's later phase.
The category nobody has solved
There is no billion-dollar legal service delivery company.
That is not a gap waiting to be filled. It is a signal about how hard the space is.
Most organizations still run legal operations on email threads, shared inboxes, and whoever you happen to know. Requests get lost. Nobody knows who owns what. Legal leadership has no real-time view of their own workload. Research shows up to 70% of business leaders route around legal entirely when the process feels too hard. Not because they want to take on risk. Because the friction defeats them first.
This is the baseline the product was built against. Not a mature category with established patterns. A function that most employees actively avoid.
Two users. Two kinds of reluctance.
Legal service delivery has a design problem most enterprise products do not face.
The two sides of the experience have almost nothing in common. And both bring resistance that does not respond to standard design moves.
The requestor is usually dealing with something they did not choose. A vendor dispute. A compliance question. A sensitive employment situation. They arrive not knowing what the service is called, who handles it, or what information they are supposed to bring. Legal jargon in category names stops them before they start. A form that asks for information they do not have causes them to abandon and call someone instead.
Even routine requests carry weight in legal. Users do not want to get something wrong in a permanent record. That anxiety shapes every intake decision.
The legal professional brings a different kind of resistance. Built into the profession. Accuracy above all is not a preference. It is a training and liability condition. Research across 800 attorneys found that traditional legal organizations are five times more likely to ban new tools outright than their corporate counterparts. That is not technophobia. It is professional risk management.
Designing for both at once is the core problem. What feels simple to an anxious first-time requestor has to feel rigorous to the fulfiller receiving it. What earns trust on one side cannot undermine it on the other.
Intake: designing for orientation, not data capture
We chose to design intake as orientation first, submission second, even though that meant some requests would still arrive incomplete.
The employee portal was clean, modern, and structured. A catalog of supported legal services that employees could actually navigate. In a space where the baseline was email, this was genuinely unusual. Legal is a category where users approach new things with suspicion. The portal had to earn that first click without overselling what it was.
The temptation in intake design is to optimize for data capture. Get everything the fulfiller needs upfront. Make the form comprehensive. The problem is that a comprehensive form in legal kills the requestor before they finish.
They do not know the answers. They do not know what the fields mean. They are already anxious. A long form that demands specificity they do not have reads like an interrogation, not a service.
So we held the line on orientation over completeness, accepting that legal teams would still need occasional clarification, because correct direction mattered more than perfect submission.
Plain language service names. Named the way employees think about problems, not the way lawyers categorize them. The difference between someone finding what they need and someone clicking away.
Guided sequencing that moved someone from "I have a problem" to "I have submitted a request" without requiring them to understand how legal works internally. Low-stakes questions first. Sensitive detail only when genuinely needed.
Mandatory fields placed carefully. Enough to protect fulfillers from incomplete submissions. Not so many that requestors abandoned mid-form.
The goal was not efficiency. It was confidence. A first-time user needed to finish a submission and trust that something would happen on the other side.
One thing I pushed for early was getting a dedicated content designer on the team. Content teams at ServiceNow were thin and stretched, and a product the size of LSD was not an obvious candidate for dedicated resource. But legal is one of the most jargon-heavy domains in enterprise software, and poor content design here was not just a usability risk. It was a customer liability risk. The wrong language in a legal intake form does not just confuse someone. It misdirects them in a high-stakes situation.
I made that case through design org leadership, framed it around risk rather than craft, and got a dedicated content designer assigned to the team. It directly shaped the plain language work across the portal and intake, and that work is what the 700% completion result traces back to.
One customer moved from email-based intake to the structured portal and saw completed legal requests increase by 700% in a comparable period. Not because the product was faster. Because the front door was finally legible enough that people actually used it.
Triage: keeping humans in the loop
We chose ML-assisted recommendations with required human confirmation over automated routing, even though automation was the more obvious path for scale.
Full automation was the default assumption going in. Every other workflow had done it. Triage especially, categorize, assign, move the queue. Nobody was arguing for it specifically. It was just the obvious direction.
What shifted the conversation was a story that had circulated internally from a ServiceNow Live event. A customer's legal team had received an urgent request through the LSD system:
"a threatening situation on their campus involving a weapon."
Because triage was human-confirmed, a legal professional immediately recognized what they were looking at, routed it to themselves, drafted an emergency property notice, and contacted the police. The situation was contained.
An automated system routing on keywords and category probability would not have caught that. It would have moved a life-safety situation through standard queue logic.
I brought that example back into the automation debate and reframed the question. This was not a design preference about keeping humans involved. It was a trust problem with real stakes. For a legal professional, a misrouted request is not a UX issue. It is a liability. Sometimes it is more than that. The room shifted. We moved collectively from full autonomy to ML-assisted triage, and nobody pushed back once the stakes were that concrete.
So rather than automatic assignment, we used machine learning to surface recommendations. The most likely categories, the most likely assignees. A human confirmation was required before anything moved.
Users got most of the speed benefit. Legal kept judgment in the loop for the cases where a wrong call was not recoverable. And the system built trust gradually. Recommendations that proved accurate over time earned credibility with the fulfillers acting on them.
As AI capabilities expanded later, that same principle held. Recommendation before autonomy. It was the right architecture for a profession where a routing error is not a UX problem.
Fulfilment and reporting: from tribal to workflow
We chose to make legal work visible without enforcing how it must be done, knowing that would mean some inconsistency across teams.
Before this product, most legal teams operated on institutional knowledge. Requests went to whoever you knew. Priority went to whoever followed up most. Workload was invisible to everyone, including legal leadership.
During discovery, the team faced a common crossroads for enterprise products: how much process should the tool enforce? The initial assumption was that to be valuable, the product needed to automate the specific steps of every legal workflow. But research with legal teams showed that standardizing how they worked was a non-starter. They did not want the software to dictate their legal craft. They just wanted to stop being a black box to the rest of the company.
That reframe changed what we built. Instead of complex bespoke workflow modules, we built a flexible universal fulfilment layer. Reliable enough that teams would actually use it. Simple enough that it did not get in the way of how legal work actually happens.
The fulfilment design replaced institutional knowledge with something structured and visible. Requests assigned, tracked, and delegated in one place. SLA timers that made turnaround visible. Supervising attorneys able to see capacity in real time. Watchers on sensitive requests so the right people stayed informed without being formally assigned.
Simplicity ran through all of it. The product covered the high-volume, repeatable request types that legal teams spend most of their time on. We stayed close to out-of-box wherever the workflow was genuinely adequate. With a small team and constrained investment, adding complexity created maintenance risk faster than it created value. If it did the job, we shipped it.
That simplicity changed what was possible on the other side. A healthcare organization used the fulfilment layer to reshape how their legal team worked. Paralegals shifted from basic ticket handling to contracting work, earning expanded responsibility over time. The product did not just process requests faster. It changed what people could do with their time.
Reporting followed from the same foundation. Before structured intake, legal leadership had no systematic view of their own operations. The reporting layer built on top gave General Counsel a real-time picture of volume, workload, turnaround, and outside counsel spend for the first time.
One customer reduced outside counsel spend by 10% after gaining that visibility. A state government legal team produced reports for their legislature demonstrating the scope of their operations. Something they had never been able to do before.
Those outcomes trace back to an intake form designed well enough that the data coming in was worth reporting on.
What 90% means in this category
In enterprise software, shelfware is the default. Customers buy, implement partially, usage drops.
More than 90% of licensed customers have successfully implemented this product and are actively using it to fulfil legal services.
In a category where employees route around legal by habit, where legal professionals approach new tools with institutional caution, and where the design challenge is two-sided reluctance, that number is not a metric. It is the argument. Proof that the design philosophy held across the full lifecycle, not just on the surface that gets demoed.
The customer base more than doubled in a single year when dedicated sales investment met a product built to hold up at scale. The design work did not create that growth. It created the conditions that made growth possible without the product falling apart under it.
What orthodox industries actually reward
The most important design work in this product was often invisible.
A category renamed in plain language. A triage recommendation that kept a human hand on a consequential decision. A workflow held deliberately simple because reliability in an orthodox industry earns more trust than richness.
None of that lands well in a design review. All of it shows up in a 90% usage rate.
Patience in an orthodox industry is not a personality trait. It is the design skill that matters most. Knowing the difference between resistance that will move with the right approach, and resistance that requires a fundamentally different one. This work made that distinction feel like second nature.
