What is Web3 and what is Web3 Design? What are the special limitations and requirements of this field? What are the best practices for designing and building decentralized applications? How do you think about the usability problems in this space and how can we begin to solve them?
These are some of the questions that we’ve started to unravel and tackle while doing the research for the Web3 Design System in the last couple of months, and that we started to condense in a Web3 Design Decision Framework: a tool to help designers and developers alike make better design choices while creating their dApp.
What is a Web3 Design System?
With the Web3 Design System we aim at building something similar to Google’s Material Design but for the Web3:
- a series of guidelines and Design Principles, focused around the specific UX needs of distributed applications
- a library of components for developers toquickly develop Dapp front-ends, through simple and composable web3 specific componentsand UX flows, that automatically implementthe Web3 Design Principles and the other UX guidelines
Why a Web3 Design System is important
As highlighted in many other places , currently the experience of using decentralized applications is overwhelmingly difficult and scares a lot of novice users away.
If we want mass adoption of Ethereum and decentralized applications, we must provide the users with understandable and consistent interaction patterns, so that they can learn them through repetition: whether they end up on Aragon or Status or another dApp, users need to see the same treatment for informing how to “unlock a wallet”, or what’s the “status of a Transaction” that has been sent and other interactions that are unique to the Web3.
We are talking about the functionality, the application’s behaviour, which should of course be customizable and brandable by each company.
Like “pinching” to zoom, or “swiping” to change a screen have become second nature to us, we are now building the new interaction patterns that will become the standards of using Web3 decentralized applications.
Methodology — How we are doing it
In the Web3 Design Principles that I published at the beginning of the year there are some Web3 components that hint at how we could solve certain usability problems of web3 distributed Application.
However some ideas presented in that article were supported by a much lighter research if compared with the extensive one that we are now undertaking.
For the last couple of months we’ve started the research for the Web3 Design System thanks to a generous Nest grant from Aragon.
In this initial phase we are interviewing designers, front-end developers, user researchers, product people, anyone who has spoken to users in the Ethereum space, and possibly the users themselves.
(📌📣 we are still doing the interviews, so if you have insights for us please get in contact )
The research phase aims at gathering and analysing what are the most important and urgent UX problems in the blockchain space and what are the current solutions or best practices that designers and developers are seeing, so that we can bake them into the components that we and the community will design and build.
Devcon4 and the various Design Systems in the space
Devcon4 was the first time we had a Design track (and a Systems & Society track too) in a conference historically dedicated to developers.
Among the many awesome design activities, talks, sessions and workshops, 3 efforts around Web3 Design Systems have been presented at Devcon:
- our own Open Source Community driven Web3 Design System
- Rimble - Consensys Design System
- Lorikeet - Aragon promoted but community adopted Web3 Design System
We will very probably converge on Lorikeet and build our own components on the strong foundation that Aragon built and that others are starting to improve and build upon.
The Web3 Design Decision Framework
At Devcon we presented the initial insights that we extracted from the interviews, which we formalised into the Web3 Design Decision Framework, a tool, a mental framework to help you think about the problems users have with the blockchain and Web3 dApps, and how to start solving them.
❓ The Web3 Problem Space
We’ve asked to people and companies that we’ve interviewed, what are the questions their users have, about using their dApp or about the blockchain in general.
Some questions are fun, like
“how do I find these projects in the OTHER internet?”
and other questions are fundamental to the space, like
“why should I care?”
We tried to make sense of all these questions and problems and we found out that there are 2 macro categories in which these problems can fit:
1 — problems that have to do with the technical workings of the blockchain
2 — doubts that relate to fundamental concepts of decentralization
Of course, in some cases, there is some obvious overlap
We then mapped all these questions into this Venn diagram that we call the “Problem Space”.
In the set of technicalities fit questions like “what is gas?” or “how do I get ETH?”;
while in the fundamental to decentralization set we find questions users have like “can you reset my private key” which indicate their misunderstanding of the PURPOSE of decentralized technologies.
Decentralization requires new mental models. Moreover the Blockchain space is filled with new complicated concepts and we are doing a bad job at explaining them!
Of course these sets are a crude simplification and there are possible subcategories, even more than the ones shown here.
But there are 2 common thoughts and patterns that jumped out:
On one side, we’ve seen is that there is a consensus among many that we’ve interviewed that decentralization requires new mental models.
For example users struggle to understand that the data is not owned by one company or service, revealed by their confusion when they are presented with 2 different wallets that show the same token amounts).
The second unanimous belief is that the Web3 is filled with new complicated concepts that are completely unfamiliar to users, like gas, transactions, private keys, Tokens, etc
It appears that, not only they are complicated concepts, but we are also doing a bad job at explaining them.
❗️ The Web3 Solution Space
When we rationalised the solutions that the interviewers told us are working for some of these problems, we found out what we call the “Solution Space”
It’s a tool, a mental framework, that will help us in the design of the components for the Web3 Design System and that can help you too make design decision about how to solve the problems your users have.
There are mainly 2 different solutions:
- either you can hide or abstract away a technical problem that is making the life of the user difficult,
- or you explain it better
Web3 Design Problems are Multidimensional !
An example will make things much more clearer.
One of the first interesting things that we discovered is that Web3 Design Problems are multidimensional, which is a fancy way of saying that they can fall in multiple buckets/categories in the problem space and also in the solution space.
For example, users have many different questions around gas, but these can be grouped together into 3 main categories:
- “technicalities” that can be hidden to them through by using some technical solution
- “technicalities” that unfortunately we don’t yet know how to hide from the user and that hence we can only make the effort of explaining better
- and questions that are fundamental to decentralization that we should not hide at all and can only try to find better explanations for
For example, practically every user asked “what is gas?”, “what is gas price?”, “what is the gas limit?”
All these questions relate to some technical mechanism of how Ethereum works and different wallets learned and taught us that it worked well to hide these optional settings from the user, giving them a simple interface and pre-made choices.
Another technical solution that recently emerged and that completely abstracts away gas (and therefore gas price and limit choices from the user), is the new pattern of the Universal logins by Alex Van de Sande and the MetaTransactions that go with it.
The Ethereum Name Service (ENS) is also another technical solution that can hide the complexity of hashes behind a simple human readable name. Although it must be said that some of the interviewees have pointed to situations in which they think addresses should be shown.
Another question is “why does gas have different costs in different times?” and this although it’s still a technical question can’t be yet hidden away (probably until we create gas futures) because a user who performs the same action on a dApp in different moments will see the different fees she had to pay and will of course start to ask questions about them.
In this case, the solution space tells you that you need to find a better explanation; until of course a technical solution comes and we can push the problem into the “hide” bucket.
For important questions like “Why do I have to pay for gas?” or “does the dApp get the gas fee?” relate to understanding how the Ethereum flavour of decentralization works. In this case you can only try to find a better explanation and this should not be hidden.
📌 Solutions: best practices for subsets of the solutions space
The Solution space gives hints at how you can tackle part of the problems, according to how you can classify them.
From the interviews we’ve extracted some key insights on how we and you can use this solution space
1 — hide or abstract away complicated technicalities, if you can
Plus there is a spreading consensus that it is ok to use a different degree of centralization, at least temporarily for the new users, so that they don’t get scared away.
We talked about this in the Alliance for Mass adoption proposal, where you can initially hide the complexities of interacting with the blockchain through a MetaTransactions layer, or in other cases, through a centralized server to help onboard the users.
Of course this is only a temporary solution and you should, at a later stage, onboard the users onto the fully decentralized solution.
2 — explain better the technicalities you can’t hide
For technicalities that can’t yet be abstracted away you can only try to explain better and to do that, you can use analogies with mechanisms that the users already know.
For example, if you are designing a financial application you can take inspiration from the experience of banking apps that will be familiar to the users.
3 — explain better the topics relating to the essence of decentralization, starting with the why.
For topics or problems that relate to the fundamentals of decentralization you only should explain them better and you can help you with those tips:
- start with the “why”, the motivating factors,
- which means to begin with explaining the BENEFITS, the ADVANTAGES of using this particular dApp, instead of explaining how it works, like every dApp is doing today
In the presentation that we gave at Devcon we also added a couple of other examples, around transactions and private keys, and a couple of generic insights. Check the video here 🎥
🛠 Next steps — test the framework
“A model is a good model if first it interprets a wide range of observations in terms of a simple and elegant model, and second if the model makes definite predictions that can be tested, and possibly falsified, by observation” — Stephen Hawking
The Web3 Design Decision Framework wants to be a tool to help you design better solutions.
This is a theoretical model for Web3 Design, but as Stephen Hawking let us understood it needs to be tested by you to see if it fits also your observations and if it effectively helps you predict solutions that will actually work better.
Gendry and Nas from the FlightPlan run a Blockchain Product Design course and they have tested the framework with designers who are new to the Web3 space. Some early learnings have show that:
- 1- Most problems look like technicalities at first to users and designers new to this space; it requires a level of expertise in web3 design to categorise problems into “fundamental to decentralisation”.
- 2 - However for experienced Web3 designers, the framework is incredibly valuable as a methodological approach adding precision to categorising user research. It provides much needed guidance for decisions on what to abstract vs. what to explain to users”
and she adds: “we hope to add more detail to this framework as we identify more of the nuanced needs for different Dapp user types.”
Please test it and tell us if it works and how to improve on it.
You can either write me on Twitter (@lyricalpolymath ) or on Telegram (@lyricalpolymath), and also join the conversation on the dedicated Conflux Forum post.
Beyond this, we are still in the interviews phase so if you have talked to users or have any insights that you learned while designing or developing your dApp, please let us know, we’d love to interview you.
Acknowledgments
- 🙏 This research was made possible thanks to a generous grant by Aragon
- 🙏🙏 of course these findings would have not been possible without the insights and experience of the many people that we’ve interviewed…to all of you, a big thank you!
