Schnell, pragmatisch, inkrementell: Das könnt ihr von GitHub über Product Design lernen

Moritz Meyer

Read this article in English.

Im Produktdesign der weltgrößten Entwicklerplattform geht es vor allem um eins: Userfeedback, so schnell wie möglich. In diesem Text erfahrt ihr von Senior Director of Product Design Max Schoening, mit welchen Methoden GitHub das anstellt.

Ein neues Feature bei GitHub beginnt manchmal ganz pragmatisch. Eine schnelle, handgezeichnete Skizze, die auf Twitter an ein paar Follower rausgeschickt wird, genügt Max unter Umständen als erste Version eines sehr einfachen Prototyps. Denn um zu verstehen, ob eine Idee in die richtige Richtung geht, muss sie nicht perfekt sein, sagt Max bei unserem Gespräch im GitHub-Office in San Francisco. Wichtig ist, dass man sie schrittweise weiterentwickelt und verbessert. “Incremental Correctness” nennt Max diesen Prozess. Es ist der zentrale Wert in der Product Design Philosophie des Unternehmens.

Von Berlin nach San Francisco

Neue Ideen zu generieren und diese schnell und erfolgreich umzusetzen, wurde für Max zum Dreh- und Angelpunkt seiner Laufbahn. Für ein erstes Startup, eine Musikplattform á la Beatport, bringt er sich selbst Programmieren bei. Das Produkt scheitert, doch schon kurz darauf hat Max sein nächstes Projekt am Start: Cloud App, ein einfaches Filesharing-Tool. Für das Grafikdesign-Studium in Berlin bleibt immer weniger Zeit, und er entscheidet sich abzubrechen. Da kommt ein Anruf von der App-Entwicklerplattform Heroku, der Max’ Leben eine neue Wendung geben soll: Cloud App ist inzwischen zu einer der größten Apps auf Heroku gewachsen. Das Management ist beeindruckt und holt Max nach San Francisco. Für fünf Jahre wird er das Produktdesign bei Heroku leiten. Eins führt zum anderen: Bei Heroku trifft Max auf Jason Warner, damals Head of Engineering bei der App-Platform. Zwischenzeitlich hatte Max – was man in San Francisco halt so macht – mit Canvas noch ein weiteres Startup gegründet und an Google verkauft. Doch dann lotst Warner, inzwischen SVP Engineering bei GitHub, Max zu der Entwicklerplattform. Dort verantwortet er jetzt als Senior Director das Product Design.

Designing GitHub

Mit 36 Millionen Nutzern ist GitHub eine der beliebtesten Plattformen für Entwickler. Rund 1000 Mitarbeiter arbeiten für das Unternehmen, das 2018 von Microsoft übernommen wurde. Gemeinsam mit Shanku Nyogi, dem SVP of Product, und Jason Warner, SVP of Engineering, ist Max Teil des EPD-Leadershipteams. Diese Aufteilung in Engineering, Product und Design zieht sich bei GitHub durch alle Ebenen im Tech-Department. Jedes EPD-Squad verantwortet einen bestimmten Bereich, in dem es weitgehend autonom arbeitet, zum Beispiel Pull Requests, Issues oder GitHub Desktop. Die Rolle der Produktdesigner bei GitHub beschreibt Max so: “Meine Aufgabe ist es, mit meinem Team Lösungen für die Probleme unserer Kunden zu finden und diese so zu gestalten, dass sie intuitiv und so zugänglich wie möglich sind.”

UX/Design Jobs

Um den Look von GitHub kümmert sich hauptsächlich das Team Marketing Design. Die Kreativabteilung kümmert sich um  die „Logged-Out-Experience“ der Plattform, die Brand Identity, aber auch alles, was mit der Octocat zu tun hat. Dazu gehört zum Beispiel der populäre Merchandise mit dem Konterfei des ikonischen GitHub-Maskottchens. Aber auch die große Bronzestatue des vielarmigen Stubentigers im Foyer des Unternehmens wurde inhouse entworfen. Besonders stolz sind sie bei GitHub auf die animierten Kurzfilme, die auf verschiedenen GitHub-Universe-Konferenzen gezeigt wurden.

Bei uns arbeiten Trickfilmer, die könnten auch bei Disney arbeiten.

Zum Produktdesign werden die Marketing Designer immer dann dazu geholt, wenn die CI von GitHub Auswirkungen auf die User-Experience hat. Dazu gibt es die Abteilung „Design Infrastructure“, die organisatorisch zum Produktdesign gehört und die das Designsystem von GitHub weiterentwickelt: “Bei einem Produkt wie Github ist es wichtig, dass alles, was wir machen, einheitlich und skalierbar gemanagt werden kann. Dafür braucht man ein Designsystem. Unseres heißt Primer, es ist als Open Source auf GitHub verfügbar”, erklärt Max. Auch Customer Research und übergreifende Elemente wie die Navigation gehören zu Design Infrastructure.

