Der Aha-Moment
sollte nicht drei Tage dauern

Aerospike ist leistungsstark, aber schwer zu erlernen. Neue Entwickler wussten nicht, wo sie anfangen sollten. Das Datenmodell zu verstehen bedeutete, zwischen Tools zu springen. Die frühe Erkundung fühlte sich undurchsichtig und fehleranfällig an. Der erste Moment der Klarheit dauerte viel zu lange.

Das eigentliche Problem war nicht nur fehlendes Tooling. Es war ein Mangel an Klarheit, Vertrauen und Momentum in der ersten Stunde mit Aerospike. Bestehende Tools zeigten Power. Keines davon erklärte, was passiert.

Ich war der Product Designer für das gesamte Erlebnis, von der frühen Discovery bis zur fertigen UI. Ich definierte die Produktrichtung, entwarf das Interaktionsmodell und übersetzte komplexe Datenbankkonzepte in etwas, das Entwickler verstehen konnten. Ich arbeitete eng mit Engineering, Produktmanagement sowie Growth- und Developer-Experience-Teams zusammen und blieb während Build und QA involviert, als Randfälle auftauchten.

Der ursprüngliche Plan war, zu prototypisieren, Nutzerfeedback zu sammeln und dann mit dem Build zu beginnen. Das änderte sich früh. Die Annahme war, dass KI es uns erlaubt, die Prototyping-Phase zu überspringen und die App schnell zu bauen, um dann mit echten Nutzern zu testen. Ich habe das damals mitgemacht, und im Nachhinein war das ein Fehler. Wichtige Produkt- und UX-Fragen waren noch ungelöst, als wir in den Build gegangen sind, und wurden in Code gegossen statt zuerst beantwortet. Die Komplikation war, dass schnell zu releasen, um zu testen, und ein Produkt tatsächlich zu releasen dasselbe war. Sobald ein Produkt offiziell released ist, haben neue Features immer Vorrang, und alles, was von Standards abgedriftet ist, bleibt so.

Meine Antwort war, auf Struktur zu setzen statt jeden Qualitätsmangel in Reviews zu diskutieren. Die Erwartungen der Stakeholder daran, was KI produzieren kann, liefen weit vor dem, was sie tatsächlich lieferte. Anstatt das Fall für Fall zu bekämpfen, habe ich ein Standards-System aufgebaut: Design-Guidelines in strukturiertem Markdown, das Tools lesen und auditieren konnten, mit klareren Prozessregeln dafür, wie Design-Feedback in der Praxis funktionierte.

Ich begann mit einer schnellen Discovery-Phase und überprüfte Gong-Calls, internes Feedback, Wettbewerbs-Tools und den ursprünglichen Engineering-Prototypen. Einige Dinge zeigten sich immer wieder. Entwickler brauchten einen klaren Startpunkt, nicht nur Flexibilität. Echte Daten schnell zu sehen war entscheidend für den Vertrauensaufbau. Bestehende Tools zeigten Power, aber kein Verständnis. Aerospikes Kernkonzepte blieben abstrakt ohne Visualisierung.

Das deutete auf den Job-to-be-done hin: von null zu einem funktionierenden Prototypen kommen, schnell genug, um Aerospike für einen echten Anwendungsfall zu validieren.

Die wichtigste Entscheidung war, Voyager als geführten Weg zum Verständnis zu gestalten, nicht nur als Datenbrowser.

Zusammen mit dem Growth-PM definierten wir einen Golden Path für neue Nutzer: Verbinden → Daten hinzufügen → Daten sehen → Untersuchen → Filtern → Sicher experimentieren. Anstatt alles von Anfang an zu zeigen, hilft das Produkt Nutzern, Schritt für Schritt zu bedeutungsvollem Fortschritt zu gelangen.

Die Definition dieses Pfades hat auch das Team ausgerichtet. Produkt, Growth und Engineering hatten unterschiedliche Vorstellungen davon, wofür Voyager ist. Der Golden Path beantwortete die Frage: Wie sieht Erfolg wirklich aus? Er wurde zum Rückgrat sowohl der UX als auch der Telemetriestrategie.

Aerospike ist eine NoSQL-Datenbank. Die Daten sind unstrukturiert, was sie extrem schnell, aber auch schwer zu visualisieren macht. Sie verhält sich nicht wie eine typische JSON-basierte Datenbank. Records, Bins, Datentypen, Ausdrücke und verschachtelte Strukturen erzeugen mentalen Overhead.

