Het proces

Toen ik mijn onderzoek begon speelde ik met de gedachte dat het product los gebruikt kon worden door teamleden die niet bij elkaar zitten. Ik ben vervolgens mijn prototype gaan bouwen, zonder enige focus op de werking van het proces waarin de applicatie gebruikt zal gaan worden. In het onderzoek met prototype 2 bleek dat designers moeite hadden met het bepalen uit welke componenten een ontwerp bestaat. Ze wisten niet precies hoe een developer het zou doen en ontwikkelde hun eigen werkwijze en systeem van benamingen.

In elk artikel wat ik lees over de 'component cut up' workshop staat benadrukt dat het belangrijk is dat het proces plaatsvind met het gehele team. Hieronder een paar citaten:

Invite anyone who will influence or benefit from the library. UX designers and front-end developers are critical. However, you’ll benefit from inviting other key stakeholders and potential champions too, for the workshop is a big event and generate momentum around the pursuit. Therefore, considering inviting QA, product managers, copywriters, project management, and even willing executive sponsors.

The Component Cut-Up Workshop - Nathan Curtis

it is a great first step to getting the entire team involved and aligned. We have considered trying something that requires less paper like taking screenshots but what I will say about physical paper and tape is that the whole team seems to stay more engaged for the whole time, rather than falling into a distraction of checking emails or doing other work on their machines.

Component Workshops: Our one-two punch for kicking off a new Design System - Josh Christopher

In dit citaat blijkt ook dat het team al eens geprobeerd heeft om het proces digitaal uit te voeren, maar ze dit het liefst ontwijken, aangezien de leden van het team snel afgeleid zijn en andere taken gaan uitvoeren op hun computer, zoals het bekijken van mail. Dit geeft aan dat wanneer iedereen apart aan de inventory zal gaan werken, teamleden afgeleid zouden kunnen worden door handelingen als hun email checken.

In een informeel gesprek met Tjerk Smit van De Voorhoede vroeg ik hem of hij vond dat het belangrijk was dat een team bij elkaar zit tijdens het proces of dat ze het ook los van elkaar kunnen uitvoeren. Hij antwoordde: "Ik denk dat het team dat gezamenlijk moet doen, design samen met development, zodat iedereen ook een begrip krijgt over wat herbruikbare componenten nou eigenlijk zijn".

Tjerk heeft hier een goed punt. Het proces wordt vooral gebruikt om te zorgen dat designers zich bewust worden van hoe een developer werkt in herbruikbare componenten.

Conclusie

Wanneer de applicatie gebruikt wordt om 'interface inventory' te maken van een ontwerp van designers binnen hetzelfde team, is het het beste om die met het gehele team te doen. Het liefst ook met de product owner/projectmanager erbij, zodat die zich ook bewust wordt van de componenten bij het maken van bijvoorbeeld user stories. Er werd in een gesprek met Declan Rek aangegeven dat hij graag de product owner bij het proces betrekt, zodat die zich bewust wordt van de werkwijze van een developer en vanuit die gedachte user stories kan gaan schrijven.

Het kan voorkomen dat een designer een 'interface inventory' wilt maken van een bestaande website voor het maken van een redesign, zodat er duidelijk wordt wat er op dit moment al op de website bestaat. Voor dat proces kan de applicatie ook geschikt zijn. De designer is dan vrij in zijn werkwijze en benaming van componenten, aangezien hij dit alleen zelf zal gaan gebruiken.

Tijdens mijn onderzoek heb ik mij gefocust op het proces waarbij een ontwikkelteam een 'interface inventory' maakt van een ontwerp gemaakt door designers, aangezien dat bij de opdrachtgever het meest gebruikelijke proces is. Er zijn echter ook andere gebruiksmogelijkheden, bijvoorbeeld een developer die voor zichzelf een inventory van het design maakt zodat hij weet welke componenten hij moet gaan bouwen. Om deze reden (flexibiliteit van de applicatie) heb ik besloten om geen extra begeleiding te geven aan gebruikers over hoe de applicatie gebruikt moet worden. Deze verantwoordelijkheid moet vanuit het team komen, de applicatie is enkel een tool ter ondersteuning van het proces.

Tijdens de validatie van de applicatie bleek wel dat de gebruikers een vorm van onboarding mistte. Hier ben ik tijdens dit onderzoek niet aan toegekomen, maar het zal zeker terugkomen in de aanbevelingen, zodat er in de toekomst aan gewerkt zou kunnen worden.