Den långsammaste delen i din app kan vara... en människa.
När ett företag säger att deras app är långsam är den första reaktionen oftast väldigt teknisk. Man måste kontrollera servern. Databasen. API:t. SQL-frågorna. Cachen. Infrastrukturen. Filstorleken. JavaScript. Svarstiderna för de enskilda tjänsterna.
Och det är helt rätt. Technical performance är oerhört viktigt.
Men ibland ser alla diagram bra ut, servern svarar snabbt, appen laddar inom rimlig tid, och användarna säger ändå: "Det tar för lång tid."
Och då dyker en mer intressant fråga upp. Kanske är appen inte alls långsam. Kanske tvingar den bara människan att vänta.
2 sekunder svarstid, 20 minuter arbete
Låt oss föreställa oss en anställd som måste förbereda ett erbjudande för en kund.
Systemet fungerar smidigt. Varje skärm öppnas snabbt. Inga fel. Servern svarar nästan omedelbart.
Men för att ta fram ett erbjudande måste den anställde: öppna kunden, gå till ordern, kopiera produktnumret, öppna en annan modul, söka upp produkten, skriva in uppgifterna igen, gå tillbaka till den första skärmen, välja kategori, gå till nästa flik, hämta priser, kontrollera rabatten manuellt, kopiera resultatet till Excel och sedan skriva in det igen i systemet.
Varje enskild åtgärd kan ta några sekunder.
Tekniskt sett fungerar allt utmärkt. Men hela processen tar 20 minuter.
Och just här slutar den klassiska förståelsen av prestanda att räcka till.
För användaren bryr sig inte främst om API:ets svarstid. Det som spelar roll är tiden som krävs för att slutföra uppgiften.
Technical performance är bara början
Systemprestanda kan mätas på många sätt.
Vi kan analysera serverns svarstid, laddningstiden för vyn, databasfrågor, minnesanvändning, processorbelastning eller fördröjningar mellan tjänster.
Det är mycket viktiga mätvärden. Men det finns ett andra lager.
Perceived performance, alltså den prestanda som användaren upplever.
Och ännu bredare kan man se på operational performance - alltså hur snabbt och smidigt en människa kan utföra en verklig uppgift med hjälp av systemet.
Och det är just på det sista lagret som företag mycket ofta förlorar mest tid. För man kan bygga en oerhört snabb app som ändå är ett långsamt arbetsverktyg.
Det långsammaste systemet är ibland sju skärmar
Låt oss anta att en anställd hanterar ett reklamationsärende.
Systemet kräver sju steg.
Först att öppna kunden.
Sedan ordern.
Därefter produkten.
Sedan reklamationsformuläret.
Sedan problemkategorin.
Sedan beslutet.
Till sist bekräftelsen.
Varje skärm laddas på 0,5 sekunder.
Ur utvecklarens perspektiv kan allt se mycket bra ut. Men användaren har gjort sju övergångar, bytt sammanhang sju gånger och sju gånger behövt fundera på vad som ska göras härnäst.
Om man gör sådana här moment flera dussin gånger per dag slutar problemet att handla om bekvämlighet. Det blir en kostnad. Och det handlar inte bara om tiden framför skärmen. Det leder också till trötthet, fler misstag, behov av att rätta data, avbrutna uppgifter och ökande belastning på medarbetaren.
Ett formulär med 40 fält är inte snabbt bara för att det öppnas snabbt
Det här är ett klassiskt exempel.
Formuläret öppnas blixtsnabbt. - Toppen.
Men användaren måste fylla i 40 fält.
En del uppgifter har företaget redan.
En del kan hämtas från CRM.
En del kan beräknas.
En del beror på tidigare svar.
Och ändå frågar systemet människan om allt igen.
Då är problemet inte appens performance.
Problemet är process- och gränssnittsdesignen.
Ett bra system bör använda den data det redan har.
Om kunden angav leveransadressen vid en tidigare beställning, varför ska medarbetaren skriva in den igen? Om systemet känner till kundens företag, varför ska användaren välja dess uppgifter på nytt? Om svaret på den första frågan utesluter hälften av de följande fälten, varför visas alla från början?
Ibland är det bästa sättet att snabba upp en app inte att optimera koden. Det är att ta bort arbete som användaren inte borde behöva göra.
Det dyraste är människans tid multiplicerad med skalan
En extra minut kan verka som ingenting.
En medarbetare utför en operation 5 gånger om dagen. - 5 minuter.
På en månad blir det mer än 1,5 timme.
Men vad händer om 20 personer gör det? Vad händer om operationen sker 30 gånger om dagen? Vad händer om hela avdelningen berörs? Vad händer om systemet ska användas i fem år till?
Då slutar en enda minut att vara en minut. Den blir en driftskostnad.
Därför är det värt att fråga inte bara när man designar ett system för ett företag: "Hur lång tid tar serverns svar?"
utan också: "Hur lång tid behöver en människa för att avsluta uppgiften?"
Det är två helt olika frågor.
Systemet kan vara snabbt, men processen långsam
Det här är ett ännu bredare problem.
Låt oss föreställa oss en inköpsprocess i ett företag.
- Medarbetaren skickar in en begäran.
- Systemet sparar den omedelbart.
- Men sedan måste hen vänta på chefens godkännande.
- Chefen får ett meddelande.
- Öppnar systemet.
- Kontrollerar dokumentet.
- Skickar det vidare till ekonomi.
- Ekonomiavdelningen kontrollerar budgeten.
- Sedan måste någon godkänna beställningen.
Tekniskt sett kan appen fungera perfekt. Och processen tar tre dagar.
Kan vi säga att appen är snabb?
Tekniskt - kanske.
Affärsmässigt - medarbetaren väntar i tre dagar.
Och just därför kräver design av affärssystem att man ser bortom själva gränssnittet. Man måste se hela arbetsflödet.
"Vänligen vänta" är också en del av UX
Det finns ytterligare ett intressant fall.
Ibland utför systemet faktiskt en lång operation.
Genererar en rapport.
Bearbetar en stor fil.
Synkroniserar data.
Skickar många poster till ett externt API.
Startar en komplex process.
Det går inte alltid att få det att ta en sekund. Men man kan se till att användaren vet vad som händer.
Det är en enorm skillnad.
Meddelandet: "Laddar..."
är något helt annat än: "Vi förbereder rapporten. 72% av data har bearbetats. Du kan stänga fönstret - rapporten blir klar i bakgrunden."
I det andra fallet får användaren information, kontroll och förutsägbarhet.
Det är just ett av elementen i perceived performance.
Systemet kan fortfarande utföra samma operation i 20 sekunder. Men användarupplevelsen är helt annorlunda.
Det värsta är att vänta utan information
Människan upplever väntan mycket sämre när hen inte vet om systemet ens gör något.
Vi klickar. - Inget.
Vi klickar en gång till. - Fortfarande inget.
Fungerar systemet?
Har det hängt sig?
Behöver man uppdatera?
Skickades formuläret?
Kan vi stänga fönstret?
Det är ögonblicket då användaren börjar kämpa med applikationen.
Och när användaren börjar kämpa med systemet uppstår fler problem.
Uppdatering av sidan.
Att skicka formuläret igen.
Dubbletter.
Samtal till supporten.
Fel.
Onödiga ärenden.
Och tid som andra personer måste lägga...
Därför är det inte någon kosmetisk detalj att informera användaren om operationens status. Det är en del av att designa ett effektivt system.
Och ibland väntar applikationen för människans skull
Det här är nog det mest intressanta fallet.
Systemet kräver att människan utför en uppgift som tekniken skulle kunna utföra automatiskt.
Medarbetaren hämtar data från ett system.
Flyttar dem till ett annat.
Kontrollerar ett villkor.
Kopierar resultatet.
Skickar ett meddelande.
Ändrar status.
Väntar.
Bekräftar.
Flyttar data vidare.
Och gör det här flera dussin gånger om dagen.
Det finns inget driftstopp.
Det finns inget fel.
Systemet fungerar enligt intentionen.
Det är bara det att intentionen var fel.
Automatisering behöver inte betyda artificiell intelligens.
Ibland är den största automatiseringen helt enkelt att se till att systemen slutar kräva att människan manuellt flyttar information mellan dem.
Arkitekturen har en direkt påverkan på hur mycket användaren måste vänta
På det här stadiet kommer vi in på tekniska frågor.
Om applikationen består av många tjänster kan varje anrop skapa fördröjning. Om systemet varje gång hämtar samma data från ett externt API kan man överväga cache. Om en rapport varje gång räknar om miljontals poster från början kan en annan strategi för att generera data behövas. Om användaren måste vänta på en operation som inte behöver utföras direkt kan asynkron bearbetning övervägas. Om flera processer utför samma arbete ligger problemet kanske i arkitekturen.
Det är just här UX, performance och software architecture börjar hänga ihop.
Designern ser användarens problem.
Analytikern ser processen.
Programmeraren ser koden.
Arkitekten ser beroendena.
Ett bra system bör förena alla fyra perspektiven.
Inte varje operation behöver snabba upp
Det är också viktigt.
Ibland investerar ett företag mycket pengar i att optimera en operation som inträffar en gång om dagen.
Samtidigt förblir en annan uppgift, som utförs av 50 personer flera dussin gånger om dagen, praktiskt taget orörd.
Därför är det värt att veta före optimeringen: vad optimerar vi egentligen och för vem?
Det handlar inte om att varje skärm ska öppnas på 100 millisekunder.
Det handlar om att systemet ska vara snabbt där hastighet har affärsmässig betydelse.
Om en finansiell rapport kan genereras i 15 sekunder en gång om dagen är det kanske inget problem. Om kundsökningen svarar på 4 sekunder vid varje säljares operation ser situationen helt annorlunda ut.
Performance bör bedömas i kontexten av frekvens, kritikalitet och kostnad för en given åtgärd.
Hur hittar man den verkliga flaskhalsen?
I stället för att bara fråga utvecklare: "Varför är applikationen långsam?"
är det värt att börja med användarna: "Visa mig hur du utför ditt arbete."
Inte: "Vad är obekvämt för dig?"
Bara:
"Visa mig hur du förbereder ett erbjudande."
"Visa mig hur du hanterar ett reklamationsärende."
"Visa mig hur du registrerar en ny kund."
"Visa mig hur du avslutar en order."
Och då kommer ofta sådant fram som inte syns i koden.
Excel.
Anteckningar.
Andra skärmen.
Kopiering av data.
Manuell kontroll.
Telefonsamtal.
Att öppna fem flikar.
Att uppdatera sidan.
Att vänta på ett mejl.
Att fråga en kollega.
Det är just där den verkliga flaskhalsen ofta finns.
En bra applikation svarar inte bara snabbt
En bra applikation gör det möjligt att utföra arbetet snabbt.
Det är en subtil, men grundläggande skillnad.
Man kan ha en mycket tekniskt effektiv applikation som kräver ett dussintal klick av användaren. Man kan ha ett vackert gränssnitt som döljer en komplicerad process. Man kan ha en utmärkt arkitektur som inte löser det verkliga affärsproblemet. Och man kan ha ett system som tekniskt sett inte är någon hastighetsrekordhållare, men som låter medarbetaren göra något på fem minuter som tidigare tog en halvtimme.
Det är just därför ett software house inte bör se på applikationen enbart genom kodens prisma.
Kod är medlet. Målet är en välfungerande verksamhet.
Innan du optimerar servern, mät människan
Det här är värt att komma ihåg.
Om användarna klagar på att applikationen är långsam, börja inte automatiskt med att öka serverns kapacitet.
Kontrollera först hela processen.
Hur lång tid tar uppgiften?
Hur många skärmar måste man gå igenom?
Hur mycket data matar användaren in manuellt?
Hur många gånger skriver hen in samma information?
Hur många system måste hen växla mellan?
Hur många gånger väntar hen?
Vad väntar hen på?
Vet hen att systemet fortfarande arbetar?
Kan en del av arbetet utföras automatiskt?
Hämtas data som vi redan har in från människan igen?
Först då är det värt att gå ner en nivå och kontrollera API, databas, infrastruktur, cache, köer eller applikationens arkitektur.
För ibland ligger problemet faktiskt i koden.
Men ibland ligger det mellan skärmen och stolen.
Och då är den bästa optimeringen inte en snabbare server.
Det är ett bättre designat system.
Den långsammaste komponenten i din applikation kan vara en människa.
Och ett bra software houses uppgift är inte att få människan att klicka snabbare.
Ett bra software houses uppgift är att se till att hon måste klicka mindre.
