Portfolio, Ventures & What I Build
Product/systems design that turns AI tech into business results
Contact Us
Contact form or information will go here.
Project Detail
Summary
An event-driven DevOps automation interface that made complex operational logic approachable without sacrificing power.
Infrastructure automation was powerful, but difficult to understand, configure, and monitor. StackStorm needed a visual layer that made event-driven automation feel clear without hiding the technical depth operators depended on.
I designed interfaces for actions, rules, execution history, and workflow visibility, helping teams move from raw automation scripts toward a more understandable operational control system.
The Problem
StackStorm helped engineering and DevOps teams automate infrastructure responses, but the core model was abstract.
Actions, triggers, rules, parameters, and executions all lived as separate mental objects that users had to connect in their heads.
That created friction for users trying to answer basic operational questions: What automation exists? What triggers it? What parameters does it need? What happened when it ran? Can I trust the result?

Without a clear UI, StackStorm risked feeling like a black-box system for all but the most technical users. The challenge was not to simplify automation into something shallow. The challenge was to make complex automation legible.
Solution
An interface around the core objects operators cared about: actions, rules, and execution history.
The goal was to create a visual operating layer for automation without losing the precision of the underlying system.

The Rules interface made automation logic visible. Users could scan what each rule did, see the trigger, understand the action, and inspect the conditions that determined when automation should run.
I treated rules as the narrative center of the product because they explained why automation happened. A rule was not just configuration. It was the bridge between a signal and a response.

The Actions interface helped users understand what could be run and how to configure it. Instead of forcing users to jump between documentation and command-line references, the UI exposed parameters, descriptions, status, and execution options in one place.

The key design decision was to keep the interface technical, but organized. StackStorm users did not need a consumer-friendly abstraction. They needed speed, confidence, and visibility.
That meant using dense tables, clear status labels, compact metadata, and structured panels that supported real operational work.
Outcome
A clearer product surface for one of its strongest ideas: event-driven automation as an operational nervous system.
Users could discover available actions, understand rule logic, inspect execution history, and troubleshoot automation behavior from a coherent interface instead of relying only on scripts, logs, or fragmented documentation.

The product experience helped position StackStorm as more than a backend automation engine. It became a usable control layer for DevOps teams managing complex infrastructure workflows.

Key outcomes:
- Made event-driven automation easier to understand.
- Improved visibility into rules, actions, parameters, and executions.
- Reduced reliance on raw scripts and scattered logs.
- Created a product surface that supported trust, troubleshooting, and adoption.
- Helped translate powerful backend automation into a usable operator experience.