Account abstraction won't save web3 UX | Mindy, CoW DAO | ETHTaipei 2025

[Music] Cool. Hi everybody. Uh I'm Mindy. Uh it's really exciting to be here in uh Taipei and thanks so much to the uh ETH Taipei team for inviting me. Uh I'm a user researcher uh at Cow Dow um part of the core uh core contribution team there.

You might know us as the team behind cow swap uh and a couple of other things. Um and I have a little bit of a spicy topic for you today. Um I think it maybe sounds more dramatic than uh than the talk is actually uh going to be. I'm not actually going to stand here for 30 minutes and like uh say a bunch of bad things about a distraction. uh account abstraction is actually really cool.

It's really necessary. Um I'm really excited about it. Um however uh I want to use account abstraction as kind of a starting point today to maybe uh open up a larger discussion about uh the trajectory of web 3 UX um kind of in general. So first let me just uh give a little bit of a um background about what about uh accountraction just in case anybody you know here is kind of unaware. So basically uh with the coming of EIP7702 uh users will be um EOAS will be able to delegate certain permissions to a smart contract uh letting them basically you know handle some functionality on behalf of the wallet and this opens up the doors to a bunch of really cool UX things including uh gas substraction for example letting a smart contract uh cover the gas for uh for a user um some different login and like recovery methods so that users aren't sort of at the mercy of their seed phrase as much um custom spending uh permissions so that you know maybe the user doesn't have to uh constantly do the same repetitive uh signature over and over and maybe a smart contract can handle that um for for the wallet instead.

And you know, a bunch of other things. Um and these are really cool. Um super exciting. However, um here's my problem. For a while now, uh account abstraction has kind of been the focus of the web 3 UX conversation.

Um, and that's kind of annoying to me, honestly. Uh, and here's why. Um, because web 3 as an industry has historically been um historically been uh an industry where techie people are building technical solutions for other techie people. Um, and now I know, you know, it's we we're we're making a lot of progress. DAP UX is getting much better.

We're onboarding more people. We have a usability track at DevCon now. You know, that's a plus. I mean, there are definitely improvements. Uh, but I feel like the conversation around account abstraction uh tends to get a little bit ahead of itself.

Um, so the conversation around account abstraction tends to kind of go like this. So like we have these kind of major problems that account abraction is going to solve. Um, and then you know at some point we're going to be able to onboard a billion users because of because of these changes. So it's like uh you know fix these problems yada yada yada uh a billion users and um that seems a little bit a little bit fishy uh to me. To me it sounds like uh it's a one more of these kind of uh technological magic silver bullets that web 3 is so fond of, right?

It's like just one more technical development, just one more, you know, thing that we're going to work on and then it's going to happen and then like suddenly block everybody's going to adopt blockchain. And um I'm here to tell you uh that that's not true. Um account abstraction is a really important step, but uh it's not enough without a deeper underlying understanding of how to build for technical non-technical people. Uh web 3 is still not going to reach its full potential. not just building for nontechnical people but building for them in such a way that web 3 is uh useful for them and easy for them to use but not abstracting away so much complexity that they are disempowered the way that they are now on web two that they're not able to control uh and make their own informed decisions uh the way that web web two has kind of has kind of um made made things Now, oops.

So, um what I want to do in this talk is uh I want to address this this this conversation. I want to uh sort of present a few criticisms and then I also want to at the end kind of give uh some recommendations and some tips and some tricks for things that you can do as a DAP builder if you are a DAP builder uh to improve the the the UX of what you're building without having to you know kind of uh wait and hope for some technical solution that that is going to make everything better. So um let's start off let's say that uh that it happened uh account abstraction uh happened and and a billion users on boarded. Wow we have a billion users now. Now what is your DAP ready for a billion users?

Um do you are you ready to uh to to educate all of those users to tell them about you know potential edge cases um to educate them about the risks that they could face? Uh, are you ready for a billion users to see that one like uh, you know, weird kind of hack together solution that you put you had to put together at the last minute because like the deadline was coming and you had to ship the feature and so like normally it works okay, but like you know every now and then kind of it gets wonky like are you ready for a billion people to to see that? Um, do you have customer support that can handle a billion people? And don't say Discord. I swear to God if you say Discord, a Discord server can hold a maximum of half a million people.

