Features – GDPR
My Role – Planning – UX Design – UI Design
Problem statement
The deletion of a users identity can be handled a number of different ways. The most common is to run a database query or command to eliminate any tables in the database from connecting to the users identity, but the entries which contain the identity are not erased. With the advent of the Right to be Forgotten legislation in the EU, any person can have their identity cleansed from a system on request. This means the entries must be erased in the database.
This left behind content in the system that other users could still experience. How might we provide the best experience for other users to encounter a deleted users content? How might a system admin deal with this situation?
Understanding pain
I interviewed a our internal administrators and enterprise administrators from a number of major companies using Atlassian products.
My team and I sat down and made a journey map of what it took to remove a user from the system. Most of the journey was high pain due to a lack of feedback from the Atlassian admin systems.
An admin could delete a user and then have to go check multiple locations to be sure they were actually gone. In addition, the identity would stick around with orphaned content, a violation of GDPR.
What is a user anyway
Atlassian products have an idea of a user being someone who creates content or interacts with it, on the surface anyway. The deadline to GDPR was two months away and I had to figure out what our success would be.
We could go with a database query, but that had risks. We had to make this easy for admins or they wouldn’t do it.
How users identity flows into the Atlassian software from an external system.
How users were understood by admins and how that understanding was experienced in Atlassian products.
Four days at a whiteboard
Working with my team and the legal department of Atlassian, we went over the structure of how users identity flowed through the systems. Having the legal team there to check the process and its compliance with GDPR.
First steps towards a naming convention
Google Docs, Mural, and other application allow anonymous collaborative users to work together they do so at a smaller scale than we needed. While I took inspiration and guidance from their naming conventions at first, I realized that I would have to move past them to accommodate the enterprise business needs.
I started exploring having admins rename users, but this was a dead end as interviews with admins showed that renaming users was a waste of their time.
What about a drop down to choose manual or automatic naming? I believed we could build on Googles naming conventions but it would rely on an utterly huge amount of animal and color names.
The development team and I figured out that we would run into duplicate names at scale, even out of a large set of animal and color names. So we had to figure out something else.
Testing out options
This left using number combinations for user names after deletion. The issue was if users would be able to track a conversation made up of only anonymous users. I tested out options on UserTesting.
I chose a set of 30 people to gauge comprehension of the identifiable names with people who had no concept of how Atlassian products worked. They were shown three options at random and asked to read the screens out loud, explain what is going on in the conversation and who was talking in the conversation. At the end they were asked what they thought about the names on each screen and what the icons meant.
A normal conversation in an Atlassian product.
This tested badly. The animals and colors bothered people as they explained it felt like an unsettling forced choice, the whimsical nature of it felt unprofessional.
This tested very well. The cadence of the numbers matched combinations found in everyday life: phone, checking, and identity numbers.
Designing the deletion of a user
With 25 out of 30 people able to comprehend the conversation and reference the user names in a conversation, I decided to move forward with a recommendation of the third option and automatic naming a deleted user. We would also use this as a way to automatically rename users who choose to be anonymous in a public region of their system.
In production
With the new design an admin can easily remove users from their system. The system now notifies them of the removal. If additional actions are needed, they are alerted to this. Because users were not actually removed before from the database, a new pop up is added in the flow to provide a positive friction to process and provide information.
Setting permission levels in production
With the newer design, each level of permissions must be set in order for the next stage to be set; an interlock system. Before these could be set in any order. The result would be errors in setting large groups of users permissions.
Putting it all together for administering user permissions
What I learned from this
I learned that sometimes following what others have designed may not be the answer to your users problems. Very quick user research gave me those insights in enough time to pivot the product and development team with weeks to go.
Competitors may have the best answer for their product, but it is always worth exploring if it is right for your users experience. Doing lightweight and quick early signal tests can point the way when you find yourself with too many options.