Usability-Tests als einziger, abschließender Meilenstein – oder: Die beste Möglichkeit Geld zu verbrennen

Ich befinde mich auf dem Rückweg von einer Kundenpräsentation und bin, sagen wir mal, nicht bei bester Laune.

Warum?

Weil ich einmal wieder schlechte Nachrichten überbringen musste. Dem neuen Kunden mitteilen musste, dass er das geplante Release in ein paar Wochen tunlichst nicht durchführen sollte aufgrund erheblicher, im abschließenden Usability-Test identifizierter Nutzungsprobleme.

Ok, wir UXler werden nun einmal für Forschung und konstruktive Kritik bezahlt. Aber manchmal schlägt es mir dann doch aufs Gemüt. Besonders dann, wenn ich schon beim ersten Telefonat merke, dass es so kommen muss.

Die jetzige Einsicht des Kunden, dass er es von Anfang an besser hätte machen können und zukünftig eine frühzeitigere, nutzerzentriertere Vorgehensweise wählen wird, ist toll (Einsicht ist der beste Weg …) Dennoch muss er sich nun gegenüber dem Lenkungsausschuss rechtfertigen. Und dies wird auch auf uns als Berater abfärben, unabhängig davon, zu welchem Zeitpunkt wir hinzugezogen wurden. Prekär, da es doch der Erfolg unserer Kunden und deren Zufriedenheit sind an denen wir uns stetig messen.

Dabei könnte vieles doch so einfach sein…

Die gute alte DIN-Norm hilft beim Sparen

…denn seit 2000 existiert die DIN EN ISO 13407 ‚Benutzer-orientierte Gestaltung interaktiver Systeme‘, die einen prototypischen, benutzerorientierten Softwareentwicklungsprozess in folgenden Teilaktivitäten beschreibt:

  1. Nutzungskontext verstehen
  2. Anforderungen spezifizieren
  3. Lösungen produzieren (Prototyping, Mockups)
  4. Lösungen bewerten (z.B. per Usability-Test)

Erst ganz am Ende steht die tatsächliche, programmiertechnische Umsetzung! (Hinweis: Ab Januar 2011 ist als Ersatz für diese Norm die EN ISO 9241-210 ‚Prozess zur Gestaltung gebrauchstauglicher Systeme‘ gültig.)

Nun gut, unsere Projekterfahrungen zeigen, dass  diese Vorgehensweise besonders im B2B / Industrie-Umfeld immer noch nicht gänzlich angekommen zu sein scheint. Deswegen wiederhole ich mich gerne auch immer wieder und missioniere; eben weil mir dieses Thema so wichtig ist.

Denn: je frühzeitiger man sich bei der Produktentwicklung (ganz gleich, ob Website, Mobile, Intranet, Software, etc.) mit den Anforderungen seiner Nutzer beschäftigt, diese in bedingt-funktionale Prototypen umsetzt, etc., desto mehr kann man sparen: ZEIT, GELD und vor allem NERVEN. Ganz nebenbei bekommt man am Ende noch eine bessere, nutzerfreundlichere Anwendung heraus.

Zurück zur Geschichte…

Vor 2 Monaten klingelt wie so oft am späten Freitagnachmittag das Telefon: Ein potentieller Neukunde möchte einen abschließenden Usability-Test durchführen; möglichst zeitnah, da sie bereits mitten in der Programmierung der neuen Version Ihrer Webapplikation sind. In 2 Monaten ist Releasetermin. Da muss dann alles stehen.

Zielgruppe: Klein-/Großkunden bzw. (Normal- und Power-User) im B2B-Bereich.

Meine Frage, inwiefern die Kundenforderungen erhoben und in die neue Version eingeflossen sind, wird wie folgt beantwortet: „Wir haben unsere Großkundenbetreuer gefragt, die sind ganz nah dran am Kunden und unseren Support.“

Meine Gegenfrage: „Haben sie zwischenzeitlich im Projektverlauf immer mal wieder Kundenfeedback eingeholt – sowohl von den Normal- als auch Power-Usern?“ Antwort vom Kunden: „Nein, das wollen wir ja nun mit Ihnen tun, wenn unsere Betaversion voll funktionstüchtig und stabil ist.“

