When a user is taking an action, they need to know who, what and where. But what happens once they’ve taken that action? When a user shares something with another user, like a photo or a document, they need to know who, why and how to make it stop.

First, let me differentiate sharing and sending. Sending is when someone transmits data to another entity and that data passes into the possession of that entity. For example, if you were to send me an email, that email goes into my inbox. You can’t see whether it’s there; you can’t delete my copy of the email — but I can. If you share a photo album with me, you retain the ability to delete it; you’ve just let me see an object that remains in your possession. Shared objects, like documents that can be edited by multiple people, are also shared.

Shared objects (usually) have access control lists. (The exception is with objects that are shared using a capability model, which I am not going to get into here. Most people are most familiar with this model when used in “share by link.”) An access control list says which users and groups of users can take an action (e.g., view, delete, edit, append). Access control lists can, sadly, be hard for users to understand. This is the simple rule of thumb for what users need to see to make them comprehensible: who, why and how to make it stop.

Who. The first need is the simplest: If other people can access my object, I want to know who they are and what kind of access they have. Be careful about the identity data displayed here. If I typed in someone’s identity data as a part of sharing (e.g., an email address) or it’s explicitly shared with me, then it’s fine to display as part of the access control list. In some circumstances, it can be trickier.

Why. Why do those people have that access? Ideally, avoid assuming that users always remember what they chose to share, especially years ago. Information, such as the date and time at which a share occurred, can help people remember. This is especially important when multiple people can share an object. If Alice, Bob and Charlie can all share the document containing their secret nefarious plans, it can be very helpful for Alice to know whether Bob or Charlie shared those plans with a superhero (and thus who isn’t going to be invited to any more secret meetings).

How to make it stop. One of the best parts of using sharing rather than sending is that sharing can be discontinued. Make this easy. Some people who want to stop a share are in some emotional distress and have extremely limited mental bandwidth for complicated instructions. Removing access to an object won’t remove unauthorized copies of that object that were made in the past, like screenshots of Snapchat pictures that were intended to disappear, but should at least prevent further access and access to new versions of an object, like new pictures added to a shared album or new text added to a shared document.

Those three rules of thumb will give you a good start to designing respectful, privacy-sensitive access control list interfaces.

Photo by Victor Smits on Unsplash