Asiantuntijatyötä tekevä haluaa, että hänen arviointikykyynsä luotetaan. Daniel Pinkin uusi kirja Drive: The Surprising Truth About What Motivates Us toteaa, että on aika päivittää motivaatiokäsityksemme:

Vanha motivaatiokäsitys: Jos ihmisille antaa vapausasteita, he ryhtyvät välttelemään työtä. Siksi on parasta kontrolloida työsuoritusta ja määrätä ylhäältä käsin oikea etenemistapa.

Uusi motivaatiokäsitys: Autonomia nostaa tuottavuutta ja työtyytyväisyyttä. Oikeaan tehtävään rekrytoidut ihmiset haluavat luontaisesti olla vastuussa tuloksista – itsemääräämisoikeus antaa heille sopivimman tavan päästä noihin tuloksiin.

Ihmiset osaavat erottaa tosistaan rutiinitehtävät ja asiantuntemusta vaativan ytimen. Määrämuotoiset rutiinit ovat kaikille helpotus. Niissä ei tarvita vapausasteita.

Mutta kysymys kuuluukin, pakottavatko tietojärjestelmäsi myös sen varsinaisen asiantuntijatyön tiukasti määrättyyn muotoon ja etenemisjärjestykseen? Vai sallivatko ne tilaa työntekijän autonomialle?

Turhan moni asiantuntijoiden käytössä oleva järjestelmä on raskas käyttää tai sallii vain yhden etenemispolun. Ohjelmiston tekijällä tai tilaajalla on siis ollut vanha motivaatiomalli suunnittelunsa pohjana.

Seurauksena on lauma asiantuntijoita, jotka kiroavat joka päivä käytössään olevia työvälineitä. Ne eivät tue heidän osaamistaan vaan kontrolloivat sitä mekaanisesti. Tämä syö tuottavuutta ja työtyytyväisyyttä.

Kaikki lähtee movaatiokäsityksestämme.

Siispä: Vähemmän raskaskäyttöistä softaa, enemmän autonomiaa.

[* mm. P. Baard, E. Deci, ja R. Ryan, ”Intrinsic Need Satisfaction: A Motivational Basis of Performance and Well-Being in Two Work Settings,” Journal of Applied Social Psychology 34 (2004).]

Nyt Thomas Wailgum kirjoittaa, kuinka rättikauppa löi sormille huonon käyttöliittymän takia. Zappos teki myynnissään 1,6 miljoonaa dollaria tappiota, koska yrityksen henkilöstö ei osannut käyttää monimutkaista hinnoittelutyökalua. Tavaraa myytiin liian halvalla.

Yhtiön pricing engine edellyttää hintojen koodaamista symbolien ja sääntöjen avulla – ja tietysti pari koodirivistöstä puuttuvaa merkkiä veivät hinnat metsään. Selvästikään kukaan ei ollut ajatellut työkalun helppoutta tai yksiselitteisyyttä, saatika varmistusmenettelyä. Työkalun käyttäjät, heidän tarpeensa ja taitotasonsa unohdettiin.

Siinä tuli huonolle käyttöliittymälle hintaa!

Mutta mihin aika liian vaikeiden sovellusten kanssa tuhraantuu? Miksi työ etenee hitaammin kuin olisi mahdollista?

Kuusi syytä:

1. Osaamattomuus: Käyttäjä eri tiedä mitä tehdä, epäröi toimintoja tai tekee asioita ensi kertaa.
2. Järjestelmä ei tue työnkulkua: Erilaisten valikkojen, näkymien, välilehtien ja painikkeiden viidakko sekoittaa käyttäjän. Kun koko tyypillisen työnkulun (kattaa esim. 95% työhön menevästä ajasta) voisi sitoa yhteen näkymään, järjestelmä on kuitenkin rakennettu niin että jokaiselle vaiheelle on oma näkymänsä ja seuraavan vaiheen näkymään ei edes pääse suoraa edellisestä vaiheesta vaan se on etsittävä peruuttamalla ja menuja painelemalla. Tavallisesti edellisen vaiheen tiedot eivät myöskään ole valmiina vaan ne pitää ladata jostain tai syöttää uudelleen.
3. Odottelu: Prosessi kestää, näkymä avautuu hitaasti, käyttäjä katselee tiimalasia ruudulla. Odotusaika on niin lyhyt, että sen aikana ei ehdi tehdä muuta hyödyllistä. Mutta kuitenkin niin pitkä, että käyttäjän ajatus katkeaa ja verenpaine alkaa kohota.
4. Mystiset kentät: Käyttäjä arpoo, missä muodossa ja mitä tietoja hän moniselitteisesti nimikoituihin kenttiin syöttäisi. Syöttää tietenkin väärin ja joutuu jälkikäteen korjailemaan – kunhan ensin keksii, kuinka korjaustoiminto toimii.
5. Tarpeettomat tiedot ja yliprosessointi: Tyhmä järjestelmä ei anna ennakkotietoja tai käyttökontekstin mukaista lähtöoletusta, vaan vaatii käyttäjää syöttämään tai rastittamaan kaiken mahdollisen. Tai tieto on olemassa, mutta ripoteltu pienissä erissä eri näyttöihin. Käyttäjä joutuu turhaan availemaan sulkemaan näyttöjä, vaikka kaiken saisi helposti upotettua yhteen jouhevaan näkymään.
6. Ratkaisu ei tue tehokäyttöä: Joskus DOS-taustainen vanha merkkipohjainen järjestelmä toimii paremmin kuin uusi graafinen lomakehässäkkä, jossa kaiken latailu, rastittelu ja tekeminen vie hillittömän ajan. Järjestelmä pitää rakentaa juuri sen käyttäjiä varten – ja yksi avainkäyttäjäryhmä on tehokäyttäjät. Tämä tuppaa unohtumaan kaiken graafisuuden ja näennäisen helppokäyttöisyyden keskellä.

Mielenkiintoista kyllä, nämä ovat samoja tekijöitä, joita lean-tuotannossa pyritään poistamaan. Sen tavoitteena on nimenomaan minimoida hukka, poistaa odotusaika, poistaa turha, minimoida etsintään käytettävä aika ja lopettaa yliprosessointi. Samat universaalit lainalaisuudet näyttävät siis pätevän mihin tahansa työnkulkuun, aina käyttöliittymistä teollisuus- tai palveluprosesseihin saakka.

Keskity laatuun ja poraudu syvemmälle käyttötapauksiin sellaisten käyttäjien kanssa, joista saat jotain irti. Sovellusten ja käytettävyyden kehitystyö ei voi perustua satunnaiskäyttäjiltä saatuun kyselytietoon.

Selvitä silti tyyppikäyttäjän käyttötilanne ja osaamisen taso. Käytä heitä tarkistaaksesi suuntaa, jonka avainhenkilöt keskusteluissa ja seurannassa antavat.

Olen oppinut, että lähes poikkeuksetta joka organisaatiosta löytyy muutama avainhenkilö, jotka ovat kiinnostuneita kehitettävästä sovelluksesta ja joilla on hyvä tilannetaju: he näkevät, kuinka kyseinen sovellus liittyy laajempaan työprosessiin ja osaavat tehdä työtään sellaisella tasolla, johon muidenkin pitäisi pyrkiä.

Joskus avainhenkilö on se kaikkein hiljaisin käyttäjä. Tein alkuaikoina sen virheen, että kuuntelin liikaa ostajaa/päätöksentekijää (totta kai heitäkin kuuluu kuunnella!) ja liian vähän käyttäjiä. Nyt tiedän, keitä tarvitaan missäkin vaiheessa.

Olen myös oppinut, että avainhenkilöiden kuuntelu on aivan oma taiteenlajinsa:

• Käyttäjä ei yleensä pidä sinusta. Häiritset hänen työtään tai jopa uhkaat sen olemassaoloa. Motivaattoriksi ei riitä se, että pomo käski. Tässä saa joskus käyttää kaiken taitonsa, että yhteistyöhön päästään hyvässä hengessä.
• Mielipiteitä ei juuri kannata kysyä ominaisuuksista, joita vasta suunnitellaan. Harva hahmottaa niitä riittävän tarkasti ennen konkreettista mallia tai prototyyppiä nenänsä edessä.
• Seuraa henkilön työnkulkua kokonaisuudessaan, ei pelkästään tietyn sovelluksen käyttöä. Ylipäätään, seuraa enemmän, kysele vähemmän.
• Älä ohjaa keskustelua liikaa. Kuuntele. Ihmiset kertovat heille tärkeistä asioista. Sitä kautta saat heidät innostumaan. Valmis haastattelurunko ei kuulu pienen käyttäjämäärän sovellusten suunnitteluun.
• Vapauta ideoimaan. Keskustele pienistäkin sivuseikoista, jos ihminen niihin tarttuu. Hänellä on mielipiteitä, joita hän ei mielestään kehtaa tuoda esille, ellei todella tunne, että häntä kuunnellaan.
• Älä yritä miellyttää liikaa. Kun käyttäjä vastustaa keskusteluun tuomiasi uusia näkökulmia, olet jonkin tärkeän asian äärellä (yhdentekevät hän kuittaa olankohautuksella). Käytä tilaisuus myydäksesi uusi ajatus. Se voi hetken hauduttuaan synnyttää isoja oivalluksia, oli ensireaktio miten kielteinen tahansa.
• Kysy, jos et ymmärrä. Käyttäjä ei ymmärrä sinun ammattislangiasi. Sinunkaan ei kannata esittää ymmärtäväsi kaikkea, mitä käyttäjä työstään kertoo. Kysy epäselvät asiat. Uskalla olla tyhmä.

Tällä toimintamallilla olen löytänyt pullonkauloja ja saanut kaivetuksi ideoita, jotka eivät koskaan olisi tulleet esiin, ellen olisi sukeltanut muutamien avainhenkilöiden kanssa tarpeeksi syvälle. Pelkkä tilaajan kanssa keskustelu ja käyttäjille lähetetty kysely eivät olisi tuottaneet lähellekään samaa tulosta.

Käytettävyyshankkeissa määrä ei korvaa laatua.

Kehitämme liiketoimintaohjelmistoa OK Perinnälle. Nyt olemme toteuttaneet myyntiprosessin hallintaa kevyellä asiakastiedolla. Käytettävyydestä ei ollut aikaisemmin pidetty erityistä haloota ja tässä vaiheessa haluttiin lähinnä vähän vilkaista käyttöliittymää.

Näköjään monen IT-talon – joskus harhautuessamme myös eCraftin – ajatusmalli pitää sisällään lomakkeiden ja pop-uppien ihannointia, sillä tämän järjestelmän käyttökokemus oli kuin ihan oikeassa CRM:ssä; useasti toistettavan prosessin läpikäynti vaati kymmenen erillisen lomakkeen aukomista ja turhaa nappien painelua sekä hierarkkisia dropdowneja.

Pop-uppien käytöstä johtuva datan haku, ikkunoiden aukominen, nappien painelu ja seuraavan lomakkeen käyttöön siirtyminen vei varmasti pari sekuntia per pop-up. Onneksi kyse ei kuitenkaan ollut oikeasta CRM:stä, joten käyttöliittymälle on helppo tehdä jotakin.

Kävimme asiakkaan kanssa prosessin läpi ja yhdessä keksimme tavan vähentää lomakkeiden auonta siitä kymmenestä ainoastaan yhteen. Kaiken muun voi tehdä päänäkymässä. Teimme myös roadmappia seuraavaksi tehtäviin käytettävyysparannuksiin.

Muutaman tunnin palaverilla saimme aikaan suunnitelman joka toteutettuna maksaa suunnitteluun menneen ajan takaisin viikossa ja järjestelmää jatkuvasti työssään käyttävien henkilöiden inhimillinen kärsimys varmasti pienenee.

Tämä oli toki harvinaisen otollinen alusta, sillä sovellus oli verrattain helposti muutettavissa, asiakas ymmärsi ketterää kehitystä ja pohjalla oleva perusprosessi oli järkevä.

Se on kuitenkin hyvä esimerkki siitä miten käytettävyyden parantamisen ei tarvitse tarkoittaa mitään käytettävyysprojektia tai organisaatiolinjausta. Joskus se on vain maalaisjärjellä läpikäyty käyttötilanne

Siksi käyttäjätutkimusta tekevien parissa ja eCraftin omassakin blogissa suositellaan käyttäjien tarkkailua. Ajatus on, että seuraamalla käyttäjiä tai asiakkaita todellisissa käyttötilanteissa, saadaan selville todelliset tarpeet.

Tämä on vain osin totta.

Kun uusimme asiakkaan nykyistä tietojärjestelmää, törmään usein niin kökköihin käyttöliittymiin, että käyttötilanteen seurannasta ei ole mitään hyötyä.

