UX

Teknistä osaamista yritykseen osaajapulasta huolimatta?

Softa-alan osaajapula on monilla huulilla ja otsikoissa. Isot firmat vievät osaajat käsistä isoihin konsultointiprojekteihin, joiden asiakkaina on usein isot yritykset sekä julkisen sektorin digitalisaatiohankkeet. Moni osaaja valitsee mielummin yrityksen, jossa on varmuutta enemmän kuin startupissa välttämättä on. Tästä syystä moni startup saattaa joutua maksamaan softa-alan osaajille erittäinkin suurta palkkaa, jotta riskinottokyky voittaisi epävarmuuden.Itse kuitenkin näen, että monesti osaajapula johtuu vain tehottomuudesta ja yritykset ostavat softaosaamista ihan liikaa todelliseen tarpeeseen ja toisaalta myös ostetun työn tuottavuuteen nähden.

Olemmekin kokeilleet nyt muutamien asiakkaiden kanssa tietynlaista "Tech lead as a service" -tyyppistä lähestymistapaa, jolla saa käyttöönsä käytännössä koko meidän firman, mutta meillä on kuitenkin selkeästi yksi henkilö, joka tuntee asiakkaan projektin parhaiten, mutta myös asiakasvastaava, joka pitää huolta siitä, että työ jakautuu järkevästi ja että kysymyksiin löytyy vastaukset tehokkaasti. Jo muutamalla tonnilla kuukaudessa voi siis saada meiltä koko firman osaamisen käyttöön ja me sisäisesti järjestämme asian niin, että meiltä on oikeat ihmiset projektissa mukana. Välillä tarvitaan arkkitehtuurisuunnittelua, integraatioita, toisaalta taas jossain kohtaa enemmän osaamista esim. mobiilisovelluskehitykseen tai käytettävyyteen. Mielestäni tämä on hyvä malli, jota pystytään tarpeen mukaan skaalaamaan erittäin nopeasti ylöspäin useaan henkilöön per kk ja tarvittaessa pistämään koko homma tauolle, jolloin kustannukset tippuvat minimiin.

Toimimme käytännössä näin jo nyt, mutta kiinteä kuukausilaskutus tuo helpoutta ja ennustettavuutta niin asiakkaalle - kuin meillekin (mitäs sitä asiaa peittelemään). Ja tätä kautta myös me pystymme koko ajan parantamaan omaa tarjontaamme ja tuomalla kysyttyä osaamista osaksi palveluitamme.Ja jos haluat vain kokeilla, miten homma toimisi käytännössä meidän kanssa, niin pystyn lupaamaan palvelun käyttöön ilman irtisanomisaikaa, vaikka kuukaudeksi. Rehellisyyden nimissä esim. 2000€/kk -paketilla ei kuukaudessa välttämättä päästä vielä paljoa pintaa syvemmälle varsinkin jos pitäisi keskittyä olemassa olevaan järjestelmään, mutta vaihtoehtoisesti, jos kyseessä olisi vaikka suppea järjestelmäintegraatio, niin työ voisi olla hyvinkin tehtävissä ja maksaisi itsensä takaisin saman tien.

Meillä tiimi palvelee Tampereella, meidän omalla porukalla tai sovittaessa otetaan paikallisia kumppaneita mukaan.

Autan mielelläni kartoittamaan tarpeesi täysin veloituksetta, joten jos haluat apua, niin ota minuun suoraan yhteyttä mikko@haltu.fi tai +358-350-6464, voit myös jättää yhteydenottopyynnön sivujemme kautta, niin palaamme asiaan mahdollisimman nopeasti. Jätä yhteydenottopyyntö

Videot Käyttäjäkokemus-appin käyttäjätestauksesta

Tutkimme tammikuussa sovelluksen käytettävyyttä käyttäjätestauksen avulla. Toteutimme käyttäjätestauksen kuudella testihenkilöllä. Lue artikkeli kokonaan kyseisestä käyttäjätestauksesta!

Käyttäjätestaus

Käyttäjätestauksen ideana on selvittää, vastaako toteutettu järjestelmä tai prototyyppi käyttäjän tarpeita. Sen aikana käyttäjä suorittaa hänelle annetun tehtävän, joka vastaa järjestelmän käyttöä oikeassa tilanteessa. Tilanne voidaan taltioida videona tai äänenä, ja/tai tilanne voidaan havainnoida samalla kun käyttäjä suorittaa tehtävän järjestelmässä.

Blogibotti Jaakko Niiles tenttaa tietämyksesi käytettävyyden pikamenetelmistä

Toteutimme blogiamme varten UX-persoonan, Jaakko Niileksen. Jaakko on vähän keskiverto bottia räiskyvämpi persoona, mutta niinhän me kaikki. Tule testaamaan Jaakkoa!

Käytettävyyden pikamenetelmät: Huonoin idea ikinä

