Kehittämisen aikana

Kehittämisen aikana

Oletko kehittämässä digitaalista palvelua?

Tälle sivulle on koottu keskeiset vaiheet ja vinkit digitaalisen palvelun kehittämiseen. Erityisesti materiaali on suunnattu tuoteomistajille ja projektipäälliköille, jotka luotsaavat kehittämistä.

Kehittäminen alkaa palvelumuotoilusta, jossa tutkitaan nykytilan haasteita ja asiakkaiden tarpeita. Sitten luodaan palvelun konsepti, jota testataan käyttäjillä prototyypin avulla. Kehittäminen etenee minimitoteutuksen (MVP) rajaamiseen, kehitysjonon muodostamiseen ja käyttöliittymäsuunnitteluun. Toteutuksessa tuoteomistaja ohjaa ohjelmistokehitystiimin työtä.

Kuvitettu innostunut hahmo

Hyödynnä palvelumuotoilua ja kehitä ketterästi

Digitaalisen palvelun kehittäminen alkaa palvelumuotoilulla ja etene kohti ketterää ohjelmistokehitystä. Tälle sivulle on koottu kattava opas tuoteomistajalle kehittämisen jokaiseen vaiheeseen:

  1. Palvelumuotoilun käynnistäminen
  2. Tutkimusvaihe
  3. Palvelun konsepti eli tuotevisio
  4. Käyttökokemuksen (UX) suunnittelu
  5. Minimitoteutuksen (MVP) rajaaminen
  6. Käyttöliittymäsuunnittelu (UI) ja uusien ominaisuuksien määrittely
  7. Ketterä ohjelmistokehitys – kehitysjono ja MVP-toteutus

Hei uusi tuoteomistaja!

Tuoteomistaja tarvitsee ympärilleen kehitystiimin ja kehittämisen verkoston. Kehitystiimiin kuuluu palvelun kehittämisen eri vaiheissa mm. palvelumuotoilijoita, käyttöliittymäsuunnittelijoita (UX/UI designer), sisältömuotoilijat, ohjelmistokehittäjiä ja arkkitehteja. Lisäksi palvelun kehittämiseen tarvitaan mukaan palvelun ja substanssin asiantuntijoita, johtoa, asiakaspalvelun henkilökuntaa, erilaisia sidosryhmiä, ja asiakkaiden edustajia. Tuoteomistaja vastaa kehitystiimin ja verkoston kokoamisesta ja aktiivisesta viestinnästä.

Kuvitettu hehkulamppu

Palvelumuotoilun käynnistymisvaihe

Varaa tähän vaiheeseen vähintään 2 viikkoa työaikaa.

  1. Tarkenna palvelumuotoilun toimeksianto projektikuvauksen tai muotoilubriiffin avulla, jotta kaikilla osapuolilla on selkeä käsitys tavoitteista. Validoi briiffi johdolla ja palvelun asiantuntijaverkostolla. Briiffi ei kannata hioa loputtomiin, vaan sitä voi tarkentaa tulevina viikkoina. 
    Lataa projektikuvauspohja
    Lataa muotoilubriiffipohja
    Katso esimerkkejä hel.fi muotoilubriiffeistä (tulossa)
  1. Sovi työsuunnitelmasta yhdessä muotoilutiimisi kanssa. Työsuunnitelmaan kirjataan mm. aikataulu ja työtavat.
    Löydät työsuunnitelmaa varten pohjia muotoilubriiffistä
    Tutustu työtapasopimukseen Confluencessa (tulossa)
  1. Aloita yhteinen projekti ydintiimin tutustumistapaamisella ja laajemman verkoston kick-off tilaisuudella. 
    Vinkit ja pohjat tutustumistapaamiseen
    Tutustu hel.fi kick-off esimerkkeihin
  1. Palvelumuotoilijat laativat tutkimussuunnitelman sisäistä kartoitusta ja asiakastutkimusta varten. Suunnitelma on hyvä validoida tai esitellä palvelun substanssiasiantuntijoille. Auta sidosryhmien ja asiakkaiden tunnistamisessa. Tutkimusosallistujien rekrytoinneissa ja sisäisten haastattelujen kalenteroinnissa tarvitaan myös apua. 
    Katso asiakastutkimuksen valmennusmoduuli
    Tutustu virtuaaliseen asiakasyhteisöön
    Lataa tutkimussuunnitelman pohja (tulossa)
    Tutustu hel.fi tutkimussuunnitelmiin (tulossa)
    Lue vinkit osallistujien rekrytointiin (tulossa)
    Lue blogi nykytilan kartoituksesta (vinkkejä sisäiseen tutkimukseen) (tulossa)

