Kuinka suunnitella hyvä kirjautumissivu

Login formin olemassaolon tarkoitus: tunnistaa käyttäjä ja päästää tämä sitten palvelussa eteenpäin. Tyypillisesti login onkin ylimääräinen paha, josta halutaan eroon mahdollisimman nopeasti. Kirjautumissivu on kuitenkin sikäli tärkeä elementti, että se on usein ensimmäinen asia, jonka käyttäjä palvelun avattuaan näkee, ja siten se toimii odotusten asettajana tulevalle käyttö­kokemukselle.

Tyypillisesti kirjautumissivun suunnittelun raameina ovat käytettävyys, tietoturva ja brändikuva. Käytettävyys on erityisen tärkeää kirjautumissivuilla, joilla käyttäjä joutuu käymään usein. Huono käytettävyys johtaa alitajuiseen palvelun välttelyyn, ja sitä kautta siirtymisen kilpailevan palvelun leiriin.

Kirjautumissivu toimii odotusten asettajana tulevalle käyttö­kokemukselle.

Paras kirjautuminen olisi tietenkin ei kirjautumista – käyttöjärjestelmän integraatio, tallennettu kirjautuminen tai biometrinen tunniste – mutta realistisesti se ei useinkaan ole mahdollista. Tässä artikkelissa keskitytään perinteiseen login/password -lomakkeeseen.

Popover vai oma sivu?

Vielä kymmenisen vuotta sitten hyvin moni verkkosivu sijoitti kirjautumistoiminnon pop-upin sisälle (on persiaa ja tarkoittaa ponnahdus­ikkunaa). Ajatus tässä oli häivyttää toiminto niin pieneksi kuin mahdollista, säilyttäen konteksti alla olevaan sisältöön.

Pop-upin käytöstä ei useimmiten ole kuitenkaan mitään hyötyä, sillä kirjautumisen jälkeen koko sivu täytyy useimmiten ladata uudestaan. Pop-upin käyttöä ei kannatakaan edes harkita, mikäli palvelu vaatii sisään­kirjautumisen toimiakseen; käyttäjällä ei ole vielä mitään sisältöä, johon konteksti täytyisi säilyttää. Jos taas palvelusi on esimerkiksi monimutkaisia valintoja sisältävä verkkokauppa – sanotaan vaikka tietokoneen rakennuspalvelu – voi pop-upin käytöstä olla hyötyä.

Foodora käyttää pop-upia sisään­kirjautumisen näyttämiseen. Käyttäjä ei näennäisesti koskaan poistu avatulta sivulta.

Gigantti käyttää pop-upia kirjautumiseen. Hyödyt ovat kyseenalaiset, sillä kirjautumisen jälkeen käyttäjä ohjataan etusivulle.

Nykyisin kirjautumissivut ovat useimmiten nimensä mukaisesti erillisisiä sivuja. Etuja tästä ovat:

• Sivun rauhoittaminen ylimääräisistä elementeistä. Muista, että kirjautumissivun tarkoitus on useimmiten yksinkertaisesti tehokas ohjaus eteenpäin.
• Virhetilanteiden parempi käsittely. Käyttäjää ei tarvitse ohjata pois nykyisestä kontekstista edes uudelleenlatauksen yhteydessä.
• Mahdollisuus jakaa kirjautuminen osuuksiin.
• Yksinkertaisempi mobiilitoteutus, erityisesti vieritystä ajatellen.

Ikea käyttää erillistä sisään­kirjautumissivua. Koko näytön kokoinen taustakuva tukee tehokkaasti brändimielikuvaa.

Kirjautumisen jakaminen osuuksiin

Kirjautumisen jakaminen useaan (yleensä kahteen) osaan on yleistymään päin oleva käytäntö. Tässä mallissa käyttäjältä kysytään ensin käyttäjätunnusta, ja salasanaa vasta seuraavassa vaiheessa. Tällöin käyttäjän nähtävillä on periaatteessa vain yksi kenttä kerrallaan ja virhemahdollisuus pienenee. Lisäksi suurempien yrityksien käyttämät single sign-on -ratkaisut asettuvat kirjautumisprosessiin luontevammin.

Googlen sisään­kirjautuminen on jaettu kahteen osaan.

