Wat ik onderschatte bij het bouwen van KAVYLO

Een fitness-app bouwen is veel meer dan code schrijven

Toen ik KAVYLO begon te bouwen, wist ik dat het ontwikkelen van een fitness-app tijd zou kosten.

Wat ik onderschatte, was hoeveel van die tijd maar indirect te maken zou hebben met het programmeren van de daadwerkelijke functie.

Een nieuwe functie begint soms met een relatief eenvoudig idee: trainingsplannen toevoegen, workouttracking verbeteren, het Coach-gedeelte uitbreiden of verschillende onderdelen van de app beter met elkaar verbinden.

Maar tussen dat idee en een functie die echt af voelt, zit veel werk.

Daarbij horen de interface, de data erachter, testen, uitzonderingssituaties, vertalingen, navigatie, toegankelijkheid, App Store-vereisten, websitecontent en alles wat ook na de release moet blijven werken.

Dat is waarschijnlijk een van de grootste lessen die ik tijdens het bouwen van KAVYLO heb geleerd.

Elke nieuwe functie zorgt voor werk rondom die functie

Het is makkelijk om een nieuwe functie te zien als één scherm of één losse mogelijkheid.

In de praktijk heeft bijna elke uitbreiding invloed op meerdere delen van het product.

Een nieuwe trainingsfunctie kan bijvoorbeeld ook vragen om:

• aanpassingen aan de navigatie
• nieuwe datastructuren
• extra instellingen
• nieuwe lege en foutstatussen
• testen in verschillende situaties
• updates op de website
• vertalingen
• supportcontent
• nieuwe analyse- of voortgangsweergaven
• aanpassingen aan andere gekoppelde functies

De zichtbare functie is vaak maar een klein deel van het totale werk.

Dat werd vooral duidelijk toen KAVYLO uitgroeide van een eenvoudige workouttracker tot een uitgebreidere fitness-app.

Training, Nutrition, Recovery, voortgang, Apple Health, Apple Watch, coaching, Community en andere onderdelen moeten samen als één product functioneren.

Meer over de volledige structuur vind je op de KAVYLO featurepagina.

Een groeiende fitness-app overzichtelijk houden is moeilijk

Iets anders wat ik onderschatte, is hoe moeilijk het wordt om meer functionaliteit toe te voegen zonder dat een app tegelijkertijd ingewikkelder aanvoelt.

Nieuwe functies bouwen is relatief eenvoudig.

De moeilijkere vraag is waar die functies binnen het product thuishoren.

Naarmate KAVYLO groter werd, werd de informatiearchitectuur daarom steeds belangrijker.

Niet elke functie hoeft dezelfde visuele prioriteit te hebben.

Niet alles hoeft direct op het eerste scherm zichtbaar te zijn.

Een app kan veel functies hebben en toch eenvoudig aanvoelen, maar alleen als de structuur logisch blijft.

Daarom stel ik mezelf bij nieuwe onderdelen steeds vaker vragen zoals:

• Wat moet iemand als eerste zien?
• Welke functies horen bij elkaar?
• Wat kan beter op een dieperliggende pagina staan?
• Welke informatie is op dit moment relevant?
• Welke informatie kan wachten totdat iemand er bewust naar zoekt?

Ik heb geleerd dat een product eenvoudiger maken niet automatisch betekent dat je functies moet verwijderen.

Soms betekent het vooral dat je de juiste functie op het juiste moment laat zien.

Trainingsplannen zijn daar een goed voorbeeld van

Trainingsplannen klinken in eerste instantie als een duidelijk afgebakende functie.

Maar zodra een trainingsplan echt nuttig in een fitness-app moet worden geïntegreerd, ontstaan er veel verbindingen met andere onderdelen.

Er zijn de plannen zelf, oefeningen, trainingsgeschiedenis, aankomende sessies, verschillende sporten, voortgang en de vraag hoe al die informatie samenkomt.

