Aishley K.

Product Vision

Our goal for the project was to streamline on-chain donations. The premise was simple: click a link, connect your wallet and donate. We wanted people to be able to create donation pages in a few clicks, and we wanted these pages to have a high level of shareability so that the web3 communities that exist on Twitter and Discord can easily recognise, share and contribute to many causes.

Value Proposition

The easiest and fastest way of receiving and making donations using cryptocurrency.

My role

I led the design for the project, which meant that I was responsible for creating a design strategy that would help us stand out from other donation platforms while staying true to our value proposition.

The Challenge

The client saw immense value in building shareability into the product. We imagined a future where Eth Gives pages were as recognisable within the Crypto Twitter community as Link Tree pages were within the content creator community on Instagram. So one of the challenges we explored was: "how might we build a product that promotes shareability more than the current products in the market?"

Empathize

Eth Gives was a straightforward project with precise requirements that the client set. Nonetheless, understanding the user was critical for the success of the project. I started the project with a stakeholder interview that helped me gain perspective on the target market and the product. I used my knowledge about web3 users to pick out personas from the target market and defined a user for our product.

Stakeholder Interviews

The stakeholder interview was a great place to start. The client introduced me to the current problem with donations in web3.

When a donation cause like Ukraine or US crypto policy comes up, the Ethereum community frequently donates via sharing an address or link to an address on Etherscan. This adds friction for donors to give to the cause.

I understood that it was frustrating for some users to donate directly to an address. There were a lot of variables that created confusion for the user. Such as, does the wallet address support all EVM chains? Do they accept all tokens or just stables?

If the current method was confusing for users, why weren't we seeing other donation platforms being used? Well, we were. But the other solutions either had complicated onboarding or didn't support crypto donations.

Larger platforms like Giveth, Giving Block, and GoFund.me require many steps to sign up and donate compared to a web3 native experience like Uniswap.

The web3 community is notoriously known for its short attention spans, especially on social media. Trends fade in and out all the time. The short-attention nature of the community is perfectly reflected in the community rejecting platforms that have long and complicated onboarding.

Insights

• Depending on the user's understanding of web3, some users feel confused/uncertain when they have to donate directly to a wallet address.
• Users are left to do their due diligence when donating directly to a wallet.
• Users don't want to go through long onboarding processes to set up a donation page.

‍

Define

By this point, I had gained a clear understanding of the value proposition and vision of the product. Combined with my knowledge of web3 - we had a clear direction of where the product was headed. So in this phase, I focused on the simple stuff. Gathering some high-level and detailed requirements so, we created a product that served its users properly., Customer journey maps to define and clarify the assumptions we had made in the first phase. Finally, a competitor analysis leads us into ideation, where we can use what we have learned from this phase to develop a standout concept for our users.

Requirements Gathering

Here's an example of some of the higher-level requirements for the project. There were detailed requirements that we mapped out too. Those requirements were mainly focused on the cause donation page and the creation of the donation page. My goal during this step was to create simple requirements while avoiding the "nice to haves."

‍

Customer Journey Maps

The customer journey map below shows a scenario where David wants to donate to a cause he has learned about through social media. The journey is relatively smooth until the donation stage when a couple of uncertainties arise for him. For example, David has to ensure that he has the correct wallet address and also figure out what tokens and chains are accepted by the cause.

‍

Ideate

I was excited for this project phase because I had a clear vision for the product by the time we got here. The first two phases had perfectly set me up for a great brainstorming session where we explored other platforms and apps that successfully achieved the goals we had set for our product. I used these learnings to create a mood board that I used for design inspiration and analysing what makes those apps so great at what we are trying to build into our app.

Brainstorm

During the brainstorming session, we listed a bunch of products in each of the three categories. Each category was a characteristic of the app we wanted to focus on. We wanted our web3 donation platform to be as convenient as web3 dapps like Uniswap while being as shareable (and recognisable) as Linktree. After listing products in each category, we drew out a Venn diagram that created overlaps between the characteristics. The standout overlaps were GoFundMe and ENS. GoFundMe links are universally recognisable, and the GoFundMe donation experience is one that the users from web2 are comfortable with. ENS as a protocol has managed to make ".ens" domains extremely recognisable and shareable in the web3 world while also making it convenient to make payments using the ".ens" domain.