Für die Datenerkundung entwarf ich erweiterbare Record-Ansichten, klare Trennung von Struktur und Werten sowie progressive Offenlegung für verschachtelte Daten.

Für Abfragen führte ich einen visuellen Filter-Builder ein, der UI-Eingaben auf Aerospikes Expression DSL abbildet – was die Notwendigkeit reduziert, Syntax auswendig zu lernen, und Nutzern ermöglicht, durch Tun zu lernen. Für riskante Operationen wie Scans entwarf ich klare Warnungen und Leitplanken statt stiller Fehler.

Voyager Preview wurde im April 2026 öffentlich als Aerospikes erstes visuelles Developer-Tool veröffentlicht, verfügbar für macOS, Windows und Linux. Im Umfang deckte es Datenbrowsing, geführtes Onboarding und einen eingebetteten MCP-Server ab. In der Absicht war es das Fundament für etwas Größeres.

Das Maß, das wir intern gesetzt hatten, war ein konkretes: einen Entwickler vom ersten Cluster zur ersten gefilterten Abfrage schnell zu bringen. Nicht Tage. Kein Support-Ticket. Schnell. Jede Designentscheidung im Projekt war darauf ausgerichtet, diesen Weg freizumachen. In der ersten Woche der öffentlichen Preview lag die mittlere Zeit vom Verbinden eines Clusters bis zum Durchsuchen des ersten Datensatzes bei etwa 11 Sekunden. Nicht fünf Minuten. Elf Sekunden.

Es führte eine visuelle Möglichkeit ein, Aerospike-Daten zu verstehen, einen geführten Onboarding-Flow für Entwickler die von null starten, einen visuellen Filter-Builder zum Formulieren von Abfragen ohne Syntax auswendig zu lernen, und Leitplanken bei riskanten Operationen statt stiller Fehler. Und dann ist da noch der MCP-Server, den ich für das interessanteste Ergebnis von allem halte.

Der geführte Pfad, den wir für Entwickler entworfen haben, wurde zur Struktur, die Aerospike für eine Maschine lesbar macht. Tools wie Claude Code, Cursor, Codex und Gemini CLI können jetzt direkt über Voyager mit Aerospike-Clustern kommunizieren, weil das mentale Modell, das wir entwickelt haben, um einem neuen Entwickler zu helfen, sich zu orientieren, dasselbe ist, das KI-Agenten nutzen, um echte Daten zu erkunden. Der MCP-Server kommt mit 21 Tools über Verbindungsverwaltung, Browsing, Record-CRUD und Info-Befehle. In der ersten Woche der öffentlichen Verfügbarkeit hatten Nutzer bereits fast alle davon erkundet. Die UX-Arbeit diente nicht nur dem Produkt. Sie formte, was danach kam.

Innerhalb eines Tages nach dem öffentlichen Launch gab es bereits Hinweise, dass Voyager half, eine Prospect-Evaluation zu gewinnen. Das frühe Nutzerfeedback aus dem Unternehmen war einfach: Es machte ihre Arbeit leichter. Für ein Developer-Tool ist das das richtige Signal zur richtigen Zeit.

Es hat die Erfahrung von "Finde es selbst heraus" zu einem geführten Weg zum Verständnis verschoben.

Interaktionsbeschränkungen und technische Beschränkungen von Anfang an gemeinsam definieren. Komplexität rund um Abfragen, verschachtelte Daten und Randfälle lässt sich früh einfacher gestalten als nachträglich einzubauen.

In diesem Tempo zu bauen bestätigte auch etwas, das ich bereits ahnte: Schnell voranzukommen ohne gemeinsame Grundlage erzeugt Inkonsistenz, die sich aufschaukelt. Diese Erkenntnis hat geprägt, wie ich die Design-System-Arbeit angegangen bin, die danach folgte.

Im Nachhinein hätte ich härter dafür kämpfen sollen, die Prototyping-Phase im Plan zu behalten. Ich habe die Verlagerung zu "schnell bauen und später testen" mitgemacht, ohne die Risiken explizit zu machen, und die offenen Fragen, die wir zuerst hätten beantworten wollen, wurden stattdessen ausgeliefert. Die Spannungen rund um Geschwindigkeit versus Qualität waren real, und ein Teil davon geht auf diese frühe Entscheidung zurück. Das Aufbauen der Standards, des Toolings, des Prozesses für KI-generierten Code erwies sich als nützlich über dieses Projekt hinaus. Aber es wäre günstiger gewesen, den Prototypen zu fahren.