Not a million, certainly not a billion. And speaking of of of Discord, um we are an industry where this is the UI that people have to use to get help. This is where people have to go if they want to get help in this in this industry. if they want to learn more uh about about the industry. First of all, I know it seems, you know, really super usable to you guys.

It's not to most people. Um, and spoiler alert, it's full of scammers. Like the place where people have to go to like learn about things in the space is full of scammers who are just waiting to uh exploit newbies who come into the space. This is where people have to go if they want to check the details of their transactions like the the UI of the DAP can be fine, but then if you want to go look at the the the transaction, this is what you have to deal with. MEV is still a huge problem, especially on on mainet.

People use uh lose millions of dollars to MEV every year. And even really sophisticated users still get burned by the the the terrible UX in some areas of web 3. I mean, look at the uh the the the the I'm sure very sophisticated, educated people who were handling the safe accounts on behalf of Bybit. They lost over a billion dollars because of this one single parameter here. This itty bitty tiny baby parameter uh in the UI that is easy easy to overlook and uh not easily human readable.

So, these are all UX issues with account abstraction. uh US issues that a counter extraction is not going to be able to solve that are out there in the wider ecosystem that we also need to be talking about. My next point uh this focus on account abstraction tends to put the onus for uh solving web3x problems on the wallet builders. First of all, I don't think this is fair to wallet builders. If you're a wallet builder, you can tell me later if you feel like uh you really are, you know, enjoying the responsibility of having to onboard a billion people.

Like that's all on your shoulders. Couldn't be me. Uh I think that we should all feel responsible. Uh not just wallet builders. Number two, wallets are not the reason why people on board to uh to web 3.

People aren't excited about making a non-custodial wallet. They're excited about contributing to a DAO, about buying, you know, a meme a meme token. They're excited about using Nosis Pay, playing a web3 game, you know, using some DAP. And the DAP uh UX is just as important as the wallet UX. You know, the wallet onboarding process can be great.

It can be super super amazing, but then if the DAP that the user wants to use sucks or if like the next thing that they use sucks or the third thing that the user sucks, that's still going to make or break their relationship with web 3 as a whole. For example, uh let's look at Poly Market. Poly Market has a really great, you know, nice uh UI. You onboard to Poly Market, you know, as a as a newbie user. Um, you get an abstracted wallet.

Great. Everything's fine. Super cool. Um, but then let's say that, you know, you want to go look at the uh this new shiny web 3 wallet that you have. You know, maybe there's something to this blockchain thing after all.

So, uh, so you click the link to go check out your wallet, maybe look at your transactions, see what it looks like. Guys, this is what it looks like on the right. You have to go from this really nice uh poly market UI to this uh polycan UI here which is barely readable by human beings uh and does not entice people to onboard to web to stay in web 3. Sorry. Um my next point is that account abstraction doesn't absolve us of having to explain complex things to the users, right?

Um I think there's this kind of excitement about like oh yeah things are going to be abstracted and like then people don't have to deal with complexity anymore. That's not true. Um just a couple of examples uh of of for example of um functionality that a can abstraction is going to be able to offer. Um, I heard one example. Let's say that uh you'll be able to set up with your uh your wallet, you'll be able to set up a custom permission where if you die and uh your wallet doesn't transact for a whole year after that, your funds will automatically be sent to your friends or family.

Um, and so, you know, then that that's, you know, something that you don't have to worry about theoretically, but you still have to like explain to the user why they need to set that up, why that's important. you still have to explain to those the person's friends and family how they're going to get those funds. It doesn't it doesn't remove all the complexity and all the need to explain certain things to educate users. Another example uh gas abstraction. Um you know you can abstract away the gas um and say like okay the smart contract is going to handle the gas for you like you don't need to think about it as a user but then if the network is busy if gas is really high uh you still have to tell the user why their transactions taking a long time.

you still have to tell them why they're not maybe going to get back as many tokens as they expected to get, you know, because gas is high and okay, we've extracted it away. You're not paying the gas, but actually we're paying the gas and you know, in under the hood. So, like there are still there are always going to be uh complex things that we still have to explain uh to users and that requires us as an industry to get better at explaining hard things. And that's something that we don't want to do. Um we haven't historically want to do it.

