Prototyypin luovutus kehittäjille: Mitä otettava huomioon?
Design | Ohjelmistoprojektit | 27. helmikuuta 2024Projektin alkuvaiheessa suunnittelija on usein merkittävässä roolissa oleellisen tiedon keräämisessä ja ymmärtämisessä. Hahmotellessaan uutta palvelua hän on aktiivisessa vuorovaikutuksessa asiakkaan kanssa. Hän perehtyy käyttäjiin – heidän tarpeisiinsa, ongelmiinsa, toiveisiinsa. Hän tutustuu asiakkaan toimialaan, projektin tavoitteisiin ja riskeihin. Kun projekti siirtyy toteutusvaiheeseen, on viimeistään tällöin suunnittelijan keräämä tieto välitettävä eteenpäin muulle kehitystiimille.
UI/UX Designer
Parhaimmillaan suunnittelijat toimivat tiiviissä yhteistyössä kehitystiimin kanssa projektin alusta alkaen. Kehitystiimi ei kuitenkaan aina pääse mukaan projektin alkumetreille aikataulu- tai resurssisyistä. Jos kehitystiimi ei ole ollut mukana projektissa alusta alkaen, on suunnittelijan keräämän tiedon välittäminen eteenpäin tiimille erityisen kriittistä.
Designin luovutusta kutsutaan usein Design Handoveriksi. Handover ei suinkaan tarkoita pelkän linkin jakamista prototyyppiin, vaan laajaa tiedonsiirtoa osapuolten välillä. Parhaimmillaan kyseessä on pitkän aikavälin liukuva prosessi, jonka aikana suunnittelija luovuttaa kaiken projektin kannalta oleellisen tiedon eteenpäin kertoen mm. asiakkaasta, käyttäjistä ja palvelun tärkeimmistä ominaisuuksista. Näin varmistetaan, että kehitystiimillä on tarvittavat tiedot palvelun viemiseksi maaliin ja että he voivat tehdä perusteltuja päätöksiä itsenäisesti.
Mitä asioita designin luovutuksessa sitten kannattaa käydä läpi?
1. Asiakkaan & palvelun tausta
On varmistettava, että kehitystiimi ymmärtää asiakkaan toimialan ja taustan. Mikä on asiakkaan tarve? Todennäköisesti asiakas on kohdannut ongelman, joka on tarkoitus ratkaista kehitteissä olevalla palvelulla. Tiimin on hyvä ymmärtää, mitkä ovat palvelulle mahdolliset kompastuskivet ja riskit samoin kuin tavoitteet ja tulevaisuudensuunnitelmat. Kun tiimi tietää, miksi ja mihin palvelua tarvitaan, voidaan silloin tehdä kestäviä, asiakasta palvelevia ratkaisuja. Kehitetäänkö palvelua, jotta kasaan saadaan nopea MVP sijoittajille vai tehdäänkö palvelua pitkäjänteisesti ja harkitusti tulevaisuutta varten?
2. Käyttäjä & käyttäjän tausta
Käyttäjälähtöinen suunnittelu lähtee aina käyttäjästä ja tämän tarpeiden ymmärtämisestä. Avaako käyttäjä palvelun, kun hän on juoksemassa bussiin vai omassa toimistossaan kahvikupin äärellä? Entä käyttääkö hän palvelua auringonpaisteessa kännykällä vai erillisellä 4K-näytöllä? Onko käyttäjä teknisesti orientoitunut listanäkymiä arvostava insinööri vai trendikkäistä kuvista inspiroitunut Z-sukupolvelainen? Tiimin on tiedettävä, keitä käyttäjät ovat, mitä nämä arvostavat, missä tilanteessa palvelua käytetään ja millä laitteilla.
3. Palvelun tärkeimmät ominaisuudet
Mikä on käyttäjän suhtautuminen palveluun: käyttääkö hän palvelua oma-aloitteisesti mukavaan ajanviettoon vai haluaako hän suorittaa tietyn toimenpiteen sen avulla mahdollisimman nopeasti ja sulkea palvelun? Entä mikä on palvelun tärkein ominaisuus? Tiimin on hyvä ymmärtää, mitkä ominaisuudet ovat palvelun ytimessä, jotta he osaavat priorisoida työtään. Kriittisten ominaisuuksien on toimittava palvelussa alusta asti, kun taas osa suunnitelluista ominaisuuksista voi odottaa tulevaisuuteen.
4. Prototyypin läpikäynti perusteluineen
Suunnittelijan on hyvä selventää tiimille, miten ja miksi nykyiseen suunnitelmaan päädyttiin. Tehtiinkö projektin alussa esimerkiksi Design Sprint, jonka työpajakeskusteluiden, konseptiluonnosten ja käyttäjätestauksen seurauksena päädyttiin nykyiseen ratkaisuun? Hyvä suunnittelija on myös avoin kysymyksille, haastamiselle ja parannusehdotuksille. Kehitystiimi ymmärtää parhaiten projektin tekniset rajoitteet ja voi tarjota vaihtoehtoisia ratkaisuja ja uutta perspektiiviä suunnitelmiin.
5. Prototyypin tulkinta
Onko prototyypin tarkoitus olla absoluuttinen totuus, jota kehittäjät seuraavat pikselilleen vai raameja tarjoava ohjenuora? Puuttuvatko esim. nappien hover-efektit, koska niitä ei haluta toteutettavan vai koska niitä ei ehditty toteuttaa prototyyppiin? Onko prototyypissä kaikki tarvittavat näkymät, vai puuttuuko sieltä jotakin?
6. Työkalut ja dokumentaatio
Ovatko suunnittelijan käyttämät työkalut tuttuja tiimille? Suunnittelijan on hyvä käydä tiimin kanssa läpi, miten prototyyppiä katsotaan ja kommentoidaan palvelussa. Myös dokumentaation pelisäännöistä on hyvä sopia. Mihin dokumentaatiota tallennetaan ja missä laajuudessa? Onko tiimi tietoinen siitä, missä projektin aikana luotu dokumentaatio sijaitsee? Onko kaikille tarvittaville henkilöille jaettu pääsyoikeudet ja salasanat?
7. Yhteydenpito
Yhteistyön muoto ja preferoidut yhteydenottotavat on hyvä sopia heti projektin alussa. Miten suunnittelijaan saa yhteyden, jos designista on kysyttävää tai sen suhteen on epäselvyyksiä? Voiko suunnittelijalta kysyä mielipiteitä hihasta vetämällä tarpeen mukaan, vai varataanko läpikäyntiin säännöllisiä tapaamisia? Onko tiimillä käytössä Slack, Teams tai muu palvelu, jossa on matala kynnys yhteydenotolle? Milloin on alustavasti hyvä aika katsoa toteutusta yhdessä läpi? Voidaanko suunnittelijalle tehdä tunnukset esim. testiympäristöön?
Kokonaisuudessaan onnistuneen designin luovutuksen seurauksena on todennäköisempää, että projekti pysyy aikataulussa, budjetissa ja sovitussa laajuudessa, sekä että projektin lopputulos vastaa asiakkaan tarpeisiin. Ilman designin luovutusta on mahdollista, että lopputulos ei vastaa odotuksia sillä oleellista tietoa on jäänyt siirtymättä, on tapahtunut väärinymmärryksiä tai työskentely ei ollut tehokasta puutteellisen tiedon seurauksena.
Haluatko nähdä luomamme Design Handover -muistilistan ja ottaa sen käyttöön? Ota yhteyttä myynti@taitounited.fi ja lähetämme muistilistan sähköpostiisi.
design, UI/UX, palvelumuotoilu
UI/UX Designer