Kirjoittajan arkistot:teemutalja

Tuotehallinta, ihmiskeskeinen suunnittelu ja ketterä kehitys Reaktorissa

Kuva aiemman projektini tuoteomistajasta.Kuva entisestä käyttöliittymäsuunnittelun opettajastani.

Entinen käyttöliittymäsuunnittelun opettajani on ollut yhdistämässä ihmiskeskeisen suunnittelun ja ketterän ohjelmistokehityksen menetelmiä Reaktorissa vuodesta 2005, jolloin tämä työ alkoi siellä. Myös tuoteomistaja aiemmasta projektistani työskentelee nyt samassa yrityksessä liiketoiminnan pääkonsulttina. Ehdotin heille keskustelua aiheesta, miten asiakkaiden vaatimukset huomioidaan Reaktorin prosesseissa, ja tapaamista lounaan merkeissä. Koen asian tärkeäksi muun muassa, koska asiakasvaatimusten hallinta tuntuu työläältä tämänhetkisessä, scrumia soveltavassa projektissamme. Tapasimme lounaalla, ja osallistuin myös kuukautta myöhemmin Reaktorin toiminnallisuusarkkitehtien vetämään, NordiCHI’14-konferenssin yhteydessä järjestettyyn koulutustyöpajaan.

Reaktorissa on neljä kiinnostavaa, tuotehallintaa parantavaa toimintamallia:

  1. Asiakas tuoteomistajana
  2. Yksi kokonaisuus kerrallaan
  3. Fasilitoiva coach
  4. Asiakas kertoo organisaation tavoitteet

Kolme ensimmäistä näistä toimintamalleista perustuu keskusteluumme lounaalla, neljäs entisen opettajani NordiCHI’14-työpajassa antamiin vastauksiin kysymyksiini.

Asiakas tuoteomistajana. Reaktorin ohjelmistotiimeissä ei ole sisäistä tuoteomistajan roolia, vaan asiakkaan edustaja hoitaa tuoteomistajan tehtävät. Näistä tehtävistä tärkein on priorisoida toteutettavia kokonaisuuksia, eli järjestää ne tärkeysjärjestyksen mukaan prioriteettijonoksi. Next-sarakkeen vihreät laput havainnollistavat ohjelmistokehityksen prioriteettijonon kuvassa alla. Tärkein kokonaisuus, joka on suunnittelun puolesta valmis toteutettavaksi, on ylimpänä. Jotkut kokonaisuudet edellyttävät vuorovaikutussuunnittelua, ennen kuin ne voidaan siirtää kehityksen työjonoon. Tällaiset kokonaisuudet esitetään punaisina lappuina next-sarakkeessa. Jos projektissa on asiakkaana monta eri organisaatiota, tuoteomistajana voi toimia johtoryhmä, joka koostuu eri asiakasorganisaatioiden edustajista. Asiakkaan, tai asiakkaiden, tärkeimpänä pitämä kokonaisuus otetaan kulloinkin seuraavaksi työn alle.

Kuva Reaktorin kanban-taulun  muunnelmasta.

Kaavio 1. Reaktorin muunnelma kanban-taulusta. Lähde: Reaktor – Extremely lean service design & development. http://www.youtube.com/watch?v=KrxTgqBCjL8

Yksi kokonaisuus kerrallaan. Koko ohjelmistotiimi kehittää yhdessä yhtä ja samaa kokonaisuutta (engl. epic). Tämä ajatus on peräisin kanbanista. In progress -sarakkeen vihreät laput ovat työn alla olevia kokonaisuuksia. Pienemmät, keltaiset laput ovat kokonaisuuteen sisältyviä tehtäviä. Kerralla toteutettava kokonaisuus on laajuudeltaan tyypillisesti noin neljä päivää kalenteriaikaa toteutusta koko tiimiltä, joskus ehkä vain päivän, joskus kaksi viikkoa. Kokonaisuuksia ei pakoteta vakioituun ”sprintin” mittaan, koska sprinttimitoitus edellyttäisi tarkkoja työmääräarvioita, joiden laatimista ei ole koettu tuottavaksi työmäärän ja saadut hyödyt huomioiden.

Fasilitoiva coach. Reaktorissa kehitystiimi vastaa monista ohjelmistoprojektissa tarvittavista päätöksistä yhdessä. Organisaatiopsykologian mukaan tällaisille vähän johdetuille tiimeille on tyypillistä, että päätöksenteon ristiriitatilanteissa asiantuntijoiden välille muodostuu näkemyseroja, jotka kasautuvat jännitteiksi henkilösuhteisiin, koska päätöksenteon roolit ovat epäselviä. Reaktorissa tiimiin pyritään aina saamaan mukaan ”fasilitoiva coach”, jonka tehtävänä on auttaa tahoja, joilla on keskenään ristiriitaiset käsitykset jostakin asiasta, löytämään yhteinen näkemys (”make it happen”). Fasilitoiva coach johtaa keskustelua ja valmentaa muita, mutta ei osallistu työhön ohjelmistokehittäjänä eikä suunnittelijana, eikä myöskään ole johtaja, joka itse tekisi päätökset. Reaktorissa työskennellään yleensä kanbanissa eikä scrumissa, ja fasilitoiva coach tavallaan korvaa scrum masterin.

