Konsepti

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:

1. Käyttötapaukset: Seurataan käyttäjien oikeaa toimintaa (tai simuloidaan sitä). Muodostetaan tavoitepohjaiset käyttötapaukset (goal-based use cases) toiminnan pohjalta.
2. 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)
3. 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).
4. 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
5. 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…

Design Management Review omistaa palvelumuotoilulle koko talvinumeronsa.

Thomas Walton kuvaa artikkelissaan It’s All About Service IDEO:n innovointiprosessia:

The first steps involve the ability to be expansive and “letting go of reality.” Once this yields a rich portfolio of promising ideas, the IDEO framework shirts gears toward prototyping and rigorous testing. This also involves gathering market insights on customers, the business in general, and current technology. These are thorough, nuance-rich explorations that reveal opportunities for growth and genuinely innovative ways to meet needs. Next, corporate leaders and front-line personnel collaborate to model new service propositions that, in a third stage, are on the cutting-edge and evaluated for desirability, viability, and economic feasibility. In the last two phases of this effort, metrics are devised to appraise success and time, and resources are allocated to fail and retool. This involves releasing a pilot and running it through its paces. Refinements are made and, finally, plans for a large-scale rollout are carefully plotted.

Samassa artikkelissa kirjoittaja kertoo Molecular-nimiselle yritykselle työskentelevän Brian Gillespien suosituksia Internet-palveluiden inkrementaaliseen suunnitteluun:

He stresses the advantages of building sites incrementally rather than all at once. Providing well-organized information can attract and help retain customers, while more-complex international transactional capabilities such as e-commerce, contact options, and an extranet can be added later. Irrespective of this possibility, all sites should embody the brand and engage the spectrum of customer profiles. Research is fundamental to determining these profiles, as well as variations in consumer needs and desires.

Eli tehdään perustyö huolellisesti, mietitään kohderyhmät ja viestinnälliset asiat jo ensi vaiheessa, mutta ei pyritä toteuttamaan sivustoa koko laajuudessaan yhdeltä istumalta.

Samansuuntaisia ajatuksia on pyöritelty myös töissä, ja tuntuisi, että jonkinlainen yhdistelmä perusasioiden huolellista määrittelyä ja toteutuksen ketteryyttä voisi tuoda fiksuja tuloksia nopeasti ja kustannustehokkaasti. Varsinaisia teknisiä esteitähän perussivuston nopeallekin toteutukselle ei juuri nykypäivänä ole (tai ainakaan pitäisi olla), kun käytössä on pitkälle kehitettyjä julkaisujärjestelmiä.

Täytyypä perehtyä lehden tarjontaan paremmin paremmalla ajalla…

[via Design for Service]