Pahempaa, huonosti toteutettu nykyjärjestelmä tai manuaalinen prosessi on saastuttanut ajatukset ja käyttötottumukset niin pahoin, että käyttäjät eivät osaa esittää edes kehitystoiveita muutoin kuin nykyjärjestelmän pikkuparannuksina.

Siinä ei tarkkailu auta. Pitää opettaa.

Olen oppinut, että kaavoihin kangistuneiden käyttäjien kuuntelu tai seuraaminen johtaa vain harhaan. On ymmärrettävä asiakkaan prosessi, ajateltava uudella tavalla ja vakuutettava asiakas uudesta tavasta. Opetettava uusille tavoille.

Siis järjestelmän uusimisprojektissa tai työprosessin siirtämisessä uuteen IT-järjestelmään älä aina seuraa käyttäjien nykytilaa, vaan luo heille järkevä, uusi toimintatapa ja opeta ajattelemaan sen mukaan.

Varsinkaan pienissä projekteissa ei ole tarvetta eikä työpäiviä ryhtyä kikkailemaan käytettävyydellä.

En seuraa jotakin käytettävyysteoriaa. En tee ihmisille testejä. En tarkkaile heitä tekemässä työtään, ellei siihen ole painavaa syytä.

Olen tehnyt ja nähnyt käyttöliittymiä tarpeeksi, jotta tiedän, mikä toimii. Uskon, että sellaisen asiantuntijan asiakaskin haluaa.

Kyllähän näitä norsunluutorneistaan paasaavia user interface experience höpö löpö vuorovaikutussuunnitelma horina jorina -guruja maailmalla riittää. Olen oppinut, että useimmiten kuitenkin riittää, että oma ajatus kulkee ja on nähnyt riittävästi huonoja ratkaisuja, että osaa automaattisesti tehdä järkevän ehdotuksen.

UI-teorioiden taakse on helppo piiloutua. Eikös se vanha sanonta näin mennyt:
Ne tekevät, jotka osaavat. Ne, jotka eivät osaa, opettavat.

Nosta asia tärkeysjärjestyksessä mahdollisimman ylös. Se tapahtuu käyttämällä siihen reilusti omia ja yrityksesi resursseja, suurella intensiteetillä.

Tämä toimii takuuvarmasti. Mutta mitä se tarkoittaa käytännössä?

Jyväskylän yliopiston Liikuntabiologian laitoksella työskentelevä liikuntatieteiden tohtori Juha Hulmi on tehnyt väitöskirjansa lihasmassa kasvuun vaikuttavista tekijöistä. Hulmi kertoi Bodaus-lehdessä (3/2007), kuinka optimaalinen kehittyminen vaatii sekä harjoituspainojen että viikossa suoritetun kokonaistoistomäärän lisäämistä.

Voimaa ja lihasmassaa saa lisää kaavasta:
intensiteetti (harjoituspainon raskaus) x volyymi (toistojen määrä).

Näiden painotukset ovat yksilöllisiä. Jotkut saavat parempia tuloksia pienemmillä painoilla ja suuremmalla toistomäärällä. Jotkut toisinpäin. Mutta vaativaa homma on aina, sillä tutkimusten mukaan alle 60 prosentin kuormat (siis suhteessa maksimikykyysi nostaa rautaa) eivät kasvata lihasta tai voimaa tehokkaasti.

Okei, mutta mitä ihmettä tällä on tekemistä erinomaisen käyttöliittymän kanssa?!

Paljonkin.

Intensiteetti: Kun Applen Steve Jobs saapuu kehitystiiminsä palaveriin nähdäkseen uusimman prototyypin, intensiteetti on huipussaan. Paikalla on yhtiön pääjohtaja, alan elävä legenda, joka on tunnettu siitä, että hän saattaa yhdellä kommentilla huitaista koko proton roskikseen. Täysin riippumatta siihen uhratuista työtunneista. Hänellä on aina viimeinen sana, hän käyttää sen ja hän katsoo tulokset viimeistä pikseliä myöten.

Näiden tapaamisten intensiteetti ei voisi olla kovempi. Rauta painaa, kämmenet hikoavat ja verisuonet pullistuvat. Se puoli yhtälöstä on kunnossa.

