{"id":7282,"date":"2016-12-02T14:22:46","date_gmt":"2016-12-02T13:22:46","guid":{"rendered":"http:\/\/www.centigrade.de\/blog\/de\/?p=7282"},"modified":"2017-08-18T19:26:42","modified_gmt":"2017-08-18T17:26:42","slug":"hmi-styleguides-im-unternehmen-etablieren-teil-2","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/hmi-styleguides-im-unternehmen-etablieren-teil-2\/","title":{"rendered":"HMI Styleguides im Unternehmen etablieren \u2013 Teil 2"},"content":{"rendered":"

Im ersten Teil dieses Artikels<\/a> habe ich geschildert, warum es zwar intuitiv, aber nicht minder gef\u00e4hrlich ist, sich bei der Etablierung eines HMI Styleguides an CD Styleguides zu orientieren. Ein Problem besteht z.B. darin, dass ein HMI Styleguide im Gegensatz zu einem CD Styleguide nicht nur f\u00fcr Gestalter, sondern vor allem auch f\u00fcr Software Engineers funktionieren muss. Die Dokumentform ist zudem zu rigide f\u00fcr die Dynamik moderner HMIs. Besonders wichtig ist die folgende Erkenntnis: der HMI Styleguide kann es generell nicht leisten, die alleinige Basis zu sein, auf deren Grundlage Software Engineers konsistente, \u00e4sthetische und intuitive HMIs entwickeln. Aufgrund meiner Erfahrung mit gro\u00dfen HMI Design Projekten in meiner Rolle als UX Berater bei Centigrade wei\u00df ich: hier kann nur die Kombination aus fl\u00fcssig ineinandergreifenden Methoden, Tools und Prozessen zum Erfolg f\u00fchren.<\/p>\n

\"TRUMPF-Centigrade-HMI-Styleguide\"

Abbildung 1: Centigrade unterst\u00fctzt TRUMPF bei der Etablierung konzernweiter HMI Gestaltungsrichtlinien<\/p><\/div>\n

<\/p>\n

Wenn schon formal, dann auch in Code<\/h3>\n

Grunds\u00e4tzlich gilt: je formaler die Regeln zur Gestaltung eines HMIs ausgedr\u00fcckt werden k\u00f6nnen, desto weniger sollten sie in ein totes Dokument oder \u201ehalbtotes\u201c Wiki gegossen werden. Generell sind Medien ungeeignet, die zu opulenter Prosa verf\u00fchren oder auf einer separaten Evolutionslinie existieren.<\/p>\n

Moderne Markupsprachen machen es aber m\u00f6glich, Gestaltungsregeln zur korrekten Verwendung von Farben, Icons, Gr\u00f6\u00dfenverh\u00e4ltnisse und dynamischem Layoutverhalten direkt im Quellcode auszudr\u00fccken. So k\u00f6nnen mittels HTML, CSS, XAML, QML oder \u00e4hnlichen Markupsprachen effektive Schablonen f\u00fcr wiederkehrende Design-Entwicklungs-Probleme geschaffen werden. Der HMI Styleguide wird zur \u201elebendigen\u201c Spezifikation.<\/p>\n

Diese von spezialisierten \u201eDesign Engineers\u201c<\/a> codierten Design-Schablonen zeichnen sich dadurch aus, dass sie visuell und interaktiv den hohen Anspr\u00fcchen eines Gestalters (und Nutzers) entsprechen, software-technisch aber auch den nicht minder hohen Anspr\u00fcchen eines Software Engineers gen\u00fcgen. Die umfassende Verwendung von Markupsprachen zur HMI Gestaltung ist daher dringend anzuraten.<\/p>\n

\"XAMLvsHTML\"<\/a>

Abbildung 2: XAML oder HTML\/CSS erlauben es, Gestaltungsvorlagen f\u00fcr das HMI direkt in Code zu gie\u00dfen.<\/p><\/div>\n

Mit Bedacht angegangen, eine gute Idee: das HMI Kit<\/h3>\n

Geht man einen Schritt weiter, so k\u00f6nnen HMI Komponenten inkl. Eingabeverhalten, Navigationsverhalten, Animationsverhalten und Visualisierung in sich geschlossen entwickelt und in Form einer zentralen Bibliothek zur Verf\u00fcgung gestellt werden \u2013 ein unternehmensweiter Baukasten also, den man \u201eHMI Kit\u201c nennen k\u00f6nnte. Diese Investition ist durchaus sinnvoll, muss jedoch mit Bedacht angegangen werden.<\/p>\n

Die richtige Reihenfolge<\/h3>\n

Da gerade die gut formalisierbaren Regeln f\u00fcr Engineers am einfachsten nachvollziehbar und konsumierbar sind, besteht der Reflex, diese im Projekt auch m\u00f6glichst fr\u00fch zu definieren, frei nach dem Motto: \u201eWas man hat, das hat man!\u201c. Dies f\u00fchlt sich f\u00fcr manchen, der das L\u00f6sen von Problemen gelernt hat, intuitiv richtig an, ist jedoch wieder ein folgenreicher Irrtum. Genau wie man eine tragf\u00e4hige 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.<\/p>\n

Es empfiehlt sich als ersten Schritt, alle wichtigen Nutzungsszenarien m\u00f6glichst detailliert zu kartographieren, sp\u00e4tere Projektergebnisse kontinuierlich anhand dieser Nutzungsszenarien zu gruppieren und mittels Usability- und Integrations-Tests zu validieren, statt einmal initial auf rein logische Einheiten wie \u201eFarben\u201c, \u201eLayout\u201c und \u201eControls\u201c zu bauen.<\/p>\n

\"MapWatchOut\"<\/a>

Abbildung 3:Das Kartographieren und Priorisieren aller bekannten Nutzungsszenarien ist einer der ersten Schritte, wenn der HMI Styleguide sp\u00e4ter erfolgreich sein soll.<\/p><\/div>\n

Erst der Rahmen, dann die W\u00e4nde<\/h3>\n

M\u00f6chte man bei der Entwicklung eines HMI Styleguides kein Risiko eingehen, so empfiehlt es sich paradoxerweise, die Verwendung des Begriffs \u201eHMI Styleguide\u201c m\u00f6glichst lange hinauszuz\u00f6gern. Es m\u00fcssen vorher viel grundlegendere Weichen gestellt werden, die man in ihrer Summe als \u201eCorporate UX Framework\u201c bezeichnen k\u00f6nnte \u2013 die Etablierung eines allgemeines Rahmenwerk also, welches UX zum strategischen Unternehmensziel erkl\u00e4rt und entsprechend konsequent integriert.<\/p>\n

\u00c4hnlich wie SCRUM definiert das eigene Corporate UX Framework ein \u00d6kosystem aus Philosophien, Rollen, Prozessen und Methoden, auf dessen Boden technische oder gestalterische Artefakte erst erfolgreich gedeihen k\u00f6nnen. Alle notwendigen Schritte hin zu einem effektiven Corporate UX Framework an dieser Stelle zu beschreiben, w\u00fcrden den Rahmen des Artikels sprengen \u2013 es empfiehlt sich hierf\u00fcr einen erfahrenen und ganzheitlichen UX Dienstleister zu konsultieren. Aber: ein besonders essenzieller Aspekt sei folgend dennoch beschrieben, da er \u2013 einmal Fehler im System geworden \u2013 nicht mehr umkehrbar ist.<\/p>\n

Jenseits der Naivit\u00e4t: UX Management<\/h3>\n

Wer ernsthaft plant, ein HMI Regelwerk unternehmensweit oder \u00fcber Produktgrenzen hinweg zu etablieren, muss in seinem Organigramm fr\u00fchzeitig die abteilungs\u00fcbergreifende Rolle des \u201eUX Managers\u201c installieren, in dessen Verantwortung ein verbindlicher Design-Abnahme Prozess definiert und \u00fcberwacht wird. Problematisch ist n\u00e4mlich wie so oft, dass verschiedene Abteilungen auch verschiedene Perspektiven auf die Notwendigkeit guter UX haben. W\u00e4hrend die eine Abteilung dem Thema tats\u00e4chlich aus Gr\u00fcnden 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 \u201eam-lautesten-schreiende-Kunde\u201c nach mehr Features verlangt, fallen die Priorit\u00e4ten f\u00fcr UX-bezogene Aktivit\u00e4ten wie Bl\u00e4tter im Herbst, sofern sie nicht gleichzeitig auch die eigentlich erhoffte Entwicklungseffizienz erh\u00f6hen. Es sei aber gesagt: ein effektiver UX Manager beseitigt nicht die Notwendigkeit, dass jeder Entwickler auch UX Design zu einem gewissen Teil verinnerlichen muss.<\/a> Im Gegenteil \u2013 der UX Manager muss explizit daran arbeiten, dieses ganzheitliche Denken in die K\u00f6pfe der Entwickler zu bekommen.<\/p>\n

Spur und \u00dcberholspur<\/h3>\n

Nat\u00fcrlich 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\u00fche Ergebnisse erwartet, um bei ihrem marktgetriebenen Voranschreiten nicht blockiert zu sein. Umgekehrt steht das fr\u00fche Corporate UX Framework mitsamt HMI Kit und HMI Styleguide vor dem Problem, dass ein Konzept zun\u00e4chst 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. Die Referenzierung unfertiger HMI Kit Komponenten im Anwendungscode stellt zu diesem fr\u00fchen Zeitpunkt also ein hohes Risiko dar, weshalb Abteilungen letztlich hingehen und doch ihre eigenen HMI Komponenten implementieren (die aber leider keinen Gestaltungsrichtlinien folgen, wie in Abbildung 4 gezeigt). Prim\u00e4rer Wunsch dieser Entwicklungsabteilungen ist es, unabh\u00e4ngig von der Entwicklungsgeschwindigkeit des HMI Kit Teams zu sein (siehe Abbildung 5).<\/p>\n

\"EvolutionFlow-SZ1-EN\"<\/a>

Abbildung 4: Werden HMI Kit Vorlagen referenziert, besteht das Risiko, dass diese bei \u00c4nderung bestehende Masken nachtr\u00e4glich \u201ebrechen\u201c.<\/p><\/div>\n

\"EvolutionFlow-SZ2-DE\"<\/a>

Abbildung 5: Wird statt zu referenzieren, \u201etoter\u201c Code kopiert, besteht umgekehrt die Gefahr, dass keine einheitliche und konsistente Gestaltungslinie existiert.<\/p><\/div>\n

Evolution beg\u00fcnstigt Entwicklung \u2013 wieder mal<\/h3>\n

Dieses Dilemma kann nur durch eine evolution\u00e4re und kontinuierliche Vorgehensweise aufgel\u00f6st werden. Um Evolutionsmechanismen erfolgreich wirken zu lassen, empfehlen wir unseren Kunden einen Trick, den wir \u201eConcept Tagging\u201c nennen: Sobald ein HMI Konzept auch nur in dem Ma\u00dfe gereift ist, dass es dem Interaktionsdesigner klar ist, welches Nutzerproblem es l\u00f6sen k\u00f6nnte (ohne dass es dies zu diesem Zeitpunkt bereits zwangsl\u00e4ufig tut), wird dem HMI Konzept eine global eindeutige ID (\u201eGUID\u201c) zugewiesen. Diese GUID taucht ab diesem Zeitpunkt in allen Assets auf, die um das unfertige Konzept herum entwickelt werden \u2013 egal ob Gestaltungsregel, Photoshop Screen, Markup oder Produktionscode oder Beispielcode. In einem entsprechenden Asset Management System kann dann jederzeit eine einheitliche Sicht auf das Konzept zusammengestellt werden, die dem Entwickler nachvollziehbar klar macht: \u201eWenn du folgende Nutzeranforderung hast, nutze folgende Assets unter Ber\u00fccksichtigung folgender Gestaltungsregeln.\u201c<\/p>\n

Ein GUID-basiertes Asset Management f\u00fcr WPF existiert z.B. mit dem frei verf\u00fcgbaren XamlBoard<\/a> von Centigrade: Icons und XAML-Snippets k\u00f6nnen mit Metadaten versehen werden, um dem Entwickler das Auffinden und die korrekte Verwendung dieser wichtigen Assets sp\u00e4ter zu erleichtern.<\/p>\n

\"InspectProperly\"<\/a>

Abbildung 6: Centigrade XamlBoard ist ein Asset-Management System mit dem XAML Ressourcen oder Icons mit Metadaten wie z.B. Verwendungshinweisen ausgestattet werden k\u00f6nnen.<\/p><\/div>\n

Fertige Gestaltungsregel-Assets existieren ebenfalls bereits in zahlreichen Auspr\u00e4gungen und k\u00f6nnen entsprechend ins Gesamtbild integriert werden \u2013 genannt seien hier z.B. die iOS Human Interface Guidelines<\/a> oder Google Material Design Guidelines.<\/a><\/p>\n

\"Guidlines\"<\/a>

Abbildung 7: Die UX Guidelines von Google (Material Design) und iOS k\u00f6nnen und sollten ebenfalls f\u00fcr manches Gestaltungsproblem konsultiert werden.<\/p><\/div>\n

Unfertig ist nicht gleich unantastbar<\/h3>\n

Beim \u201eConcept Tagging\u201c ist es nicht tragisch, wenn etwa eine HMI Kit Komponente noch nicht fertig oder noch ungetestet ist. Die Anwendungsentwickler kopieren dann den noch unfertigen HMI Kit Code inkl. GUID und bauen diesen im eigenen Tempo mit ihren eigenen L\u00f6sungsverschl\u00e4gen in ihrer eigenen Infrastruktur um oder aus. In regelm\u00e4\u00dfigen Abst\u00e4nden wird dann durch eine Code-Differenz-Analyse zu Tage gef\u00f6rdert, welche Abteilung welches Konzept wie gel\u00f6st hat und durch die bis dahin ggf. fertiggestellte L\u00f6sung des HMI Kit Teams ersetzt oder konsolidiert. Umgekehrt k\u00f6nnen auch die L\u00f6sungsans\u00e4tze des Anwendungsentwickler-Teams in das HMI Kit einflie\u00dfen und helfen, dieses so f\u00fcr andere Abteilungen zu verbessern. Um mit der Evolutionstheorie zu sprechen: Die GUID fungiert als gemeinsame DNA f\u00fcr verwandte Assets, die auf Grundlage der gleichen Konzeptzelle reproduziert wurden, wie in Abbildung 8 illustriert.<\/p>\n

\"EvolutionFlow-SZ3-DE\"<\/a>

Abbildung 8: Aufl\u00f6sung des Dilemmas durch \u201eConcept Tagging\u201c \u2013 einzelne Konzepte und deren zugeh\u00f6rige Code Fragmente werden mit GUIDs ausgestattet, so dass eine sp\u00e4tere R\u00fcckverfolgung und Konsolidierung m\u00f6glich ist.<\/p><\/div>\n

Fazit<\/h3>\n

Der HMI Styleguide ist nur eine Komponente innerhalb eines gr\u00f6\u00dferen Rahmenwerkes, dem Corporate UX Framework, um zu einer konsistenten HMI Linie zu gelangen. \u201eTop-Down\u201c kontrolliert und abgenommen, aber \u201eBottom-Up\u201c vorangetrieben, werden Nutzeranforderungen kontinuierlich gesammelt und m\u00f6gliche L\u00f6sungskonzepte mit einer eindeutigen ID ausgestattet. Gestaltungsregeln, beispielhafte Code-Schablonen oder sogar gebrauchsfertige HMI Kit Komponenten k\u00f6nnen dann evolution\u00e4r verbessert und \u00fcber diese ID jederzeit miteinander in Bezug gesetzt und konsolidiert werden. In dieser Kombination erl\u00e4utern Sie dann dem Entwickler, in welcher Nutzungssituation er welche HMI Assets wie kombinieren muss, damit in der Folge ein intuitives und konsistent gestaltetes HMI entsteht.<\/p>\n

Dies war Teil zwei\u00a0des Artikels „HMI Styleguides im Unternehmen etablieren“. Lesen Sie hier Teil eins<\/a>.<\/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