Het verloop van een usability sprint
In 2021 heeft Puck bij haar klant, een grote Nederlandse bank, een usability sprint afgerond als tester. Voor het ontwerpen en bouwen van een compleet nieuwe in-app flow (klantreis), hebben we met het voltallige team gedurende een hele sprint de focus gelegd op het bedenken van een oplossing. En dan vooral een oplossing die hoog scoort op gebruikersgemak, dus vanuit het oogpunt van de eindgebruiker. Al konden we niet 100% de volledige sprint daaraan besteden, omdat bedrijfskritische zaken natuurlijk ook doorgaan, zoals productie-incidenten oplossen.
Voor alle scrumrollen in het team is een waardevolle taak weggelegd. Ik hoor je al denken: “UX is toch alleen voor de designer?”. Absoluut niet, juist de verschillende invalshoeken zorgen voor nieuwe inzichten. Bijvoorbeeld voor:
1. Product Owner
2. QA
3. Designer
4. Developers
5. Scrummaster
6. Business analist
N.B. Naast het scrum team waren stakeholders en eindgebruikers betrokken.
Stappen in usability sprint
Stap 1: Brainstormsessie
Start met een grote brainstormsessie waarbij je de vragen en de ideeën gaat identificeren. Op maandag organiseer je een workshop met het volledige team. Laat je dan vooral niet tegenhouden door technische complicaties. Denk daarbij bijvoorbeeld aan de ‘What if’ methodiek 1. Bij ons kwamen daar interessante en onverwachte dingen uit zoals:
- Idee: Gezamenlijke rekening openen met een app-only flow. De gebruiker heeft dus maar één medium nodig, een smartphone of tablet.
- Vraag: Hoe koppelen we de rekeninghouders? En hoe doe je dat als één van de 2 al klant is? (met meerdere opties, zoals IBAN check, referentiecode generen)
Deze creatieve sessie was zonder beperkingen waarbij het hele team betrokken was. De rol van de medewerker in het team was hier niet belangrijk. Die inhoudelijke kennis komt de dag erna.
Stap 2: Technische en functionele validatie
Dinsdag gaan alle teamleden aan de slag in hun eigen werkveld. De developers starten met technische Proof of Concepts (POC). In deze POC kunnen verschillende oplossingen geverifieerd worden voor de opties die op maandag zijn bedacht en nu technisch gevalideerd worden, op haalbaarheid en technische implementatie. Tegelijkertijd bouwt de designer een functionele POC, een prototype. De ontwerper in mijn team deed dat in Figma, waar er geen enkele regel code voor geschreven hoeft te worden. Met deze functionele POC zijn we naar een klantvalidatie gegaan. In mijn rol als QA engineer heb ik samen met de designer feedback opgehaald bij klanten en klantvertegenwoordigers.
Tijdens het maken van deze verschillende POC’s worden een aantal aannames gedaan en de business analist kan deze valideren. Denk hierbij bijvoorbeeld aan “de meeste aanvragen zullen een combinatie zijn van een bekende- en onbekende rekeninghouder”.
Ook voor de Product Owner is er vandaag een specifieke rol weggelegd, namelijk het ophalen van feedback bij de business stakeholders (bijvoorbeeld Klantenservice, Legal of Branch office medewerkers). Deze kan met bijvoorbeeld de functionele POC van de designer of alleen een mondelinge uitleg alvast de mogelijke oplossingen laten valideren door de collega’s met specifieke domeinkennis. Zo heb je zoveel mogelijk invalshoeken zo vroeg mogelijk in het proces.
Stap 3: Inzichten delen
Kom met het team bij elkaar om de inzichten te delen en na te denken over mogelijke oplossingen. Hierbij wordt gekeken naar de technische en functionele mogelijkheden om daarmee de scope van de toekomstige oplossingen te bepalen. Het doorsturen van bepaalde informatie kon bijvoorbeeld niet (technische beperking) en mocht ook niet (legal beperking). N.B. Deze drie stappen kunnen herhaald worden tot er een haalbare oplossing (technisch, functioneel en timeline-wise) gekozen is. Dit is natuurlijk geen oneindige loop, gebruik de ervaringen en opgedane kennis uit stap 1 – 3 om een realistische oplossing te kiezen.
Stap 4: US en epics opstellen
Met de scope en de gekozen oplossingen worden de epics en user stories opgesteld. Deze hoeven niet volledig gerefined te worden, maar je stelt vooral de grote lijnen op. Het hele team pakt hier zijn rol in, zoals dat normaal ook tijdens een refinement gebeurt.
Voorbeeld van de onderwerpen
- Een referentiecode zodat er een link kon worden gelegd tussen de informatie op de website en de app.
- Onderzoek naar het vervolgproces. Hierbij werd vooral gezocht naar afstemming met andere contactmomenten zodat er voor de klant een seamless experience zou ontstaan bij het aanmaken van een gezamenlijke rekening.
Plannen van een usability sprint
De usability sprint is bij ons in sprint 4 ingepland, namelijk het moment dat de globale richting van de oplossing bepaald werd. Het is niet handig om dit aan het eind van het project te doen, want dan is de richting al bepaald. Eerder is ook niet praktisch omdat het team dan nog niet voldoende inhoudelijke kennis van het probleem heeft en dus nog de beste oplossing kan bedenken. De specifieke sprint zal verschillen per bedrijf en project.
De rol van de Quality Assurance Engineer
De QA rol in mijn team is naast de quality mindset overdragen naar het hele team, voornamelijk kritische vragen stellen. Niet in het begin natuurlijk, daar wil je voornamelijk groot dromen. Maar zodra we de kaders krijgen van de mogelijke oplossingen, gaan we voor een seamless experience voor de klant. Hoe minder moeite iets kost, hoe beter de klant zich voelt. Een aantal stappen zijn natuurlijk essentieel voor het identificeren bijvoorbeeld, maar we hebben uiteindelijk ook een deel geautomatiseerd “under the hood”. De klant merkt hier dus niets van, maar hoeft zelf minder handmatig te doen en minder lang te wachten op feedback. Tenslotte zorgt de QA-er ervoor dat user story’s goed testbaar zijn.
Tips voor tools bij de usability sprint
Deze tools zijn niet heilig, maar puur een middel om het doel te bereiken. Gebruik jij in je team andere vergelijkbare tools? Gebruik dan vooral de tools waar je al bekend mee bent. Wij hebben deze tools gebruikt:
- Figma voor het prototype
- Xcode voor de IOS code
- Android Studio voor de Android code.
- Jira voor de user stories en de epics
- Miro voor het creatieve proces (brainstorms)
Algeme tips bij de uitvoer van een een usability sprint
Besef dat het oké is als je in de UX sprint niets bouwt. Het gaat erom dat er heldere oplossingsrichtingen gekozen worden en dat die vertaald worden naar epics en user stories. Met de duidelijke deliverables, zoals POC’s en designs heb je een stevige basis. Het bouwen komt later.
Usability sprints iets voor jou?
Wil jij ook werken in een omgeving waar je als QA engineer aan de slag kan met usability sprints? Het Sogeti heeft een hele community van collega’s die elkaar helpen met usability vragen, usability testing en usability sprints. We hebben ervaren collega’s, trainingen en een UX laboratorium beschikbaar hiervoor. Neem vooral contact op met Puck Blom – Sr. Agile Test Engineer of Robin Klein – SAP Testmanager of bekijk de vacatures.