Ymmärrä ensin ongelma, sitten vasta ratkaisu! Miksi?

  • ratkaistaan oikea ongelma – etsi nykytilan haasteiden juurisyyt
  • ongelmat ymmärretään organisaation ja asiakkaiden näkökulmista usein eri tavoin
  • asiakkaiden tarpeiden kartoittamiseksi tarvitaan ensin asiakasymmärrystä
  • asiakasymmärrys on laadullista ja määrällistä tietoa asiakkaiden arjesta, motivaatioista ja käyttäytymisestä
  • palvelumuotoilu tähtää syväluotaavaan asiakasymmärrykseen, joka auttaa ratkaisun tarkemmassa muotoilussa.
Kaksi piirroshahmoa ihmettelee maailman menoa

Palvelumuotoilun tutkimusvaihe

Palvelumuotoilun tutkimusvaihe tähtää oikean ongelman tunnistamiseen ja erilaisten käyttäjäryhmien tarpeiden kartoittamiseen. Tätä tietoa hyödynnetään seuraavassa vaiheessa ratkaisun muotoilussa eli palvelun konseptin suunnittelussa. Varaa tutkimusvaiheeseen vähintään kuukausi työaikaa.

Olemme koostaneet laajan oppaan asiakastutkimukseen osana hel.fi-uudistushanketta.

Asiakastutkimuksen oppaassa on tietoa mm.

  1. Asiakastutkimuksen hyödyistä sekä laadullisen ja määrällisen tutkimuksen eroista
  2. Asiakastutkimuksen ja -testauksen toimintamallista
  3. Tyypillisten tutkimusmenetelmien ja -tuotosten esittely, esim. palvelupolut, palvelumallit (service blueprint), käyttäpersoonat ja asiakasprofiilit
  4. Vinkit kiteyttämiseen eli tutkimuksen analyysivaiheseen
  5. Tutkimusraporttiesimerkkejä
  6. Virtuaalisen asiakasyhteisön eli leanlabin esittely

Tuoteomistajan rooli tutkimusvaiheessa

  • etsi ja jaa taustamateriaaleja ja olemassa olevaa asiakasymmärrystä
  • pohdi tutkimustarpeita – mitä emme vielä tiedä?
  • auta tutkimuksen markkinoimisessa ja kohderyhmien tavoittamisessa
  • osallistu rohkeasti asiakasyhteisön keskusteluun ja seuraa tutkimuksen etenemistä
  • osallistu haastatteluihin havainnoimaan ja tekemään muistiinpanoja
  • osallistu tutkimusseinän kokoamiseen ja datan purkamiseen
  • tutustu tarkasti tutkimuksen tuloksiin ja omaksu havainnot – tutkimustulokset ovat työkalu palvelun kehittämisessä ja auttavat muistamaan, mikä on asiakkaalle tärkeää. Tutkimustulokset auttavat sinua perustelemaan monia valintoja.
  • kalenteroi tutkimustulosten esittely asiantuntijaverkostolle ja johdolle

Vaikeasti tavoitettava kohderyhmä?

Kun kyseessä on vaikeasti tavoitettava kohderyhmä, tutkimusta voi tehdä suoraan prototyypin avulla, kokeillen.

Varmista, että palvelussasi toteutuu yhdenvertaisuus, saavutettavuus ja osallisuus. Inkluusion huomioiminen digitaalisen palvelun suunnittelussa:

  • Kerää asiakasymmärrystä laaja-alaisesti.
  • Mahdollista erilaisten kaupunkilaisten osallistuminen kehittämiseen.
  • Varmista saavutettavuus ja käytettävyys testaamalla.
  • Huomioi myös sisältöjen ymmärrettävyys.
Piirretty hahmo sanoo Hienoa!

Kokonaisarkkitehtuuri tunnistaa nykytilan haasteita ja mahdollisuuksia

