Video Report

Was ist ETAS?

Die ETAS GmbH entwickelt und vertreibt Produkte und Lösungen für die Entwicklung und den Betrieb von Softwareplattformen für die Automobilindustrie. Dazu gehören Basissoftware, Mess- und Kalibrierlösungen sowie Middleware und Lösungen für Diagnose, Cybersecurity und Softwareplattformen. Als Pionier im Bereich Open Source ist ETAS Gründungsmitglied der Eclipse SDV Working Group, Initiator des S-CORE-Projekts und damit treibende Kraft hinter dem ersten sicherheitszertifizierbaren, offenen Software-Middleware-Stack. (Auszug aus ETAS.com)

ETAS wurde 1994 als Tochtergesellschaft von Bosch gegründet und beschäftigt heute rund 2.700 Mitarbeitende an 39 Standorten weltweit. Im Jahr 2025 erzielte das Unternehmen einen Umsatz von 542 Millionen Euro. (Zusammenfassung der Daten von ETAS.com)

Was macht mein Team?

Mein Team, das ETAS Cloud Enablement Team, bietet Cloud-Unterstützung für interne und externe Kunden an. Das Kernprodukt ist eine Cloud-Service-Plattform namens Cloud Hub, die es internen Kunden ermöglicht, ihre Produkte vollständig oder teilweise in der Cloud zu betreiben. Externe Kunden können über eine Service-Übersichtsseite spezifische Dienste abonnieren und diese über einen persönlichen Workspace verwalten. Meine Hauptaufgabe bestand darin, die User Experience der Cloud Hub Plattform zu optimieren und weiterzuentwickeln. Darüber hinaus unterstützte unser Team auch andere Abteilungen – darunter Bosch – mit Designleistungen, etwa bei der Verbesserung bestehender Produkte und der Begleitung innovativer Produktentwicklungen.

Das Team setzt sich zusammen aus einem administrativen Lead (zuständig für Budgetplanung, Ressourcenkoordination und Leistungsbeurteilung), einem Product Owner (verantwortlich für die Abstimmung mit externen Teams und Kunden, die Filterung und Priorisierung eingehender Anforderungen sowie die Leitung von Planungs- und Aufgabenmeetings – ohne tiefe Einbindung in die konkrete Produktdefinition), einem Entwicklungsteam (für laufende Wartung, Frontend- und Backend-Entwicklung sowie technischen Support) sowie einem UX-Team (für User Research, UI-Design und Handoff).

Wie sehen die Arbeitsprozesse aus?

Sprint

Die zentrale Arbeitsweise des Teams basiert auf Sprints – zweiwöchigen Zyklen aus Planung, Umsetzung und Retrospektive. Zu Beginn jedes Sprints findet ein gemeinsames Meeting statt, in dem zunächst die Teamzusammensetzung für den jeweiligen Zeitraum geklärt wird – wer arbeitet, wer ist im Urlaub. Anschließend stellt jede Person ihre geplanten Aufgaben für die kommenden zwei Wochen vor. In der Regel liegt die Entscheidung darüber vollständig bei den Mitarbeitenden selbst, gelegentlich vergibt der Product Owner jedoch auch konkrete Aufgaben. Der Großteil des Sprints ist der Umsetzung gewidmet: Montags, mittwochs und freitags finden Stand-up-Meetings statt, in denen kurz der Arbeitsfortschritt berichtet und bei Bedarf Unterstützung eingeholt werden kann. Am Ende jedes Meetings gibt es eine Pull-Request-Runde, die sich hauptsächlich an die Entwickler richtet und dem gegenseitigen Review von Code dient. Am letzten Tag eines Sprints findet erneut ein gemeinsames Meeting zur Retrospektive statt. Im Idealfall wurden alle geplanten Aufgaben abgeschlossen – es kann jedoch auch vorkommen, dass bestimmte Tickets auf Schwierigkeiten gestoßen sind, der Arbeitsaufwand falsch eingeschätzt wurde oder ein Thema in den nächsten Sprint übertragen werden muss. Abschließend gibt es eine kurze Reflexionsrunde, in der das Team bespricht, was gut gelaufen ist, welche Probleme aufgetreten sind und was daraus gelernt wurde.

