Das Engagement hatte eine feste Dauer von sechs Wochen von Forschungsbeginn bis zur Design-Übergabe. Die Arbeit wurde in koordinierten Strängen organisiert, sodass Forschungsergebnisse, Benchmarking und Interaktionsdesign sich ohne Verzögerung gegenseitig informieren konnten. Wochen eins und zwei waren der Remote-Forschung mit Technikern in Deutschland gewidmet, während die erste Erfassung von Interaktionsoptionen und embedded GUI-Einschränkungen parallel begann. Während Wochen zwei bis vier verfeinerte das Team das Interaktionsdesign für alle drei Gerätetypen und evaluierte frühe Konzepte gegen Hardware- und Werkstatteinschränkungen. Wochen vier und fünf konzentrierten sich auf High-Fidelity-Prototypen, die es uns ermöglichten, die Logik und das Timing des Interface zu testen. In Woche sechs finalisierten wir das visuelle Design und bereiteten das Design System und die Spezifikationen für das Engineering vor.

Benchmarking von Wettbewerbssystemen begann früh im Projekt, sodass wir die Arbeit innerhalb der breiteren Landschaft von Kalibriersoftware und technischer Software-UX für Automotive-Werkzeuge positionieren konnten. Parallel dazu bereiteten wir ein entwicklerorientiertes Design System vor, das Interaktionsregeln, Komponentenzustände und Verhalten über das OEM-Display, das robuste Tablet und das große Display hinweg erfasste. Die kurze Lieferzeit war möglich, weil Entscheidungen auf Erkenntnissen statt auf Präferenzen basierten. Forschung, Benchmarking und Interaktionsdesign entwickelten sich gemeinsam, und High-Fidelity-Prototypen wurden als gemeinsamer Bezugspunkt sowohl für Produkt-Stakeholder als auch für embedded Engineers verwendet.

User Research wurde remote mit Technikern in Deutschland durchgeführt, da Vor-Ort-Besuche während der Pandemie nicht machbar waren. Wir sprachen mit vierzehn Technikern über fünf Werkstätten, die autorisierte Prüfzentren und unabhängige Werkstätten umfassten. Die Forschung kombinierte kontextuelle Interviews und semi-strukturierte Interviews. Kontextuelle Interviews konzentrierten sich auf tatsächliche Nutzung und Verfahrens-Walkthroughs, während semi-strukturierte Interviews breitere Themen wie Schulung, Fehlerbehandlung und Zeitdruck erkundeten.

Techniker beschrieben Kalibrierschritte, als würden sie einen Anfänger anleiten, was die Momente offenlegte, in denen das alte Interface Zögern erzeugte. Die Hauptschmerzpunkte waren mit Geschwindigkeit, Klarheit und Schulungsaufwand verbunden. Techniker mussten oft Werte bestätigen, während sie um ein Fahrzeug herumliefen, doch das alte Interface bot keine klare Hierarchie, und wichtige Zustände hoben sich nicht von sekundären Informationen ab. Mehrere Komponenten kommunizierten ihre Funktion nicht visuell, was Werkstätten zwang, sich auf mündliche Erklärungen oder gedruckte Handbücher zu verlassen. Unter Zeitdruck trugen diese Einschränkungen zu wiederholten Messungen, unnötigen Pausen und vermeidbarer Unsicherheit bei. Diese Erkenntnisse wurden die empirische Basis für nachfolgende Interaktionsdesign-Entscheidungen.

Um eine robuste Interaktionsarchitektur zu etablieren, analysierten wir jedes Modul des Systems in Bezug auf das Verhalten der Techniker. Der Kalibrierworkflow ist keine einzelne Aktion. Er besteht aus mehreren Phasen von Messung, Ausrichtungsverifizierung und Bereitschaftsprüfungen, die je nach Verfahren leicht variieren. Wir untersuchten, wie Benutzer zwischen dem embedded OEM-Display und dem robusten Tablet wechseln, während sie sich um das Fahrzeug bewegen. Das kleine embedded GUI wird oft beim Stehen in der Nähe der Ausrüstung überprüft, während das Tablet verwendet wird, wenn Anpassungen an verschiedenen Positionen um das Auto herum vorgenommen werden. Das große Display in Prüfzentren muss eine kohärente Ansicht für Techniker und Prüfpersonal bieten, die nicht immer nah an der Hardware sind.

Eine Feature-Tabelle wurde erstellt, um das Verhalten des Systems strukturiert zu erfassen. Sie umfasste zwölf Schlüsselfunktionen, gruppiert in vier Hauptmodule. Für jede Funktion dokumentierten wir die in diesem Schritt benötigten Informationen, die Präzision der Werte, die erwartete Technikerbewegung, den Effekt der Beleuchtung und die akzeptable Zeit für einen Benutzer, das Display zu interpretieren. Diese Analyse wurde das Rückgrat für das Interaktionsdesign und für die gesamte Professional-Software-UX. Sie ermöglichte es, Engpässe zu lokalisieren, die Kalibriergeschwindigkeit und Technikersicherheit beeinflussten, und zu entscheiden, welche Informationen persistent bleiben mussten und welche sich kontextuell ändern konnten. Auf diese Weise unterstützte das Interaktionsdesign komplexe Workflows, ohne das kleine embedded Interface oder das Tablet zu überladen.

