Mitä Yhteentoimivuusalustan käyttäjät vastasivat uudenlaiseen kyselyyn marraskuussa 2020?

Kyselyn taustaa

Kysyimme marraskuussa 2020 Yhteentoimivuusalustan käyttäjien mielipidettä kymmeneen ehdotettuun ominaisuuteen tai toiminnallisuuteen. Vuoden 2020 aikana alustalle ei tehty juurikaan kehitystyötä, mutta vuoden 2021 tiekarttaa varten halusimme saada palautetta kehitysehdotuksista. Koska rahaa ja tekijöitä ei ole rajattomasti, haluamme tunnistaa ne ideat, joiden toteuttamisesta koituu hyötyä mahdollisimman monille. Kysymyksenasettelu oli tällä kertaa erilainen kuin aiemmin, sillä hyödynsimme kyselyssä niin sanottua Kano-mallia.

Saamme alustan työkaluihin kehitysehdotuksia ja palautetta useiden eri kanavien kautta, kuten sähköpostiviesteinä, kommentteina alustan työkalujen esittelytilaisuuksissa ja Slack-kanavien kautta. Ne kuitenkin kertovat vain yhden käyttäjän tai käyttäjäryhmän toiveista. Yksittäisten toiveiden kautta ei saa näkymää siihen, kuinka moni muu käyttäjä toivoo samaa ominaisuutta, mikä on toiveen prioriteetti tai onko toive kenties ristiriidassa jonkun toisen käyttäjän tarpeen kanssa. Kano-mallin avulla pyritään saamaan näitä ulottuvuuksia paremmin esiin. Kaikki asiakkaiden esittämät kehittämistoiveet eivät ole samanarvoisia.

Yhteentoimivuus on sinänsä muutakin kuin tekninen alusta, jonne tietosisältöjen kuvauksia määritellään. Monet vastaajat huomauttivatkin, että yhteentoimivuus on myös prosesseja ja ihmisiä ja näiden kyvykkyyksiä, eikä pitäisi rajautua vain yksittäisiin ominaisuuksiin. Rajaus pelkkiin alustan ominaisuuksiin oli kuitenkin tarkoituksellista – halusimme tällä kertaa keskittyä konkreettisiin muutostoiveisiin, jotka voidaan sanoittaa niin, että vaihtoehtoihin on helppoa ottaa kantaa ruksaamalla haluttu vaihtoehto.

Täysin uusien kehitysideoiden tai syväluotaavien toimintamalli- ja prosessikysymyksien esittäminen ja työstäminen Kano-mallilla ei välttämättä ole paras ratkaisu, vaan siihen tarkoitukseen esimerkiksi työpajakeskustelu toimii paremmin. Valikoimme kyselyn vaihtoehdot myös siitä näkökulmasta, että saamme kokemusta myös itse Kano-mallista ja sen käyttökelpoisuudesta. Marraskuun kyselyssä esitettiin kysymyksiä kaikista työkaluista, mutta tulevaisuudessa lienee järkevämpää tehdä kullekin työkalulle omia Kano-kyselyitä.

Kyselyssämme oli mahdollisuus antaa myös avointa palautetta. Yli puolet vastaajista hyödynsikin tätä mahdollisuutta, ja saimme arvokasta palautetta niin kysymyksistämme kuin muistakin teemoista.

Kano-kyselyn toteutustapa

Vuosien aikana Yhteentoimivuusalustan kehittäjille on esitetty kymmeniä, ellei satoja toiveita, jotka on kirjattu Jira-projektinhallintatyökaluumme kehitysideoiksi. Osa toiveista on selkeitä, teknisiä ja suoraviivaisia toteuttaa – on selvää, että Sanastot-työkalussa pitäisi olla valittavissa latinan kieli yhdeksi termien kielivalinnaksi, joten turha kysellä muidenkin mielipidettä, jos tästä puutteesta meille huomautetaan. (Asia on tätä nykyä korjattu.)

Monet esitetyistä toiveista kuitenkin vaikuttavat sisällöntuottajien tai tietoa hyödyntävien toimintatapoihin: jos esimerkiksi lisäämme uuden tilakoodin, niin sen lisääminen alasvetovalikkoon on teknisesti suoraviivaista, mutta mitä muutoksesta seuraa käyttäjille: ovatko tilatietojen erot riittävän selkeitä sisällöntuottajalle, tai pystyykö tietojen käyttäjä kohdistamaan haun aiempaa tarkemmin? Vai tuleeko tilakoodeja jo niin paljon, että niiden välillä on vaikea valita ja siten käytettävyys huononee?

Valitsimme siis kyselyyn nyt ensisijaisesti ehdotuksia, joiden toteuttaminen (ainakin ehdotuksen esittäjän mielestä) olisi tarpeen, mutta jotka eivät itsestäänselvästi hyödytä kaikkia käyttäjiä, vaan jonkin toisen käyttäjäryhmän näkökulmasta saattavat lisätä työmäärää tai huonontaa käytettävyyttä. Onko esimerkiksi tarpeen näyttää myös korvatut koodistot aina kaikille, vai näytetäänkö aluksi vain voimassa olevat koodistot, ja lisäksi annetaan mahdollisuus hakea listaukseen mukaan myös korvatut koodistot. Kumpi vaihtoehto palvelee enemmistöä paremmin?

Yksinkertaisin tapa kysyä asiaa on listata halutut toiminnot ja pyytää käyttäjiä äänestämään niistä. Kano-mallissa tähän on kuitenkin lisätty kierrettä: vastaajia pyydetään ottamaan kantaa kahdella tavalla:

• Miten suhtautuisit, jos kuvattu ratkaisu toteutetaan?
• Miten suhtautuisit, jos kuvattua ratkaisua ei toteuteta?

Kumpaankin kysymykseen on tarjolla seuraava vastausasteikko:

• Pidän siitä
• Odotan asian olevan niin
• Suhtaudun neutraalisti
• En pidä siitä, mutta voin hyväksyä sen
• En pidä sitä

Vastaaja ei siis voi vain tykätä kaikesta mukavasta ja kivasta, vaan voi antaa myös vastaääniä, jos siltä tuntuu. Ja vaikka vastaaja samaan aikaan voisikin ilmoittaa ristiriitaisesti sekä pitävänsä ratkaisun toteuttamisesta että siitä, että sitä ei toteuteta, Kano-malli kyseenalaistaa tällaisen tuloksen.

Kano-mallissa kullekin ominaisuudelle muodostetaan näiden kahden eri vastauksen yhteispisteytys seuraavanlaisen luokittelun avulla:

• Odottamattomat: Luo tyytyväisyyttä, mutta ei aiheuta negatiivisia reaktioita, mikäli ominaisuutta ei toteuteta – asiakas ei suoranaisesti odota näitä ominaisuuksia. Jos tällaisia ominaisuuksia tuodaan sovellukseen, asiakastyytyväisyys kasvaa.
• Vaaditut: Asiakas ei välttämättä erikseen kuvaile näitä tarpeiksi, sillä niiden pakollisuutta pidetään usein niin ilmeisenä. Niiden puuttuminen tuottaa tyytymättömyyttä.
• Neutraalit: Nimensä mukaisesti ovat ominaisuuksina yhdentekeviä, näiden toteutuminen tai toteutumatta jääminen ei tuota sen enempää tyytyväisyyttä kuin tyytymättömyyttäkään.
• Odotetut: Odotetut ominaisuudet ovat ideologialtaan selkeästi ”mitä enemmän, sitä parempi” -tyyppisiä ominaisuuksia. Asiakas osaa odottaa näitä ominaisuuksia.
• Käänteiset: Ominaisuus, jonka olemassaolo laskee asiakastyytyväisyyttä. Ovat harvinaisia, mutta niitäkin saattaa löytyä palvelusta.
• Kyseenalaiset: Vastausvirheistä johtuvat tulokset, esim. asiakas pitää siitä, että ominaisuus on olemassa ja samalla myös siitä, ettei ominaisuutta sovelluksesta löydy.

Mitä kysyimme ja mitä vastattiin

