LawGeex is transforming legal operations.
Our artificial intelligence solution helps legal teams automate the review and approval of contracts. We make in-house legal work easy, efficient and impactful, allowing our customers to focus on the big picture instead of getting lost in the paperwork.
I’ve been working at LawGeex for more than 2 1/2 years. Below, I present a few brief case studies of some of the work I’ve been responsible for while being UX Director.
Case Study: Action Center v.1.5
I’ve been UX Director at LawGeex since very early on. Early-stage startups are different from established products and brands. The work is fast and always changing. When I came on board, we didn’t know who our customers would be, we didn’t have a clear product vision, and we didn’t know whether we would be B2B, B2C, or both. We didn’t know if we would serve small businesses or enterprises and we didn’t exactly know what headaches we were solving for our (potential) customers. We knew we had a great tool that could read a contract and identify which legal concepts were contained in each paragraph of dense legal language. Here is a short case study of how I approached the first version of the LawGeex report (now called the Action Center) before LawGeex changed focus to a business solution rather than a consumer product.
A Consumer Product
Early on, LawGeex was meant to provide general legal knowledge for consumers about their contracts. Simple contracts like employee agreements and NDAs were analyzed and each legal concept was ranked as common, uncommon, or missing. Common clauses were considered relatively benign whereas rare clauses and missing clauses were considered dangerous and should be read carefully or added as necessary.
My first responsibility was to redesign the “report” page where customers would view their contract with the LawGeex feedback.
What the User Wants
Before I began the redesign, we defined our user personas. With the help of the marketing department (AKA Laura) we interviewed small business owners, students, and recent graduates. We were focusing on providing value for those who were not lawyers but needed to review a contract they were asked to sign. For these non-lawyers, the main pain points we discovered were:
- Lack of legal knowledge – “I’m not a lawyer. How am I supposed to know if this is ok to sign?”
- No standard contract to learn from – “I get 10 NDAs from 10 different companies and they are all different. It is hard to recognize concepts from one contract to another.”
- Need to prioritize – “I am able to understand the language, but I don’t know what I should do first.” “I don’t know which of these problems require my attention most.”
Obviously, there were other issues we discovered. Small business owners didn’t want to have to pay a lawyer every time there was a relatively standard contract like an NDA to sign. Potential employees didn’t know what to do if their employment agreement was “risky” – could they negotiate? Renters wanted to know if we could provide information about rental contracts. But the business goals at the time were focused on addressing specific contract types and specific use cases.
Make it Easy
Aside from the usual task of “making it pretty,” I tried to focus the redesign on addressing some of the key pain points.
In order to help the user prioritize, we were already using red, orange, and green colors in the UI to signify priority, but they weren’t used consistently and they weren’t prominent enough. By doing informal user testing with the old design, I found that there was some low-hanging fruit I could fix just by tweaking the UI a bit.
Because the navigation wasn’t designed with clear enough distinctions between sections, I bumped the contrast of the sections and clearly defined each section label so it was clear what was important.
Some users said that because “uncommon” clauses were listed first because they were the most “risky,” they weren’t cognizant of the missing clauses so in order to make it clear that the document was missing important clauses, I added a notification at the top of the page, highly visible when the user first opens a contract.
In the previous version, issues were indicated by either a happy face or a sad face. These icons were too similar to each other and because they were unique to our UI and lacked a label, they required the user to learn a new pattern to understand their meaning. I changed the indicator icons to skeuomorphic sticky arrows reminiscent of the same sticky arrows lawyers use to show you where to sign. Finally, to create a visual connection between the clause in the contract and the LawGeex feedback for the clause, I repeated the indicator arrows in the feedback section.
Clarify Legal Concepts
The earlier versions of the UI displayed a lot of excellent legal content about each clause which was identified in the contract but presented it in a way which cause many users to feel overwhelmed. This feedback was presented in a fairly narrow bar on the right side of the document. This was necessary due to certain other constraints such as the requirement to present the document in full on the screen as well as the navigation at the same time (later on these constraints were dealt with in other ways). To make it easier to read and absorb the large amount of text, I separated each section and added some visual flourishes to break up the wall of text.
Many users didn’t understand how we categorised clauses as common or uncommon. The earlier design iteration just labeled the clause with the words but didn’t offer any explanation or visual cues. I added a visual indicator to show the rarity of the clause as well as some microcopy to explain what the number meant.
The process of redesigning the central product gave me a great opportunity to learn about the product’s capabilities as well as the way that users approached the task of reviewing their contracts. This introduction would help in guiding later redesigns and feature updates even though the user personas changed and the product evolved. Here’s what I learned from the first redesign:
- Contracts are visually complicated. They contain lots of formatted text with indents and titles and bulleted lists and numbering. This adds a lot of visual clutter to a screen. Being able to separate the informational layer from the contract is important to provide a clear visual hierarchy and distinction between the contract and the feedback.
- People generally read contracts from top to bottom. Even with the informal testing I did, it became clear that despite the ability to jump around the contract using the navigation, people like to read or scan the contract in order.
Making the law accessible to non-lawyers is challenging. Even though we can provide simple definitions and recommendations, it requires quite a lot of text to explain complex legal concepts to people who are not trained in the law. Furthermore, non-lawyers do not view contracts the same way that lawyers do. This became way more obvious when I did formal usability testing on later versions of the report but even at the early phases, when I showed the report to lawyers, they almost always focused first entirely on what was in the contract and only after noticed the feedback. Non-lawyers always viewed the feedback first and then read the contract to see what was going on.
More case studies coming soon…