Ticketing System

Planungs- und Retrospektivemeetings sowie konkrete Arbeitsaufgaben werden in Form von Tickets auf GitHub dokumentiert und mithilfe von Labels kategorisiert, um eine spätere Nachverfolgung und Aktualisierung zu erleichtern. Für Arbeitstickets wird dabei festgehalten, wer für das jeweilige Ticket verantwortlich ist, ob es sich um ein übergeordnetes Parent-Ticket, ein Sub-Ticket oder ein eigenständiges Ticket handelt, welchem Sprint es zugeordnet ist und welchen Bearbeitungsstatus es aktuell hat – etwa „New Defined„, „In Progress“, „Pending„, „Blocked“, „In Review„, „Done for Sprint Review“ oder „Ready to Develop„.

In der Regel setze ich den Status eines Tickets auf „In Progress“, sobald ich mit der Bearbeitung beginne. Nach Abschluss des Designs dokumentiere ich das Ergebnis ausführlich als Kommentar im entsprechenden Ticket und wende mich an einen Entwickler, um die technische Umsetzbarkeit meines Konzepts prüfen zu lassen – zu diesem Zeitpunkt wird der Status auf „In Review„ gesetzt. Sämtliche Diskussionen finden im Kommentarbereich des jeweiligen Tickets statt. Wenn die zu besprechenden Punkte besonders komplex oder umfangreich sind, werden gelegentlich separate Meetings angesetzt; die Ergebnisse werden jedoch stets als Kommentar im Ticket archiviert. Sobald nach mehreren Review-Runden ein finales Konzept feststeht, wird der Ticketstatus auf „Done for Sprint Review“ gesetzt. Im Sprint-Retrospektivemeeting wird das Ergebnis kurz zusammengefasst, der Status auf „Done„ geändert und das Ticket geschlossen – oder es wird zur späteren Entwicklung an das Dev-Team übergeben. In seltenen Fällen, wenn der Product Owner das Ergebnis nicht als lieferfähig einstuft, wird der Status auf „In Progress“ zurückgesetzt.

In der Regel setze ich den Status eines Tickets auf „In Progress„, sobald ich mit der Bearbeitung beginne. Nach Abschluss des Designs dokumentiere ich das Ergebnis ausführlich als Kommentar im entsprechenden Ticket und wende mich an einen Entwickler, um die technische Umsetzbarkeit meines Konzepts prüfen zu lassen – zu diesem Zeitpunkt wird der Status auf „In Review“ gesetzt. Sämtliche Diskussionen finden im Kommentarbereich des jeweiligen Tickets statt. Wenn die zu besprechenden Punkte besonders komplex oder umfangreich sind, werden gelegentlich separate Meetings einberufen; die Ergebnisse werden jedoch stets als Kommentar im Ticket archiviert. Sobald nach mehreren Review-Runden ein finales Konzept feststeht, wird der Ticketstatus auf „Done for Sprint Review„ gesetzt. Im Sprint-Retrospektivemeeting wird das Ergebnis kurz zusammengefasst, der Status auf „Done“ geändert und das Ticket geschlossen – oder es wird zur späteren Entwicklung an das Dev-Team übergeben. In seltenen Fällen, wenn der Product Owner das Ergebnis nicht als lieferfähig einstuft, wird der Status auf „In Progress„ zurückgesetzt.

Quartalplanung

