So führen Sie neue Funktionen ein, ohne treue Benutzer zu verletzen

„Sei agil; vorzeitig entlassen; Veröffentlichung oft.“ Wir kennen die Übung. Aber ist es strategisch klug , häufig Funktionen einzuführen? Besonders wenn ein Produkt, das Sie erstellen, eine bestimmte Größe erreicht, möchten Sie wahrscheinlich nicht mit jeder neuen Nebenversion die Integrität Ihrer Anwendung gefährden.

Das Schlimmste, was Ihrem Produkt passieren kann, ist, dass treue Benutzer, Kunden, die diese eine kleine Funktion über die Jahre konsequent verwendet haben, plötzlich nicht mehr in der Lage sind, sie auf die gleiche bequeme Weise zu verwenden. Die Änderung könnte Benutzern mehr Möglichkeiten geben, aber die Erfahrung wird weniger einfach. Frustration und Angst dringen schnell und plötzlich in die sozialen Medien ein, und der Druck auf den Kundensupport, sinnvoll und rechtzeitig zu reagieren, steigt mit jeder Minute. Natürlich möchten wir keine neuen Funktionen einführen, nur um festzustellen, dass sie treuen Benutzern tatsächlich schaden.

Weiterführende Literatur zu SmashingMag: Link

• Wie wir anfingen, Funktionen doppelt so schnell zu veröffentlichen
• Die Website-Launch-Checkliste – 15 wichtige Checks, bevor Sie live gehen
• Ein benutzerzentrierter Ansatz für das Webdesign für mobile Geräte
• Wie man alles startet

Wir können dies verhindern, indem wir bei der Einführung neuer Versionen unserer Produkte strategischer vorgehen. In diesem Artikel untersuchen wir eine Strategie für Produktdesigner und Front-End-Ingenieure , um eine Funktion gründlich zu testen und bereitzustellen, bevor sie für die gesamte Benutzerbasis freigegeben wird, und wie Sie vermeiden können, dass sich UX-Probleme im Laufe der Zeit einschleichen.

Bevor wir in eine tatsächliche Teststrategie eintauchen, lassen Sie uns einen Schritt zurücktreten und allgemeine Missverständnisse darüber untersuchen, wie ein neues Feature entworfen, erstellt und schließlich bereitgestellt wird.

Missverständnisse bei neuen Funktionen

Wenn ein neues Feature für ein bestehendes Produkt entworfen wird, liegt das Hauptaugenmerk meist darauf, wie genau es in die bestehende Oberfläche integriert werden soll. Um Konsistenz zu erreichen, schauen wir Designer oft in bestehende Muster und wenden die etablierte Designsprache an, damit sich die neue Funktion gut in die Benutzeroberfläche einfügt. Probleme treten jedoch häufig nicht auf, weil Komponenten visuell nicht zusammenarbeiten, sondern weil sie sich als verwirrend oder mehrdeutig erweisen, wenn sie auf unerwartete Weise kombiniert werden .

Vielleicht ist die Kopie der Benutzeroberfläche in verwandten, aber entfernten Bereichen der Website mehrdeutig, oder das Ergebnis der gleichzeitigen aktiven Nutzung zweier Funktionen ist aus technischer Sicht sinnvoll, entspricht jedoch nicht den Erwartungen der Benutzer oder hat erhebliche Auswirkungen auf die Leistung und schadet der UX .

Tatsächlich sind es im Design diese zahlreichen Kombinationen, die so schwierig vorherzusagen und zu überprüfen sind. Eine Möglichkeit, das Problem bereits im Designprozess anzugehen, besteht darin, die Ausreißer zu berücksichtigen – Anwendungsfälle, in denen die Wahrscheinlichkeit größer ist, dass etwas schief geht. Wie würde ein Benutzerprofil aussehen, wenn der Name des Benutzers sehr lang ist? Ist eine Übersicht über unbeantwortete E-Mails noch selbstverständlich, wenn ein Dutzend Posteingangsetiketten verwendet werden? Wäre ein neuer Filter sinnvoll für Benutzer, die sich gerade neu angemeldet haben und nur wenige E-Mails in ihrem Posteingang haben?

Ausreißer entwerfen: Der User Interface Stack

