![\"Screenshot](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/amazon1994undAppleCom1997QuelleArchiveOrg.jpg\")
<\/a>Sogar Amazon und Apple irrten damals, als sie glaubten es sei eine gute Idee, das aus dem Medium \u201eZeitung\u201c erlernte Gestaltungswissen 1:1 auf das neue Medium \u201eInternet\u201c zu \u00fcbertragen.<\/p><\/div>\n
<\/p>\n
Statisch ist statisch und bleibt statisch<\/h3>\n
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\u00e4hrend der Bedienung lange im gleichen Zustand noch kommt ein HMI Konzept aufgrund sich \u00e4ndernder Marktanforderungen lange ohne Weiterentwicklungen oder Erg\u00e4nzungen aus. Das bereits bei CD Styleguides existierende, jedoch in dieser Dom\u00e4ne weniger kritische Problem des \u201eBereits-\u00dcberholt-Seins\u201c potenziert sich hier. Ein Entwickler der einmal einige Zeilen Quellcode auf Basis einer veralteten Richtlinie programmiert hat, um diese dann wieder verwerfen zu m\u00fcssen, wird dem Styleguide alsbald den R\u00fccken kehren. Zudem kann der Versuch, komplexe, dynamische Sachverhalte in einem statischen Dokument zu beschreiben in einer ausladenden Sintflut von Prosa enden, die Gefahr l\u00e4uft, niemals wirklich gelesen oder gar angewendet zu werden.<\/p>\n
<\/a>Ein typischer CD Styleguide ist im Kern ein Dokument von visuellen Gestaltern f\u00fcr visuelle Gestalter.<\/p><\/div>\n
\u00c4sthetik ist nicht gleich Ergonomie<\/h3>\n
CD Styleguides beschreiben meist rein \u00e4sthetische 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\u00e4nden, kann also effektiv in ein Regelwerk gefasst werden. Die korrekte Verwendung mannigfaltiger HMI Controls in diversesten Anwendungskontexten f\u00fcr verschiedenste UI Technologien, Endger\u00e4te und Bildschirmgr\u00f6\u00dfen dagegen ist eine ganz andere Herausforderung. Leider reicht es auch nicht, wenn das resultierende HMI \u201enur\u201c \u00e4sthetisch erfolgreich ist, also alle HMI Elemente harmonisch auf dem Bildschirm platziert wurden. Viel wichtiger f\u00fcr den Gesamterfolg des HMI ist die Frage, ob es auch ergonomisch, effizient und fehlerfrei benutzbar ist \u2013 also eine insgesamt positive User Experience (UX) bietet. Hier\u00fcber entscheiden oft viel subtilere Faktoren, die sich kaum in allgemeine, simple Regeln gie\u00dfen lassen.<\/p>\n
<\/a>Gute User Experience ist immer ein Resultat des Zusammenspiels verschiedener Disziplinen \u2013 es geht auch aber nicht alleine um \u00c4sthetik.<\/p><\/div>\n
Gestaltung ohne Hintergrund<\/h3>\n
Die Hauptnutzer eines CD Styleguides sind Designer oder Mediengestalter \u2013 ein Regelwerk von Gestaltern f\u00fcr 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\u00e4llen 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\u00e4utert 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\u00f6nnen. Software Engineers m\u00fcssen von HMI Styleguides somit grunds\u00e4tzlich anders abgeholt werden.<\/p>\n
<\/a>Nicht jede Design-Spezifikation erschlie\u00dft sich dem Entwickler direkt.<\/p><\/div>\n
Das Ziel vor Augen \u2013 aber jeder ein anderes<\/h3>\n
Das gr\u00f6\u00dfte und folgenschwerste Missverst\u00e4ndnis 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\u00f6ht sich die Wiedererkennbarkeit des Unternehmens. Bei einem HMI Styleguide ist das Ziel vordergr\u00fcndig sehr \u00e4hnlich \u2013 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.<\/p>\n
Der Software Engineer hat bei der Entwicklung eines HMI Styleguides vor allem die Hoffnung, dass seine Implementierung effizienter und wartbarer wird. Denn wenn f\u00fcr gleiche Probleme auch gleiche Bausteine verwendet werden k\u00f6nnen, produziert man keine unn\u00f6tige Code-Dopplung.\u00a0Der (visuelle) Designer erwartet von einem HMI Styleguide, dass hierdurch alle Masken elegant, konsistent und \u00e4sthetisch daherkommen und kein vordergr\u00fcndig sichtbarer Qualit\u00e4tsunterschied gegen\u00fcber den eigens gestalteten Masken existiert. Der Interaktionsdesigner erwartet zus\u00e4tzlich, dass diese Masken auch auf den zweiten Blick noch ergonomisch sind.\u00a0Der Produkt Manager erwartet von dem HMI Styleguide, dass sein Entwicklerteam trotz m\u00f6glichst weniger Design-R\u00fcckfragen benutzerfreundliche Masken eigenst\u00e4ndig implementieren kann.<\/p>\n
Doch letztlich kommt in der Wirklichkeit meist keine einzige der genannten Rollen auf ihre Kosten: Der Software Entwickler kodiert schon zum wiederholten Male \u00e4hnlichen, aber eben doch anderen HMI Code, der visuelle Designer \u00e4rgert sich dar\u00fcber, dass nicht einmal der basale Grundstock von Icons konsistent verwendet wird, der Produkt Manager hat das Gef\u00fchl, die Entwickler werden nicht ausreichend unterst\u00fctzt und der Interaktionsdesigner ist unangenehm \u00fcberrascht dar\u00fcber, dass die Bediener berichten: \u201eDas neue Interface ist zwar moderner und aufger\u00e4umter, aber es geht an den eigentlichen Arbeitsabl\u00e4ufen vorbei.\u201c.<\/p>\n
<\/a>In einem interdisziplin\u00e4ren Team driften die Erwartungen an einen HMI Styleguide oft auseinander.<\/p><\/div>\n
Teil des Ganzen<\/h3>\n
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\u00e4\u00dfigen Ergebnissen f\u00fchren? Warum bleiben resultierende HMIs trotz Regelwerken oft unter ihren M\u00f6glichkeiten und was kann man dagegen tun?<\/p>\n
Wie so oft sind die Erwartungen der einzelnen Stakeholder nicht unbedingt \u00fcberh\u00f6ht \u2013 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\u00fcssen, um seine Effektivit\u00e4t \u00fcberhaupt zu erm\u00f6glichen.<\/p>\n
Um bei der Gestaltung von HMIs erfolgreich zu sein, bedarf es etwas, dass man \u201eCorporate UX Framework\u201c nennen k\u00f6nnte. 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\u00e4nzen.<\/p>\n
Im zweiten Teil dieses Artikels<\/a> beschreibe ich, wie man mit einer Kombination aus HMI Styleguide, HMI Kit, Asset-Management, Design-Abnahme und evolution\u00e4ren Ans\u00e4tzen Schritt f\u00fcr Schritt zu einem gut gestalteten HMI kommt. Es wird erl\u00e4utert, wann und in welcher Reihenfolge die einzelnen Bausteine zum Tragen kommen und wie sie erfolgreich in einen agilen Software-Entwicklungsprozess integriert werden k\u00f6nnen.<\/p>\n Falls Sie Interesse daran haben sollten, sich in einem Projekt von uns unterst\u00fctzen zu lassen, werfen Sie auch gerne einen Blick auf unsere entsprechenden Services Seiten:<\/p>\n\n