ServiceDigiCulture Toolkit and Training

Ideointi

Täytyy, pitäisi ja voisi olla, ei tule olemaan

30-60 minuuttia

Vähintään A3-kokoinen paperiarkki tai isompi, tietokonetiedosto tai valkotaulu
Erivärisiä kyniä ja tusseja
Post-it -lappuja

Mikä tämä työkalu on ja mitä hyötyä siitä on?

Täytyy, pitäisi ja voisi olla, ei tule olemaan (Must have, Should have, Could have, Won’t have) eli MosCoW-menetelmä on projektin, tässä tapauksessa palvelun, priorisointityökalu. Se auttaa tunnistamaan ja ideoimaan ominaisuuksia, jotka palvelussa täytyy olla, jotta se toimii ja voi olla olemassa, mitä pitäisi olla – eivät ole pakollisia, mutta olisi hyvä olla, sekä voisi olla - eivät ole välttämättömiä, mutta voivat parantaa käyttökokemusta, sekä mitä ei tule olemaan eli ominaisuudet, joita ei missään tapauksessa saa olla. Tätä työkalua käytetään useimmiten projekteissa, joissa on tiukka aikataulu, jotta nähdään, mikä sillä hetkellä on kaikkein tarpeellisinta. Sitä voidaan kuitenkin käyttää myös palvelujen ideointiin, sillä sen avulla voidaan tarkentaa määritelmiä ideoinnille.

Miten käytät tätä työkalua?

Alla olevat työvaiheet soveltuvat työskentelyyn yksin, pareittain tai ryhmässä.

1

Poimi tutkimustuloksista havaintoja, mitä elementtejä ja ominaisuuksia palvelussa tulisi ja ei tulisi olla, ja ideoi uusia ratkaisuja näiden perusteella. Käytä tähän kohdissa 2-5 olevia ohjeita. Kirjoita ne valkotaululle tai paperille kohtien 2-5 mukaisten vastaavien otsikoiden alle. Voit myös kirjoittaa ne post-it -lapuille, joita on helppo siirrellä ja ryhmitellä.

2

TÄYTYY OLLA: Lisää ensin, mitä palvelussa täytyy ehdottomasti olla, jotta se toimisi ja olisi olemassa ja haluttava. Nämä ovat palvelun perusvaatimuksia.

3

PITÄISI OLLA: Lisää seuraavaksi, mitä palvelussa pitäisi olla, mutta ei ole pakollista sen toiminnan kannalta. Nämä ovat palvelun ensimmäisen tason lisäelementtejä ja ominaisuuksia, jotka tekevät siitä haluttavamman ja käyttökelpoisemman sekä antavat sille lisäarvoa.

4

VOISI OLLA: Jatka lisäämällä, mitä palvelussa voisi olla. Tämä sisältää ominaisuuksia, joita palvelussa olisi kiva olla, mutta niiden puuttuminen ei vaikuta palvelun hyväksymiseen. Nämä ovat ominaisuuksia, jotka esimerkiksi erottavat sen kilpailijoista.

5

EI TULE OLEMAAN: Lisää viimeiseksi, mitä palvelussa ei tule olemaan lainkaan tai tiettynä aikana. Nämä ovat vähiten välttämättömiä elementtejä, joita kannattaa kuitenkin säästää myöhempää kehitystä varten.

6

Tarkastele ideoitasi ja järjestä niitä, kunnes olet tyytyväinen.

7

Tunnista tärkeimmät täytyy, pitäisi ja voisi olla, ei tule olemaan -palvelulle ja kirjoita ne ylös tarkempaa palveluideointia varten.

8

Tee toinen ideointikierros, jonka lähtökohta on juuri tekemäsi lista. Käytä listan ehtoja ja ideoi näiden pohjalta täsmennettyjä ja pidemmälle vietyjä ideoita.

Vinkkejä tämän
työkalun käyttöön

Tässä vaiheessa ideoituja määritelmiä voidaan käyttää myöhemmin myös arviointivaiheessa.
Tätä menetelmää voidaan käyttää myös yleisesti työhön ja projektinhallintaan, kuten työn ja resurssien priorisointiin.
Dai Clegg ja Richard Barker ehdottivat menetelmää artikkelissaan “Case Method Fast-Track: A RAD Approach”.
Lue lisää menetelmästä esimerkiksi täältä: Making Your UX Life Easier with the MoSCow by Interaction Design Foundation https://www.interaction-design.org/literature/article/making-your-ux-life-easier-with-the-moscow