All Aboard: Getting Mainstream Users Up and Running on Decentralized Systems

  • Creating a smooth onboarding experience is a common design challenge in free and open-source software (FOSS) projects. Onboarding is a particular challenge for decentralized systems because the mental model is different from mainstream software.
  • With support from the Open Technology Fund (OTF) Usability Lab, we partnered with Snikket, a decentralized messaging platform to find the sweet spot between a technically correct mental model and usability. 
  • Our research exposed a key opportunity: Technical and non-technical users have very different needs from onboarding. We recommended changes to the website content and information architecture to improve the usability of the onboarding experience for both groups. 

Be sure to check out our interview with Snikket’s creator, Matthew Wild, as well. 

Snikket is an XMPP-based messaging platform that aims to provide an open and secure alternative to proprietary messaging apps such as WhatsApp, Facebook Messenger, and Telegram. What makes Snikket different from other messaging apps is that it allows people to create and host their own servers (including Raspberry Pis) for more control and security.  Personally controlled, decentralized servers are at the heart of Snikket, but this much end-user control means a more complicated onboarding process. Users can’t start using the app by simply downloading it from an app store and creating an account. Snikket’s goal is to distinguish itself in the fragmented and highly technical XMPP ecosystem by providing consistency and usability to a broad group of users. 

Through the OTF Security and Usability Lab, our work with Snikket focused on improving the user experience of both iOS and Android devices, and balancing ease of learning and efficiency of use. We conducted a heuristic review of Snikket apps and web interfaces, facilitated a user study, considered several UX design explorations, and delivered design recommendations for an improved onboarding experience that address the barriers for adoption. 

Onboarding doesn’t have to stop after the welcome screen 

The onboarding process is essentially a user journey to learn about a new application or software. If designed correctly, it creates a positive first impression and increases the likelihood of adoption. According to the Nielsen Norman Group, the key purposes of onboarding include:
“1) feature promotion — to educate users about the function and benefit of the app; 2) customization — to request user data to customize the user experience; and 3) instructions — to teach users how to use the interface”. A tool team might think of an onboarding process as limited to a few first screens when users open an application or software for the first time. For more complicated designs, onboarding can also take place over time, like when new features are introduced once users have achieved a certain level of fluency. This is often the case of free and open source software (FOSS) designs as they are built upon a variety of different decentralized protocols that are usually less familiar to the average, less-technical users. 

For users who aren’t familiar with XMPP, they can request to join a Snikket-hosted server and start using the app from there. Their friends can then join them by getting an invitation to the same server. If a user feels comfortable, they can find instructions on the Snikket’s website to host a XMPP server and then invite their friends. On the surface, this onboarding process may seem straightforward, but the user experience, on the contrary, is not. 

The diagram below illustrates what a non-technical user and a technical user need to do in order to start using Snikket to chat:

In contrast, the actual onboarding workflow that both user groups need to go through is much longer and more complicated: 

As technical users can create their own instance on Snikket, they are introduced to an entirely different workspace on Snikket (the web portal). After successfully creating a server, they can start sending invitations for others to join. Meanwhile, the non-technical users’ onboarding flow  only starts after they have received an invitation and downloaded the application. A simple task such as signing in can get confusing here when a new user can’t create an account on the app and isn’t introduced to the web portal priorly:

“Is this the same address and password [with the one used for the server]?”

“I don’t know how to sign in, because obviously I don’t know how to sign in.”

Mind the mental model gap

Our user study revealed that most technical users can use Snikket efficiently,  even when the overall onboarding experience is not always straightforward. They know how to set up a server, create admin accounts, send invitations to their circle, and more. 

However, this ease of use does not apply to non-technical users as most of them struggled to navigate through the app. There was a significant gap between their mental model of Snikket and the centralized messaging apps they are used to. For example, many users thought that inviting someone to a server was the same as adding contact on the app. In reality that is not the case. For example, with Whatsapp, one can simply invite someone by sending them an invitation to their phone number via the app, or they can look up their username/or phone number. With Snikket, one needs to be invited to the server and create an account on that server first. The two options to invite to server and  add contacts are not clearly presented —  inviting someone to server is done on the web hosting site whereas adding contact is done within the app. 

