Case study: data query language UX
Query builder for information security incidents
Research and insigts
We work hard every day to make our customers' lives better and happier
Do you see the loooooong input above the table? This is one of the most important places in the product.

MaxPatrol SIEM (Security Incidents and Event Management System) is developed to prevent and detect security incidents, especially in real-time. It offers insights into network infrastructure activities, potentially involving thousands of events per minute. The duty of the security engineer is to identify and probe any unusual events.

The engineers needed advanced security skills and proficiency in our software's SQL-like language to work remotely without a validation process.
SELECT time, event_src.host, text ORDER BY time
On-site discovery
I interviewed on-site security engineers to understand their use of the software. This provided me with domain insights, despite their bias towards the software.
Espionage: guided tours
Research in the field of cybersecurity is challenging. No one wants their experiments, site visits, or data exposed to unknown entities. Our project manager scheduled visits to several companies that use Security Incident and Event Management systems. During these visits, we interviewed SOC engineers to understand their work processes.
Observation in the field
We observed the work of the SOC and line engineers, gathering as much information as possible since we were unable to arrange UX tests.
Initially, we thought that searching events was like this ↓
OK Maxpatrol, give me events for today, filtered by this source
After the discovery, we thought it was like this ↓
OK Maxpatrol, give me events for today, filtered by this source
THEN
show me only login attempts
THEN
show me only failed ones
However, the search wasn't linear.
The engineers advanced, then retreated, then advanced again in different directions. They were navigating through a tree of decisions to find the right path.
This page, born out of a discussion with the project manager, served as the foundation for the new data query solution.

Low fidelity wireframes
We chose to visually deconstruct the query into multiple steps, symbolized by "wagons," although they quickly became known as "bricks". This method lets us concentrate only on the most recent part of the search. We ask: Is this step adequate? Does it supply the engineers with the information they need? If the answer is yes, they can continue with a more detailed search.
We've decided to categorize several data manipulations, including filtering, grouping, aggregation, and visualization.

Despite it being a separate functionality in the system, we've included visualization as the final stage in this sequence. Upon adopting this modular pattern, visualization seamlessly integrated as the subsequent data step.

Furthermore, we've incorporated a feature to enable or disable modules. This means the engineer won't need to redefine the query when necessary.

Initially, the bricks served merely as a visualization of the query. However, we took it a step further by creating a visual constructor. With a simple click, each brick expands to reveal options, attributes, values, parameters, and more. This was designed to give engineers the option to avoid writing code whenever possible.

High fidelity wireframes
The concept progressed, and I prepared patterns and different states of this UX for the development
How it is going
This interface remains in the product and has evolved from its original design. Take a look at the presentation of one of its versions.