Kotitehtäväpalautus 4: Matti Parkkonen

Ihmisten tarpeiden ja tekniikan rajoitteiden yhteensovittaminen on mielestäni vieläkin lastenkengissä. Graaffisten käyttöliittymien käyttö on helpottanut tietokoneidän käyttöä mutta samalla laajentanut käyttäjäkuntaa täysin kokemattomilla käyttäjillä. Enää tietokoneet eivät ole pienen ammattilaiskäyttäjäkunnan käytössä, eikä peruskäyttäjää kiinnosta enää tekniikka vaan mitä ohjelmilla voidaan tehdä. Kuitenkin ohjelmateollisuus on laahannut perässä ja käyttöliittymän ja helppokäyttöisyyden suunnittelu on jätetty viimeiseksi, jos aikaa on riittänyt.

Esimerkissä ollut teknisen suunnittelijoiden viesti "vastaanotettavan kuvan säätö ei ole teknisesti mahdollista tässä käytettävän standardin mukaan" on aika tyypillinen vastaus, kun tekniikasta tietämättömät käyttäjät haluavat uusia ominaisuuksia. Tarve halutaan vain torjua käytettävän tekniikan avulla, vaikka pitäisi etsiä keinoa miten ongelma saadaan hoidettua.

Ongelmat saataisiin ratkottua helpommin, jos loppukäyttäjä otettaisiin mukaan alunalkaen. Tällöin käytettävä tekniikka on vielä avointa ja käyttäjän toivomukset voidaan vielä toteuttaa. Käyttöliittymän "maalaaminen" ohjelman päälle loppuvaiheessa rajoittaa liittymän suunnittelua ja estää tehokkaasti käyttäjän haluamien ominaisuuksien lisäämisen juuri tuolla "koodi on valmista, sitä ei muuteta käyttöliittymän takia"-menttaliteetilla. Menttaliteetti on usein realistinen, pieni muutos käyttöliittymässä vaatisi valtavasti työtä koodin puolella.

Käyttöliittymä pitää suunnitella yhtäaikaisesti ohjelman kanssa. Tällöin valmiin ohjelman rajoitteita saadaan pienennettyä verrattuna käyttölittymän "maalaamiseen". Mieleeni tulee, että ehtivätkö ohjelmoijat pitkän projektin aikana fiksautua johonkin ratkaisutapaan? Tällöin hei eivät näe/usko/tiedosta, että ongelma ratkeasi muuttamalla ohjelman rakennetta.

Käyttäjäkeskeisessä suunnittelussa tutkitaan jo alkuvaiheesa tuotteen kohderyhmän ominaisuuksia. Helpoiten palautetta saadaan, jos on olemassa jo vastaava tuote. Tällöin kysytään tuotetta käyttäneiltä heidän mielipiteensä ja parannusehdotuksena. Yhtenä tärkeänä tiedonlähteenä on tällöin myös käyttäjän antama kritiikki ja kysymykset tuotteesta esim. puhelinneuvontaan.

Käyttäjäskeskeisessä suunnittelussa voidaan käyttää heuristista analyysia, jossa tarkoituksena on löytää ongelmia käytetävyydessä antamalla tuote testattavaksi usealle käyttäjälle. Ongelmat voidaa sitten ratkaista osana iteratiivista suunnitteluprosessia.

Kysymykseen "Millainen tuotetesuunnitteluprosessin pitäisi olla?" onkin vakeampi löytää tarkaisua. Tuotesuunnittelussa aikataulu/resurssit/tekniikka sanelevat pitkälti minkälainen tuotesuunnittelusta tulee olla. Pitää myös muistaa, että monet ohjelmathan eivät koskaan tule valmiiksi, niistä julkaistaan vain päivitettyjä versioita. Tällöinhän tuotesuunnitelu ei ala eikä lopu, esimerkkinä MS-Office-tuotteet. Ongelmana on myös, ettei todella suurten ohjelmien pitkäaikaisesta suunnitelusta ole riittävästi kokemuksia.

Ideaalisessa tilanteessa heti suunnitteluvaiheen alussa käytäisiin läpi kilpailevat tuoteet/selvitettäisiin, mitkä käyttäjät haluavat/tutkittaisiin eri tekiikoita toteuttaa tuote. Lyhyesti sanottuna mitä-miksi-miten. Näiden avulla voitadaan toteuttaa prototyyppi ja katsoa, miten käyttäjät reagoivat siihen.

Prototyypin perusteella päästään itse tuotteen toteuttamiseen. Parhaimmillaan tämä tarkoittaisi ennalta suunnitellun toteuttamista, ei uusien ideoiden lisäämistä toteutuksen aikana. Valmis tuote annettaisiin käytettävyystesteihin ja asiantuntijarvioihin. Mikäli virheitä löytyy jatketaan toteutus->testi sykliä kunnes ennalta-asetetut tavoitteet on saavutettu.