Käyttäjätarpeet, -toiveet ja -vaatimukset. Mikä ero?

Eräässä keskusteluryhmässä esitettiin käyttäjälähtöisyyteen kysymyksiä: "Mikäs on hyvä tapa löytää käyttäjävaatimuksia?" Ja "Mikä on paras tapa tietää millaista palvelua/laitetta/työkalua käyttäjät kaipaavat?"

On tärkeää, että termit määritellään niin, että ne ymmärretään ainakin kutakuinkin samalla tavalla. Ja mielellään niin, että ne ovat sisällöllisesti kuvaavia.

Yllä on kaksi käyttäjälähtöisyyteen liittyvää termiä: käyttäjävaatimukset ja mitä käyttäjät kaipaavat. Muita näitä lähellä olevia termejä ovat esimerkiksi käyttäjätarpeet ja käytettävyysvaatimukset.

Itse tulkitsen termit seuraavasti:
- Käyttäjävaatimukset: ovat käyttäjän esittämiä (sanomia tai kirjoittamia) vaatimuksia järjestelmälle. Käyttäjä voi esittää näitä esimerkiksi silloin, kun häntä haastatellaan.
- Käyttäjätoiveet, tai "mitä käyttäjät kaipaavat" ovat samantyyppisiä kuin vaatimukset, mutta termit tietenkin viittaavat siihen, että ovat "pehmeämpiä" kuin vaatimukset. Lisäksi tulkitsen, että näihin termeihin voi liittyä se, että käyttäjät eivät välttämättä ole ilmaisseet näitä toiveitaan
- Käyttäjätarpeet: ovat niitä "perimmäisiä" asioita, joiden perusteella järjestelmä olisi suunniteltava. Eli ne antavat perustan sille, mitä järjestelmän viime kädessä tulisi tehdä.

Näissä on se oleellinen ero, että

   * Käyttäjävaatimukset ja käyttäjätoiveet /-kaipaukset ovat käyttäjien itsensä jäsentämiä asioita
   * Käyttäjätarpeet ovat suunnittelutiimin jäsentämiä johtopäätöksiä käyttäjien ilmaisemista vaatimuksista, toiveista ja  muista käyttäjälähtöisistä tietolähteistä (esimerkiksi havainnointi).

Eron tekee oleelliseksi se, että käyttäjien itsensä ilmaisemien asioiden laatu riippuu siitä, kuinka hyvin juuri kyseiset käyttäjät sattuvat jäsentämään tarpeitaan tai toiveitaan. Ja oma kokemukseni on se, että asioiden jäsentäminen on varsin haastavaa monelle käyttäjälle. Eli käyttäjä voi pukea sanoiksi jotakin ja tarkoittaa jotakin ihan muuta. Tai jättää pois jotakin oleellista tai korostaa jotakin turhaa.  Ja jos suunnittelutiimi luottaa suoraan käyttäjien lausumiin, niin on suuri riski, että pieleen mennään. (Itse asiassa muistaakseni jo 80-luvulla tiedettiin, että jos suunnittelee ohjelmiston asiakkaan vaatimusten mukaan, niin asiakas ei tule olemaan siihen tyytyväinen).

Käyttäjätarpeiden määrittäminen taas riippuu suunnittelutiimin jäsentämiskyvystä. Siihen sitten liittyy se vastuu ja riskiotto, että ei tehdäkään oikeita tulkintoja ja jäsennyksiä. Mutta minun mielestäni tämä on kuitenkin se tie, joka suunnittelutiimin - tai vaikka käytettävyysasiantuntijan - olisi valittava. Olen nähnyt sellaisia käyttäjätutkimusraportteja, jossa tätä askelta ei ole otettu. Mielestäni tällainen ei edusta ammattimaisuutta vaan on vastuun pakoilua.

 (Käytettävyysvaatimuksia ei käsitellä tarkemmin tässä kirjoituksesssa)

En ollutkaan poliisi

Käytettävyysarvioinnin ei välttämättä tarvitse olla negatiiviseksi koettua "arvostelua". Ison organisaation verkkosivuista vastaavat henkilöt pitivät ulkopuolisen arviojan kanssa käymiään keskusteluja pelkästään positiivisina ja tarpeellisina. 

