Designing Interoperable, Encrypted Messaging with User Journeys

By Sukhi Gulati-Gilbert & Michal Luria

Interoperable encrypted messaging has the opportunity to provide increased choice and agency to consumers. Interoperability is a cornerstone of our underlying communications infrastructure — an internet architecture principle that facilitates decentralized networks that are more robust, resilient and equitable. Yet for implementers, interoperability introduces many challenges. 

To design such interoperable systems effectively, it is critical to center user experience alongside technical discussions. In order to improve consumer options, interoperable services should remain intuitive and easy to use. Initiating discussions on design principles that consider privacy by design as well as user experience design will result in more human-centered, transparent and easy to use encrypted messaging, optimizing privacy and security.

To help illustrate how such an approach might work, our research team, taking a design research approach, led an internal ideation workshop with CDT’s team of technologists and policy experts to identify key user experiences of interoperable, encrypted messaging. With this cross-functional group we used user journeys to capture different aspects of communicating across interoperable messaging systems from a consumer perspective. This approach provides an initial step towards understanding what some of the concerns around interoperability might be, and suggests design aspects to consider when creating interoperable messaging applications. 

Below, we walk through one sample user journey from the workshop, through which we explain the initial design considerations that we have identified. We focus on a single scenario: a simple interaction of sending a message to an individual and reacting to their reply. We walk through how it is done today, how it may be done with interoperability implemented, and some of the questions that will need to be addressed to make that transition.

User Journey: Sending and Reacting to a Message on an Encrypted Messaging App

Quinn has just met Kiran at a conference and they decided to keep in touch. Kiran hands Quinn a business card which includes a phone number and asks Quinn to “message them on WhatsApp” after the conference. Currently, where WhatsApp is not interoperable with other messaging apps, Quinn reaching out to Kiran might go something like this, from Quinn’s perspective:

• Quinn opens WhatsApp, since it is the application that Kiran uses.
• Quinn uses Kiran’s number to search for them, and finds a WhatsApp user associated with that phone number.
• Quinn sends Kiran a message: “Hi Kiran! It was nice meeting you. Are you free for a call next week?”
• Once Kiran responds, Quinn gets a push notification about it.
• Quinn reads Kiran’s message: “Yes! How about Tuesday at 10 am. You can call me here,” and reacts with a thumbs up emoji.

Consider the same scenario where messaging applications are interoperable.

At the conference when Kiran hands Quinn their business card, they say “message me” without specifying an application. The same user journey now presents many open user experience questions to understand how the interaction may look for Quinn:

• This time Quinn asked herself: which messaging app should I use for this specific interaction? Quinn opens Signal, since it is their preferred messaging application for professional contacts. 
• Quinn uses Kiran’s number to search for them. But, there are other considerations in a world of interoperability:
  • Is Kiran’s phone number the best identifier for Quinn to search with?
  • Does Quinn need to know what application Kiran prefers?
  • Does Quinn need to know Kiran’s user name on a specific application?
  • Will Kiran’s preferred application be one that is interoperable with Signal?
  • Can Quinn see all applications that Kiran has an account on? 
  • Can Kiran see all applications that Quinn has an account on? 
• Quinn selects Kiran’s WhatsApp account and sends a message: “Hi Kiran! It was nice meeting you. Are you free for a call next week?” While sending the message, Quinn may wonder:
  • Is our conversation content still fully encrypted?
  • How are WhatsApp’s policies different from Signal’s?
  • Does WhatsApp have access to this conversation metadata now? 
• After Kiran responds, Quinn gets a push notification about it: 
  • Which application will notify Quinn, Signal or WhatsApp? 
• Quinn reads Kiran’s message: “Yes! How about Tuesday at 10 am. You can call me here.” Quinn wants to react, but: 
  • Can they use Signal reaction features to respond to the message?
  • What will Quinn’s reaction look like to Kiran, who uses WhatsApp? 
  • Are other features, like message deletion, going to work the way they expect?

Design Aspects and Questions in Interoperable Encrypted Messaging

We hope comparing the above user journeys illustrates the complexity in crafting an intuitive user experience in a world of interoperable messaging. To begin exploring the different design considerations and questions that this one scenario raises, we’ve categorized the questions that came up in the workshop, and provided initial design principles that could structure the discussion in designing future interoperable messaging experiences.   

Account Management: Quinn Choosing to Open Signal

When Quinn chooses to open Signal because it is their preferred messaging application for professional contacts, they are performing account management. Users may use different messaging applications for different purposes. As a parallel, consider the difference between a work email and a personal email. One may prefer to keep all their work communications confined to one inbox, separate from personal emails. Similarly, a user may prefer to use SMS to message their friends but keep sensitive commercial interactions in fully encrypted channels like Signal. Any interoperable messaging design should preserve the user’s ability to manage their message accounts for different purposes. 

Contact Discovery & Management: Quinn Finding Kiran

In an interoperable system, Quinn would encounter various questions when attempting to find Kiran across messaging applications, questions that did not come up when they and Kiran were both using WhatsApp. Discovering contacts across applications may have additional layers of complexity when messaging apps are made interoperable. It is a technical challenge to define an identifier system which will work effectively across applications, and the parallel design challenge is to make any identifier system easy to interpret. From the user’s perspective, it should be clear who they are messaging on what application so they are aware of all parties involved in their conversation. It should also be clear what information is needed to search for users across applications. 

Privacy & Security: Quinn and Kiran Messaging Each Other Across Application Boundaries

Quinn may be familiar with Signal’s encryption strategies and privacy policies; they may have even played into the decision to use Signal. When Quinn messages Kiran, who is using another application, they may have questions about who now has access to the conversation data and what might be done with it. It is challenging to effectively communicate privacy policies and security considerations to users across one application, let alone across multiple. When applications with different encryption methods and privacy practices interoperate, users should be informed about the level of encryption applied to their conversation, and about who will have access to the data. 

Feature Parity: Quinn Reacting to Kiran’s Message

Quinn was familiar with how the “reactions” feature worked on their preferred messaging application, Signal, but not as familiar with how those reactions would show up for Kiran on WhatsApp. That uncertainty might make Quinn less confident that they are communicating what they intend to. Messaging clients introduce many features beyond barebones messaging: voice messages, emoji reactions, disappearing messages, and reply threads are just a few examples. Interoperable messaging systems therefore increase the chance that users may not understand which features are interoperable. Interoperable features may render differently on different clients, potentially changing the meaning of the interaction or presenting a poor user experience. Thus, thought should be given to creating robust fallbacks when features do not interoperate and continuously educating users on feature parity.

This is just a small taste of a vast design space for messaging interoperability that requires additional exploration. As advocates of interoperable design solutions, CDT believes a focus on user and human-centric design early in the implementation process can give interoperability implementations their best chance at success. Moving forward, we intend to continue this discussion on designing for interoperability with the broader community of end-to-end encryption (E2EE) and interoperability professionals: policymakers, designers and technologists alike.