Multiple Playbooks
Overview
Background
Playbooks are used in legal departments to keep track of how to approach different legal issues. They are a collection of knowledge to ensure that there is consistency in the department. DocJuris allowed users to upload their department's playbook so that it could be referenced while negotiating a contract in the application.
The original way playbooks were used in DocJuris was that there was only 1 playbook per contract. This worked initially for users because they could create monolithic playbooks that could hold every single position and clause that they had.
Problem
Having a single playbook for a contract was problem because:
It was too cumbersome to find specific issues
Other features were tied to a playbook and a user could not use those features separately
If a user applied the wrong playbook, the user would have to upload the contract again and select the correct playbook
Solution
The solution was to create a new way to use playbooks. We decided to allow a user to add more than 1 playbook. This meant that users could create smaller playbooks and attach or remove a playbook. This feature was both on the product roadmap for DocJuris and a popular customer request.
Research
Our user research was done by reaching out to the customers who had requested the feature. Al customer feedback was tracked using a +1 system to keep see how often a particular subject was brought up by our customers. In the customer interviews, it was surfaced that sometimes contracts start out as one thing but can also require a clause that is not found in that particular subject.
For example, if I had a Master Service Agreement (MSA) for a vendor I could apply an MSA playbook. That would work for the current state; however, if the contract included provisions for governing law that was outside of my state I would need to consult a different playbook. The multiple playbooks feature would allow a user to now add a Governing Law Playbook.
Planning
After research was completed, we had to plan out how to create multiple playbooks. The current state of playbooks put a lot of power and emphasis on adding the correct playbook. Below I outlined the current state of the 1 playbook method as opposed to the future state that we wanted the application to be.
Current State
1 playbook per contract
Monolithic Playbook
Forms - Standard Form attached to Playbook
Playbooks had to have a contract type associated with it
A playbook could not be removed from a contract
Future State
Multiple Playbooks per contract
Modular Playbooks
Forms - Standard Form separated from a Playbook
Playbooks have no contract type
Each playbook could be added or removed from a contract
Playbooks
Multiple Playbooks
The process of changing from 1 playbook to multiple playbooks started at the beginning of our user flow, when a user uploaded the contract. The current state had the user selecting a playbook that would be forever attached to the contract. The only way to change playbooks for the user was to reupload the contract and choose a different playbook. Among the many drawbacks to this method, the user could no longer see the information from another playbook.
We decided to no longer have the user choose a playbook during upload. This streamlined the process for the user to open the contract faster. We also found during discussions with customers that sometimes they did not know what type of playbook they needed until they read over the contract. This helped to validate our decision to move playbook selection to after the contract was opened in the system.
Modular Playbooks
The next discussion dealt with how users currently use playbooks and how that behavior would change with multiple playbooks. Currently, users had monolithic playbooks that contained every clause and scenario that a user would use in any contract regardless of type of contract. The ability to add and remove playbooks at will meant that we could take a modular approach to playbooks. Users could now make smaller playbooks that addressed specific issues. This meant that we needed to retrain users on how to create playbooks. This also meant that users need to alter those monolithic playbooks. However, if a user wanted to keep using the playbooks the way that they had been, nothing was preventing that. To help users create smaller playbooks, we redesigned how a user could edit a playbook. Issues in a playbook could now be copied to another playbook. This function was not previously available.
I designed the new way to manage playbooks in Figma.
Forms
Another major change to the application due to multiple playbooks was how we handled forms. Previously, forms were attached to playbooks. For a contract to use a form, the correct playbook had to be attached. This was an issue with monolithic playbooks because only one form could be attached at a time. Another issue was that we expanded the types of forms that we had in the system.
Types of Forms
Standard - Boilerplate Contract
Amendment - Template used to create an amendment from redlines
Exception Table - Template used to create an exception table from redlines
In order to separate out forms from playbooks, we created a new section in the dashboard. Also, to help users better understand how they could use these forms we changed the name of the section from "Forms" to "Templates." Now users would be able to select whichever template needed for a contract and not have to worry about what playbook was attached.
For the design I created images and text to explain the different templates that a user could upload and use.
The design for the Templates page in the dashboard used the existing patterns from the other pages. We added a button so that users could draft a contract from a Contract Type Template (formerly Standard Form). This was an existing feature that was not very prominent in the current design of the application. The function was buried in another function of playbooks.
Conclusion
The creation of the multiple playbooks feature resulted in an overhaul of the majority of the application. It took approximately 2 months to design the new feature and the launch occurred a few months after the end of design. We had several major companies buy our service as a direct result of the new feature. It also led to customers renewing their service.