Personas in der Entwicklung von Beratungstools

Personas sind ein Quasi-Standard in der menschzentrierten Produktentwicklung. Personas sind konkrete Personenbeschriebe, die uns helfen, Motive, Bedürfnisse und Verhalten von Nutzenden greifbar zu machen. Sie sollen das nutzerzentrierte Denken und Entwickeln von Anforderungen unterstützen. Oft wird auch davon gesprochen, die «Empathie für Nutzende zu steigern».

Personas sind jedoch keine allein durch die Produkt- und Projektteams angewendete Methodik. Wir kennen in Unternehmen eine Vielzahl von Personas, die um die Aufmerksamkeit der Beteiligten konkurrieren: Marketingpersonas, Kundentypologien, Produktpersonas, Sinus Milieus, Limbic Types (bekannter Vertreter ist Georg Häusel) – und viele mehr. Die Verwirrung könnte kaum grösser sein.

So geht es auch unseren Teilnehmenden der IG. Unsere Teilnehmenden haben zwar einen klaren Blick darauf, was sie von Personas erwarten, sind aber auch regelmässig damit konfrontiert, dass sie «bereits vorhandene Personas von irgendwo» benutzen sollen.

Dass das Benutzen von «bereits vorhandene Personas von irgendwo» leider gar nicht hilft, können wir nur unterstreichen: Wertvolle Personas für die Produktentwicklung sind immer fallspezifisch. Personas im Fall von Beratungstools müssen wiedergeben, wie die Kundinnen und Kunden zur Beratung allgemein eingestellt sind, wie sie sich vorher, während und nachher verhalten und welche Informationsbedürfnisse sie vor, während und nach der Beratung haben.

Die grösste Herausforderung an unserem Kontext der Beratungsunterstützung sind aber nicht die Kundinnen. Das sind die Beratenden. Häufig werden die Bedürfnisse und Ängste der Beratenden in Projekten nicht oder nicht systematisch berücksichtigt, und das obwohl sie die Primärnutzenden¹ des Beratungstools sind. Ohne sie bleibt das Tool in der Schublade und kann noch so gut für die Kundinnen gestaltet sein – sie werden es nie oder höchstens einmal sehen. Das kann bis zur Feature-Ebene gehen.

Ein Beispiel: Ein Finanzierungsberater wird daran gemessen, wie viele Finanzierungen er nach Hause bringt. (Wer hätte das gedacht?) Nun bekommt er ein Tool mit einer aufwändigen Immobiliensuche. Kundinnen werden das Feature schätzen, vor allem weil es durchaus Bankkundinnen und -kunden gibt, die bereits die Bank aufsuchen, wenn sie noch keine Immobilie in Aussicht haben. Für Beratende verstreicht Beratungszeit, die für sie noch keinen Wert hat. Denn das Immobilienbrowsen ist ein explorativer Suchprozess, der bei Erstkontakt eher selten zum Ziel kommt. Nicht selten werden Beraterinnen und Berater hier zurückmelden: Das konkrete Haus müssen Kunden sich schon selbst suchen.

Auch die Sichtweise gibt es, in der die Kundinnen und Kunden zu kurz kommen. Wenn Jargon durchschlägt oder angeblich bekannte Systematiken genutzt werden, um Sachverhalte zu erläutern. Wenn wir es konsequent mit «cleveren» Datenvisualisierungen zu tun haben wie Diagrammen, die mehrere Achsen auf eine zusammenlegen, Linienverläufe über Balken und Säulen gezeichnet werden und am besten zeigen wir alles aufs Mal. Beraterinnen und Berater (und die Anforderungssteller im Projekt) haben mit diesen Diagrammen häufig den Eindruck, Professionalität auszustrahlen. Bei Nutzenden kommt gelegentlich ein Gefühl von «ihr wollt doch, dass ich euch nicht verstehe» an.

Personas in der Entwicklung von Beratungstools in der IG Beratungsunterstützung

Die Interessensgemeinschaft (IG) Beratungsunterstützung besteht seit 2019 und zählt  inzwischen gesamthaft 17 teilnehmende Banken. Angefangen hat das alles gemeinsam mit 4 Banken. Mit Vertreterinnen und Vertretern der Thurgauer Kantonalbank, der Basler Kantonalbank mit der Bank Cler und der Zürcher Kantonalbank fand das Gründungstreffen statt. Die Interessensgemeinschaft steht allen Banken offen – unabhängig von der eingesetzten Beratungslösung oder dem gewählten Beratungsansatz.

Bei der letzten Durchführung rund um das Thema «Personas in der Entwicklung von Beratungstools» durften wir Vertreterinnen und Vertreter der Raiffeisen Schweiz, Schaffhauser Kantonalbank, Luzerner Kantonalbank, Liechtensteinischen Landesbank und der Thurgauer Kantonalbank zum virtuellen Treffen begrüssen.

Das Thema wurde uns von den Teilnehmenden vorgeschlagen und das erste, das so spezifisch in die Vorgehensmethodik geht. Bisherige Themen drehten sich zum Beispiel um Erfolgsfaktoren von Beratungstools, den Aufbau des Beratungszimmers und die Abbildung der Beratung in die Selbstberatung im Omnichannel.

Praxis mit den Personas

Eine Teilnehmerin berichtet einen Aha-Moment in ihrem Prozess der Entwicklung eines eigenen Beratungstools in ihrer Bank. Als sie dem Team eine Beraterpersona zeigte, konnte sie ihr Team darauf sensibilisieren, dass Beratende eben auch als Nutzendengruppe existieren. Grundsätzlich wird aber auch bei Personas für Kundinnen und Kunden ein primäres Ziel verfolgt: Das Nachvollziehen von und das aktive Auseinandersetzen mit dem noch so irrationalen Verhalten bei der Nutzung der Dienstleistung «Beratung mit Tool».

Ein Teilnehmer teilt seine Sicht wie folgt: für die Berater braucht seine Bank keine Personas, da sie in einem partizipativen Prozess das Tool entwickeln – und das ist valid! Kann ich im Anforderungsprozess auf die Nutzer (so gut wie) vollständig zugreifen zum Beispiel in Evaluationen, brauche ich keine Personas. Auch das ständige Anreichern des Wissens über Kundinnen und Kunden kann schlicht über die iterative Produktentwicklung gewährleistet werden. Es muss sich halt jemand dafür verantwortlich fühlen und das Risiko steigt, dass das in das Tool eingebaute Wissen über die Nutzenden durch Veränderungen in der Teamzusammensetzung verloren geht. Bewusstsein über beides lässt eine ausgewogene Risikoabschätzung zu.

Ein weiterer Teilnehmer berichtet, dass sie die vorhandenen Personas der Bank gar nicht einsetzen und auch keine eigenen entwickeln. Sie sind auch wegen des allgemeinen Nutzens der Personas im Vorhaben unsicher. Denn die üblichen Regeln guten Interaktionsdesigns, iteratives Entwickeln, Gestaltgesetze usw. bringen sie momentan weit (genug). Auch hier sind wir uns einig, dass das im Hinblick auf eine machbare Praxis von und mit Personas ein valider Weg ist. Personas sind sehr aufwändig zu erstellen und es ist zunächst für Teams sehr schwierig, mit ihnen zu arbeiten.

Die eigentliche Schwierigkeit besteht einzig darin, dass Beratungstools keine Selbstbedienungstools sind und daher auch speziellen Regeln im Interaktionsdesign folgen müssen. Unser Lieblingsbeispiel sind die Schriftgrössen: da Beratende und Kundinnen in Beratungsgesprächen zwischen 80-100 cm vom Screen entfernt sind (statt der 45 cm bei einem Einzelplatzbildschirm), werden sehr grosse Schriften benötigt. Die ergonomische Berechnung der Schriftgrösse gerät in Vergessenheit, wenn Gestalterinnen und Gestalter bisher ausschliesslich für den Einzelrechnerplatzabstand konzipiert haben. Unerfahrene Gestalter:innen würden wohl schnell ein angepasstes UI als «zu orthopädisch» abtun.