Wie genau können wir die Ausreißer gestalten, nachdem wir sie identifiziert haben? Eine gute Strategie besteht darin, die verschiedenen Zustände der Benutzeroberfläche zu studieren. Der „Benutzeroberflächen-Stack“, eine von Scott Hurff eingeführte Idee, ist vielseitig und kompliziert, und wenn wir unsere Benutzeroberflächen entwerfen, reicht es normalerweise nicht aus, ein pixelgenaues Mockup in Photoshop, Sketch oder HTML und CSS zu erstellen – wir müssen darüber nachdenken verschiedene Randfälle und Zustände: der Leerzustand, der Ladezustand, der Teilzustand, der Fehlerzustand und der Idealzustand. Diese sind nicht so einfach, wie wir vielleicht denken.

Der leere Zustand muss nicht leer sein – wir könnten Servicemitarbeiter einsetzen, um regelmäßigen Besuchern ein besseres Offline-Erlebnis zu bieten. Der partielle Zustand muss nicht gebrochen werden – wir könnten die Erfahrung mit gebrochenen Bildern und gebrochenem JavaScript durch progressive Verbesserung verbessern.

Der Idealzustand kann aufgrund von benutzerdefinierten Benutzereinstellungen und der Browserauswahl des Benutzers erheblich von unseren „perfekten Ergebnis“-Mockups abweichen; Einige Inhalte und Webfonts werden beispielsweise aufgrund der Konfiguration eines Browsers möglicherweise nicht angezeigt.

Die Landschaft ist also wie immer komplex, verworren und unvorhersehbar, und wir können das Risiko, dass etwas schief geht, nicht vernachlässigen, aber das bedeutet nicht, dass wir das Risiko nicht effektiv minimieren können. Indem wir Ausreißer und den gesamten Stack der Benutzeroberfläche frühzeitig untersuchen, können wir häufige UX-Probleme in der frühen Designphase vermeiden. Auf der technischen Seite wird es jedoch nicht einfacher.

Der Schmetterlingseffekt im Einsatz

Selbst geringfügige Änderungen neigen dazu, zu Kettenreaktionen zu führen und Fehler in Bereichen und Situationen einzuführen, die absolut nichts miteinander zu tun haben. Der Hauptgrund dafür ist die schiere Menge an Variablen, die das Benutzererlebnis beeinflussen, aber außerhalb unserer Kontrolle liegen. Wir kennen uns mit Browsern aus, aber das bedeutet nicht, dass wir mehr über den Kontext wissen, in dem ein Benutzer die von uns so unermüdlich und sorgfältig erstellte Website besucht.

Während kleinere Änderungen wie das Auffüllen einer Schaltfläche oder ein progressiv erweiterter Textbereich keine große Sache zu sein scheinen, neigen wir dazu, die Auswirkungen dieser glänzenden kleinen Änderungen oder Funktionen im großen Maßstab zu unterschätzen. Jedes Mal, wenn wir eine Design- oder Entwicklungsentscheidung treffen, wirkt sich diese Änderung auf das komplexe System aus, das wir bauen, hauptsächlich weil die Komponenten, die wir bauen, niemals isoliert existieren.

Die Realität ist, dass wir niemals einfach nur eine Schaltfläche bauen, noch schreiben wir niemals einfach eine neue JavaScript-Funktion – Schaltflächen und Funktionen gehören zu einer Familie von Komponenten oder Bibliotheken, und sie alle arbeiten innerhalb einer bestimmten Umgebung, und sie sind unvermeidlich mit anderen verbunden Teile des Systems durch ihre Eigenschaften oder durch ihren Bereich oder durch ihren Namen oder durch die ungeschriebenen Konventionen des Teams.

Diese „stillen“, kaum wahrnehmbaren Verbindungen sind der Grund, warum das Ausrollen von Features schwierig ist und sich das Vorhersagen der weitreichenden Folgen einer Änderung oft als Augenübung erweist. Aus diesem Grund ist es eine gute Idee, unnötige Abhängigkeiten so weit wie möglich zu vermeiden, sei es in CSS oder JavaScript – sie helfen Ihnen nicht bei der Wartung oder beim Debuggen, insbesondere wenn Sie sich auf eine Bibliothek verlassen, die Sie nicht vollständig verstehen .

