Siellä on mielenkiitoisia puheenvuoroja. Tässä kommentti yhteen sellaiseen (tarkoitukseni oli käydä blogissa seuraavaksi läpi JHS-suosituksia käytettävyyden kannalta, mutta lykätään sitä analyysia myöhemmäksi).
En tiedä tarkemmin, miten tuo prosessi alkupäässä menee. Kuitenkaan, jos ei ole alussa määritetty aitoja (valideja ja todennettavia) käytettävyysvaatimuksia, ei voida puhua validoinnista. Käyttäjäpalautteen kerääminen ja käytettävyystestaus ovat hyviä asioita, ja niillä käytettävyys todennäköisesti paranee. Mutta se jää auki, tuleeko riittävän hyvä. Validointiin tarvitaan kriteerit "milloin on riittävän hyvä".
Ihan niinkuin Pilvi kommentoi Petterin kirjoitukseen: "Iteratiivisen kehitystyön ja käyttäjätestausten vaatiminen ei varmaankaan riitä,mvaan edelleen on määriteltävä varhaisessa vaiheessa käytettävyystavoitteet ja pyrittävä mitattavuuteen?"
Scrum-kehityksessä käytettävyyden huomioiminen on periaatteessa helppoa, koska työn määrittelyn välineenä olevien käyttäjätarinoiden (User Stories) muotoilu on käyttäjälähtöistä. Tällöin kirjoituksen lainauksessa mainittu toimintatapa, jossa prototyypillä ("realistisella sovelluksen simulaatiolla"), on mielekäs kun siinä hyväksytetään alkuperäisen määrittelyn toiminnallisuudet asiakkaalla tai tuoteomistajalla (Product Owner).
VastaaPoista"Milloin on riittävän hyvä" on silloin kun tietyn käyttäjätarina voidaan hyväksyä tehdyksi (Definition of Done). Parhaassa tapauksessa kaikki määrittelyt ovat itse asiassa käytettävyyteen liittyviä ja käytettävyydestä ei silloin edes tarvitse puhua erikseen. Käytännössä välttämättömät muut määrittelyt liittyvät teknisiin rajapintoihin ja haluttuihin teknologioihin.
Lopulta validointiin ei varmaan ole täysin yksiselitteistä mittaustapaa. Lainauksessa mainittu käytettävyystestaus epäilemättä auttaa ja sitä voi soveltaa seuraavasti:
0. Vaatimukset
1. Nopeasti rakennetulla käyttöliittymäprotolla tehdään käytettävyystestaus, josta taltioidaan käyttäjätarinoita vastaavat käyttötapaukset. Näiden tallenteiden perusteella käyttäjätarinat hyväksytetään ja niistä tulee Definition of Done -määrittelyitä.
2. Toteutetaan valittuja ominaisuuksia ja käytettävyystestataan niiden vastaavuus protolla tehtyihin testituloksiin.
3. Jatketaan iteratiivista kehitystä sprinteissä (Sprint) ja integroidaan järjestelmää huolehtien ettei mikään mene rikki.
kiitos kommentista. Jossa montakin mielenkiintoista kohtaa. Mutta olen sitä mieltä, että ym. systeemillä hyvä käytettävyyttä voi tulla - tai olla tulematta. Ja valitettavan helposti toteutuu tuo jälkimmäinen.
VastaaPoistaSinun kommentissa niinkuin joissakin aiemmissakin on sen verran vastaamista, että tässä "kommentin kommentissa" en analysoi asiaa tarkemmin. Palaan näihin eri näkökulmiin tulevissa blogikirjoituksissani; toivottavasti maltat odottaa.
- Ja sen verran toivomusta, että mukava olisi, jos kommentoitaisiin omalla nimellä.
kirjoitinkin jo yhdestä näkökulmasta: http://hankikaytettavyytta.blogspot.com/2011/09/asiakas-hyvaksyy-ei-ole-yhtakuin.html
VastaaPoista