Audit Logs for Observe.AI
Duration: 2 months
Role: Lead Product Designer
Team: Product Designer, Product Manager, Front End and Back End Engineers
Status: ✅ Shipped, available in product and used by ~ 90% of 250+ customers
The Problem
The current process to track unwanted changes in reports and dashboards was a lengthy one. Admins of companies using our product reach out to Observe for the records, whenever they need any. Then our engineers pull a report from their database and send it the customer's way in 1-2 days.
The current process to track unwanted changes in reports and dashboards was a lengthy one. Admins of companies using our product reach out to Observe for the records, whenever they need any. Then our engineers pull a report from their database and send it the customer's way in 1-2 days.
An in-product place to store this information, especially in a B2B enterprise product was a must have, and it gave customers a self-serve damage-control mechanism.
Goal
To create a way for a user (usually an Admin) to view, search, filter and download events that happen on their company's account.
The Design Challenges
1) Filters & Search combinations
The main way to search for an event is through a filter - be it a search box, or a dropdown list. Many options were considered in combinations and in different layouts. The placement of the filters also guide where a user must start to get to an event they have in mind.The workflow had to be simple and avoid any confusion regarding the terms used.
Options had to be designed keeping in mind if users were familiar with a particular pattern (used somewhere else in the product), if a variation was available in the design system, or considering if something entirely new had to be designed for this specific purpose.
The design of the filter and search should emulate the way a user would think of or 'build' the path to find an event - and balance the interface with the objectiveness of technical resource labels and the ease of general wording.
The design of the filter and search should emulate the way a user would think of or 'build' the path to find an event - and balance the interface with the objectiveness of technical resource labels and the ease of general wording.
2) Making the table readable
As the project moved forward, the table format evolved with feedback from designers, product managers and engineers. Events had to be easily identifiable from the information in cells. We discussed naming the columns, which fields to show up-front, and how it would interact with / respond to the filters.
As the project moved forward, the table format evolved with feedback from designers, product managers and engineers. Events had to be easily identifiable from the information in cells. We discussed naming the columns, which fields to show up-front, and how it would interact with / respond to the filters.
3) Engineering considerations
With events coming from different parts of the product, we did not know exactly the amount and kind of metadata that would accompany each event. There was a need to look into how various teams defined an 'event'. Then, if there were discrepancies, depending on the reason, either the design should accommodate it, or the naming systems in the backend should be standardised.
With events coming from different parts of the product, we did not know exactly the amount and kind of metadata that would accompany each event. There was a need to look into how various teams defined an 'event'. Then, if there were discrepancies, depending on the reason, either the design should accommodate it, or the naming systems in the backend should be standardised.
All images are illustrative & don't represent the actual product.
To see the solution and look at the story in detail,
use the password provided on my Resume to access the full case study!
Experience & reflections
Even though the Audit Log is an expected feature in a B2B product, it is still a challenging one to get right. The first few iterations I made were quite complex. I started by understanding technically how information is sorted within the product. Initial discussions were about which exact features to include in the page, the kinds of events being considered, and also learning about the general design of audit/activity logs. After discussions with the team, we decided on naming conventions, the filter formats and it took time and feedback to make the simplest version possible. With time, once we have usage data and specific user feedback, more improvements can be made to enhance the interface.
Even though the Audit Log is an expected feature in a B2B product, it is still a challenging one to get right. The first few iterations I made were quite complex. I started by understanding technically how information is sorted within the product. Initial discussions were about which exact features to include in the page, the kinds of events being considered, and also learning about the general design of audit/activity logs. After discussions with the team, we decided on naming conventions, the filter formats and it took time and feedback to make the simplest version possible. With time, once we have usage data and specific user feedback, more improvements can be made to enhance the interface.