Het langzaamste element in je applicatie kan... een mens zijn.
Wanneer een bedrijf zegt dat zijn applicatie traag is, is de eerste reactie meestal erg technisch. Je moet de server controleren. De database. De API. De SQL-query's. De cache. De infrastructuur. De bestandsgrootte. JavaScript. De reactietijd van afzonderlijke diensten.
En terecht. Technische prestaties zijn van groot belang.
Alleen soms zien alle grafieken er goed uit, reageert de server snel, laadt de applicatie binnen een redelijke tijd en zeggen gebruikers nog steeds: "Dit duurt te lang."
En dan rijst een interessantere vraag. Misschien is de applicatie helemaal niet traag. Misschien dwingt ze de mens gewoon om te wachten.
2 seconden reactie, 20 minuten werk
Stel je een medewerker voor die een offerte voor een klant moet opstellen.
Het systeem werkt soepel. Elk scherm opent snel. Er zijn geen fouten. De server reageert bijna onmiddellijk.
Maar om de offerte op te stellen moet de medewerker: de klant openen, naar de bestelling gaan, het productnummer kopiëren, een tweede module openen, het product opzoeken, gegevens overtypen, teruggaan naar het eerste scherm, een categorie kiezen, naar het volgende tabblad gaan, prijzen ophalen, handmatig de korting controleren, het resultaat naar Excel kopiëren en het vervolgens opnieuw in het systeem overtypen.
Elke afzonderlijke handeling kan een paar seconden duren.
Technisch werkt alles prima. Alleen duurt het hele proces 20 minuten.
En precies hier schiet de klassieke opvatting van performance tekort.
Want de gebruiker interesseert zich niet vooral voor de API-reactietijd. Die interesseert zich voor de tijd die nodig is om de taak uit te voeren.
Technische performance is nog maar het begin
Systeemprestaties kun je op veel manieren meten.
We kunnen de serverreactietijd analyseren, de laadtijd van een view, databasequery's, geheugengebruik, CPU-belasting of vertragingen tussen diensten.
Dat zijn zeer belangrijke metrics. Maar er bestaat nog een tweede laag.
Perceived performance, oftewel de prestatie zoals de gebruiker die ervaart.
En nog breder kun je kijken naar operationele performance - dus hoe snel en soepel een mens een echte taak kan uitvoeren met behulp van het systeem.
En juist op die laatste laag verliezen bedrijven heel vaak de meeste tijd. Want je kunt een uiterst snelle applicatie bouwen die nog steeds een traag werkinstrument is.
Het langzaamste systeem zijn soms zeven schermen
Stel dat een medewerker een klacht afhandelt.
Het systeem vereist zeven stappen.
Eerst de klant openen.
Daarna de bestelling.
Vervolgens het product.
Daarna het klachtenformulier.
Dan de categorie van het probleem.
Vervolgens de beslissing.
Tenslotte de bevestiging.
Elk scherm laadt in 0,5 seconde.
Vanuit het perspectief van de ontwikkelaar kan alles er heel goed uitzien. Maar de gebruiker heeft zeven overgangen uitgevoerd, zeven keer van context gewisseld en zeven keer moeten nadenken over wat hij vervolgens moest doen.
Als zulke handelingen tientallen keren per dag worden uitgevoerd, wordt het probleem geen kwestie van gemak meer. Het wordt een kostenpost. En het gaat niet alleen om de tijd achter het scherm. Er komen vermoeidheid, fouten, de noodzaak om gegevens te corrigeren, onderbroken taken en een toenemende belasting voor de medewerker bij.
Een formulier met 40 velden is niet snel alleen omdat het snel opent
Dat is een klassiek voorbeeld.
Het formulier opent razendsnel. - Geweldig.
Alleen moet de gebruiker 40 velden invullen.
Een deel van de informatie heeft het bedrijf al.
Een deel kan uit CRM worden gehaald.
Een deel kan worden berekend.
Een deel hangt af van eerdere antwoorden.
En toch vraagt het systeem de mens alles opnieuw.
Dan ligt het probleem niet bij de performance van de applicatie.
Het probleem is het ontwerp van het proces en de interface.
Een goed systeem moet de gegevens gebruiken die het al heeft.
Als de klant het afleveradres bij een eerdere bestelling heeft opgegeven, waarom moet de medewerker het dan opnieuw invoeren? Als het systeem het bedrijf van de klant kent, waarom moet de gebruiker dan opnieuw de gegevens selecteren? Als het antwoord op de eerste vraag de helft van de volgende velden uitsluit, waarom zijn ze dan allemaal vanaf het begin zichtbaar?
Soms is de beste manier om een applicatie sneller te maken niet het optimaliseren van code. Het is het verwijderen van werk dat de gebruiker niet zou moeten doen.
De duurste factor is de tijd van een mens vermenigvuldigd met de schaal
Eén extra minuut lijkt misschien niets.
Een medewerker voert de handeling 5 keer per dag uit. - 5 minuten.
Op maandbasis loopt dat op tot meer dan 1,5 uur.
Maar wat als 20 mensen dit doen? Wat als de handeling 30 keer per dag voorkomt? Wat als het de hele afdeling betreft? Wat als het systeem nog vijf jaar gebruikt wordt?
Dan is een enkele minuut geen minuut meer. Het wordt een operationele kost.
Daarom is het bij het ontwerpen van een systeem voor een bedrijf belangrijk om niet alleen te vragen: "Hoe lang duurt de serverreactie?"
maar ook: "Hoeveel tijd heeft een mens nodig om de taak af te ronden?"
Dat zijn twee heel verschillende vragen.
Een systeem kan snel zijn, terwijl het proces traag is
Dat is een nog breder probleem.
Stel je een aankoopproces binnen een bedrijf voor.
- Een medewerker dient een aanvraag in.
- Het systeem slaat die onmiddellijk op.
- Maar daarna moet hij wachten op goedkeuring van zijn leidinggevende.
- De leidinggevende ontvangt een bericht.
- Opent het systeem.
- Controleert het document.
- Stuurt het door naar finance.
- Finance controleert het budget.
- Daarna moet iemand de bestelling goedkeuren.
Technisch kan de applicatie perfect werken. En toch duurt het proces drie dagen.
Kunnen we dan zeggen dat de applicatie snel is?
Technisch - misschien.
Zakelijk - de medewerker wacht drie dagen.
En precies daarom vereist het ontwerpen van bedrijfssystemen een blik voorbij de interface alleen. Je moet de volledige workflow zien.
"Even geduld a.u.b." is ook een onderdeel van UX
Er is nog een ander interessant geval.
Soms voert het systeem echt een lange bewerking uit.
Genereert het een rapport.
Verwerkt het een groot bestand.
Synchroniseert het gegevens.
Stuurt het veel records naar een externe API.
Start het een complex proces.
Het lukt niet altijd om dat in één seconde te laten gebeuren. Maar je kunt wel zorgen dat de gebruiker weet wat er gaande is.
Dat is een enorm verschil.
De melding: "Laden..."
is iets heel anders dan: "We bereiden het rapport voor. 72% van de gegevens is verwerkt. Je kunt het venster sluiten - het rapport wordt op de achtergrond klaargezet."
In het tweede geval krijgt de gebruiker informatie, controle en voorspelbaarheid.
Dat is precies een van de elementen van perceived performance.
Het systeem kan nog steeds dezelfde handeling 20 seconden uitvoeren. Maar de gebruikerservaring is heel anders.
Het ergste is wachten zonder informatie
Mensen ervaren wachten veel slechter wanneer ze niet weten of het systeem überhaupt iets doet.
We klikken. - Niets.
We klikken nog een keer. - Nog steeds niets.
Werkt het systeem?
Is het vastgelopen?
Moeten we verversen?
Is het formulier verzonden?
Kunnen we het venster sluiten?
Dat is het moment waarop de gebruiker met de applicatie begint te vechten.
En wanneer de gebruiker met het systeem begint te vechten, ontstaan er nieuwe problemen.
De pagina verversen.
Het formulier opnieuw verzenden.
Duplicaten.
Telefoontjes naar de support.
Fouten.
Onnodige meldingen.
En de werktijd van volgende mensen...
Daarom is de gebruiker informeren over de status van een handeling geen cosmetische toevoeging. Het is onderdeel van het ontwerpen van een efficiënt systeem.
En soms wacht de applicatie voor de mens
Dat is waarschijnlijk het interessantste geval.
Het systeem vereist dat een mens een handeling uitvoert die technologie automatisch zou kunnen uitvoeren.
De medewerker haalt gegevens uit het ene systeem op.
Zet ze over naar het andere.
Controleert de voorwaarde.
Kopieert het resultaat.
Verstuurt een bericht.
Wijzigt de status.
Wacht.
Bevestigt.
Draagt de gegevens verder over.
En doet dat tientallen keren per dag.
Er is geen storing.
Er is geen fout.
Het systeem werkt volgens de aannames.
Alleen waren de aannames verkeerd.
Automatisering hoeft niet te betekenen dat er kunstmatige intelligentie aan te pas komt.
Soms is de grootste vorm van automatisering gewoon ervoor zorgen dat systemen niet langer van de mens eisen dat die handmatig informatie tussen hen overdraagt.
Architectuur heeft een directe invloed op hoe lang de gebruiker moet wachten
Op dit punt komen we bij technische kwesties.
Als een applicatie uit meerdere services bestaat, kan elke aanroep vertraging introduceren. Als het systeem telkens opnieuw dezelfde gegevens uit een externe API ophaalt, kan caching worden overwogen. Als een rapport elke keer miljoenen records vanaf nul herberekent, is misschien een andere strategie voor het genereren van gegevens nodig. Als de gebruiker moet wachten op een handeling die niet onmiddellijk hoeft te worden uitgevoerd, kan asynchrone verwerking worden overwogen. Als meerdere processen hetzelfde werk uitvoeren, ligt het probleem misschien in de architectuur.
Juist hier beginnen UX, performance en softwarearchitectuur met elkaar samen te vallen.
De ontwerper ziet het probleem van de gebruiker.
De analist ziet het proces.
De programmeur ziet de code.
De architect ziet de afhankelijkheden.
Een goed systeem moet al deze vier perspectieven met elkaar verbinden.
Niet elke handeling hoeft versneld te worden
Dat is ook belangrijk.
Soms investeert een bedrijf veel geld in het optimaliseren van een handeling die één keer per dag voorkomt.
Ondertussen blijft een andere handeling, uitgevoerd door 50 mensen tientallen keren per dag, praktisch onaangeroerd.
Daarom is het vóór optimalisatie goed om te weten: wat optimaliseren we eigenlijk en voor wie?
Het gaat er niet om dat elk scherm binnen 100 milliseconden opent.
Het gaat erom dat het systeem snel is daar waar snelheid zakelijke waarde heeft.
Als een financieel rapport zich 15 seconden mag genereren, één keer per dag, is dat misschien geen probleem. Als de klantzoekfunctie 4 seconden reageert bij elke handeling van een verkoper, ziet de situatie er heel anders uit.
Performance moet worden beoordeeld in de context van frequentie, kritiekheid en kosten van een gegeven handeling.
Hoe vind je de echte bottleneck?
In plaats van alleen ontwikkelaars te vragen: "Waarom is de applicatie traag?"
is het de moeite waard om bij de gebruikers te beginnen: "Laat me zien hoe je je werk uitvoert."
Niet: "Wat is voor jou onhandig?"
Alleen:
"Laat me zien hoe je een offerte voorbereidt."
"Laat me zien hoe je een klacht afhandelt."
"Laat me zien hoe je een nieuwe klant invoert."
"Laat me zien hoe je een bestelling afsluit."
En dan komen vaak dingen naar voren die je in de code niet ziet.
Excel.
Kladblok.
Tweede monitor.
Gegevens kopiëren.
Handmatig controleren.
Telefoontjes.
Vijf tabbladen openen.
De pagina verversen.
Wachten op een e-mail.
Een collega vragen.
Juist daar bevindt zich vaak de echte bottleneck.
Een goede applicatie reageert niet alleen snel
Een goede applicatie maakt het mogelijk om het werk snel uit te voeren.
Dat is een subtiel, maar fundamenteel verschil.
Je kunt een technisch zeer efficiënte applicatie hebben die van de gebruiker tientallen klikken vereist. Je kunt een mooie interface hebben die een complex proces verbergt. Je kunt een uitstekende architectuur hebben die het echte zakelijke probleem niet oplost. En je kunt een systeem hebben dat technisch gezien geen snelheidsrecord breekt, maar een medewerker in staat stelt om in vijf minuten iets te doen waar eerder een half uur voor nodig was.
Daarom zou een softwarehuis een applicatie niet alleen door de bril van code moeten bekijken.
Code is een middel. Het doel is een soepel draaiende business.
Voordat je de server optimaliseert, meet de mens
Die zin is het waard om te onthouden.
Als gebruikers klagen dat de applicatie traag is, begin dan niet automatisch met het verhogen van de servercapaciteit.
Controleer eerst het hele proces.
Hoeveel tijd kost de taak?
Hoeveel schermen moeten worden doorlopen?
Hoeveel gegevens voert de gebruiker handmatig in?
Hoe vaak typt hij dezelfde informatie opnieuw?
Tussen hoeveel systemen moet hij schakelen?
Hoe vaak wacht hij?
Waarop wacht hij?
Weet hij dat het systeem nog steeds werkt?
Kan een deel van het werk automatisch worden uitgevoerd?
Worden gegevens die we al hebben opnieuw van de mens opgehaald?
Pas dan is het de moeite waard om een niveau dieper te gaan en de API, database, infrastructuur, cache, wachtrijen of de applicatiearchitectuur te controleren.
Want soms ligt het probleem inderdaad in de code.
Maar soms ligt het tussen het scherm en de stoel.
En dan is de beste optimalisatie niet een snellere server.
Maar een beter ontworpen systeem.
Het langzaamste element van jouw applicatie kan een mens zijn.
En de rol van een goed softwarehuis is niet ervoor zorgen dat de mens sneller klikt.
De rol van een goed softwarehuis is ervoor zorgen dat hij minder moet klikken.
