How we Designed a DeFi protocol in Weeks. Union Case Study

Introduction

A couple of months ago we were approached by Jacob Shiach through Twitter. Our initial conversation was not related to working together, but he just congratulated us on our InstaDApp redesign work. Shortly after, he told us about his upcoming project: UNION, a DeFi protocol that enables people to borrow from their circle of friends without collateral, and even though he was in the very early days of defining his product, he mentioned his desire to work with us to give a good look and feel to his product.

Before we started the project we knew that we had to do it in a sprint session of 2 weeks. Why? Because blockchain projects, and especially the ones related to DeFi, are already difficult to implement (due to smart contracts ) and by designing the product within weeks and not months we ensure that we get the right feedback from users and therefore the right product to start developing.

Process — Ultim Design Sprint

At this point, we assume that you are familiar with the process of design sprints. If you are not, we encourage you to take a look at it, good stuff in there. You welcome.

Although the original design sprint by Jake Knapp was framed in 5 days, we decided that because of the complex nature of the product we want to design, and our need to test more than usual, we would need 2 weeks to be able to successfully design UNION.

This is how our Sprint days looked like.

Framing the problem and finding solutions together

Before jumping into the design, we wanted to make sure that we know what our client's goals and needs. That’s why our first kick-off session was focused on problem framing and exploring potential solutions alongside the team. We firstly asked the following questions:

• Why is this problem important?
• Who is this problem for?
• Why is this worth the effort to solve?
• What is the impact if this problem is solved?
• What will make this project succeed?
• What is the product’s biggest advantage or opportunity?
• What is the product’s biggest risk?

Once we defined and framed the problem we were facing, we needed to take one more step during this phase by looking deeper into our users and product and setting out assumptions that we will validate later in the project.

Assumptions

Learning from users before designing

In order to recruit target users, we headed to Discord and contacted a bunch of people that were on DeFi groups such us Uniswap or Compound and asked them if they would want to be part of a user research interview. We ended up interviewing 2 guys, Alex and Christian. We took into consideration 3 main takeaways from these interviews:

• Alex remarked that he would lend to someone that he either trusted, a mutual friend from an online community, someone that would have a business idea to back this credit request, or if it’s for a good cause.
• Both users only feel secure if their funds are not relying on the protocol’s team responsibility (Admin Key).
• Chris pointed out that he doesn’t understand the term Vouching for this use case. Trusting would make more sense for him.

How does the solution look?

As digital product designers with a background of working with early-stage blockchain projects, we already had in mind potential solutions for this product. However, it is vital that in this collaborative process, between us and the client, the potential solutions that we discuss meet the needs of the business, and the target users. After the problem framing, exploration sessions and the user research, we had a clear idea of the value proposition of the product and which direction we needed to take to start shaping UNION: we were ready to roll up our sleeves and start having fun!

Wireframes

We were lucky enough to have Jeff Reiner on the team. Besides being the funniest man in Berlin, he was also responsible for designing the initial wireframes of the product, so before we started wireframing we already had a good amount of them set by Jeff. This helped us speed up the process considerably. We iterated the initial wireframes with the team and added some missing flows and made little changes to the existent wireframes to meet our design solutions.

At this point, we explored further the functionalities of the product and we found out that Jacob wanted to focus initially only on DAI, a detail that we didn't discover in the initial conversation and it reminded us to follow the mantra “ask early, ask often” in the initial stage so we don't make any mistakes.

A selection of the wireframe screens

Designing a DeFI product with a FinTech vibe

The blockchain and DeFi space are not especially known for having an easy and seamless design and we obviously wanted to stay far away from that. Our main goal was making UNION look more like a FinTech product rather than a DeFi protocol. Why? first of all, we want to pave the way for future crypto adopters, to make them feel welcomed in a space that might seem unknown and scary at first sight. Secondly, we want the early adopters to ultimately have a financial product that they enjoy using

That being said, we presented a mood board to the team and explained to them our vision of the digital identity of the product. Once we were all on the same boat of what visual language we will shoot for, it was time for us to put some pixels together and come up with the first UI screens.

Getting the first UI Screens

We were on day 5 and already excited to see how the project was taking shape. We finished the first 4 screens of the product and had another call with Jacob and Jeff to make sure that these initial screens were aligned with our vision for the product.

After their feedback, we iterated on the screens and finished the rest of the flows to have them ready for user testing.

The prototype of the user flow of being a Union member

Let's validate the solution

With all the screens designed we created two different prototypes to test the following user flows:

• The flow of a non-member. This user is only able to stake, he is not able to vouch or borrow until 3 other union members vouch for them. Only when they have 3 vouches they become a union member and unlock all the features.
• The flow of a member. This user is able to stake, vouch for a friend, adjust trust, and borrow.

Why did we create two different prototypes?

1. With the first prototype (non-member), we wanted to test:

• If users would understand what they needed to do in order to become a UNION member.
• If users understand the vouching process.
• If users understand the staking process (deposit and withdraw).

2. With the second prototype (member), we wanted to test :

• If users understand the benefits of being a member.
• If users understand the process of staking, borrowing, request a new credit, adjust trust to a member, vouch for a new member, and repay.

Once we determined, designed, and prototyped the user flow, we were ready to recruit new users to test these prototypes.

Note: our initial idea was to only have 3 user testing sessions as comparing this with previous products we have designed it was enough to get qualitative feedback from users, but soon we realised that this was not the case due the complexity of the product itself and its new use case it was difficult for some users to understand so we decided to test the prototype with 7 people and do several rounds of iterations to make sure we were building something that users will understand and easily interact with.

User testing findings

The user testing session gave us very valuable insights

Finding ->In the first testings, users found it difficult to understand what they needed to do in order to become a member.

Solution -> We changed the way we were onboarding users by showing them the 3 steps to become a member right after they signed up instead of having it hidden in a “ Learn more” button

Finding ->The benefits of being a member versus a non-member were not clear enough for some users. That was something we needed to solve as soon as possible, so we continued testing with more users.

Solution -> We added a dynamic card with a segmented control tab between “Solo” and “Together”.

Finding ->UNION is not only DeFi Platform but also a community of trust and we realised that we were not showing this sense of “belonging” through the UI.

Solution -> we used illustration elements that made the design look more welcoming, giving the user more of a community vibe.

Final Design

A selection of the Desktop screens

Mobile version

Once we iterate on the last user testing changes we were ready to design the mobile version of the app and finish the style guideline for the developers

What we have learned

1. Ask early and ask often. This will save you a good amount of time once you are all hands-on with the design process. Sometimes being fully aligned with the client can take more than one initial session. Make sure to keep on asking throughout the process.
2. Work clean, work tidily. Always work clean in Figma from the beginning. Make sure to create components and update the style guide as soon as possible.
3. Have a separate flow where clients give feedback on designs and a separate one for design. This allows clients to always see the most current version while we work on the next one.
4. Create a map of the flow. This would have helped us to get an overview of the whole product from the beginning of the process.
5. Your client is your teammate, the success of a project comes down to two very important things: trust and collaboration.

If you’d like to be part of the UNION DAO project head over to union.finance and fill out their application form.

Hey, hey…before you go! 🙆‍♀️🙆‍♂️

👏🏻 SPAM 50 CLAPS if you enjoyed this article.
👨‍🎨 Curious about what we do? Check our site https://ultimstudio.com/
💭 Comment your thoughts, feedback or what you had for breakfast.