Die Produktdesigner von GitHub sind in ihren EPD-Squads eng in das Produktmanagement und in die Entwicklung eingebunden. Max: “Alle Produktdesigner schreiben und veröffentlichen Code für unsere Interfaces, in unserem Fall sind das hauptsächlich HTML, CSS und so weiter. Sie arbeiten aber auch schon in der Ideation Phase mit den Produktmanagern zusammen. Wir glauben sehr stark an das Prinzip von Discovery and Delivery als zwei Seiten einer Medaille. Unsere Designer sind im gesamten Prozess dabei, helfen also mit, das Problem zu identifizieren, die Lösung zu finden und diese dann auch zu implementieren. Da wir so hochqualifizierte Leute haben, trennen wir auch nicht nach Disziplinen wie UX-Design, UI-Design oder Frontend Development.”

So lebt GitHub „Incremental Correctness“

Der wichtigste Grundsatz im Entwicklungsprozess von GitHub ist Incremental Correctness. “Im Grunde ist das die GitHub-weise zu sagen: Iterate fast!”, sagt Max. Hier sind vier Methoden aus dem Baukasten von GitHub, mit denen man es schafft schnell zu iterieren.

#1 Optimiere die Zeit bis zum ersten Nutzerkontakt

Am Anfang eines neuen Features steht bei GitHub der Nutzer. Dessen Probleme zu identifizieren ist Aufgabe des Produktmanagements. GitHub arbeitet dafür mit Personas. Die Produktmanager sprechen mit entsprechenden Usern, um herauszufinden, wo die sich auf der Plattform schwer tun oder wie man ihre Nutzererfahrung verbessern könnte. Max gibt ein Beispiel: “Kürzlich haben wir ein Feature gelauncht, dass sich Suggested Changes nennt. Manchmal ist man auf einem Pull-Request und möchte einfach einen Vorschlag machen im Sinne von: Hey, wie wäre es, wenn wir es eher so machen? Und dann schreibt man eine Zeile Code dazu. Bei Nutzerbefragungen kam heraus: Der Loop, eine Veränderung bei einem Pull-Request vorzuschlagen, ist viel zu groß, weil man dafür einen weiteren Pull-Request aufmachen muss.” Die naheliegende Idee: Könnte man es nicht einfach wie bei Google Docs machen, wo die Nutzer solche Vorschläge direkt inline machen können?

An dieser Stelle kommt Design dazu und überlegt: Wie müsste eine Version davon aussehen, die wir so schnell wie möglich dem Kunden zeigen können? Max erklärt, was das im Alltag bedeutet: „Abhängig von der Komplexität kann der erste Entwurf auch mal eine schnelle Skizze auf Papier sein, mit der wir auf Twitter gehen und sie ein paar Followern zeigen, die wir kennen. Das reicht schon, um einen ersten Eindruck davon zu bekommen, was unsere User davon halten.“ Ist detaillierteres Feedback nötig, laden die Produktdesigner zum Beispiel in Videomeetings via Zoom ein und teilen Entwürfe via Screensharing. Dabei kommt Max und seinem Team eine Sache entgegen:

Unsere Nutzer lieben es, Feedback zu geben, weil sie das Produkt so sehr lieben. Wir haben nie ein Problem damit, Nutzer aufzutreiben, wir müssen sie einfach nur fragen.

Doch egal wie das Feedback eingeholt wird: Wichtig ist, dass es schnell geht und Ergebnisse liefert, die den Designern helfen, in die nächste Iteration zu gehen.

#2 Lerne doppelt so viel in der Hälfte der Zeit.

Was Max vermeiden möchte: Dass es immer aufwändiger wird, Feedback einzuholen, je komplexer die Entwürfe werden. Denn damit würde es immer länger dauern, von einer Iteration in die nächste zu kommen. Das Gegenteil ist das Ziel: Mit jedem Schritt noch mehr und noch schneller Informationen über die Nutzer zu bekommen. Damit diese Gleichung aufgeht, kann man zwei Variablen beeinflussen. Entweder, erklärt Max, verbessert man den Grad der Fidelity des Prototyps. Oder man erhöht die Zahl der Nutzer, um zu testen, ob es zu einem Prototypen noch zusätzliches Feedback von anderen Nutzergruppen gibt. Wichtig ist dabei vor allem, in kleinen Schritten voranzuschreiten. Die Alarmglocken gehen bei Max an, „wenn wir das Gefühl haben, wir müssen gerade eine wirklich große Entscheidung treffen. Dann ist unser Prozess nicht fein genug abgestimmt. Es sollte sich nie so anfühlen, als würde man gerade von einer Klippe springen.”