Palvelumuotoilussa kannattaa olla mukana arkkitehti, joka osallistuu tutkimusvaiheessa nykytilan kartoittamiseen. Arkkitehtien osaamista on kuvata prosesseja, järjestelmiä ja tietovirtoja. Näiden avulla ymmärrät paremmin, millaiseen kontekstiin palvelu sijoittuu. Arkkitehtuurin avulla huomaat, millaisia haasteita ja reunaehtoja järjestelmät luo, ja miten voit hyödyntää dataa ja rajapintoja. Samalla löydät jo tässä vaiheessa mahdollisuuksia esimerkiksi automaatioon tai teknologian hyödyntämiseen.

Kuvitettu hehkulamppu

Palvelun konsepti eli tuotevisio

Palvelumuotoilun konseptointivaiheessa suunnitellaan palvelun tuotevisio. Varaa tähän vaiheeseen vähintään 1 kuukausi työaikaa. Tässä vaiheessa tuoteomistajan rooli muuttuu ja otat enemmän vastuuta palvelun kehittämisen suunnasta.

Palvelun konsepti tai tuotevisio tarkoittaa palvelun ylätason ja pidemmän tähtäimen visiota. Konsepti on kuvaus ratkaisusta ja tavoitetilan asiakaskokemuksesta.

  1. Visio kiteyttää palvelun olemassa olon tarkoituksen niin asiakkaiden kuin organisaationkin näkökulmista.
  2. Visio kuvaa palvelun tavoitetilan asiakaskokemuksen ja saumattoman palvelupolun tavoitetason.
  3. Visio kiteyttää tuoteomistajan työkaluksi kuvauksen, joka avulla palvelua voi kehittää myös ensijulkaisun jälkeen.
  4. Konsepti kuvaa riittävällä tasolla tuotannon näkökulmia, esimerkiksi palvelumallin tai ylätason arkkitehtuurikuvauksen.
  5. Konsepti määrittelee palvelun tavoitteet ja keskeiset mittarit.
  6. Konseptiin kuuluu usein arvolupaus, suunnitteluperiaatteet, priorisoidut ideat palvelun ominaisuuksista sekä palvelun sivukartta.
  7. Yksinkertaisimmillaan palveluvisio voi olla yksi dia tai laajimmillaan 100-sivuinen konseptidokumentti. Valitse omaan projektiin ja aikatauluun sopiva tuotos.

Älä ulkoista kokonaan!

Tuoteomistajana tärkein tehtäväsi on johtaa palvelun konseptia ja tuotevisiota. Jos ulkoistat konseptoinnin täysin, saattaa lopputuloksena olla konsepti, joka ei sovellu organisaatiomme käyttöön eikä vastaa palvelun tavoitteita.

Piirretty hahmo ja kysymysmerkki.

Tuotevision suunnittelussa on paljon mikropäätöksentekoa ja suunnan hakemista, johon tuoteomistajaa tarvitaan aktiivisesti mukaan.

Palvelun konseptoinnissa on myös tärkeää varmistaa asiakkaiden ja palvelun asiantuntijoiden ja sidosryhmien riittävä osallistuminen, jotta konseptista tulee riittävän hyvä ja yhteinen.

Palvelun konseptin suunnittelu

Konseptin suunnittelu alkaa haasteen rajaamisesta eli tutkimusvaiheen tulosten priorisoinnista – mihin haasteisiin halutaan keskittyä, mihin haasteisiin uuden palvelun tulisi erityisesti vastata? Lisäksi valitaan ja kiteytetään suunnitteluperiaatteet (design drivers), jotka auttavat arvioimaan ratkaisuaihioiden arvoa ja priorisoimaan ideoita peilaten asiakasymmärrykseen ja erilaisiin tarpeisiin.

Lue lisää haasteen rajaamisesta (blogi) (tulossa)
Lue lisää suunnitteluperiaatteista (tulossa)
Selaa esimerkkejä hel.fi suunnitteluperiaatteista (tulossa)

Tässä palvelumuotoilun vaiheessa kehittämisen malli tuplatimantti lähtee taas laajentumaan, eli ideoinnilla haetaan paljon erilaisia mahdollisuuksia haasteiden ratkomiseksi ja palvelun suunnittelun tueksi. Ideoinnissa palvelumuotoilu hyödyntää monia erilaisia luovia menetelmiä, jotka vaativat tuoteomistajalta ja palvelun asiantuntijoilta heittäytymistä. Ole siis rohkea ja näytä esimerkkiä muille.

Ideointiin kannattaa hyödyntää erilaisia menetelmiä, kuten benchmarkkausta, ideointityöpajaa ja rautalankahahmottelua. Palvelumuotoilun ideointityöpaja on hauska ja tehokas tapa tuottaa ideoita yhdessä palvelun substanssiasiantuntijoiden, kehitystiimin ja asiakkaiden kanssa. 

Tutustu hel.fi ideointityöpajan runkoon, menetelmiin ja pohjiin (tulossa)

Kun projektissa on kasassa riittävä määrä ideoita, on aika priorisoida ja jatkokehittää ideoita. Viime kädessä parhaat ideat tulee kuvata ja hahmotella rautalangoiksi, jotta niitä voi peilata palvelun tavoitteisiin, suunnitteluperiaatteisiin ja testata aidoilla käyttäjillä. 

  1. Nappaa talteen kaikki ideat ns ideabacklogiin, joka on ryhmitelty lista ideoista ja niiden kuvauksista.
  2. Arvioi ja priorisoi ideoita. Voit hyödyntää arvioinnissa erilaisia muotoilun menetelmiä sekä peilata ideoita palvelun kokonaistavoitteisiin ja suunnitteluperiaatteisiin – toteuttaako idea näitä? Voit myös hyödyntää perinteisiä priorisointikehyksiä, kuten toteutettavuus/kustannus vs. asiakasarvo/hyöty nelikenttää.
  3. Tarkenna ja yhdistele ideoita. Hahmottele rautalangat ja kuvaa tarkemmin, mikä ideassa on keskeistä.

Ota ohjelmistokehittäjät ja arkkitehdit mukaan jo ideointivaiheessa!


Usein nämä asiantuntijat näkevät erilaisia digitalisaation mahdollisuuksia, miten jokin tarve tai haaste voidaan ratkaista aivan uudella tavalla. Nämä asiantuntijat ymmärtävät myös järjestelmien ja arkkitehtuurin rajoitteita ja reunaehtoja sekä pystyvät arvioimaan ideoiden toteutettavuutta.

Piirretty hahmo ja kysymysmerkki.

Hyödynnä käyttäjätarinamenetelmää palvelumuotoilusta ketterään toteutukseen asti! Käyttäjätarinat auttavat palvelun kehittämisen eri vaiheissa konkretisoimaan palvelun ja käyttäjän vuorovaikutusta. Käyttäjätarina kiteyttävät, mitä palvelu antaa käyttäjälle.

Lue lisää käyttäjätarinamenetelmästä Confluencessa (vaatii tunnukset)

Käyttökokemuksen suunnittelu

Käyttökokemus eli UX (user experience) on keskeinen osa digitaalisen palvelun suunnittelua. Kaupungilla on yhteinen kokonaiskonsepti digitaalisten palvelujen asiakaskokemuksesta ja käyttökokemuksen kulmakivet löytyvät Helsinki Design Systemistä. Tuoteomistajan tehtävä on varmistaa oman palvelun erinomainen käyttökokemus ja tässä tukena ovat käyttökokemus- ja käyttöliittymäsuunnittelijat (UX/UI designerit). Varaa tähän vaiheeseen aikaa 1-3 sprinttiä, mutta muista säästää suunnittelijoiden työaikaa myös toteutusvaiheeseen.

Käyttökokemuksen suunnittelussa suunnitellaan mm.

  • suunnitteluperiaatteet, jotka kiteyttävät erinomaisen käyttökokemuksen kulmakivet
  • käyttäjäpolku (user flow), joka kuvaa miten käyttäjä liikkuu palvelun sisällä
  • käyttöliittymän ominaisuudet, eli miten käyttäjä hoitaa asiansa palvelun sisällä

Keskeinen työkalu käyttökokemuksen suunnittelulle on prototyypit ja käyttäjätestaukset. Käyttökokemuksen suunnittelu jatkuu käyttöliittymien suunnitteluun, joka on tarkempi vaihe lähellä ohjelmistokehitystä. Käyttöliittymäsuunnittelussa tehdään ns. tuotantoleiskat eli pikselin tarkat kuvat käyttöliittymistä ohjelmistokehitystä varten. Ennen tätä vaihetta on kuitenkin tärkeää testata käyttökokemuksen vaihtoehtoja ja rajata minimitoteutus, jotta ei tehdä turhaa työtä. 

Miten käyttökokemus ja asiakaskokemus eroaa? (tulossa)
Mitä käytettävyys tarkoittaa? (tulossa)
Miten käyttökokemus, käytettävyys ja saavutettavuus liittyvät toisiinsa? (tulossa)
Erilaiset prototyypit (tulossa)
Tutustu konseptin validointiin ja käyttäjätestausten ohjeisiin
Tutustu Helsinki Design Systemiin
Lue lisää minimitoteutuksen rajaamisesta (tulossa)

Hyödynnä Helsinki Design Systemiä!

Kaupungilla on jo valmiiksi paljon erilaisia käyttökokemusratkaisuja ja käyttöliittymien rakennuspaloja Helsinki Design Systemissä (HDS).

Vältä siis turhaa työtä ja katso ensin, mitä on jo valmiiksi saatavilla. Varmista, että kehitystiimisi suunnittelijat hyödyntävät HDS:iä.

Suunnittelijoille ja ohjelmistokehittäjille on tarjolla perehdytystä, ole yhteydessä Kehittämisen tukeen.

Mitä jos tekisit prototyypin suoraan aitoon palveluun?

Esimerkiksi verkkosivujen suunnittelussa prototyyppejä on helppo tehdä kaupungin olemassaolevilla Drupal- ja WordPress-tuotteilla. Näiden tuotteiden avulla prototyypin voi tehdä myös sisällöntuottaja. Tällä tavoin säästetään aikaa ja rahaa.

Tutustu Drupal-sisällöntuottajan oppaaseen

Tutustu WordPress-itsepalveluportaalin ohjeisiin

Sivukartta ryhdittää palvelun toteutusta

Sivukartta on tuoteomistajan tärkeimpiä työkaluja palvelun kehittämisen ohjauksessa ja toteutuksen suunnittelussa. Seuraavat periaatteet kiteyttävät, mistä sivukartassa on kyse:

  1. Sivukartta kuvaa palvelun toteutuksen sivuina hierarkiassa. 
  2. Sivukartta muodostaa myös pohjan palvelun navigaatiolle.
  3. Sivukartta tukee löydettävyyttä, kun palvelun aiheet on ryhmitelty osioiksi ja sivuiksi käyttäjälähtöisesti
  4. Sivukartta kuvaa kunkin sivun tarkoituksen ja keskeisimmän käyttäjätarinan.
  5. Sivukarttaa on hyvä työstää vaiheittain. Sivukartan luonnoksia kannattaa työstää yhdessä kehitystiimin ja substanssiasiantuntijoiden kanssa. Sivukartan aihiota voi myös testata käyttäjillä esim. card sorting, treejack- tai A/B-testausmenetelmillä.
  6. Sivukartan lisäksi käyttäjäpolku (user flow) kuvaa esimerkiksi kaaviona, miten käyttäjä etenee ja navigoi palvelun käyttöliittymän sisällä. 
  7. Sivukartasta on hyvä tehdä minimitoteutuksen versio ja palveluvision versio. Palvelun tiekarttaan kuvataan sitten, miten palvelun toteutus etenee vaiheittaa ensijulkaisusta seuraaviin versioihin.

Tutustu esimerkkeihin hel.fi sivukartoista (tulossa)
Lue ohjeet sivukartan tekemiseen ja lataa pohjat (tulossa)

Huomioithan kanavalinjaukset!

Kaikkia kaupungin digitaalisia kanavia velvoittaa kanavalinjaukset. Varmista, että tuoteomistajana tunnet linjaukset ja toimit niiden mukaisesti. Kaupungin kaikki digitaaliset kanavat tulee sijoittaa yhteiseen informaatioarkkitehtuuriin (IA), sillä olemme linjanneet, että jokainen sivusto ja palvelu löytyy yhdestä paikasta. 

Tutustu kanavalinjauksiin
Tutustu kaupungin informaatioarkkitehtuuriin (tulossa)

Kuvitettu hehkulamppu

Minimitoteutuksen (MVP) eli ensijulkaisun rajaus palvelumuotoilussa

Minimum viable product eli MVP on ketterän kehityksen termi, joka kuvaa palvelun minimitoteutusta eli ensijulkaisua. MVP on pienin mahdollinen asiakasarvoa tuottava versio palvelusta. Toteuttamalla ensin MVP:n, palvelua voidaan kehittää jatkuvasti palautteen perusteella.

Lue lisää MVP-ajattelusta (tulossa)

Millä tavalla ensijulkaisua tulisi rajata jo palvelumuotoilussa?

MVP-dokumentaatio auttaa tuoteomistajaa ensijulkaisun toteutuksen ohjaamisessa. Seuraavat tuotokset kannattaa tehdä osana palvelumuotoilua:

  1. MVPn eli ensijulkaisun arvolupaus, tavoitteet ja mittarit
  2. Käyttäjätarinakartat keskeisistä palvelun osista
  3. Uusien ominaisuuksien listaus ja priorisointi
  4. Käyttöliittymähahmotelmia, esim. prototyyppi, jolla on testattu MVP-rajausta ja ominaisuusideoita
  5. MVP sivukartta

Palvelumuotoilussa kannattaa järjestää MVP-rajauksen käynnistämistä varten työpaja, jossa lähdetään työstämään keskeisiä tuotoksia yhdessä. 

Tutustu hel.fi MVP-rajaustyöpajan runkoon ja pohjiin (tulossa)
Lataa MVP-kanvaasi (tulossa)
Tutustu käyttäjätarinakartta-menetelmään ja lataa pohjat
Katso esimerkkejä hel.fi ominaisuustaulukoista (tulossa)
Hyödynnä Helsinki Design Systemiä prototyypin suunnittelussa
Tutustu sivukartta-menetelmään ja pohjiin (tulossa)

MVP-rajaus tarkentuu ohjelmisto-kehityksessä

MVP-rajaus ei ole palvelumuotoiluvaiheessa vielä riittävän tarkka ohjelmistokehitystä varten.

On tärkeää, että MVP-rajausta jatkotyöstetään yhdessä ohjelmistokehittäjien ja arkkitehtien kanssa. Nämä asiantuntijat ymmärtävät järjestelmien ja arkkitehtuurin reunaehdot ja etsivät teknisellä tasolla minimiratkaisun käyttäjätarpeen toteuttamiseksi. Scrum master on hyvä kutsua mukaan MVP-rajaustyöpajaan palvelumuotoilun aikana.

Käyttäjätarina-kartta auttaa rajauksessa

Käyttäjätarinakartta kertoo, miten käyttäjätarpeet toteutetaan ensivaiheessa ja miten seuraavissa vaiheissa ja tavoitetilassa. Käyttäjätarinakartta yhdistää tuotteen ominaisuudet käyttäjän polkuun. 

Tutustu tarkemmin käyttäjätarinakartta-menetelmään ja lataa pohjat

Käyttöliittymäsuunnittelu ja uusien ominaisuuksien määrittely

Tässä vaiheessa on tärkeää, että ohjelmistokehityksen vaihe on jo käynnistetty. Jos käyttöliittymäsuunnittelu tehdään kokonaan ennen ohjelmistokehitystä ja ilman ohjelmistokehittäjiä eli devaajia, vaarana on, että suunnitelmat vielä muuttuvat ja tehdään turhaa työtä. Käyttöliittymäsuunnittelussa yhdistyy muotoilu ja ohjelmistokehitys – palvelun käyttäjälle näkyvät osat suunnitellaan tarkasti, jotta ne voidaan toteuttaa. Tähän vaiheeseen varattava työaika riippuu täysin ensijulkaisun laajuudesta ja ohjelmistokehityksen monimutkaisuudesta. Pyri kuitenkin, että ensijulkaisuun päästää kuukausissa, ei vuosissa.

Käyttöliittymäsuunnittelussa tulee hyödyntää aina Helsinki Design Systemiä

Helsinki Design Systemin käyttäminen varmistaa, että palvelu on kaupungin linjausten ja tavoitteiden mukainen. Lisäksi säästät aikaa ja rahaa, kun hyödynnät olemassa olevia ratkaisuja. Käyttäjät tunnistavat asioivansa Helsingin kaupungin palvelussa. 

  1. Kaikkien kaupungin digitaalisten palvelujen tulee noudattaa kaupunkiyhteistä digitaalisten palvelujen visuaalista konseptia, joka pohjautuu kaupungin brändiin.
  2. Suunnittelutyö nopeutuu, kun HDS tarjoaa valmiit asetukset ja elementit suunnittelijoille. Kaupungin digitaalisten palvelujen asiakaskokemus on yhtenäinen, kun käyttäjille tuttuja ratkaisuja hyödynnetään laajasti. 
  3. HDSn hyödyntäminen varmistaa käyttöliittymän käytettävyyden ja saavutettavuuden sekä brändinmukaisuuden. 
  4. HDS tarjoaa myös ohjelmistokehitykseen käyttöliittymäkerroksen ohjelmistokoodin. Tällä hetkellä on tarjolla ratkaisuja html (core) ja React muodoissa sekä Drupal ja WordPress-tuotteille.
  5. HDS tarjoaa tällä hetkellä suunnitteluun esimerkiksi keskeiset komponentit, painikkeet, lomakkeet ja navigaation. Lisäksi tarjolla on erilaisia sivupohjia ja “patterneja” eli painiketta laajempia käyttökokemusratkaisuja, kuten suodatushaut ja laskurit. HDS tarjoaa myös tyyppillisten rajapintojen käyttökokemusratkaisuja – esimerkiksi tapahtumien tai palvelukuvaustiedon yhtenäinen esittämistapa tai evästehyväksyntä ovat saatavilla olevia HDS-käyttöliittymämalleja (pattern).

Näin tuoteomistajana varmistat, että tiimisi hyödyntää Helsinki Design Systemiä:

  1. Hanki käyttöliittymäsuunnittelijoita vain kaupungin yhteisistä puitesopimuksista (Palvelumuotoilun ja Osaamiskeskuksen puitesopimukset sekä Dynaaminen puitejärjestely DPS).
  2. Varmista, että suunnittelijat käyvät heti alussa HDS-perehdytyksen ja tutustuvat tarkasti HDS-dokumentaatioon ja liittyvät #designsystem–kanavalle Slackissa. 
  3. Varmista, että suunnittelijoilla on kaikki tarvittavat tunnukset ja ohjelmat käytössään. Helsinki Design System toimii Skecth ja Abstract-pohjaisesti. Toimittaja hankkii oman Sketch-lisenssin, mutta käyttää kaupungin Abstractia. Varmista, että suunnittelija on perustanut palvelullesi selkeästi nimetyn oman projektin Abstractiin. 
  4. Seuraa käyttöliittymäsuunnittelua Abstractissa ja prototyypeissä. Varmista, että olette sopineet sprinttirituaalit tai muut käytännöt, jossa hyväksyt suunnitelmat ennen niiden vientiä toteutukseen. Varmista, että suunnittelijat näyttävät (peer review) käyttöliittymäsuunnitelmia myös kaupungin digitaalisen muotoilun tiimille.

Tutustu hel.fi esimerkkeihin:
Käyttöliittymäsuunnitelmien hyväksymisprosessi (tulossa)
Käyttöliittymäsuunnitelmien laadunvarmistuksen tarkistuslista (tulossa)
Sivupohjien ja komponenttien dokumentaatio Sisällöntuottajan oppaassa

Kun palvelusi vaatii aivan uutta ominaisuutta

Palvelun toteutus saattaa vaatia aivan uusien ominaisuuksien suunnittelua, tällöin tuoteomistaja varmistaa, että uudet ominaisuudet kuvataan riittävälle tasolle käyttöliittymäsuunnittelua ja ohjelmistokehitystä varten. 

  1. Uudet ominaisuudet kuvataan Jiraan epiceiksi. Varmista kuitenkin ensin, että sinulla on priorisoitu kehitysjono. Joskus uuden ominaisuuden määrittely vaatii lisäkonseptointia tai ns. nollasprintin, jossa ohjelmistokehitys ja arkkitehdit tarkentavat ominaisuuden määrittelyä.
  2. Uuden ominaisuuden visiotason käyttöliittymäsuunnitelma eli “visioleiskat” auttavat ominaisuuden käyttäjälähtöisessa ja ketterässä kehittämisessä. Hahmotelmien avulla ominaisuusidea konkretisoituu riittävästi, jotta sitä voi arvioida toteutuksen kannalta ja validoida aidoilla käyttäjillä. Tässä vaiheessa voidaan tehdä myös ohjelmistokehityksen kannalta alustava työmääräarvio.
  3. Pysähdy vielä kerran priorisoimaan kehitysjonoa. Tarvitaanko tämä ominaisuus varmasti ensijulkaisuun? Voisiko käyttäjätarpeen toteuttaa vielä yksinkertaisemmin tai voisiko ominaisuuden sittenkin jättää tekemättä? Mitä muita prioriteetteja kilpailee tämän ominaisuuden toteutuksen kanssa – usein ohjelmistokehityksen aikaa priorisoidaan hankkeen tai toimialankin tasolla yhdessä. Jos tämä ominaisuus tehdään, jääkö jotain muuta tekemättä?
  4. Jos ominaisuus jatkaa matkaansa toteutukseen, tarvitaan tuotantovalmiit käyttöliittymäkuvat eli “tuotantoleiskat”. Tällä tasolla käyttöliittymäsuunnittelijat ja ohjelmistokehittäjät ovat yhdessä tarkentaneet käyttöliittymäkuvia pikselin tarkkuudelle. Varmista suunnitelmien käytettävyys ja saavutettavuus testauksen avulla. Varmista myös, että suunnitelmat noudattavat Helsinki Design Systemiä ja, että suunnittelijat ovat benchmarkanneet vastaavia toteutuksia muista palveluista tai alan konventioista. 
  5. Seuraavaksi ominaisuus jalostetaan (“refinement”) ohjelmistokehityksen tehtäviksi (task) Jiraan. Lue lisää tästä vaiheesta ketterän kehityksen osiossa.

