The commercial lawyer’s great unforced error is this: buying into the idea of contracts written by lawyers, for lawyers. As lawyers, we are trained to write them in the special, mysterious, arcane language we studied so hard to learn. The delicate mysteries of our contracts can as such only be properly understood and interpreted by another keeper of mysteries – i.e. another lawyer or a judge. Lawyers and judges are important stakeholders in contracts but all too often the end reader of the contract is forgotten.
But think back to that expensive education. Think about every milestone contract dispute you ever learned about at law school. Those key decisions were not Freshfields v Clifford Chance, or Re. Linklaters, or Herbert Smith v Slaughter & May. It was the likes of Hadley, Baxendale, Hyde, Wrench, Williams and those Roffey brothers that bore the consequences of how their contracts were constructed. Business contracts are first and foremost for clients. Users who aren’t lawyers should be the main concern when drafting a contract.
From their perspective, what’s a contract for? It’s for securing the business objectives and performance that the parties expect. The templates, style guides and preferences that transactional lawyers use to make their job easier are really useful for those lawyers; but who cares about the lawyers? Business users want usable contracts that achieve the maximum operational efficiency, with reasonable risk allocation, at an acceptable cost. They need to know what the contract requires them to do, where, and when. Your lawyers’ eyes might see a contract as legally perfect, built on such nuanced and sophisticated language as to be a work of art; but if the business users are bamboozled by dense jargon and complexity, the contract is failing in its primary duty. End-users need and deserve better!
Clients are the reason contracts exist, not lawyers. But behind those clients, there are stakeholders from finance, HR, project management and operations management. There are technical, financial and implementation concerns to consider, as well as legal. Lawyers just got pushed even further down the hierarchy. Legal is a key piece of the transactional puzzle but it’s just one piece – alongside the boilerplate documents, language and templates, there’s deal-specific information and considerations that come from the business, with managers and engineers assigning and designing roles.
Making sure this all fits together is a question of information architecture – the need-to-knows must be incorporated elegantly and simply, in a way that’s easy to understand for all users – especially non-legal roles. For example, if you intend to send contracts to individuals in other countries, you could consider legal translation services.
After all, consider where the rubber meets the road: the operational and delivery teams that will be tasked with making sure people fulfil the roles assigned to them in the contract. If that contract stays written by and for lawyers, misunderstandings on the part of non-legal users are inevitable. Information architecture has to be robust: it’s when information and responsibilities move from team to team that interpretations become inconsistent – and contractual risks are the result.
So how do lawyers think like information architects? How do we make legal domains easy to understand, and easy to navigate for non-lawyers? We look at the work of information and interaction designers for inspiration – and what do they do?
They look for patterns. Patterns are everywhere in design, in software, in architecture; they’re easy to see. Designers collect these and create pattern libraries. Patterns libraries present common solutions to recurring problems; they help to find a universal language for stakeholders and collaborators from different disciplines.
Why can’t legal do the same? Contracts present recurring problems; patterns arise in contracts; and it’d be useful to have a common language that stakeholders and collaborators from different disciplines can use. If contracts are for clients first and lawyers second, then a library can gather best practice, and flexible solutions, to help clients understand and navigate their contracts more easily. We need design patterns for contracts. This wouldn’t mean that we get rid of your boilerplate, templates and models. Instead, we build on them, and organize them in a way that puts clients first. It might not be easy: a properly organized and validated library needs plenty of work and testing. It must be universal enough to be useful, but specific enough to address real situations, and we need to be able to update and customize it easily.
We’re not the first lawyers to make this point. Terms like ‘diagramming transactions’, ‘creating a GUI for legal texts’ and ‘building a visual interface for dealmaking’ have been tried and tested, with different levels of success and consistency. A team at Harvard tried to crowdsource a contract wiki, collecting modular contractual terms that could be used to respond to what they called ‘system shocks’. But getting a wiki to the required level of currency and maintenance isn’t easy, and the wiki is dormant now.
There are other initiatives we like too: Legal Robot is an AI-driven legal language model that constantly refines best practice; Docracy is an open library of crowdsourced contracts available to use and customize for free. These are all pulling in the right direction – moving contract objectives away from the lawyer and closer to the client – but we want to go wider. Here’s how:
We’ve set up our initial platform to get started towards this goal. It’s accessible for academics, practitioners and business stakeholders to use and discuss. Above all we want – and we all need – to develop and share tools to make commercial contracts that deliver the outcomes that people expect.
This was a guest post for the Juro blog by Margaret Hagan, Director of the Legal Design Lab at Stanford Law School's Center on the Legal Profession and Helena Haapio of Lexpert. Illustrations by Margaret Hagan - see these and more at the Legal Design Lab.