Blog

User Interface Design Engineering – eine neue Disziplin mit Zukunft

Thomas Immich
Thomas Immich
14. Dezember 2011

Dieser Artikel wurde inspiriert durch zwei interessante Tage bei der GUI+Design Konferenz am 8. und 9. Dezember in Fürth. Die Konferenz für professionelle User Experience Designer und Entwickler wartete mit Themen rundum Microsoft User Interface Technologien wie WPF und Silverlight auf.

Nicht nur der Artikel selbst entstand spontaner als gewöhnlich – auch eine der Aktivitäten, an der ich während der Konferenz teilnahm, war spontan: Clemens Lutsch, User Experience Manager bei Microsoft Deutschland hat mich gefragt, ob ich bei einem Diskussions-Panel teilnehmen möchte, welches den ersten Konferenztag ausklingen lassen sollte. Ich habe natürlich ja gesagt, denn es ging um ein sehr interessantes Thema: „Begriffe und Rollen – was uns die Arbeit schwer macht“.

Für mich war es eine exzellente Gelegenheit, einen Begriff in die Runde zu werfen, den wir schon vor einigen Monaten bei Centigrade eingeführt haben: „User Interface Design Engineering“, oder kurz: „UI Design Engineering“. Zunächst haben wir den Begriff ausschließlich intern verwendet, haben ihn aber mit der Zeit auch immer häufiger bei unseren Kunden und Partnerunternehmen angebracht und sind dabei auf große Akzeptanz gestoßen. Als ich den Begriff bei dem Diskussions-Panel fallen ließ, habe ich eine ähnliche Akzeptanz vom Publikum und den anderen Diskussionspartnern beobachtet – fast so als würde der Begriff eine Lücke schließen, die bereits eine Weile existiert. Schon am nächsten Konferenztag wurde der Begriff sogar in einer Session direkt wieder aufgegriffen.

Was ist denn nun dieses „UI Design Engineering“?

Für uns ist UI Design Engineering ein fundamentaler Baustein in einem Prozess, der letztendlich zu einem erfolgreichen User Interface führt. Beim UI Design Engineering geht es darum, diejenigen Konzepte zum Leben zu erwecken, die andernfalls in der Kommunikationswüste zwischen Designern und Entwicklern versickern würden (wenn es auch pathetisch klingen mag, passt das Bild sehr gut). Es geht also um all die Dinge, die schneller und präziser umgesetzt sind als sie jemals in Form eines Spezifikationsdokumentes weitervermittelt werden könnten. Der UI Design Engineer wird mit Aufgaben konfrontiert, die u.a. das Erstellen von Mikro-Interaktions-Prototypen, das Storyboarden von Animationen, die Definition von dynamischem Layoutverhalten und die Integration von visuellen Designs in echte Software umfassen.

Traditionelle Bedeutung

Der Unterbegriff „Design Engineering“ ist nicht neu. Er wird geläufig im elektrischen, mechanischen und industriellem Design und sogar im Bauingenieurwesen genutzt. Selbst Wikipedia hat eine umfassende Definition zur Rolle des Design Engineers parat. Wikipedia erwähnt dabei aber mit keinem Wort „Software“ oder gar „User Interfaces“.

Interessanterweise finden sich aber jede Menge Überschneidungen, wenn man die Wikipedia-Definition mit User Interfaces im Hinterkopf liest. Um nur einige zu nennen:

„Der Design Engineer kümmert sich um das gesamte System genauso wie das innere Verhalten eines Designs.“ Dies ist definitiv eine Aussage, die auf das Design eines Softwaresystems und dessen UI angewendet werden kann. Ein UI Design Engineer muss einen Blick auf die Strukturierung und Benennung von Design Assets haben (z.B. Farb oder Fontressourcen) so dass diese sich mit der gesamten System Architektur vereinbaren lassen, muss aber gleichzeitig Wissen über einzelne Details im UI haben (z.B. wie sich der Mouseover Zustand eines Buttons auf Mikro-Ebene verhält).

„Der Design Engineer arbeitet normalerweise in einem Team von Ingenieuren und Designern und entwickelt das konzeptuelle, vorläufige und detaillierte Design der kritischsten Systemteile.“ Betrachtet man die Entwicklung eines User Interface, sollte der UI Design Engineer sowohl mit Interaktionsdesignern und visuellen Designern als auch mit „echten“ Software Engineers während des gesamten UI Entwicklungsprozesses zusammenarbeiten. UI Design Engineers sollten ferner nicht nur bereits in frühen Projektphasen ein Auge darauf haben, ob Konzepte wirklich umsetzbar sind, sie sollten zudem aktiv involviert sein, wenn es darum geht, „kritische Teile des Systems“, in diesem Fall des User Interface, zu implementieren. Hierbei sind dynamische Aspekte des User Interface auch definitiv die kritischsten.

