Warum die User deine Software hassen

© Shutterstock.com/Bolkins
Es ist mit das schwärzeste Erlebnis, das einem im Laufe des Programmiererdaseins widerfahren kann: Mit viel Herzblut und noch mehr Überstunden hat man endlich ein Produkt fertig gestellt, auf das man stolz ist, von dem man sicher ist, dass es den ganz großen Wurf darstellt. Und dann will es keiner benutzen, geschweige denn dafür bezahlen. Was um Himmels Willen ist da schief gelaufen?
Rishi Mathur hat auf dem Unternehmensblog von Jixee einige typische Fallstricke des Entwicklungsprozesses vorgestellt, die eine Software zu einem wahren Hassobjekt der User machen können.
1. Es wurden Features und kein Produkt gebaut
Manchmal erstellen Entwickler ein neues Feature, das dem User zwar einen Mehrwert bringt, jedoch nicht für sich alleine stehen kann. Erfordert es eine nahtlose Integration in ein bereits existierendes Produkt, um wirklich gut zu funktionieren, sollte man deshalb besser mit dessen Entwicklern zusammenarbeiten, anstatt es als Stand-Alone-Software auf den Markt zu werfen. Als Beispiel für diese erfolgreiche Taktik nennt Mathur die Google Chrome-Erweiterungen: Diesen würde außerhalb des Chrome Web Store kaum Erfolg beschieden sein, aber als Erweiterung eines existierenden Produkts bringen sie dem User einen echten Mehrwert.
2. Es wurde nicht für den Kunden gebaut
Mathur zufolge der von Entwicklern wohl am häufigsten gemachte Fehler: Sie schreiben eine Software, die ihnen gefällt. Sie implementieren Features, die sie toll finden und gerne selber benutzen würden. Das Problem ist nur, dass 99,99 % der Menschheit über keinen Informatikabschluss verfügt – ein Programm, für dessen erfolgreichen Einsatz man über obskures Hintergrundwissen verfügen muss, kann deshalb nur scheitern. Mathurs Tipp: Entwickeln Sie Programme so, dass sie auch von Ihrer Großmutter bedient werden könnten!
3. Die User Experience wurde außer Acht gelassen
Machen wir uns nichts vor: Der Durchschnittsuser bringt eine Aufmerksamkeitsspanne von gerade einmal ein paar wenigen Minuten auf. Wenn er Ihr Programm bis dahin nicht begriffen hat, wird er es in die Tonne treten. Besonders wichtig für mobile Anwendungen ist deshalb, dass sie möglichst intuitiv zu bedienen sind und nur eine kurze Einarbeitungszeit erfordern. Mathur empfiehlt, nicht davor zurückzuscheuen, im Zweifelsfall Funktionalität zugunsten der UX zu opfern.
4. Das Produkt ist zu kompliziert
Analog zum vorangehenden Punkt: Weniger ist mehr! Zu viele Features können den User verwirren und die Lernkurve zu steil werden lassen. Die Folge ist – Sie haben es erraten –, dass er Ihr Produkt links liegen lässt und zur Konkurrenz greift. Überlegen Sie deshalb lieber zweimal, welche Features tatsächlich nötig sind. Versetzen Sie sich in die Lage des Kunden und versuchen Sie zu antizipieren, welche Wünsche und Bedürfnisse ihn antreiben und seine Kaufentscheidung beeinflussen. Konzentrieren Sie sich anschließend auf einige wenige Kernfeatures, die diese erfüllen, und streichen Sie den Rest. Denn man kann es gar nicht oft genug betonen: Weniger ist mehr!
Sind Ihnen in Ihrem Berufsleben diese und ähnliche Erlebnisse widerfahren? Haben Sie Ergänzungen? Teilen Sie es uns in den Kommentaren mit!
Aufmacherbild: angry user von Shutterstock.com / Urheberrecht: Bolkins
Besonders der letzte Punkt (Produkt zu kompliziert / weniger ist mehr) ist auch aus Entwickler-/Architekten-Sicht interessant. Ungenutzte oder extrem seltene Features kosten nicht nur in der Entwicklung, sondern auch im Nachhinein immer noch viel Zeit. Bei Änderungen, Fehlerkorrekturen und Refactorings müssen die Features trotzdem häufig berücksichtigt, angepasst und getestet werden, auch wenn es sich eigentlich nicht lohnt. Auch der Code ist dadurch unnötig kompliziert/komplex/umfangreich. Deshalb lohnt es sich auch als Entwickler/Architekt das ein oder andere Feature mal zu hinterfragen und ggf. wieder zu entfernen. 🙂