Zu Beginn eines jeden Quartals findet ein Quartalplanungsmeeting statt, in dem die Ziele und Schwerpunkte für die kommenden Monate definiert werden. Der Product Owner bringt dabei Themen ein, die sich aus neu eingegangenen externen Anforderungen sowie aus seiner eigenen Produktanalyse ergeben, und diskutiert diese gemeinsam mit dem Team. Anschließend folgt eine offene Planungsrunde, in der sowohl das Entwicklungsteam als auch das UX-Team eigene Arbeitsthemen vorschlagen können. Abschließend trägt jede Person ihre geplanten Aufgaben – aufgeteilt nach Sprint-Einheiten – in eine individuelle Quartalsplanung ein, die im Anschluss unter der Leitung des Product Owners gemeinsam abgestimmt und finalisiert wird. Da innerhalb des UX-Teams häufig enge Zusammenarbeit erforderlich ist, erstrecken sich manche Arbeitspakete über mehrere Teammitglieder.

Hybrides Arbeiten

Im Team ist der Mittwoch als fester Präsenztag vorgesehen, an dem grundsätzlich alle Mitglieder ins Büro kommen – er ist entsprechend der belebteste Tag der Woche. An den übrigen Tagen besteht die Möglichkeit, remote zu arbeiten. Einige Teammitglieder wohnen jedoch nicht in Stuttgart, sondern in anderen Städten wie Berlin oder arbeiten von Indien aus – sie sind daher auch mittwochs nicht vor Ort. Generell bevorzugt ein Großteil des Teams das Arbeiten von zu Hause. Lediglich mein Mentor Philipp und ich schätzten die Präsenzarbeit – so saßen wir über einen langen Zeitraum mit dem Rücken zueinander im Büro. Als er im letzten Drittel des Praktikums eine längere Auszeit für eine Wanderung antrat, war ich häufig allein im Büro. Meine andere Mentorin Carmen, die ebenfalls als UX-Praktikantin tätige Sarah sowie Danilo, der sein Pre-Master-Programm absolvierte, kamen in der Regel zwei- bis dreimal pro Woche ins Büro. An den Tagen, an denen wir gemeinsam vor Ort waren, tauschten wir uns spontan über fachliche Fragen aus, führten kurze Sparring-Gespräche, plauderten gelegentlich oder holten gemeinsam einen Kaffee, Tee oder ein Glas Wasser – und aßen zusammen in der Kantine. Manchmal spielten wir in den Pausen auch Tischkicker oder Tischtennis; Schach wurde zwar ebenfalls gespielt, doch da ich es nicht beherrsche, schaute ich dabei nur gelegentlich zu.

Für mich bedeutete die Präsenzarbeit einerseits direkteren Austausch und eine lebendigere Arbeitsatmosphäre, die meine Konzentration positiv beeinflusste – im Gegensatz dazu fühlte ich mich beim alleinigen Arbeiten manchmal wie eine Maschine, die ausschließlich auf den Bildschirm starrt. Im abschließenden Praktikumsgespräch sprach ich diesen Aspekt auch an: Ich wünsche mir eine Arbeitsumgebung mit einer aktiven Präsenzkultur, in der man gemeinsam mit Kolleginnen und Kollegen „sprintet“ - aber in diesem Praktikum verspürte ich manchmal ein Gefühl der Einsamkeit. Andererseits bot das Büro eine deutlich bessere Arbeitsausstattung: mehrere Bildschirme, höhenverstellbare Tische, ergonomische Stühle sowie mehr Platz und gute Lichtverhältnisse – all das trug zu einer konzentrierten und effizienten Arbeitsweise bei.

Für die Arbeit selbst gilt allerdings, dass sich die meisten Aufgaben – Problemanalyse, Konzeption, Prototyping und UI-Gestaltung – prinzipiell mit einem einzigen Laptop erledigen lassen und dass Remote-Abstimmungen für den Arbeitsfortschritt in der Regel ausreichend sind. Dazu wurden nahezu alle Interviews online durchgeführt, was durch den internationalen Kontext und die inzwischen etablierte Praxis von Online-Meetings bedingt war. Insgesamt ist Remote-Arbeit grundsätzlich gut möglich.

Was habe ich gemacht?