Sanotaan, että suunnittelijat kokevat käytettävyysarvioinnit usein "poliisityönä". Eli arvioija tulee ja arvioi toisen suunnitteluratkaisuja, ja etsii niistä ongelmia (tosin arvioijan kuuluisi toki myös kertoa vahvuuksista). 

Mutta eihän näin tietenkään tarvitse olla. Seuraava tapaus edustaa täysin päinvastaista kokemusta - oletan, että vastaavia kokemuksia on muillakin?

Arvioin ison julkisen organisaation kehitteillä olevat laajat verkkosivut. Kyseisten verkkosivujen eri alasivustojen suunnittelusta ja sisällöstä vastaavat kyseisen organisaation eri osastot. Kukin osasto oli siis tehnyt omalta osaltaan suunnitelmat alasivujen rakenteesta ja sisällöstä. 

Kävin siis sivujen suunnitteluratkaisut läpi käytettävyysnäkökulmasta. Kommunikoin näkemykseni keskustelemalla puhelimitse kunkin alasivuston vastaavan kanssa. Ja tulos oli se, että jos etukäteen pelkäsin, että minut koettaisiin poliisina, niin tuo pelko oli täysin turha. Päinvastoin, poikkeuksetta kaikki keskustelut olivat erittäin rakentavia; verkkovastaavat olivat aidosti kiinnostuneita keskustelemaan sivuista, saamaan palautetta ja ottamaan vastaan kehitysehdotuksia. Näin koin itse, ja samaa raportoivat keskustelukumppanini työni tilaajalle (verkkosivujen kokonaisvastaava). 

Eli oli erittäin mukava kokemus. Ja itse asiassa asiakkaan mielestä työni tärkein tuotos olikin nuo keskustelut (toki myös raportoin tulokset). 

Sitten se mielenkiintoinen kysymys: mistä tämä positiivinen kokemus johtui? Itse tietenkin rohkenen ajatella, että pystyin antamaan ammattimaista palautetta sekä konkreettisia ja uskottavia kehitysehdotuksia. Mutta toisaalta tulkitsen, että nuo verkkovastaavat olivat olleet varsin yksinäisiä sivujen suunnittelussa. Vähän vaikutti, että muut organisaation ihmiset ovat niin kiireisiä muissa tehtävissään, että eivät kunnolla ehtineet perehtyä sivuihin ja antaa niihin palautetta. Ja kun minä sitten analysoin sivut syvällisemmin, niin tämä perehtyminen ja palaute koettiin positiivisena. 

Jos en ollut poliisi, niin mikä sitten olin? Analogiana tulee mieleen urheiluvalmentaja, joka ulkopuolisin (ja ammattimaisin) silmin analysoi suoritusta ja neuvoo menemään eteenpäin. Ehkä jotain tällaista?

Käytettävyysjuttuja muissa blogeissa

Tämän blogin päivittämisessä on ollut jonkin verran taukoa. Sen sijaan olen kirjoitellut yleisen tason käytettävyysasioista Käytettävyysnavigoija-blogiin:

nimikkeiden pituuksista:
http://kaytettavyysnavigoija.blogspot.com/2011/05/suosi-pitkia-nimikkeita.html

käyttäjälähtöisestä tietorakennesuunnittusta
http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html

Nokian käyttöliittymäkohtalon taustoista
http://kaytettavyysnavigoija.blogspot.com/2011/06/nokian-kayttoliittymakohtalon-taustat.html

mitä on käytettävyysvaikuttavuus
http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

mitä ovat käytettävyysvaatimukset
http://kaytettavyysnavigoija.blogspot.com/2011/06/mita-ovat-kaytettavyysvaatimukset.html

Mitä ovat käytettävyysvaatimukset?

Käytettävyysvaatimusten tulisi olla todennettavia, valideja ja kattavia. Tällaiset vaatimusten määrittäminen käytännössä tarkoittaa käyttäjän suoriutumiseen perustuvia vaatimuksia: tulee määritää riittävän kattavasti käyttäjätehtävät ja -tavoitteet, sekä käyttäjän suoriutumista kuvaavat mittarit, mittausinstrumentit ja tavoitetasot.  

