Eine Matrix aus 209 Seiten: Branchen, Features und Partner

Foto: Bob Richards · StockSnap (CC0 1.0), via Openverse

Es gibt einen Moment in jedem Produkt, in dem man merkt: Die eine Startseite reicht nicht mehr. Ein Physiotherapeut, der nach Terminbuchung sucht, will keine generische „Alles für alle"-Seite lesen. Er will die Seite, die von seiner Branche und genau seinem Problem spricht. Und ein Fitnessstudio, das über Mitgliederabrechnung nachdenkt, ebenso. Multipliziert man diese beiden Achsen — Branche und Feature — landet man schnell bei Dutzenden, dann Hunderten von Kombinationen. Das ist die Woche, in der ich aufgehört habe, diese Seiten von Hand zu denken, und angefangen habe, sie aus einem Katalog fallen zu lassen.

Die Idee klingt banal, bis man sie ernst nimmt. Wer 200 Landingpages einzeln pflegt, pflegt sie nach drei Monaten nicht mehr. Die Texte veralten, die Navigation driftet auseinander, und irgendwann findet niemand mehr die Seite, auf der der falsche Preis steht. Also musste die Matrix nicht nur existieren, sondern sich selbst erklären, selbst verlinken und selbst prüfen lassen.

Die Matrix: eine Achse Branche, eine Achse Feature

Der Kern ist eine Marketing-Matrix, die 209 Feature-Seiten pro Branche unter dem Routenmuster /solutions/{org}/{feature} erzeugt. Jede dieser Seiten ist die Kreuzung aus einem Organisationstyp — Studio, Praxis, Verein, Klinik und so weiter — und einem konkreten Feature wie Terminbuchung, Zugangskontrolle oder Mitgliederabrechnung. Statt einer flachen Feature-Liste bekommt jede Branche ihre eigene Sprache: dasselbe Feature, aber im Vokabular der Leute, die es tatsächlich einsetzen.

Und weil Xircuit zweisprachig lebt, existiert jede Seite in Englisch und in deutschem Sie. Das ist kein automatisch übersetzter Anhang, sondern Teil derselben Struktur — die kulturpräfixierten Routen tragen die jeweilige Sprache, und der formale Ton auf der deutschen Seite ist bewusst, nicht zufällig. 209 mal zwei Sprachen ist eine Menge Text, und genau deshalb durfte kein Wort davon von Hand kopiert werden.

Alles aus dem Katalog, nichts von Hand

Der entscheidende Entwurf war, die Seiten nicht als Dateien zu behandeln, sondern als Ausgabe. Sie werden aus einem Feature- und Branchen-Katalog generiert, statt einzeln gepflegt. Die Slugs — also /solutions/gym/appointment-booking und seine Geschwister — stammen direkt aus diesem Katalog. Es gibt keinen zweiten Ort, an dem ein Slug definiert wird, keine Liste, die man vergisst zu aktualisieren, wenn man ein Feature umbenennt.

Das hat einen angenehmen Nebeneffekt, den man erst im Betrieb schätzt: Die Wahrheit lebt an einer Stelle. Kommt eine neue Branche hinzu, entstehen ihre Feature-Seiten in beiden Sprachen von selbst. Fällt ein Feature weg, verschwinden die zugehörigen Seiten, ohne dass irgendwo eine tote URL zurückbleibt. Der Katalog ist die Quelle, die Seiten sind nur seine Projektion — und eine Projektion muss man nicht pflegen, man muss nur die Quelle richtig halten.

Zur Matrix kamen zwei kleinere Bausteine, die aus derselben Katalog-Idee folgen. Eine katalog-generierte Sitemap entsteht direkt aus den bekannten Routen, sodass Suchmaschinen den vollständigen Graphen sehen, ohne dass ich die Sitemap von Hand nachziehe. Und ein Screenshot-Lightbox erlaubt es, Produktbilder auf den Seiten groß aufzuziehen, statt sie in Briefmarkengröße verkümmern zu lassen.

