Legal design sprints: a hard problem, a fixed window, a tested answer
A legal design sprint takes one significant problem — how advice is delivered, how a contract process works, how a service reaches its users — and runs it through a structured design process to a tested prototype in weeks, not quarters.
How a sprint works
We facilitate your team through the full arc: empathise (research with the people who actually experience the problem), define (frame what's really broken, which is rarely what the brief said), ideate (generate options beyond the obvious), prototype (build the strongest candidates fast), and test (put them in front of real users and measure). The discipline is in the last step — a sprint that ends in ideas has failed; ours end in evidence. Sprints are fixed-scope and fixed-fee, typically two to six weeks depending on the problem.
The problems sprints have solved
Previous sprints include redesigning the way a prestigious top-tier international law firm delivers legal advice; rethinking contract processes and self-service legal intake for in-house teams; designing dispute pathways and public-facing legal services; and shaping how organisations introduce AI into legal workflows — where a sprint is the fastest way to find the failure points before a full rollout. Sprint findings often seed larger engagements: knowledge curation, plain language redesign or a full pipeline build.
Why sprint with Inkling
A sprint is only as good as its facilitation and its testing. Ours are led by practitioners — Stanford d.school-trained, FT award-recognised, with eight years of legal design delivery — and every sprint ends with real-user validation benchmarked against our portfolio. It's the same rule Sara Rayment gave the FT about legal design generally: the meat is verifying the prototype.
FAQ
How long does a legal design sprint take?
Typically two to six weeks, fixed scope and fixed fee, depending on the problem's complexity and the testing required. The compressed window is a feature: it forces decisions that quarterly projects defer.
Who from our team needs to be involved?
A small core group — the people who own the problem and the people who experience it — for the workshop days, plus a sponsor for decisions. We handle facilitation, design and testing.
What do we get at the end?
A tested prototype, the evidence from real users, and a clear recommendation: ship it, iterate it, or kill it. All three outcomes are wins — the third just costs far less in a sprint than in production.
Bring us the problem your last three meetings didn't solve.