Käytännön käytettävyysvihje: hanki oikeaa ulkopuolista näkemystä

Käyttöliittymäsuunnittelussa - niinkuin monessa muussakin asiassa - sokaistuu helposti omaan tekemiseensä.  Sokaistumista tapahtuu yksilöillä mutta myös firmankin tasolla. Sen vuoksi ulkopuolinen näkemys käyttöliittymäratkaisuihin on tarpeellista.

Ulkopuolista näkemystä käytettävyyteen saa kahdella päämenetelmällä: 

1. ulkopuolisen käytettävyysasiantuntijan tekemä asiantuntija-arviointi
2. käytettävyystestaus (käyttöliittymän testaus loppukäyttäjillä)

Näistä käytettävyystestaus (2) on ehkä se perusratkaisu, mutta esimerkiksi itse olen tehnyt paljon asiantuntija-arviointeja (1). Ja oma kokemukseni on, että asiantuntija-arvioinnit ovat olleet useimmissa tapauksissa parempi ratkaisu kuin käytettävyystestaus:

• Asiantuntijan läpikäynti on nopeampi ja edullisempi kuin käytettävyystestaus
• Asiantuntija pystyy katsomaan järjestelmän läpi kattavammin ja analyyttisemmin
• Asiantuntija-arvion pystyy tekemään hyvinkin varhaisessa vaiheessa käyttöliittymäsuunnittelua

On selvää, että asiantuntija-arvioinnin laatu riippuu hyvin voimakkaasti arvioijasta. Mutta sama ilmiö on havaittu myös käytettävyystestauksen suhteen: testien laatu riippu voimaakkaasti siitä, kuka tekee testit (ks. CUE-tutkimukset). Tutkimustulokset ovat osittain ristiriitaisia menetelmien laadun suhteen.

Käytettävyystestaus on kuitenkin menetelmä, jota olisi sitten jossain välissä syytä käyttää. Mutta mielestäni liian usein sen käyttöön syöksytään liian epäkypsillä suunnitteluratkaisuilla.

Ulkopuolinen näkemys kannattaa hankkia mahdollisimman varhaisessa vaiheessa. Mielellään jo ennenkuin toteutus alkaa. Mitä pitemmälle arviointia lykätään, sitä työläämmäksi tulee mahdollisten muutosten tekeminen.

Ja vielä varoitus parista sudenkuopasta:

• Käyttöliittymän katselmointi asiakkaan kanssa ei ole tuloksellinen käytettävyyden arviointimenetelmä. On ihan eri asia tehdä käytettävyystestaus (= laittaa käyttäjät käyttämään järjestelmän protoa) kuin käydä läpi käyttöliittymäratkaisuja neuvottelussa asiakkaan kanssa. 
• Järjestelmän koekäyttö käyttäjillä ei niin, että käyttäjät antavat palautetta, ei ole sama kuin käytettävyystestaus. Käytettävyystestaus perustuu testaajien (käytettävyysasiantuntija, suunnittelutiimi tms.) jäsentämään arviointiin käyttäjien suoritumisesta. Käyttäjien antama palaute perustuu taas käyttäjien omaan jäsennykseen. Näissä on suuri ero.  

----------------------------------------------------------------

Tämä on viimeinen kirjoituksen tähän blogiin CreaBase-projektin puitteissa  - projektihan päättyy tänään 31.8.2011. Voi olla, että en jatka juuri tämän blogin kirjoittelua - riippuu siitä, missä määrin nimenomaan mobiilikäyttöliittymäasiat ovat itselläni tapetilla. Osahan tämänkin blogin kirjoituksista ovat yleisempiä, niinkuin nämä viimeiset kirjoitukset. 

Tarkoitukseni on kuitenkin jatkaa kirjoittelua ainakin kahteen muuhun blogiin: 