Wettbewerber-Interfaces wurden überprüft, um häufige Schwächen in dieser Kategorie von Kalibriersoftware und Enterprise-Software-UX für technische Werkzeuge zu verstehen. Wir untersuchten neun Kalibriersysteme verschiedener Hersteller. Viele dieser Interfaces präsentierten dicht gepackte Bildschirme mit zahlreichen Werten, die auf derselben visuellen Ebene angezeigt wurden. Farben wurden inkonsistent verwendet und mischten oft Statusanzeigen mit dekorativen Elementen. Einige Systeme stützten sich stark auf Icons, deren Bedeutungen ohne vorherige Schulung nicht ersichtlich waren.

Dieses Benchmarking bestätigte, dass die Gelegenheit nicht darin bestand, mehr visuelle Vielfalt einzuführen, sondern strukturelle Disziplin anzuwenden. Ein Kalibrierwerkzeug muss stabile Lesebereiche, klare Gruppierung verwandter Werte und eine visuelle Logik bieten, die die Präzision der zugrunde liegenden Hardware widerspiegelt. Die Benchmarking-Phase half uns, Einschränkungen für die neue Architektur zu definieren. Sie klärte, welche Ansätze kognitives Rauschen erhöhten und welche Muster auf rigorosere Weise für dieses spezielle embedded Interface und seine zugehörigen Geräte reinterpretiert werden konnten.

Das vorherige Interface war minimalistisch und war von Ingenieuren entworfen worden, um betriebliches Risiko zu reduzieren. Bestimmte Workflows funktionierten gut, weil Techniker sie im Laufe der Zeit gelernt hatten, und diese Sequenzen mussten durch constraint respecting bewahrt werden. Jedoch fehlte dem Interface eine klare visuelle Hierarchie. Messzustände, Toleranzen und Fortschrittsindikatoren wurden nicht nach ihrer Wichtigkeit betont. Text und Zahlen wurden mit ähnlicher Gewichtung präsentiert, was es Technikern erschwerte, während der Kalibrierung zwischen kritischen und unterstützenden Informationen zu unterscheiden.

Wir behandelten das alte GUI als Einschränkung statt als Hindernis. Die zugrunde liegenden Sequenzen, auf die Techniker sich unter Druck verließen, wurden bewahrt, während sich die Neugestaltung darauf konzentrierte, Struktur sichtbar und Beziehungen lesbar zu machen. Komponenten, die zuvor Erklärung erforderten, wurden umgestaltet, sodass ihre Rolle aus ihrer Position, Beschriftung und visuellen Behandlung abgeleitet werden konnte. Dieser Ansatz reduzierte die Übergangskosten für Techniker und vermied das Risiko, etablierte Verfahren zu brechen, die bereits unter realen Bedingungen funktionierten.

Die neue Interface-Architektur etabliert eine klare räumliche Hierarchie über alle Geräte hinweg. Kritische Werte besetzen stabile Zonen, die aus typischen Arbeitsabständen um das Fahrzeug herum lesbar bleiben. Verfahrenszustände werden mit konsistenter visueller Sprache auf dem embedded OEM-Display, dem robusten Tablet und dem großen Display ausgedrückt. Die Darstellung von Toleranzen, Warnungen und Bereitschaftsschritten folgt einer einzigen Logik, sodass Techniker ihr mentales Modell nicht anpassen müssen, wenn sie während einer Kalibriersequenz zwischen Geräten wechseln. Das embedded Interface und die größeren UIs bilden ein kohärentes System statt drei unabhängiger Bildschirme.

Interaktionsdesign-Entscheidungen basierten auf den Forschungserkenntnissen und den Einschränkungen der Hardware. Drei Prototyp-Varianten wurden durch option space mapping erstellt, um verschiedene Wege der Gruppierung von Werten und Zuständen auf dem OEM-Display zu erkunden, und High-Fidelity-Prototypen wurden dann unter Bedingungen getestet, die Werkstattbeleuchtung und Betrachtungsabstände reproduzierten. Das Design System beschreibt Komponentenzustände, Übergänge und Fehlerbedingungen detailliert, einschließlich Randsituationen, die in der embedded Entwicklung kritisch sind. Verhalten ist für alle drei Geräteklassen spezifiziert, sodass embedded Engineers das Interface ohne Mehrdeutigkeit implementieren können. Das Ergebnis ist ein technisches Interface Design und eine embedded GUI-Architektur, die schnelle Kalibrierworkflows heute unterstützt und zusätzliche Verfahren morgen aufnehmen kann, ohne bestehende Muster zu stören.