Oliver Pitsch, Senior UX Designer bei Studitemps

Oliver lädt uns zu einem Google Design Sprint bei Studitemps ein. Er verrät uns seine Learnings nach fünf erfolgreich durchgeführten Sprints und zeigt, wie Studitemps UX-Methoden zur Digitalisierung ihrer Strukturen einsetzt.

An einem sonnig-frischen Aprilmorgen mache ich mich auf in den neuen Kölner Coworkingspace Cowoki. Ich bin von Oliver Pitsch eingeladen, bei ihrem fünften Design Sprint dabei zu sein. Die ersten Teilnehmer sind schon da, als ich kurz vor zehn den Konferenzraum betrete. Marker, Aufkleber, Kaffee, Softdrinks und ein kleines Frühstück sind vorbereitet. Ich packe meine Kamera aus, denn in den nächsten drei Tagen fotografiere ich wichtige Schritte ihres Designsprints. Einen Monat später besuche ich Oliver in den eigenen Office-Räumen von Studitemps im Mediapark und wir sprechen über die Ergebnisse und den Verlauf des Design Sprints, sowie über UX und seinen Erfolg als Startup-Gründer.

Hallo Oliver, was ist deine Aufgabe bei Studitemps?

Warum wird User Experience für Studitemps immer wichtiger?

Unser etablierte Prozesse stoßen mittlerweile an ihre Grenzen, da wir in den letzten Jahren stark gewachsen sind. Das sind die klassischen Probleme eines Startups. Am Anfang entscheidet man sich für die einfache Lösung und sagt: Wir machen das jetzt erstmal mal so. Wenn wir groß sind, dann tut das vielleicht weh, aber dann ist das ein gutes Problem.

Außerdem wollen wir ein Produkt bauen, das sich nicht wie eine klassische Business- sondern eher wie eine Consumer-Application anfühlt. Gerade bei unserem zweiseitigen Geschäftsmodell aus Studenten und Unternehmen ist das besonders wichtig. Wir digitalisieren nun unsere internen Prozesse und stellen die User in den Fokus.

Kannst du ein Beispiel für eine aktuelle Produktentwicklung nennen?

Studitemps agiert als Personaldienstleister und schickt monatlich mehrere tausend Studenten an hunderte Unternehmenskunden raus. Da muss eine Zeiterfassung, also ein Leistungsnachweis erfolgen, damit die Leistung der Studenten dann abgerechnet werden kann. Auf der anderen Seite müssen die Unternehmen sehen, was gearbeitet wurde und müssen das auch bestätigen können. Das klingt relativ simpel. In Wirklichkeit steckt dahinter ein aufwändiger Prozess, von dem wir vieles noch auf Papier machen. Mittlerweile entsteht für viele Mitarbeiter ein enormer Aufwand und wir versuchen das nun zu optimieren.

Wie genau seid ihr da rangegangen?

Am Anfang stehen die Requirements. Wir brauchten eine neue Variante zur Zeiterfassung und die geleisteten Zeiten sollten so schnell wie möglich den Unternehmen zur Freigabe übermittelt werden. Wir haben zwei Entwicklerteams, einmal für die Studentenseite und einmal für die Unternehmensseite. In den Gesprächen mit den Product Ownern der Teams haben wir schnell gemerkt, dass dies ein perfektes Thema für einen Design Sprint ist, da man absolut radikal sein kann. Im schlimmsten Fall weiß man nämlich am Ende der Woche, dass wir zu weit gegangen sind. Das ist mir eigentlich auch das Liebste, wenn am Freitag eines Design Sprints die Studenten im Test sagen, dass die Lösung völlig übertrieben ist.

Warum ist es besser, wenn die Ergebnisse in einem Design Sprint radikal sind?

Wenn ich die sichere Lösung in der Mitte nehme, dann weiß ich nicht, wie weit wir hätten gehen können. Bei einem Design Sprint geht es darum, sich dem Problem bewusst zu sein und herauszufinden, was funktioniert oder auch nicht. Das ist dann die Grundlage für die eigentliche Konzeption. An eine Grenze zu stoßen zeigt, dass man etwas richtig gemacht hat.

