S-72.2510 Tietoliikennepalveluiden käyttäjäkeskeinen suunnittelu (5 op)

1. S-72.2510 Tietoliikennepalveluiden käyttäjäkeskeinen suunnittelu (5 op) Esittely ja käytännön järjestelyt Timo Korhonen/ComNet http://tll.tkk.fi/en/Studies/S-72.2510

3. Käyttäjät kehittäjinä Asiakkaiden ja käyttäjien mukaan ottamista tuotekehitystyöhön perustellaan tuotteiden ja palvelujen laadun parantamisella. Liiketoiminta- ja palvelukonseptien kehittämisessä yhteinen innovointi asiakkaiden kanssa on suorastaan välttämätöntä. Yhdessä tehty kehitystyö vastaa parhaiten asiakkaiden muuttuviin tarpeisiin ja luo heille lisäarvoa. Ilmiön voisi nähdä myös tuotekehityksen osittaisena ulkoistamisena ja parhaiden ideoiden poimimisena laajemmalta porukalta. Oleellista on yritysten tuotekehittäjien ja käyttäjien vuorovaikutus, keskustelu ja yhdessä tekeminen. Tekniikan näköalat 1/2008 (http://www.tekes.fi/julkaisut/tn.pdf)

5. Living Lab • Arabianrannassa on toteutettu kaiken kaikkiaan parikymmentä käyttäjätutkimusta (design ja käyttöliittymät) • Mitä kehitetään? • kännykät, tietokoneohjelmistot ja erilaiset työkalut • pesula-, kerhoja saunatilojen verkkopohjainen varausjärjestelmä • ulkoisen levytilan vuokraus • liikenneinformaation jakaminen kauppakeskus Arabiassa • uusia digitaalisia ideoita päivittäistavarakaupan käyttöön • Miten? Kyselylomakkeilla, haastatteluin ja ihmisten käyttäytymistä havainnoimalla = UCD metodiikkaa UCD=User Centric Design

6. Mitä UCD on? – mockups • Esim. Kalenteri-sovellutus lapsille • Seuraava vaihe: esim flash-prototyyppi http://www.interaction-design.org/encyclopedia/mock-ups.html

7. Mitä UCD on? – Revolution! • LEGOt oli tarkoitettuleikkiin… • Kun käyttäjät otettiinmukaan suunnitteluunpäädyttiin johonkinmuuhun • Kun hakkerit käyttivättuotetta saatiin taasjotain muuta – jokatuotteistettiin! http://mindstorms.lego.com/

8. Kurssin tavoitteet • syventää osaamista käyttäjäkeskeisen suunnittelun prosesseista ja menetelmistä • ymmärtää erilaisia käyttäjäryhmiä sekä organisatorisia haasteita • osaa soveltaa käyttäjäkeskeisen suunnittelun työtapoja käytännössä • oppii hyödyntämään verkosta saatavaa tietoa • oppiin arvioimaan verkosta saatavan tiedon laatua • osaa tuoda kirjallisesti ja suullisesti esille omia perusteltuja havaintoja palvelun laadusta • oppii työskentelemään tehokkaasti ryhmässä

9. Kurssin käytännöt • Kurssin suoritus koostuu • Luennoista • Yksilölliset luentotehtävät* 10% (3 kpl) • Ryhmätyö 50 % (10 hengen ryhmät): • UCD:n harjoittelu käytännössä • Tuloksena raportti ja esitys • Arviointi opponointiryhmillä • Parityön posteri: Artikkelin analysointi, posterin laadinta ja esitys 15 %. (Parityöskentelyn tuloksista laaditaan posteri joka arvioidaan vertaisarvioinnilla) • Kurssiin kuuluu myös tentti 25 % (8.5) • Kurssin ohjeistus löytyy kokonaisuudessaan kotisivulta http://tll.tkk.fi/en/Studies/S-72.2510 • HUOM: Luennoilta saa olla ilman lisätehtäviä pois ainoastaan kerran! *Prosenttimäärä kertoo tehtävän osuuden arvosanasta

10. Luentotehtävät • Tavoite: Luentotehtävien tarkoituksena on käydä luennon materiaalia kertaalleen läpi sekä soveltaa luennolla opittuja asioita. Lisäksi opiskelijan oletetaan tehtävästä riippuen käyttävän verkkoa täydentävän tiedon hankkimiseen lähdekriittisesti. • Suorittaminen: Luentotehtävät annetaan luennon yhteydessä • Palautus E-siiven lokeroon 24.4 mennessä

11. Luentotehtävä (esim) • Mieti tuotteita tai palveluja joiden käytettävyys jättää toivomisen varaa! • Valitse ja käytä UCD-metodiikkaa ongelmien ratkaisuun • Raportoi prosessi ja tulokset Tätä luentotehtävää ei tarvitse palauttaa

12. Ryhmätyö • Ryhmätyön tarkoituksena on • oppia UCD-metodiikkaa • teoriassa ja • erikoisesti käytännössä • ryhmätyöskentelytaitoja • tieteellistä ajattelua • tiedon hakua/validointi • raportointia • asioiden esittämistä ryhmälle

13. Ryhmätyö • Ryhmiinjako ja ohjeistus löytyy kotisivulta1 • Tulokset • Raportti • Esitys (aikataulu kotisivulla) • Arvostelu opponoinnilla • Deadline: 11.4 - ryhmätyö aloitettava heti! • Järjestäytymistä auttaa ryhmänjohtajan valinta mahdollisimman varhain • Ryhmä perustaa kommunikointiin Google docs tilin – yhteystiedot kerätään 2.4 luennolla 1http://tll.tkk.fi/en/Studies/S-72.2510

14. Ryhmätyö-käytännöt • Kaikki ryhmän jäsenet tutustuvat materiaaleihin jotka mainittu kotisivulla • Jokainen ryhmän jäsen laatii esityksen siitä miten työ tehdään 1. tapaamiseen jossa päätetään • Miten työ tehdään • Työnjako • Yhteystyö ja seuraava kokous

15. Opponoinnit • Tavoitteet • takaisinkytkentä • kriittinen asioiden tarkastelu • opetellaan argumentointitaitoja • Opponoivan ryhmä • tutustuu opponoitavan ryhmän raporttiin ja esitykseen ennen esitystä. • Opponointi tapahtuu ryhmän esityksen jälkeen noudattaen opponointiohjeistusta (kotisivulla) • Opponointiryhmät kotisivulla • Ryhmätyön arvosana opponointiryhmän ja kurssihenkilökunnan arvosanojen keskiarvo • Huom!11.4 ryhmätyön raportti ja esitys (draft) opponointiryhmille!

16. Parityön posteri • Tavoite: Parityön posterin tavoitteena on käyttäjäkeskeisen suunnittelun lisäksi tutustua tieteellisten artikkelien hakemiseen, analysoimiseen ja esittämiseen • Tarkoituksena on myös tarkastella lähteen tietoja lähdekriittisesti • Aiheet ja työparijako kotisivulla, esitykset 23.4-24.4 • Arviointi posterien esitystilaisuudessa

17. Aikataulu *Luentotehtävät palautetaan E-siiven lokeroon

18. Katsaus UCD:n

19. Tuotekehitysprosessi MARKETING -Lead users -Competitive products Identify: -market opportunity -market segments -Product options -Pricing strategy -Marketing plan -Promotion materials -Early production with key customers DESIGN -Feasibility studies -Experimental prototypes -Tolerances -Components -Part geometry -Regulatory approvement -Performance testing -Subsystems -Interfaces -Identify new technologies -Consider product platform -Evaluation of early product outputs MANUFACTURING -Production constraints -Supply chain strategy -Estimate manufacturing costs -Suppliers for key components -Quality assurance processes -Fabrication and assembly process -Follow-up product system (O&M) PLANNING CONCEPT DEVELOPMENT SYSTEM -LEVEL DETAILED DESIGN TESTING RAMP-UP & LAUNCH Ramp-up: To increase a company's operational intensity to respond to increased demand O & M: Operation & Maintenance

20. Perinteinen tuotekehitys lähtee liikkeelle kentän muutoksesta Evolution: Market Cohesion, Product Identity Established Dominant Design Regular users Hard Competition Early adapters Introduction of Innovation External Push Factors Changed market situation Revolution: Technology advances, change in legislation/resources etc • Dominant design is a common understanding across manufacturers, users, and stakeholders of the new concept, and the way it is configured for market Markkinat, Teknologia, Regulaatio & Standardit

21. Esimerkki:UCD:n vaiheet: Kehittäminen • Ideointi (tai aivoriihi) • asetetaan tehtävä tai ongelma • tuotetaan ideat • valitaan niistä paras tai parhaat • Kytkentä käyttäjiin – esim. harrastaminen! • harrastajat ymmärtävät hyvin käyttämäänsä tuotetta, sen käyttäjiä ja käyttöympäristöä • Käytäntöjen tunnistaminen • käytäntöjen ja käyttöympäristöjen havainnointi voi antaa tärkeää pohjatietoa tuotekehitykseen tai jopa tuottaa uusia tuoteideoita http://www.juuseri.com

22. Konseptointi • Testausta varten tuotteesta pitäisi olla jonkinlainen konseptisuunnitelma, josta tulisi selvitä esim. • kenelle tuote on suunnattu • mihin sitä käytetään • miten ja missä sitä käytetään • miten se toimii • mikä on sen tuottama hyöty tai hupi http://www.juuseri.com

23. UCD: vaiheet: Kehittäminen… • Markkinatutkimukset • tapa kerätä tietoa tuotekehityksen avuksi • kartoitetaan potentiaalisia ostajia, markkinoita ja kilpailijoita • huom! Markkinatutkimuksen avulla pystyy sanomaan usein vain vähän lopullisista käyttäjistä, heidän tarpeistaan, käyttöympäristöistään tai käyttötilanteistaan. http://www.juuseri.com

24. Käyttäjät mukana Käyttäjät mukana Käyttäjät mukana Käyttäjäkeskeinen suunnitteluprosessi KONSEPTIEN SUUNNITTELU KÄYTTÄJÄTUTKIMUS TUOTEKEHITYS EVALUOINTI Konseptien luonti Konseptien validointi Tarpeiden määritys Vaatimus-määrittely • Selvitetään: • MITEN KEHITETÄÄN? • suunnittelu • kehitys • yksityiskohtainen • käyttöliittymä • Menetelmät: • prototyypit • mock up:it • Menetelmät: • (SAY, DO, MAKE) • haastattelut • havainnointi • päiväkirjat/ • kuvakollaasit • roolileikit, ym. • Menetelmät: • prototestaus • käytettävyys- • testit • kenttäkokeet • Selvitetään: • MITÄ KEHITETÄÄN? • käyttötarkoitus • ominaisuudet • käyttötapa • Menetelmä: esim. aivoriihi • Evaluointimenetelmät: • käyttäjäprofiilit • skenaariot ja storyboard:it

25. Vertailua • Miten käyttäjäkeskeinen suunnittelu eroaa perinteisestä? • Fokus käyttäjässä - ei esim. voitoissa • Uusia suunnittelumenetelmiä • Toimii hyvin tuotteen parantamisessa jolle on jo verifioidut markkinat • Korostunut iteratiivisuus & interaktiivisuus • Käyttäjäkeskeistä suunnittelua voidaan soveltaa perinteisen suunnittelun joka vaiheessa! Prosessi vaihtelee tilanteen mukaan!

26. Käyttäjän ymmärtäminen • Tietääkö käyttäjä mitä haluaa? • Joskus tietää (inkrementaaliset innovaatiot) joskus ei (radikaalit innovaatiot)! • Radikaalit innovaatiot • Käyttäjän näkemyksen selvittäminen vaatii pilotointia, esim. contextual enquiry menetelmä • Inkrementaaliset innovaatiot • Haastattelututkimukset, observointi

27. Sovellutuksen ymmärtäminen • UCD:n sovellutuskohteita • Käyttöliittymät • Teollinen muotoilu • Kodintekniikka ja ICT* • Arkkitehtuuri (design for all) • Autoteollisuus (ergonomia ja turvallisuus) • Ympäristötekniikka (ympäristön suunnittelu) • Organisaation uudistaminen (laatujärjestelmä) • UCD:tä pyritään soveltamaan yhä laajemmin koska näin varmistetaan asiakastyytyväisyys ja laatu • Tärkeä osa myös business case - analyysia *Information and Communications Technology

28. UCD:n rajoituksia • Käyttäjältä ei voi kysyä sitä mitä käyttäjä ei voi tietää: • Onko meidän firma prosessi valmis tällaiseen tuotteeseen (platforms ok?) • Onko tuotteella teknoekonominen pohja? Esim. tuotteen alikokoonpanot & supply chain löytyvät varmasti (ei toimitusongelmia) ja edullisesti • Toisaalta voi olla myös asiakkaita jotka tietävät näistäkin – firman työntekijät! => sisäinen asiakkuus (&sisäinen markkinointi!) • Tärkeä haaste: UCD vie helposti paljon aikaa ja henkilöresursseja => prosessin ja menetelmien valintaan kiinnitettävä huomiota!

29. UCD-menetelmät

30. http://www.usabilitynet.org/tools/methods.htm

31. Käyttäjäkeskeiset suunnittelunmenetelmät • Onnistuneimmat menetelmät • Käytettävyystestaus, prototyyppien tekeminen ja heuristinen arviointi • Myydyimmät • Asiakas haastattelut, paperi- tai muut prototyypit sekä käytettävyystestaus

32. Ammattilaisen arvostamia menetelmä • Usein käytetyt: • Iteratiivinen suunnittelu, käytettävyystestaus, tehtävä analyysi (task analysis*), epämuodollinen asiantuntija-arvio ja kenttä tutkimukset (sis. Kongnitiiv. Läp.) • Kyky tunnistaa käyttöliittymäongelmia • Käyttäjän tarvittavat taidot • Käyttöön tarvittavat resurssit *esim! http://ca.youtube.com/watch?v=1KML29WefLo

33. Metrics of Quality • Technical quality metrics - defect/default rates, defect origin and defect cost • Process oriented metrics - productivity and capability to meet deadlines • Business oriented metrics - end user’s satisfaction as quality/price - ratio • Personnel oriented metrics – rewards, motivation, feedback and continuous learning Miten UCD voi toimia yrityksen eri laatutasoilla?

34. Laatu ja UCD (vrt. ed. kalvo) • Tekninen taso • Teknistä laatua ei voi suoraan parantaa ulkoisilla tai sisäisillä asiakaskyselyillä (UCD ei helposti sovellettavissa) vaan on kehitettävä mittausta ja tekniikkaa • Prosessin taso • Yrityksen prosessia kehitetään lähtien liikkeelle siitä miten työntekijät kokevat firman toimiva käytännössä: lähtökohtana hyvien ja huonojen käytänteiden kartoitus ja päivitys • Liiketoiminnan taso • Asiakkailta saatava palaute ja asiakkaiden mukaan ottaminen suunnitteluprosessiin oleellinen osa UCD:tä • Henkilökohtainen taso • UCD voi pitää henkilökunnan tyytyväisenä tarjoten takaisinkytkentäkanavia (jatkuva henk. kohtaisen laadun kehittäminen) jolloin myös firman prosessit kehittyvät ja laatu paranee

35. UCD ja ICT • ICT tarjoaa laitteisiin paljon toimintoja joita pitäisi päästä käyttämään • UCD:n ICT-sovellutuskohteita • Liikkuva telekommunikaatio • Aistirajoitteiset käyttäjät • Pienet laitteet • Miten kehittää ja tutkia palveluja jotka ovat hyvin uusia käyttäjille, esim. ubi-tekniikka • vaatii korkeaa innovatiivisuutta • tutkimusmenetelmien tuntemusta • vaatii aikaa ja rahaa ICT=Information and Communications Technology

36. Lähteitä • Kokonaisuus ja menetelmiä • http://www.usabilitynet.org/tools/methods.htm • http://www.cs.uta.fi/kurssit/usabsem/osallistujat.html • Käytäntöä • Youtube hakusanalla user-center design! • http://www.juuseri.com/ • Encyclopedia –käsitteet (rakenteilla) • http://www.interaction-design.org/

37. Liite: heuristinen arviointi

38. Esimerkki: Palvelun heuristinen arvionti (GUI design) 1. Palvelun tilan näkyvyys Käyttäjän pitäisi aina pystyä nopeasti huomaamaan mikä on palvelun tila ja käyttäjän sijainti palvelussa. 2. Palvelun ja tosielämän vastaavuus Palvelun pitäisi käyttää tavallisesta elämästä tuttuja termejä, sanontoja ja käsitteitä mieluummin kuin palvelun omaa erikoistermistöä. 3. Käyttäjän kontrolli ja vapausKäyttäjän pitäisi päästä nopeasti ja vaivatta takaisin kunkin vaiheen alkutilaan, tehtyään epätoivotun tai virheellisen valinnan. "Peru" ja "Tee uudestaan" toiminnot ovat suositeltavia. Palvelu ei myöskään saisi tehdä häiritseviä asioita käyttäjän tahtoa vasten tai tältä kysymättä. http://www2.uiah.fi/mediastudio/survey4/liitea1.html Jakob Nielsen's 'Heuristic Evaluation' method (Nielsen 1994)

39. heuristinen arvionti… 4. Yhteneväisyys ja standarditViestien ja toimintojen pitäisi tarkoittaa yhteneväisesti aina samoja asioita (sanoja tai merkityksiä ei saisi vaihtaa lennossa). Olemassa olevia verkko- ja muita standardeja pitäisi hyödyntää yhteneväisyyden maksimoimisessa. 5. Virheiden estäminenPalvelun pitäisi tunnistaa mahdolliset virhetilanteet ja estää niiden toistuminen kertomalla käyttäjälle ennen virheen tapahtumista. Opastus pitäisi olla aina helposti saatavilla ja ymmärrettävissä. 6. Tunnistaminen mieluummin kuin muistaminenToimintojen ja vaihtoehtojen pitäisi olla näkyvissä käyttöliittymässä. Painikkeiden ja syötteiden pitäisi liittyä palvelun toimintoihin loogisesti ja muistettavasti http://www2.uiah.fi/mediastudio/survey4/liitea1.html

40. heuristinen arvionti… 7. Käytön joustavuus ja tehokkuus Käytön pitäisi olla joustavaa ja tehokasta sekä aloitteleville että edistyneille käyttäjille. Palvelun pitäisi tarjota pikavalintoja ja personointia usein käytettyihin toimintoihin. Käytön pitäisi olla myös joustavaa ja tehokasta käyttäjän laitteistosta ja yhteydestä riippumatta. 8. Esteettinen ja minimalistinen design Ruudulla pitäisi olla ne elementit, jotka ilmaisevat halutun tiedon, toiminnot, tunnelman ja tyylin, ei enempää. Ilmaisun ei pitäisi olla vaikeasti ymmärrettävää (ellei se ole palvelun kantava idea). 9. Virhetilanteiden tunnistaminen, ilmoittaminen ja korjaaminen Virheilmoitusten pitäisi kertoa selkokielellä mitä tapahtui, miksi näin kävi, miten asia voidaan korjata ja kuinka se voidaan välttää ensi kerralla. http://www2.uiah.fi/mediastudio/survey4/liitea1.html

41. heuristinen arviointi … 10. Opastus ja ohjeistus Vaikka käytön pitäisi tapahtua ilman opastusta ja ohjeita, ovat ne usein välttämättömiä käyttäjille. Näiden pitäisi olla helposti saatavilla, nopeasti etsittävissä, toimintaan ohjaavia, käyttötilannetta tukevia ja riittävän lyhyitä. http://www2.uiah.fi/mediastudio/survey4/liitea1.html

42. Vakavuusluokitus Jokainen arvioinnissa löydetty ongelma luokitellaan vakavuusasteikolla, joka kertoo asiantuntijan mielipiteen käytettävyysongelman vakavuudesta. Ongelman vakavuuden luokitus pitäisi nojata ainakin seuraavaan neljään seikkaan: Esiintymistiheys: kuinka usein potentiaaliseen ongelmatilanteeseen törmää? (usein/harvoin) Vaikutukset käyttäjälle: onko ongelmatilanteesta helppo vai vaikea selvitä? (vaikea/helppo) Toistuvuus: Onko ongelma helposti ohitettavissa, kun sen on kerran tunnistanut, vai vaivaako se jatkuvasti? (toistuva/ohitettava) Markkinavaikutukset: tekeekö virhe palvelusta markkinoilla merkittävästi huonomman tai jopa käyttökelvottoman? (merkittävästi heikompi/ei vaikutusta)