#1.
De basisprincipes van een mobiele applicatie
Een mobiele applicatie is een stukje software die op uw telefoon of tablet wordt geïnstalleerd en die via deze apparaten verschillende acties mogelijk maakt, afhankelijk van de gebruikte toepassing.
In 2021 zijn mobiele apps alomtegenwoordig geworden in alle bedrijfstakken.
Er zijn allerlei soorten mobiele apps:
Verbindingsapps zoals Uber of Airbnb;
Sociale netwerken:
- Er zijn steeds meer netwerken die 'Mobile First' zijn, zoals Instagram of Tik Tok: ze hebben eerst een mobiele app gelanceerd voordat ze een webversie uitbrachten
- Andere netwerken hebben ervoor gekozen om pas heel laat een webversie aan te bieden of alleen mobiel te blijven, zoals Snapchat;
Productiviteitsapps: kalender, taakherinneringen, e-mails, projectbeheer, enz.;
Spelletjes: Candy Crush, Fruit Ninja of Doodle Jump;
E-commerce-apps zoals Zalando, Sarenza, Amazon of AliExpress;
Thuisbezorgingsapps voor maaltijden: Deliveroo, Takeaway of Uber Eats;
En nog veel meer soorten apps, zoals bankieren, communicatie, kaartnavigatie, weer, muziek luisteren, boeken lezen, ... Het gaat, kortom, om een oneindig aantal toepassingen.
Er zijn meer mobiele gebruikers dan pc-gebruikers, vooral bij de jongere generaties.
Aan de mobiele kant wordt ook veel gebruik gemaakt van tablets. Natuurlijk minder dan smartphones, maar ze hebben toch hun succes.
⇒ Mobiel is een van de beste media om uw doelgroep te bereiken!
De belangrijkste voordelen van een mobiele app:
Verhoogt de bekendheid;
Verbetert het merkimago;
Overal toegankelijk (en gemakkelijk toegankelijk);
Geoptimaliseerde klantervaring: de interface van een app is vaak gebruiksvriendelijker dan die van het web en is eenvoudig in gebruik;
Mogelijkheid om de specifieke kenmerken van een smartphone te gebruiken: geolocatie voor transport- of kaarttoepassingen zoals Waze, de versnellingsmeter of gyroscoop (de rotatie van een mobiel, de snelheid waarmee een mobiele telefoon zal bewegen), ...
⇒ Mobiele applicaties bieden een breed scala aan toepassingsmogelijkheden.
#2.
De persona van de typische gebruiker bepalen
De eerste stap van uw project, nadat u uw concept hebt gedefinieerd, bestaat erin uzelf een essentiële vraag te stellen: wie zal uw mobiele applicatie gebruiken? Wie zullen uw klanten zijn?
Een persona is een fictief personage dat een doelgroep van uw klanten vertegenwoordigt. Er worden bepaalde kenmerken toegewezen aan deze fictieve personages (beroepssituatie, interesses, enz.).
Verschillende elementen om in gedachten te houden bij het definiëren van uw personas:
- U kunt meerdere personas hebben, afhankelijk van uw concept.
Bijvoorbeeld, met een thuisbezorgingsapplicatie voor maaltijden hebt u de persona van de bezorger, de restauranthouder en die van de gebruiker.
Als dit het geval is voor uw applicatie, nodigen we u uit om hoofdstuk 2 van ons artikel over de ontwikkeling van een connectieplatform (marktplaats) te lezen: de complete gids. Daar leggen we dit principe meer in detail uit.
- U kunt ook slechts één persona hebben als u bijvoorbeeld een spel ontwikkelt: de persona van de speler.
- Denk aan uw personas gedurende uw hele project, omdat ze het volgende zullen bepalen:
De functies
De interfaces
Het technische aspect van uw applicatie
Uw marketingbenadering: u zult uw personas niet op dezelfde manier benaderen
...
⇒ De applicatie is voor hen ontworpen!
Deze stap is essentieel, maar kost niet noodzakelijkerwijs veel tijd.
U kunt marktonderzoek doen, maar dat is zeker niet verplicht. Vergeet ook niet dat mensen niet altijd weten wat ze willen.
Steve Jobs deed bijvoorbeeld geen marktonderzoek: voor hem was dat tijdverspilling.
Hij zei zelfs: "Het is niet de taak van consumenten om te weten wat ze willen."
Het voorbeeld van Hom'Gry:
Gedurende dit artikel zullen we onze uitspraken illustreren met een concreet voorbeeld: Hom'Gry.
Hom'Gry is een mobiele applicatie voor de levering van gastronomische maaltijden aan huis die we hebben ontwikkeld om de door de COVID-19-crisis getroffen restauranthouders in Luik te helpen. De levering wordt verzorgd in Luik en de omliggende gemeenten.
Hier is het persona dat we hebben bedacht voor onze applicatie:
Iemand die veel werkt en geen tijd heeft om te koken
Die gewend is om eten te bestellen via apps zoals Deliveroo of Takeaway
Die voldoende inkomen heeft om gastronomische maaltijden aan huis te laten bezorgen (artsen, advocaten, leidinggevenden, bedrijfsleiders, ...)
Die in Luik of de omliggende gemeenten woont
#3.
Toegevoegde waarde vinden voor de doorsnee gebruiker
2de stap van uw project: de toegevoegde waarde van uw mobiele app vinden voor uw gebruiker(s).
U moet zich afvragen waarom ze uw app zouden gebruiken.
De toegevoegde waarde is de oplossing die uw mobiele app biedt om aan de behoeften en/of problemen van uw gebruikers te voldoen. Het is ook waarvoor ze bereid zijn te betalen, zoals functies, uw expertise,...
De functies voor het type gebruiker:
De volgende stap in uw project is nadenken over de belangrijkste functies van uw app die zullen voldoen aan de behoeften van uw gebruikers.
Ga op dit moment nog niet te veel in op details.
Onthoud eerder de principes: Less is more en KISS (Keep It Simple, Stupid):
Uw klanten gebruiken uw app slechts voor 2 of 3 functies, dus het is niet nodig om er te veel toe te voegen.
Het voorbeeld van Hom'Gry:
Enkele onmisbare functies voor de app:
Keuze hebben tussen verschillende gerechten
Gemakkelijk kunnen bestellen
Weten wanneer het gerecht wordt geleverd
Direct de prijs van de bestelling kennen
Als u meerdere persona's heeft, kunt u verschillende functies hebben, zoals het voorbeeld laat zien: Claire, een gebruiker van Hom'Gry en Nicolas, een restauranteigenaar.
Vervolgens moeten deze functies worden gerangschikt op belangrijkheid.
Deze rangschikking is belangrijk als uw budget beperkt is, zodat u weet op welke schermen u de meeste inspanningen moet leveren.
Het is ook handig als u een functie moet wijzigen die niet werkt: u kunt dan een andere kiezen uit de lijst.
Het voorbeeld van Hom'Gry:
Hier zijn voorbeelden van belangrijke functies:
Gemakkelijk een gerecht kunnen bestellen
Weten wanneer het gerecht wordt geleverd
De lijst met beschikbare gerechten voor een bepaalde dag kunnen bekijken
Hier zijn voorbeelden van secundaire functies:
Allergieën kunnen bijwerken
Wachtwoord kunnen wijzigen
Dit zijn interessante maar niet essentiële functies.
Het belang van niet te veel functies aan uw app toe te voegen:
Om dit punt te benadrukken, citeren we Andrew Chen, die onder andere het team voor de groei van chauffeurs bij Uber heeft geleid. Momenteel is hij algemeen partner bij Andreessen Horowitz, het meest gerenommeerde durfkapitaalbedrijf in Silicon Valley:
"Er is een belangrijk ontwerpprincipe dat zegt 'Doe minder, maar beter' [...] Concurreer niet op functies. Als uw basisconcept niet werkt, werk dan aan de beschrijving in plaats van nieuwe dingen toe te voegen."
Als uw mobiele app 10 belangrijke functies heeft en niet werkt, heeft het geen zin om een 11de of 12de toe te voegen. Er is een probleem met uw toegevoegde waarde of functies.
U moet uw basisconcept herzien en uw app opnieuw op de markt brengen.
#4.
Welk bedrijfsmodel moet ik gebruiken voor mijn mobiele applicatie?
Hoe kunt u geld verdienen met uw mobiele app?
Er zijn verschillende economische modellen, en we zullen de 3 belangrijkste uitleggen:
-
Gratis (Free)
-
Betaald (Paid)
-
Freemium
Het GRATIS model:
Dit model is meestal gekoppeld aan advertenties.
Het lijkt voor veel projecteigenaars het beste te zijn, omdat Google en Facebook een imperium hebben opgebouwd met dit model. Deze voorbeelden doen vermoeden dat het een model is dat veel geld oplevert.
Dit is waar wanneer u miljarden gebruikers per maand hebt, maar u hebt minimaal 100.000 gebruikers per maand nodig voordat het enigszins winstgevend wordt.
Er zijn verschillende mogelijkheden om advertenties op uw app te tonen, hier zijn er twee:
Een professioneel advertentiebedrijf inschakelen: zij zorgen ervoor dat advertenties op uw app worden geplaatst. Het levert iets minder op, maar u hoeft niets te doen.
Zelf klanten benaderen om hun advertenties op uw app te plaatsen. Hier zult u wel wat tijd aan moeten besteden.
Advertenties financieren uw app, waardoor deze gratis is en dus gemakkelijker gebruikers aantrekt.
Voordat u dit economische model kiest, moet u nadenken over uw basisconcept.
Voorbeeld: als uw app een sociaal netwerk is, is reclame een goed idee.
Als u echter een nichepubliek kiest en u weet dat u niet genoeg gebruikers zult hebben, is dit niet het meest geschikte model. Het kan een aanvullend inkomen zijn, maar niet het belangrijkste.
Het BETAALD model:
Het betaalde model: men koopt de app, een product op de mobiele app of neemt een abonnement.
Aankoop van de app:
Het kopen van de app vormt een drempel, maar het is een gegarandeerde inkomstenbron.
Over het algemeen zijn apps niet te duur om de aankoop te bevorderen.
Dit model is ideaal als uw mobiele app aan een grote behoefte voldoet en er niet veel alternatieven zijn.
Dit model werkt beter voor iOS dan voor Android. Het iOS-publiek is meer geneigd om apps te kopen en tegen hogere prijzen.
Let op: Google en Apple nemen elk 30% commissie, afhankelijk van het verkochte product. Dit moet worden meegenomen bij het bepalen van de prijs van uw app.
Er zijn geen commissies op fysieke producten zoals eten of kleding, maar wel op virtuele producten zoals een Netflix-abonnement.
Abonnement:
Dit model wordt steeds populairder en is onder andere populair gemaakt door Netflix.
Het is een bron van terugkerende inkomsten, waardoor u een inkomstenpiramide kunt opbouwen:
Fictief voorbeeld:
U verkoopt 1000 abonnementen voor €10 per jaar en uw retentiepercentage is 100% (al uw gebruikers blijven maand na maand op uw app, ze zeggen hun abonnement nooit op):
Omzet jaar 1: €10.000
Omzet jaar 2: €20.000
Omzet jaar 3: €30.000
...
Hoe meer gebruikers, hoe meer het oplevert.
Nadat de app is ontwikkeld, zijn het vaak de marketingkosten die de belangrijkste kosten vertegenwoordigen.
Het FREEMIUM-model:
Dit is een tussenliggend model dat veel voorkomt. Uw app biedt zowel gratis als betaalde functies.
SaaS-bedrijven (Software as a Service), zoals Slack, Dropbox, Odoo of Hootsuite, maken veel gebruik van dit model. De brutowinstmarge van dit soort bedrijven is meestal 80%.
Het doel van de gratis functies is dus om gebruikers te verleiden een abonnement te nemen.
Voorbeeld: Spotify: u kunt gratis naar muziek luisteren, maar met advertenties, een audiokwaliteit die niet optimaal is en u kunt de volgorde van nummers niet kiezen, u hebt beperkte functies.
Als u een abonnement neemt, geen advertenties meer, aanzienlijk betere kwaliteit en toegang tot alle functies.
Andere voorbeelden: Dropbox, Hootsuite, League of Legends, Trello, Wordpress, Mailchimp, Candy Crush,...
Er is een risico: u moet het juiste evenwicht vinden. Als er te veel gratis functies zijn, is er geen reden om een abonnement te betalen, en vice versa, als er te veel betaalde functies zijn, wil men het misschien niet gratis proberen.
Het moeilijkste is om het juiste evenwicht te vinden.
⇒ Het is uw concept dat uw economische model bepaalt.
Het voorbeeld van Hom’Gry:
We hebben ervoor gekozen om een systeem van aankoop per maaltijd te hanteren. U kiest gewoon uw gerechten en betaalt ervoor.
Dit model lijkt te bevallen, want we hebben al snel ongeveer 150 actieve gebruikers gehad. Dat is al goed voor een lokale app met een niet-bestaand marketingbudget.
#5.
Marketing- en communicatiestrategie
Voordat we ingaan op operationele marketing, leggen we eerst verschillende trackingelementen uit waaraan aandacht moet worden besteed in het kader van een mobiele app.
Definieer wat een actieve persona is:
Het is belangrijk om de actie te definiëren die uw eenvoudige gebruiker zal veranderen in een actieve gebruiker.
Moeten ze een account aanmaken?
Moeten ze uw mobiele app dagelijks/wekelijks/maandelijks gebruiken?
Moeten ze functies op uw app kopen?
...
Voorbeeld: Facebook beschouwt een gebruiker als actief als deze interactie heeft op de site door te liken, te delen, te reageren, te sturen of te klikken op een andere link in de afgelopen maand. Als een gebruiker gedurende 30 dagen geen interactie heeft, wordt deze als inactief beschouwd.
Voorbeeld: Twitter: een actieve Twitter-gebruiker is iemand die minstens 30 accounts volgt en gevolgd wordt door minstens een derde van die accounts.
Voorbeeld van Hom'Gry:
Een actieve gebruiker is iemand die minstens één keer per kwartaal bestelt en minimaal twee bestellingen heeft geplaatst in het eerste kwartaal.
Het definiëren van uw actieve persona helpt bij het bepalen van de acquisitie- en retentiepercentages.
Acquisitiepercentage:
Het acquisitiepercentage is de kans dat een bezoeker van uw mobiele app een actieve gebruiker wordt.
Het traditionele proces voor acquisitie:
Een bezoeker komt op de homepage van uw site, ziet de downloadlink, downloadt uw app, maakt een account aan en voert een actie uit die een actieve gebruiker definieert.
Niet alle bezoekers zullen dit pad tot het einde volgen.
Om het acquisitiepercentage te meten:
Deel het aantal actieve gebruikers op uw app door het aantal bezoekers dat uw landingspagina heeft bezocht.
Hier is de formule om uw acquisitiekosten te berekenen:
Tel uw marketing- en verkoopkosten op en deel ze door het aantal verworven klanten.
Dit vertelt u hoeveel u moet uitgeven om een actieve gebruiker te verwerven.
Voorbeeld van Hom'Gry:
Marketingcampagnes trekken 250 bezoekers per week naar een landingspagina die is gewijd aan het installeren van de app. Deze pagina legt het concept van de app uit en probeert bezoekers te overtuigen deze te downloaden.
Van deze 250 bezoekers installeren er 100 de app op hun telefoon.
Van deze 100 bezoekers bestellen er 25 direct een gerecht via de app.
Van deze 25 zullen 20 gebruikers regelmatig bestellingen plaatsen, minstens één keer per kwartaal, zoals gedefinieerd.
⇒ Het acquisitiepercentage is 8% ((20/250)X100).
Als onze marketingcampagne €1000 per week kost, dan is onze klantacquisitiekost €50. De gebruiker moet €50 aan marge genereren voordat de marketingkosten zijn gedekt.
Het acquisitiepercentage stelt u in staat de prestaties en kosten van uw marketingcampagnes te meten en de winstgevendheid van uw mobiele app te controleren.
Retentiepercentage:
Het retentiepercentage bepaalt de tijd dat een gebruiker actief blijft op uw app. Het kan worden berekend voor elke periode (1 dag, 1 week, 1 maand). Het is in zekere zin het 'klantenbehoudpercentage'.
Voorbeeld van Hom'Gry:
Laten we het geval van Hom'Gry nemen om beter te begrijpen wat het retentiepercentage is, berekend in dit geval per kwartaal omdat we hebben gedefinieerd dat een gebruiker actief wordt als ze per kwartaal bestellen.
Kwartaal 1: onze app heeft 100 nieuwe actieve gebruikers verworven.
We hebben het retentiepercentage van de app gemeten op 80%, dus:
Kwartaal 2: er zullen 80 actieve gebruikers overblijven (als er geen marketingactie wordt ondernomen).
Kwartaal 3: er zullen 64 actieve gebruikers overblijven.
⇒ Het aantal actieve gebruikers neemt geleidelijk af als we geen nieuwe gebruikers vinden.
Het retentiepercentage is over het algemeen minder dan 100%, ongeacht de app, zelfs voor reuzen als Netflix of Spotify. Het aantal actieve gebruikers neemt dus geleidelijk af.
Het belang van acquisitie- en retentiepercentages:
Deze percentages zijn belangrijke prestatie-indicatoren waarmee u de basisprincipes van uw app kunt valideren of weerleggen.
Een Key Performance Indicator (KPI) is een maatstaf waarmee kan worden bepaald of uw mobiele app werkt of niet.
Er zijn andere interessante prestatie-indicatoren; we komen erop terug in hoofdstuk 8.
Deze twee percentages helpen ook bepalen of uw app meer marketing- en communicatie-inspanningen nodig heeft voor acquisitie of retentie, afhankelijk van uw concept. ⇒ U kunt uw strategieën naargelang aanpassen.
Levensduurwaarde:
Dit is de waarde die een gemiddelde klant u gedurende hun hele leven oplevert, gemeten in termen van omzet. Levensduurwaarde is ook een interessante KPI.
Om dit concept beter te begrijpen, gaan we deze waarde berekenen voor Hom'Gry.
Voorbeeld van Hom'Gry:
We weten dat:
De gemiddelde waarde van een bestelling €26,7 bedraagt, exclusief btw.
Een actieve gebruiker plaatst gemiddeld 1,7 bestellingen per kwartaal.
De acquisitiekost is €50.
Het retentiepercentage is 80% per kwartaal.
De bruto marge op een bestelling is 20%: bijvoorbeeld, bij een bestelling van €10 gaat €8 naar het restaurant en €2 voor ons.
⇒ Het totaal verkocht over 5 jaar voor 100 initiële klanten = €22.500 ⇒ De Levensduurwaarde is €225 per klant.
Wetende dat we een marge van 20% hebben op bestellingen, hebben we een marge van €45 per klant, en hun acquisitiekost is €50 ⇒ We moeten onze app aanpassen omdat deze structureel niet winstgevend is.
Marketingaanpak voor een mobiele app:
Denk na over het ontwikkelen van een algehele strategie.
De marketing van een mobiele app lijkt sterk op traditionele marketing.
Hier zijn enkele mogelijke benaderingen:
Media;
Promotionele evenementen;
E-mailcampagnes;
Verkoopvertegenwoordigers: om klanten/gebruikers te benaderen;
SEO: om te verschijnen in de topresultaten op Google voor specifieke zoekwoorden;
Google Ads: voor snellere resultaten dan organische SEO;
Facebook/Instagram Ads
Een communitymanager
Flyers verspreiden
...
U kunt ook SEO doen in de App Store en Google Play om als eerste te verschijnen in bepaalde resultaten, maar het is geen magische oplossing! U heeft geen garantie op resultaten.
Richt u meer op traditionele marketing.
⇒ Vergeet niet dat uw marketingbenadering afhankelijk is van het concept van uw mobiele app.
Voorbeeld van Hom'Gry:
We hebben besloten om voornamelijk Facebook Ads te gebruiken:
We richtten ons eerst op de locatie: cruciaal omdat we enkel leveren in Luik en omliggende gemeenten. We hebben ook bepaalde locaties uitgesloten.
Leeftijd: 25-65+ jaar: we hebben een brede leeftijdscategorie ingesteld omdat we ons niet op een specifieke leeftijdsgroep richten.
Aanvullende interesses: mensen die van Deliveroo en Takeaway houden en die waarschijnlijk de gewoonte hebben om eten te bestellen, evenals een interesse in gastronomie om zo goed mogelijk aan te sluiten bij het profiel van onze persona.
We voerden campagnes van verschillende stijlen uit, maar met dezelfde targeting om te zien welke het beste werken.
We verdeelden ons budget aanvankelijk over verschillende campagnes.
Vervolgens verhoogden we het budget voor advertenties met een beter acquisitie-, retentie- en conversiepercentage.
Hier is nog een ander voorbeeld van advertenties:
We kozen voor Facebook-advertenties om foto's te kunnen tonen vergezeld van tekst met verschillende berichten:
Het primaire doel van de app is om restaurants te helpen, dus we benadrukten het bericht van solidariteit in sommige advertenties en andere richtten zich meer op de gerechten.
Test verschillende berichten om te zien wat het beste werkt.
We hebben ook een communitymanager die de Facebook- en Instagrampagina's beheert.
We sturen ook wekelijks een nieuwsbrief om gebruikers op de hoogte te houden van de gerechten van de week.
We sturen e-mails naar mensen die hun adres in de app hebben ingevoerd; niet iedereen heeft besteld, dus we proberen hen te overtuigen via deze nieuwsbrief.
#6.
Applicatieschermen structureren
Na het 'reflectieve deel' komen we nu bij het technische gedeelte van uw applicatie.
De structurering van de schermen is bedoeld om uw applicatie te visualiseren en te begrijpen hoe deze zal werken.
Over het algemeen zijn er minder schermen dan op een website, en het is vaak intuïtiever en plezieriger in gebruik.
Een van de eerste stappen in de ontwikkeling is het creëren van wireframes.
Een wireframe is een plan of een schema dat handig is om u te helpen nadenken over de structuur van uw applicatie.
Informatie om in gedachten te houden bij het maken van wireframes:
- Concentreer u op de algemene structuur van de schermen en niet op de details: een wireframe vertegenwoordigt niet het definitieve ontwerp van uw applicatie, het is een algemeen idee;
- Aarzel niet om uw mening te geven: een wireframe is eenvoudig te maken en dient om de discussie aan te gaan om de beste structuur mogelijk te bouwen;
- Een wireframe vereist geen code: u kunt ze met de hand maken of via tools zoals Balsamiq;
- Laat u inspireren door wat al werkt en pas het aan uw project aan: het heeft geen zin om het wiel opnieuw uit te vinden: kijk naar wat uw concurrenten doen, kijk ook naar andere sectoren maar met vergelijkbare functies, en laat u inspireren door grote bedrijven zoals Facebook, Amazon, Uber, Instagram, enz. omdat ze weten wat wel of niet werkt, wat gebruikers leuk vinden. Altijd inspireren, nooit kopiëren!
⇒ Houd rekening met alle elementen die in de vorige stappen zijn gedefinieerd.
Hier zijn enkele voorbeelden van Balsamiq:
U moet ook nadenken over de onderlinge verbinding tussen de verschillende schermen van uw applicatie: de volgorde van de schermen bepalen of wanneer u een bepaalde actie uitvoert, u op een bepaald scherm terecht komt.
Dit leidt tot de constructie van een "gekoppelde boom", zoals het voorbeeld hieronder van Balsamiq laat zien.
U moet nadenken over de navigatie van de gebruiker op uw mobiele applicatie.
Dit kunt u doen door de schermen naast elkaar te plaatsen en te bedenken dat als u op een bepaalde knop klikt, u op een bepaald scherm terechtkomt.
Of u kunt dit doen via tools zoals Balsamiq of Figma: u kunt uw wireframes configureren zodat u echt op de knoppen kunt klikken.
Vergeet niet om uw applicatie voor te stellen op verschillende formaten. Uw interfaces moeten prettig zijn op zowel grote als kleine schermen.
We raden u aan om begeleiding te zoeken bij het maken van uw wireframes door een bedrijf dat hier ervaring mee heeft en dat ook betrokken is bij de ontwikkeling, omdat ze u goed advies kunnen geven.
De manier waarop u uw wireframes maakt en uw schermen structureert, kan de complexiteit van de ontwikkeling en dus de prijs van uw applicatie beïnvloeden.
Het voorbeeld van Hom'Gry:
Dit is het traditionele systeem van een thuisbezorgingsapplicatie voor maaltijden:
Scherm 1: u kunt een restaurant of onze gerechten kiezen;
Scherm 2: u krijgt een samenvatting van uw bestelling te zien;
Scherm 3: u komt bij de betaling van uw bestelling;
Scherm 4: u ontvangt een bevestigingsmail van uw bestelling en dan wordt uw bezorging geleverd.
Voor Hom'Gry hebben we besloten om een beetje te innoveren en dit traditionele systeem niet te gebruiken.
In de app kunt u de leveringsdag en de gerechten kiezen en uw bestelling tot 24 uur van tevoren annuleren via een "selectie-deselectie" systeem zoals u kunt zien op de onderstaande afbeelding.
De bestelling is bevestigd, maar u ontvangt geen bevestiging omdat u deze kunt annuleren.
We dachten dat dit systeem ergonomisch beter zou zijn voor gebruikers, maar het was een fout.
Het werkte niet goed omdat het te veel verschilde van de traditionele gebruikersgewoonten: de officiële bevestiging van de bestelling ontbrak.
We merkten dat dit vooral verwarrend was voor de gebruikers van bezorgings- en online koop-apps die het traditionele aankoopproces goed kennen.
Hoewel ons systeem goed werd uitgelegd in de app, vergisten mensen zich.
Aan de andere kant hadden mensen die minder vertrouwd waren met technologie of die niet vaak op e-commerce sites kochten, geen moeite met ons systeem omdat ze geen specifiek patroon verwachtten.
Dit was een fout van onze kant; we wilden innoveren, maar het is geen goed idee om een systeem te veranderen dat door bijna alle thuisbezorgingsapplicaties wordt gebruikt.
Om diepgewortelde gewoonten te veranderen, moet u ze geleidelijk aanpassen. In ons geval was dit een te grote verandering.
Innoveren is belangrijk, maar men moet altijd beseffen dat dit een risico met zich meebrengt.
#7.
De technische kant van een applicatie
We leggen in dit onderdeel uit hoe een applicatie vanuit technisch oogpunt werkt.
De architectuur van een applicatie is verdeeld in 3 delen:
1) Frontend (= de app geïnstalleerd op de telefoon):
Dit is het zichtbare deel van de applicatie. Er zijn verschillende mogelijke technologieën:
- Voor het ontwikkelen van een native applicatie (= applicatie ontwikkeld voor een specifiek besturingssysteem, IOS of Android):
Voor IOS: wij gebruiken Swift en Objective C
Voor Android: wij gebruiken Java en Kotlin
Een native applicatie vereist 2 verschillende ontwikkelingen voor de 2 besturingssystemen.
Deze talen zijn het meest geschikt voor mobiele toepassingen.
Er bestaat ook een andere benadering:
- Voor het ontwikkelen van een hybride applicatie (= een website aangepast voor mobiel gebruik):
Een paar jaar geleden waren hybride applicaties duidelijk inferieur aan native applicaties.
Vandaag zijn er verschillende technologieën die kunnen concurreren.
Flutter: ontwikkeld door Google.
React Native: ontwikkeld door Facebook
Deze benadering maakt het mogelijk om een applicatie voor beide besturingssystemen te ontwikkelen met één code, waardoor ontwikkelaars ongeveer twee keer zo snel uw mobiele applicatie kunnen maken.
2) Backend (= serverkant):
Dit is het brein van de applicatie dat alle logica bevat.
Om uw applicatie te laten werken, hebt u een server die zich ergens in Europa of elders bevindt en die communiceert met de op uw telefoon geïnstalleerde applicatie.
We nemen het voorbeeld van Facebook: alle gebruikers, geposte foto's, opmerkingen, enz. worden niet op uw telefoon opgeslagen, maar op een server.
Een server kan worden vergeleken met een enorme computer en in het geval van Facebook met tienduizenden computers om hun infrastructuur te beheren.
De server voorziet de applicatie van informatie.
Populaire technologieën:
Wij gebruiken Django en Python (gebruikt door Google, Facebook, Amazon, ...)
Laravel en PHP
Node JS
...
Het is heel eenvoudig om robuuste talen te vinden. Er is de TIOBE Index die de meest gebruikte programmeertalen ter wereld bepaalt.
3) Database:
Dit is het geheugen van de applicatie.
De backend slaat alle informatie op in een database die zich op de server bevindt.
Er zijn verschillende technologieën:
MySQL, Postrgresql, MSSQL-server
MongoDB, ...
PWA = Progressive web Apps:
Dit is een andere oplossing om een applicatie te maken.
Dit is een webapplicatie, geen mobiele, die op een telefoon kan worden geïnstalleerd.
Voordelen:
- Eenvoudig te ontwikkelen
- Goed ondersteund op Android maar zeer weinig compatibel met IOS.
- Vereist niet per se installatie: u gaat naar de website en een popup stelt voor om deze op uw telefoon te installeren.
- Geen noodzaak om deze in de app stores te publiceren (kan ook een nadeel zijn: u profiteert niet van hun beoordelingen, u kunt geen updates via de app stores plaatsen en gebruikers kunnen u niet in de app stores vinden).
Kies uw projectmanagement:
Naast het kiezen van het type applicatie en de technologieën, moet u ook een projectmanagementmethode kiezen.
Er zijn twee grote methodologieën:
1) Het watervalmodel:
U schrijft, met het ontwikkelingsteam, een volledig bestek met alle specificaties die u wilt. De ontwikkeling wordt uitgevoerd en aan het eind heeft u een afgewerkt product.
2) De Agile-projectmanagementmethode en meer specifiek SCRUM:
Dit is de meest gebruikte methode in de informatica. We gebruiken deze methode intern.
Deze methode houdt in dat de ontwikkeling van uw applicatie in verschillende fasen wordt verdeeld.
In elke fase ontwikkelen we vooraf bepaalde functies die u aan het einde van die fase test.
Nadat u ze hebt goedgekeurd, beginnen we een nieuwe fase door nieuwe specificaties te ontwikkelen totdat uw volledige applicatie is ontwikkeld.
Na elke fase geeft u ons feedback en passen we de ontwikkeling indien nodig aan, wat helpt om de beste mogelijke applicatie te ontwikkelen.
Deze methodologie bevordert de interacties tussen de klant en de IT-dienstverlener en zorgt voor een betere opvolging van de voortgang van het project.
Voor ons is het een essentieel hulpmiddel voor het succes van uw project.
Hier is een voorbeeld dat duidelijk het verschil illustreert tussen deze twee methoden:
U hebt een budget van 30.000€ voor uw applicatie:
U kiest de watervalmethode en ontwikkelt uw hele applicatie in één keer;
Eenmaal op de markt gelanceerd, werkt uw applicatie niet.
U hebt geen budget meer om uw mobiele applicatie aan te passen.
⇒ De SCRUM-methode stelt u in staat om uw initiële aannames te valideren of te weerleggen en de ontwikkeling indien nodig aan te passen.
#8.
Hoe kan ik mijn prestaties meten?
Het meten van prestaties is een zeer belangrijke stap voor alle projecten.
Om uw prestaties te meten, moet u Key Performance Indicators (KPI's) bepalen, oftewel belangrijke prestatie-indicatoren.
Het is belangrijk om de juiste indicatoren te kiezen, omdat deze variëren van project tot project.
Voorbeelden van interessante KPI's voor een mobiele applicatie zijn onder andere:
Life Time Value
Acquisitiepercentage
Retentiepercentage
Aantal actieve gebruikers
Verschillende acquisitiepercentages gedurende het hele acquisitietraject (= aankooptraject)
Aantal retouren van goederen
Sommige KPI's zijn meer gericht op marketing, andere op klanttevredenheid of productie.
Deze KPI's helpen ook te bepalen of veranderingen in uw applicatie effectief zijn.
Het voorbeeld van Hom'Gry:
Enkele interessante KPI's zijn:
- Het gemiddelde aantal bestellingen per kwartaal
- Het gemiddelde winkelwagentje per bestelling
- Brutowinstmarge op bestellingen
- Klassieke KPI's: kosten en acquisitiepercentage, retentiepercentage, Life Time Value, acquisitietraject: het percentage op elke stap
Al deze gegevens helpen bij het nemen van beslissingen over de schermen van uw applicatie: als uw applicatie niet goed werkt, kunt u sneller identificeren wat het probleem is.
De verschillende waarden die de prestaties van uw applicatie meten, zijn intrinsiek verbonden met het businessplan van uw startup/bedrijf:
Het doel is altijd dat uw applicatie een positief effect heeft op uw bedrijf.
De KPI's die u meet moeten impact hebben op uw businessplan; als ze dat niet hebben, betekent dit dat u uw KPI's niet goed hebt gedefinieerd en ze dus nutteloos zijn.
Een andere oplossing voor het meten van uw prestaties is A/B-testen:
Als u voldoende gebruikers heeft, zodat het statistisch representatief is, kunt u twee testversies maken van bepaalde schermen van uw applicatie:
100 gebruikers hebben toegang tot scherm A van uw applicatie
100 gebruikers hebben toegang tot scherm B van uw applicatie
⇒ U heeft twee versies van hetzelfde scherm nodig om te bepalen welke het meest effectief is. Nadat u een resultaat heeft, behoudt u het meest relevante scherm en verwijdert u het andere.
Soms is het voldoende om slechts één of twee dingen te veranderen, niet noodzakelijk het hele scherm.
Het voorbeeld van Hom'Gry:
Versie 1: we begonnen met een abonnementssysteem dat recht gaf op 7 bestelde gerechten per week, maar al snel realiseerden we ons dat deze formule niet populair was.
We hadden een acquisitiepercentage van 0,5%, het abonnement vormde dus een grote drempel. We zagen dat gebruikers de app installeerden, een account aanmaakten en vervolgens afhaakten bij het kiezen van het abonnementsformulier.
We hebben dus het systeem gewijzigd.
Versie 2: we kozen voor een aankoop per gerecht: de gebruiker bestelt en betaalt direct zijn gerecht. We hebben dit nieuwe systeem getest op nieuwe gebruikers voordat we de applicatie voor alle gebruikers hebben aangepast.
Het acquisitiepercentage was aanzienlijk hoger.
#9.
Aanpassingen doorvoeren of niet?
Het belang van aanpassingen doorvoeren als uw applicatie niet het verwachte succes behaalt:
Wees nooit bang om zaken aan te passen, om terug te gaan naar eerdere stappen als u merkt dat uw basisaannames niet juist zijn.
⇒ U kunt altijd uw project aanpassen!
Aanpassen biedt een nieuwe kans op succes of groei.
Aanpassen betekent niet het toevoegen van functies, maar eerder het herzien van de basis: u werkt aan een functie in plaats van er een toe te voegen.
Voorbeelden van bedrijven die hebben aangepast:
Twitch.TV: afkomstig van het platform Justin.tv dat video's aanbood van mensen die zichzelf filmden terwijl ze iets deden. Er waren verschillende categorieën, maar slechts één werkte echt goed: mensen die zichzelf filmden terwijl ze videogames speelden. Deze categorie was zo succesvol dat het bedrijf besloot er een aparte site aan te wijden genaamd Twitch.TV, meer geschikt voor gamers, en die nu miljoenen actieve gebruikers per maand heeft.
Facebook: aanvankelijk was Facebook alleen toegankelijk voor studenten van Harvard. Het was de digitale versie van het fotoalbum van studenten. Het netwerk opende vervolgens voor andere Amerikaanse universiteiten voordat het zich uitbreidde naar de rest van de wereld om vandaag de dag een onmisbaar sociaal netwerk te worden.
Het voorbeeld van Hom'Gry:
We hebben het probleem snel geanalyseerd en omdat we de SCRUM-methode gebruiken, hadden we nog steeds budget over om de applicatie aan te passen.
We hebben niet de hele applicatie aangepast, maar alleen het aankoopsysteem dat niet goed beviel.
Wat te doen om mijn prestaties te verbeteren?
Enkele tips:
- Heroverweeg uw marketingstrategie: voorbeelden:
Meer budget besteden aan adverteren op sociale media/Google Ads
Meer tijd besteden aan het beheer van sociale media
Herzie uw communicatie: Voorbeeld voor Hom'Gry: misschien moeten we het woord "gastronomie" vervangen door "traiteur".
Herzie uw persona's: richt u zich op de juiste gebruikers?
Herzie uw functies
⇒ Herzie uw initiële aannames!
#10.
Conclusie
Om een mobiele applicatie te ontwikkelen, moet u verschillende stappen doorlopen voordat u daadwerkelijk aan de ontwikkeling begint.
Allereerst moet u uw gebruikerstypen definiëren en deze gedurende het hele project in gedachten houden, omdat u de applicatie voor hen ontwerpt.
U moet de toegevoegde waarde van uw applicatie vinden, dat wil zeggen de oplossing die het biedt voor een probleem en/of behoefte. Waarom zou iemand uw applicatie willen gebruiken?
Vervolgens moet u de belangrijkste functies van uw mobiele applicatie opsommen, degene die zullen helpen om aan de behoeften en/of problemen van gebruikers te voldoen. Ga naar de essentie.
Daarna moet u nadenken over het verdienmodel van uw mobiele applicatie. Er zijn verschillende mogelijkheden: het gratis model, het betaalde model of zelfs het tussenliggende model. Het is uw concept dat uw verdienmodel bepaalt.
U moet een algehele marketing- en communicatiestrategie uitwerken om ervoor te zorgen dat uw applicatie een succes wordt. We raden aan om te kiezen voor traditionele marketingmethoden zoals media, verkoopteams, sociale media, organische en betaalde zoekmachineoptimalisatie, promotionele evenementen, enzovoort.
Na deze stap kunt u uw schermen structureren om te bepalen hoe uw applicatie eruit zal zien en hoe deze zal functioneren.
We komen nu bij de ontwikkeling van uw mobiele applicatie: u moet uw projectmanagementmethode kiezen: Waterval (alles in één keer ontwikkelen) of SCRUM (ontwikkelen in verschillende fasen).
Zodra uw mobiele applicatie op de markt is gelanceerd, moet u uw prestaties meten aan de hand van KPI's (acquisitie- en retentiepercentages, Life Time Value, aantal actieve gebruikers, enzovoort) die aangeven of uw project rendabel is of dat er aanpassingen nodig zijn.
Als uw applicatie niet het verwachte succes heeft, aarzel dan niet om aanpassingen te maken! Aanpassen staat niet voor falen, maar biedt een nieuwe kans op succes of groei. U kunt uw project altijd aanpassen tijdens de rit!
We hopen dat dit artikel u zal helpen.
Als u vragen heeft, aarzel dan niet om contact met ons op te nemen.
Heb je een vraag, een project om te ontwikkelen?Twijfel niet langer en neem contact met ons op!