![\"Grafik,](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/05\/202105_UI-Dev-Session_Teil1_1-600x268.png\")
Mit fortgeschrittener Projektlaufzeit sammeln sich kleine Abweichungen vom Styleguide, die das Gesamtbild schnell tr\u00fcgen. Weitere klassische Beispiele f\u00fcr solche UI-Fehler sind: <\/p>\n\n\n\n
- Fehlende Zust\u00e4nde von UI-Elementen (Hover, Focused, \u2026) <\/li>
- Falsche Verwendung von Schriftgr\u00f6\u00dfen, Schriftschnitten und Schriftfarben <\/li>
- Falsche Verwendung von Graustufen f\u00fcr Fl\u00e4chen, Umrandungen oder Trennlinien <\/li>
- Falsche Abst\u00e4nde und Positionierungen von UI-Elementen <\/li><\/ul>\n\n\n\n
Zwar k\u00f6nnen solche Abweichungen meist schnell behoben werden, aber h\u00e4ufig sorgen umfangreiche Erstellungs- und Abnahmeprozesse f\u00fcr einen unverh\u00e4ltnism\u00e4\u00dfig gro\u00dfen Aufwand bei solchen vergleichsweise kleinen Anpassungen. Kommt es zus\u00e4tzlich zu Missverst\u00e4ndnissen oder Missinterpretationen der Designvorgaben und werden dabei mehrere Feedback-Schleifen ben\u00f6tigt, ist das f\u00fcr alle Beteiligten eine negative Erfahrung. <\/p>\n\n\n\n
Um solche kleinen UI-Fehler effektiver und effizienter zu beheben und das Produkt damit st\u00fcckweise zu verbessern und dem Styleguide anzupassen, haben wir im Team eine unkomplizierte Form der Kollaboration geschaffen und etabliert.<\/p>\n\n\n\n
<\/div>\n\n\n\nPair Programming mit Spezialistinnen und Spezialisten f\u00fcr UI\/UX<\/strong> <\/strong> <\/h2>\n\n\n\n
Das Pair Programming wird innerhalb des Entwicklungsteams unseres Projektes schon l\u00e4ngst erfolgreich genutzt. Es f\u00f6rdert die Zusammenarbeit und die Qualit\u00e4t des Codes durch das Vier-Augen-Prinzip. Dabei arbeiten zwei Personen aus dem Entwicklungsteam gleichzeitig und direkt am Programmcode. Durch Diskussion, Kritik und das Einbringen neuer Ideen sollen hochwertiger Code erzeugt und Entwicklungszeit eingespart werden. <\/p>\n\n\n\n
Dieses Prinzip haben wir uns im Projekt zunutze gemacht und den Kreis der Teilnehmenden um Spezialistinnen und Spezialisten f\u00fcr UI\/UX erweitert, um den Entwicklerinnen und Entwicklern direktes Feedback auf ihre Anpassungen am User Interface geben zu k\u00f6nnen. Die Anforderungen und \u00c4nderungsw\u00fcnsche an das User Interface werden durch die Expertinnen und Experten f\u00fcr UI\/UX so direkt im Termin kommuniziert und die \u00c4nderungen gepr\u00fcft, statt sie im Backlog zu dokumentieren und darauf zu warten, dass sie irgendwann korrekt umgesetzt werden. Zu den in UI\/UX spezialisierten Personen geh\u00f6ren die Verantwortlichen f\u00fcr die Vorgaben an das User Interface, welche ma\u00dfgeblich an der Entwicklung des Figma-UI-Designs beteiligt sind. <\/p>\n\n\n\n
Dem regelm\u00e4\u00dfigen Austausch in diesem Kreis haben wir den Namen UI-Dev-Session oder kurz einfach nur Dev-Session gegeben. Das Ganze funktioniert sehr gut auch dezentral im mobilen Arbeiten, denn dank Microsoft Teams und seiner Screen-Sharing-Funktion sehen alle teilnehmenden Personen gleichzeitig die \u00c4nderungen am Code und dem User Interface. <\/p>\n\n\n\n
Um einen Rahmen f\u00fcr das Pair Programming zu schaffen, haben wir daf\u00fcr folgende \u201eSpielregeln\u201c aufgestellt: <\/p>\n\n\n\n
- Es nehmen sowohl Personen aus dem Bereich Entwicklung als auch aus dem Bereich UI\/UX teil. Insgesamt besteht die Gruppe aus zwei bis maximal vier Personen. Gemeinsam wird fokussiert nach der L\u00f6sung f\u00fcr konkrete UI-Fehler gesucht und live am Code programmiert. <\/li><\/ol>\n\n\n\n
- Eine UI-Dev-Session hat von vornherein keinen vordefinierten Umfang. Vielmehr werden die erreichten Ziele durch die zur Verf\u00fcgung stehende Zeit beschr\u00e4nkt. <\/li><\/ol>\n\n\n\n
- Je nach Erfordernis des Projektes soll eine UI-Dev-Session in regelm\u00e4\u00dfigen Abst\u00e4nden stattfinden und einen klaren zeitlichen Rahmen umfassen. Zum Beispiel k\u00f6nnen 2-3 Stunden je Sprint, Woche oder Monat f\u00fcr eine UI-Dev-Session vorgehalten werden. Damit soll der zeitliche Aufwand zur L\u00f6sung von UI-Fehlern verh\u00e4ltnism\u00e4\u00dfig und gleichbleibend sein. <\/li><\/ol>\n\n\n\n
- M\u00f6gliche Themen werden in einer Liste von den Spezialistinnen und Spezialisten f\u00fcr UI\/UX gepflegt und iterativ in mehreren UI-Dev-Sessions abgearbeitet. Die Grundlage daf\u00fcr sind z. B. Abweichungen zwischen Implementierung und Styleguide oder das Feedback aus Usability-Tests. <\/li><\/ol>\n\n\n\n
- Das Entwicklungsteam kann Themen aus der Liste frei w\u00e4hlen und ggf. vorab aufbereiten. Dies soll dazu beitragen, dass m\u00f6glichst viele Themen in kurzer Zeit gel\u00f6st werden. Sofern erforderlich, kann dennoch eine Priorisierung der Themen nach gr\u00f6\u00dftm\u00f6glichem Nutzen erfolgen, damit insbesondere bei engen Zeitrahmen die wichtigsten Themen zuerst gel\u00f6st werden. <\/li><\/ol>\n\n\n\n
- Die Aktivit\u00e4ten an unerwartet aufw\u00e4ndigen Themen, deren Live-Implementierung den zeitlichen Rahmen einer UI-Dev-Session sprengen, werden nach Einvernehmen der teilnehmenden Personen gestoppt und in anderweitige Backlog Items (z. B. User Stories oder Spikes) ausgelagert und sp\u00e4ter bearbeitet. <\/li><\/ol>\n\n\n\n
Die bearbeiteten und gel\u00f6sten UI-Fehler sollten im Nachgang der UI-Dev-Session dokumentiert und dem Projektteam zug\u00e4nglich gemacht werden. So kann im Nachhinein jedes Projektmitglied nachvollziehen, was f\u00fcr \u00c4nderungen in welcher UI-Dev-Session vorgenommen wurden. Au\u00dferdem bietet es sich im Sprint-Review an, dem gesamten Projektteam die bearbeiteten Themen kurz vorzustellen. <\/p>\n\n\n\n
![\"Beispiel](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2021\/05\/202105_UI-Dev-Session_Teil1_2-600x139.png\")
Abbildung 2: Beispiel f\u00fcr Abweichungen von der Implementierung (links)<\/em>
und f\u00fcr Styleguide-konformes Figma-Design (rechts)<\/em><\/figcaption><\/figure>\n\n\n\n
- Die Aktivit\u00e4ten an unerwartet aufw\u00e4ndigen Themen, deren Live-Implementierung den zeitlichen Rahmen einer UI-Dev-Session sprengen, werden nach Einvernehmen der teilnehmenden Personen gestoppt und in anderweitige Backlog Items (z. B. User Stories oder Spikes) ausgelagert und sp\u00e4ter bearbeitet. <\/li><\/ol>\n\n\n\n
- Das Entwicklungsteam kann Themen aus der Liste frei w\u00e4hlen und ggf. vorab aufbereiten. Dies soll dazu beitragen, dass m\u00f6glichst viele Themen in kurzer Zeit gel\u00f6st werden. Sofern erforderlich, kann dennoch eine Priorisierung der Themen nach gr\u00f6\u00dftm\u00f6glichem Nutzen erfolgen, damit insbesondere bei engen Zeitrahmen die wichtigsten Themen zuerst gel\u00f6st werden. <\/li><\/ol>\n\n\n\n
- M\u00f6gliche Themen werden in einer Liste von den Spezialistinnen und Spezialisten f\u00fcr UI\/UX gepflegt und iterativ in mehreren UI-Dev-Sessions abgearbeitet. Die Grundlage daf\u00fcr sind z. B. Abweichungen zwischen Implementierung und Styleguide oder das Feedback aus Usability-Tests. <\/li><\/ol>\n\n\n\n
- Je nach Erfordernis des Projektes soll eine UI-Dev-Session in regelm\u00e4\u00dfigen Abst\u00e4nden stattfinden und einen klaren zeitlichen Rahmen umfassen. Zum Beispiel k\u00f6nnen 2-3 Stunden je Sprint, Woche oder Monat f\u00fcr eine UI-Dev-Session vorgehalten werden. Damit soll der zeitliche Aufwand zur L\u00f6sung von UI-Fehlern verh\u00e4ltnism\u00e4\u00dfig und gleichbleibend sein. <\/li><\/ol>\n\n\n\n
- Eine UI-Dev-Session hat von vornherein keinen vordefinierten Umfang. Vielmehr werden die erreichten Ziele durch die zur Verf\u00fcgung stehende Zeit beschr\u00e4nkt. <\/li><\/ol>\n\n\n\n
- Es nehmen sowohl Personen aus dem Bereich Entwicklung als auch aus dem Bereich UI\/UX teil. Insgesamt besteht die Gruppe aus zwei bis maximal vier Personen. Gemeinsam wird fokussiert nach der L\u00f6sung f\u00fcr konkrete UI-Fehler gesucht und live am Code programmiert. <\/li><\/ol>\n\n\n\n