Glücklicherweise können wir Ressourcen wie die Entwicklertools eines Browsers verwenden, um die Auswirkungen einer Änderung besser zu verstehen. Wir können die Reichweite eines Selektors oder die Reichweite einer JavaScript-Funktion messen, und manchmal kann es eine gute Idee sein, während der Entwicklung immer wieder darauf zurückzukommen, um den Umfang der Änderung so lokal und minimal wie möglich zu halten.

Das ist hilfreich, aber es ist auch nur ein Teil der Geschichte. Wir treffen Annahmen, bewusst und unbewusst, basierend auf unserer eigenen Erfahrung mit der Benutzeroberfläche und unseren eigenen Gewohnheiten – wobei wir oft vergessen, dass Annahmen von Benutzer zu Benutzer erheblich variieren können (und daher auch werden ). Die meisten Anwendungen haben nur eine Schnittstelle, aber diese Schnittstelle oder ihre Konfigurationen können Dutzende von Zuständen haben – wobei sich die Ansichten je nach den Einstellungen und Vorlieben des Benutzers ändern.

Denken Sie an Dashboards mit anpassbaren Karten (Analysesoftware), Mailclients mit „kompakten“, „komfortablen“ und „detaillierten“ Ansichten (Gmail), eine Buchungsoberfläche, die sich für eingeloggte Kunden und für Gäste ändert, ein Leseerlebnis für Personen, die einen Werbeblocker oder einen aggressiven Antivirenfilter verwenden. Der Schmetterlingseffekt wirkt sich nicht nur auf die Codebasis aus; All diese externen Faktoren spielen ebenfalls eine Rolle, und das Testen gegen sie ist – anders als bei Unit-Tests oder QA im Allgemeinen – sehr schwierig, da wir oft nicht einmal wissen, gegen was wir testen sollen.

Funktionsvalidierung und lokales Maximum

Wir können Diagnosen und Metriken verwenden, um festzustellen, welche Änderungen vorgenommen werden müssen, aber wenn Sie nur Daten folgen, könnten Sie am Ende bei dem stagnieren, was wir als „lokales Maximum“ bezeichnen, ein Zustand der Schnittstelle mit einem ausreichend guten Design, aber das fehlt es völlig an Innovation, weil es immer vorhersehbaren, logischen Iterationen folgt. Wenn wir an einem Projekt arbeiten und die Daten untersuchen, neigen wir dazu, Funktionen in den folgenden vier Buckets zu gruppieren:

• Kaputte Funktionen. . Funktionen, die defekt oder ineffizient zu sein scheinen – natürlich müssen wir sie beheben;
• Ungenutzte Funktionen. . Funktionen, die wie beabsichtigt funktionieren, aber selten verwendet werden – oft ein Zeichen dafür, dass sie entweder entfernt werden sollten oder dringend eine Innovation benötigen;
• Unerwartete Verwendungsfunktionen. . Funktionen, die auf eine Weise verwendet werden, die sich stark von dem unterscheidet, was sich ihre Ersteller ursprünglich vorgestellt hatten – ein guter Kandidat für eine langsame, kontinuierliche Verfeinerung;
• Merkmale des Arbeitstiers. . Features, die stark genutzt werden und wie geplant zu funktionieren scheinen – in diesem Fall fragen wir uns, ob es eine Möglichkeit gibt, ihre UX weiter zu verbessern, indem wir sowohl den langsamen iterativen Prozess als auch völlig andere innovative Konzepte parallel untersuchen.

Die ersten beiden Bereiche sind entscheidend, um eine Benutzeroberfläche funktionsfähig und benutzerfreundlich zu halten, während die beiden letzteren entscheidend sind, um die Benutzer zu beschäftigen und zu begeistern. Idealerweise wollen wir beide Ziele gleichzeitig erreichen, aber Zeit-, Budget- und Teamrestriktionen haben die Oberhand.