We still don't really want to do it. Uh most DAPs just kind of expect people to know things. They expect people to go and do their own research or like I said, they just expect that like yeah, eventually everything's going to be abstracted away. It's going to be cool and like then we don't have to kind of deal with the fact that there are some fundamental differences between web 2 and web 3 and people need to be educated about those. So what now?

Uh thanks to accountraction, we are getting rid of some of the barriers, lowering some barriers to mass adoption. Uh however, now is the time for us as builders, as DAB builders specifically to really take on the responsibility of learning how to strike that balance of abstracting away certain things that are really technically complex that users don't need to know about, but actually giving them uh some complex information that they might need to know about. Um and we have to be ready to uh accommodate a wider range of knowledge levels of of of um backgrounds and and mental models if we really want to onboard a billion people like uh like we say we do. So first a couple of recommendations to the industry. The first one is really obvious.

I think we need to hire more UX people. Um UX designers, UX researchers. Um web 2 has so many UX people. big web web two companies, small web two companies, they have so many UX people and they have it down to such a science. It's not just like, okay, yeah, the button should be here.

Yeah, here's, you know, here's what the what color the button should be. They have it down to like how to manipulate people, how to prompt people to choose the the make the selection that they want you to to choose, how to word things so that um people believe what you want them to to believe. And a lot of times they've used that power for evil. They've used that power to addict people, to trick people into giving away their data. And it I think it's time for web 3 to really take that power into our own hands and use it for good.

Now, if you need like a business uh reason for this, uh you can look it up. UX research has um a really high ROI. It makes sure that you're building the right thing from the very beginning so you don't make a bunch of mistakes and you don't uh waste a bunch of money and a bunch of time. And if you don't have the funds to uh hire someone in house, uh there are web3 focused freelancers. Um there are agencies you can work with, you know, heck, you can even like just email me and I will find somebody who can do UX work for you.

Like it's not that hard. Another thing is I think that we should collaborate on UI standards for web 3. Um it's really interesting as an industry. Web 3 is possibly the most collaborative industry that has ever existed on the technical side. You know, you have product teams that are uh on one level competitors, but at the same time are still working together on EIPs uh on interoperability to to you know, really do uh be collaborative and ensure that things uh progress forward in a way that's good for everybody.

And I think that we should have that uh on the UI side too because um all of us who are designing DAPs who are are are working on on web 3 UIs, we're all in the same boat. Uh we're all dealing with the same issues. We're all dealing with like, you know, users don't want to read. Users don't want to, you know, they they want to click through all all the steps in the flow really quickly so they can get their transaction done uh as fast as possible, but then like they they blame the DAP, you know, if something goes wrong because they didn't read the details of their transaction. And uh by the way, I know you all do the same thing.

Uh I know you you don't read the details of your transactions either, you know. Um so many times I'll be doing research with uh somebody who's like, you know, a really sophisticated person, a really sophisticated user, really technically technologically um knowledgeable, and they'll be testing the DAP, and they'll just be like, "Yeah, I'm clicking through all this. You know, I should probably be reading it, but uh I'm not going to, you know, that's what we're that's that's what we're designing around. It's like all these everybody's dealing with these same these same issues these really human user behaviors. Um so I think that that that we should work together to find the best ways to uh to to design for those.

Now right now web 3 is in a place where we can pretty much say yeah it works uh most of the time. Uh you know the transaction normally works this way as long as you know the right tokens are being used and as long as gas is not too high and as long as you know five different services are responding properly and uh you know and then oh well if there's if there's a native token involved and things get a little bit weird because you know native tokens they behave differently from uh from ERC20 tokens. Um, and by the way, do you ever feel bad for native tokens because like they're outnumbered on their own chain and like they were first actually like they're the native token of the chain, but like you know um they're considered to be the odd one out anyway. Um, just something I think about sometimes, but I think that anyway, we should uh we should collaborate on uh UI standards for uh for web 3. And then some um some recommendations uh for what you can do as a builder or app designer to uh improve the UX of whatever you're working on right now without waiting for, you know, some technological uh improvement.

Um most of my examples are going to be from Dexes because that's mostly what I work on. Um not trying to shill just uh just you know writing what I know. Um so the first thing is uh I was thinking uh about how we make UX decisions um on the core team uh at cowdo and um I realized that that we have a lot of UX discussions like whenever we're coming up with a new feature or you know a new product we we really discuss a lot about what we want the UX to be like and it usually boils down to uh a couple of different questions. The first is uh what does the user want to do here? So what is the user's um the thing they want to accomplish?