Käytettävyyden pikamenetelmä on keino tarkastella järjestelmän käytettävyyttä mahdollisimman helposti ja nopeasti. Pikamenetelmät ovat tiivistettyjä versioita olemassa olevista menetelmistä. Pikamenetelmien avulla voidaan löytää ainakin suurimpia käytettävyysongelmia mutta suositeltavaa on aina käyttää myös täysimittaisia menetelmiä.

Käytettävyyden pikamenetelmät: Pyörä 2.0

Pyörä 2.0 lähti ajatuksesta, että sovelluksen halutaan erottuvan kilpailijoiden tuotteista ja varmistua siitä, ettei tätä tehdä käytettävyyden kustannuksella. Mutta koska pyörää ei lähtökohtaisesti kannata yrittää keksiä uudelleen, menetelmässä keskitytään yleensä yksittäisiin ominaisuuksiin, joihin etsitään valmiita ratkaisuja.

Käytettävyyden pikamenetelmät: Heuristiikat

Heuristiikat ovat tarkistuslistoja, jotka eivät ole pakollisia vaatimuksia järjestelmälle, jotta järjestelmän käytettävyys olisi hyvä. Heuristiikkoja pitää ajatella ennemminkin peukalosääntöinä. Heuristiikkoja on olemassa erilaisia mutta tämä pikamenetelmä pohjautuu Nielsenin heuristiikkoihin.

Käytettävyyden pikamenetelmät: 1-2-3 persoona

Persoona esittää käyttäjäjoukkoa, joka käyttäytyy samalla tavalla tehdessään ostopäätöksiä, käyttäessään erilaisia teknologioita tai tuotteita, ollessaan yhteydessä asiakaspalveluun ja tehdessään elämäntapaan liittyviä valintoja. Persoonia käytetään kun arvioidaan uusia ideoita, suunnitellaan sekä kehitetään järjestelmää ja suunnitellaan ulkoasua sekä olemusta.

Käytettävyyden pikamenetelmät: Kysy tyhmiä kysymyksiä

Olemme rajoittuneita ja jumiutuneita näkökantoihimme. Tyhmien kysymyksien avulla yritetään päästä eroon oletuksista, joita kaikilla on ja kyseenalaistaa itsestään selviä asioita. Kun olet tietoinen oletuksistasi ja miten ne vaikuttavat, voit tehdä tietoisen valinnan siitä luotatko oletuksiisi vai haetko uutta tietoa valintasi taustaksi.

Käytettävyyden pikamenetelmät

Pikamenetelmät perustuvat olemassa oleviin menetelmiin mutta ne on tiivistetty mahdollisimman helposti ja nopeasti toteutettaviksi. Näiden menetelmien avulla voidaan löytää ainakin suurimpia käytettävyysongelmia mutta suositeltavaa on aina käyttää myös täysimittaisia menetelmiä. Lue lisää!

Oletko kypsä suunnittelemaan eläville käyttäjille?

Mistä tiedät kehittyväsi? Mistä tiedät, että kuntosalilla vietetty aika ei ole mennyt hukkaan? Mistä tiedät sovelluksen kehittyvän? Mistä tiedät, että sovellus vie vähemmän taustajärjestelmän resursseja? Mistä tiedät, että toteutetun käyttöliittymäsuunnittelun jälkeinen työ on parempi kuin vanha?

Kuntosalilla vietetyn ajan hyötyjen todentaminen on helppoa. Jos jaksat joka viikko tehdä hieman pidemmän sarjan liikkeitä x, y ja z, tiedät että kehitystä tapahtuu. Sitä kuinka paljon sovellus vie taustajärjestelmän resursseja voi seurata useallakin eri työkalulla. Käyttöliittymän kehittymistä voi tarkastella tekemällä käytettävyystestin sekä vanhalle että uudelle käyttöliittymän versiolle ja vertailemalla tuloksia keskenään.

Sovelluksen käyttäjäkokemuksen kehittymistä voidaan seurata samoilla keinoilla kuin sovelluksen käytettävyyden kehittymistä. Käyttäjäkokemus täytyy kuitenkin suunnitella ja yrityksellä täytyy olla valmiudet käyttäjäkokemuksen suunnitteluun tai toisella nimellä UX-suunnitteluun. Kuinka yrityksen kehittymistä käyttäjäkokemuksen suunnittelun valmiudessa voidaan sitten seurata?

Yksi keino valmiuden seurantaan on Jakob Nielsenin määrittelemä UX-kypsyys, joka kuvaa sitä, kuinka paljon yrityksen prosessit ottavat käyttäjät huomioon kun tuotteita suunnitellaan ja kehitetään. Nielsenin mukaan yrityksen UX-kypsyys jakautuu kahdeksaan vaiheeseen alkaen vaiheesta “paras käyttäjä on kuollut käyttäjä” ja päättyen vaiheeseen, jossa koko organisaatio toimii käyttäjälähtöisesti.

