From Protocols to Products: UX as the Bridge to Adoption

Transcript

Hi everyone. Today I will talk about today we will talk about how user experience can help you to bridge the protocol stack into amazing applications. My name is Andre Bont. I'm from mater and our team is building zing the elastic network of the blockchain and in the blockchain field I'm from 2017 and the last three years I'm working with amazing team Malabs okay let's figure out what's different between the protocol and product and as you see the audience is different because everything else can be a common like business value or decentralization So developers are lovely users of the

protocol uh but they are building the something people touch its product. So developers usually can be more flexible than users because users can simply go to competitors. But if developers create amazing applications they will make the protocol very successful. There are real world example of protocols that became successful because someone created them and turned them into something people could actually use. For example, MetaMask as a product had a significant impact on the popularity of Ethereum.

Of course, we can ask user to download and synchronize Ethereum node, open CLI and create a wallet and manually sign transaction in hacks. But for some reasons, user will not do that. Can you guess why? Because most protocols are designed like airports. They're powerful infrastructure with horrible experience. Developers love protocols because they can provide a lot of opportunity for users and build something. But users even don't care about this. They want product easy to use.

Okay, no problem. So we can just build amazing applications and this is it. Yeah, of course. But for some reason we still don't have thousands and thousands application in web 3 with incredible ys. Why? Because most web 3 teams are led by developers. We love building things uh but we focus often to the tech first, not the users. developers care about things like speed, uh gas cost, low um and how protocol works. They ask is it efficient? Is it secure? Uh but users ask what is this wallet for? Why it's asking for the

money? And why did my uh did my transaction completely successful? Uh so there's the gap. And it's not because developers um don't care. It's just because of different mindset. So to build a great product, we have to bring in user thinking from the start, not after tech is done. I know how hard is keep users in focus because when working on the application or participating in the hackathons as a product designer, I can start thinking about users a lot. However, after the deadline, I can because of deadline, I can skip more in-depth research or

additional validations to minimize the development time. Uh, and to avoid this, we must constantly learn continuously learn about users. No, we don't learn about them. Yes. Yeah, we learn about them, of course. and we must have to understand them and and all the time and validate their needs. So the question is what they need. Definitely users don't need any of this PC you can see on this left side uh left side and they just need to do something with the blockchain benefits uh like Doomflow you can just think about this and have it right now here um

like here. Yeah. And to figure out what we can do here uh we can refer to job to be done framework. So instead of asking instead of waiting so instead of asking what feature do we do we build what we can build we can ask what job is the user hiring our product to do this mindset changes everything because but as we know the situation on the right side is almost impossible. We should interrupt this dream flow by some specific stack like this. Um but every time we add some stack we can add some something that can be an an obstacle for

the user. So fewer steps and obstacles we add to the dream flow the better right and yes and no. The last decade, especially in the blockchain, product designers and team product teams, they tried to make the application as minimalistic as possible. But it's not always the solution. Let's check this example. For example, Amazon checkout uh flow provides you a lot of steps like you have to open the website, shopping, add delivery address.

Um you have to use even external mobile device to copy the credit card details and millions of people find it intuitive just because it's familiar. On the other hand, we can we may have a small store and this small store can offer onepage checkout very simple with amazing stack which can cause friction because too it's too far from user expectations like for example unusual way to add uh the delivery address like enter the zip code and choose the address from drop down. It's fantastic okay but it's far away from user expectations. It's more

easy just to add a couple of fields. The same situation with EOA. EOA is really simple, but it's just unfamiliar. At least users don't know where to keep the seat phrase because their finances were never depend on the small piece of paper and make things familiar to users and uh because familiarity is easy to use and understand. But how to make this thing familiar?

We must understand our users. This is where user experience can help us. It can provide additional knowledge about them. This knowledge uh with this knowledge Y can turn the technology power into something usable, valuable, and even lovable. It's a bridge between engineering and experience. But how we can get this knowledge? We should conduct user research. This helps us deeply understand our users, what they need, what they value and their limitations.

