Design for the trainee, not the partner
Partners sign the contracts, but trainees and junior associates do the work. Legal tech built around what partners ask for tends to go unused - the products that stick are designed for the person actually at the keyboard.
In almost every legal tech sale, the person who decides and the person who uses are different people. The partner sits in the demo, asks the questions, signs off the budget and gives the feedback that shapes the roadmap. The trainee, or the junior associate, or the paralegal, inherits the tool on a Monday morning and has to make it work on a live matter. It is entirely natural to build for the first person. They’re in the room, they’re senior and they’re paying. It’s also, in my experience, one of the most reliable ways to build something nobody opens.
The partner buys, the trainee uses
When I was a trainee, the distance between how senior lawyers described the work and how the work was actually done was enormous. Not because anyone was being misleading, but because partners hadn’t done that layer of the work for years. They remembered its shape, not its texture. They knew a report on title needed producing; they had long since forgotten what it was like to assemble one at nine at night from forty documents of varying legibility.
That gap flows straight into product design if you let it. The partner’s mental model of a task is the summary version, and a tool built to that model will be elegant, high-level and slightly beside the point for the person doing the work.
What partners ask for
Partners tend to ask for outputs. A dashboard of matters. A one-page summary of the lease. “Can it just tell me the answer?” These are reasonable requests from someone whose job is reviewing work, and they lead to products that look superb in a boardroom.
Trainees need something different. They need help doing the task: finding the right clause in a long document, checking their reading against the source, understanding why a provision matters, getting a first draft into the shape their supervisor expects. They need the tool to sit inside the work, not on top of it. A summary is useful to the person who will never open the document. The trainee is the person who has to open it, and a tool that summarises it for them without showing where each point came from has made their job harder, not easier.
The trainee’s real fear
If you want to design for juniors, you have to understand what they’re actually afraid of, and it isn’t being slow. It’s being wrong in front of their supervisor. Every trainee has handed in a piece of work and watched it come back covered in red ink, and that memory exerts a far stronger pull on their behaviour than any promise of saved time.
This changes the design brief completely. A tool that produces a confident answer the trainee can’t explain is a liability to them, because when the associate asks “where did you get that?” they need to be able to point. So the features that matter most for junior adoption are the ones that make work defensible: every extracted point linked to its source, uncertainty flagged rather than smoothed over, and output the trainee can check quickly before it goes upstairs. Get that right and juniors will reach for the tool voluntarily, because it protects them.
Supervision is the hidden workflow
Law firms run on supervision. Almost nothing a junior produces reaches a client without someone more senior reviewing it, and that review step is one of the most expensive and least examined parts of legal work. It’s also where a lot of legal tech accidentally creates friction. If the tool’s output arrives in a format the supervisor doesn’t recognise, or hides its reasoning, the supervisor has to redo the work to trust it - and the time saving evaporates one level up.
So design for the handover. The output should look like what a good trainee would have produced, in the structure the associate expects, with the evidence visible. When the review gets faster, both people benefit, and the partner sees the benefit too - in the form of matters moving, rather than a dashboard.
Trainees are the next partners
There’s a longer game here as well. Habits formed in the first years of practice are remarkably durable. The way you learned to review a lease as a trainee is, give or take, the way you’ll review one as a partner. A tool that becomes part of how juniors learn to work doesn’t just get used this year; it gets carried into every team those people go on to run.
The reverse is also true. A tool that juniors experience as something imposed from above, built for someone else, gets quietly routed around - and they carry that habit forward too.
What this doesn’t mean
Designing for the trainee isn’t dumbing anything down, and it isn’t ignoring the buyer. Partners still need to be persuaded, and they should be: by evidence that their teams are using the thing and producing better work, faster. Sell to the partner. Listen to the partner on risk, on clients, on what quality means. But build for the person whose hands are on the keyboard, and watch them use it, because their behaviour is the only feedback that doesn’t flatter you.
The best compliment a legal tool can earn isn’t a partner calling it impressive. It’s a trainee, under pressure at the end of a long day, choosing it over doing the job by hand - and their supervisor noticing nothing except that the work came back right. Design for that moment and the partner will be happy enough. Design for the partner, and that moment never arrives.
Written by Dom Conte
Legal-tech founder, builder and speaker. More about me →