Käytettävyyden arviointi = käytettävyyden vihollinen nro 1(?)

Käytettävyysarviointipohjainen suunnittelu ei välttämättä takaa käytettävyyttä vaan helposti johtaa huonoon suunnittelun laatuun ja "helposti ansaittuun" rahavirtaan tilaajalta suunnittelu- ja käytettävyystoimistoille. Ratkaisuna on mitattavat käytettävyysvaatimukset tarjouspyynnössä. 

----------------------
LinkedInissä käydään aina silloin tällöin mielenkiintoisia keskusteluja käytettävyyteen ja käyttäjäkokemukseen liittyen. Viimeksi JulkICT-strategia ryhmässä. Koska kaikki eivät välttämättä seuraa näitä keskusteluja, niin kirjoitan tähän julkisemmalle foorumille näkökulmia esille tulleista asioista.

Yhtenä ratkaisuna käytettävyysongelmiin nousi esiin ajatus, että käytettävyystestaus sisällytetään pakollisena jokaiseen tietotekniikkaprojektiin. 

Kuitenkin tämä lähestymistapa on potentiaalisesti erittäin ongelmallinen, jopa käytettävyyden vihollinen #1. Ainakin siten, kun sitä tyypillisesti sovelletaan tietojärjestelmien hankintakontekstissa. 

Miksi näin? 

Miten käytettävyystestaus - käytettävyyden perusmenetelmä - voi olla käytettävyyden vihollinen?

Käytettävyystestaus käytännössä tarkoittaa kehittämisprosessissa seuraavaa iterointia: 

1. Lähtökohtana on jokin suunnitteluratkaisu, joka on implementoitu sille tasolle (jonkinlainen prototyyppi), että sitä voidaan testata käyttäjillä  
2. Tehdään käytettävyystestaus (tekijä yleensä suunnittelijasta riippumaton taho), jossa havaitaan ongelmia ja vahvuuksia suunnitteluratkaisussa
3. Korjataan ongelmallisia suunnitteluratkaisuja, ja palataan kohtaan 2. 
4. Jatketaan kunnes... (monesti kunnes rahat loppuvat)

Tähän liittyy sisäänrakennettuna seuraavia ongelmia:

• Mitä huonompi lähtökohtainen suunnitteluratkaisu, sitä enemmän siinä on käytettävyysongelmia, ja sitä suurempia haasteita korjata suunnitteluratkaisuja
• Tästä taas seuraa, että tarvitaan enemmän tarvitaan iteraatiokierroksia
• Ja mitä enemmän iteraatiokierroksia, sitä enemmän kustannuksia tilaajalle ja toisaalta suoraa rahavirtaa: niin suunnittelu-  kuin käytettävyystoimistoille. Ja siinä vaiheessa kun budjetti on käytetty, niin suunnitteluratkaisu jää juuri sen verran torsoksi kuin sattuu jäämään.  

Ja vielä kohtaan 4:

• Jos ei ole määritetty mitattavia käytettävyysvaatimuksia, niin ei ole perustetta tietää, milloin on tehty riittävästi testausta ja iteraatioita (käytettävyystestausten lukumäärä kun ei takaa yhtään mitään käytettävyyden tasosta)

Siis miksi käytettävyystestaus voi olla käytettävyyden vihollinen #1? 

Sen vuoksi, että rahavirran näkökulmasta käytettävyystestauspohjainen iteraatio periaatteessa suosii huonoa suunnittelua (tai ainakaan ei kannusta hyvään suunnitteluun). Mitä huonompi lähtökohtainen suunnittelu, sitä enemmän tuloja niin suunnittelusta vastaaville (asiakas tilaa korjauksia) kuin käytettävyystoimistoille (jokainen uusi iteraatio = asiakas tekee uuden käytettävyysarviointitilauksen). 

Tällä en tarkoita, että joku tekisi tahallaan huonoa suunnittelua. Mutta vaikka suunnittelijan tahto olisi hyvä, niin pitäisikö huonosta jäljestä palkita lisätilauksin?

Toki hyviäkin käytettävyysesimerkkejä julkishallinnosta löytyy. Mutta periaatteessa yllä kuvattu menettely ei takaa laatua. Jos on saatu aikaiseksi hyvä käytettävyys, niin se on enemmän tai vähemmän sattumaa: se on johtunut joko (1) hyvästä "tuurista" ja/tai (2) lisätilauksista. Käytettävyyden hirveän laaja vaihtelu julkisissa hankkeissa on osoitus tästä.  

