Designing Decentralized Storage:Without Better UX, Decentralization Remains an Underutilized...

Hey, can you guys hear me all right, feeling good? Thank you, first of all, so much for staying in. I know there is a lunch outside. The venue is amazing, but I think we have some or opportunity to look at a few things today that may be interesting, and I hope that I do a good job of really captivating you guys, but we'll see. I'm a designer.

Previously, I was an engineer, but then I quit because it was really hard. So what you'll see today is a process of thinking about stuff that I knew very little about, and just looking at them through the lens of someone who just wants to abstract some things, really look at things that we want to emphasize, and make sure that they're usable. The speakers that came before me today, I think, did a good job rooting us in the narratives, the tech, also the need for good UX, good products, and what I want to do today is just take a different approach and just go a bit more towards the practical aspect. I get that a lot of people here are building their own products, and what happens when, for example, you don't have a designer? What can you do to improve the products that the end users are going to see?

I get all of you use your bathroom, but maybe not everyone knows where the pipes on your house go. And that's how I feel a bit sometimes looking at some of the tech stacks and the products that I deal with daily, which is, what the hell is this? What is it actually doing, and how can I surface this to the end user so that it makes a bit more sense? And usually, we do not know, again, where the pipes go, but we need to find easy ways to understand what exactly we want to achieve, or else we end up getting this. You can poop and wash your hands, I think, maybe, but probably it's not the intended outcome, and I also want to think that you would not like to return to something looking like this.

Especially in a world where attention is a commodity, we need to make sure that our users, when they see our products, they see them looking at their best, even if they obviously have some underlying issues that we cannot circumvent. And this is especially important when talking about decentralization and all the tech that we work with, because there are some shortcomings that we know that exist, but I think that through great design, we can actually bypass them, really assume that they are there, but try to make sure that our users not experience the bad parts. And here, just to contrast with what you guys are seeing, like a Wes Anderson type of toilet, which is much better, but what I want to prove here is that what we're trying to get at is this is the part that we usually do not see, but if we don't fix what's in here, probably what the user will see there is not going to work, like you've seen before. So essentially, I'm proposing we deal with design thinking about two layers of design, which is developer UX and user UX. People are usually most worried or concerned about how the product looks to the others outside, but I want to believe that if we do not fix how things look and feel for the builders of the space, they don't have great incentives to build great products to end with.

And there were discussions earlier about adoption and probably time to market, why things don't have that adoption, and I think it's mostly because we're not onboarding people correctly, we're not managing incentives the right way, and we have to look at what products are working. And I'm not talking again about how they're looking visually, if they're beautiful, but essentially if the experience to start using them to begin with is working or correct. So what can we do to improve developer user experience? There are a set of things that I want to show you guys today, and I'm pretty much done talking about in abstract, I'm going to start showing what I want to show you. But I just want to make a disclaimer that things that you're going to see today I have no association with these products, I'm not endorsing any of them.

There are a lot of centralized alternatives to decentralized storage that I'll be showing here today, but I just want to put them side-by-side so we can look at them and really see maybe how can we do a bit better. And some of these things obviously there are at protocol level, so there's not much that we can do other than advocating for change, requesting, or being involved in them, like trying to really change from within. But probably there's also some good things that we can look at centralized options as a guidance. Onboarding. I think the way we are onboarding currently these users or developers, because developers are users of these protocols, is not ideal.

We should instead minimize the setup and the delayed decisions as much as possible and let devs show value before asking for tokens. Here I have side-by-side two products, it's Cloudflare and Filecoin. And just the idea of just trying to go to both of these websites regardless if they're good-looking or not, it's evident how easy it is to access. I'm not sure if this is going to play the video, but I had videos here that showed that for Cloudflare, it's basically just two clicks to get to pricing clarity. So, you essentially have a clear idea of good UX copywriting, which enables you to get started and understand how much something is going to cost pretty easily.