Daarom wil ik trainingsplannen in KAVYLO niet behandelen als alleen een losse lijst met workouts.

De planning moet verbonden zijn met de trainingen die daadwerkelijk worden uitgevoerd en met de bredere fitnesscontext daaromheen.

Meer hierover lees je op de pagina Trainingsplan-app met KAVYLO.

Het onzichtbare werk kost verrassend veel tijd

Sommige taken die het meeste tijd kosten, zijn dingen die gebruikers waarschijnlijk nooit bewust opmerken.

Een knop moet correct reageren.

Een pagina mag niet kapotgaan op een kleiner scherm.

Een vertaalde zin moet voldoende ruimte krijgen.

Een laadstatus moet duidelijk zijn.

Een leeg scherm moet uitleggen wat iemand vervolgens kan doen.

Een gebruiker moet begrijpen waar die zich bevindt zonder over de navigatie na te hoeven denken.

Geen van deze dingen lijkt op zichzelf bijzonder spectaculair.

Samen bepalen ze wel of een app doordacht of onaf voelt.

Ik heb onderschat hoeveel tijd juist dit soort werk kost.

Lokalisatie is meer dan tekst vertalen

KAVYLO is inmiddels beschikbaar in meerdere talen.

Op het eerste gezicht klinkt lokalisatie vrij eenvoudig: teksten vertalen en een taalkeuze toevoegen.

In de praktijk heeft het invloed op veel meer onderdelen van een product.

Teksten hebben verschillende lengtes.

Navigatielabels veranderen.

SEO-pagina's hebben hun eigen titels, beschrijvingen en URL's nodig.

Blogartikelen hebben aparte taalversies nodig.

Sommige termen moeten worden vertaald, terwijl andere bewust onderdeel blijven van de producttaal.

En elke taal moet consistent blijven terwijl KAVYLO verder verandert.

Het werk stopt dus niet zodra de eerste vertaling klaar is.

Elke toekomstige functie moet opnieuw in dat systeem passen.

Ook hier bleek de langdurige inspanning veel groter dan ik in het begin verwachtte.

Een gepubliceerde app is niet af

Voordat ik KAVYLO bouwde, was het makkelijk om een release in de App Store als een soort finishlijn te zien.

Dat is het niet.

Na de publicatie begint er een ander soort werk.

Echte gebruikers gebruiken de app anders dan ik tijdens het ontwikkelen doe.

Zij zien dingen die ik zelf op een gegeven moment niet meer opmerk, omdat ik hetzelfde scherm al honderden keren heb bekeken.

Een functie die voor mij vanzelfsprekend voelt, hoeft voor iemand die KAVYLO voor het eerst opent helemaal niet vanzelfsprekend te zijn.

Die feedback is belangrijk, omdat ze verandert hoe ik over het product nadenk.

Het gaat er niet om dat ik op elke losse opmerking direct reageer met een wijziging.

Belangrijker is de vraag wat de feedback zegt over de onderliggende gebruikerservaring.

Gebruikersfeedback veranderde hoe ik naar complexiteit kijk

Een belangrijke les was dat een product met veel functies snel overweldigend kan aanvoelen.

KAVYLO brengt bewust meerdere fitnessgebieden samen.

Ik wil dat probleem daarom niet simpelweg oplossen door nuttige functies te verwijderen.

In plaats daarvan let ik steeds meer op zichtbare complexiteit.

De vraag is niet meer alleen:

“Wat kan KAVYLO nog meer?”

Maar ook:

“Hoe kan KAVYLO meer doen zonder dat de gebruiker over meer hoeft na te denken?”

Dat beïnvloedt Training, Today, Nutrition, Progress, Community en de manier waarop nieuwe functies worden geïntroduceerd.

KAVYLO alleen bouwen verandert hoe ik prioriteiten stel

Ik bouw KAVYLO zelfstandig.

Dat geeft me veel vrijheid, omdat ik productbeslissingen snel kan nemen en een duidelijke visie kan behouden op waar KAVYLO naartoe moet.