• Käytettävyysnavigoija -blogi, jossa keskityn yleiseisiin käytettävyysasioihin
• Hanki käytettävyyttä -blogi, joka käsittelee käytettävyyden varmistamista järjestelmien kilpailutuksessa ja hankinnassa (esimerkiksi kun hankitaan terveydenhuollon järjestelmiä)

Olet tietenkin tervetullut seuraamaan mielenkiintosi mukaan näitäkin blogeja!

Käytännön käytettävyysvihje: mieti mittareita

Miten paljon käytettävyyteen kannattaa panosta? Miten ohjata käyttöliittymän suunnittelua oikeaan suuntaan?

Kehitysprojektin aluksi kannattaa miettiä sitä, mitä vaikuttavuutta käytettävyydellä halutaan, ja määrittää vaikuttavuudelle mittarit ja tavoitetasot.

Mitä käytettävyyden vaikuttavuus tarkoittaa? Otetaan esimerkki:

• Eräässä julkisessa virastossa tilanne on se, että virkailijoiden aikaa kuluu aivan turhan paljon siihen, että joutuvat vastaamaan asiakkaiden "turhiin" puheluihin. Näissä "turhissa" puheluissa asiakkaat kysyvät, miten täytetään erilaisia lomakkeita, mitä tietoja tarvitaan eri hakemusten tekemiseen jne.
• Kaikki nuo asiat periaatteessa ovat tällä hetkellä viraston verkkopalvelussa, mutta se vain ei toimi käyttäjien kannalta. Kyseessä siis puhtaasti käytettävyysongelma. 
• Nyt kun järjestelmää uudistetaan, niin yhdeksi käytettävyyden vaikuttavuustavoitteeksi määritettiin asiakkaiden "turhien" puheluiden määrän radikaali pienentäminen: 90% vähemmän puheluita kuin mikä on nykytilanne
• Eli mittari on "turhien puheluiden lukumäärä", ja tavoitetaso on 90% vähennys puheluihin

Tämä esimerkki kertonee sen, että käytettävyyden vaikuttavuus on aina sovelluskohtainen liiketoiminta-asia (tuskin ylläolevan esimerkin mittari ja tavoitetaso pätevät kaikille järjestelmille tai tuotteille...).

Kunkin tuotteen tai järjestelmän kohdalla pitää siis erikseen miettiä ja päättää, mitä merkittävää vaikuttavuutta käytettäävyydellä voidaan  saavuttaa omassa sovelluksessa tai tuotteessa. Seuraavassa tyypillisiä käytettävyyden vaikuttavuusnäkökulmia:

• järjestelmän käyttöönoton sujuvuus
• oppimisaika
• käyttäjän työn tai tehtävien suorittamisaika
• järjestelmän hyväksyttävyys
• käyttökoulutuksen tarve (missä määrin tarvitaan)
• käyttäjädokumentaation määrää 
• käyttäjätyytyväisyys
• käyttäjätuen tarve 
• käyttäjät tekemien virheiden määrä
• jälleenmyyjien ja edustajien koulutuksen tarve

Käytännön käytettävyysvihje: vältä turhat mokat

Käyttöliittymissä näkyy niin paljon turhia mokia. Esimerkiksi alla oleva vähintääkin hämmentävä ("yksikäsitteisyysrajoitusten") virheilmoitus. Tällaisia kun olisi helppo välttää.

Ja se vinkki tähän on ehkä vähän tylsä: lukeminen. 