Asiakas kertoo organisaation tavoitteet. Entisen opettajani ”unelmien tuoteomistajalla” olisi selvä näkemys, mitkä kokonaisuudet ovat tärkeitä organisaation taloudellisten ja muiden tavoitteiden kannalta, eli palvelun ansaintalogiikasta. Tuoteomistajana toimivan asiakkaan edustajan ei tarvitsisi kilpailla Reaktorin tiimin kanssa käyttäjien arjen tuntemuksessa, koska käyttäjäymmärrystä kertyy perinteisissä asiakasorganisaatioissa yleensä vähemmän perusteellisilla menetelmillä kuin Reaktorissa tehtävä ihmiskeskeinen suunnittelu.

Kuva Reaktorin ihmiskeskeisestä kehitysprosessista.

Kaavio 2: Reaktorin ihmiskeskeinen kehitysprosessi. Lähde: User interface design in agile projects -tutoriaali, Reaktor, NordiCHI’14.

Kokonaisuuksien priorisointi oli kiinnostavassa asemassa, kun palvelu oli siirtynyt tuotantoon esimerkkiprojektissa, jota entinen opettajani esitteli NordiCHI’14-koulutustyöpajassa. Koska käyttäjien ja asiakkaiden toimintaympäristö muuttuu uuden palvelun käyttöönoton myötä, myös heidän toiminnalliset, palveluun kohdistuvat tarpeensa muuttuvat. Nämä tarpeiden muutokset kyetään huomioimaan syklisessä palvelukehityksessä (kuva yllä). Kun esimerkkipalvelu oli viety tuotantoon, nostettiin ohi muun prioriteettijonon kolme kokonaisuutta, jotka edistivät organisaatiotavoitteen ”uuden ohjelmiston laajamittainen käyttöönotto” toteutumista. Kenttätutkimuksissa oli seurattu käyttöönoton etenemistä ja haastateltu tahoja, jotka eivät olleet vielä ottaneet palvelua käyttöönsä. Kun tämän organisaatiotavoitteen kannalta tärkeät kokonaisuudet oli saatu tehtyä, tehtiin kokonaisuuksia, jotka edistivät käyttäjien tavoitteiden saavuttamista.

Käyn seuraavaksi läpi artikkelin alussa listaamani toimintamallit arvioiden, mitkä niistä olisivat hyödyksi omassa, tämänhetkisessä toimintaympäristössäni. Henkilökohtainen kiinnostukseni tuotehallintaanhan lähtee siitä, että olen päätynyt suunnittelijana ketterän kehityksen projekteissa olemaan ”prosessin joka vaiheessa” samanaikaisesti, mikä lisää työn kuormittavuutta ja pitkään jatkuessaan vähentää työssä jaksamista sekä tuottavuutta. Esimerkiksi kahden päivän aikana olen ollut mukana suunnittelemassa töitä pidemmällä aikavälillä, kuuntelemassa käytettävyystutkimuksen palautetta toteutustehtäviä poimien, toteuttanut prototyyppiä javascriptillä, suunnitellut parannuksia tuotantoversion käyttäjäkyselyyn ja kirjoittanut tarjouspyyntöä käyttäjätutkimukselle. Työtehtäviä oli eri puolilta suunnittelun ympäriltä, mutta varsinaista suunnittelua ei oikeastaan juurikaan.

Malli ”asiakas tuoteomistajana” näyttäisi ehkäisevän tehokkaasti ”rikkinäistä puhelinta” prioriteettien viestinnässä, eivätkä tilanteet, joissa jokin asiakkaan toive jää jostain syystä toteutumatta, aiheuta siinä kielteistä mielikuvaa palvelun tarjoajalle. Asiakkaiden erisuuntaiset pyynnöt vähenisivät, timiltä kuluisi vähemmän aikaa asiakasvaatimusten pähkäilyyn ja jäisi enemmän aikaa toteutukselle, mitä kautta myös suunnittelijan rooli voisi yksinkertaistua. Tuoteomistajan tarvitsisi kuitenkin nähdäkseni osallistua vaatimustenhallinnan arkeen viikkotasolla, jotta suunnittelijan työnkuva selkiytyisi, eikä näin aktiivista osallistumista liene realistista odottaa nykyisen projektimme asiakkailta. Erityyppisistä asiakkaista koostuva ohjausryhmä vaikuttaisi kyllä hyvältä ratkaisulta meidänkin projektissamme, mutta meillä on jo useampikin vastaava elin, jotka ovat käytännössä liian raskaita ollakseen viikkotasolla mukana projektin tuotehallinnassa.

Mallit ”yksi kokonaisuus kerrallaan” ja ”fasilitoiva coach” helpottanevat suunnittelijan työtä ketterissä ohjelmistokehitysprojekteissa suoraan. Kun koko projektissa on ”vähemmän palloja ilmassa”, myös suunnittelijoille kasaantuu vähemmän rinnakkaisia työtehtäviä. Ihmiskeskeistä suunnittelua tuntevasta ”fasilitoivasta coachista” olisi apua laajojen ja pienempienkin kokonaisuuksien suunnittelussa, koska tämä työ on risteävien vaatimusten ja tarpeiden yhteensovittamista.