Sobald eine neue Iteration oder eine neue Idee ausgewählt wurde, kann es jedoch verlockend sein, sofort mit dem Entwerfen oder Erstellen der neuen Funktion zu beginnen. Aber bevor Sie überhaupt darüber nachdenken, wie eine Funktion in eine vorhandene Benutzeroberfläche passen würde, ist es eine gute Strategie, die Idee zuerst zu validieren – mit einem schnellen Prototyp und Benutzerrecherchen. Ein gängiger Weg, dies zu erreichen, ist die Verwendung eines schnellen iterativen Prozesses, wie z. B. des Design-Sprints von Google Ventures. Indem Sie innerhalb weniger Tage iterieren, können Sie feststellen, wie das neue Feature implementiert werden sollte und/oder ob es so nützlich ist, wie Sie es sich ursprünglich vorgestellt hatten.

Mit Design Sprints setzen wir die Idee frühzeitig der Usability-Forschung aus. In der Methodik von Google Ventures würden Sie ein Design mit fünf Nutzern pro Tag testen; dann würden Sie iterieren und eine weitere Testrunde des neuen Designs durchlaufen. Der Grund, warum alle dieselben Benutzer beteiligt sind, liegt darin, dass Sie, wenn Sie an diesem Tag mit jedem Benutzer ein anderes Design testen, keine gültigen Daten hätten, um zu wissen, welche Elemente geändert werden sollten. Sie benötigen einige Benutzer, um eine Design-Iteration zu validieren.

Wir wenden in unseren Sprints ein etwas anderes Modell an. Wenn wir mit der Arbeit an einem neuen Feature beginnen, bringen wir Designer, Entwickler und das UX-Team zusammen, nachdem ein früher erster Prototyp erstellt wurde, im selben Raum, laden echte Benutzer zum Testen ein und iterieren dann nach einem engen Zeitplan. Am ersten Tag können die ersten Tester (zwei bis drei Personen) für ein 30-minütiges Interview um 9:00 Uhr, die zweite Gruppe um 11:00 Uhr, die nächste um 14:00 Uhr und die letzte Gruppe eingeplant werden eine gegen 16:00 Uhr. Zwischen den Benutzerinterviews haben wir „offene Zeitfenster“, in denen wir das Design und den Prototypen tatsächlich iterieren, bis wir irgendwann etwas Brauchbares haben.

Der Grund dafür ist, dass wir früh ganz andere, manchmal sogar entgegengesetzte Richtungen schnell erkunden wollen; Sobald wir Feedback zu verschiedenen Schnittstellen gesammelt haben, können wir uns dem annähern, was sich wie das „absolute Maximum“ anfühlt . Auf diese Weise können wir sehr unterschiedliches Feedback zu sehr unterschiedlichen Design-Iterationen schneller erhalten. Das Feedback basiert hauptsächlich auf drei Faktoren: Heatmaps, die Benutzerklicks aufzeichnen, die Zeit, die Benutzer benötigen, um eine Aufgabe zu erledigen, und wie angenehm die Erfahrung für sie ist. Später in der Woche arbeiten wir weiterhin konsequent mit einer größeren Anzahl von Benutzern, ähnlich wie Google, und validieren das neue Design ständig, während wir fortfahren.

So weit, so gut, aber manchmal kollidiert eine scheinbar innovative neue Funktion mit einer bestehenden Funktion, und beide in derselben Benutzeroberfläche zu haben, würde das Design unübersichtlich machen. In diesem Fall untersuchen wir, ob eine der Optionen als Erweiterung der anderen betrachtet werden könnte. Wenn ja, beginnen wir damit, die Funktionalität und das Design zu wiederholen. Dann müssen wir uns für eine radikale Neugestaltung oder eine schrittweise Änderung entscheiden. Letzteres ist weniger riskant und behält ein vertrautes Interaktionsmuster für Benutzer bei, während ersteres erforderlich ist, wenn kritische Änderungen nicht anders erreicht werden können oder wenn die Gewinne aus inkrementellen Änderungen zu gering wären.

In jedem Fall ist es entscheidend, den Fokus auf die gesamte Benutzererfahrung des Produkts zu richten und nicht auf den Wert einer einzelnen Funktion innerhalb dieses Produkts. Und sobald Sie sich für die Funktion entschieden und den ersten Prototyp entworfen und gebaut haben, ist es an der Zeit zu testen.

Die acht Teststufen

