Så här skapar du en app för musikstreaming: funktioner, arbetsflöde och trender

Börja med en mening som förklarar varför just den lyssnararen skulle välja just din produkt.

“Bättre musikupptäckt” säger inte särskilt mycket.

“En streamingtjänst för underground-etiketter inom elektronisk musik där fans kan följa nya utgåvor, köpa begränsade upplagor och delta i lyssningsrum som drivs av etiketterna” ger teamet en bra utgångspunkt att bygga vidare på.

Den meningen fungerar som ett filter för färdplanen. Sångtexter kan passa in. Samarbetsbaserade spellistor kan passa in. Poddar kanske inte har något med idén att göra. Beslutet utgår från produkten, snarare än från en genomgång av Spotifys funktionslista.

Detta är viktigt eftersom musikappar kan bredda sig väldigt snabbt. En musikspelare utvecklas till spellistor, sociala profiler, meddelandefunktioner, låttexter, rekommendationer, kreatörssidor, biljettförsäljning och tio andra funktioner innan den huvudsakliga lyssningsvanan ens har testats.

En mer avgränsad fråga ger oftast bättre svar snabbare.

Katalogstrategin bör fastställas i ett tidigt skede, eftersom den påverkar nästan alla tekniska nivåer.

Musiken kan komma från skivbolag, direktuppladdningar från artister, distributörer, din egen katalog, inspelningar som tillhör det allmänna eller flera källor samtidigt. Varje modell medför olika regler när det gäller uppspelning, nedladdningar, territorier, kreditering, rapportering och borttagning.

Detta medför också förändringar i backend-systemet.

En låt kan vara tillgänglig i ett land men inte i ett annat. En utgåva kan upphöra att gälla. En prenumerationsnivå kan tillåta lyssnande offline medan en annan inte gör det. Ett skivbolag kan tillåta fullständig uppspelning men begränsa korta utdrag eller redigeringar som användaren själv skapat.

Tillgänglighet är alltså sällan en enkel ja-eller-nej-fråga. Systemet måste ofta kunna avgöra vem som får spela ett spår, var, enligt vilket abonnemang och under vilka rättighetsvillkor.

Det är mycket enklare att utforma dessa regler när de ingår i datamodellen redan från början.

Affärsmodellen bör vara begriplig ur lyssnarens perspektiv.

Ett abonnemang kan ge tillgång till ett utbud, men en nischprodukt kan ta betalt för något mer specifikt: förhandslanseringar, artistgemenskaper, livesessioner, arkivmaterial, stämmor, lektioner, DJ-verktyg, fanmedlemskap eller evenemang.

Vissa produkter kan kombinera flera intäktskällor. En lyssnare kan använda appen gratis, betala för ett medlemskap hos en skapare, köpa en begränsad utgåva och köpa en biljett från samma konto.

Den relevanta frågan här är enkel: vad upplevs som tillräckligt värdefullt för att en användare omedelbart ska förstå priset?

För en stor streamingtjänst är det ofta tillgången till katalogen som utgör värdet. För en mindre tjänst kan det handla om närhet till en viss scen, bättre möjligheter att upptäcka musik inom en genre, sällsynt innehåll eller en direkt relation till artisterna.

Det svaret kommer att påverka produktutformningen, betalningar, behörigheter, analysverktyg och till och med katalogstrukturen.

En MVP bör visa på ett beteende som människor vill upprepa.

Skriv det beteendet som en kort sekvens.

Upptäck artisten → spela upp låten → spara → följ → kom tillbaka för nästa släpp

Eller:

Gå med i rummet → lägg till ett spår → interagera med vänner → följ andra → kom tillbaka till nästa session

Eller:

Starta träningen → välj intensitet → kör ett set → betygsätt träningen → kom tillbaka imorgon

Den här övningen brukar leda till att man snabbare kommer överens om funktionerna än vad som är fallet med ett långt kravdokument.

