Miten varmistaa käytettävyys, jos käyttäjäkeskeinen suunnittelu ei sitä varmista?

Tuntematon käytettävyys -kurssin osassa 3 kerroin, miksi käyttäjäkeskeinen suunnittelu ei takaa käytettävyyttä.

Osassa 4 nyt kerron, mikä on se tapa, miten varmistaa käytettävyys. Videon mitta on 5 min 6 s.

Miksi tuloksena on huonoa käytettävyyttä, vaikka tehdään ehkä paljonkin käyttäjäkeskeistä suunnittelua?

Verkkokurssi Tuntematon käytettävyys jatkuu. Osa vastaa kysymykseen:

Miksi tuloksena on huonoa käytettävyyttä, vaikka tehdään ehkä paljonkin käyttäjäkeskeistä suunnittelua?

Katso video (5 min 30 s) tästä.

Mikä suunnitteluratkaisu on kriittisin käytettävyyden saavuttamiseksi?

Verkkokurssi Tuntematon käytettävyys jatkuu.

Osassa 2 vastaan kysymykseen: Mikä suunnitteluratkaisu on kriittisin käytettävyyden saavuttamiseksi? Alaotsikkona Vastaus EI ole "käyttöliittymä".

Katso luentovideo (6 min 35 s).

Ilmainen verkkokurssi "Tuntematon käytettävyys" alkaa kohta...

Suomi 100 vuotta -teemaa juhlistetaan monin tempauksin. Ja ajattelin, että miksei juhlavuotta voisi juhlistaa myös yhdellä käytettävyyskurssilla. Niinpä pidän syksyn aikana (ilmaisen) Tuntematon käytettävyys -verkkokurssin.

Kurssin nimi on tietenkin mukailtu tunnetusta kansallisromaanista, mutta se kuvaa myös kurssin sisältöä. Jonka voi tiivistää: Mitä jokaisen olisi tiedettävä käytettävyydestä ja käyttäjäkeskeisestä suunnittelusta, mutta mitä kaikki asiantuntijatkaan eivät tiedä.

Havaintoni on, että jo pelkästään termi "käytettävyys" ymmärretään kovin monin tavoin. Ja kun termien sisältö on epäselvä, niin ei ihme että keskustelu tökkii ja päätöksenteossa tehdään virheitä.

Kurssi on tiivis esitys tärkeimmistä ydinasioista, joiden uskon olevan kiinnostavia kaikille tietojärjestelmien kehitystyössä ja niiden hankinnoissa mukana oleville. Kurssi vastaa mm. seuraaviin kysymyksiin:

• Mitä oikeasti on "käytettävyys"? (ja mitä ei)
• Mitkä ovat keskeisimmät toimenpiteet, joiden kautta varmistetaan järjestelmän käytettävyys? 
• Miksi korkeatasoinenkaan käyttöliittymäsuunnittelu ei takaa hyvää käytettävyyttä?
• Mitkä suunnitteluratkaisut ovat kriittisiä käytettävyyden saavuttamiseksi? 
• Millaisia ovat aidot, toimivat käytettävyysvaatimukset?
• Millaista on "oikea" käyttäjäkeskeisyys: miten käyttäjät mukaan kehityshankkeeseen, ja miten ei?
• Miten haastatella käyttäjiä, ja miten? Miksi esimerkiksi käyttäjien mielipiteiden kysyminen ei ole suositeltavaa eikä tuloksellista?
• Millä tavalla käytettävyydestä pitäisi keskustella liiketoimintajohdon kanssa? Miksi käytettävyyttä ei tarvitse "myydä" liiketoimintajohdolle? 

...
Tavoitteena on, että tämän lyhyen kurssin jälkeen olet käytettävyyden ja käyttäjäkeskeisen suunnittelun keskeisten asioiden asiantuntija (käytännön tason käyttäjäkeskeinen suunnittelu on sitten laajempien kurssien asia). Tiedät ja ymmärrät keskeiset asiat niin, että voit asiantuntemuksella olla mukana ohjaamassa ja arvioimassa kehityshankkeiden käytettävyystyötä.

Pysy kuulolla! Seuraa blogia tai liity postituslistalleni tästä!

Miten käytettävyysammattilainen onnistuu tilaamaan hampurilaisen tilausautomaatilla?

Käydessäni sattumoisin Meilahden McDonaldsissa siellä oli yllättäen automaatti, jolla voi tilata hampurilaisen. Siis ilman, että tarvitsee jonottaa tiskille.

Kertoivat, että tilausautomaatti on ensimmäinen laatuaan Suomessa.

Idea siis sellainen, että tilauksen tekemisen jälkeen voi mennä pöytään odottamaan, ja salissa olevalta näytöltä näkee sitten, kun tilaus on valmis noudettavaksi (kuitissa on tilauksen numero, joka ilmestyy näytölle).

Mutta mitä arvelet, miten käytettävyysammattilaisella tilaus onnistui? Katsopa alla oleva video! Halutessasi voit jättää kommenttisi/ arvauksesi alle kommenttikenttään.

Videon pituus 3 min 36 s.

"Oikeaa käyttäjälähtöisyyttä ei ole kysellä käyttäjien mielipiteitä ja toiveita vaan faktatietoa heidän todellisesta maailmasta".

Yksi ammatillinen ydinsanomani. (IT-lehti 2/2017)

Miten hankkia helppokäyttöisiä tietojärjestelmiä? Yleisohje hankkijoille

Kuten tunnettua, julkiset hankinnat usein epäonnistuvat käytettävyydessä yhä uudestaan.

Miten hankinta pitäisi sitten suorittaa, jotta käytettävyys onnistuisi? Tässä videossa annan tiiviin yleisohjeen. Videolla käyn läpi:

• yleisiä ohjeita, jotka pätevät kaikkiin hankintatilanteisiin
• erityisiä ohjeita eri hankintatilanteita varten: valmis-/ räätälöitävät/ asiakaskohtaiset ohjelmistot

Tällaisessa lyhyessä videossa en kuitenkaan mene yksityiskohtiin. Käytettävyyden tuloksellinen huomiointi ja käytännön osaaminen hankinnoissa edellyttävät perusteellisempaa perehtymistä asiaan.

Videon pituus: n. 7 minuuttia.

"Miksi julkinen taho hankkii hankalakäyttöisiä tietojärjestelmiä?" Neljän minuutin vastaus

Julkisten tietojärjestelmien vaikeakäyttöisyys nousee aina uudestaan esiin. Yhtenä esimerkkinä pääkaupunkiseudun matkakortinlukija, jota olen analysoinut blogissani aika perusteellisesti.

Huomasin Googlesta jokin aika sitten taas uuden puheenvuoron, kirjoittajana Markus Norrgran, jossa aiheellisesti perätään parannusta asiaan. 

Mistä oikeastaan on kyse? Miksi julkinen taho hankkii jatkuvasti hankalakäyttöisiä tietojärjestelmiä? 

Olen kirjoittanut aika paljon (blogissa, Helsingin sanomissa jne.) ja pitänyt kursseja aiheesta. Mutta huomasin, että lyhyt videomuotoinen tiivistys asiasta puuttuu.

Tein nyt lyhyen (4 min 17 s) videon, jossa yritän vastata otsikon kysymykseen tiiviisti.

Miksi julkinen taho hankkii jatkuvasti 

hankalakäyttöisiä tietojärjestelmiä?

terveisin, Timo Jokela

PS. Jos sait tämän viestin kaverisi lähettämänä, pääset postituslistalleni tästä!

Kurssi "Käytettävyys ja käyttäjäkeskeinen suunnittelu" 31.5.-1.6.2017

"Taklaa käytettävyysongelmat jo ennen niiden syntymistä osallistumalla Käytettävyys ja käyttäjäkeskeinen suunnittelu -koulutukseen!

Käyttäjäkeskeisellä suunnittelulla luot helppokäyttöisiä tuotteita. Kurssilla käydään läpi suunnitteluprosessin kulku sekä joukko tärkeimpiä menetelmiä ja keinoja varmistaa, että palvelusi tai tuotteesi on helppokäyttöinen myös käyttäjien mielestä".

Järjestää Ari Hovi Oy, kouluttajina Aapo Puskala ja Timo Jokela.

Lisätietoja täältä.

Onko ratkaisu käytettävyyden ongelmiin se, että palkataan käyttäjiä kehitystiimiin?

Sain palautetta edelliseen videooni, jossa käsittelin erään lääkärin esityksessään esiin ottamia kysymyksiä:

• Millainen pitäisi olla järjestelmien koulutettavuus?
• Miten käyttäjien pitäisi osallistuaa kehitystyöhön?

Palautteen perusteella tein uuden (lyhyen) videon, jossa tarkennan vastausta jälkimmäiseen kysymykseen. Erityisesti vastaan kysymykseen: Onko ratkaisu käytettävyyden ongelmiin se, että palkataan käyttäjiä (esim. lääkäreitä) kehitystiimiin? 

Videon pituus: 3min 20s.

------------
EDIT (24.3.17). Sain palautetta tähänkin (kiitos siitä!). Ja pieni tarkennus videoon. Oleellista on, että kehitystiimin tulee hankkia ymmärrys asiakkaan maailmasta. Tietenkin on periaatteessa mahdollista, että palkataan käyttäjä kehitystiimiin, jos tuota ymmärrystä ei muuten pystytä hankkimaan.

Mutta käyttäjien palkkaaminen ei ole mielestäni yleinen ratkaisu. Lähtökohtaisesti syvällisen ymmärryksen asiakkaan maailmasta pystyy hankkimaan paljon kevyemmin kuin palkkaamalla. Näkemykseni on, että käyttäjien ja muiden substanssiosaajien haastattelut (kuitenkaan ei ihan millaiset vain - tästä enemmän toiste) ovat avainmenetelmä.

Ja vielä: näen riskin siinäkin, jos palkataan (yksi) käyttäjä kehitystiimiin. Mielestäni lähtökohtaisesti ei tulisi olettaa, että tämä käyttäjä osaa aina sanoa oikeat vastaukset (vaikka tuntisikin syvällisesti substanssin). Kehitystiimin tulisi joka tapauksessa hankkia syvällinen ymmärrys asiakkaan maailmasta.
-----------

PS. Liity postituslistalleni tästä!

Lääkäri ottaa esiin kaksi tärkeää käytettävyyskysymystä: Millainen pitäisi olla järjestelmien koulutettavuus? Entä millaista käyttäjien osallistuminen kehitystyöhön?

Huomasin tällaisen esityksen netissä. Lääkäri Lauri Lammi ottaa esiin - muiden asioiden ohessa - kaksi tärkeää käytettävyyskysymystä:

• Millainen pitäisi olla järjestelmien koulutettavuus? 
• Entä käyttäjien osallistuminen kehitystyöhön? 

Väittäisin, että nämä asiat ovat usein aika tavalla väärin ymmärrettyjä. Katso videolta vastaukseni näihin kysymyksiin! (videon pituus 7:16)

Matkakortinlukija. Osa 17. WEBINAARI 14.3.2017: Miten matkakortinlukijan* hankinta olisi pitänyt tehdä, jotta käytettävyys olisi varmistettu?

Tämä ilmainen webinaari on samalla viimeinen osa (#17) pääkaupunkiseudun matkakortinlukijan käytettävyysanalyysia. 

Webinaarissa vastaan kysymykseen: miten hankinta olisi pitänyt tehdä, jotta tuloksena olisi ollut aidosti helppokäyttöinen matkakortinlukija? Webinaarissa annan konkreettisia ohjeita hankinnan paremmiksi käytännöiksi ja tarjouspyynnön sisällöksi. 

Koska matkakortinlukijan hankinta edustaa yleisiä hankintakäytäntöjä, niin webinaarin sisältö pätee myös tietojärjestelmähankintoihin yleisemmin. 

Webinaarin ajankohta: ti 14.3.2017 klo 10 - 11. 

ILMOITTAUDU WEBINAARIIN TÄSTÄ!

Huom! Webinaariin on rajoitettu määrä paikkoja.

Verrattuna videoihin, webinaarissa on merkittävä etu: webinaari on live-tilaisuus, jossa voi myös esittää kysymyksiä. 

Webinaariin voi osallistua, vaikka ei olisikaan katsonut tämän blogin aiempia analyyseja matkakortinlukijan käytettävyydestä. Toki niistä saat hyödyllistä perustietoa. 

Matkakortinlukija. Osa 16: Miksi käytettävyys petti, vaikka paljonkin käyttäjäkeskeistä suunnittelua? Hankintatekniset syyt.

Nyt jatkuu sarjan ydin: miten matkakortinlukijan käytettävyysongelmat mahdollisia, vaikka (paljonkin) käyttäjäkeskeistä suunnittelua?

Edellisessä osassa kerroin "yleisiä" syitä; siis syitä, joiden vuoksi käyttäjäkeskeisyys ei välttämättä takaa hyvää käytettävyyttä myöskään tuotekehityksessä. 

Tässä osassa käyn läpi niitä syitä, jotka liittyvät erityisesti julkiseen kilpailutukseen ja hankintaan. Oma arvaukseni on, että nämä ovat todennäköisempiä syitä matkakortinlukijan käytettävyysongelmiin. 

Video 16a. Julkisen hankinnan pääpiirteet. Pituus 8:38

(taustaksi niille, joille julkinen hankinta ei ole tuttua) 

Video 16b. Hankintatilanteesta johtuvat (todennäköiset) syyt
käytettävyysongelmiin. Pituus: 10:56. 

Sarjan edellisen osan (15) voit katsoa täältä.

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

Matkakortinlukija. Osa 15: Miksi käytettävyys petti, vaikka paljonkin käyttäjäkeskeistä suunnittelua? "Yleiset" syyt.

Nyt menen koko sarjan ytimeen: miten matkakortinlukijan käytettävyysongelmat mahdollisia, vaikka (paljonkin) käyttäjäkeskeistä suunnittelua?

Toivon, että tähän astiset "tausta"-osat ovat olleet mielenkiintoisia. Olen käynyt läpi:

• matkakortinlukijan käyttöliittymän (yllättäviä) ongelmia
• ehdottanut toimivampia ratkaisuja
• käynyt läpi matkakortinlukijan käytettävyyssuunnitelmaa
• analysoinut, miksi sovelletut periaatteet eivät varmista käytettävyyttä
• analysoinut, miksi asetetut käytettävyysvaatimukset eivät toimi

Tässä osassa käyn läpi "yleisiä" syitä, mitkä matkakortinlukijan käyttäjäkeskeisessä suunnittelussa saattoivat mennä pieleen. Yleisillä syillä tarkoitan syitä, jotka ovat hankintatilanteesta riippumattomia; joita voi siis olla myös tuotekehityksessä.

Videon pituus: 5:24

Videossa viittaan ns. CUE (Comparative Usability Evaluations) -tutkimuksiin. Olen kirjoittanut niistä aiemmin blogissani, esimerkiksi täällä.

"Hankintateknisiä" syitä pohdin seuraavassa osassa.

Sarjan edellisen osan (14) voit katsoa täältä.
Sarja seuraavan osan (16) voit katsoa täältä.

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

Matkakortinlukija. Osa 14: Millainen oli matkakortinlukijan käyttäjäkeskeisen suunnittelun prosessi? Tulkintani

Miten matkakortinlukijan käyttäjäkeskeisen suunnittelun prosessi todellisuudessa meni?

Sitä en tiedä. Kuitenkin näen, että voi tehdä aika hyvän arvauksen näillä perusteella:

• mitä hankkeen käytettävyyssuunnitelmassa sanotaan ja 
• mitä olen yleensä nähnyt käytettävyyssuunnittelun tapahtuvan julkisissa hankinnoissa. 

Jos kiinnostusta riittää, niin voit pohtia videon perusteella itse: Miksi käytettävyys voi mennä pieleen, vaikka tehdään mahdollisesti paljonkin käytettävyystyötä? Esitän sitten oman tulkintani seuraavissa osissa. 

Videon kesto: 8.05. 

Sarjan edellisen osan (13) voit katsoa täältä.

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

Matkakortinlukija. Osa 13: "Väärää mielenrauhaa". Miksi matkakortinlukijan käytettävyysvaatimukset eivät toimi?

Tässä osassa analysoin matkakortinlukijan "Käytettävyysvaatimukset" -osion. 

• Miksi matkakortinlukijan käytettävyysvaatimukset eivät toimi? 
• Mitä tarkoittaa "väärä mielenrauha"? 

Lopuksi annan yksinkertaisen vinkin, miten säästää aikaa ja vaivaa tarjouspyynnön valmistelussa ilman, että menettää mitään käytettävyydestä. 

Samoin kommentoin Nielsenin heuristiikkojen toimivuutta käytettävyysvaatimuksina. Niitä ei käytetä matkakortinlukijan käytettävyysvaatimuksissa mutta olen nähnyt niitä käytettävän useissa tarjoupyynnöissä. 

PS. Edellisellä videolla (osa 12) pidin lyhyen "luennon" aiheesta mitä ovat käytettävyysvaatimukset. Suosittelen sen katsomista ennen näitä videoita. 

Video 13a: Johdanto, tulokset ja johtopäätökset. Videon kesto: 9:43. 

Video 13b: Vaatimusten yksityiskohtainen analyysi. Kesto 11:44.

Sarjan edellisen osan  (12) voit katsoa täältä
Sarjan seuraavan osan (14) voit katsoa täältä. 

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

"HSL ei tilannut helppokäyttöistä laitetta" (Helsingin sanomat 22.1.2017)

Tällainen välipostaus, joka aiheeltaan kuuluu matkakortinlukija-aiheeseen mutta ei ole varsianainen osa tätä analyysisarjaa.

Kun matkakortinlukijan käytettävyys (tai epäkäytettävyys) nousi esiin myös Helsingin sanomissa, kirjoitin mielipidekirjoituksen, joka julkaistiin 22.1.2017. Ei sisällä mitään uutta tämän blogin seuraajille; tiedoksi kuitenkin. 

Linkki kirjoitukseen. 

Matkakortinlukija. Osa 12: Mitä ovat käytettävyysvaatimukset - ja mitä eivät?

Piti tällä videolla jo mennä matkakortinlukijan käytettävyysvaatimusten analysointiin.

Kuitenkin ajattelin, että on ehkä järkevää tehdä välissä lyhyt luentovideo, aiheena: Mitä käytettävyysvaatimukset ovat - ja mitä eivät?

Kun analysoin matkakortinlukijan käytettävyysvaatimuksia tätä seuraavalla videolla, niin käytän analysoinnin "silmälaseina" käytettävyysvaatimusten määritelmää. Toivon, että on helpompi seurata analyysia, kun tietää nämä näkökulmat. 

Videon kesto: 5:49. 

Sarjan edellisen osan  (11) voit katsoa täältä.
Sarjan seuraavan osan (13) voit katsoa täältä.

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

Matkakortinlukija, osa 11: Kauniit käytettävyyden periaatteet, jotka eivät toimi. Miksi?

Nyt menen varsinaiseen asiaan. Eli näillä ja seuraavilla videoilla vastaan kysymykseen: Miten on mahdollista, että tehdään paljonkin käytettävyystyötä, mutta lopputulos on käytettävyydeltään ongelmallinen?

Matkakortinlukijan hankinnassa käytettävyyden varmistamista on kuvattu kolmesta näkökulmasta:

1. käyttäjäkeskeinen suunnittelu, 
2. käytettävyysvaatimukset ja 
3. käytettävyysarvioinnit (käytettävyyskatselmoinnit).

Näissä kahdessa videossa analysoin kohtaa 1: Miksi sinällään hyvän tuntuiset käyttäjäkeskeisen suunnittelun periaatteet eivät varmista käytettävyyttä? Edes periaatteellisella tasolla.

Video 11a. Johdanto ja käytännön perustelut (pituus 6:15):

Video 11b. Teoreettiset perustelut ja johtopäätökset (pituus 6:22) 

Huom! Analyysissa käytän välillä termiä "käytettävyyssuunnittelu", synonyymina termille "käyttäjäkeskeinen suunnittelu".

Edellisen osan (10) voit katsoa täältä. 

Seuraavan osan (12) voit katsoa täältä.

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

Matkakortinlukija, osa 10: Mitä ovat tarjouspyynnön käytettävyysvaatimukset ja -prosessi?

Matkakortinlukijan kehityksen käytettävyystyön suorittaja kilpailutettiin julkisesti. Tarjouspyynnön liitteenä oli dokumentti, jossa kuvataan käytettävyysvaatimukset sekä se, millainen hankkeen käytettävyysprosessi on.

Tässä videossa käyn läpi, mitä tuo dokumentti pitää sisällään. Tämä video ei siis sisällä vielä analyysia.

Video on pitempi kuin muut (15 min 50s). Ja ei ehkä ole välttämätön katsoa siinä mielessä, että käyn läpi dokumenttia myöhemmin analysoinnin yhteydessä.

Mutta katso video, jos kiinnostaa "vain" tietää, miten dokumentissa määritetään käytettävyysvaatimukset ja käytettävyysprosessi. Siis ilman, että mitenkään kommentoin tai analysoin niitä. Ja jos haluat haastaa itseäsi ja miettiä, mikä noissa mahdollisesti menee pieleen (ja mikä on hyvää). Voit sitten myöhemmin verrata omia ajatuksiasi minun ajatuksiini.

Edellisen osan (9) voit katsoa täältä. 

Seuraavan osan (11) voit katsoa täältä.

. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!

Matkakortinlukija, osa 9: Miksi huonoa käytettävyyttä, vaikka paljon käytettävyystyötä? Johdanto

Tähän asti olen käynyt läpi itse matkakortinlukijan käytettävyyspiirteitä. Tässähän en ole ainoa, moni muukin on tehnyt vastaavia analyyseja.

Mutta nyt sitten siirrytään siihen asiaan, joka minulla on varsinaisesti ollut mielessä. Miten on mahdollista, että tuloksena on ongelmallista käytettävyyttä, vaikka tehdään paljonkin käytettävyystyötä? Alla olevalla videolla lyhyt johdanto tähän (3 min 20s).

Edellisen osan (8) voit katsoa täältä. 

Seuraavan osan (10) voit katsoa täältä.

PS. Saat ilmoituksen sarja uusista osista liittymällä postituslistalle!