‍

Mood board

I used the results from the brainstorming session to create a mood board highlighting the mentioned platforms' key characteristics. One of the conclusions I reached during this exercise was that:

Platforms allowing users to choose and edit links to their page are more recognisable and shareable - for example, Linktree, GoFundMe and ENS.

My conclusion was that our donation page needed minimal branding from our end (the platform). The goal was to make the user creating the donation feel like the page was "their own" as they would with a Linktree page or an ENS domain.

‍

Donation Page

I used all that we had learned from the brainstorming session and mood board to create a screen for the donation page. We used a two-panel approach, somewhat similar to GoFundMe. On the left panel, we have the link for the page up the top, which also serves as subtle branding for our platform. Below that, we have a logo for the cause, the title of the cause, and a description limited to (500 chars). We allowed the user to attach a link so that the donator could learn more about the cause if they wanted to. Under that, we have a history section that makes it easier for the donor to do their due diligence on the cause.

The right panel is the 'action' panel. The left panel is read-only, and the right panel is where the user can connect their wallet, pick a chain, pick a token and donate the suitable amount. The left panel is scrollable while the right is fixed, making it easy for the user to start donating as they read about the cause. I took inspiration from Uniswap and Zerion here. The modals used by these two dapps are now industry standard in web3.

In the customer journey maps, we explored that the customers like to do their due diligence on the people they are going to donate to. So incorporated elements that would make this process easier for the user. For example, a learn more button takes the user to an external link like a news story. In the right panel, we added the donation wallet, total funds donated, and created by fields to create transparency. They are all clickable, leading to an external link where the user can view the wallet history.

‍

Prototype

Now that we had a rough idea of what the donation page looked like. I was ready to build backward. I usually take this approach, where I start with designing the most valuable screen of the project and then trace the journey backwards. So the critical user journeys to explore here were:

1. Donating to a cause
2. Creating a cause page

‍

User Flows

We wanted to ensure the donation and creating the cause journey didn't have too many steps. So, I made sure that the journeys were straightforward. The critical decision in the donation journey was to ensure the user was signalled that they could use any EVM chain to donate. We did this by prompting the user to pick a chain after connecting their wallet. In the cause creation journey, the critical design decision was to start the journey by allowing the user to choose a name/slug for their campaign before taking them through the input form. This would create a focus on the link/slug which promotes shareability, as we saw with Linktree and ENS.

‍

Rapid Prototyping

In this phase, I built out the journeys and quickly tested them with the stakeholders and potential users to ensure we were on the right track. By the end of this cycle, we had two clickable prototypes that represented the user journeys described above.

Design System

Design Systems are great because they save designers and developers a bunch of time. As a designer, it makes it easier for me to create screens quickly and create changes across all screens with a few simple clicks. And as a developer, it allows them to develop screens, pages and interactions without the need for designed screens at times. In this case, I started with the Chakra library and combined it with a web3 colour pallet.

Test

By this point, we had a design system, clickable prototypes, and user flows that we were internally happy with. So in this phase, we just wanted to ensure that we covered all our bases. So I decided to do a usability test with our stakeholders and some friends from web3.

‍

Usability Testing

During the testing, I learned that our buttons were bright and always caught the most attention from the user, which was a good thing as this prompted action from the user. I also learned that, at times, the state changes weren't as apparent to the user as we'd like, specifically when going through the donation journey. To ensure this wasn't the case - I played around with the opacity of the input fields and tested them with a different set of users.

‍

Implementation

We had a small team, just the three of us. So communication was pretty easy. As part of the handover, I made a Loom video for every user journey. I also created fully clickable prototypes with different states.

Feedback Loops

Unfortunately, a lot of the time - designs don't translate well to the browser. So, my goal was to keep giving feedback as we went through the build. I would take screenshots and provide feedback on them with the required changes.

‍

‍

Status

Eth Gives platform is currently under development and is planned to launch in early fall.

Learn More

Follow @corbpage on Twitter for updates on the project.

‍