#3 Graduelle Verbesserungen statt großer Würfe

Entscheidend für die Fidelity ist die Balance zwischen Aufwand und Ertrag. Das Team muss die Komplexität soweit erhöhen, damit es neue Annahmen beim Nutzer sauber validieren kann, ohne dass der Arbeitsaufwand unverhältnismäßig ist.

Die GitHub-Designer nutzen in dieser Phase Tools wie Keynote oder Figma, um die Prototypen zu verbessern, haben aber auch dabei viele Freiheiten. “Die Tools sind nicht so wichtig an dieser Stelle”, betont Max. “Incremental Correctness” bedeutet für ihn, dass in jeder Phase genau das funktionieren muss, auf dass es gerade ankommt: “Die User Story muss stimmen. Eine Skizze wird natürlich nie das zeigen, was später das fertige Inerface zeigt. Wichtig ist, dass man gerade genug Material hat, um die Annahmen validieren zu können, die man zu diesem Zeitpunkt hat.” Er vergleicht diesen Prozess mit einer Filmproduktion: “Man startet mit einer Idee, die gleicht eher einem kurzen Comic. Mit jedem Schritt fügt man der Geschichte mehr Bilder und mehr Bewegung hinzu. Der 8k-Film in 60fps kommt erst ganz am Schluss. Aber man nähert sich dem Endergebnis schrittweise.”

Übersetzt in das Product Design bedeutet das: Es beginnt mit einer schnellen Skizze, entwickelt sich zu einem klickbaren Figma-Prototypen und irgendwann werden tatsächlich die ersten Zeilen Code geschrieben. Aber auch dann gilt für Max: Hauptsache, es funktioniert erst mal. “Der Code in den ersten Versionen muss noch nicht mal skalierbar sein. Wir können auf GitHub über ein Feature Flagging System bestimmte Features gezielt an eine handvoll Nutzer rausgeben und sie damit arbeiten lassen,” erklärt Max und fügt augenzwinkernd hinzu: “Wenn wir diesen Nutzern das Feature wieder wegnehmen und sich alle tierisch darüber aufregen, dann wissen wir, dass es ein sehr gutes Feature ist.” Doch um wirklich sicherzugehen, reicht es nicht, nur mit ein paar Dutzend Usern zu testen.

#4 Wenn das Feedback gleich bleibt, vergrößere das Testpublikum

Auch wenn die Zahl der Nutzer, die ein neues Feature ausprobieren sollen, erhöht wird, geht GitHub Schritt für Schritt vor. In der Regel beginnt es mit einer Handvoll Nutzer, bevor es dann zu ein paar Dutzend über Hundert bis zu mehreren tausenden Usern geht. Ziel ist es, solange mit dem Feedback einer Nutzergruppe zu arbeiten, bis von denen nichts Neues mehr kommt. Heißt konkret: Die Nutzer geben kritisches Feedback zur Funktion eines bestimmten Features. Dann wird das Team solange mit den gleichen Nutzern arbeiten, bis

a) entweder den Nutzern klar geworden ist, warum das Feature, so wie es ist, richtig ist, oder

b) das Feature soweit verbessert wurde, dass kein zusätzliches Feedback mehr kommt.

Das ist der richtige Moment, die Zielgruppe zu vergrößern und zu testen, ob sich mit mehr Nutzern auch die Art des Feedbacks verändert. Dieser Prozess wiederholt sich solange, bis man am Punkt für einen “GA-Release” ist, also General Availability. Das ist der Moment, ab dem bei GitHub ein Feature allen 36 Millionen Nutzern zur Verfügung steht.

Die richtige Balance von Freiheit vs. Verantwortung

Die Aufgabe des Senior Managements in diesem Prozess besteht darin, die richtige Balance zwischen Freiheit und Verantwortlichkeit herzustellen. “Was wir nicht wollen ist, dass jede Entscheidung immer die komplette Hierarchie hoch und wieder runter gehen muss, sonst wären wir nicht agil”, sagt Max. Gleichzeitig gilt: “Wir müssen dafür sorgen, dass dabei alle Teams aligned sind.” In der Praxis bedeutet das zum Beispiel, dass die Teams ihre Sprintzyklen frei einteilen können, üblicherweise dauern diese ein bis drei Wochen.

Wir reden nicht so gerne von Sprints, sondern  von Cycles. Sprints implizieren, dass man versucht, sehr schnell zu rennen, und diese Vorstellung gefällt nicht jedem.

Um Verantwortlichkeit herzustellen, definieren die Teams vor dem Cycle, was sie erreichen möchten und wie sie messen wollen, ob das Ziel erreicht wurde.

UX/Design Jobs

Mit Videos die User Story visualisieren

