God design af tilmeldings- og loginside handler om fire ting: bed kun om de felter, som godkendelsen rent faktisk kræver, placer login-punktet, hvor folk kan se det, skriv fejlmeddelelser, der fortæller brugerne, hvordan de løser problemet, og giv dem en adgangskode-gendannelse, som de kan finde, selv når de er irriterede. Få styr på det, så er resten bare finpudsning. Gør du det forkert, betaler du fuld pris for trafik, der aldrig når frem til dit produkt. Undersøgelser viser, at 18 % af kunderne opgiver et køb, fordi siden tvinger dem til at oprette en konto, og 17 % gør det, fordi processen er for lang eller kompliceret.
Det er det korte svar. Nedenfor er de femten beslutninger, der rykker ved de tal, hvordan du prioriterer dem, og hvad hver enkelt er værd for din forretning.
Betragt dit anskaffelsesbudget som vand i et rør. Betalt søgning, indhold, outbound, partnerhenvisninger: Alle kanaler føder det samme rør, og det hele ender i ét smalt samlingspunkt, hvor du beder nogen om at oprette en konto. Alt, hvad der lækker dér, har du allerede betalt for.
Lækagen er veldokumenteret. Baymards forskning i checkout-brugervenlighed viser, at det gennemsnitlige amerikanske checkout-flow som standard indeholder 23,48 formularfelter, mens omfattende brugervenlighedstests viser, at et ideelt flow kan nøjes med 12 til 14. Omkring halvdelen af de felter, du beder folk udfylde, gør intet gavn. Og gevinsten er ikke lille: Ved kun at fokusere på de checkout-problemer, der er dokumenteret som løsbare, kan det gennemsnitlige store e-handelssite opnå en stigning i konverteringsraten på 35,26 % gennem bedre checkout-design. På tværs af det samlede amerikanske og europæiske e-handelssalg svarer det til anslået 260 milliarder dollars i genindvundne ordrer.
Er det et designproblem eller et forretningsproblem? Begge dele, og det er netop derfor, det går i stå. For en CEO, CTO eller COO lander det på tre punkter.
Anskaffelsesomkostninger (CAC). Hvis dit registreringsflow konverterer med 40 % i stedet for 55 %, stiger din effektive CAC med mere end en tredjedel. Ingen ændring i annonceforbrug. Ingen ændring i antallet af medarbejdere. Ingen ændring i tragtens volumen ovenover. Du beholder ganske enkelt mindre af det, du har købt.
Konverteringsrate. Registreringsfriktion er et af de sjældne konverteringsproblemer, som du har fuld kontrol over. Ingen prisændringer, ingen nye funktioner, ingen repositionering. Det er et design- og ingeniørmæssigt problem med et målbart loft, hvilket er præcis, hvad en teknisk og UX-audit er til for at kortlægge.
Churn-risiko. En person, der kæmper med tilmeldingen, har allerede dannet sig et indtryk af dit produkt, før de overhovedet har set en eneste funktion. Fejl ved nulstilling af adgangskoder og låste konti skaber supporthenvendelser og tidlige opsigelser. De omkostninger lander hos driften, ikke marketing, hvilket normalt er grunden til, at ingen lægger mærke til dem i konverteringsdebatten.
De fleste råd om login-UX kommer som en flad tjekliste, og det er præcis derfor, teams implementerer dem dårligt. De får de nemme opgaver fra hånden. De vigtige opgaver ender i backloggen, fordi en tjekliste fortæller dig, hvad du skal gøre, men intet siger om, hvad du skal gøre først.
Derfor bruger vi i stedet pointgivning. TSU: Traffic (Trafik), Security (Sikkerhed), User type (Brugertype). Tre akser, hver fra ét til fem, udviklet gennem vores klientopgaver og i tråd med vores bredere produktdesignproces, der bygger på design thinking. Læg dem sammen, og agér ud fra det samlede resultat.
Et flow til nulstilling af adgangskode, som bruges af 2 % af din brugerbase, har ikke samme prioritet som en tilmeldingsformular, som alle nye brugere skal igennem. Find de faktiske tal fra tragten, før du giver point til noget som helst. Teams overinvesterer rutinemæssigt i specialtilfælde, og oftest skyldes det, at disse flows genererer de mest højlydte supporthenvendelser, ikke den største volumen.
Noget friktion er nødvendig. Det er sikkert at fjerne bekræftelse af adgangskode. Det er derimod ikke sikkert at gøre dine fejlmeddelelser skarpere, da "forkert adgangskode" diskret bekræfter over for en angriber, at e-mailen tilhører en rigtig konto. Det halverer arbejdsindsatsen ved et credential-stuffing-angreb (et automatiseret angreb, der genbruger kombinationer af brugernavne og adgangskoder lækket fra andre databrud). Giv 5 point, hvis en ændring er sikkerhedsmæssigt neutral. Giv 1 point, hvis den bytter reel risiko ud med bekvemmelighed.
En forbruger-app optimerer til hastighed og socialt login. En B2B-platform, hvor en administrator opretter konti, optimerer til klarhed, single sign-on og tildeling af roller. Samme ændring, forskellig score, afhængigt af om din bruger selv har valgt at være der, eller om de er blevet bedt om at være der.
| Total | Handling | Typiske udviklingsomkostninger |
|---|---|---|
| 12–15 | Lancér i denne sprint. Høj volumen, lav risiko, tydeligt match. | Timer til 2 dage |
| 8–11 | Planlæg det. Reelle gevinster, men prioriteres efter ovenstående. | 2–5 dage plus gennemgang |
| 4–7 | Drop det. Lav rækkevidde, eller sikkerhedsomkostningerne overstiger gevinsten. | Ikke pladsen værd |
Pointen er ikke selve regnestykket. Pointen er, at pointgivningen rykker sikkerhedsdiskussionen frem til designfasen i stedet for til kodegennemgangen, hvor login-redesigns ofte dør, og hvor omarbejde bliver dyrt.
Hvis brugeren skal lede efter loginområdet, har du skabt friktion, før formularen overhovedet er indlæst. Placer det øverst til højre i headeren, hvor konventionen har lært alle at kigge, og behold det der på hele sitet i stedet for kun på forsiden.
Googles login-skærm er referencepunktet. Ét felt, én klar handling, og links til gendannelse placeret præcis der, hvor en bruger, der sidder fast, vil lede.
TSU: T5 / S5 / U5 = 15. Implementér. Kommercielt: den billigste rettelse på denne liste – en ændring i navigation og CSS, der kan måles i timer, og som påvirker alle besøgende, der vender tilbage.
At tilmelde sig med en eksisterende konto fjerner behovet for at oprette en adgangskode, og det er netop ved oprettelse af adgangskoder, at mange brugere falder fra. Det letter også din egen byrde. Du er ikke længere ansvarlig for at opbevare legitimationsoplysninger, som du ellers skulle beskytte.
Hold listen over udbydere enkel. Forbrugerprodukter bør tilbyde Google og Apple, da Apple kræver sin egen login-mulighed til iOS-apps, der tilbyder tredjeparts-login. B2B-produkter bør prioritere Google Workspace og Microsoft samt SAML SSO (Security Assertion Markup Language single sign-on, den protokol som it-afdelinger i virksomheder bruger til at centralisere medarbejderadgang), hvis du sælger til erhvervskunder. Tilpas listen til dine faktiske brugere frem for blot at kopiere, hvad din nærmeste konkurrent viser.
TSU: T5 / S4 / U4 = 13. Implementér. Kommercielt: fjerner et trin for alle nye brugere og reducerer permanent antallet af supporthenvendelser vedrørende nulstilling af adgangskoder. Træk et point fra på sikkerhedsaksen, hvis du håndterer regulerede data, hvor brug af en identitetsudbyder kræver en særskilt vurdering.
Hvis en bruger taster blindt med Caps Lock aktiveret, vil de fejle, prøve igen, fejle igen og ende i dit flow for nulstilling af adgangskode. Det koster dem tid og koster dig en supporthenvendelse – alt sammen på grund af en tastaturstatus, du kunne have gjort dem opmærksom på. GitHubs loginside viser en advarsel om, at "Caps Lock er aktiveret", og det kræver kun få linjers JavaScript.
TSU: T4 / S5 / U4 = 13. Implementér. Kommercielt: en halv dags arbejde for at undgå en tilbagevendende og fuldstændig undgåelig supportomkostning.
"Sign in", "log in", "login" og "log on" betyder det samme. At blande dem i ét produkt skaber en lille tvivl, der gentages ved hvert kontaktpunkt. Vælg ét udtryk og hold fast i det, også for den modsatte handling: Hvis du bruger "sign in", så brug "sign out", aldrig "logout".
Det er værd at give videre til dine udviklere, da dette ofte smutter. "Login" er et navneord, som i "loginsiden". "Log in" er et udsagnsord, som i "log in på din konto". At bruge det forkert i interfacet virker sjusket over for netop det tekniske publikum, som du mindst ønsker skal tænke sådan.
TSU: T5 / S5 / U3 = 13. Implementér det. Kommercielt: næsten nul i udviklingsomkostninger, og det forstærker alle andre tillidssignaler på siden.
Løbende validering forhindrer, at brugeren sender en formular, for derefter at opdage, at noget var galt tre felter tilbage. Udløs valideringen, når brugeren forlader et felt i stedet for ved hvert tastetryk, og fortæl dem, hvordan de løser problemet, frem for blot at markere, at der er en fejl.
Så er der fejlmeddelelsen ved login, hvor god UX og god sikkerhed trækker i hver sin retning. "Forkert adgangskode" hjælper brugeren. Det bekræfter dog også over for en angriber, at e-mailen tilhører en rigtig konto, hvilket halverer arbejdet ved et credential-stuffing-angreb. "Ugyldig e-mail eller adgangskode" er det rette kompromis. Beskyttelse mod enumeration – altså at forhindre angribere i at finde ud af, hvilke e-mailadresser der har konti – er mere værd end den smule klarhed, man giver afkald på.
TSU: T5 / S2 / U4 = 11. Planlæg det, og inddrag sikkerhed i copy-reviewet. Dette punkt har mest brug for modellen, fordi designmæssige og sikkerhedsmæssige prioriteter ofte er i modstrid. Kommercielt: pointgivningen er det, der forhindrer, at denne uenighed sætter hele dit redesign på pause i 14 dage.
Overrask ikke brugeren med adgangskoderegler, efter de allerede har fejlet. Placer kravene ved siden af feltet fra start, og valider dem løbende, mens brugeren skriver.
To fælder her. For det første regler, der er så komplekse, at alle ender med at bruge det samme svage, men godkendte mønster. For det andet tvungen periodisk udskiftning, hvilket nu officielt frarådes. NIST Special Publication 800-63B-4, det amerikanske National Institute of Standards and Technologys retningslinjer for digital identitet, færdiggjort den 31. juli 2025, fastslår, at systemer ikke må kræve periodisk udskiftning, medmindre der er bevis for, at adgangskoden er kompromitteret. Skiftet fra "bør ikke" i 2017-udgaven til "må ikke" gør det fra en anbefaling til et krav. Begrundelsen er velkendt for alle, der har haft en arbejdscomputer: tvungen udskiftning skaber forudsigelige, trinvise adgangskoder, hvor "Password1!" bliver til "Password2!". Et forbehold: hvor specifik lovgivning som PCI-DSS strider mod NIST-vejledningen, har lovgivningen forrang.
TSU: T5 / S5 / U4 = 14. Implementér det. Kommercielt: at droppe udskiftning reducerer antallet af nulstillinger og fjerner tilbagevendende friktion for betalende kunder uden sikkerhedsmæssige omkostninger under de nuværende retningslinjer.
Feltet til bekræftelse af adgangskode er et forældet mønster, der skaber netop den fejl, det var bygget til at forhindre. Indtastningerne matcher ikke, brugeren kan ikke se nogen af dem, og nu skal de slette begge og starte forfra uden at vide, hvilken der var forkert. Genialt.
En vis/skjul-knap løser det hurtigere. Folk kan tjekke, hvad de har skrevet, og rette det med det samme, præcis som de fleste moderne forbrugerplatforme tillader i dag.
TSU: T5 / S4 / U4 = 13. Implementér det. Kommercielt: ét felt mindre og én fejlkilde mindre på din mest trafikerede formular.
Hvis en bruger kan tilmelde sig via flere veje – gratis eller betalt, privat eller erhverv – skal knappen tydeligt angive, hvad den fører til. "Tilmeld" fortæller intet, når to knapper deler skærmen. "Start gratis prøveperiode" og "Køb Pro" fortæller dem alt.
TSU: T4 / S5 / U4 = 13. Implementér det. Kommercielt: dette ændrer din fordeling af abonnementsniveauer, hvilket øger omsætningen pr. tilmelding frem for blot antallet af tilmeldinger.
En tilbagevendende kunde, der lander på tilmeldingsformularen, og en ny besøgende, der lander på login-siden, har det samme problem, bare i hver sin retning. Begge har brug for en synlig vej videre, med det samme. Differentier de to tilstande gennem layout og tekst – det samme princip, der styrer et vellykket website-redesign – og gør skiftet muligt med et enkelt klik uden at genindlæse siden.
TSU: T5 / S5 / U4 = 14. Udgiv det. Kommercielt: Tilbagevendende brugere er omsætning, du allerede har. At miste dem ved døren koster mere end at miste en potentiel kunde, som aldrig har haft en relation til dig.
Brugernavne giver dine brugere et hukommelsesproblem, de aldrig har bedt om. De glemmer, hvilken variant de registrerede sig med, og fejlmeddelelser om optagede brugernavne tilføjer et fejlpunkt til en formular, der ellers ikke havde nogen.
E-mail fungerer både som identifikator og gendannelseskanal, og den giver dig en legitim vej tilbage til brugeren til onboarding og re-engagement. Naturligvis under forudsætning af samtykke i henhold til GDPR, EU's generelle forordning om databeskyttelse, hvilket for europæiske virksomheder ikke er et spørgsmål om præference.
TSU: T5 / S4 / U4 = 13. Udgiv det. Kommercielt: ét felt fjernet, én fejltilstand fjernet, én marketingkanal vundet.
Folk glemmer deres adgangskoder. Det er ikke en designfejl, der skal løses teknisk, men almindelig menneskelig adfærd, som dit produkt bør håndtere elegant. Placer nulstillingslinket direkte på login-siden, send e-mailen afsted på få sekunder, og send brugeren tilbage til, hvor de kom fra, i stedet for at dumpe dem på forsiden, så de skal starte forfra.
Vær opmærksom på sikkerheden. "Vi har sendt et nulstillingslink, hvis kontoen findes" omgår det samme enumerationsproblem fra tip 5.
TSU: T3 / S4 / U4 = 11. Planlæg det. Kommercielt: lavere trafik end ved tilmelding, men dette flow rammer i høj grad tilbagevendende betalende kunder. Prioritér det højere, hvis abonnementer er dit fundament.
Femten felter på én skærm føles som arbejde. De samme femten felter fordelt på tre navngivne trin med en statuslinje føles overskueligt, og det giver dig mulighed for at oprette en brugbar konto efter første trin i stedet for at miste det hele, når nogen giver op ved felt elleve.
Endnu bedre: Bed kun om det, der er nødvendigt for at oprette kontoen, og indsaml resten, når brugeren har set værdien af produktet. Alt, hvad der ikke er godkendelse, hører til i onboarding og produktdesign, ikke ved indgangen.
TSU: T5 / S5 / U4 = 14. Udgiv det. Kommercielt: Delvis indsamling af data alene genvinder en andel af de afbrudte registreringer, som ellers ville være gået helt tabt.
Lad folk selv beslutte, om de vil forblive logget ind, i stedet for at beslutte det for dem. På en delt eller offentlig computer har de brug for at kunne fravælge det. På deres egen bærbare vil de med glæde vælge det til. Lad feltet være umarkeret som standard, og beskriv det med klare ord.
TSU: T4 / S3 / U4 = 11. Planlæg det. Kommercielt: Sessionens varighed er en reel risikovurdering, især når det drejer sig om finansielle eller sundhedsmæssige data. Vurdér dette punkt sammen med din compliance-ansvarlige med det samme, ikke bagefter.
Mobil er der, hvor størstedelen af registreringerne nu sker, og hvor de fleste går tabt. Baymards data om afbrudte køb viser, at raterne på mobil er væsentligt højere end på desktop, og login-formularer er blandt de værste syndere, fordi fejlkilderne hober sig op: små knapper, et tastatur, der dækker halvdelen af skærmen, og indtastning af adgangskode uden en password-manager til hjælp.
Fire rettelser giver det største udbytte. Indstil de korrekte input-typer, type="email" og type="tel", så det rigtige tastatur vises i stedet for, at brugerne skal lede efter @-symbolet. Indstil autocomplete-attributter som email, current-password og new-password, så browserens og adgangskodehåndteringens autofyld rent faktisk virker. Overhold et minimumskrav for berøringsflader på 24x24 CSS-pixels i henhold til WCAG 2.2 succeskriterium 2.5.8 Målområde (minimum). Og tjek, at din primære knap ikke gemmer sig bag skærmtastaturet, så snart et felt får fokus.
TSU: T5 / S5 / U4 = 14. Send det ud. Kommercielt set er dette den største volumenmulighed for de fleste forbrugerprodukter, og det er den, teams oftest overser, fordi de tester på den stationære computer, de sidder ved.
Tilgængelighed i login- og tilmeldingsformularer er både et konverteringsproblem og en juridisk risiko. I henhold til European Accessibility Act, som har været gældende siden 28. juni 2025, er det et lovkrav for mange produkter, der sælges i EU. De relevante WCAG 2.2 succeskriterier er specifikke og målbare, hvilket gør dette lettere at implementere end det meste andet compliance-arbejde.
Labels, ikke pladsholdere (1.3.1, 3.3.2). Alle inputfelter skal have en programmatisk tilknyttet label. Pladsholdertekst forsvinder i det øjeblik, nogen begynder at skrive, hvilket efterlader brugere af skærmlæsere og alle, der har mistet overblikket, uden vejledning.
Fejl skal identificeres og forklares (3.3.1, 3.3.3). Beskeder skal navngive problemet og foreslå en løsning, og de skal være tilgængelige for hjælpemidler. At gøre feltet rødt er ikke en fejlmeddelelse.
Tilgængelig godkendelse (3.3.8). At blokere for indsættelse af tekst eller bruge scripts, der forhindrer browsere og adgangskodehåndteringsværktøjer i at udfylde felter, overtræder dette kriterium, da det at skulle huske eller afskrive en adgangskode udgør en meget stor eller umulig byrde for personer med visse kognitive handicap. Læs det to gange, hvis dit sikkerhedsteam i øjeblikket blokerer for indsættelse i adgangskodefelter. Den kontrol er nu en overtrædelse af WCAG.
Kontrast og tastaturbetjening (1.4.3, 2.1.1). Hele formularen skal kunne udfyldes udelukkende ved brug af tastatur, med synlige fokusmarkeringer og en tekstkontrast på mindst 4,5:1.
TSU: T5 / S5 / U5 = 15. Send det afsted. Kommercielt set: det eneste punkt på denne liste, der medfører direkte regulatorisk eksponering. Det hjælper også brugere med ældre enheder, revnede skærme og i skarpt sollys, hvilket er en langt større gruppe, end de fleste teams antager.
Fire beslutninger og én metode. Bed om mindre, hvilket betyder de absolut nødvendige felter til godkendelse, mens alt andet udskydes til senere i produktet. Gør stierne tydelige, hvilket betyder et synligt indgangspunkt til loginside, et klart skift mellem tilmelding og login, samt et gendannelseslink, som folk kan finde, selv når de er frustrerede. Håndter fejl elegant, hvilket betyder inline-validering, der forklarer løsningen, en vis-adgangskode-knap i stedet for et bekræftelsesfelt, og loginfejl, der er bevidst uklare, så angribere ikke får en liste over gyldige konti. Design til mobil og hjælpemidler først, da det er her, størstedelen af trafikken ligger, og hvor det juridiske ansvar også er størst.
Metoden er TSU. Giv hver ændring en score baseret på Traffic, Security og User type, og udgiv derefter i rækkefølge efter score. Den eksisterer, fordi det, der får redesigns af login til at fejle, næsten aldrig er manglende kendskab til best practice. Det er teams, der udgiver de nemme gevinster, mens det volumen-tunge og sikkerhedskritiske arbejde går i stå i review. Baymards konklusion om, at løsbare problemer med brugervenlighed ved checkout repræsenterer en gennemsnitlig stigning i konvertering på 35,26 %, giver kun pote for teams, der prioriterer arbejdet og rent faktisk får det udgivet.
Start med én formular: et felt til e-mail og et felt til adgangskode, begge med synlige etiketter og korrekte autocomplete-attributter. Tilføj en enkelt primær knap, et synligt link til nulstilling og en tydelig vej til tilmeldingsformularen for folk uden en konto. Placer sociale loginmuligheder eller SSO over formularen, hvis dine brugere forventer det. Håndter derefter fejl: en generisk "ugyldig kombination af e-mail eller adgangskode", en advarsel om Caps Lock og hastighedsbegrænsning ved gentagne forsøg. Alt derudover er blot finpudsning.
Som minimum et e-mailfelt, et adgangskodefelt med synlige krav og en vis/skjul-knap samt én tydeligt markeret send-knap. Tilføj socialt login, hvis det passer til din målgruppe, et synligt link til dine vilkår og privatlivspolitik samt en vej tilbage til loginsiden for tilbagevendende brugere. Udelad alt, der ikke har med godkendelse at gøre. Virksomhedsstørrelse, jobtitel og telefonnummer hører til i onboarding-processen, efter kontoen er oprettet.
Så få som godkendelsen kræver, hvilket ofte er e-mail og adgangskode eller én knap til socialt login. Baymard fandt ud af, at det gennemsnitlige checkout-flow i USA viser 23,48 formularfelter, selvom et ideelt flow kan nøjes med 12 til 14. Hvert ekstra felt er et punkt, hvor brugeren kan gå i stå. Når en interessent beder om et ekstra felt, så spørg, hvad der går galt, hvis den data først ankommer en uge senere inde fra selve produktet.
I denne rækkefølge: skær felter ned til det absolut nødvendige for godkendelse, tilføj socialt login eller SSO, opdel det resterende i navngivne trin med en statusindikator, ret inputtyper og autofyld til mobil, og omskriv fejlmeddelelser, så de forklarer løsningen. Mål derefter tragten, så du kan se, hvilken ændring der påvirkede hvilket tal. De fleste teams implementerer alle fem på én gang og lærer intet om, hvad der rent faktisk gjorde en forskel.
Direkte, og det kan måles. Baymard fandt ud af, at 18 % af kunderne opgiver købet, fordi siden kræver oprettelse af en konto, og 17 % fordi processen er for lang eller kompliceret. Registrering ligger lige i slutningen af anskaffelsestragten, så frafald her spilder penge, du allerede har brugt tidligere i processen. Det er grunden til, at det normalt giver et bedre afkast pr. ingeniørtime end optimering længere oppe i tragten.
Funktionelt er der ingen forskel. De beskriver den samme handling. Forskellen er grammatisk og handler om konsistens. "Login" er et navneord, som i "loginsiden". "Log in" er udsagnsordet, som i "log ind på din konto". "Sign in" fungerer som en verbalfrase, med "sign-in" som navneordsformen. Vælg én konvention, brug den overalt, og glem ikke den tilhørende formulering for log-ud.
Nej. En vis/skjul-knap gør det samme med mindre friktion. Når bekræftelsesfelter ikke stemmer overens, kan brugerne ikke se nogen af indtastningerne, så de taster begge dele forfra uden nogensinde at lære, hvilken af dem der var forkert.
For de fleste B2B-produkter, ja, forudsat at du bruger udbydere, der er egnede til erhvervsbrug. Google Workspace og Microsoft Entra tilbyder stærkere godkendelse end de fleste interne adgangskodesystemer, herunder tvungen multifaktor-godkendelse og centraliseret adgangsspærring den dag, en medarbejder stopper. For regulerede brancher eller store virksomhedskunder er SAML SSO ofte et indkøbskrav snarere end en valgfri ekstra funktion.
Indstil korrekte inputtyper, så det rigtige tastatur vises. Indstil autocomplete-attributter, så adgangskodeadministratorer kan udfylde felterne. Overhold minimumskravet for berøringsflader på 24x24 CSS-pixels fra WCAG 2.2 kriterium 2.5.8. Og tjek, at send-knappen ikke bliver skjult bag skærmtastaturet, når et felt får fokus. Test på en rigtig telefon, ikke en emulator, da tastaturadfærd er præcis det, emulatorer gør forkert.
Mål tre ting: frafaldet mellem visning af login-side og gennemført godkendelse, forholdet mellem anmodninger om nulstilling af adgangskode og aktive sessioner, samt andelen af registreringer, der afbrydes efter første felt. Segmentér efter enhed, da frafald på mobil typisk er væsentligt højere end på desktop, og det er ofte her, dit potentiale for genvinding ligger. Der findes ingen universel standard for en sund rate for nulstilling af adgangskoder. Det, der betyder noget, er din egen tendenslinje, og hvordan den ændrer sig, når du foretager justeringer.
Hvis jeres tilmeldings- eller loginside mister konverteringer, er første skridt at finde ud af hvor og hvor meget. Vi starter med en UX-audit af jeres nuværende registreringsflow: Vi kortlægger tragten fra første visning til gennemført godkendelse, finder de specifikke frafaldspunkter og sammenligner jeres gennemførelsesrater med lignende produkter i jeres branche.
Du får en prioriteret liste vurderet ud fra TSU-modellen. Hvad der skal ændres, i hvilken rækkefølge, hvad hver rettelse er værd i forhold til jeres nuværende CAC, og hvad det koster at bygge. Den sidste del er vigtig, fordi den gør det muligt at vurdere login-arbejdet op mod alt andet, der kæmper om pladsen i samme sprint, frem for at diskutere det som et spørgsmål om smag. Ikke en rapport til skrivebordsskuffen. En backlog, som jeres udviklere kan gå i gang med på mandag.
Book et opkald med vores UX/UI-design- og produktteam for at gennemgå jeres nuværende flow.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Ung UX/UI-designer brænder for detaljer og menneskelig adfærd, der elsker at lære noget nyt hver dag.
People who read this post, also found these interesting:
