UX Design in Web3, or why Web 1 + Web 2 does not equal Web3
For all of the attention around web3 and what technological advancement it brings, it’s still a fairly ill-defined idea, especially for end-user experiences. Largely a collection of newly available technical capabilities, web3 can be a daunting moniker, and one probably coined too early in the shaking out of what these new technologies will mean to the people that will use them.
Web 2.0 was itself a collection of discreet new capabilities — advanced browsers and the scripting languages to take advantage of them, the bandwidth advancements allowed for richer media and more fluid experiences, and new classes of mobile and always-connected devices.
After twenty-plus years, it’s easy to see how these capabilities changed our connected user experiences and the design profession as a whole. But at the time it was just as much of a chaotic rollercoaster of new nomenclature, paradigms, workflows, and experiences as this new web3 era feels like right now.
But, rather than regurgitating the sweeping promises and potential advantages of the new web3 world, we thought it would be valuable to look at some of the discrete technical advancements, both of Web 2.0 and web3, and what they mean for designers.
Web 2.0: When ‘Web Design’ Became ‘Product Design’
The early 2000s gave us rapid browser advancements and new languages to build with as well as new opportunities and challenges for designers.
In the previous Web 1 world of static web pages, a web designer was largely concerned with the same things a graphic designer in the print world dealt with — layout and presentation, information hierarchy, communication and reference-ability. Think newspapers, brochures, and encyclopedias, but online and with hyperlinks.
We were stoked when CSS allowed us to have text wrap around an image or use custom typefaces not already installed on a visitor's computer. We used to go crazy when a new experiment was posted to the CSS Zen Garden because we were finally seeing centuries-old print design techniques as possible in web design.
But, it was all still largely concerned with the presentation layer and the web was primarily a form of ‘media.’ While the experience was becoming richer every day, it wasn’t until some major technology advancements came along that we began to form a different understanding of what designing for the web meant and what we could do with it.
Some Key Elements of the Web 2.0 Tech Stack
AJAX (asynchronous javascript and XML) gave us dynamic content on websites. Being able to send and retrieve information to and from a database without refreshing the page — like submitting a comment and having it show up immediately — was huge. Websites were suddenly dynamic experiences.
AJAX – also sometimes called dHTML, or Dynamic HTML – was literally the defining characteristic of Web 2.0 before all of the other elements we identify as Web 2.0 were later added making it a full era.
It was a game changer for what it was like to design and program websites. No longer the read-only magazine-version of the internet, websites became interactive and more complex. Designers now had to factor in on-the-fly changes to content, the timing of interactions, and wildly shifting page layouts.
At the same time, increased bandwidth and multimedia capabilities gave us richer websites that could play back audio and video with embeddable plugins like Flash, RealPlayer, and Shockwave adding the extra dimensions of timelines, sound, and motion to our designs.
We became less constrained by dial-up modem speeds, so we crafted more complex web pages with multi-layered and capable interfaces and gained the ability to bring full applications to the web.
Flash may have finally lost out to the increasingly expanded capabilities of HTML+CSS+Javascript but only after decades of enabling wildly creative interactive experiences.
SSL certificates and HTTPS brought secure connectivity and allowed for more commerce to move online than ever before, requiring even more thoughtful approaches to designing workflows involving financial data and privacy.
Robust APIs and social graphs provided data connections and semantic understanding across websites, requiring designers to think not just about how data and content would be displayed on sites they were creating but also how others might incorporate that information into their own designs.
Mobile displays of various sizes required a consideration for usability and responsiveness across wide arrays of viewports, while their always-on cellular connectivity – and bandwidth constraints – brought new use cases and contexts to the forefront. We could no longer assume someone using a webapp was doing so from a desk or table in a “computing” context. Now they could be anywhere, on any size device, and involved in any number of real-world activities.
Along with those screen constraints came the readily apparent bandwidth constraints of early cellular connections. Ironically, many modern mobile devices have faster data connections than some user’s home broadband. The landscape of what constitutes the “primary interface” to the web has shifted wildly.
We were no longer simply designing static web pages, we were now designing dynamic web applications. This included the full interface and computing capabilities of any modern computer application but with their own new sets of complexities to contend with as a designer.
Web3: design is our only hope (says a designer)
Much like with Web 2.0, web3 brings a similar collection of new technologies designers need to incorporate into their skill sets. However, the shift from Web 1 to Web 2.0 was about newfound interactive and visual experience capabilities, where web3 brings a layer of meta capabilities. This fabric of connectivity between our personal identities, our devices, and our data/money/connections are profoundly different beasts to design for.
Concepts of identity, permanence, decentralization, ownership, and transparency are adjusting the concept of the web. Just as Web 2.0 was both a continuation of and advancement on Web 1.0, web3 builds on tried and true experiences of Web 2.0 while requiring new design patterns to incorporate its technical capabilities.
The best digital products will find ways to take advantage of the capabilities of blockchains and cryptographic signatures. Marrying them to the familiar experiences and capabilities of the Web 2.0 stack will create fully practical, useful, and eminently usable web applications augmented by the new technologies.
Basically, if we as designers do our jobs right, the users of this new web will not have to think about which parts of their experience are enabled by which parts of the technology. They will simply incorporate these new workflows and patterns into their daily lives as they’ve done with other user-facing enhancements to their digital experiences — simply, securely, and confidently.
Is there an AJAX of web3?
So far, the majority of technical advancements in web3 are not really user-facing or browser-based. Blockchains and tokens are the new technical underpinnings with decentralization and digital ownership being more conceptual outcomes of that technology. It can be hard for those of us that worked through the transition to the modern Web 2.0 world to see web3 discussed in the same transformative sense, at least for end users.
Because of that, we’re seeing a lot of behind-the-scenes conceptual complexity being wrapped in familiar interfaces and design patterns – ones our users are eminently comfortable with. Yet using UX patterns from the past to make folks comfortable in the present can provoke a false awareness of what’s going on under the covers since so much of web3 is formed around some very valuable (and also expensive) artifacts. “What’s going on?” is probably the biggest design problem we face.
If this technology is going to be fundamentally disruptive to the ideas of ownership and value as we’re told, informing users of what is really happening with their data, their funds, and their personal information is a must. For that to happen, more designers need to get involved and understand what’s going on behind the scenes in order to design for it.
Smart Contracts Are Actually Rudimentary Applications
Blockchains, especially compute-enabled ones like Ethereum, are providing new paradigms for building applications. The programs that run on these distributed systems are written in the form of smart contracts.
A smart contract is basically a set of functions that can be programmed to read and write information to blockchains in order to trade tokens and digital currency, generate (“mint”) NFTs, and a host of other functionality still to be dreamed up.
The smart contracts behind these programs are similar to most of the programming behind any other application, but have some fundamental differences in that they are locked after launched, will always run as designed (for better or worse), and the code behind them is fully public for all to see.
Transparency does not necessarily mean clarity. These contracts are still largely in the realm of the developers that understand how to create them. If transparency is going to be a web3 advantage non-developers should be impressed by, helpful interpretations are going to be necessary.
Decentralization
Decentralized architecture, where many nodes (or servers) are working together to keep the network alive – conceptually similar to Bittorrent for file serving — also uncouples parts of the user journey. A user’s (1) wallet software interacts with a (2) web application that leverages a (3) smart contract on a (4) blockchain. These are all technically separate entities, and you as the product builder/designer don’t always control every step of that journey. This is in pretty stark contrast to a traditional web app where the whole experience – from the webpage to the database – is a first-party concern.
Being decentralized can also come with slower transaction speeds, as multiple nodes need to confirm a transaction before it is considered “complete” and finalized. This can have pretty significant impacts on the user experience if not taken into account. There is still way too much head scratching in the web3 space because affordances have not been built to simply let people know the waiting is to be expected.
Permissionless-ness
All information on permissionless blockchains – like Bitcoin and Ethereum – is publicly available and can be accessed and transacted anonymously. This provides extreme transparency, exemplified by the ability to see what is stored in anyone’s wallet – if you know the address – as well as an ability to see the code behind smart contract programs. Not entirely unlike viewing the HTML source code of early websites.
Inherent openness provokes its own complexity. And the transparency makes storing sensitive data on the blockchain problematic.. Knowing-your-customer (KYC) is difficult, and still relies on Web 2.0-style centralized infrastructure. Fully permissionless architectures can be slower and more expensive to interact with as well.
Alternatively, there are other more centralized, permissioned blockchains providing better identity verification, privacy, and efficiency, but at the cost of losing the openness. Designing for applications on those permissioned platforms will be quite a bit different than the design patterns necessary for permissionless architectures.
There are both benefits and drawbacks in the permissionless paradigms, but we will likely see a beneficial blend of approaches that allow important areas to be fully open and decentralized, while leveraging permissioned interactions to provide a better experience.
Wallets
One of the key points of interaction in web3 applications is connecting, authenticating with, and approving transactions from “wallets”. These wallets can take the form of browser extensions (like Metamask), mobile applications (like Rainbow), and keyfob-style hardware devices (like Ledgers). Each of these methodologies present wildly different user experiences, while fundamentally doing the same thing; storing the private keys required to maintain control over your web3 presence. But the end result is so much more.
Wallets are probably the most visible aspect of a user’s experience in web3. Just like web3 has moved quickly past the initial, singular cryptocurrency trading functionality, wallets now have to accommodate a wide variety of functionality. They can act as an authentication mechanism (like a keychain), a stock portfolio (or ticker tape), an NFT portfolio display (art gallery), and mobile banking (debit card).
Whether it even makes sense for all of these pieces to be included in the same end-user application will be the subject of a whole other article, as well as whether or not the nomenclature of “wallet” is the right term given all the water it has to carry now.
Lots of web3 technical characteristics, but what about web3 user experiences?
Not all of the principles of designing for web3 applications are as heady and ethereal as permissionless-ness though. There are some clear needs for practical design patterns around a number of tangible user-facing issues right now.
- Be Real
- Be Clear
- Be Obvious
- Be Traceable
- Be Solid
Be real: Deliver complete and useful information
Lets face it, the nomenclature in crypto is rough. Contracts, gas, wallets, mints, airdrops, signatures, forks, emissions, fungibles, mining. These words all have real world definitions the crypto industry has analogized in ways that are sometimes meaningful and sometimes confounding.
Using clear language and imagery to describe what a user is working their way through when using your application is generally important enough, but when it involves enormously valuable assets, it can be dangerous – bordering on negligent – to allow for any confusion.
Make it clear what type of process they are undergoing. What is a “connect your wallet” transaction going to allow the application to do with the contents of the wallet? Who are they actually interacting with? What is going to happen after they approve a transaction? How do they revoke previously approved authorizations?
Be clear: Hashes make no sense
Blockchains are built on hashes, the long and inscrutable strings of letters and numbers that are the marker for every transaction, wallet address, contract, NFT, and token ever created.
App developers and designers should be doing everything they can to keep hashes far in the background and provide useful and referential information about what that hash actually represents. Displaying ENS domains, smart contract titles, and token names wherever possible goes a long way towards building a mental model of who and what users are interacting with.
Be obvious: Make processes, wait times, and transaction costs fully apparent
There’s a lot going on in a simple blockchain transaction, let alone something complex like bridging tokens across different chains. The more clarity you can give to the process, the better.
How long does minting one of your NFTs tend to take? What’s the average transaction cost (gas) vs what you’re paying now? What am I actually authorizing when I approve this request? What happens when I ‘stake’ something and where does it go?
These are all new concepts for the average web user, and none of it is obvious. Remember the lessons we learned from the classic product design bible, Don’t Make Me Think, by Steve Krug; good software lets users accomplish their tasks easily and directly, without frustration. Confusion breeds frustration.
Be comprehensive: Explain the past as clearly as possible
Knowing what has happened is just as important as knowing what will. When designing anything related to spending, trading, investing, etc., your users will be well served by giving them easy access to all their transactions your application handles. Go the extra mile and build useful and interpretive histories, and not just a table full of transaction hash strings.
How much did that transaction cost, in tokens and in fiat value at the time? What did they get for that transaction? Simply linking to an Etherscan transaction page is lazy, and unhelpful for most people.
Be solid: Make crypto security simpler
This is a big one. Many of us at Superlunar come from the cyber security industry, and learned long ago blaming users and assuming they need to be more educated is no help to security pursuits, and only makes users more frustrated and susceptible. Telling people they need complicated hardware wallets; to jump through more hoops; and to be scared of everything they interact with is a sure fire way to ensure this web3 world remains the niche playground of the technically proficient.
Social engineering is rampant in web3, and preys on confusion, urgency, and fear of missing out. People are conditioned to click on things and dismiss lengthy explanations (see literally every terms & conditions document you’ve never read). We need to design workflows that do a much better job of double checking that what’s going to happen is what the user expects to happen.
What’s Next?
Looking back at the twenty-plus years of the Web 2.0 era, we can see how evolutionary and iterative the user experience was. Web application design and development and the broader software industry went from being the playground for technologists to one of the most dominant industries and economic forces on the planet.
Web3 and crypto have similar potential to alter the landscapes of online identity, stores of value, privacy, and digital ownership. But if design isn't just what it looks like, but how it works (thanks Steve Jobs), we as designers have a lot of work to do.
“The space needs many more founders with experience building products that customers love. It needs people who know how to build a consumer company in this space — encouraging positive consumer habits, understanding behavioral psychology, designing delightful user experiences, and so on. I feel confident we’ll get there.” — Mercedes Bent
If web3 use cases are going to be anywhere near as impactful as their Web 2.0 predecessors, we need to work towards similar levels of simplicity, clarity, and ease of use.
Designing in web3 will likely be less about taking advantage of new technologies to craft richer user experiences than crafting experiences for our users that don’t let the technology take advantage of them.
