IHTE-1100 Kaper s2008 Luento 6: Käytettävyyden hyötyjä Käytettävyyden arviointimenetelmiä Ja sitten se IHTE:n vessan hana Tämän päivän aiheita VEDÄ HANASTA ITSEESI PÄIN Viisivuotiaan käyttäjän kommentti: Onpas hassu hana Pitää ihan miettiä, miten se toimii Käytettävyyden hyötyjä Käytettävyyden arviointimenetelmiä - Heuristiikat, heuristinen arviointi - Käytettävyystestaus - Paperiprototypointi Käytettävyystyön trendejä Käytettävyyskurssien esittelyä
Tämän päivän aiheita Käytettävyyden hyötyjä Käytettävyyden arviointimenetelmiä - Heuristiikat, heuristinen arviointi - Käytettävyystestaus - Paperiprototypointi Käytettävyystyön trendejä Käytettävyyskurssien esittelyä ISO 9241-11:1998 Käytettävyyden hyödyt Käytettävyyden huomioiminen suunnittelussa on tärkeää - edistää käyttäjien työn tehokkuutta ja tarkkuutta - edistää käyttäjien tyytyväisyyttä Tuotteen käytettävyyttä voidaan parantaa ottamalla mukaan ominaisuuksia, joiden tiedetään auttavan käyttäjää Käytettävyyden tason määrittäminen vaatii käyttäjän työn suorituksen ja käyttäjän tyytyväisyyden mittaamista Jotta käytettävyys voidaan ottaa osaksi tuotekehitystä, täytyy ymmärtää käyttäjien tarpeet ja käytettävyyden suunnitteluvaatimukset Ohjelmiston elinkaarikustannukset Käytettävyyden hyötyjä Pienemmät kehityskustannukset Pienemmät ylläpitokustannukset Pienemmät käyttökustannukset - Suuremmat käytön hyödyt Parempi laatu tuotteelle (Haikala & Märijärvi, Ohjelmistotuotanto, 2002) Tyytyväinen käyttäjä on tyytyväinen asiakas. Tyytyväinen asiakas on asiakas jatkossakin.
Return of investment (ROI): Käytettävyys = $ For developers and manufacturers, the advantages of creating usable products far outweigh the costs. The rule of thumb: every dollar invested in ease of use returns $10 to $100. [http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/23] Jakob Nielsen: Alertbox, January 7, 2003: Return on Investment for Usability - Development projects should spend 10% of their budget on usability. Following a usability redesign, websites increase usability by 135% on average; intranets improve slightly less. - Current best practices call for devoting about 10% of a project's budget to usability; this doubles usability. ROI: Esimerkkejä IBM - On IBM's website, the most popular feature was the search function, because the site was difficult to navigate. The second most popular feature was the 'help' button, because the search technology was so ineffective. IBM's solution was a 10-week effort to redesign the site, which involved more than 100 employees at a cost estimated 'in the millions.' The result: In the first week after the redesign, use of the 'help' button decreased 84 per cent, while sales increased 400 per cent. http://www.theomandel.com/resources/returnoninvestment.html Ongelmista rahallisia menetyksiä Tulostimen ajuri, jonka asentaminen ei onnistunut helposti - Yli 50% ostajista soitti puhelintukeen (>50 000 ihmistä) - kulut lähes $500.000 / kk - lopulta lähetettiin päivitys kaikille asiakkaille kulut noin $ 300.000 Olisiko kannattanut investoida esim. $10.000 käytettävyystestaukseen? Lisää esimerkkejä Tunnetuimpia ja lainatuimpia esimerkkejä liian tekniikkapainoisesta suunnittelusta ja sen seurauksista on Xerox-yhtiön tapaus 1980-luvulla (Nussbaum & Neff 1991): Markkinat hylkäsivät Xerox 8200 -kopiokoneen, eikä kukaan tiennyt, miksi. Laite oli markkinoiden kehittynein ja teknisesti varsin vaikuttava. Lisäksi se toimi täydellisesti laboratoriossa. Ongelmana oli se, että insinöörit olivat lisänneet kopiokoneeseen niin paljon monimutkaisia ominaisuuksia, etteivät satunnaiset käyttäjät saaneet sitä toimimaan. Kukaan ei ollut ottanut käyttäjää huomioon. Vanhat asiakkaat vaihtoivat yksinkertaisempiin, japanilaisiin kopiokoneisiin, ja Xeroxin markkinaosuus romahti.
Työajasta tuhraantuu yli kolme tuntia viikossa Kotimaiset yritykset menettävät vuosittain kymmeniä tuhansia henkilötyövuosia it-ongelmien takia. Tietotekniikan ongelmat ovat nousseet uhaksi suomalaisten yritysten tehokkuudelle. Niistä aiheutuu jo 2,7 miljardin taakka kansantaloudelle. Tutkimuksen mukaan kansantalouden tehokkuuden kannalta olisi tärkeää, että tietotekniikan käytettävyys varmistetaan niin yksilö- kuin organisaatiotasolla. Käytettävyyttä kohentavat esimerkiksi [...] pitkäjänteinen käyttäjälähtöinen tutkimus- ja kehitystoiminta. [ITviikko 18.09.2003] Käytettävyyden liiketaloudellisia perusteita (ROI) Alhaisemmat kehityskustannukset Lyhyempi kehitysaika Suurempi tuotekehityksen tehokkuus Asiakasmäärän kasvu Pidempi tuotteen elinkaari Asiakkaiden menetyksen estäminen Vahvempi brändi Alhaisemmat tuotetukikustannukset Alhaisemmat käyttäjädokumentaatiokustannukset Huomattava kilpailutekijä Karat, C. (1990) Cost-benefit analysis of usability engineering techniques. Proceedings of the Human Factors Society 34th Annual Meeting. Santa Monica, CA: Human Factors Society. Käytettävyyteen käytetty 1 $ tuottaa 10-100 $ myöhemmissä vaiheissa Tuotekehitysprojektien kannattaa käyttää 10% budjetistaan käytettävyystyöhön Tämän päivän aiheita Käytettävyyden hyötyjä Käytettävyyden arviointimenetelmiä - Heuristiikat, heuristinen arviointi - Käytettävyystestaus - Paperiprototypointi Käytettävyystyön trendejä Käytettävyyskurssien esittelyä [T. Gilb, J. Nielsen]
UCD:n menetelmiä Http://www.usabilitynet.org/tools/methods.htm Tunnista tarve käyttäjäkeskeiselle suunnittelulle Ymmärrä ja määrittele käyttökonteksti Käyttäjäkeskeinen suunnitteluprosessi (ISO 13407) Evaluoi suunnitteluratkaisut vaatimuksia vasten Järjestelmä täyttää määritellyt käyttäjän ja organisaation vaatimukset Määrittele käyttäjän ja organisaation vaatimukset Tuota suunnitteluratkaisuja Ref: ISO 13407 Heuristiikka Heuristiikalla tarkoitetaan sääntöjen tai yleisten ohjeiden kokoelmaa Käytettävyyden heuristiikkojen tarkoitus on olla virikkeitä antava, keksimään ja analysoimaan auttava nyrkkisääntöjen kokoelma Heureka! Heuristiikka Käytettävyyden heuristiikkoja on useita erilaisia, esim. - Normanin suunnitteluperiaatteet - Nielsenin heuristisen arvioinnin lista - Shneidermanin kahdeksan kultaista sääntöä - jne Käytännön projekteissa usein luodaan tai muokataan omat heuristiikat
Jakob Nielsen "the king of usability" (Internet Magazine) "the guru of Web page usability" (The New York Times) "the smartest person on the Web" (ZDNet AnchorDesk) "perhaps the best-known design and usability guru on the Internet" (Financial Times) "the usability Pope" (Wirtschaftswoche Magazine, Germany) Kirjoja: - Prioritizing Web Usability, 2006 - Homepage Usability: 50 Websites Deconstructed, 2001 - Designing Web Usability: The Practice of Simplicity, 2000 - International User Interfaces, 1996 - Multimedia and Hypertext: The Internet and Beyond, 1995: - Advances in Human-Computer Interaction Vol. 5, 1995 (editor) - Usability Engineering, 1994 Nielsen: heuristisen arvioinnin lista 1. Järjestelmän tilan näkyvyys Sivusto: http://www.useit.com/ Nielsen: heuristisen arvioinnin lista 2. Järjestelmän ja todellisen maailman yhteys 3. Käyttäjän kontrolli ja vapaus Nielsen: heuristisen arvioinnin lista 4. Johdonmukaisuus 5. Virheiden välttäminen 6. Tunnistettavuus ennen muistamista
Nielsen: heuristisen arvioinnin lista 7. Käytön joustavuus ja tehokkuus 8. Yksinkertaisuus (ja esteettisyys) 9. Virheiden käsittely (tunnistus ja toipuminen) 10.Opasteet ja dokumentaatio Ben Shneiderman Professor in University of Maryland, (Human-Computer Interaction Laboratory ) Kirjoja: - Designing the User Interface: Strategies for Effective Human-Computer Interaction - Leonardo's Laptop: Human Needs and the New Computing Technologies the Eight Golden Rules of Interface Design Käyttöliittymäsuunnittelun 8 kultaista sääntöä 1. Noudata yhtenäisyyttä toimintaketjuissa ja toimintatavoissa Terminologia Värit, fontit, kuvakkeet Samanlainen toimintatapa samassa tilanteessa Kahdeksan kultaista sääntöä 2. Tarjoa edistyneille käyttäjille oikoteitä. näppäinoikotiet makrot piilotetut komennot
Kahdeksan kultaista sääntöä 3. Tarjoa informatiivista palautetta. Kahdeksan kultaista sääntöä 4. Suunnittele dialogit siten, että ne johtavat lopputulokseen. Järjestä toimintoketjut siten, että niillä on alku, keskikohta ja loppu. Kahdeksan kultaista sääntöä 5. Tarjoa yksinkertaista virheenkäsittelyä estä virheet auta käyttäjää toipumaan virhetilanteista Kahdeksan kultaista sääntöä 6. Salli toimintojen helppo peruminen. yksittäisen tapahtuman toimintosarjojen
Kahdeksan kultaista sääntöä 7. Tue käyttäjän kontrollin tunnetta. Käyttäjä käynnistää tapahtumat ja toiminnot Käyttäjä voi tehdä valintoja Kahdeksan kultaista sääntöä 8. Rajoita käyttäjän lyhytkestoisen muistin kuormitusta. tarvittava informaatio joka näytöllä ohjeet, opasteet, syöteformaatit Heuristinen arviointi Heuristinen arviointi tarkoittaa käyttöliittymän arviointia käytettävyysperiaatteiden (heuristiikkojen) avulla - taustalla oltava aina siis jotain teoreettista, tutkittua - arvioinnit eivät saa perustua pelkkään mutuun vaan objektiiviset perustelut on löydettävä kaikille väitteille! Heuristinen arviointi Asiantuntijat suorittavat arvioinnin joko ryhmässä samalla kertaa tai yksin erikseen - suurin hyöty tavoitetaan 2-4 arvioijalla Arvioija eläytyy käyttäjän osaan - heuristiikat taustalla Tulokset analysoidaan ja vedetään yhteen
Montako arvioijaa? Löytyneet ongelmat Hyöty / kustannukset Heuristinen arviointi, etuja nopea suhteellisen halpa paljastaa monia potentiaalisia käytettävyysuhkia - myös sellaisia, joita ei käytettävyystesteissä löydy (Nielsen) Heuristinen arviointi, ongelmia maksimihyödyn saavuttamiseksi tulee suorittaa useita arviointeja arvioijan kokemattomuus vaikuttaa tuloksiin suuri väärien hälytyksien todennäköisyys monesti vaikea erottaa turhat ja vakavat ongelmat ei koskaan korvaa kunnollista käytettävyystestausta! Heuristinen arviointi vs. asiantuntijaarviointi? Lähteestä riippuen saattavat olla synonyymit
Käytettävyystestaus Käytettävyystestaus Empiiristä käytettävyyden arvioimista Löydetään mahdollisia ongelmia käyttöliittymässä, navigoinnissa sekä käytön tehokkuudessa sekä miellyttävyydessä - Testin painopiste riippuu tavoitteenasettelusta Käytettävyystestauksesta Käytettävyystestaus Laboratoriossa... 1. Testin tavoitteiden asettaminen 2. Budjetti 3. Aikataulu 4. Testausympäristön valinta 5. Testaustavan valinta 6. Laitteistovaatimukset 7. Testikäyttäjien määrittäminen ja tavoittaminen 8. Vastuualueiden jakaminen 9. Testitehtävien laatiminen 10. Pilottitestaus 11. Testaus ja datankeruu 12. Analyysi 13. Raportointi ja tulosten purku http://www.oclc.org/ IHTE...tai käyttökontekstissa
Käytettävyystestaus Käytettävyyslaboratorio TV istuin sohva nojatuoli pöytä 120x80 IHTE http://www.littlespringsdesign.com/ Työtuoli Työtuoli pöytä 100x80 Testikäyttäjien määrä Kritiikkiä testikäyttäjien määrästä Mistä tiedetään, että on valittu juuri oikeat viisi käyttäjää? Mitä, jos kuudes käyttäjä löytää jonkun vakavan ongelman? Ei ole olemassa yhtä oikeaa vastausta, testikäyttäjien määrään tulisi vaikuttaa esim. - Eri käyttäjäryhmien ominaisuudet - Sovellusalue: voiko käytettävyysongelma olla turvallisuusriski Olennaista on, että testikäyttäjät edustavat todellisia käyttäjiä! http://www.useit.com/alertbox/20000319.html
Paritestaus Käytettävyystesti, jossa kaksi käyttäjää neuvottelee yhdessä järjestelmän käytöstä Keskustelu luontevaa, tarkkailija saa selville päätösten perustelut Ei välttämättä aina luonteva testaustilanne Prototyypit Erilaisia prototyyppejä Prototyyppien tulisi olla halpoja ja nopeita tehdä Käyttötarkoituksesta riippuen prototyyppi voi olla - low-fi- (low fidelity), - täydellinen tai - käyttöliittymäprototyyppi - Ozin velhoa voidaan käyttää silloin, kun muunlaisen protyypin tekeminen ei ole mahdollista tai mielekästä. Paperiprototyyppi Paperille tulostettu tai piirretty malli suunnitellun järjestelmän käyttöliittymästä - näytöt, dialogi-ikkunat, valikot jne. paperikuvina. Prototyypillä suoritetaan käytettävyystestaus (paperiprototypointi) - käyttäjä suorittaa tehtäviä - kuvien välisestä toiminnallisuudesta huolehtii tietokonetta leikkivä ihminen Päämääränä käyttöliittymäluonnosten vuorovaikutuksen sekä näyttöjen nopea testaaminen
Paperiprototyyppi Liiankin hienoja protopohjia: Paperiprototypoinnin neljä vaihetta ovat 1. Konseptin suunnittelu 2. Interaktiivisuuden suunnittelu 3. Näyttöjen suunnittelu 4. Näyttöjen testaaminen www.infodesign.com.au Paperiprototypointi, hyötyjä Low-fi -menetelmät Käytettävyysongelmien havaitseminen aikaisessa vaiheessa Erilaisten ratkaisujen kokeileminen Nopea ja halpa menetelmä Suunnittelijoiden ja käyttäjien välinen kommunikaatio paranee Päätelaitetta ei tarvita www.infodesign.com.au
Käytettävyysongelmien luonteesta Mikä on käytettävyysongelma? Jos tuotteen... - käyttö johtaa väärän toiminnon valitsemiseen - käyttö johtaa turhautumiseen ja luovuttamiseen - antama palaute on huomaamatonta silloin kuin sen huomaaminen olisi tärkeää - antama palaute on väärin tulkittavissa - avulla ei pysty ratkaisemaan tehtävää tietyssä ajassa - avulla ei pysty ratkaisemaan tehtävää tietyllä määrällä yrityksiä - avulla ei päästä tehtävän määrittelemään lopputulokseen Käytettävyysongelman vakavuus Riippuu kolmesta tekijästä: - Tiheydestä, kuinka usein ongelma ilmenee Yleistä-harvinaista - Vaikutuksesta, joka ongelmalla on Helppo vaikea toipua - Ongelman jatkuvuudesta Ensikertalaisen ongelma jatkuvasti eteen tuleva Luokitus löydöksen vakavuudelle (Nielsen) 0 - En pidä tätä käytettävyysongelmana. 1 Kosmeettinen: korjataan, jos aikaa jää 2 Pieni: korjattava, jos mahdollista 3 Suuri: tärkeää korjata kun mahdollista 4 Katastrofi: välttämätön korjata heti Muita viittauksia: T Tekninen ongelma (bugi) K Kommentti tai suunnitteluehdotus
Discount Usability Edulliset ja nopeat menetelmät Tavoitteena vuorovaikutuksen nopea testaaminen tai arviointi, ei tilastollinen luotettavuus Esim. nopeaa, iteratiivista paperiprototestausta, jossa suunnittelijat ovat mukana Discount usability The primary characteristics of discount usability engineering are small sample sizes (i.e., fewer participants), frequent iterations of these small tests, and reliance on direct observations rather than on statistically established findings. Best suited to projects that have access to an in-house staff of usability specialists. A prerequisite is the capability to quickly incorporate the results of each small study into a subsequent iteration of the prototype which will be tested again. It's necessary to be able to define test tasks quickly and perform the testing in a short timeframe. These short turn-around cycles are easiest to perform when all the developers and experimenters involved work for the same company and have an established pattern of working together. Ref: http://www.ergolabs.com/discount_usabilty_engineer.htm Käytettävyyden trendejä 2007-> Tämän päivän aiheita Käytettävyyden hyötyjä Käytettävyyden arviointimenetelmiä - Heuristiikat, heuristinen arviointi - Käytettävyystestaus - Paperiprototypointi Käytettävyystyön trendejä Käytettävyyskurssien esittelyä
Motto Käytettävyys Käyttöliittymä ei ole maali jolla projektin tuote lopussa päällystetään, tavoite, tehtävä vaan teräskehikko jonka varaan Tarkoituksenmukaisuus Tehokkuus yksityiskohdat kiinnitetään. käyttäjä Tyytyväisyys käyttökonteksti Ben Shneiderman Kontekstin ymmärtäminen on keskeistä käytettävyyssuunnittelussa Fyysinen ympäristö valaistus, tilan käyttö, lämpötila, jne. Sosiaalinen ympäristö keitä muita osallistuu tuotteen käyttöön tai näkevät sen käytön Tehtäväkonteksti mitä muuta käyttäjä on tekemässä kun hän käyttää kehitettävää järjestelmää, mihin muihin tehtäviin käyttö liittyy Tekninen ympäristö mitä teknisiä mahdollisuuksia ja rajoitteita on, esim. tietoliikenneverkot, printtaus, muut koneet ja sovellukset Erityisen kriittistä mobiilikonteksteissa! - koska ne ovat niin muuttuvia ja monipuolisia Kontekstin riittävä ymmärtäminen vaatii yleensä menemistä ko. ympäristöön - Myös haastatteluilla voidaan saada kerättyä osa kontekstitiedosta ei kuitenkaan kaikkea Käyttäjäkeskeisen suunnittelun periaatteet 1. Käyttäjät aktiivisesti mukana; ymmärrys käyttäjistä ja tehtävien asettamista vaatimuksista 2. Tarkoituksenmukainen tehtävänjako käyttäjien ja teknologian välillä 3. Suunnitteluratkaisujen iterointi 4. Poikkitieteellinen eli monialainen suunnittelu [ISO13407]
Paras arvaus ei ole riittävän hyvä Käytettävyydestä sanottua Ihmiset eivät yksinkertaisesti toimi niin kuin sinä ajattelet. Tiedä mitä asiakas tekee, suunnittele mielestäsi paras mahdollinen käyttöliittymä, testaa, korjaa. Mahdotonta suunnitella hyvää käyttöliittymää vain omien ajatusten varassa. Käyttäjä on aina oikeassa Jos käyttäjällä on ongelmia käyttöliittymän kanssa, niin käyttäjä - ei ole tyhmä - ei yritä liian lepsusti -> vika on tuotteessa tai sen käyttöliittymässä käyttäjä on oikeassa! Ongelmakohtia ei korjata viittaamalla käyttöohjeen sivuun 52. Käyttäjä ei ole aina oikeassa Käyttäjä ei tiedä mitä hän oikeasti tarvitsee. - (Muutosvastarinta, totutut toimintatavat, ) Käyttäjä voi olla tyytyväinen johonkin, mutta nähdessään uudistuneen version voi jälleen olla tyytyväinen, eikä paluuta entiseen ole. Käyttäjä voi esittää ehdotuksen, joka ei oikeasti poista ongelmaa!
Käyttäjät eivät ole suunnittelijoita Käyttäjät eivät muokkaa käyttöliittymää mieleisekseen, vaikka se olisi mahdollista Eli muokattavat käyttöliittymät eivät välttämättä ole ratkaisu ongelmiin Käyttäjät eivät välttämättä ajattele oikein Suunnittelijat eivät ole käyttäjiä Mikä on suunnittelijalle selkeää ja yksinkertaista, ei ole sitä välttämättä käyttäjälle Toimitusjohtajat eivät ole käyttäjiä Ihmiset jotka tilaavat ohjelman, ja näin kenties osallistuvat sen suunnitteluun, eivät välttämättä ole koskaan tehneet niitä asioita, joiden työkaluksi ohjelmistoa suunnitellaan. Myöskään oman yrityksen johtohenkilöt eivät ole yleensä käyttöliittymän suunnitteluun erikoistuneita ihmisiä. Tietojärjestelmän ostajat eivät myöskään aina ole itse käyttäjiä (vrt. asiakas vs. käyttäjä). Vähemmän on enemmän Jos kaikki toiminnot ovat esillä, niin kaikki ovat tyytyväisiä? Jokainen ylimääräinen nippeli vähentää ohjelman käytettävyyttä -> lisää käyttäjän taakkaa -> vähemmän on enemmän - Peruskäyttäjä eksperttikäyttäjä - Oppivat järjestelmät?
Yksityiskohdat vaikuttavat ohjeet eivät Käyttöohjeet eivät pelasta huonoa suunnittelua. Käyttöohjeita ei lueta. Mutta kun ohjeita luetaan, on jo iso hätä -> hyvä dokumentaatio voi pelastaa tilanteen Käytettävyys on prosessi Ei ole olemassa yhtä selkeää ohjetta: tee näin, ja käyttöliittymäsi on hyvä. Käytettävyys rakennetaan koko prosessin ajan tuotteeseen. Jokainen tuote on erilainen, joten yhtä ohjetta ei ole. Tämän päivän aiheita Käytettävyystyön roolit, esimerkkejä Käytettävyyden hyötyjä Käytettävyyden arviointimenetelmiä - Heuristiikat, heuristinen arviointi - Käytettävyystestaus - Paperiprototypointi Käytettävyystyön trendejä Käytettävyyskurssien esittelyä Käytettävyysasiantuntija - tuotekehitysprojektin päällikkö, jolla UCD-näkökulma -projektin UCD-asiantuntija, joka suorittaa UCD-aktiviteetit -useamman UCD-projektin sisäinen käytettävyyskonsultti Tutkija/tutkimuspäällikkö - puoliperustutkimuskysymysten ratkaisu tutkimusprojekteissa -liittyen käyttökokemukseen Suunnittelija-toteuttaja -UI-suunnittelu -käyttäjätutkimusten tulkkaus -SW-suunnittelu -koodaus Muut sivuaineopiskelijat, esim. -markkinointipäällikkö -laatupäällikkö -jne.
Kenen kannattaa valita käytettävyys? Käytettävyyden pääaine soveltuu opiskelijoille, jotka ovat kiinnostuneet ihmisen ja tekniikan välisestä vuorovaikutuksesta. Käytettävyyden pääaine antaa opiskelijalle monialaisen kokonaiskuvan vuorovaikutteisten menestystuotteiden suunnittelusta ja toteutuksesta. Pääaine antaa valmiudet yhdistää tekniikan mahdollisuudet ja käyttäjäryhmien vaatimukset tuotekehitysprosessissa.
Käytettävyyden opinnot TTY:ssa Mihin käytettävyys liittyy Teknologia/ innovaatiot Käytettävyyden päämäärä: Tuotteen suunnittelu Tehokkuus siten, Tarkoituksenmukaisuus että se soveltuu Tyytyväisyys tuotteen käyttäjille ja heidän tehtäviinsä Markkinat/ talous Titepk Käytettävyyden perusteet Alkuolio Käyttöliittymäsuunnittelun perusteet Ihminen käyttäjänä Otupk Kandi Käyttäjäkeskeinen tuotekehitys Kandityö 8 op P/Kandi Maisteri Graafisen käyttöliittymän ohjelmointi OTM Käytettävyystutkimuksen menetelmät Käytettävyys ohjelmistoprojektissa Käyttäjäkeskeinen suunnittelu Käyttäjäkokemuksen kvant. analyysi Seminaarit Jatkoopinto- kelp. Kirjatentit Vain Jatkoopiskelijat OHJ-proj Tutkimus, tuotekehitys ja -suunnittelu Kokonaisuuden laajuus pää- ja sivuaineena 30 op Pohjautuu ohjelmistotekniikan aineopintoihin Katso http://www.cs.tut.fi/ihte/opetus.html Vastuuhenkilö: Kaisa Väänänen-Vainio-Mattila Käyttäjäkeskeinen tuotekehitys, IHTE-3100 Tavoitteet: - ymmärtää käyttäjäkeskeisen tuotekehityksen kokonaisprosessi - tuntea eri sidosryhmien vaatimukset - käyttäjäkeskeisen suunnittelun menetelmien sopivuus eri vaiheissa Aihepiiri 1: Näkökulmat käytettävyyteen ja käyttäjäkeskeiseen suunnitteluun Aihepiiri 2: Miten käytettävyys integroidaan tuotekehitysprosesseihin Kommunikointi, ryhmätyömenetelmät, tiedon jakaminen HT vaihe 1 HT vaihe 2 Aihepiiri 3: Käyttäjäkeskeisen suunnittelun menetelmät Ihmiskeskeisen suunnittelun aineopintokokonaisuus IHSU 25 op Tarjoaa perusvalmiudet huomioida ihmisnäkökulmaa suunnittelussa kaikille tekniikan opiskelijoille Tavoitteena ymmärtää ihmisen käyttäytymistä ja miten ihmistä voidaan tukea tekniikan avulla Pakolliset kurssit: Kaper, Johdatus ihmisen käyttäytymiseen, Tehtävien analyysi ja suunnittelu, Monikulttuurinen suunnittelu
Käytettävyys on kaikkialla