Frontend consultancy begint niet bij de code

Maar capaciteit is zelden het echte doel. Wat organisaties uiteindelijk zoeken, is iemand die het product beter maakt: die niet alleen bouwt wat gevraagd wordt, maar onderzoekt waarom het gebouwd moet worden, hoe het slimmer kan, en welke kansen onderweg blijven liggen.

Extra handen zijn soms wél het antwoord: als het probleem helder is, de richting vastligt, en het team vooral doorvoer nodig heeft. Tot die tijd is "we hebben capaciteit nodig" vaak een symptoom. Mijn werk begint bij dat onderscheid: de opdracht ter discussie stellen, de flow scherper maken, en blijven tot het resultaat voor de gebruiker klopt.

Het ontwerp is het begin van het gesprek

Frontend wordt nog vaak gezien als interfaces en code. In de praktijk werk je aan webapplicaties, dashboards en digitale processen waarin mensen iets moeten afronden: data bekijken, een contract wijzigen, een aanvraag doorlopen. Een aangeleverd ontwerp is daarom geen eindpunt. Het is het begin van het gesprek. Past deze oplossing bij het probleem? Bij de technologie? Bij de mensen die het moeten gebruiken? Is het toegankelijk? Werkt het op kleine schermen? Komt data op tijd? Wat gebeurt er als iemand een fout maakt? Die vragen stel je niet om het project zwaarder te maken. Je stelt ze aan designers, product owners en andere teams om te voorkomen dat een team maandenlang uitstekend bouwt aan het verkeerde. Daar zit het verschil tussen uitvoeren en adviseren. Het kost ook iets. De opdracht openbreken vraagt tijd die niet in de planning zat, en het is niet prettig voor een product owner die zijn keuze al drie keer heeft verdedigd. Soms blijkt een week later dat de oorspronkelijke richting gewoon goed was. Dat hoort erbij. Het alternatief is dat niemand de vraag stelt.

Waar frontend zichtbaar wordt

Een voorbeeld: het verhuizen en overnemen van energiecontracten. De bestaande flow draaide op oudere technologie en was langzaam. Gebruikers moesten te veel stappen doorlopen. Ging er onderweg iets mis, dan bestond het risico dat ze opnieuw moesten beginnen. Van de mensen die de flow startten, rondde destijds ongeveer 20 tot 30 procent af. We bouwden de flow opnieuw. Minder vragen. Sneller. Duidelijkere fouten. Ingevulde informatie bleef staan als er iets misging. Aan het einde van de opdracht lag het afronden van de flow rond de 60 procent. Bij die cijfers hoort context. Ze komen uit de logs die onze business analyst heeft gemeten over de 4 maanden na de release. Op dezelfde instappunten en met dezelfde definitie van "afgerond". Dat is waar goede frontend zichtbaar wordt: in of mensen de flow afronden.

Complexiteit hoort achter de schermen

Een ander project ging over financiële ondersteuning tijdens sterk stijgende energieprijzen. Voor gebruikers moest het eenvoudig zijn: gegevens invoeren, snel zien waar ze mogelijk recht op hadden. Achter die eenvoud zat het ophalen en verwerken van gegevens uit meerdere bronnen, elk met eigen voorwaarden en informatiestromen. De verleiding is om die logica op het scherm te leggen: extra velden, extra uitleg, extra stappen "voor de zekerheid."Wij deden het omgekeerde. De voorkant vroeg alleen wat de gebruiker kon weten. De rest bleef achter de schermen. Wat ik eruit meenam: elke uitzondering die je op het scherm legt, wordt een uitzondering die de gebruiker moet begrijpen. Hoe ingewikkelder het systeem erachter, hoe minder daarvan naar voren mag lekken.

Wat je achterlaat

Je komt bijna altijd in een bestaand team. Samenwerken, keuzes uitleggen, anderen meenemen. Een consultant mag meer achterlaten dan afgeronde tickets. In een van die teams zat de kennis bij iemand die in refinement nauwelijks aan het woord kwam. Toen dat eenmaal opviel en de sessies daarop werden aangepast, veranderde er weinig aan de agenda en veel aan de uitkomst: aannames die we anders pas in code hadden ontdekt, kwamen een sprint eerder boven tafel.

In het opzetten van het nieuwe project had ik de aanname dat het project er schoner uit zou zien als we een andere manier van imports zouden gebruiken, echter na het bespreken van het team wisten zij mij te overtuigen dat de bestaande manier van importeren er netter uitzag in de overige bestanden. Als de keuzes daarna zijn vastgelegd, kan het team verder zonder dezelfde externe stem.

AI maakt die rol groter, niet kleiner

Een deel van de implementatie gaat inmiddels veel sneller. Code die vroeger met de hand geschreven werd, kan een model in korte tijd genereren. Dat werk verdwijnt niet, het verschuift: als code sneller komt, wordt het belangrijker om vooraf scherp te hebben wat er moet gebeuren, en achteraf hard te toetsen wat er staat.

AI kent de organisatie niet, de geschiedenis van het product niet, en de afspraken die een team in jaren heeft opgebouwd niet. Op de frontend is dat extra riskant. Gegenereerde UI kan eruitzien alsof het werkt, terwijl staat zoekraakt, foutpaden ontbreken, of het scherm ontoegankelijk is. De gebruiker ziet een knop. Niet of het proces overleeft.

Het begint bij het probleem

Het onderwerp hoeft niet hetzelfde te zijn. Een dashboard, een klanten flow, de modernisering van een applicatie. Deze voorbeelden komen uit energie; de les niet.

Goede frontend consultancy begint niet bij de code. Bij het probleem dat je ermee wilt oplossen.

‍

Jouw ticket tot de beste line-up

Ben je op zoek naar versterking voor je team, wil je een frisse blik op je project of heb je vragen? Stuur me dan een bericht anneli.janssen@headliners.tech of bel 06 31 33 62 73.

‍

Have fun, Get it Done

‍