Sovelluksesi hitain osa voi olla... ihminen.
Kun yritys sanoo, että sen sovellus on hidas, ensimmäinen reaktio on yleensä hyvin tekninen. Täytyy tarkistaa palvelin. Tietokanta. API. SQL-kyselyt. Välimuisti. Infrastruktuuri. Tiedostojen koko. JavaScript. Yksittäisten palvelujen vasteajat.
Ja aivan syystä. Technical performance on erittäin tärkeää.
Mutta joskus kaikki kaaviot näyttävät hyviltä, palvelin vastaa nopeasti, sovellus latautuu kohtuullisessa ajassa, ja käyttäjät sanovat silti: "Tämä kestää liian kauan."
Ja silloin esiin nousee kiinnostavampi kysymys. Ehkä sovellus ei olekaan hidas. Ehkä se vain pakottaa ihmisen odottamaan.
2 sekunnin vasteaika, 20 minuuttia työtä
Kuvitellaan työntekijä, jonka täytyy valmistella tarjous asiakkaalle.
Järjestelmä toimii sujuvasti. Jokainen näkymä avautuu nopeasti. Virheitä ei ole. Palvelin vastaa lähes välittömästi.
Mutta tarjouksen valmistellakseen työntekijän täytyy: avata asiakas, siirtyä tilaukseen, kopioida tuotenumero, avata toinen moduuli, hakea tuote, kirjoittaa tiedot uudelleen, palata ensimmäiseen näkymään, valita kategoria, siirtyä seuraavaan välilehteen, hakea hinnat, tarkistaa alennus käsin, kopioida tulos Exceliin ja kirjoittaa se sitten uudelleen järjestelmään.
Jokainen yksittäinen toimenpide voi kestää muutamia sekunteja.
Teknisesti kaikki toimii hienosti. Mutta koko prosessi vie 20 minuuttia.
Ja juuri tässä perinteinen käsitys suorituskyvystä ei enää riitä.
Sillä käyttäjää ei ensisijaisesti kiinnosta API:n vasteaika. Häntä kiinnostaa tehtävän suorittamiseen kuluva aika.
Technical performance on vasta alku
Järjestelmän suorituskykyä voidaan mitata monella tavalla.
Voimme analysoida palvelimen vasteaikaa, näkymän latausaikaa, tietokantakyselyjä, muistinkäyttöä, prosessorikuormaa tai palvelujen välisiä viiveitä.
Nämä ovat erittäin tärkeitä mittareita. Mutta on olemassa myös toinen taso.
Perceived performance, eli käyttäjän havaitsema suorituskyky.
Ja vielä laajemmin voidaan tarkastella operational performance - eli sitä, kuinka nopeasti ja sujuvasti ihminen pystyy tekemään todellisen tehtävän järjestelmää käyttäen.
Ja juuri tällä viimeisellä tasolla yritykset menettävät usein eniten aikaa. Sillä voidaan rakentaa erittäin nopea sovellus, joka on silti hidas työväline.
Hitain järjestelmä on joskus seitsemän näyttöä
Oletetaan, että työntekijä käsittelee reklamaatiota.
Järjestelmä vaatii seitsemän vaihetta.
Ensin asiakkaan avaamisen.
Sitten tilauksen.
Sen jälkeen tuotteen.
Myöhemmin reklamaatiolomakkeen.
Sitten ongelmakategorian.
Sen jälkeen päätöksen.
Lopuksi vahvistuksen.
Jokainen näkymä latautuu 0,5 sekunnissa.
Kehittäjän näkökulmasta kaikki voi näyttää erittäin hyvältä. Mutta käyttäjä teki seitsemän siirtymää, vaihtoi kontekstia seitsemän kertaa ja joutui seitsemän kertaa miettimään, mitä tehdä seuraavaksi.
Jos tällaisia operaatioita tehdään päivittäin kymmeniä, ongelma lakkaa olemasta mukavuuskysymys. Siitä tulee kustannus. Eikä kyse ole vain ruudun ääressä vietetystä ajasta. Mukana tulevat väsymys, virheiden määrä, tietojen korjaamisen tarve, keskeytyneet tehtävät ja työntekijän kasvava kuormitus.
40 kentän lomake ei ole nopea vain siksi, että se avautuu nopeasti
Tämä on yksi klassisista esimerkeistä.
Lomake avautuu salamannopeasti. - Hienoa.
Mutta käyttäjän täytyy täyttää 40 kenttää.
Osa tiedoista on yrityksellä jo valmiiksi.
Osa voidaan hakea CRM:stä.
Osa voidaan laskea.
Osa riippuu aiemmista vastauksista.
Ja siitä huolimatta järjestelmä kysyy ihmiseltä kaiken uudelleen.
Silloin ongelma ei ole sovelluksen suorituskyky.
Ongelma on prosessin ja käyttöliittymän suunnittelu.
Hyvän järjestelmän pitäisi hyödyntää jo olemassa olevaa dataa.
Jos asiakas antoi toimitusosoitteen aiemmassa tilauksessa, miksi työntekijän pitäisi syöttää se uudelleen? Jos järjestelmä tuntee asiakkaan yrityksen, miksi käyttäjän pitäisi valita sen tiedot uudelleen? Jos ensimmäisen kysymyksen vastaus sulkee pois puolet seuraavista kentistä, miksi kaikki ovat näkyvissä alusta alkaen?
Joskus paras tapa nopeuttaa sovellusta ei ole koodin optimointi. Se on sen työn poistaminen, jota käyttäjän ei pitäisi tehdä.
Kalleinta on ihmisen aika kerrottuna mittakaavalla
Yksi lisäminuutti voi tuntua mitättömältä.
Työntekijä suorittaa operaation 5 kertaa päivässä. - 5 minuuttia.
Kuukauden mittakaavassa siitä kertyy yli 1,5 tuntia.
Mutta entä jos sen tekee 20 henkilöä? Entä jos operaatio toistuu 30 kertaa päivässä? Entä jos se koskee koko osastoa? Entä jos järjestelmää käytetään vielä viiden vuoden ajan?
Silloin yksittäinen minuutti lakkaa olemasta minuutti. Siitä tulee operatiivinen kustannus.
Siksi yritysjärjestelmää suunniteltaessa kannattaa kysyä ei vain: "Kuinka kauan palvelimen vastaus kestää?"
vaan myös: "Kuinka paljon aikaa ihminen tarvitsee tehtävän päättämiseen?"
Nämä ovat kaksi täysin eri kysymystä.
Järjestelmä voi olla nopea, mutta prosessi hidas
Tämä on vielä laajempi ongelma.
Kuvitellaan yrityksen hankintaprosessi.
- Työntekijä tekee hakemuksen.
- Järjestelmä tallentaa sen välittömästi.
- Mutta sitten hänen täytyy odottaa esimiehen hyväksyntää.
- Esimies saa viestin.
- Hän avaa järjestelmän.
- Tarkistaa dokumentin.
- Siirtää sen talousosastolle.
- Talousosasto tarkistaa budjetin.
- Sitten jonkun täytyy hyväksyä tilaus.
Teknisesti sovellus voi toimia täydellisesti. Ja prosessi kestää kolme päivää.
Voimmeko sanoa, että sovellus on nopea?
Teknisesti - ehkä.
Liiketoiminnallisesti - työntekijä odottaa kolme päivää.
Ja juuri siksi liiketoimintajärjestelmien suunnittelu vaatii katsomaan pelkän käyttöliittymän yli. On nähtävä koko työnkulku.
"Odottakaa hetki" on myös osa UX:ää
On vielä yksi kiinnostava tapaus.
Joskus järjestelmä todella suorittaa pitkän operaation.
Se luo raportin.
Käsittelee suuren tiedoston.
Synkronoi tiedot.
Lähettää paljon tietueita ulkoiseen API:in.
Käynnistää monimutkaisen prosessin.
Ei aina ole mahdollista saada sitä kestämään sekuntia. Mutta on mahdollista saada käyttäjä tietämään, mitä tapahtuu.
Se on valtava ero.
Viesti: "Ladataan..."
on jotain aivan muuta kuin: "Valmistellaan raporttia. 72% tiedoista on käsitelty. Voit sulkea ikkunan - raportti valmistuu taustalla."
Toisessa tapauksessa käyttäjä saa tietoa, hallinnan ja ennakoitavuuden.
Juuri tämä on yksi perceived performance -elementeistä.
Järjestelmä voi edelleen suorittaa samaa toimintoa 20 sekunnin ajan. Mutta käyttäjäkokemus on täysin erilainen.
Pahinta on odottaminen ilman tietoa
Ihminen kokee odottamisen paljon huonommin, kun hän ei tiedä, tekeekö järjestelmä ylipäätään mitään.
Klikataan. - Ei mitään.
Klikataan toisen kerran. - Edelleen ei mitään.
Toimiiko järjestelmä?
Onko se jumissa?
Pitääkö päivittää?
Lähetettiinkö lomake?
Voimmeko sulkea ikkunan?
Tässä vaiheessa käyttäjä alkaa taistella sovelluksen kanssa.
Ja kun käyttäjä alkaa taistella järjestelmän kanssa, ilmaantuu uusia ongelmia.
Sivun päivittäminen.
Lomakkeen lähettäminen uudelleen.
Duplikaatit.
Puhelut tukeen.
Virheet.
Tarpeettomat ilmoitukset.
Ja seuraavien ihmisten työaika...
Siksi käyttäjän informointi operaation tilasta ei ole kosmetiikkaa. Se on osa tehokkaan järjestelmän suunnittelua.
Ja joskus sovellus odottaa ihmisen puolesta
Tämä on ehkä kiinnostavin tapaus.
Järjestelmä vaatii, että ihminen tekee toimenpiteen, jonka teknologia voisi tehdä automaattisesti.
Työntekijä hakee tiedot yhdestä järjestelmästä.
Siirtää ne toiseen.
Tarkistaa ehdon.
Kopioi tuloksen.
Lähettää viestin.
Muuttaa tilan.
Odottaa.
Vahvistaa.
Siirtää tiedot eteenpäin.
Ja tekee tätä kymmeniä kertoja päivässä.
Ei ole häiriötä.
Ei ole virhettä.
Järjestelmä toimii oletusten mukaisesti.
Ainoastaan oletukset olivat väärät.
Automaatio ei tarkoita välttämättä tekoälyä.
Joskus suurin automaatio on yksinkertaisesti sitä, että järjestelmät lakkaavat vaatimasta ihmiseltä tiedon manuaalista siirtämistä niiden välillä.
Arkkitehtuurilla on suora vaikutus siihen, kuinka paljon käyttäjä odottaa
Tässä vaiheessa pääsemme teknisiin kysymyksiin.
Jos sovellus koostuu useista palveluista, jokainen kutsu voi aiheuttaa viivettä. Jos järjestelmä hakee joka kerta samat tiedot ulkoisesta API:sta, kannattaa harkita cachea. Jos raportti laskee joka kerta miljoonia rivejä alusta alkaen, tarvitaan ehkä toinen datan generointistrategia. Jos käyttäjän täytyy odottaa operaatiota, jota ei tarvitse suorittaa välittömästi, voidaan harkita asynkronista käsittelyä. Jos useat prosessit tekevät samaa työtä, ongelma voi olla arkkitehtuurissa.
Juuri tässä UX, performance ja software architecture alkavat limittyä toisiinsa.
Suunnittelija näkee käyttäjän ongelman.
Analyytikko näkee prosessin.
Ohjelmoija näkee koodin.
Arkkitehti näkee riippuvuudet.
Hyvän järjestelmän pitäisi yhdistää kaikki neljä näkökulmaa.
Kaikkea ei tarvitse nopeuttaa
Sekin on tärkeää.
Joskus yritys sijoittaa paljon rahaa kerran päivässä tapahtuvan operaation optimointiin.
Sillä välin toinen tehtävä, jonka suorittaa 50 henkilöä kymmeniä kertoja päivässä, jää käytännössä koskemattomaksi.
Siksi ennen optimointia kannattaa tietää: mitä oikeastaan optimoimme ja kenelle?
Ei ole kyse siitä, että jokaisen näytön pitäisi avautua 100 millisekunnissa.
Kyse on siitä, että järjestelmä on nopea siellä, missä nopeudella on liiketoiminnallista merkitystä.
Jos talousraportti voi generoida 15 sekuntia kerran päivässä, se ei ehkä ole ongelma. Jos asiakashaku vastaa 4 sekuntia jokaisella myyjän toiminnolla, tilanne näyttää aivan erilaiselta.
Suorituskykyä pitäisi arvioida toiminnon tiheyden, kriittisyyden ja kustannuksen kontekstissa.
Miten löytää todellinen pullonkaula?
Sen sijaan, että kysytään vain ohjelmoijilta: "Miksi sovellus on hidas?"
kannattaa aloittaa käyttäjistä: "Näytä minulle, miten teet työsi."
Ei: "Mikä on sinulle hankalaa?"
Vain:
"Näytä minulle, miten valmistat tarjouksen."
"Näytä minulle, miten käsittelet reklamaation."
"Näytä minulle, miten syötät uuden asiakkaan."
"Näytä minulle, miten päätät tilauksen."
Ja silloin usein paljastuu asioita, joita koodissa ei näy.
Excel.
Muistio.
Toinen näyttö.
Tietojen kopiointi.
Manuaalinen tarkistaminen.
Puhelut.
Viiden välilehden avaaminen.
Sivun päivittäminen.
Sähköpostin odottaminen.
Kollegalta kysyminen.
Juuri siellä sijaitsee usein todellinen pullonkaula.
Hyvä sovellus ei vain vastaa nopeasti
Hyvä sovellus antaa tehdä työn nopeasti.
Se on hienovarainen, mutta perustavanlaatuinen ero.
Voi olla teknisesti erittäin tehokas sovellus, joka vaatii käyttäjältä toistakymmentä klikkausta. Voi olla kaunis käyttöliittymä, joka piilottaa monimutkaisen prosessin. Voi olla erinomainen arkkitehtuuri, joka ei ratkaise todellista liiketoimintaongelmaa. Ja voi olla järjestelmä, joka ei teknisesti ole suorituskyvyn ennätyksentekijä, mutta jonka avulla työntekijä saa viidessä minuutissa tehtyä jotain, mikä ennen vei puoli tuntia.
Siksi software house ei saisi tarkastella sovellusta vain koodin kautta.
Koodi on väline. Tavoite on sujuvasti toimiva liiketoiminta.
Ennen kuin optimoit palvelimen, mittaa ihminen
Tämä lause kannattaa muistaa.
Jos käyttäjät valittavat, että sovellus on hidas, älä aloita automaattisesti palvelimen tehon lisäämisestä.
Tarkista ensin koko prosessi.
Kuinka kauan tehtävä kestää?
Kuinka monta näyttöä pitää läpikäydä?
Kuinka paljon tietoa käyttäjä syöttää käsin?
Kuinka monta kertaa hän kirjoittaa samat tiedot uudelleen?
Kuinka moneen järjestelmään hänen täytyy vaihtaa?
Kuinka monta kertaa hän odottaa?
Mitä hän odottaa?
Tiedäkö hän, että järjestelmä työskentelee edelleen?
Voiko osa työstä hoitua automaattisesti?
Pyydetäänkö ihmiseltä uudelleen tiedot, jotka meillä jo on?
Vasta sitten kannattaa mennä tasoa alemmas ja tarkistaa API, tietokanta, infrastruktuuri, cache, jonot tai sovelluksen arkkitehtuuri.
Sillä joskus ongelma todella löytyy koodista.
Mutta joskus se löytyy näytön ja tuolin välistä.
Ja silloin paras optimointi ei ole nopeampi palvelin.
On paremmin suunniteltu järjestelmä.
Sovelluksesi hitain osa voi olla ihminen.
Ja hyvän software housen tehtävä ei ole saada ihmistä klikkaamaan nopeammin.
Hyvän software housen tehtävä on saada aikaan se, että hänen tarvitsee klikata vähemmän.
