My Role: Leading UX / UI from problem research, concept development, and collaboration with engineering
Project Timeline: 7 business days
Goal: Significantly reduce the number of support tickets automatically generated when an Account Admin attempts to remove a user who cannot be deleted because (s)he is the last leader of a team.
Constraints: There is a business logic in place that requires each team to have at least one ‘Team Leader’ or ‘Team Administrator’.
Impact: After this improvement was implemented, weekly support tickets decreased by 16% (approx 20 per week).
Existing User Experience
Product Context & Terminology
There are three roles involved in this product feature and will be mentioned throughout this project:
- Account Admin — This is a role within the Yesware product which manages the users in their account and the account billing.
- Team — Within an account, a number of teams can be created.
- Team Roles — Within each team, there are three roles that exist: Member, Team Leader, and Administrator. The roles determine the level of permissions the user has throughout the product features.
The Happy Path
For an Account Admin looking to remove a user from the account (eg. if the user has left the company), he or she would:
- Navigate to the Users section in the appsite
- Find the user’s name in the list of users
- Tick the checkbox next to said user’s name
- Click the 'Remove' button
- Observe the modal (shown below)
- Click 'Remove'
- Observe a success message saying that user was successfully removed
So, what’s the problem that generated hundreds of weekly support tickets?
I wouldn’t be here today writing about this project if removing users from an account just worked as expected.
There is a Yesware business logic in place that requires each team to have at least one user designated as “Team Leader” or “Team Administrator.”
It is important to note that the reasoning for the requirement is so that a team consisting only of "Team Members" can’t essentially lock themselves out of the team. However, this adds a layer of complexity when a single user needs to be removed from an account and is the only Team Leader of one or more teams.
To make things more complicated, what if the Account Admin needed to remove multiple users — some of which are the only Team Leader of multiple teams?
Referring to the UI abstraction above, because the team roles aren't listed in the Users list view, you also can't see which teams only have one Team Leader or Team Administrator. That means that whenever the Account Admin is removing users, they'll potentially get blocked by the business logic validation. More annoyingly, they have no idea why certain users can be successfully removed and why some cannot.
The deeper I dug, the more issues I found.
To get more background with the issue, I spoke to the Customer Support Team at Yesware, to get an idea of how much more complicated the current issue was.
I learned that each time an Account Admin clicks the “Remove” button that leads to an error, they receive an automated email letting them know that an error has happened, but not why. It is quite common for the user to click the “Remove” button an average of 3–5 times before giving up. With each failed instance, a customer support ticket is automatically generated and then added to the queue.
Secondly, once the Account Admin realizes that they’d been charged for the seats they thought they had removed previously, the Yesware finance folks have to intervene to sort out the billing.
Thirdly, the current validation in the backend processes the removal of users sequentially. What that means is once there is an error in the user list during the removal process, it will stop at that point in the list.
Going back to the UI abstraction for an example — let's say we need to remove User #1, User #3, User, #4. If the backend hits an error on User #3, the removal process will end there and User #4 will not be removed.
There were several approaches we could have taken here.
- Option 0.5: Removing the false positive "success" message that appears when hitting the error state (a half-hearted solution)
- Option 1: Remove the business logic in place (too many repercussions)
- Option 2: Change the team role permissions so that anyone can modify content (would mushroom into a major overhaul)
- Option 3: Implement an indicator on the user’s list of teams modal as shown in gif below (not bad, though adds unnecessary user effort to check for each user)
- Option 4: When unsuccessful, surface which users failed and which teams they are the last Team Leader or Administrator on (would provide helpful insight but is not accessible or discoverable until the error occurs)
After weighing these potential options with the Customer Support Team, the Product Manager, and Engineering, we decided that Option 4 would be the most feasible to build and most helpful for our users. Option 4 would provide that additional level of insight to the Account Admin so that they can take the appropriate actions and understand why and which users cannot be removed.
Thankfully, we would additionally fold in Option 0.5 as it’s imperative that we don’t show a success message when it’s actually an error in disguise.
From a high-level, the five main use cases that can occur are:
A. Removing a single user, successfully ✅
B. Removing a single user, unsuccessfully 🚫
C. Removing multiple users, successfully ✅
D. Removing multiple users, unsuccessfully 🚫
E. Removing multiple users, some successfully, some unsuccessfully ✅🚫
In addition to providing information to the Account Admins, there was space for supplementary UI improvements so that we make this process less painful.
As noted earlier around the sequential validation, the backend processing was modified so that the removal continues through the list instead of stopping when it hits an error.
Other improvements included:
- Adding a numerical value to the button so that it dynamically shows how many users have been selected for removal
- Providing the list of name and emails for review before removal
- Changing the toggle component to an “opt-in” checkbox component for users to send a notification email
- Updating the call-to-action button to ‘GO TO TEAMS PAGE’ so that users can directly go to the page where they can reassign the team roles accordingly
- Removing the false-positive success message
The Business and User Impact
Because this issue had spanned multiple years, it is really a time saver for both the Yesware Customer Support Team and our users. Our users are directly provided the information around which users and team roles need to be reassigned before removal. Gone are the days where they get false positive success messages, vague error emails, and sit around waiting for a response from the support team.
The Yesware Customer Support Manager and Finance Manager were both thrilled to announce that just a month after this improvement was implemented, weekly support tickets decreased by 16% (average of 23 per week). Woo hoo! 🎉