Ratkaisuehdotukset, jotka eivät ratkaise ongelmaa

Aluksikin, pari asiaa, jotka eivät ratkaise ongelmaa: 

• Edellytetään toimittajalta käytettävyysprosesseja tai -menetelmiä (käyttäjätutkimukset, käytettävyysarvioinnit tms.). Nämä ovat laadun edellytyksiä, mutta eivät itsessään takaa laatua (koska menetelmiä ja prosesseja voidaan soveltaa laaduttomasti)
• Edellytetään suunnittelijoilta käytettävyysosaamista. Tässäkin on pari ongelmaa. Aluksikaan, tyypillinen kriteeri "kokemus" (työvuodet, projektien lukumäärät, tms.) ei itsessään takaa mitään osaamisesta. Toiseksi, osaaminen ei itsessään takaa lopputulosta (sanoisin kuitenkin, että toki parempi kriteeri kuin prosessit tai menetelmät)

Prosessit ja osaaminen ovat edellytyksiä, mutta periaatteessa eivät takaa mitään lopputuloksen laadusta. 

Periaatteellinen ratkaisuehdotus

• Tarjouspyyntöön mitattavat käytettävyysvaatimukset (= määrittävät "riittävän hyvän" käytettävyyden) pakollisina vaatimuksina. Tätä kautta toimittajan "on pakko" kiinnittää huomiota käytettävyyteen (koska ovat pakollisia vaatimuksia)
• Loogisesti, (laadullinen) käytettävyystestaus on sitten toimittajan sisäistä toimintaa; tilaajan rooli olisi ehkä hankkia tarvittavia testikäyttäjiä. Toimittaja voi käyttää ulkopuolista käytettävyystoimistoa suunnittelunsa tukena oman harkintansa mukaan. Koska käytettävyystestaus sisältyy toimittajan tarjoukseen, niin toimittajan kannattaa kiinnittää alusta lähtien huomioita suunnittelun laatuun ja (kalliiden ulkopuolisten) käytettävyysarviointien ja iterointien minimoimiseen. Huom. Korostan vielä, että laadullisia käytettävyystestejä ei siis tilaa tilaaja vaan toimittaja - eli pitäisi toimia juuri toisin kuin nykyään tehdään. 
• Tilaaja tekee käytettävyyden hyväksymistestit - siis mittaa, täyttääkö toimittajan toimittama suunnitteluratkaisu asetetut käytettävyysvaatimukset. Jos ei, niin toimittajan tulee omakustanteisesti parantaa suunnitteluratkaisuja. 

------------------

Myönnän, että ehdotukseni on haastava moneltakin osin:

• Hankkijan kannalta tämä ei ole ihan helppo ratkaisu, koska ensimmäinen kohta edellä - validien, mitattavien käytettävyysvaatimusten määrittäminen - on haastavaa
• Tarkoittaisi uutta ajattelua kummallekin osapuolelle. Esimerkiksi ei enää olisi suunnitteluaikaisia käyttöliittymäratkaisujen katselmointeja, vaan tilaajan olisi periaatteessa annettava toimittajan tehdä millaiset suunnitteluratkaisut tahansa, kunhan ne vain täyttävät asetetut käytettävyysvaatimukset
• Tarjouskilpailutuksessa tarkoittaa, että toimittajan olisi ruksittava täyttävänsä käytettävyysvaatimukset (koska muuten pullahtaa kilpailutuksesta pois). Sitä kautta toimittaja voi päätyä lupaamaan sellaista, josta sillä ei ole mitään aiempaa kokemusta

Mutta enpä ole nähnyt myöskään kenenkään esittävän vaihtoehtoisia ratkaisuja. Olisiko sinulla, arvoisa lukija?

(Sen periaatteellisen ratkaisun jätin tästä pois, että tilaaja toimii kuten "ohjelmistotalo": eli tilaajalla on vahva järjestelmäsuunnitteluosaaminen ja se hankkii ainoastaan henkilöstöresursseja. Käsittääkseni Tike toimii näin? Mutta ei liene voi olla lähtökohtana, että kaikki julkiset hankkijat ovat "ohjelmistotaloja".)