Arbitrus.ai is a private court system with an AI judge. While the public court system or AAA arbitration are expensive and time consuming, Arbitrus helps users settle disputes faster, cheaper and with more consideration.
THE PROBLEM
I was tasked with designing, from scratch, the concept for an AI powered arbitrator. This product needed to pace the user's tasks throughout the arbitration process, while also considering all of the details of the claim to determine a fair, infomed decision for both parties involved.
THE GOAL
Generate a tool to accelerate and enhance the arbitration procecss. Keep the interface concise while remaining accessible.
ROLES
Mary Pyrdol - Sole UX/UI designer and researcher.
RESPONSIBILITIES
Competitve analysis, wireframing, prototyping,
unify branding, and advertising materials.
PROJECT DURATION
October 2024 - January 2025
On top of UI/UX design, I also enjoy creating animations to bring to life the important features of a product. Here's an animation I made in Adobe After Effects, describing the benefits and overall catalyzation of the arbitration process via Arbitrus.ai.
SUMMARY
In preparation for the success of Arbitrus, I conducted a competitive audit on American Arbitration Association (AAA) to see what has already been done to help users in terms of automating the arbitration process.
I found that AAA provides resources for connecting with human arbitrators online, but no where do they have a tool where users can get straight to arbitration in general. Users are required to apply for an arbitration and wait for a response which could take anywhere between days to months. This provided me with insight on the lack of AI involved in current digitization of legal resources, and that our team had a lot of leeway with what and how we wanted to trailblaze.
In my analysis of AAA, I did take into consideration of where they organized forms and contracts for users, as well as providing users with a list of tasks they must complete in thier application form. I figured we would want to provide the users with enough instructions within each step without overwhelming them. Nesting these sub-lists of instructions into individual pages of the process was the best adaptation we had for this.
Give the user context as to what stage of arbitration they are on, what steps come next, and how much time they have to complete necessary tasks.
Front and center, this notification section will consistently populate with instructions for the user and when they are to be completed by.
At the Hearing stage of arbitration, the AI model will take place, asking the users specific questions about their case to consider for the decision of the dispute.
For mapping out the user flow, I reviewed the steps of the arbitration process with my boss (a Harvard law student) to then configure the entry and exit points of the projected user flow.
User Flow Map
There were many features and functions we wanted to include on the initial screen of Arbitrus. I tested the idea of distinguishing the different actions into their own windows, but the screen quickly became crowded.
I then transformed the mini windows into tabs, trying to better manage the screen space.
Early Concept DesignsThe biggest issue we addresses in our Lo-Fi's was utilizing screen space more efficiently. Different from our early concepts, I managed to organize the steps of the arbitration process onto different screens. The user would advance to the next step as soon as the current step was completed, etc.
Low-Fidelity Prototype
From there, we were able to organize the different tasks to their respective stages (i.e., uploading evidence on the "Discovery" page, inputing responses on the "Hearing" page). This saved us a lot of screen space in the Hi-Fi prototype. I solidified this structure with the use of a timeline/breadcrumbs at the top center of the screen.
After some moderated usability testing for pain points, I managed to simplify the display by creating a smaller, more central task manager. I also removed the large AI profile icon because it became less and less necessary as we tested the flow of the arbitrator, and took up a ton of screen space.
High-Fidelity Prototype
In addition to the central task manager, one of the most useful updates was the use of tabs on the left-hand side of the screen. The tabs function as drawers and slide out to the right to reveal its contents, creating more breathing room and organizing all the necessary arbitration information for the user.
Once I had addressed our more pressing concerns about the lo-fi designs, it was clear that the main improvement in the hi-fi designs was avoiding overwhelming the user. It was clear that we needed all of the inital components from the early concept designs, however we could not afford the components to be in such close proximity to one another.
Most of this change was catalyzed by testing out our color palette. There are certain areas that need the right level of contrast, and that helped us determine what essential functions should be centralized. With the central task manager and side tabs, the flow became much easier to visualize.
WHAT I LEARNED
From this project, I From this project, I gained a better sense of utilizing space across the screen. I learned a lot about Figma's component creation capabilities when I designed the tab drawers on the left-hand side of the screen, discovering that there is more "canvas" space than just the screen's dimensions. Overlays and tabs are capable of storing information that does not need to be displayed constantly to the user while they complete more essential tasks.
I also gathered useful insight between lo-fi and hi-fi prototypes when implementing the color palette for the first time. Different shades of purple in Arbitrus' branding have different contrast capabilities than the different shades of gray in lo-fi prototyping, especially when it comes down to action buttons versus static (but changing) components.