What's their goal and what do they need in order to make this uh make this decision or to accomplish this goal? So this is where we kind of pair down the UI um and only really show what the user needs to see. So like if it's you know if it's a swap, they need to see like how much they're paying and how much they're getting, right? Like the most basic things. But then um the second question is what does the user deserve?

And this is um where we start to add more things back into the UI. So uh you know if it's a swap, maybe they need to know some risks potentially that they're taking. Maybe they need to know what some potential edge cases are. Maybe they need to they need some um some links to you know to the contract or or or to the token to kind of get more information and like make sure they're making the right decision. um what kind of information should we be showing to the user uh that they really deserve to see before they make this transaction.

Uh one way to do this is uh progressive disclosure especially if you want to know how to like add those deserve elements into the UI. So this is uh a pattern where basically first you show as I said you show the user in the first step or on the first page what they need to see really the basics um and then maybe on the next pages uh or on some secondary pages or in the next step of the flow you show them secondary actions secondary information that they might need to see um more advanced information uh that maybe they didn't need to think about at the first step um and that way they kind of don't get overloaded from the very beginning. So, one good example of this is um on a DEX, for example, uh at the very bottom here by above the swap button, you know, you'll see uh the the total amount that that you're going to be paying for this transaction in terms of like fees uh and gas. Um but then uh if the user wants, they can open up that drop down and see more details of this. Right?

This is a good example of of progressive disclosure. Another example also on Dex's where um you know at first you just see kind of the information that you're that that that you really need to do to do the swap but then on the confirmation screen the second step second step um you see more detailed information and then you also see maybe like a secondary uh action like uh you know if you want to send the tokens to a different uh a different wallet. Um, another is to uh explain what's happening to users because users actually don't want everything to be abstracted away. Um, so this is an example from an old version of uh cow swap where as the swap was happening uh the user would see a progress bar that would kind of slowly fill and then you know if there was a problem uh like in this example you see here the limit price is out of market then um it would like tell the user there was an error. um users didn't like this and uh as I was doing research to kind of understand why they didn't like it um I realized that it wasn't that it didn't give enough information because it did um but it was too abstract.

It was abstracted away. It didn't uh accurately reflect how cow swap works under the hood. And users could tell that. Users were like, "This doesn't seem real to me. This seems fake.

It seems like there's something else going on that this UI is not telling me about." and they were right. So, we tried a bunch of different things and what we came up with was um kind of a a step-by-step model instead. So, now if you do a trade- on cow swap, you see uh step one, step two, step three um and then kind of the you know the the confirmation at the end. Um and the steps here are actually 100% accurate.

They are all tied to the actual status of the order in our backend. Um and and we we wanted to make sure that this wasn't too technical uh for users. Uh that it was accurate but not too technical. So what we did was um you know we made it pretty simple. Uh the the text for each step is a maximum of one or two sentences.

Uh we didn't write a bunch of technical language here. Uh we used words that people are familiar with. Batch. Everybody knows what a batch is. Uh competition.

People know what a competition is. The winner, people know what that is. Um and so when users saw that um they uh they liked it they liked it a lot more. In fact uh even users who hadn't used cow swap before um ended up really liking this and the reason was not because they understood a bunch of technical things about what cow swap was doing in the back end. Um but it was just because they saw the information that they needed to see.

Uh they went away with you know I know what's happening to my order. I know what's going to happen next. Um I know where I can click if I want to like go get more technical information about what's happening and uh and I know that you know cows is doing something here and you know maybe I don't need to know all the details about it but like I know why my order is taking maybe a long time because I know what what's happening to it and that's enough you know and this is an example of how um non-technical doesn't have to mean not complex or super basic or super abstracted away because people just won't be able to understand Uh just a couple other things that you can keep in mind. Um understand who your or your target user is and what their mental model is. Like I said, you know, for our users, uh we don't expect users to know a lot of technical things.

So we use concepts they're already familiar with batching competition. Uh Facebook when they first, you know, launched, they were using the directory model, right? They made it look like a physical directory because that was something people were familiar with. So whatever your users are already kind of familiar with, think about that and design with that in mind. provide pathways for people to dig deeper.