Kymmenistä mahdollisista kehitysideoista valittiin kyselyyn seuraavat kymmenen:

• Käyttöoikeudet annetaan kohdennetusti sisältöön, ei koko organisaation tasolla
• Kommentointipyyntöjen otsikoiden ja tietojen näkyminen kaikille
• Kommentit-työkalun kommenttien näkyminen ja niihin annettujen vastausten näkyminen muillekin kuin kommentoijille
• Avataan kommentointikierrokset avoimiksi kaikille
• Suositellut tietosisällöt listauksiin ylimmäksi ja kuvauksiin jokin merkki siitä, että kyseessä on "suositus"
• Suosituimmat tietosisällöt nostetaan listauksissa ylimmäksi
• Lisätään Tietomallit-työkaluun YAML-tuki
• Tilatietoihin (status-tieto) lisää vaihtoehtoja
• Piilotetaan korvatut ja käytöstä poistetut koodistot listausnäkymästä
• Rajapinnan muutostietopalvelu

Linkki kyselyyn lähetettiin 88 Yhteentoimivuusalustan pääkäyttäjälle tai muuten alustan kanssa tekemisissä olevalle henkilölle. Lisäksi kyselyä mainostettiin LinkedInissä ja Slackissä. Vastauksia saatiin yhteensä 40 kappaletta ja vastauksien jakautuminen näkyy kuvassa 1. Kolmisenkymmentä vastausta riittää antamaan Kano-kyselyssä tilastollisesti merkitsevän tuloksen, joten saimme vastauksia siis riittävästi.

Kaikki vastaajat eivät vastanneet kaikkiin kysymyksiin, minkä vuoksi niiden palkit ovat kuvaajassa eri pituisia. Kyseenalaisia (eli virheellisiä) vastauksia ei tullut lainkaan, joten se vaihtoehto jätettiin kuvaajasta pois.

Kuva 1. Kano-kyselyn vastausten jakautuminen eri luokkiin.

Kysymykset olivat laajuudeltaan erilaisia: esimerkiksi ensimmäinen kysymys oli yksittäinen muokkausoikeuksia koskeva kysymys, jolle ei esitetty muita vaihtoehtoja. Sen sijaan kysymyksissä 2 - 4 oli kyse samasta työkalusta ja samasta asiasta: kuinka laajasti Kommentit-työkalun tietoja voidaan avata myös ulkopuolisten tahojen nähtäville?

Kuvasta 1 näkyy, että useimmille käyttäjille ehdotetut ominaisuudet tai toiminnot olivat enimmäkseen neutraaleja. Kymmenestä kysymyksestä Kano-malli nosti esiin neljä, jotka luokiteltiin odottamattomiksi eli joissa toiminnallisuus eniten nostaisi asiakkaiden tyytyväisyyttä:

• (2) Kommentointipyyntöjen otsikoiden ja tietojen näkyminen kaikille
• (3) Kommentit-työkalun kommenttien näkyminen ja niihin annettujen vastausten näkyminen muillekin kuin kommentoijille.
• (9) Piilotetaan korvatut ja käytöstä poistetut koodistot listausnäkymästä
• (10) Rajapinnan muutostietopalvelu

Loput vaihtoehdoista olivat neutraaleja, eli kaiken kaikkiaan neutraaleja ominaisuuksia oli kuusi kappaletta.

Esimerkiksi kysymys 7, Tietomallit-työkaluun YAML-tuki, oli useimpien kannalta neutraali – ei herätä intohimoja sen enempää puolesta kuin vastaan, jos se toteutetaan tai jätetään toteuttamatta. Vain yksi käyttäjä piti sen toteuttamista välttämättömänä. Eikä ketään sinänsä toki harmita, jos tämä ominaisuus toteutetaan. Kyseessä on siis ominaisuus, joka sinänsä on hyödyllinen, mutta jolle ei vielä näytä olevan laajaa tarvetta. Koska työkalu jo tukee OpenAPI-formaattia, josta käyttäjä voi konvertoida YAML-muodon, YAML-tuen toteutus saa työlistalla alhaisen prioriteetin.

