Usability-Tests – Empfehlung für die Praxis

​Heute wird so viel von Usability gesprochen und dass man überall Usability machen sollte, weil man damit alles etwas besser machen kann … JA, stimmt … und man sollte so viele Usability-Tests wie möglich machen, denn nur so kann man alle Fehler schnell finden … OK, das würde ich so nicht unterstützen … und außerdem bekommt man die Kosten, auch bei sehr vielen Tests, durch die verkürzte Entwicklungs- und Testzeit wieder rein … OK, jetzt bin ich raus!

Es gibt so viele Usability-Tests und die meisten haben bestimmt hier und da ihre Daseinsberechtigung, aber viele Tests können schnell teuer werden und bringen meist quasi keinen oder nur einen kleinen Nutzen. Oder bringen Verwirrung oder geben vielleicht sogar eine falsche Richtung vor.

Beispiel: EyeTracking

Die Personen sind alleine vor ihrem Rechner und arbeiten frei mit der Anwendung oder arbeiten Aufgaben ab. Jetzt schauen 2 oder 3 User der Gruppe häufig in dieselbe Ecke. OK, wir wissen jetzt, das der User in die Ecke schaut, aber warum können wir nur vermuten. Vielleicht ist da ein Icon was der Person gefällt oder sie an etwas erinnert, etwas das ihnen nicht gefällt … Alles Vermutungen und vielleicht hat jeder einen anderen Grund… In den meisten Fällen bringt dieser Test nur sehr wenig und Aufwand und Kosten sind recht hoch, weil es Zeit, Probanden und Ausstattung kostet.

Hier sind ein paar Tests, die Sie als Grundlage nutzen sollten. Je nach Einsatzgebiet könne Sie diese Tests natürlich sinnvoll erweitern. Aber halten Sie die Menge der Tests möglichst klein.

Für die Praxis empfehle ich 3 Schritte, die dann während der Entwicklung in einem Kreislauf durchlaufen werden können und auch sollten.

  1. Kundenworkshops
  2. Mockups und Reduzierte Prototypen
  3. Prototyp und Vereinfachte Benutzertests

 

1. Kundenworkshops

Einer der wichtigsten Punkte bei gutem Usability Engineering sollte immer der Kontakt mit dem Kunden bzw. dem wirklichen Endanwender sein. Auch wenn man glaubt die Probleme zu kennen, der Endanwender kennt sie immer etwas besser.

Erstkontakt und „Das Kind des Kunden“ erkennen… Als ersten Kontakt zwischen Kunde und Usability Engineer sollte der Workshop das Mittel der Wahl sein und die Besetzung durch den Kunden sollte möglichst homogen sein. Haben Sie im Workshop nur Personen aus dem Management, bekommen Sie zwar einen guten Überblick über die Anforderungen, erkennen aber vielleicht nicht alle Probleme der täglichen Arbeit, die nur der Endanwender kennt.

Bei Workshops in denen Sie die Probleme mit dem Kunden betrachten sollten die Lösungsvorschläge und Anforderungen auf rein fachlicher Ebene betrachten. Die Implementierung bzw. Umsetzung sollte in diesem Kontext nicht thematisiert werden! Als Außenstehender können Sie nicht einschätzen, ob es innerhalb des Kunden schon Meinungen für oder gegen eine Lösungsvariante gibt. Sollten Sie also so einen Punkt mit einer konkreten Umsetzungsmöglichkeit ansprechen, kann es schnell zu Diskussionen führen und der Workshop schnell in eine falsche Richtung gehen. Außerdem weiß der Kunde zwar oft was er will, aber nicht was er wirklich haben kann und was eigentlich möglich ist.

Bei einem Workshop mit ihrem Kunden, kommt es in erster Linie darauf an zu erkennen was der Kunde will und wonach er sucht. Die meisten Kunden haben ein Problem das gelöst werden soll und dafür werden Sie gerufen!

 

2. Mockups und Reduzierte Prototypen