Auf welche Art habt ihr den Sprint umgesetzt? Welche Learnings aus den vorherigen Sprints habt ihr umgesetzt?

Beim ersten Design Sprint war mir die Methode noch komplett neu. Ich war gerade zu Studitemps gekommen und wir haben den ersten Sprint mit 25 Leuten veranstaltet. Heute sind es maximal acht Leute. Ich kann mir bis heute nicht vorstellen, wie es passieren konnte, dass dieser Sprint zu guten Ergebnissen geführt hat. Es war das pure Chaos, aber wir haben es irgendwie geschafft. Das war also eins der Learnings: lieber eine kleine Gruppe und dafür die richtigen Leute.

Das Wichtigste an Design Sprints ist, dass das Team aus den Leuten zusammengestellt ist, die die meiste Kompetenz zu diesen Fragen im Unternehmen mitbringen. Das ist oftmals die Geschäftsführung und die Teamleads, also Personen, die überhaupt keine Zeit für sowas haben. Da geht dann alle fünf Minuten die Tür auf und jemand will wirklich nur ganz kurz eine Frage stellen. Deswegen finden bei uns Design Sprints immer off-site in einem externen Raum statt. Dann hat man den Fokus und niemand stört einen. Das war ein schmerzhaftes Learning. Aber das Geld für den externen Raum lohnt sich einfach.

Wie war das Team diesmal zusammengesetzt?

Das Team war aus verschiedenen Standorten zusammengestellt. Studitemps hat 19 Standorte in Deutschland und wir haben die Leute reingeholt, von denen wir das Gefühl hatten, das sind die Richtigen für diese Kompetenzen. Die Leiterin der Abteilung zum Thema Leistungsnachweis und Zeiterfassung war mit dabei. Sie hat das Know-how und vor allem kennt sie die Pain Points im Prozess. Das war besonders am Montag eine Erfahrung für uns. Denn wir kannten natürlich das Problem. Aber direkt die Erfahrungen mitzubekommen, war sehr wertvoll. 

Wie sind dann die einzelnen Tage über die Bühne gegangen?

Wir versuchen uns an den Leitfaden aus dem Buch zu halten, weil das für uns am besten funktioniert. Ich bin zwar schon dabei die eine oder andere Stelle ein bisschen abzuwandeln, aber die ersten Sprints möchte ich wirklich erst mal nach Plan machen, um herauszufinden, wie das sein soll.

Am Montag geht es also los. Wir haben uns im Cowoki, einem Kölner Coworkingspace, getroffen. Du warst ja auch dabei. Den Anfang macht eine Übung, die wir “Karibik oder Chorweiler” genannt haben. Dabei geht es darum, zwei Szenarien zu entwerfen. Bei der einen geht es darum zu zeigen, was passiert, wenn alles schiefläuft. Bei der anderen, wie die Welt in zwölf Monaten aussieht, wenn alles nach Plan läuft. Dann schaut man sich die Problemstellung an und stellt “How-might-we”-Fragen, die am Ende des Tages an der Wand stehen. Wie können wir es schaffen, dass Leistungen automatisch erfasst werden?

Das Ziel des Montags ist es, das Problem in der Tiefe zu verstehen. Es gilt die Fragestellung für die nächsten Tage zu erarbeiten. Dieser Tag wird im Buch als Auspacken beschrieben. Jeder legt auf den Tisch, was er weiß und man merkt, wo man im Team steht.

Der Dienstag ist dann der Tag, der sich gut zum Fotografieren eignet.

Genau, denn da geht es ans Sketchen. Dienstag ist der Tag, an dem es an die Lösungsansätze geht. Dazu schaut man sich auch an, was es bereits auf dem Markt gibt und stellt das in Lightning-Demos vor.

Dann kommt der spaßige Teil, die Crazy-Eight-Methode. Man nimmt ein Blatt Papier, faltet es dreimal, sodass man acht Felder bekommt und zeichnet innerhalb von jeweils 30 Sekunden acht Solutions, acht Ideenansätze. Das findet unter Zeitdruck statt und bringt die Leute auch erst mal zum Schwitzen. Der erste Versuch geht in der Regel in die Hose und das ist auch völlig in Ordnung. Die Hand wird lockerer und man merkt plötzlich, wie viel man mit einer Strichfigur und einem Pfeil ausdrücken kann. Wenn das Team dann die Angst vor dem Sketchen verloren hat, nimmt man sich ausreichend Zeit, um die eigenen Ideen auf sogenannten Solution Sketches für den Rest des Teams festzuhalten.

