An dieser Stelle befragen wir immer mal wieder Kunden und andere UX-Experten zu ihren UX-Prozessen, Lessons Learned und Best Practices.
Heute erzählt Martin Peters aus seinem Alltag bei DropFriends: Wie er die Schnittstellen zwischen verschiedenen Abteilungen organisiert, wie sie mit Remote-Arbeit umgehen und warum er schon Schafe aus Flüssen gerettet hat. Außerdem gibt er Tipps für das agile Arbeiten und erzählt, was er aus der Arbeit in Konzernen und Start-Ups gelernt hat.
Wer bist du und was machst du?
Ich bin Martin – einer von drei GründerInnen bei DropFriends und als Geschäftsführer tätig. Geboren in Köln – lebend in Köln – ‘ne echte kölsche Jong.
Ursprünglich komme ich aus der Gestaltungstechnik und bin dann über den Umweg des telefonischen Servicemitarbeiters zum Produktmanager gelangt. Ich bin seit 2004 im Großbereich Online Payment, Produktmanagement und
Process & Quality in Konzernen, mittelständischen Unternehmen und StartUps unterwegs. Insbesondere als Spezialist für Digital Commerce in leitender Funktion von crossfunktionalen Teams (Agile Product Owner seit 2015), mit Schnittstellen zum Product Marketing, der Inhouse Entwicklung und dem User Experience Lab. In Expertenfunktionen unterstütze ich zu den Themen Prozessoptimierung, UI/UX, Service-Implementierung und interner Wissenstransfer (Info- & Knowledge Management).
Zudem war ich sehr lange als Feuerwehrmann aktiv und habe mich dort auf die Abwehr von atomaren, biologischen und chemischen Gefahren spezialisiert. Aber ja, ich habe z.B. auch Feuer unter Atemschutz gelöscht, Schafe aus Flüssen gerettet, Personen aus Verkehrsunfällen rausgeholt und Bäume bei Stürmen zersägt.
Welche Rolle spielt User Experience bei eurer Produktentwicklung bei DropFriends?
Die Begrifflichkeit lässt sich weitestgehend nicht mit dem Beginn eines Startups vereinen, da man stets den Fokus auf die Erstellung eines Prototyps hat. Da bleibt dann gerne Design, Nutzerführung und Psychologie liegen. Viele erfolgreiche Unternehmen haben den Schlachtruf “Execute or die!” und das stimmt auch zu einem gewissen Grad.
Wir sehen die Begrifflichkeit dagegen zweigeteilt: “User” und “Experience”.
Der Nutzer steht bei uns absolut im Zentrum von allem. Und da wir als Plattform auch noch drei verschiedene Richtungen bespielen, bleibt uns dahingehend auch gar nicht viel anderes übrig. Wenn es uns dann auch noch gelingt, unsere aufgebaute Community an einer “Erfahrung” teilhaben zu lassen, dann gehen bei uns die Mundwinkel hoch. Auch dahingehend, weil wir in einem regulatorischen Bereich arbeiten. Entsprechend müssen wir uns in vorgegebenen Rahmen bewegen, in dem ein “Husch-Husch” à la “Execute > Idea” oft nicht möglich ist – oder zumindest arg mit Hürden abgewägt werden muss. Somit können wir die Umsetzung nicht einfach auf eine Türschwelle knallen und einfach schauen, was passiert.
Natürlich ist das auch sehr überspitzt dargestellt. Der Mittelweg machts. Aber letztlich ist es ja so, dass man eine gute Experience schon mit Automatisierungen hinbekommt. Selbige hat zudem starken Impact auf die eigenen Prozess- und Kostenstrukturen. Da lohnt sich ein Blick dann doch öfter, als man glauben mag.
Welche Erfahrungen konntest du bei der Organisation der Schnittstellen zwischen verschiedenen Abteilungen machen, zum Beispiel zwischen Product Marketing und dem User Experience Lab?
Wie bei allem im Leben ist Kommunikation der Schlüssel. Es fällt mir immer wieder auf, dass viel über Personas und Zielgruppen gesprochen wird, um den Umsatz bei gewissen Personengruppen triggern zu können. Es ist schon fast ironisch, dass selbiges im Stakeholdermanagement komplett ignoriert wird.
Interne Umsetzungen gelangen meist nur in abteilungsübergreifenden Schritten. Versteht man die Kommunikationskultur seines Gegenübers nicht, dann redet man häufig aneinander vorbei oder es kommt zu klassischen Missverständnissen. Einer der Gründe, warum ich auf eine kosten- und zeitintensive agile Arbeitsweise setze. Es wird mehr gesprochen. Spitzfindiger recherchiert. Präziser erklärt. Das ist auch notwendig.
Es reicht einfach nicht zu sagen: “Ich brauche auf der Website einen Button!”. Daraus ergeben sich Kausalitäten, die bedacht und hinterfragt werden müssen. Das fängt bei der Positionierung und der CI an und hört bei der Funktion und positiven, wie auch negativen Feedbacks auf. Was soll im Hintergrund alles ausgelöst werden? Müssen Mails verschickt werden? Soll eine Meldung erscheinen? Was ist mit einem Loading Spinner? Soll ein Event zum Tracken ausgelöst werden?
Was waren für euch die größten Herausforderungen beim Remote-Arbeiten und wie habt ihr sie gelöst?
Wir sprechen viel miteinander. Das ist der agilen Arbeitsweise geschuldet. Und tatsächlich hat sich immer klarer herauskristallisiert, dass es der absolut richtige Weg für uns ist. Das erleichtert uns die “Remote Work” erheblich. Darüber hinaus haben wir eine transparente Dokumentation über unsere Scrumban Boards. Jede KollegIn kann jederzeit einsehen, wer woran arbeitet. Egal ob PraktikantIn, Voll-/TeilzeitlerIn oder GründerIn.
Eine Herausforderung ist aber sicherlich der nicht vorhandene Plausch in der Kaffee-Küche oder im Büroflur. Das ist für ein soziales Miteinander sehr wichtig und fördert auch die Zusammenarbeit. Selbst in Pausen arbeiten die KollegInnen im Kopf häufig weiter und möchten sich hierzu austauschen. Das fehlt.
Wir machen gerne “Remote-Wichteln” für unsere MitarbeiterInnen und schauen dann virtuell zu, wenn jemand “zufällig” sein Lieblingsgetränk im Paket vorfindet oder ein selbstgemaltes Portrait. Das ist immer für einen Schmunzler gut. Zumal es auch tolle digitale Cocktailkurse gibt, die man gemeinsam absolvieren kann.
Glücklicherweise haben sich unsere KollegInnen auch noch super miteinander selbst vernetzt. So hatten wir zuletzt eine Gruppe von PraktikantInnen, die sich nie im Real-Life trafen, aber sich über eine private WhatsApp-Gruppe verbunden haben. Wir fördern diese Art der Verbindung. So können private Dinge natürlich auch über unternehmensexterne Instrumente abgehandelt werden, statt über Microsoft Teams oder die geschäftliche Mailadresse. Das gibt den KollegInnen Freiräume und Sicherheit. Und vielleicht auch ein wenig Platz, um mal über den Chef abzulästern. 🙂 Das ist vollkommen in Ordnung und schweißt auch zusammen.
Welche Tipps hast du für agiles Arbeiten / agile Entwicklungsprozesse?
Es sollte zunächst einmal allen Parteien klar sein, was “Agilität” oder “Scrum” oder “Kanban” wirklich bedeutet.
Es muss klar sein, dass es teuer, zeitintensiv, aber dafür sehr effektiv ist. Und da kommen wir bereits zum nächsten Punkt: Die Unterschiede zwischen den Begriffen “Effizienz” und “Effektivität” müssen verinnerlicht werden.
Und wenn dies das ganze Unternehmen (inkl. Geschäftsführung) verstanden hat, dann kann man weiter darüber nachdenken, ob Agilität passt – oder eben nicht. Es bringt einfach nichts, die Sache für vier Wochen auszuprobieren und dann abzubrechen, weil der Output noch nicht stimmt. Die Sache braucht Zeit, aber wird mit etwas Geduld zum selbstständigen Rennpferd. Es ist gelebtes Pareto auf Koffein.
Es gibt viele Frameworks in der Agilität, an denen man sich austoben kann. Ein Beispiel ist SCRUM. Es hat ein klares Regelwerk, an das man sich halten kann. Man sollte sich aber angewöhnen, dass man seine Vorgehensweise nicht mehr SCRUM nennt, sobald man von den Regeln abweicht. Das ist durchaus möglich und macht ggf. sogar Sinn.
In diesem Fall ist das Umbenennen von SCRUM zu “Agiles Arbeiten” eine wirkliche Empfehlung. Das macht die Kommunikation einfacher. Es gibt immer Stakeholder oder KollegInnen, die anfangen im Netz zu überprüfen, ob man das denn auch alles richtig macht. Das kann sehr anstrengend sein und lenkt von den eigentlichen Zielen ab. So kann man dann auf lange Sicht Diskussionen vermeiden.
Ein Tipp, der mir sehr am Herzen liegt, ist aber ein anderer: Verheizt Eure Leute nicht. Agile Frameworks wie SCRUM sehen verschiedene Rollen vor. Diese sollten tatsächlich eingehalten werden. Es macht einfach keinen Sinn, auf eine Person zu verzichten, um deren Aufgabe einer anderen Rolle zuzuschreiben. Das geht auf Dauer nicht gut. Zumal diese z.T. auch wie Sparringspartner wirken sollen. Und ganz wichtig: Rollen unterliegen keiner Hierarchie. Innerhalb einer agilen Gruppe gibt es keinen Chef. Das muss jedem klar sein.
Du kennst die Arbeit in Konzernen und in Start-Ups – welche Unterschiede hast du bemerkt und was könnte sich das eine vom anderen abschauen?
Das Offensichtliche zuerst: Konzerne haben lange Entscheidungswege. Startups sind da deutlich dynamischer. Das kann man sich tatsächlich als kleines Tech-Unternehmen zunutze machen. Auch die „Trial & Error“-Mentalität ist eine ganz andere und so mancher Konzernchef hat schon neidisch auf die Zwei-Personen-Teams geschaut, die mit einem Produkt plötzlich den Markt aufmischen.
Dagegen spricht für Konzerne oftmals ein Erfahrungsschatz, der sehr hochwertig ist – leider nur oft eingestaubt. Kitzelt man aber an den richtigen Stellen, dann spart man sich viel Recherchearbeit und manches Problem im Prozessablauf. Struktur und Dokumentation können starke Verbündete im Bau eines Features bzw. eines Produktes sein. Die personelle Fluktuation in Startups ist oft deutlich höher als in Großunternehmen. Da spürt man dann erst, wenn eine Schlüsselperson fehlt, wenn keine Dokumentation oder keine Struktur zum Auffangen der nun zu bewältigen Aufgaben vorhanden ist. Natürlich steht das Budget hier im Vordergrund, doch man kann seine Personaldecke strategisch auf solche Szenarien vorbereiten oder eben Zeit für eine Dokumentation aufbringen.
Was letztlich ein allgemeines Thema ist, ganz unabhängig von der Unternehmensgröße, ist das Thema “Verantwortung übernehmen”. Menschen verschwenden so viel Zeit damit, sich vor Verantwortung zu drücken oder Ausreden für dies und das zu erfinden, dass man dafür 500 mehr Produkte bauen könnte. Aus dem Bauch heraus würde ich behaupten, dass 80% aller Probleme nicht aufkommen würden oder aber lösbar wären, wenn man zu Fehlern steht oder schlichtweg Verantwortung übernimmt.
An welches Produkt denkst du bei guter User Experience?
Die Google Suchmaschine. Ein Formularfeld. Eine Enter-Taste. Und ich.
Hast du eine goldene UX-Regel?
Verstehe die Kommunikationskultur deiner Zielgruppe.
Teilen
Diesen Artikel teilen