User stories en website ontwikkeling

Doelgroep
Vaak zie je dat de informatie-architectuur van sites vanuit doelgroepen georganiseerd wordt. Meestal is dit een afspiegeling van de manier waarop een organisatie met zijn klanten omgaat. Doelgroepen bestaan wel, echter ze zijn nogal fluïde. Kijk naar een ziekenhuis. Vaak wordt informatie ontsloten op basis van doelgroepen: medische professionals, patiënten, familie. Als je arts bent, dan behoor je tot de doelgroep medische professionals. Als je echter als arts ziek bent, dan behoor je tot de doelgroep patiënten.  Zelfs tijdens een bezoek aan een site, kun je als lid van een doelgroep wisselen van de ene groep naar de andere. Je kunt beter spreken over rollen of situaties dan lidmaatschap van een doelgroep.

Wat wil de gebruiker
In het algemeen kun je stellen dat bezoekers intentioneel zijn. Ze willen iets. Ze willen iets vanuit hun rol of situatie. Ze willen iets teneinde een doel te bereiken. Dat doel kan van alles zijn:

  • Nieuwsgierigheid bevredigen;
  • Snel en oppervlakkig informatie verkrijgen;
  • Diepgaand informatie verkrijgen;
  • Informatie kopiëren (downloaden);
  • Advies vinden;
  • Aanmelden voor iets;
  • Op de hoogte blijven (herhaling);
  • Iets kopen;
  • Iets regelen.

Deze manier van kijken naar de ontwikkeling van een website, is afkomstig uit de Agile Development hoek. Agile Development (bv. XP en Scrum) is een manier van softwareontwikkeling die ‘lean en mean’ is, altijd uitgaat van de positie van de gebruiker en continu werkende producten oplevert. Dit in tegenstelling tot de traditionele watervalmethode. Daar moet je als gebruiker toch enig geduld hebben voordat je iets te zien krijgt. Je moet eerst door een berg papier (definitiestudie, functioneel ontwerp, technisch ontwerp, etc.) voordat er überhaupt gestart wordt met het handwerk van configuratie en programmeren.

Interessant, zult u denken, die Agile Development, maar hoe kom ik als gebruiker nu precies in dat verhaal aan bod.
Het antwoord is ‘User Stories’. User Stories is een aanpak om functionaliteit te ontwikkelen aan de hand van hoe een gebruiker met een bepaalde functie omgaat of om wilt gaan.

Voorbeelden van User Stories zijn:

  • Parkeerkaarten kun je betalen met je creditkaart;
  • Studenten kunnen een Cursusoverzicht krijgen;
  • Geprinte afdrukken van de resultaten van cursisten kunnen verkregen worden;
  • De applicatie begint altijd met het tonen van het item waar de gebruiker het laatst mee bezig is geweest.

User Stories zijn meestal van de vorm:

Als …. (rol) wil ik dit ..… (doel) bereiken om …… (reden)

Een voorbeeld:
Als werkzoekende verpleegkundige wil ik specifieke informatie over het vacatureaanbod van het Erasmus Ziekenhuis Rotterdam, om een nieuw, uitdagende baan te krijgen.
De tools voor User Stories zijn simpel: notitiekaartjes en wat pennen.
Aanpak:

  • Geef elke kaart een uniek nummer;
  • Laat de Stakeholders hun User Stories verzamelen;
  • Een User Story is kort en bestaat bij voorkeur uit één zin;
  • Geef een prioriteitswaarde aan de User Story;
  • Geef elke User Story een slaagcriterium oftewel een acceptatietest.

Als model voor het opstellen van User Stories kan onderstaand voorbeeld kaartje gebruikt worden.

Nr Prio ROL wil IETS (Doel) zodat WINST, VOORDEEL, GEMAK Acceptatie
1 2 Klant wil Zich oriënteren om een afspraak te maken zodat Hij/zij weet hoe dat gedaan kan worden Alle gegevens om een afspraak te maken worden aan de klant gepresenteerd
2 5 Klant wil Afspraak maken voor onderzoek zodat Hij/zij weet wat er aan de hand is Afspraak-bureau ontvangt alle benodigde gegevens om een agenda-event in te plannen
.. etc. ………. ………..

Verzamel de kaartjes en sorteer op volgorde van prioriteit.
Bepaal de haalbaarheid van realisatie van de Story binnen het gegeven budget.
Een aantal User Stories met hoge prioriteit zal gerealiseerd worden, een aantal niet. Deze worden doorgeschoven naar een volgende fase.

Al die User Stories vormen de uiteindelijke specificatie van een website, met als grote voordeel dat de gebruiker daarin centraal staat en zich direct herkent omdat hij het zelf heeft opgeschreven.

Testen van user stories
Hoe weet je nu of je user story goed in elkaar zit? Om dat te checken kun je de INVEST test doen. Hiermee kijk je naar de volgende aspecten van je story.

  • Is het Independent? Oftewel is je story onafhankelijk van de andere stories. Waardoor je prio’s kunt stellen binnen je agile-scrum project en ontwikkelaars onafhankelijk van elkaar kunt laten bouwen.
  •  Is het Negotiable? Oftewel is er ruimte voor onderhandelingen bij ontwikkeling? Ontwikkelaars willen graag implementatie-ruimte hebben.
  • Is het Valuable? De story moet (business) waarde toevoegen. De gebruikers moeten er iets aan hebben. Maar denk bij gebruikers niet alleen aan menselijke gebruikers. Ook software componenten die samenwerken binnen je architectuur, kun je als gebruikers zien.
  • Is het Estimable? Oftewel kunnen we de story begroten in benodigde kennis, tijd en geld?
  • Is het Small genoeg? De story moet niet te klein en niet te groot zijn. Kun je hem realiseren binnen 1-2 uur, dan is de story te klein. Duurt het langer dan 2 dagen, dan is de story te groot. Grote stories (Epics) kun je opdelen in kleinere. Maar maak ze niet te klein omdat je dan problemen krijgt met de I van Independent.
  • Is het Testable? Heb je acceptatiecriteria opgesteld die werkbaar en realistisch zijn?

Praten met elkaar
Het geheim van de User Stories is dat ze niet over-gespecificeerd zijn. Het zijn globale verhalen zonder specificaties op het niveau van Use Cases of een ander requirementspecificatie-niveau. Dit dwingt de gebruiker(s) en het ontwikkelteam tot mondelinge communicatie om de details boven tafel te krijgen, te bespreken en te besluiten met welke prioriteit deze op de lijst (Product Backlog) komen te staan.

Samen doen van start tot eind
Zoals met veel zaken in het leven is het werken met User Stories bij het ontwikkelen van websites, geen panacee voor alle ‘gebruikersspecificatie/ontwikkel’ kwalen. Wat wel duidelijk is, is dat met het toepassen van User Stories de verantwoordelijkheid van het eindresultaat goed verankerd wordt binnen het team van gebruikers/opdrachtgevers en de ontwikkelaars. En daar schort het vaak aan bij het ontwikkelen van website. Te vaak scheiden de wegen tussen gebruikers en ontwikkelaars zich na de eerste de beste project-kickoff en betrekt eenieder zijn stellingen.
Goed begeleide implementaties van User Stories zijn een uitstekende aanpak om dit te voorkomen.

Wil je meer lezen over onze ideeën over internet, datascience en dergelijke: kijk eens bij dit of dat of ditzo.