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 Initial understandings
The first few discussions were about understanding how information is categorised. Which events are we covering? What all information do we store for an event? What extra capabilities will the Audit Log page have? What is the general expected interaction for a feature like this?
The first few discussions were about understanding how information is categorised. Which events are we covering? What all information do we store for an event? What extra capabilities will the Audit Log page have? What is the general expected interaction for a feature like this?
Create, Update & Delete were the 'Event Type' categories that were most relevant in our use case. A download function was necessary to export, save and send event details. Additional properties in some specific events were necessary to understand the context. Few features like the 'Read' event (from CRUD); the ability to set up notifications/ alerts for specific high-risk changes; and adding a 'go-to-page' link for events - These mini features were discussed as additional help to our users, but were determined not to be entirely necessary for our users at this stage.
I moved forward with creating the first versions of the interface after these details were discussed. Reviews were done with the Product Manager, Engineers, and Senior Designers for feedback and refinement of the the design.
I moved forward with creating the first versions of the interface after these details were discussed. Reviews were done with the Product Manager, Engineers, and Senior Designers for feedback and refinement of the the design.
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.
✅ The "Pill" filters are already used in different places in the product - familiar design, highly customizable pinned filters.
⚠️ Too many steps to build a search query. Start point, and task flow not clear.
✅ Clear task flow with layout guiding the steps - first build search query with filters, then see results.
⚠️ Too many options make the page visually overwhelming. No pre-loaded table lowers understanding of log formats. Very mechanical flow of searching.
✅ One Search box for all inputs. User can start with any key word that comes to mind. Add keywords to filter further.
⚠️ A completely new type of search box will have to be built. No guidance at all from labels and prompts can be confusing.
To see the final solution,
use the password provided on my Resume to access the full case study!
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.
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.