Om huvudloopen är klar kan du bedöma varje funktion utifrån om den stöder den loopen. Sökfunktionen gör det troligen. Återställning av konto gör det. En fullfjädrad marknadsplats för skapare kanske kommer först långt senare.

För en mer övergripande bild av planering och leverans av appar, se Innowise:s guide till Typer och processer inom utveckling av mobilappar.

En klickbar prototyp räcker för att testa det grundläggande flödet innan teamet bygger det fullständiga mediesystemet.

Lägg fokus på introduktionen, startsidan, sökfunktionen, spelaren, köbeteendet, åtgärder i biblioteket, prenumerationer och den funktion som ger produkten dess identitet.

Spelaren förtjänar extra uppmärksamhet eftersom man hela tiden upprepar samma handlingar.

Vad händer när en användare trycker på ett annat spår? Var hamnar det i kön? Hur fungerar funktionen “spela nästa”? Vad händer när ett album tar slut? Kan lyssnaren återställa kön efter att ha stängt appen?

Dessa val kan verka obetydliga på en Figma-skärm. I det dagliga arbetet blir de till ett automatiskt handlag.

Därför bör användarupplevelsen vid uppspelning betraktas som produktdesign, inte som en dekorativ ram runt en ljudfil.

Det blir oftast lättare att förstå de flesta musikprodukter när backend-delen delas upp i tre övergripande områden.

Medieformat omfattar ljudfiler, kodade versioner, omslagsbilder, nedladdningar och leverans.

Metadata omfattar artister, utgåvor, genrer, medverkande, skivbolag, kompositörer, stämningar, språk, versioner och relationer mellan katalogobjekt.

Användarrättigheterna reglerar vem som får lyssna, var, med vilket abonnemang, hur länge och under vilka villkor.

Musikdata blir förvånansvärt snabbt komplicerade.

En låt kan finnas i form av en albumversion, en radioversion, en remasterad version, en remix, en instrumentalversion, en censurerad version, en liveinspelning, en deluxe-utgåva eller en regional utgåva. Två artister kan ha samma namn. En artist kan byta namn. En utgåva kan försvinna i ett visst område men fortfarande vara tillgänglig överallt annars.

En datamodell som återspeglar dessa samband kommer att bespara en hel del besvärligt uppstädningsarbete senare.

Dåliga metadata gör det svårt att hitta bra musik.

Användarna märker problemen direkt. Dubbla artistsidor skapar förvirring. Felaktiga eller dåligt angivna utgivningsdatum gör att det känns slarvigt att bläddra i katalogen. En remix som är kopplad till fel artist påverkar både sökresultaten och rekommendationerna negativt.

Nischprodukter kräver ofta mer detaljerade metadata än allmänna konsumenttjänster.

En klassisk app kan ta hänsyn till kompositör, verk, sats, dirigent, orkester, solist, epok och inspelningsdatum.

En produkt som är inriktad på DJ:ar kan ta hänsyn till BPM, tonart, skivbolag, mixversion, utgivningsserie och remixrelationer.

En regional tjänst kan behöva transkribering, lokala stavningar, alternativa artistnamn och språkspecifik sökning.

I vissa produkter blir metadatamodellen ett av de viktigaste skälen att använda appen. Den gör det möjligt för användarna att bläddra bland musik på samma sätt som de redan tänker på den.

En musikspelare bör testas i de situationer där lyssnarna faktiskt använder den: i mobilnät, på tåg, i bilar, med svagt Wi-Fi, med Bluetooth-hörlurar, i bakgrundsläge och på enheter med nästan inget ledigt lagringsutrymme.

Gå igenom de komplicerade fallen.

Byt från Wi-Fi till mobilnätet mitt i en låt. Lås telefonen. Ta ett samtal. Koppla bort Bluetooth. Stäng appen. Öppna den igen. Avbryt en nedladdning. Fyll enhetens lagringsutrymme.

