Jos luulet hyvän suunnittelun olevan kallista, sinun kannattaa tarkastella huonon suunnittelun kustannuksia.
Tri Ralf Speth, Jaguar Land Roverin toimitusjohtaja
Viime vuosikymmenen aikana käyttäjäkokemuksesta on tullut todellinen erottava tekijä hyvien ja loistavien sovellusten välillä.
Ohjelmistojen rakentamisen tekninen puoli on jokseenkin ratkaistu ongelma. Ohjelmistotuotteiden poikkeuksellisen menestyksen todelliset mahdollisuudet piilevät käyttäjäkokemuksessa. Seuraavalla hittisovelluksella tulee olemaan käyttöliittymä, jota voi käyttää välittömästi. Tämä on johtanut tutkimuspohjaiseen, käyttäjäkokemukseen keskittyvään lähestymistapaan tuotekehityksessä.
Tämän keskittymisen tulokset puhuvat puolestaan.
Esimerkiksi jokainen käyttäjäkokemukseen sijoitettu dollari tuottaa 100 dollaria voittoa Forrester Researchin raportin mukaan. Lisäksi tutkimus osoittaa, että kymmenen vuoden ajanjaksolla suunnitteluvetoisten yritysten taloudellinen suorituskyky ylittää S&P:n 219 prosentilla.
On myös legendaarinen tarina siitä, kuinka pelkkä tekstin vaihtaminen yhdessä painikkeessa toi verkkokauppayritykselle 300 miljoonaa dollaria lisää myyntiä yhden vuoden aikana!
Kaikesta tästä hypestä ja hälinästä huolimatta jokaista loistavan käyttäjäkokemuksen tarjoavaa sovellusta kohden on useita sovelluksia, joiden käyttäjäkokemus on puutteellinen tai erittäin puutteellinen. Surkeat sovellukset on helppo tunnistaa: ne saavat sinut haluamaan reiän lyömistä kannettavan tietokoneesi näyttöön tai mobiililaitteesi heittämistä ikkunasta. Darwin huolehtii näistä sovelluksista.
Todellinen haaste ovat sovellukset, joiden käyttäjäkokemus on ihan ok. Ne ovat niitä sananlaskun mukaisia ”tikku mielessä” -kokemuksia, joiden kohdalla et millään pysty keksimään, miksi et pidä niistä!
Kuulen sinun sanovan: ”Tiedämme tämän kaiken; luen The QA Leadia, hyvänen aika, joten mitä tekemistä tällä on minun kanssani?” Palaan siihen kohta.
Käyttäjäkokemuksen merkitys
Johtaessani urani alkuvaiheessa insinööritiimejä työskentelimme suuren ohjelmistoratkaisuprojektin parissa yhdelle asiakkaistamme. Se oli osa laajempaa digitaalisen transformaation strategiaa, jota kyseiselle asiakkaalle toteutettiin. Kyseessä oli tyypillinen insinööritiimi, joka koostui pääasiassa ohjelmistokehittäjistä ja laadunvarmistusinsinööreistä ja käytti Scrumia kahden viikon sprinteissä.
Tiimissä oli pieni käyttäjäkokemustiimi, mutta suurimmaksi osaksi se työskenteli useiden projektien parissa. Tyypillisesti käyttäjäkokemuksen asiantuntijat osallistuivat tiimin päivittäisiin kokouksiin projektin alkuvaiheessa, mutta kun asiakas oli hyväksynyt visuaalisen suunnittelun, he luovuttivat kaikki visuaalisen suunnittelun mallit sekä työnkulut ja siirtyivät työskentelemään muiden projektien parissa.
Ensimmäisen sprinttiesittelyn aikana asiakasta näytti huolestuttavan ensisijaisesti se, etteivät visuaalinen suunnittelu ja käyttöliittymä vastanneet täsmälleen suunnittelumalleja. Myös ehdotetun toiminnallisuuden ja tosiasiassa toteutetun toiminnallisuuden välillä oli kuilu.
Huomaa, ettei kuilu ollut suuri, mutta vaikka yritimme kuinka vakuuttaa asiakkaalle, että käyttäjäkokemukseen liittyvät asiat korjattaisiin myöhemmissä sprinteissä, hänen kehonkielensä osoitti, ettei hän ollut tyytyväinen tilanteeseen.
Onneksi tiimimme laadunvarmistusvastaava käytti puheenvuoron, sanoi tämän olevan poikkeama ja ettei se tapahtuisi uudelleen. Sitten hän teki jotain hämmästyttävää. Käyn sen tässä läpi:
- Hän päätti itse perehtyä käyttäjäkokemukseen lukemalla aiheesta perusteellisesti.
- Sen jälkeen hän teki itse toimitetulle toiminnallisuudelle perustason käyttäjäkokemuksen heuristisen arvioinnin, keskusteli käyttäjäkokemuksen asiantuntijoiden kanssa ja pyysi heiltä apua tarvittaessa.
- Hän loi JIRAan uusia tehtäviä korjatakseen sen eron, mitä oli luvattu ja mitä toimitettiin – käyttäjäkokemuksen näkökulmasta.
- Hän järjesti puhelun käyttäjäkokemuksesta vastaavan johtajamme kanssa ja sai tämän hyväksynnän uudelle prosessille, jossa sovelluksen visuaaliset näkökohdat korjattiin jokaisen sprintin aikana eikä vasta lopussa.
- Lopuksi hän perehdytti myös laadunvarmistusasiantuntijamme käyttäjäkokemuksen perusteisiin, jotta he pystyisivät havaitsemaan räikeät ongelmat ja auttamaan tiimiä ratkaisemaan ne varhaisessa vaiheessa.
Kuorrutus kakun päällä? Seuraavassa sprinttiesittelyssä tuotteen omistaja/asiakas hymyili leveästi, ja muutaman kuukauden kuluttua laadunvarmistusvastaavamme ylennettiin laadunvarmistuspäälliköksi! 😉
Romanttiset ja klassiset näkökulmat todellisuuteen
Tämä koko tapahtumasarja sai minut pohtimaan valtavaa eroa siinä, miten me insinöörit näemme sovelluksen ja miten asiakkaat ja käyttäjät näkevät sen. Robert Pirsig käsittelee klassisessa kirjassaan Zen ja moottoripyörän kunnossapidon taito kahta näkökulmaa todellisuuteen: klassista ja romanttista.
Pirsigin mukaan ne, joiden hallitseva näkökulma on romanttinen, tarkastelevat asioita ja arvioivat niitä sen perusteella, miltä ne näyttävät. He ovat ensisijaisesti kiinnostuneita siitä, millaisia asiat ovat, eivätkä välitä siitä, miten ne toimivat – taustalla olevasta järjestyksestä. Tämä on taiteen ja tieteen välisen jaon taiteellinen puoli.
Toisaalta me insinöörit & tiedemiehet kannatamme klassista näkökulmaa, jossa kauneus piilee ulkoisen muodon taustalla olevissa mekanismeissa. Insinöörit voivat nähdä kauneutta Python-koodissa tai auton konepellin alla olevissa rakenteissa, mikä näyttää romanttisen näkökulman kannattajista rumalta.
Kuten kaikki muukin, tämä ei tietenkään ole kaksijakoinen luokittelu, vaan jatkumo, jossa useimmat meistä suosivat hallitsevasti jompaakumpaa näkökulmaa.
Tällä tavalla maailman luokittelulla on kiinnostavia seurauksia:
1. Useimpien ihmisten hallitseva näkökulma on oletusarvoisesti joko klassinen tai romanttinen, ei molempia.
2. Romanttisen näkökulman omaavia ihmisiä – ajatellaanpa asiakkaita, olivatpa he sisäisiä tai ulkoisia – on ylivoimaisesti enemmän kuin klassisen näkökulman omaavia. Jos olet joskus joutunut toimimaan perheen ja ystävien teknisenä tukihenkilönä, tiedät, mitä tarkoitan!
3. Hyvin harvat pystyvät vaihtamaan näkökulmaa, ja heillekin se on ponnistelua vaativa tehtävä.
4. Todellisuus = klassinen + romanttinen. Ne eivät sulje toisiaan pois. Molemmat ovat kokonaisuuden olennaisia puolia. Kauneus on toiminnallista. Toiminta voi olla kaunista.
Otetaan esimerkiksi kukat. Niissä on upeita kuvioita, joilla ei näytä olevan mitään tehtävää. Silti kukissa näkemämme kauneus perustuu matematiikkaan juurtuvaan taustarakenteeseen: Fibonaccin lukujono ohjaa kukissa näkemiämme rakenteita ja kuvioita. Rakenne ja eteerinen kauneus kulkevat luonnossa käsi kädessä.
Eikä kyse ole vain kauneudesta. Auringonkukan siementen sijoittelu noudattaa Fibonaccin lukujonoa ja kultaista leikkausta, jotta kukkaan saadaan mahtumaan mahdollisimman suuri määrä siemeniä. Samat periaatteet pätevät suunnitteluun ja käyttäjäkokemukseen.
Tämä johdattaa meidät vihdoin tämän artikkelin ytimeen: laadunvarmistuksen ammattilaisilla on ihanteelliset edellytykset hyödyntää näitä kahta näennäisesti kilpailevaa näkökulmaa.
Have an account? Log In
Ohjelmistojen laadunvarmistuksen rooli UX:ssä ja käytettävyydessä
Testauksen ammattilaisena sinulla on ollut paljon enemmän kokemusta käyttöliittymistä kuin keskivertokehittäjällä tai -käyttäjällä.
Olet testannut niin monia sovelluksia järjestelmällisesti ja toistuvasti (kyllästymiseen asti!), että olet saattanut saavuttaa korkeamman tason eli 4D-ajattelun UX:n suhteen – kuten tarunomainen shakin suurmestari, joka ajattelee asemien kautta, toisin kuin allekirjoittanut, joka yrittää epätoivoisesti selvittää, mitä nappulaa pitäisi siirtää seuraavaksi! ;-)
Siksi, huolimatta voimakkaasta siirtymisestä kohti automatisointia – joka on epäilemättä hieno kehitysaskel – myös jonkin verran manuaaliselle testaukselle on paikkansa. Jos ihmiset tulevat käyttämään sovellusta, onhan järkevää sisällyttää testaukseen myös ihmisen näkökulma.
Näin testausinsinööri tekee UX- ja käytettävyyskatselmuksen
Jos laadunvarmistuksessa on otettava UX huomioon, sen on alettava suunnitteluvaiheen rinnalla eli elinkaaren alussa. Näin voit sisällyttää UX-katselmuksen testaukseesi ja kehittyä laadunvarmistuksen moniosaajaksi!
Käyttöliittymäsuunnittelun käytettävyysheuristiikat
Tutustu Jakob Nielsenin kymmeneen vuorovaikutussuunnittelun yleiseen periaatteeseen. Nämä ohjeet ovat luotettava viitekehys kaikkiin käytettävyyskatselmuksiin. Ota nämä periaatteet huomioon keskusteluissa UX-tiimin kanssa sekä testisuunnitelmassasi. Voit myös tutustua mihin tahansa peruskursseista, jotka käsittelevät käytettävyyttä ja UX-suunnittelua.
Opettele saavutettavuuden periaatteet
Olet ehkä tehnyt saavutettavuustestausta osana testisuunnitelmaasi aiemmin, mutta saavutettavuuden taustalla olevien periaatteiden – havaittavuuden, hallittavuuden, ymmärrettävyyden ja vankkuuden – ymmärtäminen antaa sinulle valmiudet huomata asioita, jotka muut saattavat jättää huomaamatta.
UX-tiimi on uusi hengailupaikkasi
Älä jää ulkopuoliseksi: tutustu projektin UX-tiimiin. Tee yhteistyötä heidän kanssaan. Jaa testisuunnitelmasi heidän kanssaan ja pyydä palautetta siitä, mitä voit sisällyttää suunnitelmaan UX:n näkökulmasta.
Tämän vuorovaikutuksen hyödyt ovat kaksisuuntaisia, sillä testisuunnitelmasi antaa suunnittelutiimille tietoa heidän ehdottamiensa suunnitteluominaisuuksien toteutettavuudesta. QA-vastaavana vuorovaikutuksesi UX-tiimin kanssa on oltava yhtä tiivistä kuin kehittäjien kanssa.
Sisällytä analytiikka testisuunnitelmaasi
Testaamasi tuotteen käyttäjäanalytiikka on testaajille tiedon kultakaivos. Analytiikan avulla voit tunnistaa riskialueita ja käyttäjien toimintatapoja. Näiden tietojen avulla voit puolestaan tunnistaa ja priorisoida korjaukset mahdollisimman varhaisessa vaiheessa tuotteen elinkaarta.
Siirrä testausta vasemmalle, kunnes et voi siirtää sitä enempää
Testaamasi tuote on kuin vauva. Sinun on varmistettava, että se saa tarvitsemansa tuen heti tuotteen suunnittelusta lähtien. Aloita aivan alusta.
Ennen kehitysvaihetta
Testaa suunnitteluvaiheessa heti, kun prototyyppi on valmis. Hyödynnä sovelluksista saamaasi kokemusta sekä käytettävyysperiaatteiden ja saavutettavuusohjeiden tuntemustasi tarkistaaksesi, tarvitseeko jotain muuttaa ENNEN kuin tuote siirtyy kehitysvaiheeseen.
Jos QA ei vielä kuulu suunnitteluvaiheeseen, ota se mukaan, jos mahdollista.
More Articles
Kohdennettu manuaalinen testaus
Käy manuaalisen testauksen osana läpi koko tuotteen käyttökokemus alusta loppuun. Keskity esittämään oikeita kysymyksiä ja ajattele sekä käyttäjän että QA-insinöörin tavoin.
Aloita ottamalla askel taaksepäin ja tarkastelemalla tuotetta laajemmasta näkökulmasta. Nautitko käyttökokemuksesta?
Katso sitten tarkemmin. Onko tuotetta helppo käyttää? Ovatko käyttöpolut selkeitä ja intuitiivisia? Ovatko ne työläitä ja hitaita? Sisältävätkö ne toimintojen päällekkäisyyksiä tai toistoa, jotka saattavat ärsyttää käyttäjää? Onko suunnittelu käytettävä erikokoisilla näytöillä?
Lopuksi
Työn tulevaisuus kuuluu niille, joilla on useita toisiaan täydentäviä taitokokonaisuuksia, joita koneiden on lähes mahdotonta ottaa hoitaakseen (mutta tutustu artikkeliini aiheesta tekoäly testiautomaatiossa saadaksesi käsityksen siitä, mihin ne pystyvät).
UX-taitoja omaavaksi QA-moniosaajaksi kehittyminen voi olla erinomainen tapa hyödyntää luontaisia kykyjäsi ja kokemustasi, tuottaa paljon lisäarvoa ilman liiallista vaivannäköä tai liian kauas ydinalalta poikkeamista.
Innostaako tämä sinua? Vai ajatteletko, että UX liittyy tähän alaan vain sivujuonteena? Kerro mielipiteesi alla olevissa kommenteissa.
Jos olet valmis oppimaan lisää, tässä on podcast, jonka voit lukea tai kuunnella: MITEN AVOIMEN LÄHDEKOODIN OHJELMISTOT YKSINKERTAISTAVAT AUTOMAATIOINSINÖÖRITYKSEN INTEGRAATIOTA (JAMES WALKERIN JA SANJAY KUMARIN KANSSA)
