Vom Usability Review zur eigenen UX/UI-Abteilung : Kyra, Teamlead bei One Data im Interview

In dem Interview erzählt Kyra Bollmeyer, wie die interne UX-Ressource bei ONE DATA in nur drei Jahren von Null auf ein eigenes UX/UI Chapter wuchs – und wie UX-Methodik die Produktvision befeuerte. Das 2013 gegründete Tech-Unternehmen ONE DATA hilft, Daten in Businesswerte umzuwandeln und Datenprodukte schnell auf die Straße zu bringen. Der Gartner® Report 2021 listet das Unternehmen als einen von fünf “Cool Vendors for AI Core Technologies”.

Erste Schritte

Kyra, wann war UX bei euch das erste mal ein Thema?

Eigentlich war UX bei uns schon immer ein Thema, leider muss man aber sagen, dass es am Anfang noch nicht die Aufmerksamkeit bekommen hat, die es verdient hätte. Dazu muss man wissen: Unser Produkt ONE DATA, ein Data-Product-Builder, ist aus dem Auftragsgeschäft heraus entstanden. Die Software wurde immer umfangreicher, und bevor sich jemand genaue Gedanken über das Interface gemacht hat, ging es erstmal um den technischen Unterbau. Technologie-Framework, Tech-Stack und die grundsätzlichen Software- Funktionalitäten mussten definiert werden. Es gab damals noch keine dezidierten UX-Spezialist* innen im Team. So haben die Entwickler*innen zunächst Googles Material als Framework für alles genutzt. Das ist aber eher für Apps geeignet, nicht für komplexe Software. Wir merkten immer deutlicher, dass wir die Usability mehr in den Fokus setzen müssen. Die Navigation beispielsweise war verwirrend,
die Gestaltung war nicht konsistent im Sinne einer einheitlichen Corporate Identity. Im Rahmen eines Usability Objectives wurde dann UX&I beauftragt, die UX von ONE DATA mal genauer unter die Lupe zu nehmen.

Womit ging die Arbeit an der Usability los?

Gestartet hat alles vor meiner Zeit mit vielen roten Post-its in einem Workshop. Und erstmal kleinen Etappen. Nach einer heuristischen Evaluation schnürten wir gemeinsam mit UX&I die Arbeitspakete und gingen sie Schritt für Schritt an. Der Spirit von UX&I passte super zusammen mit unserer Kultur. Wir haben an konkreten Interface-Themen zusammengearbeitet, schnell kam ein UI-Designer von UX&I und dann später ich dazu. Wir haben gemeinsam die Grundlagen für einen Styleguide gelegt, das Ganze wurde in Komponenten übersetzt und im Frontend umgesetzt. Kanban Flight Levels halfen uns bei der Organisation und auch bei der Kommunikation. Um ein gemeinsames Verständnis im ganzen Team zu schaffen und strategisch weiterzukommen, nutzten wir Wardley Maps. Statt gleich die nächsten fünf Jahre genau durchzuplanen, schärften wir unsere Produktvision und arbeiteten die einzelnen Pakete Stück für Stück nacheinander ab.

Gab es auch übergreifende UX-Ziele?

Ja, den Nutzerfokus wollten wir konsequent verankern, möglichst in allen Arbeitsprozessen und im ganzen Unternehmen. Nach und nach wurde aus den Interface-Themen ein generelles Product Coaching. In Workshops zu einzelnen UX-Bausteinen arbeiteten wir daran, die UX-Denke zu etablieren. User Story Mapping war eine Methode, wie wir Nutzerbedürfnisse erkennen und gezielt adressieren konnten. Gleichzeitig begannen wir auch mit dem Aufbau unseres eigenen UX/UI-Teams.

Wir definierten Rollen, suchten nach Prozessen für die UX-Perspektive und nach geeigneten Kolleg*innen.

Warum ein eigenes Team?