Haluttavuus, elinkelpoisuus ja toteutettavuus kolmena toisiaan leikkaavana pallona.

Kaavio 3. Elinkelpoisuuden, haluttavuuden ja toteutettavuuden näkökulmat. Muokattu Ideon design innovation -kaavion pohjalta. www.ideo.com/about

Kokonaisuuksien tasolla tapahtuva priorisointi on yhtenä lähtökohtana malleissa ”kokonaisuus kerrallaan”, ”asiakas kertoo organisaation tavoitteet” ja ”asiakas tuoteomistajana”. Kehittämäämme palveluun on kuitenkin tarvetta toteuttaa nopeasti myös yksittäisiä palvelupyyntöjä, jotka koskevat jo tuotannossa olevia kokonaisuuksia. Tällaisilta irrallisilta tehtäviltä lienee vaikea välttyä, kun kehitetään alustaa, joka on jo tuotannossa. Tuotannossa oleviin kokonaisuuksiin liittyvät tehtävät voitaisiin vaikkapa esittää pieninä, oransseina lappuina, joiden käsittelyyn olisi omat käytäntönsä.

Toimintamalli ”asiakas kertoo organisaation tavoitteet” yhdistää tehokkaasti elinkelpoisuuden (engl. viability), haluttavuuden (engl. desirability) ja toteutettavuuden (engl. feasibility) näkökulmat, ja helpottaisi ihmiskeskeisen suunnittelun arkea omassa ympäristössäni. Asiakkaan edustaja ilmaisee organisaatiotavoitteet vapaamuotoisesti. Kun asiakas ehdottaa ratkaisumallia, ei kuitenkaan keskitytä hänen sanoihinsa, vaan pyritään kuuntelemaan toiminnallisia tarpeita, joita ehdotettu ratkaisu voisi palvella, ”sanojen takana”. Tässä kohtaa ihmiskeskeisen suunnittelun, palveluajattelun ja käyttäjätutkimuksen lähestymistavat soveltuvat mielestäni paitsi käyttäjien myös asiakkaiden ymmärtämiseen. Kun eri puolilla ehdotetut, samaa tai samankaltaista tarvetta palvelevat ratkaisumallit saadaan redusoitua yhdeksi toiminnalliseksi kokonaisuudeksi, helpottuu paitsi ihmiskeskeinen suunnittelu, myös ohjelmistokehitys. Tarvittavat kokonaisuudet saadaan toteutettua vähemmillä resursseilla, mutta valmiit toteutukset ovat silti asiakkaille elinkelpoisia ja käyttäjille haluttavia.

1. Ymmärrä tuettavan toiminnan tilanteet ja tavoitteet. Tuottaa vaatimuksia. 2. Havainnollista toimiva ratkaisu. Tuottaa palautetta.

Ketterä versio ihmiskeskeisen suunnittelun standardista (ISO 13407)

En taustoittanut aiemmassa artikkelissa esittämääni käyttäjäkeskeisen suunnittelun prosessimalliluonnosta. Vaikka käyttäjäkeskeisestä ja ihmiskeskeisestä suunnittelusta on julkaistu kehittyneitä ja vertaisarvioituja menetelmiä, näitä termejä käytetään arjessa löyhästi. Esittelen tässä ISO 13407 -standardissa kuvatun ihmiskeskeisen suunnittelun prosessimallin ja sen pohjalta luonnostelemani kevyemmän mallin, joka lähestyy standardia käytännön näkökulmasta.

ISO 13407 kuvaa vuorovaikutteisten järjestelmien ihmiskeskeisen suunnittelun. Sen sisältämässä prosessimallissa (kuva alla) tehdään neljää toimintaa (activity):

  1. Käyttöyhteyden ymmärtäminen
  2. Tavoitteiden asettaminen
  3. Ratkaisujen suunnittelu
  4. Ratkaisujen arvointi
1. Käyttöyhteyden ymmärtäminen 2. Tavoitteiden asettaminen 3. Ratkaisujen suunnittelu 4. Ratkaisujen arvointi

Kuva: © Tuuli Mattelmäki, 2006

Kaavio kuvaa syklisen prosessin, joka vastaa kokemukseni mukaan tiedonkulkua ja oppimista suunnittelutyössä, mutta ei sen työvaiheita, koska samassa arjen hetkessä voi tapahtua montaa ISO:n toiminnoista. Esimerkiksi käyttökokemusta arvioidessaan kannattaa yleensä pyrkiä kasvattamaan ymmärrystä paitsi olemassaolevan ratkaisun käytettävyydestä, myös sen käyttöyhteydestä eli missä tilanteessa sitä käytetään ja miksi. Montaa ISO:n toimintoa voi tapahtua yhdessä hetkessä myös suunnittelutilanteessa, kun syntyy oivallus käyttötilanteesta ja sen asettamista vaatimuksista, sekä samalla jo hahmotelma vaatimukset täyttävästä ratkaisusta.

Ihmiskeskeisen suunnittelun voi mielestäni pelkistää kahdeksi toiminnaksi. Näistä ensimmäinen on käyttötilanteiden ja tavoitteiden ymmärtäminen, toinen ratkaisujen havainnollistaminen (kuva alla). Karkeasti ottaen näitä suunnittelutyön kahta osaa voisi kutsua myös nimillä tutkimus ja suunnittelu, mutta tutkimus on kovin juhlava sana seuraaville esimerkeille.

1. Ymmärrä tuettavan toiminnan tilanteet ja tavoitteet. Tuottaa vaatimuksia. 2. Havainnollista toimiva ratkaisu. Tuottaa palautetta.

Palvelu- ja vuorovaikutussuunnittelijalta tilattavat kokonaisuudet ovat yleensä melko laajoja, jolloin yksi ”kierros suunnittelua” kestää joitakin viikkoja. Esimerkkinä toimikoon Finna.fi -tiedonhakupalvelu, jonka käyttökokemuksesta vastaan, ja jonka käyttötilanteet kartoitin viime vuonna. Uskottavia käyttötilanteita oli tunnistettu ja kerätty projektissa jo aiemmin, enkä lähtenyt tekemään varsinaista käyttäjätutkimusta. Empiirinen tiedonkeruu ei ollut tässä tapauksessa välttämätöntä myöskään, koska Finna.fi on laajalle käyttäjäryhmälle suunnattu palvelu, jonka käyttötilanteista moni oli minulle ja muille tiimissä entuudestaan tuttu ”oman elämän etnografian” kautta eli omasta elämänkokemuksesta.

Analysoin Finna.fi:n käyttötilanteet ja luokittelin ne kolmeen luokkaan, jotka ovat temaattinen haku, teoshaku ja selaileva haku. Temaattista hakua on esimerkiksi materiaalin keruu musiikintutkija A. O. Väisäsestä TV-dokumenttia tai tutkimusta varten. Tenttikirjan etsiminen olisi teoshakua. Selailevassa haussa käyttäjän päämäärä ei ole aina kovinkaan konkreettinen, esimerkiksi kun taiteentutkija surffailee materiaalia taideteoksesta tulevien tutkimustensa mahdollisiksi aiheiksi. Tein käyttötilannekartoituksen ja tavoiteanalyysin muutaman kuukauden kuluessa, mikä ei ollut kokoaikaista työtä, koska suunnittelimme ja Scrum-kehitystiimi toteutti samalla palveluun käyttöliittymäparannuksia. Idea moneen käyttöliittymäparannukseen nousi käyttötilanteiden läpikäymisestä, ja toteutustehtäviä myös priorisoitiin sen perusteella, kuinka monessa esimerkkitilanteessa ongelma toistui. Poimin ne käyttötilanteet, joissa oli riittävät taustatiedot käyttökokemuksen arviointiin, myöhemmin suunnittelussa hyödynnettäviksi. Jätin viisitoista – kaksikymmentä käyttötilannetta pois, koska niistä ei ollut riittäviä tietoja käytön ”simuloimiseen” asiantuntijatyönä. Olen käynyt esimerkkitilanteet läpi suunnittelutyön edetessä muutaman kuukauden välein, jotta käyttötilanteet ja käyttäjien tavoitteet säilyvät minun ja kehitystiimin mielissä, ja jotta ”pysyn kartalla” Finna.fi:n käyttökokemuksesta ja käytettävyydestä todellisissa käyttötilanteissa.

Ylävalikko ennen muutosta, Tietoa-valikko auki

Ylävalikko muutoksen jälkeen: Tietoa-valikko poistettu

Pienen osakokonaisuuden suunnittelu, kuvat ennen ja jälkeen.

Myös pienempien osakokonaisuuksien käytettävyyden parantaminen etenee joskus ”ihmiskeskeisen suunnittelun kierroksina”. Esimerkiksi kun sisällytimme palveluun listan mukana olevista organisaatioista, se oli aluksi vaikea löytää, koska valikon ykköstason linkkiteksti ei houkutellut avaamaan sitä. Ylemmässä kuvassa vasemmalla on tämä ensimmäinen versio. Organisaatiot-linkki siirrettiin myöhemmin valikon ykköstasolle, missä se on heti näkyvillä (alempi kuva). Tämän käytettävyysparannuksen suunnittelu ja toteutus kesti yhteensä alle henkilötyöpäivän.

Käyttäjäkeskeinen ja ihmiskeskeinen suunnittelu tarkoittavat tässä ja aiemmassa artikkelissani samaa asiaa, vaikkakin ihmiskeskeisessä suunnittelussa käytännön suunnitteluprosessi ja asiakkaan tarpeet korostuvat, kun taas käyttäjäkeskeisessä painottuu tuotteen ja loppukäyttäjän välinen vuorovaikutus. Termin käyttäjäkeskeinen suunnittelu on esitellyt Don Norman teoksessaan The Design of Everyday Things, jonka voi ladata verkosta ilmaiseksi.

Viisi vihjettä, miten parantaa yksityisyyttä käytettävyydestä tinkimättä

Janet Hill's painting Mistress Of Disguise