„…Synthese steht für Design Engineers an erster Stelle.“ Dinge zusammenzufügen, die lose „irgendwo“ existieren ist definitiv eine Aufgabe, der sich jeder UI Design Engineer stellen muss. Er/sie muss Dinge implementieren oder integrieren, die andere Personen geplant haben (z.B. Screen Mocks oder Interaktionsparadigmen), so dass diese technisch kompatibel mit allen anderen Dingen sind, die bereits im System existieren.

„Eine weitere Verantwortlichkeit eines Design Engineers ist das Prototyping. Ein Modell eines Produktes wird erschaffen und bewertet.“ Hierzu gibt es eigentlich nicht viel Erklärungsbedarf. Das Modell eines Produktes im UI Kontext ist natürlich ein interaktiver Software Prototyp, der relevante Interaktionsmechanismen greifbar macht. Die Bewertung (und die potenzielle Verfeinerung) des Prototypen sollte ein integraler Bestandteil eines jeden professionellen User Interface Design Prozesses sein.

„Der Design Engineer ist während des gesamten Produkt Lebenszyklus anwesend und führt während dieser gesamten Zeit Änderungen durch. Dies wird auch augenzwinkernd als „von der Wiege bis zur Bahre“ Engineering bezeichnet.“ Software ist niemals fertig und genauso wenig ist es das User Interface. Daher macht es Sinn, dass ein UI Design Engineer den gesamten Prozess von Anfang bis Ende begleitet. Er/sie ist sozusagen das „Design Gedächtnis“, das zu jedem Zeitpunkt sagen können sollte, wann sich bestimmte Designs im System geändert haben und warum – nicht zuletzt deshalb, weil er/sie weiß, wie mit modernen Versionierungs-Tools wie SVN, Git oder TFS umzugehen ist.

Abgrenzung von „User Interface Engineering“