Käytettävyysvaatimuksista on vastikään keskusteltu eri käytettävyysfoorumeissa. Muunmuassa CreaBasen seminaarissa Kajaanissa toukokuussa ja nyt KäytettävyysOSY:n LinkedInin keskusteluryhmässä.

Käytettävyysvaatimusten määritys tulisi olla käytettävyysohjatun vuorovaikutussuunnittelun keskeinen aktiviteetti. Aktiviteetissa asetetaan tavoitteet kehitettävän sovelluksen käytettävyydelle: kuinka hyvää käytettävyyttä tavoitellaan.

Käytettävyysvaatimusten määrityksellä on periaatteessa kaksi tarkoitusta:

• vaatimukset toimivat käyttöliittymän suunnittelua ohjaavina suunnitteluajureina (”drivereina”): kun suunnittelijat tietävät tavoitteet, joiden perusteella suunnitteluratkaisujen laatua arvioidaan, ne ohjaavat suunnitteluratkaisuja oikeaan suuntaan
• vaatimukset muodostavat kriteerit käytettävyyden todentamiselle: todentamisessa saatuja tuloksia verrataan määriteltyihin käytettävyystavoitteisiin

Kun keskustellaan jostakin asiasta niin on tärkeää, että on yhteinen ymmärrys siitä, mitä käytetyillä termeillä tarkoitetaan. Ja kun puhutaan käytettävyysvaatimuksista, keskeinen termi on tietenkin "käytettävyysvaatimus".

Lehtonen & al (2010) tutkimuksessa löydettiin kolmen eri tyyppisiä käytettävyyteen liittyviä vaatimuksia. Vaatimukset liittyvät

  1. suunnitteluohjeistojen noudattamiseen
  2. suunnittelukäytäntöihin ja -resursseihin
  3. käyttäjän suoriutumiseen

Mutta ovatko nämä kaikki aidosti käytettävyysvaatimuksia? Vai vain osa niistä? Mitä itse asiassa on käytettävyysvaatimus?

Tässä kirjoituksessa jäsennetään sitä, mikä on käytettävyysvaatimus - ja mikä ei. Joka ei jakas lukea loppuun asti, niin yhteenvetona on se, että lähinnä käyttäjän suoriutumiseen perustuvat vaatimukset ovat "aitoja" käytettävyysvaatimuksia.

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

Mitä on käytettävyysvaatimus? Periaatteessahan asia on yksinkertainen: käytettävyysvaatimukset ovat sellaisia, että kun ne täyttyvät,  niin tuote (järjestelmä, palvelu) on käytettävyydeltään "hyvä" (= halutun tasoinen). Mutta kun käytettävyysvaatimuksia lähtee tarkemmin jäsentämään, niin kyseessä ei olekaan ihan yksinkertainen juttu.

Vaatimuksia vaatimuksille

Kirjallisuudesta löytyy paljonkin vaatimuksia vaatimuksille - siis mikä tekee vaatimuksesta "hyvän". Keskeisiä kriteereitä ovat:

  1. Vaatimuksen on oltava todennettava: vaatimuksen saavuttaminen voidaan objektiivisesti testata.
  2. Vaatimus on oltava validi: vaatimus on sisällöltään oikea
  3. Vaatimukset on oltava kattavat: ne kattavat koko tuotteen (järjestelmän, palvelun) riittävän laajalti

Nämä "vaatimukset vaatimuksille" ovat aika kinkkisiä, kun puhutaan käytettävyydestä.

1. Todennettavuus

Todennettavuus liittyy vaatimuksen yksikäsitteisyyteen. Todennettavuus siis tarkoittaa sitä, että vaatimus on määritelty siten, että sen saavuttaminen - tai että sitä ei saavuteta - voidaan todentaa objektiivisesti. Tämä on oikeastaan "vaatimuksen perusvaatimus": jos vaatimus ei ole todennettava, se ei ole vaatimus.

Todennettavuus käytännössä sulkee pois laadulliset vaatimukset (vaatimukset tyyliin, että pitää olla "helposti opittava"; "nykyaikainen käyttöliittymä"; "suunniteltu käyttäjäkeskeisesti"...). Sen vuoksi yllä luetelluista vaatimustyypeistä suunnitteluohjeiden noudattaminen ei tyypillisesti ole todennettava vaatimus, koska useimmat suunnitteluohjeet ovat laadullisia.

