Der er intet login
Den friktion, der afgør, om et system bliver brugt, står sjældent i kravspecifikationen. Den indvending, jeg oftest møder, handler om et login, der aldrig har eksisteret.
Da jeg havde bygget klientportalen, kom den samme indvending igen og igen. Klienterne gider ikke endnu et login.
Det er en helt rimelig indvending mod stort set alt, hvad der bliver bygget i den her kategori. Den er bare faktuelt forkert om det, jeg har lavet, og det er min egen skyld, at den bliver ved med at komme.
Der er intet login. Klienten får en mail, klikker på linket i den, og er inde. Der bliver ikke oprettet en bruger, der bliver ikke valgt et kodeord, og der er ikke noget at glemme til næste gang.
Det hedder et magic link, og ingen kender ordet
Første gang jeg skrev om portalen, nævnte jeg det i en bisætning til sidst. Alle tre, der kommenterede, læste hen over det, og to af dem rejste login som deres hovedindvending.
Én af dem skrev tilbage, at et magic link var et begreb, de aldrig havde hørt om. Det var nyttigt at få at vide, for jeg havde behandlet ordet som noget, alle kendte, og skrevet derefter.
Det er en fejl, jeg tror er meget almindelig lige nu. Man bygger noget, der fjerner et trin, og så beskriver man det med det ord, ens egen branche bruger om mekanismen, i stedet for at beskrive, hvad brugeren slipper for. Læseren skal kunne se sig selv i sætningen, uden først at slå noget op.
Systemet blokerer aldrig
Der er en anden detalje i portalen, som jeg synes er den bedre historie.
Uploader en klient en lønseddel, læser systemet dokumentet og finder selv, hvilken måned den hører til. Også når den ligger på tværs af kalenderen, altså en augustseddel, der kommer ind i juli.
Er systemet i tvivl, ryger dokumentet under "Uden periode". Det bliver stadig modtaget. Uploaden bliver aldrig afvist, fordi maskinen ikke kunne finde ud af det.
Den regel er blevet min standard alle steder, hvor en model tager stilling til noget, et menneske lige har afleveret. Modellen må gerne gætte, og den må gerne sige, at den ikke ved det. Den må aldrig stå i vejen for handlingen. Et system, der afviser en upload, fordi det ikke kunne klassificere den, har flyttet sit eget problem over på den person, der var i gang med at hjælpe.
Friktionen står sjældent i kravspecifikationen
Det, jeg tager med fra hele forløbet, handler om, hvad der egentlig afgør, om et system bliver brugt.
Kravene til en klientportal handler om felter, kategorier, rettigheder og revisionsspor. Alt det er nemt at skrive ned, og det bliver bygget, fordi det står på listen.
Det, der afgør sagen, er derimod, om en travl virksomhedsejer på en telefon i en kø kan komme videre på ét klik. Den slags kommer sjældent på listen, fordi den ikke ligner et krav. Den ligner en detalje.
Jeg har målt det på mig selv. Jeg opgiver et system, i det sekund det beder mig om at oprette en konto for at gøre noget, der ellers ville have taget et øjeblik. Jeg har bare aldrig skrevet det i en kravspecifikation.
Grænsen for, hvad jeg kan påstå
Jeg kan sige, hvad der er bygget. Jeg kan ikke sige, hvor mange klienter der rent faktisk bruger det, for det tal har jeg ikke endnu.
Så det her er en påstand om design, og adoptionen har jeg stadig til gode at måle. Portalen fjerner det trin, jeg tror flest falder på. Om der ligger et andet trin lige efter, som jeg ikke har fået øje på endnu, finder jeg først ud af, når nok mennesker har prøvet.