Manchmal fällt im Kontext der UI Entwicklung der Begriff „User Interface Engineering“. Dieser ist nicht zu verwechseln mit „User Interface Design Engineering“. Es gibt zwar einige Gemeinsamkeiten, aber eben auch große Unterschiede. Es folgen einige Punkte in denen sich die beiden Begriffe unterscheiden:
UI Engineers schreiben objekt-orientierten Code (z.B. in C#) während UI Design Engineers deklarativen Code schreiben (z.B. in XAML).

UI Engineers müssen Business Objekte im Detail kennen (z.B. Datenmodelle oder DTOs) und sind verantwortlich dafür Datenbindungen zu etablieren, die die View-Schicht an die Präsentationslogik koppeln.

In dieser Hinsicht müssen UI Engineers auch ein Auge auf Performanz-Aspekte haben: Datenbindungen sind elegant und einfach zu etablieren, können aber einen ausgesprochen negativen Einfluss auf die Gesamtperformanz des Systems haben, was manchmal nur durch ausgiebiges Profiling identifiziert werden kann. Der UI Design Engineer kümmert sich ebenfalls um Performanz – allerdings eher in Bezug auf das visuelle Erscheinungsbild und nicht in Bezug auf die Logik des UIs. Wenn z.B. ein visueller Effekt sowohl durch eine einfache Linie als auch durch einen Pixelshader-basierten Schatteneffekt realisiert werden kann, entscheidet sich der UI Design Engineer eher für erstere Lösung, um auch auf alten Maschinen mit schwächeren Grafikkarten immer noch eine akzeptable Laufzeitperformanz garantieren zu können.

UI Engineers müssen sich Gedanken um Speicherlöcher machen. Da sie objekt-orientierten Code schreiben (und dabei relativ frei Objekte instanziieren oder referenzieren), können sie jederzeit in eine Situation kommen, in der sie potenzielle Speicherlöcher aufreißen (z.B. durch zyklische Objektreferenzen). Für UI Design Engineers ist der Umgang mit Objekten weitaus restriktiver, da sie lediglich die Möglichkeiten der deklarativen Sprache ausschöpfen können und damit jede Menge potenzieller Gefahren vor ihnen versteckt bleibt (z.B. der Umstand, dass UI Elemente immer nur in einer gerichteten 1:n Eltern-Kind-Beziehung existieren können).

Es ist gemeinhin akzeptiert, dass moderne Software-Programmierung auch immer die Produktion von Test Code involviert. Daher müssen UI Engineers immer auch Unit Tests und automatisierte UI Tests implementieren. Im Gegensatz dazu können UI Design Engineers gar keine Test Cases schreiben, da sie nur über die eingeschränkten Mittel der deklarativen Sprache verfügen. Zukünftig kann jedoch immer häufiger der Fall eintreten, dass UI Design Engineers auch UI Interaktionen aufzeichnen und Annahmen („Assertions“) definieren, die dann bei einer späteren Testsession wieder revalidiert werden. Dieser letzte Ansatz setzt natürlich ein leistungsfähiges Authoring-Werkzeug zur Erzeugung solcher Tests voraus – und diese sind zur Zeit schwerlich zu finden.

Um diese kurze Gegenüberstellung in kurzen Worten zusammenzufassen: der UI Engineer ist ein Softwareentwickler während der UI Design Engineer ein Designer mit einigen Softwareentwickler-Fähigkeiten ist.

Welche Skills muss ein UI Design Engineer besitzen?

Um nur ein typisches Talent des Design Engineers zu nennen: die Fähigkeit, ein dynamisches, auflösungsunabhängiges Layoutverhaltens, welches in vielfältigsten Kontexten mit verschiedenen Lokalisierungen und Displaygrößen zurechtkommt zu definieren. Dies erfordert auf der einen Seite ein scharfes Verständnis komplexer logischer Ketten, auf der anderen Seite aber auch die Fähigkeit, gut proportioniertes Layout von schlecht proportioniertem zu unterscheiden und vor allen Dingen diejenigen Spezifikationslücken zu füllen, die der visuelle Designer oder Interaktionsdesigner evtl. hinterlassen hat, da dieser nicht alle Implikationen vorausgesehen hat. Nicht, dass visuelle Designer oder Interaktionsdesigner nicht die Fähigkeiten hätten, solche Situationen zu identifizieren – der Punkt ist, dass sie sie praktisch nicht identifizieren können, da sie nicht an der „echten“ Software arbeiten. Gemeint ist der deklarative Code, der das Design lebendig macht und dabei direktes Feedback und eine greifbare User Experience liefert. Während der direkten Zusammenarbeit zwischen Designern und Entwicklern am gleichen Projekt können grobe konzeptuelle Schnitzer oder unpassende Interaktionsmechanismen daher bereits während der Entwicklung aufgedeckt werden. Natürlich macht dieser Umstand Usability Tests nicht hinfällig, er „schmiert“ aber in jedem Fall den gesamten Entwicklungsprozess.

Neu, aber zeitlos

Der Begriff UI Design Engineering ist relativ neu, aufgrund der Tatsache, dass wir ihn als Konsequenz eines immer noch sehr modernen User Interface Entwicklungs-Ökosystems rundum WPF und Silverlight ins Leben gerufen haben.

Zugegebenermaßen: die Werkzeuge, die im allgemeinen genutzt werden, um diese modernen technischen Möglichkeiten auszunutzen – Expression Blend und Visual Studio – sind bereits seit einiger Zeit verfügbar. Trotzdem existierte niemals eine größere Übereinstimmung darüber, welche Fähigkeiten und Verantwortlichkeiten mit einer Person verknüpft sein müssen, die effektiv mit Expression Blend arbeiten können soll. Eine starke und meiner Meinung nach sehr vorteilhafte Entwicklung ist, dass Expression Blend nicht länger als reines Design Tool betrachtet wird. Es wird endlich als ein Werkzeug betrachtet, dass nur von Designern mit „Spezialkräften“ beherrscht werden kann – Design-Entwickler-Hybride, die in ihrem Denken und Handeln zwischen linker und rechter Gehirnhälfte umschalten können. Oder eben kurz: UI Design Engineers.

Ausblick in die Zukunft

Ich bin der festen Überzeugung, dass es keinen Weg zurück zu einer rigiden Abgrenzung zwischen Entwickler- und Designertätigkeiten. Selbst andere Technologien als WPF und Silverlight werden in Zukunft anhand ihrer Fähigkeit gemessen werden, wie sie Designer und Entwickler zusammenzubringen, nicht bloß lediglich anhand ihrer „harten“ Merkmale wie z.B. Performanz oder Plattformunabhängigkeit. Es ist kein Zufall, dass Nokias neues Qt Quick mit zwei Tools (QML und Qt Creator) aufwartet, die UI Design Engineering Aktivitäten umfassend abdecken. Offensichtlich ist die Kombination aus deklarativer Sprache (XAML oder QML) und einer starken WYSIWIG Umgebung (Expression Blend oder Qt Creator) ein Schlüssel für diese neue Disziplin, mehr als es die eigentliche Syntax der Sprache oder die unterstützte Zielplattform ist.

Vor diesem Hintergrund habe ich die starke Vermutung, dass die Idee, die wir mit der Bezeichnung „UI Design Engineering“ beschreiben, von Dauer ist und dass der Begriff über die Technologien hinausgeht, die ihn bei Centigrade ursprünglich hervorgerufen haben. In jedem Fall, finde ich es sehr schön zu beobachten, dass beide Disziplinen – traditionelles Software Engineering und traditionelles User Interface Design – in Zukunft weiterhin näher zueinanderrücken werden. Und UI Design Engineering wird dabei die Verbindung sein, die die beiden Disziplinen auf Dauer zusammenhält.


Alle genannten Marken oder eingetragene Marken sind Eigentum der jeweiligen Markeninhaber.

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

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