Hoe voorkomt u eindeloze feedbackrondes in uw webproject?

Om een webproject tot een optimaal einde te brengen, is het belangrijk dat de samenwerking tussen alle partijen vanaf het eerste moment goed is. Lars Galesloot van Jungle Minds geeft vier tips om eindeloze feedbackrondes te voorkomen.

Tekst: Lars Galesloot

Webprojecten kenmerken zich door een intensieve samenwerking. De opdrachtgever heeft te maken met een multidisciplinair team. Het liefst zit je met z’n allen bij elkaar, fysiek. In de praktijk is dat vaak helaas niet haalbaar.

Het eerste resultaat wordt vaak op de proef gesteld in de feedbackrondes. Deze rondes zijn bedoeld om de oplevering (website, app) te verbeteren, maar helaas leiden deze rondes er lang niet altijd toe dat het eindproduct ook daadwerkelijk een eindproduct is. Het komt regelmatig voor dat u als opdrachtgever het gevoel hebt dat er niet goed geluisterd wordt, of anders, omdat het ontwikkelteam vindt dat zij feedback ontvangt waar zij weinig mee kan.

Ruis op de lijn
Vaak zit er veel ruis op de lijn. Reden hiervoor is dat beide partijen elkaars achtergrond en proces onvoldoende begrijpen of kennen en niet goed weten wat de daadwerkelijke motieven, werkwijzen en doelstellingen zijn. Dit leidt tot onbegrip en gaat ten koste van het resultaat. Met dit artikel zal ik proberen om handvatten te bieden die ertoe bijdragen dat partijen elkaar beter gaan begrijpen en zo samen naar een optimaal eindproduct kunnen werken.

1. Wees specifiek

-> Development team: vraag om specifieke en gerichte feedback.
'Wat vind je ervan?' Die vraag gaat er niet voor zorgen dat er constructieve feedback komt. Wees specifiek en wijs de opdrachtgever erop waarnaar hij of zij moet kijken. U stuurt delen van een interactieontwerp of design op met een bepaald doel voor ogen. Zorg dat de opdrachtgever ook weet wat dit doel is.

-> Opdrachtgever: beargumenteer de feedback die u geeft.
Soms is het voor een development team lastig te begrijpen waar feedback vandaan komt. Het team heeft de verplichting om gemaakte keuzes te kunnen beargumenteren en het is ook de verplichting van de opdrachtgever om feedback te kunnen beargumenteren. Zorg dus dat u dit kunt. Wanneer u duidelijk aan kunt geven waarom u iets wilt en wat de achterliggende gedachte is, zal het voor het development team eenvoudiger zijn om te zoeken naar een geschikte oplossing. Of ze kunnen vanuit de expertrol de argumentatie weerleggen.

2. Deel de achtergrond en context

-> Development team: geef aan welke keuzes u in het proces maakt.
Door uw design of interacties te onderbouwen, krijgt de opdrachtgever inzicht in de overwegingen en keuzes die gemaakt zijn tijdens het proces. Dit leidt tot meer begrip vanuit het perspectief van de opdrachtgever en betere acceptatie. U aat zien dat overal goed over nagedacht is. Dit voorkomt veel zinloze feedback.

-> Development team: geef aan hoe de oplevering zich verhoudt tot de totale eindoplevering.
U kunt een oplevering pas op waarde schatten wanneer u het proces begrijpt. Het is bijna niet mogelijk om feedback te geven op iets waarvan u niet precies begrijpt wat het is, welke aannames erin gemaakt zijn en wat de invloed van de deliverable is in de vervolgstappen van het proces. Geef aan dat bijvoorbeeld de foto’s op dit moment slechts placeholders zijn en dat de fotografie in de volgende sprint opgepakt wordt. Hierdoor is het duidelijk dat fotografie niet over het hoofd gezien wordt en dat het niet nuttig is om nu uitgebreid feedback op foto’s te geven.

