We've been working on SSB Private Groups for a year now, and today we're excited to show you the user experience design for the feature. This is something we iterated on many times, in such a way that the design presented here is generic enough and useful for any SSB app, including Manyverse.
Why groups?
Groups are important because SSB is a cloud-less peer-to-peer platform, where discourse is generally open (like Twitter).
Adding groups means communities can coordinate, share memories, manage resources, away from prying eyes, protecting their sovereignty.
On audience and deliverables
Currently the two apps spearheading the new feature are Manyverse and Āhau (a data-sovereignty-minded app built by and for indigenous groups) but others will come.
Assumptions and scope
We started by validating our assumptions to produce an agreed scope. From there we validated group personas.
Group personas
User personas are archetypes that render explicit to peers of the team the kind of user we're building for. Making it explicit helps us align our goals, reducing confusion.
You use personas as an acid test against a proposed flow, empathizing with their needs and goals and limitations.
For SSB, we decided on group personas since it's a social media after all.
- family photos: family wants to share pics of their life when they meet, seamlessly and privately. think siblings meeting for coffee while their devices update pics.
- company documentation: company writes their policies, code of ethics, tutorials straight on SSB. publicly or privately (closed groups?)
- indigenous groups: collective mapping and oral stories, respecting data sovereignty (related: Principles of Māori Data Sovereignty, PDF)
- study groups: a book club using SSB for event planning, notes and overall book (or any media, in fact) criticism
- political refugees: climate migration is on the rise. how can SSB help coordination of resources where corporate clouds fail?
Negative personas
The easier we make to enter and enjoy our tools, the more we're a target of recruiters.
Any group that depends on recruiting to grow should be part of our threat model. I'm talking about:
- nazis, white supremacists, alt-right
- cults, MLM, pyramid schemes
- marketeers, PR
- political propaganda, sock puppets
We want to deter threats from these personas: Our tools should make their work harder.
Possible deterrences are authentication security (that's our next post), blocklists (of both peers and subs, or even subs that follow them-like gab vs mastodon teach us), flagging systems, etc.
Group as an object
To simplify specs, certain SSB features are called objects. Objects can be pointed at (shared, linked, referenced) and have a profile that shows more or less of its contents depending on the relationship peer has with it.
Peers have 4 types of relationship with groups: they're either in, out, requesting to enter, or invited to enter.
Joining a group
Groups are opaque to outside peers, but existence of the group is not. Outside peers can either request to join, or be invited to.
To request to join, peer answers pre-filled questions that then become a thread seen only by admins asking follow up questions. Admins can accept, reject or even silently reject candidate.
Sharing on SSB
Objects that can be shared either inside SSB platform (if you know each other) or outside it (if you only know each other outside it).
Sharing outside SSB platform generates a token page that acts as a bridge, redirecting outsider towards the platform either by connecting with an existing account/app, or suggesting them to install it.
Sharing tokens links appear as Open Graph for friends. Token link and page are generic, and don't leak info of what exactly is on the other side, besides type of object.
Invitation to a group
Group invitations are also an object, but can only be claimed by the person invited, or have a 1 week expiration date if invitation is made outside SSB platform.
Being thrown into a group automatically violates consent, but it's a choice corporate social media made to drives engagement. On SSB, after invitation, peer sees profile and choose to join or not.
Inside a group
Once a group member, peer can see common threads, and if promoted to admin, admin-only and request threads. Candidates only see and interact with their own request thread.
Group peers can view other peers, along with their personal relationships and possible actions.
Clicking on a member opens a mini-profile, with everything about peer in the group. This mini profile differs depending on type of member, plus permissions.
SSB groups act as a truce between blocked, muted peers: Peers and admins are notified when people blocked by peers join group or admin. The mutual notification forces existing peers to discuss their differences before acting.
Group messages are seen by all peers, so any message blocked/muted person sends can be seen.
Blocked peers are not notified. Since muting is silent, only member who muted is notified and has access to list.
Conclusion
Because we're creating specs for different apps, design deliverables are loose (mostly flows and wireframes) so apps themselves can personalize as they wish. SSB community is composed of incredible individuals, so it's cool to build stuff together.