Wenn man Software selbst entwickelt, kennt man ihre innere Logik. Man weiß, warum eine Funktion an einer bestimmten Stelle liegt, was ein Begriff bedeutet und welche Reihenfolge bei einem Vorgang vorgesehen ist. Genau dieses Wissen ist bei der Entwicklung notwendig, gleichzeitig macht es aber erstaunlich schwer, die eigene Anwendung so zu sehen wie ein Mensch, der all diese Hintergründe nicht kennt.
Meine Erfahrungen im Helpdesk haben meinen Blick darauf deutlich verändert.
Dort interessiert zunächst niemanden, wie elegant der Code hinter einer Funktion aufgebaut ist, welche Architekturentscheidung besonders gelungen war oder warum eine bestimmte Benutzerführung aus technischer Sicht logisch erscheint. Entscheidend ist etwas wesentlich Einfacheres: Ein Mensch möchte eine Aufgabe erledigen und kommt an irgendeiner Stelle nicht weiter.
Diese Perspektive ist mir bis heute geblieben und beeinflusst auch die Software, die ich selbst entwickle.
Im Helpdesk landet die Realität der Benutzer
Software lässt sich aus sehr unterschiedlichen Blickwinkeln betrachten, und der Helpdesk besitzt dabei eine besonders direkte Perspektive.
Dort kommen nicht die theoretischen Abläufe an, die man beim Entwurf vorgesehen hat, sondern die Situationen, die tatsächlich passieren.
Ein Benutzer klickt in einer Reihenfolge, mit der niemand gerechnet hat. Eine Meldung wird völlig anders verstanden, als sie gemeint war. Eine Funktion wird für einen Zweck verwendet, für den sie ursprünglich gar nicht gedacht war. Ein Schritt wird übersprungen, weil der Benutzer nicht erkennt, warum er notwendig ist.
Aus Entwicklungssicht kann man viele dieser Situationen schnell als Bedienfehler einordnen.
Das ist manchmal sogar korrekt.
Trotzdem lohnt sich eine zweite Frage:
Warum war dieser Bedienfehler so naheliegend?
Genau diese Frage hat meinen Blick auf Benutzeroberflächen und Abläufe nachhaltig verändert.
„Der Benutzer hat es falsch gemacht“ ist selten das Ende der Analyse
Natürlich kann Software nicht jede denkbare Fehlbedienung verhindern.
Menschen können falsche Daten eingeben, Hinweise ignorieren oder bewusst etwas tun, das offensichtlich nicht vorgesehen ist. Trotzdem ist es für mich zu einfach, jeden solchen Fall damit abzuschließen, dass der Benutzer eben einen Fehler gemacht hat.
Wenn immer wieder unterschiedliche Menschen an derselben Stelle denselben Fehler machen, liegt das Problem möglicherweise nicht mehr ausschließlich bei ihnen.
Dann sollte ich mir ansehen, ob die Oberfläche eine falsche Erwartung erzeugt, eine wichtige Information zu spät zeigt oder einen Ablauf unnötig missverständlich gestaltet.
Im Helpdesk wird genau das sichtbar, weil nicht nur der einzelne Fehler zählt, sondern auch Muster entstehen.
Was aus Entwicklersicht wie zehn unabhängige Bedienfehler aussieht, kann aus Supportsicht plötzlich ein sehr deutliches Signal dafür sein, dass eine Funktion anders gestaltet werden sollte.
Fehlermeldungen sehen aus Entwicklersicht völlig anders aus
Ein besonders gutes Beispiel sind Fehlermeldungen.
Für mich als technisch arbeitenden Menschen kann eine präzise Fehlermeldung sehr hilfreich sein. Ein Fehlercode, eine Exception oder ein konkreter Systemzustand gibt mir Hinweise darauf, wo ich nach der Ursache suchen muss.
Für einen normalen Benutzer beantwortet dieselbe Meldung häufig keine einzige relevante Frage.
Er möchte meistens wissen:
Was ist passiert, und was soll ich jetzt tun?
Eine Meldung kann technisch vollkommen korrekt sein und trotzdem unbrauchbar bleiben, wenn sie nur die interne Ursache beschreibt.
Das hat meine Vorstellung von guten Fehlermeldungen stark geprägt.
Ich möchte, soweit es sinnvoll möglich ist, nicht nur melden, dass etwas nicht funktioniert hat. Die Anwendung sollte auch vermitteln, welche Konsequenz das hat und ob der Benutzer selbst etwas tun kann.
Technische Details können zusätzlich für Logs oder Diagnosezwecke vorhanden sein.
Sie müssen aber nicht die erste Information sein, mit der ein Benutzer konfrontiert wird.
Gute Software muss nicht alle internen Zusammenhänge erklären
Dabei geht es mir nicht darum, jede technische Funktion ausführlich in der Oberfläche zu erklären.
Eine gute Anwendung sollte im Gegenteil möglichst viel durch ihr Verhalten, ihre Struktur und ihre Benennung verständlich machen.
Wenn ich für einen simplen Vorgang eine halbe Seite Hilfetext benötige, ist das möglicherweise ein Zeichen dafür, dass der Ablauf selbst unnötig kompliziert ist.
Mein Oma-Test setzt genau an dieser Stelle an. Ein Mensch ohne mein internes Wissen muss nicht jedes technische Detail verstehen, sollte aber möglichst erkennen können, worum es geht, was von ihm erwartet wird und welche Folgen eine Aktion ungefähr haben wird.
Diese Haltung kommt zu einem erheblichen Teil aus der Helpdesk-Perspektive.
Denn dort sieht man sehr schnell, wie wenig Nutzen eine logisch perfekte Oberfläche hat, wenn ihre Logik nur für denjenigen offensichtlich ist, der sie entwickelt hat.
Seltene Sonderfälle sind im Helpdesk plötzlich gar nicht mehr so selten
Während der Entwicklung bewertet man Sonderfälle häufig danach, wie wahrscheinlich sie erscheinen.
Ein bestimmter Zustand dürfte eigentlich nur selten eintreten.
Ein ungewöhnlicher Ablauf wirkt so speziell, dass man ihn zunächst nicht besonders hoch priorisiert.
Im Support kann sich diese Wahrnehmung verändern.
Selbst wenn ein Problem nur einen sehr kleinen Anteil der Benutzer betrifft, kann es regelmäßig auftreten, sobald genügend Menschen mit der Software arbeiten. Außerdem landen gerade ungewöhnliche Situationen besonders häufig im Helpdesk, weil normale Abläufe eben keinen Support benötigen.
Dadurch lernt man, Wahrscheinlichkeit etwas anders zu betrachten.
Ein Fehler muss nicht ständig auftreten, um für die betroffenen Menschen sehr störend zu sein.
Und manche vermeintlich seltenen Zustände verdienen deshalb mehr Aufmerksamkeit, als man ihnen beim ersten Entwurf geben würde.
Helpdesk-Erfahrung verändert auch mein Testing
Diese Perspektive passt gut zu meinem heutigen Ansatz für automatisierte Tests.
Ich möchte nicht nur prüfen, ob der vorgesehene Standardablauf funktioniert, sondern gezielt Situationen erzeugen, die außerhalb dieses idealen Pfades liegen.
Was passiert, wenn jemand Schritte in einer anderen Reihenfolge ausführt?
Was passiert, wenn eine Eingabe fehlt?
Was passiert, wenn jemand einen Vorgang doppelt startet?
Wie reagiert das System, wenn eine Verbindung genau im falschen Moment abbricht?
Solche Fragen entstehen technisch beim Testing, stammen aber gedanklich oft aus derselben Welt wie Helpdesk-Fälle.
Der entscheidende Unterschied besteht darin, dass ich diese Probleme möglichst finden möchte, bevor ein echter Benutzer deshalb Unterstützung benötigt.
Mit KI kann die Helpdesk-Perspektive noch wichtiger werden
Codex kann sehr schnell Funktionen erzeugen.
Das ist hilfreich, erhöht aber gleichzeitig die Gefahr, dass eine technisch vollständige Oberfläche entsteht, bevor ich ausreichend darüber nachgedacht habe, wie ein Mensch sie tatsächlich benutzen wird.
Eine Spezifikation kann sehr präzise beschreiben, welche Funktionen vorhanden sein müssen. Trotzdem kann das Ergebnis unverständlich wirken, wenn alle Begriffe und Abläufe ausschließlich aus Sicht des internen Systems formuliert wurden.
Deshalb möchte ich bei KI-generierten Funktionen nicht nur fragen, ob alle Anforderungen umgesetzt wurden.
Ich möchte genauso prüfen, ob jemand die Funktion versteht, der unsere komplette Konzeptdiskussion vorher nicht gelesen hat.
Die KI kennt schließlich dieselben Begriffe und Beschreibungen, die ich ihr gegeben habe. Ein echter Benutzer kennt sie nicht.
Dieser Unterschied darf bei der Abnahme nicht verloren gehen.
Supportfälle sind auch Produktfeedback
Ein Helpdesk wird manchmal nur als Stelle betrachtet, an der Probleme möglichst schnell gelöst und Tickets geschlossen werden sollen.
Für mich steckt darin noch etwas anderes.
Supportfälle sind Informationen darüber, wie ein Produkt in der Realität benutzt wird.
Wenn Menschen regelmäßig nach derselben Funktion fragen, könnte sie schlecht auffindbar sein. Wenn immer wieder dieselbe Fehlermeldung erklärt werden muss, könnte die Meldung verbessert werden. Wenn ein bestimmter Ablauf ständig Rückfragen erzeugt, lohnt sich möglicherweise eine grundlegende Überarbeitung.
Damit wird Helpdesk-Arbeit indirekt zu Produktentwicklung.
Nicht jeder Supportfall verlangt sofort eine Änderung der Software.
Aber eine gute Entwicklung sollte zumindest zuhören.
Als Einzelunternehmer treffen diese Perspektiven heute wieder bei mir zusammen
Heute habe ich keinen separaten Helpdesk und keine eigene Entwicklungsabteilung. Ich arbeite allein und muss deshalb alle diese Blickwinkel selbst miteinander verbinden.
Genau dabei helfen mir meine früheren Erfahrungen.
Wenn ich eine Funktion entwickle, versuche ich nicht nur aus der Sicht desjenigen darauf zu schauen, der sie technisch gebaut hat. Ich frage mich auch, welche Rückfrage dazu später entstehen würde, welche Fehlermeldung jemand missverstehen könnte und an welcher Stelle ein Mensch wahrscheinlich nicht das tut, was ich beim Entwurf vorgesehen habe.
Das funktioniert natürlich nicht perfekt.
Ich kenne meine eigene Software immer noch zu gut, um vollständig unvoreingenommen zu sein.
Aber ich weiß zumindest, dass diese blinden Flecken existieren.
Der Helpdesk hat mir vor allem eine einfache Sache beigebracht
Software wird nicht dadurch gut, dass der Entwickler erklären kann, wie sie gemeint ist.
Sie wird dann gut, wenn die Menschen, die sie benutzen sollen, möglichst selten jemanden brauchen, der ihnen genau diese Erklärung gibt.
Das bedeutet nicht, dass jede Anwendung selbsterklärend sein muss und niemals Unterstützung notwendig sein darf. Komplexe Aufgaben bleiben komplex.
Trotzdem ist jede unnötige Rückfrage ein Hinweis darauf, dass zwischen meiner Vorstellung und der Wahrnehmung des Benutzers irgendwo eine Lücke entstanden ist.
Genau deshalb gehört die Helpdesk-Perspektive für mich bis heute zur Softwareentwicklung.
Auch wenn ich gerade Code schreibe.
Und besonders dann, wenn Codex ihn für mich schreibt.