Kirjoitin edellisessä postauksessa kokemuksestani ekan käytettävyysluennon ja projektikurssilaisten konsultoinnin parissa: Käytettävyyttä opettamassa. Siitäpä heräsi ajatuksia siitä, mikä kulmani käytettävyys/UX-kasvatukseen voisi olla.
Mikä on UX-koulutuksen pihvi?
Luennon ja saadun palautteen ansiosta mulle kirkastui lisää se mihin suuntaan haluan käytettävyysopetusta viedä.
Tajusin palautteesta kuinka tärkeää käytettävyyden opetuksessa itse asiassa saattaakin olla itse käyttöliittymäsuunnittelu ammatillisena osaamisena, craftina, muun muassa:
- Heuristiikkojen ja vaikkapa gestalt-lakien oppiminen
- Erilaisten käyttöliittymien arviointi käytännössä ja sen miettiminen, mikä niissä on hyvää ja mikä huonoa.
- Vähitellen itsekin käyttöliittymäprotojen tekeminen ihan vaan kädet mutaan -kokemuksen aikaansaamiseksi
Mulle käytettävyyden/UX:n/UCD:n pihvi on kuitenkin lopulta seuraava. Se on ensimmäinen ja samalla vaikein askel: Suunnittelijana sen kanssa sinuiksi tuleminen, että en voi käyttäjieni puolesta olettaa, mitä he tarvitsevat. Periaatteessa helppo ymmärtää, käytännön työssä usein haastavaa hahmottaa.
Pragmaattisessa teknologiamaailmassa tuntuu monesta yksinkertaisimmalta se, että asiakas kertoo mitä tarvitsee ja sitten se toteutetaan. Sen tajuaminen on usein pitkä matka, että asiakas tai edes käyttäjä itse ei osaa kuvata, mitä tarkalleen tarvitsee. ”Ai mitenniin ei tiedä? Kai sen nyt täytyy tietää, mitä se on ostamassa!”
Teoreettinen keskustelu tästä ei usein vie kovin pitkälle. Tärkeintä on lähteä yhdessä liikkeelle ja nähdä, mihin haasteisiin törmätään käytännössä, oikeissa projekteissa. Hyvä peukkusääntö voisi olla seuraava:
Porukan saamiseksi mukaan on itse opetuksesta on tehtävä yhtä kokemuksellista kuin ne käyttäjäkokemukset, joita porukkaa opetetaan suunnittelemaan!
Tiedollinen tavoite on eri asia kuin oppimispolku sinne.
Voidaan ajatella, että tiedollinen tavoite olisi vaikkapa käytettävyystestauksen tärkeyden ymmärtäminen ja jalkauttaminen ohjelmistokehityksen arkeen. Vaatii kuitenkin aikamoista rohkeutta astua heti naamatusten käyttäjän kanssa, varsinkin oppimisen alkuvaiheessa.
Ainakin yliopistossa testaus tapahtui vielä labrassa ja testin järjestäjän rooli oli aika muodollinen. Tässä tullaan valinnan eteen – halutaanko:
- korostaa käytettävyysammattilaisten erityistä identiteettiä datan hankinnan teknisinä ammattilaisina, vai
- pyrkiä siihen että käyttäjien kohtaaminen tulee osaksi ohjelmistotuotteiden kehitystyön arkisia käytäntöjä?
Itse toivon nimenomaan vallankumousta jälkimmäisessä. Jos kaikki tai edes iso osa porukasta halutaan mukaan, käytettävyystestauksesta olisi opetettava selkeää ja helposti toteutettavaa versiota kuten Joel Testin kohdassa 12, hallway usability testing. Labratestit on sitten erikseen.
Käyttöliittymäsuunnittelun peruslainalaisuuksien opettaminen ei toki johda suoraan siihen, että oikeasti tiedetään miten suunnitteluprosessissa toimia. Sen sijaan tämän ammatillisen tiedon oppiminen ja soveltaminen toimivat hyvänä oppimisalustana, konstruktivistisena leikkikenttänä, jonka äärellä itsevarmuutta ammattilaisena voi kerätä.
Kunhan siihen realistiseen palautteeseen todellisuudelta, oikeilta käyttäjiltä, lopulta päästään.
Tiedollisesta tavoitteesta tarkemmin
Mikä on käyttöliittymäsuunnittelija joka ei tee käytettävyystestausta? Noh. Todellisuus on siitä vänkä paikka että se antaa suunnittelijan valehdella itselleen tietävänsä mitä käyttäjät tarvitsevat… öh, varsin pitkään. Voit tuntea kaikki säännöt siitä, miten hyvännäköisiä käyttäjäkokemuksia periaatteessa rakennetaan. Koko tiimi saattaa olla ihan bileissään siitä kuinka hieno juttu tää on. Saatetaan olla silti rakentamassa väärää sovellusta tai väärän käyttäjäryhmän näkökulmaa ajatellen.
Perinteisesti UCD opettaa meitä ajattelemaan, että lopulta ei voida tietää käyttäjän tarpeista paljoakaan asiantuntijoina. Käytettävyystestaus ja käyttäjän observointi (esim. contextual inquiry tai etnografiasta lainaavat tutkimukset) ovat tärkein keino todentaa että ollaan oikealla tiellä. Ainoa tapa oppia oikeasti tekemään parasta mahdollista käyttäjäkokemusta on lopulta tutkimuks… yrityksen ja erehdyksen kautta, palauteluupissa todellisten käyttäjien kanssa.
This is all good and well. Todellinen pähkinä oppimisen ohjausta suunnitellessa on kuitenkin: Miten saada opiskelijat lähtemään liikkeelle ja löytämään nämä oivallukset todellisuudesta itse? Olen kokenut UCD-opetuksen sävyn joskus hieman saarnaavaksi. Samoin keskusteluissa paljolti koodareiden kanssa olen huomannut, että pelkkä tosiasioihin kuten ”sinä et ole käyttäjäsi” vetoaminen voi tuntua keskustelun toisesta osapuolesta jeesustelulta, vaikken tarkoita sitä ilmaista.
Tähänastisten kokemusteni perusteella ilmiöpohjaisen oppimisen maailmasta löytyy tähän haasteeseen avuksi kummasti potentiaalia, jota ei vielä ole valjastettu!
Onwards!
Joka tapauksessa luennon pitäminen ja konsultointisessiot olivat tärkeä reissu mulle. Tästä on hyvä lähteä miettimään laajempia opintokokonaisuuksia. Ei liian teoreettisena aiheena, vaan nimenomaan kokemuksellisena, ammatillisena, käytännöllisena matkana.
Projektijohtamisen tasolla tärkein suunnitellessa syntynyt oivallus oli että ohjelmistoprojekteissa tarvitsisi korostaa palauteluuppeja, eli ymmärrystä käyttäjästä hankkimista systemaattisesti läpi projektin. Ei riitä, että tuote on kertaalleen käytettävyystestattu, vaan yhteyden käyttäjään täytyy jatkua läpi projektin jotta ymmärrys pysyy elossa ja ajan tasalla. Se tulee olemaan tulevaisuudessa vielä selkeämmin tämän opetuskerran kantava teema. (ks. Spoolin kriteerit ja käytettävyystestaus vs. test driven development, molemmat englanniksi)
Toistaiseksi tämä ei minusta näytä olevan suomalaisessa ohjelmistokehityskulttuurissa kovin kirkkaana:
Tavoitteenani kaikessa on, että suomalaiset ohjelmistotuotteet pärjää kansainvälisillä markkinoilla – sen seurauksena, että käyttäjät nauttivat niiden käyttämisestä. Kaikilla tasoilla.
“The day you think you know, your death has happened – because now there will be no wonder and no joy and no surprise. Now you will live a dead life.” -Osho
Otsakekuva: SATO StudioKoti Martinlaakso