Myös kysymyksessä 1, Käyttöoikeudet annetaan kohdennetusti sisältöön, ei koko organisaation tasolla ja kysymyksessä 8, Tilatietoihin (status-tieto) lisää vaihtoehtoja, suurin osa vastaajista suhtautui vaihtoehtoihin neutraalisti. Näissä kuitenkin löytyi myös useita käyttäjiä, joiden mielestä ehdotetun ominaisuuden toteuttaminen olisi huono asia.

Vaikka lisääntynyt työmäärä voi pienillä tietomäärillä olla kohtuullinen, on myös otettava huomioon, mitä muutos vaikuttaa, kun hallinnoitavia sisältöjä olisi paljon. Käytännössä siis tällaisen toiminnallisuuden kanssa pitää palata suunnittelupöydälle ja miettiä tarkemmin, millaisella ratkaisulla eri käyttäjäryhmien ristiriitaiset tarpeet voidaan parhaiten ratkaista. Toiminnallisuuden muutos vaikuttaisi monien käyttäjien prosesseihin.

Kommentointi-toimintojen kehittäminen (kysymykset 2 - 4) sai siis suosiota ja siten nousee näistä teemoista toteutuslistan kärkeen. Kaikkien toivottujen ominaisuuksien muuttamista valinnaisiksi ja kommentointikierroksen tekijän päätettäväksi ei kuitenkaan pysty tekemään yhdellä kertaa, joten tässäkin pitää suunnitella käyttäjien kanssa heitä parhaiten palveleva vaiheistus.

Suositeltujen (kysymys 5) ja suosittujen eli eniten viitattujen (kysymys 6) tietosisältöjen korostamisesta on ollut paljon keskustelua aiempina vuosina, mutta tällä vastaajajoukolla suurin osa suhtautui näihin ominaisuuksiin neutraalisti. Tulosten perusteella ihmisten tekemää suosittelua arvostetaan enemmän kuin sovelluksen tekemiä automaattisia nostoja.

Tosin hyvin moni vastaaja kysyi avoimessa palautteessaan, mikä tällainen asiantuntijaraati sitten olisi ja kuka sen valitsee. Tässä tapauksessa siis pitää ensin hahmotella hallintamalli ja asiantuntijaraadin rooli ja vaatimukset. Vasta kun näistä on yhteinen näkemys, voidaan rakentaa toiminnallisuus, joka tukee hallintamallia.

Korvattujen ja käytöstä poistettujen koodistojen piilottaminen listausnäkymästä (kysymys 9) sai paljon kannatusta. Koska vanhojakin koodistoja tarvitaan, niitä ei ole tarkoitus kokonaan poistaa, vaan ajatuksena on, että listaussivu jatkossa oletusarvoisesti näyttää vain aktiivisessa käytössä olevat koodistot. Ja jos käyttäjä haluaa nähdä kaikki koodistot, ne voi saada näkyvilleen muuttamalla listauksen asetuksia (esimerkiksi: aktiiviset -> kaikki). Tällä hetkellä käytöstä poistuneita koodistoja ei vielä ole kovin paljon, mutta ajan myötä niiden määrä kasvaa. Oletettavasti käyttäjiä turhauttaa pyöritellä pitkiä koodistolistauksia, jos suuri osa niistä on jo korvattu uudemmilla. Jos tämä suodatus pystytään toteuttamaan kohtuullisen pienellä vaivalla, se kannattaa tehdä.

Toteutuksessa on otettava huomioon, että vastaava suodatustoiminnallisuus on käytössä kaikissa työkaluissa, joten alasvetovalikon tekstien pitää olla sellaisia, että ne soveltuvat koodistojen lisäksi myös sanastoille, tietomalleille ja kommentointikierroksille. Ja käyttäjillä pitää olla helppo tapa vaihtaa suodatusta haluamakseen.

