Von verstreuten Screens zu einer kohärenten Logistik-App.

Wie navigiert und verhandelt man in Kuyuy?

Kuyuy verbindet Transporteure mit Ladungserzeugern für nationale und internationale Sendungen. Die Migration zu einer nativen App versprach Skalierbarkeit, Zeitersparnis und Support — alles an einem Ort.

Doch die Realität war chaotischer. Das Produkt hatte viele High-Fidelity-Wireframes, aber keine globale Architektur, keinen interaktiven Prototyp und inkonsistente Terminologie über drei Nutzerprofile hinweg (Transporteur, Ladungserzeuger und SuperAdmin — jedes mit Admin- und Mitarbeiter-Varianten). Was intern Sinn ergab, ergab für die eigentlichen Nutzer keinen Sinn.

Design-Lead in einem crossfunktionalen Squad.

Ich habe das Design end-to-end verantwortet: Informationsarchitektur, User Flows, High-Fidelity-Prototypen, Edge-Case-Mapping und die Komponenten-Library, der Engineering während des Builds folgte. Ich habe eng mit dem PM beim Scoping und mit dem Kunden gearbeitet, um Entscheidungen in jeder Phase zu validieren.

Mein Fokus lag darauf, ein fragmentiertes Web-Produkt in eine native App zu verwandeln, die für drei Nutzerprofile funktioniert — ohne drei verschiedene Interfaces bauen zu müssen.

Wie jede Entscheidung in der Praxis aussah.

Eine Architektur, drei Profile

Statt drei parallele Apps zu bauen, habe ich eine einzige Informationsarchitektur entworfen, bei der geteilte Entitäten (Sendungen, Verträge, Nachrichten) für alle gleich aussahen — aber rollenspezifische Aktionen dort zeigten, wo es zählte. Der SuperAdmin behielt die volle Kontrolle, Transporteure und Erzeuger sahen nur, was sie für ihre Aktionen brauchten.

Ein Label = ein Konzept

Das alte Produkt verwendete je nach eingeloggtem Profil unterschiedliche Terminologie. Ich habe mit dem PM zusammengearbeitet, um diese in ein einziges Vokabular zu überführen. Beispiel: „Mit Angeboten" bedeutet für jedes Profil dasselbe — Angebot + Annehmen/Ablehnen + Gegenangebot. Gleicher Begriff, gleiche Aktionen, gleiche Validierungen.

Der Happy Path reichte nicht

Ich habe kritische Edge Cases gemappt: abgelehnte Dokumente (fehlende Anforderungen anzeigen, erneut versuchen oder eskalieren), unvollständige Daten (validieren und Ticket erstellen), Vorfälle unterwegs (pausieren, neu zuweisen oder an Operations eskalieren) und gescheiterte Abschlüsse. Gutes UX deckt sowohl das Erwartete als auch das Unerwartete ab.

Schlüsselerkenntnisse, die ich mitnehme.

• Architektur zuerst vermeidet lose Screens und Endlosdiskussionen. Ohne eine Karte startet jedes Gespräch bei null.
• Ein Begriff = eine Aktion. Das Angleichen der Sprache über Profile hinweg beschleunigt alles — und verhindert Bugs, die durch fehlausgerichtete Erwartungen entstehen.
• Prototyp pro Flow ist besser, als auf „die komplette App" zu warten. Kleine Validierungen summieren sich schneller als große Releases.
• Den Kunden aktiv führen. Die visuelle Karte beseitigt Ambiguität und verkürzt Review-Zyklen.
• Was wir nicht validieren konnten: frühes Task-Testing mit echten Transporteuren und Erzeugern. Im Nachhinein hätte ein Fünf-Sekunden-Test auf die erste Aktion pro Profil Wochen gespart.