Ich verzog meine bislang gut gelaunte Miene und hätte am liebsten folgendes Geräusch gemacht: “Plumps!“, um dem Kunden zu signalisieren, dass das Kind bereits in den Brunnen gefallen war.
Stattdessen erwähnte ich meine Bedenken höchst diplomatisch und schritt zur Tat: „Natürlich unterstützen wir Sie gerne bei diesem Projekt: erstellen gemeinsam mit Ihnen ein Studienkonzept, rekrutieren in Absprache mit Ihnen die passenden Probanden, führen die Interviews, werten die Beobachtungen und Aussagen aus und liefern Ihnen einen managementorientierten Bericht mit konkreten Handlungsempfehlungen.

Gesagt getan… Während der Erhebung und deren Beobachtung durch eine Handvoll Kunden bot sich dann das befürchtete Szenario (kommt leider öfters vor, wenn erst am Ende eines Projektes ein Usability-Test gemacht wird): alle Beobachter, schreien mehr oder weniger laut auf, wenn die Probanden Probleme haben/nicht weiterkommen. Die einen, weil sie nicht den Grund dafür nicht („das liegt doch klar auf der Hand/guck doch nur hin.“); die anderen, weil „sie es ja schon immer gesagt haben, dass das nicht funktioniert.“

Den Rest der Geschichte bis hin zur heutigen Ergebnispräsentation kennen Sie ja bereits…

Was lernen wir aus dieser Geschichte?

Anforderungsanalysen und frühzeitiges Prototyping mit bedingt-funktionalen(!) Prototypen sind das A&O und der Garant dafür, Projektzeitpläne & Budget besser einhalten zu können und im gesamten Team für bessere Laune zu sorgen.

Meine Kollegin Frau Struckmeier hat einen vertiefenden Artikel zum Thema „Iterativ testen – Warum eigentlich?“ verfasst, auf den ich gerne verweise.

Sofern jedoch nicht nur der Bedarf an iterativem Testing (Rapid Prototyping) besteht, sondern der gesamte Entwicklungsprozess (Anforderungsanalyse, Konzeption, Testing und Design) in die Hände einer erfahrenen UX-Agentur gelegt werden soll, kann ich folgenden Link empfehlen: User Experience Konzeption (hier finden Sie erfolgreiche Projektbeispiele).

Ihre Meinung

Gerne können Sie mir auch Ihre Projekterfahrungen mitteilen. Ging es Ihnen bereits auch schon einmal so wie mir? Haben Sie andere Erfahrungen sammeln können – ganz gleich, ob auf Kunden- oder Agenturseite?
Ich freue mich auf Ihre Kommentare zu diesem Thema.

6 Gedanken zu „Usability-Tests als einziger, abschließender Meilenstein – oder: Die beste Möglichkeit Geld zu verbrennen

  1. Martin Beschnitt Beitragsautor

    Hallo Herr Buggisch, vielen Dank für Ihren beigesteuerten Link. So sollte ein Relaunch-Prozess aussehen. Wobei es da je nach Zielgruppe, Nutzungskontext, Art der Anwendung immer feine Nuancen zu beachten gibt. Wäre ja langweilig, wenn es für alles die eine richtige Vorgehensweise gibt;-)

    Antworten
  2. Bernhard Kelz

    Ich darf bei solchen Debakeln manchmal zusehen. Ich bin häufig erst nach UX dran und manchmal derjenige, der das Fass dann zum Überlaufen bringt, denn ich kümmere mich um das Thema Recht und Datenschutz. Wenn ich überhaupt gefragt werde bevor die erste Abmahnung auf dem Tisch liegt, dann auch erst wenn die Applikation schon fertig ist. Das Ergebnis ist häufig dasselbe wie bei den UX-Tests… alles auf Anfang. Spaßig wird es vor allem dann, wenn man alles nur bilateral bespricht und UX und Datenschutz nicht gemeinsam an einen Tisch holt, denn Datenschutz ist by default nicht auf nutzerfreundlichkeit ausgelegt. Gemeinsam hat man zumindest den Hauch einer Chance, eine grafisch ansprechende, nutzefreundliche und rechtskonforme Anwendung zu bauen. Aber was rede ich, ihr kennt das sicherlich…

    Vielen Dank für den Artikel, der mir zumindest den Trost spendet, dass ich nicht alleine bin 🙂

    Antworten
  3. Pingback: 10 Lesetipps der Woche für Shopbetreiber » shopbetreiber-blog.de

  4. Pingback: 3 typische Aussagen zur Relativierung von Usability-Problemen | Usabilityblog.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *