Liquid is a is a web app that helps businesses manage contracts and invoices for independent contractors. I worked alongside a team of designers to create a contract editor and a more robust contract management system for the company. 
The app originally had no way to edit contracts once they were uploaded to the site and that was a big problem and inconvenience for users. Through our design process, we sought to make it easier for users to manage and change the contracts that they used in their hiring process.
My Role: UX Designer
Duration: 3 weeks, August 2020
Tools: Figma, Whimsical, Asana
Key Skills: User Research, Competitive Research, Wireframing, Prototyping, Usability Testing
User Interviews
In order to get a better idea of the users we were designing for, we conducted a series of user interviews. We mainly interviewed small business owners who had experiences hiring contractors as they made up a good portion of our target audience. We wanted to know more about their experiences hiring independent contractors and how they managed contracts for them.
What we found was that:
1. Most people who hire independent contractors complete the contracts and paperwork over email.
2. Small business owners don't update their contracts often.
3. Many small business owners find using an additional program such as DocuSign to help with contracts is too cumbersome and expensive.
We made sure to keep these findings in mind as we moved forward through the design process as we wanted to make sure that we were designing a product that would help our users. One of the key takeaways was that current systems were too cumbersome and many users felt that they were unnecessary. As we developed our design solution, we sought to find ways to solve to these problems.
Competitive and Comparative Analysis
In addition to interviews, we also researched Liquid's competitors in both the document editor and contract management space. We tried to find features that these other products were using that would greatly benefit Liquid's current users. The research that we gained from this process greatly influenced what features we decided to add to our final design.

Contract Editors and Contract Management Systems

After gathering research on our users, we developed two different personas to get a better idea of what types of users we were designing for.
Rowan is a CEO at a smaller startup who is rapidly hiring more contractors for their company. They needed a way to manage all of the people they were hiring as well as an easy way to handle and create contracts and invoices for them.
Peyton is an administrative assistant at a big company who manages contracts for their workers. She is in charge of editing the contracts and getting the contractors hired and onboarded into the company. She needs to use the contract editor for contract negotiation and adding addendums.
We made sure to always be thinking about these personas as well as what they would need and want as we continued to develop our design.
User and Task Flows
We created user and task flows to map out Liquid's current process for sending contracts to contractors and getting them signed. Through this process, we were able to map out how we wanted to rearrange these flows and how our design might be able to improve them. Our team added a section into the flow about using the contract editor as being able to use this feature would vastly improve our users' experiences.

User Flow (Current Site)

User Flow (Rowan)

User Flow (Peyton)

Journey Maps
We also mapped out our two persona's feelings as they went through Liquid's process on journey maps to get a better sense of their pain points if they attempted to use Liquid in its existing state. Most of the pain points happened after they selected the contract that they wanted to use and attempted to edit and view it. We made sure to consider these pain points as we developed the contract editor for our users.
Low-Fidelity Sketches
After gathering a lot of data on our users and coming up with ideas about where we wanted to start our solution, we created sketches to better visualize how our editor might look.


Mid-Fidelity Wireframes
We then used these sketches to develop a mid-fidelity wireframe in Figma. Liquid already had a very extensive design system so we made sure that we fully utilized it to make sure that our design would fit into Liquid's current app. We wanted to make sure that we were designing a feature that Liquid could potentially incorporate into their app if it worked out well.
Our mid-fidelity wireframe focused mostly on the contract editor. We went through multiple ideas about how to incorporate information fields that people would be using with the contracts. Ultimately, we decided to go with a dropdown menu idea this phase.
Prototyping and Usability Testing
After we finished developing our wireframes, we then moved on to prototyping where we created a fully clickable prototype that users could navigate through.
We tested this prototype on users to see what issues they had with our current design iteration. What we found was that:
1. Users were confused by the 3 levels of headers and that mass amount of information and buttons that were presented to them.
2. Users didn't intuitively know how to add information fields into their document through the dropdown we created.
3. Many users were used to other programs where they could drag and drop information fields into their contracts.
This feedback was extremely helpful to us and we made sure to fully utilize it when developing our final prototype.

Prototyping in Figma

Final Design
High-Fidelity Prototype
After implementing changes from user feedback, we created our high-fidelity prototype. We focused on two main sections with this prototype: the contract editor and the contract management system.
1. Contract Editor Fields
Through our user testing, we found that users may like to insert information fields into their documents in multiple ways. Because of this, we created 3 ways to insert fields into the document. The first way is to highlight a section and use the dropdown menu to replace it with a field. The second way is to highlight a section and use a button that pops up along with the comment button on the right side to add them. Finally, the third way is to utilize a drag and drop menu on the right hand side to directly insert the fields into the document.
We found that implementing these different ways to add fields helped users who were more familiar with different types of software use this system.

Adding Fields to the Contract (High-Fidelity)

2. Contract Editor Comments
Commenting was added into the editor as a way to manage internal collaboration on contracts and to allow for suggestions from the contractor. Highlighting a section of the document brings up an option to comment on the right hand side.

Adding Comments to the Contract (High-Fidelity)

3. Contract Management System
Because companies may have hundreds of different contracts for their many workers, we felt that it was necessary to design a way for them to manage them. We created a way to allow users to make templates, use Liquid's preexisting contracts, and sort their contracts into groups to organize them.

Contract Management System (High-Fidelity)

4. Vendor View
After a contract is sent to the vendor or contractor, they are able to use a limited amount of editing tools when they are filling out the requested information. They also are able to comment and add suggestions which helps in contract negotiation.

Vendor's Contract View (High-Fidelity)

Journey Map After Redesign
After designing the contract editor and management system, we felt that we had addressed our user's pain points in a big way. Most of their frustrations with not being in control and being able to edit their documents went away with the features that we added to the process.
Next Steps
Because we only had a limited amount of time to complete this project, we would've liked to go through a few more rounds of iteration and usability testing if we had more time. In addition, we would've liked to be able to build out more functionality within the contract management side of things. Ideally, once we were satisfied with the features that we designed, we would pass them off to developers to have them implemented into the site.
Back to Top