Die Entwicklung von Adobe XD – Beta-Version neu definiert

Die Entwicklung und das Basteln an einer Software kann ein äußerst zufriedenstellendes Unterfangen sein. Ich selbst liebe es und bin leidenschaftlich dabei. Ich habe das Glück, ein talentiertes Entwicklungsteam für eine neue Initiative namens Adobe Experience Design CC (kurz: Adobe XD) zu leiten. Eines unserer Hauptziele bei der Ausarbeitung des Entwicklungsprozesses für Adobe XD war es, die Art und Weise der Softwareerstellung und -lieferung zu überdenken, um sicherzustellen, dass wir die Design-Gemeinschaft einbeziehen und ein Produkt entwickeln, das auf ihre Wünsche und Bedürfnisse zugeschnitten ist. Nach meiner Erfahrung ist der Aufbau dieses Prozesses nicht immer einfach.

Zu einem bestimmten Zeitpunkt in meiner Karriere hätte ich am liebsten etwas anderes gemacht. Bevor ich mir meiner Liebe für die Entwicklung von Software wieder sicher war, sah ich mich zwei großen Problemen ausgesetzt.

Erstens hatte ich an zu vielen Softwareprojekten gearbeitet, bei denen sich jede Veränderung als schwierig erwies: Die Fehlerbehebung war mühsam und das Hinzufügen von Funktionen beinahe unmöglich. Das Ändern einer Codezeile schien dem Versuch zu gleichen, in einem riesigen Industriekomplex Dampf- und Wasserrohre hinzufügen zu wollen, ohne eine Abbildung des gesamten Systems zu haben und ohne eine Möglichkeit, den Vorgang zu validieren. Nur die ursprünglichen Entwickler (die Helden oder die Gurus) besaßen den Mut, wichtige Veränderungen an der Codebasis vorzunehmen, da ihnen mehr Kontext zur Verfügung stand. Die Qualität verschlechterte sich ständig und die Wartung wurde unerschwinglich. Es machte keinen Spaß und war weder erfüllend noch interessant – und es war vor allem für die Endnutzer schlecht, die eine suboptimale Lösung für ihr Problem erhielten.

Was mich zum zweiten Problem bringt. Viele Projekte, an denen ich gearbeitet habe, waren trotz der erklärten Absicht, die Bedürfnisse der Nutzer zu erfüllen, so aufgebaut, dass Funktionen überstürzt eingebaut wurden. Dies geschah sowohl auf der Seite der Entwicklung (zu schnell umgesetzt), als auch auf der Seite von Produkt und Design (ohne angemessene Nutzervalidierung). Obwohl wir also bei der Lieferung den Zeitplan einhielten, wurde eine fehlerhafte Umsetzung geliefert, die unsere Nutzer überhaupt nicht wollten.

Warum passiert so etwas Unerwünschtes?

In der Softwareentwicklung arbeitet man mit drei Schlüsselfaktoren: Qualität, Zeitpunkt (der Veröffentlichung) und Umfang (für Funktionen). In unserem Team nennen wir es das „Eiserne Dreieck“ (unsere Version des magischen Projektmanagementdreiecks). In jedem Projekt können jeweils nur zwei der drei Parameter eingeschränkt werden. Versucht man, alle drei Parameter einzuschränken, wird einer darunter leiden. Werden zum Beispiel Zeit und Umfang eingeschränkt, leidet die Qualität. Werden Qualität und Umfang eingeschränkt, verschiebt sich der Lieferzeitpunkt.

Allzu oft führt der Wunsch, zahlreiche Funktionen in einem begrenzten Zeitraum bereitzustellen (Umfang erhöhen), zu einer schlechteren Qualität (und Leistung).

Warum arbeite ich also noch immer im Bereich Softwareentwicklung?

Natürlich hatten auch Andere die gleichen Probleme und sie stellten fest, dass es auch anders ging und entwickelten neue Methoden und Lösungen. Und zwar richtig gute.

Es tauchten bessere Entwicklungsmethoden in der Branche auf, wie zum Beispiel agile Entwicklung oder Extreme Programming, die darauf abzielten, Qualität in den Entwicklungsaufwand einfließen zu lassen. Das Ziel lautete, keine Abstriche bei dem Parameter „Qualität“ im Eisernen Dreieck zuzulassen, regelmäßig zu liefern und Funktionen im Laufe der Zeit hinzuzufügen. Dies erlaubte uns Flexibilität beim Parameter „Umfang“: Wir konnten nun eine besser wartbare Software entwickeln, da wir uns die Zeit nahmen, nicht nur die benötigten Funktionen, sondern auch eine umfangreiche Suite automatisierter Tests einzubauen, damit wir im Laufe der Zeit stets wussten, ob eine bestimmte Funktion oder ein Teil des Codes weiterhin funktionierte oder nicht.

Ich setzte diese Verfahren zum ersten Mal in einem Open-Source-Projekt bei Apache und anschließend in kommerziellen Projekten um. Die Übernahme dieser besseren Verfahren veränderte mein Leben als Softwareentwickler und machte es so viel besser. Und ich fing wieder an, Spaß am Entwickeln von Software zu haben!

