Mobile toepassingen: Wanneer kies je voor m-web, native of hybride?
De discussie rond de keuze voor m-web versus native voor de ontwikkeling van mobile toepassingen heeft zich voornamelijk gericht op zaken als het kunnen gebruiken van functionaliteit van het mobiele toestel (zoals GPS, Adresboek etc), noodzaak tot uitgebreide en complexere user experience, portabiliteit tussen platformen etc etc.
Meer recent is daar de hybride app als valide optie bij gekomen (apps op basis van webtechnologie gewrapt voor een specifiek platform).
Echter er wordt vaak gesproken van of het een of het ander. Mijns inziens is het niet zo zeer of-of maar veeleer en-en.
Laat me dat proberen uit te leggen.
Doel van de mobile app
Er zijn verschillende dimensies waar je naar kunt kijken bij het bepalen van de mobile strategie voor je bedrijf. Eén ervan kan zijn welke functies je aan wilt bieden aan je klanten. Er zijn globaal een 4-tal typen apps te onderscheiden:
1. Branding apps –> belangrijkste functionaliteiten liggen op sociale interactie vlak, met als doel brand value te creëren
2. Simple services apps –> eenvoudige services voor je eindklanten waarbij minimale koppelingen met interne systemen nodig zijn (vinden van info als prijzen, winkellocaties, contactgegevens)
3. Complex services apps –> complexere klantprocesondersteuning (procesondersteuning bij advies processen, aankoopprocessen etc)
4. Omnichannel enabled apps –> ondersteunen van klantreizen over verschillende kanalen heen waarbij een verregaande kanaalintegratie vereist is.
Veel bedrijven in Nederland experimenteren met apps uit categorie 1 of 2. voor categorie 1 zijn veelal marketing afdelingen opdrachtgever die er voor kiezen een deel van hun advertentiebudget te alloceren aan een app in plaats van een advertentie. Focus ligt daar veelal op exposure en brand value.
Voor bedrijven die type 2 apps uitbrengen ligt de focus veelal op kostenreductie: een poging om met name eenvoudige diensten naar een selfservice kanaal te pushen (en niet langer in de dure bemenste kanalen af te handelen). Dit is vaak niet succesvol om verschillende redenen. Daar kom ik graag een ander moment op terug.
Voor veel bedrijven zijn type 3. apps veelal nog een brug te ver, laat staan type 4 waar met name ook de voorwaarde dat de andere klantcontactkanalen op orde zijn onvoldoende is ingevuld.
Dichotomie: complexiteit versus totale economische impact
Afhankelijk van het doel en de functie van de app is het belangrijk om te kijken naar zowel de verwachte economische impact als ook de complexiteit van de app (en landschap waarin deze moet landen) alvorens tot een keuze te komen voor een mobiele ontwikkelmethode.
Hoe definieer je totale economische impact?
- zaken als: bijdrage aan brand value, klanttevredenheid, cross- & upsell
- keuze voor welke platformen en apparaten ondersteund worden
- bijbehorende kosten van de mobiele oplossing
Hoe definieer je complexiteit?
- benodigde koppelingen met IT landschap
- aantal apps dat gelijktijdig beheerd dient te worden
- aantal platformen en devices dat ondersteund dient te worden
Deze opsommingen zijn nog verre van uitputtend maar geven wel een goed idee welke aspecten relevant kunnen zijn.
Als je op deze tweedeling een eerste plot maakt van de verschillende ontwikkelmogelijkheden krijg je een dergelijke opzet:
De verwachting is dat er zeker nog verschuivingen gaan plaatsvinden als gevolg van verregaande ontwikkeling van de verschillende methoden. Mogelijkerwijs zullen er ook nieuwe methoden aan toegevoegd worden.
Keuze voor m-web, hybride of native
Het is een valide optie om te starten met een native app of m-web wanneer de complexiteit laag is. Hiermee bouwt het bedrijf ervaring op met het vertalen van de mobiele strategie naar toepassingen.
Wanneer over de loop van tijd de complexiteit toeneemt wordt het meer en meer relevant om te kijken naar een vorm van platform ontwikkeling.
Een keuze voor een ontwikkelmethode hoeft dus niet eenmalig te zijn. Een goede mobiele strategie wordt regelmatig herijkt waarbij de gekozen ontwikkelmethode heroverwogen kan worden.