Case Study · Masterarbeit

RaceTrace – Dashboard Redesign
für ein 24h-Radrennen

Evaluation und Redesign eines Dashboards zur Visualisierung von (Quasi-)Echtzeitdaten im Rennsport. UCD nach DIN EN ISO 9241-210, getestet mit A/B-Tests, ISONORM 9241-110 und VisAWI-S.

Masterarbeit · TH Köln adesso SE · internes Projekt Event: „Rad am Ring“ Rollen: UX Research · UX/UI · Prototyping
Ziel Verbesserung der Gebrauchstauglichkeit des Dashboards und der Funktion „Neues Event erstellen“ unter Berücksichtigung unterschiedlicher Stakeholder (Administrator:innen, Fahrer:innen, Zuschauer:innen).
Ergebnis in Kürze Neues Event-Layout, vereinfachtes Team-Management, verbesserte Strecken-Konfiguration und getrennte Dashboards für Einzel- und Teamrennen. Ästhetik mit VisAWI-S positiv bestätigt (Gesamtwert ca. 5,8 / 7).

Projektkontext & Ergebnisse

Die Arbeit untersucht das bestehende RaceTrace-Dashboard für das 24-Stunden-Rennen „Rad am Ring“ und entwickelt auf Basis eines menschzentrierten Gestaltungsprozesses ein Redesign.

Projektart
Masterarbeit (M. Sc. Medieninformatik, HCI)
Unternehmen
adesso SE · internes Tool
Zeitraum
2023–2024
Nutzergruppen
Admin · Fahrer:in · Zuschauer:in
Alle 7 Dialogprinzipien ≥ +1 MW ISONORM 9241-110 – Aufgabenangemessenheit knapp positiv, Verbesserungsfokus auf Individualisierbarkeit & Lernförderlichkeit.
VisAWI-S Ø ≈ 5,8 / 7 Ästhetik deutlich über Benchmark-Schwellenwert 4,5 → kein Bedarf für grundsätzliche visuelle Änderungen.
Platzhalter-KPIs Beispiel: „−20 % Aufwand beim Anlegen neuer Events“ oder „+X % schnellere Konfiguration der Strecke“. (Werte später aus Messdaten ableitbar.)

Ausgangssituation & Problem

RaceTrace visualisiert Live-Daten zum Rennen (Karte, Rundenzeiten, Performance, Leaderboard, nächste Wechsel, Streckenhöhe). Admins konfigurieren Strecken, Teams und Profile, Fahrer:innen und Zuschauer:innen verfolgen den Rennverlauf.

Das bestehende Dashboard war funktional, zeigte aber:

  • hohe Komplexität bei der Funktion „Neues Event erstellen“,
  • umständliches Hinzufügen von Teammitgliedern,
  • eingeschränkte Unterstützung für Rennen, die nicht als Rundkurs stattfinden,
  • eine horizontale Navigation, in der Dashboard und Verwaltungsseiten ineinanderliefen.

Designlösung in Kürze

  • Neues, getestetes Layout für „Neues Event erstellen“.
  • Überarbeitete Teamverwaltung mit Pflichtfeldern und klaren Fehlermeldungen.
  • Markierung von Start- und Zielpunkt auf der Karte + flexible Wechselzonen.
  • Getrennte Dashboards für Teamrennen und Einzelrennen + vertikale Navigation.
  • Ergänztes Typografiesystem für konsistentes Hand-off.

Designprozess nach DIN EN ISO 9241-210

Die Case Study folgt den vier Schritten des menschzentrierten Gestaltungsprozesses. Jede Phase ist mit einer Kurzbeschreibung und einer einklappbaren Galerie dokumentiert.

1 Phase · Nutzungskontext
Stakeholderanalyse & Empathy-Map

In Phase 1 wurden die relevanten Stakeholder identifiziert und mit Empathy-Maps vertieft: Administrator:innen, Fahrer:innen und Zuschauer:innen.

Methode: Stakeholderanalyse, Empathy-Map, Kontextbeschreibung.
Stakeholder Empathy-Map Kontextanalyse
2 Phase · Anforderungen
Erfordernisse & Nutzungsanforderungen

Auf Basis des Nutzungskontexts wurden Erfordernisse formuliert und daraus konkrete Nutzungsanforderungen abgeleitet – u. a. für Eventanlage, Rollenmodell, Strecken-Konfiguration und Teamverwaltung.

Ergebnis: strukturierte Anforderungsliste als Grundlage für das Interaction Design.
Requirements Use Cases Dashboard-Funktionalität
3 Phase · Gestaltung
Scribbles, Wireframes & Prototyp

In Phase 3 wurden Scribbles für zentrale Dialoge erstellt, in Wireframes überführt und schließlich als High-Fidelity-Prototyp in Figma ausgearbeitet.

Fokus: Klarere Informationsarchitektur und visuelle Hierarchie für Admin-Tasks.
Scribbles Wireframes Figma-Prototyp
4 Phase · Evaluation
A/B-Tests, ISONORM & VisAWI-S

In Phase 4 wurden Layoutvarianten im A/B-Test verglichen und anschließend die Gebrauchstauglichkeit (ISONORM 9241-110) sowie Ästhetik (VisAWI-S) erhoben.

Ergebnis: Dialogprinzipien leicht verbessert, Ästhetik deutlich über Benchmark (VisAWI-S > 4,5).
A/B-Test ISONORM 9241-110 VisAWI-S
Redesign · Vergleich
Vorher/Nachher des RaceTrace Dashboards

Gegenüberstellung der wichtigsten Screens: Navigation, Informationsdichte und visuelle Hierarchie.

Alt vs. Neu: Admin-/User-Ansichten, Unterseiten und neue Dashboard-Layouts.
Vorher/Nachher Dashboard Team & Einzelrennen

Designsystem & Typografie

Die Farb-Sticker lesen ihre Werte zentral aus :root. So kann das RaceTrace-Branding an einer Stelle angepasst werden:

:root {
  --rt-primary: #0b3558; /* Dashboards, Navigation */
  --rt-accent:  #ffb347; /* Status, Countdown */
  --rt-bg-dark: #020617; /* Dark Cards, Charts */
}
        

Typografie

RaceTrace Headline H1
System Sans · ~32–40 px · 700
Section-Headlines (H2) liegen im Bereich 22–26 px, semibold. Fließtext bleibt neutral und gut lesbar (z. B. 16 px, 1.5 Zeilenhöhe). Komponenten orientieren sich an einem 4-px-Spacing-Raster, damit das Dashboard trotz Quasi-Echtzeitdaten ruhig bleibt.

Farben (Sticker)

Dunkles Blau für Datenflächen, warmes Akzent-Gelb für Status/Countdown, sehr dunkles Blau-Schwarz für Night-Mode-Karten.

Primary
Dashboards · Navigation
#0B3558
Accent
Status · CTA · Countdown
#FFB347
Dark BG
Hero-Karte · Charts
#020617
Neutrals
Karten, Linien, Textflächen
Portfolio-System

Learnings & nächste Schritte

  • A/B-Tests + ISONORM + VisAWI-S liefern zusammen ein rundes Bild aus Usability & Wahrnehmung.
  • Funktionale Aspekte wie Individualisierbarkeit und Lernförderlichkeit lassen sich gezielt verbessern, ohne „Look & Feel“ zu verlieren.
  • Als nächster Schritt: größere Stichprobe (extern), plus KPIs aus Logdaten / Zeit-&-Fehler-Messungen.

Numerische KPIs (z. B. -X % Bearbeitungszeit) lassen sich später aus Log-Daten oder Tests ableiten (z. B. Excel/Sheets, R, SPSS, JASP/Jamovi).

Nach oben Zurück zu allen Projekten