Die zweite große Veränderung war eine wichtiger Wandel in der Art und Weise, wie wir die Entwicklung unserer Produkte leiten – von der Idee bis zur Umsetzung. Bei Methoden wie dem Lean Product Development kommt dem Entdecken der Probleme echter Nutzer wesentlich mehr Bedeutung zu. Es werden spezifische Hypothesen aufgestellt, die wir durch Experimente validieren (oder als falsch erweisen) können, und zur Entscheidungsfindung wird anstelle von individuellen Meinungen die Analyse von Daten verwendet. Dies hat zu besser ausgearbeiteten Lösungen und einer besseren Anpassung der Lösungen auf die jeweiligen Probleme geführt.

Methoden wie agile Softwareentwicklung und Lean Product Development sind zwar nicht neu, aber haben mein Berufsleben dennoch verändert, da ich Aspekte dieser Methoden gelernt und in meine Arbeit integriert habe. Ich habe in ihnen ganz klar das Potenzial gesehen, robustere Softwaresysteme zu entwickeln, die die Bedürfnisse und Erwartungen der Nutzer besser erfüllen.

Und nun freue ich mich darauf, dieser Methoden für ein ehrgeiziges Projekt anzuwenden: Adobe XD.

Vor einigen Monaten veröffentlichte unser Team die erste Beta-Version von Adobe XD – eine Lösung für das Design, Prototyping und den Erfahrungsaustausch für mobile Anwendungen, Websites und andere bildschirmbasierte Erfahrungen.

Das erste Element dieser Lösung ist die Desktop-Version von Adobe XD für Mac OS X. Im unten abgebildeten Screenshot der Anwendung kann man ihre einfache und fokussierte Benutzeroberfläche sehen.

Schon seit Beginn haben wir Adobe XD für Schnelligkeit und Qualität entwickelt. Damit meinen wir, dass die Software den Designern ermöglichen soll, in Sekundenschnelle und ohne Probleme designen zu können. Wir haben von Designern erfahren, dass schlechte Leistung oder Qualität nicht nur frustrierend für sie waren, sondern auch ihre kreative Ausdruckskraft und die Fähigkeit beeinträchtigen, schnell viele Arbeiten zu produzieren und zu wiederholen. Dies ist besonders wichtig, wenn sie Erfahrungen für viele verschiedene Bildschirme erstellen (z. B. Anwendungen, Websites und Wearables).

Bei Projektbeginn war uns klar, dass wir einige Zeit brauchen würden, um diese Aufgabe richtig hinzubekommen. Uns war auch klar, dass wir unsere Lösung schnell durch Nutzer testen lassen wollten, um aus deren Erfahrungen zu lernen und das Produkt schrittweise ausbauen zu können. Und wir wollten den Nutzern eine qualitativ hochwertige Erfahrung bringen.

Was haben wir für das Erreichen dieses Ziels getan?

Auf einer kleinen, aber robusten Basis beginnen. Und anschließend schrittweise ausbauen.

Wir alle kennen „Beta-Software“, die zwar viele Funktionen hat, aber Mängel bei Leistung, Qualität oder beidem aufweist. Mit der ersten Beta-Version wird versucht, alle Funktionen des fertigen Produkts zur Schau zu stellen, jedoch zulasten der „Funktionstiefe“ (weil die Arbeit und die Details, die in die Fertigstellung einer Funktion einfließen, Zeit brauchen) und zulasten der Qualität (weil „dafür keine Zeit bleibt“). Auf die Beta-Version folgen andere Versionen, mit denen die Funktionstiefe und Qualität verbessert werden sollen. In der Eile, so viele Funktionen in die erste Beta-Version einzubinden, werden jedoch oft Abstriche gemacht, die später nur schwer behoben werden können. Ohne eine starke automatisierte Testsuite und Qualitätskontrollen während der gesamten Entwicklungsphase kann sich der Versuch, das Gesamtprodukt später zu stabilisieren, als äußerst schwierig und zeitaufwändig erweisen. Dieser Ansatz ist unten dargestellt.

Es gibt viele Gründe dafür, warum dieser Ansatz suboptimal ist. Die Hauptgründe ergeben sich aus denselben Gründen, aus denen wir überhaupt eine „Beta-Version“ veröffentlichen. Die „Beta-Version“ soll die Vision für das Tool, das wir entwickeln, und für seine spezifischen Funktionen vermitteln. Wir möchten Feedback zu beidem bekommen, um es in die Projektausrichtung und -umsetzung einfließen zu lassen. Das Ziel lautet hier, die Chancen für den Erfolg des Produkts zu vergrößern.

Der frühe Einbau zu vieler Funktionen zulasten der Qualität verursacht ein hohes Risiko: Die Vision und Zielsetzung des Produkts können durch den Ruf schlechter Qualität oder Leistung lädiert werden und das Feedback konzentriert sich nur auf Fehler und Bedenken hinsichtlich der Leistung anstatt auf die eigentliche Vision und die Funktionen. Wir versäumen also die Chance, die wichtigsten Lehren zu ziehen, die unsere Nutzer uns beibringen können.

