Eerste versie van je webapp: kies één ding en maak het af

Bij een nieuwe webapp begint het vaak met een lijst. Inloggen, rollen, rapportages, facturen, een dashboard, notificaties, een mobiele weergave.

Allemaal nuttig. En allemaal samen in versie één is een goede manier om niet te leren wat de app eigenlijk moet doen.

Wat een lange lijst kost

Hoe meer een eerste versie moet, hoe later hij af is en hoe meer er kan breken. Elke functie wil getest, elke functie hangt aan een andere, en elke week uitstel is een week waarin niemand de app gebruikt.

Het pijnlijke is dat je in die maanden bouwen niet leert of het ding klopt. Je gokt. Een lijst die vooraf is bedacht, beschrijft hoe mensen denken dat ze gaan werken. Hoe ze werken, zie je pas als iemand de app gebruikt.

De ene vraag die ik stel

Begin bij één vraag: "Wat is het ene dat deze app moet kunnen, waar hij zonder niet hoeft te bestaan?"

Niet drie dingen. Eén.

Neem een offerte-tool. Het ene is: een offerte invoeren en er een net document uit krijgen. Niet de klantenadministratie, niet de omzetgrafiek, niet de koppeling met de boekhouding. Eén handeling, van begin tot eind, die werkt.

Die ene handeling bouw je eerst. Zodra die werkt, kan hij in gebruik, ook al kan de app verder weinig.

Waar je met die handeling begint, is ook een keuze. Het scherm waar het werk echt gebeurt, is zelden het scherm dat in een demo staat.

Wat wel in versie één hoort

"Eén ding" betekent niet dat alles eromheen wegvalt. Staat er data in die niet van iedereen is, dan is een veilige manier van inloggen geen extra functie maar een voorwaarde. Ook een betrouwbare opslag en een plek waar de app draait horen erbij.

Het verschil zit in wat je erbovenop zet. Een inlogscherm helpt niemand verder met zijn werk. De handeling zelf doet dat wel. Daarom is het ene ding de handeling die waarde oplevert, met alleen het hoogstnodige eromheen om hem veilig te kunnen gebruiken.

Waarom kaal beginnen sneller is

Een app die één ding doet, is eerder in gebruik te nemen dan een app met de hele lijst. Hoe kleiner het eerste stuk, hoe eerder je begint met leren.

Je ziet waar de gebruiker vastloopt. Je hoort welke functie als eerste gemist wordt, en dat hoeft niet de functie te zijn die bovenaan de oorspronkelijke lijst stond. Je bouwt de tweede functie op wat je weet, niet op wat je gokte.

Zo groeit de app in de richting die het gebruik aanwijst. Dat is goedkoper dan alles vooraf bedenken, en meestal ook beter.

Wat er met de rest van de lijst gebeurt

De lijst verdwijnt niet. Hij wordt een volgorde.

Rollen, rapportages, dat dashboard: ze komen, maar pas als de basis draait en als blijkt dat ze echt nodig zijn. Soms valt een deel van de oorspronkelijke lijst weg omdat het in de praktijk niet bleek te kloppen. Dat is geen verlies. Dat is werk dat je niet hoefde te doen.

Wensen zijn geen behoeftes

Wat die volgorde bepaalt is het verschil tussen een wens en een behoefte.

Een wens is iets wat leuk klinkt in een gesprek. Zou het niet mooi zijn als de app ook grafieken liet zien? Een behoefte is iets waar iemand vandaag tegenaan loopt. Stel: Ik typ elke maandag dezelfde planning over uit mijn mail, dat kost me een uur.

De tweede kan meteen de lijst op. De eerste schrijf je op en laat je liggen. Niet omdat hij niet mag, maar omdat je wilt zien of hij terugkomt. Wensen die ertoe doen komen vanzelf weer langs.

De vraag die de twee uit elkaar houdt

Als iemand een functie voorstelt, is een goede vraag: wanneer heb je dat voor het laatst echt nodig gehad, en wat deed je toen?

Bij een behoefte komt er een concreet verhaal. "Vorige week nog, toen moest ik het met de hand in Excel doen." Bij een wens komt er een stilte, of een "nou, niet echt, maar het zou kunnen". Dat onderscheid is vaak genoeg.

Een functie die niemand gebruikt, is bovendien niet gratis. Hij moet ontworpen, gebouwd, getest en onderhouden worden, hij hangt aan andere onderdelen, en als er iets stukgaat is hij een plek waar je moet zoeken. Een functie die later nodig bleek, heeft tenminste een reden om die kosten te dragen.

Wanneer één ding niet genoeg is

Dit werkt niet overal. Vervangt de app een bestaand proces dat in zijn geheel moet overgaan, dan is een app die maar de helft doet onbruikbaar: niemand werkt in twee systemen. Dan kies je een kleiner proces om mee te beginnen, of je bouwt de volledige route voor één type klus en laat de andere nog even in het oude systeem. Is er een wettelijke of contractuele eis, zoals een factuur die aan bepaalde regels moet voldoen, dan hoort die ook in versie één.

Het advies in één zin

Bouw niet de app die alles kan. Bouw het ene dat zonder de app niet kan, zet dat live, en laat de rest volgen op wat je daarna ziet.

Een kale eerste versie die draait is meer waard dan een complete versie die nog niet bestaat.

---

Zie ook: Wanneer een spreadsheet nog steeds beter is dan een app. Een webapp-idee scherp krijgen? Bekijk hoe ik webapps bouw of plan een gesprek.