Warum gute Software oft weniger können sollte

Es gibt einen erstaunlich zuverlässigen Weg, eine Software langsam schlechter zu machen: Man fügt immer weiter Funktionen hinzu.

Das klingt zunächst widersprüchlich. Schließlich ist eine neue Funktion doch etwas Gutes. Sie löst ein Problem, deckt einen Sonderfall ab oder erfüllt einen Wunsch, den jemand irgendwann einmal geäußert hat. Und genau deshalb ist es so schwer, Nein zu sagen.

Das Problem beginnt dort, wo aus vielen guten Einzelentscheidungen ein schlechtes Gesamtprodukt wird.

Eine Anwendung kann hundert nützliche Funktionen besitzen und sich trotzdem unangenehm anfühlen. Sie kann technisch beeindruckend sein und ihren Benutzer gleichzeitig mit Dialogen, Optionen, Schaltern und Untermenüs erschlagen. Sie kann fast alles können und gerade deshalb im Alltag nerven.

Gute Software zeichnet sich für mich deshalb nicht dadurch aus, dass sie möglichst viel kann. Sie zeichnet sich dadurch aus, dass sie das Richtige kann und diese Dinge möglichst selbstverständlich macht.

Jede Funktion hat Folgekosten

Wenn Entwickler über neue Features sprechen, betrachten sie häufig zuerst den Aufwand für die Umsetzung.

Wie lange dauert die Entwicklung? Welche Klassen brauchen wir? Muss das Datenmodell erweitert werden? Welche Tests kommen dazu?

Das sind wichtige Fragen. Sie greifen aber zu kurz.

Eine Funktion kostet nicht nur während ihrer Entwicklung. Sie bleibt im Produkt.

Sie braucht einen Platz in der Oberfläche. Sie muss dokumentiert werden. Sie muss getestet werden. Sie interagiert möglicherweise mit anderen Funktionen. Sie erzeugt neue Zustände, neue Fehlerfälle und irgendwann neue Rückfragen.

Vor allem aber kostet sie Aufmerksamkeit.

Ein zusätzlicher Button nimmt nicht nur zwanzig oder dreißig Pixel Platz ein. Er ist eine weitere Entscheidung, die der Benutzer treffen muss.

Brauche ich das? Was passiert, wenn ich darauf klicke? Ist das der richtige Weg oder gibt es irgendwo noch eine bessere Funktion?

Bei zehn Funktionen fällt das kaum auf. Bei hundert schon.

Flexibilität ist nicht automatisch Benutzerfreundlichkeit

Als Entwickler ist man leicht versucht, Software möglichst flexibel zu machen.

Warum nur drei Optionen anbieten, wenn man auch zwölf anbieten könnte?

Warum eine sinnvolle Voreinstellung treffen, wenn man dem Benutzer die Entscheidung überlassen kann?

Warum einen festen Ablauf vorgeben, wenn sich alles konfigurieren lässt?

Technisch wirkt das häufig elegant. Aus Benutzersicht kann es anstrengend sein.

Ein Beispiel ist ein Umbenennungswerkzeug für Dateien. Natürlich könnte man jede erdenkliche Transformation als eigene Option anbieten. Präfixe, Suffixe, Zähler, reguläre Ausdrücke, Datumswerte, Zeichenersetzungen, Skripte und vieles mehr.

Die Herausforderung besteht nicht darin, diese Möglichkeiten zu programmieren. Die eigentliche Herausforderung ist, sie so anzuordnen, dass jemand, der lediglich zwanzig Fotos umbenennen möchte, nicht das Gefühl bekommt, gerade eine kleine Programmiersprache lernen zu müssen.

Genau hier trennt sich Funktionsumfang von Produktqualität.

Gute Software trifft Entscheidungen

Ich glaube, dass ein großer Teil guter Produktentwicklung darin besteht, dem Benutzer Entscheidungen abzunehmen.

Nicht bevormundend. Sondern sinnvoll.

Wenn in neunzig Prozent der Fälle eine Einstellung richtig ist, sollte sie wahrscheinlich voreingestellt sein.

Wenn eine Funktion nur von sehr wenigen Menschen gebraucht wird, muss sie vielleicht nicht prominent im Hauptfenster stehen.

Wenn zwei Optionen fast dasselbe bewirken, sollte man überlegen, ob wirklich beide notwendig sind.

Das klingt banal, ist aber erstaunlich schwer.

Denn Weglassen fühlt sich während der Entwicklung schnell so an, als würde man Möglichkeiten verschenken. Tatsächlich gewinnt man häufig etwas viel Wertvolleres: Klarheit.

Der Hauptbildschirm ist kein Lagerraum

Bei Oberflächen gibt es einen Effekt, den vermutlich jeder kennt, der länger an einem Produkt arbeitet.

Am Anfang ist viel Platz.

Dann kommt eine Funktion hinzu. Und noch eine. Irgendwo passt noch ein Button hin. Rechts könnte man eine kleine Gruppe ergänzen. Unten ist auch noch Platz.

Ein paar Monate später sieht der Hauptbildschirm aus wie der Werkzeugwagen eines sehr motivierten Heimwerkers.

Alles hat seinen Grund. Nichts darf weg. Und niemand findet mehr auf Anhieb den Schraubendreher.

Deshalb versuche ich bei Oberflächen inzwischen stärker in Ebenen zu denken.

Was braucht man ständig? Das gehört sichtbar nach vorne.

Was braucht man gelegentlich? Das darf einen Schritt entfernt sein.

Was ist eine Expertenfunktion? Die darf existieren, ohne jedem Benutzer beim ersten Start zuzuwinken.

