YourJustice (YJ) is a startup working on a comprehensive Web3 platform with a lot of features such as a rating system, court, Nomad Passport, and smart contracts. This case study will be about the Smart contracts functionality of the platform.

A smart contract is a type of contract that guarantees an honest and accurate execution process. Compensation funds will be frozen in an e-wallet of a customer and after the contract is executed it will be given to a contractor’s wallet automatically. If something goes wrong – the third independent party joins the contract to adjust the dispute.

My task was to design an end-to-end solution for this process. Develop and deploy new user flows for all contract's parties such as contractor, customer, and mediator while still maintaining consistency and similarity for users.

As far as this platform does not exist online yet and I couldn’t measure success with real user feedback, I wanted to measure it somehow else. Me and my product manager (PM) decided to focus on such metric as time spent on creating a new contract.

Initially, I conducted market research, interviewing stakeholders and potential users to understand the possible user flow of such a contract. Based on the research I explored that there can be 2 possible types of smart contracts. A simple one and a milestone one. They differ from each other in the scale of tasks. Milestone is used for multistep deliverables to streamline complex processes. And a simple one is used for small-scaled tasks for one contractor.

It's a type of contract you can use for small-scaled tasks while your project is already in the phase of execution.

Simple smart contract

It's a contract you can use while working on multistep deliverables in bigger scaled projects to streamline complex processes.

Milestone smart contract

Let’s have a closer look at the simple one. To make complex things easy I divided this flow into 3 understandable scenarios. «Ideal» one, «Revision» one, and «Mediation» one. Each one is made for a specific purpose.

It is a scenario when a contract is executed on time and without any pretensions from each side. I divided it into small steps which are the statuses of a contract. Initially, a user fills a form to create a contract, then invites and waits for the contract’s participants, then makes a deposit, then awaits contract execution results from a contractor, and then verifies the results. If it’s ok and work is done flawlessly then it’s closed. Frozen funds are given to a contractor’s e-wallet, and a contract is executed.

Ideal scenario

If there is a need to change conditions or move a deadline or refine the work, then a revision scenario appears. It is made for the purpose of changing some conditions of the contract due to changes while the execution process.

Revision scenario

The last scenario here is made for controversial situations when participants couldn’t find an agreement and they need a third independent party to resolve it. It can end in two ways. In the first one, participants agree with the meditator’s decision and continue working on the contract. In the second one, they disagree and one of the parties sends this case to a court. Which is another section of the platform.

Mediation scenario

Based on the research and my exploration I created multiple versions of possible designs. I’ve built high-fidelity wireframes, I was closely working with my PM to find a better solution. Ultimately, I and my project manager decided to leave 2 design versions to conduct A/B testing to choose the most user-friendly solution.

This version uses tabs to organize the workspace. This significantly reduces the length of the scroll and information is available within one screen. Sections of a contract such as compensation, history, deadline, etc. are divided into four tabs.

Tab version

The second version is a one-pager with all contract sections under each other.

One-pager version

I did internal A/B testing among the YJ team members from different departments. They are potential users of such a platform. The main gathered insight was that users value speed the most during working on contracts as I assumed in the beginning. Fast stage checking, adding materials, adding new participants, etc. Tabs are obstacles in this way.

Tab version feedback

One-pager version feedback

*9-10 min spent on creating a new contract

*6-7 min spent on creating a new contract

I’ve learned that the «One space» version is more than 40% more efficient. 6-7 minutes to create a new contract compared to 9-10 minutes in the «Tab» version.

Takeaway

The next stage of working on this flow was the UI part. When I joined the startup they already had a design system. It is built with the atomic design principle. It consists of atoms, molecules, organisms, templates, and pages. A little part of that system is on the screen. Atoms are the smallest semantic units of a system, they cannot be divided into smaller parts without losing their semantic meaning. Molecules are bigger parts of that system and consist of atoms, organisms consist of molecules, etc.

I contributed to the existing design system of new molecules and organisms. You can see it below.

It is a component that allows seeing the history or the latest updates of a contract. It is built of components below that are from the existing design system. So, I combined them to build a history section.

History section

Here you can see more components that I contributed to the design system.

More components

Finally, I built over 30 pages of consistent designs. There are 3 flows. Each one is built for a specific role of a contract. Customer, contractor, and mediator flows. They have the same difficulty level, so I picked designs to show randomly.

It is an important part of designing almost any web interface because it provides business availability for customers who prefers using their mobile phones or maybe haven’t got a computer or a laptop.

In the future, it would be better if the YJ team will build an application for their platform. It enables more opportunities to use familiar interaction patterns so they would provide a better experience than a mobile website. But from the business perspective at this stage of building a YJ platform, it was more important to focus the team’s time and other resources to build a web version online first.

As I said in the beginning the main metric for me was the time potential users spent on creating a new contract. So I built multiple design versions, working with PM we focused on 2 specific design versions to see which one will be better for this purpose and conducted A/B testing to find a better solution.

The ultimate result was more than 40% less time spent on creating a simple contract on the «One space» design version. But it wasn’t enough for me.

40% less time spent on creating a simple contract

I found a way how to reduce that time even more. And as another result, I have 50% less time spent on creating a similar contract (to the existing one) by adding just one little function such as «Duplicate contract». It enables an opportunity to copy existing contracts and edit them as new ones instead of filling a new form from the scratch.

The feature that reduced 50% of time spent on duplicating the contract

I’m looking forward to testing this solution and collecting user feedback. This will allow me to better understand the specifics, find out the strengths and weaknesses and create the best product.

Now the platform is under development by the engineering team, not only specific piece such as smart contracts but nomad passport (which is another case study on my portfolio website), and court as well.