• Aiemmin kirjoittelin ISO 9241 -standardista. Sen eri osista löytyy lukuisa määrä ohjeita hyvistä suunnittelukäytännöistä. Ks. aiemmat kirjoitukset. 
• Konkreettinen ja helppolukuinen opas on Jeff Johnsonin GUI Bloopers. Englanninkielinen kirja, ja pitää tietenkin ostaa. On hauska, ja kuvaa monin esimerkein "käyttöliittymätöppäyksiä" ("blooper"), ja antaa ehdotuksia paremmiksi ratkaisuiksi
• Jos suunnittelee verkkosivuja, niin hyvä ja ilmainen opas on Research-Based Web Design and Usability Guidelines. Englanninkielinen, mutta helppolukuinen ja konkreettinen, käytetty paljon kuvia. Ja siis ilmaiseksi verkosta ladattavissa
• Edelleen verkkosivumaailmaan liittyen tunnettu, hauska ja myös tiivis kirja on Steve Krugin Don't make me think. Jo tuo kirjan nimi on mielestäni yksi verkkosivujen - ja myös laajemminkin käyttöliittymien - perusohjeita. Siis "älä pane käyttäjää pähkäilemään". Alla on esimerkki esimerkki dialogista, joka kyllä laittaa pähkäilemään: (siis mikä tuo rengastettu dialogi on?) 

Tällaisten ohjeiden tunteminen lisää käyttöliittymien laatua ja käytettävyyttä - ei tule turhia mokia. 

Mutta tulee muistaa, että tällaisten ohjeiden noudattaminen ei vielä takaa hyvää käytettävyyttä. Ja miksi? Koska hyvä käytettävyys on viime kädessä käyttäjien työn ja tehtävien tukemista. Ja tämän näkökulman suunnittelu on aina sovelluskohtaista, johon yleiset ohjeet eivät tietenkään voi antaa konkreettisia suunnitteluohjeita. 

Käytännön käytettävyysvihje: käyttäjähaastattelut

Tee käyttäjähaastatteluja niin, että opit ymmärtämään käyttäjien työn

Tässä alkaa CreaBase-projekti päättyä. Voi olla, että senkin jälkeen kirjoittelen tähän blogiin jotain.

Mutta ajattelen kirjoittaa tähän lopuksi muutamia käytännön vihjeitä, jotka haluaisin nostaa keskeisinä "vinkkeinä" käyttöliittymäsuunnittelussa.

Ja aloitan siitä, että käyttöliittymäsuunnittelun perustaksi tulisi ymmärtää käyttäjän työ.

Käytettävyys on käyttäjän työn tukemista, ja hyvä järjestelmä/ tuote on siis sellainen, joka tukee käyttäjän työtä. Sen vuoksi käyttäjän työn tunteminen on ensiarvoisen tärkeää.

Se, miten minä olen pyrkinyt ymmärtämään käyttäjän työtä, on käyttäjien haastattelut seuraavilla periaatteilla:

• Haastatellaan siis siinä mielessä, että oppii aidosti ymmärtämään käyttäjän työn
• Tässä tulee ymmärtää se, että käyttäjät eivät monestikaan osaa jäsentää työtään ja pukea ajatuksiaan selkeästi. Kyse ei ole siis siitä, että haastatellaan ja kirjataan käyttäjien sanomisia ylös
• Ydin on se, että opit ymmärtämään työn. Itselläni on useinkin käynyt niin, että tällaisessa haastattelutilanteessa itse käyttäjäkin on oppinut omasta työstään sellaista, mitä ei ole itse jäsentänyt aiemmin
• Tee tarkentavia kysymyksiä, tulkintoja jne. 

Käyttäjän työn ymmärtäminen antaa perustaa myös käyttöliittymää syvemmille asioille, kuten tietorakenteen suunnittelulle. Ks. http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html.

Tiedän, että yllä oleva selitys haastatteluista ei ole tyhjentävä "resepti". Mielestäni sellaista ei voi antaakaan, koska kyse on ymmärtämisestä, haastattelijan oivalluksiin perustuvasta jäsennys- ja ajattelutyöstä. Mutta ehkä tuo antaa idean siitä, mistä on kysymys.

