Bessere Zusammenarbeit durch Einbeziehung von Designern in den Code-Review-Prozess

Eine reibungslose Zusammenarbeit zwischen Entwicklern und Designern ist etwas, das jeder anstrebt, aber es ist notorisch schwierig. Aber mit dem modernen Web von heute ist es schwierig – wenn nicht sogar unmöglich –, ein wirklich großartiges Produkt zu entwickeln, ohne interdisziplinär zusammenzuarbeiten. Aufgrund der Bandbreite an Technologien, die zum Erstellen eines Produkts erforderlich sind, kann das Produkt nur dann wirklich erfolgreich sein, wenn alle Disziplinen – Entwickler und Designer, Ersteller von Inhalten und Strategen für die Benutzererfahrung – von den frühen Phasen des Projekts an intensiv eingebunden werden. Wenn dies geschieht, fügen sich alle Enden dessen, was zum Bau eines Produkts erforderlich ist, auf natürliche Weise zu einem einheitlichen Ganzen und somit zu einem großartigen Produkt zusammen.

Aus diesem Grund fördert niemand mehr wirklich Wasserfallprozesse. Dennoch kann es beängstigend sein, andere Personen, insbesondere Personen aus anderen Disziplinen, frühzeitig einzubeziehen. Im schlimmsten Fall führt dies zum „Design by Committee“.

Darüber hinaus haben sowohl Designer als auch Content-Strategen oft einen Hintergrund in Bereichen, in denen ein einziges kreatives Genie immer noch das Ideal ist. Wenn jemand anderes Ihre Arbeit prüft, kann das wie eine Bedrohung für Ihre Kreativität wirken.

Wie also können Sie die Leute frühzeitig einbeziehen, um den Wasserfall zu vermeiden, aber auch sicherstellen, dass Sie sich nicht auf ein Design von Gremien einstellen? Ich habe meine Antwort gefunden, als ich etwas über Code-Reviews gelernt habe.

Das Aha! Moment

Im Juli 2017 habe ich Confrere zusammen mit zwei Entwicklern gegründet, und wir haben schnell unseren ersten Ingenieur eingestellt (ich bin selbst kein Entwickler, ich bin eher ein UX- oder Content-Designer). Unsere Zusammenarbeit verlief überraschend reibungslos, so sehr, dass bei unseren Retrospektiven das wiederkehrende Thema war, dass wir alle das Gefühl hatten, „es richtig zu machen“.

Ich habe mich mit meinen Kollegen zusammengesetzt, um herauszufinden, was genau wir „richtig gemacht“ haben, damit wir versuchen konnten, dieses Gefühl zu bewahren, auch wenn unser Unternehmen wuchs und unser Team größer wurde. Wir stellten fest, dass wir alle es zu schätzen wussten, dass das gesamte Team frühzeitig eingebunden wurde und dass wir ehrlich und klar in unserem Feedback zueinander waren. Unser CTO Dag-Inge fügte hinzu: „Es funktioniert, weil wir es auf Augenhöhe tun. Man wird nicht beschimpft und bekommt nur eine Fehlerliste“.

Das Wort „Peer“ hat mir das Aha-Erlebnis beschert. Mir wurde klar, dass diejenigen von uns, die in den Bereichen UX, Design und Inhalte arbeiten, viel von Entwicklern lernen können, wenn es um Zusammenarbeit geht.

Peer-Reviewing in Form von Code-Reviews ist für die Erstellung von Software unerlässlich. Für mich bieten Code-Reviews Inspiration für die Verbesserung der Zusammenarbeit in unseren eigenen Bereichen, aber auch ein Modell für die Zusammenarbeit über Bereiche und Disziplinen hinweg.

Wenn Sie bereits mit Codeüberprüfungen vertraut sind, können Sie den nächsten Abschnitt überspringen.

Was ist eine Codeüberprüfung?

