Die richtige Reihenfolge

Da gerade die gut formalisierbaren Regeln für Entwickler am einfachsten nachvollziehbar und konsumierbar sind, besteht der Reflex, diese im Projekt auch möglichst früh zu definieren - frei nach dem Motto: „Was man hat, das hat man!“. Dies fühlt sich für manchen, der das Lösen von Problemen gelernt hat, intuitiv richtig an, ist jedoch wieder ein folgenreicher Irrtum. Genau wie man eine tragfähige Software-Architektur nicht vom View-Layer, sondern Service-Layer aus aufbauen sollte, sollte man auch die Entwicklung eines HMI-Regelwerkes nicht beim Augenscheinlichen starten. Stattdessen sollte man vom Ursprung ausgehen, also den Nutzeranforderungen.

Es empfiehlt sich als ersten Schritt, alle wichtigen Nutzungsszenarien möglichst detailliert zu kartographieren. Spätere Projektergebnisse sollten anhand dieser Nutzungsszenarien zu kontinuierlich gruppiert und mittels Usability- und Integrations-Tests validiert werden, statt einmal Initial auf rein logische Einheiten wie „Farben“, „Layout“ und „Controls“ zu bauen.

Möchte man bei der Entwicklung eines HMI-Styleguides kein Risiko eingehen, so empfiehlt es sich paradoxerweise, die Verwendung des Begriffs „HMI-Styleguide“ möglichst lange hinauszuzögern. Es müssen vorher viel grundlegendere Weichen gestellt werden, die man in ihrer Summe als „Corporate UX Framework“ bezeichnen könnte – die Etablierung eines allgemeinen Rahmenwerks also, welches UX zum strategischen Unternehmensziel erklärt und entsprechend konsequent integriert.

Ähnlich wie SCRUM definiert das eigene Corporate UX Framework ein Ökosystem aus Philosophien, Rollen, Prozessen und Methoden, auf dessen Boden technische oder gestalterische Artefakte erst erfolgreich gedeihen können. Alle notwendigen Schritte hin zu einem effektiven Corporate UX Framework an dieser Stelle zu beschreiben, würden den Rahmen des Artikels sprengen – es empfiehlt sich hierfür einen erfahrenen und ganzheitlichen UX-Dienstleister zu konsultieren. Aber: ein besonders essenzieller Aspekt sei folgend dennoch beschrieben, da er – einmal Fehler im System geworden – nicht mehr umkehrbar ist.

Wer ernsthaft plant, ein HMI-Regelwerk unternehmensweit oder über Produktgrenzen hinweg zu etablieren, muss in seinem Organigramm frühzeitig die abteilungsübergreifende Rolle des „UX-Managers“ installieren, in dessen Verantwortung ein verbindlicher Design-Abnahme-Prozess definiert und überwacht wird. Problematisch ist wie so oft, dass verschiedene Abteilungen auch verschiedene Perspektiven auf die Notwendigkeit guter UX haben. Während die eine Abteilung dem Thema tatsächlich aus Gründen einer verbesserten Nutzbarkeit verbunden sein mag, ist eine andere Abteilung eigentlich nur daran interessiert, mit den entstehenden Regelwerken und Bausteinen effizienter Software zu entwickeln.

Sobald dann zeitlicher Druck entsteht oder der „am-lautesten-schreiende-Kunde“ nach mehr Features verlangt, fallen die Prioritäten für UX-bezogene Aktivitäten wie Blätter im Herbst, sofern sie nicht gleichzeitig auch die eigentlich erhoffte Entwicklungseffizienz erhöhen. Es sei aber gesagt: ein effektiver UX-Manager beseitigt nicht die Notwendigkeit, dass jeder Entwickler auch UX-Design zu einem gewissen Teil verinnerlichen muss. Im Gegenteil: der UX-Manager muss explizit daran arbeiten, dieses ganzheitliche Denken in die Köpfe der Entwickler zu bekommen.

Natürlich kann man eine uneinige Interessenslage nicht von heute auf morgen angleichen. Auf der einen Seite besteht das nachvollziehbare Problem, dass eine Feature-getriebene Abteilung frühe Ergebnisse erwartet, um bei ihrem marktgetriebenen Voranschreiten nicht blockiert zu sein. Umgekehrt steht das frühe Corporate UX Framework mitsamt HMI-Kit und HMI-Styleguide vor dem Problem, dass ein Konzept zunächst an verschiedenen Nutzungsszenarien verschiedener Abteilungen ordentlich erprobt und validiert werden muss, bevor es unternehmensweit eingesetzt werden kann. Denn genau wie sich gute Konzepte positiv verbreiten, verbreiten sich auch fehlerhafte Konzepte negativ.

Das Referenzieren unfertiger HMI-Kit-Komponenten im Anwendungscode stellt zu diesem frühen Zeitpunkt also ein hohes Risiko dar, weshalb Abteilungen letztlich doch ihre eigenen HMI-Komponenten implementieren, die aber leider keinen Gestaltungsrichtlinien folgen. Primärer Wunsch dieser Entwicklungsabteilungen ist es, unabhängig von der Entwicklungsgeschwindigkeit des HMI-Kit-Teams zu sein.