Toinen tapa ymmärtää käyttäjien työtä on käyttäjien työn havainnointi (kutsutaan engl. contextual inquiry). Tämä on periaatteessa vahvempi tapa; siinähän ollaan kentällä. Ja periaatteessa myös ehdottomasti suositeltava. Ongelmana kuitenkin se, että havainnointi vaatii enemmän resursseja. Itse lähtisin aina ensi haastatteluista. (tai itse asiassa ihan ensiksi luen saatavilla olevat dokumentit, jotta haastatteluihin menisi mahdollisimman hyvällä taustatietämyksellä).

"Järjestelmän on oltava helppokäyttöinen" - vaatimus, jolla ei merkitystä

Kirjoittelen kyseisestä aiheesta "Hanki käytettävyyttä" -blogissa: http://hankikaytettavyytta.blogspot.com/2011/08/jarjestelman-on-oltava-helppokayttoinen.html. Ja totean, että jokainen järjestelmä täyttää vaatimuksen "järjestelmän on oltava helppokäyttöinen". 


Tämä aihe on herättänyt myös muutaman kommentin.

muutama käytettävyysongelmaharjoite

ks: http://kaytettavyysnavigoija.blogspot.com/2011/08/muutama-kaytettavyysharjoite.html

Ehdottakaapa ratkaisuja!

Ohjeita lomakkeiden suunnitteluun: ISO 9241-17

Tässä on jo ollut muutama kirjoitus standardeista. Mutta otetaan vielä tämä. 

ISO 9241-17 sisältää ohjeita useissa järjestelmässä hyvin keskeiseen osa-alueeseen, lomakkeiden suunnitteluun.  Ohjeita annetaan neljässä kategoriassa 

• Lomakkeen täyttörakenne: annetaan ohjeita liittyen otsikointiin, visuaaliseen koodaukseen, näytön täyttämiseen, käyttäjäohjeisiin, lomakkeen layoutiin, kenttiin ja nimikkeisiin
• Syötteen huomiointi: annetaan ohjeita  monien yksityiskohtien kuten kursorin liikkumisen, tekstin syötön, oletusarvojen, aakkosnumeerisen tekstin syötön, valintojen, valikoiden, luetteloiden, painikkeiden, valintojen, syötön korjauksen, virheiden käsittelyn, tietojen uudelleensyötön ja kenttien validoinnin suunnitteluun
• Palaute: annetaan ohjeita syötteen kaiuttamisen, kursorin ja osoittimien näyttämisen, virhesyöttöjen ja tietokantamuutosten näyttämisen suunnitteluun
• Navigointi: annetaan ohjeita kursorin oletussijainnin, kenttien välisen liikkumisen, tabuloinnin, vierittämisen ja lomakkeen valinnan suunnitteluun

Esimerkkinä ohjeet asioihin, joissa yllättävän paljon näkee puutteita: 

• pakolliset ja valinnaiset syöttökentät tulisi esittää siten, että kuka tahansa käyttäjä erottaa ne välittömästi toisistaan
• kun lomaketta näytetään ensimmäisen kerran, kursorin tulisi olla automaattisesti kentässä, jonka käyttäjän joutuu tai mahdollisesti täyttää ensimmäiseksi.  

Vähän tarkempaa tietoa artikkelissa  http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Ja vielä tarkempaa itse kyseisessä standardin osassa. 

ISO 9241-14: ohjeita valikkojen suunnitteluun

ISO 9241-14 antaa ohjeita valikkojen rakenteen, navigoinnin, valinnan ja esitystavan suunnitteluun. 
Jos tehtävääsi kuuluu valikkojen suunnittelu, niin 9241-14 sisältää ohjeita tähän:   

• Valikkojen rakenne: annetaan ohjeita valikon valintojen ryhmittelyyn ja valintojen järjestykseen
• Valikossa navigointi: annetaan ohjeita navigointivihjeiden käyttöön sekä pikanavigointiin 
• Valinnan tekeminen: annetaan ohjeita valintatapoihin, näppäimistön käyttöön, kursorin käyttöön, osoittamiseen, sekä myös ääniohjaukseen.  
• Valikon esitystapa: annetaan ohjeita valinnan havaitsemiseen, valikkoihin liittyvään sijoitteluun sekä niin tekstivalinnan, graafisen valinnan kuin äänivalinnan rakenteeseen ja syntaksiin. 

