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 over 90% of 250+ clients
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.
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.
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.
A place like an Audit Log also has opportunity to be used in new ways, if given access to different roles. It can be used as a checklist, to see if a certain task has been completed as per schedule. Or see the history of how a certain entity in the product has been modified over time - For example, from creating an Evaluation form, to submitting it, to it being acknowledged by an Agent.
A place like an Audit Log also has opportunity to be used in new ways, if given access to different roles. It can be used as a checklist, to see if a certain task has been completed as per schedule. Or see the history of how a certain entity in the product has been modified over time - For example, from creating an Evaluation form, to submitting it, to it being acknowledged by an Agent.
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.
Search Users with in-Column filter
Select from list of available events
Reports sent to email in a .csv format
The Version History of this Design
As many iterations were made, the column header also evolved. How do we show the information in the most readable manner? How do we make sure an event is not misinterpreted? What is the essential information to show upfront in the table, and what do we tuck away in the drawer?
Combining Event, Entity and Entity Name into one column made a lot of difference. This was inspired by Figma's Activity Logs.
Shown below is how the table changed in various versions before reaching the final design.
Another challenge in this project was the balancing act of filters and the search box. Filters are the primary way in which a user interacts with the table, and looks for what they want. How filters were treated on this page also evolved during the project.
✅ 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.
The Final Layout
The final design represented the most straightforward and simple workflow. It was a combination of different filters and searching methods that felt intuitive and easy to use.
The final design represented the most straightforward and simple workflow. It was a combination of different filters and searching methods that felt intuitive and easy to use.
✅ Combined 'Entity', 'Event details' and 'Event' type into one column for easy understanding of the event.
✅ The 'Search' box was a familiar pattern in the product, and provided the right balance of flexibility and relevance.
✅ The 'Search' box was a familiar pattern in the product, and provided the right balance of flexibility and relevance.
✅ Single selection dropdown of 'Event' type satisfied the use case.
✅ Straightforward workflow, an event can be found even with just 2 inputs. Combinations of date range, name, event, search properties can be used in multiple ways of searching.
✅ Straightforward workflow, an event can be found even with just 2 inputs. Combinations of date range, name, event, search properties can be used in multiple ways of searching.
Engineering Considerations
The way event 'Properties' or metadata are recorded, is dependant on the documentation practises of various different teams in the company. So, the extra information in the 'Properties' section in the open drawer was not in our control, or even predictable.
Even naming trends that would appear in 'updated' type events were not standardised. When we started to test this interface, and receive data from backend teams, a lot of discussion was needed to make sure the data is understandable in the tabular, and JSON format.
The way event 'Properties' or metadata are recorded, is dependant on the documentation practises of various different teams in the company. So, the extra information in the 'Properties' section in the open drawer was not in our control, or even predictable.
Even naming trends that would appear in 'updated' type events were not standardised. When we started to test this interface, and receive data from backend teams, a lot of discussion was needed to make sure the data is understandable in the tabular, and JSON format.
Experience, learnings, many thanks
Even though Audit Logs is an expected feature; every enterprise product has it - but it is still a challenging one to get right. The first few iterations I made were quite complex. I was in the headspace of understanding technically how information is sorted within the product. It took some time to make the simplest version possible. My last contribution to the product was having bug fixing discussion with Front-end and Back-end engineers, before I had to leave to pursue a Masters degree.
I am thankful to the Product Manager of this project Ritesh Sharma, who I share great synergy with, and have had the pleasure of working with on multiple successful projects. Special thanks to our Principle Product Designer Bhasker Sharma whose deep product knowledge and clarity of thinking has been an irreplaceable guidance in this project.
Even though Audit Logs is an expected feature; every enterprise product has it - but it is still a challenging one to get right. The first few iterations I made were quite complex. I was in the headspace of understanding technically how information is sorted within the product. It took some time to make the simplest version possible. My last contribution to the product was having bug fixing discussion with Front-end and Back-end engineers, before I had to leave to pursue a Masters degree.
I am thankful to the Product Manager of this project Ritesh Sharma, who I share great synergy with, and have had the pleasure of working with on multiple successful projects. Special thanks to our Principle Product Designer Bhasker Sharma whose deep product knowledge and clarity of thinking has been an irreplaceable guidance in this project.