Missä UX-kypsyyden vaiheessa Haltu sitten yrityksenä on? Kuten kaikki muukin käyttäjäkokemukseen liittyen: se riippuu.On projekteja, joissa kehittäjä tekee käyttäjäkokemuksen suunnittelun kehityksen ohessa. Tällöin kyseessä on UX-kypsyyden toinen vaihe, kehittäjäkeskeinen käyttäjäkokemuksen suunnittelu. Kehittäjä on kuitenkin kehittämänsä järjestelmän asiantuntija ja osaa käyttää järjestelmää liian hyvin, eikä siksi vastaa taidoiltaan tavallista käyttäjää.Toisaalta on myös projekteja, joiden perusteella voidaan katsoa UX-kypsyyden olevan Haltulla neljännessä vaiheessa. Neljännessä vaiheessa projektin budjetista osa on allokoitu UX-suunnitteluun. Kokonaisuudessaan suunnitteluun käytettävissä oleva budjetti on yleensä 10–15 % projektin kokonaisbudjetista ja se sisältää sekä UX-, UI- että graafisen suunnittelun. Koska projektin tuntihinta on kiinteä, UX-suunnitteluun käytettävissä oleva aika on riippuvainen projektin kokonaisbudjetista.

Toisen ja neljännen vaiheen väliin jää UX-kypsyyden kolmas vaihe, josta käytetään nimitystä Skunkworks UX, enkä ole vielä keksinyt miten sen kääntää järkevästi. Kyseessä on kuitenkin ilman budjetissa olevaa valtuutusta tehtävä käyttäjäkeskeinen suunnittelu. Ad hoc -testaus on hyvä keino tehdä nopeasti käytettävyystestausta. Esimerkiksi UX-ammattilainen voi käyttää viisitoista minuuttia sovelluksen läpikäyntiin. Kyseessä on nimensä mukaisesti tässä ja nyt tehtävä testaus, ilman sen kummempia suunnitelmia. Ad hoc -testauksen avulla voidaan löytää suurimmat käytettävyysongelmat ja tuloksia voidaan käyttää osoittamaan siirtymisen UX-kypsyyden neljänteen vaiheeseen tuottavan vielä parempia tuloksia.

Onneksi yhdessäkään projektissa ei kuitenkaan olla enää ensimmäisessä vaiheessa ja ajatella kuolleen käyttäjän olevan paras käyttäjä.Tavoitteena on nostaa Haltun UX-kypsyys aluksi kuudenteen vaiheeseen. Kuudennessa vaiheessa yrityksellä on prosessi, jonka mukaan käyttäjäkeskeisen suunnittelun tuloksia seurataan ja prosessi on käytössä jokaisessa projektissa. Se miten tulokset saadaan, on projektikohtaista mutta jokaisessa projektissa käyttäjäkeskeinen suunnittelu on iteratiivista.

Kuinka kuudenteen vaiheeseen sitten päästään? Nielsenin mukaan eteneminen vaiheittain on suositeltavaa pakotetun hyppäyksen sijaan. Hänen mukaansa pakotettu hyppäys aiheuttaa todennäköisesti muutosvastarintaa, koska UX-kypsyyden kasvaessa myös toimintatavat, käsitteet ja vaatimukset muuttuvat. Vaikka Haltulla selvästi on halua olla yritys, joka tuottaa käyttäjäkokemukseltaan loistavia palveluita, en halua että halu tapetaan hukuttamalla työntekijät vaatimuksiin tai kuristamalla heidät toimintatapojen muutoksilla.Siksi etenemme vähitellen. Esimerkiksi koulutusten avulla lisätään tietoisuutta muun muassa siitä, mitä käyttäjäkokemus on, miten sitä suunnitellaan ja kehitetään sekä miten sitä voidaan mitata. Tavoitteena on, että jokainen pystyy tarvittaessa tekemään ad hoc -testausta. Projekteissa tehtävillä UX-katselmoinneilla ohjataan kehitystä kohti parempaa käyttäjäkokemusta. Neljännestä viidenteen vaiheeseen siirtyminen edellyttää selviä tuloksia parantuneen käyttäjäkokemuksen vaikutuksista. Siksi neljännessä vaiheessa käyttäjätestauksen lisääminen on erittäin tärkeää. Käyttäjätestausta pitäisi tehdä mieluummin projektin alkuvaiheessa sen sijaan, että sitä tehtäisiin vasta lähes valmiilla tuotteella.Kuinka kauan tähän kaikkeen sitten kuluu aikaa? Kymmenen vuotta sitten Nielsen arvioi että siirtyminen toisesta vaiheesta seitsemänteen vie noin 20 vuotta ja kuudenteen vaiheeseen noin 13 vuotta.

Nykyisin yleinen käsitys käyttäjäkokemuksesta ja sen vaikutuksista on parantunut, joten asiakkaan vaatimukset ja halu UX-toiminnan kehittymiselle todennäköisesti nopeuttavat siirtymiä kaikissa yrityksissä. Kukaan ei kuitenkaan tarkoituksella suunnittele käyttäjäkokemukseltaan huonoja palveluja.

Tikaskuvan ottaja Jaymantri, kuva Pexels-palvelusta