tiistai 5. lokakuuta 2010
torstai 19. elokuuta 2010
Mistä ISO 9241-210:n saa?
Minulle on tullut joku kysely, että mistä 9241-210:n saa?
ISO-standardithan eivät ole esimerkiksi ladattavissa verkosta, vaan ne on ostettava. Valitettavasti ne ovat suhteellisen (suhteettoman?) kalliita yksityiselle henkilölle; ISO 9241-210:n hinta näyttää olevan CHF 124,00 (http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075).
Kirjastoista voi myös kysyä. Tiedän, että ainakin Helsingin yliopiston Kumpulan kirjastossa se on.
ISO-standardithan eivät ole esimerkiksi ladattavissa verkosta, vaan ne on ostettava. Valitettavasti ne ovat suhteellisen (suhteettoman?) kalliita yksityiselle henkilölle; ISO 9241-210:n hinta näyttää olevan CHF 124,00 (http://www.iso.org/iso/catalogue_detail.htm?csnumber=52075).
Kirjastoista voi myös kysyä. Tiedän, että ainakin Helsingin yliopiston Kumpulan kirjastossa se on.
sunnuntai 23. toukokuuta 2010
"4. Principles of human-centred design" (jatkoa 2)
-->
Ja periaatteet e) ja d)
"e) The design addresses the whole user experience"
- Otoksia tekstistä: “… the concept of usability used in ISO 9241 … can include the kind of perceptual and emotional aspects typically associated with user experience, as well as issues such as job satisfaction and the elimination of monotony. Designing for the user’s experience involves considering, where appropriate, organisational impacts, user documentation, on-line help, support and maintenance (including help desks and customer contact points), training, long-term use, and product packaging (including the ‘out-of-box experience’)... Design decisions related to this allocation of function determine the extent to which a given job, task, function or responsibility is to be automated or assigned to human performance…. Representative users should generally be involved in these decisions”.
- Tässä siis aluksikin periaatteessa sanotaan, että käytettävyyden määritelmä kattaa paljolti myös käyttökokemuksen. Mikä mielestäni pitää paikkaansa. Lisäksi korostetaan aivan oikein, että suunnittelussa pitää ottaa huomioon muut asiat, joiden kanssa käyttäjä tekee interaktiota (“user documentation, on-line help…”; tästä kokonaisuudesta itse käytän termiä “interaktiomediat”).
- Mutta ohje siitä, että käyttäjien tulisi osallistua päätöksen tekoon suunnitteluratkaisuista on kyllä ongelmallinen. Sen vuoksi, että käytännössä tämä tarkoittaa helposti sitä, että käyttäjille valutetaan vastuu suunnitteluratkaiusjen laadusta. Tämä voi olla jopa eettinen ongelma.
"f) The design team includes multi- disciplinary skills and perspectives"
- Tässä kohdassa luetellaan taitoja ja näkökulmia, joita voidaan tarvita: “human factors and ergonomics, usability, accessibility, human-computer interaction, user research; users and other stakeholder groups; application domain expertise, subject matter expertise…)”. Lisäksi todetaan, että etuna on “creativity and ideas” ja “team members become more aware of the constraints and realities of the other disciplines”.
- Tähän kohtaan ei ole isompaa kommenttia; näinhän on. Kannattaa kuitenkin arvostaa päätöksen teossa nimenomaan käyttöliittymäsuunnittelijoiden ammattitaitoa. Heillähän on nimenomaan käyttöliittymäkoulutusta taustallaan.
"4. Principles of human-centred design" (jatkoa)
Jatketaan periaatteilla c) ja d)
c) "The design is driven and refined by user-centred evaluation"
c) "The design is driven and refined by user-centred evaluation"
- Tämä periaate korostaa kyllä liikaa evaluoinnin roolia. Yksinkertaisesti siitä syystä, että evaluointipohjainen suunnittelu on kallista ja hidasta
- Parempi muotoilu olisi esimerkiksi: "The design is driven by a thorough understanding of users, tasks, user goals, and a good knowledge of design and usability guidelines and standards". Sitten tuo "user-centred evalution" on tätä tukeva toimenpide.
- Standardissa sanotaan: "The most appropriate design for an interactive system cannot typically be achieved without iteration".
- Tässä on oleellinen muotoilu: "... cannot typically be achieved...". Eli iterointi nähdään ilmiönä, johon tulee varautua mutta joka ei ole tavoiteltavaa sinällään. Ja tämä on aivan oikein.
- Mutta tästä seuraa samantien ristiriita: kun iterointi on ilmiö, "välttämätön paha", niin silloinhan se ei ole periaate ("näin tulisi tehdä"). Paremmin muotoiltu periaate olisikin esimerkiksi "Try to achieve appropriate design without unnecessary iteration".
perjantai 21. toukokuuta 2010
"4. Principles of human-centred design"
Standardi määrittää seuraavat ihmiskeskeisen suunnittelun periaatteet:
"a) The design is based upon an explicit understanding of users, tasks and environments
b) Users are involved throughout design and development
c) The design is driven and refined by user-centred evaluation
d) The process is iterative
e) The design addresses the whole user experience
f) The design team includes multi- disciplinary skills and perspectives"
---------------------------------
Aluksi verrattuna ISO 13407 -periaatteisiin. ISO 13407:ssa olivat yllä olevista b, d ja f. Lisäksi siinä oli neljäntenä periaatteena "appropriate allocation of function between users and technology". Tämä viime mainittu ei enää ole periaatteena 9241-210:ssa vaan osana "Producing design solutions" -aktiviteettia, mikä onkin loogisempi paikka.
Ja nyt aluksi kommentit kahteen ensimmäiseen periaatteeseen.
"a) The design is based upon an explicit understanding of users, tasks and environments"
"a) The design is based upon an explicit understanding of users, tasks and environments
b) Users are involved throughout design and development
c) The design is driven and refined by user-centred evaluation
d) The process is iterative
e) The design addresses the whole user experience
f) The design team includes multi- disciplinary skills and perspectives"
---------------------------------
Aluksi verrattuna ISO 13407 -periaatteisiin. ISO 13407:ssa olivat yllä olevista b, d ja f. Lisäksi siinä oli neljäntenä periaatteena "appropriate allocation of function between users and technology". Tämä viime mainittu ei enää ole periaatteena 9241-210:ssa vaan osana "Producing design solutions" -aktiviteettia, mikä onkin loogisempi paikka.
Ja nyt aluksi kommentit kahteen ensimmäiseen periaatteeseen.
"a) The design is based upon an explicit understanding of users, tasks and environments"
- Tämä on päällekkäinen "Undestanding and specifying the context of use" -aktiviteetin kanssa. Ja siinä mielessä redundantti ja ehkä tarpeeton periaatteena. Mutta tämä on toki erittäin oleellinen asia. Yksi keskeinen sana mielestäni kuitenkin puuttuu listasta: "understanding of users, USER GOALS, tasks...". Käyttäjien ymmärtäminen jää puolitiehen, jos tehtävät tunnistetaan mutta tavoitteita ei määritetä.
- Periaatteen kuvaus korostaa käyttäjiä arvokkaana tietolähteenä ("a valuable source of knowledge"), ja käyttäjien mukanaolon tärkeyttä. Mukana olemisen muodoista sanotaan: "User involvement should be active, whether by participation in design, acting as a source of relevant data or by evaluating solutions". Asiakaskohtaisten järjestelmien ja kulutustuotteiden kehittämisestä puhutaan erikseen. Edelliseen liittyen tuodaan esiin, että "organization procuring the system has the opportunity to have a direct influence on the design as it emerges".
- Käyttäjät ovat arvokas tietolähde; sitä asia standardi korostaa aivan oikein. Mutta standardin tekstimuodot jättävät tulkinnan varaa. Käyttäjien osallistuminen suunnitteluun ("participation in design") sisältää riskejä, jos tuolla tarkoitetaan nimenomaan sitä, että käyttäjät tuottaisivat suunnitteluratkaisuja. Samoin se, että käyttäjät arvioisivat suunnitteluratkaisuja (... should be active... by evaluation solutions) on ongelmallinen ajatus. Yleisessä tapauksessa käyttäjillähän ei ole tällaisiin toimenpiteisiin kunnon edellytyksiä (esimerkiksi ei ole käyttöliittymäkoulutusta).
- Yhteenvetona, itse muotoilisin periaatteen tyyliin "Users are valuabe source knowledge in the throughout the design and development".
tiistai 11. toukokuuta 2010
"6.5 Evaluating the design"
Poimintoja aktiviteetin kuvauksesta:
"Even at the earliest stages in the project, design concepts should be evaluated to obtain a better understanding of the user needs. ... However, evaluation by users ... is not always practical or cost effective at every stage of a project. ... design solutions should also be evaluated in other ways - for example using task modelling and simulations. These methods are still centred on how the user will experience the system even though the users themselves might not participate directly. User-centred evaluation can be used to
a) collect new information about user needs;
b) provide feedback on strengths and weaknesses of the design solution from the users’ perspective (in order to improve the design);
c) assess whether user requirements have been achieved (which can include assessing conformity to international, national, local, corporate or statutory standards);
d) establish baselines or make comparisons between designs.
....
There is a variety of user-centred evaluation methods which can be used to evaluate designs.
....
To obtain valid results, the evaluation should be carried out by experienced practitioners, and should use appropriate methods.
...
Two widely used approaches to user-centred evaluation are:
- user based testing;
- expert evaluation using usability and accessibility guidelines or requirements.
When prototypes are used, they should be used to collect user feedback while carrying out tasks, rather than just being demonstrations to show users a preview of the design. The information gathered is used to drive the design.... Later in development, user testing can be used to assess whether usability objectives including measurable usability performance and satisfaction criteria have been met in the intended context or contexts of use.
Expert evaluation can be valuable and cost effective and can also complement user testing. It can be used to eliminate major issues before user testing (and hence make the user testing more cost- effective).... Expert evaluation can be supported by checklists, lists of user requirements, general usability guidance, industry best practices, usability heuristics, guidelines or standards. However, the effectiveness of the expert evaluation always depends on the skills, experience and knowledge of the experts.
Expert evaluation is simpler and quicker to carry out than user testing and can, in principle, take account of a wider range of users and tasks than user-based evaluation... Experts do not always find the same problems that would be found in user based testing. Expert evaluation tends to emphasize obvious problems and might not scale well for complex or novel interfaces. The greater the difference between the knowledge and experience of the experts and the real users, the less reliable are the results. When appropriate, expert evaluation can be carried out with domain experts working alongside the usability expert."
-------------------
Evaluointi on perinteisintä käytettävyysasiaa, eikä tässä tule mitään erityistä yllättävää esiin. Muutama huomio kuitenkin:
- Korostetaan aivan oikein käytettävyystestien rajallisuutta menetelmänä. Käyttäjätestit eivät useinkaan ole kustannustehokas tapa tehdä evaluointia
- Korostetaan asiantuntijuuden roolia käytettävyysarvioinneissa. Tämä tietenkin pitää paikkaansa. Mutta on syytä ottaa muistaa, että "käytettävyysasiantuntijuus" ei ole selkeästi määritetty asia. Esimerkiksi Molich & al tutkimukset (2006) osoittavat, että ammattimaiset käytettävyysasiantuntijat voivat tuottaa hyvinkin erilaisia tuloksia. (tämä siis pätee myös käytettävyystesteihin, ei ainoastaan asiantuntija-arviointeihin).
- Tuodaan myös esiin aivan oikein asiantuntija-arvioinneista, että "the greater the difference between the knowledge and experience of the experts and the real users, the less reliable are the results". On oikeasti varottava pintapuolisia asiantuntija-arviointeja!
--------
Yhteenveto
"Even at the earliest stages in the project, design concepts should be evaluated to obtain a better understanding of the user needs. ... However, evaluation by users ... is not always practical or cost effective at every stage of a project. ... design solutions should also be evaluated in other ways - for example using task modelling and simulations. These methods are still centred on how the user will experience the system even though the users themselves might not participate directly. User-centred evaluation can be used to
a) collect new information about user needs;
b) provide feedback on strengths and weaknesses of the design solution from the users’ perspective (in order to improve the design);
c) assess whether user requirements have been achieved (which can include assessing conformity to international, national, local, corporate or statutory standards);
d) establish baselines or make comparisons between designs.
....
There is a variety of user-centred evaluation methods which can be used to evaluate designs.
....
To obtain valid results, the evaluation should be carried out by experienced practitioners, and should use appropriate methods.
...
Two widely used approaches to user-centred evaluation are:
- user based testing;
- expert evaluation using usability and accessibility guidelines or requirements.
When prototypes are used, they should be used to collect user feedback while carrying out tasks, rather than just being demonstrations to show users a preview of the design. The information gathered is used to drive the design.... Later in development, user testing can be used to assess whether usability objectives including measurable usability performance and satisfaction criteria have been met in the intended context or contexts of use.
Expert evaluation can be valuable and cost effective and can also complement user testing. It can be used to eliminate major issues before user testing (and hence make the user testing more cost- effective).... Expert evaluation can be supported by checklists, lists of user requirements, general usability guidance, industry best practices, usability heuristics, guidelines or standards. However, the effectiveness of the expert evaluation always depends on the skills, experience and knowledge of the experts.
Expert evaluation is simpler and quicker to carry out than user testing and can, in principle, take account of a wider range of users and tasks than user-based evaluation... Experts do not always find the same problems that would be found in user based testing. Expert evaluation tends to emphasize obvious problems and might not scale well for complex or novel interfaces. The greater the difference between the knowledge and experience of the experts and the real users, the less reliable are the results. When appropriate, expert evaluation can be carried out with domain experts working alongside the usability expert."
-------------------
Evaluointi on perinteisintä käytettävyysasiaa, eikä tässä tule mitään erityistä yllättävää esiin. Muutama huomio kuitenkin:
- Korostetaan aivan oikein käytettävyystestien rajallisuutta menetelmänä. Käyttäjätestit eivät useinkaan ole kustannustehokas tapa tehdä evaluointia
- Korostetaan asiantuntijuuden roolia käytettävyysarvioinneissa. Tämä tietenkin pitää paikkaansa. Mutta on syytä ottaa muistaa, että "käytettävyysasiantuntijuus" ei ole selkeästi määritetty asia. Esimerkiksi Molich & al tutkimukset (2006) osoittavat, että ammattimaiset käytettävyysasiantuntijat voivat tuottaa hyvinkin erilaisia tuloksia. (tämä siis pätee myös käytettävyystesteihin, ei ainoastaan asiantuntija-arviointeihin).
- Tuodaan myös esiin aivan oikein asiantuntija-arvioinneista, että "the greater the difference between the knowledge and experience of the experts and the real users, the less reliable are the results". On oikeasti varottava pintapuolisia asiantuntija-arviointeja!
--------
Yhteenveto
- Tuo esiin tiiviisti käytettävyysarvioinnin pääpiirteet
- Voisi enemmän korostaa käytettävyysarviointeihin liittyviä laaturiskejä
- Tuodaan esiin kautta linjan ammattimaisuuden tarpeellisuutta ja käyttäjätuntemuksen hyödyllisyyttä
- Samaan aktiviteettiin sisällytetty sekä laadullinen ("provide feedback on strengths and weaknesses of the design solution") että todentava ("assess whether user requirements have been achieved") evaluointi. Itse näkisin nämä kaksi luonteeltaan sen verran erilaisina, että erottaisin ne omiksi aktiviteeteikseen
tiistai 4. toukokuuta 2010
"6.4. Producing design solutions"
Pääkohtia:
"6.4.1 General
.....
Potential design solutions are produced by drawing on the description of the context of use, the results of any baseline evaluations, the established state of the art in the application domain, design and usability guidelines and standards, and the experience and knowledge of the multidisciplinary design team.
......
(Sub-activities)
6.4.2 Designing user tasks, user-system interaction and user interface to meet user requirements, taking into consideration the whole user experience
........
6.4.2.1 Principles for design
The following principles (taken from ISO 9241-110) should be taken into account when designing interactive systems: suitability for the task; self-descriptiveness; conformity with user expectations; suitability for learning; controllability; error tolerance; suitability for individualization.
.............
6.4.2.2 Designing the tasks and interaction between the user and the system
Appropriate design of the user-system interaction relies on a clear understanding of the intended context of use, including the users’ roles and tasks and their outputs. This leads to an appropriate ‘allocation of function’ – the division of system tasks into those performed by humans and those performed by technology.
.....Designing the interaction should include:
a) making high level decisions;
b) identifying tasks and sub-tasks;
c) allocating tasks and sub-tasks to the user and to other parts of the system;
d) identifying the interaction objects required for the completion of the tasks;
e) identifying and selecting appropriate dialogue techniques (see ISO 9241 parts...)
f) designing the sequence and timing (dynamics) of the interaction; g) designing the information architecture of the user interface of an interactive system to allow efficient access to interaction objects.
....
6.4.2.3 Designing the user interface
For the detailed design of the user interface there is a substantial body of ergonomics and user interface knowledge, standards and guidelines which should be used to inform the design...
....
6.4.3 Making the design solutions more concrete
Using simulations, models and mock-ups or other forms of prototype allows designers to communicate in a meaningful way what the proposed design is/would be like to users and other stakeholders.
....
6.4.4 Altering the design solutions in response to user-centred evaluation and feedback
Feedback from evaluation should be used to improve and refine the system.
...
6.4.5 Communicating the design to those responsible for implementation
There are a variety of ways of communicating the design solution to those teams and individuals responsible for implementation or manufacture.
.....
Whatever the nature of the overall project, there should be some sustained channel of communication between those responsible for human-centred design and other members of the project team."
---------------------------------------
Tässä kuvataan siis suunnitteluratkaisujen tuottamista. Tuodaan aivan oikein esiin se, että suunnitteluratkaisuhin vaikuttavat monet seikat ("description of the context of use, the results of any baseline evaluations,..."). Tosin tästä listasta jostain syystä on jäänyt pois yksi oleellinen kohta, nimittäin "user requirements" (tosin tulee esiin myöhemmin kohdassa 6.4.2.2)
Myöskin tuodaan hyvin esiin se, että käyttäjän työn suunnittelu (designing the tasks) on oma suunnittelukohteensa. Tähän kohtaan on myös siirretty loogisesti aivan oikein yksi ISO 13407 periaate, "allocation of function".
Viittaukset standardisarjan muihin osiin sekä yleensä suunnitteluohjeistojen hyödyntämiseen ovat myös paikallaan.
Muutama "parannettavaa" -näkökulma:
"6.4.1 General
.....
Potential design solutions are produced by drawing on the description of the context of use, the results of any baseline evaluations, the established state of the art in the application domain, design and usability guidelines and standards, and the experience and knowledge of the multidisciplinary design team.
......
(Sub-activities)
6.4.2 Designing user tasks, user-system interaction and user interface to meet user requirements, taking into consideration the whole user experience
........
6.4.2.1 Principles for design
The following principles (taken from ISO 9241-110) should be taken into account when designing interactive systems: suitability for the task; self-descriptiveness; conformity with user expectations; suitability for learning; controllability; error tolerance; suitability for individualization.
.............
6.4.2.2 Designing the tasks and interaction between the user and the system
Appropriate design of the user-system interaction relies on a clear understanding of the intended context of use, including the users’ roles and tasks and their outputs. This leads to an appropriate ‘allocation of function’ – the division of system tasks into those performed by humans and those performed by technology.
.....Designing the interaction should include:
a) making high level decisions;
b) identifying tasks and sub-tasks;
c) allocating tasks and sub-tasks to the user and to other parts of the system;
d) identifying the interaction objects required for the completion of the tasks;
e) identifying and selecting appropriate dialogue techniques (see ISO 9241 parts...)
f) designing the sequence and timing (dynamics) of the interaction; g) designing the information architecture of the user interface of an interactive system to allow efficient access to interaction objects.
....
6.4.2.3 Designing the user interface
For the detailed design of the user interface there is a substantial body of ergonomics and user interface knowledge, standards and guidelines which should be used to inform the design...
....
6.4.3 Making the design solutions more concrete
Using simulations, models and mock-ups or other forms of prototype allows designers to communicate in a meaningful way what the proposed design is/would be like to users and other stakeholders.
....
6.4.4 Altering the design solutions in response to user-centred evaluation and feedback
Feedback from evaluation should be used to improve and refine the system.
...
6.4.5 Communicating the design to those responsible for implementation
There are a variety of ways of communicating the design solution to those teams and individuals responsible for implementation or manufacture.
.....
Whatever the nature of the overall project, there should be some sustained channel of communication between those responsible for human-centred design and other members of the project team."
---------------------------------------
Tässä kuvataan siis suunnitteluratkaisujen tuottamista. Tuodaan aivan oikein esiin se, että suunnitteluratkaisuhin vaikuttavat monet seikat ("description of the context of use, the results of any baseline evaluations,..."). Tosin tästä listasta jostain syystä on jäänyt pois yksi oleellinen kohta, nimittäin "user requirements" (tosin tulee esiin myöhemmin kohdassa 6.4.2.2)
Myöskin tuodaan hyvin esiin se, että käyttäjän työn suunnittelu (designing the tasks) on oma suunnittelukohteensa. Tähän kohtaan on myös siirretty loogisesti aivan oikein yksi ISO 13407 periaate, "allocation of function".
Viittaukset standardisarjan muihin osiin sekä yleensä suunnitteluohjeistojen hyödyntämiseen ovat myös paikallaan.
Muutama "parannettavaa" -näkökulma:
- Käyttäjän työn (käyttäjätehtävien) suunnittelu ja interaktiosuunnittelu ovat sen verran eri asioita, että niiden olisi loogista olla omia aktiviteettejaan. Ja nimenomaan niin, että käyttäjän työn suunnittelu ohjaa interaktiosuunnitelua
- Voisi tuoda selkeämmin esille käyttöliittymän tasot. Niin, että standardit ja ohjeistot erityisesti ohjaavat "pintatason" interaktiosuunnittelua kun taas "context of use" ja "user requirements" ohjaavat käyttöliittymän rakennesuunnittelua. Samoin sitä, että suunnitteluhaaste riippuu mitattavien käytettävyysvaatimusten (user requirements) vaativuustasosta.
- Suunnittelun yhteistyöstä tuodaan vähän yksisuuntainen kuva ("...communicating the design solution to those... responsible for implementation"). Implementoijien tulisi olla mukana jo itse suunnitteluratkaisujen luonnissa, jotta suunnitteluratkaisut olisivat jo lähtökohdiltaan toteutuksellisesti helppoja
- Vaikka tekstissä viitataan hyvin standardeihin ja ohjeistoihin, olisi voinut enemmän korostaa, että suunnittelijoiden tulisi tuntea näiden sisältö.
- Sisältää hyvin perusasioita, joiden tulisi ohjata suunnitteluratkaisujen tuottamista
- Käyttäjän työn (tehtävien) suunnittelun ja interaktiosuunnittelun eroa olisi voinut korostaa
- Samoin olisi voinut korostaa, että suunnitteluratkaisujen laatuun kannattaa panostaa heti alusta lähtien. Evaluoinnin kautta suunnittelu on välttämättä resursseja kuluttavaa, ja sitä kannattaisi pyrkiä minimoimaan
tiistai 27. huhtikuuta 2010
"6.3 Specifying the user requirements"
Pääkohtia:
"In most design projects, identifying user needs and specifying the functional and other requirements for the product or system is a major activity. For human-centred design, this activity shall be extended to create an explicit statement of user requirements in relation to the intended context of use and the business objectives of the system.
...
User and other stakeholder needs should be identified, taking account of the context of use. These should include what users need to achieve (rather than how to achieve it)
...
The specification of user requirements shall include:
a) the intended context of use;
b) requirements derived from the user needs and the context of use
c) requirements arising from relevant ergonomics and user interface knowledge, standards and guidelines
d) usability requirements and objectives, including measurable usability performance and satisfaction criteria in specific contexts of use - for example an objective might be that 90 % of the intended users can successfully divert an incoming call to voice mail, or for the aesthetic design of a Web page to achieve a given user satisfaction score;
e) requirements derived from organizational requirements that directly affect the user - for example a call centre system might require that customer calls aswered within a specific time frame."
--------
Aluksikin termi "user requirements" ei ole semanttisesti paras mahdollinen: siitä voi saada sen kuvan, että kyseessä olisi "käyttäjien määrittämät vaatimukset". Näinhän ei todellakaan ole. Vaatimukset kyllä tulee osaltaan pohjautua käyttäjädataan, mutta ne eivät suinkaan ole käyttäjän määrittämät.
Kuvauksen lähtökohta on hyvä: käyttäjävaatimusten määrittely tulisi pohjautua niin käyttökontekstiin kuin liiketoiminnan lähtökohtiin ("... in relation to the intended context of use and the business objectives").
Tuotoksen ("the specification") kuvaus on osaltaan epämääräinen: mitä lisäarvoa esimerkiksi kohta "b) requirements derived from the user needs and the context of use" tuo?
Kohta "c) requirements arising from relevant ... knowledge, standards and guidelines" on sinällään oleellinen. Kuitenkin tässä jätetään avoimeksi se ongelma, että näiden noudattaminen on vaikeasti todennettava asia. Otetaanpa vaikka esimerkiksi tuttu "käytä käyttäjän kieltä". Miten todentaa objektiivisesti, että täyttyykö tällainen vaatimus?
Kohta "d) ... including measurable usability performance and satisfaction criteria" on tärkeä, koska periaatteessa mittareilla päästään vaatimusten todennettavuuteen. Kuitenkin esimerkit ovat ongelmallisia. Vaatimusta "... 90 % of the intended users can successfully divert an incoming call to voice mail" ei voida todentaa, ellei testata koko käyttäjäkunnalla. Jos testataan suppeammalla testiryhmällä, saadaan ainoastaan tietty tilastollinen luottamus. Puolestaan vaatimus "... to achieve a given user satisfaction score" on ongelmallinen, koska yleensä käyttäjätyytyväisyysmittareille on hankala määrittää "hyvän" rajaa.
Aktiviteetin kuvauksen puute on myös se, että ei käydä tarkemmin läpi sitä, mitä käytännössä tarkoittaa "... in relation to ... the business objectives". Tämä on kuitenkin hyvin merkittävä näkökulma. Mistäpä muualta kuin liiketoimintatavoitteista tulisi määräytyä esimerkiksi tuo esimerkki "...90% of the intended users".
Yhteenveto:
"In most design projects, identifying user needs and specifying the functional and other requirements for the product or system is a major activity. For human-centred design, this activity shall be extended to create an explicit statement of user requirements in relation to the intended context of use and the business objectives of the system.
...
User and other stakeholder needs should be identified, taking account of the context of use. These should include what users need to achieve (rather than how to achieve it)
...
The specification of user requirements shall include:
a) the intended context of use;
b) requirements derived from the user needs and the context of use
c) requirements arising from relevant ergonomics and user interface knowledge, standards and guidelines
d) usability requirements and objectives, including measurable usability performance and satisfaction criteria in specific contexts of use - for example an objective might be that 90 % of the intended users can successfully divert an incoming call to voice mail, or for the aesthetic design of a Web page to achieve a given user satisfaction score;
e) requirements derived from organizational requirements that directly affect the user - for example a call centre system might require that customer calls aswered within a specific time frame."
--------
Aluksikin termi "user requirements" ei ole semanttisesti paras mahdollinen: siitä voi saada sen kuvan, että kyseessä olisi "käyttäjien määrittämät vaatimukset". Näinhän ei todellakaan ole. Vaatimukset kyllä tulee osaltaan pohjautua käyttäjädataan, mutta ne eivät suinkaan ole käyttäjän määrittämät.
Kuvauksen lähtökohta on hyvä: käyttäjävaatimusten määrittely tulisi pohjautua niin käyttökontekstiin kuin liiketoiminnan lähtökohtiin ("... in relation to the intended context of use and the business objectives").
Tuotoksen ("the specification") kuvaus on osaltaan epämääräinen: mitä lisäarvoa esimerkiksi kohta "b) requirements derived from the user needs and the context of use" tuo?
Kohta "c) requirements arising from relevant ... knowledge, standards and guidelines" on sinällään oleellinen. Kuitenkin tässä jätetään avoimeksi se ongelma, että näiden noudattaminen on vaikeasti todennettava asia. Otetaanpa vaikka esimerkiksi tuttu "käytä käyttäjän kieltä". Miten todentaa objektiivisesti, että täyttyykö tällainen vaatimus?
Kohta "d) ... including measurable usability performance and satisfaction criteria" on tärkeä, koska periaatteessa mittareilla päästään vaatimusten todennettavuuteen. Kuitenkin esimerkit ovat ongelmallisia. Vaatimusta "... 90 % of the intended users can successfully divert an incoming call to voice mail" ei voida todentaa, ellei testata koko käyttäjäkunnalla. Jos testataan suppeammalla testiryhmällä, saadaan ainoastaan tietty tilastollinen luottamus. Puolestaan vaatimus "... to achieve a given user satisfaction score" on ongelmallinen, koska yleensä käyttäjätyytyväisyysmittareille on hankala määrittää "hyvän" rajaa.
Aktiviteetin kuvauksen puute on myös se, että ei käydä tarkemmin läpi sitä, mitä käytännössä tarkoittaa "... in relation to ... the business objectives". Tämä on kuitenkin hyvin merkittävä näkökulma. Mistäpä muualta kuin liiketoimintatavoitteista tulisi määräytyä esimerkiksi tuo esimerkki "...90% of the intended users".
Yhteenveto:
- huomattavasti selkeämpi ja yksinkertaisempi kuvaus kuin ISO 13407:ssa
- korostaa vaatimusten business -lähtöisyyttä ja mitattavuutta
- kuitenkin näiden kahden asian käsittelyssä puutteita: business -puoli jää vähälle käsittelylle, ja mittariesimerkit käytännössä ongelmallisia
ISO 9241-210
kirjoittelen blogia ISO 9241-210:stä; pidän tässä blogissa taukoa sen aikaa
http://iso9241-210.blogspot.com/
http://iso9241-210.blogspot.com/
tiistai 20. huhtikuuta 2010
"6.2 Understanding and specifying the context of use"
Kyseessä on "ihmiskeskeisen suunnittelun" ensimmäinen aktiviteetti.
Sisältöä:
Sisältöä:
- "Context of use": "The characteristics of the users, tasks and the organizational, technical and physical environment define the context in which the system is used".
- Nykyisen kontekstin analyysi on hyödyllistä, jotta ymmärrettäisiin uutta kontestia: "it is useful to gather and analyse information on the current context in order to understand and then specify the context that will apply in the future system".
- Tuotoksia ovat seuraavat määritykset:
- käyttäjä- ja muut asianosais- (stakeholders) ryhmät
- käyttäjien ja käyttäjäryhmien kuvaukset
- käyttäjien tavoitteet ja tehtävät
- järjestelmän ympäristöt
- "sufficient detail to support design"
- Verrattuna ISO 13407:aan tuodaan selkeämmin esille, että aktiviteetin tavoite on nimenomaan tulevan järjestelmän käyttökontekstin määritys (nykyisen järjestelmän kontekstimääritys nähdään potentiaalisesti hyödylliseksi, mutta ei siis itseisarvoksi).
- Myös verrattuna 13407:aan, kuvauksessa tuodaan selkeämmin esille, että eri käyttäjäryhmien tunnistaminen/määrittäminen on ekplisiittinen tehtävä (tämä oikeasti puuttuu ISO 13407:sta!). Ohjeita ei kuitenkaan anneta, miten tämä tehdään.
- Mielestäni selkeämpää olisi ollut, että käyttäjäryhmien tunnistaminen olisi oma aktiviteettinsa. Kun käytettävyysuunnittelun ensimmäinen kysymys tunnetusti on "ketä ovat käyttäjäsi?"
- Hieman epäselvästi tuodaan esiin, että käyttökonteksti on käyttäjäryhmästä riippuvaista, ja että se tulisi määrittää käyttäjäryhmäkohtaisesti. Tämä seikka myös tukee sitä, että selkeämpää olisi määrittää käyttäjäryhmien tunnistus omaksi aktiviteetikseen
- On hyvä, että puhutaan sekä käyttäjien tehtävistä että tavoitteista. Kuitenkin niin suhde jätetään epäselväksi. Oma tulkintani on, että keskeistä on tavoitteet; tehtävät ovat sitten tapoja saavuttaa tavoitteet.
- Aktiviteetti systemaatisesti suoritettuna on käytännössä mahdoton tehdä. Sen vuoksi ohje "should be described in sufficient detail to support the design activity" on mitä oleellisin.
- tullut vähän selkeyttä ISO 13407:aan verrattuna
- puutteena erillisen käyttäjäryhmien määritys -aktiviteetin puuttuminen; käyttäjätavoitteiden "löysä" käsittely
torstai 15. huhtikuuta 2010
Käyttäjäkokemuksen määritelmä
ISO 9241-210 sisältää kauan kaivatun (?) käyttäjäkokemuksen määritelmän:
User experience
"A person's perceptions and responses resulting from the use and/or anticipated use of a product, system or service
NOTE 1 User experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviours and accomplishments that occur before, during, and after the use.
NOTE 2 User experience is a consequence of brand image, presentation, functionality, system performance, interactive behaviour and assistive capabilities of the interactive system, the user's internal and physical state resulting from prior experiences, attitudes, skills and personality, and the context of use.
NOTE 3 Usability, when interpreted from the perspective of the users’ personal goals, can include the kind of perceptual and emotional aspects typically associated with user experience. Usability criteria can be used to assess aspects of user experience."
Oletan, että tämä määritelmä herättää keskustelua UX -asiantuntijoiden keskuudessa. Itse vain toteaisin, että kovin on laajasisältöinen määritelmä. Voipi olla, että ei auta yhteisen kielen löytymisessä, kun UX -asioista keskustellaan.
-----
Seuraavassa postauksessa käyn läpi ensimmäistä aktiviteettia, "Understand and specify the context of use".
User experience
"A person's perceptions and responses resulting from the use and/or anticipated use of a product, system or service
NOTE 1 User experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviours and accomplishments that occur before, during, and after the use.
NOTE 2 User experience is a consequence of brand image, presentation, functionality, system performance, interactive behaviour and assistive capabilities of the interactive system, the user's internal and physical state resulting from prior experiences, attitudes, skills and personality, and the context of use.
NOTE 3 Usability, when interpreted from the perspective of the users’ personal goals, can include the kind of perceptual and emotional aspects typically associated with user experience. Usability criteria can be used to assess aspects of user experience."
Oletan, että tämä määritelmä herättää keskustelua UX -asiantuntijoiden keskuudessa. Itse vain toteaisin, että kovin on laajasisältöinen määritelmä. Voipi olla, että ei auta yhteisen kielen löytymisessä, kun UX -asioista keskustellaan.
-----
Seuraavassa postauksessa käyn läpi ensimmäistä aktiviteettia, "Understand and specify the context of use".
ISO 9241-210 on ilmestynyt, korvaa ISO 13407:n
ISO 13407 on käyttäjäkeskeisen (käytettävyys-) suunnittelun tunnetuimpia standardeja.
Nyt siitä on ilmestynyt uusi versio; samalla ISO -nimike vaihtui: ISO 9241-210 "Human-centred design for interactive systems". Uusi nimike on looginen, koska ISO 9241 -sarja sisältää laajalti ergonomian, käyttöliittymien ja käytettävyyden suunnittelun ohjeistoja.
ISO 9241-210 määrittää "ihmiskeskeisen" suunnittelun periaatteet ja aktiviteetit, vastaavasti kuin ISO 13407. Periaatteet ovat:
Keskeisestä aktiviteettien suhteita kuvaavasta kuvasta haluttiin pitää kiinni, mutta se kuitenkin vähän muuttui. Kuva ilmentää aiempaa paremmin iterointia, mutta on visuaalisesti vähän kömpelö (lopputulos vasemmalle yläsuuntaan).
Nyt siitä on ilmestynyt uusi versio; samalla ISO -nimike vaihtui: ISO 9241-210 "Human-centred design for interactive systems". Uusi nimike on looginen, koska ISO 9241 -sarja sisältää laajalti ergonomian, käyttöliittymien ja käytettävyyden suunnittelun ohjeistoja.
ISO 9241-210 määrittää "ihmiskeskeisen" suunnittelun periaatteet ja aktiviteetit, vastaavasti kuin ISO 13407. Periaatteet ovat:
- The design is based upon an explicit understanding of users, tasks and
environments - Users are involved throughout design and development
- The design is driven and refined by user-centred evaluation
- The process is iterative
- The design addresses the whole user experience
- The design team includes multidisciplinary skills and perspectives
- Understanding and specifying the context of use
- Specifying the user requirements
- Producing design solutions
- Evaluating the design
Keskeisestä aktiviteettien suhteita kuvaavasta kuvasta haluttiin pitää kiinni, mutta se kuitenkin vähän muuttui. Kuva ilmentää aiempaa paremmin iterointia, mutta on visuaalisesti vähän kömpelö (lopputulos vasemmalle yläsuuntaan).
maanantai 12. huhtikuuta 2010
Apple ei kysele käyttäjiltä
Uusimassa Time -lehdessä (April 12, 2010) on juttu Applesta. Siinä sanotaan: "Apple never holds focus groups. It doesn't ask people what they want; it tells them what they're going to want next".
Yess! Juuri näin!
"Kysytään käyttäjiltä" on helposti ensimmäinen mieleen tuleva keino, kun halutaan kehittää tuotteista käyttäjäystävällisempiä.
Käyttäjälähtöisyys on a ja o. Ja käyttäjät toki tulee ottaa mukaan suunnitteluun. Mutta ei niin, että kysytään käyttäjiltä, "mitä he haluavat?" tai "haluavatko tätä ja tätä?". Tällainen lähestymistapa on ongelmallinen kahdestakin syystä. (1) Tulokset perustuvat käyttäjien jäsentelykykyyn. Se voi osua kohdalleen, mutta aika suuri todennäköisyys, että ei. (2) Käyttäjät laitetaan asemaan, joka ei ole heille luontainen. Itse käytän sähköpostia päivittäin, mutta minua ei tippaakaan kiinnosta pohtia, millaisen paremman sähköpostiohjelman haluasin. Minulla on paljon muutakin tekemistä.
Käyttäjien tulisi olla tiedon lähteitä, heille ominaisilla tavoillaan. Käytettävyysasiantuntijoiden ja suunnittelijoiden tulee tulkita ja muuntaa tämä tieto tuotteeksi, jota "käyttäjät haluavat seuraavaksi".
Yess! Juuri näin!
"Kysytään käyttäjiltä" on helposti ensimmäinen mieleen tuleva keino, kun halutaan kehittää tuotteista käyttäjäystävällisempiä.
Käyttäjälähtöisyys on a ja o. Ja käyttäjät toki tulee ottaa mukaan suunnitteluun. Mutta ei niin, että kysytään käyttäjiltä, "mitä he haluavat?" tai "haluavatko tätä ja tätä?". Tällainen lähestymistapa on ongelmallinen kahdestakin syystä. (1) Tulokset perustuvat käyttäjien jäsentelykykyyn. Se voi osua kohdalleen, mutta aika suuri todennäköisyys, että ei. (2) Käyttäjät laitetaan asemaan, joka ei ole heille luontainen. Itse käytän sähköpostia päivittäin, mutta minua ei tippaakaan kiinnosta pohtia, millaisen paremman sähköpostiohjelman haluasin. Minulla on paljon muutakin tekemistä.
Käyttäjien tulisi olla tiedon lähteitä, heille ominaisilla tavoillaan. Käytettävyysasiantuntijoiden ja suunnittelijoiden tulee tulkita ja muuntaa tämä tieto tuotteeksi, jota "käyttäjät haluavat seuraavaksi".
Tilaa:
Blogitekstit (Atom)