Sie verwenden derzeit einen Browser, der nicht mehr unterstützt wird und bei dem es daher zu Darstellungsfehlern kommen kann. Wechseln sie den Browser, um ein noch schöneres Design zu erleben.

Cookies helfen uns bei der Bereitstellung unserer Dienste. Durch die Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies setzen. Mehr erfahren.

Close

Über den Tellerrand geschaut

HMI Styleguides im Unternehmen etablieren – Teil 2

Thomas Immich

Im ersten Teil dieses Artikels habe ich geschildert, warum es zwar intuitiv, aber nicht minder gefährlich 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ür Gestalter, sondern vor allem auch für Software Engineers funktionieren muss. Die Dokumentform ist zudem zu rigide für 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, ästhetische und intuitive HMIs entwickeln. Aufgrund meiner Erfahrung mit großen HMI Design Projekten in meiner Rolle als UX Berater bei Centigrade weiß ich: hier kann nur die Kombination aus flüssig ineinandergreifenden Methoden, Tools und Prozessen zum Erfolg führen.

TRUMPF-Centigrade-HMI-Styleguide

Abbildung 1: Centigrade unterstützt TRUMPF bei der Etablierung konzernweiter HMI Gestaltungsrichtlinien

Wenn schon formal, dann auch in Code

Grundsätzlich gilt: je formaler die Regeln zur Gestaltung eines HMIs ausgedrückt werden können, desto weniger sollten sie in ein totes Dokument oder „halbtotes“ Wiki gegossen werden. Generell sind Medien ungeeignet, die zu opulenter Prosa verführen oder auf einer separaten Evolutionslinie existieren.

Moderne Markupsprachen machen es aber möglich, Gestaltungsregeln zur korrekten Verwendung von Farben, Icons, Größenverhältnisse und dynamischem Layoutverhalten direkt im Quellcode auszudrücken. So können mittels HTML, CSS, XAML, QML oder ähnlichen Markupsprachen effektive Schablonen für wiederkehrende Design-Entwicklungs-Probleme geschaffen werden. Der HMI Styleguide wird zur „lebendigen“ Spezifikation.

Diese von spezialisierten „Design Engineers“ codierten Design-Schablonen zeichnen sich dadurch aus, dass sie visuell und interaktiv den hohen Ansprüchen eines Gestalters (und Nutzers) entsprechen, software-technisch aber auch den nicht minder hohen Ansprüchen eines Software Engineers genügen. Die umfassende Verwendung von Markupsprachen zur HMI Gestaltung ist daher dringend anzuraten.

XAMLvsHTML

Abbildung 2: XAML oder HTML/CSS erlauben es, Gestaltungsvorlagen für das HMI direkt in Code zu gießen.

Mit Bedacht angegangen, eine gute Idee: das HMI Kit

Geht man einen Schritt weiter, so können HMI Komponenten inkl. Eingabeverhalten, Navigationsverhalten, Animationsverhalten und Visualisierung in sich geschlossen entwickelt und in Form einer zentralen Bibliothek zur Verfügung gestellt werden – ein unternehmensweiter Baukasten also, den man „HMI Kit“ nennen könnte. Diese Investition ist durchaus sinnvoll, muss jedoch mit Bedacht angegangen werden.

Die richtige Reihenfolge

Da gerade die gut formalisierbaren Regeln für Engineers 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 kontinuierlich anhand dieser Nutzungsszenarien zu gruppieren und mittels Usability- und Integrations-Tests zu validieren, statt einmal initial auf rein logische Einheiten wie „Farben“, „Layout“ und „Controls“ zu bauen.

MapWatchOut

Abbildung 3:Das Kartographieren und Priorisieren aller bekannten Nutzungsszenarien ist einer der ersten Schritte, wenn der HMI Styleguide später erfolgreich sein soll.

Erst der Rahmen, dann die Wände

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 allgemeines Rahmenwerk 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.

Jenseits der Naivität: UX Management

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 nämlich 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.

Spur und Überholspur

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. Die Referenzierung unfertiger HMI Kit Komponenten im Anwendungscode stellt zu diesem frühen 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ärer Wunsch dieser Entwicklungsabteilungen ist es, unabhängig von der Entwicklungsgeschwindigkeit des HMI Kit Teams zu sein (siehe Abbildung 5).

EvolutionFlow-SZ1-EN

Abbildung 4: Werden HMI Kit Vorlagen referenziert, besteht das Risiko, dass diese bei Änderung bestehende Masken nachträglich „brechen“.

EvolutionFlow-SZ2-DE

Abbildung 5: Wird statt zu referenzieren, „toter“ Code kopiert, besteht umgekehrt die Gefahr, dass keine einheitliche und konsistente Gestaltungslinie existiert.

Evolution begünstigt Entwicklung – wieder mal

