T Käyttöliittymäsuunnittelu T Vuorovaikutustekniikka

Transkriptio

1 T Käyttöliittymäsuunnittelu T Vuorovaikutustekniikka Luento 2. Käyttäjäkeskeinen suunnitteluprosessi Vaatimusmäärittelyt käyttöliittymäsuunnittelussa Teknillinen korkeakoulu Käyttöliittymät ja käytettävyys

2 Luennon sisältö Käyttäjäkeskeinen suunnitteluprosessi: LUCID Vaatimusmäärittelyt yleisesti/perinteisesti Käyttäjäkeskeisen suunnittelun erityispainotukset vaatimusmäärittelyille

3 Käyttäjäkeskeinen suunnitteluprosessi

4 Käyttäjäkeskeisen vuorovaikutussuunnittelun prosessi (ks. Shneiderman 1998) Logical User-Centered Interaction Design määrittelee myös suunnitteluprosessin tuotokset l. deliveraabelit Vaiheet Konseptin luonnostelu (Concept; envision) Suunnittelu (Design; User & task analysis, Design & prototype, Evaluate & refine) Toteutus (Build; Complete detailed design and production, Evaluate and refine) Julkaiseminen (Release; Release & follow-up) Ei peräkkäinen vaan iteratiivinen prosessi!

5 Konseptin luonnostelu Selkeän, helposti kommunikoitavan ja yhteisesti suunnittelujoukossa ymmärretyn ja hyväksytyn tuote/palvelu/järjestelmäkonseptin toteuttaminen Käytettävyystavoitteiden määrittely käyttöliittymäsuunnittelun pohjaksi Käyttöliittymäsuunnittelun toteutusohjelma (roadmap) monin tavoin tutkimuksen kohteena

6 Suunnittelu Käyttäjä- ja tehtäväanalyysi Käyttäjien toiminnan ja tehtävien analysointi Odotukset, tehtävä- ja toimintaprosessikuvaukset Suunnittelu ja prototyypin hahmottelu suunnittelun toteutus käyttöliittymä/näyttöprototyypin avulla Arviointi, tarkentaminen ja uudelleenmäärittely prototyypin avulla suunnittelun tulosten arviointi, tarkentaminen ja uudelleenmäärittely

7 Toteutus (Build) Yksityiskohtainen suunnittelu ja toteutus täydennetään prototyypissä ollut ehkä vielä vaillinainen käyttöliittymä kokonaiseksi jätettävä mahdollisuus myöhäisille muutoksille Arviointi ja uudelleenmäärittely arvioidaan prototyyppejä tai toteutetun tuotteen/järjestelmän esiversioita (käytettävyysarviot) tarkennetaan suunnitelmia iteratiivisesti

8 Julkaiseminen Julkaiseminen ja seuranta (Release & follow-up) määritellään hallittu käyttöönottotapa suunnitellaan ja toteutetaan käytettävyyttä tarkastelevat hyväksyntätestit määritellään ja toimeenpannaan palautteen keräämisen ja hallinnan mekanismit määritellään tavat, joilla palautetietoa voidaan käyttää seuraavien tuoteversioiden kehittämisen tukena

9 Vaatimusmäärittelyt

10 Mihin vaatimusmäärittelyjä tarvitaan? Perinteisesti vaatimusmäärittelyissä (spesifikaatioissa) pyritään kuvaamaan lopputuloksena syntyvä järjestelmä sellaisella tarkkuudella, että suunnittelijat voivat toteuttaa järjestelmän. Käyttäjät ja asiakkaat allekirjoittavat sopimuksen ja sitoutuvat siten tehtyyn suunnitelmaan. Onko ongelmia? Hankaluuksia helposti ymmärtämättömyyden ja puuttuvan osaamisen vuoksi Vaihtoehtoja massiivisille vaatimusmäärittelydokumenteille: paperiprototyypit ja iteratiivinen suunnittelutapa

