Share
Ik maak deel uit van het team dat onlangs een web-app genaamd Dunked heeft gelanceerd. Dunked is een gratis eenvoudig te gebruiken online portfolio voor creatievelingen. Vanaf mei 2013 zijn we in de publieke bèta; doorgaan met het uitbouwen van functies en het maken van incrementele verbeteringen op basis van gebruikersfeedback.
In dit artikel ga ik enkele van de redenen bespreken die ik van mening ben dat een beta-lancering belangrijk is voor de ontwikkeling van uw product. Ik zal ook bespreken hoe wij, bij Dunked, bezig zijn met het proces van het monitoren en verzamelen van gebruikersfeedback. Ten slotte zal ik bespreken hoe het gaat met het implementeren van wijzigingen op basis van feedback van gebruikers, terwijl we doorgaan met het bouwen van het product.
Persoonlijk ben ik van mening dat het hebben van een beta-lancering een geweldig idee is. Het is natuurlijk niet raadzaam om iets los te laten dat bezaaid zit met bugs. Het is ook een slecht idee om een product uit te brengen dat nog niet klaar is voor openbare consumptie. Het is veel beter om het product uit te brengen als het eenmaal over de noodzakelijke basisfuncties beschikt en geen bugs bevat.
Google is waarschijnlijk een van de bekendere bedrijven die producten aanvankelijk aanbiedt als bètaversie. Gmail is een geweldig voorbeeld. Gmail was in privé-bèta van april 2004 tot februari 2007, toen het beschikbaar werd gemaakt voor het grote publiek. Zelfs toen nog had het het "bèta" -label. Gmail werd officieel nog geen twee jaar uit de bèta gehaald. Door het als bètaproduct te gebruiken, konden Google-technici Gmail blijven verbeteren op basis van gebruikersgegevens en verschillende toevoegingen testen.
Perfect bestaat gewoon niet binnen de ontwikkeling van software
Ik erken dat het lastig kan zijn om gebruikers een product te laten zien voordat je denkt dat het perfect is. Maar perfect bestaat gewoon niet binnen de ontwikkeling van software. Je zult altijd een product moeten herhalen met constante inspanningen om verbeteringen aan te brengen. Ik geloof dat door een bètaversie van een product vrij te geven, je jezelf in een positie plaatst om gebruikers het beste te bieden wat ze willen. Je hebt misschien aannames die gewoon fout zijn. Door in bèta te werken, kunt u snel pivoteren om uw product te verbeteren volgens de behoeften van uw gebruikers.
Bij het nemen van Dunked om te lanceren, voelden we dat het van cruciaal belang was om de verschillen te identificeren en vast te stellen tussen essentiële functies en handige functies. Must-have-functies zijn de functies die uw product vormen en in wezen maken. Must-haves zijn de functies waarop u uw tijd vooraf moet richten. Zodra je je lijst met must-haves hebt voltooid, start je. Na de lancering kunt u de 'leuk-te-dingen' aanpakken, eventuele bugs oplossen die zich voordoen en aanpassingen doorvoeren op basis van gebruikersfeedback.
Terwijl we doorgaan met bouwen, is feedback van gebruikers hetzelfde als goud. Gebruikers vertellen ons wanneer we dingen geweldig doen; wanneer we dingen verkeerd doen; en wanneer we gewoon dom zijn. Omdat gebruikersfeedback zo waardevol is, is het belangrijk dat u een systeem hebt geïnstalleerd voorafgaand aan de lancering, zodat u kunt controleren en feedback kunt verzamelen. Je moet ook een systeem opzetten om te reageren op de feedback die je ontvangt.
Het monitoren en verzamelen van feedback is geen eenvoudige taak. Gebruikers zijn allemaal verschillend, met verschillende voorkeuren in hoe ze hun meningen uiten. Daarom moet u beschikken over een systeem om actief verschillende feedbackkanalen te kunnen volgen. We hebben ervoor gekozen om Desk te gebruiken. Het dient als onze centrale hub voor het verzamelen van alle tweets die zijn gericht op onze @DunkedHQ Twitter-handle, reacties op onze Facebook-pagina en e-mails die zijn verzonden via ons ondersteuningscontactformulier (dit formulier is gelinkt vanuit de app zelf). Hiermee kan ik inloggen op een enkele locatie, waar ik de feedback kan beoordelen en erop kan reageren in de volgorde waarin deze is ingediend. Dit is een win-win voor ons en voor gebruikers. Gebruikers kunnen hun mening geven, maar ze voelen zich het meest op hun gemak, en we kunnen heel eenvoudig alle feedback op één locatie bekijken.
Dat behandelt huidige gebruikers, maar hoe zit het met de mensen die gewoon hun accounts verwijderen zonder feedback te geven. Weet dat accounts worden gesloten en doe je best om informatie te verzamelen van gebruikers die hun accounts sluiten. Bij Dunked leiden we de gebruiker naar een snelle "exit" -enquête zodra ze het verwijderen van het account hebben voltooid. De enquête is volledig optioneel en kan in minder dan vijf minuten worden voltooid. De meeste mensen zijn bereid om het in te vullen, en gaven ons aanvullende feedback over waarom ze hun account hebben verwijderd. We hebben Wufoo gebruikt om aan onze enquête-behoeften te voldoen omdat ze het echt gemakkelijk maken.
Nu we een methode hebben voor het monitoren en verzamelen van feedback, wat moeten we ermee doen? Voor Dunked hebben we een vrij eenvoudige benadering. We gebruiken een takenlijst in Basecamp om de feedback die we verzamelen te huisvesten. Wanneer een gebruiker schrijft met een voorgestelde verbetering of een ontbrekende functie aanvraagt, voegen we deze toe aan onze verlanglijst / suggesties-takenlijst. Deze lijst bevat ook onze eerder genoemde nice-to-have-functies. Niet alle items die aan de lijst worden toegevoegd, zullen aan Dunked worden toegevoegd, maar het helpt ons om de suggesties te volgen. Veel voorkomende functieverzoeken worden genoteerd, naar de top van de lijst verplaatst en zijn vaak opgenomen in onze codesprints, die ik later zal bespreken.
Helaas is het Dunked-platform niet perfect geweest, dus we krijgen af en toe bugrapporten. We handhaven ook een aparte buglijst binnen Basecamp. Elk item dat aan de lijst met fouten is toegevoegd, wordt als een topprioriteit beschouwd en wordt zo snel mogelijk opgelost.
Zoals ik eerder al zei, blijven we kernfuncties voor Dunked uitbouwen, maar we vinden het belangrijk om te reageren op de feedback van vroege gebruikers. Omdat gebruikers ons zo goed hebben geholpen met feedback, willen we hun suggesties implementeren als de tijd het toelaat. Dit doen we door dagelijkse codesprints. Een of twee keer per week zullen we onze lijst met suggesties / feedback bekijken en enkele items kiezen die in een dag coderen kunnen worden voltooid. We voltooien deze items, testen op onze ontwikkelserver en pushen vervolgens naar de productieserver zodra we tevreden zijn met de code.
Om te illustreren hoe gebruikersfeedback Dunked heeft verbeterd, overweeg dan het volgende voorbeeld. Voor afbeeldingsuploads hebben we een eenvoudige klik om te uploaden gemaakt. Door op de knop te klikken, startte de bestandsbrowser op de computer van de gebruiker, waardoor ze naar afbeeldingen voor hun projecten konden bladeren en deze konden uploaden. Het werkte perfect voor ons. Gebruikers hadden echter enkele problemen.
Er zijn twee basisopties voor het verwerken van afbeeldingsuploads: click-to-upload of drag-and-drop om te uploaden. Het blijkt dat we (Team Dunked) elk click-to-upload de voorkeur geven. We hadden niet verwacht dat gebruikers uploads zouden willen slepen en neerzetten. Bij het verzamelen van feedback werd het duidelijk dat er ruimte was voor verbetering in beelduploads. We hebben 'Uploads met slepen en neerzetten' toegevoegd aan onze verlanglijst / suggestieslijst. Na meerdere verzoeken zijn uploads met slepen en neerzetten toegevoegd aan een van onze vroege codesprints. Wanneer u nu afbeeldingen naar een project wilt uploaden, kunt u klikken om te uploaden of slepen en neerzetten.
Dit is een vrij eenvoudig voorbeeld van hoe gebruikers Dunked anders gebruikten dan we hadden verwacht. We hebben nooit overwogen dat gebruikers zouden worden afgeschrikt door onze traditionele methode van beelduploads. Bij het monitoren, verzamelen en reageren op gebruikersfeedback konden we echter de Dunked voor onze gebruikers verbeteren.
Nu ik iets heb uitgelegd over onze aanpak van een bèta-release en waarom ik denk dat bètaversies geweldig zijn, moet ik enkele van de fouten en beperkingen bespreken die een bèta-release zouden kunnen veroorzaken. De grootste fout die je kunt maken in een bètaversie, is door een bètaversie vrij te geven voordat deze beschikbaar is. Als u bugs tegenkomt tijdens uw eigen tests of als u geen uitgebreide tests voor uw toepassing hebt uitgevoerd, komt er geen bedrijf vrij in de bèta. Wanneer u software vrijgeeft waarvan u weet dat deze niet gereed is voor uitgave, riskeert u het vertrouwen van uw gebruikers en de levensduur van uw product. Hoewel de meeste bètagebruikers bereid zijn om kleine bugs te vergeven die in bèta verschijnen, is het onverantwoord om een product vrij te geven waarvan je weet dat het een bugs is.
Wanneer u software vrijgeeft waarvan u weet dat deze niet gereed is voor uitgave, riskeert u het vertrouwen van uw gebruikers en de levensduur van uw product.
De tweede grootste fout die je kunt maken in een beta-release, is om gebruikers te snel binnen te laten. Terwijl u stresstests kunt uitvoeren, weet u niet 100% wat uw server aankan totdat deze onder een echte test is geplaatst. Als de server crasht, wil je dat deze crasht met 1000 bèta-uitnodigingen en geen 10.000 of 100.000 bèta-uitnodigingen uitstaan. Bovendien bevindt u zich in de bètafase, dus het is mogelijk dat u een bug of twee tegenkomt. Met Dunked hadden we bijvoorbeeld een vreemde fout in verband met bepaalde projectslakken. Alles werkte prima met de beheerder, maar de live pagina resulteerde in een 403-fout. Het bleek een heel eenvoudige oplossing. Omdat het probleem te maken had met de URL's, moesten we bestaande URL-slugs corrigeren. Het was zeker gemakkelijker om honderden project- en paginaslakken te doorzoeken en op te ruimen dan het voor honderdduizenden zou zijn geweest.
Een van de grootste beperkingen van een bèta-release heeft betrekking op feedback. Gebruikers bètatoegang verlenen, betekent niet dat ze u feedback zullen geven. Gebruikers kunnen volledig feedback geven, maar hebben simpelweg niet de tijd om hun feedback onder woorden te brengen. Ze kunnen ook het gevoel hebben dat ze iets verkeerd doen, wanneer de applicatie niet werkt zoals verwacht, en dus niet schrijven met feedback. Als u bovendien een bepaald onderdeel in uw toepassing moet herhalen, is de kans groot dat de kwaliteit en kwantiteit van de feedback afnemen.
Ik geloof niet dat het niet verstandig is om elke gewenste functie te gebruiken bij het starten van een product. Ik denk dat het beter is om een "voltooide" bètaversie te lanceren en vervolgens door te gaan met het herhalen van het product door extra functies toe te voegen. Door dit te doen, kunt u gebruikersfeedback verzamelen en gebruiken om uw product te verbeteren.
Als u dat zegt, moet u een plan hebben om na te gaan hoe u de feedback die u verzamelt, zult monitoren, verzamelen en ernaar zult handelen. U kunt dus functies toevoegen die echte waarde creëren voor de gebruiker, waardoor uw kansen op succes worden vergroot.
Accentsconagua