TalkAbout

UCD: Lösungen evaluieren

Von Julian Traut @J_Traut_Tweet auf Twitter
2. April 2019

User-Centered Design bedeutet, NutzerInnen in den Mittelpunkt unserer Arbeit zu stellen. Wir beschreiben unser Vorgehen in einer Artikelserie über ein fiktives Projekt beim fiktiven Logistikunternehmen ML. Jede der vier Phasen unseres Projekts steht im Mittelpunkt eines eigenen Blog-Artikels. Der erste Teil beschäftigt sich damit, den Nutzer-Kontext zu verstehen. Der zweite Teil erklärt, wie Anforderungen formuliert werden sollten. Im dritten Teil geht es um das Entwickeln von Ideen im Partizipativen Parallelen Design Workshop. Hier geht es zur Leküre. In diesem Blog schreibe ich über die vierte Phase: Lösungen evaluieren. Die Links zu  den bisherigen Teilen teile ich unten.


In die Lösungsevaluation eintauchen

Mit dem Klickprototypen wollen wir vor der Entwicklung nochmal in einen ausgedehnteren Usability-Test gehen. Wir sind bereits mit den ersten Papierprototypen zum ersten Mal in die Phase der Lösungsevaluation eingetaucht. Direkt nach den PPDs haben wir beispielsweise die konsolidierten Entwürfe einer heuristischen Evaluation unterzogen. Was so hochtrabend klingt, ist mit unseren Usability-Karten eigentlich ganz einfach. Um eine hohe Usability sicherzustellen, gibt es zahlreiche grundsätzliche Regeln und Vorgaben, denen eine Anwendung folgen sollte. Diese sind auf den Karten so aufbereitet, dass man schnell prüfen kann, ob eine Anwendung diesen Ansprüchen genügt.

Dabei gibt es so viele Aspekte zu berücksichtigen, dass man sie beim Konzipieren selten auf Anhieb alle erfüllt. Außerdem muss man häufig eine Abwägung zwischen verschiedenen Anforderungen machen. Hier helfen uns die Usability-Ziele, die wir anfangs im Projekt formuliert haben, diese Entscheidungen nicht nur nach Bauchgefühl, sondern an den Nutzer- und Nutzungsanforderungen orientiert zu treffen.

Gut war, dass wir die Evaluation nach einigen Iterationen bereits wiederholt hatten. Unser Prototyp hatte Stück für Stück an Komplexität gewonnen und als wir diesen noch einmal strukturiert anhand der Karten untersucht haben, stellten wir fest, dass die Orientierung in der Anwendung nun gar nicht mehr so leicht war wie in den Einzelschritten. Das konnten wir schnell durch eine entsprechende Navigation beheben. So konnten wir uns in den Nutzertests wirklich auf die Fachlichkeit konzentrieren und mussten nicht „herausfinden“, dass sich die NutzerInnen in unserer Anwendung verlaufen.

Effektive Tests gestalten

Wir wussten, dass unsere NutzerInnen sich die Zeit mit uns immer aus ihrem Tagesgeschäft herausschneiden mussten. Deshalb war es uns sehr wichtig, die Tests mit ihnen möglichst effektiv zu gestalten. So haben wir uns entschlossen, neue Entwürfe erstmal bei uns intern durch einen Guerilla Test zu schicken. Tests mit fachfremden Personen sind natürlich nicht so aussagekräftig. Manchmal war es auch schwierig, die Aufgaben für die Tests so zu gestalten, dass der Kollege von nebenan mal eben einen Test machen konnte. Dennoch hat es uns sehr geholfen, ganz grundlegende Usability-Probleme zu identifizieren, bevor wir uns wieder an die echten NutzerInnen gewendet haben.

Für den finalen Usability-Test haben wir uns entschieden eine größere Nutzergruppe auszuwählen. Zum einen wollten wir valide Ergebnisse und zum anderen wollten wir den Werbeeffekt unseres Klickprototyps nutzen, um uns auch für die nächsten Phasen unsere AnwenderInnen gewogen zu halten. Wir haben daher die NutzerInnen in zwei Gruppen geteilt. Sechs von ihnen haben wir in einem geführten Test bei der Lösung von mehreren Aufgaben beobachtet. Alle anderen haben wir per Mail gebeten, die Aufgaben selbstständig durchzuführen und danach einen kurzen Fragebogen auszufüllen. In dem Fragebogen haben wir sowohl einige offene Fragen gestellt, um unter anderem nochmal die Priorisierung der nächsten Features festzulegen, als auch die standardisierte „System Usability Scale“ verwendet. So konnten wir tatsächlich messen, ob wir mit unserem Vorgehen auch in der Breite eine hohe Usability unseres Prototyps erreicht haben.

Mit einem Wert von 83 lagen wir nur knapp unter der „Excellent“ Marke, für einen frühen Prototyp ein beachtliches Ergebnis. Gemeinsam mit Annett Haders und vielen der AnwenderInnen, die wir in den letzten Wochen kennen- und schätzen gelernt haben, feiern wir diesen großartigen Abschluss der ersten Projektphase bei Sekt und Snacks.

Futter für die EntwicklerInnen

In ein paar Wochen wird unser Entwicklungsteam loslegen. Bis dahin haben wir noch etwas Zeit, um die Epics zu Priorisieren, ein initiales Backlog mit den ersten User Stories zu erstellen und die anderen Artefakte auf Vordermann zu bringen. Schon jetzt überlegen wir uns, wie wir Big Picture und Prozessbilder zum Onboarding der neuen KollegInnen nutzen können. Sicherlich werden uns die Personas und Employee Journeys helfen, den EntwicklerInnen zu vermitteln, für wen wir eine Anwendung bauen. Die größte Herausforderung wird es sein, unseren EntwicklerInnen in der Fachlichkeit und dem Wissen über die Nutzer immer eine Nasenlänge voraus zu sein. Schließlich wollen wir sie kontinuierlich mit neuem Futter versorgen und die vielen Details, die wir noch nicht bedenken konnten, schnell klären. Wir freuen uns drauf und werden berichten.


In unserer Blog-Serie über User-Centred Design beschreiben wir unser Vorgehen an einem fiktiven Projekt. Wir beschreiben jede der vier Phasen unseres Vorgehens in einem eigenen Blog-Artikel:

    1. den Nutzer-Kontext verstehen (Link zum Artikel)
    2. Anforderungen formulieren (Link zum Artikel)
    3. Ideen entwickeln (Link zum Artikel)
    4. Lösungen evaluieren (Artikel oben)
    Deutsch

    Neuen Kommentar schreiben

    Public Comment form

    • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

    Plain text

    • Keine HTML-Tags erlaubt.
    • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
    • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

    ME Landing Page Question