Mikäli palvelu ei ole kovin tietoturvakriittinen, voi ensimmäisessä vaiheessa myös tarkistaa, onko käyttäjänimeä ylipäänsä olemassa, ja ohjata sitten edelleen tilin luontisivulle. Lookbackin kaltaisessa palvelussa tämä on aivan ok, mutta esimerkiksi uskontoa tai seksuaalisuutta käsittelevissä palveluissa ei kannata antaa ihmisten testata, käyttääkö jokin tietty sähkö­posti­osoite palvelua.

Lookback jakaa kirjautumisen osiin, niin että käyttäjäpolku haarautuu riippuen siitä, onko sähkö­posti rekisteröity palveluun.

Kirjautumisen jakaminen osuuksiin käy järkiin ainoastaan silloin kun se helpottaa prosessia tai palvelun on tuettava SSO-ratkaisuja. Suurin osa kirjautumissivuista on varsin yksinkertaisia, jolloin prosessin jakaminen osuuksiin itse asiassa tekisi siitä monimutkaisemman tuntuisen.

Monimutkaisenkin prosessin voi toteuttaa yhdellä ainoalla sivulla skriptejä käyttämällä. Esimerkiksi Netflixin web-versioon voi kirjautua sisään joko sähkö­postilla tai puhelinnumerolla, ja lomake muuttuu lennosta vastaamaan annettua kirjautumistietoa. Periaatteessa tämän toiminnon olisi voinut jakaa kahteen osaankin, mutta Netflixin käyttäjäkokemuksessa nopeus painaa enemmän kuin prosessin koettu yksinkertaisuus.

Netflixiin voi kirjautua joko sähkö­postilla tai puhelinnumerolla, ja valintaan reagoidaan lennosta, ilman erillisiä osuuksia.

Pidä kirjautuminen yksinkertaisena

Yksinkertaisimmillaan kirjautumissivun täytyy sisältää seuraavat elementit, tässä tärkeysjärjestyksessä:

1. Kirjautumispainike
2. Tunnistautumistiedot (yleensä käyttäjätunnus ja salasana)
3. Viestikenttä virhetilanteita varten
4. Tunnistautumistietojen palautustoiminto
5. Tilin luominen

Käyttöliittymän suunnittelun perusasioita on tunnistaa näkymän elementtien prioriteetit – ja sitten myös noudattaa sitä. Tämä tarkoittaa sitä, että tärkeimpien elementtien tulee olla löydettävissä vaikka silmät kiinni, ja alemman prioriteetin elementtien tulee olla häivytetympiä.

Piilota siis tilin luominen ja salasanan unohtuminen matalakontrastisen napin/linkin taakse; kyllä ne sieltä löytyvät, jos niille tarve joskus tulee. Erilliset toiminnot voivat avata myös erillisen sivun/popupin, jolloin erikoistilanteisiin liittyvät tietokentät (kuten rekisteröityminen) voidaan piilottaa kokonaan peruskäytössä.

Book Depository näyttää sekä kirjautumisen että tilin luonnin samassa tilassa, luoden vaikutelman vaativasti prosessista.

Käytä standardimuotoilua

Käyttäjätunnus-salasana -yhdistelmä on niin usein käytetty, että käyttäjät ovat jo tottuneita tunnistamaan sen pelkän muodon perusteella. Tätä kannattaa käyttää hyödykseen, jotta vältyt monimutkaisten ohjetekstien kirjoittamiselta.

Standardimuotoisen login formin tunnistaa sen muotokielestä, vaikka itse sisältö olisi täyttä latinaa.

Kielellisesti kannattaa käyttää myös peruskieltä ja vakiintuneita käsitteitä. Siis Log in, Forgot your password?, Username; eikä Authorize, Got an error?, Registered Login. Sanavalintojen kannattaa myös olla sellaisia, ei-natiivi puhujakin ottaa niistä selvää. Vältä esimerkiksi Sign in ja Sign up -yhdistelmää – käytä sen sijaan vaikkapa Log in ja Create Account.

Vältä Sign in ja Sign up -teksti­yhdistelmää.

Standardimuotoilu tarkoittaa myös sitä, että sisään­kirjautumis­näkymään ei kannata kikkailla mitään erityistoimintoja, joita kirjautumis­näkymissä ei yleensä ole. Unohda siis postituslistat ja ylimääräiset painikkeet. Niistä on enemmän haittaa kuin hyötyä – muista, että sisään­kirjautumissivun on tarkoitus ohjata käyttäjä itse sisältöön, jossa voit sitten puffata lisäarvoa niin paljon kuin kaista antaa periksi.

