Checkmk is an IT infrastructure monitoring platform used by admins to configure alerting rules across hosts and services at scale.
MY ROLE
As the sole designer, I synthesized usability findings, mapped the flow against real product behavior, and validated every core design assumption directly against Checkmk’s own documentation before finalizing the concept.
DESIGN RATIONALE
I restructured the flow into a guided five-step builder with a persistent live “Affected Hosts” panel, plain-language parameter explanations, inline threshold validation, and precedence-aware conflict detection — plus a reusable design-system pattern for other rule types.
The redesign had to serve a first-time admin who needs guidance and an experienced admin who needs speed — without splitting into two separate products.
Since production environments can have thousands of existing rules, duplication uses a search-first picker rather than a dropdown, surfacing folder, last-edited date, and threshold values so similar rules can be told apart.
Templates are a short, curated list rather than a searchable one — bounded by design, since they're meant to represent a small set of recommended baselines, not every rule that already exists.
Even before any conditions are set, the panel makes clear the rule currently applies to every host in scope — establishing the habit of checking impact from the very first step, not just before saving.
If a critical value is set below the warning value — meaning the alert could never actually fire — the form blocks progress immediately with a clear explanation, rather than allowing a silently broken rule to be saved.
The system distinguishes a genuine conflict from harmless overlap: this rule is flagged specifically because it will sit below an existing rule with the same scope and will never take effect for the shared hosts.
Every value, the scope, and the conflict warning are restated together immediately before the save action, so a rule is never saved without the admin having seen its full consequences.
Every trade-off in the redesign was weighed against three principles: serving both admin personas within one product, surfacing risk before save rather than after, and building one reusable pattern instead of a one-off fix.
RESULT
Deliverables included an interactive desktop prototype, a documented design-system pattern, a decision log with a rationale for every choice, and a validation record that cross-checked assumptions against actual product behavior.