Volyymi: Apple ei anna suunnittelutiimilleen volyymissä armoa yhtään enempää. Alain Breillattin artikkeli kertoo, kuinka jokaisen tuotteen jokaisesta ominaisuudesta suunnitellaan kymmenkunta eri versiota. Joka version joka yksityiskohta tehdään täsmälleen vaatimusmäärittelyn mukaan, ei sinnepäin. Applen metodi on valita näistä työläästi kasatuista ehdotuksista kolme jatkoon. Loput armotta heitetään yli laidan. Kolmea jatkoversiota työstetään kuukausia ja niistä valitaan lopulta yksi. Kaksi muuta tapetaan.

Breillattin mukaan jo lähtökohtaoletuskin on, että 90 % työstä kipataan yli laidan. Volyymi on siis hirmuinen. Lopputulosta varten rauta nousee yhä uudestaan ja uudestaan ja uudestaan.

Kun käytettävyys on ykkösenä, se näkyy siihen käyttämiesi resurssien määrässä ja siinä intensiteetissä, jolla työtä teet.

Tuloksena syntyy erinomainen käyttöliittymä.

Vielä tärkeämpää, Applen kyky tehdä entistäkin parempia käyttöliittymiä kasvaa jokaisen harjoituskierroksen jälkeen.

Voimailussa ja kehonrakennuksessa ilmiö tunnetaan nimellä superkompensaatio. Työn rasittama lihas ei pelkästää palaudu levossa entiselle suorituskykytasolle, vaan rasituksen ansiosta lihas pistää vielä vähän suorituskykyä entisen päälle. Lihas siis superkompensoi itsensä entistä vahvemmaksi.

Et voi saada tietojärjestelmällesi tai vaikkapa asiakaspalvelullesi hyvää käytettävyyttä sattumalta. Aivan yhtä vähän kuin voit saada mahtavat hauikset sattumalta.

Intensiteetti kertaa volyymi.

Se on uutta bisneskieltä.

Kun Apple valtaa älypuhelinmarkkinoita, jokainen ymmärtää, että Apple myy intuitiivisuutta ja helppokäyttöisyyttä. Asiakkaat rakastavat sitä. Ja maksavat Applelle markkinoiden ylivoimaisesti kovinta katetta.

Nyt Kallasvuokin puhuu sekä sijoittajille että omalle väelleen käytettävyyden tärkeydestä. Sekä hyppäyttää Nokian kokonaisen käyttöjärjestelmäsukupolven yli, jotta yhtiö voisi tehdä intuitiivisempia käyttöliittymiä.

Intuitiivinen käyttöliittymä nostaa myös sinun tietojärjestelmiesi käyttöastetta ja -tyytyväisyyttä. Tai siis nostaisi, ellet olisi uhrannut sitä funktionaalisuuden alttarille.

Mitä se tarkoittaa? Valtaosa käytössäsi olevista tietojärjestelmistä on funktionaalisia. Ne tekevät jotakin hyödyllistä. Itse asiassa ne tekevät koko joukon asioita. Saat niillä aikaan suurin piirtein sen lopputuloksen, jonka haluatkin. Aivan kuten Nokian matkapuhelimilla.

Mutta ongelma on tämä: järjestelmässäsi on valtavan paljon ominaisuuksia. Funktionaalisuutta siis löytyy vaikka muille jakaa. Mutta järjestelmäsi käyttäjä osaa käyttää vain murto-osaa ominaisuuksista. Pahempaa, hän ei osaa tai voi käyttää edes niitä tärkeitä ominaisuuksia tehokkaasti.

Koska järjestelmäsi eivät ole intuitiivisia. Siis:

• Helppoja – osaat käyttää sitä hetkessä ja ymmärrät mistä löydät lisää tietoa. Homma sujuu kuin ajattelematta. Et tarvitse käyttöohjeita tai kursseja päästäksesi vauhtiin.
• Nopeita – pääset suoraan asiaan ilman kiertoteitä ja pitkiä valikkopolkuja. Kaikki tarvittava tieto on fiksussa esitysmuodossa suoraan edessäsi, eikä piilotettuna pitkin sinne tänne aukeavia välilehtiä.
• Mukavia – käyttö tuntuu niin luonnolliselta, että se tuottaa mielihyvää. Hyvällä työkalulla on aina tämä ominaisuus, olipa kyseessä graafikon Photoshop tai kirvesmiehen luottovasara tai verkottuneen asiantuntijan iPhone.

