Wir begannen mit einem fokussierten Usability-Audit für Embedded-Geräte. Die Überprüfung kombinierte heuristische Inspektion der Oberfläche mit Durchgängen realer AV-Diagnoseaufgaben, die von erfahrenen Technikern und Ingenieuren beschrieben wurden. Die Ergebnisse zeigten, dass frühere Designs Bildschirme nach Backend-Modulen organisiert hatten statt nach Techniker-Workflows. Funktionen saßen dort, wo sie im Code existierten, nicht wo sie in der Arbeitssequenz benötigt wurden.

Ein späteres Redesign hatte sich auf Farben und Icons konzentriert, aber die zugrunde liegende Struktur beibehalten. Infolgedessen mussten Techniker sich weiterhin merken, welcher Modus welche Diagnosen enthielt, und sie konnten den Kontext verlieren, wenn sie zwischen Signalprüfungen wechselten. Das Problem war nicht der visuelle Stil, sondern das Fehlen eines kohärenten UX-Modells für Engineering-Tools, das mit der Praxis im Feld übereinstimmt.

Das Gerät läuft auf einem kleinen Embedded-Display mit 480 mal 320 Pixeln mit begrenztem Single-Point-Touch und bescheidenen Rechenressourcen. Touch-Targets mussten großzügig genug für die Nutzung mit Handschuhen bleiben. Text musste auf Armlänge lesbar bleiben. Die GUI des Messgeräts konnte sich daher nicht auf gestengesteuerte Muster oder dichte Informationslayouts verlassen.

Diese Einschränkungen prägten konkrete Entscheidungen. Wir begrenzten die Menütiefe und die Anzahl der Elemente pro Bildschirm, sodass jede Ansicht einen vollständigen Satz von Optionen anzeigen konnte, ohne die Schriftgröße unter eine komfortable Schwelle zu reduzieren. Wir vermieden Animationen und aufwendige grafische Behandlungen, um die Interaktion auf der eingeschränkten Hardware knackig zu halten. Jeder Bildschirm wurde als ein kleiner, in sich geschlossener Zustand konzipiert, den Techniker in Sekundenbruchteilen interpretieren konnten, während sie gleichzeitig Kabel, Displays und Switcher im Auge behielten.

Wir sammelten Anforderungen mit dem MSolutions Product Owner, dem Lead Firmware Engineer und einer Gruppe von erfahrenen AV-Technikern, die professionelle Messsoftware in der täglichen Arbeit nutzen. Jede Gruppe hatte unterschiedliche Prioritäten. Engineers wollten vollen Zugriff auf Low-Level-Parameter. Techniker wollten weniger Schritte und klarere Bestätigung der Ergebnisse. Produktmanagement benötigte eine Struktur, die zukünftige Features unterstützen konnte, ohne ein weiteres Redesign.

Wir übersetzten diese Inputs in eine einzige Strategie durch tension-driven reasoning. Für jeden Bildschirm des professionellen Instrumentierungs-Interface definierten wir ein explizites Ergebnis: welche Entscheidung der Techniker in diesem Moment treffen können sollte. Bestehende Funktionen wurden dann diesen Ergebnissen zugeordnet, und widersprüchliche Prioritäten wurden auf Strategieebene gelöst, anstatt sie ad hoc Entscheidungen auf einzelnen Bildschirmen zu überlassen. Dies schuf eine stabile Grundlage für Release-Planung und für spätere Erweiterung des embedded device UX Designs.

Der konzeptionelle Durchbruch kam davon, das Gerät als Leitfaden durch eine standardmäßige AV-Diagnose-Narrative zu behandeln, anstatt als eine Sammlung von Tools. Das neue Modell strukturiert die Messsequenz so, wie Techniker sie tatsächlich erleben. Ein typischer Workflow beginnt beispielsweise mit Link-Integritätsprüfungen, fährt mit EDID- und HDCP-Verifizierung fort, geht dann zur Auflösungs- und Farbraum-Validierung auf jedem Display über und endet mit einer konsolidierten Bestätigung, dass die Installation das definierte Profil erfüllt.

In der neuen embedded GUI weist jeder Zustand auf die nächste logische Aktion hin. Parameter erscheinen nur, wenn sie für den aktuellen Diagnoseschritt benötigt werden. Die visuelle Hierarchie betont eine technische Absicht pro Bildschirm und verweist sekundäre Informationen auf vorhersehbare Positionen. Für Techniker verhält sich das Gerät nun wie ein erfahrener Kollege, der die richtigen Prüfungen in der richtigen Reihenfolge anzeigt, anstatt wie eine Schublade voller separater Instrumente.

Wir übersetzten das neue Modell in interaktive Prototypen und testeten sie mit AV-Technikern, die regelmäßig an Multi-Monitor-Konferenzräumen und Video-Walls arbeiten. Sessions kombinierten aufgabenbasierte Beobachtung mit kurzen Interviews. Techniker wurden gebeten, realistische Szenarien durchzuführen, wie zum Beispiel die Identifizierung der Ursache einer falschen Auflösung auf einem Display in einer Signalkette, die ansonsten gesund erscheint.

Feedback konzentrierte sich auf Terminologie, Gruppierung von Signalparametern und die Reihenfolge, in der Ergebnisse erscheinen sollten, wenn ein Fehler entdeckt wird. Der zentrale Workflow erforderte keine Änderung, aber viele Details wurden angepasst. Bestimmte Labels wurden überarbeitet, um der Sprache zu entsprechen, die Techniker vor Ort verwenden. Einige zwischengeschaltete Bestätigungszustände wurden vereinfacht, um Zögern zu vermeiden. Nach diesen Verfeinerungen bemerkte ein Teilnehmer, dass das embedded Interface endlich der Art und Weise entsprach, wie sie bereits denken, wenn sie vor einem Rack stehen. Der vollständige Loop von Testing und Iteration dauerte zwei intensive Tage innerhalb des sechswöchigen Projektfensters.

Sobald das embedded Interaktionsmodell stabil war, erweiterten wir das technische device UX auf eine Laptop- und Mobile-Umgebung. Die responsive Architektur bewahrt die gleiche Sequenz von Techniker-Workflows, während sie die größeren Flächen nutzt, um Beziehungen zwischen Messungen, historischen Werten und Referenzprofilen klarer zu zeigen.

Techniker können sich jetzt während Inbetriebnahmesessions von einem Laptop aus mit dem Messgerät verbinden oder ein mobiles Interface während schneller Checks nutzen. Das Cross-Platform-Interface-Design ermöglicht Fernsteuerung in engen Räumen und bessere Zusammenarbeit zwischen Kollegen vor Ort und Kollegen in einem zentralen Operationszentrum. Da das konzeptionelle Modell identisch ist, gibt es keine Notwendigkeit, separate Verhaltensweisen für jede Plattform zu erlernen.