Tommi oli soveltanut Valtioneuvoston julkaisemaa Käyttöliittymäsuunnittelun tyyliopasta HelMet-kirjastojärjestelmään, joka on tuttu seminaarin aiemmista esityksistä. Tommin lähestymistapa oli, että hän laati tyylioppaan pohjalta oman kokoelman sääntöjä HelMetin käyttöliittymän uudistamiseksi - toisin sanoen hän loi oman version ohjeistosta tätä nimenomaista uudistamisprojektia varten.
Heti alkuun nousi esille kysymys käyttöliittymäohjeiston käyttötarkoitus ja tapa, jolla ohjeet on esitetty. Keskustelussa todettiin, että
Ohjeisto on kirjoitettu aika korkealla abstraktiotasolla. Se toimii siksi parhaiten muistilistana asiantuntijalle. Sitä ei ole kovin mielekästä käyttää irrallaan käytettävyystietämyksestä - pelkillä ohjeistoilla ei tehdä hyviä käyttöliittymiä vaan tarvitaan myös asiantuntemusta. Yksi hyvä puoli ohjeistoissa on se, että niihin voi tarvittaessa vedota, jos jokin käyttöliittymäratkaisu aiheuttaa närää. Kun esimerkiksi suunnitellaan käyttöliittymää Valtioneuvoston alaiselle organisaatiolle (esim. jokin ministeriö tai virasto), niin on kätevää, kun voi sanoa että "tehdään näin koska VN:n ohjeisto vaatii" - paljon helpompi kuin esim. viitata johonkin Nielsenin heuristiikkaan josta kukaan projektissa ei ole kuullutkaan...
Tommi oli poiminut omaan versioonsa ohjeistosta keskeisimmät asettelusäännöt tyylioppaasta ja täsmentänyt niitä mm. määrittämällä mihin sivun alueisiin HelMet-järjestelmän eri toiminnot tulee sijoittaa. Tätä ohjetta noudattamalla monet HelMetin toiminnot tulisivat näkyviin (lähes) kaikilla sivuilla, kun siinä tällä hetkellä näkyvissä on yleensä vain osa toiminnoista.
Esimerkiksi kielivalinta täytyy HelMetissä tehdä etusivulla, myöhemmin kieltä ei voi vaihtaa palaamatta takaisin etusivulle. Tommin versiossa kieltä voi vaihtaa koska tahansa: esimerkkitapauksessa ruotsinkielinen käyttäjä käyttää järjestelmää aluksi suomeksi, koska ei viitsi vaihtaa kieltä, mutta törmää seinään kun ei ymmärrä mitä tarkoittaa "nideluokka". Uudessa versiossa hän voisi lennossa vaihtaa kieltä ongelman selvittämiseksi (tässä tapauksessa ruotsinkielinen versio "hyllplats" eli hyllypaikka on muuten oikeastikin paljon helpompi tajuta kuin "nideluokka" - ehkä perimmäinen ongelma onkin tässä huonosti valittu suomenkielinen nimitys?).
Tommin poimimat ohjeet (oleellinen tieto ensin, tiedon ryhmittely asiakokonaisuuksiin, selkeä otsikointi) tuovat hyvin esiin ohjeiston subjektiivisuuden, kuten jo edellä on todettu. Kaikkia ohjeita ei voi soveltaa tiukasti, koska ne ovat osittain ristiriitaisia, ja kompromissien tekeminen vaatii suunnittelijalta kokemusta ja ammattitaitoa.
Pitkien hakutulosten jakaminen useille näytöille herätti keskustelua: miksei näytetä kaikkia tuloksia kerralla? Syyt löytyvät web-teknologian rajoitteista: pitkä lista aiheuttaa pitkän latausajan ja vie paljon tilaa ruudulla. Toisaalta käyttäjän tavoitteen voi yleensä toteuttaa näyttämällä vain osan tuloksia. Keskusteltiin siitä, olisiko jatkuva filtteröinti parempi vaihtoehto kuin sivuttaminen. Saattaisi ollakin, mutta sen toteuttaminen webissä on ainakin toistaiseksi aika työlästä. Teknologia pakottaa tekemään kompromisseja, joita joudutaan arvioimaan käyttäjän tavoitteiden valossa.
Yksi konkreettinen ehdotus HelMetin parantamiseksi on työkaluvihjeiden lisääminen. Kalvojen esimerkki (Hae-painikkeeseen vihje "Käynnistä haku") ei ehkä kuitenkaan pureudu mihinkään todelliseen ongelmaan, koska vihjeen lisääminen tuskin auttaa valaisemaan jo valmiiksi varsin ilmeisen nappulan toimintaa. Sen sijaan toinen esimerkki siitä, että käyttäjän yhteystiedoissa tulisi kertoa tietojen julkisuus (ehkä myös käyttötarkoitus?) voisi tarjota konkreettista hyötyä käyttäjälle, joka muuten voi empiä henkilötietojen antamista järjestelmän käyttöön.
Lomakkeita koskevat, varsin yleisen tason ohjeet pureutuivat jossain määrin HelMetin varauslomakkeen ongelmiin. PIN-koodikenttä on selvästi liian leveä, jolloin se antaa virheellisen kuvan toivotun syötetekstin pituudesta. Aiemmissa tutkiskeluissa ongelmalliseksi todettu noutokirjaston valinta tulisi ohjeistuksen mukaan toteuttaa toisella tavalla, esim. esittää valinta kirjaston ja kirjastoauton välillä radionapein. Pysäkkikenttä on myös ohjeistojen valossa aivan liian suuri. On silti epäselvää, olisivatko ohjeiston ehdottamat korjaukset korjanneet kaikkia lomakkeen käytettävyysongelmia.
Ohjeisto suosittaa välilehtien käyttöä HelMetin vaihtoehtoisten hakulomakkeiden välillä navigointiin. Nykyinenkin järjestelmä on jaettu välilehtiin toiminnallisessa mielessä, mutta visuaalinen ilme ei muistuta ollenkaan välilehtiä.
Tähän osaan ohjeistusta on koottu paljon yksityiskohtaista pikkuohjetta. Tommi ehdottaa parannuksia mm. aineistohakulomakkeeseen (lisäys: tietojen järjestäminen ilmestymisvuoden mukaan) sekä kirjautumislomakkeen virheenkäsittelyyn.
Keskustelussa todettiin, että ohjeistuksen tapa määritellä toiminnallisuutta nippelitasolla on ongelmallinen. Ohjeisto on tehty yleispäteväksi eikä se siis ota huomioon sovelluksen käyttötarkoitusta tai käyttäjien tavoitteita/tehtäviä. Näin ollen korkean tason toimintojen toteuttamista (esim. kirjan löytäminen) ei ole määritelty ollenkaan, mutta esim. hakukielen syntaksi on määritelty hyvinkin tarkasti. Sovellusalariippumattomalla ohjeistolla voi siis "tehdä geneerisiä sivustoja jotka eivät oikeasti sovellu mihinkään".
Tämä osa Tommin ohjeistoa jäi ajan puutteen vuoksi käsittelemättä.
Parhaimmillaan käytettävyysohjeisto helpottaa suunnittelutyötä, koska monien yksityiskohtien suunnitteli on jo puoliksi tehty. Esim. asettelumalli antaa lähtökohdan, jonka perusteella sivuston elementtien sijoittelua voi suunnitella tarkemmin ilman että tarvitsee aloittaa tyhjästä. Ohjeisto voi myös välittää kokeneiden suunnittelijoiden (ohjeiston kirjoittajat) asiantuntemusta kokemattomammille. Sitä voi myös käyttää arvioinnin apuvälineenä, esim. VN:n ohjeisto sisältää konkreettisten ohjeiden lisäksi listan arviointiheuristiikkoja.
Kun samalla ohjeistuksella tehdään monta toisiinsa liittyvää sovellusta, saadaan (toivottavasti) niille yhtenäisempi ilme.
Ohjeiston ongelmia on jo käsitelty edellä. Eräs keskeinen ongelma on se, että ohjeisto käsittelee pääsääntöisesti vain yksittäisiä näyttöjä eikä näin ollen kerro mitään käyttäjien poluista. Tehokkuusongelmiin ohjeisto puree huonosti.
Ohjeisto ei myöskään kerro juuri mitään sivuston rakenteen ja keskeisten osioiden suunnittelusta tai siitä, mitä etusivulla pitäisi olla. VN:n ohjeistus tosin luettelee joukon vakiosivuja (esim. tietoja sivustosta, palautelomake) joiden toteuttamista suositellaan tai joissain tapauksissa vaaditaan. Ohjeisto myös edellyttää hakutoiminnon toteuttamista, mutta muutoin se ei juuri ota kantaa siihen, mitä toimintoja järjestelmässä tulisi olla tai miten käyttäjää ohjataan pääsemään tavoitteisiinsa. Näin ollen ohjeistuksen hyödyllisyys suunnittelussa jää aika kyseenalaiseksi.
Lopuksi keskusteltiin siitä, olisiko HelMet-järjestelmä oleellisesti parantunut ohjeistoa soveltamalla. Jotkin lomakeongelmat olisivat ainakin osittain ratkenneet kuten edellä on todettu. Puuttuva toiminnallisuus jäisi edelleen puuttumaan. Toistuvaan kirjautumiseen tämä nimenomainen ohjeisto ei puuttuisi, mutta esim. Nielsenin esittelemä ohjeisto vuodelta 1986 olisi korjannut tämän ongelman.
Tommin lähestymistapa - oman hiukan sovellusalakohtaisemman ohjeiston kirjoittaminen geneerisen ohjeiston pohjalta - olisi ehkä sopinut paremmin tilanteeseen, jossa olisi tarkoitus uudistaa useiden eri kirjastojärjestelmien käyttöliittymiä. Nyt menetelmä oli ehkä liian työläs ja oman ohjeiston tekemisen sijaan olisi kenties kannattanut panostaa siihen, että valmista ohjeistoa olisi suoraan sovellettu HelMet-järjestelmään siltä osin kuin se oli mahdollista. Tämä olisi ehkä valaissut paremmin ohjeistopohjaisen arvioinnin mahdollisuuksia. Toisaalta tälläkin tavoin varmasti saatiin selville ohjeistojen keskeisimmät hyvät ja huonot puolet.