Käytännössä todennettavan vaatimuksen saavuttaminen on objektiivisesti mitattavissa jollakin skaalalla. Yksinkertaisimmillaan skaala on kaksiarvoinen (kyllä/ei). Joka tapauksessa, todennettavaa vaatimusta varten on määritettävä mittarit, mittausinstrumentit ja tavoitetasot.

2. Validiteetti

Validiteetti ottaa kantaa vaatimusten sisältöön. Validit vaatimukset tarkoittavat sitä, että ne ovat sisällöllisesti oikeat. Validi käytettävyysvaatimus on sellainen, että kun se täyttyy, niin lopputuloksena on tuote (järjestelmä, palvelu), joka  aidosti on käytettävyydeltään "hyvä". Epävalidi vaatimus on taas sellainen, että vaatimus voi täyttyä, mutta silti käytettävyys voi olla "huono".

Validit vaatimukset tulisi määrittää sellaisiksi, jotka kuvaavat juuri kyseisen järjestelmän haluttua ja järkevää käytettävyyttä. Jos esimerkiksi sovelluksen käyttö perustuu vapaaehtoisuuteen, niin käyttäjätyytyväisyys on kriittistä (muutenhan järjestelmää ei käytetä); toisissa tapauksissa käytettävyysongelmat on ehkä mahdollista ratkaista vaikka koulutuksella. Joissakin tapauksissa kriittisiä käyttäjätehtäviä on muutama, toisissa kymmeniä. Joissakin tapauksissa virheiden seuraukset ovat pahemmat kuin toisissa. Joissakin tapauksissa päähyöty tulee tehostuneina työprosesseina, toisissa käyttäjätuen tarpeen vähenemisenä, kolmansissa ehkä koulutussäästöinä. Jne.

Alussa mainituista kategorioista:

• suunnitteluohjeistovaatimukset ovat periaatteessa valideja (mutta eivät yleensä todennettavia)
• suunnittelukäytäntö- tai resurssivaatimukset eivät ole valideja (= ne voivat täyttyä, mutta silti lopputulos voi olla käytettävyydeltään ongelmallinen)
• käyttäjän suoriutumiseen perustuvat vaatimukset ovat valideja (oikein määritettyinä)

 3. Kattavuus

Kun käytettävyysvaatimukset ovat kattavat, ei jää "käytettävyysaukkoja". Kattavuus on tietenkin haastava asia, ja täydelliseen kattavuuteen tuskin yleensä päästään. Joka tapauksessa, tulisi pyrkiä määrittämään kattavasti käyttäjätehtävät ja -tavoitteet

Käytettävyyden vaikuttavuustavoitteiden määrittäminen: perusta käytettävyyden suunnittelulle

Käytettävyysohjatun vuorovaikutussuunnittelun prosessia kuvaavan JFunnel-mallin (Jokela 2010) ensimmäinen aktiviteetti on "strategisten käytettävyystavoitteiden määritys". Sen tarkoitus kuvataan: "Strategisten käytettävyystavoitteiden tarkoituksena on määrittää, miten sovelluksen käytettävyyden halutaan tukevan liiketoimintaa (tai organisaation toimintaa). Strategiset käytettävyystavoitteet määrittävät ”liiketoiminnan kielellä”, mitä hyvä käytettävyys tarkoittaa".

Olen tullut siihen tulokseen, että "strateginen käytettävyystavoite" ei ehkä ole paras mahdollinen termi: se ei semanttisesti kerro kovin selvästi, millaisesta aktiviteetista on sisällöllisesti kyse. Kuvaavampi termi tälle asialle on "käytettävyysvaikuttavuus". Ehkä tämäkään termi ei kuullosta kovin elegantilta, mutta asiallisesti tästä on kyse: aktivitetissa kun nimenomaisesti tulisi määrittää, mitä liiketoiminnallista vaikuttavuutta käytettävyydeltä halutaan. (Englanniksi termi on elegantimpi: "usability impact".)