Zum Ende des Sprints präsentieren die Teams ihre Ergebnisse dem EPD-Management. Dabei kommt es weniger darauf an zu zeigen, dass man alles abgehakt hat, was auf der To-Do-List stand, sagt Max: “Wir wollen, dass die Teams die Userstory erzählen und uns in einer Demo zeigen, was der User nun tun kann.” Wie die Präsentation aussieht, ist aber den Teams überlassen, da gibt es nur wenige Vorgaben. Das gibt den Teams die Möglichkeit, kreativ zu werden und zusätzliche kleine Anreize für die Teammitglieder zu setzen. Max berichtet uns von einem Team, das seit sechs Monaten jede Woche ein neues Video für diese Sprintreviews erstellt. Mehr Aufwand, der sich auszahlt: “Es ist ein Team, das insgesamt sehr gut arbeitet und zuverlässig delivert. Das zeigt, wie der Mechanismus von Freedom und Accountability funktioniert.”

Diese Reviews sind deshalb wichtig, weil sie den Teams den richtigen Kontext für ihre Arbeit liefern. Üblicherweise präsentieren die EPD-Squads ihre Ergebnisse vor dem Senior Product Management von GitHub. Die Aufgabe des Leadershipteams ist aber nicht zu entscheiden, welches Feature releast wird und welches Team zurück ans Whiteboard muss. “In der Regel werden in diesen Meetings eine ganze Menge Fragen gestellt”, erklärt Max. “In der Idealsituation beginnt jede Frage mit: Wie könnten wir…? Wie könnten wir Sign-Ups erhöhen oder: Wie könnten wir die User dazu bringen, ein neues Feature zu benutzen?” Mit diesen Fragen im Gepäck ist das Team in der Lage, seine weiteren Aufgaben zu definieren und zu priorisieren.

Fester Rahmen mit Bewegungsfreiheit

Die Verantwortung des Managements liegt darin, die Anforderungen an die Teams richtig zu setzen, sagt Max: “Man kann sich das wie einen Rahmen vorstellen, der den Teams vorgibt, bis wohin sie sich bewegen können. Wenn der Rahmen zu sehr hin- und her bewegt wird, stoßen die Teams zu schnell an die Grenzen. Und das ist schlecht. Was wir wollen ist, dass die Teams viel Bewegungsfreiheit haben. Der Rahmen für das Team sollte aber immer etwas zu groß sein, so dass das Team sich herausgefordert fühlt und das Gefühl hat, sich weiterentwickeln zu können.”

Seine Rolle in diesem Prozess beschreibt Max so: “Ich versuche, meinem Team dabei zu helfen, so viele eigene Entscheidungen wie möglich treffen zu können.” Entscheidend dafür ist es, die Kommunikation unter den Teams in die richtigen Bahnen zu lenken. “Ich vergleiche meine Aufgabe mit den Menschen, die in den 1960er Jahren in Telefonzentralen an den riesigen Schalttafeln saßen und die Gespräche miteinander verbunden haben. Ich muss sicherstellen, dass die Teams, die miteinander sprechen sollten, auch wirklich zusammen kommen, so dass sie bessere Entscheidungen treffen können.”

Working Remote bei GitHub

Das gilt umso mehr, als Remote Work Teil der DNA von GitHub ist: Ein Drittel der 1000 Mitarbeiter arbeitet nicht im Hauptquartier in San Francisco auf der Brannan Street. Das ist gerade für Design eine große Herausforderung, weil viele Prozesse damit starten, dass Menschen in einem Raum zusammenkommen und Ideen an einem Whiteboard skizzieren. “Das perfekt zu replizieren, hat bis jetzt noch kein Startup geschafft”, sagt Max seufzend. Realtime-Collaboration-Tools für Designer wie Figma, Screensharing via Zoom oder iPads, auf denen man scribblen kann, helfen dabei, Prozesse zu simulieren, die ansonsten vor Ort stattfinden würden.

Software verändert die Welt und niemand sollte gezwungen werden, nach San Francisco ziehen zu müssen, wenn er ein Teil davon sein möchte.

Trotz der Schwierigkeiten hält Max Remote für unverzichtbaren Bestandteil der GitHub-Philosophie: „GitHub ist wahrscheinlich die größte Maker-Community auf diesem Planeten und ermöglicht es Menschen, die am komplett anderen Ende der Welt sitzen, gemeinsam an Projekten zu arbeiten. Darum ist es wichtig und großartig, dass auch bei GitHub selber Menschen aus aller Welt zusammenarbeiten.“

Das Gespräch mit Max Schoening haben wir am Montag, 18. März 2019, bei GitHub in San Francisco geführt. Mit Max sprachen Moritz Meyer und Stefan Vosskötter.

Fotos: Thomas Riedel.