Das Problem
Bevor wir auch nur eine Linie gezeichnet haben, haben wir uns eine einfache Frage gestellt: Warum fühlen sich Traktor-Terminals im Jahr 2026 noch so an wie vor 15 Jahren?
Wir haben uns bestehende Systeme systematisch angeschaut, wie sie aufgebaut sind, wie Fahrer damit umgehen und wo sie scheitern. Schnell wurde klar: Das Problem liegt nicht an fehlender Technologie. Die Bedürfnisse der Menschen in der Kabine standen einfach nie wirklich im Mittelpunkt.
Wir haben Wettbewerber analysiert, Fahrer und Betriebsleiter interviewt und Pain Points gesammelt. Strukturiert, nicht aus dem Bauch heraus.
In den Gesprächen haben wir gemerkt, dass die Frustrationspunkte überall gleich sind: zu viele Menüebenen, keine Kontextsensitivität, Interfaces die für Techniker gebaut wurden und nicht für Menschen, die 10 Stunden am Tag auf dem Schlepper sitzen.
Die Competitor Analysis hat das bestätigt. Marktübliche Terminals lösen technische Anforderungen, aber kaum echte Nutzungsprobleme. Genau da haben wir angesetzt.


Der erste Schritt war kein Figma-File, es war Papier. Wir haben Informationsarchitekturen skizziert, Workflows durchgespielt und gefragt: Was muss ein Fahrer wirklich sehen, und wann?
Daraus entstanden erste Wireframes, die wir intern diskutiert und iteriert haben. Viele frühe Ideen haben wir verworfen, nicht weil sie schlecht aussahen, sondern weil sie in der Kabine schlicht nicht funktioniert hätten.
Das Ziel war kein Klick-Dummy. Wir wollten einen Prototypen, der echtes Fahrzeugverhalten simuliert: Maschinenstatus, Sensordaten, Auftragswechsel in Echtzeit.
Dafür haben wir das Interface in Figma ausgearbeitet und mit ProtoPie zum Leben erweckt. Über ProtoPie Connect und eine Python-Middleware haben wir eine CAN-Bus-Simulation angebunden, die echte ISOBUS-Datenpunkte in den Prototypen einspeist. Das Ergebnis ist ein Interface, das man nicht nur anschaut, sondern tatsächlich bedienen kann.

Das Problem
Ein voll interaktiver Prototyp, der zeigt wie ein Traktor-Terminal aussehen kann, wenn man beim Nutzer anfängt. Keine theoretische Studie, sondern ein funktionierendes Interface das man in die Hand nehmen, durchklicken und erleben kann.
Und ein Prozess, den wir genauso für echte Produkte einsetzen.
Der Unterschied zeigt sich nicht im ersten Mockup, sondern wenn das Produkt auf echte Nutzer trifft.