Eerst worden de belangrijkste gebruikersroutes beschreven. Zo’n route laat zien welke stappen iemand doorloopt om een doel te bereiken. Bij een reserveringsapp kan dat bijvoorbeeld bestaan uit een locatie selecteren, beschikbaarheid bekijken, gegevens invullen, bevestigen en later de reservering wijzigen.

Per route wordt bepaald welke schermen nodig zijn en welke informatie de gebruiker ziet of invoert. Ook afwijkende situaties verdienen aandacht. Wat gebeurt er wanneer een product niet beschikbaar is, een betaling wordt afgebroken of een internetverbinding wegvalt? Deze voorwaarden worden opgenomen in de functionele werking van de app.

Daarna volgt het ontwerp van de gebruikersomgeving. Wireframes maken de indeling en navigatie zichtbaar voordat alle techniek is gebouwd. Vervolgens kan de visuele uitwerking worden afgestemd op de huisstijl, het type apparaat en de manier waarop de doelgroep de app gebruikt.

Een volgende keuze is het platform. Een app kan worden ontwikkeld voor Android, iOS of beide. Soms is een webapplicatie via de browser voldoende. De gewenste apparaatfuncties, distributievorm en gebruiksomgeving bepalen welke technische oplossing passend is.

Veel mobiele apps hebben een backend nodig. Dit is de techniek waarmee gegevens worden verwerkt, accounts worden beheerd en bedrijfsregels worden uitgevoerd. Ook kan een afzonderlijk beheerpaneel worden ontwikkeld waarin bevoegde medewerkers bijvoorbeeld content, aanvragen, gebruikers of instellingen beheren.

Moet de app informatie uit bestaande software gebruiken? Dan zijn API-koppelingen nodig. Een app kan bijvoorbeeld klantgegevens ophalen uit een CRM-systeem, planningsinformatie uit bedrijfssoftware tonen of een uitgevoerde handeling terugsturen. De beschikbare technische interfaces bepalen welke gegevensuitwisseling mogelijk is.

Ook gebruikersrollen moeten vooraf worden vastgelegd. Een klant, medewerker en beheerder hebben doorgaans niet dezelfde toegang nodig. Per rol wordt bepaald welke schermen, gegevens en handelingen beschikbaar zijn. APPelit bouwt deze autorisaties volgens de door de opdrachtgever aangeleverde regels.

Tijdens de ontwikkeling worden onderdelen getest. Daarbij wordt niet alleen gecontroleerd of een knop werkt, maar ook of invoer correct wordt verwerkt, rollen worden gerespecteerd en afwijkende situaties goed worden afgehandeld. De opdrachtgever beoordeelt tijdens controles of de gerealiseerde functies aansluiten op de overeengekomen werking.

Voor publicatie in de Google Play Store of Apple App Store zijn ontwikkelaarsaccounts, appinformatie, afbeeldingen en technische builds nodig. Ook moeten vereiste verklaringen over functies en gegevensverwerking worden ingevuld. APPelit kan deze voorbereiding en publicatie begeleiden als onderdeel van het ontwikkeltraject. Eventuele app-store-optimalisatie hoort daarbij en wordt niet als losse dienst aangeboden.

Na de lancering blijft technisch beheer relevant. Besturingssystemen, externe koppelingen en gebruikte softwarecomponenten kunnen veranderen. Daarnaast kunnen gebruikers nieuwe wensen opleveren. Daarom worden afspraken gemaakt over onderhoud, foutoplossing en eventuele verdere ontwikkeling.

Wat bepaalt de kosten van een app laten maken? Vooral het aantal schermen en functies, de complexiteit van de bedrijfsregels, de platformkeuze, het ontwerp, gebruikersrollen, koppelingen en beheerfuncties hebben invloed. Ook offline gebruik, betalingen, locatiebepaling, pushberichten en verwerking van bestanden kunnen de omvang vergroten.

Een eerste versie hoeft niet direct iedere toekomstige functie te bevatten. Wanneer de belangrijkste gebruiksroute duidelijk is, kan een afgebakende versie worden ontwikkeld en later worden uitgebreid. Welke onderdelen tot de eerste oplevering behoren, wordt vooraf vastgelegd.

Case: service-app voor onderhoud aan zakelijke apparatuur

Meldingen, foto’s en servicestatussen mobiel beschikbaar maken

Een leverancier onderhoudt apparatuur op locaties van zakelijke klanten. Storingen worden telefonisch of per e-mail gemeld. Daardoor ontbreekt soms informatie over het apparaat, de locatie of de aard van het probleem wanneer een servicemedewerker de melding ontvangt.

De leverancier wil een mobiele app waarmee klanten een storing kunnen registreren. De opdrachtgever bepaalt welke klantgegevens, apparaatkenmerken en categorieën nodig zijn. Ook legt de organisatie vast welke statussen zichtbaar worden en wanneer een melding mag worden gewijzigd.

De belangrijkste gebruikersroute begint bij het selecteren van een geregistreerd apparaat. De klant kiest daarna een storingscategorie, beschrijft het probleem en kan één of meer foto’s toevoegen. Na verzending ontvangt de melding een uniek nummer.

APPelit ontwikkelt de mobiele schermen, accounts en backend voor de verwerking van meldingen. Via een koppeling wordt gecontroleerd welke apparaten bij het ingelogde klantaccount horen. Gebruikers kunnen daardoor geen apparatuur van andere organisaties bekijken.

In een afzonderlijke beheeromgeving zien servicemedewerkers de nieuwe meldingen. Zij kunnen een status aanpassen en een interne notitie toevoegen. Alleen de afgesproken status en klantgerichte toelichting worden in de app zichtbaar; interne informatie blijft afgeschermd.

De klant ontvangt een pushbericht wanneer de status verandert. Vanuit de app kan vervolgens de actuele voortgang worden bekeken. De software voorspelt niet zelfstandig wanneer een storing is opgelost, maar toont uitsluitend de status die door een bevoegde medewerker is vastgelegd.

Tijdens de tests worden verschillende situaties gecontroleerd. Denk aan een ontbrekende foto, een ongeldig apparaatnummer, een onderbroken upload of een gebruiker zonder toegang tot het gekozen apparaat. De opdrachtgever controleert daarnaast of de statussen en gebruikersrechten overeenkomen met het eigen serviceproces.

Na de eerste versie kan de app worden uitgebreid met onderhoudsdocumenten, afspraakbevestigingen of digitale ondertekening. Deze mogelijkheden worden als aanvullende functionaliteiten ontwikkeld wanneer de werking ervan is vastgesteld.