Einerseits analysierte und optimierte ich den bestehenden UX-Workflow des Teams und aktualisierte auf Basis vorhandener User-Research-Daten die produktbezogenen Personas und Journey Maps. Andererseits lag ein Schwerpunkt meiner Arbeit auf der Verbesserung der Browse-Erfahrung auf cloudhub.etas.com – darunter die Navigation sowie das Browsen verschiedener Unterseiten und die plattformübergreifende Navigationserfahrung innerhalb bestimmter User Journeys. Darüber hinaus bearbeitete ich verschiedene UI-Probleme im Zusammenhang mit der Cloud-Bereitstellung, die sich an Produktteams richten – etwa Themen rund um Feedback-Mechanismen sowie neue Funktionen. In den letzten zwei Monaten des Praktikums war ich außerdem an zwei innovativen Projekten anderer Abteilungen beteiligt, bei denen ich durch Stakeholder Management, Konzeption und Prototyping die jeweiligen Teams dabei unterstützte, ihre Produktideen im abschließenden Pitch vor dem Board zu präsentieren.

UX Workflow Improvement und Personas & Journey Maps Update

Problembeschreibung

Zu Beginn meines Praktikums stellte ich fest, dass der UX-Workflow des Teams einige Schwachstellen aufwies: Research-Ergebnisse waren an verschiedenen Stellen verstreut, nicht systematisch archiviert und ohne Zeitstempel versehen. Zudem fehlte es an einer tiefergehenden Auseinandersetzung mit den Motiven hinter den von Nutzern geäußerten Problemen. Identifizierte Probleme wurden nicht priorisiert – die Entscheidung, welche Themen vorrangig angegangen werden sollten, basierte häufig auf Bauchgefühl, was dazu führen konnte, dass dringendere Probleme übersehen oder aufgeschoben wurden. Die Persona-Daten waren seit Längerem nicht aktualisiert worden und enthielten kaum handlungsleitende Informationen wie etwa Prioritäten. Schließlich fehlten für bestimmte Designentscheidungen auch grundlegende User-Journey-Daten.

Ergebnis

Auf dieser Grundlage entwickelte ich ein Konzept zur Optimierung des gesamten UX-Workflows – darunter, welche Research-Daten wie und wo erfasst und archiviert werden sollten, welche Art von Research in welcher Projektphase benötigt wird sowie wie der Prozess der Design-Iteration nachvollziehbar dokumentiert werden kann.

Browserfahrung auf Cloudhub.etas.com und Navigation über zusammenhängende Plattformen

Problembeschreibung

Die bestehende Website cloudhub.etas.com verfügte über keine echte Landing Page – es fehlte eine Seite, die Besuchende schrittweise durch die Inhalte der Plattform führt. Für bestimmte User Journeys fehlten unterstützende UI-Elemente. Die Navigation zu verschiedenen Seiten und Inhalten war an einer einzigen Stelle gebündelt, der Navigationsbutton war schwer zu erkennen – was dazu führte, dass Nutzende ihn nur schwer auffinden konnten, sich von der Informationsfülle überfordert fühlten oder in bestimmten Situationen nicht wussten, wo sie die relevante Navigation finden sollten. Darüber hinaus mangelte es den Unterseiten an gestalterischer Konsistenz; Inhalte waren teils schwer lesbar oder wenig aussagekräftig.

Ergebnis

Ich entwickelte ein übergreifendes Konzept für die User Journey und die Narrativ der Website, optimierte die Informationsarchitektur, erstellte eine neue Landing Page, überarbeitete bestehende Unterseiten und gestaltete die Top-Navigation plattformübergreifend.

Weitere UX-Probleme

Problembeschreibung

Zu den weiteren identifizierten UX-Problemen zählten unter anderem unbekannte Begriffe auf der Tabelle, mangelnde Erklärungen bzw. Hinweise für deaktivierte Zustände, fehlende Rückmeldungen zu Nutzeraktionen und deren Ergebnissen sowie das Fehlen einer Funktion zur Archivierung und zum Abruf von Build-Logs.

Ergebnis

Innovative Projekte