Rajapinnan muutostietopalvelu (kysymys 10) sai suurta suosiota, mutta vapaassa palautteessa todettiin, että jos tiedon tietosisällön muutoksesta saa vasta rajapinnassa, se tulee liian myöhään. Olennaisempaa olisi saada viesti muutoksista ennakkoon niin, että rajapinnan käyttäjä voi omalta osaltaan jo aiemmin varautua muutoksiin. Koska käyttäjät voivat jo nyt tilata sähköpostiinsa ilmoituksen, kun jokin alustalla jo oleva tietosisältö on muuttunut (katso ilmoituspalvelu), pitää teknisen rajapinnan tarpeet miettiä toisesta näkökulmasta: Kun sisällöntuottaja aikoo muuttaa tietosisältöjä, niin miten hän saa tiedon tietosisältönsä käyttäjistä, jotta voi ottaa näihin yhteyttä? Miten rajapinnassa kerrotaan sisällön päivitykset (esimerkiksi tietomallin version muutokset)? Miten ilmaistaan tekniset muutokset (esimerkiksi rajapinnan versiot)? Tässäkin tarvitaan lisäkeskusteluja käyttäjien kanssa.

Tehty kysely ei tietenkään ole niin sanotusti lopullinen totuus, koska se kertoo vain niistä toiminnallisuuksista, joista kysyimme. Aiemmin esitettyjä toivomuksia on paljon enemmän kuin tähän kyselyyn otettiin, ja kyselymme vapaassa palautteessa saimme vielä tukun uusia. Kano-malli sopiikin ehkä parhaiten siihen, että sen avulla haarukoidaan monien vaihtoehtojen joukosta tärkeimmiksi katsotut kehitysideat. Näin käyttäjien kanssa pidettävissä työpajoissa voidaan keskittyä näihin helmiin, jotta kehitystyöstä saadaan suurin hyöty.

Avoimet palautteet

Avointen vastausten osuudessa saimme palautetta niin alustan teknisistä ominaisuuksista kuin yleisemmistä teemoista, kuten harmonisoinnista ja toimintamallin periaatteista. Palautteen kooste on tämän kirjoituksen liitteenä.

Avoimissa vastauksissa oli esimerkiksi viety Kommentit-työkalun toiminnallisuuksiin liittyviä kysymyksiä eteenpäin mm. ehdottamalla, että kommentointipyynnön lähettäjällä pitäisi olla mahdollisuus määritellä kommentointipyyntöjen julkisuus vaihtoehdoilla: täysin julkinen, osittain julkinen tai täysin rajattu. Samaten kommenttien ja kommentoijien tietojen näkymisen pitäisi olla valittavissa oleva tieto. Tai asian voisi ratkaista niin, että kirjautuneille käyttäjille näkyy kommentoijan identiteetti, mutta anonyymeille käyttäjille ei. Myös kommentointikierroksen avaaminen ”kaikelle kansalle” voisi olla valinnainen ominaisuus. 

Entä jatko?

Käymme läpi saadut kommentit ja kehitysehdotukset työkaluittain ja lisäämme ne soveltuvin osin kunkin työkalun kehitysjonoon. Melkein kaikki kehitysehdotukset vaativat jatkotyöstöä sekä sidosryhmien että kehittäjien kanssa. Todennäköisesti jatkotyöstö tehdään enimmäkseen työkalu kerrallaan eikä tällaisena yhteiskyselynä kuin marraskuussa.

Koska tietoalueita ei vielä ole perustettu muita kuin Ympäristöministeriön luotsaama rakennettu ympäristö, täytyy yhteistyö tässä vaiheessa rakentaa muulla tavalla kuin tietoalueiden varaan. Yksi vaihtoehto on perustaa kullekin työkalulle oma asiakasraatinsa, mutta silloinkin tarvitaan jokin tapa koordinoida kokonaisuutta. Toinen vaihtoehto on rakentaa esimerkiksi pääkäyttäjäfoorumi, jossa pääkäyttäjät olisivat yhteyslinkkinä Yhteentoimivuusalustan ylläpitäjien ja oman organisaationsa välillä. 

Tältä pohjalta jatkamme kehitysehdotusten työstämistä ja toimintamallin suunnittelua vuoden 2021 alussa. Julkaisemme lisätietoja Slackissä ja muilla kanavillamme, kun olemme ehtineet asiassa pidemmälle.