Most of the non-technical testers could not figure out how to install the app. Even if they did manage to download the app, they didn’t know how to start using it. The lack of clearly visible next steps makes it difficult for users to establish a workflow. Most users, including tech-savvy users, expected to be able to use the app right after installation. To address these challenges, we relied on our two personas — the non-technical user and the technical user. We mapped out both persona’s needs and pain points and then identified the similarities in their onboarding process.


Technical user persona

Non technical user persona

Ease of Learning versus Efficiency of Use 

The Snikket onboarding process starts at different places depending on the users’ level of technical knowledge and their familiarity with XMPP. A non-technical user usually has their first interaction on the app, while a technical user might go to the website first and start with the Snikket Hosting platform. Because of this, it is important to deliver the right message, in the right place, at the right time. We had to keep in mind that this doesn’t mean packing in and presenting all the information to users at once - users don’t need to know all the technical information in order to perform a task. In some cases, it might be too technical for non-technical users and XMPP beginners to fully comprehend the differences between the variety of Snikket components such as instance, app, network, and server.

Language and tone are other powerful tools to support the comprehension process and improve usability. As such, we wanted to make the language consistent and reduce technical jargon. It’s advisable to generally avoid technical jargon to deliver concise and timely messages rather than informative yet obtrusive and exhausting ones. Whether it is to employ an interactive walkthrough, help text, or a deck-of-cards tutorials, the instructional onboarding process should be built on existing mental models to reduce memory strain. A good practice when introducing new features is to keep customization to a minimum and provide a clear structure that enables users of different technical levels to follow. 

An effective onboarding process should prioritize what users need to do and know by highlighting the most important information in a timely manner. For example, the images below display a comparison of Snikket two different versions for the UI/UX design of account deletion. In version 1.1, there was no system confirmation of the deletion but two different options of account removal, none of which presented in a non-technical friendly manner. A small UX change in version 1.2 makes it a lot easier for users to perform their task. By eliminating the technical removal options and providing a confirmation message, users can avoid making an error (log-out versus delete) and focus on the task at hand. 

Usability starts with a good onboarding experience

The benefits of FOSS is that it’s easy and flexible for community members of different disciplines to contribute and there is no paywall for the end-users. Many FOSS and decentralized tools have played a critical role in helping vulnerable communities maintain their security, autonomy and independence. If these technologies are hard to use, they are less likely to get adopted and hence become less critical. When it comes to unfamiliar and highly-technical decentralized tools and protocols such as Snikket’s XMPP,  it is even more important to have a good onboarding design in place. 

Our design recommendations for Snikket’s onboarding process are based on the Simply Secure 10 Heuristics for Responsible Interface Design. We believe that a learning-by-doing approach would ensure a balance between the ease of learning and efficiency of use in a complicated and unfamiliar system design like Snikket, not only during the onboarding process but also throughout the entire user experience. We hope that our learning has shed some lights on the importance of onboarding design in enabling usability in FOSS. 

Read our interview with Snikket’s creator, Matthew Wild, here.

Learn more about our previous work on FOSS design: 

Project Credit

Project Contributors: Ngọc Triệu, Ame Elliott, Rae McKelvey, Snikket (Matthew Wild) 

Illustration: Ngọc Triệu 

Project funded by Open Technology Fund’s Secure Usability and Accessibility Lab.

Related

Selecting Research Participants for Privacy and Beyond

A screener is a questionnaire that helps researchers recruit the most appropriate participants for their user study research. Here is an example we used for our mobile messaging study in NYC. Blue Ridge Labs handled the recruiting. Most of this screener's questions are a standard part of how they work with potential participants. Our questions, in red, focus on messaging and attitudes towards privacy. Additional questions about VPN use, email, and getting online were for our Fellow Gus Andrews's research.

Web Monetization: A Report on Barriers to Adoption

With support from Grant for the Web, our team examined existing challenges to the wide adoption of web monetization protocols in an effort to determine how these obstacles can best be overcome.

Threats, Tests, and Trust: Designing for Mobile Surveillance Monitor

Supported by the Open Technology Fund, our team provided human-centered design and research support for Mobile Surveillance Monitor, a new, public online platform that tracks and maps mobile surveillance threats.