1 juli 2021
In een eerdere blog beschreven we al kort de Design Sprint waaraan we gingen meedoen en hoe dit in zijn werk gaat. Nu, een maand later, kunnen we met een trots gevoel terugkijken op deze Sprint. In precies vier dagen hebben wij samen met de experts de klachtenapplicatie Seintje ontwikkeld. Wat hier allemaal aan vooraf ging, lees je in een uitgebreid verslag per dag. Hieronder dag 1, veel leesplezier!
Vijf jaar geleden zijn we bij Kodision gestart met de ontwikkeling van Kotuur; een no-code platform, waarmee iedereen (ook mensen zonder IT-kennis) een applicatie kan bouwen. De doelgroep ‘iedereen’ is natuurlijk niet erg specifiek en daarom besloten we te beginnen met ons focussen op de overheid. Daar hebben we vanuit Kodision namelijk al meer dan 20 jaar ervaring mee.
Al eerder schreven we dat je met een Design Sprint in een week van abstract idee naar werkende applicatie kunt gaan. Dit wordt ook wel Rapid Application Development (RAD) genoemd, een manier van werken gebaseerd op de Agile Scrum methodiek. Dit hebben we zelf uitgeprobeerd in de Design Sprint voor Kotuur, begeleid door Julia Alberga.
Om te beginnen, was het goed om te weten welke behoeften van overheden vervuld konden worden met no-code platform Kotuur. En natuurlijk welke functionaliteiten er dan in de applicatie moeten zitten. Dit was dan ook het doel van de Design Sprint. De behoeften hebben we in kaart gebracht door middel van diepte interviews met vier organisaties uit de doelgroep en deze behoeften hebben we steeds verder uitgewerkt totdat er uiteindelijk een tastbaar concept ontstond. Een concept dat een antwoord gaf op de challenge:
“Hoe kunnen we met Kotuur gemeenten en overheden helpen de klachtenafhandeling te vergemakkelijken?”
De eerste dag draait vooral om het aanbrengen van focus en het bepalen van een duidelijk doel. Dit doen we allereerst door experts te bevragen over hun wensen en eisen van een klachtenapplicatie. De verkregen inzichten delen we vervolgens in clusters in en kiezen hier de meest belangrijke uit. Deze belangrijkste inzichten gebruiken we om de customer journeys op te stellen. Voor het begin van de Sprint kregen de deelnemers van het Kotuur-team al een pakketje thuisgestuurd met borrelhapjes en het nodige materiaal voor de brainstormoefeningen.
We beginnen de dag met de agenda van vandaag en het hoe en waarom van een Design Sprint. Daarna gaan we door met een korte huiswerkopdracht, waar we ons thuisgestuurde schrijfgerei meteen voor kunnen gebruiken. Alle deelnemers moeten namelijk hun vijf belangrijkste inzichten opschrijven die ze hebben opgedaan door een eigen ervaren klachtenproces bij onze gemeente. Iedereen denkt even hard na over een ervaring die ze kunnen gebruiken en vervolgens vliegen de pennen over het papier. Hierna krijgt iedereen één minuut om deze ervaring en hun vijf verkregen inzichten uit te leggen aan de rest. Deze opdracht heeft als doel om inzichtelijk te krijgen hoe zo’n klachtenproces en -formulier beter kan. Daarnaast is het natuurlijk ook een erg goede opwarmer voor de hersencellen, zodat ze helemaal klaar zijn voor de échte sprint!
Vervolgens is het tijd voor wat praktische zaken. We moeten onder andere een ‘decider’ aanwijzen, die bij alle besluitmomenten een iets groter aandeel heeft om een knoop door te hakken. Hiervoor wezen we Edwin aan door zijn ervaring met Kotuur, waar hij vanuit meerdere invalshoeken (zowel aan de ontwikkelkant als aan de consultancykant) het onderwerp kan bekijken én het feit dat hij de gehele Design Sprint aanwezig kan zijn, leek ons dit een goede keuze.
Na een korte uitleg van onze facilitator, Julia Alberga, is het tijd voor de expertinterviews. In deze uitleg vertelt Julia onder andere dat we open vragen moeten stellen en door moeten vragen; aannames zijn verboden. We kwamen na even nadenken tot de conclusie dat we de experts in ieder geval de volgende hoofdvragen willen stellen:
Na een bevestiging dat iedereen snapte wat de bedoeling is, komen de experts één voor één binnen: gemeente Nieuwegein, gemeente Helmond, Equalit en deelnemers vanuit een provincie. We krijgen 30 minuten per expert om onze voorbereide (en impulsieve) vragen te stellen en zo inzichten te verkrijgen over hun specifieke wensen en eisen rondom de no-code klachtenapp. Elke expert heeft natuurlijk andere wensen en eisen, dus aan ons te taak om één passende applicatie te maken voor al deze eindgebruikers. Tijdens de interviews schrijven we als studenten in een collegezaal mee met hun antwoorden op het MURAL bord die we tijdens deze sprint gebruiken.
Deze interviews kosten natuurlijk wel wat mentale capaciteit, dus het is tijd voor de lunchpauze. Degenen die na de pauze nog niet genoeg waren opgeladen, zijn dat zeker wel na de energizer! Julia zet gelijk de muziek aan, om vervolgens iedereen een keer aan te wijzen om een dancemove te doen die alle anderen na moeten doen. Weer energiek? Mooi! Dan gaan we door met alle verkregen inzichten.
Om deze overzichtelijk te maken en een rode draad te ontdekken, beginnen we met het indelen van alle notities in clusters; wat hoort er allemaal bij elkaar? Hoort deze notitie bij de cluster ‘communicatie’, of juist bij ‘registreren/afhandelen’? De volgende clusters komen naar voren tijdens het prioriteren en indelen van de inzichten:
Als we het eenmaal over de indeling van de inzichten eens zijn, stemmen we individueel op onze drie favoriete inzichten door middel van rode stippen (zie afbeelding). De decider (Edwin) krijgt hierbij twee extra stemmen om de uiteindelijke doorslag te geven in hetgeen we mee verder willen.
Uit de vele inzichten komen er nog 12 uit de test als meest belangrijk. Hiermee kunnen we dus verder gaan werken. De volgende opdracht is een brainstorm in tweetallen over hoe we ervoor kunnen zorgen dat deze 12 meest belangrijke inzichten ook echt verwerkt worden in de no-code klachtenapplicatie: de how-might-we (HMW) brainstorm. Door de inzichten om te zetten naar deze HMW’s, ontstaat er ruimte om een brug te slaan tussen de analysefase en de brainstormfase. Eenmaal weer als hele groep bij elkaar gekomen, stemmen we weer op de belangrijkste vragen die we gaan inzetten tijdens de brainstorm op dag 2. De belangrijkste HMW’s bleken:
De bedachte antwoorden op deze brainstorm leggen we even opzij, om door te gaan naar het schetsen van de huidige customer journey rondom klachten. Let op: de huidige (!) customer journey beste Kotuur collega’s, niet de ideale… Begin maar opnieuw! In deze customer journey bedenken we in twee groepen hoe alles samen komt: het beginpunt, het eindpunt, de emoties van de ‘klager’ en de kanalen via waar de communicatie plaatsvindt. Je kunt hiervoor gebruik maken van de benoemde frustraties van de experts. Ook de belangrijkste HMW’s en de gemaakte clusters komen op de customer journey. Aan de hand van de gemaakte journeys kunnen we bepalen waar precies de grootste twee pijnpunten en kansen liggen. Voor onze customer journeys gebruikten we de voorbeelden van een burger die struikelt over een losliggende stoeptegel en hiervan een melding wil maken bij de gemeente. En die van een burger die een parkeervergunning aan wil vragen.
We bekijken de twee customer journeys die gemaakt zijn door de verschillende deelnemers: welke journey is het beste? Kunnen we die als leidraad gebruiken voor de uiteindelijke journey, de customer journey 2.0? Het antwoord: deels. In ons geval is het de beste optie om de twee customer journeys samen te voegen en de ontbrekende stappen in te vullen. Hierbij omcirkelen we de belangrijkste pijnpunten en kansen, die de focus en dus het doel vormen van deze Sprint. Natuurlijk is het wel van belang om hierbij te overwegen of deze focus haalbaar is binnen Kotuur, of dat we het antwoord meer vanuit Kotuur zouden moeten zoeken.
Na het doorspreken van de journeys komen we gezamenlijk tot de conclusie dat we ons tijdens deze Design Sprint met name willen richten op het gemakkelijk kunnen indienen van een klacht, ongeacht wat voor type klacht dit is. Voor de burger moet het geen verschil maken of het om een klacht over een persoon gaat, of om een Melding Openbare Ruimte. Daarnaast willen we tijdens de Design Sprint een manier bedenken om snel feedback te geven op de ingediende klacht en inzicht in het verdere verloop van het proces, zodat de burger altijd overzicht heeft en weet waar hij/zij aan toe is.
Dan zit de dag er al weer bijna op. We sluiten de dag af met een terugblik op onze inzichten en door stil te staan bij persoonlijke doelen, zorgen en vragen. Dit omdat de groepsdynamiek ook veel invloed heeft op de Design Sprint. Ook nemen we even een kijkje in de ‘parkeerflap’. Dat is een plekje op het MURAL bord waar je tussentijdse ideeën en inzichten konden plaatsen die op dat moment geen bijdrage leverden aan het proces, maar wél van belang zijn om bij stil te staan. Eén van de belangrijke opmerkingen van dag 1 gaat over de WCAG. Deze wet is van belang om mee te nemen in de uiteindelijke oplossing. Tot morgen!