Käytettävyyden vaikuttavuus on valintakysymys. Se, millaista vaikuttavuutta halutaan, riippuu sovelluksesta mutta on myös business-valinta. Vaikuttavuus voi olla erilaista niin laadultaan kuin tasoltaan, riippuen casesta. Esimerkiksi yhdessä julkisen hallinnon sovelluksessa määritettiin erääksi keskeiseksi käytettävyysvaikuttavuudeksi se, että "turhat" puhelut asiakkailta vähenevät merkittävästi (koska niihin menee paljon virkailijoiden aikaa). Vaikuttavuuden taso määritettiin myös numeerisesti.

Käytettävyystoimenpiteiden määrä ja laatu sitten riippuu tästä halutun vaikuttavuuden laadusta ja tasosta. Jos sovellus ja businessvalinta ovat sellaisia, että potentilaalisesti saavutettavat vaikuttavuudet eivät ole merkittäviä, niin vaikeapa silloin voi olla perustella käytettävyystoimenpiteitä. Esim. julkisissa kilpailutuksissa on usein niin, että asiakas ei tarjouspyynnöissä aidosti edellytetä käytettävyyttä. Eipä silloin ole paljon perusteita softantekijöille otta käytettävyttä huomioon (itse asiassa tarkoittaisi vain tarjouksen kilpailukyvyn heikkenemistä).

Eli korjattu versio kirjan tekstiin:

"Aktiviteetin otsikko: 0. Käytettävyyden vaikuttavuustavoitteiden määrittäminen

Halutun käytettävyysvaikuttavuuden (desired usability impact) määritys on aktiviteetti, jota ei yleensä käytettävyyssuunnittelun lähteissä tuoda esiin. Toki on kirjallisuutta liittyen käytettävyydellä saavutettaviin etuihin (Bias and Mayhew 1994), mutta vähemmän siitä, miten määrittää etuja tavoitteellisesti. Käytettävyyden vaikuttavuus on tietoinen valinta - sen vuoksi puhutaan halututusta vaikuttavuudesta - eikä laskennallisesta "mitä kaikkia etuja käytettävyydellä voi saavuttaa".
Taustana tämän aktiviteetin sisällyttämiseen on se tosiasia, että käytettävyys on jatkuva, ei ”on/off” –suure. Sen vuoksi käytettävyydelle tulisi määrittää tavoitetaso: kuinka hyvää käytettävyyttä halutaan. Ja tällainen tason määritys periaatteessa ei voi perustua muuhun kuin niihin strategisiin valintoihin, joita liiketoiminta tai organisaatio tekee.

Tarkoitus

Haluttu käytettävyysvaikuttavuus määrittää, miten ja missä määrin sovelluksen käytettävyyden halutaan tukevan liiketoimintaa tai organisaation toimintaa. Haluttu vaikuttavuus määrittää ”liiketoiminnan kielellä”, miten käytettävyyden tulisi konkreettisesti tukea liiketoimintaa tai organisaation toimintaa.


Luonnehdinta

Tavoitteen määrittämiseksi tarvitaan tietoa sovelluksen liiketoimintakontekstista. Näitä ovat esimerkiksi:

   * mikä tuote ja sen päätoiminnallisuus (mitkä ovat sen tarjoamat palvelut asiakkaalle)
   * mille markkinoille
   * ketkä ovat asiakkaat
   * miten sen halutaan erottuvan markkinoilla
   * mitkä ovat kilpailutekijät
   * mitkä ovat liiketoiminnalliset tavoitteet

”Liiketoiminnan” tilalla voi olla – kontekstista riippuen – organisaation, esimerkiksi sairaalaympäristön toimivuus.

Tavoitteita määrittäessä tulee ymmärtää, että käytettävyys ei välttämättä ole kaikki kaikessa vaan sen merkitys ja vaadittu taso riippuu liiketoimintakontekstista. Käytettävyyden suunnitteluun voidaan helposti laittaa paljonkin resursseja, enemmän kuin on järkevää. Haluttu käytettävyysvaikuttavuus on organisaation strateginen valinta, joiden tulisi toisaalta tuottaa järkeviä liiketoiminnallisia etuja, ja toisaalta olla kehitysresursseihin nähden järkevästi saavutettavissa.

