Von der „Warum?“-Frage zur UX-Gilde: DevStory mit Perihan Rashed (Senior Product Experience Designer bei Dynatrace)

Ein Einstieg über Stühle – und warum das zählt

Es klingt wie der Anfang einer Anekdote, bleibt aber als Leitmotiv haften: In „DevStory: Perihan Rashed, Senior Product Experience Designer bei Dynatrace“ erzählt Perihan Rashed, wie sie als Kind mit ständigen „Warum?“-Fragen auffiel. Eine dieser Fragen hat ihre berufliche Richtung geprägt: „Warum sind Stühle, wie sie sind?“ Die Recherche führte sie zur Erkenntnis, dass die alten Ägypter erste Impulse zur Form und Funktion des Stuhls gaben – ein Detail, das für sie als gebürtige Ägypterin besonders resonierte. Über die Griechen und die weitere Entwicklung hin zur Bequemlichkeit (Polsterung, komfortorientierte Anpassungen) entspinnt sich ein roter Faden: Gestaltung dient dem menschlichen Erlebnis.

Wir bei DevJobs.at haben diese DevStory deshalb so aufmerksam verfolgt, weil sie eine essenzielle Wahrheit für Produktteams freilegt: Hinter jeder Oberfläche steht eine Entscheidungskette aus Beobachtung, Empathie, Abwägung und Iteration. Perihan verbindet diese Haltung mit einer konkreten Praxis im Alltag als Senior Product Experience Designer bei Dynatrace GmbH – und als UX Guild Lead, der Design spürbar in die Produktorganisation trägt.

Rolle und Setup: Produkt-Erlebnisgestaltung eingebettet im Dev-Team

Perihan beschreibt ihre Arbeit als End-to-End-Verantwortung für das Nutzererlebnis – unmittelbar eingebettet in ein Entwicklungsteam. Je nach Größe des Teams sind dort typischerweise ein bis drei Product Experience Designer:innen involviert. Diese Einbettung ist kein Nebenaspekt, sondern Basis für Tempo und Qualität: Der Designprozess beginnt gemeinsam mit Entwickler:innen und Product Manager:innen bei der Problemdefinition und endet dort, wo Tests die Lösung validieren – immer mit der Option, in frühere Phasen zurückzuspringen.

Die Konsequenz: Design ist keine Dienstleistung „am Rand“, sondern integraler Bestandteil der Produktentwicklung. Genau diese Nähe macht es möglich, Erkenntnisse aus Tests schnell in Code, Komponenten und Interaktionen zu überführen.

Der Prozess: Design Thinking als Realität im Tagesgeschäft

Perihan ordnet die Arbeitsweise ihres Teams klar in ein Design-Thinking-Mindset ein. Das bedeutet: Nicht linear abarbeiten, sondern erkunden, verdichten, entwerfen, verproben – und bei Bedarf zurückgehen. Aus ihrer Beschreibung destillieren sich die klassischen Etappen, die viele von uns kennen, aber zu selten konsequent leben:

• Verständnisphase: Problemdefinition, Kontextklärung, „Warum ist das ein Problem?“
• Empathieaufbau: Nutzerperspektive, Bedürfnisse, Hürden, Zielzustände
• Problem Statement: Prägnant formuliert, als gemeinsamer Fokus für alle Beteiligten
• Recherche: Wettbewerbsanalyse und Inspirationen aus anderen Domänen
• Prototyping: Von Low-Fidelity bis hin zu klickbaren Flows – kollaborativ erstellt
• Brainstorming mit Dev & PM: Zielbild schärfen, Lösungsweg priorisieren
• Testen: Mit Nutzer:innen validieren, Hypothesen bestätigen oder widerlegen
• Iteration: Je nach Erkenntnisstand zurückspringen und verbessern

Wichtig ist die Offenheit, zwischen den Phasen zu wechseln. Genau das unterscheidet „Prozess als Checkliste“ von „Prozess als Lernschleife“: Erkenntnisse sind keine Dokumente, sondern Hebel für Entscheidungen – und der nächste Prototyp ist selten die Endfassung.

Zusammenarbeit, die funktioniert: Gemeinsame Verantwortung statt Übergaben

Die Beschreibung von Perihan vermeidet jedes Wasserfall-Vokabular. Stattdessen steht dort ein Miteinander, das Entwickler:innen früh in die Lösungsfindung einbindet und Product Manager:innen ins Testen und Lernen integriert. Die Konsequenzen für den Alltag sind klar:

• Brainstorming ist kein Ideen-Basar, sondern ein Orientierungspunkt: „Wo wollen wir hin?“
• Prototypen sind Gesprächsanlässe und Entscheidungshilfen, nicht nur „Vorlagen fürs Pixel-Perfect“.
• Tests sind keine Kür, sondern Teil der Definition of Done – denn nur validierte Erlebnisse sind robuste Erlebnisse.

Für Teams, die diese Praxis noch nicht leben, ist der entscheidende Schritt oft organisatorisch: Designer:innen frühzeitig ins Backlog holen, mit klarer Problemstellung starten und Explorationszeit einplanen.

Die UX-Gilde: Designkräfte in Produktorganisationen entfalten

Ein weiterer Schwerpunkt in Perihans DevStory ist ihre Rolle als UX Guild Lead. Der Kontext: In vielen IT-Organisationen sind UX-Teams zahlenmäßig kleiner als Engineering – „die Minderheit unter vielen Entwickler:innen“, wie sie es beschreibt. Genau hier setzt die Gilde an: Sie macht Design zugänglich und anwendbar, auch für Nicht-Designer:innen.

Konkret adressiert die Gilde drei Felder:

• Designsystem-Arbeit: Komponenten, Muster, Richtlinien – und wie man sie sinnvoll nutzt
• Testing-Kompetenz: Wie Entwickler:innen ihre eigenen Designs prüfen können
• PM-Empowerment: Wie Product Manager:innen selbstständig testen können

Dieser Ansatz löst zwei typische Spannungen: Erstens wird Design nicht zum Flaschenhals, weil Wissen und Werkzeuge geteilt werden. Zweitens verbessert sich die Qualität von Entscheidungen, weil Konsistenz (Designsystem) und Evidenz (Testing) in mehr Köpfen verankert sind. Für uns ist das ein praktisch erprobtes Organisationsprinzip: Design führt, aber es kontrolliert nicht – es befähigt.

Ein Leitmotiv: Neugier als Motor des Erlebens

Die Geschichte mit den Stühlen ist mehr als eine Kindheitserinnerung. Sie ist eine Haltung: Design beginnt beim staunenden, fragenden Blick auf Dinge, die „schon immer so waren“. Aus „Warum sind Stühle so?“ wird „Warum ist unser Onboarding so?“ oder „Warum löst dieser Flow das Nutzerproblem (noch) nicht?“ Diese Haltung trägt durch den gesamten Prozess, den Perihan beschreibt:

• vom Problemverständnis (nicht die Lösung voreilig definieren)
• über Empathie (die Perspektive der Nutzer:innen ernst nehmen)
• hin zu schrittweiser, testbarer Ausgestaltung.

Neugier ist hier kein Soft Skill, sondern das Startsignal jeder Verbesserung.

Karriereleitplanken für Designer:innen: „Rückwärts anfangen“

Zum Schluss teilt Perihan einen Rat, der sofort anschlussfähig ist – besonders für Talente, die in UI/UX, Produktdesign oder Research in die Tech-Welt hineinwachsen wollen. Der Markt sei groß, sagt sie, und vielfältig. Deshalb sollte man „rückwärts anfangen“:

Konkret bedeutet das vor allem eines: das Portfolio ausrichten. Jede:r Designer:in braucht ein Portfolio, aber nicht jedes Portfolio funktioniert überall. Perihan unterscheidet drei grobe Ausrichtungen:

• agenturorientiert (Agency)
• marketingorientiert
• technologieorientiert

Diese Unterscheidung ist ein wertvoller Filter. Wer in Produktteams mit Entwickler:innen arbeiten möchte, braucht andere Schwerpunkte als jemand, der Kampagnenvisuals oder Markenauftritte gestaltet. Und wer mit Research überzeugen will, zeigt andere Tiefe als jemand, der Motion oder Branding in den Vordergrund rückt. Zusätzlicher Hinweis von Perihan: Es gibt zahlreiche Kurse und Universitäten – aber die Auswahl sollte sich am Ziel ausrichten. Erst das „Wohin?“, dann das „Wie?“.

Eine praktische Vorgehensweise für dein Portfolio

• Ziel definieren: Agentur, Marketing oder Technologie? In welchem Umfeld willst du arbeiten?
• Cases auswählen: Zeige die Arbeitsweise, die dieses Umfeld verlangt (z. B. Problemdefinition, Research, Iterationen für Tech-Teams).
• Prozess zeigen: Vom Problem Statement zum Prototyp zum Test – sichtbar machen, was du gelernt hast.
• Ergebnisse verankern: Welche Entscheidungen wurden getroffen – und warum?
• Lesbarkeit priorisieren: Klar strukturierte, nachvollziehbare Storylines gewinnen gegenüber reinen Endscreens.

Was Tech-Teams aus dieser DevStory mitnehmen können

Aus der Session „DevStory: Perihan Rashed, Senior Product Experience Designer bei Dynatrace“ lassen sich für Entwickler:innen und Product Manager:innen mehrere handfeste Leitlinien ableiten – ohne den Rahmen der Erzählung zu verlassen:

1) UX als Teamaufgabe

• Designer:innen frühzeitig einbinden; gemeinsam Problemstatements formulieren.
• Brainstormings als Richtungsentscheidungen nutzen, nicht als reine Ideensammlungen.

2) Designsystem + Testing = Qualitätssprung

• Ein geteiltes Designsystem ist ein Produktivitätsbooster – Komponenten, Muster, Richtlinien.
• Entwickler:innen sollten in der Lage sein, erste Designannahmen selbst zu testen.

3) Iteration statt Finalität

• Tests sind kein Endpunkt, sondern Umschlagplatz für Lernen.
• Zurückspringen in den Prozess ist kein Rückschritt, sondern Fortschritt in Schleifen.

4) Portfolio-Fokus (für Recruiter:innen und Hiring-Manager)

• Achte darauf, ob Bewerber:innen das „rückwärts denken“ sichtbar machen.
• Technologieorientierte Portfolios zeigen oft klare Problemstatements, Hypothesen, Testresultate – und enge Dev-Kollaboration.

Zitate, die hängen bleiben

Für die Praxis: Ein kompaktes Anwendungsrezept

Wenn wir das Gesagte in ein kurzes, wiederverwendbares Rezept für Produktteams übersetzen, entsteht folgender Ablauf:

• Problem scharf stellen: Ein klar formuliertes Problem Statement als Ausgangspunkt.
• Nutzerperspektive sichern: Empathie durch Research, nicht durch Bauchgefühl.
• Inspiration kuratieren: Wettbewerbs- und Domänen-Insights als Ideengeber.
• Prototyp iterativ entwickeln: Von grob zu fein – sichtbar und testbar.
• Kollaboration fest verankern: Dev und PM in jedem Schritt dabei; Brainstormings mit Zielbild.
• Testen, lernen, zurückspringen: Erkenntnisse priorisieren und gezielt einarbeiten.
• Designsystem nutzen: Komponenten konsistent einsetzen; Qualität durch Wiederverwendbarkeit.
• Gilde/Community pflegen: Wissen teilen, Standards erklären, Selbstwirksamkeit fördern.

Fazit: Neugier, Methode, Befähigung

Die DevStory mit Perihan Rashed bei Dynatrace GmbH verdichtet drei Elemente erfolgreicher Produktarbeit: echte Neugier, ein lernorientierter Designprozess und eine Organisation, die Designkompetenz breit zugänglich macht. Vom Stuhl der Antike bis zum Prototyp von heute spannt sich ein überraschend logischer Bogen: Gute Erlebnisse entstehen, wenn Menschen zunächst fragen, warum Dinge sind, wie sie sind – und dann mit System und Teamgeist daran arbeiten, sie besser zu machen.

Wer in Produktteams Verantwortung trägt – als Entwickler:in, Designer:in oder Product Manager:in –, findet hier eine klare Handlungsanweisung: Stelle Fragen. Beschreibe Probleme sauber. Entwirf, teste, lerne. Teile dein Wissen – und befähige andere. Genau so wird aus Design nicht nur ein Ergebnis, sondern ein gemeinsamer Weg.

• 

  

  Internal Developer Platforms

  Katharina Sick von Dynatrace gibt in ihrem TechTalk Einblicke in die Herangehensweise, wie die Internal Developer Platform das Entwickeln von Software im Unternehmen einfacher gestaltet.

  Jetzt ansehen

• 

  

  Indermohan Singh, Platform Developer Advocate bei Dynatrace

  Indermohan Singh von Dynatrace spricht im Interview von seinen ersten Berührungspunkten mit Software Development bis hin zu seiner aktuellen Arbeit und gibt Tipps für Neueinsteiger.

  Jetzt ansehen