Dieses Dilemma kann nur durch eine evolutionäre und kontinuierliche Vorgehensweise aufgelöst werden. Um Evolutionsmechanismen erfolgreich wirken zu lassen, empfehlen wir unseren Kunden einen Trick, den wir „Concept Tagging“ nennen: Sobald ein HMI Konzept auch nur in dem Maße gereift ist, dass es dem Interaktionsdesigner klar ist, welches Nutzerproblem es lösen könnte (ohne dass es dies zu diesem Zeitpunkt bereits zwangsläufig tut), wird dem HMI Konzept eine global eindeutige ID („GUID“) zugewiesen. Diese GUID taucht ab diesem Zeitpunkt in allen Assets auf, die um das unfertige Konzept herum entwickelt werden – 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: „Wenn du folgende Nutzeranforderung hast, nutze folgende Assets unter Berücksichtigung folgender Gestaltungsregeln.“

Ein GUID-basiertes Asset Management für WPF existiert z.B. mit dem frei verfügbaren XamlBoard von Centigrade: Icons und XAML-Snippets können mit Metadaten versehen werden, um dem Entwickler das Auffinden und die korrekte Verwendung dieser wichtigen Assets später zu erleichtern.

InspectProperly

Abbildung 6: Centigrade XamlBoard ist ein Asset-Management System mit dem XAML Ressourcen oder Icons mit Metadaten wie z.B. Verwendungshinweisen ausgestattet werden können.

Fertige Gestaltungsregel-Assets existieren ebenfalls bereits in zahlreichen Ausprägungen und können entsprechend ins Gesamtbild integriert werden – genannt seien hier z.B. die iOS Human Interface Guidelines oder Google Material Design Guidelines.

Guidlines

Abbildung 7: Die UX Guidelines von Google (Material Design) und iOS können und sollten ebenfalls für manches Gestaltungsproblem konsultiert werden.

Unfertig ist nicht gleich unantastbar

Beim „Concept Tagging“ 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ösungsverschlägen in ihrer eigenen Infrastruktur um oder aus. In regelmäßigen Abständen wird dann durch eine Code-Differenz-Analyse zu Tage gefördert, welche Abteilung welches Konzept wie gelöst hat und durch die bis dahin ggf. fertiggestellte Lösung des HMI Kit Teams ersetzt oder konsolidiert. Umgekehrt können auch die Lösungsansätze des Anwendungsentwickler-Teams in das HMI Kit einfließen und helfen, dieses so für andere Abteilungen zu verbessern. Um mit der Evolutionstheorie zu sprechen: Die GUID fungiert als gemeinsame DNA für verwandte Assets, die auf Grundlage der gleichen Konzeptzelle reproduziert wurden, wie in Abbildung 8 illustriert.

EvolutionFlow-SZ3-DE

Abbildung 8: Auflösung des Dilemmas durch „Concept Tagging“ – einzelne Konzepte und deren zugehörige Code Fragmente werden mit GUIDs ausgestattet, so dass eine spätere Rückverfolgung und Konsolidierung möglich ist.

Fazit

Der HMI Styleguide ist nur eine Komponente innerhalb eines größeren Rahmenwerkes, dem Corporate UX Framework, um zu einer konsistenten HMI Linie zu gelangen. „Top-Down“ kontrolliert und abgenommen, aber „Bottom-Up“ vorangetrieben, werden Nutzeranforderungen kontinuierlich gesammelt und mögliche Lösungskonzepte mit einer eindeutigen ID ausgestattet. Gestaltungsregeln, beispielhafte Code-Schablonen oder sogar gebrauchsfertige HMI Kit Komponenten können dann evolutionär verbessert und über diese ID jederzeit miteinander in Bezug gesetzt und konsolidiert werden. In dieser Kombination erläutern 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.

Dies war Teil zwei des Artikels “HMI Styleguides im Unternehmen etablieren”. Lesen Sie hier Teil eins.

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:

Möchten Sie mehr zu unseren Leistungen, Produkten oder zu unserem UX-Prozess erfahren?
Wir sind gespannt auf Ihre Anfrage.

Corporate Experience Manager
+49 681 959 3110
Kontaktformular

Bitte bestätigen Sie vor dem Versand Ihrer Anfrage über die obige Checkbox, dass wir Sie kontaktieren dürfen.
  • Saarbrücken

    Science Park Saar, Saarbrücken

    Standort Südwest

    Hauptsitz Saarbrücken
    Centigrade GmbH
    Science Park 2
    66123 Saarbrücken
    Deutschland
    Saarland
    Auf der Karte

    +49 681 959 3110

    +49 681 959 3119

  • Mülheim an der Ruhr

    Games Factory Mülheim an der Ruhr

    Standort Nordwest

    Geschäftsstelle Mülheim
    Centigrade GmbH
    Kreuzstraße 1-3
    45468 Mülheim an der Ruhr
    Deutschland
    Nordrhein-Westfalen
    Auf der Karte

    +49 208 883 672 89

    +49 681 959 3119

  • Haar · München

    Haar / München

    Standort Süd

    Geschäftsstelle München
    Centigrade GmbH
    Bahnhofstraße 18
    85540 Haar · München
    Deutschland
    Bayern
    Auf der Karte

    +49 89 20 96 95 94

    +49 681 959 3119

  • Frankfurt am Main

    Frankfurt am Main

    Standort Mitte

    Geschäftsstelle Frankfurt
    Centigrade GmbH
    Kaiserstraße 61
    60329 Frankfurt am Main
    Deutschland
    Hessen
    Auf der Karte

    +49 69 241 827 91

    +49 681 959 3119