Nun, wie verhindern wir effektiv, dass sich Fehler und Ausfälle in eine tatsächliche Live-Umgebung einschleichen? Wie viele Überprüfungen, Überprüfungen und Tests führen wir durch, bevor eine Funktion bereitgestellt wird? Und in welcher Reihenfolge führen wir diese Tests durch? Mit anderen Worten, wie würde die ultimative Strategie für die Einführung von Funktionen aussehen?

Eine der besseren Strategien für die Einführung von Funktionen wurde von Andrew Sumin, Entwicklungsleiter bei Mail.ru, einem großen E-Mail-Anbieter in Russland, vorgeschlagen. Die Strategie wäre nicht auf jedes Projekt anwendbar, aber es ist ein vernünftiger und umfassender Ansatz für Unternehmen, die mittelgroße und große Produkte für Tausende von Kunden anbieten.

Sehen wir uns die Strategie im Detail an und behandeln die acht Schritte einer Funktionseinführung, die den Produktentwicklungsprozess von Mail.ru abdecken:

1. mit Entwicklern testen,
2. Test mit echten Benutzern in einer kontrollierten Umgebung,
3. Test mit unternehmensweiten Benutzern,
4. mit Betatestern testen,
5. Test mit Benutzern, die sich manuell anmelden,
6. Split-Test und Überprüfung der Aufbewahrung,
7. langsam und allmählich loslassen,
8. Messen Sie die Folgen.

Im Fall von Mail.ru ist die wichtigste Funktion, die intakt bleiben muss, egal was eine Nachricht verfasst (offensichtlich). Das ist der am häufigsten verwendete Teil der Benutzeroberfläche, und es zuzulassen, dass es nicht verfügbar ist oder auch nur für Sekunden falsch funktioniert, wäre absolut ausgeschlossen. Was wäre also, wenn wir die Funktionalität eines Textbereichs erweitern wollten, vielleicht durch Hinzufügen einiger intelligenter Autovervollständigungsfunktionen, eines Zählers oder einer Seitenvorschau?

1. Testen Sie mit Entwicklern

Je mehr Zeit in der Entwicklung vergeht, desto teurer wird es, ein Problem zu beheben. Denken Sie noch einmal darüber nach, wie verbunden alle Entscheidungen in der Produktentwicklung sind; Je raffinierter das Produkt ist, desto mehr Entscheidungen müssen rückgängig gemacht werden, was Zeit und Ressourcen kostet. Das frühzeitige Identifizieren und Lösen von Problemen sowohl aus geschäftlicher als auch aus Design- und Entwicklungsperspektive.

Sie können eine Idee jedoch nicht debuggen, daher sollten erste Tests während der Produktion an den allerersten Prototypen stattfinden. Die ersten Tester bei Mail.ru sind also die Entwickler, die den Code tatsächlich schreiben. Das Unternehmen ermutigt seine Mitarbeiter, das Produkt für die interne Kommunikation (und sogar für die private Kommunikation) zu verwenden. Daher könnten Entwickler als Hardcore-Benutzer des Produkts betrachtet werden.

Der erste Schritt liegt auf der Hand: Entwerfen und Erstellen der Funktion und anschließendes lokales Testen, Überprüfen und Ausrollen auf dem Staging-Server. Hier kommen QA-Tests ins Spiel, mit umfassenden Tools und Task-Runnern, die versuchen, das Feature und die Schnittstelle zum Absturz zu bringen, möglicherweise automatisiert mit Monkey-Testing-Tools wie Gremlins.js.

Die Ergebnisse werden überwacht und dann für die nächste Iteration des Features in die Feedback-Schleife zurückgeführt. Irgendwann werden die Entwickler mit dem Build recht zuversichtlich sein: Die Änderung scheint wie erwartet zu funktionieren, und die Anforderungen wurden erfüllt. Dann kommen echte Benutzertests ins Spiel.

2. Testen Sie mit echten Benutzern in einer kontrollierten Umgebung

Wenn der erste funktionierende Prototyp fertig ist, wird die Funktion mit tatsächlichen Benutzern in Interviews getestet. Kunden werden eingeladen, Aufgaben zu erledigen, und dabei überwacht das UX-Team Sackgassen und auftretende Probleme und behebt sie vor Ort.

