Konzeptstudie
UX
Protopie

So entsteht ein Traktor-Terminal-Prototyp

Unser Ausgangspunkt

Kein Briefing, keine technischen Vorgaben, sondern nur die Frage: Wie müsste ein Terminal aussehen, das wirklich für Fahrer gemacht ist? Wir haben mit Research angefangen, nicht mit Design.

Unsere Ansatz

Research, Konzept, Figma, ProtoPie und perspektivisch eine CAN-Bus-Anbindung die den Prototypen mit echten Maschinendaten füttert. Von der ersten Skizze bis zum klickbaren Interface.

Das Problem

Was uns der Markt gezeigt hat

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.

Erst Verstehen, dann gestalten

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.

  • Strukturierte Interviews mit Fahrern und Betriebsleiter
  • Competitor Analysis bestehender Terminaloberflächen
  • Pain Points gesammelt und nach Häufigkeit priorisiert

Von der Idee zum Konzept

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.

  • Nutzer-Workflows durchgespielt und hinterfragt
  • Erste Wireframes intern iteriert
  • Designentscheidungen konsequent am Nutzungskontext ausgerichtet

Ein Prototyp, der sich echt anfühlt

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.

  • Interaktionen und Übergänge in ProtoPie umgesetzt
  • Interface in Figma ausgearbeitet und komponentisiert

Das Problem

Was am Ende steht

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.

Was ein durchdachter Prozess bewirkt

Der Unterschied zeigt sich nicht im ersten Mockup, sondern wenn das Produkt auf echte Nutzer trifft.

Ohne strukturierten UX-Prozess

Fragmentiert

Anforderungen kommen aus verschiedenen Richtungen, niemand hat vorher mit den echten Nutzern gesprochen. Das Interface spiegelt die interne Projektstruktur wider, nicht den Arbeitsalltag des Fahrers.

Teuer in der Korrektur

Probleme die in der Research-Phase 10 Minuten gekostet hätten, werden in der Entwicklung zu wochenlangen Schleifen. Je später Feedback kommt, desto teurer wird es.

Schwer vermittelbar

Ohne Prototyp redet jeder über etwas anderes. Missverständnisse zwischen Auftraggeber, Entwicklung und Design kosten Zeit und Nerven.

Unsere Vision

Fundiert

Jede Designentscheidung lässt sich auf echte Nutzerbedürfnisse zurückführen. Das macht Reviews schneller und Diskussionen sachlicher.

Früh testbar

Ein klickbarer Prototyp schafft Klarheit bevor eine Zeile Code geschrieben wird. Feedback kommt zum richtigen Zeitpunkt.

Direkt übergabefähig

Komponenten, Logik und Interaktionen sind dokumentiert und entwicklungsbereit. Was wir liefern, kann man direkt weiterverarbeiten. Oder wir entwickeln es gleich selbst :)