Janus – B2B SaaS Design für Logistik & Freight
Service
UI/UX Design, Prototyping, Research, Testing
Year
2026
Website
www.janus.solutions
Kunde
Janus GmbH
Tools
Figma, FigJam
Herausforderung (why)
Janus Technologies baut ein internes Rate Management System für Spediteure. Das System verarbeitet Frachtraten, die täglich von Carriern und Service Providern als Tabellen und Dateien angeliefert werden — oft unstrukturiert, fehleranfällig, und in einem Format, das niemand wirklich kontrolliert hat. Meine Aufgabe war es, die UX für diesen Ingestion-Prozess zu gestalten: also den Moment, in dem ein Ops-Nutzer eine neue Raten-Datei hochlädt, prüft, bereinigt, und freigibt.
Das klingt technisch, ist es auch — aber genau darin lag die designerische Herausforderung. Die Nutzer sind keine Entwickler. Es sind Freight Ops Profis, die täglich unter Zeitdruck arbeiten und sich nicht durch kryptische Fehlermeldungen oder leere Tabellen durchkämpfen wollen. Das System musste ihnen in Sekunden sagen: Hier stimmt etwas nicht. Das musst du prüfen. Das kannst du jetzt freigeben.
Dazu kam eine zweite Ebene: die Customer-Facing Screens, also die Raten-Übersicht, die Detailseite und der Rate Explorer. Diese richten sich an Kunden des Spediteurs, die schnell nach Raten suchen und vergleichen wollen. Hier war die Anforderung eine ganz andere — weniger Kontrolle, mehr Lesbarkeit und Geschwindigkeit.
Prozess (how)
Ich habe über mehrere Monate eng mit dem Produktteam zusammengearbeitet — hauptsächlich mit Philipp als Product Owner, Kieron als Lead Developer, sowie Ravi und Neale als primären Ops-Nutzern auf der Testseite.
Den Großteil der Zeit habe ich in Figma verbracht, aber der Prozess war alles andere als linear. Ein wiederkehrendes Muster war: Ich entwerfe eine Bildschirmversion, Philipp kommentiert mit konkreten Fragen, Kieron baut etwas Eigenes, Ravi testet und liefert Feedback zurück. Manchmal hat Kieron’s technische Implementierung Design-Fragen beantwortet, die ich noch nicht gestellt hatte — und manchmal war es umgekehrt.
Ein konkretes Beispiel dafür ist die Review Page. Ich hatte mehrere Versionen entworfen — mit einer klaren linken Spalte für Kontext, einer zentralen Tabelle für die Rate Sets und einer rechten Spalte für Amendments. Parallel dazu baute Kieron eine Excel-artige Alternative mit direkter Zellbearbeitung. Als Ravi und Neale bei User Tests Kieron’s Version bevorzugten, habe ich meine eigene Arbeit zurückgezogen und die Energie in andere Bereiche gelenkt. Das war eine wichtige Entscheidung: schnell zu reagieren bevor Workarounds entstehen, die sich im Team einbrennen.
Inhaltlich habe ich für dieses System sehr tief in Fachdomäne eintauchen müssen. Rate Sets bestehen aus SP, Carrier, Lane, Routing und Scope — und jede Kombination dieser Elemente hat eigene Regeln. Via-Knoten bedeuten etwas anderes als T/S-Knoten, CY/CY hat andere Implikationen als Door/CY, und Surcharge-States wie “Subject to” oder “Conditional” sind keine Labels, sondern rechtlich relevante Zustände. Um gute UX zu designen, musste ich diese Unterschiede verstehen und in der Sprache des Systems denken.
Lösung (what)
Das Ergebnis ist ein kohärentes Design-System für vier zentrale Screens: Speed-Read, Rate Detail, Review Page und Rate Explorer.
Die Review Page — also der Kern des Ingestion-Prozesses — ist um eine klare Navigationsstruktur herum aufgebaut. Die linke Spalte ist das Steuerungszentrum: Sie zeigt eine KI-generierte Zusammenfassung der gelesenen Datei, eine Reconciliation-Sektion mit klickbaren Zählern (wie viele Zeilen wurden gelesen, wie viele wurden zu Rate Sets expandiert, wie viele gingen verloren), und vier Status-Counter für Rate Sets, Clean, Issues und Highlights. Diese Zähler sind nicht dekorativ — sie steuern direkt, was in der zentralen Tabelle angezeigt wird.
Die Tabelle selbst hat eine zweistufige Filter-Bar, die nach Klick auf einen Reconciliation-Label automatisch den richtigen Filter aktiviert. Für jede ausgewählte Gruppe kann direkt ein Amendment geöffnet werden — ein seitlicher Drawer mit vier Schritten: Scope, Änderung, Begründung, Vorschau. Die Begründung ist Pflicht, bevor ein Amendment gespeichert wird. Das ist nicht nur formale Anforderung, sondern Absicht: jede Änderung soll nachvollziehbar sein.
Für die Customer-Facing Screens habe ich einen Clean-Row-Ansatz entwickelt, inspiriert von Aviation SaaS UIs. Jede Rate-Zeile zeigt Route, Service Conditions, Raten pro Equipment-Typ, Carrier-Logo, SP & Commercials, Gültigkeit und Status in sieben Spalten — ohne Card-Rahmen, ohne überflüssige Hierarchie. Die Route-Visualisierung in der aufgeklappten Zeile folgt einer Linie mit farbigen Knoten: gefüllte Kreise für Ports, hohle Kreise für Via-Stops, Rauten für T/S-Umschlagspunkte. Pfeile zwischen Knoten wurden bewusst entfernt — die Linie selbst zeigt die Verbindung.Erkenntnisse
Die wichtigste Erkenntnis war, wie viel Designarbeit in der Domäne steckt, nicht im Interface. Ich konnte keine gute UX für ein Rate-Set bauen, bevor ich verstanden hatte, warum ein Rate-Set aus genau diesen Feldern besteht — und welche davon editierbar sind, bevor die Apply-Logik feuert, und welche danach nur noch über Amendments verändert werden können. Dieses Wissen kommt nicht aus einem Briefing-Dokument. Es kommt aus Gesprächen, aus Kommentaren in Figma, aus Fragen die ich gestellt habe und manchmal erst Tage später beantwortet bekommen habe.
Die zweite Erkenntnis: Ops-Nutzer und Customer-Users brauchen fundamental unterschiedliche Screens — nicht nur visuell, sondern in ihrer gesamten Informationslogik. Für Ops ist Vollständigkeit entscheidend: Jede Anomalie muss sichtbar, jeder Schritt nachvollziehbar sein. Für Kunden ist das Gegenteil richtig: so wenig wie möglich, so klar wie nötig.
Und drittens: Manchmal ist das beste Design-Ergebnis, das eigene Design nicht zu liefern. Als Kieron’s technische Lösung bei den Nutzern besser ankam als mein Entwurf, habe ich das akzeptiert und die Energie in Bereiche gelenkt, wo mein Beitrag tatsächlich gebraucht wurde. Das ist keine Niederlage — das ist wie gutes Produktdesign funktioniert.