Die 10 größten Herausforderungen für Produktmanager bei nativen Apps

Dass man den Trend nicht verpassen sollte, ist den meisten bewusst. Aber wie sich native Apps von Websites unterscheiden, ist selbst unter Produktmanagern nicht immer bekannt. In wie fern sich das Produktmanagement von nativen Apps und Websites unterscheidet, zeigen folgende 10 Punkte.

1. Apps erfordern Releases

App-Abteilungen entwickeln Apps und neue Features in der Regel nach agilen Methoden. Dennoch trifft sie ein gravierender Unterschied in der Entwicklung: Releases werden wasserfallartig angegangen. Der Grund hierfür ist simpel: Man möchte den User nicht mit zu häufigen Updates, die immer wieder aufs Neue Datenvolumen erfordern, belasten und, noch schlimmer, verschrecken. Längst noch nicht alle Smartphone-Besitzer nutzen die automatischen App-Downloads. Daher werden Apps nicht on-the-fly releast und Continuous Deployment ist eher ein Fremdwort. Hinzu kommt, dass jedes iOS Release durch den Review Prozess von Apple muss, der einige Wochen beanspruchen kann.

2. Auch kleinste Änderungen sind an Releases gekoppelt

Da man für alle Änderungen, seien sie noch so klein, die nicht über eine API geändert werden können ein Release braucht, und für ein Release das oben beschriebe Problem auftaucht, müssen auch kleine Änderungen (wie z.B. einen Button austauschen) im Voraus geplant werden. Dies trifft auch auf A/B Tests zu, bei denen im Sprint zum anstehenden Release schon die A/B Tests für die Zeit nach dem Release geplant und vollständig eingebaut sein müssen. Das Resultat ist, dass man Releases schon weit im Voraus plant und in der Flexibilität im Vergleich zum Web begrenzt ist. Dennoch ergibt sich auch ein großer Vorteil: Da die Apps lokal auf dem Smartphone des Nutzers laufen, kann auf bestimmte Inhalte auch offline zugegriffen werden.

3. Alte App Versionen

Da es dem Nutzer überlassen ist, ob er ein App Update runterlädt oder nicht, kommt es natürlich vor, dass veraltete App Versionen im Umlauf sind. Manchen Firmen „zwingen” den Nutzer die neue App Version runterzuladen indem sie die alten App Versionen unbrauchbar machen. Andere Firmen haben so ein Vorgehen nicht implementiert und müssen bei jeder Neuerung bedenken, dass es weiterhin User mit alten Versionen gibt und releaste Versionen ggf. nie ganz verschwinden. Das hat auch Auswirkungen auf Features und Funktionen: Ein gutes Beispiel ist hier das Austauschen von Texten zu Einwilligungen von Nutzern (z.B. Datenschutz): Bei Apps reicht es nicht aus nur das Datum mitzuspeichern, wann ein User die Erklärung akzeptiert hat. Alleine aus dem Datum kann man nämlich noch nicht auf die betreffende Version zurückschließen. Das ergibts sich daraus, dass Nutzer auch nicht-aktuellen Einwilligungen in alten App-Versionen zustimmen können.

4. App Testing und Bug Handling

Mit dem Wissen, dass releaste App Versionen ggf. nie ganz von den Smartphones und Tablets der User verschwinden werden, fällt eine besonders große Bedeutung auf das App Testing und die Qualitätssicherung. Zudem sind auch Bug-Fixes an Releases gekoppelt und müssen durch den iOS Review Prozess. Auch wenn es bei kritischen Bugs die Möglichkeit zum Expedited Review gibt, bedeutet dennoch jedes Release erneuten Aufwand für den User. Nicht selten werden deshalb fertige App Versionen tagelang auf Herz und Nieren getestet bevor sie in den Store gehen, denn genauso wie App Versionen, können auch Bugs ggf. nie ganz aus dem Verkehr verschwinden. Dies ist besonders kritisch bei Bugs, die es dem Nutzer ermöglichen einen bezahlten Service (z.B. In App Käufe) kostenlos zu nutzen.

5. Developer Guidelines

Bei der nativen App-Entwicklung haben beide großen Plattforms eigene Guidelines. Was für Android ein Kinderspiel ist, wird bei Apple unterbunden. Und andersrum. Das betrifft sowohl die technische Umsetzung bei Features als auch die Design Richtlinien. Will man seine App auch auf der Watch laufen lassen, gibt es erneut unterschiedliche Guidelines. Ein tolles UX Konzept bedeutet also noch lange nicht die problemlose Umsetzung auf unterschiedlichen Plattformen. Gleiches gilt auch für die Ergebnisse aus A/B Tests: Erkenntnisse von Android können oft nicht auf iOS übertragen werden. Und andersrum. Genauso wenig können Insights aus A/B Tests im Web auf Apps übertragen werden. Dafür unterscheidet sich das Nutzerverhalten zu sehr zwischen den Plattformen. Dies gilt vor allem für Tests, die mit der Nutzerführung und/oder dem Design in Verbindung stehen.

6. Zwei Plattformen = zwei unabhängige Apps?

