Leichtgewichtige, nutzerforschungsbasierte UX-Design-Prinzipien, Personas und Szenarien (Teil 3)

Usability_Tag_Cloud"Nützliche Personas an einem Tag entwickeln? Das ist Spinnerei!"

Das stimmt. Es ist Spinnerei. Warum sollten wir einen ganzen Tag mit der Entwicklung von Personas verbringen, wenn wir das in drei Stunden tun können, maximal?

In den ersten beiden Artikeln dieser Serie (Teil 1, Teil 2) haben wir gesehen, welche Vorbereitungen nötig sind, um die kritischen UX-Design-Referenzwerkzeuge Prinzipien, Personas und Szenarien zu entwickeln. Wir können das an einem Tag umsetzen, denn wir zehren dabei von der Feldforschung, die wir gerade durchgeführt haben. Durch die Einbindung des ganzen Teams in die Nutzerforschung und die Entwicklung der Referenzwerkzeuge sind am Ende alle auf derselben Seite – bei minimalem Aufwand.

Letzte Vorbereitungen: Den Raum mit Zubehör ausstatten

Es ist ein bekannter Fakt, dass im UX-Design nichts passiert, ehe nicht farbige Klebezettel im Spiel sind. Dieser Prozess ist keine Besonderheit. Wir greifen uns also ein paar Stapel in verschiedenen Größen. (Die großen Schreibblöcke sind ebenso hilfreich wie kleine bunte Flaggen.)

Wir wollen auch je ein Flipchart auf drei Personen im Team haben und genügend Marker, um sie am Board zu nutzen. Diese kleinen farbigen Sticker sind ebenfalls praktisch.

Ein großer Raum, in dem wir Dinge an die Wände kleben können, funktioniert am besten. Im Verlauf des Tages werden wir die Klebezettel, Ausdrucke von der Nutzerforschung und die Flipchart-Seiten hier befestigen.

Und zuletzt denken Sie zurück an die Aufzeichnungen, die das Team über die besuchten Kunden gemacht hat. Davon brauchen wir jeweils ein oder zwei Kopien. Es ist hilfreich, wenn es von jedem Teilnehmern ein Bild in ordentlicher Größe gibt, zusammen mit seinem Namen und dem Standort, an dem das Team ihn getroffen hat.

Wer nimmt teil? Die Teams startklar machen

Wir haben eine einfache Regel, um zu entscheiden, wer bei der Entwicklung unserer Personas, Szenarien und Prinzipien mitreden darf – nur Leute, die ein Minimum von zwei Feldbesuchen gemacht haben. Auf diese Weise gründet jeder seine Entscheidungen auf Nutzerforschung. Wenn wir Leute dabei hätten, die nicht im Feld waren, würden diese von ihren eigenen Erfahrungen ausgehen oder von Personen, mit denen wir in dieser Runde Nutzerforschung gar nicht gesprochen haben. Es würde die Chancen reduzieren, dass wir Personas bekommen, die zu unserem Publikum passen; unsere Referenzwerkzeuge würden weniger wertvoll.

Diese Regel direkt zu Projektbeginn aufzustellen, bedeutet, dass jeder den Eintrittspreis versteht. Du willst helfen, die Personas, Szenarien und Design-Prinzipien zu entwickeln? Dann musst du mindestens zwei Standorte besuchen und Notizen machen.

Falls Sie's noch nicht durchschaut haben – das ist der geheime Teil unserer Agenda. Je mehr Teammitglieder in Kontakt mit echten Kunden kommen und ihnen bei der tatsächlichen Arbeit zuschauen, desto mehr Evidenz gibt es zu zeigen – und desto besser das UX-Design. Die Referenzwerkzeuge, die wir entwickeln, helfen uns, die Effekte dieser Beobachtungen auszuweiten. Ohne Nutzerforschung sind diese Werkzeuge nutzlos. (Mehr dazu bietet der Artikel Der schnelle Weg zum großartigen Nutzererlebnis: Das ganze Team schaut dem User zu.)

In unser Team wollen wir UX-Designer, Entwickler, Stakeholder und andere Leute integrieren, die unsere finale Lösung beeinflussen. Es ist nicht ungewöhnlich, dass nicht weniger als zwölf bis 15 Leute daran beteiligt sind, unsere Referenzwerkzeuge zu erstellen.

Diese vielen Leute teilen wir in kleinere Projektteams mit drei bis fünf Leuten auf. Jedes Team bekommt eine der Prioritäten aus der priorisierten Maßnahmenliste. Sie nutzen diese Priorität als Projekt zur Entwicklung ihrer eigenen Personas, Szenarien und Prinzipien.

