Written by:
Last Published:
21 juli 2026
•
Bra design av registrerings- och inloggningssida handlar om fyra saker: be om så få fält som autentiseringen faktiskt kräver, placera inloggningspunkten där folk ser den, skriv felmeddelanden som talar om för användarna hur de löser problemet, och ge dem en väg för lösenordsåterställning som de kan hitta även när de är irriterade. Får du till dessa är resten bara finputsning. Gör du fel betalar du fullt pris för trafik som aldrig når din produkt. Studier visar att 18 % av kunderna avbryter ett köp för att webbplatsen tvingar dem att skapa ett konto, och 17 % för att processen är för lång eller komplicerad.
Det är det korta svaret. Nedan följer de femton beslut som påverkar dessa siffror, hur de bör sekvenseras och vad varje beslut är värt för din verksamhet.
Se din anskaffningsbudget som vatten i ett rör. Betald sökning, innehåll, utgående försäljning, partnerhänvisningar: varje kanal matar samma rör, och allt når en smal skarv där du ber någon att skapa ett konto. Allt som läcker ut där har du redan betalat för.
Läckaget är väldokumenterat. Baymards forskning om användarvänlighet i kassan visade att det genomsnittliga kassaflödet i USA innehåller 23,48 formulärelement som standard, medan storskaliga användartester visar att ett idealiskt flöde kan vara så kort som 12 till 14. Ungefär hälften av fälten du ber folk att fylla i gör ingen nytta. Och vinsten är inte liten: genom att bara fokusera på de problem med användarvänlighet i kassan som dokumenterats som lösbara, kan den genomsnittliga stora e-handelssajten öka sin konverteringsgrad med 35,26 % genom bättre kassadesign, vilket för den kombinerade e-handeln i USA och EU motsvarar uppskattningsvis 260 miljarder dollar i återvinningsbara ordrar.
Är det ett designproblem eller ett affärsproblem? Både och, och det är precis därför det stannar av. För en VD, CTO eller COO landar det på tre punkter.
Kundanskaffningskostnad. Om ditt registreringsflöde konverterar till 40 % istället för 55 %, stiger din effektiva CAC med mer än en tredjedel. Ingen ändring i annonsutgifter. Ingen ändring i personalstyrka. Ingen ändring i trattvolymen ovanför. Du behåller helt enkelt mindre av det du köpt.
Konverteringsgrad. Registreringsfriktion är ett av de få konverteringsproblem som ligger helt inom din kontroll. Ingen prisändring, ingen ny funktion, ingen ompositionering. Det är ett design- och teknikproblem med ett mätbart tak, vilket är precis vad en teknisk och UX-revision är till för att fastställa.
Churn-risk. Någon som kämpar med registreringen har redan bildat sig en uppfattning om din produkt innan de sett en enda funktion. Misslyckade lösenordsåterställningar och utlåsta konton skapar supportärenden och tidiga uppsägningar. Dessa kostnader landar på driftavdelningen, inte marknadsföringen, vilket oftast är anledningen till att ingen lägger märke till dem i konverteringsdiskussionen.
De flesta råd om UX för inloggning presenteras som en enkel checklista, och det är precis därför team implementerar dem dåligt. De bockar av de enkla punkterna. De som har störst effekt hamnar i backloggen, eftersom en checklista talar om vad du ska göra, men ingenting om vad du ska göra först.
Därför använder vi poängsättning istället. TSU: Traffic (Trafik), Security (Säkerhet), User type (Användartyp). Tre axlar, en till fem poäng vardera, framtagna genom våra kunduppdrag och i linje med vår bredare produktdesignprocess som bygger på design thinking. Summera poängen och agera utifrån totalen.
Ett flöde för lösenordsåterställning som används av 2 % av din bas har inte samma prioritet som ett registreringsformulär som varje ny användare måste gå igenom. Ta fram de faktiska siffrorna från tratten innan du poängsätter något. Team överinvesterar rutinmässigt i specialfall, och oftast beror det på att dessa flöden genererar de mest högljudda supportärendena, inte den största volymen.
Viss friktion är nödvändig. Att ta bort lösenordsbekräftelse är säkert. Att vässa felmeddelanden är det inte, eftersom "fel lösenord" tyst bekräftar för en angripare att e-postadressen tillhör ett riktigt konto, vilket halverar arbetet för en credential stuffing-attack (en automatiserad attack som återanvänder användarnamn och lösenord som läckt från andra dataintrång). Ge 5 poäng där en ändring är säkerhetsneutral. Ge 1 poäng där den byter ut genuin risk mot bekvämlighet.
En konsumentapp optimerar för hastighet och social inloggning. En B2B-plattform där en administratör skapar konton optimerar för tydlighet, enkel inloggning (SSO) och rolltilldelning. Samma ändring, olika poäng, beroende på om din användare valde att vara där eller blev tillsagd att vara där.
Poängen är inte matematiken. Poängen är att poängsättningen flyttar fram säkerhetsdiskussionen till designfasen istället för till kodgranskningen, vilket är där inloggningsdesigner brukar dö och där omarbete blir dyrt.
Om användaren måste leta efter inloggningen har du skapat friktion redan innan formuläret har laddats. Placera den längst upp till höger i sidhuvudet, där alla är vana vid att leta, och behåll den där på hela webbplatsen, inte bara på startsidan.
Googles inloggningsskärm är referensmodellen. Ett fält, en tydlig åtgärd och länkar för lösenordsåterställning precis där en användare som kört fast förväntar sig att hitta dem.
TSU: T5 / S5 / U5 = 15. Kör på. Kommersiellt: den billigaste åtgärden på listan, en ändring i navigering och CSS som tar några timmar och påverkar alla besökare som vill återvända.
Att registrera sig med ett befintligt konto eliminerar behovet av att skapa ett lösenord, vilket är ett moment där många avbryter processen. Det minskar även din egen arbetsbörda. Du slipper ansvara för inloggningsuppgifter som du annars måste skydda.
Håll utbudet av leverantörer enkelt. Konsumentprodukter bör erbjuda Google och Apple, eftersom Apple kräver ett eget inloggningsalternativ för iOS-appar som erbjuder inloggning via tredje part. B2B-produkter bör prioritera Google Workspace och Microsoft, samt SAML SSO (Security Assertion Markup Language single sign-on, protokollet som IT-avdelningar på företag använder för att centralisera medarbetarnas åtkomst) om du säljer till företagskunder. Anpassa listan efter dina faktiska användare istället för att bara kopiera vad din närmaste konkurrent visar.
TSU: T5 / S4 / U4 = 13. Kör på. Kommersiellt: tar bort ett steg för varje ny användare och minskar antalet supportärenden gällande lösenordsåterställning permanent. Dra av en poäng på säkerhetsaxeln om du hanterar reglerad data, där användning av en identitetsleverantör kräver en egen granskning.
Någon som skriver utan att se tecknen med Caps Lock på kommer att misslyckas, försöka igen, misslyckas på nytt och till slut hamna i ditt flöde för lösenordsåterställning. Det kostar dem tid och dig ett supportärende, på grund av ett tangentbordsläge du enkelt kunde ha informerat om. GitHubs inloggningssida visar en varning om att Caps Lock är aktiverat direkt i fältet, och det kräver bara några rader JavaScript.
TSU: T4 / S5 / U4 = 13. Kör på. Kommersiellt: en halv dags utvecklingsarbete för att eliminera en återkommande och helt onödig supportkostnad.
"Logga in", "inloggning" och liknande termer betyder samma sak. Att blanda dem i en och samma produkt skapar en liten osäkerhet som upprepas vid varje kontaktpunkt. Välj ett uttryck och håll dig till det, även för motsatsen: om du använder "logga in", använd "logga ut", aldrig "logout".
Detta är värt att påpeka för utvecklarna, eftersom det ofta slinker igenom. "Inloggning" är ett substantiv, som i inloggningssidan. "Logga in" är ett verb, som i logga in på ditt konto. Att använda fel termer i gränssnittet ger ett slarvigt intryck, särskilt för den tekniska målgrupp du minst vill ska uppfatta det så.
TSU: T5 / S5 / U3 = 13. Implementera. Kommersiellt: nästintill noll i byggkostnad, och det förstärks av varje annan förtroendesignal på sidan.
Löpande validering förhindrar att användare skickar in ett formulär för att först efteråt upptäcka att något blev fel tre fält tidigare. Aktivera valideringen när användaren lämnar ett fält istället för vid varje tangenttryckning, och förklara hur problemet åtgärdas istället för att bara markera att ett fel har uppstått.
Sedan har vi felmeddelandet vid inloggning, där god UX och god säkerhet drar åt olika håll. "Fel lösenord" hjälper användaren, men bekräftar också för en angripare att e-postadressen tillhör ett verkligt konto, vilket halverar arbetet vid en automatiserad inloggningsattack. "Ogiltig kombination av e-post och lösenord" är den rätta avvägningen. Skydd mot uppräkning, det vill säga att hindra angripare från att identifiera vilka adresser som har konton, är värt mer än den lilla tydlighet man offrar.
TSU: T5 / S2 / U4 = 11. Schemalägg och inkludera säkerhet i granskningen av textinnehållet. Detta är punkten som mest behöver modellen, eftersom designmässigt optimalt och säkerhetsmässigt optimalt ofta står i konflikt. Kommersiellt: att poängsätta detta förhindrar att oenigheten stoppar hela din redesign i två veckor.
Överraska inte användaren med lösenordsregler först efter att de misslyckats med att uppfylla dem. Visa kraven bredvid fältet från början och validera dem i realtid medan användaren skriver.
Två fallgropar här. För det första: regler som är så krångliga att alla väljer samma svaga men godkända mönster. För det andra: tvingande periodiska lösenordsbyten, vilket numera anses föråldrat. NIST Special Publication 800-63B-4, den amerikanska myndigheten NIST:s riktlinjer för digital identitet som fastställdes den 31 juli 2025, anger att verifierare inte ska kräva periodiska byten såvida det inte finns bevis för att autentiseringsuppgifterna har komprometterats. Övergången från "bör inte" i 2017 års utgåva till "ska inte" gör detta från en rekommendation till ett krav. Resonemanget är välkänt för alla som haft en arbetsdator: tvingande byten skapar förutsägbara lösenord, där "Lösenord1!" blir till "Lösenord2!". Ett undantag: där specifika regler som PCI-DSS står i konflikt med NIST-vägledningen har regleringen företräde.
TSU: T5 / S5 / U4 = 14. Implementera. Kommersiellt: att slopa krav på lösenordsbyten minskar antalet lösenordsåterställningar och tar bort återkommande friktion för betalande kunder, utan att tumma på säkerheten enligt nuvarande riktlinjer.
Fältet för att bekräfta lösenord är ett föråldrat mönster som skapar just det fel det var tänkt att förhindra. Uppgifterna matchar inte, användaren kan inte se något av dem, och nu måste de rensa båda fälten och börja om utan att veta vilket som var fel. Genialt.
En knapp för att visa eller dölja lösenordet löser problemet snabbare. Användare kan kontrollera vad de skrivit och korrigera det direkt, vilket de flesta moderna konsumenttjänster numera tillåter.
TSU: T5 / S4 / U4 = 13. Implementera. Kommersiellt: ett fält mindre och ett felsteg mindre i det formulär du har med högst trafik.
Om en användare kan registrera sig via flera vägar – gratisnivå eller betalnivå, privatkonto eller företagskonto – måste knappen tydligt ange vad den leder till. "Registrera dig" säger ingenting när två sådana knappar visas på samma skärm. "Starta gratis provperiod" och "Köp Pro" förklarar allt.
TSU: T4 / S5 / U4 = 13. Implementera. Kommersiellt: detta påverkar fördelningen mellan dina prisnivåer, vilket ökar intäkten per registrering snarare än bara antalet registreringar.
En återkommande kund som hamnar på registreringsformuläret och en ny besökare som hamnar på inloggningssidan har samma problem, fast åt motsatta håll. Båda behöver en tydlig väg vidare, omedelbart. Differentiera de två tillstånden genom layout och text – samma princip som styr en lyckad webbplatsdesign – och gör bytet till ett enda klick utan att sidan behöver laddas om.
TSU: T5 / S5 / U4 = 14. Kör på. Kommersiellt: återkommande användare är intäkter du redan har. Att förlora dem vid dörren kostar mer än att förlora en potentiell kund som aldrig haft en relation med dig.
Användarnamn ger dina användare ett minnesproblem de aldrig bett om. De glömmer vilken variant de registrerade sig med, och felmeddelanden om upptagna användarnamn skapar en onödig felkälla i ett formulär som annars inte hade haft någon.
E-post fyller dubbla funktioner som identifierare och återställningskanal, och ger dig dessutom en legitim väg tillbaka till användaren för onboarding och återengagemang. Detta förutsätter naturligtvis samtycke enligt GDPR, EU:s dataskyddsförordning, vilket för europeisk verksamhet inte är valfritt.
TSU: T5 / S4 / U4 = 13. Kör på. Kommersiellt: ett fält borttaget, ett felsteg eliminerat, en marknadsföringskanal vunnen.
Folk glömmer lösenord. Det är inte ett designfel som väntar på att tekniskt lösas, det är ett vanligt mänskligt beteende som din produkt bör hantera smidigt. Placera återställningslänken direkt på inloggningssidan, skicka e-postmeddelandet på några sekunder och skicka tillbaka användaren dit de var istället för att dumpa dem på startsidan för att börja om.
Tänk på säkerheten. "Vi har skickat en återställningslänk om kontot finns" undviker samma problem med kontouppräkning som i tips 5.
TSU: T3 / S4 / U4 = 11. Planera in. Kommersiellt: lägre trafik än vid registrering, men detta flöde används i hög grad av återkommande betalande kunder. Prioritera detta om prenumerationer är din bas.
Femton fält på en skärm upplevs som ett arbete. Samma femton fält fördelade på tre tydliga steg med en förloppsindikator upplevs som hanterbart, och det gör att du kan fånga upp ett användbart konto efter första steget istället för att förlora allt när någon ger upp vid fält elva.
Ännu bättre: be bara om det som krävs för att skapa kontot och samla in resten när användaren har sett ett värde. Allt som inte rör autentisering hör hemma i onboarding och produktdesign, inte i dörren.
TSU: T5 / S5 / U4 = 14. Kör på. Kommersiellt: att bara fånga upp delvis information räddar en andel av de avbrutna registreringarna som annars hade varit helt förlorade.
Låt folk själva bestämma över ihållande sessioner istället för att bestämma åt dem. På en delad eller offentlig dator behöver de kunna välja bort det. På sin egen bärbara dator väljer de gärna till det. Lämna rutan omarkerad som standard och använd ett tydligt språk.
TSU: T4 / S3 / U4 = 11. Planera in. Kommersiellt: sessionslängd är ett reellt riskbeslut, särskilt när det gäller finansiell eller medicinsk data. Utvärdera den aspekten tillsammans med din ansvariga för regelefterlevnad direkt, inte i efterhand.
Mobilen är där de flesta registreringar sker idag, och där de flesta går förlorade. Baymards data visar att avhoppsfrekvensen är betydligt högre på mobilen än på datorn, och inloggningsformulär är bland de värsta bovarna eftersom felen staplas på varandra: små träffytor, ett tangentbord som täcker halva skärmen och lösenordsinmatning utan hjälp från en lösenordshanterare.
Fyra förbättringar ger störst effekt. Ställ in rätt inmatningstyper, type="email" och type="tel", så att rätt tangentbord visas istället för att användaren ska behöva leta efter @-tecknet. Ställ in autocomplete-attribut som email, current-password och new-password så att webbläsarens och lösenordshanterarens autofyll faktiskt fungerar. Se till att tryckytan är minst 24x24 CSS-pixlar, enligt WCAG 2.2 framgångskriterium 2.5.8 Målstorlek (minimum). Kontrollera även att din huvudknapp inte döljs bakom skärmtangentbordet så fort ett fält får fokus.
TSU: T5 / S5 / U4 = 14. Kör på. Kommersiellt sett är detta den enskilt största volymmöjligheten för de flesta konsumentprodukter, och den som team oftast missar eftersom de testar på den stationära datorn de har framför sig.
Tillgänglighet i inloggnings- och registreringsformulär är både en konverteringsfråga och en juridisk risk. Enligt European Accessibility Act, som trädde i kraft den 28 juni 2025, är det ett lagkrav för många produkter som säljs inom EU. De relevanta WCAG 2.2 -kriterierna är specifika och mätbara, vilket gör detta lättare att åtgärda än det mesta annat efterlevnadsarbete.
Etiketter, inte platshållare (1.3.1, 3.3.2). Varje inmatningsfält behöver en programmatiskt kopplad etikett. Platshållartext försvinner så fort någon börjar skriva, vilket gör att användare av skärmläsare och personer som tappat bort sig står utan vägledning.
Fel identifierade och förklarade (3.3.1, 3.3.3). Felmeddelanden måste ange vad problemet är, föreslå en lösning och vara tillgängliga för hjälpmedel. Att bara färga fältet rött räknas inte som ett felmeddelande.
Tillgänglig autentisering (3.3.8). Att blockera inklistring eller använda skript som hindrar webbläsare och lösenordshanterare från att fylla i fält bryter mot detta kriterium, eftersom det innebär en orimlig eller omöjlig belastning för personer med vissa kognitiva funktionsnedsättningar att behöva memorera eller skriva av ett lösenord. Läs det där två gånger om ditt säkerhetsteam för närvarande blockerar inklistring i lösenordsfält. Den kontrollen är numera ett WCAG-fel.
Kontrast och tangentbordsnavigering (1.4.3, 2.1.1). Hela formuläret måste kunna fyllas i enbart med tangentbord, med synliga fokusmarkeringar och en textkontrast på minst 4,5:1.
TSU: T5 / S5 / U5 = 15. Kör på. Kommersiellt: den enda punkten på listan som innebär direkt regulatorisk exponering. Det hjälper även användare med äldre enheter, spruckna skärmar och i starkt solljus, vilket är en betydligt större grupp än vad de flesta team tror.
Fyra beslut och en metod. Be om mindre, det vill säga det minimum av fält som autentiseringen kräver, och skjut upp allt annat till senare i produkten. Gör vägarna tydliga, vilket innebär en synlig ingång till inloggningssidan, ett uppenbart byte mellan registrering och inloggning, samt en återställningslänk som användare kan hitta även när de är frustrerade. Hantera fel på ett smidigt sätt, vilket innebär validering direkt i formuläret som förklarar hur felet åtgärdas, en funktion för att visa lösenordet istället för ett bekräftelsefält, och inloggningsfel som är tillräckligt vaga för att inte ge angripare en lista över giltiga konton. Designa för mobila enheter och hjälpmedel först, eftersom det är där den största volymen finns och där de juridiska riskerna är som störst.
Metoden är TSU. Betygsätt varje ändring utifrån trafik, säkerhet och användartyp, och lansera sedan i ordning efter poäng. Den finns till för att det som sänker redesignprojekt för inloggningar nästan aldrig är brist på kunskap om best practice. Det är snarare team som lanserar de enkla vinsterna medan det högvolyms- och säkerhetskänsliga arbetet stannar av i granskningsfasen. Baymards upptäckt att åtgärdbara användbarhetsproblem i kassan motsvarar en genomsnittlig konverteringsökning på 35,26 % ger bara utdelning för team som prioriterar arbetet och faktiskt genomför lanseringen.
Börja med ett formulär: ett fält för e-post och ett för lösenord, båda med synliga etiketter och korrekta autocomplete-attribut. Lägg till en primär knapp, en synlig länk för lösenordsåterställning och en tydlig väg till registreringssidan för de som inte har ett konto. Placera sociala inloggningsalternativ eller SSO ovanför formuläret om dina användare förväntar sig det. Hantera sedan felen: ett generiskt meddelande om "ogiltig kombination av e-post och lösenord", en varning för Caps Lock och hastighetsbegränsning vid upprepade försök. Allt utöver detta är bara finputsning.
Som minst ett e-postfält, ett lösenordsfält med synliga krav och en funktion för att visa/dölja lösenordet, samt en tydligt märkt skicka-knapp. Lägg till social inloggning om det passar din målgrupp, en synlig länk till dina användarvillkor och din integritetspolicy, samt en länk tillbaka till inloggningssidan för återkommande användare. Uteslut allt som inte rör autentisering. Företagsstorlek, yrkestitel och telefonnummer hör hemma i onboarding-processen, efter att kontot har skapats.
Så få som autentiseringen kräver, vilket ofta bara är e-post och lösenord, eller en knapp för social inloggning. Baymard fann att det genomsnittliga kassaflödet i USA visar 23,48 formulärelement, trots att ett idealiskt flöde kan vara så kort som 12 till 14. Varje extra fält är en punkt där någon kan avbryta. När en intressent ber om ett extra fält, fråga vad som händer om den informationen kommer in en vecka senare inifrån produkten istället.
I denna ordning: korta ner fälten till det absoluta minimum för autentisering, lägg till social inloggning eller SSO, dela upp det som återstår i steg med tydliga etiketter och en förloppsindikator, fixa inmatningstyper och autofyll för mobiler, och skriv om felmeddelanden så att de förklarar hur felet åtgärdas. Mät sedan hela flödet så att du kan se vilken ändring som påverkade vilken siffra. De flesta team lanserar alla fem samtidigt och lär sig ingenting om vad som faktiskt gjorde skillnad.
Direkt, och det går att mäta. Baymard fann att 18 % av kunderna avbryter köpet för att webbplatsen kräver att man skapar ett konto, och 17 % för att processen är för lång eller komplicerad. Registreringen ligger precis i slutet av anskaffningstratten, så avhopp där innebär att pengar du redan lagt på marknadsföring går till spillo. Det är därför det oftast ger mer avkastning per utvecklingstimme än optimeringar högre upp i tratten.
Funktionellt sett ingen. De beskriver samma handling. Skillnaden är grammatisk och handlar om konsekvens. "Login" är ett substantiv, som i "inloggningssidan". "Log in" är verbet, som i "logga in på ditt konto". "Sign in" fungerar som en verbfras, med "sign-in" som substantivform. Välj en konvention, använd den överallt och glöm inte att matcha med motsvarande uttryck för utloggning.
Nej. En funktion för att visa/dölja lösenordet gör samma jobb med mindre friktion. När bekräftelsefält inte matchar kan användarna inte se vad de skrivit, så de skriver om båda utan att någonsin få veta vilket som var fel.
För de flesta B2B-produkter, ja, förutsatt att du använder leverantörer anpassade för företag. Google Workspace och Microsoft Entra erbjuder starkare autentisering än de flesta interna lösenordssystem, inklusive tvingande multifaktorautentisering och centraliserad åtkomstkontroll den dag en anställd slutar. För reglerade branscher eller företagskunder är SAML SSO ofta ett krav vid upphandling snarare än ett tillval.
Ställ in korrekta inmatningstyper så att rätt tangentbord visas. Använd autocomplete-attribut så att lösenordshanterare kan fylla i fälten. Uppfyll kravet på en tryckyta på minst 24x24 CSS-pixlar enligt WCAG 2.2 kriterium 2.5.8. Kontrollera också att knappen för att skicka inte hamnar bakom det virtuella tangentbordet när ett fält får fokus. Testa på en riktig enhet, inte en emulator, eftersom tangentbordsbeteende är precis det som emulatorer ofta hanterar fel.
Mät tre saker: bortfallet mellan visning av inloggningssida och lyckad autentisering, kvoten mellan lösenordsåterställningar och aktiva sessioner, samt andelen registreringar som avbryts efter första fältet. Segmentera per enhet, eftersom bortfallet på mobilen oftast är betydligt större än på desktop, och det är ofta där din potential för återhämtning finns. Det finns inget universellt riktvärde för en hälsosam nivå av lösenordsåterställningar. Det som spelar roll är din egen trendlinje och hur den påverkas när du gör ändringar.
Om er registrerings- eller inloggningssida tappar konverteringar är det första steget att ta reda på var och hur mycket. Vi börjar med en UX-revision av ert befintliga registreringsflöde: vi kartlägger tratten från första visning till lyckad autentisering, identifierar specifika avhoppspunkter och jämför era slutförandegrader med liknande produkter i er bransch.
Du får med dig en prioriterad lista baserad på TSU-modellen. Vad som bör ändras, i vilken ordning, vad varje åtgärd är värd i förhållande till er nuvarande CAC och vad det kostar att bygga. Den sista delen är viktig, eftersom den gör att ni kan väga inloggningsarbetet mot allt annat som konkurrerar om samma sprint, istället för att diskutera det utifrån tycke och smak. Inte en rapport att lägga i en pärm. En backlog som era utvecklare kan börja arbeta med på måndag.
Boka ett samtal med vårt UX/UI-design- och produktteam för att gå igenom ert nuvarande flöde.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Ung UX/UI-designer som brinner för detaljer och mänskligt beteende som älskar att lära sig något nytt varje dag.
People who read this post, also found these interesting:
