Wanneer je een goed idee hebt voor een webapplicatie of een
mobiele app, wil je het misschien wel van de daken af schreeuwen. Of houd je
jouw plan liever nog even geheim? Hoe dan ook. Het is verstandig om jouw idee
op papier te zetten. Het helpt je om je gedachten te ordenen en maakt je idee
overdraagbaar. Hoe pak je dat aan?
Je kunt altijd een van onze specialisten om hulp vragen, maar het is eigenlijk best eenvoudig en bovendien leuk om te doen. In dit artikel nemen we je stap voor stap mee door het correct omschrijven van jouw idee.
Stap 1 – De doelstelling
Het lijkt misschien een open deur, maar begin jouw plan met het omschrijven van de doelstelling. Wil je geld verdienen met je app, een hogere klanttevredenheid of heb je misschien een idee om je kosten te drukken?
Beschrijf wanneer je tevreden bent met het resultaat van jouw app of webapplicatie. Zo kunnen leveranciers, investeerders of je collega's zich achter jouw plan scharen. Een goede doelstelling is SMART geformuleerd, ofwel specifiek, meetbaar, acceptabel, realistisch en tijdsgebonden.
Stel je wil een app bouwen waarmee je alle inspectieformulieren, die je nu op papier schrijft, via een tablet app gaat invullen. De doelstelling zou luiden; Onze afdeling werkt binnen 2 jaar uitsluitend digitaal zodat we 20% meer werk kunnen verzetten met dezelfde mensen.
Stap 2 – Het ontwerp
Het is belangrijk dat het ontwerp van jouw concept aansluit bij jouw voorkeuren én die van je doelgroep. Je gebruikt vast dagelijks apps of webapplicaties die je aanspreken. Het is dan ook verstandig om voorbeelden te verzamelen. Maak een lijstje van de ontwerpen die je aanspreken en probeer te duiden waarom. Is het de kleur, de interactie, of misschien juist het lettertype? Deze lijst zal je later enorm helpen om een ontwerp te (laten) maken.
Heb je een gebrek aan inspiratie? Er zijn diverse websites die de meest prachtige ontwerpen delen. Kijk bijvoorbeeld eens hier, hier, of hier.
Stap 3 – De gebruikers
Om jouw idee goed te beschrijven is het noodzakelijk om de gebruikersgroepen te bepalen. Dit zijn alle mensen die jouw applicatie gaan gebruiken. In de volgende stappen kijken we door hun ogen naar jouw idee. Vergeet vooral ook jezelf niet als beheerder. Deze hebben vaak afwijkende verantwoordelijkheden en functies. Wil je zeker weten dat je niemand vergeet, benader het dan eens andersom. Heb je alle gebruikers beschreven die:
Informatie invoeren;
Informatie raadplegen;
Informatie in de vorm van een rapportage of dashboard verwachten;
Het systeem onderhouden.
Stap 4 - De customer journey(s)
Laat je niet afschrikken door de titel van dit stukje. Een customer journey, of klantreis in het Nederlands, is een abstracte beschrijving van wat een gebruiker in de applicatie doet. Je begint door één soort gebruiker centraal te stellen. Vraag je af hoe deze begint met het gebruik. Ga zo ver terug als je kan bedenken. Bijvoorbeeld bij het inloggen of het registreren voor de applicatie.
Een klantreis is eigenlijk een proces van A tot Z. We raden je daarom aan om lekker te tekenen. Je begint links bij de allereerste stap en eindigt rechts wanneer de gebruiker klaar is. Door het visueel te maken wordt het eenvoudiger om de tussenliggende stappen te overzien. Bespreek je klantreis vooral met je doelgroep. Zij hebben vast creatieve ideeën voor stappen die je zou kunnen vergeten.
Stap 5 – Functionaliteiten
Als de customer journey's de grote brokken vormen van jouw applicatie, dan zijn de functionaliteiten de details. Eigenlijk is het zo dat je per gebruiker tenminste één klantreis maakt, waarbij je vervolgens de functionaliteiten omschrijft.
Zo ontstaat de volgende structuur:
Jouw applicatie > Type gebruiker > Klantreis > Functionaliteiten
Je kunt op deze manier zoveel detail aanbrengen als je zou willen. Denk er aan om per stap in je klantreis de schermen te benoemen die je graag zou willen bouwen. Nog een stapje verder gaan? Benoem ook de velden die ingevuld moeten worden, of die kunnen worden geraadpleegd.
Een goede omschrijving van een functionaliteit in jouw applicatie schrijf je zo: Als een [type gebruiker], wil ik [omschrijf de actie] zodat [omschrijf de reden]. Dat klinkt nog een beetje vaag, dus ik geef een voorbeeld. Als beheerder - wil ik nieuwe gebruikers aanmaken - zodat zij zich met hun e-mail kunnen registreren. Of, Als bezoeker - wil ik een formulier invullen - om mij te registreren.
Stap 6 – Clusteren en rangschikken
Niet zo lang geleden werkten veel bedrijven nog op basis van een volledig uitgeschreven functioneel ontwerp. Tegenwoordig is dat bij veel ICT-bedrijven anders. Net als bij MSML wordt Agile gewerkt. Je kan gedurende dat proces nog functionaliteiten aanpassen, zonder dat het direct invloed heeft op je budget.
Vroeger spraken we in projecten wel over 'must-haves' en 'nice-to-haves'. Door Agile te werken is dat niet meer nodig. Je maakt daarentegen een prioriteitenlijst van alle functionaliteiten die je hebt beschreven. Je zet de belangrijkste bovenaan, en de minst belangrijke onderaan. Vervolgens ben je zelf aan zet om te bepalen wat er minimaal in de applicatie moet zitten om succesvol te zijn. Als je de prioriteiten goed hebt gezet, dan kun je een denkbeeldige lijn zetten. Wij noemen dat een Minimal Viable Product. Alles wat onder deze lijn staat is niet kritisch voor het succes en kun je later introduceren. Dit is bovendien een uitstekende methode om:
Kleinschalig te beginnen;
Een korte time-to-market te bereiken;
Je kosten over een langere termijn te verdelen.
Met deze zes stappen schrijf je in no-time een plan van professioneel niveau. Heb je wat hulp nodig of wil je van gedachten wisselen over jouw idee? Chat direct met een medewerker. Liever nog even verder lezen?