Objektives Testen des Qualitätsfaktors mit Customer Journey Map

Hallo, Chabrowsk-Bürger!

Ich bin von Beruf Analyst und entwerfe seit 10 Jahren Systeme und Schreibanforderungen. Ich schlage vor, den Ansatz zum Testen von UX / UI zu diskutieren.

Vor der Quarantäne stieß ich auf eine Situation: Ich musste ein Flugticket kaufen. Ungefähr 30 Minuten ging ich in den luftlosen Raum: Während ich alle Felder ausfüllte (obwohl es ein Profil im Service gibt), überprüfte ich alles nicht ein einziges Mal und entfernte dann sorgfältig alle bezahlten Optionen.
IMHO, das ist unmenschlich.

Warum nicht meine Daten speichern und ersetzen? Warum zusätzliche Optionen auferlegen - reduziert die Loyalität?

Ich denke, ich bin nicht der einzige, der sich über die unangenehme und unverständliche UX / UI ärgert. Frage: "Wie wird es behandelt?"



Bisher bin ich zu dem Schluss gekommen, dass eine Lösung ein systematisches und unabhängiges Testen von Systemqualitätsindikatoren sein kann. Diejenigen, über die am Institut und in den Lehrbüchern gesprochen wird: Ergonomie, Komfort, Verständlichkeit, Geschwindigkeit der Aufgabenausführung.

In der Regel läuft die Qualitätsprüfung auf Folgendes hinaus:

• Das Team arbeitet mit aller Kraft, um die Funktionalität rechtzeitig zu gewährleisten, und niemand denkt an UX / UI
• UX / UI wird nur auf Übereinstimmung mit Layouts überprüft
• UX / UI-Tests werden nach Geschmack und persönlicher Einschätzung des Testers durchgeführt. Ja, dies kann durch allgemeine Regeln gerechtfertigt sein (z. B. aus Coopers Büchern „On Interfaces“), aber in benutzerdefinierten und B2B-Systemen gibt es häufig nicht triviale Lösungen. Das Team kann sich in Geschmack und Vorstellungen über das Schöne unterscheiden. Dies führt zu unkonstruktiven Streitigkeiten aufgrund von Meinungsverschiedenheiten. Der Stärkste gewinnt in ihnen.

Dann dachte ich, dass eine ähnliche Geschichte passiert, wenn Anforderungen in Produkten gesammelt werden. Es kommt vor, dass die Entwickler eine Entscheidung für ihre Schmerzen treffen und denken, dass sie die Bedürfnisse der Endbenutzer schließen werden. Um die Realität abzubilden, gibt es Möglichkeiten a la Customer Journey Map.

Das Wesentliche der Methode besteht darin, die Erfahrung mehrerer Benutzer anhand einer statistischen Stichprobe zu nutzen, um ein bestimmtes Problem zu lösen. So können Sie herausfinden, ob andere Menschen mit einem Problem konfrontiert sind und ob diese Situation nur für eine kleine Gruppe von Menschen gilt oder ob es sich um ein Gesamtproblem handelt.

Warum nicht dieses Prinzip und UX / UI überprüfen?

Testalgorithmus:

1) Legen Sie eine Testrichtlinie fest.

• Satz von Benutzerskripten zum Testen
• getestete Qualitätsindikatoren: Komfort, Ergonomie, Verständlichkeit usw.

2) Finden Sie die zu testenden Befragten

Von 3 bis 5 Befragten. Es können Endbenutzer oder Mitglieder eines anderen Teams sein. Die Hauptsache ist die Unabhängigkeit vom Entwicklungsteam.

3) Führen Sie eine Studie durch. Wiederholen Sie den

Zyklus mit jedem Befragten.
> Die Benutzerkartenvorlage wird erstellt.
> Der Befragte erhält eine Einführung in die Aufgabe und ein laufendes System / Prototyp / Layout.
> Die Schritte des Befragten, sein Feedback, die Zeit für einen Schritt - all dies wird am
Ende der Vorlage aufgezeichnet.



4) Aggregierte Daten.

Da eine Kartenvorlage eine Meinung ist, müssen Sie den Schnittpunkt der Befragten finden. Für jedes Szenario wird eine Gap-Map-Matrix erstellt (in den besten Traditionen von CJM).

• Matrixspalten - Skriptschritte.
• Linien sind ein Indikator für Unzufriedenheit.
• An der Kreuzung - die Ergebnisse aus den Karten der Befragten.
• Die Schritte, die die meiste Zeit in Anspruch genommen haben, oder negative Emotionen, Missverständnisse - das sind die Schmerzen der Qualität des Systems.

5) Erstellen Sie eine Liste der gefundenen Probleme.

Ich habe es GrowthPointsList genannt.



Die Daten sind in der Liste der Probleme + Erwartungen der Befragten zusammengefasst, wie sich das System verhalten wird. Sie können den Grad des Einflusses auf die Passage des Skripts angeben:

1. Das Skript kann nicht abgeschlossen werden
2. Negativ, aber Skript bestanden
3. Einige Befragte hatten ein Negativ, aber sie haben es geschafft, durch das Skript zu kommen.

So ist es bereits vor der Entwicklung in der Phase des Layouts möglich, Layouts zu testen und Probleme zu geringeren Kosten zu beseitigen. Das Testergebnis ist angemessen und führt zu keinen Kontroversen zwischen den Teilnehmern und dem Kunden.

Ich denke, die Welt der Anwendungen kann sich daher in Richtung Bequemlichkeit und Einfachheit für Endbenutzer ändern.

Telegrammkanal - tlgg.ru/@analyst_way (Analystenpfad)