"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"

• 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.

d) "The process is iterative"

• 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".

"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"

• 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ä. 

"b) Users are involved throughout design and development"

• 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".

"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

• 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

"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:

• 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ö. 

Yhteenveto:

• 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