Appsignal

Logging update

— PROJECT NAME

Appsignal

— ROLE

Product design

— DATE

March, 2022

— COLLABORATE WITH

Wes Oudshoorn

Appsignal is the all-in-one APM service for Ruby, Elixir, and Node.js.

We are building Appsignal of developers, for developers, and by developers. We have 6 different significant features – error tracking, performance monitoring, anomaly detection, host monitoring, and uptime monitoring. It's all about finding a developer-centered solution in order to make them happy.

I've participated in multiple projects – launching new product features for error tracking, updating the onboarding process, organizing the design system, and creating new landing pages.

When we were doing a user interview, we got a suggestion about a ‘logging’ feature from one of our users. This project started from there, and now it’s one of the most important features in Appsignal. This posting is about updating a new feature – 'logging'.

Logging is one of the most important things for developers to understand the context of incidents. It’s compiling the log of events in a computer system, so developers can see the raw data such as problems, errors, etc.

So, what we are focusing on is creating a better solution in finding the actual error message more quickly. Usually, it might be hard for developers to find the right error message because a lot of raw messages are being piled up every second.

Competitor analysis

In one log line, there are different types of information such as date, timestamp, server information, group, and actual message. The first thing I tried to do was listing up the actual log data to see what would be the best way to sort out the information efficiently so the users could find the right information quickly.

List up which kind of information in one log line.

But before setting up actual filters, we set up the interviews internally to better understand our users. Throughout several interviews, we have figured out several points to focus on based on our users’ behavior.

1. Our users can get used to the new feature quickly.

2. Our users can easily get tired of repetitive actions.

3. Our users want to customize their views about the product.

4. Our users don’t want to scroll a lot, so it’s important to show a large amount of data in one screen.

We have come to the realization that the filters will be a must-have in the future. Also, the idea was to make a customized view so users can hide unnecessary information if needed. This way, true values would be found by filtering and setting up the priorities.

From there, I started drawing the user flow of each feature in order not to miss out on any detail. For example, the userflow below is about how to save their customized view, because we know our users hate setting up the same filters again and again. Thus, the customized view allows them to save their own settings and make the entire process more time-saving.

User flow: how to save the customized filters?

Wait, why don’t I have the wireframes here?

When we are thinking of the purpose of the wireframe, it comes down to establishing easier communication with the team before jumping into an actual design so we don’t have to miss any structures, functions or features.

But when there’s already a solid design system, which makes super quick mock-ups, somehow the wireframes won’t be necessary anymore. You can easily grab the components from the design system, which will make things easier and more coherent.

Delivering the best product design is all about timing. So, it’s rather questionable whether we should follow the process just because it’s usually considered important.

Anyway, I love this moment, where I can play with the design and different types of solutions.

Yay playing around!

Here is the fun part! Communication with our developers! :)

Sometimes I am not using the mockups intentionally to not block their imagination, but usually it’s always helpful to have some mockups to have a conversation with the team especially when you have to talk about the details of the features.

So I made the mockups of each process and leave the notes and comments to consider and apply the feedback.

It’s important to deliver the clear message and design direction to the team so they can see the blueprint of the product.