Strategisena tavoitteena ei siis välttämättä tulisi olla, että saavutetaan ”paras mahdollinen käytettävyys”. Tavoitetason asettaminen riippuu esimerkiksi siitä, haluaako yritys haluaa olla ”johtotähti” käytettävyydessä vai pyrkiikö olemaan kilpailijoiden tasolla. Tuote voi olla liiketoimintamenestys huolimatta käytettävyysongelmista. Esimerkiksi Nokian 90-luvun peruspuhelinmallin (kuva 6, kuva 9) kaupallinen menestyminen lienee ollut erinomainen, selkeistä käytettävyysongelmista huolimatta.

Aktiviteetti on liiketoimintajohdon, yrityksen ja kehitysprojektin eri osapuolten sekä käytettävyysammattilaisten vuoropuhelua. Tavoitteiden määrittämistä varten tulee valita attribuutit, jotka sopivat sovelluksen liiketoimintakontekstiin. Käytettävyysvaikuttavuuden tyypilliset attribuutit perustuvat ns. käytettävyyden liiketoimintaetuihin, esimerkiksi:

   * järjestelmän hyväksyttävyys
   * koulutuksen helppous
   * käyttäjät eivät tee virheitä
   * käyttäjätuen tarpeen minimointi
   * käytön nopeus, vaivattomuus
   * käyttäjien työn tehostuminen
   * käyttäjä- ja työtyytyväisyys

Haluttu käytettävyysvaikuttavuus on aina väistämättä sovelluskohtaista. Vaikuttavuus  asettamisessa voidaan esimerkiksi ottaa kantaa käyttöohjeeseen tai käyttökoulutukseen: onko tavoitteena, että tuote tulisi olla opittavissa ilman käyttöohjetta tai käyttökoulutusta? Esimerkki toisen tyyppisestä tavoitteesta on asiakkaiden viranomaisille tekemien ”turhien” puhelujen vähentäminen.

Tuotokset

Aktiviteetin tuotoksena kuvataan haluttu käytettävyysvaikuttavuus niin laadullisesti (mitä attribuutteja) kuin tavoitetasona. Attribuuttien tulisi kuvata yrityksen tai organisaation todellisia liiketoimintahyötyjä. Tavoitteiden määrityksessä tulisi pyrkiä mitattavuuteen.

Syytä olisi välttää sellaisia kriteereitä, jotka eivät riipu yksikäsitteisesti käytettävyydestä. Tällainen on esimerkiksi ”lisääntynyt myynti”: myyntiin vaikuttavat niin monet muutkin seikat, että käytettävyyden vaikuttavuutta on vaikea erottaa.

Käytettävyysvaikuttavuuden määrittäminen voidaan nähdä myös riskinhallintana. Tunnistetaan riskit, jotka seuraavat potentiaalisista käytettävyysongelmista. Käytettävyyssuunnittelu nähdään sitten riskin pienentämismenetelmänä.

Menetelmät

Aktiviteetti on liiketoimintajohdon, projektijohdon ja käytettävyysasiantuntijan välistä vuoropuhelua. Taustatiedoiksi voidaan tarvita ymmärrystä niin käyttäjäryhmistä (aktiviteetti 1) ja käyttökontekstista (aktiviteetti 2).

Viitteet

Jokela, T (2010). Navigoi oikein käytettävyyden vesillä. www.kaytettavyyskirja.net

Nokian käyttöliittymäkohtalon taustat 90-luvulla?

Nyt siis Nokia kurssi huitelee alamaissa. Käyttäjäkokemuksen suunnittelussa jälkeen jäämistä pidetään yhtenä keskeisistä syistä Nokian alamäkeen.

On kaikkiaan hämmentävää Nokian epäonnistuminen hyvän käyttäjäkokemuksen tuottamisessa. Nokialla on sankoin joukoin käytettävyys- ja käyttäjäkokemusammattilaisia - moni alalta väitellyt ja kansainvälisesti tunnustettu. Ei ole uskottavaa, etteikö Nokialla olisi ollut alan osaamista. Syyt ovat muualla. Nokia teknologiavetoisesta kulttuurista on puhuttu yhtenä syynä.

