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. 

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.

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.

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.

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.

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.

Product Blog Post