Last month I had the opportunity to chat about legal design at an event co-organized by Helsinki Legal Hackers, IACCM Finland, and PMAF Contract Management SIG. Since I don’t like to share slides without context, I thought I’d rather write a summary of the key ideas of my talk. Enjoy!

How come a designer is interested in contracts?

The simple and candid answer would be: in 2010 I met proactive law and contract pioneer Helena Haapio, and her passion to make contracts better and simpler was just contagious.

The longer answer would be: as an information designer, my job is to solve complex communication problems. Contracts seemed to be a genre of documents in dire need of a user-centric makeover. We can pick any contract, and, at a glance, they just look and feel and read the same. This, from a design point of view makes no sense: why so much sameness in different documents for different users with different needs and skills, produced by different organizations to regulate different transactions with different goals? At best, we are foregoing the opportunity to create a meaningful touchpoint and build positive relationships and experiences with suppliers and clients. At worse, we are leaking economic and relational value!

Isn’t design inefficient too?

Given the amount of dysfunctional, bamboozling, dense, and boring legal-bureaucratic documents out there, it is still a surprise to me that there aren’t more designers collaborating with lawyers, governments, and businesses. In the last couple of years, we saw the emergence of the “legal design” movement and I thought my colleagues would finally join the good fight. But most “legal designers” seem to be lawyers who eagerly embraced design thinking, service design, and user-centered methodologies to challenge the status quo – not designers!

On the other hand, developers, engineers, computer scientists, and “legal geeks” have set their eyes on solving some of the problems of the legal field. Contracts, in their current form, do not make sense for a techie either: they are complex, costly and slow to produce, they are inefficiently created, edited, signed, managed, monitored…

The promise of technology is to end the “bullshit jobs” (or bullshit tasks) that lawyers still have to do. Why doing slow and messy rounds of revision when we can draft and revise collaboratively online? Why having paper documents and scribbled signatures at all? Why having messy archives when we can store contracts digitally and even set up notifications to help us manage their provisions? Why not using analytics on databases of contracts to develop best practices? Why not standardizing clauses and make them machine-readable, instead of having a million different versions of the same provision? Why not creating self-enforcing smart contracts whenever it’s possible?

But as a designer, the marriage of tech and legal raises two fears:

1. What if technology adds its own flavor of complexity to legal? I always think about the dawn of personal computing as a cautionary tale. It well illustrates why we need designers in the mix. The first personal computers worked just fine, technically, but users did not understand them, and could not use them properly. “Users are stupid” engineers would say, because from their perspective the computers were just fine: people just needed to learn how to use them. But who would fork out thousands of dollars for something they couldn’t use and made them feel inadequate? For regular joes to finally adopt the personal computer, we had to bring in psychologists and designers to understand the “flawed” users and ensure that products would be designed to adapt to them, not vice-versa. The whole new discipline of human-computer interaction was born. Back to the present: we have to learn from history, and avoid repeating the same mistakes. We need experts of human-centered design in the mix, from day one, to avoid building solutions that make sense only to lawyers-coders and engineers.
2. What if technology means the end of bullshit tasks only for lawyers? What if we simply automate dysfunctional processes and the result is just to create more dysfunctional documents faster and cheaper? We have to avoid the garbage in – garbage out problem: how “intelligent” is a legal AI that learns from existing crummy documents and spews out new crummy documents (just very fast, and by itself)? The revolution will be a paltry one if it won’t be perceived also by the end users – business, citizens, consumers, lawyers’ clients, and all other non-lawyers who are somewhat affected by what legal practitioners and systems do. We can’t be content with improving production tools and methods – the end result must look and feel and function dramatically better.

So, yes, we need designers.  Because it’s a designer’s job to fiercely take the side of the end users in a world of machines and lawyers and ensure that whatever new system we are building or “disrupting” actually improves people’s lives. We cannot cop out from this responsibility.

How do we get the best of tech and design?

The good news is that tech and design have successfully collaborated in the past to deliver meaningful, usable, delightful solutions. So, when we think about contracts, where could we start?

[Disclosure: With my co-authors Tom Barton, Helena Haapio and Jim Hazard, we are currently exploring this question in a forthcoming book chap. Some of the ideas below are a loose summary of this more academic work-in-progress]

A good first step is to challenge the implicit assumption that contracts are “documents written by lawyers for lawyers”: when you are willing to change this paradigm, you can start doing things differently.

When digital technologies enter the picture, we are not married anymore to paper or digital paper (read: PDF or Word files). While these media will still survive, for the time being, we can start focusing on what really matters: the information that constitutes contracts. Focusing on information quality, and only then on the specific technology to manage and deliver such information, may offer a way forward in the debate about whether and most importantly how we “want new technologies to sweep away traditional contracting, so we can have faster, more efficient, and more cost-effective contracting” (this is the so-called Cummins/Adams debate, and you can read here Tim’s and Ken’s perspectives).

If contract information is digitized, then we can start rethinking how to display and communicate it in different ways so that the content is always context-relevant and user-centered. We are not married to pure text anymore. We can supplement text with layers of explanatory diagrams, examples, plain language translations, videos etc. We can use information layering strategies, and implement the information-seeking principle of “overview first, then details on demand” to help readers avoid cognitive overload (admit it: not all contract users need ALL the information at ALL time. What they need is task/problem-specific information that can be readily translated into decisions and actions). We could even switch between these different versions of the same content and make use of various “problem representations” to improve our understanding and clear away any doubt about what we are required to do. We could finally have “wise contracts” which are simple at the front, but smart – from a legal and technological perspective – at the back.

To build wise contracts and a wise contracting environment we need the standardization and scalability that technology offers. They cannot be attained through the manual work of copy-and-paste-monkeys. But paradoxically, the more we push forward with technology, the more we need to double-down on human factors. We need multidisciplinary teams of experts to build contracting systems or templates that are good for business, legally sound, technically smart, and human-friendly. And human users are not going anywhere. The name “smart contracts” is somewhat misleading, and if you think the implementation of every contract obligation in every type of contract can be magically delegated to computers, well, think again. Perhaps the name “smart clauses” would be more meaningful, because these self-enforcing provisions live along with other human-implementable provisions, in the same contract. They are not the whole contract. And in case a contract needs to be litigated, more human users enter the picture (litigating lawyers, judges, etc.). So, while making contracts and clauses machine-readable is a necessary step towards standardization, automation, and efficiency, by no means this alone solves the old problem of “human-readability”. In fact, if we are not careful, it could make it even worse by adding an extra layer of complexity (in the form of user flows and experiences that make sense only to hard-core legal geeks) and jargon (in the form of code).

A wider definition of contract design?

In the future, if contracts will no longer be “documents written by lawyers for lawyers”, simply equating “contract design” with “contract drafting” won’t do: choosing the right provisions and writing them clearly, concisely, and precisely will still be a key ingredient of wise contracts, but not the only one. The influence of technology and design affect the concept of “contract design” by demanding a more comprehensive definition of what it is to be designed: not only the content, but also how it is effectively presented and communicated. And not only comprehensible and functional contract documents (which enable transactions, build trust and facilitate internal governance), but also the right tools and resources to create them efficiently – without acritical copy-paste.