Der Output des Dienstags sind die Solution Sketches. Wir legen sie auf einen Stapel und gehen nach Hause.

Mittwoch.

Mittwoch ist Entscheidungstag. Während eines Design Sprints lernt man, dass Gruppenentscheidungen nicht funktionieren. Darum hängt man mittwochs erst mal die ganzen Solution Sketches an die Wand. Man könnte jetzt anfangen darüber zu diskutieren. Aber das ist Zeitverschwendung. Stattdessen schaut man sich in einer stillen Übung alle Sketches an und jeder darf Punkte vergeben. Dazu nehmen wir Klebesticker und jeder kann so viele Sticker kleben, wie er will. Daraus entsteht eine Heatmap. Es folgt eine Speed Critic, bei der der Moderator drei Minuten über jedes Sketch etwas sagt.  Dabei kommen häufig ganz neue Aspekte heraus, die der Sketcher sich eigentlich anders gedacht hatte. 

Dann wird erneut abgestimmt und die Bewertung verschiebt sich meist etwas. Wir nehmen dafür unterschiedliche Größen an Stickern, damit man den Unterschied zwischen dem ersten und zweiten Voting sieht. Dann kommt der Super Vote. Jeder hat genau einen Sticker und den klebt man dort hin, wo man sagt, das muss unbedingt in den Prototypen mit rein.

Wie wird dann letztendlich entschieden?

Im Sprint gibt es immer eine Person, die sich Entscheider nennt. Diese Person hat bei kritischen Fragen den Hut auf und besitzt mehrere Super Votes. Am Ende des Mittwochs hat man dann alle Teile, die man in den Prototypen baut. 

Bauen bedeutet was?

Bauen bedeutet Prototypisieren. Das kann auf einem Stück Papier passieren, wenn das funktioniert.

Wie habt ihr den Prototypen umgesetzt?

Wir haben den Prototypen in Sketch gebaut und mit InVision auf einem iPhone klickbar gemacht. Die Daten waren von uns reingeschrieben und es ging letztlich nur darum das Gefühl einer echten App zu vermitteln.

Dazu teilt man sich in der Regel in drei Teams auf. Team 1 baut den Prototypen. Team 2 überlegt sich den Content für den Prototypen, denn Prototypen mit Lorem-Ipsum-Texten funktionieren schlecht. Das dritte Team organisiert das folgende Interview und entwickelt einen Leitfaden für den Freitag.

Freitag ist dann Testing angesagt.

Genau. Aus hundert Bewerbern haben wir bereits im Vorfeld fünf Kandidaten ausgesucht. Zurück bei Studitemps, haben wir in einem Meetingraum ein Testgerät und eine Kamera aufgebaut. Wir streamen das für gewöhnlich in einen anderen Raum, wo wir die Interviewsituation sehen und Mimik und Gestik ablesen können. Die Aufgabe des Interviewers ist das Interview zu führen, die Leute willkommen zu heißen, sich mit den Kandidaten zu unterhalten und Fragen zu stellen. Dabei geht es auch darum, die Tester besser kennenzulernen und herauszufinden, was sie so den ganzen Tag machen, um die Probleme besser verstehen zu können. Dafür reicht es dann auch mit fünf Leuten zu sprechen. 

Welche Ergebnisse konntet ihr aus diesem Design Sprint ziehen?

Wir haben zwei Design Sprints zum Thema Leistungsnachweis gemacht. Auf der Studentenseite kam heraus, dass wir sehr technologisch werden können, ohne Leute zu verschrecken. Das ist ein sehr gutes Zeichen für uns.

Auf Unternehmensseite haben wir gesehen, dass eine einfache, schöne Lösung die Kunden glücklich macht.

Was geschieht nun mit den Ergebnissen des Design Sprints?

