Mit der Intuition ist es so eine Sache. Der Mensch profitiert oft von ihr, lässt sich aber auch immer wieder von ihr täuschen. Ein HMI so zu gestalten, dass es intuitiv bedienbar ist, scheint eines der erstrebenswertesten Ziele moderner Software-Entwicklung zu sein, erspart es doch kostenaufwändige Schulungen, Fehlbedienungen und vieles mehr.
Auf dem Weg dorthin unterliegen jedoch viele Software Engineers und sogar HMI Designer der Täuschung Ihrer eigenen Intuition. Sie sagen sich (noch korrekterweise): „Ein HMI Design muss konsistent und ästhetisch aufgebaut sein, damit Bediener aus bereits erlernten Mustern auch in neuen Nutzungskontexten profitieren können. Können sie eine Maschine bedienen, können sie dann praktisch jede Maschinen bedienen.“ Manche schlussfolgern jedoch falsch weiter: „Wer Konsistenz im HMI Design schaffen möchte, tut gut daran, sich bei der Nachbardisziplin des Corporate Design zu bedienen – denn dort existieren bereits seit Jahr und Tag Regelwerke zur Schaffung von Konsistenz in Markenerlebnissen: die Corporate Design (CD) Styleguides.“
Leider ist dies eine falsche Analogie: genauso wie es in den Anfangsjahren des Fernsehens eine schlechte Idee war, die Tagesnachrichten in gleicher Manier wie im Radio einfach vorzulesen oder erste Internetseiten wie Zeitungsartikel mit jeder Menge Fließtext in Serifenschrift zu gestalten, ist dies zwar intuitiv (weil bereits bekannt), aber trotzdem falsch. Die Regelwerk-Philosophie traditioneller CD Styleguides kann nicht so einfach auf moderne HMIs und deren Entwicklung übertragen werden.
Statisch ist statisch und bleibt statisch
CD Styleguides sind statische Dokumente, und mit den darin enthaltenen Design-Richtlinien werden statische Medien gestaltet. HMIs hingegen sind alles andere als statisch. Weder bleibt ein HMI Screen während der Bedienung lange im gleichen Zustand noch kommt ein HMI Konzept aufgrund sich ändernder Marktanforderungen lange ohne Weiterentwicklungen oder Ergänzungen aus. Das bereits bei CD Styleguides existierende, jedoch in dieser Domäne weniger kritische Problem des „Bereits-Überholt-Seins“ potenziert sich hier. Ein Entwickler der einmal einige Zeilen Quellcode auf Basis einer veralteten Richtlinie programmiert hat, um diese dann wieder verwerfen zu müssen, wird dem Styleguide alsbald den Rücken kehren. Zudem kann der Versuch, komplexe, dynamische Sachverhalte in einem statischen Dokument zu beschreiben in einer ausladenden Sintflut von Prosa enden, die Gefahr läuft, niemals wirklich gelesen oder gar angewendet zu werden.
Ästhetik ist nicht gleich Ergonomie
CD Styleguides beschreiben meist rein ästhetische Sachverhalte, aus denen sich leicht Richtlinien ableiten lassen. Die korrekte Positionierung eines Firmenlogos oder die geordnete Verwendung bestimmter vordefinierter CD Farben, z.B. in Printmaterialien oder Messeständen, kann also effektiv in ein Regelwerk gefasst werden. Die korrekte Verwendung mannigfaltiger HMI Controls in diversesten Anwendungskontexten für verschiedenste UI Technologien, Endgeräte und Bildschirmgrößen dagegen ist eine ganz andere Herausforderung. Leider reicht es auch nicht, wenn das resultierende HMI „nur“ ästhetisch erfolgreich ist, also alle HMI Elemente harmonisch auf dem Bildschirm platziert wurden. Viel wichtiger für den Gesamterfolg des HMI ist die Frage, ob es auch ergonomisch, effizient und fehlerfrei benutzbar ist – also eine insgesamt positive User Experience (UX) bietet. Hierüber entscheiden oft viel subtilere Faktoren, die sich kaum in allgemeine, simple Regeln gießen lassen.
Gestaltung ohne Hintergrund
Die Hauptnutzer eines CD Styleguides sind Designer oder Mediengestalter – ein Regelwerk von Gestaltern für Gestalter also. Die verwendete Sprache und Terminologie wird somit unter seinesgleichen verstanden. Die Hauptnutzer eines HMI Styleguides hingegen sind Software Engineers. Diese haben in den allermeisten Fällen keinerlei Gestaltungshintergrund und messen Design oft einen geringen Stellenwert bei. Ein Software Engineer zieht daher auch keinen Gewinn daraus, wenn ihm eine Design Richtlinie in Form opulenter Prosa erläutert wird. Aber auch eine etwas visuellere, formalere Spezifikation des Designs als Photoshop- oder Illustrator-Datei ist nur von begrenztem Nutzen, besitzen die meisten Engineers oft weder entsprechende Software-Lizenzen noch die Ausbildung, um die notwendigen Informationen effektiv herauslesen zu können. Software Engineers müssen von HMI Styleguides somit grundsätzlich anders abgeholt werden.
Das Ziel vor Augen – aber jeder ein anderes
Das größte und folgenschwerste Missverständnis bei der intuitiven, aber falschen Analogie von CD Styleguide und HMI Styleguide resultiert aber aus einem verborgenen Zielkonflikt. Bei einem CD Styleguide ist das Ziel klar erkennbar und jeder kann sich damit identifizieren: durch Konsistenz im visuellen Auftritt erhöht sich die Wiedererkennbarkeit des Unternehmens. Bei einem HMI Styleguide ist das Ziel vordergründig sehr ähnlich – bohrt man jedoch tiefer, ist es in Wirklichkeit ein anderes. Schlimmer noch: es handelt sich nicht um ein, sondern gleich um mehrere Ziele, die von Rolle zu Rolle im Entwicklungsteam variieren und teilweise konfligieren.
Der Software Engineer hat bei der Entwicklung eines HMI Styleguides vor allem die Hoffnung, dass seine Implementierung effizienter und wartbarer wird. Denn wenn für gleiche Probleme auch gleiche Bausteine verwendet werden können, produziert man keine unnötige Code-Dopplung. Der (visuelle) Designer erwartet von einem HMI Styleguide, dass hierdurch alle Masken elegant, konsistent und ästhetisch daherkommen und kein vordergründig sichtbarer Qualitätsunterschied gegenüber den eigens gestalteten Masken existiert. Der Interaktionsdesigner erwartet zusätzlich, dass diese Masken auch auf den zweiten Blick noch ergonomisch sind. Der Produkt Manager erwartet von dem HMI Styleguide, dass sein Entwicklerteam trotz möglichst weniger Design-Rückfragen benutzerfreundliche Masken eigenständig implementieren kann.
Doch letztlich kommt in der Wirklichkeit meist keine einzige der genannten Rollen auf ihre Kosten: Der Software Entwickler kodiert schon zum wiederholten Male ähnlichen, aber eben doch anderen HMI Code, der visuelle Designer ärgert sich darüber, dass nicht einmal der basale Grundstock von Icons konsistent verwendet wird, der Produkt Manager hat das Gefühl, die Entwickler werden nicht ausreichend unterstützt und der Interaktionsdesigner ist unangenehm überrascht darüber, dass die Bediener berichten: „Das neue Interface ist zwar moderner und aufgeräumter, aber es geht an den eigentlichen Arbeitsabläufen vorbei.“.
Teil des Ganzen
Doch warum ist das so? Wie kann das intuitiv so richtig und wichtig klingende Konzept des HMI Styleguides in der Praxis oft zu so mäßigen Ergebnissen führen? Warum bleiben resultierende HMIs trotz Regelwerken oft unter ihren Möglichkeiten und was kann man dagegen tun?
Wie so oft sind die Erwartungen der einzelnen Stakeholder nicht unbedingt überhöht – sie richten sich nur an den falschen Adressaten. Der HMI Styleguide ist nicht der alleinige Heilsbringer und kann dies auch nicht sein. Er ist wichtiger Bestandteil einer Reihe weiterer Komponenten, die korrekt ineinandergreifen müssen, um seine Effektivität überhaupt zu ermöglichen.
Um bei der Gestaltung von HMIs erfolgreich zu sein, bedarf es etwas, dass man „Corporate UX Framework“ nennen könnte. Dieses (zum Teil auch nicht-technische) Rahmenwerk beinhaltet zum einen den HMI Styleguide selbst, zum anderen aber auch eine Reihe von Prozessen und Technologien, die den Software Entwicklungsalltag aus der User Experience Perspektive effektiv ergänzen.
Im zweiten Teil dieses Artikels beschreibe ich, wie man mit einer Kombination aus HMI Styleguide, HMI Kit, Asset-Management, Design-Abnahme und evolutionären Ansätzen Schritt für Schritt zu einem gut gestalteten HMI kommt. Es wird erläutert, wann und in welcher Reihenfolge die einzelnen Bausteine zum Tragen kommen und wie sie erfolgreich in einen agilen Software-Entwicklungsprozess integriert werden können.
Falls Sie Interesse daran haben sollten, sich in einem Projekt von uns unterstützen zu lassen, werfen Sie auch gerne einen Blick auf unsere entsprechenden Services Seiten:
- UX Strategy
- Anwenderzufriedenheit direkt ab Werk: Usability
- Ästhetik trifft Architektur: Design
- Architektur trifft Ästhetik: Engineering