11 Vaatimusmäärittelyt (trad.) Vaatimusmäärittelyt kuvaavat yksityiskohtaisesti ne tarpeet, joihin järjestelmän pitää tuottaa ratkaisu Vaatimusten analysointi ja määrittely on alku perinteisen vesiputousmallin mukaisessa suunnitteluprosessissa (Vaatimusten analysointi -> Määrittely -> Suunnittelu (arkkitehtuuri, yksityiskohdat) -> Toteutus -> Integrointi -> Ylläpito) Tiukimmin tulkittuna seuraavaa vaihetta ei aloiteta ennen kuin edellinen vaihe on päättynyt; edelliseen vaiheeseen ei myöskään palata Esimerkkejä vaatimusmäärittelyiden rakenteesta löytyy mm. IEEE:ltä (alkaen )

12 Vaatimusmäärittelyn rakenne (Pressman 1987) Johdanto tavoitteet (toiminta, liiketoiminta), projektin reunaehdot Tietomalli yksityiskohtainen kuvaus ongelmasta, jonka järjestelmä ratkaisee tietovirrat, tietosisällöt, tiedon rakenteet, järjestelmärajapinnat (hw, sw, hci!) Toiminnallinen kuvaus toiminnalliset osat, toimintojen kuvaukset (toimintaselostus, rajoitukset, suorituskykyvaatimukset, suunnittelurajoitukset, kuvaavat diagrammit) Validointikriteerit suorituskyvyn reunaehdot, käytettävät testit, erityishuomiot (Viitteet, liitteet)

13 Pohdintaa vaatimusmäärittelyn rakenteesta Tieto-intensiivinen: painottaa käsiteltävän tiedon määrittelyä Pyrkii tarkastelemaan ratkaisua, huomio on jo merkittävissä määrin lopputuloksessa Vähäinen painotus järjestelmän toimintaympäristön kuvauksessa ja käyttäjän tavoitteiden kuvaamisessa Sisältää kuitenkin osia, joihin päästään pureutumaan erittäin hyvin ja syvällisestikin käyttäjäkeskeisen suunnittelun keinoin

14 Vaatimusmäärittelyjen tuottaminen Aikamoista kysely- ja luonnostelutyötä; asioiden hoksaamista ja pohdiskelua, kuitenkin yleensä varsin tiukoissa aikatauluraameissa Vaiheet Ongelman tunnistaminen Arviointi ja syntetisointi Määrittely Katselmointi

15 Vaatimusmäärittelyn haasteita Kommunikointi Ymmärtäminen Käyttäjä/asiakaskaan ei aina tiedä mitä haluaa tai mitä vaaditaan... Analysoijan rooli keskeinen! Ymmärrettävä sekä asiakkaan tarpeet että kehitysorganisaation näkökulmat. Hoksattava abstrakteja käsitteitä, uudelleenjärjestettävä loogisesti, syntetisoitava uusia ratkaisuja uusien rakenteiden pohjalta Kyettävä tunnistamaan keskeiset ja tärkeät seikat ristiriitaisista ja sekavistakin lähteistä Analysoija Kyky ymmärtää käyttäjän/asiakkaan Analysoija on toimintaympäristöä on - Kyky sovittaa teknisiä elementtejä/ratkaisuja -asiakkaan näkökulmasta em. näkökulmasta konsultti toimintaympäristöön konsultti ja ja tiedustelija tiedustelija - Kyky kommunikoida selkeästi sekä keskustellen -kehittäjien näkökulmasta näkökulmasta määrittelijä että kirjallisesti määrittelijä ja ja korkean korkean tason tason suunnittelija suunnittelija Kyky nähdä metsä puilta

16 Vaatimusmäärittelyn deliveraabeli Vaatimusmäärittelydokumentti validointikriteereineen Mutta myös: Prototyypit Alustava käyttöohje

17 Vaatimusmäärittelyt käyttöliittymäsuunnittelussa Myös käyttöliittymäsuunnittelussa pitää lähteä liikkeelle vaatimusten määrittelystä Toisaalta käyttöliittymäsuunnittelu voi olla myös iteratiivinen osa vaatimusten määrittelyä Käyttäjälle näkyvän järjestelmän osan - käyttöliittymän - vaatimusmäärittelyjen pitää tarkastella käyttäjälle keskeisiä asioita Taustalla todelliset, kattavat ja edustavat kuvaukset Perinteisesti: abstraktit ja osittaiset tehtäväkuvat Keinot, joilla määritykset tuotetaan, ratkaisevat vaatimusmääritysten laadukkuuden (prosessilähtöinen näkökulma)