Meine Aufgabe nach dem Sprint ist die Ergebnisse zu digitalisieren und in Confluence einzugeben. Dann setzen wir uns mit den Product Ownern zusammen, die oftmals auch im Sprint dabei waren und fassen die Ergebnisse zusammen. Danach stellen wir sie dem Team vor und nutzen das als Sprungbrett, um daraus ein Konzept zu erstellen.

Aktuell sind wir in der Konzeptionsphase, die wir aber auch agil gestalten. Es geht also nicht darum, jetzt eine Spec zu schreiben und das dann einfach so zu bauen. Sondern auch hier nähern wir uns dem Problem und werden das in den Entwicklerteams Stück für Stück umsetzen. Der erste Schritt wird ein MVP sein. Da geht es dann zum Beispiel auch um die Frage, welche Technologie wir nutzen, um das umzusetzen. Aber das passiert immer im Austausch mit den Stakeholdern.

Das klingt so, als ob ihr vom Format der Design Sprints sehr überzeugt seid.

Absolut. Wir sind im Ganzen sehr begeistert. Man merkt, es kommt eine große Wertschätzung rüber, besonders aus den Fachabteilungen. Endlich, ihr hört auf uns, ihr löst unsere Probleme wirklich, heißt es da.

Ich kann jedem nur empfehlen Sprints auszuprobieren. Der erste und der zweite werden vielleicht eher noch ein bisschen hakelig sein. Aber wenn man sich reinfuchst und sich mit den richtigen Leuten eine Woche zusammensetzt, um die Ergebnisse rauszukitzeln, dann hat man ein sehr wertvolles und mächtiges Tool in der Produktentwicklung. Zu überschaubaren Kosten.

Welche Tools nutzt ihr später in der Produktentwicklung?

Wir arbeiten mit Jira und Confluence. Wireframes entwerfen wir, wie schon gesagt, mit Sketch. Bis vor zwei Jahren habe ich noch alles in Photoshop gemacht und mich lange gegen Sketch gewehrt. Das liegt sicher auch an meiner Vergangenheit. Aber die Jungs von Bohemian Coding haben wirklich ein unglaublich geiles Tool hingestellt. In Kombination mit dem Plugin Craft von InVision, einer Art Werkzeuggürtel, mit dem ich Dummy-Content in Mockups reinladen kann, haben wir einen Flow, der unglaublich viel Zeit spart.

Ich bin immer auch auf dem Sprung mal Adobe Experience Design auszuprobieren.

Du hast es eben angesprochen: Du hast in der deiner Vergangenheit viel Photoshop genutzt. Welches war deine Einsteigerversion?

Photoshop 4. Wobei ich damals noch viel Adobe Fireworks und PaintShop Pro verwendet habe. Ab ab 6 wurde Photoshop dann richtig geil.

Welchen beruflichen Werdegang hast du?

Nach der Schule habe ich eine Ausbildung zum Mediengestalter in einer Werbeagentur in Bonn gemacht. Werbung und Grafik waren absolut mein Thema. Danach war ich einige Jahre in der Agenturwelt zu Hause und habe dann Ibrahim Evsan kennengelernt, der damals sein neues Startup United Prototype und Fliplife aufbaute. Damals hatte ich mich bereits mit Icon-Design beschäftigt und er brauchte dringend einen guten Interface- und Icon-Designer. Da ich in der Agenturwelt sehr glücklich war, war ich zunächst Freelancer. Nach einem halben Jahr habe ich gemerkt, wie geil die Startup-Welt ist und bin dann komplett in diese Welt abgetaucht.

Dann wurde Fliplife verkauft.

Genau. Danach war ich selbstständiger Grafikdesigner, was sehr gut funktionierte. Mit meinem Partner Ali haben wir dann Reputami gegründet, ein Startup, das sich mit Online-Reputationsmanagement für die Hotellerie und Gastronomie beschäftigte. Dieses Startup habe ich viereinhalb Jahre aufgebaut und Investoren und Kunden an Bord geholt. Ende 2015 haben wir an eKomi in Berlin verkauft, die es bis heute fortführen. Wir haben uns dann aus dem operativen Geschäft zurückgezogen. Wir waren damals 15 Mitarbeiter.

Wie ging es dann weiter?