Tegelijkertijd concurreren daardoor alle onderdelen om dezelfde beperkte tijd.

Development, design, testen, content, vertalingen, support, de website, App Store-werk en toekomstige planning moeten voortdurend tegen elkaar worden afgewogen.

Niet elk goed idee kan direct worden gebouwd.

Leren wat ik bewust nog niet bouw, is daarom net zo belangrijk geworden als beslissen wat als volgende komt.

Meer over hoe ik KAVYLO combineer met de rest van mijn dagelijks leven lees je in Hoe ik KAVYLO bouw naast een fulltime baan, mijn studie en dagelijks leven.

Een werkende functie is niet automatisch een afgewerkte functie

Dit is waarschijnlijk een van de belangrijkste verschillen die ik heb geleerd.

Een functie kan technisch werken en toch nog niet klaar zijn.

Misschien is de tekst niet duidelijk genoeg.

Misschien klopt de visuele hiërarchie nog niet.

Misschien bevat het scherm te veel informatie.

Misschien is de lege status verwarrend.

Of de functie werkt op mijn eigen apparaat perfect, maar gedraagt zich in een andere situatie anders.

De eerste werkende versie is daarom vaak pas het begin.

De verfijning daarna verandert functionaliteit uiteindelijk in een echte productervaring.

Ik onderschatte hoe sterk alles met elkaar verbonden zou raken

Hoe groter KAVYLO wordt, hoe minder functies echt volledig op zichzelf staan.

Training is verbonden met Progress.

Training is verbonden met Recovery.

Nutrition geeft extra context.

Apple Health en Apple Watch leveren gegevens.

Coaching kan informatie uit meerdere onderdelen samenbrengen.

Een verandering op één plek kan daardoor beïnvloeden hoe een ander onderdeel zou moeten werken.

Die verbondenheid is een van de dingen die ik het interessantst vind aan het bouwen van KAVYLO.

Tegelijkertijd zorgt ze achter de schermen voor extra complexiteit.

De uitdaging is om die complexiteit nuttig te maken zonder ze bij de gebruiker neer te leggen.

Wat ik vandaag anders zou aanpakken

Als ik opnieuw zou beginnen met wat ik nu weet, zou ik eerder nadenken over systemen.

Niet alleen over afzonderlijke functies, maar over de structuren die toekomstige functies moeten ondersteunen.

Daarbij horen:

• herbruikbare componenten
• schaalbare contentstructuren
• meertaligheid vanaf het begin
• een duidelijkere informatiearchitectuur
• herbruikbare adminfuncties
• consistente datamodellen
• minder losse eenmalige oplossingen

Een aantal van deze lessen verandert nu al de manier waarop ik KAVYLO verder bouw.

Onderdelen van de website waarvoor vroeger bijvoorbeeld aparte codewijzigingen nodig waren, werken nu via herbruikbare systemen.

Daardoor kan ik nieuwe content sneller toevoegen en hoef ik hetzelfde technische probleem niet telkens opnieuw op te lossen.

Wat ik heb geleerd van het bouwen van KAVYLO

Het bouwen van KAVYLO heeft mijn kijk op software sterk veranderd.

Het zichtbare product is alleen het oppervlak.

Achter elk scherm zitten veel kleine beslissingen over structuur, duidelijkheid, betrouwbaarheid en wat er daarna moet gebeuren.

Ik heb nog steeds een lange lijst met dingen die ik wil verbeteren of bouwen.

Tegelijkertijd denk ik inmiddels veel bewuster na over hoe nieuwe functies onderdeel worden van KAVYLO.

Het doel is niet om de fitness-app met de meeste functies te bouwen.

Het doel is een fitness-app waarin training, voeding, recovery, voortgang en de bijbehorende data zo samenwerken dat ze in het dagelijks gebruik echt nuttig zijn.

En precies dat blijkt veel complexer, maar ook veel interessanter, dan ik aan het begin had verwacht.