Das neue Feature wird jedoch nicht nur getestet; Ziel des Usability-Tests ist es, sicherzustellen, dass die neue Funktion keine kritischen Komponenten der Benutzeroberfläche beeinträchtigt, weshalb Benutzer Routineaufgaben wie das Verfassen einer Nachricht und das Öffnen, Beantworten und Durchsuchen von E-Mails in ihrem Posteingang erledigen. Wenn sowohl das neue Feature als auch die alten Features gut verstanden sind, kann der Prozess fortgesetzt werden.

3. Testen Sie mit unternehmensweiten Benutzern

Offensichtlich veranlasst das Feedback aus dem Usability-Test die Entwickler, Änderungen einzuführen, die dann an die Usability-Tester zurückgemeldet werden, wobei hin und her gegangen wird, bis das Ergebnis für ein größeres Publikum von Wert zu sein scheint. Im nächsten Schritt wird das Feature dann im Unternehmen hervorgehoben: Es wird eine unternehmensweite E-Mail verschickt, in der alle Kollegen aufgefordert werden, das Feature zu prüfen und Berichte, Bugs und Vorschläge in einem Tracker einzureichen.

Beim Testen gibt es keinen besonders großen Unterschied zwischen Benutzern in „entfernten“ Abteilungen innerhalb des Unternehmens und Benutzern in freier Wildbahn. Selbst interne Benutzer wissen nicht, welche Änderungen zu erwarten sind, oder wissen genau, was eine Funktion tut oder wie sie funktionieren oder aussehen soll. Der einzige Hauptunterschied besteht darin, dass Kollegen aufgefordert werden können, schnell Feedback zu senden oder einen Kommentar zu hinterlassen. Dann werden Abstimmungsformulare eingeführt. Tester können nicht nur mit der Funktion spielen, sondern auch einen Kommentar hinzufügen und sie positiv oder negativ bewerten. Die Abstimmung muss gegen die Produktstrategie und die Geschäftsanforderungen abgewogen werden, aber wenn Benutzer eine Funktion eindeutig als nutzlos oder hilfreich empfinden, ist dies eine einfache und effektive Möglichkeit, Feedback zu sammeln und zu testen, ob das Produkt wie erwartet funktioniert.

4. Testen Sie mit Beta-Testern

Wenn ein Feature einen technischen Check, einen Usability-Check und eine Überprüfung im Unternehmen bestanden hat, ist der nächste logische Schritt, es einigen Segmenten der Zielgruppe vorzustellen. Anstatt es jedoch einem zufälligen Segment von Benutzern zur Verfügung zu stellen, reicht das Team eine Funktion zur Überprüfung unter Betatestern ein – Benutzern, die sich entschieden haben, an Tests teilzunehmen und Feedback zu experimentellen Funktionen einzureichen. Sie können eine Funktion herab- oder hochstufen sowie Fehler melden und Codeteile übertragen.

Doch wie wählt man geeignete Beta-Tester aus? Nun, wenn Sie Tester ermutigen möchten, die Benutzeroberfläche zu beschädigen, könnten Sie sich auf fortgeschrittene loyale Benutzer mit technischen Fähigkeiten konzentrieren – Benutzer, die bei Bedarf technische Details zu einem Fehler liefern könnten, und Benutzer, die die vorhandene Benutzeroberfläche gut genug kennen in der Lage, Probleme vorherzusehen, die andere Benutzer haben könnten.

Sie benötigen jedoch Kriterien, um festzustellen, ob ein Benutzer fortgeschritten genug ist, um ein Betatester zu sein. Im Falle eines E-Mail-Clients könnte es jemand sein, der Chrome oder Firefox verwendet (dh weiß, wie man seinen Standardbrowser ändert), der mehr als drei Ordner in seinem Posteingang erstellt hat und der auch die mobile App installiert hat.

5. Testen Sie mit Benutzern, die sich manuell anmelden

Bisher umfassten die Tests eine überschaubare Anzahl von Benutzern, Konfigurationen und Testberichten. Doch die Vielfalt von Benutzern, Systemen und Konfigurationen in freier Wildbahn, einschließlich Betriebssystem, Browser, Plugins, Netzwerkeinstellungen, Antivirensoftware und anderen lokal installierten Anwendungen, kann etwas beängstigender sein.

