A month ago, more than 750 tech minds interested in building the web we want — and the web we deserve — gathered at the old San Francisco Mint for DWeb Summit. While my dev team was busy running workshops, I joined the UX/UI session on Builders Day as a storyteller to later share with the world what puzzled our minds at the time.

What happened on Builders Day?

On Builders Day there were no panels or talks. Instead, 100+ of the top builders of decentralised protocols and apps, along with leaders from the law, governance, the arts and global rights formed 13 working groups to discuss current and upcoming challenges to building a new web.

Our group, led by facilitators Michelle Lee from Protocol Labs and Amy James from Alexandria.io, got lucky number 13. Personally, I felt super proud that the session on design was the only one facilitated by ladies, so I simply couldn’t resist starting a tweet with lyrics:

There was no advance registration for sessions. Instead organisers turned the group-forming process into a short trade show of topics (dear Reader, note this! — it’s an idea worth stealing for your next event).

Each topic had its own stand where attendees could share their thoughts, frustrations or challenges they currently face within that area.

This first round of chats helped facilitators get a feel for the audience in advance, and the questions we noted down during the “trade show” became our starting points for the afternoon sessions.

Breaking the ice

Michelle suggested an icebreaker game I cannot fail to mention.

We created an imaginary axis across our space for two controversial opinions. After Michelle read each statement related to the session topic, participants arranged themselves along the line — did they agree? how strongly did they feel?

1. For any decentralised app that appears I can build a centralised one that performs faster.
2. Users don’t need to understand decentralisation to benefit from it.
3. We need to abandon UX of centralised web to create excellent experiences for the decentralised web.
4. In the last week of work did you create for end users or for developers?

Guess which statements were the hottest?

Users don’t need to understand how decentralised technology works to benefit from it.

Our working group in unison agreed that people need to understand that something is better and to see the difference in benefits and implications of using one technology over another, but they don’t need to know all the details.

Should we really abandon UX of the centralised web in order to create better experiences for the decentralised web?

Can you imagine throwing out decades of practices developed by our UX heroes and mentors?

There was one memorable opinion that we don’t need to abandon everything at once — different approaches to UX will emerge organically. The behaviour of users will change: once they recognize differences between current apps and dapps, they will sit back, rethink, and change their behaviours. And only then we should adjust UX practises to meet these new patterns of behaviour and help people adopt decentralised products faster.

My opinion here:
it’s very important to remember that when it comes to adoption of new technologies our design decisions influence and literally “place” new behaviours into people who adopt this technology. So the question is rather: “To change or not to change behaviours that people earned using the centralised web?” Unfortunately, getting people to change is very difficult. What if there is unexpectedly high resistance to adoption of new technologies? How do you plan for that? Is it mission impossible then? On the other hand, if to keep applying old patterns over and over, where is the difference between using Web2.0 and Web3.0?
+
I believe that we should not wait for users’ behaviour to change on its own. Instead, we should kick-start the process by building on behaviours that already are familiar to people so that they can more easily try out new things. And then, step by step, introduce new, better patterns of experience design.

Getting on with it:
ideas we put on the table

Well, not on a table — on a whiteboard. And not only ideas — all things that bother us that day. (I’m very curious, how many of them will appear again during the design track at the next DWeb Summit in 2019?)

Some of the brainstormed questions kept us running a discussion for the next 4 hours until the final call to join the closing keynote. They are also our (designers’) homework — we will not successfully move forward if we don’t find at least first hypotheses of their solutions.

In this post I want to break down three of them.

01. Should apps die?

When data (finally!) leaves the storages of current centralised services and value captured on their application layers moves to protocol layers, what will happen to apps?

At some point the group agreed that apps would become tools for accessing data from massive indexes, that an average user will need only to pick their favourite tool and stick to it, while other users may choose different tools depending on 1) their needs, 2) their level of technical proficiency.

