Gerade in der UX Branche entstehen oft neue Fachbereiche. Fachbereiche, bei denen Mitarbeiter mit verschiedenen Skills notwendig sind und als Schnittstelle zu anderen Fachbereichen ihre Stärken voll auspielen können. „Hybride“, Menschen die zwei oder ggf. sogar mehrere Dinge können oder sich zumindest für mehrere interessieren. Designer die programmieren können, Autoren die designen können, Analysten die programmieren können.
Man könnte jetzt meinen, welches Unternehmen möchte so unentschlossene Mitarbeiter haben oder diese sogar fördern. Ganz schnell werden sie als „die können alles, aber nichts richtig“, abgestempelt. Die Vorteile sind jedoch nicht von der Hand zu weisen: Hybride sind großartig an Schnittstellen oder in kleinen Projektteams, wo jeder mehrere Aufgaben übernehmen muss. Gleichzeitig können Hybride aber auch extrem anstrengend sein, da sie durch Ihr Wissen aus verschiedenen Themengebieten in jedem Fachbereich „Schwächen und Probleme“ aufdecken und damit allen unglaublich auf die Nerven gehen können.
Während sich die Konzepter beispielsweise noch mit User Needs, Personas und Szenarios beschäftigen und die Entwicklung noch gar nicht im Boot ist, macht ein Designer mit Coding-Background sich schon Gedanken darum, wie das Ganze letztendlich umgesetzt werden kann und schmeißt den Konzeptern schon Steine in den Weg, bevor sie überhaupt loslaufen können. „Wie wird das denn mit dem Keyboard bedient?“, „Die Animationen werden aber nervig in der Umsetzung“, „Die Tabellencontrol funktioniert in anderen Kontexten nicht, wir müssen modularer denken“ etc.
Ein Entwickler mit Design Background fährt in der Entwicklung vielleicht dem Designer in die Parade. Während der Designer sich individuelle Farbsemantiken für Zustände und einzelne Bereiche ausdenkt, versucht der Code-Design-Hybrid sämtliche Designprobleme mit SCSS Mixins zu lösen. Gleichzeitig versucht er, dem Designer zu erklären, warum zu viel Individualität die Wartbarkeit des Codes erschwert, anstatt eine gute Lösung zu finden das Design möglichst pixelgetreu umzusetzen.
Fluch und Segen
Hybriden können dazu neigen, überall mitreden zu wollen. Und da es einfacher ist Probleme zu finden als sie zu lösen, neigen sie auch dazu allen Fachbereichen Probleme zu „machen“.
Wiederum gern gesehen, zumindest aus Unternehmersicht, sind Hybride, die nicht nur überall Probleme sehen, sondern diese Probleme auch lösen können. Denn auch wenn sie eben keine „Specialists“ sind und bei tiefgreifenden Problemen länger brauchen, können Sie vor allem schnell oberflächliche Probleme direkt selbst lösen und in Kommunikation und Ablauf zwischen den einzelnen Fachbereichen unterstützen. Besonders wenn es um Themen der Spezifikation geht, wie z. B. Dokumentation, Styleguides, UI-Kits oder ganzen Design Systemen. Ein Designer, der sich in Entwickler hineinversetzen kann, wird es jedenfalls einfacher haben die Sprache der Entwickler zu verstehen.
Der Alltag eines Hybriden
Aus Entwicklersicht versuchen wir immer Designs so pixelgenau wie möglich umzusetzen. Gleichzeitig wollen wir aber auch Designer möglichst wenig kreativ einschränken (zumindest in den Anfangsphasen eines Projektes). Das führt oft dazu, dass z.B. Abstände, Schriftgrößen, Farben etc. innerhalb eines Screens sinnvoll genutzt werden, aber innerhalb des CSS-Frameworks (wie z. B. Bootstrap) das Ganze Probleme verursacht. Während der Designer Abstände und Größen immer „frei“ wählen kann, macht es in Bootstrap mehr Sinn mit den vorgegebenen Klassen zu arbeiten. Während ein aufmerksamer Entwickler vermutlich eigene Klassen anlegen würde, um mit Bootstrap das Design möglichst pixelgetreu abzubilden, kann der Entwickler mit Design-Background entsprechend das Designs „ableiten“ um konsistent mit den Gegebenheiten des Frameworks alles trotzdem abbilden zu können. Auch wenn hier und da nicht mehr alles 100 % pixelgenau ist, sollte es konsistent bleiben. Letztendlich ist wartbarer und schnell produzierter Code genauso wichtig wie gutes Design.
Mir als Designer, der ein wenig Coding-Background hat, fallen mir Inkonsistenzen in meinen eigenen Designs schnell auf. Tools wie Sketch oder Figma helfen dabei ungemein möglichst „modular“ zu arbeiten. Mit Symbolen und Styles können flexible und wiederverwendbare „Komponenten“ erstellt werden, die den Arbeitsablauf deutlich beschleunigen und das Design konsistenter machen.
Auch Wireframes müssen nicht zwangsweise ein festes Layout vorgeben oder genaue Komponenten. Solange Interaktionsmöglichkeiten ersichtlich sind, kann sich ein Designer mit einem guten Verständnis von User Experience, Standards und Interaktionsdesign kreativ austoben und wird zu einem guten Ergebnis kommen, auch ohne besonders detaillierte Wireframes als Basis zu nutzen.
Anwenden von Framework Standards setzen auch eine gewisse Entwicklernähe voraus. Wenn ich z. B. zu Beginn des Projektes weiß, mit welchem Framework die letztendliche Front-End-Entwicklung durchgeführt wird, habe ich als Designer direkt eine Dokumentation der verfügbaren UI-Komponenten. Ich muss mir als Designer eben nicht „alles“ selber ausdenken, sondern kann mich auf die Standards des Frameworks beziehen. Scrollt das Kalenderwidget oder blättere ich durch die Monate? Filtert das Standardgrid im Header der Tabelle oder außerhalb der Tabelle? Werden Spalten über ein dediziertes Menu ein-/ ausgeblendet oder wird ein Kontextmenu o. Ä. benutzt.
Das heißt natürlich nicht im Umkehrschluss, dass es keine Customization geben darf und alles nur noch „Standard“ ist, aber viele Designentscheidungen sind leider nicht wichtig genug, um einen Haufen von Customcontrols oder hohe Entwicklungsaufwände zu rechtfertigen.
Durch die Arbeit mit verschiedenen Front-End-Frameworks geht mir das Schreiben von Dokumentationen (Patternguides, Styleguides, UI-Kits etc.) auch deutlich leichter von der Hand. Gerade in den heißen Phasen wo möglichst schnell geliefert werden muss, weiß ich, dass Entwickler z. B. keine „ausgereifte“ Button Dokumentation brauchen. Sätze wie „Buttons are used to trigger actions” oder “The Buttons provide a clickable UI functionality with arbitrary content.” sind an dieser Stelle nicht zielführend. Front-End-Entwickler wissen in der Regel was ein Button oder Dropdown ist und wofür es benutzt wird. Wichtiger ist dann z. B. die Unterscheidung zwischen Links (Navigation) und Buttons (Aktion), also die „impliziteren“ Verhaltensregeln der Controls, als deren funktionale Beschreibung.
Fazit
Die Welt braucht Hybriden! UI-Entwicklung ist an sich schon ein sehr spezieller Bereich, da hilft es ungemein ein paar Mitarbeiter zu haben, die sich nicht noch weiter spezialisieren.
Klar die Welt braucht weiterhin Experten in eigenen Bereichen. Kaum ein Entwickler wird Interesse daran haben eine Kernkompetenz in Typographie und Nutzerinterviews aufzubauen, aber Entwickler mit einem gewissen Maß an Sympathie für den Nutzer helfen ungemein.
Wir (Designer) denken mittlerweile immer an Nutzer, aber wir vergessen dabei gerne, dass wir nicht nur für die Endbenutzer arbeiten, die hinterher das Produkt sehen, sondern das dazwischen noch ein kompletter Fachbereich sitzt, der die Designs erstmal programmieren muss. Ich plädiere also dafür, dass Designer auch Entwickler als relevanten Nutzergruppe ansehen und nicht nur einfordern, dass sie mit ihrer Codingmagie die Designvision umsetzen.