Wenn es für beide Plattformen unterschiedlich Guidelines und dementsprechend unterschiedliche Entwicklungsmöglichkeiten gibt, macht es dann Sinn beide Teams als separate Teams zu behandeln, mit jeweils eigenem UX-ler und PM? Jein. Dieser Aufbau birgt die Gefahr, dass sich beide Apps in verschiedene Richtungen bewegen und Features und Benutzerführung unabhängig voneinander umgesetzt werden. An sich kein Problem für die Entwicklung. Allerdings kommen hier die User ins Spiel. Diese tauschen sich über das unterschiedliche Verhalten von Apps auf den Plattformen aus und so kommen nicht umgesetzte Features der einzelnen Plattformen letztendlich doch ans Licht (bzw. in die App-Bewertungen).

7. Unterschiedlich kleine Screensizes

App-Entwicklung bedeutet für einen kleinen Bildschirm zu entwickeln, der zum einen wenig Platz für Ablenkung bedeutet, und zum anderen keinen Platz für Unklarheiten und Fehler bietet. Im Zentrum steht der Weg, den der Nutzer bewältigen muss um seinen Job zu erfüllen. Dabei bieten native Apps einen großen Vorteil: Man kann sich aus einem Pool an System Elementen bedienen, mit denen der Nutzer schon vertraut ist und mit denen er sich wohl fühlt. Oft kann man auch auf bestehende Animationen zurückgreifen, man braucht sie also nicht von Grund auf individuell zu bauen.

8. Wahl der Nutzerinteraktionen

Der kleine Bildschirm bietet zwar wenig Platz für graphische Verspieltheit, durch seine sensible Oberfläche bietet er aber Platz für viele User-Interaktionen. User können swipen, tappen, scrollen,… Jede Geste bietet Platz für neue Funktionen, so können Inhalte in Listen durch horizontales Swipen gelöscht werden, anderswo werden Inhalte durch vertikales Swipen ausgefahren. Für seine kleine Größe bietet der kleine Smartphone-Screen also vergleichsweise eine große Menge Interaktionspotential. Und es kommen immer neue Möglichkeiten hinzu, so wurde mit dem iPhone 6s der gelauncht, der durch peek und pop dem User erneut neue Möglichkeiten bietet. Es gibt viele Interaktionsvarianten und viele Best Practices, aber das Verhalten ist leider (noch) wenig einheitlich. So bleiben Funktionen oft im Verborgenen.

9. Keine Cookies, dafür aber Sprachen und Locations

Cookies ermöglichen es Nutzer wiederzuerkennen. Sie können aber nur begrenzt zwischen Browsern und Apps geteilt werden, daher haben Cookies für die Mobile Entwicklung nur eine untergeordnete Bedeutung. Stattdessen lassen sich Nutzer anhand ihrer Device ID zuordnen und dadurch, dass Apps lokal auf dem Device des Users laufen, lassen sich Nutzereinstellungen und z.B. der Fortschritt in Spielen lokal speichern, ohne einen Login zu benötigen. Außerdem lassen sich Nutzer anhand von Sprachen und Regionen erkennen. Viele Apps haben sich diese Eigenschaft zunutze gemacht und steuern je nach Spracheinstellung auf dem Gerät die passende Sprache in der App aus. Daher gibt es meist nur eine App mit verschiedenen Sprachversionen und nur selten Apps für verschiedene Länder, wie man es von Websites kennt (.de, .fr, .pl etc.). Dadurch, dass der Code für alle Sprachversionen gleich ist, lassen sich Features für viele Länder gleichzeitig ausrollen. Aber Locations bieten noch einen Mehrwert für die Produktentwicklung: Man kann den Standort des User identifizieren und ihn so auf Angebote in seiner Nähe aufmerksam machen.

10. Der Nutzer

Und zu guter Letzt unterscheiden sich auch die Nutzer von App und Web. Nutzer, die eine Website öffnen, gelangen auch dorthin, weil sie durch eine Anzeige „eingekauft” wurden, vielleicht aber auch einfach zufällig. Nutzer, die eine App öffnen, machen dieses nicht zufällig. Sie sind vorab (meist anderswo) auf die App aufmerksam geworden, sie haben sich die Zeit genommen, die App herunterzuladen und zu installieren. Sie haben schon so einige Hürden unternommen um die App zu nutzen – sie sind also in der Regel schon mit dem Produkt und der Marke vertraut und generieren i.d.R. mehr Sessions als User im Web. Dementsprechend schwierig gestaltet sich das Marketing für Apps, das zudem auch noch verhältnismäßig teuer ist. Seit kurzem werden Interstitials auf Websiten, die den Nutzer zum Download der App auffordern, von Google abgestraft. Für diese wertvolle Kundengruppe ist also viel Kreativität gefragt.

Das Produktmanagement für Apps hat also mit einigen Herausforderungen zu kämpfen, die im Web eher unbekannt sind und andere Wege erfordern. Gleichzeitig bieten Apps aber auch viele neue Möglichkeiten dem User im Alltag zu helfen und ihn zu begeistern. Somit bieten Apps Unternehmen auch viel Potential loyale Kunden besser zu bedienen und sie in unterschiedlichen Situation und immer und überall zu erreichen.