The second condition influencing users’ choice of tools comes directly from the result of our future efforts to educate users on technology. Developers and design teams collaboratively have already succeeded with one part of the world — with those who are working in technology, but we still keep explaining to our moms, grandmas and people outside the tech industry that apps are ephemeral, that data is stored “elsewhere” and an app is only a “looking glass” to see it and a tool to use, because “your data is out there — we have it safe”. Today we are still explaining how everything works in a data-centric world.

Tomorrow, once all data centralised today is liberated, when we start switching to app-centric models — keeping in mind how complex products are with Big Data — what will user experience be like then? Will everyone feel comfortable in an app-less world?

Let’s imagine that, one day, Spotify, SoundCloud and iTunes each reveal their databases. In that case, as a daily user of Spotify, daily listener of podcasts via iTunes and a very, very rare visitor to SoundCloud, I wouldn’t need all three apps. Instead, there will be some interface to browse my collected data, at least to choose what to play. Figuring out how the interface should look here may not be a very complex task.

Now let’s take it a step further: add a decentralized database of audiobooks, also sound content. The interface concept in our minds is getting more complex, isn’t it?

Yet, it is not the main challenge here.

The true challenge for experience designers is to make sure that thousands of datasets collected through different tools and existing in different formats are combined into a coherent experience that is easily adoptable by users who are not used to interacting with big data in the way data holders do today.

The true challenge for visual designers is to find a way to represent the same data, browsable across selected products, in one unified way, so that users don’t need to reconstruct and realign this information in their minds when they access their data through their tool of choice.

To do so, we need a great level of standardisation to allow people to equally use whatever tool they prefer — be it an app or an agent — and to make in-tool experiences that match their needs as much as possible so that they never abandon that tool.

02. How can we remove friction in the decentralized web? Or wait… should we?

The increase of the information complexity will definitely increase the friction that directly affects technology adoption by non-tech users.

Our group started with a question: “How can we reduce the friction?”

And, yes, we came up with a few draft ideas how to achieve this goal: maybe users should be able to select the level of data complexity that matches their level of technicality, needs and context. Or what about flipping around the relationships users currently have with data sources? Why don’t we “offload” users from the data search since it doesn’t matter where the information is stored in a decentralised context — it always should come to you.

Whatever we brainstormed, that day our main conclusion was clear: let us commit ourselves, heart and soul, to the frictionless future of the Web!

However.
Digging deeper into what friction actually does to UX, I found this fantastic talk (link) that Steve Selzer gave at the last 99U Conference.

In the talk, Steve explains how the design team in Airbnb, while constantly working to remove friction from digital moments in their product, also embraced the right amount of friction in offline experiences that lead to self-reflection, self-discovery, and personal growth of travellers.

I urge you to watch this video before we jump into a few cases:

Now — the cases.
Yes, they come from centralised services, but shouldn’t we build on lessons from the centralised web in order to create excellent experiences for the decentralised future?

SnapChat
The app’s unusable design “with purpose” deters adults from wrestling with its confusing interfaces, almost encouraging them to abandon the app entirely, that makes app a “safe place” for teens to hang out. Designing for friction in order to attract the right audience on a scale.

IKEA
IKEA effect has already become a UX design principle. The effort that users put into completing a product to a ready-to-use state on their own and the friction they usually overcome to do so increases the perceived value of the product they purchased. Plus, it is good for company logistics. (Great UX design serves business needs as well. Always!)

Does it actually work? Just try it, if you haven’t bought anything large from IKEA yet.

Personal example:
how many tables did I assemble in my life? One — from IKEA. And by the way, I completely forgot about their concept when buying it, so was quite surprised to pull out a bag with screws from the box before I saw all the wooden parts of my future summer table: “Why in the heaven I need this??” A second of disappointment (exactly — a moment of friction), two hours of crawling from the manual to toolbox, and finally I shouted to my sister: “Look, I did a table!”

Other cases:

• when Slack warns you before sending a “notification to 120 people in 4 different time zones” — a very small, but still… a friction;
• fake progress bars are added to most banking apps just to make the product look more “real” in your eyes, while it actually takes milliseconds to perform the action in the backend;
• the whole gaming industry is built on making games challenging by introducing the right amount of friction.

Whatever technology is and whoever end users are — we shouldn’t try to make it all silk-n-smooth, applying Steve’s Krug advice on every moment of interaction. Instead we should leverage a little friction if the context demands it and if it will make the overall user experience better.

No-one shares data as a hobby

We started with a common frustration that incentives for personal data sharing are very low, unless doing so gives people an access to something of high value. Every time designers try to collect data, they face difficulties with getting it clean and structured.

So we dived into the question: what are those key experiences that contain incentives for informed and consistent data sharing from users?

Firstly, we “broke down” the statement that incentives for sharing data are always very low. It depends… By the way, if you, Reader, are not a designer yourself, let me introduce one of the most favourite replies of experience designers: “It depends.”

Yes, the incentive level depends first of all on the context. Every experience you create should be considered in the larger context: a chair in a room, a house in an environment, a new park in a city plan, a person who is asked to share data in relation to other players.

This means that, when designing an incentive structure for experiences, we should first take into account not which kinds of data, but who the parties are.

An easy question to check this hypothesis: you are asked to share information about your age, body, lifestyle and diet with a grocery chain (or a food brand), medical research centre and local agriculture monitoring initiative. With which organization would you be most likely to share your private data?

I suppose, your answer also is highly influenced not only by your relationships with parties, but also by your level of understanding their purpose behind using the requested data. Medical institutions and research centres struggle the most in this area.

For example, the Medical Informatics Initiative (MII) has recently introduced a new profession — data steward — which involves training their researchers and IT professionals how to help users understand information in a clinical context.

We also tried to approach the following questions during the discussion on this topic, but for lack of time agreed to leave it as homework for each of us:

What are the defaults for data sharing? What do they depend on? What level of freedom should be given to users in turning off the default settings and creating custom presets?

Have any thoughts to share on this?
Please, leave a comment below or tweet your idea using the hashtags #DWebSummit #datasharing #UX

We all should change the common perception that design is not valued

I wish I came up with this so-true call-to-action before Michelle did! It brought the whole group into something I call “visible brain processing”.

As a closing idea for our Builders Day, it wasn’t meant to start a discussion — and we didn’t. But for some reason my mind keeps coming back back to this again and again.

We feel valued within our companies (that’s why we stick with our teams), respected by our clients, followed and appreciated by the design community, but still… If you were to ask me: “How would you describe the reputation of design in early-stage startups?” I’d answer, “It is still undervalued. Unless we’re talking about bigger companies with design teams.”

Why?

Is it because we designers don’t communicate the roots of our decisions and don’t engage our teams in the design process when working solo, taking cover behind the excuse that “we are a small team, everybody has their duties and we are short on time”?
Or is it because of the high costs of hiring seniors?
Or copycatting UI design trends massively followed by juniors who, under the time/expectation pressure in their first job ever and lack of in-agency work experience, approach design as a Trello task, not as an exercise for all stakeholders?
Or is it because of the numerous DIY design workshops for startups — from “create a brand in a day” to “design your product UX in a day”? If you can DIY in a day, why invest in a designer to join your team?
Or is it because Web 2.0 is full of UX patterns and trendy UI kits that anyone can easily mix&match?

I hope these questions will open up a broader discussion, urging us to rethink design education and better promote the importance of learning how to design cultures and experiences in addition to designing products.

What is undoubtedly true: in the decentralised web is not a right environment for old perceptions to flourish. There are already experiences that didn’t exist before. There may be no interfaces in the future for these experiences, and dapps will process our data in a completely different way. In other words: no UX patterns, no visual standards, a huge demand for driving user education and… well, let’s roll up our sleeves and make a better design in Web3 happen!