Warum App-Projekte scheitern

Jeden Monat kommen unzählige neue Apps auf den Markt. Doch häufig führt die Begeisterung der Entwickler dazu, dass die zweite Version einer App an der Fülle neuer Funktionen förmlich erstickt. Man verliert die Kernfunktionen aus den Augen und auch der Projektmanager, der den Überblick behalten sollte, lässt sich mitreißen.

Nehmen wir einmal ein fiktives Start-up als Beispiel: Ein paar junge Berliner wollen eine Foto-App ähnlich wie Instagram realisieren. Inspiriert von der Fotografenweisheit, dass die beste Kamera die ist, die man dabei hat, entsteht die Idee: Mit der iPhone-App können Fotografen ihre Smartphone-Fotos nach der Aufnahme mit einem von sieben verfügbaren Filtern einzigartig machen und diese per E-Mail oder über Facebook mit ihren Freunden teilen. Ursprünglich hatte das Start-up sehr viel mehr vor, doch das kleine Budget und der enge Zeitrahmen ließen nur einen geringen Funktionsumfang zu. Viele Funktionalitäten wurden daher für die Version 1.0 gestrichen und zurück ins „Backlog” gelegt. Bereits kurz nach der Veröffentlichung der iOS-App plante das Team das Release 2.0. Endlich hatte man mehr Zeit und entschied sich dafür, die App komplett neu zu programmieren. Am besten als Hybrid-App auf HTML5-Basis, damit sowohl iOS- als auch Android-Nutzer die App verwenden können. Zudem sollte die zweite Version natürlich mehr Funktionen bieten als die erste. Da die „Facebook-Sharing-Funktion” besonders beliebt war, beschloss man, die App in ein eigenständiges Foto-Social-Network zu verwandeln. Nach langen Besprechungen war man sich einig, welche Features realisiert werden sollten. Die große Vision war der „Fotostream”: Wie bei Twitter und Facebook sollten die User eigene Fotos und Fotos von Personen, denen sie folgten, in einer Zeitleiste zeigen, kommentieren und „liken“ können. Zusätzlich konnten die Nutzer zwischen „Events“ und „privaten Nutzergruppen“ wechseln. Es gab also eine Menge zu tun!

Die Idee verselbstständigt sich

Getreu nach Lehrbuch teilte das Start-up die Programmierung der „Features“ in einzelne Sprints auf, die verschiedene Teams abarbeiteten. Als schließlich alle wesentlichen Funktionalitäten in der Alphaversion implementiert waren, bemerkte man Unstimmigkeiten im Interface-Design und in der User Experience. Die App war schwer zu bedienen und die Kernfunktionen, nämlich „Fotos machen und diese durch Filter verändern“, war kaum noch erkennbar.

Was war passiert? Die einzelnen Teams hatten ihre Aufgaben früher als geplant erledigt und eifrig weitere Features hinzugefügt. So konnten die Benutzer nun beispielsweise ein fremdes Foto nicht nur kommentieren und „liken“, sondern auch in ihren Fotostream aufnehmen. Außerdem konnten sie im Fotostream weitere Aufnahmen eines Freundes sofort durch „horizontales Wischen“ auf dem Screen ansehen. Leider wurde dadurch die Hauptfunktion – das schnelle „vertikale Wischen“ im chronologischen Fotostream – beinahe unmöglich, da das System schwer zwischen den Gesten differenzieren konnte.
Die Unterschiede im Design und in der User Experience wurden behoben, man hielt aber daran fest, möglichst viele Funktionen zu bieten. Nun taten sich jedoch weitere Probleme auf: Das User-Experience-Team stellte fest, dass die App dem Interface Design beider Plattformen, also iOS und Android, nicht gerecht wurde. So waren beispielsweise „Action Sheets”, „Tab Bar” und „Navigation Bar” jeweils unterschiedlich positioniert oder verhielten sich komplett anders. Human Interface Guidelines (HIG) für hybride iPhone- und Android-Apps gibt es nicht. Letztlich wurde die App dann an die plattformspezifischen Unterschiede angepasst.

Die Monate zogen ins Land und der Funktionsumfang der App wuchs weiter, bis sie schließlich auf den Markt kam. Die Bewertungen in beiden App-Stores waren vernichtend: Durch die vielen Funktionen war es nicht mehr möglich, schnelle Aufnahmen mit den Filtern zu machen. Viele „Features“ des Fotostreams nutzten die Smartphone-Besitzer nicht und empfanden sie als lästig. Außerdem stürzte die App häufig ab.

All dies sollte dazu führen, dass man bei der Konzeption eines Release 2.0 zunächst einmal darüber nachdenken sollte, welche Funktionen die User tatsächlich verwenden. „Wenn man sich bei einem Feature unsicher ist, sollte man es weglassen“, erklärt Jens Krahe, Creative Director und Head of User Experience bei Triplesense. „Die User werden fehlende Funktionen ohnehin nach der Veröffentlichung anfordern. Denn für sie ist es wichtiger, die eine richtige zusätzliche Funktion zu bekommen als mehrere nicht relevante.“ Auch für die Entwicklung hat das Vorteile: Das Unternehmen kann sich auf bestimmte Features konzentrieren und diese in hoher Qualität realisieren. Man sollte zudem niemals eine App für iOS- und Android-Smartphones gleichzeitig entwickeln. Hier gilt der Grundsatz „Lieber den Spatz in der Hand als die Taube auf dem Dach”.

Bildquell: iStockphoto.com/bevangoldswain