Det langsomste element i din app kan være... et menneske.
Når en virksomhed siger, at deres app er langsom, er den første reaktion som regel meget teknisk. Man skal tjekke serveren. Databasen. API’et. SQL-forespørgsler. Cache. Infrastruktur. Filstørrelser. JavaScript. Svartiden for de enkelte tjenester.
Og med god grund. Teknisk performance er af enorm betydning.
Men nogle gange ser alle grafer fine ud, serveren svarer hurtigt, appen indlæses på rimelig tid, og brugerne siger stadig: "Det tager for lang tid."
Og så opstår et mere interessant spørgsmål. Måske er appen slet ikke langsom. Måske tvinger den bare mennesket til at vente.
2 sekunders svartid, 20 minutters arbejde
Lad os forestille os en medarbejder, der skal forberede et tilbud til en kunde.
Systemet fungerer fint. Hver skærm åbner hurtigt. Der er ingen fejl. Serveren svarer næsten øjeblikkeligt.
Men for at forberede tilbuddet skal medarbejderen: åbne kunden, gå til ordren, kopiere produktnummeret, åbne et andet modul, finde produktet, indtaste dataene igen, vende tilbage til den første skærm, vælge kategori, gå til den næste fane, hente priser, manuelt kontrollere rabatten, kopiere resultatet til Excel og derefter indtaste det igen i systemet.
Hver enkelt handling kan tage et par sekunder.
Teknisk set fungerer alt glimrende. Bare hele processen tager 20 minutter.
Og netop her bliver den klassiske forståelse af performance ikke længere tilstrækkelig.
For brugeren er det ikke først og fremmest API’ets svartid, der er interessant. Det, der betyder noget, er den tid, det tager at udføre opgaven.
Teknisk performance er kun begyndelsen
Systemets performance kan måles på mange måder.
Vi kan analysere serverens svartid, indlæsningstiden for visningen, databaseforespørgsler, hukommelsesforbrug, CPU-belastning eller forsinkelser mellem tjenester.
Det er meget vigtige metrikker. Men der findes endnu et lag.
Perceived performance, altså den performance, som brugeren oplever.
Og i endnu bredere forstand kan man se på operational performance - altså hvor hurtigt og effektivt et menneske kan udføre en reel opgave ved hjælp af systemet.
Og netop på det sidste lag mister virksomheder meget ofte mest tid. For man kan bygge en ekstremt hurtig applikation, som stadig vil være et langsomt arbejdsredskab.
Det langsomste system er nogle gange syv skærmbilleder
Lad os antage, at en medarbejder håndterer en reklamation.
Systemet kræver syv trin.
Først åbning af kunden.
Derefter ordren.
Så produktet.
Senere reklamationsformularen.
Derefter problemkategorien.
Så afgørelsen.
Til sidst bekræftelsen.
Hver skærm indlæses på 0,5 sekunder.
Set fra udviklerens perspektiv kan alt se rigtig godt ud. Men brugeren har foretaget syv skift, skiftet kontekst syv gange og har syv gange måttet tænke over, hvad der nu skal gøres.
Hvis man udfører den slags handlinger flere dusin gange om dagen, er problemet ikke længere et spørgsmål om bekvemmelighed. Det bliver til en omkostning. Og det handler ikke kun om tiden foran skærmen. Der kommer træthed, flere fejl, behov for at rette data, afbrudte opgaver og stigende belastning på medarbejderen.
En formular med 40 felter er ikke hurtig, bare fordi den åbner hurtigt
Det er et af de klassiske eksempler.
Formularen åbner lynhurtigt. - Fint.
Men brugeren skal udfylde 40 felter.
Noget af informationen har virksomheden allerede.
Noget kan hentes fra CRM.
Noget kan udregnes.
Noget afhænger af tidligere svar.
Og alligevel spørger systemet mennesket om det hele igen.
Så er problemet ikke appens performance.
Problemet er processens og grænsefladens design.
Et godt system bør udnytte de data, det allerede har.
Hvis kunden opgav leveringsadressen ved en tidligere ordre, hvorfor skal medarbejderen så indtaste den igen? Hvis systemet kender kundens virksomhed, hvorfor skal brugeren så vælge dens data igen? Hvis svaret på det første spørgsmål udelukker halvdelen af de næste felter, hvorfor er alle så synlige fra starten?
Nogle gange er den bedste måde at gøre appen hurtigere på ikke at optimere koden. Det er at fjerne det arbejde, som brugeren ikke bør udføre.
Den dyreste ting er menneskets tid ganget med skalaen
Et ekstra minut kan virke som ingenting.
Medarbejderen udfører handlingen 5 gange om dagen. - 5 minutter.
På en måned bliver det til over 1,5 time.
Men hvad hvis 20 personer gør det? Hvad hvis handlingen forekommer 30 gange om dagen? Hvad hvis det gælder hele afdelingen? Hvad hvis systemet skal bruges i de næste fem år?
Så holder det enkelte minut op med at være et minut. Det bliver til en driftsomkostning.
Derfor er det værd, når man designer et system for en virksomhed, ikke kun at spørge: "Hvor lang tid tager serverens svar?"
men også: "Hvor lang tid har et menneske brug for til at afslutte opgaven?"
Det er to helt forskellige spørgsmål.
Systemet kan være hurtigt, og processen langsom
Det er et endnu bredere problem.
Lad os forestille os en indkøbsproces i en virksomhed.
- Medarbejderen indsender en anmodning.
- Systemet gemmer den med det samme.
- Men bagefter skal vedkommende vente på lederens godkendelse.
- Lederen modtager en besked.
- Åbner systemet.
- Kontrollerer dokumentet.
- Sender det videre til økonomi.
- Økonomi kontrollerer budgettet.
- Derefter skal nogen godkende ordren.
Teknisk set kan appen fungere perfekt. Og processen varer tre dage.
Kan vi sige, at appen er hurtig?
Teknisk - måske.
Forretningmæssigt - medarbejderen venter tre dage.
Og netop derfor kræver design af forretningssystemer, at man ser ud over selve grænsefladen. Man skal se hele arbejdsflowet.
"Vent venligst" er også en del af UX
Der er endnu et interessant tilfælde.
Nogle gange udfører systemet faktisk en lang operation.
Genererer en rapport.
Behandler en stor fil.
Synkroniserer data.
Sender mange poster til et eksternt API.
Starter en kompleks proces.
Det er ikke altid muligt at få det til at tage ét sekund. Men man kan sørge for, at brugeren ved, hvad der sker.
Det er en enorm forskel.
Beskeden: "Indlæser..."
er noget helt andet end: "Vi forbereder rapporten. 72% af dataene er behandlet. Du kan lukke vinduet - rapporten vil være klar i baggrunden."
I det andet tilfælde får brugeren information, kontrol og forudsigelighed.
Det er netop et af elementerne i perceived performance.
Systemet kan stadig udføre den samme operation i 20 sekunder. Men brugeroplevelsen er helt anderledes.
Det værste er at vente uden information
Mennesket opfatter ventetid meget dårligere, når man ikke ved, om systemet overhovedet laver noget.
Vi klikker. - Intet.
Vi klikker igen. - Stadig intet.
Virker systemet?
Er det gået i stå?
Skal man opdatere?
Er formularen blevet sendt?
Kan vi lukke vinduet?
Det er det øjeblik, hvor brugeren begynder at kæmpe med applikationen.
Og når brugeren begynder at kæmpe med systemet, opstår der flere problemer.
Opdatering af siden.
Afsendelse af formularen igen.
Dubletter.
Opkald til support.
Fejl.
Unødvendige henvendelser.
Og tid brugt af andre personer...
Derfor er det ikke en kosmetisk tilføjelse at informere brugeren om operationens status. Det er en del af at designe et effektivt system.
Og nogle gange venter applikationen på mennesket
Det er nok det mest interessante tilfælde.
Systemet kræver, at mennesket udfører en handling, som teknologien kunne udføre automatisk.
Medarbejderen henter data fra et system.
Flytter dem til et andet.
Tjekker en betingelse.
Kopierer resultatet.
Sender en besked.
Ændrer status.
Venter.
Bekræfter.
Flytter data videre.
Og gør det adskillige dusin gange om dagen.
Der er ingen fejl.
Der er ingen fejlmelding.
Systemet fungerer i overensstemmelse med antagelserne.
Det er bare antagelserne, der var forkerte.
Automatisering behøver ikke betyde kunstig intelligens.
Nogle gange er den største automatisering bare at få systemerne til at holde op med at kræve, at mennesket manuelt flytter information mellem dem.
Arkitekturen har direkte indflydelse på, hvor meget brugeren venter
På dette stadie kommer vi ind på de tekniske spørgsmål.
Hvis applikationen består af mange tjenester, kan hvert kald tilføre forsinkelse. Hvis systemet hver gang henter de samme data fra et eksternt API, kan man overveje cache. Hvis en rapport hver gang genberegner millioner af poster fra bunden, er der måske behov for en anden strategi til at generere data. Hvis brugeren skal vente på en operation, der ikke behøver at blive udført med det samme, kan man overveje asynkron behandling. Hvis flere processer udfører det samme arbejde, ligger problemet måske i arkitekturen.
Det er netop her, UX, performance og softwarearkitektur begynder at hænge sammen.
Designeren ser brugerens problem.
Analytikeren ser processen.
Udvikleren ser koden.
Arkitekten ser afhængighederne.
Et godt system bør forene alle fire perspektiver.
Man behøver ikke at fremskynde hver eneste operation
Det er også vigtigt.
Nogle gange investerer virksomheden mange penge i at optimere en operation, der forekommer én gang om dagen.
Imens forbliver en anden handling, udført af 50 personer adskillige dusin gange om dagen, praktisk talt uberørt.
Derfor er det værd at vide før optimering: hvad optimerer vi egentlig, og for hvem?
Det handler ikke om, at hver skærm skal åbne på 100 millisekunder.
Det handler om, at systemet skal være hurtigt der, hvor hastighed har forretningsmæssig betydning.
Hvis en finansrapport kan genereres i 15 sekunder én gang om dagen, er det måske ikke et problem. Hvis kundesøgemaskinen svarer i 4 sekunder ved hver handling for en sælger, ser situationen helt anderledes ud.
Performance bør vurderes i konteksten af hyppighed, kritikalitet og omkostning ved den pågældende handling.
Hvordan finder man den virkelige flaskehals?
I stedet for kun at spørge udviklerne: "Hvorfor er applikationen langsom?"
er det værd at begynde med brugerne: "Vis mig, hvordan du udfører dit arbejde."
Ikke: "Hvad er besværligt for dig?"
Kun:
"Vis mig, hvordan du forbereder et tilbud."
"Vis mig, hvordan du håndterer en reklamation."
"Vis mig, hvordan du opretter en ny kunde."
"Vis mig, hvordan du afslutter en ordre."
Og så dukker der ofte ting op, som ikke er synlige i koden.
Excel.
Notesblok.
Anden skærm.
Kopiering af data.
Manuel kontrol.
Telefonopkald.
Åbning af fem faner.
Opdatering af siden.
Vente på en e-mail.
Spørge en kollega.
Det er netop der, den virkelige flaskehals ofte ligger.
En god applikation svarer ikke bare hurtigt
En god applikation gør det muligt at udføre arbejdet hurtigt.
Det er en subtil, men fundamental forskel.
Man kan have en meget teknisk effektiv applikation, som kræver et dusin klik fra brugeren. Man kan have et smukt interface, som skjuler en kompliceret proces. Man kan have en fremragende arkitektur, som ikke løser det reelle forretningsproblem. Og man kan have et system, som teknisk set ikke er nogen hastighedsrekord, men som lader medarbejderen gøre noget på fem minutter, som tidligere tog en halv time.
Derfor bør et softwarehus ikke se på applikationen udelukkende gennem kodens prisme.
Koden er midlet. Målet er en velfungerende forretning.
Før du optimerer serveren, så mål mennesket
Den sætning er værd at huske.
Hvis brugerne klager over, at applikationen er langsom, så begynd ikke automatisk med at øge serverens kapacitet.
Tjek hele processen først.
Hvor lang tid tager opgaven?
Hvor mange skærme skal man igennem?
Hvor mange data indtaster brugeren manuelt?
Hvor mange gange omskriver han de samme oplysninger?
Hvor mange systemer skal han skifte imellem?
Hvor mange gange venter han?
Hvad venter han på?
Ved han, at systemet stadig arbejder?
Kan en del af arbejdet udføres automatisk?
Bliver de data, vi allerede har, indsamlet igen fra mennesket?
Først derefter giver det mening at gå et niveau dybere og tjekke API'et, databasen, infrastrukturen, cache, køer eller applikationens arkitektur.
For nogle gange ligger problemet faktisk i koden.
Men nogle gange ligger det mellem skærmen og stolen.
Og så er den bedste optimering ikke en hurtigere server.
Det er et bedre designet system.
Det langsomste element i din applikation kan være et menneske.
Og en god softwarehus' rolle er ikke at få mennesket til at klikke hurtigere.
En god softwarehus' rolle er at sørge for, at det skal klikke mindre.