Eine gute Oberfläche zeigt nicht alles, was eine Anwendung kann. Sie zeigt zuerst das, was in diesem Moment wahrscheinlich gebraucht wird.

Weniger bedeutet nicht simpel

Dabei ist mir eine Unterscheidung wichtig.

Software mit einer klaren Oberfläche muss intern keineswegs simpel sein.

Im Gegenteil.

Oft steckt gerade hinter einer einfachen Bedienung besonders viel Arbeit. Die Anwendung muss sinnvolle Standardwerte wählen, Fehler erkennen, Abhängigkeiten berücksichtigen und Sonderfälle abfangen.

Der Benutzer sieht davon idealerweise wenig.

Das ist ein bisschen wie bei einem guten Aufzug. Niemand möchte vor der Fahrt eine Konfigurationsseite für Beschleunigung, Türzeiten und Motorsteuerung sehen. Man möchte auf einen Knopf drücken und in einem anderen Stockwerk ankommen.

Bei Software vergessen wir dieses Prinzip erstaunlich oft.

Funktionen zu löschen ist schwieriger als Funktionen zu bauen

Eine neue Funktion lässt sich relativ leicht rechtfertigen.

Jemand möchte sie. Ein Wettbewerber hat sie. Sie klingt interessant.

Eine bestehende Funktion zu entfernen ist unangenehmer.

Vielleicht nutzt sie jemand. Vielleicht beschwert sich genau dieser jemand. Vielleicht braucht man sie später doch wieder.

Deshalb wächst Software häufig fast automatisch.

Ich halte es mittlerweile für mindestens genauso wichtig, regelmäßig über das Gegenteil nachzudenken:

Welche Funktion ist kaum noch relevant?

Welche Einstellung existiert nur noch aus historischen Gründen?

Welche zwei Wege könnten zu einem zusammengeführt werden?

Welcher Dialog könnte verschwinden, weil die Anwendung selbst eine vernünftige Entscheidung treffen kann?

Diese Fragen sind weniger spektakulär als ein neues Feature. Für die Qualität eines Produkts sind sie häufig wichtiger.

Auch ich muss mich daran erinnern

Das Interessante daran ist: Selbst wenn man diese Prinzipien kennt, ist man nicht davor geschützt.

Wenn ich an eigener Software arbeite, ertappe ich mich regelmäßig bei dem Gedanken: Das könnte man doch auch noch einbauen.

Technisch ist die Idee vielleicht sogar reizvoll.

Dann hilft eine andere Frage:

Macht diese Funktion das Programm für den Benutzer wirklich besser oder macht sie hauptsächlich die Featureliste länger?

Das ist nicht immer leicht zu beantworten.

Manchmal lautet die Antwort natürlich Ja. Software soll Probleme lösen und dafür braucht sie Funktionen.

Aber eine gute Produktentscheidung endet nicht mit der Frage, ob etwas möglich ist.

Sie beginnt dort.

Die beste Funktion kann eine sein, die niemand bemerkt

Einige der angenehmsten Eigenschaften guter Software tauchen in keiner großen Featureliste auf.

Eine Anwendung merkt sich den letzten sinnvollen Zustand.

Sie verhindert eine ungültige Aktion, bevor eine Fehlermeldung nötig wird.

Sie schlägt einen brauchbaren Standard vor.

Sie zeigt im richtigen Moment die richtige Information.

Sie zwingt mich nicht, etwas zu konfigurieren, das sie selbst wissen könnte.

Solche Dinge sind schwer zu verkaufen, weil sie unspektakulär klingen.

Beim täglichen Arbeiten machen sie aber einen gewaltigen Unterschied.

Vielleicht ist das sogar ein brauchbarer Maßstab für gute Software:

Nicht wie viele Dinge sie mir ermöglicht, sondern wie wenig ich über ihre Bedienung nachdenken muss.

Weniger ist keine Religion

Natürlich wäre es Unsinn, daraus ein Dogma zu machen.

Ein professionelles Werkzeug darf komplex sein. Ein Dateimanager, eine Entwicklungsumgebung oder eine Bildbearbeitung benötigt mehr Möglichkeiten als ein Taschenrechner.

Die Frage lautet deshalb nicht: Wie bekommen wir möglichst wenige Funktionen?

Die bessere Frage lautet:

Wie viel Komplexität ist für die Aufgabe tatsächlich notwendig und wie viel davon müssen wir dem Benutzer zumuten?

Das ist ein großer Unterschied.

Komplexität lässt sich nicht immer vermeiden. Aber man kann entscheiden, wo sie sichtbar wird.

Gute Software respektiert Aufmerksamkeit

Am Ende geht es für mich um etwas, das in technischen Diskussionen erstaunlich selten erwähnt wird: Aufmerksamkeit.

Menschen benutzen Software meistens nicht, weil sie Software benutzen möchten.

Sie wollen eine Rechnung schreiben, Dateien sortieren, ein Bild bearbeiten, einen QR-Code erstellen oder irgendeine andere Aufgabe erledigen.

Die Anwendung ist Mittel zum Zweck.

Gute Software respektiert das.

Sie versucht nicht ständig zu beweisen, wie leistungsfähig sie ist. Sie drängt sich nicht unnötig in den Vordergrund. Sie hilft und verschwindet danach wieder ein Stück aus dem Kopf.

Vielleicht ist genau das der Grund, warum gute Software manchmal weniger können sollte.

Nicht weil weniger grundsätzlich besser ist.

Sondern weil jede Funktion ihren Platz verdienen muss.