Mutta pidän yhtenä mahdollisena syynä myös erikoista käyttöliittymäparadigmaa, joka sai vallan Nokialla 1990-luvulla. Mielestäni on mahdollista, että tämän paradigman vaikutukset näkyivät vielä viime vuosiin asti ja ovat osaltaan taustalla Nokian puhelinten käyttäjäkokemusongelmiin.

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

Monet ehkä muistavat Nokian puhelinten erilaiset käyttöliittymät 90-luvun lopulla. Oli punainen ja vihreä luurinäppäin -käyttöliitymä, oli "navi"-näppäinkäyttöliittymä, oli rullakäyttöliittymä...

Nokialla sai silloin valtaa erikoinen "tyyliohjautunut" käytettävyysparadigma: strategiana oli erilaisia käyttöliittymätyylejä. Käytännössä silloin paradigma tarkoitti erilaisilla näppäimistöillä varustettuja puhelimia. Erilaisista käyttöliittymätyyleistä tehtiin itseisarvoja; niitä käytettiin mm. markkinasegmentoinnin keinona. Välitön seuraus ja ongelma oli tietenkin se, että eri puhelimet olivat keskenään erilaisia käyttää. Tyylien rajoitteissa pyrittiin kuitenkin tekemään puhelinten sovelluksista niin helppokäyttöisiä kuin pystyttiin. Ja kohtuudella onnistuttiinkin.

Toinen seuraus oli kuitenkin se, että yksinkertaistetuilla käyttöliittymätyyleillä oli vaikea suunnitella joitakin puhelinten sovelluksia millään tavalla elegantisti. Seurauksena saatettiin jättää operaattoreille tärkeitä sovelluksia pois. Jopa sanottiin, että "asiakkaat ovat väärässä", kun operaattorit halusivat tiettyä sovellusta.

Ydinasia tässä kuitenkin on se, että tyylikeskeisyys on tietenkin vastoin sitä, mitä käytettävyys aidosti on. Se on itse asiassa täysin vastakkaista käytettävyyden periaatteille, vaikka käytettävyyden nimellä sitä Nokialla sisäisesti markkinoitiinkin. Käyttöliittymänhän ei tulisi ole itseisarvo, vaan apuväline, vuorovaikutuskeino sovelluksiin. Kriteeri hyvälle käyttöliittymä on se, että sovellusten käyttö sujuu. Ei sen enempää. Käyttöliittymät tulisi suunnitella sovellusten ehdoilla eikä toisin päin.

Ja nyt pidän mahdollisena, että tämä erikoinen 1990-luvun oppi jäi elämään joidenkin Nokian päättävien henkilöiden keskuuteen myös pitkälle 2000-luvulle. Tällaista olen tulkinnut joidenkin Nokian johtajien julkisuudessa olleista lausunnoista vuosien aikana (tosin niin tarkkaan en seurannut asioita, että olisin kirjannut näitä muistiin). Joka tapauksessa vähän sen tyylistä viestiä, että ratkaisu ongelmaan olisivat olleet jotkut "käyttöliittymäjippo"-tason asiat.

-----------

Eli pidän siis mahdollisena, että tämä erikoinen oppi olisi vaikuttanut vielä viime vuosina Nokian käyttöliittymäpäätöksiin, jotka sitten viime kädessä realisoituivat tämän päivän jälkeenjääneisyyteen.

Tämä on kuitenkin minun pohdintaani, enkä tiedä, että menivätkö asiat todella näin 2000-luvulla (noita 1990-luvun tapahtumia kyllä seurasin omin silmin). Mutta ainakin tämä mielestäni olisi yksi looginen selitys sille, miksi Nokialla kävi kuin kävi; miksi Nokian merkittävä käyttäjäkokemusosaaminen ja -resurssit eivät realisoituneet tuotteisiin. Jos joku nokialainen eksyy tälle blogille, niin ehkä voi kommentoida asiaa.

Jos tämä tulkintani on osittainkin totta, niin siinä on tietenkin on mielenkiintoista pohdittavaa käytettävyys- ja käyttöliittymäalalle yleensä. Mutta ei mennä tässä asioiden edelle.