Der nächste Schritt nach dem Workshop ist das Finden von potentiellen Lösungsmöglichkeiten. Da die möglichen Lösungen bisher nicht thematisiert wurden können Sie dem Kunden nun verschiedene Möglichkeiten aufzeigen. Häufig hat der Kunde zwar schon eine Vorstellung von dem was er haben möchte, aber eben nicht davon was er haben kann und was möglich wäre. Sie sollten dem User jetzt aber nicht nur Premiumlösungen zeigen, die später sein Budget sprengen. Erstellen Sie mehrere Varianten, damit der Kunde die für sich passende Lösung finden kann.

Warum nur Mockups und Reduzierte Prototypen?

Selbstverständlich macht ein Prototyp in Form eines professionellen Renderings oder gar in lauffähiger Form mehr her, aber bedenken Sie, dass Sie noch in der Phase der Lösungsfindung sind. Ein Prototyp sollte nur so konkret wie nötig sein. Zu viel Design lenkt von der Lösungsfindung ab und bietet Potential für die Diskussionen die nicht in den Kontext der Usability gehören. Das UX-Design ist ein Bereich der später einfließen kann und außerdem sind Mockups und Papierprototypen unschlagbar günstige Varianten, die zudem noch in Echtzeit änderbar sind.

Besprechen Sie die Mockups mit dem Kunden und lassen Sie Wünsche oder Verbesserungen des Kunden in die Konzepte einfließen. Diese Absprachen sollten Sie solange wiederholen bis der Kunde zufrieden ist. Durch die vielen möglichen Änderungszyklen zeigt sich wieder warum Mockups und Papierprototypen wesentlich billiger sind als Renderings oder lauffähige Prototypen.

 

3. Prototypen und vereinfachte Benutzertests

Jetzt ist ein erstes Lösungskonzept mit dem Kunden abgestimmt und Sie können sich mit der Umsetzung der ersten lauffähigen Prototypen beschäftigen. Auch hier sollten Sie noch nicht zu viel Zeit in die Schönheit der Oberflächen investieren, denn Usability ist nicht „Schöne Masken und runde Ecken“… aber die Zeiten von Windows 98 sind auch vorbei!

Bevor Sie mit der Implementierung starten ist es ratsam sich Aufgaben/Storys zu überlegen die die User später im Zuge der Benutzertests erledigen sollen. Hiermit legt man auch schon eine Reihenfolge für die Implementierung der Masken und Features fest.

Wenn alle Masken und Features zu einer Aufgabe/Story implementiert sind wird es Zeit für die Tests mit Usern. Hier eigenen sich besonders die „Thinking Aloud Tests“ um schnelle und günstige Ergebnisse zu erzielen. Durch diese Art der Tests gewinnen Sie aber nur Erkenntnisse aus den subjektiven Eindrücken der User. Aussagen über Punkte wie z.B. Performance können hierbei nicht getroffen werden. Ein System sollte weitestgehend selbsterklärend sein, den User bei seiner Arbeit unterstützen und ihm Aufgaben abnehmen und genau zu diesen Punkten liefert dieser Test die nötigen Erkenntnisse.

Da es die Nutzer meist nicht gewohnt sind alles zu kommentieren was Sie denken, startet ein Test meist schleppend und die Benutzer werden mit der Zeit auch wieder ruhiger oder verstummen. Um diesem Verhalten vorzubeugen kann es auch ein adäquates Mittel sein den Test mit 2 Usern pro System durchzuführen, da die User so in einen Gesprächsfluss kommen. Außerdem sollte ein Test immer anonym durchgeführt werden damit sich ein User sicherer fühlt. Der Usability Engineer macht sich während des gesamten Tests Notizen um die Aktionen und Auffälligkeiten zu protokollieren.

Die so gesammelten Daten wertet der Usability Engineer später aus und die Erkenntnisse fließen zurück in die Lösungskonzepte, die wieder mit dem Kunden im Zuge von Workshops und Mockups besprochen werden.

Wir wären also wieder bei den Workshops und der Kreislauf schließt sich.

Dieser Beitrag wurde unter Software Engineering veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s