Käyttöliittymien HUIMA-suunnittelumallin ensimmäinen varsinainen toiminnallinen vaihe on sivukartan luominen. Tätä vaihetta on edeltänyt vaatimusmäärittelyn dokumentointi ja siitä johdettujen käyttötapausten listaaminen. Käyttötapaukset ovat pääosassa HUIMA-malliin pohjautuvassa käyttöliittymäsuunnittelussa. Ne luetellaan ja ryhmitellään aluksi suuriin kokonaisuuksiin, joita esimerkkisovelluksessani tunnistettiin seitsemää eri laatua.

Käyttötapauksista sivukarttaan

Vaatimusmäärittelydokumentti luetaan huolellisesti. Siitä tunnistetaan ensin käyttötapaukset, mutta ei liian tarkalla tasolla. Käyttötapausten ryhmistä laaditaan karkea sivukartta. Yksinkertaisimmillaan kartta laaditaan piirtämällä lyijykynällä ruutupaperille vain otsikoituja laatikoita (kuva 2). Ensimmäisellä kierroksella sivuja saattaa syntyä enemmän kuin mitä niitä on lopullisessa toteuttavassa sovelluksessa. Tärkeintä on kuitenkin tunnistaa käyttötapauksien pohjalta mahdolliset sivuehdokkaat. Ylimääräiset sivut yhdistyvät prosessin edetessä, ja sivukarttaan saattaa tulla vielä uusia sivuja suunnittelun tarkentuessa. Sivukartan tavoitteena on hahmottaa tulevaa sovellusta sekä alkaa vähitellen tunnistamaan käyttöliittymään tarvittavia osia ja komponentteja.

Sivukartan laatimista voi verrata aivoriihen työskentelyyn. Kaikki sivuehdokkaat ovat sallittuja ja tervetulleita. Seuraavalla kierroksella ehdokkaat ryhmitellään ja samankaltaiset sivut yhdistetään. Blogisovelluksen sivukarttaan on ehdolla esimerkiksi seuraavia sivuja:

• etusivu,
• blogikirjoituksen esityssivu,
• kommentointisivu,
• hakusivu,
• kirjoittajan esittelysivu,
• hallinnointisivu,
• artikkelin kirjoitussivu,
• kommenttien käsittelysivu,
• esittelysivun käsittelysivu ja
• sisäänkirjautumissivu.

Jokaista sivuehdokasta vastaa jokin suuremman luokan käyttötapaus vaatimusmäärittelyssä. Esimerkiksi hakusivua vastaa määrittelyssä vaadittu ominaisuus, jossa pitää pystyä hakemaan blogin arkistosta kirjoituksia. Määrittelyssä on niin ikään vaadittu, että etusivulla pitää esitellä muutamia uusimpia kirjoituksia. Blogin ylläpitämiseen liittyy hyvin luonnollisena osana tietysti itse blogikirjoituksien eli artikkelien kirjoittaminen. Vaatimuksissa vaaditaan tyypillisesti myös mahdollisuutta jo olemassa olevien artikkelien muokkaamiseen ja poistamiseen. Uuden lisääminen, vanhan muokkaaminen ja poistaminen ovat kaikki eri käyttötapauksia, mutta käyttöliittymän suunnittelun alkuvaiheessa nämä voidaan hyvin yhdistää yhdeksi isoksi kokonaisuudeksi, jota kutsutaan yksinkertaisesti vain muokkaukseksi tai käsittelyksi. Suunnittelun edetessä myös yksityiskohtaisemmat käyttötapaukset otetaan huomioon.

Sivukartan ensimmäisellä luonnostelukierroksella ei saa kiinnittää liikaa huomiota yksityiskohtiin. Tällä kierroksella ei siis saa vielä alkaa miettiä sivun ulkoasua tai mistä osista sivut koostuvat. Näihin yksityiskohtaisempiin osiin paneudutaan HUIMA-mallin seuraavissa vaiheissa, jolloin sivut alkavat samalla saada sisältöä. Tulevissa vaiheissa ja kierroksissa saattaa löytyä lisää tarpeellisia sivuja, jotka lisätään sivukarttaan. Sivujen välisiin suhteisiin tai siihen, miten sivulta toiselle siirrytään, ei myöskään kannata keskittyä vielä tässä vaiheessa. Sivulta toiselle siirtymiset ovat oikeastaan enemmän toiminnallista suunnittelua kuin käyttöliittymäsuunnittelua, vaikka siirtymiset edellyttävätkin käyttöliittymältä toimenpiteitä.

Valmis sivukartta on sovelluskehityksen näkökulmasta erittäin käyttökelpoinen työväline. Sivukartta on ennen kaikkea toteuttajien apu, sillä siitä näkee, mitä kaikkia sivuja ja toiminnallisuuksia sovellukseen tulee. Karttaa kannattaa käyttää myös projektisuunnittelussa, sillä eri sivut voidaan jakaa eri toteuttajille tehtäviksi. Projektin aikataulutus helpottuu sivukartan myötä, jolloin käyttöliittymän valmistuminen voidaan jopa ennustaa.