Kirjoitukseni tarkoituksena oli nimenomaisesti pohtia GUIDe:n soveltuvuutta verkkojulkaisemiseen, jonka sijoittaisin tuon huonon “vähän käliä, paljon sisältöä” -kategorian alle.

Verkossa konventiot rulaavat ja tuntuu, että jos niistä lähdetään poikkemaan radikaalisti, mennään helposti vikaan. Miksi siis käyttää aikaa käyttöliittymän suunnitteluun, kun konventioilla pärjätään? Kärjistäen sanottuna.

Oma ongelmani käyttöliittymäsuunnittelun sovittamisessa verkkomaailmaan on, että näen käyttöliittymäsuunnittelun nappien sijoitteluna ja erilaisten toimintojen suorittamisen optimointina.

Keskimääräisellä sisältöorientoituneella verkkosivulla toimintoja on yleensä muutama (haku, sisäänkirjautuminen, muutama lomake jne). Lisäksi on muutama navigaatiotaso, jotka voivat olla (kärjistäen sanottuna) vaakatasossa tai pystytasossa. Näiden suunnittelussa uskon konventioiden riittävän hyvin. Esimerkiksi verkkokaupan tapauksessa tilanne on tietysti täysin eri.

Sitä, miksen ole ymmärtänyt käytettävyyden ja käyttöliittymäsuunnittelun olevan olennaisesti sidoksissa myös informaatioarkkitehtuurin suunnitteluun ja tiedon löytämiseen, voin vain ihmetellä.

Tämän suunnitteluun GUIDe olisi varmasti omiaan: Tunnistetaan käyttäjäryhmät ja heidän tarpeensa ja muodostetaan informaatioarkkitehtuuri näiden mukaan siten, että käyttäjien tarpeisiin vastataan. Tosin väitän, että tässäkin liian radikaalit ratkaisut menevät mäkeen ja rakenne, joka kuvaa sisällön loogisessa ja hierarkisessa, asiakkaan maailmaan hyvin istuvassa muodossa toimii parhaiten.

Pointtisi käyttäjälähtöisen suunnittelun optionaalisuudesta on aiheellinen. Vaikkakin reaalimaailmassa ja “näinä aikoina” mennään kyllä pitkälti asiakkaan rahapussin mukaan, jos halutaan tehdä projekteja jatkossakin.

Jokaisen IT-toimittajan velvollisuutena olisi mielestäni asiakkaiden valistaminen hyvistä käytännöistä, mutta loppukädessä päätökset prosessista ja hinnasta tekee kuitenkin (ainakin meillä) asiakas. Valitettavasti.

Verkkomaailmassa suurin hyöty käyttäjälähtöisestä suunnittelusta olisi varmasti prosessin alkupäässä, jossa sivuston tärkeimmät käyttäjäryhmät tunnistetaan ja heidän tarpeensa kartoitetaan. Tähän kartoitustyöhön voisin kuvitella esimerkiksi focus group -henkisen työskentelytavan toimivan hyvin, vaikkei omakohtaisia kokemuksia (vielä) juuri olekaan.

Ostan siis ajatuksesi faktojen tarkastamisesta. Asiakkaan luuloihin käyttäjien tarpeista ei pitäisi luottaa, vaan kartoittaa tarpeet oikeilla käyttäjillä. Tämä on olennainen osa diplomityötäni ja toivottavasti käytännön kokemuksia meidän kontekstissamme seuraa keväämmällä.

Kiitos kirjavinkistä, lisäsin User and Task Analysis for Interface Designin lukulistalle.

Siihen ei vain pidä tyytyä. Vaikka asiakas usein tosiaan luulee tietävänsä loppukäyttäjistä vaikka mitä, faktat voi silti tarkistaa kentältä. Sen rahallinen vaikutus projektiin on itse asiassa ihan todella pieni verrattuna vaikkapa siihen, että koodataan ns. paras arvaus, joka osoittautuu sittemmin vääräksi tai joskus jopa aivan täysin vääräksi. Itse asiassa (oikein tehty ja tuloksekas) kälityö on todella halpaa verrattuna esim. kuukausien “määrittelyprojekteihin” (joiden lopputulos harvoin on hyödyllinen juuri kenenkään kannalta).

Perustelutyötä asiakkaan suuntaan vähentää se, jos ei anna vaihtoehtoja. “Meidän menetelmässä ratkaisujen käyttökelpoisuus arvioidaan siten, että niitä simuloidaan loppukäyttäjille. Sattuuko teillä muuten itsellänne olemaan kontakteja soveltuviin käyttäjiin? Voitaisiin nyt miettiä vaikka alkuun yhdessä, millaisia käyttäjiä tarvitaan.” Jos annat sellaisen kuvan, että käyttäjät ovat jokin lisäoptio, josta voisi olla hyötyä, homma päätyy samaan nippuun kuin muu yleisesti hyväksi tiedetty, johon ei ole nyt rahaa.

Osaamisen puutetta ei tietenkään korvaa millään, mutta käyttäjätutkimuksiin ja kenttäselvityksiin on (toisin kuin itse kälisuunnitteluun) hyllymetreittäin kirjallisuutta, joukossa hyvinkin konkreettisia teoksia, esim Hackos & Redish’n kirja, jonka nimi ei nyt heti tule mieleen. Lisäksi tekemälläkin oppii nopeasti, jos metakognitio on kunnossa.

Nuo “vähän käliä, paljon sisältöä”-sovellukset jäivät minulle esimerkin puuttuessa hämäräksi. Mitähän sinulla oli mielessäsi?