Beide Innovationsprojekte befinden sich in der Konzeptvalidierungsphase und zielen darauf ab, dem Board des Unternehmens im Rahmen eines Pitches vorgestellt zu werden, um Zustimmung und weitere Unterstützung zu erhalten. Das UI-Design dient dabei als visuelle Referenz zur Unterstützung der Konzeptkommunikation. Als Design Support haben mein Teammitglied und ich die internen Kunden durch kontinuierliche Diskussion und iterative Zusammenarbeit dabei unterstützt, ihre Innovationskonzepte weiterzuentwickeln – einschließlich der Ausarbeitung von Funktionsumfang und Story Line, der Festlegung von Entwicklungsprioritäten sowie der Definition von User Flows, Interaktionskonzepten und Interface-Konzepten.

Aus Datenschutzgründen zeige ich die beiden Projekte nicht.

Was habe ich gelernt?

Von der Problemerkennung zur Abgrenzung

Ich habe gelernt, UX-Probleme systematischer zu betrachten und konkrete Handlungsfelder zu identifizieren – etwa im Hinblick auf narrative Struktur, Navigation, visuelle Verständlichkeit, gestalterische Konsistenz und Responsiveness.

Mir ist außerdem bewusster geworden, dass es situationsabhängig ist, wie weit man denken muss: In manchen Fällen ist es wichtig, Abhängigkeiten frühzeitig zu erkennen und den Scope sorgfältig zu definieren, um spätere Überarbeitungen zu vermeiden. In anderen Situationen hingegen ist es sinnvoller, sich zu fokussieren und nicht unnötig zu verkomplizieren – etwa indem man sich fragt: Was ist das Ziel des Projekts? Was sind die Anforderungen und Erwartungen der Stakeholder? Welche Werkzeuge helfen dabei, konkrete Aufgaben zu definieren? Nach jedem Abstimmungsgespräch empfiehlt es sich zudem, meine Notizen mit den Beteiligten abzugleichen, um sicherzustellen, dass alle dasselbe Verständnis haben.

Im Rahmen des Sprint-basierten Projektmanagements habe ich gelernt, wie wichtig klar beschriebene, möglichst kleinschrittige Tickets sind – für den Product Owner im Hinblick auf Aufwandsschätzung und Arbeitsplanung, für die Entwickler im Hinblick auf eine handhabbare Arbeitslast.

Von „ich kann es„ zu „ich liefere es zuverlässig“

Ich kann heute sicher mit Figma arbeiten, Atomic Design und Responsive Design anwenden, Interaktivität berücksichtigen und das bestehende Designsystem nutzen, um Design-Assets und konkrete Seiten zu gestalten und zu verwalten. Das gewährleistet einerseits die Konsistenz und Skalierbarkeit meiner Designs und ermöglicht effiziente Anpassungen. Andererseits erleichtert es den Handoff-Prozess erheblich, da alle Designelemente als Komponenten erstellt und parametrisiert sind – Entwickler können sie abrufen und weiterverwenden.

Bei der Gestaltung ist Skalierbarkeit ein zentrales Kriterium: Lässt sich das Design in großem Maßstab wiederverwenden? Basiert es auf dem bestehenden Design System? Gibt es klare Patterns, die auf andere Situationen übertragbar sind? Kann es unterschiedliche Inhalte und Textlängen aufnehmen, ohne an Ästhetik oder Funktionalität einzubüßen?

Für die Zukunft möchte ich mein Wissen über UI- und UX-Patterns und deren Anwendungsfälle weiter ausbauen, um in spezifischen Situationen schneller fundierte Designkonzepte entwickeln zu können.

Professioneller und zuverlässiger Handoff

Ich habe gelernt, wie ich meine Entwürfe übergeben sollte. Dazu gehören die Nachverfolgung der ursprünglichen Fragestellung, die konkreten Auswirkungen des Designkonzepts (sowie ein Vergleich mit dem alten Entwurf und Optimierungsvorschläge), Überlegungen zur Wahl geeigneter Medien für die Vermittlung der verschiedenen Entwürfe, die Umsetzung des Designkonzepts in konkrete Entwicklungsaufgaben sowie die Bereitstellung der erforderlichen Assets und relevanter Links. Mir ist auch bewusst, dass die Übergabe nicht das Ende ist und oft auch nicht sein kann – eine einzelne Übergabe entspricht möglicherweise nicht genau den ursprünglichen Anforderungen, und es können offene Fragen und konkrete Diskussionspunkte existieren. Daher müssen wir im Rahmen des GitHub-basierten Ticketingsystems unseres Teams häufig nach einer Übergabe die Diskussion in einem einzelnen Ticket fortsetzen, bis alle Fragen geklärt sind. Bei der Festlegung von Inhalt und Format einer Lieferung müssen daher in einem einzelnen Ticket ausreichende Referenzen bereitgestellt werden, um weitere Diskussionen zu unterstützen. Insbesondere bei der Bearbeitung eines größeren Problems ist es einerseits erforderlich, dieses in kleinere Probleme, also Sub-Tickets, aufzuteilen, andererseits muss sichergestellt werden, dass das Problem und die Lösung innerhalb eines Tickets verständlich sind.

Kommunikation und Zusammenarbeit

Bei der Präsentation von Designlösungen ist es wichtig, Inhalte klar zu beschriften und nur relevante Informationen zu zeigen, um Missverständnisse zu vermeiden.

In einem Team, in dem der Product Owner – wie in meinem Fall – keine klassische Roadmap- und Priorisierungsverantwortung übernimmt, ist es Aufgabe des UX-Teams, stärker strategisch zu denken, relevante Themen aktiv voranzutreiben und dabei auch eine gewisse Führungsrolle einzunehmen.

Unklarheiten sollten wann immer möglich direkt im Gespräch mit den betreffenden Personen geklärt werden. Bei komplexeren Themen kann es sinnvoll sein, weitere relevante Personen hinzuzuziehen. Um eine produktive Kommunikation zu fördern, ist es hilfreich, Empathie zu zeigen, die Perspektive des Gegenübers anzuerkennen und dessen Erwartungen im Blick zu behalten.

Mehr als nur Output zählen

Ich habe gelernt, die Faktoren, die Arbeitsleistung und Effizienz beeinflussen, differenzierter zu betrachten: Komplexität, Qualität, Überarbeitungsaufwand, Kommunikationsaufwand, Teamdynamik und Aufgabenplanung spielen dabei alle eine Rolle.

Für die Zukunft möchte ich meinen Arbeitsaufwand noch klarer definieren, mich regelmäßiger mit dem Product Owner abstimmen und meine Arbeit stärker an der internen UX-Strategie ausrichten, um besser an der Sprint-Planung mitwirken zu können.

Selbstmanagement im Berufsalltag: Motivation, Atmosphäre und Selbstvertrauen

Mir ist klar geworden, dass ich in einer Umgebung mit aktiver Präsenzkultur und lebendiger Teamatmosphäre deutlich engagierter arbeite.

In einem Team, das auf gegenseitigem Verständnis und Respekt vor fachlicher Expertise basiert, habe ich zunehmend mehr Sicherheit gewonnen, meine eigene Perspektive zu vertreten. Als UXler, der die Interessen der Nutzenden repräsentiert, habe ich gelernt, meinen fachlichen Standpunkt klar und bestimmt zu vertreten, ohne dabei in Konflikte zu verfallen – und gleichzeitig offen für die Sichtweisen anderer zu bleiben.

Fazit