Apple, Google ja Facebook tarjoavat käyttökokemukseltaan hyviä palvelukokonaisuuksia, ja keräävät tietoa näiden käyttäjistä osana liiketoimintaansa. Kerättävät miljoonien ihmisten, kokonaisten kansakuntien, tiedot kasautuvat näiden suuryritysten palvelimille. Nämä tietomäärät tulevat paisumaan ja muodostamaan yhteiskunnallisia riskejä lähivuosikymmeninä. Käyttäjien seuranta on yrityksille edullista ja vaivatonta, koska robotit keräävät tiedon ja tekoäly analysoi sitä. Esitän tässä viisi vihjettä, joilla mobiililaitteiden ja verkkopalvelujen käyttäjä voi ehkäistä yksityisyyteensä kohdistuvia loukkauksia.

  1. Facebook ja surffailu eri selaimissa
  2. Muiden epäoleellista tietoa keräävien sovellusten välttäminen
  3. Eri käyttäjätilit Googlen laitteille ja palveluille
  4. Gmail Boomerang-sovelluksessa
  5. Googlen omien Android-sovellusten käyttö tunnistautumatta

Tämän tekstin näkökulma on rajattu erityisesti Googlen laitteisiin ja palveluihin, koska nykyinen puhelimeni on Android-laite. Kuten Googlen, myös Applen ja Microsoftin liiketoimintamalleissa sama yritys tuottaa sekä laiteohjelmiston että verkkopalveluita. Siksi jotkut Googlea koskevista vihjeistä auttanevat myös iOS- ja Windows Phone- käyttäjiä, joita tiedonkeruu huolettaa.

The first Czech radio amateur, Pravoslav Motycka, 1923 (OK1AB). Source http://www.crk.cz/ENG/SPOLKYE.
Female Radio Amateurs © The Ham Radio Files, from blog article Historical Events in Amateur Radio, source http://wp4oca.blogspot.fi/

1.  Facebook ja surffailu eri selaimissa. Kun Facebookia käyttää mobiiliselaimella, luovuttaa vähemmän käyttäjätietojaan Facebookille kuin jos käyttäisi Facebookin omaa mobiilisovellusta. Verkkosivustot eivät Android-selaimissa saa käyttöönsä laitteen yksilöivää IMEI-koodia, eivätkä selainsovellukset vaadi yleensä kuin murto-osan Facebook-sovelluksen pääsyoikeuksista käyttäjän tietoihin. Kun Facebookin Android-sovelluksen asentaa puhelimeensa, se ottaa käyttöönsä muun muassa puhelimen kalenterin, teksti-, multimedia- ja sähköpostiviestit sekä puhelu- ja viestilokit. Koska nämä eivät liity kiinteästi Facebookiin, on suojatumpaa käyttää mobiilisivustoa kuin sovellusta. Kolmansien osapuolten Android-sovellukset ovat mobiilisivustoa huonompi ratkaisu, koska niissä ei näy kaikkia henkilöitä ja tietoja, jotka ovat Facebookissa. Facebook vaikuttaisi toimivan moitteetta esimerkiksi Google Chrome -selaimella.

Käytän itse yhtä selainta googlettamiseen ja surffailuun, ja toisessa tunnistautumista vaativia palveluja kuten Facebook, Twitter, LinkedIn ja Gmail. Kun on kirjautunut selaimessa Facebook-sivustoon, Facebook seuraa käyttäjän liikkeitä paitsi Facebookin sisällä myös kaikissa sivustoissa, joihin Facebook on integroitu joko Tykkää-painikkeella tai muulla tavoin. Koska tunnistautuminen on selainkohtainen, seurannalta välttyy käyttämällä kahta selainta.

2.  Muiden epäoleellista tietoa keräävien sovellusten välttäminen. Yritykset saavat Euroopan ja Yhdysvaltojen lakien mukaan tallentaa verkkopalvelun tai laitteen käyttäjistä tietoja, joita ne tarvitsevat palvelun tai laitteen toiminnallisuuksien toteuttamiseksi. Yritys voi perustella kiinnostaviksi katsomiensa tietojen keräämisen, kun se tarjoaa näihin tietoihin liittyviä lisäominaisuuksia, vaikka näiden toiminnallisuuksien merkitys käytettävyydelle ja käyttökokemukselle olisikin vähäinen. On suositeltavaa välttää sellaisten sovellusten asentamista ja käyttöä, joissa käyttäjätietojen keruu ei liity sovelluksen tärkeinä pitämiinsä toiminnallisuuksiin.

Emily Winfield Martin's painting Bear Disguise

3.  Eri käyttäjätilit Googlen laitteille ja palveluille. Käyttäjätietoja keräävillä yrityksillä on usein pyrkimyksenä yhdistää eri puolilta kerättävät tiedot mahdollisimman suuriksi kokonaisuuksiksi. Internetin suuryrityksistä Googlella on parhaat mahdollisuudet laajojen tietovarantojen keräämiseen, koska se tarjoaa monia yleisimpiä laite- ja selainalustoja sekä verkkopalveluja. Jotta toisiinsa sisällöllisesti liittymättömissä palveluissa kerättyjä tietoja ei voi aivan helposti yhdistää, kannattaa tunnistautua eri käyttäjätileillä laitteeseen ja laitevalmistajan verkkopalveluihin. Esimerkiksi Google Play -sovelluskaupassa ja Gmailissa voi käyttää eri Google-tilejä tinkimättä palvelujen käytettävyydestä, koska nämä palvelut eivät liity sisällöllisesti toisiinsa.