Ein Code-Review kann auf verschiedene Arten durchgeführt werden. Heutzutage erfolgt die typischste Form der Codeüberprüfung in Form von sogenannten Pull-Requests (unter Verwendung einer Technologie namens Git). Wie unten dargestellt, teilen die Pull-Requests anderen Teammitgliedern mit, dass ein Entwickler Code fertiggestellt hat, den sie mit der Hauptcodebasis zusammenführen möchten. Es ermöglicht dem Team auch, den Code zu überprüfen: Sie geben Feedback zum Code, bevor er zusammengeführt wird, falls er verbessert werden muss.

Pull-Requests haben klar definierte Rollen: Es gibt einen Autor und einen oder mehrere Reviewer.

Nehmen wir als Beispiel an, unsere leitende Ingenieurin Ingvild hat eine Änderung am Anmeldefluss von Confrere vorgenommen. Bevor es mit der Hauptcodebasis zusammengeführt und versendet wird, erstellt sie (die Autorin) eine Pull-Anforderung, um eine Überprüfung von unserem CTO Dag-Inge (der Prüferin) anzufordern. Er wird keine Änderungen an ihrem Code vornehmen, sondern nur seine Kommentare hinzufügen.

Es liegt an Ingvild, wie sie auf das Feedback reagieren möchte, das sie in der Bewertung erhalten hat. Sie aktualisiert ihre Pull-Anfrage mit den Änderungen, die sie für richtig hält.

Wenn der/die Prüfer die Pull-Anforderung genehmigen, kann Ingvild ihre Änderungen mit der Hauptcodebasis zusammenführen.

Warum sich die Mühe machen, Code-Reviews durchzuführen?

Wenn Sie noch nie eine Codeüberprüfung durchgeführt haben, klingt der obige Prozess möglicherweise bürokratisch. Wenn Sie Zweifel haben, finden Sie hier eine Menge Blog-Posts und akademische Forschung über die Vorteile der Codeüberprüfung.

Code-Reviews geben für das gesamte Unternehmen den Ton an, dass alles, was wir tun, für die Überprüfung durch andere offen sein sollte und dass eine solche Überprüfung ein willkommener Teil Ihres Arbeitsablaufs sein sollte und nicht als Bedrohung angesehen werden sollte.

— Bruce Johnson, Mitbegründer von Full Story

Code-Review reduziert das Risiko. Jemanden zu haben, der Ihre Arbeit prüft, und auch zu wissen , dass jemand Ihre Arbeit prüft, hilft, Fehler auszusortieren und die Qualität zu steigern. Darüber hinaus sorgt es für Konsistenz und hilft jedem Teammitglied, sich mit der Codebasis besser vertraut zu machen.

Wenn es richtig gemacht wird, baut Code Review auch eine Kultur der Zusammenarbeit und Offenheit auf. Der Versuch, die Arbeit anderer zu verstehen und zu kritisieren, ist eine hervorragende Möglichkeit, etwas zu lernen, ebenso wie ehrliches Feedback zu Ihrer Arbeit.

Wenn immer mindestens zwei Personen den Code begutachten, wird auch die Vorstellung von „meinem“ Code und „Ihrem“ Code eingeschränkt. Es ist unser Code.

In Anbetracht dieser Vorteile sollte eine Überprüfung nicht nur für Code gelten.

Review-Prinzipien für alle Disziplinen, nicht nur Code

Bei Rezensionen gibt es immer einen Autor und einen oder mehrere Rezensenten. So können Sie frühzeitig Menschen einbeziehen, ohne in die Gremiengestaltung zu verfallen.

Zunächst muss ich zwei wichtige Faktoren erwähnen, die die Fähigkeit Ihres Teams beeinflussen werden, nützliche Reviews durchzuführen. Sie müssen diese nicht zwingend beherrschen, sollten aber mindestens Folgendes anstreben:

• Sie und Ihre Kollegen respektieren einander und die Disziplinen des anderen.
• Sie sind selbstbewusst genug in Ihrer eigenen Rolle, sodass Sie das Gefühl haben, sowohl Kritik äußern als auch annehmen zu können (dies hängt auch mit der psychologischen Sicherheit des Teams zusammen).

Auch wenn wir keinen Code überprüfen, gibt es eine Menge von bestehenden Best Practices für Codeüberprüfungen zu lernen.

Innerhalb unseres Teams versuchen wir, bei der Durchführung von Bewertungen die folgenden Grundsätze einzuhalten:

1. Kritisieren Sie die Arbeit, nicht den Autor.
2. Seien Sie kritisch, aber bleiben Sie umgänglich und neugierig.
3. Unterscheiden Sie zwischen a) Vorschlägen, b) Anforderungen, c) Punkten, die diskutiert oder geklärt werden müssen.
4. Verlagern Sie Diskussionen von Text zu Angesicht zu Angesicht. (Video zählt)
5. Vergessen Sie nicht, die guten Teile zu loben! Was ist clever, kreativ, solide, originell, lustig, nett und so weiter?

Aufgeschrieben wurden diese Grundsätze erst, nachdem wir besprochen hatten, warum unsere Zusammenarbeit so gut funktioniert. Wir alle hatten das Gefühl, dass wir bereits Fragen stellen und Verbesserungen vorschlagen durften und erwarteten und dass unsere Motivation immer darin lag, gemeinsam etwas Großartiges aufzubauen, und nicht darin, eine andere Person zu kritisieren.

Da wir uns darüber im Klaren waren, welche Art von Feedback wir geben, und uns auch daran erinnerten, die gute Arbeit des anderen zu loben, war das Durchführen von Bewertungen eher eine positive als eine demotivierende Kraft.

Ein Beispiel

Um Ihnen eine Vorstellung davon zu geben, wie unser Team die Überprüfung fachübergreifend und während eines Prozesses einsetzt, schauen wir uns an, wie die verschiedenen Mitglieder unseres Teams zwischen den Rollen des Autors und des Prüfers gewechselt haben, als wir unseren Registrierungsprozess erstellt haben.

Schritt 1: Anforderungserfassung

Autor: Ida (UX)

Gutachter: Svein (Strategie), Dag-Inge (Technik), Ingvild (Technik).

Whiteboard-Sitzungen können anstrengend sein, wenn sie keine Struktur haben. Um Produktivität und Kreativität aufrechtzuerhalten, verwenden wir die Autoren-/Rezensentenstruktur, selbst für etwas so scheinbar Einfaches wie das Brainstorming auf einem Whiteboard. In diesem Fall, in dem wir die Anforderungen für unseren Registrierungsablauf entwickelten, durfte ich der Autor sein, und der Rest des Teams gab sein Feedback ab und fungierte als Prüfer. Da sie auch wussten, dass sie in der Lage sein würden, zu überprüfen, was ich mir in Schritt 2 ausgedacht hatte (viel mehr Möglichkeiten für Anpassungen, Vorschläge und Verbesserungen), arbeiteten wir schnell und konnten uns in weniger als 2 Stunden auf die Anforderungen einigen.

Schritt 2: Mockup mit Mikroskopie

Autor: Ida (UX)

Rezensenten: Ingvild (Engineering), Eivind (Design), Svein (Strategie).

Als Autor habe ich mit Microcopy ein Mockup des Anmeldeablaufs erstellt. War der Registrierungsprozess sowohl aus Benutzer- als auch aus technischer Sicht sinnvoll? Und wie könnten wir den Ablauf aus Design- und Frontend-Perspektive verbessern? In dieser Phase war es wichtig, in einem Format zu arbeiten, in dem es für alle Disziplinen einfach ist, Feedback zu geben (wir haben uns für Google Docs entschieden, aber es hätte auch mit einem Tool wie InvisionApp gehen können).