18 Vaatimusmäärittelyissä kuvattavat asiat (ISO 9241) Vaatimusmäärittely: Vaatimusmäärittely: JOHDANTO JOHDANTO (toiminta-liiketoiminta) (toiminta-liiketoiminta) Tämän Tämän kuvaaminen kuvaaminen tuottaa tuottaa puitteet puitteet vaatimusmäärittelyn vaatimusmäärittelyn muiden muiden osien osien tuottamiselle. tuottamiselle. Käyttäjä Tehtävä Laitteet ja välineet Ympäristö Aiotut lopputulokset Käyttökonteksti Vuorovaikutuksen tulos Käytettävyys Tavoitteet Tuottavuus/ vaikuttavuus Tehokkuus Tyytyväisyys Vaatimusmäärittely: Vaatimusmäärittely: JOHDANTO JOHDANTO (tavoitteet) (tavoitteet) Vaatimusmäärittely: Vaatimusmäärittely: VALIDOINTIKRITEERIT Tuote Käytettävyyden mittarit

19 Käyttäjäkeskeiset toimenpiteet vaatimusten määrityksessä Vaatimusmäärittely Suunnittelu ja Toteutus Testaus Seuranta V1 V2 V3 V4 V5 Käyttäjien tunnistaminen ja ryhmittely Käyttäjäluonnehdinnat Tehtäväanalyysit Ympäristö- ja tilanneanalyysit Käytettävyystavoitteiden luonti Käyttäjien tunnistaminen ja ryhmittely Käyttäjäluonnehdinnat Tyylioppaat Tarkistuslistat Heuristiset säännöt Tehtäväanalyysit Kognitiivinen läpikäynti Pienimuotoiset käytettävyystestit Ympäristö- Käytettävyystavoitteiden ja tilanneanalyysit tarkastelu Käytettävyystavoitteiden luonti Katselmoinnit Käytettävyystestit Tulosten vertailu käytettävyystavoitteisiin Asiakaspalaute tuotekehittäjille asti! Käyttäjätietouden keruu Tuotehallinta

20 Tunnista käyttäjä! Jos tuotteesi edes yrittää olla myyntikelpoinen, joku käyttää sitä! Kuka käyttää tuotetta? Millainen henkilö hän on? Miksi hän käyttää tuotetta? Mitä käytöllä tavoitellaan? Missä tilanteessa tuotetta käytetään? Miten tuotetta yritetään käyttää? Tunnista, valitse ja kuvaa tuotteen käyttäjät!

21 Tehtäväkuvaus Konkreettinen, yksityiskohtainen esimerkki tehtävästä, jonka käyttäjä suorittaa kertoo, mitä käyttäjä haluaa tehdä, muttei sitä, miten käyttäjä tekee asian on hyvin yksityiskohtainen, kertoo esimerkissä asiat todellisilla käsitteillä -- ei yleistyksiä kuvaa kokonaisen työtehtävän tehtäväkuvaukset osoittavat, ketkä työtä tekevät laajennettavissa skenaarioksi (mm. storyboard), joka kertoo, miten käyttäjä suorittaa tietyt toimenpiteet tietyn järjestelmän avulla

22 Harjoitustehtävä Hahmottele vierustoverisi kanssa skenaario opiskelijasta, joka haluaa varata kirjan korkeakoulun kirjastosta internet-palvelun kautta

23 Kuvausten taustalla todelliset havainnot! Tärkeää on perustaa käyttäjäkuvaukset todellisuuteen Havainnointikeinona esim etnografinen havainnointi tai sen johdannaiset; Contextual Inquiry ; myös osallistuvan suunnittelun keinoin voidaan saada selville kuvausten vaatimia faktoja.

24 User Characterisation (Booth 1989) USER DATA Identify the target user group Proportion of males and females Average age / age range Cultural characteristics (language etc.) JOB CHARACTERISTICS Job role description Main activities Main responsibilities Reporting structure Reward structure Schedules Status / quality Turnover rate USER BACKGROUND Relevant education / knowledge / experience Relevant skills Relevant training USAGE CONSTRAINTS Voluntary vs. mandatory use Motivators vs. de-motivators PERSONAL PREFERENCES AND TRAITS Learning style Interactional style Aesthetic preference Personality traits Physical traits