Lulun sisään­kirjautumis­näkymässä kirjautumispainiketta edeltää peruutustoiminto. Kuinkahan moni käyttäjä on vahingossa peruuttanut kirjautumisen sen kuittaamisen sijaan?

Ja btw, tyypillisesti lomakkeissa ei kannata käyttää tekstikentän sisäisiä otsikkoja (ns. inline labels), mutta kirjautumislomakkeen tapauksessa se on ihan ok. Kenttiä on kuitenkin vain kaksi ja ne ovat vakiojärjestyksessä. Jos tunnistetietosi kuitenkin on jotenkin poikkeava – esimerkiksi asiakasnumero – älä käytä inline labeleita.

Looginen kenttäjärjestys

Ylhäältä alas ja vasemmalta oikealle. Siinä on peruslänkkärin lukusuunta ja aivomme ovat tottuneet lukemaan myös käyttöliittymiä samassa järjestyksessä. Älä siis sijoita ”Muista minut” -painiketta kirjautumispainikkeen alapuolelle, koska käyttäjät tulevat painamaan nappia ennen kuin edes huomaavat kyseisen kentän.

Magic the Gathering: Arena asemoi kentät loogisessa järjestyksessä ylhäältä alas.

”Näytä salasana” ja ”Unohtuiko salasana?” -kentät kannattaa sijoittaa salasanakentän yhteyteen. Näin saat sisällytettyä ne itse kirjautumislomakkeen yhteyteen, minkä lisäksi niiden paikka viestii toiminnallisesta yhteydestä salasanakenttään. Tässä tulee kuitenkin käyttää tilannekohtaista harkintaa, sillä liika toimintopainikkeiden määrä ennen kirjautumispainiketta voi tehdä lomakkeesta sekavan.

Esimerkiksi Ikea (katso kuva ylempää) käyttää salasanan näyttämiseen ainoastaan salasanakentän sisälle sijoitettua silmäsymbolia, joka olisi ilman salasanakentän yhteyteen sijoittelua täysin irrallinen painike, mutta toimii loistavasti itse kentän sisällä. Huomioi kuitenkin, että tekstikentän sisäiset elementit vaativat valtavan osuma-alueen, jotta niitä on mahdollista klikata/täpätä kentän sisältä.

Elloksen sisään­kirjautumislomakkeen ”Muista minut” -valinta on lipsahtanut kirjautumispainikkeen väärälle puolelle.

Tee validointi vasta syötön jälkeen

sähkö­postin validointi on kätevä tapa huomauttaa mahdollisista typoista. Käyttäjät ovat niin tottuneita login/password -yhdistelmän naputtelemiseen, etteivät he usein edes katso mitä kirjoittavat. Tällöin esimerkiksi @-merkin tilalle humpsahtaa vahingossa 2-merkki.

Validointi tulee tehdä ennen lomakkeen lähettämistä. On turhauttavaa saada virheilmoitus sähkö­postiosoitteesta sen jälkeen, kun käyttäjä on painanut kirjautumisnappia ja ehtinyt jo henkisesti siirtyä pois lomakkeesta.

Älä kuitenkaan validoi sähkö­postia sen kirjoittamisen aikana! Hyvä ajatusharjoitus on kuvitella käyttöliittymän olevan oikea asiakaspalveluhenkilö; miltä tuntuisi, jos sähkö­postiosoitteesi lausumisen aikana aspa nalkuttaisi jatkuvasti ääneen, että tuo nyt ainakaan ei ole mikään oikea osoite?

Hyvä hetki sähkö­postin validointiin on kentästä poistuminen, pitkä tauko kirjoittamisessa tai harkiten tiettyihin merkkeihin perustuva seuranta (kuten ”2gmail” tai ”.com” jälkeen). Ainoa poikkeus tähän ovat erityismerkit, joita sähkö­postiosoitteessa ei voi olla (kuten kaksi @-merkkiä).

Escape from Tarkov -pelin kenttävalidointi nillittää sähkö­postista ennen kuin se on syötettykään. Muutenkin lomake on sössitty melkein niin pahasti kuin vain mahdollista on.

Laita palveluusi ”näytä salasana” -toiminnallisuus, jos vain mahdollista. Salasanan kirjoittaminen sokkona on monelle hyvin vaikeaa ja varsinkin kosketusnäytöllä se voi olla aikamoista tuskaa. Mobiilipalveluissa olisi suotavaa, että sanasana näytettäisiin oletuksena; mobiililaitteen näyttöä on hankala kuikuilla olan yli.

