ES|QL Editor

I designed and shipped the redesigned ES|QL editor: better query authoring for developers and technical users, without losing ground on the advanced workflows the old one supported.

Context

An editor is the most unforgiving surface in a data product. It is used constantly, by people who are fast at it, and every millisecond of friction is felt hundreds of times a day. It also has to be the place where someone writes their first query without feeling stupid.

My role

I owned interaction design, developer experience and accessibility on this, working directly with engineering through delivery.

The problem

The editor had to get better at two opposite things simultaneously: discoverability for people learning the language, and speed for people who already know it. Optimising for either one alone would have made the other worse.

Draft gap (Laura): what specifically was hard about the previous editor? Concrete before-and-after is the strongest possible material here, and screenshots do most of the talking.

Approach

Discoverability in an editor comes from the system telling you what's possible at the exact moment you could act on it, not from documentation elsewhere. The design work was largely about timing and placement of that guidance, and making sure it never blocked someone who already knew what they were typing.

Accessibility was treated as a constraint from the start rather than a pass at the end. An editor that only works with a mouse is not an editor.

Draft gap (Laura): the specific interaction decisions: autocomplete behaviour, error surfacing, keyboard model. This is the section where your engineering background shows, so it's worth the detail.

What shipped

Draft gap (Laura): what's live, and what improved. Note any accessibility outcomes explicitly: very few product designers can speak to that credibly, and you can.