Zes hacks voor service designers in een Agile omgeving

Of je nu een doorgewinterde service designer bent of een beginner, de kans is groot dat je tijdens je opleiding en eerste projectervaringen zeeën van tijd had om je werk uit te voeren. Een paar weken contextueel onderzoek doen? Geen probleem. Nog een paar weken om een prototype te bouwen en te testen? Ook geen probleem. Met de vrijheid om je eigen tijdlijnen te bepalen, kon je je werk in je eigen tempo doen. Maar nu agile werken steeds meer wordt omarmd, komt die werkwijze op z’n kop te staan.

Idealiter leveren we als service designers de meeste waarde wanneer we buiten de ‘scrum’ blijven (letterlijk en figuurlijk), onze strategische rol vervullen en het koortsige tempo en de beperkte focus van de sprints van twee weken vermijden. Ons werk moet richtinggevend zijn voor tactische en operationele activiteiten, in plaats van er een directe rol in te spelen. Maar soms is zo'n afstandelijke positie niet haalbaar en moeten we de agile-werkwijze aannemen, accepteren dat we worden geleid door een producteigenaar (en niet een service-eigenaar) en een manier vinden om binnen een team te werken.

Maar wees niet bang, service designers die agile moeten werken! Hier zijn zes hacks die je kunt uitvoeren om je strategisch perspectief en invloed uit te breiden, terwijl je nog steeds bezig bent om items van de backlog af te vinken en die volgende iteratie van je product (service!) de deur uit te krijgen. Deze hacks zijn tot stand gekomen op basis van het consultancywerk van Informaat en hands-on ervaringen bij verschillende grote Nederlandse organisaties die zijn overgestapt op agile en waar service designers zoals ik een rol hebben gespeeld in agile teams. Want ook zit je vast aan een operationele rol die het echte service design werk moeilijk maakt, biedt de overgang naar agile zelf wel kansen om de rol van (service) design in de organisatie te versterken.

Maak tijd vrij om de aandacht van het team te richten op de strategische aspecten van je project en gebruik hiervoor bestaande canvas-gebaseerde technieken. Ondanks het feit dat agile teams onder enorme druk werken om stapsgewijs te leveren, zal iedereen profiteren van gedeelde input en een gemeenschappelijk inzicht van het 'grote geheel'. Als ze de activiteit niet zelf hebben geïnitieerd, nodig dan producteigenaren en de rest van het team uit voor korte, intensieve sessies om documenten zo vroeg mogelijk in te vullen, als een Business Model Canvas en Value Proposition Canvas. Beter nog, overweeg canvassen die uitdrukkelijk zijn ontworpen met serviceontwerp in gedachten, zoals de toolkit Lean Service Creation van Futurice. Wanneer meerdere serviceontwerpers onafhankelijk werken, zorg er dan voor dat je contact maakt met hen en dezelfde visie, principes en ecosysteemvisie deelt. Je zult versteld staan van de waarde die deze activiteiten en resultaten opleveren.

Het betrekken van echte eindgebruikers bij het ontwerpproces is cruciaal om aan de verwachtingen van een serviceontwerper te voldoen. En ondanks het feit dat je agile-methode misschien iteratie en gebruikerstests ingebed heeft, wordt er vaak van uitgegaan dat testen exclusief worden uitgevoerd door UX-ers en service designers. Overtuig in plaats daarvan niet-ontwerpers om onderzoekssessies bij te wonen. Een uurtje meekijken over de schouder van echte klanten kan grote voordelen opleveren, omdat je het vage concept van eindgebruikers vervangt door levende mensen. En als bestaande methoden voor gebruikersonderzoek problematisch blijken te zijn in een agile team, help dan met het zoeken naar een meer geschikte, eenvoudiger methode.

Hoewel deze hack de inspanning van verschillende disciplines binnen het team vereist, levert het veel toegevoegde waarde op en helpt het ervoor te zorgen dat naarmate een service groeit, dit efficiënt gebeurt en een consistente eindgebruikerservaring voor ogen houdt. De bibliotheek bestaat verschillende soorten documenten die worden gemaakt, onderhouden en geraadpleegd door vier afzonderlijke teams:

• Brand & Communications (merkwaarde & -principes, merkidentiteit, tone of voice, beeldbank)
• Design Management (kanaal- en ontwerpprincipes, referentieontwerpen, structuur- en navigatiesjablonen, patronen en UX-richtlijnen)
• Digital Identity (digitale identiteit, pagina's en templates, UI-componenten, elementen)
• Front-end (referentiecode (webcomponenten), Platformspecifieke code)

Hoewel deze documenten misschien al bestaan (in dat geval kunt je er trots op zijn om in een goed geoliede organisatie te werken!), zijn ze waarschijnlijk afzonderlijk opgeslagen, onregelmatig bijgewerkt en moeilijk te vinden. Benut je mandaat en je vaardigheden om te delegeren, verzamel de documenten in een gemakkelijk te raadplegen bibliotheek, rust goed, wetende dat je team nog efficiënter zal zijn omdat ze consistente ervaringen bieden.

Meer en meer service designers rekenen hun collega’s die data analyseren tot hun beste vrienden. Dat komt omdat huidige complexe services steeds beter worden ontwikkeld en geleverd en ze het potentieel hebben om enorm waardevolle gegevens te genereren hoe ze door klanten worden gebruikt. Werk samen met een data-analist om te ontdekken welke inzichten je uit de zee van data kunt halen. Categoriseer deze inzichten met behulp van het HEART-framework van Google:

• Happiness
• Engagement
• Adoption
• Retention
• Task success

Zorg vervolgens voor het creëren van een intern toegankelijk dashboard waarop de data continu gemonitord kan worden. Te vaak is de kracht van analyse gericht op droge ‘webstatistieken’ (unieke bezoeken en verwijzingen) of commerciële prestaties (conversiecijfers en uitval). Pas in plaats daarvan een servicedesignbenadering toe, beginnend bij een analyse van individuele touchpoints en richt een dashboard in waarin service experience wordt gemeten en weergegeven als een journey. Je levert waardevolle nieuwe inzichten aan zowel je team als stakeholders en je krijgt een holistisch beeld van hoe je service het doet.

In een scrum (als één van de meest toegepaste agilemethodologieën) doorloopt het team een reeks mijlpalen (milestones) die worden herhaald in sprints van twee weken. Hoewel je werk misschien in het teken staat van sprintplanningen en demo's en je focus wordt gedreven door de backlog, kun je je ook gedeeltelijk losmaken van deze routine en voor de troepen uit werken. Als de backlog aangeeft dat een nieuwe, complexe feature over twee sprints van nu moet worden ontwikkeld, waarom zou je je dan niet nu al voorbereiden? Reserveer een deel van je tijd voor ideevorming, prototyping en onderzoek (of zelfs een kleinschalige service blueprint). Doe dit in samenwerking met je UX-partner. Als die sprint eenmaal begint, is het ontwerpwerk beter voorbereid en heb je niet het gevoel dat je de kantjes eraf loopt simpelweg omdat je je werk binnen één sprint moest beginnen en eindigen.

Ik heb verhitte discussies gehad waarin ik producteigenaren ervan heb proberen te overtuigen dat ze - ondanks wat hun functietitel suggereert - slechts een deel van een product creëren. In grote organisaties hebben product owners een haarscherpe focus op het in de markt zetten van uitstekende producten. Maar soms moet je ze dwingen te erkennen dat hun product niet in het luchtledige terechtkomt. Het zal bestaan en samen met vele andere producten worden gebruikt in een complexe en rijke klantervaring. Je zult in twee richtingen moeten werken.

Ten eerste vanuit een serviceniveau. Zorg dat producteigenaren op de hoogte zijn van elkaars initiatieven. Een organisatie wil een consistente (en geweldige) klantervaring leveren die niet laat zien dat de producten onafhankelijk van elkaar zijn ontwikkeld. Denk in termen van touchpoints als dat helpt. Als de producteigenaar verantwoordelijk is voor de app, is dan de klantenservice geïnformeerd dat er een nieuwe feature is waar vragen van klanten over kunnen binnenkomen en dat de telefonisten niet onvoorbereid zijn? Ten tweede, werk op productniveau. Neem tijdens je werk in het agile team voortdurend een stapje terug en evalueer hoe de laatste iteratie past binnen het grote geheel. Dit is een afstemming tussen product en service en hoewel het geen onderdeel is van een pure, productgebaseerde methodologie, is het van cruciaal belang wanneer het product een onderdeel is van een grotere service.

Tot slot wil ik herhalen dat de toepassing van service design al in gevaar komt als het alleen tactische en operationele activiteiten beïnvloedt. Om je strategische capaciteiten als serviceontwerper te vervullen wanneer je alleen met een operationele blik werkt, probeer dan de organisatie ervan te overtuigen om het profiel uit te breiden en het mandaat van service design te vergroten door het op een meer strategisch niveau te plaatsen.

Deze hacks zijn geïnspireerd op de presentatie '5 Agile Design Hacks, and How To Do It Properly in the Near Future' van mijn Informaat-collega Rob van der Haar op 19 september 2017, die hij gaf tijdens het SDN Netherlands event en op mijn eigen ervaringen.