📌
sharing multiple email lists
Role: Product Designer at Staffbase
Date: Aug 2022
Industry: Email, Internal Communications
- 1 Product Designer (me)
- 1 Product Manager
- 6 Full Stack Engineers
- 1 QA Engineer
- Sharebears Team
- Design Manager
- Customer Success Team
- Sales Team
background
Staffbase Email is one of the app’s in the Staffbase internal communications platform that allows enterprise customers to send email communications to their employees.
One of Staffbase Email’s most highly requested and long awaited features for 2022 was the ability to pick and choose which distribution lists were shared with which users and groups. Customers wanted the ability to create private distribution lists and only grant access to other team members who have permission to send emails to it.
Version 1 and 2 of the List Permission Feature was worked on and shipped by the Sharebears Team and customers were able to share a single list to groups or users.
The next iteration of the feature (List Permissions Version 3) would allow users to share multiple lists to groups or users at once. Since my team regularly owns contacts, lists and integrations, after urgent customer needs had been addressed, the work was passed back to us.
| Version | Functionality Added |
|---|---|
| 1 | Give users the basic capacity to share a list with their own group. Version one will also only focus on two permission types: send and edit, send only. |
| 2 | Expand the existing capabilities to include sharing a list with a single individual team member. |
| 3 | Allow list owners to select multiple lists to share at once with multiple users or groups. |
Problem to Address
When an Internal Communicator wanted to share multiple lists to their colleagues, they had to go through a very manual process. With List Permissions thus far, lists could only be shared one at a time and were private to the list owner (the person who created or synced the list first), so all responsibility fell to one person. It was most challenging when customers were onboarding and had 1000’s of lists that needed to be shared with their team members. Doing the sharing process manually was extremely time consuming. It would take our customer success team up to 3 hours to manually share all lists on behalf of our customers who (rightfully) refused to go through this manual process. This lackluster user experience put a strain on the product team’s relationship with success and we hoped to alleviate their workload as soon as we could.
Understanding Current Designs
Our Objectives
- Empower customers with the ability to bulk share their distribution lists and alleviate workload on customer success team
- Create prototype, user testing protocol, recruitment, and design remediation on existing bulk list sharing designs
- Build new component for multi-selecting lists
usability test
- Testing Method: Moderated usability testing over Zoom with Figma Prototype
- Participants: 3 Internal users
- Observers: 2 Engineers per session
Flow that we tested
Usability Insights
Overall, participants were able to complete the usability test successfully due to its resemblance to existing platform patterns. However, they did highlight some areas that we should revisit:- Ensure that search capabilities allow users to find lists/individuals/groups easily
- Clarify copy: aliases vs. individuals vs. groups
- Clarify copy: on card or elsewhere that details what permissions a list has
- Discuss if we want to allow overriding of inherited group permissions
- Discuss and clarify behaviour for list ownership
design remediation
Distribution List card
- Changed metadata to sentence case for legibility
- Added ‘permission’ metadata field to show access from the logged in user’s perspective. Permission can be:
- No access
- Full access (List owner or Parent Admin)
- Send and edit
- Send only
- Kept ‘owner’ field so users needing access know who to ask for permissions
- Moved ‘privacy’ metadata into an icon. Private lists have a lock to denote that they are not shared.
Sharing Modal
- Previously did not allow users to override sharing permissions for an individual inherited from a group - Decided to allow this
- Clarified in modal that Parent Admin will always have full access to all lists
design considerations
Updating cards
New card component needed with multi-select option.- Opportunity to build something accessible
- Copies owner's email on click (In case user wants to ask for list access)
Sharing Process
- For single list and bulk list sharing, sharing action moved to a modal instead of in-page
- Allows for consistent sharing behavior in all cases and engineers need to maintain less code by re-using one component
Unsharing a List
- If there are scheduled emails for a list that is being un-shared, user will see this modal before continuing.
- Scheduled emails will still send, but team members may lose access.
Sharing Performance
We knew that for some larger customers there may be a slight lag when trying to share a large number of lists (thousands) and a large number of individual users and groups. We implemented tabs for individuals and groups to help reduce the number of entities selected with the “select all” function.No Display of Existing Permissions
When the modal opens we are unable to show the existing permissions because you are sharing multiple lists at once each list may have different permissions. We explored an option showing 'mixed permissions', but eventually a majority of individuals and groups would display mixed permissions and the UI would no longer reflect useful information. However, users are still able to view existing permissions when opening the sharing modal for a single list.sharing permissions
Along with this feature, we also had to consider the access and permission impacts of sharing distribution lists. What are different access levels allowed to manage in the list itself? Can they create new lists from shared lists? Who can send emails to these recipients and how does data show up in reporting? The sharing matrixes we landed on are as follows:List Access and Permissions
| Access / Permission | Owner | Send and edit | Send only | Revoked | Not shared |
|---|---|---|---|---|---|
| Read | ✅ | ✅ | ✅ | ✅ | ⛔ |
| Send | ✅ | ✅ | ✅ | ⛔ | ⛔ |
| Edit | ✅ | ✅ | ⛔ | ⛔ | ⛔ |
| Delete | ✅ | ⛔ | ⛔ | ⛔ | ⛔ |
| Share | ✅ | ⛔ | ⛔ | ⛔ | ⛔ |
Updating Feature Access Permissions
Before List Permissions V3 was implemented, any user could access the “All Contacts” tab, create any list and send to it even if they had restricted List Permissions. This defeated the purpose of having List Permissions in the first place since users had access to the entire contact directory and could potentially create lists they had restricted access to from the “All Contacts” tab.
We fixed this by adding another option to the Feature Access Permissions that can be configured for each user:
Page Hierarchy
We also rearranged the page hierarchy of the contacts area. This way, if users did not have "All Contacts" access, we can hide the "Directory" link, while still maintaining access to the "Distribution Lists" page.
storymapping
challenges
- Onboarding to the project mid-way
- Determined what had been discussed and decided against by the previous team
- Identified gaps and unknowns to continue design process from
- Building new components
- Ensured new component is configurable for other teams without being too prescriptive
- Socialized new design with designers and engineers
- Capturing edge cases in permissions
- Worked with QA to test flows thoroughly
- Added remediation tickets to areas we missed
- Documented known use cases that haven't been addressed (lowest probability)
results
After we released this feature, our customer retention rate increased by 30%. We renewed many existing enterprise customers and built a stronger partnership with the customer success team. The new design was also well received and we continue to monitor its usage in Pendo.