Schritt 3: Implementieren des Anmeldeablaufs

Autor: Ingvild (Ingenieurwesen)

Gutachter: Ida (UX) und Dag-Inge (Engineering).

Wir hatten uns auf den Ablauf, die Eingabefelder und die Mikroskopie geeinigt, und so lag es an Ingvild, dies umzusetzen. Dank Surge können wir automatisch Vorschau-URLs der Änderungen erstellen, sodass auch Personen, die den Code nicht lesen können, in dieser Phase Feedback geben können.

Schritt 4: Benutzertests

Autor: Ida (UX)

Rezensent: Die Benutzer.

Ja, wir betrachten Benutzertests als eine Form der Überprüfung. Wir haben unseren neu aufgebauten Registrierungsablauf von Angesicht zu Angesicht mit tatsächlichen Benutzern gebracht. Dieser Schritt hat uns eine Menge Einblicke verschafft, und die wichtigsten Änderungen in unserem Anmeldefluss waren das Ergebnis.

Schritt 5: Entwerfen

Autor: Eivind (Design)

Gutachter: Ingvild (Engineering) und Ida (UX).

Wenn das Design hier in Schritt 5 plötzlich auftaucht, sieht es möglicherweise sehr nach einem Wasserfallprozess aus. Unser Designer Eivind war jedoch bereits seit Schritt 2 als Reviewer involviert. Er gab in dieser Phase viele nützliche Rückmeldungen und konnte auch darüber nachdenken, wie wir das Design des Anmeldeflusses über die bestehenden Module hinaus verbessern könnten in unserem Designsystem. In diesem Schritt könnte Eivind auch dabei helfen, einige der Probleme zu lösen, die wir in den Benutzertests identifiziert haben.

Schritt 6: Implementierung

Autor: Ingvild (Ingenieurwesen)

Gutachter: Eivind (Design), Ida (UX) und Dag-Inge (Engineering).

Und dann sind wir wieder bei der Umsetzung.

Warum Überprüfung funktioniert

Zusammenfassend gibt es immer nur einen Autor und vermeidet so die Gestaltung durch Gremien. Durch die frühzeitige Einbindung unterschiedlicher Disziplinen als Gutachter vermeiden wir einen Wasserfallprozess.

Die Menschen können ihre Bedenken frühzeitig äußern und auch darüber nachdenken, wie sie später dazu beitragen können. Die klar definierten Rollen halten den Prozess auf Kurs.

Regelmäßige Überprüfung Walkthroughs

Inspiriert von Code-Walkthroughs führen wir auch regelmäßige Review-Walkthroughs mit unterschiedlichen Schwerpunkten durch, die sich an den folgenden Prinzipien orientieren:

• Der Rundgang erfolgt gemeinsam.
• Eine Person übernimmt die Prüfung und Dokumentation.
• Die Idee ist , Probleme zu identifizieren , nicht unbedingt, sie zu lösen.
• Wählen Sie ein Format , das so viel Kontext wie möglich bietet, damit Sie später leicht auf die Ergebnisse reagieren können (z. B. InvisionApp für visuelle Überprüfungen, Google Docs für Text usw.).

Wir haben exemplarische Vorgehensweisen für Dinge wie Zugänglichkeitsaudits, das Überprüfen von Funktionsanfragen, das Auditieren der Implementierung des Designs und das Durchführen heuristischer Usability-Bewertungen durchgeführt.

Wenn wir unsere vierteljährlichen Barrierefreiheitsüberprüfungen durchführen, geht unser Barrierefreiheitsberater Joakim zuerst die Benutzeroberfläche durch und dokumentiert und priorisiert die Probleme, die er in einem gemeinsamen Google Sheet gefunden hat. Joakim führt uns dann durch die wichtigsten Probleme, die er identifiziert hat.

