Ihre Gewalt ist nur ein stummer Schrei nach Liebe...

Warum die User deine Software hassen

Michael Thomas

© 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

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Warum die User deine Software hassen"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Sven
Gast

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. 🙂