And whereas with other options, you tend to get into a maze without understanding how much something costs, how to get started, where are things that you eventually will need. We need to make incentives intuitive and fair. Incentives, and I'm talking not tokenomics, obviously some of these protocols require you to have the tokens. But I think that as much as possible, abstraction on some of these parts are required in order for users to really understand what they're dealing with. We need to be able to compare apples to apples so that users can make a decision on what to use.

And obviously, there's the ethical imperative and all of the advantages that we know of are using decentralized storage. But in the end, it's all due to how easy it is to use and is it going to cost me more. And cost can be effective cost when I'm looking at something like a subscription or even dev time. I'm going to take the first example that I'm going to show today. And I took a stab at some of these products where I have the current state and some suggestions of improvement of designs.

And I'm going to run you through them so you can see how they look like. So first is R Drive built on our weave. And this is their pricing page, which essentially is a great deal of a motivation for someone who wants to use any of this. But what is failing here is that they're not surfacing anything about what's great about the product and the features. And also providing it in a UI that's fairly different from what people are used to seeing.

So my first approach was doing this. And what we're trying to do is just bring in a direct comparison so it's easy to see. Like, okay, centralized option, cost is this, these are the features, this is the R Drive, this is what we offer, and a clear call to action. Also, and again, I'm going to really emphasize this, correct or at least improved UX copywriting also goes a long way. What are these guys doing?

Like what are the features? R Weave offers permanent storage. So you pay once and it gets stored forever. So why not say it clearly? And in order to compare apples to apples, when people look at these different products, they need to be able to see what Dropbox is going to cost when we compare scales, right?

So it's difficult to tell. All of these examples I'm using like a 100-year scale to make sense of all of it. But again, what we're bringing in is a really recognizable pattern instead of a complex calculator. And again, I know that we can have calculators still. That's why like you can have a dropdown here that still changes the values.

But what we want to do, this is hard enough for us to try to reinvent the wheel. So just bring in some normality and fit in with the rest of the guys that are already bringing in your users. This is a different approach like a redesign option to for a redesign, which kind of looks like something that you've seen a million times. Just try to simplify and really bring in the value that the value prop that you have for your product. At the end, developer UX is what enables end-user UX.

If we not make it easier for the developer to make the choice to use the product, it's really hard for then the end product to look great. Again, if you don't have a designer or someone caring about these, I think there are very or a few easy points that I would like to mention that maybe when you're building your products, you think about them. And again, some of these things, they are very, are things that we don't even think about because they're so normal on all the products. But I think that we have to think about them when building it. We may not control protocol complexity, but we can still shape user experience around it.

So how do we improve what users see, feel, and trust when protocol constraints exist? Essentially, can devs do something? And I think yes, yes, for sure. We adopt UX primitives to help mitigate current limitations and meet user expectations across four pillars. And these four pillars, especially for decentralized tech, I think are very important and are usually creating a lot of issues at the front speed.

Design for perceived performance even if protocol reality lags. What often happens is that things are slow because it's on the blockchain and decentralized protocols, some of them obviously, it all varies, but have this thing that we need to create barriers so that users do not feel that it's slow. I have an example here for Boson. Obviously, the videos are not working, but gladly I have a screenshot here. And this is what it looks like, the product loading.

It takes maybe like six seconds to load the UI. So this is where you are when you first load the product. This is a decentralized marketplace. And what can we do in order to not show this? Because users do not care what is the infrastructure that is powering the product.

They really don't give a crap. So when they come to website and see it looking like this, they're going to bounce, right? But there are a few things that we can do easily to take this. We're not changing infra, we're just applying some UX and hiding the problem, which is essentially what we did in the sink a few slides back. We're going to work on optimistic UI, progressive disclosure, missing non-blocking UI states, or even the concept of hybrid architecture when thinking about these things.

