Sasha Tanase Luca - Designing for Trust in Web3: Lessons from the User Research Field

Trust is the hardest currency in web 3. Bitcoin and Ethereum users have an emotional relationship with their assets. Losing BTC is a significant fear. Trust is deeply personal. And you have to understand that for a lot of people in web 3, their Bitcoin reserves are just like their pension funds, their retirement money and a means to a peaceful old age.

And that's why they are the trust final boss. Elder ring trust. They are extremely skeptical, extremely cautious, will take much more time to do research if anything catches their eye. So, let's talk about visual and UX trust signals. If it was built hasty and looks bad, it's probably a scam.

And this is both hilarious and completely serious. So first of all before we go forward can I get a raise of hand uh to if anyone here knows what a jobs to be done is. Okay lovely a very nice surprise. But for the other ones uh jobs to be done are a UX framework that focuses on how users hire a product to solve a problem. Like for example, uh you are hiring a drill not because you need the hole but you need to hang your uh picture on the wall.

So it's about the why behind the action. So first impressions matter and as a user I want the website and interface to feel clean and legit so I can trust it's not a scam. Because when someone says that, what they really say is, "I have no idea what this protocol does, but I've seen enough rugs to know what they usually look like." And that's the thing. In web 3, we've trained users to trust their gut and not our docs, not our audits, their gut.

That means if your font is off, if your button feels slow, if your layout reminds them of a rug they lost 2K last year, they're out. Design isn't just aesthetics design. It's a survival filter. So, here are some very good examples from Zapper and Llama Swap. They have very clean design, no hype, fast load, immediate visual credibility.

They focus on simplicity and they prioritize clarity over complexity. And good. Now, let's talk about trust through transparency and verifiability. Proof of reserves. This is convincing me.

So, I really love this quote because it's so rational. Is the opposite of the gut check. It's a user saying, "I don't want the hype. Give me the evidence." And real proof builds real confidence.

So, as a user, show me audits. Explain how it works. So, I know my money is safe and the risks make sense for me. So, this is the researcher mindset. This is how I like to call it, the checklist person, the I read the white paper person.

And in web three, they're not rare. They're everywhere because once you've been burnt, you will look for fire everywhere. And they're going to ask, "Where are the audits? Who verified this? Can I see the smart contract?

Can I check the reserves?" And we have here uh meodouin dashboard and lido very good examples on uh trust through transparency. All of them have public onchain metrics. They are verifiable through transparent user activity, public audits, onchain validator stats, you know, open protocol data. Very very useful.

And here's also an maybe more um applied type of uh trust through verifiability. Here we have an example from uh the TBTC bridge. You can see in the DAP the live minting flow with verifiable checkpoints. So it actually shows you in real time uh the Bitcoin to TBTC conversion process transparently. So you can check it at any time.

So let's learn about social proof and community endorsement. Uh this is actually something very interesting in our space. Um most of the projects I use are recommended by someone I trust. And this quote tells us something critical. Web 3 doesn't have onboarding.

It actually has whisper networks who build squad goals. And trust is something extremely social. And you have to remember that as a user, I'd rather hear from trusted people than guess what's real. Referrals help me skip the BS. So trust begins in the group chat.

There's no app store, no customer reviews, no trust pilot, just Telegram groups, Discord servers, Twitter followers. So when someone uses your product, it's often because they saw someone else using it first. A wallet, a dress, a screenshot, a shared success story. And in this space, reputation spreads like wildfire. And it only takes one negative signal, a glitch, a Sasal or a Coffeezilla tweeting something about shady little mechanism you have in your product for your product to actually burn to the ground.

So uh I have very two very interesting examples here from TBTC and a um they both showcase clear TVL and easily accessible protocol history and in web 3 this is actually TVL and wallet addresses are uh equaling social proofing. Uh and also we have another uh very good example of Sasal and Celo. Basically Sasal who is a very well-known influencer with a impeccable reputation is associating his name with Cello which in return means that Cello is actually very reputable as well. Um so uh let's learn a bit about protocol and team reputation or pedigree as I like to call it. Um, so has there been any exploit?

Is the team good? These questions aren't optional. These questions are actually instinctual. And it's super important to learn who is behind this. And as a user, I need to know who's running it and see a proven track record before I commit serious funds.

