zurück
Startseite / Transport Monitoring System
ProductDashboardResearchDesign System

Transport Monitoring System — wie ein „kleines“ Feature die Vorfallsbearbeitung um 34% beschleunigte

Ein Jahr Arbeit am Interface eines Transport-Monitoring-Systems auf Basis von KI-Kameras: ein Research-getriebener Ansatz für Icons, ein Designsystem — und ein Feature, das Operatoren 8 Stunden im Monat sparte.

Jahr2023
KundeNDA
RolleArt Director
TeamAnthracite Studio
Transport Monitoring System — Cover der Case Study

Diese Case Study handelt von einem Transport-Monitoring-System: einem Netz aus KI-Kameras, das von Operatoren gesteuert wird. Das System hilft, Vorfälle auf den Straßen zu verhindern, Folgen zu minimieren und Fälle für die Analyse zu katalogisieren — für eine sicherere Stadt.

Das Anthracite-Team und ich arbeiteten ein Jahr mit dem Kunden am Interface. Nach dem MVP-Release wuchs die Datenbank, das KI-Modell wurde klüger — und wir ergänzten laufend neue Funktionen. Hier zwei Geschichten aus diesem Jahr: wie wir Icons durch Research gestalteten und wie ein „kleines“ Feature unerwartet ein großes Ergebnis brachte.

Interface des Transport-Monitoring-Systems

Teil 1. Kamera-Icons: Zahlt sich Research aus?

Kamera-Icons sind der zentrale Weg, Operatoren über erkannte Vorfälle auf Straßen zu informieren. Es gibt viele Kameratypen, jeder spezialisiert: einer analysiert Gesichter im Material, ein anderer erfasst Verkehrsverstöße. Um Vorfälle schnell zu melden und Einsatzkräfte zu rufen, muss ein Operator Typ, Kategorie, Funktion und Status der Kamera auf der Karte sofort erfassen.

Die Aufgabe: ein Icon-Set gestalten, das Operatoren auf einen Blick erkennen. Herausforderungen gab es genug: 15+ Kameratypen, Hauptkategorien, KI-Modul, Größen- und Ausrichtungsvarianten, Status und Prioritäten. Außerdem brauchten wir einen einfachen Prozess, um neue Kameras auf bestehende Screens zu bringen und Updates zu verwalten.

Wir begannen mit Research: Ein guter Teil der Zeit floss in die Frage, wie Kameras im echten Leben aussehen. Das lieferte die Grundelemente für die Darstellung jedes Typs.

Kameravarianten
Ein Beispiel der Kameravarianten, mit denen wir arbeiteten. Einige Typen dürfen wir wegen NDA nicht zeigen

Auch wenn das System auf KI-Kameras läuft, steuern es Menschen. Also machten wir mehrere Iterationen von Usability-Tests mit Operatoren und verfeinerten das Design für die, die sich täglich darauf verlassen.

Iterationen der Icon-Usability-Tests

Als Schwelle setzten wir >80% Wiedererkennung: 100% zu jagen ergab keinen Sinn — real arbeiten Operatoren mit mehreren Kameras gleichzeitig, statt sie einzeln zu identifizieren. Mit diesem Benchmark finalisierten wir die neuen Icons.

Die Icons wurden Teil des Designsystems: ein gut organisiertes Komponenten-Set, das den Bau neuer Screens beschleunigte.

Komponenten-Set der Kamera-Icons im Designsystem

Parallel dokumentierten wir Designprinzipien, Guidelines und Regeln für Designteam und Entwickler — damit Design und Umsetzung konsistent bleiben.

Icon-Prinzipien und Nutzungs-Guidelines

Und um die Umsetzung zu vereinfachen, bauten wir Prototypen, die genau zeigten, wie neue Kamerafunktionen im Produkt funktionieren sollen:

Zusätzliche Zeit für Research und die Integration der Icons ins Designsystem mag wie eine überflüssige Investition wirken — doch der langfristige Gewinn ist unbestreitbar: mehr Sicherheit in Entscheidungen und spürbar schnellere Updates, Anpassungen und neue Layouts.

Teil 2. Ein „kleines“ Feature, das große 34% wert ist

Stellen Sie sich einen Unfall vor, den zehn Kameras aus verschiedenen Winkeln erfassen. Bis vor Kurzem führten Operatoren diese Streams manuell zu einem Vorfallsbericht zusammen. Ohne das verstopft das System mit unklassifizierten Vorfällen, die Effizienz leidet. Selbst als die KI lernte, zusammengehörige Vorfälle zu finden und zu bündeln, blieb die Validierung beim Operator.

Die Aufgabe: die Zeit fürs Zusammenführen senken und Fehler minimieren. Die Hauptherausforderung: Das Feature musste sich nahtlos in den Workflow fügen — das System läuft 24/7, und die bestehende Effizienz der Stadtüberwachung durften wir nicht gefährden.

