One Shoe logo

Creative & Digital Agency

UX Define fase: op naar de eerste MVP!

De Discovery fase is de eerste fase in een ontwikkeltraject. Nadat je informatie hebt opgehaald en inzichten hebt opgedaan (hebt verbreed) is van belang om zaken te concretiseren in de 'Define' stap.

Lex Laureijssen | 06 jul 2020

UX discovery define kostenraming backlog requirements MVP

Eerder hebben we al besproken waarom de Discovery fase zo belangrijk is en welke methodes we inzetten om te verbreden en de kaders van het project te bepalen in de Discover stap: desk-research, user needs, business goals en customer journeys. Na de eerste Discover stap wordt het allemaal concreter.

  • Program of requirements & user stories

Je hebt als het goed is in de Discover stap duidelijk in kaart gebracht wat de oplossing allemaal moet kunnen doen om in alle scenario's te voorzien. Nu gaan we meer denken richting realisatie. Maar daarvoor moet je wel alles op een rijtje zetten. Dit “rijtje” noemen we een program of requirements of backlog.

Een program of requirements is een beschrijvend document waar alle functionaliteiten van een oplossing beschreven worden op detail niveau. Dit gaat met behulp van user stories. Een user story vertaalt vaak een specifiek element van een oplossing door middel van een functionele beschrijving vanuit een gebruiker.

Voorbeeld van een user story

“Als gebruiker wil ik me kunnen inschrijven op een nieuwsbrief van de reisorganisatie zodat ik weet wanneer er een leuke aanbieding voor me is”

Nu kunnen mensen zich natuurlijk ook om andere redenen inschrijven, daar gaat het niet persé om. Het gaat erom dat we geen zaken willen realiseren waarvan we eigenlijk niet weten waarvoor ze dienen. En elke keuze moet dus een soort van validatie of uitleg hebben, één enkele goede reden is echter wel genoeg. 

Nu kunnen we gaan beschrijven wat er precies nodig is om deze functie te kunnen realiseren. Vanuit de UX-er (die bekijkt de gebruikerszijde), vanuit de developers (front-end en back-end) en vanuit de organisaties (bijvoorbeeld content of externe koppelingen).

Je hebt voor een inschrijving op een nieuwsbrief bijvoorbeeld de volgende zaken nodig.

Voor de gebruikers (via de UX-er):

  • Invulveld voor e-mailadres
  • Verzend button
  • Melding bij foutief e-mailadres
  • Text of bericht die de gebruiker aanspoort om dit te doen
  • Help text in het invoerveld
  • Melding als aanvraag verstuurd is
  • E-mail in je inbox ter bevestiging (dit kan ook al een nieuwe story zijn, maar er is wel een koppeling met dit verhaal)

Voor de developers:

  • Opslaan van e-mailadressen
  • Afvangen van misbruik van deze mogelijkheid (bots, etc)
  • Frontend realisatie van alle individuele elementen benoemd bij gebruiker (behalve de nieuwsbrief zelf, dat is een andere story, deze gaat puur over de inschrijving)
  • Versturen van een bevestiging e-mail

Voor de organisaties:

  • Een privacy statement realiseren die dekt wat de organisatie doet met je data (AVG)
  • Copywriting voor dit stuk van de oplossing
  • Licentie bij een externe partij

Dit klinkt misschien wat omslachtig, maar daar zijn goede redenen voor:

  1. Je vergeet niks, nawerk is vaak duurder en vervelender dan goede directe realisatie
  2. Je kan hier ook duidelijker van zeggen hoeveel tijd en dus geld het gaat kosten. Wat belangrijk is voor de volgende stappen.
  • Kostenraming en doorlooptijd

We hebben alle gewenste functionaliteiten en voorwaarden gedocumenteerd in een program of requirements. Nu is het tijd dat developers en designers gaan kijken wat dat voor hen betekent. 

Door heel specifiek de oplossing te beschrijven op feature niveau (user stories) kunnen developers en designers duidelijker terugkoppelen hoe lang ze denken met elk onderdeel bezig te zijn, of hoe complex zaken zijn om te ontwikkelen. Zo wordt het dus uiteindelijk een grote optelsom van alle losse onderdelen van je oplossing. Uiteindelijke doel is altijd het zo goed mogelijk inzichtelijk maken voor alle partijen wat we gaan doen. En dus ook hoe lang we denken nodig te hebben om dit te kunnen realiseren. Op basis van dit overzicht komt er dus ook een kostenplaatje uit, want…

  • Minimal Viable Product (MVP):

Vaak is er dan nog een laatste stap die we moeten nemen - of de organisatie moet carte blanche geven op alles wat we willen gaan doen. Namelijk de optelsom van de requirements aan de realiteit toetsen: 

- Hoeveel kost het in het totaal? (Schatting op basis van alle requirements).
- Hoeveel budget en tijd is er werkelijk? (Staat vaak al deels vast, maar tijd is vaak rekbaarder dan budget) 
- Matched dit allemaal wel met elkaar?

Voorbeeld van wensen vs. budget:

Stel: de ontwikkeling van de digitale oplossing wordt geschat op totaal 100.000 euro. De organisatie heeft echter maar 80.000 euro. Je hebt dus een concreet probleem wat je moet oplossen. We gaan dan denken vanuit een MVP. Wat heb je minimaal nodig om zoveel mogelijk essentiële zaken te realiseren? En welke elementen zijn niet kritisch voor je bedrijfsvoering en/of de eindgebruiker voor een eerste versie? Kunnen er zaken eventueel na realisatie nog opgepakt worden met een ander budget? Etcetera.

Hoe kom je dan op 100.000 uit? Zien we dat niet eerder aankomen? Als UX-er zie je dit natuurlijk niet altijd pas op het laatste moment. We hebben wel vaker met dit bijltje gehakt. Onze adviesrol op budget en tijd is bij de start van het traject al essentieel. Bij elke stap zal een UX-er al bezig zijn met de budget indicatie en wensen vanuit de verschillende partijen. Tijdens het proces zullen we al aangeven wanneer we denken dat we niet realistisch bezig zijn. Of wanneer we signaleren dat de scope van het project nogal aan de grote kant wordt in verhouding tot budget en/of tijd.

Wat daartegenover staat is dat je natuurlijk niet al gaat bezuinigen voordat je echt weet dat het te duur wordt. Je wil de beste oplossing en niet meteen de budget versie. Dat geldt ook op detailniveau. 

Een UX-er kan veel zeggen over verwachte impact op budget, maar lang niet alles. Er zitten ook een hele hoop technische aspecten aan een functie of feature, en er is ook nog niks ontworpen. We maken dit overzicht juist zodat daar naar gekeken kan worden, omdat er dan cumulatief een eerste kostenplaatje uitkomt. UX-ers kunnen dat nooit allemaal overzien voordat er een overzicht ligt wat redelijk compleet is.

Budget niet toereikend?

Je gaat in deze situatie nogmaals door de requirements heen en gaat per element bekijken of deze essentieel zijn, en of misschien wat zaken simpeler en goedkoper opgelost kunnen worden. Is het hebben van een nieuwsbrief-feature bijvoorbeeld wel essentieel voor een eerste launch? Iets willen hebben ("nice to have" ) betekent niet nodig hebben ("need to have") voor een eerste realisatie. Of misschien voldoet de iets minder perfecte oplossing voor nu ook. Dit zal per organisatie natuurlijk gigantisch verschillen, maar we moeten wel alles kritisch gaan bekijken, er moet zo ongeveer 20.000 euro af.

Maar wat gebeurt er dan met die nieuwsbrief? Die wil je natuurlijk nog steeds. Een MVP betekent niet dat je daarna stopt met ontwikkelen. Digitale oplossingen worden continu doorontwikkelt. Een website is nooit echt af, een app krijgt updates, etc. We maken de keuze om de nieuwsbrief niet meteen te ontwikkelen omdat er daardoor andere zaken wel ontwikkeld kunnen worden die essentieel zijn. Vaak volgt er na de MVP sowieso een vervolgtraject waarin dan zaken opgepakt kunnen worden die zijn blijven liggen in verband met tijd of eerste budget. 

Hierdoor wordt nogmaals relevant hoe belangrijk een program of requirements is. Want deze documentatie blijft dus ook na de eerste lancering relevant. Je program of requirements blijft in zijn geheel bestaan, alleen zet je ergens een streep tussen “nodig” en “gewenst / niet meteen nodig” om de 80.000 euro te benaderen. Er blijven misschien wel zaken open die je niet meteen oppakt, maar dat betekent niet dat je ze nooit meer wil realiseren.

Dit verhaal kan je ook op tijd toepassen. Een deadline betekent vaak beperkte tijd in plaats van geld, maar creëert hetzelfde probleem in haalbaarheid. De totaal beschikbare tijd kan ook niet matchen met de hoeveelheid werk of manuren die daarvoor nodig zijn.

Solution discovered?

Om de best mogelijke oplossing te realiseren waar iedereen het maximale uit kan halen moet je dus samen met het bureau nogal wat stappen door. Maar uiteindelijk is dit allemaal omdat we een zo goed mogelijke ervaring willen bieden voor de eindgebruiker, terwijl de organisatie er volledig achterstaat en dit met de beschikbare middelen ook te realiseren is. 

Nu je een gedetailleerd overzicht hebt, een kostenplaatje hebt wat klopt en een MVP hebt gedefinieerd, kunnen andere mensen aan de slag. UX-ers, designers en daarna developers kunnen nu echt vorm gaan geven aan je oplossing. Allemaal onderbouwd én gevalideerd. 

Over de auteur

Lex Laureijssen is UX designer & strateeg bij One Shoe. Hij streeft naar heldere interactie en no nonsense oplossingen waarmee gebruikers aan de slag willen.