The shipped recorder: what you recorded on the left, whether it works on the right.
Elastic Synthetic Monitoring
I led the design of Elastic's Synthetic Monitoring recorder, helping teams create reliable browser-based monitors without depending on lengthy scripts and fragmented configuration workflows.
The shipped recorder: what you recorded on the left, whether it works on the right.
Synthetic monitoring lets teams simulate critical user journeys and detect failures before customers encounter them.
But creating those monitors was highly technical. Teams often relied on their most experienced engineers to write and maintain long scripts. Configuration lived across YAML files, remote environments, and tools outside the main product experience.
That made a basic monitoring task expensive to create, and difficult to maintain.
The challenge wasn't simply to eliminate code. It was:
Creation, logging and configuration, monitoring, alerting, diagnosis and remediation are connected stages rather than isolated tasks. Our work initially focused on the beginning of that journey: helping users create, understand, validate, and deploy a reliable monitor.
Fix the front of the loop and the whole loop starts turning for people who were previously locked out of it.
I led the design effort from discovery through launch, partnering closely with a Principal Product Manager and 12 engineers. My work included:
I stayed involved throughout development rather than treating design handoff as the end of the process.
One of the most important shifts in the project was realizing that capturing browser interactions solved only part of the problem.
A user could record a journey, but they still needed to understand what the system had captured. They needed to:
That changed how I thought about the product.
That became the foundation for the interaction model.
Early versions emphasized capturing interactions. The recorded actions existed, but the experience didn't yet provide enough structure for users to reason about longer flows. Through testing and iteration, we evolved toward a clearer step-based model.
The later version gave recorded actions clearer hierarchy and made their structure easier to inspect and modify.
Flat list. Two actions presented as two "steps", every input open, nothing nameable, nothing groupable. The test result arrives as a panel over the top, reporting a failure you then have to go and find.
The structure arrives. Steps become containers you can name and collapse, actions nest inside them, and assertions get a control of their own. But a step is still called "Step 1", and the result panel still sits apart from the thing it describes.
1
2
3
None of this changed what the tool recorded. All of it changed whether someone could look at the result and decide to trust it.
Replaying interactions isn't enough for monitoring. A monitor needs to know whether the expected outcome actually occurred. We introduced editable assertions that allowed users to define:
Users could update or delete assertions directly within the recorded journey. This moved the product beyond simple browser automation. It gave users a way to encode what success meant.
Every action carries its own add-assertion control, so saying what must be true happens where the action already is, rather than in a separate mode. The step name is editable in place, which is what lets a long journey be read as phases instead of a list.
Three things, editable and removable inside the journey. That is the whole vocabulary needed to say what success means at a given point, and holding it to three is what kept assertions from becoming a second product.
As recorded journeys became longer, another problem emerged: individual actions weren't enough to communicate the meaning of the flow. Users needed structure. We introduced dividers and editable step names so actions could be grouped into meaningful stages of a journey.
A small interaction decision created a much clearer mental model.
After recording a journey, users needed a way to verify that it actually worked. We added testing directly into the recorder. The result view summarized successful, skipped, and failed steps so users could identify problems before deploying the monitor.
This was an important shift from a recording tool toward an environment for building and validating monitoring journeys.
Before the runner, the loop broke after Record: you exported, ran it somewhere else, and found out. Closing it inside the tool means the person who made the journey is the one who sees it fail.
Users ultimately needed to take what they created and operate it within Elastic's broader Synthetic Monitoring experience. That meant connecting the Electron-based recorder with monitor configuration and ongoing monitoring in the Elastic platform.
The seam is a person, not a file. A front-end engineer produces the script; a DevOps engineer decides how and where it runs, and owns the site's performance afterwards. Designing that crossing, rather than leaving it between two backlogs, was most of the work.
Because the interface represented executable browser journeys, the interaction model couldn't be designed independently from the underlying implementation.
I worked directly with engineering throughout the project, creating detailed interaction specifications, flows, design documentation, and GitHub issues.
That collaboration allowed us to work through product behavior and technical constraints together instead of resolving them after handoff.
The Synthetic Monitoring product achieved 70% adoption among the target user base in its first three months.
The UI script reduced manual testing time by 60%, allowing the development team to spend more time on product improvements.
The recorder exceeded 1,000 downloads within its first months after launch.
The recorder is open source. The repository opened in August 2021 and is still being committed to, and you can read the whole release history rather than take my word for any of it.
Record, edit, ship survived five years of dependency churn, platform changes and new maintainers without the model itself being reworked.
The biggest lesson from this project was that simplifying a technical product doesn't mean removing complexity. It means deciding which complexity users need to see, when they need to see it, and how much control they need at that moment.
The recorder became more useful when we moved beyond simply automating browser interactions and gave users ways to understand, structure, validate, and correct what the system created.
The project also reinforced how important close engineering collaboration is when interaction design maps directly onto technical behavior.