Merkmale, Personas & Journeys

Identifizieren von Nutzergruppen

Stellen wir uns nun vor, wir dürften ein User interface für eine Kaffeemaschine gestalten. Zu den unterstützten Abläufen könnte auch die Durchführung einer jährlichen Wartung gehören. Diese Wartung könnte durch die Konsumierenden selbst durchgeführt werden.

Wir können nun in Bezug auf die beiden Merkmale Häufigkeit der Nutzung und Fachkenntnisse in Bezug auf die Funktionsweise einer Kaffeemaschine vernünftige Annahmen treffen: Sie nutzen die Funktion selten — in diesem konkreten Fall etwa einmal im Jahr. Die Konsumierenden verfügen — im Vergleich zu technischem Wartungsperson eines Herstellers — über geringe Fachkenntnisse.

Wir sehen, dass sich hier also eine Art "Klumpen" gebildet hat. Die Merkmale "Fachkenntnisse" und "Häufigkeit" unserer Nutzenden haben eine spezifische Ausprägung. Dies erlaubt uns, passende Designentscheidungen zu treffen. Es liegt in diesem Fall nahe, einen stark geführten Prozess mit möglichst vereinfachten Einstellungsmöglichkeiten anbieten.

Erweitern wir das Beispiel: Die Kaffeemaschine wird häufig in Firmen genutzt und diese Firmen profitieren von einem Serviceangebot: Sie lassen die Kaffeemaschine durch Servicepersonal warten. Dieses Servicepersonal wartet täglich mehrere Maschinen. Die Merkmalsverteilung sieht daher ganz anders aus.

Wir erkennen nun zwei Cluster. Das Servicepersonal — hier in Grün — verfügt im Gegensatz zu den Konsumierenden — in Blau gezeigt — über sehr hohe Fachkenntnisse und sie führen einen Wartungsvorgang sehr häufig durch. Ein optimales Interaktionsdesign für das Servicepersonal würde ganz anders aussehen.

Priorisieren von Nutzergruppen

Ob wir tatsächlich zwei unterschiedliche Varianten des User Interfaces anbieten, ist eine Entscheidung, die wir treffen müssen. Wenn wir nur eine einzelne Variante anbieten, dann stellt sich eine zweite interessante Frage. Für wen gestalten wir das System dann? Für die Servicetechniker? Für die Kaffeetrinker oder nehmen wir gar einen Durchschnitt an?

Ein Durchschnitt wird jedoch keine der beiden Nutzergruppen wirklich zufriedenstellen. Daher erscheint es sinnvoll, sich entweder für eine dieser beiden Nutzergruppen zu entscheiden oder aber verschiedene Varianten anzubieten. Das bedeutet nicht automatisch, dass es zwei vollständig unterschiedliche Systeme gibt: Ein System kann vereinzelte Zusatzfunktionalitäten bieten oder konfigurierbar sein.

Aufgaben und Nutzergruppen

Merkmale können sich auch auf einzelne Abläufe beziehen. So wird ein "Kaffee trinkende Person" zwar nur einmal im Jahr die Kaffeemaschine warten, jedoch täglich Kaffee beziehen. Somit lassen sich nicht alle Merkmale auf eine Benutzergruppe anwenden, relevant ist hier jeweils der Bezug von Aufgaben zu bestimmten Nutzergruppe. Constantine & Lockwood schlugen in diesem Zusammenhang das Modell einer Rolle vor (Link zum Artikel): Ein User führt eine Aufgabe in einer bestimmten Rolle durch. Jared Spool postulierte, dass zwischen den Konzepten Personas und Szenarien oft nicht getrennt werden kann (Link zum Artikel).

Zur Lösung des Dilemmas können für einzelne Personas unterschiedliche Journeys beschrieben und die Merkmale, die sich auf die Journeys beziehen, dort detailliert werden. In Frage kommen: Schritte, Kontext, Tools, Fallarten, Daten, Mengengerüste, Artefakte, Business-Regeln, Kommunikation. Mehr dazu findet sich auf einer Checkliste zu Merkmalen.

Eine weitere Besonderheit liegt dann vor, wenn Benutzergruppen zwar das gleiche System nutzen, aber nicht die gleichen Aufgaben lösen. In dem Fall haben wir als Designer oder Designerinnen etwas mehr Freiheitsgrade. Wir können in einem gewissen Maße die einzelnen Funktionsbereiche auf  bestimmte Merkmale von Nutzergruppen optimieren. Oft erweist es sich dabei als sinnvoll, zunächst Nutzergruppen mit unterschiedlichen Aufgaben zu identifizieren und dann zu überlegen, ob diese nochmals in weitere Gruppen unterteilt werden sollten.