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 - mitä? (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. Mitä huonompi lähtökohtainen suunnittelu, sitä enemmän töitä 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".)

SUS on hyvä - mutta älä käytä sitä hankinnoissa väärin!

Kehoitukseksi niin Apotti-hankkeelle kuin muillekin järjestelmähankkijoille: Älä käytä SUSia (System Usability Scale) käyttäjäraadin tekemissä pisteytyksissä - äläkä käytä käyttäjäraateja muutenkaan... 


SUS (System Usability Scale, ks. esim. http://www.measuringusability.com/sus.php) on perinteinen ja toimivaksi havaittu "subjektiivisen käytettävyyden" mittari. 

SUS:in hyviä puolia ovat sen yksinkertaisuus ja julkisuus: kuka tahansa voi sitä käyttää. Ja sitä on siis paljon tutkittu (mm. juuri Jeff Sauro) ja se on havaittu validiksi (= mittaa aidosti käyttäjäkokemusta). SUSista on myös uusi "positiivinen" versio, joka on myös todettu validiksi. 

Näyttää kuitenkin, että SUSia käytetään helposti väärin. Olen kirjoittanut tästä aiemmin LinkedInin keskustelupalstoilla. Mutta nyt tässä asia vielä kertaalleen. 

------------------
SUS on tarkoitettu käytettäväksi käytettävyystestisession jälkeen mittaamaan subjektiivista käyttökokemusta. SUSin käyttöön liittyy seuraavat oleelliset piirteet: 

• SUS mittaa käyttökokemusta käyttäjän omakohtaisen järjestelmän käytön perusteella
• SUS mittaa nimenomaan käyttäjäkokemusta, EI käyttäjien mielipidettä järjestelmästä (käyttäjäkokemus ja käyttäjien mielipiteet ovat IHAN eri asioita)
• SUS mittaa käyttökokemusta kun käyttäjä on käyttänyt järjestelmää ensi kertaa; se siis ei sovellu tilanteeseen, jossa henkilö on käyttänyt järjestelmää jo pitempään

Nyt SUSia näytetään - tai ainakin suunnitellaan - käytettävän julkisten hankintojen yhteydessä tavalla, joka ei ole toimiva monellakaan tapaa. Tämä on siis tullut esiin aiemmin LinkedInissä, ja myös nyt, kun Apotti-hanke esitteli julkisesti käytettävyyden arviointisuunnitelmiaan. 

Tämä väärä tapa on seuraava: 

• Toimittajat esittelevät järjestelmiään käyttäjäraadille
• Käyttäjät vertailevat järjestelmiä, pisteyttämällä järjestelmiä käyttäen SUS-kyselyä

Tässä lähestymistavassa on monta ongelmaa

• Suoraan SUSin käyttöön liittyvä ongelma: käyttäjäraadissa käyttäjien arviointi perustuu järjestelmän näkemiseen ja toiminnan seuraamisen, ei siis omaan käyttökokemukseen. Tällaiseen SUS ei ole tarkoitettu, ja tällainen SUSin käyttö ei yksinkertaisesti ole validia.
• Käyttäjäraati ei yleensäkään ei ole validi käytettävyyden arviointitapa, siis että käyttäjät laitetaan arvioimaan käytettävyyttä "näkemisen perusteella". Tällaista käytettävyyden arviointitapaa ei ole, eikä tämä tuota valideja tuloksia (riippumatta käytetäänkö SUS-kyselyä vai ei). 
• Yleensäkään käytettävyyttä ei pitäisi laittaa vertailukriteereihin vaan käytettävyys pitäisi asettaa hankinnoissa pakolliseksi vaatimukseksi; ks. http://hankikaytettavyytta.blogspot.fi/2013/03/esimerkki-jos-haluaa-laatua-niin-hinta.html

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

Mikä olisi sitten toimiva tapa? Tästä olen kirjoitellut ja pitänyt esityksiä monesti aiemmin. Eikä tässä yhteydessä siitä enempää. Paitsi ehkä sen periaatteen verran, että käytettävyyden arviointia ei koskaan tulisi lykätä käyttäjien tehtäväksi - se kun on vain (epäeettistä) vastuun siirtoa suunnittelu- tai hankintatiimiltä käyttäjille. 

On kuitenkin helppo sanoa, mikä olisi helppo askel parempaan. Yksinkertaisesti: jos sinulla ei ole muuta tapaa kuin käyttäjäraati, mieluummin älä arvioi käytettävyyttä ollenkaan! Kaksi perustetta tähän: 

• Ei tule "väärää mielenrauhaa": että ei vain ajatella tehtävän käytettävyyttä vaikka sitä aidosti ei tehdäkään. Siis parempi olla rehellinen itselleen, todeta tämä ja jättää käyttäjäraati pois.  
• Säästetään (turhia) arviointikuluja. Esimerkiksi Apotin suunnitelmissa on aika massiiviset arvioinnit, jotka vievät huomattavasti sekä Apotti-projektin että käyttäjien (lukuisat eri HUS:in käyttäjäryhmien edustajat) resursseja. 

Kommentteja JHS 129 luonnokseen (Verkkopalvelujen suunnittelu)

(Pahoitteluni tämän kirjoituksen ulkonäköseikoista. Joko en oikein osaa käyttää blogspotia, tai sitten se ei tee aina siistiä jälkeä). 

TAUSTA

Julkisen hallinnon suositukset (JHS:t) ovat keskeinen referenssi julkisen hallinnon tietojärjestelmäkehityksessä. Sen vuoksi suositusten laatuun pitäisi kiinnittää erityistä huomiota.

JHS 129 on suositus verkkopalvelujen suunnitteluun. Sen uusi versio on kehitteillä, työnimenä “Julkisten verkkopalvelujen suunnittelu ja kehittäminen”. Siitä on julkaistu luonnos, jonka pohjalta pidettiin esittely- ja keskustelutilaisuus 6.6.2013. Itse myös osallistuin tuohon tilaisuuteen.

Luonnokseen pyydettiin kommentteja 24.6. mennessä, lähettämään Suvi Pietikäiselle, joka on hankkeen editori. Kirjoitan kommenttini tähän blogiin. Ajattelen, että asiasta voitaisiin olla kiinnostuneita laajemminkin. Ja blogin kautta halukkaat voivat kommentoida näitä kommenttejani. 

YLEISTÄ

Luonnoksessa on paljonkin kommentoitavia kohteita. Seuraavassa muutamia sellaisia, näin kesähelteiden keskellä kirjoitettuja. Kommenteissa kirjoitan aika paljon laadusta; samalla kuitenkin voin todeta, että näiden kommenttien laatu ei ole välttämättä loppuun hiottua.

Aluksi kerron yleiset päähavaintoni, ja sitten otan niitä esiin yksittäisinä huomioina. Näitä käyn läpi suosituksen kohtia suurin piirtein järjestyksessä. Kommenttini eivät ole tärkeysjärjestyksessä. Osin kommentoin luonnosta tilaisuudessa; tässä on osin niiden kertausta mutta myös muita.

Kommenteissani keskityn käytettävyys- /käyttäjäkokemusnäkökulmiin (käytän tekstissä yksinkertaisuuden vuoksia termiä käytettävyys tarkoittaen näitä kumpaakin). 

Kommenteissani viittaan kolmeen eri rooliin, jotka ovat tyypillisiä verkkopalvelun kehittämisessä: 

• Tilaaja/ hankkija:  viranomainen, joka hankkii verkkopalvelun
• Suunnittelutoimisto: kilpailutettu toimittaja, joka tuottaa palvelun suunnitteluratkaisut
• Käytettävyystoimisto: kilpailutettu toimittaja, joka tuo käyttäjänäkökulman (käyttäjätutkimukset, käytettävyysarvioinnit yms.) palvelun kehittämiseen. Voi olla sama tai eri toimittaja kuin suunnittelutoimisto.  

PÄÄHAVAINNOT

Suosituksen pitäisi olla enemmän laatu- kuin resurssikeskeinen

Nykyään julkisen tahon hankkimat verkkopalvelut joskus onnistuvat ja toisinaan epäonnistuvat. Nyt tämä suositusluonnos ei mielestäni muuta tätä tilannetta: suositusta voi noudattaa ja silti epäonnistua.

Ongelma on tähän asti ollut se, että verkkopalvelun kehityksen hankinnoissa ei käytännössä aidosti edellytetä suunnittelijan eikä käytettävyysasiantuntijan työltä laatua. Uudesssa suosituksessa pitäisi ottaa selkeä askel siihen suuntaan, että suunnittelijaa ja käytettävyysasiantuntijaa vastuutetaan työnsä laadusta. 

Nyt suositusluonnoksen käytettävyyssisältö on resurssikeskeistä. Tällä tarkoitan sitä, että suositusluonnos perustuu käytettävyysaktiviteettien tekemisen määrään: ajatellaan, että sitä parempi käytettävyys saavutetaan, mitä enemmän käytettävyysaktiviteetteja tehdään (= käytetään resursseja): käyttäjätutkimuksia, iterointia, käytettävyysarviointeja jne.

Nuo ovat toki tyypillisiä käytettävyystoimenpiteitä. Mutta hyvä käytettävyyttä ei välttämättä saa lainkaan aikaiseksi sillä periaatteella, että "mitä enemmän tehdään, sitä parempaa saadaan". Tällä tavalla muotoiltuna suositus on "avoin shekki" niin suunnittelu- kuin käytettävyystoimistoille: jokainen toimenpide kun tehdään suoraan tilaajan kustannuksella (tämä on tulkintani mukaan suositusluonnoksen yleinen sisältö).

Iterointia (suunnittele - testaa - suunnittele - testaa jne.) tarvitaan sen vuoksi, että suunnitteluratkaisut ovat ongelmallisia. Sitä enemmän iterointia tarvitaan, mitä huonompilaatuisista suunnitteluratkaisuista lähdetään liikkeelle ja mitä huonommalla laadulla käytettävyysaktiviteetteja tehdään.

Uskon kyllä, että suunnittelu- ja käytettävyystoimistot pyrkivät hyvään tekemisen laatuun. Mutta tällaisenaan suositusluonnoksen rakenne on se, että se periaatteessa tukee huonon laadun tekemistä. Suunnittelu- ja käytettävyystoimistot saavat sitä enemmän tilauksia, mitä huonompaa laatua tekevät. Tai sitten verkkopalvelu jää ongelmalliseksi, jos asiakkaalla ei ole varaa tilata lisää käytettävyyspalveluita. 

Kaikkiaan, tällaisen lähestymistavan seuraukset näkyvät tänä päivänä verkkopalvelujen isoissa laatueroissa. Verkkopalvelujen laatu kun riippuu siitä, millaista jälkeä suunnittelu- ja käytettävyystoimistot ovat sattuneet tekemään (niin, kyse ei siis ole pelkästään suunnittelun laadusta; kansainvälisten tutkimusten mukaan myös käytettävyysaktiviteettien laadulla voi olla isoja laatueroja).

Nykyisestä luonnoksesta on vaikea löytää kohtia, jossa kiinnitettäisiin huomiota suunnittelun ja käytettävyysaktiviteettien laatuun.

Suositusluonnosta pitäisi kehittää siihen suuntaan, että hankkija tilaa laatua (hyvää käytetävyyttä/ käyttäjäkokemusta) eikä resursseja (erilaisten käytettävyysaktiviteettien tekemistä). Tätä varten tilaajan pitäisi määritellä aidot käytettävyysvaatimukset, siis määritellä haluttu käytettävyyden taso, jota valitun suunnittelutoimiston pitäisi toimittaa.

Tämä johtaisi siihen, että suunnittelutoimiston on järkevä kiinnittää huomiota työnsä laatuun, koska työ on toimistolle sitä kannattavampaa, mitä vähemmän resursseja (mitä vähemmän käytettävyysaktiveetteja ja iterointia) tarvitaan.

Mitä tuollaiset käytettävyysvaatimukset tarkalleen ottaen ovat, siitä kirjoitan erikseen. Joka tapauksessa, ne tarkoittavat käyttäjien suoriutumiseen perustuvien mittareiden, mittausinstrumenttien ja tavoitetasojen määrittämistä.

Tämä tarkoittaisi myös, että laadulliset käytettävyysaktiviteetit (käyttäjätutkimukset, käytettävyysarvioinnit jne.) olisivat suunnittelutoimiston sisäistä toimintaa. Siis eivät tilaajan erikseen tilaamia toimenpiteitä.

Ajattelumallia voisi ottaa siitä, miten tuotekehitysfirmat "joutuvat" tekemään käytettävyyttä. He joutuvat itse ottamaan vastuun käytettävyydestä, eivätkä voi sälyttää sitä asiakkaille. Olisi hullua ajatella, että Apple tai Nokia vastuuttaisivat asiakkaita siitä, jos heidän suunnitteluratkaisut ovat ongelmallisia. Siinä maailmassa kuitenkin tehdään käytettävyydeltään parhaat ohjelmistot ja palvelut.

Käyttäjien rooli tulisi nähdä tiedon lähteenä

Suosituksessa tuodaan eri paikoissa esiin käyttäjien mukanaoloa suunnitteluprosessissa. Ja käyttäjien osallistaminen on tietenkin yksi keskeinen asia. 

Mutta käyttäjien osallistuminen ei tulisi tapahtua millä tavalla tahansa. Apple esimerkiksi suoraan sanoo, että se ei kysy käyttäjiltä. 

Pääsääntö tulisi olla se, että käyttäjien rooli tulisi olla pelkästään tiedon lähteenä "omasta työstään". Eikä muuta. Siis pääsääntöisesti käyttäjät eivät tee määrittelyjä, eivät määrittele tarpeitaan, eivät ehdota suunnitteluratkaisuja, eivät kommentoi suunnitteluratkaisuja tms. Käyttäjät voidaan toki laittaa tekemään näitä asioita, mutta sitten tuotoksiin liittyy suuret laaturiskit. Käyttäjät eivät ole määrittelyn/ suunnittelun/ käyttöliittymäarvioinnin asiantuntijoita, eikä heidän työnsä ole tällaisten asioiden tekemistä. 

Tämä tarkoittaa esimerkiksi sitä, että käyttäjätutkimuksen laatu ei koskaan tule olla riippuvainen siitä, ketä käyttäjiä haastateltiin tai havainnointiin. Laatu riippuu täsmälleen käyttäjätutkimuksen tekijästä: siitä, miten hyvän analyysin ja johtopäätökset tehdään saadun datan perusteella. 

Jotkut käyttäjät voivat toki olla fiksuja, ja tuottaa hyvää laatua. Mutta tällöin pelataan suurella riskillä, jota julkisen tahon mielestäni ei pitäisi ottaa.

Siis suosituksen viesti tulisi olla, että käyttäjät ovat tiedon lähteenä, ja suunnittelutiimi vastuullinen kaikkien tuotosten laadusta. Myös käyttäjädatasta.

Verkkopalvelun hankinta/toteuttamisen kilpailutus

Tämä osio on kirjoittamatta, joten siinä ei sinällään kommentoimista.

Mutta tämä on ehkä koko suosituksen kaikkein haastavin yksittäinen asia, ainakin käytettävyyden näkökulmasta. Mielestäni mikään nykyään tarjouspyynnöissä nähdyistä tavoista ei ole toimiva, joten nykyisistä käytännöistä ei kyllä kannata ottaa oppia tähän suositukseen.

Suosituksessa tulisi käyttää systemaattisemmin verbimuotoja.

Sitten tällainen vähän teknisempi asia. Nyt luonnoksessa näkyy monenmoisia verbimuotoja, tyyliin:

• tee
• on tehtävä
• on suositeltavaa tehdä
• on hyvä tehdä
• pyri tekemään
• voi tehdä
• tulee tehdä
• tehdään
• (enkä muitakin)

Nyt ongelmaksi jää, että on epäselvää, millä edellytyksillä voidaan sanoa, että jokin taho noudattaa suositusta.

Ehdotan, että tätä aluetta täsmennettäisiin. Yksi malli on ISO –standardien käytäntö. Niissä käytetään kahta verbimuotoa ilmaisemaan edellytyksiä sille, että standardia voidaan katsoa noudatettavan: 

•  on tehtävä (shall…) -lausumat
•  olisi tehtävä (should…) - lausumat

Organisaatio noudattaa ISO –standardia, jos

• kaikki ”on tehtävä” (shall) –tyyliset vaatimukset täytetään
• kaikki ”olisi tehtävä” (should) – tyyliset vaatimukset täytetään, ellei ole perusteltu, miksi niitä ei täytettäisi

Vaihejaossa keskeisintä on määrittää, mitkä ovat kunkin vaiheen konkreettiset tuotokset

Suosituksessa olisi selkeästi erotettava, (1) mitä tulee tehdä ja (2) miten asia tehdä. Ja keskeistä on kohta 1: mitä tulee tehdä. 

Sivulla 2 oleva kuva on esimerkki aktiviteeteista, joita tulee tehdä. Kuvaa pitäisi vain täsmentää, että mitä tuotoksia (sisällöllisesti) kunkin aktiviteetin tuloksena pitäisi syntyä. "Mitä tulee tehdä" -määrittely tehdään määrittelemällä, mikä on vaiheen konkreettinen tuotos.

”Miten” –asia on sitten se, miten aktiviteettien tuotokset tuotetaan. Käytännöissä aktiviteetit tehdään hyödyntäen erilaisia menetelmiä. Tiettyjen menetelmien suosittamisessa tulee kuitenkin olla varovainen, koska menetelmät elävät ja uusia menetelmiä syntyy.

Suositus ei saisi olla menetelmä- (miten tehdä) keskeinen vaan "mitä tehdä" (tuotos) -keskeinen.

KOMMENTTEJA YKSITTÄISIIN KOHTIIN

Lukuohje: 

• Sivu n kertoo, mihin luonnoksen sivuun viitataan
• kursiivi teksti on lainaus luonnoksen tekstistä
• normaali teksti on kommentti (jos siinä ehdotus tekstiksi, niin se on kursiivilla)

Sivu 2

Vaiheet ovat esiselvitys, suunnittelu, toteutus, testaus, käyttöönotto ja ylläpito sekä palvelun alasajo tai purkaminen. + Kuva

Teksti ei yhtä pitävä kuvan kanssa. Alkuvaiheet puuttuvat, samoin vaatimusmäärittely ja kilpailutus.

Olisi myös loogista, jos suosituksen rakenne olisi yhtenevä kuvan vaiheiden kanssa (jos ei, niin mikä merkitys kuvalla?)

Sivu 3

Tämä suositus ei välttämättä sovellu verkkopalveluihin, joiden käyttötarkoitus tai käyttäjäryhmät ovat hyvin rajattuja, kuten joidenkin ammatti- tai erityisryhmien verkkopalvelut. Suositus ei kaikilta osin sovellu suhteellisen monimutkaisille internetsovelluksille, kuten karttasovelluksille, sähköposti- tai puhelinsovelluksille, ammattikäyttöön tarkoitetut sovelluksille ja järjestelmille, peleille tai pelillistetyille palveluille.

En näe miksi tällainen negatiivinen rajaus. Mieluummin positiivisesti, tyyliin ”Tätä suositusta voinee hyödyntää myös verkkopalveluihin, joiden …., vaikka suositus ei ole erityisesti suunniteltu tällaisten suunnittelua varten".

Sivu 4

Verkkopalvelun pitää liittyä selkeästi organisaation toimintaprosesseihin sekä tavoitteisiin. Siksi palvelulla tulee olla omat organisaation johdon hyväksymät tavoitteet, jotka tukevat organisaation toiminnan tavoitteita.

Olisi hyvä konkretisoida, mitä ”tavoitteilla” tässä yhteydessä tarkoitetaan, jotta lukijoilla ei tulisi vääriä tulkintoja siitä, mitä suositus tarkoittaa. 

Sivu 4

Verkkopalvelun toteuttamista edeltää yleensä myös konseptisuunnittelu, jossa palvelun omistaja määrittelee verkkopalvelun tehtävät, tavoitteet ja käyttäjät, sekä tarkastaa, että ne ovat organisaation yleisen toimintastrategian mukaisia.

Konseptisuunnittelusta kommentteja myöhemmin.

Sivu 4

Tästä johtuen organisaation johdon tulisi seurata palvelulle asetettujen vaatimusten toteutumista.

Onko tässä mukana käytettävyys- /käyttäjäkokemusvaatimukset?

Sivu 5

Palvelun toteuttamisen aloittavan päätöksenteon tueksi on kerättävä esimerkiksi palvelukuvauksia, arvioita käyttäjämääristä ja nykyisten palveluiden käyttäjätyytyväisyystuloksia ja muita nykytilasta kertovia tietoja.

Onko kyseessä vaatimus? Keskeistä olisi määrittää, mitä asioita olisi selvitettävä (tuotokset). Nämä toimenpiteet ei pitäisi "olla pitäisi" vaan esimerkkejä, miten noita asioita (mitä?) saa selville. 

Sivu 5

Toiminnan tehokkuuden seuraamiseksi ja kehittämiseksi on luotava mittaristo.

Olisi hyvä konkretisoida, mitä ”mittaristolla” tässä yhteydessä tarkoitetaan. Onko mukana käytettävyys-/ käyttäjäkokemusmittareita? (Mielestäni pitäisi olla!)

Sivu 5

Otsikko: Verkkopalvelun tavoitteiden ja hyötyjen määrittely

Entä vaikuttavuus? 

Sivu 7

Määrittele ja sovi vastuut ja valtuudet sekä päätöksentekovaltuudet ristiriitatilanteissa.

Entä vastuu suunnitteluratkaisujen laadusta? Loogista on, että vastuu suunnitteluratkaisujen laadusta on suunnittelijalla (suunnittelutoimistolla). 

Sivu 8

Lähtökohtaisesti suositeltava malli (riippuu toki palvelun/organisaation luonteesta) perustuu jatkuvaan ja nopeasykliseen kehittämiseen.

Tämä on ihan puhtaasti menetelmäasia, eikä tulisi olla normatiivinen. Ja lisäksi tämä on puhtaasti resurssipohjainen suositus. 

Tämä on helposti ”avoin shekki” suunnittelijoille ja käytettävyysasiantuntijoille. Sitä enemmän syklejä kun tarvitaan, mitä ”huonompaa” suunnittelua.

Mieluummin teksti tähän tyyliin: Tilaajan tulee asettaa kehitettävälle verkkopalvelulle laatuvaatimukset, joiden täyttämiseen toimittajan tulee sitoutua. Suunnittelutoimisto voi käyttää jatkuvaa ja nopeasyklistä kehittämistä tai muuta harkitsemaansa suunnittelumallia. 

Sivu 8

Yhteiskehittämisen kautta on mahdollista saada asiakkaiden tarpeisiin liittyvät tiedot ja kehittämisideat suhteellisen helposti ja nopeasti.

Yhteiskehittämisellä pyritään siihen, että tuotteista ja palveluista tulee sellaisia, joita käyttäjät aidosti tarvitsevat. Toimimalla aktiivisesti loppukäyttäjien kanssa ja luomalla yhteistyörakenne vastuullisen kehittäjätahon suuntaan kehittäjät varmistavat relevantin ja realistisen user need -tiedon käytettävyyden koko kehitysprosessin läpi ja tuotannon puolelle.

On huomattava, että perinteinen osallistavan kehittämisen tapa, jossa esim. palvelusta tehdään mahdollisimman varhain prototyyppejä ja malleja, joita testataan oikeilla loppukäyttäjillä, ei ole varsinaista yhteiskehittämistä termin nykyisessä merkityksessä: osallistujavolyymit ovat pieniä eikä käyttäjillä ole roolia palvelun ideointi- ja suunnitteluvaiheissa.

Nämä ovat mahdollisia käyttäjien osallistamisen menetelmiä. Mutta kuten aiemmin totesin, julkisen tilaajan ei tulisi koskaan luottaa siihen, että käyttäjät tuottavat hyvää laatua. Käyttäjät voivat tuottaa hyvää laatua mutta ei välttämättä. Sen sijaan käyttäjät ovat aina hyvä tiedon lähde (mutta sen tiedon jäsentäminen ja sanoiksi pukeminen ei taas enää ole käyttäjien tehtävä).

Ja yksittäinen kommentti lausumaan "toimimalla aktiivisesti loppukäyttäjien kanssa ja luomalla yhteistyörakenne vastuullisen kehittäjätahon suuntaan kehittäjät varmistavat relevantin ja realistisen user need -tiedon". Toimenpide - seuraussuhde ei missään tapauksessa ole näin varma ("...varmistavat..."). Mieluummin esim. ".. ovat yksi keino saada user need -tietoa". 

Ja ehdottomasti ei "user need" vaan kunnolla määritelty termi suomeksi, siis käyttäjätarve. Ja sitten tulisi määritellä, mitä on käyttäjätarve on. 

Sivu 9 (”kehittämisen periaatteet”)

1.     Määrittele mitkä ovat käyttäjien tarpeet. Suunnittele palvelu ja verkkosivusto näiden tarpeiden pohjalta. Varmista myös yhdenmukaisuus organisaation tarpeiden ja tavoitteiden kanssa

Pitäisi määritellä tarkemmin, mitä tarkoitetaan ”käyttäjien tarpeilla”. Muuten periaate liian tulkinnanvarainen ollakseen hyödyllinen.

2.     Pidä palvelun sisältö ja verkkosivut yksinkertaisina ja selkeinä. Priorisoi palvelussa tarjottavat toiminnallisuudet ja sisällöt. Mikäli joku toinen taho tarjoaa jo palvelussaan vastaavia tietoja tai toimintoja, linkitä sivut tarpeellisin osin.

“Yksinkertaisina ja selkeinä” hyvä periaate, mutta liian löysä ohjaamaan suunnittelijan työtä. (ei objektiivisesti todennettavissa)

3.     Käytä suunnittelussa apuna olemassa olevia tietoja käyttötottumuksista ja käyttäjätutkimuksista. Tee palvelusta toiminnallisia demoversioita ja testaa ne käyttäjillä.

Alkuosa (Käytä suunnittelussa apuna olemassa olevia tietoja käyttötottumuksista ja käyttäjätutkimuksista). Olisi kuvattava vähän systemaattisemmin se, minkä tiedon pohjalta suunnittelu tulisi tehdä. Esim. tyyliin: “Käytä suunnittelussa apuna tietoja käyttäjistä,  käyttäjätehtävistä ja halutuista aikaansaannoksista, käytettävyysvaatimuksia sekä suunnitteluohjeistoja ja –standardeja.

Loppuosa (Tee palvelusta toiminnallisia demoversioita ja testaa ne käyttäjillä ) on taas esimerkki asiasta, joka on resurssilähtöinen ja sitä paitsi jonka pitäisi olla suunnittelutoimittajan sisäinen asia. Jos tätä ohjeistaa,  niin esim.  tyyliin: “Suunnittele harkitusti ennen kuin testataan. Suunnittelu testauksen kautta on helposti kallista ja resursseja vievää”. 

4.     Suunnittele palvelusta mahdollisimman yksinkertainen. Käytä runsaasti aikaa ja asiantuntijoita käytettävyyden ja selkeyden varmistamiseen.

“Mahdollisimman yksinkertainen” on periaatteen 2 toistoa.

 “Käytä runsaasti aikaa ja asiantuntijoita…” kuulostaa tämäkin avoimelta shekiltä käytettävyysasiantuntijoille. Itse muotoilisin tyyliin: Varmista, että suunnittelijoilta edellytetään vastuuta käytettävyyden tuottamista.

5.     Tee toteutus useamman toteutus-testaus -iteraatiokierroksen avulla. Testaa jokainen versio oikeilla käyttäjillä.

Tämäkin vaikuttaa myös avoimelta shekiltä suunnittelijoille ja käytettävyysasiantuntijoille. Mieluummin: edellytä suunnittelijoilta vastuuta vaaditun käytettävyyden tuottamisesta.

6.     Varmista palvelun helppokäyttöisyys ja selkeys. Huolehdi siitä, että palvelu on suunniteltu eritasoisille ja erilaisille käyttäjille. Varmista palvelun esteettömyys.

“Helppokäyttöisyys ja selkeys” periaatteiden 2 ja 4 toistoa.

On hyvä periaate, että palvelun suunnittelussa otetaan huomioon erilaiset käyttäjät (vrt. kommenttini periaatteeseen 3).  

7.     Selvitä milloin ja miten palvelua käytetään – tiedon haussa tai sen antamisessa, eri päätelaitteilla, kotoa tai julkiselta paikalta, eri kellonaikoina.

Hyvää asiaa mutta vähän epämääräinen. “Miten palvelua käytetään” aika laaja kysymys.

8.     Rakenna sähköinen palvelu, älä pelkkiä verkkosivuja.

Kovin tulkinnanvarainen. Mitä tämä tarkoittaa konkreettisesti?

9.     Ole johdonmukainen sivujen sisällön tai visuaalisten piirteiden suunnittelussa, mutta älä pakota 
kaikkia sivuja täysin samannäköisiksi. Eri palveluilla tai sisällöillä voi olla erilainen ulkoasu, esimerkiksi päätelaitteista riippuva sellainen. Tue visuaalisuudella sisältöä, organisaation strategiaa tai tarinaa.

Sivujen sisältö ja visuaalinen suunnittelu aika tavalla eri asioita. Ehkä eri periaatteiksi.

Sivu 9 (6 Esiselvitys verkkopalvelun kehittämisestä)

lisäisin ranskalaisiin viivoihin: ”Määritä, mitä aiotaan kehittää”

Sivu 10

Myös niissä tapauksissa, joissa palvelu annetaan ulkopuolisen tahon toteutettavaksi, tulee organisaatiolla olla vastuu tavoitteiden määrittelemisestä, palvelun ja prosessin suunnittelusta ja kehittämisestä ja linjauksista sekä käyttöönotosta.

” tulee organisaatiolla olla vastuu.. palvelun… suunnittelusta”. Siis tarkoittaako tämä sitä, että suunnittelijoilla ja käytettävyysasiantuntijoilla ei ole vastuuta oman työnsä laadusta? 

Tämä on asia, joka on mielestäni se keskeinen ongelma nykyään, ja tähän pitäisi saada muutos. 

Ongelmahan käytännössä konkretisoituu siten, että kehitettyjen verkkopalvelujen laatu on sattumanvaraista: laatua saadaan joko sillä, että suunnittelija tuotti hyvää laatua “sattumalta” tai sitten muutoshallinnan ja lisätilausten kautta.

Tämä lausuma kuuluu edelleen luokkaan “avoin shekki suunnittelijoille ja käytettävyysasiantuntijoille”.

Itse näen, että tekstissä voisi lukea jotain: “Myös niissä tapauksissa, joissa palvelu annetaan ulkopuolisen tahon toteutettavaksi, tulee organisaatiolla olla vastuu tavoitteiden määrittelemisestä, prosessin suunnittelusta ja kehittämisestä ja linjauksista sekä käyttöönotosta. Sen sijaan palvelun suunnitteluratkaisujen laatu tulisi olla suunnitteluratkaisun tuottajien vastuulla; on loogista, että suuunnittelija vastaa oman työnsä laadusta.

Sivu 11

Kokonaisvastuu palvelun laadukkaasta toteutuksesta pysyy ulkoa hankittaessa aina tilaajalla.

Tätäkään en ymmärrä: eikö toteuttajan pitäisi vastata oman työnsä laadusta?

Mielestäni pitäisi lukea jotain: “Kehittämistyö tulee tehdä siten, että suunnittelija vastaa toteuttamiensa suunnitteluratkaisujen laadusta.

Ks. myös kommenttini sivulle 10.

Sivu 11

Suunnitteluvaiheessa määritellään verkkopalvelun tavoitteet ja toiminnallisuus, palvelun prosessit, palvelulle asetettavat vaatimukset (sisältäen myös käytettävyyden ja esteettömyyden vaatimukset), tarvittavat tiedot, keskeiset käyttötapaukset tai -skenaariot, yhteys muihin järjestelmiin sekä tehdään alustava testaussuunnitelma ja testitapaukset.

“määritellään …. käytettävyyden vaatimukset”. Tämä on hyvä!

Mutta, näiden määrittelystä ei sitten kirjoitetaan missään kohdin enempää. 

Palaan myöhemmin siihen, mitä käytettävyysvaatimukset voisivat olla.

Sivu 16

Verkkopalvelu täytyy suunnitella tukemaan eri käyttäjäryhmien ja yksittäisten käyttäjien todellisia tarpeita heidän lähtökohdistaan.

Tämä on totta. Mutta käsite “tarve” pitäisi täsmentää, että se toimisi suosituksena. Tai sitten käyttää muita, täsmällisemmin määriteltyjä käsitteitä sen sijaan.

Sivu 16

Palvelua on kehitettävä perustuen todellisten käyttäjien kanssa toteutettuihin tutkimuksiin, kuten esimerkiksi käytettävyystesteihin sekä käytöstä saatavaan palautteeseen.

Tässä viitataan menettelytapaan (“todellisten käyttäjien kanssa”), joka yleensä ottaen ei tulisi olla normatiivinen. Mieluummin tyyliin: “Eräs vahva tapa kehittää palvelua on todellisten käyttäjien kanssa…” tms.

Sivu 16

Palvelussa asioinnin on edettävä asiakkaan näkökulmasta kokonaisuutena, joka vastaa hänen ymmärrystään asiointiprosessista ja siihen kuuluvista osista.

Tämä on sinällään varmasti totta, mutta liian tulkinnanvaraista toimiakseen suosituksena.

Sivu 16

Määrittele, mitkä ovat palvelun pääkohderyhmät sekä mitkä ovat toissijaisia kohderyhmiä. Palvelu suunnitellaan ja toteutetaan ensisijaisesti tukemaan pääkohderyhmiä tai muuten yleisiä käyttötarpeita. Toissijaisten ryhmien tarpeet huomioidaan, mutta siten, etteivät ne vaikeuta pääkäyttäjäryhmien tarpeiden täyttymistä. Myös huomioon otettavat erityisryhmät on määriteltävä, koska ne vaikuttavat palvelun toteutukseen.

Mitä tarkoitetaan “toissijaiset kohderyhmät” vs. “erityisryhmät”?

Sivu 16

Käyttäjäryhmien selvittämisessä ja määrittelyssä voidaan käyttää apuna esimerkiksi käyttäjätutkimuksia. Lisäksi voidaan ottaa yhteys erityisryhmiä edustaviin järjestöihin tai hyödyntää muiden tekemiä tutkimuksia ja tilastoja. Tutkimukset tuovat esiin tosiasioita eri käyttäjäryhmien mieltymyksistä ja tarpeista.

“Tutkimukset tuovat esiin tosiasioita…”. Tämä ei ole fakta vaan riippuu siitä, millä laadulla tutkimuksia tehdään. Mieluummin: “Tutkimusten avulla voidaan saada esiin tosiasioita…”.

Sivu 17

Verkkopalvelun suunnittelussa on alusta lähtien varmistettava palvelun käytettävyys ja käyttökokemus.

Tämä on hyvä! Paitsi että termi käyttökokemus on ehdottomasti määriteltävä (mitä sillä tarkoitetaan tässä suosituksessa)

Sivu 17

Käytettävyydellä tarkoitetaan sitä, kuinka helppoa, miellyttävää ja tehokasta palvelun käyttö on todellisessa käyttökontekstissa. Se vaikuttaa siihen, kuinka hyvin käyttäjä saavuttaa todellisen tavoitteensa palvelussa (viite: ISO 9241-11).

Käytettävyys on tässä tulkittu (käännetty?) epätarkasti. Virallinen määritelmä kuuluu: “Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi”.

Poiketen luonnoksen tekstistä, käytettävyys on siis keskeisesti sitä, missä määrin käyttäjä saavuttaa määritetyt tavoitteensa palvelussa (tuloksellisuus). Siis käytettävyys ON keskeisesti tavoitteiden saavuttamista (eikä pelkästään vaikuta tavoitteiden saavuttamiseen).

Ja toinen täsmennys: käytettävyys on määritettyjen tavoitteiden saavuttamista; ei pelkästään käyttäjän (oman) tavoitteensa saavuttamista.

Sivu 17

Selvitä käyttäjien tarpeet käyttäjätutkimuksen avulla ja perusta suunnittelu todellisiin tarpeisiin ja tavoitteisiin.

Tässäkin: määrittele mitä on “tarve”, tai käytä muita täsmällisempiä termejä. Myös termiä “tavoite” on käytetty epämääräistesti tässä.

“Selvitä … käyttäjätutkimuksen avulla”. Käyttäjätutkimus on  menetelmä, joka ei tulisi olla normatiivinen. Mieluummin tyyliin: “Määritä… esimerkiksi käyttäjätutkimuksen avulla”.

Sivu 17

Suunnittele palvelua iteratiivisesti. Ota käyttäjät mukaan suunnittelun aikana, käy läpi ja testaa jo karkeita suunnitelmia heidän kanssaan (esim. demoversiot).

Tässä on myös tehty menetelmien käyttö normatiiviseksi. 

Ja iteratiivinen suunnittelu ja testaus eivät tulisi olla normativiisia myöskään sen vuoksi, että ne ovat resurssi- eikä laatukeskeisiä. Iterointia tarvitaan nimenomaan sen vuoksi, että suunnitteluratkaisujen laatu on ongelmallista. Iterointi ei siis itsessään ohjaa laatuun, vaan on helposti “avoin shekki” suunnittelijalle ja käytettävyysasiantuntijalle”.

Itse pukisin tämän asian toisin: “Aseta palvelulle todennettavat ja validit käytettävyysvaatimukset, ja edellytä, että suunnittelijan tuottamat suunnitteluratkaisut täyttävät nämä vaatimukset. Jos suunnittelija käyttää iteratiivista suunnittelua, sen tulee itse vastata iterointikierrosten aiheuttamista kustannuksista.”

Sivu 17

Järjestä käytettävyystestaus palvelun prototyypillä tai viimeistään toiminnallisella palvelulla. Korjaa vähintään vakavat ongelmakohdat ennen käyttöönottoa ja laadi suunnitelma sellaisille korjauksille, joita ei heti voida tehdä.

Laadulliset käytettävyystestaukset pitäisi olla suunnittelijan sisäistä toimintaa, eikä hankkijan tulisi niitä pääsääntöisesti järjestää.

Sen sijaan hankkijan tulee testata sitä, että täyttääkö suunnitteluratkaisut asetetut käytettävyysvaatimukset (“määrällinen käytettävyystestaus”).

Sivu 17

Käytettävyyden arviointi kannattaa aloittaa mahdollisimman varhain, koska mitä myöhemmin muutoksia 
tehdään, sitä kalliimmiksi ne tulevat.

Pitäisi korostaa suunnitteluratkaisujen laatua heti alusta lähtien, ei arviointia. Kehittämistyö arviointeihin perustuen on aina jälkijättöistä, resursseja vaativaa ja kallista (niin, vaikka tehdään protojen testauksella). Lisäksi käytettävyysarvioinnit ovat aina rajattuja, ja arviointien laatu itsessään on vaikea varmistaa.

Jos suunnitteluratkaisujen laatuvastuu on toimittajalla (niin kuin siis mielestäni pitäisi olla), niin tämä on toimittajan sisäistä toimintaa ja sitä kautta suunnittelun pitäisi automaattisesti ohjautua oikeaan suuntaan (harkitut suunnitteluratkaisut alusta lähtien ja vähemmän iterointia). 

 Sivu 17

Käytettävyyden arvioinnissa havaitaan usein ongelmakohtia, jotka tyypillisesti liittyvät esimerkiksi 
rakenteen toimivuuteen, asioiden ja termien ymmärrettävyyteen, vuorovaikutuselementtien loogiseen käyttöön ja ymmärrettävyyteen sekä asioiden löydettävyyteen.

Nämä ovat esimerkkejä suunnittelun huonosta laadusta. Jos suunnitteluratkaisujen laatuvastuu on toimittajalla (niin kuin siis mielestäni pitäisi olla), niin toimittajan kannattaa kiinnittää huomiota suunnitteluratkaisujen laatuun alusta lähtien. Siis että tuollaisia ongelmallisia suunnitteluratkaisuja on minimaalisen vähän jo ensimmäisessä testattavassa versiossa.

 Sivu 17

Myös graafinen ja muu ilmaisutapojen arviointi - esimerkiksi ikonit, muu kuvitus, värit, äänet - ovat osa käytettävyyden arviointia.

Nämä ovat osa käytettävyyden arviointia niin kauan kuin ne vaikuttavat käyttäjien suoriutumiseen palvelun käytössä. Käytettävyyttä eivät siis ole “mainostoimistotyyppiset” asiat”.

Sivu 17

Arvioinnin tuloksena saadaan tavallisesti ongelmien luokitus niiden vakavuuden mukaan, selvitys ongelman syystä sekä perustellut korjausehdotukset.

Pitäisi siis olla suunnitteluratkaisujen toimittajan sisäistä toimintaa.

Sivu 17

Huomioi arvioinnit ja testaukset jo budjetoinnissa ja aikataulutuksessa.

Koska tämä on suunnitteluratkaisujen toimittajan vastuulla, pitäisi lukea: “Toimittajan tulisi huomioida arvioinnit ja testaukset jo tarjousta tehdessäsi”.

Sivu 17

Käytettävyyden arvioinnin ja testien tuloksena löytyy käytännössä aina korjattavaa, joten varaa 
projektisuunnitelmassa aikaa ongelmien korjaamiseen.

Suunnitteluratkaisun toimittajan sisäistä toimintaa.

Sivu 17

Mikäli projektin aikana ei ole taloudellisesti tai aikataulullisesti mahdollista tehdä useampaa arviointia 
tai testiä, tulee palvelu kuitenkin aina arvioida tai testata vähintään kerran. Tämä kannattaa yleensä tehdä hyvissä ajoin ennen julkaisua. Näin korjaukset saadaan tehtyä ennen julkaisua.

Tässä korostuu se ajattelutapa, että suunnitteluratkaisujen toimittajalla ei ole vastuuta käytettävyydestä.

Ehdotettu toimintatapa on sikäli oikea, että varmaan joitakin ongelmallisia suunnitteluratkaisuja voidaan saada korjatuksi. Mutta tätä lausumaa en suosittele, koska se osaltaan vesittää käytettävyyden suunnittelun kokonaan.

Ja myös se näkökulma, että jos suunnitteluratkaisuissa on yhtään isompia ongelmia, niitä ei todennäköisesti saada mitenkään korjatuksi tällä lähestymistavalla. (Itselläni on kokemusta tapauksista, jossa keskeisten käytettävyysongelmien korjaaminen olisi tarkoittanut järjestelmän uudelleen suunnittelua “alusta lähtien”).

Sivu 21

Palvelun tavoitteet: Mitä palvelulla pyritään konkreettisesti saavuttamaan?

Tässä käytetään termiä “konkreettisesti”, mutta pitäisi avata, mitä “palvelun tavoitteet” konkreettisesti tarkoittaa?

Sivu 21

Palvelun kohderyhmät…

Jos kohderyhmät on sama kuin käyttäjäryhmät, niin kannattaisi käyttää systemaattisesti samaa termiä. Jos kyseessä on eri asia, niin pitäisi kertoa mikä on ero.

Sivu 21

Palvelun ulkoasu ja graafinen ilme: Mikä on ulkoasun kattava teema?

Ulkoasu ja graafinen ilme ovat asioita, joita yleensä on helppo toteuttaa suunnittelun loppuvaiheessakin. Kannattaako ne ottaa mukaan jo konseptointivaiheessa?

Sivu 21

Palvelun rakenne: Rakenteen hahmotelma, palvelukokonaisuuksien päänäkymät ja 
siirtymät, käyttöliittymälogiikan periaatteet. Palvelukokonaisuudet.

Näen riskin siinä, jos tällaisia suunnitteluratkaisuja tehdään konseptointivaiheessa. Rakenne ym. ovat merkittäviä ja keskeisiä suunnitteluratkaisuja. Niiden laadukas suunnittelu edellyttää pitkälle vietyä jäsennystä kehittävästä sovelluksesta ja käyttäjien maailmasta. Ja tulkintani mukaan tällaista jäsennystyötä ole tehty konseptointivaiheessa.

Sivu 21

Visuaalinen suunnittelu: Millaista mielikuvaa verkkopalvelun visuaalinen ilme välittää, 
miten visuaalinen ilme ilmaisee verkkopalvelun lajityypin, millaisia metaforia tai 
analogioita mahdollisesti käytetään?

Kuten aiemmin totesin, nämä eivät ole perustavaa laatua olevia verkkopalvelun asioita. Näihin tuskin kannattaa keskittyä konseptointivaiheessa.

Sivu 21

Palvelun toiminnallisuudet: Mitä käyttäjät voivat verkkopalvelussa tehdä?

Myöhemmin tehtävää määrittelyä; ks. kommentit kohtaan “Palvelu rakenne”.

Sivu 22

Palvelun tietosisältö ja toiminnot tulee jäsennellä kokonaisuuksiksi, joille annetaan asiakokonaisuutta kuvaavat otsikot. Tavoitteena on, että rakenne vastaa käyttäjien lähestymistapaa ja tarpeita.

Mitä tarkoittaa “käyttäjien lähestymistapa ja tarpeet”?

Sivu 22

Rakennekartoituksessa on mietittävä palvelun muodostavan sivuston kokonaisrakenne ja osien, esimerkiksi sivujen keskinäiset yhteydet.

Tämä on keskeinen toimenpide. Tässä nyt sitten kaipaa menetelmällisiä suosituksia, miten tämä tehdään.

(tämä asia oli muuten jo osana konseptisuunnittelua).

Sivu 22

Palvelurakenteen suunnittelu

Itse ottaisin esiin myös palvelun konfiguroitavuuden. Tarkoitan tällä sitä, että palvelu suunnitellaan siten, että hankkija itse voi tehdä palveluun viilauksia käytön aikana (ilman että muutoksia saa ainoastaan tekemällä lisätilauksia toimittajalta).

Siis tyyliin: “Palvelu olisi suunniteltava siten, että se on tilaajan konfiguroitavissa. Tätä varten tilaajan tulee määrittää konfiguroitavat asiat…”.

Sivu 23

Suunnittelussa on ratkaistava, miltä palvelu näyttää käyttäjälle, mitkä ovat keskeisiä asioita, miten käyttäjää ohjataan yms.

Ja lisäksi erityisesti: millaiset suunnitteluratkaisut täyttävät asetetut käytettävyysvaatimukset.

Sivu 23

Suunnittelussa tulee ottaa huomioon yleiset käytettävyysperiaatteet sekä verkkoympäristön vakiintuneet käytännöt.

Periaatteessa juuri näin. Mutta haasteena on se, että “yleiset käytettävyysperiaatteet” ovat todentamattomasti määritelty, ts. niiden ei noudattamista käytännössä voi edellyttää toimittajilta.

Sen vuoksi suunnitteluratkaisujen toimittajilta tulisi vaatia käyttäjien suoriutumiseen perustuvien käytettävyysvaatimusten täyttämistä. Näiden täyttyminen käytännössä edellyttää, että suunnitteluratkaisut noudattavat noita yleisiä käytettävyysperiaatteita.

Sivu 23

Mikäli verkkopalvelun kautta käytetään sähköistä asiointipalvelua, huolehdi, että myös näissä palveluissa noudatetaan yhdenmukaista käyttökokemusta.

“yhdenmukaista käyttökokemusta”  - mitä tarkoittaa?

Sivu 25

Käyttöliittymän elementtien tulisi olla toiminnan etenemisen mukaisessa järjestyksessä, painikkeiden kokojen tulisi olla vakioituja sekä painikkeiden olisi oltava riittävän isoja. Käyttäjälle täytyisi tarjota käyttötilanteen mukaan laadittuja oletusarvoja ja valintalistoja.

Nämä ovat oikeita ohjeita, mutta eivät toimi hankinnoissa (käytännössä näiden vaatimusten täyttäminen on joko kiistanalaista tai vaatimukset voidaan toteuttaa toimimattomilla ratkaisuilla).

Ks. aiempi kommenttini/ sivu 23.

Sivut 25 - 27

Näillä sivuilla esitetään useita suosituksia:

Jokaisella sivulla tulee olla aloitussivulinkki. Aloitussivun linkkinä ei saa käyttää ainoastaan organisaation tunnusta.

Linkkien nimien on kaikissa tapauksissa oltava kuvaavia ja niiden tulee osoittaa käyttäjälle, minne ne johdattavat.

Linkkien nimien, linkkikuvien tekstimuotoisten vastineiden ja kuvametaforien (linkin nimen 
kuvavastineiden) on oltava selkeitä.

Ulkoisiin linkkeihin kannattaa liittää linkin sisältöön liittyviä arvioita tai kuvailuja.

Linkit on merkittävä visuaalisin keinoin, esimerkiksi alleviivauksella tai taustavärillä. Käyttämättömän ja 
käytetyn linkin välillä on oltava selkeä visuaalinen ero: käyttämätön linkki voi näkyä esimerkiksi sinisenä, käytetty tummanpunaisena. Linkkien erottamisessa voidaan myös käyttää hyväksi värien eri ominaisuuksia (esimerkiksi sävy, kirkkaus, tummuus).

Palvelusta ulos menevät linkit on syytä merkitä eri tavoin kuin palvelun sisäiset linkit.

Verkkopalvelun rakenteen ja käyttöliittymän on lisäksi oltava selkeitä.

Huolehdi, että käyttöliittymän asettelu on mahdollisimman yhtenäinen ja selkeä. Tekstin pitää selkeästi erottua taustastaan

Ohjaa käyttäjän katsetta sijainnin, erilaisten ryhmittelyjen, kontrastien (esimerkiksi koko, vahvuus, muoto, tummuuskontrastit) sekä ohjaavien merkkien avulla.

Käytä käyttöliittymien vakiintuneita esittämis- ja vuorovaikutustapoja tarkoituksenmukaisesti.

Tarpeettomia tyhjiä rivejä tulee välttää.

Liiallinen tekstitehosteiden käyttö tekee tekstistä epämiellyttävää ja levotonta luettavaa ja voi hävittää olennaisen asian.

Lauserakenteiden on oltava selkeitä ja verbimuodot helppoja

Teksti etenee loogisesti esimerkiksi syystä seurauksiin.

Käytettyjen lyhenteiden ja termien selitykset löytyvät helposti.

Tekstissä on käytetty väliotsikoita ja luettelomerkkejä.

Käytä kuvia harkiten. Kuvien tulee olla sisältöä tukevia.

Taustakuvat on valittava huolella: tummia ja sekavia taustakuvia pitää välttää.

Nämä ovat sinällään sisällöllisesti hyviä suosituksia. Mutta toisaalta nämä ovat esimerkkejä suosituksista, joiden todentaminen on kiistanalaista (esim. onko “verkkopalvelun rakenne ja käyttöliittymä selkeitä”) tai ne voidaan täyttää huonolla laadulla (esim. “Jokaisella sivulla tulee olla aloitussivulinkki”).

Tästä syystä tällaiset suositukset ovat käytännössä merkityksettömiä hankinnoissa.'

Sivu 28

Verkkopalvelun hankinta/toteuttamisen kilpailutus

Tämä on ehkä kaikkein haastavin osuus tästä suosituksesta (tätä siis ei ole vielä kirjoitettu ollenkaan)

Sivu 28

Projektille tulee määritellä myös laatukriteerit, joilla sen onnistumista mitataan.

Pitääkö laatukriteerit sisällään myös käytettävyyden/ käyttäjäkokemuksen? (mielestäni ehdottomasti pitäisi)

Sivu 28

Käytä toteutuksessa suunnitteluvaiheessa tehtyjä dokumentteja: palvelun prosessikuvaukset, käyttäjäryhmä- ja käyttötapausmäärittelyt, vaatimusmäärittely, käyttöliittymäkuvaukset, integraatiokuvaukset, palveluun liittyvät arkkitehtuurikuvaukset.

Nämä ovat tapoja, miten toimitaan paljolti nykyään. Ja kuten tiedetään, niin monesti tulokset ovat kuitenkin huonoja.

Mielestäni asioita pitäisi tehdä uusilla tavoilla. Ja mielestäni ne kulminoituu siihen, että määritetään palvelulle käyttäjien suoriutumiseen perustuvat käytettävyysvaatimukset.