As the product designer I conducted in-depth interviews with our users and customer success team, analyzing existing user feedback to uncover key pain points and bottlenecks in the user deactivation process. By designing a more reliable and streamlined solution, I significantly reduced support requests related to user deactivation, allowing the customer success team to focus on higher-priority issues while empowering end users to manage their organization's account effectively.
There are various reasons for deactivating a user from the Staffbase Email platform, most often falling into two categories: they are no longer with the organization or have transitioned to a role that no longer requires access. Currently, the deactivation process requires submitting a request to the account manager and engaging in multiple follow-ups before the user is officially deactivated - making it lengthy and frustrating.
Through interviews with end users and the customer success team, I discovered that deactivating a user was more than just a simple click of the button; our customer team also had to recreate templates that became inaccessible after the owner of those templates was deactivated.
Requires customer support assistance: Users cannot deactivate accounts themselves, requests must go through the account manager.
Inaccessible shared resources: When a user is deactivated, all resources (i.e. templates, drafts, lists) they own become inaccessible, even if shared with others in the organization.
Each resource in the database is linked to an owner ID, defaulting to the user who created it.
When that user becomes deactivated, that piece of resource cannot be surfaced since it is tied to that user.
Removing the owner ID from the database is complex and could require a system overhaul, increasing the project’s scope.
To address this challenge, we need to rethink how resources are tied to users. Instead of relying solely on owner IDs linked to individual users, we envisioned a system where shared resources are decoupled from a single owner. This would enable resources like templates and drafts to remain accessible even if the original owner is deactivated, without requiring a complete overhaul of the database structure.
I explored various solutions, including resource ownership transfers, access permissions, and centralized resource management, to preserve valuable assets and streamline the deactivation process. With only two months to design and develop the feature, I collaborated closely with the engineering team to identify the most impactful solution that could be implemented within our timeline.
Only an Admin user can deactivate another user, as users with Manager access may not have permission to view or manage all resources owned by others.
All resources owned by the deactivated user are automatically transferred to the Admin performing the deactivation.
Deactivating a user:
Admin user understands what type of resources would potentially by transferred over to them.
Scheduled drafts for deactivated users:
Email drafts scheduled by the deactivated user will be sent as planned, giving the Admin user a clear sense of all scheduled drafts. In most instances, there is no need to reschedule these drafts, this primarily serves as an informative overview.
The implementation of the resource transfer process significantly enhanced the user deactivation workflow. Following the feature's release into production, there was a notable decrease in support requests related to user deactivations and the recreation of email drafts and templates.
While the current solution adds tremendous value to the user management system, further enhancements are possible but were not captured due to the tight 2 month deadline from idea to production.
For example, enabling admins to select specific resources for transfer or implementing bulk actions could further streamline the process and boost user autonomy. These ideas are illustrated in mockups, laying the groundwork for continuous improvement of the feature at a later date.
Selecting resources:
Categorized by types, Admins can select which resources to keep or deactivated along with the user.
Selecting an owner:
Instead of defaulting ownership to the Admin performing the deactivation, they can select another Admin user to take ownership.