Users user research help us to know more about user needs, their pain points and their behaviors. helps validate decisions and improve product development and reduces risks and increases user satisfactions. Let's check the example of how we can use this information with GR tech. For example, if you want to make a great onboarding experience what one of the most important part you can use for example ZK Zync SSL it's a single and user and developer friendly model account implementation on Zync. Our goal as a team is to build uh to make on boarding feel as easy as logging into mail. No browser extensions, no seat phrase, no

fees. For example, user can authorize their account using the pass key that just one click and this is it because and this one click on boarding in my personal opinion is something amazing because instead of dawning the wallet saving a phrase finding the account user can just use pass key with face ID and this is it. You can even allow user to use the application without paying fee and without um any confirmation because of pay master and sessions. Fantastic, right? Yes, this one click on boarding is amazing. But does it feed to everyone?

For example, we may have Amy. Amy is active user of five different European banks and QC is something she doesn't like. But on the other hand, it's something that build trust. Imagine she decided to to use self-custody wallet to make onchain transactions. Of course, she researched the market and downloaded the best application that uses the pass key because it's something promising and created for providing a mass adoption. If she creates if she creates creates a self custody wallet uh with an amazing one-click and budging process with Puski and this is it, you will have a user who

has no trust, no clarity about what happened. Just one click, no QAC, no option to share the contact or any personal data she usually use when called to the bank if something happened. This might be a great for web 3 active users because uh they usually use PI but it's not good for Emmy. So everything depends on the users and this is why you should learn them and you learn their experience to know their pain points and expectations.

You should know what is better for whom and depending to their experience build something they will be familiar with. No matter it's minimalistic flow or the flow with couple of steps. So instead of saying that we have something incredible just one amazing option everyone can use uh we should remember about our target audience. If you're building something for developer developers and web 3 natives, EO might be the better option. However, if we're talking about the mass adoption and the millions of people involved, most of them have mail and mobile phone number and they can use and they is

usually used daily. So the mass adoption solution is using mail and phone number, right? You know people say let's build something for mass adoption like it's one single user because when we talk about blockchain user we usually have web three natives web three enthusiasts blockchain beginners blockchain developers etc etc for mass adoption we need some one specific thing and everyone will be on chain um but it's not true even if we talk about the mail and phone number and the as a way to mass adoption There are a lot of things need to be researched because some users are happy to share

their phone number especially in banking or security applications but others see that and immediately bounce especially in gaming or casual apps. Email looks easier but even here you have two different options like traditional login with password and social login via Google. This is the heart of mass adoption. It's not choosing one right login for everyone. It's understanding who you are building for and why. So even simple like simple things like login need deep research notes.

For example, fun phone number login works well in uh India, Nigeria, Southeast Asia because in this region you don't people usually don't have even mail. They use SMS and WhatsApp. Email and password works well in North America, Europe and and Latin America. It's familiar, but users may forget passwords or reject the flows without autofill. What else? Apasky and biometic login are rising in Asia in US. It's great for privacy speed and mobile first UX, but many users still don't know what it is.

So education matters. Google and Apple and social login is very popular uh with Gen Z globally especially in casual mobile first apps because it's fast and low friction but not everyone wants to connect a personal account to a crypto product. Mass adoption doesn't mean finding the one right login method. It means understanding the context, country, culture, use case and user maturity.

The deeper the research, the wider the doors you open. So today we covered only one thing on boarding. But you should follow your users everywhere in the app and help to avoid obstacles. Use the power of the protocol to make everything familiar to your specific target audience. If something differs, explain why it matters and what benefits users will have because of this. Find this different. Always look for their problems and pain points and convert them into something beneficial.

To be sure your product is clear for the users, you can use for example those three questions to verify yourself. First, what is this page for? Why do you need it at why do you need it at as a user and what do you have to do? For example, what this page is is for uh name entering or enabling permissions. What user should do? Enter world name or tap to enable? But the answer to the question why is often very critical. On the first screen we can we can say instead of this we need a wallet name to name your smart contact wallet properly.

This message can convert this page into the obstacle. So instead of this uh and make it beneficial we can say something like it's your public identity. Your friends can use this name to send you crypto. So it's beneficial. So in general, more obstacles you and pain points you find, more smooth this experience you can do. Fall in love with user problems and they fall in love with your solutions. Thank you so much.

If you have any question, I will be help. Thanks so much.