Kurssin ryhmätyön aiheena oli luoda digitaalinen ratkaisu Bar Laurealle ja toimeksiantajan toiveena oli luoda uusi appi heille. Asiakkaan brieffin jälkeen mietimme ryhmässä, että miten lähdemme tätä lähestymään. Sen sijaan, että olisimme lähteneet heti miettimään ratkaisua, otimme askeleen taaksepäin. Päätimme selvittää, että oliko aiheesta tehty aiempia tutkimuksia, minkä kautta voisimme validoida toimeksiantajan esittämät haasteet.
Miksi päädyimme eri ratkaisuun, mitä asiakas toivoi?
Käyttäjähaastattelujen perusteella. Monet haastateltavista eivät mielellään lataisi yhtä ylimääräistä appia, mieluummin integraation olemassa olevien kanssa. Ensin ajattelimme vaihtoehtona responsiivista verkkosivustoa, sitten PWA, kun eräs ryhmäläisistämme löysi tämän vaihtoehdon.
Mikä on PWA eli Progressive Web App?
PWA on verkkosovellus, mihin pääsee verkkoselaimen kautta. Se käyttää nykyaikaisia verkkotekniikoita tuottaakseen perinteisen sovelluksen kaltaisen kokemuksen käyttäjille.
Verkkosivun kehittäjän ei tarvitse huolehtia erilaisten mobiilikäyttöliittymien koodikantojen ylläpitämisestä (IOS, Android, Windows), mikä vähentää ylläpitokustannuksia.
Voit lisätä linkin mobiiliisi eikä se vie muistia kuten appi. Se toimii samalla tavoin kuin appi vaikka on verkkosivusto.
Miten saimme listattua alustavan listan suunnittelemamme ratkaisun ominaisuuksista?
Yksi ryhmämme jäsenistä teki käyttäjähaastatteluita, joiden oivallusten pohjalta täytimme Value proposition canvaksen. Sen jälkeen tehtiin ideointi pienryhmässä, että miten ja millä toiminnoilla käyttäjien ongelmia voitaisiin ratkaista ja tuottaa heille lisäarvoa.
Value proposition Canvaksesta lisää tämän linkin kautta ja alla kuva tyhjästä pohjasta.
Loimme ideoinnin pohjalta alustavan listan ratkaisumme ominaisuuksista, joille aloimme työstämään käyttäjäpolkuja esimerkin mukaisesti.
Linkki Googlen hakutuloksissa -> Blogi -postaus -> Liittyy sähköpostilistalle
DIRECT
Suoraan sivuille -> Kotisivu -> Tuotesivu -> Lisää ostoskoriin -> Suorittaa ostoksen
PPC
Klikkaa maksullista mainosta -> Laskeutumissivu -> Suorittaa ostoksen
Samaan aikaan työstimme käyttäjätarinoita (User stories) tällä formaatilla:
As a < type of user >, I want < some goal > so that < some reason >.
Tarinat olivat sillä tasolla, että ne kuvaavat toimintoja. Alla minun tekemäni ensimmäiset versiot käyttäjätarinoista.
User stories (Feedback feature)
As a customer (any customer) I want to give feedback about my experience in BarLaurea, good or bad, so that they can improve their operations.
As a customer (any customer) I want to know if my feedback has been received.
As a customer (any customer) I want to know what has been done based on my feedback.
As an administrator of BarLaurea, I want to collect feedback from customers, so that I can develop my own operations.
As an administrator of BarLaurea, I want to know how customers feel about different parts of customer experience.
As an administrator of BarLaurea, I want to show to customers, that they feedback has been received.
As an administrator of BarLaurea, I want to thank customers for the feedback they have given, so that they know it is valuable to us.
As an administrator of BarLaurea, I want to show to customers, that actions have been made based on their feedback.
User stories (Language selection feature)
As a customer (any customer) I want to have the content in a language that I can understand.
As a customer (any customer) I want to know what food is there available in the restaurant, in a language that I can understand.
As a customer (any customer) I want to know what the food is made of, in a language that I can understand.
As an administrator of BarLaurea, I want to provide content to website, so that all users can understand the content.
As an administrator of BarLaurea, I want to provide information about what food is there available in the restaurant, so that all users can understand the content.
As an administrator of BarLaurea, I want to provide information about what the food is made of, so that all users can understand the content.
Haastatteluiden ja Value Proposition Canvaksen tulosten pohjalta loimme muutaman asiakaspersoonan. Luoduista persoonista valitsimme yhden, kenelle keskityimme suunnittelemaan ratkaisua. Kuten Marc Stickdorn sanoi, suunnittele keskiverrolle, testaa ääripäiden kanssa.
Jos haluat tietää, mikä asiakaspersoona on ja mitä hyötyä niistä voi olla, niin alla olevan linkin takaa löydät lisää tietoa.
Miten valitsimme ratkaisuun sisältyvät ominaisuudet yhdessä käyttäjien kanssa ja miten jaottelimme ne tärkeysjärjestykseen?
Suunnittelimme ja fasilitoimme Pop-up workshopin, missä käyttäjät laitettiin kategorisoimaan ratkaisun toiminnot kolmeen kategoriaan. Must have, nice to have, not important. Tämän työpajan suunnittelussa, osallistujien rekrytoinnissa ja fasilitoinnissa minulla oli suuri rooli.
Työpajan tavoitteena oli tunnistaa käyttäjille tärkeimmät ominaisuudet, tunnistaa puuttuvat ominaisuudet, jos niitä on, tunnistaa käyttäjien suosima navigointi.
Jos tuli mieleen jokin puuttuva toiminto, pyydettiin kirjoittamaan se post-it lapulle ja lisäämään listalle. Kun toiminnot oli kategorisoitu, käyttäjien piti siirtää ne seuraavaksi tyhjälle aloitussivu-templatelle, sen mukaan, että mitä he haluaisivat aloitussivulla olevan.
Jos osallistujilla oli aikaa, niin kysyttiin myös mielipiteitä ensimmäisestä ratkaisun käsin piirretystä rautalankaversiosta.
Tässä vaiheessa jouduimme unohtamaan muutaman mielestämme hyvän ominaisuuden, koska käyttäjien mielestä ne eivät olleet tarpeellisia. Tärkeä oppi olikin se, että vaikka designerin ja asiakkaan mielestä jokin ominaisuus olisi hyvä juttu, loppujen lopuksi käyttäjä on se, joka päättää sen tarpeellisuuden.
Lopputuloksista otettiin kuvat, jotka analysoitiin ja ominaisuudet jaoteltiin taulukkoon. Näiden valintojen ja asiakkaan toivomien ominaisuuksien pohjalta aloimme työstämään toimintojen prototyyppejä. Tämä oli vähän niin kuin sarjakuvan tekoa, yksi kuva per yksi vaihe käyttäjän polussa.
Tästä pop-up workshopista ja sen oivalluksista kirjoittelinkin jo aiemmin:
Miten luoda toimiva prototyyppi verkkosivusta tai sovelluksesta ilmaiseksi ja ilman teknistä osaamista?
Kirjoitin tästä aiemmin: https://www.linkedin.com/posts/lauri-eskelinen_prototyyppi-latenlorut-uxdesign-activity-6595966056911695873-jreh
Miten pääsimme prototyypin ensimmäisestä raakaversiosta, missä oli vain yksi toiminto, lopulliseen esitettyyn versioon?
Ensimmäisessä käytettävyystestauksessa meillä oli käytössä todellinen raakaversio prototyypistä, siinä oli vain yksi toiminto, palautteen antaminen. Käyttäjille kerrottiin tämä alla oleva skenaario, heitä tarkkailtiin sen suorittamisen aikana ja kysyttiin kommentteja ja kehitysideoita jälkeenpäin.
Skenaariona oli: ”Vierailit juuri alakerran ravintolassa, mutta et ollut tyytyväinen. Oli jonoja, listalla ollut ruoka loppui kesken ja korvaava ruoka oli hieman kylmää. Haluat antaa palautetta, jotta he voivat kehittää toimintaansa.”
Tässä kuva meidän prototyypin ensimmäisestä versiosta:
Tämä palautteen antaminen ja FAQ -toiminto olivat minun vastuullani.
Tehdyistä käytettävyystestauksista ja niiden oivalluksista kirjoittelin myös aiemmin:
Toisessa käytettävyystestauksessa meillä oli käytössä prototyyppi, missä oli jo neljä toimintoa, edellisen päivän kommenttien pohjalta iteroitu palautteen antaminen, FAQ-osio, Menu ja Take-away annoksen tilaaminen. Palautteen anto -toiminnon kanssa käytettiin samaa skenaariota kuin ensimmäisessä testauksessa.
Tässä kuva edellisen päivän kommenttien pohjalta iteroidusta palautteen antaminen -toiminnosta:
FAQ-toiminnon skenaario oli: ”Olet kuullut, että ravintolassa on myynnissä 10-kerran kahvikortti. Olet etsinyt tietoa monesta eri paikasta, mutta et ole vielä sitä löytänyt.”
Alla kuva FAQ-toiminnon ensimmäisestä raakaversiosta:
Menu-toiminnon skenaario oli: ”Sinulla on ruokavalioon liittyviä tarpeita ja haluat tarkistaa etukäteen, että ravintolassa on ruokaa, mitä pystyt syömään. Jotta pystyt viettämään laatuaikaa ystäviesi kanssa samalla kun syöt.”
Take away-toiminnon skenaario oli: ”Mietit, että mitä tekisit tänään illalliseksi ja tunnet olosi hieman laiskaksi. Tiedät, että BarLaurea myy leftover-annoksia edullisesti ja mietit ostavasi annoksen. Miten etenet?”
Jokaisen skenaarion suorittamisen aikana tarkkailimme sitä, että meneekö sen suorittamiseen paljon aikaa ja löytääkö käyttäjä heti sen, mitä he etsivät.
Näitä kysymyksiä kysyimme skenaarion suorittamisen jälkeen:
Miltä prosessi tuntui? Oliko mielestäsi helppo löytää sitä mitä etsit? Mitä muuttaisit tässä prosessissa?
Näiden käytettävyystestausten suunnittelussa, osallistujien rekrytoinnissa ja toteuttamisessa minulla oli suuri rooli. Ensimmäisessä testauksessa toimin suurimmaksi osaksi testauttajana, Salla kirjasi ylös saatuja palautteita. Toisessa testauksessa vaihdoimme rooleja.
Toimitimme asiakkaalle myös nämä tuotokset:
Päivitetty Value Proposition Canvas
User key path scenarios
Epics & User stories
User flow map
Use cases
Wireframes
UI sketches
UI flow chart to see the big picture of our service and to explore even detailed single interfaces
Sequence Diagrams (Frontend/Backend Interaction)
Site map with clear call-to-actions
Web Accessibility Checkin tulokset
Insight based proposed next steps to continue development and dev roadmap
Esitelty versio
Saatujen palautteiden ja kehitysideoiden pohjalta iteroimme ratkaisuamme vastaamaan käyttäjien toiveita. Lopullinen prototyyppi esiteltiin asiakkaalle perjantaina 8.11.2019 ja tämän linkin kautta pääsee katsomaan prototyypistä Sallan tekemän videon.
Linkki videoon: https://www.youtube.com/watch?v=RARBzVMnVuU
Tämän linkin takaa löydät interaktiivisen prototyypin, mitä pääset halutessasi testaamaan. Ei tarvitse antaa mitään tietoja.
Projekti oli haastavin, mutta myös opettavaisin tähän mennessä näiden opintojen aikana. Aikaa oli rajoitetusti, mutta olin kyllä tosi tyytyväinen lopputulokseen. Saimmekin tuotoksestamme arvosanaksi 4.8/5 juuri ennen joululomia. Pystyi hyvillä fiiliksillä lähtemään joulun viettoon.
Listasin tähän alle vielä ryhmämme tärkeimmät opit ja kehityskohteet.
Mitä opimme?
Tämmöisessä projektissa on paljon yksityiskohtia, jotka ovat riippuvaisia toisistaan. Tästä syystä projekti on aika monimutkainen ja aikaa vievä.
Käyttäjätestaus on mielenkiintoista ja hauskaa! Tulokset voivat olla yllättäviä. On todella tärkeätä suunnitella nämä sessiot hyvin ja miettiä, miten oivallukset kerätään.
On hyvä yhdistää Marvel ja Canva. Visuaalisen ulkonäön ja vaikutelman vuoksi on tärkeää luoda suuntaviivat kaikille tiimin jäsenille, jotta saadaan johdonmukainen ulkoasu läpi ratkaisun.
Vaikka asiakas haluaisi jonkin tietyn ratkaisun, käyttäjien vaatimukset voivat olla täysin erit. Ja jos designerit ajattelevat, että jokin voisi olla hyvä ratkaisu, käyttäjät eivät ole välttämättä samaa mieltä.
On kriittistä osallistaa asiakkaat jokaisessa vaiheessa. Jotkin ominaisuudet, mitä ei tullut esille haastatteluissa, tulivat esille pop-up workshop-vaiheessa.
Pidä se yksinkertaisena ja tee siitä mahdollisimman helppoa käyttäjille. Keep it simple stupid!
Mikä olisi voinut mennä paremmin?
Olisi ollut hyvä, jos meillä olisi ollut aikaa suorittaa viimeinen käytettävyystestaus lopullisen prototyypin kanssa eikä vain testata erillisten ominaisuuksien polkuja.
Oli melko haastavaa pysyä puolueettomana eikä ”rakastua” omaan ratkaisuun. Olimmehan kaikki myös potentiaalisia käyttäjiä. Sen sijaan luottaa kerättyyn käyttäjädataan eikä puskea omia ideoita, mitä data ei tukenut.
Sen sijaan, että keskittyy rakentamaan täydellistä ratkaisua, uskaltaa mennä ja testata keskeneräistä versiota käyttäjien kanssa. Sitä kautta voi saada paljon enemmän palautetta ja kehitysideoita heiltä. On paljon vaikeampaa muuttaa jotain, joka on omasta mielestä valmis.
Mitä olit mieltä luomastamme ratkaisusta?