Abbildung: Welche Art von Personas setzen die Teilnehmenden der IG Beratungsunterstützung für die Entwicklung von Beratungstools ein?

Auffällig bei der Selbsteinschätzung zur Frage welche Personas eingesetzt werden ist, dass de facto alle bereits mit irgendeiner Art von Personas arbeiten oder arbeiten sollen. Dabei scheint die Rückkopplung von anderen Research-Aktivitäten in der Produktentwicklung zu zentral erarbeiteten Personas nicht zu existieren oder zumindest von den Personen abhängig zu sein. Das ist nicht unbedingt überraschend, aber für die Banken einigermassen kurzsichtig.

Warum Personas zentral entwickelt werden und dann durch die ganze Unternehmung verwendet werden sollen, ist durchaus nachvollziehbar. Wie bereits erwähnt: die Übung ist teuer. Und da ist der Wunsch nach möglichst breiter, möglichst langer Verwendbarkeit durchaus gerechtfertigt.

Die Schwierigkeiten daraus für die Produktentwicklung sind insbesondere diese zwei:

1. Die Informationen in den Personabeschrieben sind eben generisch, um ein bisschen was für alle Anspruchsgruppen (z. B. Marketing, Kommunikation, Sales, Produktmanagement) zu enthalten. Sie gehen aber für ein echtes Werkzeug der Produktentwicklung nicht tief genug.
2. Die Informationen altern und veralten. Besonders der Einschnitt mit der Coronazeit hat Verhalten, Erwartungen und Einstellungen zu bestimmten Bankgeschäften verändert – manche zeitweise, manche nachhaltig. Auch ohne dieses zweifelsohne besonders einschneidende Ereignis namens Covid-19 entgehen uns Veränderungen im Verhalten, wenn wir Personas nur im 10-Jahres-Rhythmus erarbeiten.

Unter den Teilnehmenden der IG haben wir daher auch den Umgang mit diesen Schwierigkeiten diskutiert. Dabei zeigt sich noch eine weitere Strategie: die Abkehr von Personas auf Unternehmensebene und das Zur-Verfügung-Stellen von Typologien. So bliebe auch (dem Namen nach) die Offenheit erhalten, dass Projekt- und Produktverantwortliche eigene Personas entwickeln (lassen) können. Das könne Schwierigkeit 1 bewältigen. Eine Frage, die dabei offenbleibt: Wie komme ich im Projekt dann von einer Typologie zu meinen eigentlichen Personas? Und wer macht das oder kann das machen? Ohne fallspezifische User Research wird auch das leider nicht funktionieren. Methodisch können sich Projekte hier auch ein bisschen allein gelassen fühlen.

Bei Schwierigkeit 2 wird es noch dünner. Gegen das Altern und Veralten können im Grunde nur zwei Massnahmen helfen: Ein geregelter Aktualisierungsprozess, der alle Anspruchsgruppen an Personas berücksichtigt oder eine kontinuierliche Neuerfassung. Letzteres ist mit den klassischen Methoden für empirisch gesicherte Personas unverhältnismässig teuer und langsam. Erst mit Möglichkeiten wie z. B. den KI-generierten Personas von evux’ Aino kann hier eine interessante Lösung gefunden werden. So können wir bereits heute Personas in einer Woche statt in vier bis sechs Wochen erstellen und so die Bedürfnisse, Motivationen und Verhaltensweisen monitoren.

Ein Aktualisierungsprozess würde voraussetzen, dass die fallspezifischen Untersuchungen des Nutzungsverhaltens methodischen Richtlinien folgen. Da dann aber quasi alle Vorhaben an der Anreicherung der Personas beteiligt sind, steigt der Wert der Personas innerhalb der Organisation immens.

Eine sehr pragmatische Vorgehensweise ist das Auslassen der empirischen Untersuchung und die Zusammenstellung von Personas als interne Hypothese oder wahlweise auch Erweiterung der internen Hypothese mit einer sehr geringen Zahl an Vertreterinnen der Nutzungsgruppe – mit der Überlegung «besser als nichts». Diese Abkürzung kann jedoch die Projektrisiken erhöhen. Sie können dramatische blinde Flecken enthalten, wenn die Datenerhebung nicht bis zur Erkenntnissättigung durchgeführt wurde und somit zentrale Nutzungsmotive verpassen. Häufig bilden diese Beschriebe Rollen ab und beinhalten besonders viele Informationen, die wir freundlich als Rauschen bezeichnen würden (banales Beispiel: Persona X hat einen Hund. Wenn es nicht gerade um eine Tierversicherung geht, ist das vermutlich nicht wirklich relevant). Dafür fehlen entscheidende Informationen für das Beratungsgespräch (z.B. Persona X entschiedet nicht allein und muss daheim einen Mitentscheider überzeugen. Dafür bräuchte diese Persona also Überzeugungsmaterial, das wir bestenfalls so in der Beratung generieren, dass die Persona eine hohe Wiedergabetreue erreicht.) Unserer Erfahrung nach beeinträchtigen diese hypothetischen Qualitäten an Personas das Image der Methode zusätzlich nachteilig und verhindern dabei das Wichtige: Den Fokus auf die eigentlichen Probleme der Nutzenden.

Besonderheiten im Nutzungsverhalten bei Beratungstools

Insgesamt gibt es neben den offensichtlichen Andersartigkeiten wie den deutlich grösseren Schriften, die auf einem Beratungstool notwendig sind, weitere Besonderheiten im Nutzungsverhalten. Diese Besonderheiten ergeben sich durch die sehr eigene Positionierung der beiden Nutzendengruppen. Während Beratende das Tool als ihr Arbeitswerkzeug und Hilfsmittel betrachten (müssen), erleben Kundinnen und Kunden den sogenannten «Beifahrereffekt». Das hat starke Auswirkungen auf die Abbildbarkeit und Abbildungsgeschwindigkeit von Informationen, die beispielsweise über Diagramme kommuniziert werden. Das besondere Informationsdesign ist kontraintuitiv für Stakeholder und für Teammitarbeitende, selbst diejenigen, die ihr fachliches Zuhause in Interaktionsdesign oder User Experience haben. Beide Spezifitäten sind zwingend in den Verhaltenspersonas zu berücksichtigen, denn sie haben starke Auswirkungen auf die Art der Features und ihre Integration in die Tools.

Zusammenfassend bleiben Personas ein sehr anspruchsvolles Werkzeug, bei dem wir in Produktteams aufpassen müssen, dass das Ganze nicht zu einer theoretischen Übung wird. Also dass wir sie nicht nur erstellen, dass wir sie haben und nicht mehr wissen, wofür. Dafür ist der Aufwand zu hoch, sie empirisch gesichert zu erstellen. Die Anschlussfähigkeit von Personas aus einer zentralen Stelle an die Arbeit in Produktteams ist auch bei Beratungstools sehr schlecht. Erst wenn erfahrene Personen die Arbeit mit Personas demonstrieren und sie regelmässig für das interne Challengen von Ideen heranziehen, werden sie ein hilfreiches Instrument der Menschzentrierung in der Produktentwicklung.

Wenn du interessiert bist, wie wir deine Personas zu neuem Schwung verhelfen können, dann melde dich gern. Das evux-Team steht dir gern zur Seite, den richtigen Weg im richtigen Kosten-Nutzen-Verhältnis einzuschlagen.

1: Terminologie Primär- und Sekundärnutzende wie z. B. in Triberti, Stefano & Riva, Giuseppe. (2015). Engaging Users to Design Positive Technologies for Patient Engagement: the Perfect Interaction Model.