Käyttö & liittymä
Santtu Toivonen, 19.12.2008, 10:42Miten käyttöliittymä suunnitellaan?
Olen usein löytänyt itseni yhteisöstä, joissa edustan oppositiota vallitsevan
ajatus- ja arvomaailman suhteen.
Pienenä pidin legoista, mekanoista ja vähän tietokoneistakin. Sitten kuitenkin ajauduin kaveriporukkaan, joka johdatti minut filosofian ja uskontotieteiden opintojen pariin.
Teoreettista filosofiaa opiskellessani taas kiinnostuin kognitiotieteestä ja tekoälystä. Sen siivittämänä päädyin ainoana humanistina teleoperaattorin tutkimusosastolle, keskelle kovan luokan olio-ohjelmoijia.
Hyvä vierailija!
Arkistomme on vain rekisteröityneiden käytettävissä.
Jos sinulla on jo käyttäjätunnus Tietoviikkoon, kirjaudu sisään.
Mahtaakohan vesiputousmalli olla liian "hidas" it-projekteissa, joissa ei olla osattu määritellä lopputulosta riittävän hyvin. Luulisin, että monet julkisuudessakin olleista jättiprojekteista (esim. AKE) on kärsinyt juuri siitä, että asiakas on vanhanaikaisesti tilannut "avaimet-käteen"-ratkaisun. Analogiana voisi ajatella fyysisen talon tilaamista, asiakas ilmoittaa haluavansa "talon" kahdessa vuodessa. Kahden vuoden ajan suunnitellaan ja rakennetaan omakotitaloa ja loppusuoralla asiakas ilmoittaa halunneensa rivitalon.
Hyvä pointti tuo liian yleisen tason kuvaus (talo vs. rivitalo). Eräs iteroinnin hyvistä puolista on, että voidaan aloittaa yleisemmästä päämäärästä ja erityistää matkan varrella. Taloa koskevassa analogiassa rivitalo-määrityksen olisi pitänyt tulla siinä vaiheessa, kun prosessi jakaantuu joko omakotitaloa tai rivitaloa toteuttavaan haaraan.
Aihe on varsin ajankohtainen, kun ketterästä kehityksestä on tullut ohjelmistokehityksen uusin Graalin malja ja hopealuoti. Vähän syvällisempää pohdintaa olisin toivonut kuitenkin. Joitakin kommentteja ja ajatuksia omiin kokemuksiini pohjautuen.
"Yleisesti vesiputousmallin puolustajat arvostelevat agile-menetelmiä siitä, että ne tuottavat liikaa päällekkäistä ja turhaa työtä, toisin kuin suoraviivainen vesiputousmalli."
Todellako? Itse olen törmännyt vesiputousmiesten kohdalla siihen, että pääkritiikki ketteryyttä kohtaan kulminoituu lähinnä suunnittelemattomuuteen ja epäselvään kykyyn kertoa, koska homma on valmis. Turhaa työtä en ole kuullut kenenkään listaavan syynä agile-vastustukseensa tai -epäluuloonsa.
"Suunnitteluprosessi on usein vahvasti yksilötyötä. Sitä ei voi verbaalisesti kommunikoida, vaan se edellyttää tuekseen valmiin designin tai ainakin luonnoksen. Ympäristön pitää olla mahdollisimman stressitön, jotta luovuus pääsee valloilleen. Liian usein toistuvat kokoukset ja raportoinnit voivat häiritä tätä."
Minusta kuvailet tässä nyt enemmän taiteilijan työtä kuin tuotesuunnittelijan. Tuotesuunnittelu (ohjelmistotuote tai fyysinen tuote, kahvipannu tai sykemittari) on ryhmätyötä, tiimityötä, jossa markkinointi, insinöörit, muotoilijat, käytettävyysihmiset, ohjelmistokehittäjät, valmistusteknologiaihmiset, asiakastuki kaikki yhdessä ovat suunnittelemassa ja toteuttamassa tuotetta. Myytti yksin omassa studiossaan tuotetta suunnittelevasta baskeripäästä ei ole tätä päivää. 2000-luvun tuotteet sisältävät usein niin monimutkaista teknologiaa, että jos tuotetta ei suunnitella yhdessä, ei siitä voi millään saada helppokäyttöistä. Yksin omassa studiossa työskentely johtaa sitäpaitsi automaattisesti vesiputousmalliin. Suunnitelmaa tai suunnitteluprosessia voi ja pitää voida kuvata verbaalisesti; toki prototyypit auttavat. Keltaiset laput ja muovailuvaha tai pahvilaatikko ovat hyviä protoiluvälineitä.
"Entä käyttöliittymäsuunnittelun erityispiirteet? Lyhyt vastaus: Käyttäjät mukaan agile-prosessiin. Ihmisten kokemus ohjelmistoista ja laitteista tulee käyttöliittymien kautta.
Tehokkaimman sovelluksen, jossa on maailman parhaat tekniset ominaisuudet, voi pilata huonolla käyttöliittymällä. Siksi on tärkeää, että suunnitteluprosessissa olevaa tuotetta arvioidaan useita kertoja yhdessä käyttäjien kanssa. Luonnollisesti suunnitelmasyklien tulee olla tarpeeksi pitkiä, jotta yllä peräänkuulutettua luovaa aikaa jää suunnittelulle. Päivittäin iteroituvaan scrum-prosessiin tuskin tarvitsee lähteä."
Alistair Cockburn puhuu isojen kivien kääntämisestä ensin, ja pienet tulevat sen jälkeen. Tämä pätee myös käyttöliittymäsuunnittelussa. Käyttöliittymäarkkitehtuuri (= informaatioarkkitehtuuri, ainakin suurin piirtein samasta asiasta on kyse) on saman tasoinen asia kuin ohjelmisto- tai rauta-arkkitehtuuri, ja se pitää olla olemassa ensin. Käyttäjätutkimusta voi ja kannattaa tehdä vaikka pari scrum-iteraatiota insinöörien edellä. Jokaisen sprintin kuluessa testataan syntymässä olevan tuotteen käytettävyys vaikkapa soveltaen Nielsenin 'discount-menetelmiä', ja löydökset viedään takaisin suunnittelijoille samalla tavalla kuin ohjelmistokehityksen tuottamat bugit viedään korjattaviksi.
"Itse uskon projektiryhmän sisäisen dynamiikan ja persoonallisuuksien viime kädessä ratkaisevan, kenelle sopii vesiputous ja kenelle ketteryys. Kunhan substanssiosaamista löytyy projektiryhmästä tarpeeksi, voi kummalla tahansa menetelmällä päästä loistavaan lopputulokseen."
Isommissa tuote- tai ohjelmistokehitysharjoituksissa (joissa on monta alaprojektiryhmää) ei ole yleensä mahdollista eikä edes suotavaa, että yksittäinen projektiryhmä valitsee menetelmät sisäisen dynamiikkansa perusteella. Kumpikin tuotekehitysviitekehys tuo mukanaan omanlaisensa rajapinnat, roolit ja aikataulutusmekanismit, ja ylätason ohjaus menee varsin vaikeaksi, jos yksittäiset aliprojektit elävät keskenään epäyhteensopivassa maailmassa. Itse olisin myös taipuvainen uskomaan, että vesiputousmalli on aikansa elänyt myös pienemmissä projekteissa, varsinkin jos on tarkoitus kehittää kuluttajatuotetta nopealla aikataululla.
Vesiputousmalli painottaa aikatauluja ja dokumentteja. Ketterä kehitys painottaa käyttäjän kokemaa laatua ja suunnittelijoiden yhteistyötä.
Jälleen tuli arvokkaita huomioita. Tässä vähän jatkoa. Yleisesti on todettava, että blogikirjoitukset kommentteineen ovat luonteeltaan sellaisia, että kovin syvälliselle tasolle ei tarvitse porautua heti, vaan keskustelun edetessä voidaan syventää mielenkiintoisia kohtia.
1) Re: Yleisin syy agile-menetelmien arvosteluun "vesiputousihmisten" toimesta. Turha ja päällekkäinen työ on suunnittelemattomuuden tulos. Jos ei pystytä kertomaan, milloin työ on valmis, eikä vielä sitäkään, mitä lopulta ollaan tavoittelemassa, on riski tehdä jotain muuta kuin mitä pitäisi. Tämä pitää sitten purkaa ja tehdä uudestaan toisella tavalla.
2) Re: Taiteilija vs. tuotesuunnittelija. Hyvän designerin erottaa huonosta erityisesti se, että hyvä pystyy ymmärtämään asiakkaan/käyttäjän tarpeet ja suunnittelemaan juuri hänelle sopivan tuotteen. Taiteellinen itseilmaus ei saa olla designerille itsetarkoitus. Kuitenkin hyvän suunnittelijan erottaa erinomaisesta siinä, että jälkimmäinen pystyy menemään vielä askeleen pidemmälle. Hänen ylivertainen (tyypillisesti visuaalinen) ilmaisukykynsä on se joka viime kädesssä tuottaa asiakkaalle wow-efektin. Näin erityisesti käyttöliittymäsuunnittelijoiden tapauksessa.
3) Re: Käyttäjät mukana agile-prosessissa. Totta, mitä enemmän käyttäjiä saadaan osallistettua, sitä parempia tuloksia voidaan odottaa. Vaikka se nähdään usein kustannustekijäksi implementointivaiheessa, maksaa se itsensä todennäköisesti moninkertaisesti takaisin.
4) Re: Projektiryhmän dynamiikka ja persoonallisuudet. Ei pidä sekottaa realiteettia ja ideaalimaailmaa. Toki metodologinen valinnanvapaus jokaiselle projektiryhmälle jokaisen projekti-instanssin kohdalla saisi aikaan hallinnallisen painajaisen. Silti voidaan olettaa, että kussakin instanssissa olisi aina teoriassa valittavissa erikseen se nimenomainen menetelmä, joka juuri silloin ja juuri sille projektiryhmälle olisi paras.
Design approprioidaan olemassa olevista malleista. Kumulatiivinen mallinnus omaksuu vain toimivat ja 'testatut' ratkaisut ja toteuttamalla käyttökontekstin asettamat vaatimukset.
(tässä vaiheessa voi miettiä moraalia).
Käyttöliittymän patentointi ei ole sama asia kuin vuorovaikutuksen patentointi. Käyttöliittymä on konkreettinen (materiaalinen) artefakta, vuorovaikutus on tässä yhteydessä immateriaalinen artefakta.
Ongelma ei ole viimekädessä käyttöliittymän ja arkkitehtuurin välinen dynamiikka. Kyse on siitä kuinka kauan osapuolilta kuluu tunnistaa ja tunnustaa suunnittelun sisäinen normatiivinen luonne. Fakta on ettei mikään design täytä koskaan kuviteltuja vaatimuksia. Peräänkuulutettaessa hyvän suunnittelun lisäarvoa helposti unohdetaan ihminen ja muutos.
Usein suunnitteluun vain päädytään valikoimalla ja 'omaksumalla' oikeita ratkaisuja. Tämäkin pätee vain uusien sovellusten kehittämisessä.
Silti, ei pidä erehtyä luulemaan että vanhaa kannattaa lähteä taivuttamaan trendikkääseen ulkoasuun, sillä tämä voi aiheuttaa katkoksen loppukäyttäjien työn tuottavuudessa.
KPA
Ilmoituksesi käsitellään seuraavan työpäivän kuluessa.