Langsam wurde festgestellt, dass der externe UX-Support extremen Mehrwert bietet und unser Produkt nach vorne bringt. Natürlich wollte das Management das dann auch Inhouse noch mehr haben und uns auf diesem wichtigen Gebiet selbst stark aufstellen. Die Stimmen nach guter Usability wurden lauter und es gab noch viel zu tun. Schnell wurden wir mehr UX/UI-Designer*innen im Unternehmen. Damals saßen wir tatsächlich auch schon direkt in einzelnen Entwicklungsteams. Dabei haben wir festgestellt:

Es macht trotzdem absolut Sinn, sich mit seinen UX-Buddies zu verknüpfen. Der Gedanke des UX-Teams war geboren, aber schnell haben wir gemerkt, dass wir auch kein Silo sein wollen, sondern weiterhin Teil der Entwicklungsteams sein müssen. So ist es dann gekommen, dass wir zum Chapter geworden sind. Als Chapter spannen wir uns nun über alle Entwicklungsteams und können die UX-Sichtweise überall verankern, uns aber trotzdem auch unter uns organisieren.

Organisation als UX/UI Hub

Ihr habt nun euren eigenen internen “UX/UI Hub”? Wie ist dieser organisiert?

Übergreifend ist One Data in mehrere Departments strukturiert. Wir als UX-Chapter sind im Software Development Department aufgehängt. Dieses teilt sich nochmal auf in unser Produkt ONE DATA und in die Projekte. Innerhalb des Produkts gibt es verschiedene Entwicklungsteams. Jeder von uns UXlern sitzt in einem dieser Teams und unterstützt die Entwickler*innen. Dann gibt es noch die Gilden für übergeordnete Themen, z. B. unser Diversity & Inclusive Committee. Bei den Gilden kann jeder teilnehmen.

Innerhalb der Entwicklungsteams hat jeder UXler seine eigenen Themen, die sie oder er vorantreibt, mit den Entwicklern, den Produkt- managern und den Testern. Damit wir trotzdem den Kontakt nicht verlieren und einheitlich sind in der UX, aber auch in der UI, treffen wir uns jeden Tag im UX/UI Daily. Wir tauschen uns aus, was so die Probleme sind, ob jemand einen Peer Review braucht oder ob wir neue Components in unserer Library ergänzen sollten. Themen also, die für die Entwickler*innen nicht spannend sind, für uns aber sehr wichtig. Bei den Peer Reviews haben wir zugewiesene UX Buddies, die wir am Anfang des Projekts festlegen. Man hat also immer einen Partner innerhalb des UX/UI-Teams, den man fragen kann, wenn man Hilfe braucht oder einem die Kreativität ausgeht. Auch für die Konsistenz ist das hilfreich, vier Augen sehen mehr als zwei. Meistens machen wir für die Peer Reviews einen kurzen Call oder kommentieren in Abstract, das funktioniert am schnellsten und es gehen keine Hintergrundinfos verloren.

Herausforderungen

Was waren eure Herausforderungen auf dem Weg zum nutzerzentrierten Produkt bzw. Unternehmen?

Stolpersteine gab es gerade am Anfang genug. Der Fokus lag erstmal ganz klar auf der Funktionalität des Produkts und auf Geschwindigkeit. Die Verbesserung von Usability und UX war und ist auch vom Management explizit gewünscht. Aber das war anfangs auch das Erste, was hinten runter gefallen ist, wenn Zeit und Budget knapp waren. Und auch die Entwickler*innen mussten erstmal lernen, dass der UX-Support hilfreich sein kann. Wir helfen dabei, beide Stärken miteinander zu kombinieren, Tech und UX, und nebenbei die Probleme der User nicht aus den Augen zu verlieren. Denn gute UX ist keine Frage von Budget und Zeit mehr, im Gegenteil. Mittlerweile kommen viele Kolleg*innen aktiv auf uns zu, wenn sie Unterstützung bei UX- oder UI-Themen brauchen. Was unser Produkt selbst angeht: Hier lag die Herausforderung in der Komplexität und im großen Funktionsumfang. Komplexe technische Zusammenhänge mussten verständlich und nutzbar gemacht werden.

