Design Challenges in Decentralization

In working with decentralization projects funded by the Prototype Fund, I’ve been thinking more about overall design patterns for decentralized systems. By “decentralized systems”, I mean protocols, apps, and services that are non-centralized– including both federated networks, e.g. Mastodon, and peer to peer networks, e.g. Fritter.1 By “design patterns”, I mean recurring concepts we see in interfaces, workflows, and writing. For example, Projects by IF has a catalogue of patterns on Data Permissions that collects many design concepts related to privacy.

In looking at the decentralized space, the big question is what about our existing mental models as well as existing design patterns changes. For example, the pattern of account authentication (the trio of “login”/“signup”/“password reset”) is almost everywhere in centralized and decentralized tools. But in a decentralized system, authentication can work differently — it’s possible that the service you are connecting to doesn’t have your account information to complete the authentication. How do we communicate that difference consistently? Do users need to know that a system has decentralized technology under the hood? And when it comes to the interfaces we build: what new patterns can we develop to make decentralized systems easier to understand? Are there existing patterns that work well? With so many new decentralized tools emerging lately, the technology is (often) new, non-mainstream, and sometimes counterintuitive for experienced users of the centralized web.

In trying to tackle some of these challenges across the board, I’ve started compiling some emerging themes in decentralized systems design. I will give four areas as examples.

  1. Explanation and terminology
    How do you explain the difference between centralized and decentralized systems? What do users expect, what should be communicated without overwhelming people? What kinds of metaphors can we use to talk about this technology?

  2. Onboarding to Federation
    When onboarding new users to a federated system, what do they need to know about the federation? Does the system need them to choose which community to join? If so, what are the factors that should influence such a decision? What happens when they want to move from one community to another?

  3. Privacy/Discoverability
    There is a known trade-off between privacy and discoverability in p2p contexts.2 What choices does that present to the user experience? How do you communicate unusual privacy properties such as exposing people’s IPs? What settings should be allowed? On the other end of that spectrum: what UX options are there when there is no look-up table for privacy reasons?

  4. Identity Management
    Without a central authority in place, it can be hard to manage identities across different communities, or encryption keys across different devices. What are sensible UX flows that protect the user’s security without adding to their cognitive load? And how can our digital identity be framed differently to match the constraints and possibilities in decentralized contexts?

What’s next?

Many of these issues are sector-wide. Some of them require a joint effort from different decentralization projects to solve. And others present a huge and exciting playground for people interested in designing a totally different digital space. For now, I’m researching and compiling the patterns I see. Watch this space!


Thanks to everyone at #35C3 who pitched in, esp. Jan from Nextcloud, Ben from Matrix, Roel from XMPP, Elio from Ura Design, Ksenia from Delta Chat, Cade from Tactical Tech.

1 My definitions are largely based on this article, which also introduces the distinction between technical, political, and logical decentralization. I will mostly talk about technical decentralization, and specify when I mean political or logical decentralization.

2 See the dat whitepaper for an excellent description of the trade-off.


Awkward! QR Scanning + LinkedIn Spam

Messaging with friends and colleagues is rewarding – but sharing contact information is awkward. Many people want to preserve their privacy by carefully controlling who gets their contact information, and choose not to broadcast their email address or phone number via a public Facebook or Twitter profile. Instead, they choose to strategically share their contact info. It's awkward to navigate the social and UX challenges in this sharing. Looking at how WeChat and LinkedIn handle this problem exposes two different kinds of awkwardness: mechanics of sharing and social agreement about what permissions you get as a result.

Chatbots, UX, and Privacy

Chatbots, or conversational programs that simulate interactive human speech patterns, are a hot topic in UX right now. Microsoft CEO Satya Nadella recently claimed that “bots are the new apps”, and that they are the interface of the future for tasks like ordering food and booking transportation. In San Francisco, tech elites use a multitude of oft-parodied services like Wag to find dog walkers and Rinse to have their laundry done.

Illustrated Quick-start Intro to Wireframing

If you're new to UX design, wireframing is a powerful tool to understand how users experience your software. People with technical backgrounds benefit from wireframing because it forces them to take a step back from their coding mentality. Rather than focusing on the technical architecture, wireframing exposes the user-experience structure: how the user moves from one screen to another. Example wireframes taken from Both show the same content organized with two different structures, but the left wireframe is better because it discloses choices rather than keeping them hidden.