Hoe maak je een app voor het streamen van muziek: functies, werkwijze en trends

Begin met één zin waarin je uitlegt waarom een bepaalde doelgroep voor jouw product zou kiezen.

“Betere muziekontdekking” zegt eigenlijk heel weinig.

“Een streamingdienst voor underground elektronische labels waar fans releases kunnen volgen, gelimiteerde releases kunnen kopen en lid kunnen worden van door de labels georganiseerde luisterruimtes” biedt het team een nuttig uitgangspunt om verder op voort te bouwen.

Die zin fungeert als filter voor de routekaart. Songteksten kunnen erbij passen. Gezamenlijke afspeellijsten kunnen erbij passen. Podcasts hebben misschien helemaal niets met het idee te maken. De beslissing wordt ingegeven door het product zelf, en niet door een rondleiding langs de lijst met functies van Spotify.

Dit is belangrijk omdat muziekapps heel snel in de breedte kunnen uitgroeien. Een muziekspeler verandert al snel in afspeellijsten, sociale profielen, berichtenfuncties, songteksten, aanbevelingen, pagina’s van artiesten, ticketverkoop en nog tien andere functies, nog voordat het eigenlijke luistergedrag überhaupt is getest.

Een nauwkeuriger product levert doorgaans sneller betere antwoorden op.

De catalogusstrategie moet in een vroeg stadium worden vastgesteld, omdat deze van invloed is op vrijwel elke technische laag.

De muziek kan afkomstig zijn van platenlabels, rechtstreekse uploads door artiesten, distributeurs, je eigen catalogus, opnames in het publieke domein of meerdere bronnen tegelijk. Elk model kent andere regels met betrekking tot het afspelen, downloads, regio’s, vermeldingen, rapportage en verwijderingsverzoeken.

Hierdoor verandert ook de backend.

Een nummer kan in het ene land beschikbaar zijn, maar in een ander land niet. Een uitgave kan verlopen. Bij het ene abonnementsniveau is offline luisteren mogelijk, bij het andere niet. Een platenlabel kan het volledig afspelen toestaan, maar het gebruik van fragmenten of door gebruikers gemaakte bewerkingen beperken.

Beschikbaarheid is dus zelden een eenvoudig ja-of-nee-veld. Het systeem moet vaak weten wie een nummer mag afspelen, waar, onder welk abonnement en onder welke rechtenvoorwaarden.

Die regels zijn veel eenvoudiger op te stellen als ze vanaf het begin deel uitmaken van het gegevensmodel.

Het bedrijfsmodel moet vanuit het perspectief van de luisteraar logisch zijn.

Met een abonnement kan toegang tot een catalogus worden verkocht, maar bij een nicheproduct kan er geld worden gevraagd voor iets specifiekers: vroege releases, artiestengemeenschappen, livesessies, archiefmateriaal, stems, lessen, DJ-tools, fanlidmaatschappen of evenementen.

Sommige producten kunnen meerdere inkomstenbronnen combineren. Een luisteraar kan de app gratis gebruiken, een lidmaatschap voor makers betalen, een gelimiteerde uitgave kopen en via hetzelfde account een ticket aanschaffen.

De relevante vraag is hier simpel: wat voelt zo waardevol aan dat een gebruiker de prijs meteen begrijpt?

Voor een grote streamingdienst is die meerwaarde vaak de toegang tot de catalogus. Voor een kleiner product kan het gaan om de band met een bepaalde scene, betere ontdekkingsmogelijkheden binnen een genre, zeldzame content of een directe band met artiesten.

Dat antwoord zal van invloed zijn op het productontwerp, de betalingen, de machtigingen, de analysegegevens en zelfs de structuur van de catalogus.

Een MVP moet aantonen dat mensen een bepaald gedrag willen herhalen.

Schrijf dat gedrag als een korte reeks.

Ontdek artiest → nummer afspelen → opslaan → volgen → terugkomen voor de volgende release

Of:

Ga naar de chatroom → voeg een nummer toe → reageer samen met vrienden → volg mensen → kom terug voor de volgende sessie

Of:

Begin met trainen → kies de intensiteit → speel de set af → beoordeel de fit → kom morgen terug

Deze oefening zorgt er meestal voor dat men het sneller eens wordt over de functies dan bij een uitgebreid eisenoverzicht.

