Jij bent expert in het domein van jouw bedrijf en wij zijn expert in het bouwen van applicaties. Om een goede keuze te kunnen maken of jouw bedrijf past bij onze werkwijze en techniek hebben we uiteengezet wat wij belangrijk vinden bij het bouwen van een mobiele app.
Voordat we beginnen met het bouwen van een mobiele applicatie zoeken we zorgvuldig uit wat en waarom we deze gaan bouwen. We beginnen een project met één of meerdere Discovery Sprints, waarin we onderzoek doen, een Value Proposition Canvas invullen, conceptontwerpen maken en een MVP (Minimal Viable Product) definiëren. Hiermee creëren we samen een goede basis voor de te bouwen app.
Na de Discovery Sprint(s) starten we met doorlopende Delivery Sprints. Deze sprints zijn gebaseerd op de SCRUM-methodiek die veel wordt gebruikt in productontwikkelingsteams. In deze sprints werken onze designers en developers samen om features van de roadmap te ontwerpen én te bouwen.
Bij het ontwerpen van een mobiele applicatie, (zowel in Discovery- als Delivery Sprints), stellen we de gebruiker centraal. Vaak zijn deze apps een nieuwe service of een onderdeel van een complex digitaliseringstraject. Dit vraagt om kennis en expertise om deze vraagstukken op te lossen.
In de Discovery Sprints willen we erachter komen wat we gaan bouwen en waarom. Vaak komt de vraag in eerste instantie vanuit de business, maar is het juist een oplossing voor een gebruikersprobleem. Door middel van user research, bijvoorbeeld interviews, valideren we in welke mate dit of deze problemen bestaan. Op basis van deze informatie ontwerpen we conceptrichtingen en prototypes die we vervolgens weer voorleggen bij de toekomstige gebruikers. Zo valideren we of onze oplossing ook daadwerkelijk iets oplost. Ook kunnen we hiermee een goed bepalen wat we als eerste moeten bouwen om het grootste effect te sorteren.
In de Delivery Sprints is design ook een belangrijk onderdeel. In deze sprints ontwerpen we de daadwerkelijke functionaliteiten van de app. De basis van elk goed design van een app is het Design System. Dit is een verzameling van designelementen zoals knoppen, invoervelden, typografie, layouts en navigatiestructuren. Wanneer een Design System goed is opgezet, zul je zien dat een applicatie schaalbaar en consistent is op het gebied van design. Wij hechten hier veel waarde aan, omdat we hiermee op de lange termijn veel tijd en moeite besparen.
Naast een Design System maken we gebruik van veel gebruikte mobiele Design Patterns. Dit is vergelijkbaar met Design Patterns in de architectuur. Achter een voordeur zit altijd een gang met een garderobe, toilet en de trap naar boven. Dit soort Patterns bestaan ook voor digitale producten en zorgen ervoor dat gebruikers direct snappen hoe de app werkt. We hoeven het wiel in veel gevallen niet opnieuw uit te vinden.
Wij ontwikkelen onze mobiele apps in React Native. Dit is een framework op basis van de populaire React Library, ontwikkeld door Facebook en de open source community. Wereldwijd maken veel grote bedrijven gebruik van React en React Native en is het één van de standaarden om applicaties in te bouwen.
Het grote voordeel van React Native ten opzichte van de "traditionele" manier van mobiele applicaties schrijven (een aparte app voor iOS en Android), is dat je maar één keer code hoeft te schrijven voor iOS en Android. Dit scheelt in veel gevallen 50% van de tijd en dús budget.
Wat erg belangrijk is bij React Native, is dat de app en de elementen die je op je scherm ziet, "native code" is. Dat is wat technisch, maar het zorgt ervoor dat een app snel en betrouwbaar is. Dat is een belangrijk verschil met andere frameworks die een website omzetten in een app. Daar krijg je geen echte app-ervaring en voelt de app gewoon als een website.
Een ander bijkomend voordeel van React Native is dat je kleine updates direct kan versturen naar de app, zodat je bugs of belangrijke wijzigingen direct kunt doorvoeren, zonder eerst goedkeuring te krijgen van de App Store (Apple) en de Play Store (Android).
Snelheid is essentieel bij een app. Gebruikers verwachten apps waarbij ze weinig hoeven te wachten tot hun content geladen is. Dat begint al aan de 'achterkant': bij de server API. We zorgen ervoor dat de server(s) en datasources (database en bestanden) dicht bij de fysieke locatie van de gebruiker zijn. Dit maakt dat de tijd die het kost om data van de server naar de gebruiker te sturen zo kort mogelijk is. Daarnaast maken we slim gebruik van 'server side' caching. Server side caching betekent dat wanneer een gebruiker twee keer dezelfde data opvraagt (bijvoorbeeld als iemand het app-scherm ververst), de tweede keer niet alles uit de database komt, maar uit een cache wordt gehaald. Dit kan veel tijd schelen, met name bij data-intensieve applicaties.
Ook maken we gebruik van lokale caching en pre-loading. Lokale caching betekent dat wanneer je de app binnen een bepaalde periode nog een keer opent je data ziet die lokaal op je telefoon is opgeslagen. De data wordt vervolgens op de achtergrond ververst. In dit geval toont de app dus informatie die al eerder is gedownload en dus niet hoeft te laden.
Daarnaast maken we gebruik van pre-loading. Hiermee laden we van tevoren pagina's of elementen waarvan we denken dat de gebruiker die in de toekomst gaat gebruiken. Een goed voorbeeld hiervan is de inzicht pagina in de Frank Energie app. Hier kun je jouw historische verbruik zien per maand, week of dag. Wanneer de pagina is geladen op een bepaalde maand, pre-loaden we alvast de maand ervoor en erna. Wanneer de gebruiker op de vorige maand drukt, heeft de app de data al geladen en hoeft de gebruiker niet meer te wachten.
Het is van groot belang dat je applicatie betrouwbaar is en altijd goed werkt. Gebruikers raken gefrustreerd wanneer er bugs in de app zitten of informatie niet geladen kan worden. Om dit te voorkomen maken we gebruik van Automated Testing, Error Tracking en een stabiel wereldwijd netwerk.
We minimaliseren het aantal bugs door in eerste instantie alle code te peer-reviewen voordat deze naar de live-omgeving gaat, maar ook door ons uitgebreide Automated Testing proces. In dit proces vertellen we een computer hoe een bepaald onderdeel van de app moet werken en wat we verwachten van de app als een gebruiker bepaalde handelingen uitvoert. De computer voert dan volgens onze instructies uit op individuele onderdelen van de app, maar ook door de gehele app heen. Dit heet End-to-End testing. Hiermee voorkomen we dat een nieuwe feature eventueel een andere bestaande feature breekt.
Samen met onze infrastructuurpartners Vercel, Digital Ocean en AWS (Amazon), maken we gebruik van een betrouwbaar en schaalbaar netwerk dat wordt gebruikt door vele grote bedrijven wereldwijd. We garanderen een uptime van 99,5% van al onze technische onderdelen, inclusief externe partijen. In de praktijk ligt dit percentage nog hoger.
Ook zorgen onze partners voor wereldwijde schaalbaarheid. Onze websites, platformen en API's worden gehost op verschillende plekken in de wereld en schalen automatisch op bij drukte. Hierdoor kunnen we grote pieken in verkeer en grote groei in gebruikersaantallen gemakkelijk aan.
Al onze software werkt met een API-architectuur. Dat houdt in dat de API (de achterkant) gescheiden is van de voorkant. Dit maakt het mogelijk om alle informatie uit de API ook te ontsluiten naar andere onderdelen zoals een web applicatie, desktop applicatie of zelfs een billboard langs de snelweg.
Ook komt het vaak voor dat we moeten koppelen met externe systemen die onze opdrachtgevers al in gebruik hebben. Door onze API-aanpak kunnen we eenvoudig koppelen aan deze systemen, zodat onze API informatie krijgt van het externe systeem, of dat onze API informatie toevoegt aan het externe systeem.
Een goed voorbeeld daarvan is een koppeling met een betalingsprovider. De betalingsprovider zorgt voor de afhandeling van de betaling binnen een webshop, terwijl onze API over en weer communiceert zodat we altijd op de hoogte zijn van de status van de betaling.
Vanaf het moment dat de eerste versie van de app live is leveren we support en blijven we de software onderhouden. Dit doen we onder een standaard Service Level Agreement. Onder deze SLA monitoren we de systemen continu, waarbij errors direct bij ons binnenkomen. Hierdoor zorgen we dat we altijd op te hoogte zijn als er iets mis gaat. Ook zijn we 24/7 bereikbaar bij kritische problemen.
Nadat we de eerste versie (de MVP) hebben opgeleverd zullen we verder sprinten in de vorm van Delivery Sprints. We stellen gezamenlijk een roadmap op en zullen continu doorwerken aan de nieuwe features met de hoogste prioriteit. Het is aan jou om te bepalen hoe lang we door blijven ontwikkelen en hoe snel de ontwikkeling zal gaan. Door het werken in sprints kunnen we op elk moment de scope van het project wijzigen, zonder dat we daar nieuwe contractuele afspraken voor hoeven te maken.
Als je meer wilt weten over hoe we samen met jou een nieuwe app kunnen ontwikkelen, neem dan contact op met Corjen, onze technisch directeur.