They can click and do get a learn more get an information and uh information icon and you know go learn more technical information if they want to tell the user how to fix a problem. I was recently using a competitor Dex, not going to say who, and uh they there was an an error because it said um the the route couldn't be found for my my trade. And the error message was um route could not be found. Please use a different sell token or buy token. That's not very helpful because, you know, it's like, I came to this DEX to like buy this new meme coin, but uh while I'm here, I guess I'll just buy some ETH or something.

Like, that's not a realistic uh that's not a realistic scenario, right? Um so, if you're going to provide, you know, an error message, tell the user what's happening, tell them how to fix it if it's possible. Uh give them a link to where they can go, like in this example, to go fix it. um tell them, you know, uh where to go to like let you know about this error if there's really nothing they can do about it in that moment so at least they feel like they've been able to uh to do something. Um and if there's really nothing they can do, just like be honest and just like tell them like we're working on it, guys.

Sorry. Like, you know, don't lie to them. Uh learn what your user's main questions are and try to preemptively answer those in the UI if you can. So, you know, we had a lot of questions around um when around limit orders specifically around, you know, like where is the price coming from for this limit order and like how do I know when my uh limit order is going to execute? And so we we put that information right there in the UI so people can see it.

And we tested these messages to make sure that they were pretty understandable by most people. Um sometimes you might want to be opinionated with your DAP, but you need to explain to users why. What I mean by opinionated is um if you think about web 2 for example, a lot of times the apps will make uh decisions for you so that you're you know you as a user are kind of not overloaded by decisions. So like if you think about Tik Tok for example, you can't decide what's on your for you page, right? Um the app is making that decision for you.

Sometimes that's good, but sometimes uh it limits users freedom. So uh you want to be careful about that. If you are making decisions um that uh making decisions for the user or changing something for the user on their behalf, you want to let them know about that. You want to give them the option to change it. Uh for example, here um on cow swap sometimes we uh we have a dynamic slippage setting where um for certain token pairs uh maybe if there's a lot of volatility, the slippage will kind of automatically uh be algorithmically adjusted to make sure that that transaction is likely to go through.

But we tell the user about that and we give them the option to change it if they want. Uh don't assume that users know a lot of things. Give them plenty of information. Give them plenty of explainers, you know, information icons. Uh links to um to different official pages if necessary to uh contracts so they can check them out, verify them for themselves.

um information about edge cases or about like maybe when a different uh action would actually be better for them and just like tell people what your DAP does and like why they should use it. A lot of times we neglect this in web 3 and then people are like why should I use this DAP because you didn't actually put that in your UI that's why um provide help provide FAQ but like don't like validate your FAQ with the users make sure that the questions in your FAQ are you questions the actual users ask not just questions that you would ask sorry I was supposed to skip this slide Most importantly, talk to your users. Um, it's like I said, it's not that hard. Um, and you can do it. You can do this in a lot of different ways that people don't think about.

So, you know, you can test your DAP. Obviously, if you don't have a DAP, you can test a prototype of your DAP. Um, if you don't have a prototype, you can test a competitor DAP. Like, if you're building something right now, you know what your competitors are going to be. Like, go test that DAP with users.

You can test your dev docs to make sure that the the the that it's uh understandable uh by you know other devs who might want to work work on your your protocol. A couple of tools you can use for this. If you want to DIY it, you can just use type form, Google forms, you know, send out a survey to your Discord, get people to sign up for uh for research, etc. Um I really like DSpark uh on the left here. Um DSpark is a web 3 focused platform.

They recruit web 3 users for you. They handle the um the the uh signing them up and and handling the payouts for them for their compensation, everything like that. It's super useful. I really recommend that you use it. Here are a couple of um resources for unmodderated testing of DAPs.

If you don't want to sit and do the test individually yourself, you just set up the test questions and then uh the app will walk the user through the test. And then it's always nice as well obviously to have a place that's not Discord where uh people can go and leave feedback for your DAP. um or you know get some help if they need it. So that's my talk. Thank you.

Um and I have QR codes here on the left if you want to access these slides and on the right um is a uh web 3 UX um re web3 UX research 101 uh explainer and resource document made by my friend Christina at SAFE. It's really useful and um I think that you should check it out. That's it. Thank you so much, Mindy. So, [Music]