Eri laitteissa ja palveluissa kerättyjen, yhtä käyttäjää koskevien tietojen yhdistämiseen tarvitaan sama yksilöivä tunniste eri tietolähteissä. Sellaisena voi toimia esimerkiksi käyttäjätunnus, sähköpostiosoite, puhelinnumero, laitekohtainen IMEI-koodi tai muu laitteen ”sarjanumero”. Jos haluaa tehdä parhaansa hankaloittaakseen käyttäjätiliensä yhdistämistä, ei kannata liittää yhtään samaa puhelinnumeroa, luottokorttia tai sähköpostiosoitetta eri tileihin. Toissijaisena yhteystietonaan voi antaa yhdessä Google-tilissä sähköpostiosoitteen puhelinnumeron sijaan, ja liittää luottokortin ainoastaan laitetiliin, jossa sitä tarvitaan Google Play-sovelluskaupassa. Käyttäjänimi voi olla eri Google-tileissä sama, koska on monesti välttämätöntäkin esiintyä omalla nimellään.

The emblem of the Boomerang Gmail app

4.  Gmail Boomerang-sovelluksessa. Jos haluaa ehkäistä Gmail- sähköpostiarkistojensa ja laitteen käyttötietojen yhdistämistä samaan tietovarantoon, Gmail-sähköpostiarkistoaan voi käyttää muulla kuin Googlen Android-sovelluksella. Kun käyttää kolmannen osapuolen Gmail-sovellusta, IMEI-laitetunnistetta ei voida käyttää Gmail-palvelussa käytetyn tilin ja laitetilin kytkemiseen. Boomerangin Gmail-sovellus tarjoaa hyvän käyttöliittymän, jolla voi muun muassa hakea kaikista Gmail-kansioista kerralla. Vielä paremman yksityisyyden toki saavuttaa, jos käyttää pienemmän palveluntarjoajan sähköpostia Gmailin sijaan.

5.  Googlen omien Android-sovellusten käyttö tunnistautumatta. Koska Googlen Android-sovellukset kytkeytyvät oletusarvona laitetiliin, on erikseen kirjauduttava ulos sovelluksista, jos haluaa käyttää niitä tunnistautumatta. Kirjautuminen ulos Google Chrome -selaimesta ei haittaa Internet-käyttöä, ja myös Google Maps toimii hyvin, kunhan sallii paikkatiedon käytön.

Keskustelu mobiililaitteiden ja verkkopalvelujen yksityisyydestä on mielestäni erittäin tervetullutta. Kommentoikaa vapaasti, myös jos minulta on jotain huomioimatta.

Mitä on interaktiosuunnittelu – suomeksi?

tanworth_iron_age_bronze_comb
Rautakautinen pronssikampa (n. 25-75 jkr)

Mitä on interaktiosuunnittelu – suomeksi?  Sanan laajemmassa merkityksessä suunnittelun lähtökohdaksi otetaan käyttäjän tavoitteet ja mietitään, millaisella vuorovaikutusprosessilla nämä tavoitteet saavutettaisiin mahdollisimman helposti ja miellyttävästi. Koska työn lähtökohtana ja arvona on vuorovaikutuksen sujuvuus, prosessia voisi kutsua vuorovaikutussuunnitteluksi. Esimerkiksi kampa (kuvassa) voitaisiin suunnitella takkujen poistamista hiuksista, hiusten muotoilua ja kauneutta varten. Näistä lähtökohdista hahmoteltaisiin mahdollisimman sujuva vuorovaikutus ja sitä tukeva väline.

Ammattikielessä puhutaan ”interaktioista” ja niiden suunnittelusta, kun viitataan yksittäisiin osaongelmiin ja -ratkaisuihin. Esimerkiksi kammassa on piikit ja kahva sekä kuvan muinaiskammassa lisäksi kahvassa reikä, samoin kuin monissa nykyisissä hiusharjoissa. Voisiko tällaisia ”interaktioita” kutsua vuorovaikutteiksi ja niiden muotoilua vuorovaikutesuunnitteluksi? Tällaisessa hajota ja hallitse -vuorovaikutussuunnittelussa on ongelmansa. Esimerkiksi kampaaminen tai hiusten harjaaminen ei välttämättä ole helppoa ja miellyttävää kaikilla välineillä, joissa on piikit, kahva ja reikä, vaikka jokainen osa olisi hyvin suunniteltu.

Kun puhutaan ohjelmistojen vuorovaikutussuunnittelusta sanan laajemmassa merkityksessä, käyttöliittymäsuunnittelu on harhaanjohtava sana. Käyttöliittymä on toteutuksen tekninen osa, ja jos käytöstä halutaan sujuvaa, vaikutukset eivät välttämättä rajoitu käyttöliittymään.

Puhelinten ja taululaitteiden näyttö- ja pikselikoot

