Timeline

Reimagining the classic audit log

Timeline

Almost every piece of software has some kind of audit log. Timeline is an attempt to take that complicated data and convert into a simple readable format that a CSR can use to find important information related to a single customer.

User interviews

To start we had to ask our customers what their problems were with the current Audit Log. Some key highlights from our research include:
‍
‍- "It's impossible to know when an event happened"
- "I don't know who this transaction belongs to"
- "I can't find my customer very easily"

Requirements

These are just a few of the most common responses received when we asked the question: "What are the  problems you have?"

‍Taking the research and working with our product team, we were able to whiteboard out a set of requirements we could use to establish our HMW statement: "How might we ensure an employee can easily find the events for a
specific customer?"

Exploration

From this point we had to start thinking about the data we would need. This took me personally into a new tool I'd surprisingly not used too much - Google sheets. A tool that I am sure many of us would not suspect of being a design tool, but one that we used to design the data that would form the base for all that followed.
‍
After many weeks of struggle looking at and trying to tidy data, we were able to create a amount of events that we wanted to display in the newly named Timeline.

Building out the idea

These events would cover the vast majority of customer activity from login to logout, and all the actions that could take place between. We also wanted to ensure we had accountability and security, and added in employee access to a customer profile. This would mean that suspicious activity could be monitored with ease. Once the data was squared away, we began exploring how we would display it. Exploring these sections allowed us to consider several options for how to proceed. By starting with sketches, whiteboards and eventually Miro, we were able to understand on what our customers required as important, we developed 3 clear sections;
‍
‍- 1.  Event details
- 2. User
- 3. Related events

At this point, we also explored other ways to present this data, could it be present all the time? What would the impact be on resources if it was? But we decided that at the time, the number of API requests and the amount of APIs needed would be too high to have it permanently visible and updating and opted to pause this exploration until a new API could be created to handle it.

Once more unto Figma

Now we had a clear understanding of the areas we wanted to focus on, the data we needed and the resources required, we were able to move from low fidelity into Figma and eventually on to prototypes.

Event details would be all the important data points that could help anyone understand what happened, why and when. User covers who conducted the action, be it the customer, employee or system. Related events documented anything that could be of interest to the employee and help them dive deeper if needed.After developing the idea into what is shown here, we needed to test our hypothesis and adapt based on that information.

Structuring the data

Now we had the data and groups all sorted, we needed to begin creating examples of how each set of data would look and work. To do this we created a template in our Figma files, one that could easily be changed and adjusted for any situation. Below are just two examples of the template, though the Figma file has nearly twenty different filled versions.

Each follows the same pattern, the first item is the Timeline table view. We asked ourselves what is the important information to have present here? How much does an employee need to see at this point? How can we make it scannable? Settling on some consistent themes of, date/time, icon, event and user we created a simple yet effective table row that solved all these needs.

Then we needed to explore how the rest of the data would work. "How much is too much?" was a common question we asked ourselves during this step. In the end, we dove back into our research to find the answers and realised there is several consistent elements we could use and because of this, we could create a repeatable pattern that would allow us to populate the details view easily and would enhance the user experience of the journey.