Was 2001 als Flüstern begonnen hat, ist jetzt praktisch eine Naturgewalt: Überall ist der Entwicklungsprozess im Wandel begriffen. Die Leute merken, dass sie ihre Herangehensweise an Probleme ändern müssen, um Qualität und konkurrenzfähige Software zu produzieren. Agile Entwicklung ist keine Marotte mehr – Agile ist der Weg, auf dem die Software entwickelt wurde, die Sie heute nutzen.
Nun schreiben wir das Jahr 2012 und die agile Welle ist dabei, über die Schwelle der UX-Professionals zu schlagen. Wenn unsere Teams auf Agile umsatteln, müssen wir wohl oder übel die Ansätze unserer Arbeit ändern.
Unsere alten Methoden reichen nicht mehr aus, sie sind zu plump und zu langsam für die Anforderungen des agilen Prozesses. Wir müssen alles, was wir tun, auf den Prüfstand stellen.
Es wäre schön gewesen, wenn wir uns auf diesen Wandel hätten vorbereiten können, doch der Paradigmenwechsel hin zum neuen Entwicklungsprozess hat viele überrascht. Das Ergebnis: Wir finden zahlreiche Teams vor, die in einer sehr chaotischen und frustrierenden Welt arbeiten, vergleichbar mit dem Versuch, die Reifen zu wechseln, während das Auto noch rollt.
Wir haben die letzten Monate damit verbracht, Teams zu interviewen, um zu verstehen, worin sie in diesem Jahr die größten Herausforderungen beim Transfer ihrer UX-Praktiken in den agilen Prozess sehen. Beim Katalogisieren dieser Herausforderungen haben wir auch mehrere Chancen aufgedeckt, die das Potenzial haben, uns insgesamt schneller und effektiver zu machen – und uns besser der Einhaltung des Versprechens widmen zu können, das Agile und UX gleichermaßen gegeben haben: bessere Produkte.
UX und Agile: Workflows im Konflikt
Die größte Ironie dieses Umschaltens auf iterative Prozesse besteht darin, dass Agile genau das ist, wonach die UX-Welt seit Jahren gesucht hat. Jetzt ist es da, und wir sind gänzlich unvorbereitet.
Der Kern von Agile ist die schnelle Iteration, etwas, das wir seit Jahrzehnten anregen, um bessere Software zu erschaffen. Wenn wir mit unseren Entwürfen experimentieren und ausprobieren können, was funktioniert, und dann diejenigen Teile verändern, bei denen dies nicht der Fall ist, kommen wir zu einem Ergebnis, das wir uns am Anfang nicht vorstellen konnten. Wir gehen nicht mehr davon aus, dass der erste Aufbau der letzte ist.
Doch weil die Entwicklung keine schnellen Iterationen kannte, haben wir unseren Werkzeugkasten mit Techniken gefüllt, um komplett durchgeplante Designs an die Implementierung zu übergeben. Das ließ wenig Spielraum.
Jetzt, da sich der Spieß umgedreht hat und die Entwickler bereit für ein iteratives Vorgehen sind, erweist sich unser Werkzeug als durch und durch unzureichend für die Aufgabe. Klar, wir könnten all unsere Konzeptions- und Design-Arbeit in einen "Sprint Null" quetschen, aber das würde alle nur aufregen, weil es weiterhin dem Konzept "Big design up front" entspräche – etwas, von dem uns die agile Bewegung verzweifelt abzubringen versucht.
Unsere Herausforderung besteht darin, so viel von der agilen Welt zu lernen, wie wir können, und es zu adaptieren. Wir müssen unsere UX-Arbeit in Stücke aufteilen und gleichzeitig sicherstellen, dass sich das Ganze, wenn all die Teile zusammengesetzt werden, wie ein kohärentes, gut durchdachtes Design anfühlt. Agile hilft uns dabei nicht, und zwar allem deshalb, weil es nicht für die UX-Komponente gedacht war. Wir sind auf uns allein gestellt.
Der Wechsel zu Agile eröffnet uns auch die große Möglichkeit zu erklären, wie wichtig die Erkenntnisse der Usability-Forschung für hervorragende Produkte sind. Es sind nicht mehr als ein paar Sprints nötig, um zu erkennen, dass UX in den Prozess integriert werden muss.
Aus dem Konflikt können wir den Vorteil ziehen, dass unser Input wieder mehr ins Bewusstsein rückt. Jeder will, dass das Produkt von den Nutzern angenommen wird. Alle verlassen sich darauf, dass wir die notwendigen Zutaten dafür beisteuern. Wenn wir die Möglichkeit nutzen und für eine klare Integration von UX in den agilen Prozess sorgen, haben wir am Ende eine Win-win-Situation.
Von den fixen Ergebnissen zu einem gemeinsamen Verständnis
Jahrelang standen die fertigen Ergebnisse im Zentrum unserer Arbeit. Ob das Oberflächenspezifikationen, Persona-Beschreibungen, Wireframes oder Style-Guides waren – alles, was wir taten, war auf die Produktion eines Endergebnisses ausgerichtet. Wenn wir es ausgeliefert hatten, konnten wir sicher sein, dass unsere Arbeit an dieser Stelle abgeschlossen war. Dann gingen wir stolz ans nächste Projekt.
Agile Teams interessieren sich nicht für solche Dinge. Das Agile Manifest sagt "Funktionierende Software vor detaillierter Dokumentation!" und "Auf Veränderung reagieren vor Plänen folgen!". In einem agilen Projekt können Sie nicht einfach einen Stapel Papier auf den Tisch legen und mit etwas anderem weitermachen.
Wenn wir keine fixen Ergebnisse haben können, was machen wir dann? Wie kommunizieren wir den Entwicklern, was sie umsetzen sollen? Wie sorgen wir dafür, dass sie verstehen, wer unsere Nutzer sind und was sie wollen?
Viele UX-Teams lernen gerade, dass dies eine Chance ist, die Art und Weise, auf die wir mit Entwicklern zusammenarbeiten, komplett zu überdenken. Seit wir ihnen keine Ordner mit Dokumenten mehr vorlegen können, müssen wir die einzig verbleibende Möglichkeit nutzen: Wir müssen in das Bewusstsein des Entwicklers hinein.
Die Chance für uns besteht darin, unsere Werkzeuge so zurechtzuschneiden, dass sie dabei helfen, den Entwicklern verständlich zu machen, was wir umzusetzen versuchen und für wen wir das tun. Neue Ansätze wie Lean UX machen genau das. Lean UX nimmt die besten Dinge, mit denen wir arbeiten, und bringt sie in eine neue Form - weg von den feststehenden Ergebnissen hin zu einem gemeinsamen Verständnis.
Wenn das gesamte Team ein gemeinsames Verständnis davon teilt, was wir erreichen wollen, läuft die Arbeit weit effizienter. Alle wissen, welche Ziele wir haben, wer die Nutzer sind, was funktionieren wird und was nicht. Wenn das Team Iterationen am Design durchführt und die Sachen mit echten Nutzern ausprobiert, festigt sich dieses Verständnis.
Und nicht zuletzt sind UX-Fragen in diesem Fall nicht mehr das alleinige Territorium des Konzeptions- und Design-Teams. Alle verstehen, was nötig ist, um erfreuliche Nutzererlebnisse zu schaffen, und bringen die eigene Perspektive ein.
Das Power-Tool: Prototyping
Vor einem Whiteboard zu stehen, mit den Armen zu rudern und gestenreich zu kommunizieren, wie Sie sich Ihr Design vorstellen, erinnert eher an einen Ausdruckstanz als an Software-Design. Leider ist es auch nicht effektiver.
Das Problem ist, dass die Whiteboard-Diskussion ebenso viel Interpretationsspielraum lässt wie ein Ausdruckstanz: Jeder geht mit einem anderen Verständnis dessen raus, was realisiert werden soll. Und das heißt, dass das, was gebaut wird, nicht wirklich viel mit dem zu tun hat, was Sie sich vorgestellt haben.
Dem sind wir mit Ergebnissen z.B. in Form umfangreicher Spezifikationen begegnet, aber seit es damit vorbei ist, sind viele wieder beim Mit-den-Armen-Rudern angekommen.
Nehmen wir also den anderen Bühneneingang: Prototypen. Traditionell war der Prototyp reserviert für Präsentationen vor Entscheidern und gelegentlich für den Bereich der Nutzerforschung. Zumeist diente er als Machbarkeitsnachweis des Konzepts, um zu zeigen, was wir vorhaben und dass es gründlich durchdacht ist.
Teilweise lag diese sparsame Nutzung daran, dass in jeden Tagen einiges an Aufwand nötig war, um einen funktionierenden Prototypen unserer Ideen zu entwickeln. Tatsächlich brauchte es fast so viel Arbeit wie die Entwicklung des fertigen Produkts.
In unserer neuen, modernen Welt sind Prototypen viel einfach zu bewerkstelligen. Bewaffnet mit JavaScript und jQuery kann ein UX-Fachmann seine Idee fast so schnell digital umreißen wie mithilfe einer Zeichnung auf dem Whiteboard.
Das bedeutet, dass Prototypen jetzt in der Kommunikation mit unseren Teamkollegen eingesetzt werden können und nicht nur für die Abstimmung mit Außenstehenden. Wir können schnell etwas bauen, um exakt zu zeigen, was wir meinen, und um darüber zu diskutieren, ob es das ist, was wir wollen, oder nicht. Noch wichtiger: Wir können es schnell verändern und sich den Prototypen im Gleichschritt mit unserem Denken entwickeln lassen.
Wir gehen davon aus, dass in diesem Jahr mehr UX-Profis als je zuvor auf Prototyping setzen werden. Das wird unsere Wunderwaffe sein, um schnell zu einem gemeinsamen Verständnis zu kommen.
Auf Agile umzusatteln, ist furchterregend, bis man's gemacht hat
Anfangs sieht Agile wie eine fremde Welt aus, in der alle Regeln sich geändert haben. Aber sobald wir den Dreh raus haben, erkennen wir, welche Geschwindigkeit und Macht es mit sich bringt. Neue Ideen liegen auf dem Tisch und werden ständig in den Entwicklungsprozess integriert. Innovationen kommen mit Lichtgeschwindigkeit angerauscht.
Uns stehen einige große Herausforderungen bevor. Doch wegen der mit ihnen verbundenen Chancen können wir uns auf dieses Jahr wirklich freuen.
Dieser Artikel wurde im Original am 14. Februar 2012 unter dem Titel UX and Agile Development: 2012's Challenges and Opportunities
