header-img-rl-authoring-tool.png

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.

  1. Must work with “cyclical” and “non-cyclical” components

  2. Must work with rules

  3. Must be able to perform functions like SUM and ROUND

  4. Must be able to apply percentages (discounts)

    Reference requirements: Math UK needs analysis , Functionality required for the UK Migration

Challenges

  1. 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.

  2. 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.

  3. 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.

  4. 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.

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

  1. Create a system that is flexible enough to accomodate math needs while being simple and intuitive for Quill artists

  2. Design a MVP for math applied to the boilerplate that will cover most needs for the UK migration

  3. 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

Math Validation Flow

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.


 
Screen Shot 2019-02-08 at 5.17.25 PM.png

Math Validation Final Design

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.