("ym." otsikossa tarkoittaa yleensäkin julkiselle taholle, esimerkiksi terveydenhuollolle, järjestelmiä kehittäviä ja toimittavia yrityksiä).
Joka tätä blogia on seurannut, tietää, että seuraan julkisen tahon tekemiä tietojärjestelmien tarjouspyyntöjä.
Havaintona siis se, että sellaisia tarjouspyyntöjä ei käytännössä ole, jossa käytettävyyttä aidosti vaadittaisiin tai jossa käytettävyys olisi aito kilpailutuskriteeri (mikä sinällään ei ole ihme, koska käytettävyyden vaatiminen on menetelmällisesti todella haastavaa).
Tästä seurauksena on tietenkin se, että toimittajien ei käytännössä tarvitse - eikä kannata - aidosti sitoutua toimittamaan hyvää käytettävyyttä/ helppokäyttöisiä järjestelmiä.
Tiedän, että järjestelmien toimittajilla (kuten Logicalla ja Tiedolla) on palveluksessaan käytettävyysasiantuntijoita. Aina joskus mietin heidän rooliaan projekteissa.
Ja tohdin tehdä tällaisen, toivottavasti ei liian provosoivan kysymyksen: Millaista on käytettävyysasiantuntijan työ projekteissa, jossa asiakas ei aidosti vaadi käytettävyyttä eikä projekti käytännössä ole aidosti sitoutunut toimittamaan käytettävyyttä? Vai ovatko käytettävyysasiantuntijat yleensäkään mukana näissä projekteissa?
Vai meneekö tässä ajatteluketjussani jokin pieleen?
Haluaisiko joku kertoa ajatuksiaan/ kokemuksiaan?
(Yleensä toivon, että kommentoitaisiin nimellä. Mutta ehkä tässä tapauksessa joku haluaa vastata anonyymisti)
Käytettävyys tietojärjestelmien hankinnoissa on paljon haastavampaa kuin tuotekehityksessä. Tämän blogin teemana on viestiä erityisesti *tietojärjestelmien hankkijoille* käytettävyyden varmistamisen näkökulmia: haasteita, havaintoja, ratkaisuja, ohjeita niin tarjouspyyntö- kuin toteutusvaiheisiin. Yleisempiä käytettävyysasioita: ks http://kaytettavyysnavigoija.blogspot.com/. - Kommentit tervetulleita! (mielellään omalla nimellä)
Tilaa:
Lähetä kommentteja (Atom)
Tilanne voi olla myös sellainen, että asiakas vaatii projektiin käytettävyysasiantuntijan. Ja anonyymi, suurehko yritys tarjoaakin projektin käyttöön sellaisen.
VastaaPoistaValitettavasti myöhemmin paljastuu, että ko. asiantuntijan käytettävyysosaaminen tarkoittakin sitä, että hän on ohjelmoinut käyttöliittymiä Swingillä.
Topin esimerkki ("asiakas vaatii projektiin käytettävyysasiantuntijan") on tosiaan yksi tapa, miten asiakkaiden näkee toimivan. Ja Topin mainitsema ilmiö (tulee käytettävyysasiantuntija joka tosiasiassa ei ole käytettävyysasiantuntija) on yksi syy, miksi homma ei pelitä.
VastaaPoistaJa toinen - periaatteellisempi - syy sille, että tämä lähestymistapa ei toimi on se, että käytettävyys tarkoittaa laatuvaatimuksia suunnittelulle. Eikä ole loogista, että suunnittelija(yritys) asettaa vaatimuksia itselleen.
Kysymyksen asettelu on tosiaan hieman erikoinen, ja kuten tuossa pohditkin, käytettävyysasiantuntijat eivät välttämättä saa työpöydälleen hankkeita, joissa käytettävyys ei ketään liiemmin liikuta.
VastaaPoistaMutta niissä projekteissa, joissa käytettävyysasiantuntijat ovat mukana, on vaikutusmahdollisuudet omien kokemusteni mukaan suhteellisen hyvät. Projektityössä asiantuntijoilla on aina oma arvonsa, ja heidän sanomisilleen annetaan painoa (kunhan ymmärtävät pysyä omalla tontillaan) meikäläisessä työkulttuurissa.
Eroja asiantuntijoiden välillä tietenkin on. Jotkut asiantuntijat lokeroidaan (tai omavalintaisesti lokeroituvat!) liian helposti vain yhden asian osaajiksi, ja silloin heillä voi olla edessään haaste saada hankkeessa pysyvää jalansijaa.
Hyvä käytettävyysasiantuntija on mielestäni sellainen, joka pystyy käsittelemään ja ymmärtämään suurtakin hanketta kokonaisuutena, myös teknologian näkökulmasta. Lisäksi hän tuo hankkeeseen – ja pitää toiminnassa – ne käytännöt, joilla varmistetaan asiantuntemuksen tehokas hyödyntäminen.
Vaikka oman kokemukseni piirissä useimmat hankkeet pääsevätkin tavoitteisiinsa, on toki ongelmiakin päästy oikomaan. Yksittäisten tapausten luettelointi ei tässä ole järkevää, mutta niitä voisi luokitella vaikkapa näin:
1) Käytettävyyteen panostetaan liian vähän: Hankkeessa on käyttöliittymän suunnitteluun varattu jonkin verran aikaa (useita iteraatioitakin), mutta suunnitelmaa ei validoida käytettävyystesteillä. Suunnitelmaan luotetaan liiaksi, tai sen uskotaan olevan dokumenttina riittävä, ja tämä taktiikka kostautuu käyttöönotossa. Asialleen omistautunut käytettävyysasiantuntija voi tietenkin testata käyttöliittymää vaikka paperiprotoilla "sissitaktiikoilla".
Hieman paremmassa tilanteessa suunnitelmat validoidaan joko ulkopuolisilla asiantuntijoilla tai käytettävyystesteissä käyttäjillä. Raportteihin suhtaudutaan niiden vaatimalla vakavuudella. Kuitenkaan hankkeelle ei aseteta pitkän aikavälin mittareita, jolloin on vaikea sanoa, kehittyikö käytettävyys kokonaisuudessaan, vai tuliko järjestelmästä ainoastaan uudella tavalla yhtä käytettävä kuin aikaisemmin.
2) Käytettävyyteen panostetaan vain alussa: Joissakin tapauksissa käytettävyystyö nähdään ainoastaan teknisenä piirustustehtävänä. Kun suunnitelmat on dokumentoitu, käytettävyysasiantuntijan roolia aletaan hiljalleen supistamaaan joko kustannussyistä, tai uskoen siihen että ongelma on jo ratkennut. Valvonta ja katselmoinnit jätetään tekemättä, ja suunnitelman eläessä käyttöliittymään ilmestyy muutoksia, jotka eivät ole enää käytettävyysasiantuntijoiden ajatusten mukaisia.
3) Käytettävyyteen panostetaan vasta lopussa: Kaikkein turhauttavin tilanne on helposti sellainen, jossa käytettävyysasiantuntija otetaan mukaan hankkeeseen oltaessa jo pitkällä toteutusvaiheessa. Ehkä työryhmässä ollaan havahduttu käytettävyysongelmiin, tai sitten vallalla on ajatus käytettävyydestä koko komeuden kruunaavana kirsikkana, joka voidaan hyvin asettaa kakun päälle vasta aivan lopuksi.
Jälkiviisauksiaan nieleskellen ei käytettävyysasiantuntijalla ole juuri muita vaihtoehtoja kuin pohtia, mihin ongelmiin – kenties yhteen suurempaan, tai muutamaan pienempään – käyttäisi työpanoksensa.
Mainioita pointteja Hannulla. Ikävä huomio myös omien kokemusteni pohjalta on se, että yleensä käytettävyyttä pidetään nykyisinkin monissa isoissa firmoissa projektista täysin irrallaan olevana kokonaisuutena, mikä voidaan "korjata" tai "varmistaa" projektin loppusuoralla.
VastaaPoistaBloggasin itsekin tätä aihetta sivuten ihan muutamia päiviä sitten. Jos aihe kiinnostaa, niin lukea voi osoitteesta http://www.kimmokuisma.com/2011/10/14/why-designs-fail-to-fulfill-user-needs-and-desires-how-to-avoid-the-pitfalls/
Itse puhuin tekstissä tosin käyttäjäkokemusta varten suunnittelusta, eli varsinainen käytettävyys on tuossa vain yksi elementeistä. Painopiste on aika paljon potentiaalisten ratkaisujen puolella.
Hannu jäsentää kokemuksiaan tosin hyvin.
VastaaPoistaMutta mitä nuo eri caset tarkoittavat asiakkaan kannalta? Eikö ole vähän ongelma asiakkaalle, jos käytettävyys perustuu siihen, miten toimittajan käytettävyysasiantuntijan "sissitaktiikka" onnistuu tms?
On myös projekteja, joissa vertaillaan käytettävyysasiantuntijoita monin erilaisin kriteerein, jotta mukaan saataisiin parhaat mahdolliset asiantuntijat. Myöhemmin sitten käy ilmi, että käytännössä tarvittiin joku piirtämään rautalankakuviksi asiakkaan määrittelyporukan speksit ja ajatus oli, että kokenut ihminen samalla varmistaisi lopputuotteen käytettävyyden ja korkealuokkaisen käyttökokemuksen ihan vain omalla kokemuksellaan ja asiantuntemuksellaan...
VastaaPoistaJuuri näinhän se on: hyvät resurssit ovat edellytys laadulle mutta eivät itsessään takaa laatua (se mikä periaatteessa takaa laadun on varsinaiseen lopputuotokseen sidotut laatuvaatimukset)
VastaaPoista