Status Quo

Was hat sich seit den ersten Usability Reviews getan?

Wir sind aktuell sieben feste interne UX/UI-Expertinnen und Experten. Nutzerzentrierung ist Bestandteil unserer Firmenkultur. Wir haben in den letzten Jahren fliegen gelernt, UX&I begleitet uns heute vor allem noch bei Impulsvorträgen zu UX-Themen oder bei Kapa-Engpässen. Im UX/UI-Team gibt es nun auch eine Management- Perspektive mit Lead-of-Rollen, ähnlich wie beim Produktmanagement. UX-Methoden sind in viele unserer Prozesse integriert, zum Beispiel im Bereich Standardisierung. Anfangs hatten wir viele Inkonsistenzen, heute arbeiten wir streng nach Styleguide, der von einem eigenen Team gepflegt wird. Der Styleguide wird auch von unseren Entwickler*innen genutzt, wodurch wir nicht nur die Einheitlichkeit stärken, sondern auch ein besseres gegenseitiges Verständnis bekommen. Wenn etwas unklar ist, fragen wir nach. Code-Styleguide und UI-Styleguide laufen synchron. Demnächst sind noch Text-Guidelines geplant. UX ist auch in die Qualitätsprüfung eingegangen, am Ende schaut immer nochmal eine UXlerin oder ein UXler auf die Ergebnisse und prüft aus Usersicht. Haben wir wirklich das anfängliche Problem gelöst?

Apropos User-Sicht, welche Methoden helfen euch dabei?

Auch wenn das Thema Deep Tech sehr verwirrend und technisch sein kann, sollten wir nicht vergessen, warum wir das eigentlich tun. Am Anfang steht immer das eigentliche Problem des Nutzers, das gelöst werden muss. Dieses Problem kann in der sehr technischen Umgebung schnell vergessen werden. Und natürlich der Leitgedanke “Du bist nicht der Nutzer”, den Satz haben wir verinnerlicht. User Tests machen wir so früh und so oft wie möglich, auch vorab kommunizieren wir schon im kleinen Stil mit den Nutzern. Und wir arbeiten viel mit User Flows. So können wir Entscheidungen nutzerzentriert begründen.

Wie hat sich euer Produkt ONE DATA weiterentwickelt?

Die Produktvision steht jetzt im Fokus. Anfangs waren wir sehr im Projektgeschäft gefangen. Wir waren vor allem damit beschäftigt, den Wünschen unserer Kunden Herr zu werden und Anforderungen abzuarbeiten. Wir haben gelernt, auch mal nein zu sagen und unsere eigene Roadmap voranzutreiben.

Ziele

Wie geht es weiter mit dem UX/UI Chapter?

Das Ziel ist es, uns generalistisch auszurichten und uns umfassend in vielen UX-Themen auszukennen. Wenn es zum Beispiel um Research geht und User Interviews durchgeführt werden müssen, soll keiner von uns Panik bekommen. Wir wollen uns innerhalb der UX- Themen breit aufstellen, so dass wir im Chapter alles gut abdecken können. Wichtig ist daher das Interesse, sich weiterzuentwickeln. Unser Langzeitziel ist es, auf dem Gebiet User Experience vollständig autark zu sein. Es gibt genug zu tun und wir suchen gute Leute, die sich von Tech und Code nicht abschrecken lassen. Wir brauchen auch mehr Mädels in Tech 😅. Ich versuche immer, zu inspirieren. Früher hätte ich auch nie gedacht, dass ich mal Richtung Ínformatik gehe. Mittlerweile kann ich sagen, es war eine meiner besten Entscheidungen. Wer sich in dem Bereich spezialisiert, dem stehen alle Türen offen.

Mehr zur UX-Erfolgsgeschichte von One Data findest du im Showcase.
Übrigens gibt es offene Stellen im Team von Kyra 👉 Zur Karriereseite von One Data.