Kun asiakas ja graafikko näkevät ensimmäisen version toteutetusta verkkopalvelusta, he saattavat pahimmillaan hämmästellä: ”Mitä ihmettä tapahtui?”
Mitä tapahtui?
Minkä takia graafikon hieno tuotos kääntyy verkkopalveluksi, joka näyttää vain sinne päin sutaistulta?
Web-selaimet ovat huomattavasti hankalampi ympäristö kuin Photoshop, Sketch, tai InDesign. Siinä missä mallikuva näyttää ohjelmasta toiseen aina samalta, selaimissa on puutteita ja bugeja. Ne saattavat esittää saman asian eri tavalla. Yhden rivin englanninkielinen otsikko istuu nätisti pöytäkoneen näytölle, mutta jakautuu kolmelle riville suomenkielisessä tabletissa. Taustakuva katkeaa eripituisella sisällöllä hassusta kohtaa. Fontti, joka näytti piirtotyökalussa hyvältä skaalattuna 12 pikselin korkuiseksi, näyttääkin selaimessa erilaiselta. Lisäksi tietyt asettelut ja muodot ovat vaikeampia tuottaa selaimessa. Niiden tunnistaminen ei välttämättä ole selviö, jollei ole tehnyt web-kehitystä.
Web-sivut ovat paljon muutakin kuin staattista sisältöä. Monia käyttäjäkokemuksen kannalta tärkeitä asioita ei voi kommunikoida staattisen grafiikan avulla. Otetaan esimerkiksi vaikka verkkokaupan suodattimet. Aukeaako suodatinlista kun hiiren vie suodattimen päälle vai kun suodatinta klikkaa? Aukeaako lista animaatiolla vai tuleeko se välittömästi näkyviin? Näytetäänkö käyttäjälle animoitu ikoni sillä välin, kun tuotelista päivittyy? Nämä kaikki ovat asioita, joiden määrittely vaatii enemmän kuin vain staattista grafiikkaa.
Ei ole poikkeuksellista, että sivustolla on viisi eri visuaalista ilmettä riippuen päätelaitteen koosta. Pitäisikö graafikon tuottaa viisi eri versiota kustakin sivusta? Tietysti olisi tehokkaampaa tuottaa yksi versio grafiikkana ja loput rautalankoina, mutta tällöin lopullisen toteutuksen visualisointi jää osittain asiakkaan mielikuvituksen varaan.
Miten tämän hyvää työtä hukkaavan prosessin voi korjata?
Design by prototyping
Ainoa tapa saada täsmällinen ja varmasti toteutettavissa oleva käyttöliittymämääritys on tehdä se luonnollisessa elinympäristössään - koodina selaimessa. Varsin usein palvelun vaatimaa teknologiaa ei ole valittu tässä vaiheessa projektia. Siksi määritys tehdään staattisena sivustona eli prototyyppinä.
Prototyyppi on lopullista verkkopalvelua vastaava, selaimella käytettävä käyttöliittymä. Siitä käy ilmi, miltä palvelu näyttää ja tuntuu eri päätelaitteilla, mutta ilman kytkentää taustajärjestelmiin. Prototyypin avulla voidaan ottaa kantaa jokaiseen yksityiskohtaan, visuaalisesta ilmeestä animaatioiden nopeuksiin ja ruudunlukijoiden käyttäytymiseen. Tämän ansiosta asiakas saa jo projektin varhaisessa vaiheessa todellisen kuvan siitä, millainen lopputulos tulee olemaan.
Kaikki sivustot - kuten prototyyppikin - ovat pohjimmiltaan HTML-, CSS-, ja JavaScript-koodia. Tämä mahdollistaa prototyypin koodin uudelleenkäytön lopullisessa verkkopalvelussa. Prototyypin rakentaminen ei siis ole hukkaan heitettyä työtä. Koodin uudelleenkäyttö ei ole ainoastaan mahdollista vaan käytännössä pakollista, jotta jokainen yksityiskohta välittyy lopulliseen tuotokseen. Koodin kierrätys kannattaa huomioida myös sopimuksessa. Toimittajan ei kannata koodata uudestaan kertaalleen tehtyä, eikä asiakkaan pidä maksaa tuplatyöstä.
Uudelleenkäytön takia prototyypille täytyy asettaa samat vaatimukset kuin lopullisen tuotantojärjestelmän käyttöliittymälle. Tyypillistä kuitenkin on, että varhaisessa vaiheessa prototyyppi esimerkiksi toimii halutulla tavalla vain yhdellä selaimella. Määritystyön edetessä prototyypin kypsyys kasvaa, kunnes ominaisuus kerrallaan saavutetaan tuotantotasoinen laatu, jolloin palvelu tai sovellus on valmis kehitysprojektin toteutukseen.
Mikäli prototyypillä mallintaminen tehdään ketterästi ja samassa tahdissa kehitysprojektin kanssa, esimerkiksi sprintti ennen varsinaista sovelluskehitystyötä, siitä voidaan johtaa käyttöliittymävaatimukset kullekin kehityssprintille. Näin visuaaliseen suunnitteluun ei tarvitse varata erillistä usean kuukauden projektivaihetta. Myös käyttäjäpalaute ja iterointi on nopeampaa, kun visuaalinen suunnittelu elää kehitystyön kanssa samassa rytmissä.Tarvitaanko graafikkoa?
Prototyyppaus ei missään nimessä tee graafikosta turhaa. Päinvastoin. Web-kehittäjä, jolla on visuaalista silmää, on kutakuinkin yhtä harvinainen kuin koodaava graafikko. Täydellisessä prototiimissä on sekä graafikoita että web-kehittäjiä, jotka työskentelevät yhdessä tietyn ominaisuuden parissa.
Web-kehittäjä varmistaa graafikon suunnitelman toteutettavuuden ennen pikselintarkkaa viimeistelyä. Graafikko pitää puolestaan huolen siitä, että lopputulos vastaa visuaalista mallia. Ongelmia syntyy lähes aina, jos yhteistyö näiden roolien välillä on vähäistä tai jos käyttöliittymä on tilattu ainoastaan koodaajalta tai ainoastaan graafisena suunnitteluna.
Milloin prototyyppi ei ole tarpeen?
Koodatun prototyypin teko on turhaa, mikäli tiedät a) millä tuotteella palvelu toteutetaan ja b) kyseisellä tuotteella on vakiintuneet käyttöliittymät. Muun muassa CRM-järjestelmät ovat usein tällaisia. Näissäkin tapauksissa vaikkapa rautalankojen tai mallikuvien teko auttaa ymmärtämään, miltä palvelu lopulta näyttää.
Prototyypin käyttö kannattaa myös lopettaa projektin kypsyessä. Se on kuitenkin yksi ylläpidettävä asia lisää. Tyypillisesti prototyypin voi kuopata silloin, kun järjestelmään ei enää tule iterointia vaativia ominaisuuksia, ja se alkaa olla enemmän ylläpitovaiheessa. Prototyyppi on siis ketterän kehityksen eräs vaihe, menetelmä ja työkalu, jolla säästetään aikaa ja rahaa.
Kirjoittaja Asko Relas on Talent Base Oy:n senior konsultti, joka keskittyy pääasiassa moderneihin tiedonhallintateknologioihin, analytiikkaan ja responsiiviseen web-suunnitteluun. Hän on työskennellyt myös käytettävyyssuunnittelijana ja graafisena suunnittelijana.
Ei kommentteja:
Lähetä kommentti