Detective work in user management space
In the end of 2017 Atlassian Crowd, a user management software, was in dire need of a detailed audit log. I was part of the team that took existing audit log and implemented new patterns that would become the basis of a cross-product auditing.
"We're experiencing a problem where a user is getting deleted sometime during the night. We're not sure what user or more likely, what automated process is removing this user."
- large streaming company
note: because of my non-disclosure agreement, I have omitted confidential information in this case study, including exact data and some elements of the design.
My role
I led design process for the project, including preliminary research and benchmarking, workshops with the development team, and user testing. I was responsible for design deliverables from early mockups illustrating information architecture to final hi-fidelity designs to instruct implementation.
Challenges
Crowd is a less known Atlassian product for user management; it is used heavily by large enterprises that often obtain new business entities.
User management is a complex area; the minimal entity is user that can be a member of a group, which itself can be a part of another group or a set of groups. These can be located in directories, both internal to a product or external (such as LDAP or Azure AD). The directories can be then plugged into applications (which is another name for products like Jira, Confluence, Bitbucket, etc.). Till 2018, Crowd's audit log only showed actions connected to applications.
Teams of product administrators using Crowd can be spread across geos and not communicate with each other. This quickly became a problem, when an admin would remove a user from a group - suddenly a person was not able to log into their account or lost access to their project. And this couldn't be traced.
We were gathering feedback that extension of the audit log is necessary, however I also believed that a simple addition of new categories would not be enough. I believed we needed to rework the whole information architecture of the feature.
Research: Wonder & EXPLORE
I set off by looking at the audit logs in other Atlassian products to find common patterns. Having identified these, I mapped out all entities one would like to audit for in user management space and created a sketch for new IA.
The audit log was designed to tell a story:
When someone did something to a thing/someone where and how.
Date + author + action + object affected + place + source
Persona
Will, Crowd administrator
Will works in a company that buys new business every week. He's responsible for managing users across the whole organization. He's not working alone, he has teams working from different time zones. Will is not a fan of detective work, but he needs to do a lot of it when something happens to user database and he needs to learn why some groups disappeared... and fix the mistakes by recreating deleted elements.
Problem statement:
As an admin responsible for user management, I need to be able to track who did certain actions that resulted in user management issues, so I can react quickly and prevent security breaches.
User Testing
I prepared three scenarios to test different aspects of the new audit log. During user testing sessions, the admins from large companies were asked to click through an Invision prototype as if they were really searching for clues in an investigation.
The scenarios included finding out why a given user is not able to log in to a product or finding out a culprit of mass group deletion.
The tests went really well and uncovered an interesting thing: the last scenario showcased a functionality available in the basic version of the audit log (expandable table rows, showing info on the change). It turned out the users didn't know the feature existed and were very happy it will be included in the new version.
An updated version of the extended audit log: new filter component has been added.
Implementation
I believed that anything in a data heavy table should be filterable, thus I insisted on implementing a full set of filters.
Some of the aspects of design had to be altered in implementation: because of performance issues, we had to resign from entries counter and true pagination.
Impact
The use of the new audit log quickly surpassed the use fo the old one. In the first 9 months from the release, the extended audit log has been viewed 3970 unique times. Almost 30% of these instances used filters, the most common filter used was 'user' with 'action' being closed second.
"The improved Audit interface is so much better than the existing Jira/Confluence, etc. ones too - go show the rest of the teams how it is done."
- CTO of a large advertising and PR company
The IA of the extended audit log has been used as the base for cross-product audit log in 2019, when new consistent experience substituted different in-product logs.