Vähän tarkempaa tietoa artikkelissa  http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Ja vielä tarkempaa itse kyseisessä standardin osassa. 


Ja kommentti näistä standardeista yleensä. Oman subjektiivisen käsitykseni voisin ilmaista vaikka siten, että kun on nähnyt kaikenlaisia käyttöliittymäratkaisuja, niin on tullut mieleen, että olisipa tuonkin suunnittelija lukenut jos ei muuta niin edes noita standardeja... 
Standardit eivät ole ehkä varsinaisia lukuelämyksiä.  Mutta ne kuitenkin perustuvat monien kansainvälisten ammattilaisten kumuloituneeseen tietämykseen ja osaamiseen. 

ISO 9241-13: ohjeita käyttäjä opastamiseen käyttöliittymässä

ISO 9241-13 sisältää ohjeita liittyen sanalliseen muotoiluun, kehotteisiin, palautteen antamiseen, virheen hallintaan, tilatietoon ja on-line ohjeisiin. 

• Yleiset ohjeet: esimerkiksi ohje, että käyttäjäohjeiden tulisi erottua muusta näytössä olevasta tiedosta 
• Sanallinen muotoilu: annetaan ohjeita sille, miten tekstiä tulisi muotoilla; esimerkiksi ohje, että ohjeviestin tulisi ilmaista käyttäjän eikä järjestelmän kontrollia. 
• Kehotteet: annetaan ohjeita sen ilmaisulle, miten järjestelmä on valmis vastaanottamaan käyttäjän syötteen 
• Palautteet: annetaan ohjeita, miten järjestelmän tulisi antaa palautetta käyttäjälle; esimerkiksi ohje siitä, että järjestelmän tulisi antaa vasteen jokaiseen käyttäjän syötteeseen
• Tilatieto: annetaan ohjeita, miten ilmaista tietoa järjestelmän tai 
• vuorovaikutuselementin tilasta; Esimerkkinä ohje siitä, että olisi käytettävä näytön 
(ikkunan) vakiopaikkaa kunkin tyyppiselle tilatiedolle
• Virheenhallinta: esimerkiksi ohje, että virheviestien tulisi kertoa mikä meni väärin, mitä korjaavia toimenpiteitä käyttäjä voi tehdä ja mikä oli virheen syy
• On-line ohjeet: esimerkiksi  olisi annettava 
• tehtävään liittyvää tietoa järjestelmästä ja sen tarkoituksesta

Vähän tarkempaa tietoa artikkelissa  http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Ja vielä tarkempaa itse standardissa.

ISO 9241-12 kertoo, miten esittää erityyppisiä tietoja käyttöliittymässä

ISO 9241-12 antaa perusohjeet käyttöliittymässä näkyvän tiedon suunnitteluun, sijoitteluun ja koodaukseen

ISO 9241-12 sisältää ohjeita tiedon esittämisen suunnitteluun käyttöliittymissä:

• Tiedon sijoittelu ja organisointi: ohjeita ikkunoiden ja alueiden, syöte- ja tulostealueiden, ryhmien, luetteloiden, taulukoiden, nimikkeiden ja kenttien suunnitteluun. 
• Graafiset elementit: ohjeita kursorien ja osoittimien suunnitteluun
• Koodaustekniikat. Koodaus on lyhenteiden käyttöä tai eri tyyppisten tietojen luokittelua (esimerkiksi miten lomakkeessa ilmoitetaan pakolliset kentät, tai miten tekstissä ilmaistaan avainsanat). Annetaan ohjeita aakkosnumeeriseen ja graafiseen koodaukseen, värikoodaukseen sekä markkereiden, välkkymisen, koon, kirkkauden ja alleviivauksen käyttöön koodauksessa