Mutta eikö ole tietojärjestelmien toimittajien hommaa pistää käytettävyysasiat kuntoon? On toki, mutta aika harva it-firma on asiaan oikeasti perehtynyt. Eivätkä asiakkaat ole osanneet vaatia.

Jos kuulut ylimpään johtoon, olit hyvin todennäköisesti mukana toiminnanohjausjärjestelmäsi tai jonkin muun keskeisen liiketoimintajärjestelmän ohjausryhmässä, kun sitä rakennettiin.

Muistele nyt rehellisesti: Kuinka paljon aikaa käytitte sen päättämiseen, mitä funktionaalisuutta (toiminnallisuutta) järjestelmältä edellytätte? Entä kuinka paljon aikaa käytitte miettiäksenne ja testataksenne käytetettävyyttä, järjestelmän intuitiivisuutta ja käytön mukavuutta?

Aivan.

Seuraukset ovat karut. Sata käyttäjää, jokainen hukkaamassa vaikka vain kaksi minuuttia tunnissa epäintuitiivisen järjestelmäsi syövereihin tarkoitaa vähintään 400 tuntia hukattua työaikaa kuukaudessa! Sinne hurahti parikymmentätuhatta euroa rahaa. Sama toistuu joka kuukausi.

Kova hinta pehmoilun karttamiselle.

Osa asioista ei ylipäätään hahmotu muutoin kuin visuaalisesti.

Siksi tietojärjestelmiesi käyttöliittymä on niin keskeinen asia. Keskikokoinen yritys hukkaa vuodessa helposti jopa tuhansia työtunteja puisevan, vaikeakäyttöisen ja epäinformatiivisen tietojärjestelmänsä syövereihin.

Bisnesjärjestelmäsi on usein suunniteltu raportoinnin tarpeisiin. Ne tuottavat numeroita ja kirjaimia siisteihin sarakkeisiin – muutamalle päättäjälle tai kirjanpitäjälle. Valitettavan harva järjestelmä huomioi ihmisen ja hänen tarpeensa tehdä työtään tehokkaammin. Käyttäjä nähdään vain datan syöttäjänä.

Vielä harvempi järjestelmä osaa yksinkertaistaa tarvittavan tiedon nopeaan ja helppoon muotoon.

Ne, jotka osaavat, perustuvat järjestään tiedon esittämiseen kuvamuodossa. Kuvatieto on tehokas keino tukea ja ohjata käyttäjää.

Suunnittele ensivaikutelma positiiviseksi: Käyttäjä muodostaa yllättävän lopullisen mielikuvan webbisivusta, intranetistä tai toiminnanohjausjärjestelmän ruudusta 50-500 millisekunnissa. (Lähde: Dr. Lindgaard, Carleton University, Kanada)

Ohjaa käyttäjän huomio tärkeimpään: Hyvällä suunnittelulla ohjaat katseen ensin tärkeimpiin asioihin. Et jätä käyttäjää harhailemaan tai arvailemaan. Tuet tärkeintä tai todennäköisintä tehtävää, jota käyttäjä pyrkii suorittamaan. Tämä korostuu sitä enemmän, mitä useampi järjestelmä yhden käyttäjän käytettävänä on. Hänen pitää voida keskittyä työhönsä, ei joka järjestelmän erityispiirteiden opetteluun.

Synnytä oivallus: Paloittele, jaottele ja yhdistele monimutkainen tieto kuvaksi, joka kertoo yhdellä silmäyksellä asioiden väliset suhteet tai mahdolliset etenemissuunnat. Mikä olennaisinta, kuva jää mieleen. Ja se, mikä jää mieleen, vaikuttaa toimintaan. Joten näytä, missä logistiikkaketjusi pullonkaula piilee – sen sijaan, että lyöt pöytään numeroa numeron perään.

Nopeuta omaksumista: Kun kiire painaa päälle, käyttäjä arvostaa graafia, joka kirkastaa olennaisen. Yhtä tärkeää, käyttäjä arvostaa kuvaa, jonka hän voi näyttää kollegalle tai asiakkaalle tietäen, että sillä hän vie viestin tehokkaammin perille kuin pitkillä selityksillä. Anna ihmisille kättä pidempää.

Tämäkin blogipostaus toimisi paremmin visualisoituna!