Seit fast 10 Jahren konzipiere ich nun schon Software für Autorenunterstützung. Dabei habe ich sehr viel über Produktentwicklung gelernt, aber eine der wichtigsten Lektionen war sicherlich die Folgende:
Es reicht nicht eine gute Idee zu haben oder ein Problem zu lösen, um mit Software erfolgreich zu sein.
Congree ist in einer relativ komfortablen Situation. Wir entwickeln und vertreiben ein Produkt, das in großen und mittelständischen Unternehmen nahezu unverzichtbar ist und mit dem sich beeindruckende ROIs von einem Jahr oder weniger erreichen lassen. Dennoch merken auch wir, dass das alleine nicht immer für einen Abschluss ausreicht.
Ich sehe das ein bisschen so wie mit dem Sport. Klar verstehe ich, dass Sport mein Leben verbessern und verlängern wird. Trotzdem sitze ich abends lieber am Rechner und schaue süße Katzenvideos auf YouTube. Ich habe ein Problem erkannt, kenne die Lösung, aber bin nicht gewillt, mich damit auseinanderzusetzen, weil es mir nicht attraktiv genug erscheint oder zumindest nicht mit Katzenvideos mithalten kann.
Schon vor einigen Jahren haben wir deswegen damit angefangen, uns Gedanken zu machen, wie wir Anwender und potenzielle Kunden besser abholen und für unsere Software begeistern können. Und zwar durch intuitivere, attraktivere Software, die neben einem klaren Nutzen auch ein Gefühl der Zufriedenheit auslösen sollte.
Wir sind zu Kunden gefahren, haben Konferenzen initiiert, haben Umfragen und Workshops durchgeführt und uns erhofft, dass wir die Software dadurch so angepasst bekommen, dass sich mehr Interessenten schneller dafür entscheiden, existierende Qualitätsprobleme mithilfe einer Autorenunterstützung anzugehen.
Wir haben durch das Kunden-Feedback auch tatsächlich Einiges gelernt und auch in der Software berücksichtigt. Allerdings haben wir auch noch eine überraschende Erkenntnis gewonnen:
Anwender haben manchmal Schwierigkeiten, Ihre Anforderungen zu formulieren.
Fragt man den Anwender, bekommt man oft nicht die Antworten, die das Produkt tatsächlich für ihn besser machen würden. Stattdessen muss man eher aufpassen, dass das Produkt nicht zu einem klobigen, unübersichtlichen Softwaremonster wird, ohne die wahren Begeisterungsfeatures zu enthalten. Das liegt natürlich nicht daran, dass Anwender keine guten Ideen haben. Definitiv nicht. Zurückzuführen ist dies vielmehr auf nachvollziehbare Überlegungen der Anwender:
„Meine Wünsche sind viel zu utopisch und sollten erst gar nicht artikuliert werden. Ich will niemandem Zeit stehlen.“
„Vielleicht kann die Software das ja auch schon und ich habe es nur nicht verstanden, nicht richtig aufgepasst oder das Handbuch nicht aufmerksam gelesen.“
„Meine Idee könnte total naiv sein und ich würde mich technisch versierten Menschen gegenüber bloßstellen.“
„Mein Gegenüber ist eigentlich ganz sympathisch. Warum soll ich es jetzt mit zu vielen Forderungen ärgern? Besser ich spare mir ein paar Ideen für ein andermal auf.“
„Warum soll ich mir die Mühe machen und mein Problem beschreiben? Tut sich ja eh Nix.“
„Ich will auf X klicken können, damit Y passiert. Alles Andere ist doch Unsinn.“
„Ich weiß, was ich brauche. Aber ich kann das nicht richtig verständlich machen. Mein Gegenüber versteht mich nicht.“
„Ich bin zwar nicht selbst ein Anwender aber ich weiß, was mein Team braucht.“
„Ich kenne die Software ja schon länger. Ich habe mich eigentlich daran gewöhnt, wie sie sich verhält.“
„Ich bin kein Softwareentwickler. Woher soll ich wissen, was machbar ist und was nicht?“
„Ich bin für die Anschaffung der Software verantwortlich. Jetzt soll es nicht so aussehen, als sei sie noch unvollständig.“
Man sieht also, dass „einfach mal Fragen“ zwar offensichtlich klingt, aber nicht zwingenderweise zu tatsächlich begeisternder Software führt. Vielleicht bleiben die besten Ideen verborgen. Vielleicht wird so etwas umgesetzt, was man viel komfortabler hätte lösen können.
Aber welche Alternativen haben wir dann? Ohne Input vom Anwender wird sich das Produkt früher oder später von der Zielgruppe wegentwickeln. Wie kann man seine Software so verbessern, dass sie nicht nur einen Nutzen bringt, sondern Anwender sich damit wohlfühlen und auch gerne damit arbeiten? Hierzu ist es erforderlich, sein eigenes Ego abzulegen und sich komplett in den Anwender hineinzuversetzen. Weit weg von der eigenen Meinung und Erfahrung. Dies ist der Ansatz, der heute unter dem Begriff „Empathisches Design“ bekannt ist.
Empathisches Design
Empathie ist unsere menschliche Fähigkeit das mitzufühlen, was unser Gegenüber fühlt. Seinen Schmerz oder seine Freude zu verstehen und passend darauf zu reagieren. Diese Fähigkeit lässt sich sehr gut auch für Softwareentwicklung und besonders für die Entwicklung von Benutzeroberflächen nutzen.
Empathisches Design ergibt sich nicht aus dem reinen Einsammeln von Anforderungen, sondern aus den Wünschen, Sorgen und Nöten, die sich zwischen den Zeilen rauslesen lassen. Diese Anforderungen werden oft auch nonverbal – also z. B. über Gestik, Mimik oder Handeln – an uns herangetragen.
Hinweise dieser Art können also im Dialog eingesammelt werden oder indem wir beobachten und analysieren. Immer mit der zentralen Frage im Hinterkopf: Was braucht unser Anwender eigentlich und was macht ihn glücklich?
Wirklich zuhören lernen
Bekommen wir eine Supportanfrage oder einen Verbesserungsvorschlag, wird darin in der Regel ein konkretes Problem beschrieben, für welches sich der Anwender eine Lösung wünscht. Zuerst wird das Problem geschildert („so verhält es sich gerade“), dann werden Anforderungen abgeleitet („zukünftig sollte es sich so verhalten“). An dieser Abfolge orientiert sich auch die Problemlösung. Lastenhefte und Telefonate verfolgen im Grunde ebenfalls das geschilderte zweischrittige Prinzip. Aus dieser Art von Kommunikation können wir aber noch viel mehr ableiten als nur das Gesagte.
- Wir lernen, wie die Software eingesetzt wird
- Wir bekommen ein Gefühl, wie gravierend ein Defekt eingestuft wird
- Wir sehen, welche Features der Software besonders wichtig für die Anwender sind
- Wir hören raus, ob der Anwender Supporter oder Skeptiker ist
Diese Informationen können wir dann nutzen, um das Problem nicht nur zu lösen, sondern die Software auch der Erwartungshaltung und der Einstellung unserer Anwender anzunähern. Kein Gespräch sollte enden, ohne dass man sich im Anschluss Gedanken und Notizen zu den eben genannten Punkten macht.
Zeig‘ mir, wie du arbeitest und ich zeig‘ dir, was du brauchst
Das Optimum ist selbstverständlich, den Anwender bei der Arbeit zu beobachten – sei das über Videos oder direkt vor Ort. Ich hatte öfters die Gelegenheit, Autoren einen gesamten Arbeitstag lang zu begleiten. Kein verbales Feedback ist so wertvoll, wie einem Anwender beim Verwenden Ihrer Software zuzusehen. Sie werden mit Sicherheit einige dieser lehrreichen Informationen mitnehmen:
- Funktionen werden falsch verstanden und daher falsch angewendet
- Funktionen werden für andere Zwecke eingesetzt als ursprünglich geplant
- Eine Lösung wurde um Ihre Software herumgebaut, um ein bestimmtes Problem zu lösen
- In Interaktion mit anderer Software oder bestimmter Hardware kommt es zu Seiteneffekten
- Anwender nehmen immer dieselben Einstellungen vor, die nicht den Standardeinstellungen entsprechen
- Anwender setzen Features eher selten ein (man erkennt, wie wenig Erfahrung sie damit haben) oder sehr häufig (ihre Vertrautheit ist klar zu erkennen)
Entsprechend können Sie dann darauf reagieren und die Software eindeutiger machen, um Features erweitern, kompatibler machen und den Entwicklungsfokus anpassen – immer mit diesem Hintergedanken: „Was wird für den Autor nach diesen Änderungen besser und wie steigert dies seine Zufriedenheit?“
Empathisches Design ist nicht immer einfach und auch nicht billig. Es kostet viel Zeit und Energie. Man muss zuhören können und wollen. Eine gute Beobachtungsgabe mit einem hohen Interesse an und einer tiefen Neugier für andere Menschen ist notwendig. Man muss mitleiden können, wenn ein Anwender Probleme mit der Software hat. Allerdings sind die positiven Resultate in unserer Software nicht zu übersehen. Congree macht unseren Anwendern mehr Freude, wird intensiver eingesetzt und geht schneller über die Ladentheke, als es bei unseren Vorgängerprodukten jemals der Fall war. Darum gilt in der Softwareentwicklung dasselbe, was auch in der Politik und im Privaten gilt: Ein bisschen Empathie schadet nie.