Pikselin koko on ollut kutakuinkin vakio, 38 pikseliä senttimetrillä (96dpi). Kun on puhunut kirjasinkoosta “14 pikselin Arialina”, on voinut olettaa tulevansa ymmärretyksi, samaan tapaan kuin puhuisi tennispallon koosta. Koska näyttöjen piirtotarkkuus on kasvanut uusissa puhelin- ja taululaitteissa, pikselin käsite on muuttunut moniulotteisemmaksi.

Piet Mondrian: Composition Chequerboard, Dark Colors, from year 1919

Internet-sivujen tyylimäärittelyissä pituutta mitataan CSS-pikseleissä, jotta sivut näkyvät samalla tavoin eri laitteilla. Neljä CSS-pikseliä on noin yksi millimetri, kun kohdetta katsellaan käsivarren etäisyydeltä. CSS-pikseli on laitepikseliä tarkoituksenmukaisempi mittayksikkö, koska CSS-pikseli on vakiokokoinen ja laitepikseli suhteessa näytön piirtotarkkuuteen. Kun kirjasinkoko annetaan laitepikseleinä, Samsung Galaxy Note -puhelimessa neljätoista pikseliä on millimetrikooltaan vain noin puolet siitä, mitä toisessa Samsungin puhelimessa, Galaxy Y:ssä.

Pikselisuhde (engl. device pixel ratio) kertoo, montako CSS-pikseliä mahtuu laitepikselille. Goldilocks-blogiartikkelin kuvat havainnollistavat pikselisuhdetta. Taulukossa alla on listattu joidenkin tällä hetkellä myynnissä olevien laitteiden oletusselainten ilmoittamat pikselisuhteet, ja portrait- ja landscape-asennoissa ilmoittamat näytön leveydet.

Laite Koko Tarkkuus Portrait Land-
scape
Pikseli-
suhde
Yksikkö
Samsung Galaxy Y (S5360) 3,0” 240×320 320 427 0,75 css-
pikseli
Apple iPhone, 4th Gen 3,5” 640×960 320 320 2 css-
pikseli
Nokia Lumia 800 3,7” 480×800 480 480 undefined laite-pikseli
Samsung Galaxy S Plus (i9001) 4,0” 480×800 320 533 1,5 css-
pikseli
Sony Xperia S 4,3” 720×1280 360 640 2 css-
pikseli
Samsung Galaxy SII (I9100) 4,8” 480×800 480 800 undefined laite-pikseli
Samsung Galaxy Note 5,3” 800×1280 800 1280 2 laite-pikseli
Samsung Galaxy Tab 7,0” 600×1024  600  1024 1  
Sony Tablet S1 9,4” 800×1280  800 1280 1  
Apple iPad 2 9,7” 768×1024 768 768 1  
Apple iPad, 3rd Gen 9,7” 1536×2048 768 768 2 css-
pikseli
Samsung Galaxy Tab 10.1 10,1” 800×1280 800 1280 1  
Acer Iconia Tab A200 10,1” 800×1280 800 1280 1
Acer Iconia Tab A510 10,1” 800×1280 800 1280 1  
Asus Eee Pad Transformer 10,1” 800×1280 800 1280 1  

Näyttökokoa mitataan joskus matalan tason laitepikseleinä, vaikka CSS-standardin mukaan mittayksikkönä tulisi käyttää CSS-pikseliä. Valtaosa tällä hetkellä myynnissä olevista puhelimista ja taululaitteista ilmoittaa näytön leveyden CSS-pikseleissä. (Jos pikselisuhde on yksi, css-pikseli ja laitepikseli ovat samankokoiset.)

Näytön tuumakoko kertoo laitteesta enemmän kuin tarkkuus pikseleissä. Halkaisijaltaan alle viiden tuuman näytöllä varustetut laitteet ovat lähes aina puhelimia. Koska pientä laitetta on miellyttävää pidellä yhden käden varassa ja sitä katsellaan yleensä lähempää kuin suurempaa, sylissä pidettävää laitetta, puhelimissa on yleensä pienemmät pikselit kuin taululaitteissa. Taululaitteiden näyttökoot vaihtelevat välillä 7 – 10.1 tuumaa. On vain harvoja laitteita, joissa näyttökoko on välillä 5 – 7 tuumaa. Tällä hetkellä myytävistä laitteista tällainen näyttö on Samsung Galaxy Notessa ja kirjanlukulaitteissa.

Eräässä kaksi vuotta sitten tehdyssä testissä matalan tason laitepikseli oli vielä yleisin yksikkö, jossa puhelimet ja taululaitteet ilmoittivat näyttökoon. On hyvä, että CSS-pikselin käyttö on yleistymässä, koska se on laiteriippumaton ja loppukäyttäjälle tarkoituksenmukainen yksikkö.

Käyttäjäkeskeinen suunnitteluprosessi: ensimmäinen luonnos

suunnitteluprosessi

Hyvä palvelu- ja käyttökokemussuunnittelija tekee kahta asiaa: ymmärtää tuotteeseen tai palveluun kohdistuvat tarpeet ja luo ne täyttäviä ratkaisuja.Luomisen ja ymmärtämisen vaiheet seuraavat toinen toisiaan.

