perjantai 21. lokakuuta 2011

Käytetttävyyssuunnittelun perustandardi ISO 9241-210 ilmestynyt suomeksi

ISO 9241-210 kuvaa käytettävyyssuunnittelun ("Vuorovaikuittesten järjestelmien käyttäjäkeskeisen suunnittelun") keskeiset käsitteet, periaatteet ja aktiviteetit. Sisältää esimerkiksi käyttäjäkokemuksen määritelmän. Korvaa aiemman, hyvin tunnetun standardin ISO 13407.

Standardia saa SFS:ltä: http://sales.sfs.fi/servlets/ProductServlet?action=showquicksearch&keywords=9241-210&x=24&y=15 (standardithan pitää ostaa).

Standardi on periaatteessa suunnattu "laite- ja ohjelmistokehityksen sekä uudelleensuunnittelun prosesseista vastaaville henkilöille", mutta on ehdottoman suositeltavaa peruslukemista myös käytettävyysasiantuntijoille ja käyttöliittymäsuunnittelijoille.

Olin itse mukana valmistelevassa työryhmässä. Vaikka standardi on siis tärkeää peruslukemista alan ammattilaisille, kannattaa ottaa huomioon, että tämä(kin) standardi on osaltaan kompromissi,  ja sitä tulee tarkastella myös kriittisesti. Standardi sisältää hyvin keskeisiä asioita, mutta omasta mielestäni siihen jäi myös ongelmakohtia (käyn läpi standardia blogissa http://iso9241-210.blogspot.com/).

- Tein itse standardin peruskäännöstyön, jota sitten viimeisteltiin MetStan kanssa. Palautetta käännöksestä otan mielelläni vastaan, ja kysymyksiä saa esittää.

tiistai 11. lokakuuta 2011

Älä kysy näitä asioita käyttäjiltä


Yksi käytettävyysalan guruja on Jared Spool. Persoonallinen kaveri ja tosi hyvä esiintyjä. 

Kävin - tai käytiin porukalla - hänen kurssillaan joskus Nokialla ollessani joskus ammoin (vuonna 1995), aiheena paperiprotoilu. Se kurssi opetti paljon. Väitän muuten, että paperiprotoilulla oli ratkaiseva merkitys sille, että aikanaan Nokia oli käytettävyydessä markkinoiden ykkönen (ks. slide show paperiprotoilusta). 

Nyt Jared kirjoittaa aiheesta "kolme kysymystä, mitä ei tulisi kysyä käyttäjätutkimuksessa": http://www.uie.com/articles/three_questions_not_to_ask/

Ja ottaa esiin seuraavat asiat: 
  • älä kysy käyttäjältä tulevaisuudesta
  • älä kysy, kuinka käyttäjä suunnittelisi jonkun toiminnon (oma huomautus: tämä kiusaus tulee kovin helposti käytettävyystesteissä tai palavereissa käyttäjien kanssa)
  • älä kysy siten, että tarjoat valmista ehdotusta syyksi 
Nämä kaikki hyviä pointteja. Mutta eivät kaikki välttämättä uusia. Osallistuin CHI-konferenssin tutoriaaliin käyttäjien haastattelusta vuonna 1996. Pitäjänä Eileen Isaac. Hän toi esiin osittain samat asiat. Eli älä kysy käyttäjiltä:
  • mitä he tekisivät hypoteettisissa tilanteissa (vastaa tuota "älä kysy käyttäjältä tulevaisuudesta")
  • kuinka usein käyttäjät tekevät asioita
  • milloin he tekivät viimeksi jonkin asian
  • paljonko he pitävät jostain asiasta absoluuttisella skaalalla
Ja minä lisäisin tähän vielä oman mausteeni: 
  • kun kysyt, älä tyydy sellaiseen vastaukseen, jota et ymmärrä

perjantai 7. lokakuuta 2011

Millaista on käytettävyysasiantuntijan työ Logicalla, Tiedolla ym?

("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)


Älä laita käyttäjää jäsentämään työtään!

Lue Käytettävyysnavigoija-blogista:
http://kaytettavyysnavigoija.blogspot.com/2011/10/ala-laita-kayttajia-jasentamaan-tyotaan.html

Älä laita käyttäjiä jäsentämään työtään!


Mikä on toimiva tapa ottaa käyttäjät mukaan järjestelmänkehitysprojektiin? Asia tuli taas esiin neuvottelussa asiakkaan kanssa.

Aluksikin, on mielestäni myytti, että järjestelmänkehitysprojekteissa eivät käyttäjät olisi mukana, eikä käyttäjiä kuunnella. Kyllä minun havaintoni on se, että projekteissa kannetaan huolta siitä, että käyttäjät ovat mukana, käyttäjiltä kysellään jne. 

Silti tulokset ovat mitä ovat. Käytettävyys tökkii enemmän tai vähemmän.

Kyse ei ole siitä, että käyttäjät eivät olisi mukana, tai että käyttäjiltä ei kyseltäisi. Jopa väitän, että syyt käytettävyysongelmiin ovat osaltaan juuri siinä, että käyttäjät ovat mukana - mutta siinä "väärässä" roolissa, missä ovat tänä päivänä. 

Tänä päivänä käyttäjät otetaan mukaan projekteihin rooleissa, jotka eivät toimi. 

MIkä on sitten ongelma käyttäjien rooleissa? Tiivistäisin asian siten, että ongelma on se, että käyttäjille annetaan vastuu tarpeitteinsa ja työnsä jäsentämisestä

Oman työn ja tarpeiden jäsentäminen on vaativaa työtä. Ja väitän, että käyttäjiä ei aidosti kiinnosta laittaa omia resurssejaan sellaiseen asiaan, joka ei ole heidän varsinaista työtään. Toki kyse on myös osaamisesta - työn jäsentäminen vaatii oman ammattitaitonsakin.

Työ jäsentäminen on haastavaa, "aivoresursseja" kuluttavaa työtä. Ja sellaiseen työhön pitää aidosti pinnistellä. Jos nyt tätä tekee "velvollisuudesta jonkin verran", niin ei ihme, jos lopputulos ei ole laadukas. 

--------------------------
Esimerkki: Otetaanpa esimerkiksi se, että joku olisi kehittämässä uutta sähköpostiohjelmaa. 

Kaikki me olemme sähköpostiohjelman käyttäjiä; joillekin voi olla hyvinkin keskeinen työkalu. Niinkuin minullekin. 

Mutta jos joku tulisi haastattelemaan minulta tyyliin "millaisen sähköpostiohjelman haluat?", "mitä toiminnallisuuksia siinä pitäisi olla?", "miten nykyistä voisi parantaa?", "pitäisikö olla sitä ja tätä ominaisuutta?" jne. niin voin suoraan sanoa, että ei kiinnosta alkaa pohtia vastauksia tällaisiin kysymyksiin. Minua kiinnostaa hyvä sähköpostiohjelma, mutta sen kehittäminen ei ole minun päänsärkyni. 

Minä uskon, että samalla tavalla suhtautuisi haastatteluun moni teistä lukijoistakin. (Vai olenko väärässä?)

Joka tapauksessa, jos kehittäjät perustavat suunnittelunsa sille, mitä minä sanon tällaisessa haastattelussa, niin heikoilla ovat. 

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

Nyt kuitenkin kokemukseni mukaan järjestelmänkehityshankkeissa käyttäjiä laitetaan juuri tämän tyyppisiin rooleihin. Jäsentämään omaa työtään. Mikä taas ei ole heidän työtään. 

Itse teen työkseni käyttäjien työn jäsennystä, mutta kun juuri sähköpostin kehittäminen ei erityisesti ole minun työtäni, niin resurssieni laittaminen siihen - ei kiitos!

Eli yhteenvetona näkemykseni ja suositukseni on: Käyttäjien työn jäsennys on järjestelmän kehityksestä vastaavien työtä, ei käyttäjien. Sen sijaan käyttäjille sopiva rooli on olla tiedon lähteenä. 

Mitä tämä tarkoittaa menetelmällisesti, siitä myöhemmin enemmän. 

----------------------
PS. Tätä näkemystä tukee myös tuleva väitöskirja terveydenhuollon järjestelmien käytettävyydestä, jossa muun muassa tutkittiin sitä, missä rooleissa lääkärit haluaisivat olla mukana järjestelmien kehittämisessa. Mutta enpä kerro tästä enempää; Johanna Kaipio väittelee aiheesta Aalto-yliopistossa myöhemmin syksyllä (itse toimin esitarkastajana ja sitä kautta minulla etukäteistietoa)

maanantai 3. lokakuuta 2011

Käytettävyysvaatimus tarjouspyynnössä -pähkinä

Yksi tarjouspyyntö pisti silmään, jossa käytettävyys on huomioitu pakollisissa vaatimuksissa pariinkin kertaan: 

1. "... tarvitaan selkeä ja helppokäyttöinen työkalu. Siirtyminen ... tasolta seuraavalle tulee olla helppoa..."

Tukeeko toimittaja edellä kuvattua ominaisuutta?
Vastaus:___"

2. ".... (toiminnallisuuden) tulee olla helposti ymmärrettävässä ja käsiteltävässä muodossa ja raporttien ottaminen tulee olla helppoa..."

Tukeeko toimittaja edellä kuvattua toiminnallisuutta?
Vastaus:___"


Eli tarjouspyynnössä edellytetään, että toimittajan tulee sitoutua yllä olevien vaatimusten täyttämiseen. Eli toimittajan tulisi vastata yo. kysymyksiin "Kyllä" tai muuten tipahtaa kilpailusta pois. 


Kysymys lukijoille: Mitä hyvää ja mitä ongelmia yllä olevissa käytettävyysvaatimuksissa?