So this is an idea of a redesign. So taking what you see in here, this example, and hiding a few things so it takes or gives time to load, and surfacing only a few. So essentially just hiding a few things. Like if this is the end of the browser, we can just do some sort of like progressive loading, putting it slightly lower down the page to give it some time. Another thing that we can do is use a concept of an hybrid architecture, which is think about a product and really think deep what things need to be stored in a decentralized manner, and only those are being surfaced that way, and everything else can be centralized or be coming from a different method.

For example, here we just promoted this banner and just added some content, but this doesn't have to be on-chain. The things that are important here for this product would be like brands, sellers, and any impacts of products and things like that. Another example of a redesign is by using an optimistic UI, and what this is is just not breaking the layout, which is something that in their case, they broke a lot. Like if you clicked, it went to a different page. It was still waiting for things to load, and these days we see all the time using a lot of skeletons and things like that.

I would go a bit further just using those types of ideas, but making it branded so that it feels it's not ideal, but it's not like super bad, which is what we're trying to do. We're just trying to surface a few things, but hide the others so that products do not suck. Access. We need to be able to design for observability, which is like, can I see my stuff? By adding status indicators, error messaging, and other things that – I have an image here of also Thrasher, which gives a good example of this.

We need to give the user previews of what they're going to see, and some of these centralized storage products make it a bit hard to understand if my upload is actually there or not. People are used to a certain pattern that reveals those. I have here Vercel versus Pinata, which is kind of like surfacing the things that I believe Vercel is doing interesting, like just visibility of status, metrics, a code snippet that it's easy for you to just copy and start using, and real-time feedback with those, just signaling when something happens. You drop a file and it's actually uploaded. Contrasting this to Pinata, there are a few things that they decided on purpose not to show.

For example, that all files are pinned by default, which I think would be interesting to add, and again, some of the things we need to make redundant for people to really understand is that they can't access it and or have trust, and this leads me to the next, security. Designed for perceived safety, informing users on how their data is protected. Showing encryption storage or region info through like iconography and things like that, contextual cues like tooltips, term permanence info, or any protocol-specific information that needs to be there for them to assess that the file is secure, it's of utmost importance. Trust. Will it still be there?

Promote those trusts by surfacing redundancy, file health dashboards, like number copies where it's stored, decentralization meters, UI prompts. When user needs to take an action in order to continue having the file stored, these are things that can help us here, and in the end, there's a question, which is when will decentralized storage be the default, and I think that if we are able to improve the whole experience from developers to end users will benefit, and all of the ethical imperatives that based the ideals of decentralization will survive, grow strong, because in the end, no one wants to go and use that toilet from the beginning, but everyone wants to access great, great bathrooms. Thank you so much. Thank you. We do have a couple of questions and a bunch of questions that are for some reason for another session.

I don't think we should talk about those. Let's do the first two ones. Hybrid architectures require a higher maintenance effort. Won't this push us to rather drop the more decentralized part of the fast for our users? Any way to counter this?

I would even add that costs even more money, but it's kind of like, I think, a choice, right? Are you having users at this stage or not? Can you make compromises? I would put it that way, honestly. All right, and then another question, this is pretty product focused and translates fairly well to Web 2.

0, like the stuff you talked about. Any ideas for how we could improve, for example, Wallet UX doesn't translate so well to Web 2.0 maybe? Yeah. Yeah, for sure.

Well, Wallet UX, I was previously lead designer for Talisman Wallet, so actually I know of wallets, sort of. And I think that there's obviously a great transition towards account abstraction and all of that, that I think it's already powering a big move in Wallet UX. I honestly, I think wallets are pretty far ahead when it comes, when comparing to, and for like the storage. So I'm not sure exactly how the examples that I showed today can translate directly. But what I say is, when we start talking about complex things like private keys, and in order to onboard more users, if that's the goal, it's all dependent on what your goal, what you want users to do.

I think that trying to create all of those or more abstractions will help ease of onboard. And I think that are the things that I believe could apply for wallets. All right, thank you for that. I think the last three questions accidentally ended up here. You can answer them if you want.

I wouldn't want to.