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ä.
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)
Hyvä kirjoitus Timo. Olen täysin samaa mieltä. Jokainen on asiantuntija omalla aluellaan. Turha käyttäjää on laittaa sellaiseen roolin mihin hänellä ei ole osaamista. Se on resurssien haaskausta ja johtaa huonoihin lopputuloksiin.
VastaaPoistaLinkedIn-palstalla tuotiin esiin menetelmänä fasilitointityöpajat. Ja varmaan ne ovat ihan toimiva menetelmä.
VastaaPoistaMutta pointtini on, että riippumatta menetelmästä, on riski antaa työn jäsennys käyttäjien tehtäväksi. Joskus voi onnistua, mutta on (iso) riski, että ei onnistuta.
Tästä näkökulmasta fasilitointityöpajojenkin pitäisi toimia niin, että vastuu lopputuloksen laadusta ei ole sen osallistujilla.
Ehkä asian voisi tiivistää siten, että käyttäjien tekemän jäsennyksen laatu riippuu käyttäjien kyvyistä. Parempi on, että on suunnittelutiimi pitää laadun omissa käsissään.
Esimerkiksi (oikein suunnitellun ja suoritetun) käytettävyystestin tulosten laatu ei riipu siitä, ketkä sattuivat olemaan käyttäjiä. Vaan tulosten laadun ratkaisee se, miten laadukkaita havaintoja ja johtopäätöksiä suunnittelutiimi teki testien perusteella.
Juuri näin, käyttäjät eivät voi määritellä lopputulosta tai sen laatua, siitä vastaavat suunnittelijat. Käyttäjät tuovat työhön vain substanssinsa.
VastaaPoistaMeillä on toimialoilla käytössä mm. useita erilaisia toimintajärjestelmiä, joista halutaan tehdä tietointegraatioita sähköiselle työpöydälle (toimialojen tahto). Työpöydän suunnittelijoilla ei voi olla tietoa ja käyttökokemusta noista toimialojen omista toimintajärjestelmistä eikä myöskään sananvaltaa niiden käyttöön liittyen. Niiden käyttötavoista, tiedoista ja työnkuluista tietävät toimialalla työskentelevät henkilöt.
Työpöydän suunnittelijat voivat työpajoissa onkia esiin näitä toiveita ja vaatimuksia, yhdistää muihin/muiden vastaaviin toiveisiin tai vaatimuksiin ja etsiä toimivaa ja laadukasta ratkaisua kuinka työpöytä voi palvella heidän tarpeitaan (esim. työpöydän ratkaisut, joilla tieto toimintajärjestelmästä on helpompi käsitellä/saavutettaa/löytää).
Vaikeinta on se, että jopa saman yksikön sisällä voi olla erilaisia käsityksiä siitä, miten toimintajärjestelmän tietoa pitäisi hyödyntää. Työpajoissa on tarkoitus, että he itse ensin löytävät yhteisen tahtotilan omiin toimintoihinsa liittyen ja saavat myös "vertaistukea" sellasilta toimialoilta, joissa näitä ratkaisuja on jo toteutettu tai suunniteltu. Työpöydän suunnitteljoiden tehtävänä on vetää asiat yhteen ja lähteä suunnittelemaan siltä pohjalta toimivaa ja sit parasta ratkaisua.
Tuossahan se olikin jo aika hyvin kiteytettynä, eli "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ä."
VastaaPoistaAika usein sovelluskehityksessä vain unohdetaan se, kuinka pitkälle tuon tiedon lähteenä olemisen voi viedä. Esimerkiksi informaatioarkkitehtuurin osalta löytyy nopeita ja helppoja keinoja (mm. korttien lajittelu) selvittämään, miten käyttäjät ryhmittelevät asioita. Perinteisestihän tuo rajautuu aika pitkällä sisältöihin ja hierarkioihin sovelluksessa, mutta miksei samaa käytäntöä voisi soveltaa toiminnallisuuksienkin ryhmittelyssä.
Liian usein näkee, että tuo vaihe skipataan kokonaan ja toteutus pohjautuu suunnittelijoiden omiin mieltymyksiin ja ajatusmalleihin. Mielestäni suunnittelijoiden pitäisi jossain määrin pyrkiä minimoimaan omaa roolinsa näkyvyyttä tässä kuviossa ja pyrkiä luomaan yleisesti toimiva kokonaisuus käyttäjien mieltymysten pohjlta. Miten tuohon keskitiehen sitten pääsee tehokkaimmin, se onkin jo huomattavasti vaikeampi kysymys.