Als de hoofdlus duidelijk is, kun je elke functie beoordelen op basis van de vraag of deze die lus ondersteunt. Zoeken doet dat waarschijnlijk wel. Accountherstel ook. Een volledige marktplaats voor makers komt wellicht pas veel later aan bod.

Voor een breder overzicht van de planning en levering van apps, zie de gids van Innowise over Soorten en processen bij de ontwikkeling van mobiele apps.

Een klikbaar prototype volstaat om de basisworkflow te testen voordat het team het volledige mediasysteem bouwt.

Richt je op de onboarding, de startpagina, de zoekfunctie, de speler, het gedrag in de wachtrij, acties in de bibliotheek, abonnementen en de functie die het product zijn identiteit geeft.

De speler verdient extra aandacht omdat mensen voortdurend dezelfde handelingen herhalen.

Wat gebeurt er als een gebruiker op een ander nummer tikt? Waar komt dat nummer in de wachtrij terecht? Hoe werkt de functie “volgende afspelen”? Wat gebeurt er als een album ten einde loopt? Kan de luisteraar de wachtrij weer ophalen nadat hij de app heeft gesloten?

Op een Figma-scherm lijken deze keuzes misschien onbeduidend. In het dagelijks gebruik worden ze een soort tweede natuur.

Daarom moet de gebruikerservaring bij het afspelen worden beschouwd als productontwerp, en niet als een decoratief scherm rondom een audiobestand.

De meeste muziekproducten worden overzichtelijker als de backend in drie brede gebieden wordt onderverdeeld.

Onder ‘Media’ vallen audiobestanden, gecodeerde versies, albumhoezen, downloads en levering.

Metadata omvatten artiesten, uitgaven, genres, credits, platenlabels, componisten, sferen, talen, versies en relaties tussen catalogusentiteiten.

In de gebruiksvoorwaarden wordt vastgelegd wie er mag luisteren, waar, met welk abonnement, hoe lang en onder welke voorwaarden.

Muziekgegevens worden verrassend snel ingewikkeld.

Een nummer kan bestaan als albumversie, radio-edit, remaster, remix, instrumentale versie, schone versie, live-opname, deluxe-heruitgave of regionale uitgave. Twee artiesten kunnen dezelfde naam hebben. Een artiest kan van naam veranderen. Een uitgave kan in het ene gebied verdwijnen en elders gewoon beschikbaar blijven.

Een datamodel dat deze relaties weergeeft, bespaart je later een hoop moeizaam opschoonwerk.

Door slechte metagegevens is het moeilijk om goede muziek te vinden.

Gebruikers merken problemen meteen op. Dubbele artiestenpagina’s zorgen voor verwarring. Onjuiste of slecht opgebouwde releasedata zorgen ervoor dat het doorbladeren van de catalogus slordig overkomt. Een remix die aan de verkeerde artiest is gekoppeld, schaadt zowel de zoekresultaten als de aanbevelingen.

Nicheproducten vereisen vaak gedetailleerdere metadata dan algemene consumentendiensten.

Een klassieke app kan informatie bevatten over de componist, het werk, het deel, de dirigent, het orkest, de solist, de periode en de opnamedatum.

Een product dat speciaal voor dj’s is bedoeld, kan rekening houden met BPM, toonsoort, label, mixversie, uitgaveserie en remixrelaties.

Een regionale dienst kan behoefte hebben aan transliteratie, lokale spellingen, alternatieve artiestennamen en taalspecifieke zoekfuncties.

Bij sommige producten is het metadatamodel een van de belangrijkste redenen om de app te gebruiken. Het stelt mensen in staat om muziek te doorzoeken op de manier waarop ze er zelf al over denken.

Een muziekspeler moet worden getest op de plekken waar luisteraars hem daadwerkelijk gebruiken: mobiele netwerken, treinen, auto’s, zwakke wifi-verbindingen, Bluetooth-hoofdtelefoons, de achtergrondmodus en apparaten met bijna geen vrije opslagruimte.

Neem de ingewikkelde zaken eens door.

Schakel halverwege een nummer over van wifi naar mobiel internet. Vergrendel de telefoon. Neem een telefoontje aan. Verbreek de Bluetooth-verbinding. Sluit de app af. Open de app opnieuw. Onderbreek een download. Vul de opslagruimte van het apparaat.

Controleer vervolgens wat de gebruiker te zien krijgt.