-> Opdrachtgever: deel uw interne agenda met het development team.
Laat weten hoe het project er intern voor staat. Wanneer moet het project gepresenteerd worden? Wat zijn interne gevoeligheden? Dit zijn zaken die een buitenstaander niet weet. Door uw agenda te delen met uw development team, wordt voor hen duidelijk waarom bepaalde verzoeken komen en wat gevoelig ligt. Dit vergroot het begrip en vaak kan juist het development team u goed helpen om het project intern door te verkopen. Maak daar gebruik van!

3. Behoud snelheid

-> Development team: laat zo snel mogelijk weten wat de impact van feedback is.
Geef zo snel mogelijk aan wat de impact is van bepaalde feedback. Denk hierbij niet alleen aan de financiële impact, maar ook aan de impact op design-, development- of interactiewerkzaamheden. Vaak wordt de relatie van bepaalde punten niet gezien door personen die onbekend zijn met het proces. Het kan voor de opdrachtgever bijvoorbeeld eenvoudig lijken om een visual even snel te wijzigen. In de praktijk zijn hier vaak echter meerdere handelingen voor nodig die van buiten niet zichtbaar zijn. Door direct aan te geven welke werkzaamheden komen kijken bij ogenschijnlijk kleine wijzigingen, leert de opdrachtgever zijn verzoeken beter op waarde te schatten. Zo houdt u de snelheid in het proces.

-> Development team: laat áltijd zien wat u met feedback doet.
Laat als developers altijd zien wat u met de feedback gedaan hebt in een volgende iteratie. Zo houd u de opdrachtgever betrokken en raakt het project nooit te ver af van het einddoel. Daarnaast is het ook een bevestiging naar de opdrachtgever toe dat u zijn feedback serieus neemt. Wanneer u feedback niet implementeert, zorg dan dat u voldoende argumentatie hebt om de feedback te weerleggen; negeer feedback nooit.

-> Opdrachtgever: vraag in een vroeg stadium slechts feedback aan een kleine interne groep stakeholders.
Betrek in een later stadium pas personen die verder van het project af staan, maar wel stakeholder zijn. Niet iedereen hoeft er in het begin iets van te vinden. Hoe meer meningen, hoe meer compromissen en hoe groter de kans op een ‘middle-of-the-road’ eindproduct waar niemand echt tevreden mee is. Door in een vroeg stadium feedback te krijgen vanuit een selecte groep personen uit de business, kan een solide fundament onder het project gelegd worden. Later in het proces kunnen meerdere stakeholders feedback geven op concrete zaken rond een product dat al grotendeels staat. Dat versnelt het proces.

-> Opdrachtgever: houd interne meningsverschillen intern. En houd zo voortgang in het project.
Dit voorkomt dat het projectteam vanuit verschillende kanten feedback krijgt die elkaar tegenspreekt. Dit kan ervoor zorgen dat een project stilvalt, bijvoorbeeld omdat het onduidelijk is welke feedback verwerkt moet worden en welke niet. Door als opdrachtgever interne feedback te filteren, worden interne meningsverschillen snel zichtbaar. Deze kunnen dan direct geadresseerd worden. Zodra hier keuzes binnen gemaakt zijn, kan de feedback doorgespeeld worden naar het development team. Het project blijft zo snel meters maken, omdat de visie vanuit de opdrachtgever naar het development team eenduidig is.

4. Communiceer open en direct
Schroom niet om ook gevoelige issues op tafel te leggen, maar spreek direct uw twijfels uit. Zo kunnen deze direct geadresseerd worden. Zorg dat niks onduidelijk blijft. Denk niet dat u het wel begrijpt, maar zorg dat u 100 procent zeker weet dat u elkaar begrijpt. Doe zo min mogelijk aannames en reduceer hiermee de ruis op de lijn. Immer: ‘Assumptions are the mother of all fuckups’.

Een project is gebaseerd op transparantie en vertrouwen. Zorg dat u te allen tijden een open communicatie met elkaar houdt en dat u blijft uitleggen waarom u doet wat u doet. Zo blijft u elkaar begrijpen en kunt u hard naar het gezamenlijke doel toewerken.
 
Lars Galesloot is research consultant bij Jungle Minds. Dit artikel verscheen eerder op de site van het adviesbureau.


Foto: The word Feedback in cut out magazine letters pinned to a cork, Shutterstock