 So, what is a design system? Traditionally, design systems are a set of reusable components that are backed by some sort of standards or guidelines. These can be assembled together to build any number of applications, and they kind of enable products to prototype and test their products faster. So, some of the design systems that we're familiar with today are such things as material design, angular, and bootstrap. And as we know today, web users for Web 3 have to learn very new concepts, mental models, and patterns with each application that they use on Web 3. And like the early days of the internet, we're coming up with new patterns, and eventually we'll get to a place where design is kind of coalesced into a set of standards making the users to bounce from one application to the next. So in the aspect, Web 3 has kind of taken us back to where user experience was in the 90s. There's a lot of excitement, a lot of experimentation going on, but we need to establish some new patterns to serve our users and get them through the hurdles of Web 3. So, I'm going to be introducing the Web 3 design system team. What we are is a federated design systems team, what that means is we each work for different organizations, and we've kind of, through community efforts, come together to spearhead the use, UX, and usability issues in the ecosystem. Our goal is to create a resource in an open source format that anyone can make it on their own and rely upon whether you're a designer or a developer to prototype and test our products faster. We hope to do this through VEL research and validated component library, but we've been very mindful of jumping into the components because let's be realistic, there's not a lot of user data out there, and traditional UX research methods kind of start to fall apart when you put them in front of people with Web 3 ecosystem. So currently we've been working with some of the top teams and projects that have actually been working on solving the UX issues in the space for the past few years. So we're learning from the challenges and the issues that they face and trying to bring everything in a cohesive manner so that not people are creating siloed solutions. Our goal is to open up our project to anyone who's creating any components or any research to kind of help us facilitate that better. I'm going to pass it off to Beletran to speak about the problem space. I need to turn it on. Yes, thank you. At the beginning of the year we published the Web 3 design principles that tried to propose some of the components or hinted at some of the possible components. However, like Akil said, the research was much lighter than the thorough one that we are doing right now. We are interviewing everybody in the space that has stopped to users with intention of mapping up those problems and the user's face and the current solutions to later create this Web 3 design system, this library of components and the guidelines of best user practices. So you know all of the problems. There's plenty of them. Today is a very confusing space. We can share some, we don't have any components like we were saying yet, but what we can share is the second best thing, which is a mental framework about how to go about and think and solve these problems. And we've asked these companies what are the questions the users have and we try to map them out and gather them. Some are fun, like how do I find these projects in the other internet? Or some are very important, like why should I care? These are questions that users really ask. And so we try to make sense of all these questions and we came up with this pattern that we call the problem space, to map them out in a problem space. And we found the problems can be categorizing two buckets, like problems that are relating to technicalities of the blockchain or decentralization in itself and other problems that are fundamental to the explanation about decentralization. And of course there's some obvious overlap and there are also subcategories we will see. So we put these questions, we map them into this problem space, into this diagram. And in the technical buckets you have questions like what is gas, what is gas price, how do I get the ETH, etc. And in the fundamental part of decentralization, we find questions that are more important like how or can you reset my private key, which speak to the misunderstanding of users of the purpose of decentralized technology. And I was mentioning subcategories, of course there is consensus among many of the interviewed people that decentralization, like Akhil was mentioning, requires new mental models. And besides this, we also have new complicated concepts like gas, transactions, tokens, private keys. These are completely new to the users and they are unfamiliar. And so not only they are complicated concepts, but it appears today we are doing a very bad job at explaining them. And so advancing the possible solutions that the creators, the developers and designers are using and they are seeing that work into this problem space. We found out this, that we call the solution space, which reduces the possible solutions to two, which is either hide the complexity of the technology or explain it better. And we will see in a minute how to do it. So let's see an example, for example, all these problems are multi-dimensional. It means that the questions relating, for example, to gas fall in various of those buckets and in various possible solutions. For example, in the bottom part, the questions, what is gas? What is gas price, etc. Those are technicalities that if possible we should hide and the missed team has taught us how to hide them progressively from the user. Then there are questions like, why does gas have varying different costs at different times? This, although we hope to be able to hide it one day, today there's not a technical solution yet. And if the user sees different fees in different moments for the same action, they will still be asking why is it different? So you need simply to be explaining what is happening in the back. And on the top part, there are questions that relate to misunderstanding of decentralization itself, like why do I have to pay gas? Or does the theorem foundation get the gas? Or why do I have to pay the gas too? So these things you need right now only to find better solutions. And this solution space can help you make better design decisions. And it will help us design decisions for the components. So the key insights is on the bottom part, the technicalities hide or obstruct them away and we have patterns that Akil will mention that today help us, for example, hide gas. Or there is a consensus among the interviewed people that it is okay for newcomers to have different degrees of centralization, okay? That you can put a centralized service to simplify the experience of the newcomer. But as soon as possible, onboard them onto the real decentralized and educate them to that real decentralization. For technicalities that cannot be hidden yet, we hope one day we can push it down into the hiding bucket. But today you should use analogies that they know. So if it's a financial application, use or look at patterns they're used, for example, in banking. And most importantly, for the fundamental parts of decentralization, these questions overarching and important, you should not hide them. And you should explain them better. And to explain them better, you have to start with the why. Why is it important? Why are we motivated by this? And something that came up from many is that you should start explaining the benefits and not the technology. This is something dabs are completely failing at doing. So we quickly went over the issues with gas, but the underlying issues for the problem space are that it's a very novel experience. People don't really understand what they have to pay fees for interfacing with the technology. Also, as Beltran was mentioning, there's variations in gas prices and that's not really conducive for mass adoption use cases. And another thing is the concept and the terminology of gas itself is very counterintuitive and the analogy doesn't match up with speed versus distance. But we've been starting to see a lot of emerging patterns come out from the research that we're doing through the community efforts. And those things are such as abstracting gas interactions for new users, so things such as universal logins, relays or meta transactions. And then other options have kind of emerged from places like MetaMask and MyCrypto where you give modular options for people to have low, fast or varying speeds. And one key insight was that we need to some way standardize gas moving forward for the entire ecosystem. Key management has a similar problem space where people don't really understand, can you reset my password? We need to do a better job of explaining how and why they should be backing up private keys and maybe just kind of get rid of seed phrases altogether. So the problem space with the key management is it disrupts the onboarding flow of the whole interface. People don't really know when or why or why they should be backing up keys. There's a confusion between passers and private keys and people kind of give them away just for air drops and lose all their finances. And the biggest issue is there's a lack of recoverability. So emerging patterns are progressive tiered security models. So you kind of work the user into knowing what a private key is through a progressive model like Universal Logins is using or maybe use some disposable keys that users don't actually have to back up or maybe do multiple device private keys on local wallets. Transactions, people don't really understand why it's taking so long and we need to get rid of things such as the nonce. So people don't really understand, one key insight that we got from the larger projects was that they don't understand the relationship between what a transaction is, what a wallet is, how that relates to the blockchain and what things like either scan actually enables for them to do. Because a lot of the sport tickets end up into either scans mailboxes where people don't really know that they're not responsible for anything. Emerging patterns out of this space are giving human readability and transparency to their transactions. So things like NAT spec and RAT spec that are coming out and then from the front UI perspective maybe giving in-app history and transaction context. Two main insights beyond the questions are everybody thinks that mobile will be the future of onboarding the next wave of users but everybody is working on desktop, some exceptions apply. And the second most important one relates to what we are trying to do also with the dev contract, design track, which is everybody agrees that designers need to be in the room since day one, since day zero actually. Simple smart contracts create complex UX patterns. So get a designer in your team from day one and I'll pass it to Gustavo. Sorry, yeah, thank you. And we will have also another slide where you can take a screenshot to come and talk to us. We want to interview you, get your insights and we will be posting this mental framework and also the future components. Gustavo. Thank you. Thank you. Thank you, Velter and Akil. My name is Gustavo, guys. I'm here with Consensus Design and I'm going to talk to you. I'm going to show you guys a little bit of what we are working with and what we hope to accomplish in this space and bring into this initiative and design systems. We are calling it RIMBLE and our mission is to make it easier for developers to build depths with outstanding UX. The way we're doing this is by partnering with some of the leading companies in the space and their design teams to learn about their insights, learn about their users and what their struggles are and how these companies have been solving them. We are going to take this insight and build a React component library for developers to start building depths with some patterns to start with and you don't have to do a lot of guessing from day one. Some of the stuff we hear about is gas and transactions. So MetaMask has been doing wonderful work with these teams and we want to take their insights. We want to build things like transaction components into RIMBLE that you can import and start using from day one. We are talking with bounties to figure out what their users are wondering. What happens when something goes to the blockchain? What's that all about? So we want to build things like prompts and alerts to educate users and get them to developers from day one. We are talking with companies like Uport to manage identity and we want to take their insights and build them into RIMBLE as well. We want to build the identity components to RIMBLE that you can start using from day one. So that's some of the things that we're working on. If you're interested, please visit rimble.consensus.design and join our spectrum chat and tell us what you think. Tell us about your pains, your hopes, and your dreams and we want to build this with you. So give us your feedback. So now we're just going to do a little panel discussion and pose some questions to you both. What do you think is the role of designers in this space? Would like Gustavo or? I can go, thank you. So we are here to simplify your lives and we want to show you that design or you should start thinking that design is not UI. This is a very important misconception of everybody. And design actually has a lot of tools. There's a lot of different types of design that can help you at different moments of your project. There is service design, system design, behavioral design. And all of these can help you in different moments of your creation of your apps or your application of your projects. So get a design co-founder. Come to the UX audits and see how your mindset can change after one hour of spending with a designer helping you through your own app. So I think you made a really good point about service design and systems design. How do you think we can get that seat on the table as designers when people are actually creating these ecosystems and platforms and protocols? How do we engage the people as designers? So for sure, DevCon is working a bit for that. I hope that developers are working up, are waking up to that. Through the design system, we are making, trying to make your life easier. And maybe you discovered through that as well. Come to rimble consensus design and to on-conflux and hear and ask questions. And again, just talk to designers from day one. If you want to bring a designer into your team, you will see how it works. Yeah, just like you guys said, I think we have design at DevCon today this year. So I think that's a great start. Let's bring designers into the space. Let's involve designers from day one. Let's start talking about design, talking about design systems and get the conversation going. And I think that's how we really incorporate this into the ecosystem and into the blockchain space. So now we have designers in the space. How do you think we bring more users into the space? Well, I'm biased, I'm a designer. So my point of view is that design kind of can help solve everything. I think it's a problem-solving mindset. And I think we need designers tackling our biggest problems. So how do we do that? So I think we are, our design teams are tackling a lot of these problems, are tackling like thinking about users first and thinking about how blockchain affects their lives as opposed to just the technology. We need this technology to be used by humans. And I think that's, designers bring that into the space, thinking about people first. Yeah, so I think like you touch on like empathy and taking it from the user's perspective. So how can non-designers kind of facilitate that too? Because I think that's a key skill set that anyone can kind of enable. So is there some value that you can bring to the rest of the room to kind of enable that process? Something that you should be looking at, some readings. Yeah, I think like look at design. Look at, I mean, from a designer's point of view, like let's think about the users first. Let's think about their lives. Let's think about our grandpas and our nieces and our sisters and our moms and how blockchain is going to help their lives. We need this to be usable by everyone. So let's start there. We need to like think about the end user and what does the space look like in 10 years? I think you also have to be mindful of not marginalizing the people that we're building technology for. So if we're building this new paradigm of financial ecosystem, are we marginalizing maybe four billion people while we're doing this? So maybe having those conversations while developing these protocols as well. So maybe you could give a viewpoint on do you guys think we're at like the beginning of the web again or? Yeah, so we are starting a new adventure and it feels kind of stepping back. There are some similar things and some new things I think. We show the slide of the early Giosciiti's super ugly problems, okay? That was because people, the new creators did not know about kind of the standards to communicate and to tell on the web. And I've been teaching usability engineering. Jacob Nielsen's usability engineering. Sorry, remember that. And today it feels similar in the sense that we don't know the standards yet. We are still looking for them. But there is a very important difference from the early stages of the web, which is at the beginning of the web everybody knew what it was for and they wanted it. Everybody wanted to tap onto this global connected mindset of culture, commerce, et cetera. Today instead users ask why do I care? So we have a difference today that we need to solve. Decentralization is a cultural movement and as designers and developers also in the space we need to make a concept to therefore to bring societies to this new idea. Yeah, I think in terms of being back in the web 1.0 world, I think in terms of designing UI I don't think a lot has changed. We do have new paradigms and new UX flows and new problems that we have to tackle. However, I think one of the biggest things aside from UI and UX and visual things is these new ideas that we have instilling to our users. The idea of being responsible for your keys, the idea of owning your data, the idea of being the only person in control and nobody else can help you. Those things are 100% new to our space and we need to do a really, really good job of instilling that in our users if we're gonna move forward. Just to put a counterweight to that, do you think we should be bringing in existing mental models from web 2.0 even though we're designing these new systems or do we have the opportunity to step back and look at it from first principles and try to redesign the whole thing? Do you think that's conducive to what we're trying to do here or do you think that's... Yeah, sorry. I think we can definitely bring in whatever works. We see right now we're in the fork in the road where we see a lot of things where centralizing some services all of a sudden becomes, all of a sudden we can get carried away and get rid of all the benefits that we get through blockchain. Steve Frey has our heart so let's just use passwords and then we lose the user owning their data and their user being responsible. So I think we just need to be mindful of that and yeah, we have an opportunity right now to set the path and we need to really make blockchain useful and remember what it's here for and what the value is and keep that and do our best job to keep that and not relinquish it by just making things easier for users. We can try harder and we can make people learn this stuff. Do you want to add both, Ron? No, that's good. I think we've had these internal conversations all the time so maybe we can give an opportunity to the audience if they have any questions. I see your hand back there or... Nope, okay, back there, right there in the center. So to repeat the question, what is the thoughts between explicit education rather than implicit good design? Yeah, we struggle with that in our day-to-day jobs because of course, good design should not need explanations but in this case, we need to put onto the balance that we are giving new unfamiliar concepts to the users and all at once, it's like the fire hose. So one good design way of doing this is to progressively show and explain what these things are and what they are important are. So it's a balance that we need to struggle every day with. I don't think they're need-to-exclusive. I think good education is also a good design. I think on top of making things pretty and making things easier and reducing friction, we have to be mindful of necessary friction. We need to educate. We need to talk about blockchain and talk about this stuff and talk to your moms and your sisters and your nieces about blockchain and read articles and we need to instill it in the culture. We need to have people talking about it. We need to educate people on why it's important and why all this friction is necessary in order to build the future that we wanna have and not like step back into Web 2.0. I think another key point there is when we're educating people, we need to make sure that there's some sort of centralization to this decentralized ecosystem where people have a common terminology and a common set of frameworks to kind of actually wrap their heads around because if each project is creating their own set of standards in education, it gets very confusing for users to bounce from one to another. So that's why having opportunities for people to come in a room together and have these discussions is very imperative at this point in our life cycle for the ecosystem and hopefully we can start doing a better job with that. Any other additional questions? You're right here. Our room is right there. No plans as of yet, but everything is open. We really want all the people we can get in the community and Ethereum in the blockchain space is moving so fast that we need to know what developers are thinking about and what they're looking ahead and start tackling things before we even get there. I'm biased, of course, but the E&S should be everywhere. If you have users, if you have users, you need E&S. If you have complicated hashes or something, you can resolve them to a simple string. Other questions? Yeah, back there. Yes? Good question. How do we as designer keep up with a constantly and rapidly evolving ecosystem, the blockchain ecosystem? We don't sleep. We party hard. Rave fun. I think it's important also for designers to be educated to technology in this case. This is my personal opinion. It's one of the debates of the space also. There's a lot of new designers coming in who don't understand the technology as deeply, but I am one of those that think it's important for designers and for everybody to learn about technology in general. Also be mindful, we were supposed to have four people here today and only three made it. She was a party hard. No, no. Additional questions? Designer, tools for the cooperation between designers and developers. In our interviews, we are analyzing that and how to better integrate and make concerted effort that designers are since day one on working together with the developers. So one key insight we got from the interviews was when people are prototyping these tools, they're using Figma or these existing tools, but that doesn't really give you a realistic user feedback because people aren't waiting for those load times or when they click everything seems so smooth, they're like, yeah, this is awesome from the existing patterns, but you need to have some sort of test network or some sort of application that kind of facilitates that. So he's basically saying that people don't really need to understand protocols in web 2.0, but it's kind of imperative for the decentralized technology stack for people to understand these to actually benefit from the value. Exactly, we also ask, do users need to know about the blockchain and to all the people that we interface? And so sorry to just step back, he's saying, is it limiting, having to know that, is it limiting to mass adoption or will we ever get to a point? I have faith in us that we will bring it and today we had an awesome onboarding track, onboarding breakout where a lot of people tried and tackled to solve these problems to hide and bring everything in the hide bucket, okay? You have here Universal Logins, Alex van de Sands, he created also an awesome tool to hide a lot of that complexity, gas, et cetera, and private keys. And I think we will get there, but there is this layer that is unavoidable to explain why we are doing this and why a decentralized Facebook will be a better than decentralized version. So that is, you need to explain and maybe hopefully not, you need to explain some technicality, hopefully you don't need. Also when other scalability solutions and sidechains and state channels coming in, I think it's gonna change the dynamics of the user interfaces and kind of make it more palatable for users because not everything needs to be decentralized, you can play around with that. So I think it's exciting to see where we're going and just last question, we have five seconds right there. Yeah, like that's one of our biggest things, right? Like onboarding, like the first step, the most important step is like one of the hardest steps in blockchain right now. So we are all working super hard to fix onboarding. If you guys will be going into the talks, there's like Universal Logins and there's like tons of solutions like popping in left and right. Sorry, were you talking about actually onboarding designers into the space? Yeah, so these efforts like Conflux, what consensus I think just onboarded like 70 designers in the past few years. So there's a lot of people that are doing great stuff and you saw workshops happening over DevCon. There was Gendry and NAS that did the mechanism design for you and the UX implications. Alex was there with his Universal Logins and kind of bringing that UX voice and I think it's just gonna get better from here. Thank you for everyone for your time and be sure to reach us to us.