Coderechte, Lean Startup, Tests & Targeting
Nach der ersten Idee folgt häufig ein App-Konzept und schnell ein erster Prototyp – aber was kommt danach? Ohne einige grundsätzliche Überlegungen und einigem an Hintergrundwissen lässt sich kein vermarktungsfähiges Produkt erstellen. Lasse Clausen ist der Gründer, Produktdesigner und Geschäftsführer von Foundd (www.foundd.com), einer personalisierten Empfehlungsplattform für Filme, Apps, Videos und Bücher. Seit Dezember gibt es Foundd auch als iPhone-App – daher bat Gründerszene den Entrepreneur darum, die wichtigsten Erfahrungswerte beziehungsweise Abwägungen, die für App-Programmierer interessant oder wichtig sein können, zu teilen. Hier seine Top-Ten:
1. Nativ oder Framework?
Diese Frage sollten sich App-Entwickler gleich zu Beginn stellen, besonders, wenn die Verfügbarkeit auf mehreren Plattformen wichtig ist. Das Versprechen von Phonegap, Appcelerator et cetera, mit einem Schlag auf allen Plattformen eine App zu haben, ist einfach zu verlockend, um nicht ordentlich unter die Lupe genommen zu werden.
Prinzipiell können diese Frameworks gut für Apps sein, bei denen es hauptsächlich darum geht, Text und andere “leichte” Inhalte anzuzeigen.
Sobald es etwas Besonderes geben soll wie eigene Animation und datenreiche Inhalte, ist es aber empfehlenswert, nativ zu arbeiten und nicht mit einem Framework. Facebook zum Beispiel hatte auf HTML5 gesetzt und sich erst Ende 2012 von dem Fehler erholt.
2. Rechte am Code sichern
Eigene Entwickler im Team oder Freelancer beziehungsweise Agentur? Vorsicht, bei den beiden Letzteren bleiben die Rechte am Code standardmäßig – sofern nicht vertraglich anders vereinbart – beim Entwickler.
Sollte die App dann durchstarten und man in ein paar Monaten eigene Entwickler anstellen wollen, müsste man erst für viel Geld die Rechte am Code beim vormaligen Entwickler erwerben.
3. Keinen großen Launch planen
Von einem großen, koordinierten Launch mit Presse und Marketingkampagnen ist generell abzuraten. Kaum ein Startup, das sein erstes Launchdatum nicht verschieben musste und das deswegen viel vermeidbaren Ärger und Stress erlebt hat.
Bei einer iOS-App kommt dann noch der Prüfungsprozess von Apple erschwerend hinzu, der mindestens zwischen fünf und zehn Werktagen dauert. Generell sollte, sobald die App stabil läuft und man sich an die Apple HUI Guidelines hält, nichts schief gehen. Jedoch kann auch mal ein Reviewer einen schlechten Tag haben und die App wegen irgendeiner Lappalie verweigern. Und eine Verweigerung bedeutet, dass man wieder hinten in der Warteschlage steht und weiter warten muss.
Und zu guter Letzt kann es passieren, dass der Reviewer direkt nach dem Bemerken des ersten Verweigerungsgrundes die App ablehnt. Das heißt, er listet nicht andere mögliche Gründe der Verweigerung auf und man kann pro Mangel von vorn anfangen und jeweils mit fünf bis zehn Tagen Prüfungsprozess rechnen.
4. Sei Lean, aber weniger als im Web
Wir bei Foundd sind große Fans des Lean Startup Framework. Jedoch sind die Mindesterwartungen der Benutzer von Apple-Produkten höher als im Web, die schöne Apple-Welt verwöhnt eben.
Das heißt, man sollte immer noch als erstes eine App nur mit seiner wichtigsten Grundfunktion veröffentlichen, um herauszufinden, ob überhaupt jemand sie benutzen will. Aber sie muss absolut fehlerlos funktionieren, sonst hagelt es schlechte Bewertungen. Und ein bisschen entzückendes Design sollte auch dabei sein.
5. Benutzerschnittstelle nochmal komplett neu überdenken
Falls man eine Website hat und nun das Ganze nun auch als App verfügbar machen möchte, reicht es leider nicht, die Website einfach “klein” zu designen. Während des Besuches einer Website am Computer sitzt der Benutzer, hat meistens beide Hände zur Verfügung, ist Input-bereit und hat eine längere Aufmerksamkeitsspanne.
Beim Handy ist der Benutzer häufig unterwegs, navigiert mit einer Hand, möchte eher konsumieren als Informationen eingeben und hat eine kürzere Aufmerksamkeitsspanne. Dementsprechend lohnt es sich, die Features des Produkts, welche dem Konsum in kurzen Intervallen dienen, zu identifizieren, und diese in der App in den Vordergrund zu stellen.
6. Keine Links zu kaufbaren digitalen Inhalten
Apple sieht seine Geräte als ein Land, in dem es 30 Prozent Steuer von allen Verkäufen digitialer Medien einnehmen kann. Das heißt Apps mit Links zu Websiten, in denen Bücher, Filme, Musik et cetera zum Verkauf angeboten werden, fliegen beim Review-Prozess raus.
Verkäufe können nur über das In-App-Purchase-Programm getätigt werden, was zugegebenermaßen etwas angenehmer für den Benutzer ist und dadurch höhere Conversions haben kann. Denn er muss nur sein iTunes-Passwort eingeben, um den Verkauf abzuschließen, und nicht eine lange Kreditkartennummer eintippen. Das kostet den App-Entwickler dann aber auch 30 Prozent des Umsatzes.
7. Automatische Tests
Die Implementierung von automatischen Tests für die wichtigsten Bestandteile der App ist fundamental. Nichts ist ärgerlicher, als wenn die App nach zehn Tagen endlich im Store ist und dann nur eingeschränkt verwendet werden kann. Automatisierte Tests sind kein heiliger Gral, aber sie verringern die Wahrscheinlichkeit von Fehlern enorm, besonders die von Folgefehlern.
Außerdem fordern sie die Entwicklung einer guten Architektur und so kann man die Spreu vom Weizen der Entwickler trennen.
8. Manuelle Tests mit einem alten Gerät
Für die manuellen Tests kann ich nur zur Verwendung eines Uralt-Geräts raten. Nichts scheint mehr Ein-Sterne-Bewertungen zu erregen als ein Crash der App. Wenn die App einwandfrei auf einem alten Gerät funktioniert, ist man in der sicheren Zone.
9. Keyword-Optimierung kann funktionieren
Appstore Search Optimization (ASO) ist noch sehr neu und schwierig, besonders, da man keine Referrer für einzelne Downloads erhält. Das heißt, man kann nur intelligent raten, woher sie eigentlich kommen.
Trotzdem lohnt es sich, besonders für Apps von unbekannten Marken, in Suchwortoptimierung etwas Zeit zu investieren. Das beste Tool dafür ist Appcodes.
10. Tracking
So wie die Nutzung einer App auf einem Smartphone anders als die Nutzung einer Website auf einem Computer ist (siehe Nummer fünf), haben die Analytics-Tools einer App eigene Anforderungen. Außerdem kann es passieren, dass die selben Conversion Funnels in einer App ganz anders aussehen als im Web. Das heißt, man muss bei einer App das gesamte Nutzerverhalten nochmal separat messen.
Daher ist ein Mobile- und Tablet-spezifisches Trackingtool wie Flurry empfehlenswert, welches man am besten durch ein Analytics-Tool komplementiert, das die wichtigsten Metriken plattformübergreifend messen kann.