Um unsere Lern- und Erfolgsmöglichkeiten zu vergrößern, entschieden wir uns dazu, mit einem Mindestmaß an Funktionen zu beginnen, die:

• Funktionstiefe besaßen und ausgearbeitete Details aufwiesen, die für die Nutzer wichtig sind
• Ein solides Design und einen Implementierungsplan hatten
• Gemäß unseren Qualitätsstandards entwickelt wurden

Anschließend verbessern wir das Produkt im Laufe der Zeit, sobald wir Feedback durch die Nutzer erhalten. Die vorhandenen Funktionen werden stabilisiert und neue kommen Schritt für Schritt hinzu.

Dieser Prozess wird im folgenden Diagramm veranschaulicht:

Das Diagramm zeigt, dass wir schon mit der ersten Version darauf abgezielt haben, eine Erfahrung zu liefern, die die Erwartungen der Nutzer an ein endgültiges Software-Release in Bezug auf Qualität und Leistung erfüllt. Um noch einmal auf das „Eiserne Dreieck“ zurückzukommen: Wir liefern pünktlich und mit der Qualität eines Software-Release, indem wir gegebenenfalls den Umfang eingrenzen. Durch diesen Ansatz besitzt jede Beta-Version dieselbe hohe Leistung und Qualität wie eine Vollversion – nur mit weniger Funktionen. Unserer Meinung nach können Nutzer das Produkt somit besser testen und uns mehr Möglichkeiten zum Lernen bieten.

Um diesen Qualitätsgrad zu erreichen, begannen wir mit einer kleinen, soliden Codebasis und stellten höchste Anforderungen an alle Funktionen, die wir hinzufügen. Diese Anforderungen nehmen die Form einer strengen Definition of Done (DoD) an. Unsere DoD enthält Punkte wie Codeüberprüfungen, Unit Tests und Code-Abdeckung, die sicherstellen, dass diese Verfahren systematisch umgesetzt werden. Wir haben es uns zur Aufgabe gemacht, unseren Nutzern monatlich neue Updates zur Verfügung zu stellen (für die meiste Desktop-Software ein schneller Zyklus). Auf mittlere und lange Sicht glauben wir, dass wir zusätzliche Funktionen dadurch schneller, in regelmäßigeren Abständen und mit einer höheren Qualität liefern können, als wenn wir die Updates in größeren Abständen bereitstellen würden. Und mit jedem Zwischenrelease wird uns eine neue Lernmöglichkeit geboten, wie bereits oben dargelegt.

Zusammenfassend bietet uns dieser Ansatz also zwei wesentliche Vorteile:

1. Rasche Validierung durch den Nutzer. Wir nehmen nicht an, dass die von uns entwickelte Lösung von Anfang an perfekt ist. Indem wir oft neue Releases bereitstellen, erhalten wir ständiges Feedback und können unseren Kurs anpassen, wann und wo es notwendig ist. So haben wir zum Beispiel den Farbwähler, das Stiftwerkzeug und die Sharing-Funktionen unseres Tools basierend auf der Validierung der Nutzer verbessert.
2. Nutzereinbindung und Iteration. Nach dem Release einer neuen Version teilen uns die Nutzer mit, was sie sich sonst noch von unserem Tool wünschen. Dies erlaubt es uns, unsere Prioritätensetzung für die folgenden Versionen anzupassen, um sicherzustellen, dass wir zuerst an den wichtigsten Punkten arbeiten. Es kann einige Versionen dauern, bis das Nutzer-Feedback sich in der Software widerspiegelt, da zum Zeitpunkt des Releases einer neuen Version die nächste bereits fertiggestellt ist und in den Startlöchern steht. Dieser Fließbandansatz erlaubt es uns, unseren Nutzern kontinuierlich einen Wert anzubieten und dabei das Produkt ständig zu verbessern.

Zusammenfassung

Wir haben bis jetzt eine tolle Resonanz aus der Community erhalten. Es war uns möglich, drei monatliche Updates von Adobe XD zu veröffentlichen und das vierte ist bereits auf dem Weg. Das Feedback der Nutzer bezieht sich auf Funktionen und nicht auf Qualitäts- oder Leistungsprobleme und ich bin begeistert von dieser Art und Weise, Beta-Versionen an den Nutzer zu bringen.

Ich freue mich auf das Lernerlebnis, das noch vor uns liegt, während wir unsere Methoden kontinuierlich verbessern. Wir entwickeln gegenwärtig neue und spannende Funktionen (siehe „Was noch kommt“ in diesem Artikel von Andrew, dem Produktmanagement-Leiter von Adobe XD) und wir würden uns über euer Feedback sehr freuen. Testet die XD-Preview für Mac OS X (Win10 wird auch gerade entwickelt!) und schließt euch den anderen Designern auf UserVoice an, um Fehler zu melden, Funktionen zu kommentieren oder neue Funktionen anzufragen!

The post Die Entwicklung von Adobe XD – Beta-Version neu definiert appeared first on Creative Connection.