Esimerkki tiedon organisoinnista: Näytön elementeillä (esim. kentät, ikonit, graafit) tulisi olla nimike/ otsikko.

Esimerkki koodaustekniikoista: Väriä ei tulisi koskaan käyttää ainoana koodaustapana.

Vähän tarkempaa tietoa artikkelissa http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Ja vielä tarkempaa itse standardissa.

ISO 9241-110 sisältää käyttöliittymän "perusperiaatteet"

ISO 9241-110 Dialogin periaatteet on käyttöliittymäsuunnittelijan keskeistä osaamista

ISO 9241-110 sisältää käyttäjävuorovaikutuksen suunnittelun keskeisiä periaatteita. Sisältö nimensä – ”periaatteet” - mukaan ei ole suoraan keittokirjamaisia konkreettisia ohjeita, vaan niitä on suunnittelijan sovellettava. 

ISO 9241-110 on päivitetty versio aiemmasta osasta ISO 9241-10, ja siten sisällöltään ”kypsynyt” yhden kierroksen verran.

Tässä kirjoituksessa esitän osan sisällön hyvin tiivistettynä. Jonkin verran seikkaperäisemmin olen käsitellyt sitä MetStan verkkojulkaisussa http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Tarkempaa perehtymistä varten tulee standardi kuitenkin hankkia. Standardi on saatavissa myös osana SFS:n käsikirjaa 72-2. 

Periaatteet on jaettu seitsemään osa-alueeseen:

• Sopivuus tehtävään: järjestelmä tukee käyttäjää tehtävän suorittamisessa; tehtävän suoritus ei perustu esimerkiksi valitun teknologian ominaisuuksiin. 
• Itsekuvautuvuus:  käyttäjille on selvää, missä dialogissa he ovat, missä kohdassa dialogia he ovat, mitkä toimet ovat mahdollisia ja miten ne voidaan suorittaa
• Yhdenmukaisuus käyttäjän odotuksiin nähden: järjestelmä vastaa käyttäjän ennakoitavissa olevia tilannekohtaisia tarpeita ja yleisesti hyväksyttäviä käytäntöjä
• Sopivuus oppimiseen: järjestelmä avustaa ja ohjaa käyttäjää järjestelmän käytön oppimisessa
• Hallittavuus:  käyttäjä kykenee aloittamaan ja hallitsemaan vuorovaikutuksen suuntaa ja nopeutta, kunnes tavoite on saavutettu
• Virheiden sieto: tarkoitetut tulokset voidaan saavuttaa syötteissä olevista ilmeisistä virheistä huolimatta joko ilman käyttäjän korjauksia tai vähäisin korjauksin
• Sopivuus yksilöllistämiseen: käyttäjät voivat muokata vuorovaikutusta ja tiedon esittämistä vastaamaan yksilöllisiä kykyjään ja tarpeitaan

Kukin osa-alue sisältää useita periaatteita, ja kukin periaate on konkretisoitu esimerkillä. Esimerkiksi yksi itsekuvautuvuuden periaate on: 

• Missä tahansa dialogin vaiheessa käyttäjälle esittävän tiedon olisi opastettava käyttäjää dialogin suorittamisessa loppuun. 
• Ja tätä konkretisoiva esimerkki:  Hotellivarausjärjestelmä antaa käyttäjän syöttää tarvittavat tiedot ja käyttää painikkeita [Seuraava] ja [Edellinen] dialogin vaiheiden läpikäymisen ohjaamiseen. 

Mikä hyödyllistä käytettävyystutkimusta?

Asiasta käytettävyysnavigoijablogissa (siinä myös mobiili näkökulma!)

http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-hyodyllista-kaytettavyystutkimusta.html

ISO 9241: Perustietoa käyttöliittymäsuunnittelijoille ja käytettävyysasiantuntijoille

Moniosainen ISO 9241 -standardi sisältää oleellista perustietoa jokaiselle käyttöliittymäsuunnittelijalle ja käytettyvyysasiantuntijalle