Anna oikeaa apua virhetilanteisiin

Kuten jo mainittu, syötön aikana tapahtuva virhetarkastus on kaikista mukavin, mutta totta kai virheet pitää tarkastaa myös tausta­järjestelmässä kirjautumisyrityksen jälkeen.

Jokainen ihminen joutuu muistamaan salasanoja satoihin eri palveluihin, eikä ole mikään ihme, että salasanat tyypillisesti noudattavat jotain tiettyä kaavaa. Palvelut pyrkivät tyypillisesti tehostamaan tietoturvaansa asettamalla salasanalle erityisiä vaatimuksia, kuten erityismerkkien tai numeroiden käyttöpakkoa. Ongelma syntyy siinä vaiheessa, kun nämä pakot eivät sovi käyttäjän peruskaavaan.

Älä koskaan rajoita salasanan pituutta naurettavaan kahdeksaan merkkiin.

Esimerkiksi EA Origin vaatii salasanaan ainakin yhden ison kirjaimen ja numeron. Jos käyttäjän salasanakaava menee jotenkin tyyliin ”munpelit2020vayrynen”, aiheuttaa ison kirjaimen vaatimus muistamisongelman. Lopputulos on tietenkin se, että käyttäjä laittaa salasanakseen ”Munpelit2020vayrynen”, eikä sitten parin viikon päästä enää muista tuota isoa alkukirjainta. Käyttäjä ottaa avuksi salasanan palautustoiminnon ja koko homma alkaa taas alusta.

Näytä siis salasanavaatimukset sisään­kirjautumis­sivulla, edes epäonnistuneen kirjautumisen jälkeen, jos ei muuten. Säästät tällä useita ”Unohtuiko salasana?” -toiminnon käyttöjä. Lisäksi – luojan tähden! – älä koskaan rajoita salasanan pituutta johonkin naurettavaan 8 merkkiin.

EA Origin -palvelun salasanassa on oltava iso kirjain ja numero. Olisipa kiva, jos tästä muistutettaisiin jossain.

Jos sisään­kirjautuminen epäonnistuu, täytä käyttäjätunnus ja (tietoturvan puitteissa) salasanakentät valmiiksi seuraavaa yritystä varten. Näin käyttäjä voi paremmin jäljittää ongelman syytä, kuten tarkastamalla sähkö­posti­osoitteen typon.

Täydellinen sisään­kirjautumis­näkymä

Tässäpä lopuksi malliesimerkki perusmuotoisesta sisään­kirjautumis­näkymästä. Palveluissa on luonnollisesti tapauskohtaisia eroja, jotka vaikuttavat asemointiin ja tyylivalintoihin, mutta eiköhän tästä jo haisua saa.

kirjautumis­näkymä prosessin alkuvaiheessa

Huomioitavaa alkuvaiheesta

• Aktivoi käyttäjätunnus-kenttä jo valmiiksi.
• Aktiivisen kentän kevyt korostaminen helpottaa käytettävyyttä.
• Mikäli lomakkeessa on paljon elementtejä, on lisätoiminnot (unohtunut salasana, rekisteröinti) hyvä laittaa sen ulkopuolelle.

kirjautumis­näkymä live-validoinnilla

Huomioitavaa live-validoinnista

• Validoi kenttä vasta kun käyttäjä ei selvästi enää kirjoita siihen.
• Korosta virhekenttä värillä ja ikonilla.
• Kerro selkeästi, mistä virheestä on kyse. Vältä yleisiä ”jokin meni vikaan” -viestejä.

kirjautumis­näkymä täytön jälkeen

Huomioitavaa valmiiksi täytetystä kirjautumiskentästä

• Älä näytä mitään ylimääräistä sälää. Käyttäjä ei niitä todennäköisesti ehdi kunnolla näkemään, jolloin ne voivat vaikuttaa virheeltä.
• Varmista, että kirjautumisnappi näkyy ja on tässä vaiheessa folding yläpuolella.

kirjautumis­näkymä virhetilassa. Tässä näkymässä käyttäjä valinnut salasanan näytettäväksi.

Huomioita virhetilasta

• Kuten aiemmin, korosta virheellinen kenttä ja kerro missä vika on.
• Tuo esille salasanavaatimukset. Tarjoa mahdollisuus lukea lisätietoa salasanan formaatista.
• Säilytä käyttäjän jo kirjoittamat tiedot, jotta hän voi tarkastaa ne.

« Back to post listing