Quill
Rocket Lawyer Document Authoring Tool
Product Context
What is Quill?
Quill is tool for the authorship and management of document templates.
What does Quill do?
Allows RL attorneys (A.K.A. “Quill Artists”) to build interviews and documents on the web
Enables side-by-side visual formatting of the interview and the document
Manage our library of document content
In the process of transforming old code base to new code base
What Do customers see?
Quill is an internal facing tool that powers our document templates. Once the template is pushed to production, customers who start their document see interview questions and a preview of their document which automatically updates as they fill in answers.
Project Requirements for math feature
Overview
Rocket lawyer has three separate document platforms the US platform, UK platform, and Quill, the global platform. While the overarching goal is to parody the all the functions in the US and UK platforms, the business MVP for building the Math feature is primarily supporting the UK platform’s migration to the global platform.
Feature Requirements
Create feature that allows Quill artists to create math variables that can be applied to the document so that it is visible to the customer.
Must work with “cyclical” and “non-cyclical” components
Must work with rules
Must be able to perform functions like SUM and ROUND
Must be able to apply percentages (discounts)
Reference requirements: Math UK needs analysis , Functionality required for the UK Migration
Challenges
No product manager
I joined this team after the product manager left Rocket Lawyer. In order to keep the momentum going on the project, I was tasked with sharing the responsibility of product manager between myself, an engineer and a QA.
Lacked proper development resources
The team lost some key developer resources due to management decisions. While this change in personnel didn’t direct impact on the design process, it had an impact on overall team moral and affected decision making.
Communication between international teams caused friction
Working with the international team to communicate about feature requirements made it more difficult to gain alignment on requirements and solutions. It also slowed down the design review process.
Functionality between multiple platforms slightly different
The terminology used to describe desired functions sometimes differed between the US and UK platforms. In order to deal with this challenge we demoed feature functions to each other to better understand expectations and needs in order to align on goals.
Understanding USe CASES
Understanding Document Author Perspective
In order to inform the design of the math feature, I talked with our team’s attorneys and document authors to become more familiar with their process of creating math equations in legal documents, as well as learning about different legal documents that required math components.
Understanding technical constraints
I spent time talking with engineers in both the UK office and the US office to understand the technical constraints each platform faced as well as required desired outcomes. The new math feature would also have to work with the existing features available on Quill, mainly dealing with “rules” and “cyclicals” (repeated components).
This sketch illustrates the concept of cyclicals the desired outcome seen by a customer, compared to the components in Quill. Many conversations between myself, engineers, and document authors took place in this format to clarify technical concepts.
Defining design goals
Create a system that is flexible enough to accomodate math needs while being simple and intuitive for Quill artists
Design a MVP for math applied to the boilerplate that will cover most needs for the UK migration
Consider how numeric fields interact with each other when inside and outside of a cyclical
User flows
Above is a user journey that illustrates the path of a Quill Artist as they create a new document with the math tool. The last row illustrates in detail how a Quill Artist might create a specific equation as well as illustrates the phases that the design components would be built. I chose this particular equation because it deals with multiple components that are working together. It’s also a simply illustrated math equation.
Design Phase
Early Versions
See full design in this InVision Prototype
The earliest version of the math design has one modal where the quill artist begins by clicking “Build math” to create an equation, once that equation is complete the modal prompts you to apply the equation.
PROS
Modal design allows user to reference document & interview easily
Math equation builder is extremely flexible
Tradeoffs
Equations are built one by one
View all equations are available in a separate action
Engineering identified build/scalability road block
Prototype User Testing
Test parameters
Used usertesting.com “myrecruit” function
Users were given simple sum prototype
About Users
3 quill users completed the test
1 quill user did the test but did not complete
2 quill users confused by the prototype tasks
Results
Able to understand equation math builder
Needed some clarification to define function (fx) SUM usage
Confusion over how to follow tasks and limited abilities of prototype overshadowed test reliability
Final Design
View Figma prototype Final Design
Pros
Leverages existing familiar pattern adopted from page creation structure
Solves for the separate view all equation lists
More scaleable without adding complex functionality on CK Editor
Cons
Panel hides question interview fields
Math Validation Flow
Validating User Error
This diagram shows a quill artist’s experience when creating erroneous equations. Purpose of validation is to ensure templates do not become corrupt. A quill artist is responsible for setting up the logic of their document template. Design is responsible for notifying the quill artist when they’ve made a mistake in the system they are trying to create.
Math Validation Final Design
While I explored a few options for applying, editing, and deleting equations decisions on design direction were ultimately informed by a simple moderated user test with one of the UK document authors. I sat with her and observed her as she used the prototype to see if the validation errors made sense to her.