Discovery

Wir beobachteten Operatoren durch ihren Arbeitstag und führten Tiefeninterviews — so sahen wir das Problem aus mehreren Blickwinkeln. Kernbefunde aus der Beobachtung:

  • Operatoren brechen Aufgaben mittendrin ab, wenn etwas Dringendes reinkommt;
  • den richtigen Vorfall zu finden dauert viel zu lange;
  • Fehler beim Zusammenführen stauen den Backlog.

Und aus den Interviews:

  • unerledigte Aufgaben erzeugen Anspannung;
  • die Jagd nach KPIs führt mitunter zu Fehlern und Frust;
  • vollständige Vorfallsdokumentation frisst viel Zeit;
  • manches zugehörige Material wird schlicht übersehen.

Es wurde klar: Operatoren sind ohnehin mit Ereignissen auf dem Bildschirm überlastet — besonders zur Rushhour, wenn die Vorfälle Spitzenwerte erreichen. Mehr kognitive Last hätte alles verschlimmert. Also stützten wir unsere Nullhypothese auf die Theorie mentaler Modelle: Vertraute Muster aus Massen-Apps prägen Erwartungen und Verhalten in ähnlichen Interfaces.

Nullhypothese: Vertraute Interaktionsmuster aus weitverbreiteten Apps helfen Operatoren, das neue Feature nahtlos in ihren Workflow zu integrieren.

Operatoren sind normale Menschen mit normalen Apps auf dem Handy. Eine schnelle Umfrage zeigte, welche — und das lenkte die Hypothesen für unsere Prototypen.

Prototypen

Hypothese 1 — Farbpunkt, Badge oder Benachrichtigung
Hypothese 1: Ein Farbpunkt, Badge oder eine Benachrichtigung lenkt die Aufmerksamkeit auf das neue Feature
Hypothese 2 — ein Stapel von Kameraaufnahmen
Hypothese 2: Ein „Stapel“ von Kameraaufnahmen — wie in Gruppenanrufen oder Chats — signalisiert mehrere zusammengeführte Aufnahmen

Als Alternative prüften wir auch ein manuelles Szenario — falls Operatoren den Prozess lieber selbst steuern:

Hypothese 3 — Hervorheben zusammengehöriger Zeilen
Hypothese 3: Hervorgehobene Zeilen deuten eine Verbindung an und laden ein, sie zu einem Vorfall zusammenzuführen

Dann berieten wir uns mit den Entwicklern und gewichteten jede Hypothese nach Umsetzungskosten — nur was Wirkung ohne überzogenen Aufwand versprach, ging ins Prototyping.

Tests

Wir führten moderierte Usability-Tests an den Prototypen durch und maßen die Wirksamkeit mit mehreren Metriken: Task Success Rate, Task Time und Learnability — Erfolgsquote über die Zeit.

Metriken der Usability-Tests

Learnability war für den Kunden entscheidend: Operatoren mussten sich so schnell wie möglich an das Feature gewöhnen, der Umstieg auf den neuen Workflow unbemerkt bleiben. Deshalb zählten die Learnability-Ergebnisse doppelt. Und obwohl Prototyp V1 die bessere Durchschnittszeit zeigte, gewann V3 bei der Learnability — und wurde die finale Lösung.

Testergebnisse der Prototypen V1–V3

Das Ergebnis

Die Tests bestätigten die zentrale Hypothese: Vertraute Muster schlugen die „manuellen“ Alternativen — obwohl die näher am bestehenden Workflow lagen. In Produktion ging die Variante mit Benachrichtigung im Stil einer roten Bubble und Fotostapel: Sie signalisiert zusammengeführte Vorfälle klar und fängt die Aufmerksamkeit des Operators.

Nach dem Release stieg die Workflow-Effizienz der Operatoren um 34%. Besonders wertvoll war das Feature in Corner Cases, wo Operatoren früher 5–9 Minuten pro Aufgabe verloren. Die Beobachtung nach dem Release zeigte zudem: Zusatzarbeit — etwa das Bereinigen versehentlicher Auslassungen — sank um rund 2 Stunden pro Woche. Das sind 8 gesparte Stunden im Monat pro Operator und spürbar mehr Zufriedenheit im Job.

Fazit

Zwei Episoden — ein Ansatz: Research vor Design. Icons, gebaut auf echten Kameras und Operatoren-Tests, gaben dem System eine visuelle Sprache, die man sofort liest. Und ein „kleines“ Feature, gegründet auf mentalen Modellen und mit Metriken validiert, brachte 34% schnellere Vorfallsbearbeitung.

Art Director: Sydorov Alex · Design und Text: Lisa Furina · Anthracite Studio

Eine ähnliche Aufgabe?

Ich helfe beim Design komplexer Produkte und Dashboards — vom Research bis zum finalen UI.