Im Fall von Mail.ru besteht der nächste Schritt darin, die Funktion in einer Live-Oberfläche hinter einer Flagge einzuführen und eine E-Mail an dieses größere Segment aktiver Benutzer zu senden, die neue Funktion vorzustellen und sie einzuladen, sie auf ihrem eigenen zu aktivieren eigenen in der Benutzeroberfläche, normalerweise mit einem glänzenden „Aktualisieren“-Button. Um den Wert der Funktion für die tatsächlichen Benutzer zu messen, verwendet das Team wieder ein Abstimmungssystem mit einigen Eingabeaufforderungen hier und da, bei denen die Benutzer im Grunde genommen gefragt werden, ob sie die Funktion hilfreich oder nützlich finden. Beachten Sie, dass der Unterschied zwischen dieser Ebene und der vorherigen Ebene darin besteht, dass das manuelle Opt-in ein viel größeres Publikum betrifft – viele von ihnen sind im Gegensatz zu Betatestern überhaupt nicht technisch versiert.

Also kommt es auf Timing und Koordination an . Sie würden wahrscheinlich keinen zufälligen Tag auswählen, um die E-Mail an aktive Benutzer zu senden, weil Sie möchten, dass das Kundensupport-Team und die Entwickler verfügbar sind, wenn der Strom von Fehlerberichten eintrifft. Deshalb wird die E-Mail um verschickt Anfang der Woche, wenn alle (oder die meisten) Entwickler verfügbar sind und das Support-Team bereit ist, in Aktion zu treten, nachdem es über Skype oder Slack gebrieft und aktiv mit den Entwicklern verbunden wurde. In einem kleineren Unternehmen können Entwickler sogar einige Stunden an Support-Desks sitzen, um durch direkte Gespräche mit Kunden schneller zum Kern eines Problems vorzudringen.

6. Split-Test und Überprüfung der Retention

In den bisherigen Schritten haben bis auf Usability-Tests alle Tester das neue Feature freiwillig genutzt. Wenn Sie die Funktion jedoch standardmäßig aktivieren, müssen Benutzer sie plötzlich verwenden, und dies ist eine ganz andere Art von Gruppe, die wir überhaupt nicht getestet haben.

Um sicherzustellen, dass Sie die Gewohnheiten passiver Nutzer nicht brechen, könnten Sie einen Split-Test mit drei kleinen Segmenten von Nutzern durchführen und die Kundenbindung messen . Schließlich möchten Sie sichergehen, dass eine neue Version mindestens so gut funktioniert wie die vorherige. Identifizieren Sie die wichtigsten Aktivitäten in der Oberfläche und messen Sie nicht nur, wie viel Zeit die Benutzer vor und nach dem Rollout dafür aufwenden, sondern auch, wie viel Zeit vergeht, bis sie zurückkehren. Im Fall von Mail.ru bedeutet die Aufbewahrung, dass Benutzer ihre E-Mails abrufen und eine Nachricht verfassen. Je öfter ein Benutzer zurückkommt, desto höher ist die Retention, was ein Indikator für eine bessere UX ist.

Jedes Segment erhält eine etwas andere Ansicht , wodurch wir später testen können, wie die neue Funktion allen Benutzern angezeigt wird. Für das erste Segment fügen wir die neue Funktion hinzu und stellen eine Anleitung zur Verwendung bereit. Für das zweite Segment fügen wir einfach die neue Funktion hinzu. Für das dritte Segment könnten wir das Feature so lassen, wie es ist. Für alle diese Segmente könnten wir die Änderung gleichzeitig implementieren, einen angemessenen Zeitrahmen für die Durchführung des Tests auswählen, die Kundenbindung messen und dann die Ergebnisse vergleichen. Je höher die Retention eines Segments ist, desto wahrscheinlicher wird dieses Design später bei allen Benutzern beworben.

7. Lassen Sie langsam und allmählich los

Wenn ein Feature es bis zu diesem Punkt geschafft hat, funktioniert es wahrscheinlich bereits gut für einen großen Teil des Publikums. Zu diesem Zeitpunkt könnten Sie es nach und nach für alle Benutzer einführen – mit einer Abstimmungsaufforderung, um Feedback zu sammeln. Wenn das Feedback überwiegend positiv ist, können Sie das Feature weiter ausrollen und es wird schließlich zu einem integralen Bestandteil der Benutzeroberfläche. Andernfalls würden Sie das Feedback auswerten und für die nächste Iteration zum Labor zurückkehren.