Die viereinhalb Jahre mit Reputami waren schon wirklich knallhart und es war wenig Zeit für alles andere. Darum habe ich meiner Frau versprochen, dass ich erst mal nicht wieder gründe und wir haben uns auf das Privatleben fokussiert. Kurz darauf haben wir dann erfahren, dass meine Frau schwanger ist.

Herzlichen Glückwunsch! Wann kam dann Studitemps ins Spiel?

Benni, der Gründer von Studitemps hat mich zum Mittagessen eingeladen und mir von den Wachstumsschmerzen seines Unternehmens erzählt. Wir merkten schnell, dass es gut passen würde und haben kurz darauf eine Stelle für UX bei Studitemps geschaffen.

Wo hast du in deinem Werdegang den Sprung von der klassischen Grafik zu UX gemacht?

Ab dem Moment, als ich bei Fliplife das User-Interface gestaltet habe. In dem Zusammenhang kam oftmals die Frage: Warum ist das denn besser, wenn das anders ist? Also habe ich mich mit der ganzen Theorie und den Methoden beschäftigt. Ich wollte wissen, wie ich wirklich herausfinden kann, was die User wollen. Ich entdeckte diesen theoretischen Teil von User Experience. Ich merkte was dahintersteckt und was für ein riesengroßes Aufgabenfeld sich da auftut.

Gibt es ein Learning, von dem du heute noch bei Studitemps zehrst?

Gerade bei Reputami habe ich gemerkt, dass das geilste Produkt sich nicht selbst verkauft. Niemand wartet darauf und fragt, ob er das haben kann. Das passiert nicht. Es ist eines der wichtigsten Learnings, dass Produkt und Produktmanagement und geile UX und ein tolles Feature-Set nicht ausreichen, um meine Firma und mein Produkt erfolgreich zu machen. Sondern das ein guter Sales-Prozess extrem wichtig ist.

Was sind für dich die aktuellen Themen und Trends im Bereich UX?

Das Thema Prototyping wird immer größer. Die Diskussionen, ob Prototyping überhaupt sinnvoll ist, sind verstummt. Laut einer Forbes-Studie von 2014 kostet das Fixen eines Problems in der Design-Prototyping-Phase circa 5 Dollar und nach dem ersten Release circa 30 Dollar. Einfach weil das Team ein größeres ist. Die Tools entwickeln sich immer weiter und in diesem Zuge natürlich auch die Methoden wie Design Sprints.

Komischerweise lese ich in letzter Zeit immer häufiger von Leuten, die versuchen das klassische Thema der Personas, wie von Alan Cooper entwickelt, neu aufzurollen. Ich kann darauf noch keine Antwort geben, denn wir arbeiten bei Studitemps sehr gerne und sehr viel mit Personas. Ich finde es aber spannend zu beobachten, dass es mittlerweile neue Ansätze gibt. Dazu lese ich sehr viel und versuche am Puls der Zeit zu bleiben.

Wo liest du da zum Beispiel?

Uxdesign.cc ist sehr gut. Ich mag den Blog von MarvelApp sehr. Außerdem verbringe ich viel Zeit auf Medium unter verschiedenen Tags, wie “UX Design” und “Design Sprint.” Da findet man immer die neusten Artikel und bleibt sehr gut auf dem Laufenden. Des Weiteren kann ich jedem den Twitter Account von InVision sehr ans Herz legen. Die Kollegen teilen sehr viel und gern gute Artikel rund um UX.

Hast du zum Schluss unseres Interviews noch den ultimativen UX-Tipp?

Mein Rat für alle, die User Experience machen wollen: Redet mit allen, die eure Produkte benutzen und redet mit allen, die sie potentiell benutzen. Hört zu und findet heraus, wie ihr deren Bedürfnisse wirklich erfüllen könnt. Das ist, glaube ich, das Wichtigste, was man als UX-Spezialist machen muss: zuhören.

Lieber Oliver, vielen Dank für das Interview.

Webseite: 7 Hacks für euren Google Design Sprint

Dieses Interview wurde am 24. Mai 2017 in den Räumlichkeiten von Studitemps geführt. Die Bilder und Videos des Design Sprints entstanden vom 24. bis 26. April im Coworkingspace Cowoki in Köln.