s-72.2510 tietoliikennepalveluiden käyttäjäkeskeinen suunnittelu (5 op)
DESCRIPTION
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. Käyttäjät kehittäjinä. - PowerPoint PPT PresentationTRANSCRIPT
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)