Inloggning och registrering i mobilappar: gör kontosteget tydligt
En praktisk guide till inloggning och registrering i mobilappar: när ett konto behövs, formulär som tillåter misstag och användbara vägar för återställning.
En inloggningsskärm är ett litet gränssnitt med en överdimensionerad effekt: den kan hjälpa någon att återuppta en uppgift, eller avbryta dem innan de förstår varför ett konto är viktigt. Bra mobilkontodesign börjar med att behandla autentisering som en del av en produktresa, snarare än en grind som varje person måste passera vid lanseringen.
Flödet ska göra sitt syfte och sina val lätta att förstå, be bara om information som behövs nu och ge människor en lugn väg framåt när något går fel. Detaljerna är viktiga för både förstagångsbesökare och återkommande användare som kanske har glömt vilken inloggningsmetod de använde.
Viktigaste lärdomarna
- Be om ett konto vid den första meningsfulla punkten där det möjliggör en tydlig fördel eller verkligen krävs.
- Förklara varje inloggningsalternativ på ett välbekant språk och gör att sökvägen till det nya kontot skiljer sig från återkommande användares åtkomst.
- Håll formulär fokuserade, märk fält tydligt och låt lösenordshanterare och klistra in fungera som förväntat.
- Visa fel i text med ett användbart nästa steg, bevara giltig input och erbjuda återställning utan skuld.
Välj när ett konto blir användbart
Börja med jobbet personen kom för att göra. Om kärnupplevelsen kan fungera utan ett konto, låt människor utforska först och begär inloggning när de når en funktion som behöver sparade inställningar, åtkomst över flera enheter, samarbete eller en transaktion. Apples riktlinjer för mänskligt gränssnitt rekommenderar att du skjuter upp inloggningen när det är möjligt och förklarar fördelen när ett konto krävs.
En kontextuell uppmaning är lättare att förstå än en vägg vid lansering. En läsapp kan till exempel låta någon bläddra bland titlar och sedan be dem skapa ett konto när de väljer att synkronisera en läslista. Om det är viktigt att skapa ett konto från början, säg varför innan du presenterar fält. Håll förklaringen konkret och proportionerlig: "Skapa ett konto för att spara dina projekt och öppna dem på en annan enhet" är mer användbart än "Gå med i vår community."
- Separera nödvändig information från valfri profilinformation.
- För gästutcheckning eller en engångsuppgift, överväg om kontoskapandet kan vänta tills det omedelbara värdet har levererats.
- När autentiseringen har lyckats, ta människor till den åtgärd de tänkt slutföra.
Gör inloggningsvalen tydliga och igenkännbara
En person ska kunna se om de skapar ett konto eller återgår till ett. Ge de två vägarna distinkta etiketter, håll den primära handlingen visuellt tydlig och placera alternativa metoder där de kan jämföras utan att överväldiga skärmen. Använd leverantörsnamn och plattformsgodkända knappbehandlingar där det är relevant; En generisk "Fortsätt"-etikett förklarar inte enbart vad som händer härnäst.
Erbjud endast metoder som produkten stöder och kan underhålla. E-post, en lösenordsnyckel eller ett alternativ för plattformsidentitet kan passa olika målgrupper. Presentera dem som val, inte som ett påstående om att en metod är universellt enklast eller säkrast. Förklara eventuell ytterligare information som krävs.
Återkommande användare kanske inte kommer ihåg sin inloggningsmetod. Gör återställning och alternativ inloggning synliga och förklara vad du ska göra om ett e-postmeddelande är kopplat till en annan metod. Vägledning om kontolänkning kan hjälpa människor att behålla åtkomst till ett befintligt konto.
Håll formulär fokuserade och kompatibla med människors verktyg
Fråga endast efter fält som behövs för att skapa eller komma åt kontot. Använd beständiga etiketter istället för att lita på platshållartext som enda etikett, välj en lämplig inmatningstyp och tangentbord och gör nästa åtgärd tydlig. Om registreringen behöver flera delar av information, gruppera relaterade fält och skjut upp valfria inställningar tills efter att personen når produkten.
Autentisering bör fungera med autofyll och lösenordshanterare. Använd vanliga fältnamn och semantik och undvik anpassat beteende som förhindrar ifyllning av autentiseringsuppgifter. Blockera inte klistra in lösenord: människor kan använda en lösenordshanterare eller ett annat verktyg. WCAG-vägledning uppmanar webbläsare och lösenordshanterare från tredje part att fylla i inloggningsfält.
Beteende kan variera mellan enheter och lösenordshanterare, så kontrollera flödet på plattformar som stöds och tillåt manuell korrigering. Efter ett misslyckat försök, bevara användbara icke-känsliga värden som en e-postadress när det är praktiskt möjligt.
- Använd en synlig etikett som "E-postadress" och en tydlig lösenordsetikett.
- Tillåt personer att avslöja eller kontrollera ett lösenord när det är lämpligt, utan att göra den kontrollen till det enda sättet att korrigera inmatningen.
- Håll den primära knappen nära fälten och ge den en åtgärdsspecifik etikett som "Skapa konto" eller "Logga in".
Design för misstag, återhämtning och nästa besök
Ett användbart fel identifierar det berörda fältet eller det misslyckade steget i texten och talar om för personen hur han ska fortsätta. "Något gick fel" räcker inte när ett e-postformat är ogiltigt eller ett fält är tomt. WCAG 2.2 Framgångskriterium 3.3.1 kräver att upptäckta inmatningsfel identifieras och beskrivs i text; färg eller en ikon bör inte bära budskapet ensamt.
Använd ett neutralt språk och placera fältspecifik vägledning nära fältet. En hypotetisk feltext för en felaktig adress kan till exempel säga: "Ange en e-postadress i formatet [email protected]." För en misslyckad inloggning kan en produkt säga: "Vi kunde inte logga in dig med dessa uppgifter. Kontrollera din e-postadress och ditt lösenord eller återställ ditt lösenord." Undvik att exponera känslig kontoinformation i felmeddelanden; välj en formulering som passar produktens integritets- och missbruksförebyggande behov.
Förklara vad som händer efter att någon har begärt en återställning, ge en väg tillbaka för att logga in och hjälp människor att hitta metoden de använde tidigare. Vid senare besök, visa inloggad status tydligt och ge en väg till kontoinställningar, utloggning och hjälp. Om konton kan skapas i appen, gör det lätt att hitta kontoborttagning.
- Koppla ett fel till fältet som det beskriver och gör det märkbart utan enbart färg.
- Håll återställningsåtgärder nära inloggningsformuläret och undvik att få användare att starta om i onödan.
- Granska status för både första användning och återkommande användare, inklusive ändrade e-postadresser och otillgängliga inloggningsmetoder.
En praktisk genomgång av kontoflödet
Gå igenom flödet som en ny person, en återvändande person och någon som återställer tillgången. Kontrollera skärmarna i sammanhanget. Det mobila mönsterbiblioteket kan hjälpa team att jämföra hur formulär organiserar inmatningar, etiketter och åtgärder.
- Kan människor nå användbart produktvärde innan de loggar in när kontot inte är nödvändigt?
- Står det på skärmen varför ett konto behövs och vilken information som krävs?
- Kan en person skilja på registrering, inloggning, alternativa metoder och kontoåterställning?
- Förblir fältetiketter synliga och kan autofylla och klistra in autentiseringsuppgifter?
- Namnger fel problemet i text, behåller användbar input och föreslår ett nästa steg?
- Efter framgång, återgår personen till uppgiften de påbörjade?
Vanliga frågor
Ska en mobilapp kräva ett konto innan folk kan utforska?
Endast när kärnfunktionen verkligen kräver ett konto. Om människor kan bläddra eller prova produkten först, låt dem göra det och begär inloggning när det möjliggör en tydlig fördel eller behövs för en specifik åtgärd.
Bör lösenordsfält tillåta automatisk inklistring och lösenordshanterare?
Ja. Använd igenkännliga fältetiketter och semantik, och blockera inte klistra in eller autofyll. Dessa funktioner hjälper människor att använda sina föredragna autentiseringsverktyg, även om beteendet kan variera mellan enheter och lösenordshanterare, så kontrollera flödet på plattformar som stöds.
Vad ska ett inloggningsfelmeddelande innehålla?
Beskriv problemet i text, identifiera det berörda fältet eller steget och ge en praktisk nästa åtgärd. Håll formuleringen neutral och undvik att avslöja känsliga kontouppgifter.