Wir können Teams zufällig bilden, sie sich selbst organisieren lassen oder sie bewusst zusammenstellen (sodass zum Beispiel in jedem Team ein Designer ist). Wenn man es mit fähigen Leuten zu tun hat, macht es keinen großen Unterschied, wer in welchem Team ist, finde ich. Es funktioniert immer.

Einer unserer letzten Kunden wollte seine HR-Software erneuern, die Managern bei ihren Performance-Reviews hilft. Nachdem wir 14 Unternehmen besucht und 22 Manager und HR-Verantwortliche interviewt hatten, kamen wir zusammen, um unsere Personas, Szenarien und Prinzipien auszuarbeiten. Wir priorisierten die wichtigsten Maßnahmen, um die Software zu aktualisieren, und wiesen jedem Projektteam eine zu. Nun waren wir bereit.

Aktivität 1: Die Personas identifizieren - drei Stunden

In diesem Prozess tendieren wir dazu, die Personas zuerst und die Prinzipien zuletzt anzupacken. Der erste Schritt bei der Erstellung unserer Personas ist der, die Nutzerforschungsteilnehmer herauszupicken, die wir berücksichtigen wollen. Jedes Team wählt seine eigenen Teilnehmer – durch die Linse ihres gerade zugewiesenen Projekts schauend.

Bei der Priorität unseres Teams ging es darum, Managern beim regelmäßigen, ganzjährigen Sammeln von Performance-Informationen zu helfen. Wir hatten viele Manager dabei beobachtet, wie sie Probleme hatten, nachzuvollziehen, was ihre Mitarbeiter das ganze Jahr über getan hatten. Die jährlichen Performance-Reviews wurden massiv von den letzten paar Wochen vor der Erstellung beeinflusst. Das ist nicht fair Mitarbeitern gegenüber, die über das ganze Jahr hinweg hart arbeiten.

Als wir die Teilnehmer durchgingen, die wir bei der Feldforschung besucht hatten, suchten wir nach Managern, die mit diesem Problem konfrontiert waren, Informationen über die Jahresleistung eines Angestellten zu tracken. Wir wussten, dass wir ein Tool bauen wollten, dass dabei hilft, aber wir mussten verstehen, welche User am stärksten profitieren würden.

Wir nutzen die farbigen Punkte, um zu voten, welche Teilnehmer am kritischsten für unser Projekt sein würden. Wir stuften sie nach Anzahl der Punkte ein, von den meisten bis zu den wenigsten.

Das Auswählen und Einstufen der relevantesten Teilnehmer kostete uns ungefähr eine halbe Stunde. Die anderen beiden Projektteams taten das gleiche für ihre Prioritäten.

Die Eigenschaft der Personas herausziehen

Als nächstes wollten wir eine Liste mit Eigenschaften erstellen, die wir für unsere Personas in Betracht zogen. Die Eigenschaften sind das, was die Teilnehmer von allen anderen unterscheidet.

Einige unserer Manager arbeiteten für große, multinationale Konzerne. Einige arbeiteten in Unternehmen mit weniger als 200 Mitarbeitern.

Also war Unternehmensgröße ein Attribut, das wir aufs Flipchart schrieben. Ebenso ob die HR-Abteilung strenge Prozesse hat oder nicht. Und ob dieser Unternehmensbereich viertel- oder halbjährliche Reviews empfahl.

Wir schauten auch auf Unterschiede aufgrund der Teamorganisation. Einige Manager hatten große Teams, andere kleine. Einige hatten Teams, in denen alle ähnliche Arbeit machten (etwa ein Callcenter), andere hatten Teams, in denen jeder etwas anderes tat (wie in einem interdisziplinären Design- und Entwicklungsteam.)

Mein Team interessierte sich auch dafür, wie die Manager offenbar arbeiteten. Einige waren exzellent darin, regelmäßige Eins-zu-eins-Gespräche mit all ihren direkten Berichten zu führen, während andere so etwas nie taten. Einige konnten sich schlecht Notizen machen, andere waren hier sehr gründlich. All diese Unterschiede kamen aufs Flipchart.

Nochmals: Wir hatten all diese Dinge im Rahmen kürzlich durchgeführter Nutzerforschung gesehen. Hätten wir sie nicht gesehen, wären sie auch nicht auf unserer Liste mit Eigenschaften gelandet.

Der einfachste Weg, diese Unterschiede zu sammeln, war der, die obersten zwei Teilnehmer vom Stapel zu nehmen und sie nebeneinander zu hängen. Dann fragten wir, was sie unterschied. Wir hielten die Unterschiede auf dem Board fest und ersetzten dann einen der Teilnehmer durch den nächsten. Das wiederholten wir, bis wir nichts Neues mehr herausfanden. Der Prozess des Identifizierens von Eigenschaften dauerte etwa eine Stunde.

Skalen für die Eigenschaften

Als nächstes nahmen wir die eben erstellte Eigenschaftenliste und voteten mit den farbigen Punkten, welche Attribute unserer Meinung unser neues Tool zum Sammeln von Performance-Daten über das ganze Jahr hinweg am meisten tangieren würden.

Wir schrieben die Top-Eigenschaften in Großbuchstaben auf größere klebende Blätter. Dann ermittelten wir die Skala für das Attribut und schrieben die Endpunkte auf jede Seite.

Eines unserer Attribute war Gründlichkeit beim Notizen-Machen. Auf eine Seite des Klebezettels schrieben wir "Macht sorgfältig Notizen" und auf die andere Seite "Macht schlecht Notizen".

Eine andere Eigenschaft lautete Teamrollen-Unterschiede. Auf eine Seite schrieben wir "Sehr ähnlich" und dachten an die Callcenter-Leute, auf der Seite gegenüber stand entsprechend "Alle verschieden" wie im Entwicklungsteam, das wir besucht hatten.

Wir hängten unsere Blätter mit Eigenschaften an der Wand auf, und zwar von der wichtigsten (basierend auf unserem Voting) bis zur am wenigsten wichtigen. (Mit Attributen, die überhaupt keine Punkte erhalten haben, beschäftigen wir uns normalerweise nicht weiter.)

Unsere Personas ausgestalten

Aus unserer Eigenschaftenliste, die auf echten Leuten basierte, die wir beobachtet hatten, konnten wir nun die interessantesten zusammentragen, um unsere Personas zu formen. Diese Personas sollten die Grundlage für künftige UX-Design-Entscheidungen bilden; es richtig hinzubekommen, war also die Mühe wert. Unser Ziel war es, drei bis fünf Personas zu erhalten, mit denen man arbeiten konnte.

Für jede Persona eine andere Farbe nutzend, setzten wir kleine Klebezettel oder Flaggen. Jemand im Team schlug ein Set an Eigenschaften vor, klebte den Zettel auf die Seite der Skala, die aus seiner Sicht eine interessante Persona charakterisieren würde.

Eine Person, die uns interessierte, war ein First-time-Manager in einem großen Unternehmen, in dem HR nicht sehr unterstützend war. Hier könnte der Manager ein großes Team mit ähnlichen Rollen haben.

Eines unserer Teammitglieder klebte eine lila Flagge auf das Attribut Unternehmensgröße nahe der Groß-Seite auf der Skala, bei HR-Support nahe "Nicht sehr", bei Manager-Erfahrung nahe "Neuling" und bei Teamrollenunterschiede nahe "Sehr ähnlich". Alle nickten übereinstimmend. "Das ist genau wie Roger von Acme", sagte einer von uns.

Wir einigten uns auf Namen für jede Persona, darunter First-time-Freddy und Erfahrende Managerin Evelyn. Die farbigen Stecker halfen uns zu sehen, ob wir die Personas im Hinblick auf bestimmte Eigenschaften beeinflussten. Das Ziel war eine hübsche Verteilung auf jeder der wichtigen Attribut-Skalen.

Die Dokumentation all unserer Personas war einfach. Eine simple Ausarbeitung mit halb verschleierten Beschreibungen dessen, was wir bei der Nutzerforschung gesehen hatten, lieferte uns vier solide Personas. Jede von ihnen konnten wir mit echten Unternehmen und Managern in Verbindung bringen.

Wir verbrachten die letzte halbe Stunde unseres Vormittags damit, die Personas mit den anderen Teams zu teilen. Jedes Team stellte den anderen seine Personas vor und ging die wichtigsten Eigenschaften für das spezifische Projekt durch. Es war faszinierend, die Überlappungen zu sehen, und die Unterschiede boten uns interessante Perspektiven auf unsere eigenen Personas.

Im kommenden vierten und letzten Teil der Artikelserie geht es schließlich um den Entwicklungsprozess der Szenarien und UX-Design-Prinzipien.

Dieser Artikel wurde im Original am 14. November 2013 unter dem Titel LiRPPS: Lightweight, Research-Based Principles, Personas, and Scenarios - Part 2 von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.