Writing contracts can be very time consuming for lawyers. Files are stored in unorganized repositories, which makes referencing templates and other resources difficult. My team wanted to tackle this problem by designing a tool that legal teams can use to standardize their contracting language and improve future negotiations.

Position Board is a web app that streamlines the contract writing process and captures user data for analytics. The main purpose is to save lawyers valuable time and reduce risk for the company.

Defining the Problem

Knowable is an enterprise-contract software company located in Seattle, WA that I worked with on the Position Board project. After meeting their team, I was briefly introduced to their mission and details of the project. Basically, lawyers need a better way to get on the same page about using standard contract language at their company.

I didn't had any experience with contracts or legal documents before, so I was immediately confused and overwhelmed. The next few days had been dedicated to filling in gaps with my knowledge and familiarizing myself with their platform. I wanted to understand the user, gain domain knowledge, and research the problem - in order to design a solution. It was clear to me that building software for an enterprise SaaS company required input from users and internal stakeholders alike.

Interviewing Lawyers

My research came primarily from interviewing lawyers from Knowable and other external companies. After pulling important quotes/ideas from each interview, I used an affinity map exercise to organize my findings in key insights. I learned more about writing basic contracts and the tools they currently use. I also learned that most contracts have standard elements to ensure that they cover all the necessary risks, obligations and entitlements.

Contracts are typically the same with each negotiation, and lawyers will pull language from previous work to incorporate into the current document.

Affinity Map Exercise

Here’s what I found:
• Users do not have a single source of reference for company policies to minimize risk and increase compliance.
• Users don’t organize their documents properly and their paperwork are tucked away in emails, which wastes valuable time and effort to find them.
• Users rely on resources from their colleagues, or they might not be using one at all.

My takeaway from the research was to start addressing a method to display reference data and allow users to manage company-wide legal policy.

Identifying User Needs

With my research, I was able to think more deeply about defining the end user and their needs. I created a persona (Stephen) based off of the user interviews whom embodies the lawyers I spoke to and their contract writing process. Stephen is very busy lawyer that wants to prioritize his time. He'd rather be negotiating with the counter-party than searching for mismatched files on his laptop.

Aside from lawyers, I learned that there was a need for other parties like paralegals and senior partners to reference contract data. Their usage for Position Board would be slightly different, but this had introduced the idea of an admin vs. standard user.

In addition, I investigated competitors to learn more about how legal teams use contract analysis software. I found was that there are three main roles that the competitors fell into: Data Analysis, Document Storage, and Contract Creation.

Many of the competitors fulfilled 2 or more roles with either their main product or a combination of their side products. My main takeaway was there isn't a central tool on the market that helps users reference analytics taken on a company-wide scale.

Competitive Feature Analysis
User Persona (Stephen) - Lawyer

Brainstorming Ideas

I conducted a design studio with my teammates in order to to sketch and brainstorm ideas, while identifying features that should be incorporated. Using the knowledge I gained from the research, I knew that the layout of the contract structure should be broken down and visualized for users to quickly find what they need.

Contract Structure:
All contracts have the same basic structure as outlined. Each following topic is nested within the previous topic (ex. positions are found within subsections)

1) Templates: The entire document of the legal contract
2) Section: Key groups within a contract that defines a broad contract topic
3) Subsection: Groups with a section that defines a specific contract term
4) Position: The meaning or intent of language within a subsection

From there, I began to map out a user flow to plan out wireframes where the user utilizes Position Board to help them write a contract. The user should be able to search keywords within topics, document positions for analytics, and find positions to use for any situation. With Position Board, I wanted to allow users to capture performance data for the company and reference a single-point of truth.

Design Studio Sketch
User Flow

Final Designs

Using the design system provided by Knowable, I created a high-fidelity prototype to deliver to the client and stakeholders. The focus was on user research and I made use of their existing design guidelines to create the UI. With the insight I gained, I designed a two-panel workspace to view a full breakdown of the contract template and approved language by the company. 

With Position Board, legal teams now have access to organized company data and useful tools to write contracts with.

Design Breakdown

Contract breakdown contains each section, subsection, and position where users can select one and narrow their search.

Once clicked, the select topic will highlight yellow and the dashboard will update with its corresponding lower-level topics. Users will also be able to filter “potential non-standard” or high risk topics (pink label) that are reported to change often by other users.

Allowing lawyers to see which topics are related can help them explore and discover language they might want to use in their contracts. A visualized data breakdown can also help users outside the legal department find the information they need.

Workspace contains each selected topic and additional information to assist the user. This information includes: standard language, contract structure, and notes from other lawyers.

With standardized language, users can copy and paste this text directly into the contract that they’re writing in another application. Contract structure allows users to backtrack their search and find related topics. Notes from other lawyers help users understand why a topic was changed in previous negotiations, and other considerations that can help them in their current work.

Lawyers are often referencing multiple documents so organized information is beneficial to improve time-management and quality of work for users.

As part of the analytics, users can “record positions” that the system uses to percentages of times used and which positions are used the most. This info will inform future negotiations and save lawyers time/effort that they might have wasted in order to backtrack their old files.

Contract Breakdown - Hi Fi Wireframe
Workspace - Hi Fi Wireframe

Testing the Design

After completing 3 rounds of usability testing with internal and external company lawyers, I was able to iterate the design based on user feedback. The majority of the update was changing components of the UI to improve usability (i.e. consistency of color and typography, risk indication status, etc). 

In addition, an important iteration was allowing the workspace to expand to display more content. This was due to a concern from testers who informed me that contracts can be very lengthy (20+ pages long) and they needed better usage of screen real-estate to see and read the document.

Expanded Workspace


At the end of our design sprint, my team and I presented to Knowable with a slide deck and final prototype. We were met with positive reviews! Not only was the product intuitive, but their legal team expressed that it would greatly improve their workflow. If I was able to work on this project longer, I would also defined success for this product as having high user adoption (unique users and page views) in client organizations.

I had a few recommendations for Position Board that were supported by the research, but were declined by the stakeholders due to external factors such as engineering constraints and business guidelines.


• Lawyers like to see the full contract draft and versioning process to be able to track how unique positions were arrived at and to learn about the thought process behind the decisions. Notes might be unreliable and lack full coverage.

• Changing the company keyword “concept” and “subconcept” because research indicated that section/subsection relates better to lawyers. Further research may be required to identify the terminology that would best fit.


My next steps would be to continue usability testing and building out the “search” feature of the contract breakdown. I would reach out to Knowable’s UX team again to learn about their company’s testing procedures.

Position Board is an aspirational project for Knowable’s 2021 Q1 engineering sprints. I learned a lot about how design and business goals intersect, as well as working with enterprise software and cross-functional teams. I gained valuable domain knowledge on contracts and the legal world, as well as how to quickly overcome that obstacle. Not only was it important for me to design based on my own research, it was also vital to learn how to work with the company’s existing framework. I hope to be able to continue playing well-rounded roles as a designer on future projects.

Let’s connect! 🌿
Website Built and Designed by Tim Pham.