Das Ausrollen des Features reicht jedoch nicht aus: Es muss den Benutzern mitgeteilt werden. Ein gängiger Weg, dies zu tun, ist über E-Mail und soziale Medien. Dennoch könnte auch ein kurzes Walkthrough-Tutorial hilfreich sein, das den Wert der Funktion in realen Szenarien erklärt. Vergessen Sie auch nicht, eine Vorschlagsbox zu integrieren, um sofort Feedback zu erhalten.

8. Messen Sie die Nachwirkungen

Sobald die Funktion eingeführt wurde, können wir ihre Leistung überwachen und verschiedene Methoden ausprobieren, um die Aufmerksamkeit darauf zu lenken, damit die Benutzer ihre Aufgaben effizienter ausführen können. Sie könnten die häufigsten Aufgaben oder die am häufigsten besuchten Seiten verfolgen und dann eine kleine Inline-Notiz anzeigen, die dem Benutzer einen etwas intelligenteren und schnelleren Weg zum Erreichen seines Ziels empfiehlt, und dann messen, ob der Benutzer diese neue Funktion oder die übliche Methode bevorzugt.

Vergessen Sie nicht, das Feedback an das gesamte Team weiterzugeben, nicht nur an die Entwickler oder Designer, damit sie motiviert und engagiert sind und sehen, wie die Leute eine Funktion nutzen, die ursprünglich nur eine grobe Idee war. Nichts ist motivierender, als glückliche, begeisterte Menschen zu sehen, die eine Anwendung genau so verwenden, wie Sie es sich vorgestellt haben, oder auf ganz andere Weise. Es wird auch das Wachstum der nachfolgenden Funktionen des Teams fördern.

Der Überprüfungsprozess sieht komplex und gründlich aus, aber manchmal kann nur die Zeit und ein weites Netz für Benutzertests ein Problem aufdecken. Beeinflusst eine Änderung beispielsweise das Aussehen der Übersicht eingehender Nachrichten, kann kein Unit-Test Schwierigkeiten aufdecken, auf die Nutzer von Hilfssoftware stoßen könnten. Was möchten Sie in einer Mailschnittstelle zuerst von der Eingabehilfe vorlesen lassen: das Datum, den Absender, die Betreffzeile oder die Nachricht selbst? Die Art und Weise, wie Sie die Spalten in der Übersicht neu anordnen, kann die Art und Weise ändern, wie Benutzer auf die Informationen zugreifen. Daher wäre es auch wichtig, ihnen zu erlauben, die neue Funktion auszuschalten.

Fazit

Wie sieht also eine Rollout-Strategie aus? Sie könnten damit beginnen, das Diagramm der Abhängigkeiten zu untersuchen, um zu verstehen, wie weitreichend Ihre Änderung sein könnte. Dann könnten Sie die Funktion mit Entwicklern und echten Benutzern in einer kontrollierten Umgebung testen. Dann könnten Sie Kollegen bitten, die Funktion zu überprüfen, bevor Sie sie an eine ausgewählte Gruppe von Betatestern senden. Schließlich könnten Sie die Funktion den Benutzern als Option zur Verfügung stellen. Und bevor Sie die Funktion für alle aktivieren, könnten Sie einen Split-Test durchführen, um herauszufinden, wie die Funktion am besten eingeführt werden kann, und dann die Aufbewahrungsraten für kritische Aufgaben messen.

Offensichtlich ist die Bereitstellung kein linearer Prozess . Während des gesamten Prozesses müssen Sie möglicherweise zwei Schritte zurückgehen, um einen Schritt vorwärts zu gehen – bis Sie schließlich einen Release Candidate haben. Der oben beschriebene Workflow mag ziemlich langsam und nicht besonders agil erscheinen, aber Sie minimieren drastisch das Risiko, dass Benutzer plötzlich mit einem unerwarteten Problem konfrontiert werden und infolgedessen eine schlechtere Erfahrung machen. In manchen Situationen kann es sich sehr lohnen.