Query builder for security engineers who think in trees, not lines
Security incident investigation is non-linear by nature. I redesigned the query interface to match how engineers actually think — and the result has stayed in the product ever since.
- RoleSolo designer in team with Product Owner
- Duration6 months
- PlatformWeb, B2B SaaS
The problem
MaxPatrol SIEM is a security incident and event management system used to detect threats across large network infrastructures — often processing thousands of events per minute. At the heart of the product was a single long text input where engineers wrote SQL-like queries to investigate incidents.
Using it required both advanced security expertise and fluency in the product's query language. There was no validation, no guidance, no way to build a query step by step. If you didn't already know what you were doing, the interface offered nothing.
Using it required both advanced security expertise and fluency in the product's query language. There was no validation, no guidance, no way to build a query step by step. If you didn't already know what you were doing, the interface offered nothing.
Research and insigts
Cybersecurity research is difficult. Companies don't want their workflows, infrastructure, or tooling observed by outsiders. Together with the PM, we visited several organisations using SIEM systems — interviewing and shadowing SOC and line engineers on-site.
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.
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.
The key insight came from watching how engineers actually investigate incidents. We had assumed the process was linear — filter by source, narrow by time, get results. The reality was different.
What we assumed:
What we assumed:
Get events for today → filter by source
What we observed ↓
Get events → filter by source → show only login attempts → show only failed ones →
cancel everything →
try a different path
cancel everything →
try a different path
Engineers weren't running a single query — they were navigating a tree of decisions, advancing and retreating until they found the right path. The single text input had no way to support this.
This page, born out of a discussion with the project manager, served as the foundation for the new data query solution.
This page, born out of a discussion with the project manager, served as the foundation for the new data query solution.
Decisions
- Modular "bricks" instead of a single inputThe core idea was to break the query into discrete, stackable steps — visually separate modules we called "bricks". Each brick represents one operation: filter, group, aggregate, or visualise. This maps directly to how engineers think: one step at a time, each one building on the last. It also makes the query readable at a glance — no more parsing a long string of SQL-like syntax to understand what a query does.
- Visual constructor: click to configure, no code requiredEach brick starts collapsed. Click to expand it, and it reveals the options, attributes, and values for that step. Engineers who know the query language can still type directly — but those who don't no longer have to. This lowered the barrier to entry without removing power from experienced users.
- Enable / disable without rewritingOne of the most painful parts of the old interface: if you wanted to temporarily remove a step from your query, you had to delete it and rewrite it later. The brick system introduced a toggle on each module — disable a step, keep it in place, re-enable it when needed. This directly supports the non-linear investigation pattern we observed in the field.
- Visualisation as the final step in the sequenceVisualisation was technically a separate feature in the product. But once we had the modular brick pattern, it became obvious that visualisation is just another data step — what you do after filtering and grouping. Placing it at the end of the sequence made the relationship between data manipulation and output explicit, and gave the whole flow a natural endpoint.
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.
High fidelity wireframes
The concept progressed, and I prepared patterns and different states of this UX for the development
Outcome
The query builder shipped and became a core part of MaxPatrol SIEM. Years later, it's still in the product — evolved and extended, but built on the same structural foundation.
That longevity is the result of a deliberate choice: rather than designing for a specific set of use cases, the brick system was designed to be extensible. New data operations could be added as new bricks without breaking the pattern. The interface grew with the product instead of being replaced by it.
That longevity is the result of a deliberate choice: rather than designing for a specific set of use cases, the brick system was designed to be extensible. New data operations could be added as new bricks without breaking the pattern. The interface grew with the product instead of being replaced by it.