Blijft de afspeellijst behouden? Wordt het afspelen op de juiste plek hervat? Herstelt de app zich na een verbindingsoverbreking? Is de foutmelding nuttig? Kan de luisteraar zien welke nummers offline beschikbaar zijn?

Bufferregels, lokale cache, vooraf laden, herhalingslogica, kwaliteitsinstellingen en downloadgedrag bepalen allemaal deze ervaring.

Een mooi startscherm heeft weinig betekenis als het afspelen steeds hapert.

Een krachtige zoekfunctie voegt doorgaans meer waarde toe aan een nieuw muziekproduct dan een ambitieuze aanbevelingsengine die te vroeg is geïmplementeerd.

Gebruikers moeten artiesten kunnen vinden, ook al zijn er typefouten. De zoekfunctie moet nummers, albums, platenlabels, afspeellijsten, genres en de cataloguselementen herkennen die voor uw publiek van belang zijn.

Ontdekkingen kunnen beginnen met eenvoudige maar nuttige signalen: recente releases van artiesten die je volgt, door de redactie samengestelde verzamelingen, genreverbanden, labelrelaties, je luistergeschiedenis en suggesties van het type “meer zoals dit”.

Complexere aanbevelingsmodellen zijn pas echt zinvol als er voldoende gegevens over het daadwerkelijke gedrag van het product beschikbaar zijn om van te leren.

En de duur van een sessie op zich is een zwakke maatstaf voor de kwaliteit van een aanbeveling.

Kijk naar het aantal keer dat nummers worden overgeslagen, opgeslagen, opnieuw afgespeeld, gevolgd, verborgen of gezocht, en of luisteraars terugkeren naar artiesten die ze via de app hebben ontdekt. Deze signalen geven je veel meer inzicht in de vraag of het ontdekkingsproces daadwerkelijk werkt.

Geef gebruikers ook wat zeggenschap. Een simpele actie als “minder van dit soort” kan een slechte aanbeveling sneller verhelpen dan nog een extra laag rangschikkingslogica.

Muziekapps verzamelen al snel uitzonderlijke gevallen, dus bij de kwaliteitscontrole moet meer worden getest dan alleen het normale afspelen.

Kijk eens wat er gebeurt als:

• een abonnement verloopt;
• een downloadlicentie verloopt;
• een nummer verdwijnt uit de catalogus;
• een betaling mislukt;
• een gebruiker van land verandert;
• hetzelfde account is op meerdere apparaten actief;
• een afspeellijst bevat muziek die niet beschikbaar is;
• een kunstenaar verwijdert een upload;
• een luisteraar heeft een zeer uitgebreide muziekcollectie;
• een download stopt net voordat deze is voltooid.

Behandel vervolgens het onderwerp misbruik.

Nepstreams kunnen van invloed zijn op de uitbetalingen. Door scraping kunnen catalogusgegevens openbaar worden gemaakt. Spamuploads kunnen legitieme muziek naar de achtergrond verdringen. Het zich voordoen als een artiest leidt tot problemen op het gebied van rechten en vertrouwen. Het delen van accounts kan de abonnementsregels verstoren.

Als het product makers betaalt of toegang tot gelicentieerde inhoud verkoopt, horen deze gevallen thuis in het eerste serieuze kwaliteitsborgingsplan.

De eerste release moet worden aangeboden aan mensen die zo goed mogelijk aansluiten bij het oorspronkelijke productconcept.

Een dienst voor onafhankelijke technolabels heeft in de bètafase techno-luisteraars, dj’s, artiesten en labelteams nodig.

Voor een product om muziek te leren zijn muzikanten nodig die het vaardigheidsniveau hebben waarop de ervaring is afgestemd.

Een fanplatform is veel gemakkelijker te testen als een klein aantal makers al een publiek heeft dat bereid is hen naar een nieuwe plek te volgen.

Let dan op het gedrag van de kern.

Hoe snel komt iemand bij het eerste nummer terecht? Waar zoeken ze naar? Wat wordt er opgeslagen? Welke functie zorgt ervoor dat ze terugkomen? Waar stappen ze uit? Ontstaat de hoofdluisterlus vanzelf, of stuurt het product gebruikers er steeds weer naartoe?

Die laatste vraag is het belangrijkst.

Versie één moet je laten zien of het idee daadwerkelijk tot een gewoonte leidt. Als je dat eenmaal weet, wordt de rest van het stappenplan veel gemakkelijker te onderbouwen.