The aha moment
shouldn't take three days

Aerospike is powerful but hard to learn. New developers didn't know where to start. Understanding the data model required jumping between tools. Early exploration felt opaque and error-prone. The first moment of clarity took too long to reach.

The core issue wasn't just missing tooling. It was a lack of clarity, confidence, and momentum in the first hour of using Aerospike. Existing tools exposed power. None of them explained what was happening.

I was the product designer across the entire experience, from early discovery through to shipped UI. I defined the product direction, designed the interaction model, and translated complex database concepts into something developers could reason about. I worked closely with engineering, product management, and growth and developer experience teams, staying involved through build and QA as edge cases surfaced throughout.

The original plan was to prototype, get user feedback, then commit to build. That shifted early. The belief was that AI let us skip the prototype stage and build the full app fast, testing with real users from there instead. I went along with it at the time, and in hindsight that was the wrong call. Important product and UX questions were still unresolved when we moved into build, and they got baked into code rather than answered first. The complication was that releasing fast to test and actually releasing a product turned out to be the same thing. Once a product is released officially, new features always take priority and anything that has drifted from standards stays that way.

My response was to push for structure rather than argue each quality gap in review. Stakeholder expectations about what AI could produce were running well ahead of what it actually delivered. Rather than fighting that case by case, I built a standards system: design guidelines in structured markdown that tools could read and audit, with clearer process rules for how design feedback worked in practice.

I started with a fast discovery phase, reviewing Gong calls, internal feedback, competitor tools, and the original engineering prototype. A few things showed up consistently. Developers needed a clear starting point, not just flexibility. Seeing real data quickly was critical to building confidence. Existing tools exposed power, but not understanding. Aerospike's core concepts remained abstract without visualisation.

This pointed to the job-to-be-done: get from zero to a working prototype fast enough to validate Aerospike for a real use case.

The most important decision was to design Voyager as a guided path to confidence, not just a data browser.

Working with the growth PM, we defined a golden path for new users: Connect → Add data → See data → Inspect → Filter → Feel confident experimenting. Instead of exposing everything upfront, the product helps users move step by step toward meaningful progress.

Defining this path also aligned the team. Product, growth, and engineering had different ideas about what Voyager was for. The golden path answered the question: what does success actually look like? It became the backbone of both the UX and the telemetry strategy.

Aerospike is a NoSQL database. The data is unstructured, which makes it extremely fast but also hard to visualise. It doesn't behave like a typical JSON-based database. Records, bins, data types, expressions, and nested structures all introduce mental overhead.

For data exploration, I designed expandable record views, clear separation of structure versus values, and progressive disclosure for nested data.

For querying, I introduced a visual filter builder that maps UI inputs to Aerospike's Expression DSL — reducing the need to memorise syntax and letting users learn by doing. For risky operations like scans, I designed clear warnings and guardrails instead of silent failures.

Voyager Preview shipped publicly in April 2026 as Aerospike's first visual developer tool, available on macOS, Windows, and Linux. In scope, it covered data browsing, guided onboarding, and an embedded MCP server. In intent, it was the foundation for something bigger.

The measure we'd set internally was a concrete one: get a developer from first cluster to first filtered query fast. Not days. Not a support ticket. Fast. Every design decision through the project was oriented toward clearing that path. In the first week of public preview, the median time from connecting to a cluster to browsing the first record was about 11 seconds. Not five minutes. Eleven seconds.

It introduced a visual way to understand Aerospike data, a guided onboarding flow for developers starting from zero, a visual filter builder for shaping queries without memorising syntax, and guardrails on risky operations instead of silent failures. And then there's the MCP server, which I think is the most interesting outcome of all of it.

The guided path we designed for developers became the structure that makes Aerospike legible to a machine. Tools like Claude Code, Cursor, Codex, and Gemini CLI can now talk directly to Aerospike clusters through Voyager, because the mental model we built to help a new developer orient is the same one AI agents use to explore real data. The MCP server ships with 21 tools across connection management, browsing, record CRUD, and info commands. In the first week of public availability, users had already explored nearly every one of them. The UX work didn't just serve the product. It shaped what came after it.

Within a day of the public launch, there was already evidence of Voyager helping win a prospect evaluation. Early user feedback from inside the company was simple: it made their work easier. For a developer tool, that's the right signal at the right time.

It reframed the experience from "figure it out yourself" to a guided path to confidence.

Define interaction constraints alongside technical constraints from the start. Complexity around querying, nested data, and edge cases is easier to design for early than to retrofit late.

Building at this pace also reinforced something I already suspected: moving fast without a shared foundation creates inconsistency that compounds. That realisation shaped how I approached the design system work that followed.

Looking back, I should have pushed harder to keep the prototype stage in the plan. I went along with the shift to "build fast and test later" without making the risks explicit, and the open questions we'd planned to answer first got shipped instead. The friction around speed versus quality was real throughout, and some of it traced back to that early decision. Building the standards, the tooling, the process for AI-generated code ended up being useful beyond this project. But it would have been cheaper to run the prototype.