Ein persönliches Treffen (oder zumindest per Video), um die Probleme durchzugehen, trägt dazu bei, eine Umgebung zum Lernen zu schaffen, anstatt das Gefühl zu haben, beaufsichtigt oder mikroverwaltet zu werden.

Wenn Sie feststellen, dass Sie ständig mit etwas beschäftigt sind, das zur Veröffentlichung ansteht, oder das reparieren, was sich ganz oben in Ihrem Posteingang befindet, können Bewertungen Abhilfe schaffen. Wenn Sie regelmäßig halbe Tage für die Überprüfung bereits erledigter Arbeiten einplanen, können Sie Probleme erkennen, bevor sie dringend werden. Es kann Ihnen auch dabei helfen, sich neu zu konzentrieren und sicherzustellen, dass Ihre Prioritäten in der richtigen Linie bleiben. Ihr Team sollte vielleicht nicht mit der Entwicklung dieser neuen Funktion beginnen, bevor Sie sicher sind, dass die vorhandenen Funktionen Ihren Standards entsprechen.

Benutzertests sind eine Form der Überprüfung

Eine wichtige Motivation für Code-Reviews ist die Risikominderung. Indem Sie dies jedes Mal tun, wenn Sie eine Änderung vornehmen oder Ihrem Produkt etwas Neues hinzufügen, und nicht nur, wenn Sie vermuten, dass etwas nicht den Anforderungen entspricht, verringern Sie die Wahrscheinlichkeit, dass Fehler oder unterdurchschnittliche Funktionen ausgeliefert werden. Ich glaube, wir sollten Benutzertests aus derselben Perspektive betrachten.

Sie sehen, wenn Sie das Risiko verringern wollen, dass Sie mit größeren Usability-Problemen ausgeliefert werden, müssen Benutzertests Teil Ihres Prozesses sein. Es reicht nicht aus, nur Ihre UX-Designer die Benutzeroberfläche überprüfen zu lassen. Mehrere Studien haben ergeben, dass selbst Usability-Experten nicht alle tatsächlichen Usability-Probleme identifizieren können. Im Durchschnitt war 1 von 3 Problemen, die von Experten identifiziert wurden, Fehlalarme – sie waren keine Probleme für Benutzer in der Praxis. Aber schlimmer noch, 1 von 2 Problemen, die Benutzer tatsächlich hatten, wurden von den Experten übersehen.

Das Überspringen von Benutzertests ist ein ebenso großes Risiko wie das Überspringen von Codeüberprüfungen.

Bedeutet Überprüfung den Tod der Kreativität?

Menschen, die in den Bereichen Design, Benutzererfahrung und Inhalte arbeiten, haben oft einen Bildungshintergrund von Kunsthochschulen oder vielleicht Literatur, in denen der einzige Schöpfer oder das kreative künstlerische Genie als Ideal gefeiert wird. Wenn Sie in die Geschichte zurückgehen, war dies früher auch bei Entwicklern der Fall. Im Laufe der Zeit hat sich dies zwangsläufig geändert, da die Webentwicklung komplexer geworden ist.

Wenn Sie an der Idee festhalten, dass Kreativität irgendwo tief in Ihnen selbst entsteht, kann sich die Vorstellung einer Überprüfung bedrohlich oder beängstigend anfühlen. Jemand mischt sich in Ihre halbfertige Arbeit ein? Autsch. Aber wenn Sie Kreativität als etwas betrachten, das aus vielen Quellen stammen kann, einschließlich Dialog, Zusammenarbeit oder jeder Form von Inspiration (ob von außen oder von irgendwo in Ihnen), dann ist eine Bewertung nur ein Gewinn und eine Chance.

Solange wir etwas für das Web bauen, führt kein Weg daran vorbei, mit anderen zusammenzuarbeiten, sei es in unserem eigenen Bereich oder in anderen. Und eine gute Idee übersteht die Überprüfung.

Lassen Sie uns gemeinsam etwas Großartiges schaffen.