”Palveluni vaatii aivan uudenlaisen tai erilaisen visuaalisen ilmeen.”


Kaupunki on linjannut brändiarkkitehtuurin, joka kuvaa mitkä toimijat kuuluvat brändin käytön piiriin. Kaupungin tavoitteena on yhtenäinen visuaalinen ilme ja kaupungin tunnettuuden varmistaminen myös digitaalisissa kanavissa. Brändimme on varsin joustava ja voit erilaisten värivalintojen, elementtien ja kuvituksen avulla luoda palvelulle visuaalisen ilmeen, joka kuitenkin näyttää Helsingiltä. Jos palvelu vaatii erilaista visuaalista ilmettä, koska se toimii kaupungin rajojen ulkopuolella tai liittyy yhteishankkeeseen muiden toimijoiden kanssa, neuvottele tästä brändiyksikön kanssa. 

Piirretty hahmo ja kysymysmerkki.

Suunnittele toteutus ja tiekartta

Toteutusvaiheen suunnittelua kannattaa tehdä jo palvelumuotoilun loppuvaiheessa. Palvelumuotoilijat voivat auttaa palvelun tiekartan laatimisessa. Sisältömuotoilun avulla voit luoda suunnitelman myös palvelun sisältöjen tuottamiselle. 

Tutustu hel.fi esimerkkeihin verkkosivuston toteutussuunnitelmista ja tiekartoista. (tulossa)

Ketterä kehittäminen – kokoa kehitysjono, rajaa ensijulkaisu ja toteuta

Tämä vaihe keskittyy digitaalisen palvelun toteutukseen, erityisesti palvelunmuotoilun ja ensijulkaisun väliseen kehittämiseen eli ketterään ohjelmistokehitykseen. Tähän osioon on koottu tuoteomistajalle keskeiset vinkit toteutuksen ohjaamiseen ja tuoteomistajan tehtäviin toteutusvaiheen aikana.

Määrittele kehitysjono ja rajaa minimitoteutus eli ensijulkaisu

Tässä osiossa kuvataan vielä tarkemmin, miten kehitysjonoa ja MVP-rajausta kannattaa tehdä ketterän ohjelmistokehityksen näkökulmasta. 

Kehitysjono kuvaa palvelun ominaisuudet ja pilkkoo toteutuksen tehtävälistaksi
Kehitysjonon priorisointi kuvaa, mitä tehdään ensin ja mitkä ominaisuudet sisältyvät palvelun ensijulkaisuun. 
Käyttäjätarinakartta-menetelmä auttaa kehitysjonon priorisoinnissa ja MVP-rajauksessa

Huom! Tämä osio on vielä kesken ja päivittyy syksyllä 2022.

Ohjaa ketterää ohjelmistokehitystä

  1. Tee tiimisi kanssa työtapasopimus
  2. Kirjaa palvelun dokumentaatio Confluenceen
  3. Käynnistä sprinttirituaalit ja kehitä tiimin toimintatapoja
  4. Ohjaa palvelun toteutuksen laatua ja suuntaa
  5. Seuraa toteutuksen etenemistä ja työn tehokkuutta
  6. Julkaisuvalmistelut ja palvelun määräystenmukaisuus
  7. Laadi suunnitelma jatkuvalle kehittämiselle
Kaksi piirroshahmoa ihmettelee maailman menoa

Pikapalaute

Löysitko tiedon mitä kaipasit? Voit jättää palautetta palvelun toiminnallisuuksista tai kertoa, jos jokin asia ei mielestäsi toiminut tai mennyt aivan nappiin.