Luo. Luomisvaiheessa hahmotellaan tuote tai palvelu pitäen loppukäyttäjien tavoitteet ja asiakkaan liiketoimintatavoitteet suunnittelun lähtökohtana. Tuloksena syntyy konkreettisia havainnekuvia, joista loppukäyttäjät ja liiketoiminta-asiakkaat osaavat sanoa, täyttävätkö ne omat tarpeet ja tavoitteet vai eivät.

Ymmärrä. Ymmärryksen hankkimisvaihe tuottaa ymmärrystä sekä arvioitavien ”rautalankojen” toimivuudesta että käyttäjien ja asiakkaiden tarpeista ja tavoitteista. Havainnekuvien käyttö nostaa esiin käyttökokemuksen kannalta tärkeitä asioita, jotka jäävät helposti huomaamatta. Ymmärryksen hankkimisvaihe auttaa myös löytämään kokonaan uusia toimintamalleja, joita ei aiemmin ole ajateltu, koska se luo vuoropuhelua eri näkökulmien välille.

suunnitteluprosessi, toteutusvaihe
Ihmiskeskeinen suunnittelu toteutusvaiheissa.

Rakenna. Kuva yllä esittää suunnittelun varhaisia vaiheita, joissa toteutusta ei vielä ole aloitettu. Tekijätiimillä on hyvä olla kokonaiskuva tuotteen tai palvelunrakenteesta, ja käyttäjän vuorovaikutuksesta sen kanssa, ennen kuin toteutus alkaa. Suunnittelun yksityiskohdat täsmennetään toteutuksen aikana.

Käytettävyystesti ja kontekstuaalinen haastattelu

tumblr_lf0wsbb5871qziezc

Käytettävyystesti ja kontekstuaalinen haastattelu ovat hyvin samanlaisia. Monilla asiantuntijoilla tosin on taipumus keskittyä käytettävyystesteissä kapea-alaisiin, tarkasti ennalta rajattuihin kysymyksiin. Tällainen lähestymistapa ei jätä juurikaan varaa perehtyä käyttäjien toimintaan, todellisiin kokemuksiin ja käyttötilanteisiin. Sen sijaan kontekstuaalisissa haastatteluissa kysymykset ja tehtävät pidetään usein avoimina ja ne liittyvät käyttäjien todelliseen toimintaan. Raja käytettävyystestin ja kontekstuaalisen haastattelun välillä on häilyvä, samaan tapaan kuin rakenteellisessa ja temaattisessa haastattelussa.

Monilla designereilla tuntuu olevan kielteinen asenne käytettävyystestausta ja -tutkimusta kohtaan. Uskon, että tämä johtuu käytettävyyden kapeasta mieltämisestä ja helppojen voittojen strategiasta, joita molempia Jakob Nielsen on voimakkaasti ajanut. Laajemmassa merkityksessä käytettävyys tarkoittaa, miten tarkoituksenmukainen, käytännöllinen ja miellyttävä palvelu tai tuote on todellisille käyttäjille todellisissa käyttötilanteissa. Tämä on käytettävyyden ”todellinen” merkitys, joka on määritelty ISO-standardissa 9241. Käytettävyys on paljon enemmän kuin suuria fontteja ja kontrasteja, kun sitä kehitetään tarkoituksenmukaisesti ja kontekstuaalisesti.

Hyvä pyöräilyasento

Pattabhi Jois in samasthiti, the yoga standing pose, which is also known as tadasana. 1_nurmikolla_nishiki_351_shorter3
3_05012011294_hyva
Hyvä seisoma-asento. Polkupyörän ohjaustanko vaikuttaa ryhtiin.

Hybridipyörissä on suora ohjaustanko. Se vetää olkapäät eteenpäin, samaan tapaan kuin tietokoneella työskentely, mikä ei ole hyväksi työmatkapyöräiljälle. Vaihdatin siksi pyörääni vakiomallisen ohjaustangon.

Ohjaustangon ”vakiomallista” on paljon eri muunnelmia, jokainen vähän eri tavalla käyrä. Kiitos kaverin vinkin, tajusin mennä kierrätyskeskukseen, jossa oli yli 50 ohjaustangon valikoima 3 euron kappalehintaan.

Käytettävyystestin rakenne

usability_test_comicsHuomaan, että järjestän käytettävyystestitehtävät yleensä seuraavalla tavalla:

  1. Käyttäjän omat tehtävät.

    ”Mitä teit viimeksi kun käytit tätä? […] Näytä, miten toimisit siinä tilanteessa.”

  2. Ennalta asetetut tehtävät.

    ”Tyttöystävälläsi on huomenna syntymäpäivä. Haluat ostaa elokuvaliput teille molemmille. Miten toimisit?”

  3. Katselmointitehtävät.

    ”Tutustu tähän [järjestelmän osaan tai toimintoon], ja kerro vapaasti mitä ajattelet.”

Tällä järjestyksellä pyrin minimoimaan aiempien tehtävien priming-vaikutukset. Priming-vaikutus tarkoittaa, että se mitä olet tehnyt hetkeä aiemmin vaikuttaa, miten ratkaiset ongelmia ja toimit nyt.