Partner bekommen ein eigenes System

Eine Produktseite erzählt, was das Produkt kann. Sie erzählt selten, mit wem es zusammenspielt — und gerade im Gesundheits- und Studiokontext ist genau das eine Vertrauensfrage. Deshalb gibt es jetzt ein eigenes Partner-System mit einer /partners-Übersicht und einzelnen Detailseiten, das die Integrationspartner vorstellt.

Foto: Snappa.io · StockSnap (CC0 1.0), via Openverse

Auf der Übersicht landet der Leser bei den Namen, die im Alltag der Plattform eine Rolle spielen: Apple mit HealthKit für die Gesundheitsdaten auf iOS, Stripe für die Zahlungsabwicklung, Withings für Körper- und Vitalmessungen und Abbott für die Glukosesensorik. Jeder Partner hat eine eigene Detailseite, auf der die Integration mehr Raum bekommt als eine Logo-Zeile — was verbunden wird, warum es zusammenpasst, und was der Nutzer davon hat.

Ein ehrlicher Vermerk gehört dazu: Nicht jedes Partnerlogo, das dort heute steht, ist schon der finale Stand. Die Apple-Zusammenarbeit läuft über das HealthKit-Framework, und die genaue Darstellung — bis hin zum offiziellen Badge — folgt eigenen Regeln, die wir respektieren, bevor wir sie prominent ausspielen. Das Partner-System ist die Struktur; das Ausschmücken einzelner Kacheln ist die kleinere, laufende Arbeit.

Über uns, noch einmal von vorn

Die Über-uns-Seite habe ich neu geschrieben. Die alte war ein Relikt aus einer Zeit, in der das Produkt kleiner und die Geschichte kürzer war — sie klang nach Platzhalter, weil sie einer war. Die neue Fassung erzählt, wer hinter Xircuit steht und wofür die Plattform da ist, ohne in die üblichen Über-uns-Floskeln zu kippen.

Genau hier zahlt sich der eben erwähnte Screenshot-Lightbox aus: Die Seite zeigt echte Produktansichten, und wer eine davon anklickt, sieht sie groß, statt raten zu müssen, was auf dem Miniaturbild passiert. Eine Über-uns-Seite ist am Ende auch ein Verkaufsargument — nur eines, das über Vertrauen läuft statt über Feature-Listen, und Vertrauen verträgt keine unscharfen Bildchen.

Wie man 209 Seiten überhaupt noch prüft

Der eigentliche Grund, warum eine generierte Matrix funktioniert und eine handgepflegte irgendwann zerfällt, ist die Prüfbarkeit. Über 900 Website-Tests sichern die Matrix ab. Sie stellen sicher, dass jede Kombination aus Branche und Feature tatsächlich eine Seite ergibt, dass beide Sprachen ausgeliefert werden, dass die Slugs zu dem passen, was der Katalog verspricht, und dass keine Route ins Leere zeigt.

Das ist der Teil, den man von außen nie sieht und ohne den ich das Ganze nie live geschaltet hätte. Bei 209 Seiten kann ich nicht mehr durchklicken; ich muss dem Testlauf glauben können. Und weil eine grüne Testsuite auf meinem Rechner noch keine Aussage über die echte Seite ist, wurden die neuen Routen anschließend in die Marketing-E2E-Suite aufgenommen. Dort werden sie gegen die tatsächlich deployte Website gefahren — nicht „kompiliert die Komponente", sondern „lädt die URL, die ein Besucher aufruft, und steht darauf, was daraufstehen soll". Erst diese zweite Ebene macht aus einem Katalog-Trick eine Sache, der ich im Produktivbetrieb vertraue.

Was kommt als Nächstes?

Zum Abschluss der Serie: das Multi-Plattform-Finish — schnelle iOS- und Mac-Builds, ein Release und ein Blick auf den Stand heute. Nach Wochen, in denen die Arbeit im Web und im Katalog stattfand, geht es noch einmal zurück auf die Geräte, auf denen das Produkt am Ende laufen soll.