Kontrollera sedan vad användaren ser.

Bevaras köen? Fortsätter uppspelningen från rätt ställe? Återställs appen efter ett avbrott i anslutningen? Är felmeddelandet till hjälp? Kan lyssnaren se vilka spår som är tillgängliga offline?

Buffringsregler, lokal cache, förladdning, logik för omförsök, kvalitetsinställningar och nedladdningsbeteende påverkar alla denna upplevelse.

En snygg startskärm betyder inte särskilt mycket om uppspelningen hela tiden avbryts.

En effektiv sökfunktion ger oftast ett nytt musikprodukt större värde än en ambitiös rekommendationsmotor som införs för tidigt.

Användarna ska kunna hitta artister även om de skriver fel. Sökfunktionen ska kunna hantera låtar, album, skivbolag, spellistor, genrer och de katalogobjekt som är viktiga för din målgrupp.

Upptäckten kan börja med enkla men användbara signaler: nya släpp från artister man följer, redaktionella sammanställningar, kopplingar mellan genrer, kopplingar till skivbolag, lyssningshistorik och förslag av typen “mer som detta”.

Mer komplexa rekommendationsmodeller blir mer meningsfulla när produkten har tillräckligt med verkliga beteendemönster att lära sig av.

Och sessionens längd i sig är ett svagt mått på rekommendationernas kvalitet.

Titta på hur ofta lyssnarna hoppar över låtar, sparar dem, spelar om dem, följer artister, döljer dem, söker efter dem och om de återvänder till artister som de upptäckt via appen. Dessa signaler ger dig mycket mer information om huruvida upptäcktsfunktionen faktiskt fungerar.

Ge även användarna viss kontroll. En enkel åtgärd som “gilla inte detta” kan åtgärda en dålig rekommendation snabbare än ytterligare ett lager av rankningslogik.

Musikappar samlar snabbt in undantagsfall, så kvalitetskontrollen bör omfatta mer än bara normal uppspelning.

Se vad som händer när:

• en prenumeration löper ut;
• en nedladdningslicens löper ut;
• en låt försvinner ur katalogen;
• en betalning misslyckas;
• en användare byter land;
• samma konto är aktivt på flera enheter;
• en spellista innehåller musik som inte är tillgänglig;
• en konstnär tar bort en uppladdning;
• en lyssnare har ett mycket stort musikbibliotek;
• nedladdningen avbryts precis innan den är klar.

Sedan tar vi upp ämnet övergrepp.

Falska strömmar kan påverka utbetalningarna. Skrapning kan leda till att katalogdata läcker ut. Spam i uppladdningar kan tränga undan legitim musik. Att utge sig för att vara en artist skapar problem med rättigheter och förtroende. Delning av konton kan snedvrida prenumerationsreglerna.

Om produkten betalar upphovsmännen eller säljer tillgång till licensierat innehåll, ska dessa fall ingå i den första omfattande kvalitetssäkringsplanen.

Den första lanseringen bör riktas till personer som så nära som möjligt motsvarar den ursprungliga produktidén.

En tjänst för oberoende technoskivbolag behöver technolyssnare, DJ:ar, artister och skivbolagsteam i betaversionen.

En produkt för musikundervisning kräver musiker med den färdighetsnivå som upplevelsen är utformad för.

Det blir mycket enklare att testa en fanplattform när ett litet antal innehållsskapare redan har en publik som är villig att följa med dem till en ny plattform.

Observera sedan kärnans beteende.

Hur snabbt når användaren det första spåret? Vad söker de efter? Vad sparas? Vilken funktion får dem att återvända? Var lämnar de tjänsten? Uppstår den huvudsakliga lyssningscykeln naturligt, eller driver produkten användarna mot den?

Den sista frågan är den viktigaste.

Version 1 bör ge dig svar på om idén skapar en verklig vana. När du väl vet det blir det mycket enklare att motivera resten av utvecklingsplanen.