25 Task Analysis (Booth 1989) GOALS Identify goals and list important supporting tasks For each important task: TASK INTRINSICS Task identifier Inputs and outputs Transformational process Operational procedures & patterns Planning, decision points, problem solving Terminology Equipment TASK DEPENDENCY AND CRITICALITY Dependency on other tasks & systems Concurrent effects Criticality of tasks (linked to dependency) CURRENT USER PROBLEMS PERFORMANCE CRITERIA Speed, Accuracy, Quality TASK CRITERIA Sequence, frequency & importance of actions Functional relationships between actions Availability of functions Flexibility of operation USER DISCRETION Can the user control or determine pace, priority & procedure? TASK DEMANDS Physical, Perceptual, Cognitive, Environmental Health and safety requirements

26 Situational Analysis (see Booth 1989) EQUIPMENT (what equipment) does not meet performance criteria does not meet specification fails SURROUNDINGS Physical environment Social environment Changes in surroundings POLICY Changing laws, rules, standards, guidelines AVAILABILITY missing data missing materials missing personnel missing support OVERLOADS too many people/machines using resource too much data, information, materials, etc. INTERRUPTIONS process breakdown things missed/forgotten restart required

27 Kysymyksiä... Missä tuotetta käytetään? Kuka on käyttäjä tai käyttäjäorganisaatio? Missä ympäristössä tuotetta käytetään? Keitä ovat tuotteen käyttäjät? Mitkä ovat käyttäjien toimenkuvat/tehtävänimikkeet? Minkä nimisiä käyttäjät ovat? Mitä käyttäjät haluavat tehdä tuotteella? Mitä tavoitteita käyttäjillä on tuotetta käyttäessään? Missä tilanteessa tuotetta käytetään? Mitä tapahtuu tyypillisessä käyttötilanteessa? Miten tilanteet etenevät? Missä vaiheissa tehtävää tuotetta käytetään? Mitä muita osia käyttäjän tehtävään kuuluu? Mikä on tyypillisin käyttötilanne/käyttötapahtuma? Mitä tietoja tarvitaan tuotteen käyttämiseksi? Kokemusta? Koulutusta? Mitä tietoa EI tarvita? Miten tuotteen pitäisi palvella käyttäjää käyttötilanteessa?

28 Käytettävyystavoitteet (ks. Whiteside & al 1988) Käytettävyystekijä Mittauskohde Mittayksikkö Huonoin taso Suunniteltu taso Paras taso Tilanne nyt Tyytyväisyys Ensivaikutelma järjestelmästä vastaajien määrä 50 % neg. 90 % pos. 100% pos. Opittavuus Koulutus aika 1 pv + kouluttaja 1 h + kouluttaja 1 h (ei koul.) Muistettavuus Käyttöliittymän painikkeiden muistaminen hlömäärä 70 % muistaa 4 / 7 90 % muistaa 6 / % muistaa 7 / 7 Virheet Tehtävä: tarkista henkilön tiedot Virheiden määrä Tehokkuus Tehtävä: vastaa puhelintiedusteluun, jossa pyydetään henkilön puhelinnumeroa tiedon hakuun kulunut aika 30 sek 7 sek 3 sek

29 Oliopohjainen analyysi Soveltuu oliopohjaisiin kehitysympäristöihin Keskeiset käsitteet: objektit (objects) jaetaan kuuluviksi joko ongelma-alueeseen (problem space) tai toteutukseen (solution space) operaatiot (operations/methods) ominaisuudet (attributes/properties) Vaiheet: liittyvät sekä olioihin että operaatioihin Kuvataan järjestelmä sopivalla tarkkuudella vapaamuotoisesti, mutta kirjallisesti objektit=substantiivit; ominaisuudet=adjektiivit; operaatiot=verbit; operaatioiden ominaisuudet=adverbit

30 Vaatimusmäärittelyt kertovat, mihin tarpeisiin käyttäjät (asiakkaat) haluavat järjestelmän/tuotteen vastaavan antavat pohjan järjestelmän/tuotteen toiminnallisen kuvauksen kirjoittamiselle

31 mutta...

32 The First Law of System Engineering (Bersoff 1980) No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle

33