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

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

Esittely ja käytännön järjestelytTimo Korhonen/ComNet

http://tll.tkk.fi/en/Studies/S-72.2510

Asiakkaiden ja käyttäjien mukaan ottamista tuotekehitystyöhön perustellaan tuotteiden ja palvelujen laadun parantamisella.Liiketoiminta- ja palvelukonseptien kehittämisessä yhteineninnovointi asiakkaiden kanssa on suorastaan välttämätöntä.Yhdessä tehty kehitystyö vastaa parhaiten asiakkaidenmuuttuviin 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äjienvuorovaikutus, keskustelu ja yhdessä tekeminen.

Käyttäjät kehittäjinä

Tekniikan näköalat 1/2008 (http://www.tekes.fi/julkaisut/tn.pdf)

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 metodiikkaaUCD=User Centric Design

Mitä UCD on? – mockups

Esim. Kalenteri-sovellutus lapsille Seuraava vaihe: esim flash-prototyyppi

http://www.interaction-design.org/encyclopedia/mock-ups.html

Mitä UCD on? – Revolution! LEGOt oli tarkoitettu

leikkiin… Kun käyttäjät otettiin

mukaan suunnitteluunpäädyttiin johonkinmuuhun

Kun hakkerit käyttivättuotetta saatiin taasjotain muuta – jokatuotteistettiin!

http://mindstorms.lego.com/

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ä

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

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ä

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

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

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

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

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!

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

AikatauluTeema ke 14-16 E110

ke 16-20 E208

to 16-20 E208

pe 12-14 E111 Aktiviteetti

Aloitusluento 28.3 LuentoUCD -menetelmät 1 2.4 LuentoUCD -menetelmät 2 3.4 LuentoErityiskäyttäjät 9.4 LuentoUCD ja organisaatiot 10.4 LuentoRyhmätyön palautus Deadline: 11.4Ryhmätyön opponointeihin valmistautuminen

Katso opponointiohje ja ryhmän esityksen ohje!

11.4-16.4

Ryhmäesitys 1 16.4 Esitys ja opponointiRyhmäesitys 2 & 3 17.4 Esitys ja opponointiRyhmäesitys 4 18.4 Esitys ja opponointiRyhmäesitys 5 23.4 Esitys ja opponointiPosterit no: 1-13 23.4 Esitys ja arviointiPosterit no: 14-26 24.4 Esitys ja arviointiLuentotehtävien palautus* Deadline: 24.4

*Luentotehtävät palautetaan E-siiven lokeroon

Katsaus UCD:n

TuotekehitysprosessiMARKETING

DESIGN

MANUFACTURING

CONCEPTDEVELOPMENT

SYSTEM-LEVEL

DETAILEDDESIGN

TESTING RAMP-UP& LAUNCH

PLANNING

-Promotion materials

-Early productionwith key customers

-Marketingplan

-Product options-Pricing strategy

-Leadusers-Competitiveproducts

Identify:-market opportunity-market segments

-Evaluation ofearly productoutputs

-Regulatoryapprovement-Performancetesting

-Tolerances-Components-Part geometry

-Subsystems-Interfaces

-Feasibilitystudies-Experimentalprototypes

-Identify new technologies-Consider product platform

-Productionconstraints-Supply chainstrategy

-Estimatemanufacturingcosts

-Suppliersfor keycomponents

-Qualityassuranceprocesses

-Fabrication and assembly process

-Follow-upproduct system(O&M)

Ramp-up: To increase a company's operational intensity to respond to increased demandO & M: Operation & Maintenance

Dominant design is a common understanding across manufacturers, users, and stakeholders of the new concept, and the way it is configured for market

Dominant Design

Introduction of Innovation

Revolution: Technology advances, change in legislation/resources etc

Changed market situation

Early adapters

Hard Competition

Regular users

External Push Factors

Evolution: Market Cohesion,Product Identity Established

Perinteinen tuotekehitys lähtee liikkeelle kentän muutoksesta

Markkinat,Teknologia,Regulaatio & Standardit

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

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

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

Käyttäjäkeskeinen suunnitteluprosessiKäyttäjätmukana

Käyttäjätmukana

Käyttäjätmukana

KÄYTTÄJÄTUTKIMUS KONSEPTIEN

SUUNNITTELU TUOTEKEHITYS EVALUOINTI

Tarpeiden määritys

Vaatimus-määrittely

Konseptien luonti

Konseptien validointi

Menetelmät:(SAY, DO, MAKE)

•haastattelut•havainnointi•päiväkirjat/ kuvakollaasit•roolileikit, ym.

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

Selvitetään:MITEN KEHITETÄÄN?

•suunnittelu•kehitys•yksityiskohtainen käyttöliittymä

Menetelmät: prototyypit•mock up:it

Menetelmät:•prototestaus•käytettävyys- testit•kenttäkokeet

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!

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

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

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!

UCD-menetelmät

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

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

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

TEKNILLINEN KORKEAKOULUHELSINKI UNIVERSITY OF TECHNOLOGY

Communications Laboratoryhttp://www.comlab.hut.fi

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?

TEKNILLINEN KORKEAKOULUHELSINKI UNIVERSITY OF TECHNOLOGY

Communications Laboratoryhttp://www.comlab.hut.fi

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

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

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/

Liite: heuristinen arviointi

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 vapaus Kä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.htmlJakob Nielsen's 'Heuristic Evaluation' method (Nielsen 1994)

heuristinen arvionti…4. Yhteneväisyys ja standardit Viestien 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äminen Palvelun 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 muistaminen Toimintojen 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

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

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

VakavuusluokitusJokainen 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)