ContractStandards is a free reference resource that lawyers can use to get standardized contract and clause language, along with relevant research, case law, etc. As time went on, we started to sell our custom content management system we used to maintain our free resources as a solution for organizations managing large contract template libraries.
This is a brief look at problems we encountered in deploying the specialized CMS, our solutions, and user reception.
The Problem
When we started taking our initial solution to potential customers, a user could maintain two types of content: contracts and clauses. These types of content were not directly linked in the database. If the user wanted to use a clause in multiple contracts, they had to manually sync. It turned out that this was a common user need and proved too difficult to maintain for most users.
User edits the content of a contract as a single block of text. Keeping clauses consistent across the site was done manually.
The Solution
Users wanted a system that made it easier to integrate their clause and contract libraries. The new system we built treated contracts as outlines of a document to be made whole by syncing clauses with that skeletal structure. By properly syncing clauses with the contract outlines, users could create fully-formed, usable documents.
Conceptual sketch of relationship between synced clauses and contracts.
Early sketch of user path when updating a clause instance in a contract. User has option to propagate changes to all other instances of clause.
Later prototype of contract edit page. User can edit a clause directly on the page. Save is reflected in the contract being edited. User has options to determine how those changes will impact other contracts.
This new system offered a couple of benefits over the old:
Contracts were no longer static documents. The syncing mechanism we built meant that a change to an underlying clause would be automatically pushed to any synced contract.
Clause language was reusable. Different types of contracts often use the same “boilerplate” language. Ideally, lawyers have one snippet that works across all documents. Our platform allows that kind of reusability. If a user has some language already in their clause library, the system allows and encourages them to sync that language across many different contracts.
Greater insight into a user’s content. Our platform allows a user to see a clause’s synced agreements so they can better assess how clauses are being used.
User Reception
We went through several prototypes. The feedback on those prototypes hit on the following issues:
Hard to see how all clauses came together. Despite the benefits of a modular system, users still missed a way to edit a document as a whole. Early versions let the user see all of the clauses assembled together but the user had edit the clause record on a separate page in order to change text. This required a lot switching to new screens. In response, we built a contract editor that let you edit the clauses in your document. The layout preserved the modular feel but allowed for greater editing of the document as a whole. Users can make an edit in the contract editor and immediately publish that change to the underlying clause record.
Content too connected. As we made it easier to sync clauses across contracts and edit content in multiple places, users became concerned that they would change a clause in one contract and create problems in other contract. To address this problem, we borrowed from the world of computer programming. Users can now fork clause language. If a user makes a change to a clause in a contract that they think might negatively impact other contracts, they can simply fork that changed language and save it as a variant of the original text.
Conclusion
In developing this new platform, we solved the initial problem of syncing content libraries. Contracts and clauses are linked in a way that reflects how they are used in practice and makes it easier to manage large collections.
However, in solving one problem, we exposed another. Our next barrier to adoption inside organizations was cultural. Most lawyers are not used to a modular contracting approach. To adopt the system, a change in contracting culture is likely necessary. That is never an easy thing.
This is an iterative process and it is hard to say exactly how a feature or product will evolve. I suspect the challenges going forward will focus on integrating the platform into existing contracting cultures or finding ways to encourage changes in the culture.
