GUIDe (Goals – User Interface Design – Implementation) on Interacta Design Oy:ssä kehitetty prosessimalli käyttötapauslähtöiseen käyttöliittymäsuunnitteluun. Menetelmä pyrkii varmistamaan tarkoituksenmukaisen käyttöliittymän syntymisen siirtämällä käyttöliittymäsuunnitteluvaihe määrittelyvaiheen alkuun ja muodostamalla käyttöliittymä systemaattisesti käyttötapausten avulla.
Prosessi menee seuraavasti:
- Käyttötapaukset: Seurataan käyttäjien oikeaa toimintaa (tai simuloidaan sitä). Muodostetaan tavoitepohjaiset käyttötapaukset (goal-based use cases) toiminnan pohjalta.
- Käyttöliittymäsuunnittelu: Hahmotellaan käyttöliittymä yksi käyttötapaus kerrallaan ja lisätään käyttöliittymään vain elementtejä, jotka ovat käyttötapausten kannalta olennaisia (simulointipohjainen käyttöliittymäsuunnittelu (Goal-Derived Design, GDD)
- Testaus: Kaikki toiminnot sisältävä käyttöliittymä testataan oikeiden käyttäjien avulla joko käytettävyystestien tai läpikäyntien (walkthroughs) avulla. Tehdään kokemusten perusteella tarvittaessa muutoksia, eli palataan edelliseen vaiheeseen (iteratiivinen käyttöliittymäsuunnittelu).
- Käyttöliittymäspeksi: Valmis käyttöliittymä dokumentoidaan speksiksi, jossa on periaatteessa kaikki näkymät piirretty lopulliseen muotoonsa. Speksi pyrkii siis kuvaamaan miltä suunniteltu käyttöliittymä näyttää ja miten se toimii. Hyötynä on
- Toteutus: Valmis käyttöliittymä toteutetaan joko vesiputousmallin mukaisesti yhdessä klimpissä tai ketterämmin toimintokokonaisuus kerrallaan.
Menetelmä on kuulemma saanut jonkinverran kritiikkiä ketterien kehitysmenetelmien kannattajilta, koska se periaatteessa pyrkii siirtämään kaiken suunnittelun projektin alkuun, sen sijaan, että toiminnallisuuksia suunniteltaisiin ja toteutettaisiin pienemmissä ja helpommin hallittavissa osissa.
Menetelmä on myös käytössä Reaktor Innovationsilla, jossa yksi GUIDe:n kehittäjistäkin nykyisin vaikuttaa. Reaktorin artikkelin suositusten mukaan kannattaa pienet käyttöliittymät suunnitella kokonaan yhdellä istumalla ja laajemmat pyrkiä suunnittelemaan karkealla tasolla siten, että käyttöliittymän kokonaisrakenne saadaan selville. Yksittäiset osakokonaisuudet voidaan tämän jälkeen suunnitella ja toteuttaa yksi kerrallaan ketterästi esimerkiksi Scrum-menetelmää noudattaen.
Soveltaminen verkkokehitykseen
Menetelmä toimii varmasti perinteisessä softakehityksessä loistavasti. Verkkokehitykseen soveltaminen perinteisessä toimittaja-asiakas-loppukäyttäjä-asetelmassa vaatii jo enemmän mielikuvitusta.
Sisällöllisesti rikkaissa ja toiminnallisesti köyhissä verkkopalveluissa käyttöliittymä on usein aika pienessä roolissa. Sivuston yleinen käyttöliittymä (navigaatio, hakutoiminnot, …) pitää toki suunnitella, mutta ok-lopputulokseen päästään usein maalaisjärjellä ja konventioita noudattamalla. Sisältöorientoituneella sivustolla käyttäjien tarpeet liittyvät usein jonkin tietyn tiedon löytämiseen ja sikäli niiden simuloiminen ei luultavasti tuota ei-triviaalia tietoa.
Sinänsä menetelmään sisältyvä less-is-more -ajatus voisi olla hedelmällinen myös sivuston sisällön miettimiseen. Periaatteessahan sivustolla on turha kertoa asioista, joista loppukäyttäjät eivät ole kiinnostuneet. Turhan sisällön lisääminen sivustolle vaikeuttaa olennaisen löytämistä ja lisää sisällön ylläpitämiseksi tehtävää työtä.
Menetelmä on nimenomaisesti käyttäjälähtöinen ja sen soveltaminen edellyttäisi aitoa kontaktia tuotteen loppukäyttäjiin. Kuitenkin suurelle yleisölle tehtävää verkkokehitystä joudutaan usein tekemään ainakin osittain side silmillä, kun loppukäyttäjistä ja heidän tarpeistaan tiedetään oikeastaan vain se, mitä asiakas osaa kertoa.
Tilanne olisi korjattavissa, jos toimittajalla olisi paukkuja ottaa loppukäyttäjä (asiakkaan asiakas) mukaan suunnitteluprosessiin. Tämä vaatisi tosin osaamista ja rahallisia panoksia ja näin ollen perustelutyötä asiakkaan suuntaan. Tilannetta ei helpota se, että asiakas usein luulee tietävänsä omat asiakkaansa todellisuutta paremmin. Optimaalisessa tilanteessa asiakas ymmärtää asiakkaansa hyvin, mutta ei tajua verkkokehityksen lainalaisuuksista tai ihmisten verkkokäyttäytymisestä riittävästi tajutakseen, mitä loppukäyttäjät verkossa tarvitsevat.
Tilanne on tietysti täysin erilainen, jos ollaan tekemässä toiminnallista verkkosivustoa tai esimerkiksi siirtämään olemassaolevan työpöytäsovelluksen toimintoja verkkoon. Tällöin luulisi käyttöliittymäsuunnittelun olevan automaattisesti iso osa projektia, mutta reaalimaailmassa ei tämäkään aina ihan toteudu…
Avainsanat: käyttöliittymäsuunnittelu, menetelmät, web-kehitys
11. joulukuuta 2008 kello 18.01
> Kuitenkin suurelle yleisölle tehtävää verkkokehitystä joudutaan usein tekemään ainakin osittain side silmillä, kun loppukäyttäjistä ja heidän tarpeistaan tiedetään oikeastaan vain se, mitä asiakas osaa kertoa.
Siihen ei vain pidä tyytyä. Vaikka asiakas usein tosiaan luulee tietävänsä loppukäyttäjistä vaikka mitä, faktat voi silti tarkistaa kentältä. Sen rahallinen vaikutus projektiin on itse asiassa ihan todella pieni verrattuna vaikkapa siihen, että koodataan ns. paras arvaus, joka osoittautuu sittemmin vääräksi tai joskus jopa aivan täysin vääräksi. Itse asiassa (oikein tehty ja tuloksekas) kälityö on todella halpaa verrattuna esim. kuukausien “määrittelyprojekteihin” (joiden lopputulos harvoin on hyödyllinen juuri kenenkään kannalta).
Perustelutyötä asiakkaan suuntaan vähentää se, jos ei anna vaihtoehtoja. “Meidän menetelmässä ratkaisujen käyttökelpoisuus arvioidaan siten, että niitä simuloidaan loppukäyttäjille. Sattuuko teillä muuten itsellänne olemaan kontakteja soveltuviin käyttäjiin? Voitaisiin nyt miettiä vaikka alkuun yhdessä, millaisia käyttäjiä tarvitaan.” Jos annat sellaisen kuvan, että käyttäjät ovat jokin lisäoptio, josta voisi olla hyötyä, homma päätyy samaan nippuun kuin muu yleisesti hyväksi tiedetty, johon ei ole nyt rahaa.
Osaamisen puutetta ei tietenkään korvaa millään, mutta käyttäjätutkimuksiin ja kenttäselvityksiin on (toisin kuin itse kälisuunnitteluun) hyllymetreittäin kirjallisuutta, joukossa hyvinkin konkreettisia teoksia, esim Hackos & Redish’n kirja, jonka nimi ei nyt heti tule mieleen. Lisäksi tekemälläkin oppii nopeasti, jos metakognitio on kunnossa.
Nuo “vähän käliä, paljon sisältöä”-sovellukset jäivät minulle esimerkin puuttuessa hämäräksi. Mitähän sinulla oli mielessäsi?
18. joulukuuta 2008 kello 12.11
Kiitos ansiokkaasta kommentista ja huomioista!
Kirjoitukseni tarkoituksena oli nimenomaisesti pohtia GUIDe:n soveltuvuutta verkkojulkaisemiseen, jonka sijoittaisin tuon huonon “vähän käliä, paljon sisältöä” -kategorian alle.
Verkossa konventiot rulaavat ja tuntuu, että jos niistä lähdetään poikkemaan radikaalisti, mennään helposti vikaan. Miksi siis käyttää aikaa käyttöliittymän suunnitteluun, kun konventioilla pärjätään? Kärjistäen sanottuna.
Oma ongelmani käyttöliittymäsuunnittelun sovittamisessa verkkomaailmaan on, että näen käyttöliittymäsuunnittelun nappien sijoitteluna ja erilaisten toimintojen suorittamisen optimointina.
Keskimääräisellä sisältöorientoituneella verkkosivulla toimintoja on yleensä muutama (haku, sisäänkirjautuminen, muutama lomake jne). Lisäksi on muutama navigaatiotaso, jotka voivat olla (kärjistäen sanottuna) vaakatasossa tai pystytasossa. Näiden suunnittelussa uskon konventioiden riittävän hyvin. Esimerkiksi verkkokaupan tapauksessa tilanne on tietysti täysin eri.
Sitä, miksen ole ymmärtänyt käytettävyyden ja käyttöliittymäsuunnittelun olevan olennaisesti sidoksissa myös informaatioarkkitehtuurin suunnitteluun ja tiedon löytämiseen, voin vain ihmetellä.
Tämän suunnitteluun GUIDe olisi varmasti omiaan: Tunnistetaan käyttäjäryhmät ja heidän tarpeensa ja muodostetaan informaatioarkkitehtuuri näiden mukaan siten, että käyttäjien tarpeisiin vastataan. Tosin väitän, että tässäkin liian radikaalit ratkaisut menevät mäkeen ja rakenne, joka kuvaa sisällön loogisessa ja hierarkisessa, asiakkaan maailmaan hyvin istuvassa muodossa toimii parhaiten.
Pointtisi käyttäjälähtöisen suunnittelun optionaalisuudesta on aiheellinen. Vaikkakin reaalimaailmassa ja “näinä aikoina” mennään kyllä pitkälti asiakkaan rahapussin mukaan, jos halutaan tehdä projekteja jatkossakin.
Jokaisen IT-toimittajan velvollisuutena olisi mielestäni asiakkaiden valistaminen hyvistä käytännöistä, mutta loppukädessä päätökset prosessista ja hinnasta tekee kuitenkin (ainakin meillä) asiakas. Valitettavasti.
Verkkomaailmassa suurin hyöty käyttäjälähtöisestä suunnittelusta olisi varmasti prosessin alkupäässä, jossa sivuston tärkeimmät käyttäjäryhmät tunnistetaan ja heidän tarpeensa kartoitetaan. Tähän kartoitustyöhön voisin kuvitella esimerkiksi focus group -henkisen työskentelytavan toimivan hyvin, vaikkei omakohtaisia kokemuksia (vielä) juuri olekaan.
Ostan siis ajatuksesi faktojen tarkastamisesta. Asiakkaan luuloihin käyttäjien tarpeista ei pitäisi luottaa, vaan kartoittaa tarpeet oikeilla käyttäjillä. Tämä on olennainen osa diplomityötäni ja toivottavasti käytännön kokemuksia meidän kontekstissamme seuraa keväämmällä.
Kiitos kirjavinkistä, lisäsin User and Task Analysis for Interface Designin lukulistalle.