My Kleros Fellowship Experience as a Digital Product Designer
My foray into the world of “B-law-ckchain” as a digital product designer (UX/UI/IX Design)
How I found this opportunity called the Kleros Fellowship:
November 2018, I was scrolling through my Twitter newsfeed and given my sheer love for the blockchain space, I happened upon this post by one of the companies I was following called Kleros:
Now, I’m a digital product designer and despite not seeing a track for design, I still ambitiously decided to reach out to them anyway. I initially applied to the Cryptoeconomics track given its close proximity to the design discipline, however there wasn’t a fit for it. After a couple conversations however, they determined that they’d create a new track for me so that I can focus on digital product design (UX/UI Design/Research).
Why I chose this problem space of blockchain & law:
Why I chose to work with Kleros is because it was a great opportunity for me to learn and contribute more as a blockchain-focused product designer who’s passionate about social impact.
What’s incredible about all of this is that prior to encountering Kleros, I had no interest in law. Despite being told that I should become a lawyer when I was young (due to how much I loved to argue, I guess), I still had no interest in law growing up.
As I got older though, I realized one simple thing for myself as a designer — creating everlasting positive systemic change is the endgame for me and so, as long as I can achieve it through a scalable piece of technology and sustainable business solution, that’s all I care about.
Therefore, if it meant diving deep into a world that I never used to care about as much, then I would. I can now honestly say — legaltech and legal-design are worlds that I’m incredibly fascinated with.
Legaltech innovation aims to revolutionize the legal industry, which has typically been considered conservative and resistant to change. New ideas, products, and concepts being developed in the field are trying to simplify complex law processes and generate more affordable and engaging solutions for end users.
Design represents a fundamental tool for promoting the changes that will benefit both lawyers, legal departments and individual consumers. By taking a design-driven approach to problem-solving, the legal system can be innovated in ways that were unimaginable in the past.
Kleros uses blockchain technology to rethink the justice system and propose solutions that can cause a positive impact on people’s lives. Decentralized applications (dApps) can help us propose a more efficient legal process by automating the enforcement of rulings through smart contracts, effectively reducing cost and increasing transparency.
Excerpt from: Kleros. “ Dispute Revolution — The Kleros Handbook of Decentralized Justice.” Apple Books.
What is this challenge that Kleros is tackling?
Kleros exists because they wish to answer the following overarching question: how to design a system that produces true decisions at the lowest possible cost and in the shortest amount of time?
Given blockchain’s promise to truly democratize the internet as a whole, the founders of Kleros dug deep into he Grecian legal system. The concept and etymology of Kleros and its core features was born from the following:
The Athenians had trials, which were conducted by a large body of ordinary citizens. On trial days, citizens wishing to serve as jurors went to the courthouse where a sophisticated jury selection procedure took place.
Each citizen inserted his pinakion (a bronze or wood ID token) into a slot of an allotment machine called kleroterion. After all citizens had inserted their pinakia, an official threw white and black icosahedron (20 faces) dice in a tube affixed vertically on a side of the kleroterion. The tube stopped at the bottom and held the dice in the random order in which they entered. Dice were then released one at a time. Candidates having a black dice on their row were dismissed for the day. Candidates with a white dice were drawn for paid jury duty (Boegehold 1995).
About 25 centuries ago, Athenians knew that courts could work as a peer-to-peer system without turning into mob justice, provided three conditions were met: jury duty was voluntary; jury duty was paid; jury selection was done by sortition (kleros).
Greek popular courts had no continuing existence or permanent personnel. They were decentralized organizations where jurors and officers changed from day to day following predefined rules[…]”
Excerpt From: Kleros. “ Dispute Revolution — The Kleros Handbook of Decentralized Justice.” Apple Books.
These core features are therefore:
- a native token called “Pinakion” (abbreviated as PNK);
- a voluntary P2P system of jurors and plaintiff vs. defendant without a judge; and
- a randomized jury selection process based off of the “Kleroterion”, which of course is the source of inspiration for the name “Kleros” altogether.
From this overarching question, they came up with the following overarching goals for Kleros as a whole — to build an optimal cryptoeconomic model for user engagement that is:
- Efficient — does it incentivize users to arbitrate cases privately?
- Effective — does it incentivize users to to arbitrate cases commutatively?
- Ethical — does it incentivize users to to arbitrate cases impartially?
Kleros is hoping to address the following macro-challenge:
Ultimately, they hope to positively affect change in this area as well:
Product Timeline (inclusive dates): 4 months (Sept. to Dec. 2018)
Product Platforms: Mobile and Web
Product Type: Social Venture Tech Startup
Product Status: Early-Stage & Bootstrapping
Product Background: www.Kleros.io
During the beginning of this project, I was provided with much ambiguity, given that I was simply tasked to “improve the UX” of the following product:
Kleros Court AKA the Athena release, which is an online portal that allows users to join as a juror and to be randomly selected to adjudicate disputes in various subcourts.
After spending a considerable amount of time researching the problem space some more, I came up with the following goals, to drastically & dramatically improve:
- The Onboarding process
- The Court Selection & Staking process
- The Case Arbitration or Dispute Resolution process
And by “drastically” and “dramatically”, I mean for each of these 3 components to be noticeably better for the user wherein, the ultimate goal for them is to become a juror so that they can (help) resolve digital/online disputes. Therefore, the final iteration should allow users to have minimal-to-no confusions regarding what they have to do & why they have to do it w.r.t.:
- Getting started as a juror
- Accessing a case
- Arbitrating a case
All the while, I should ensure that the design adheres to the design principles emergent from the blockchain backbone and why it’s there as well as the legal industry and its requirements. Before I share my design principles, I must explain share one simple infographic explaining why Kleros needs a native token and what it’s all about:
The aforementioned design principles I decided to adhere to are as follows:
- Wisdom of the Crowd & Privacy — this principle is all about being respectful of people’s data whilst empowering them to feel like they’re a part of something larger than themselves.
- Fairness & Trust — this principle is all about being bias-free because “justice is blind” after all.
- Transparency & Truth — this principle is all about being as concise yet comprehensive with the information provided so as to establish professionalism, dignity, and modernity.
- The company is located in South America and I was the only designer in Toronto working on this
- The company does have one lead designer, but his hands were tied for the most part dealing with a lot of other design work.
- This did however make it easier for me to focus on my work since it meant that I would be given more autonomy with it.
- Additional to this though was the fact that overall, because the startup was in its early-stage and bootstrapping, funding was limited for me.
- Therefore, we couldn’t do highly-quantified data-driven user research due to inaccessibility to such software.
- Moreover, I was limited in time due to juggling a full-time job at the time at RBC as a design researcher there; as well I have a long daily commute of about 2 hours roundtrip.
- I did both the initial scoping and iterations, usability testing and analysis, as well as final iterations and project wrap-up.
- Reading several articles published by Kleros, Stanford Law School, and Civic Hall Toronto on the subject matters of legal-tech, legal-design, and of course to better understand the Kleros ecosystem. In essence, I sought to understand the problem space more and to basically put my head in the game of what the Juror Product was trying to be: https://blog.kleros.io/become-a-juror-blockchain-dispute-resolution-on-ethereum/.
- I applied a mental problem-solving technique known as MECE: https://en.wikipedia.org/wiki/MECE_principle — to conclude that initial research step to determine what my Happy Path would/should be.
- Formulating a survey based on all the above readings
- Applied standard digital product design principles such as the “10 Usability Heuristics for User Interface Design — by the NNGroup” to conduct an initial iteration based on the Figma prototype provided to me by their lead designer.
- Recruited several legal practitioners with a curiosity for futurology at a hackathon run by the Toronto Legal Hackers group as well as several young professionals.
- Tested my first iteration with said young professionals, conducted a second iteration, then tested that second iteration with the legal practitioners.
- Conducted analysis on all the feedback provided
- Designed a few more iterations.
- Synthesized everything into this article.
- Overall — I applied the technique of the Happy Path: https://en.wikipedia.org/wiki/Happy_path to focus the scope of my work.
The following are some highlights/samples of the survey I had conducted, where I was able to assess 9 different individuals:
Below are some visual elements that are commonly used throughout. I didn’t have enough time to rethink these, but if I did I would’ve used a different typeface and created additional illustrations. As it stands right now, the only main change I made was standardize the colour palette because previously/originally they had upwards to 10 different shades of greys and purples. I had to standardize that down to the following. This was still hard to work with but more manageable and if I had more time I would’ve reduced the amount of purple shades to 4 instead of the current 5.
Roboto was the chosen typeface used throughout.
This was the colour scheme used throughout
This was the main illustration used in variations.
“I want to be a juror, arbitrate a case, and win the rewards.”
This is the Happy Path the team and I set out to optimize on.
The following describes the main tasks a user would have to undergo in the DApp:
Join as a juror via email invitation:
Once they hit the “here” hyperlink, they’ll be taken to Court.Kleros.io
- Choose a court where they will have the competency to arbitrate.
- Stake PNK to a chosen court in order to be selected as a juror.
- Wait to be selected as a juror and/or indicate they’d like to be notified via email.
- Upon being randomly selected as a juror for a case: they’ll come back to Kleros and enter the same chosen court as before.
- Choose a case to arbitrate.
- Analyze case evidence.
- Make a decision as to who they think deserves to win — plaintiff or defendant.
- As a consequence, the juror can win rewards in ETH and PNK, or lose staked PNK, depending if he/she voted coherently with the majority or not.”
Below are before and after shots of key screens and UI elements during/within the aforementioned Happy Path.
Courthouse, Court Lobby, and Courtrooms:
You’ll notice that my final iteration contains only these 2 different words. Based on my testing, I found the initial nomenclature to be highly confusing for several users including myself even. “Courts” and “Courtrooms” for example meant the same thing to those with a legal background. Though, for those who may not be so familiar such as myself — I though a “Court” meant the whole “Courthouse” and “Courtrooms” meant a “Subcourt” for example. I felt that the term — “subcourt” despite being used profusely initially was confusing — given that no such term exists in the legal space and could be perceived the same as “court” and “courtroom”. Therefore, I’ve chosen to create a new set of terminology wherein:
Courthouse supersedes Court Lobby, which supersedes Courtroom.
The Courthouse houses the entire court as a whole which consists of a hub-and-spoke model where the hub = Court Lobby and the spoke = Courtroom. The Courtroom contains all cases that belong to it. So for the purpose of consistency, I’ll be using these 3 words as opposed to the original terminology.
Another change I made was to make the “Courtrooms” tab a dropdown. I did this as a way to conceptually merge “Cases” and the previously entitled “Courts” together. Now, if someone clicks on “Court Lobby” dropdown (which will be the default that’s selected), they can see all other courtrooms they’ve joined. They can try clicking on each of them to enter into them, but if they either haven’t staked them or weren’t chosen as a juror for them, they won’t be able to actually click on it. A tooltip should then popup to inform the user as to why. This way, the user is “always being onboarded” but subtly.
I removed “Cases”, “Governance”, and “Guides” because the latter 2 were superfluous to this MVP (Governance belonged in its own product whilst Guides would’ve just been FAQs and is usually tucked away elsewhere).
“Cases” was confusing given that users are required to stake their courtrooms first before entering it to view them. Having separate tabs for “Cases” and “Courtrooms” didn’t make sense because it broke the information architecture of it all.
The logical progression is to join a courtroom, stake courtroom, then enter it in order to view cases, decide which one to study, study it, and then make a decision as to who deserves to win the case — plaintiff or defendant. The IA is one of an in-series sequence of events as opposed to parallel movement.
Therefore I simplified it to illustrate the “hub-and-spoke” model I mentioned previously. As for “Tokens”, it was separated out as a CTA button for the purpose of calling it out as a unique action that could occur in parallel to the main course of events.
The sub-navigation before needed a revamp because previously it was airy looking and didn’t instil confidence in its instructive text as well as its CTA buttons. Now there’s both consistency as well as boldness in terms of how the sub-navigation looks and what it says in the different pages.
This is a crucial element and will stay consistent throughout most pages so as to keep the users constantly updated as to their PNK count. Visibility of System Status is the reigning design principle that I’m adhering to for this. It provides a visual reminder at all times how much they own, staked, and locked since Kleros has redesigned the legal practice of arbitration to become a transactional activity.
The original Swimlane lacked consistency in terms of its visual design. Additionally, I removed the Etherscan address as well as the Ether amount due to how overwhelming it would be for the user. Monitoring 1 token all the time was daunting enough as it is. Ether does show up elsewhere in the Courtroom Cards but has more meaning there.
I removed the bell icon because users weren’t sure what it was for. If we want to keep users notified about when they’ve been drawn as a juror, we should simply ask them once if they wish to be notified globally for all courtrooms and that can be done elsewhere.
I expanded the diamond to account for scalability of the number within as well as to place emphasis on it. I made the “clicked” state bolder because that’s the only way to reveal the bottom action bar. This is to account of the in-series UX of the overall navigation that the previous design didn’t have.
I removed the case numbers because that denotes judged cases not arbitrating cases. I increased the ETH count because 0.01 was demotivating. I spruced up the visual design a bit to adhere to my grid as well as removed all real world names so as to adhere to the bias-free design principle.
MetaMask has become a hallmark in the Web 3 world. The only thing that I would change is, I noticed that this pops up the moment “court.kleros.io” is entered.
There should be a screen that appears beforehand — maybe a splash screen similar to those that appear during a mobile app’s loading screen informing the user about MetaMask.
The original contained zero onboarding, save for reading materials beforehand. I’ve decided to include not only a typical onboarding that contains spotlights, but also a “preview-mode”.
The preview can be toggled but only before the user actually joins and stakes their first courtroom. The preview allows the user to eventually view case details but not arbitrate it.
Most existing DApps require purchase of their native token beforehand. I thought to create this preview as a way for users to peer through the window before opening the door as opposed to simply being told to enter it by a realtor.
After the user has decided to click “Browse Courtrooms” they’ll be taken to the “All Courtrooms” page. The original empty state screen is instructive but that instructive text is very unnoticeable and overall screen is uninviting. My proposition would be for the empty state to be modernized with with an empty state illustration. This empty state no longer feels weak and removes all confusion as to what the user should do.
Court Selection didn’t change much due in part to a lack of time to rethink this but also due in part to the technical constraint that I felt was placed here. The code for this navigation is more complex than most other UI elements in this Happy Path and I didn’t want to tamper with that.
Typically a screen like this might look more akin to an eCommerce browsing page given their similarities in how there are courtrooms within courtrooms, akin to eCommerce categories and subcategories. However, there is good reason for this design because eCommerce has to be highly-visual so as to drive purchases, the world of Justice on the other hand cannot be as such.
Therefore, this has to be text-based so as to remove biases, however if I had enough time to update this, I’d use more iconography and recreate this page to look more similar to something like this infographic with concentric circles signifying courtrooms that supersede other courtrooms. This way it’d stay neutral, but be enticing at the same time.
Apart from integrating the aforementioned UI elements of the Subnav, Swimlane, and Courtroom Cards, I introduced the bottom Action-Bar as a way to address the overall in-series UX of Kleros. Visually, it also makes it look like a house given that the user is now within the Courthouse — with a top and bottom enclosing the user in. This makes them feel safe, secure, and have confidence to know where to go next. The other key thing to note here is that at any given time a Courtroom Card will be automatically selected as default because previously this wasn’t the case. All Courtroom Cards could be deselected. Also previously there wasn’t a metric updating the user how many active cases there were and additional instructive text notifying them about the average wait time as well as why staking more PNK mattered.
Apart from integrating the aforementioned UI elements of the Subnav, Swimlane, and Case Cards, I introduced another new element to play. This time, a small thing but important change that will only show up are in the cases pages — both all cases and within a case. This is to signify to the user that there are other users who are arbitrating thus enabling a sense of “I’m a part of something larger than myself.”
This horizontal bar will be tentatively called the Community Lane so as to keep in line with the “community” aspect of blockchain as a whole. When I tested the initial design with users, they all asked “is anyone else arbitrating?” They wanted to know that their actions weren’t the only ones affecting change in the system since that would help them feel their actions mattered.
This Community Lane is also my signal to the blockchain community as a whole, to say — that something like this needs to be more thought out and standardized across all DApps. What do I mean by that? I’ve always held onto the notion that DApps differ from regular Apps because since it’s supposed to give “power back to the people” or data back to the people so-to-speak, then it’s up to the DApps to provide data analytics for them.
Therefore as designers: data analytics, science, and visualization is a key element to a great user experience in this space. Despite this Community Lane not being a “visualization”, it’s just an initial move towards that, hence its minimalist design. Currently, DApp developers love showing raw numbers straight from Etherscan thinking that it’s enough to give insight to users. This is why I tried my best in this regards by only focusing on a few pieces of data with key info such as “sender” and “receiver” amount for each case and all cases might help instil a sense of “Wow, there’s some serious activity going on here! Okay, I guess I’ll put my PNK in since others are clearly doing it.”
I’m not going to bother with “total volume” and other metrics that only investors care about because the goal here isn’t to motivate Kleros Jurors to invest in PNK, but to simply use it for a greater goal and to earn more money of course for themselves. This is why this data needs to be re-represented, repackaged, and reframed for the user so as to provide inspirational insight and promote encouragement in their decision-making.
Arbitrating Court Case
Arbitrating a case changed a lot here because this is the crux of the Happy Path, this is why users are here at all. One of my research participants said that this was his favourite page and he was the passionate litigator who always takes his time to optimize his work. All legal practitioners I tested with said had the most to say about this screen.
The main takeaways I got were that this page needed more information as well as more space dedicated to both the case brief as well as the case feedback sections. There also needed to be an unbiased look to this, whereas prior only the defendant was highlighted, here the defendant and plaintiff are equally represented. Key actions and metrics are now up top in the subnav as well as the area right below it.
Key additions are as follows: Legislations, Policies, Plead, Suing for, Accused of, and Counter-Sue. These were all considered to be incredibly critical pieces of information or areas of knowledge that without would make the arbitrating UX a pain given that the user would have to search elsewhere for relevant legislations for example and might not feel as motivated to arbitrate if they weren’t sure what the user was pleading and doing about their case.
There’s a lot more to be said about this page and that could be done to improve it even more, but these key changes I felt were necessary for the MVP.
Now that they were onboarded, the new Courthouse page would simply be more dashboard-like. the background illustration was maintained so as to keep a sense of visual appeal. Key thing here to note is that the original design had the dashboard UI in its pre-onboarded state. This iteration ensures that users only see this dashboard UI when it matters, after they’ve become fully onboarded.
Below is the final prototype of the fifth iteration: