Bestand und offene Vorgänge
Portfolio, Guthaben und laufende Aufträge gehören in einen verständlichen Zusammenhang. „My Squad“ führt diese Informationen in einer Übersicht zusammen.
01 Produktstruktur
Die Funktionen nach
Nutzeraufgaben ordnen.
TRADAR musste sportliche Informationen und finanzielle Vorgänge zusammenbringen. Ein Spieler konnte gleichzeitig Teil des eigenen Portfolios, Gegenstand eines Kaufangebots und Teilnehmer eines laufenden Spiels sein.
Wir prüften deshalb die Zusammenhänge zwischen den Bereichen und arbeiteten an Navigation und Nutzerwegen. Die Projektunterlagen verbinden diese Strukturarbeit mit konkreten Fragen: Wo finde ich meinen Bestand? Wie komme ich zum passenden Spieler? Und was passiert mit einer noch offenen Order?
Produktregeln und Nutzerwege gemeinsam klären
Die Anforderungslandkarte enthält grundlegende Fragen: Welche Faktoren beeinflussen den Wert eines Spielers? Wie oft wird dieser aktualisiert? Wann ist Kaufen oder Verkaufen möglich? Diese offenen Punkte zeigen, dass sich die UX-Arbeit bis in die Klärung des Produktmodells erstreckte.
Für die Oberfläche bedeutete das: Ein Spielerprofil musste je nach Situation andere Informationen und Aktionen anbieten. Sportliche Informationen, eigener Bestand und ein verfügbares Angebot mussten zusammenpassen. Die Strukturarbeit und die Ausarbeitung dieser Zustände waren deshalb eng miteinander verbunden.
Spieler und Handelsmöglichkeiten
Die Spieleransicht verbindet sportlichen Kontext mit dem jeweiligen Angebotsstatus. Die Entwürfe berücksichtigen unter anderem laufende Angebote, ausverkaufte Token und fehlende Angebote.
02 Registrierung & Identität
Auch die Unterbrechungen
im Einstieg gestalten.
Zum Einstieg gehörten mehrere Schritte: ein Konto anlegen, persönliche Daten erfassen und die Identität über einen externen Dienst bestätigen. Die Übergänge mussten ebenso ausgearbeitet werden wie die einzelnen Formulare.
Bei der Videoidentifikation zeigt sich das besonders deutlich. Wir gestalteten die Vorbereitung, die benötigten Berechtigungen und den Umgang mit einem fehlgeschlagenen Start. Nutzer sollten jeweils erkennen können, was sie als Nächstes tun können.
Notwendige Schritte von zusätzlicher Reibung trennen
In der Analyse hinterfragte ich ausdrücklich, warum schon in der Registrierung gefragt wurde, wie jemand auf TRADAR aufmerksam geworden war. Auch die Verständlichkeit der Passwortanforderungen und eine Einführung in die wichtigsten Funktionen waren Gegenstand meiner Anmerkungen. Wir berieten damit bereits darüber, welche Informationen an welchem Punkt überhaupt gebraucht wurden.
Die Anforderungslandkarte unterschied Kontoerstellung, persönliche Daten und externe Identitätsprüfung. Bei nachgelagerten Prüfschritten fragte ich konkret nach, welche Informationen Nutzer sehen sollten und ob sie zunächst nur warten konnten. Die ausgearbeiteten Screens zeigen, wie wir solche Übergänge auf der TRADAR-Seite verständlich machten: Voraussetzungen erklären, fehlende Berechtigungen benennen und nach einem Startfehler einen erneuten Versuch anbieten.
01 · VorbereitenVoraussetzungen erklären
Vor dem Videoanruf wird sichtbar, welche Dokumente und technischen Voraussetzungen benötigt werden.
02 · BerechtigungenDen nächsten Schritt anbieten
Fehlen Kamera- oder Mikrofonzugriff, führt der Entwurf zu den Einstellungen und erklärt den Zweck der Freigabe.
03 · FehlerfallEinen erneuten Versuch ermöglichen
Kann die Identifikation nicht starten, zeigt die Oberfläche den Fehler und bietet einen Wiederholungsversuch an.
TRADAR-Oberflächen rund um die externe IDnow-Identifikation. Die eigentliche Oberfläche des Identifikationsdienstes ist hier nicht abgebildet.
03 Spieler & Transaktionen
Vom Spielerangebot
zur nachvollziehbaren Kaufvorschau.
Im Kaufablauf mussten Token-Anzahl, Euro-Betrag, Gebühren und Zahlungsmittel eindeutig zusammenpassen.
In der Teamanalyse war ein konkreter Widerspruch markiert: Die Oberfläche zeigte Euro-Beträge, erwartete bei der Eingabe aber eine Anzahl von Spieler-Token. Damit war schon vor dem Abschluss unklar, worauf sich die Eingabe bezog.
Die ausgearbeitete Kaufvorschau trennt diese Größen sichtbar: Token-Anzahl, Preis pro Token, Gebühr und Gesamtbetrag erhalten eigene Zeilen. Das Zahlungsmittel lässt sich vor dem Abschluss prüfen und ändern. Dokumente und Risikohinweis gehören ebenfalls zu dieser Ansicht.
Wir arbeiteten die Schritte vom Angebot über die Eingabe und Kaufvorschau bis zur Bestätigung aus. Dazu gehörten auch Grenzen und Fehlerfälle sowie die Verwaltung noch offener Aufträge. Der Zusammenhang zwischen verständlicher Eingabe und überprüfbarer Kaufentscheidung wird damit an einem konkreten Ablauf sichtbar.
Das Angebot im Kontext zeigen
Die Spieleransicht verbindet das laufende Angebot mit Preis, Verfügbarkeit und eigenem Bestand. Matches und Biografie ergänzen den sportlichen Kontext.
Oberer Ausschnitt einer langen Spieleransicht.
Die Entscheidung vor dem Kauf prüfen
Die Vorschau führt Menge, Einzelpreis, Gebühren und Gesamtbetrag zusammen. Zahlungsmittel, Dokumente und Risikohinweis sind vor dem Abschluss zugänglich.
Originalentwurf mit beispielhaften Preisen und Gebühren.
04 Designsystem & Zusammenarbeit
Wiederkehrende Muster
für die weitere Ausarbeitung.
Viele Informationen tauchen an mehreren Stellen auf: Spieler, Token-Menge, Wert, Orderstatus und Aktionen. Wir arbeiteten dafür wiederkehrende Komponenten und Darstellungsmuster aus.
Die Komponentenübersicht unterscheidet beispielsweise offene, am Markt befindliche und noch in Verarbeitung befindliche Orders. Eine Live-Karte verbindet den Spieler mit Spielstatus und Rewards; Angebotsmuster stellen Preis, Menge und Summe gegenüber. Die wiederkehrenden Bausteine mussten also auch die unterschiedlichen Bedeutungen und Zustände abbilden.
Die Gestaltung wurde eng mit Produktmanagement und Entwicklung abgestimmt. Als Principal verantwortete ich das Projekt bei userdoo und begleitete die UX- und Produktentscheidungen. Der Design Lead lag bei einem Designer aus meinem Team; die Ausarbeitung erfolgte gemeinsam.
Den Gestaltungsumfang für das MVP eingrenzen
Im Projektboard sind drei konkrete Festlegungen dokumentiert: zuerst Darkmode, Lightmode erst nach dem MVP und die Systemschrift als typografische Grundlage. Damit war festgehalten, welche Gestaltungsvarianten zunächst ausgearbeitet werden sollten und welche später folgen konnten.
Parallel sah die Planung Komponenten, Interaktionsmuster und kompakte Spezifikationen vor. Diese gemeinsame Grundlage half, die wachsende Zahl an Abläufen als zusammenhängendes Produkt auszuarbeiten und mit der Entwicklung zu besprechen.
Die Lieferung umfasste zusammenhängende Abläufe, ausgearbeitete Screens, Komponenten und Spezifikationen. So konnte die Abstimmung mit der Entwicklung an konkreten Zuständen und Übergängen stattfinden.
Der Gesamtumfang reichte über die hier gezeigten Beispiele hinaus: unter anderem Kontoverwaltung, Sicherheit, Benachrichtigungen, Transaktionshistorie, Rewards und Store.
Verantwortung im Projekt
Mein Beitrag
Principal, Projektverantwortung, UX-Beratung und Abstimmung mit Produktmanagement und Entwicklung
Tommy Haacke und Team
Gemeinsame Ausarbeitung der Abläufe, Oberflächen, Komponenten und Zustände
Produktmanagement & Entwicklung
Enge fachliche und technische Abstimmung
Ergebnis
Produktfragen klären und die Umsetzung konkretisieren.
Produktmanagement und Entwicklung erhielten abgestimmte Nutzerwege, Screens und Spezifikationen. Offene Fragen zu Kauf, Identifikation und Orderstatus wurden damit bis in die Bedienung konkretisiert. Das Designsystem hielt wiederkehrende Komponenten und Zustände für den weiteren Ausbau bereit.
Gemeinsam entwickelte Nutzerwege
Zentrale Abläufe von der Registrierung über das Portfolio bis zu Kauf und Orderverwaltung.
Screens & Zustände
Oberflächen für reguläre Abläufe, fehlende Voraussetzungen und erneute Versuche.
Komponenten & Spezifikationen
Wiederkehrende Muster für die Ausarbeitung und die Abstimmung mit der Entwicklung.