Rückblickend habe ich im Laufe des Praktikums eine deutliche persönliche Entwicklung durchlaufen: von anfänglicher Unsicherheit im Umgang mit der deutschen Sprache hin zu einem selbstverständlichen und unbelasteten Austausch mit meinen Kolleginnen und Kollegen; von einem vorsichtigen Herantasten an meine Designaufgaben hin zu einem selbstbewussten Vertreten und kontinuierlichen Kommunizieren meiner Lösungen. Als Praktikant war mein Hauptziel das Lernen. Daher war ich während des gesamten Praktikums hoch motiviert, mich mit allem auseinanderzusetzen, was mir begegnet ist – von Arbeitsabläufen über konkrete Research- und Designaufgaben bis hin zu den Zielen des Teams und der Projekte. Ich habe von mir selbst nicht nur hochwertige Designergebnisse erwartet, sondern auch einen ganzheitlichen Blick auf das Gesamtbild. Als Designer habe ich stets meine durchdachten Standpunkte vertreten und versucht, meine Arbeit aktiv voranzutreiben. Als Person aus einer anderen Kultur habe ich außerdem kontinuierlich versucht, die hiesige Arbeitskultur und zwischenmenschliche Dynamiken besser zu verstehen. Ich bin dankbar, dass mein Team mir einen Raum geboten hat, in dem ich mich entfalten konnte, und ich habe dabei nach und nach mein professionelles Selbstvertrauen aufgebaut.

Die technische Infrastruktur des IT-Teams, die helle und komfortable Arbeitsumgebung, die zugängliche und unterstützende Haltung des administrativen Leads sowie die zuverlässig funktionierenden digitalen Arbeitswerkzeuge ermöglichten es mir, mich vollständig auf meine Kernaufgaben zu konzentrieren. Die Kantine des Unternehmens bot zudem ein breites und günstiges Speisenangebot – als Praktikant profitierte ich von einem zusätzlichen Rabatt –, sodass ich aus der Mittagspause stets gut gestärkt zurückkehrte.

Obwohl das Unternehmen bereits aktiv KI-Tools einführt und selbst KI-basierte Software entwickelt, war der Einsatz von KI im Design-Workflow in der Praxis – abgesehen von der Research-Phase – kaum möglich. So war es beispielsweise nicht umsetzbar, das firmeneigene Design System mit KI-Tools zu verknüpfen, um interaktive Prototypen schnell zu generieren oder die gesamte Designdokumentation effizienter zu verwalten. Im Verlauf meiner Arbeit habe ich gespürt, dass bestimmte Aufgaben – etwa die Erstellung responsiver Varianten auf Basis eines bestehenden Design Systems und bereits gestalteter Komponenten – gut von KI übernommen werden könnten, während ich mich stärker auf die Definition von Regeln, Anforderungen und Vorlagen konzentrieren würde. Dies würde die Effizienz erheblich steigern und den Arbeitsaufwand spürbar reduzieren.

Wie bereits angedeutet, werden im Unternehmen unter Einhaltung der Compliance-Vorgaben bereits einige KI-Tools eingesetzt – etwa ein KI-Chatbot. Dennoch ist die Etablierung eines durchgängigen KI-Workflows immer noch nicht da, wobei ich finde, dass es daran liegt: Es fehlt an jemandem, der diesen Prozess aktiv vorantreibt. Kolleginnen und Kollegen, die seit Jahren an denselben Projekten arbeiten, sollten wenig Anreiz haben, ihre eingespielten Arbeitsweisen zu verändern. Ein neuer UI- und Entwicklungs-Workflow würde umfangreiche Abstimmungen erfordern und unweigerlich in bestehende Zuständigkeitsbereiche eingreifen, was Widerstände erzeugen kann. Hinzu kommt, dass bei internen Projekten wie dem unseren – die keinem hohen Zeitdruck und keiner schnellen Iterationsgeschwindigkeit unterliegen – der wahrgenommene Nutzen von KI-gestützter Effizienzsteigerung verhältnismäßig gering ist. Ich bin jedoch der Überzeugung, dass die Einführung eines KI-Workflows grundsätzlich machbar ist – insbesondere im Bereich Frontend-Design, wo die Risiken überschaubar sind. Es mangelt schlicht an der treibenden Kraft, die Veränderung anzustoßen. KI-Workflows haben zweifellos ihre Vorteile und sind bahnbrechend. Daher bin ich der Meinung, dass man sie dennoch ausprobieren sollte, um für die Zukunft oder für eine Tätigkeit in anderen Unternehmen gerüstet zu sein.