So, people want to know who built this. Were they around for the last bull market? Did they disappear during the last hack? Did they run with the money? Are they building in public or hiding behind avatars?

And if you think being anonymous is cool, well, maybe you might think again. uh to users. This is actually a red flag. Unless you have earned your trust over time and you can now uh just hide yourself behind a beautiful monkey, make sure that you're actually displaying uh your at least one of your team members. Make sure you display other teams who have integrated their protocol in your protocol.

So no sound protocol will want to be associated with a scam. Therefore, you will gain validation and unfortunately for all of us, the web sleuth has always one eye on your team's history. So we have here um thesis studio and uh threshold network doing an extremely good job of showcasing their uh theme and basically you can go and check their GitHub and other um social links they have provided and they are comfortable with providing. And um I would like us now to move on to emotional trust behavior which is actually one of my favorite uh topics of this uh talk. Um this is a behavioral pattern that I have only observed here in web 3.

So I usually start with a small amount so that I can see how things work out. If anything goes wrong I do not lose a lot. So, this one is really hitting me because it's not just about being cautious. It's about a strategy. It's about control.

It's about surviving in an ecosystem where the margin for error is razor thin. Start small and then scale. So as a user, I would like you to let me try with a small amount first and if it holds up, then I'll consider going bigger. And this is very important because a lot of our uh a lot of the web 3 protocols do not actually give easy access to users to their test net. So then they can build trust with your product.

They just throw them in the mainet C and that's it. So when someone sends a small transaction, that's not a shrug, it's a stress test. And they're not testing your UI, your gas estimate, your latency. They're testing you to see how your product behaves when it's holding their value. And they do not call it a test transaction.

They call it let's see what's happening. So these are uh quite fine examples of uh products that are responding very well to this emotional trust behavior pattern. We have here um MEO that just gives very easy uh access to testnet tokens. This is basically a very lowrisk on boarding uh method. Uh we also have another example from uh TBTC um and basically they set up outcomes and expectations before the user commits and also they provide the easy way out if the user doesn't feel comfortable anymore.

And now I would like us to talk about uh risk perception and fear. I saw someone had uh here at the conference had a um t-shirt with let ask me about bridges or let's talk about my bridges. Okay, I would like to ask them because I asked other users and what they told me about bridges was that bridges are scary, not confusing, not clunky, not experimental, scary and transparency beats the hype. And as a user, warn me about risks and explain the high yields. I don't want surprises or shady fine print.

That's the level of emotional gravity we're dealing with. These are the UX complaints. These are trauma responses and users have watched funds disappear into bridges with no clear receipt, no progress bar, no confirmation message, just a silent void. And even if your code is secure, if the experience feels unstable, you lost them. In web 3, uncertainty feels like a theft.

So, how do you counter that? Show users what's happening at every moment. Tell them what's next. Tell them what's just happened. Give them a chance to back out before they panic.

So as I was saying earlier, Meobaro has very good examples. Also another very good example is here from Mezobar uh upfrontness on the risks and um let's move forward faster to uh learning and research and education. So I read everything before doing anything. Here's the beautiful paradox. Users want freedom in web 3, but they also want guidance.

So make it understandable. Give me plain language docs and inapp guidance so I don't need to be a dev to use it. They don't need the financial advisor, but they do need a glossery. They don't want you to treat them like babies, but they do want a walk through. The best users aren't lazy, they're learners.

But if your product makes them feel dumb for just asking simple questions, you've lost them. So show them the flow, use simple language and respect their curiosity. We have here um Zerion and Pawn Finance. They really really have very good examples on uh supporting education and um research for the users. everything is very u easily understandable.

also another good example for me. They make everything super simple. And I would like us to talk a little bit about the trust journey now. So this is how trust actually works. It's not a single moment.

It's actually an emotional arc. So from landing on your site to that tiny transaction to deciding whether or not to recommend it and fight for it, trust builds quietly and breaks loudly. So your product lives or dies in these five moments. So trust isn't the feature, it's the product. In web 3, everything we build exists in tension between risk and reward.

We say decentralized, but we ask users to trust our smart contracts. We say self-custody, but we ask them to sign with a hot wallet. And that's fine if we're honest about it. If we design with care, not just cleverness, because trust isn't built through branding. It's built through behavior.

It's built in the way your DAP handles errors. It's in the copy that explains what's happening in whether or not someone feels safe handing over that their Bitcoin. So don't just build for functionality, build for doubt, for caution, for people who've lost money and are trying not to lose it again. And in this space, trust is not a side quest. Trust is the product.

Thank you. Thank you so much for the amazing presentation. We have a couple of questions for you. So the first question is, is there a UX framework process I can use to get started?

Get started what? For what? Get started to put together a product. Get started to do research. If you needed to uh put together a product, I have a saying um which is quite easy.

Uh explorative design helps you do the right things. Iterative design help you do the things right. So first you test your idea, you see if there is a market fit and then you build it and test it again and see if you're actually building it right. And this is like the simplest way that I encourage anyone to to start their product whether or not they're designers or anything. This is like uh basic basic things.

So yeah, hopefully this is useful.

So we have a followup to that question. UX research is is usually expensive and lenty. Is there a way to vibe UX research?

Haha.

So, first of all, uh UX research doesn't have to be expensive, doesn't have to be lengthy, depending on what you want to uh test. It can be super fast and cheap. Anyone can do UX research. And I encourage anyone who has a little bit of u love for their users to just start talking to them and burst their bubbles and just listen to what they have, what they need and what they do and look at them how they interact with your product. From there on maybe you're not going to become a UX researcher but at least you will get some insight.

So uh about vibe UX research uh no there isn't such a thing because you actually need to talk to people you cannot ask chatty to do it for you however chat GPT or any other LLM can uh provide you with useful frameworks on how to maybe at least um frame your questions so you are not doing any leading type of uh questions and then you have spoiled data. And one more question. What is the process you use to find the fine line between overtargeting a product versus keeping it ambiguous? What is the process? Uh I used to Well, I think it's overtargeting a product is just like your uh I I don't think it's a very good idea to do it in any way.

Um because your product evolves. So you need to have always one eye on the user that is growing and you're educating and you want to on board. So um I think uh to avoid overtargeting is very useful to every now and then go and do exploratory research and talk to people outside and see maybe I want to start targeting like for example I am building a super cool wallet uh for Bitcoin that can be used in uh IRL and uh it has a card attached And if I will only target Bitcoiners at some point my uh product will just like my target audience will run dry. But then if I am a visionary and I want to make sure that my product becomes successful, I can invest in explorative um and exploratory research and I can start saying maybe neo bankank users might become my target audience. Let's see what's the overlap.

Let's see how I can learn more about them and how I can onboard and convert them at some point. So I think web three is not yet in the overtargeting uh part because we don't even target people. So we're safe.

Nice. Uh let's get a few people in the mic. I I know that we have two more questions, but I need a brave soul that can formulate a well definfed question and it's not a keyboard warrior. Okay, thank you. Thank you Paul.

Um, hey Sasha, what is the best way you found to sell user research to project leaders and pro product leaders and people that are in charge?

So for me the easiest was to just invite them like okay let's just try it out. You don't have to pay anything. We won't pay anyone. Just come in and observe and listen to the user. And the moment they are listening to the user actually they start to believe in it.

And then when they are starting to learn about the things that they like the the um things they really thought they're true and in the end they are invalidated by the users. They start to actually believe in that. And I think what's the most important is the fact that you can what worked for me was to tell them that maybe now uh it will cost you a little bit but it actually saves you 10 months of working in your cave and not testing it and validating it to anyone sending out sending your product out and no one uh using it. So I try to encourage them to break things fast, learn, regroup, iterate, and uh try it again.

Thank you. Thank you.

You're welcome. There's one more question. You have time for it. Would you like to answer it?

Yeah, sure. Why not? Happy to.

Uh, have you seen any specific design patterns that help onboard complete web 3 users into the web 3 more successfully? Uh no no. However, I think what is going to what we actually need to start uh change and do a paradigm um change in our mindset is that web two is a different thing. Web two is uh at a huge m maturity. it has finally um reached a huge maturity and now they can think about little details whereas we still need to uh work out uh how we are on boarding people and I think we need to start um making a very big difference between web two and start accept that they're different technologies and we cannot just apply one thing to fit all.

We need to invent new patterns or adapt them for us to on board these new people. But it's just like uh I think I I make this comparison all of the time, but it's as if uh someone would like to on board anyone to becoming a pilot, an airplane pilot. It's it's the same type of uh learning curve and also the pilot wants to needs to want to be on boarded. So yeah, it's uh it's it's a lot of