This case study is locked 🔒

If you'd like to review this work, please email me for access.

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

Overview of list permissions v3


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.
Summary of differences between versions of List Permissions

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

Example showing distribution list named Carrie List with 4 contacts all named Carrie.
Sharing process after List Permissions Version 1
After clicking on the Share List button on the Carrie List page, new section slides open in UI to allow user to select groups to share with: Marketingfam, Test, Other or Leadership
Ability to multi-select groups to share single list with
Clicking on checkboxes beside groups multi-selects them. New content opens up to allow users to change permissions in bulk using Share with all button. Carol has a sticky note on top commenting: Maybe instead of share with all, it should be apply and save button can be save and share
Ability to bulk apply certain permissions to selected groups
Clicking the share with all button applies permissions to groups that have been multi-selected
Ability to bulk apply certain permissions to selected groups (con’t)
Beside each row sits a minus icon which reveals a tooltip that says Unshare on hover
After clicking ‘Share’, users can change permissions of each group
After user clicks save on the sharing screen, a success message pops up in the UI telling them their list permissions have been successfully updated
Toast message to confirm successful sharing
After the success message disappears, users are left on distribution list page. Within the distribution list card, there is no new indication that the list permissions have changed
Returning to list page after sharing shows no indicator that list has been shared

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
Recommended screen setup for usability testers (left) and testing scenario (right)
Figma prototype

Flow that we tested

Clicking on checkbox beside 'Kelowna Team' distribution list
Clicking on checkbox beside 'Kelowna Team' distribution list
Click 'Share' button to share selected lists
Click 'Share' button to share selected lists
Select individuals to share lists with
Apply 'Send and edit' share permission to selected individuals
Click on 'Groups' tab
Select groups to share lists with
Apply 'Send only' share permission to selected groups
Return to 'Individuals' tab
Individuals in groups will inherit group permissions
Lists will now show 'Privacy: Shared'

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:
  1. Ensure that search capabilities allow users to find lists/individuals/groups easily
  2. Clarify copy: aliases vs. individuals vs. groups
  3. Clarify copy: on card or elsewhere that details what permissions a list has
  4. Discuss if we want to allow overriding of inherited group permissions
  5. 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.
Card design from usability test
Card design after usability test with copy remediations

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
Ability to override group permission
Ability to revert to group permission after overriding
Clarifying permission for Parent Admins (Always full access)

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)
Tab order of card: use spacebar or enter key to check checkbox
Specs for new card component and its states

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
Before: Sharing managed in list detail page
After: Sharing managed in a modal

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.
Modal detailing which scheduled emails are using the lists to be un-shared

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
Basic permissions per access level

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:

New permission to control access to contact directory

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.

Before: Distribution lists were nested as a tab in the Contacts / Directory page
After: Distribution lists moved up one level in the hierarchy


Designs converted into tickets during storymapping


  1. 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
  2. Building new components
    • Ensured new component is configurable for other teams without being too prescriptive
    • Socialized new design with designers and engineers
  3. 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)


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.

Pendo heatmap of new distribution list cards