Gremminger
Designing System Logic in Early-Stage Operational Products
Das Produkt entstand im Startup-Kontext ohne bestehende UX-, UI- oder Systemstrukturen. Ich war von Beginn an konzeptionell eingebunden und verantwortete sowohl die fachliche Struktur als auch die visuelle Systemlogik. Ziel war eine hochfrequent genutzte B2B-Anwendung zur Verwaltung zeitlich begrenzter Ressourcen inklusive Preislogik, Rollenmodellen und operativer Zustände.
Abstraktion
Die hier dargestellte Sport-Club-Domäne dient als abstrahierte Visualisierung eines realen Infrastruktur- und Ressourcenmanagement-Systems.
Challenge & Problem
Die zentrale Herausforderung bestand nicht im Aufbau eines visuellen Design Systems, sondern in der Modellierung einer konsistenten operativen Logik.
Das Produkt musste:
- begrenzte Ressourcen eindeutig modellieren (abtrahiert: Sporthallen, Sportplätze)
- zeitliche Belegung regelbasiert abbilden
- Zustände dynamisch verwalten
- Preislogiken automatisiert berechnen
- Rollen und Zugriffsrechte systemweit durchsetzen
UI war dabei kein Ziel, sondern ein Ausdruck dieser Logik. Ohne klare Systemlogik wäre jede neue Funktion ein potenzieller Sonderfall geworden – mit steigenden Implementierungskosten, wachsender Komplexität und sinkender Geschwindigkeit.
Zentrale Entscheidungen
Systemlogik vor UI
Die Struktur der Daten, Zustände und Abhängigkeiten wurde vor visuellen Entscheidungen definiert. UI-Komponenten folgten der Logik – nicht umgekehrt.
- Ressourcen sind klar identifizierbare operative Einheiten: zeitlich begrenzt, zustandsgetrieben und systemübergreifend referenzierbar.
- Systemzustände fungieren dabei als zentrale Steuerinstanz. Ein Time-Slot ist nie „nur belegt“, sondern befindet sich in einem expliziten Zustand, der Sichtbarkeit, Interaktion, Berechtigung und Preislogik bestimmt.
- Rollen sind strukturelle Einschränkungen: Sie definieren, welche Zustände erlaubt sind und welche Aktionen existieren dürfen.
- Preise werden nicht vergeben, sondern berechnet. Sie entstehen aus Zeitsegmenten, Nutzungsart, Rolle und tenant-spezifischen Regeln.
Modulare Ressourcenmodelle und frühzeitige Skalierungslogik
Die operative Kernstruktur des Produkts wurde nicht um konkrete Ressourcentypen herum aufgebaut, sondern um ein abstrahiertes Ressourcenmodell. Eine Ressource wurde als operative Einheit aus Ort × Zeit definiert – ergänzt um klar definierte Systemzustände und regelbasierte Ableitungen. Preislogik, Rollenregeln und Nutzungstypen wurden nicht in einzelnen UI-Komponenten verankert, sondern als eigenständige Regel-Layer über dieses Modell gelegt.
Dadurch entstand keine featuregetriebene Struktur, sondern eine systemgetriebene Architektur.
Dieses Ressourcenverständnis hatte konkrete strukturelle Konsequenzen:
- Neue Ressourcentypen (abstrahiert z.B. Tennis, Squash, Beach-Volleyball) erfordern keine neue Logik, sondern nur Konfiguration
- Preisänderungen werden regelbasiert gesteuert, nicht visuell implementiert
- Rollen wirken als Constraint-Layer, nicht als Sonderfall-Code
- Zustände bleiben systemweit konsistent und modulübergreifend interpretierbar
Skalierbarkeit wurde nicht als nachgelagerte Optimierung behandelt, sondern als strukturelle Designentscheidung verankert. Erweiterungen entlang von Ressourcentyp, Preismodell oder Rollenstruktur erfolgen durch Regelanpassung – nicht durch Re-Design oder komponentenbasierte Ausnahmen.
Das Ergebnis ist ein operatives System, das Komplexität aufnehmen kann, ohne seine innere Logik zu fragmentieren.
Das Modell trennt operative Einheit, Zustandslogik und kommerzielle Regeln in klar definierte Systemlayer.
UI als Ausdruck der Systemlogik
Zustand-gesteuerte Betriebseinheiten
Jede visuelle Einheit fungiert als State Carrier und repräsentiert einen expliziten, systemisch definierten Zustand.
Preise als deterministische Reaktion
Der Preis entsteht aus regelbasierter Ableitung und wird als deterministische Systemreaktion berechnet.
Rollen & Buchungs-Klassifizierung
Rollen wirken als Constraint-Layer und bestimmen zulässige Zustände und Aktionen systemweit.
Resultierende Wirkung
Strukurelle Wirkung
Wachstum über Modell-Erweiterung statt Sonderstrukturen
Zustände bleiben systemweit interpretierbar
Rollen wirken als Constraint-Layer
Keine Fragmentierung der Kernlogik
Operativer Impact
Reduzierter Implementierungsaufwand bei neuen Modulen
Konsistente Geschäftslogik über Module hinweg
Einfache Integration tenant-spezifischer Anforderungen
Stabilere Weiterentwicklung bei wachsender Produktkomplexität
Frühe architektonische Entscheidungen bestimmten nicht nur die Oberfläche, sondern die Skalierfähigkeit des Produkts. Dadurch bleibt das System mit wachsender Komplexität stabil – ohne Re-Design, ohne Modellbruch.