ISO 9241, Ihmisen ja järjestelmän välisen vuorovaikutuksen ergonomia, on laaja moniosainen standardi, joka sisältää periaatteita ja ohjeita käyttöliittymäsuunnittelun eri osa-alueisiin. Standardin eri osat sisältävät hyödyllistä perustietoa, joista jokaisen käyttöliittymäsuunnittelijan ja käytettävyysasiantuntijan olisi hyvä olla selvillä.

Ohjelmistojen suunnittelun sekä käytettävyyden varmistamiseen ohjeita antavat keskeiset osat ovat: 

• ISO 9241-110: Dialogin periaatteet (suomennettu)

• ISO 9241-11: Käytettävyyden määrittely ja arviointi (suomennettu)
• ISO 9241-12: Tiedon esittäminen (suomennettu)
• ISO 9241-13: Käyttäjäopastus (suomennettu)
• ISO 9241-14: Valikkodialogi
• ISO 9241-15: Komentodialogi
• ISO 9241-16: Suorakäyttödialogi
• ISO 9241-17: Lomakepohjainen dialogi
• ISO 9241-20: Tieto- ja viestintäteknologian laitteiden sekä palvelujen esteettömyyttä koskevat ohjeet (suomennettu)

• ISO 9241-129: Opastusta yksilöllistämiseen
• ISO 9241-151: Opastusta www-käyttöliittymiä varten (suomennettu)
• ISO 9241-171: Ohjelmistojen esteettömyttä koskevaa opastusta

• ISO 9241-210 Vuorovaikutteisten järjestelmien ihmiskeskeinen suunnittelu (aiemmin ISO 13407)

Osat sisältävät kaikkiaan satoja yksittäisiä periaatteita tai ohjeita. Standardin osissa valaistaan ohjeita myös esimerkein - tosin vaihtelvissa määräin - jotka parantavat ohjeiden luettavuutta ja ymmärtämistä.

Standardi ei ole mobiilispesifinen - itse asiassa siinä ei ole erityistä osaa mobiiliohjelmistojen suunnitteluun. Kuitenkin standardin sisältö on laajasti yleispätevää, niin mobiilisovelluksille kuin muillekin.  

Tämän blogin seuraavissa kirjoituksissa annan tietoa  tiivistetysti kunkin osan sisällöstä ja esimerkkejä osien ohjeista tai periaatteista. Sisältöön tarkempi perehtyminen - ohjeet kattavammin - edellyttää osien hankkimista (standardit ovat tekijänoikeuksien alaisia, eikä niitä saa kopioida). Ajatus on, että blogin perusteella lukijat saavat käsityksen standardin osien keskeisistä sisällöistä.  

käytettävyysammattilaisen eettiset säännöt

Eettiset säännöt on periaattessa käytettävyysammattilaisen perustietoa: http://www.usabilityprofessionals.org/about_upa/leadership/code_of_conduct.html .

Itse olen nyt joutunut näihin perehtymään, ja ne kyllä antavat tukea, jos joutuu hankalaan tilanteeseen (ei siis teknisesti vaan eettisesti).

käyttöliittymän mallia...

tietyllä tavalla mobiili käyttöliittymä tämäkin: http://360vr.com/2011/06/22-discovery-flight-deck-opf_6236/index.html

Mikä olikaan käytettävyyden määritelmä? Mitä ajatuksia ja kokemuksia?

Näin kesälomien päättyessä kertaus perusasioihin. Onko aito, oikea käytettävyyden määritelmä joskus hukassa? (ainakin itse joudun virallista määritelmää aina aika etsimään). Määritelmähän on sanamuodoltaan aika monimutkainen, ja hieman erilaisia käännöksiä näkyy eri kirjoituksissa. 


Käytettävyysnavigoija-blogissa käyn läpi määritelmää ja kyselen kokemuksia: 
http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html