Відмінності між версіями «Експертна оцінка»
(не показані 18 проміжних версій 3 учасників) | |||
Рядок 1: | Рядок 1: | ||
− | + | ==Коротко== | |
− | + | Евристична оцінка (heuristic evaluation) - це форма дослідження юзабіліті, в якій фахівці з юзабіліті оцінюють кожен елемент інтерфейсу, спираючись на список певних принципів юзабіліті (які називаються "евристики"). Експертна ж оцінка (expert evaluation) - це те ж саме, тільки без опори на специфічні евристики. | |
− | Метод | + | Метод експертної оцінки, при якому експерт висуває гіпотези щодо поліпшення інтерфейсу сайту і, виходячи з них, відбувається перепроектування сайту, проте перевірити, чи справді ця гіпотеза вірна, можна тільки за підсумком впровадження змін, що тягне за собою більшу ціну помилки. |
+ | |||
+ | ''Приклад: за допомогою Google analytics можна визначили, що користувачі заходять на сторінку реєстрації, проте її не проходять. Можливо, користувачі не можуть зрозуміти, яку інформацію вводити в поля або не знають, що робити далі, після заповнення полів. Значить, нам необхідно протестувати дану сторінку по метрик зрозумілості системних повідомлень та експлуатаційної послідовності.'' | ||
+ | |||
+ | Як правило, в оцінці системи беруть участь два-три аналітика, які перевіряють дизайн системи на відповідність обумовленими правилами і принципами. Вони записують свої спостереження і сортують їх у порядку серйозності виявлених проблем. Як аналітиків запрошують фахівців в галузі взаємодії людини і комп'ютера або фахівців з людського фактору, але, як показує досвід, і менш досвідчені фахівці були здатні виявити серйозні проблеми. | ||
+ | |||
+ | ==Плюси== | ||
+ | |||
+ | <ul> | ||
+ | <li>Метод дозволяє отримати швидко і порівняно недорого оцінку роботи дизайнерів. На підставі результатів можуть з'явитися хороші ідеї щодо поліпшення інтерфейсу. Команда розробників отримає можливість дізнатися, яким чином інтерфейс може бути поліпшений</li> | ||
+ | <li> | ||
+ | Існує загальновизнаний думку, що результати аналізу за цим методом є цінним і корисним внеском у процес розробки. Метод може застосовуватися і на ранньому етапі дизайну, коли постійна перевірка інтерфейсу на предмет дотримання встановлених правил дозволять забезпечити сумісність інтерфейсу з інтерфейсами інших подібних систем.</li> | ||
+ | |||
+ | <li>Дуже вигідно проводити евристичну оцінку наранніх прототипах , ще до того, як до подальшого тестування прототипів будуть залучені реальні користувачі</li> | ||
+ | <li>Проблеми з юзабіліті, виявлені на даному етапі, досить легко побачити і оцінити: це можуть бути проблеми з вибором кольору, взаємне розташування елементів, однаковість термінології, однаковість відповідної реакції системи на дії користувача. Існує думка, що проблеми виявлені даним методом аналогічні проблемам, які можна виявити методом оцінки продуктивності, хоча без сумніву кожен з методів дозволяє виявити свої особливі проблеми, які не можна знайти інший спосіб.</li> | ||
+ | <li>Цей метод може надати дуже крітіканським, так як дизайнер отримує звіт тільки за знайденими проблем, а гарні рішення і знахідки в звіті зазвичай не згадуються.</li> </ul> | ||
+ | |||
+ | Даний метод служить для виявлення проблем з юзабіліті на основі певних принципів людського фактора. Метод дозволяє скласти рекомендації щодо поліпшення дизайну системи. Тим не менш, у зв'язку з тим, що метод покладається на думку експертів, як результат ви більшою мірою отримаєте абстрактну оцінку функціональності системи і її дизайну, а не оцінку того, наскільки з нею зручно працювати реальному користувачеві. | ||
+ | |||
+ | ==Планування== | ||
+ | У зручний час зберіть групу експертів. Для зборів підготуйте матеріал для роботи та обладнання для презентації. У всіх аналітиків має бути достатньо часу на те, щоб ознайомитися з вашим продуктом, а також зі сценаріями роботи з ним. Вони також повинні бути ознайомлені з вашою системою оцінки. | ||
+ | |||
+ | ==Проведення== | ||
+ | |||
+ | Експертам слід надати всю необхідну інформацію, пов'язану з передбачуваними групами користувачів, завданнями, які вони повинні виконувати і інш. Перед початком сесії слід провести невеликий інструктаж, щоб погодити спільний набір критеріїв, якими будуть користуватися експерти. Втім, якщо експерти знайомі з даним методом, інструктаж можна пропустити. | ||
+ | |||
+ | Потім експерти працюють з системою виконуючи обумовлені завдання і записують свої спостереження у вигляді списку. Якщо в експерименті бере участь два або більше експертів, вони не повинні перемовлятися один з одним до тих пір, поки експеримент не буде закінчений. Після того, як оцінка буде завершена, експерти можуть звірити свої списки і оцінити кожен пункт на предмет серйозності проблеми. | ||
+ | |||
+ | ==Висновок== | ||
+ | Як результат експерименту виступає список виявлених проблем, який відсортований за ступенем серйозності тієї чи іншої проблеми. | ||
+ | |||
+ | В кінці списку можна вказати кількість виявлених проблем, відсоток кількості знайдених проблем в ставленні до очікуваної кількості, передбачувана кількість нових проблем, які можливо будуть виявлені при включенні певного числа додаткових експертів. | ||
+ | |||
+ | Після проведення експерименту пишеться звіт, в якому перераховуються виявлені проблеми. Звіт передається в команду розробників. Якщо проблеми були розсортовані за важливістю, у звіті описується, за якою схемою визначалася ця важливість. | ||
+ | |||
+ | [http://usethics.ru/blog/lib/testing_by_the_cheap/#_Toc104718087 Юзабіліті-тестування] |
Поточна версія на 21:36, 30 жовтня 2013
Коротко
Евристична оцінка (heuristic evaluation) - це форма дослідження юзабіліті, в якій фахівці з юзабіліті оцінюють кожен елемент інтерфейсу, спираючись на список певних принципів юзабіліті (які називаються "евристики"). Експертна ж оцінка (expert evaluation) - це те ж саме, тільки без опори на специфічні евристики.
Метод експертної оцінки, при якому експерт висуває гіпотези щодо поліпшення інтерфейсу сайту і, виходячи з них, відбувається перепроектування сайту, проте перевірити, чи справді ця гіпотеза вірна, можна тільки за підсумком впровадження змін, що тягне за собою більшу ціну помилки.
Приклад: за допомогою Google analytics можна визначили, що користувачі заходять на сторінку реєстрації, проте її не проходять. Можливо, користувачі не можуть зрозуміти, яку інформацію вводити в поля або не знають, що робити далі, після заповнення полів. Значить, нам необхідно протестувати дану сторінку по метрик зрозумілості системних повідомлень та експлуатаційної послідовності.
Як правило, в оцінці системи беруть участь два-три аналітика, які перевіряють дизайн системи на відповідність обумовленими правилами і принципами. Вони записують свої спостереження і сортують їх у порядку серйозності виявлених проблем. Як аналітиків запрошують фахівців в галузі взаємодії людини і комп'ютера або фахівців з людського фактору, але, як показує досвід, і менш досвідчені фахівці були здатні виявити серйозні проблеми.
Плюси
- Метод дозволяє отримати швидко і порівняно недорого оцінку роботи дизайнерів. На підставі результатів можуть з'явитися хороші ідеї щодо поліпшення інтерфейсу. Команда розробників отримає можливість дізнатися, яким чином інтерфейс може бути поліпшений
- Існує загальновизнаний думку, що результати аналізу за цим методом є цінним і корисним внеском у процес розробки. Метод може застосовуватися і на ранньому етапі дизайну, коли постійна перевірка інтерфейсу на предмет дотримання встановлених правил дозволять забезпечити сумісність інтерфейсу з інтерфейсами інших подібних систем.
- Дуже вигідно проводити евристичну оцінку наранніх прототипах , ще до того, як до подальшого тестування прототипів будуть залучені реальні користувачі
- Проблеми з юзабіліті, виявлені на даному етапі, досить легко побачити і оцінити: це можуть бути проблеми з вибором кольору, взаємне розташування елементів, однаковість термінології, однаковість відповідної реакції системи на дії користувача. Існує думка, що проблеми виявлені даним методом аналогічні проблемам, які можна виявити методом оцінки продуктивності, хоча без сумніву кожен з методів дозволяє виявити свої особливі проблеми, які не можна знайти інший спосіб.
- Цей метод може надати дуже крітіканським, так як дизайнер отримує звіт тільки за знайденими проблем, а гарні рішення і знахідки в звіті зазвичай не згадуються.
Даний метод служить для виявлення проблем з юзабіліті на основі певних принципів людського фактора. Метод дозволяє скласти рекомендації щодо поліпшення дизайну системи. Тим не менш, у зв'язку з тим, що метод покладається на думку експертів, як результат ви більшою мірою отримаєте абстрактну оцінку функціональності системи і її дизайну, а не оцінку того, наскільки з нею зручно працювати реальному користувачеві.
Планування
У зручний час зберіть групу експертів. Для зборів підготуйте матеріал для роботи та обладнання для презентації. У всіх аналітиків має бути достатньо часу на те, щоб ознайомитися з вашим продуктом, а також зі сценаріями роботи з ним. Вони також повинні бути ознайомлені з вашою системою оцінки.
Проведення
Експертам слід надати всю необхідну інформацію, пов'язану з передбачуваними групами користувачів, завданнями, які вони повинні виконувати і інш. Перед початком сесії слід провести невеликий інструктаж, щоб погодити спільний набір критеріїв, якими будуть користуватися експерти. Втім, якщо експерти знайомі з даним методом, інструктаж можна пропустити.
Потім експерти працюють з системою виконуючи обумовлені завдання і записують свої спостереження у вигляді списку. Якщо в експерименті бере участь два або більше експертів, вони не повинні перемовлятися один з одним до тих пір, поки експеримент не буде закінчений. Після того, як оцінка буде завершена, експерти можуть звірити свої списки і оцінити кожен пункт на предмет серйозності проблеми.
Висновок
Як результат експерименту виступає список виявлених проблем, який відсортований за ступенем серйозності тієї чи іншої проблеми.
В кінці списку можна вказати кількість виявлених проблем, відсоток кількості знайдених проблем в ставленні до очікуваної кількості, передбачувана кількість нових проблем, які можливо будуть виявлені при включенні певного числа додаткових експертів.
Після проведення експерименту пишеться звіт, в якому перераховуються виявлені проблеми. Звіт передається в команду розробників. Якщо проблеми були розсортовані за важливістю, у звіті описується, за якою схемою визначалася ця важливість.