Custom Search

jeudi 29 décembre 2011

(Translations) Запитайте себе "А що б зробив користувач?"

Переклад статті з книги 97 Things Every Programmer Should Know про те, як мислить юзер і як його краще зрозуміти. Більше стосується програмування, та думаю і тестерам може бути цікаво. Буду вдячний за будь-які зауваження щодо помилок чи неточностей. Також вдячний друзям за допомогу. Ну що ж, поїхали!

В оригіналі статтю можна прочитати тут.

Запитайте себе "А що б зробив користувач?"

Giles Colborne
Ми всі часто припускаємо, що інші люди думають так само як і ми. Але це не так. Психологи називають це упередженням несправжньої згоди. Людей, які мислять або поводяться не так як ми, ми часто (підсвідомо) вважаємо неповноцінними.

Це припущення пояснює, чому програмістові так складно поставити себе на місце користувача. Користувачі думають зовсім не так, як це роблять програмісти. Перш за все, вони проводять значно менше часу за комп’ютером. Вони не знають, яким чином працює комп’ютер, та їх це й не цікавить. Це означає, що вони не можуть застосувати одну з багатьох технік розв’язання проблем, які добре відомі програмістам. Вони не розпізнають структури та натяки, які допомагають програмістам використовувати, вдосконалювати та обходити інтерфейс.

Найкращий спосіб дізнатися, як думає користувач, -- це спостерігати за ним. Попросіть його виконати якесь завдання, використовуючи програмне забезпечення, схоже на те, що ви розробляєте. Переконайтесь, що завдання цілком реальне: "Знайти суму колонки чисел" -- нормально; "Підрахувати витрати за останній місяць" -- взагалі чудово. Уникайте занадто конкретизованих завдань, на зразок "Виберіть комірки таблиці і введіть формулу сумування під ними" -- занадто багато підказок в одному реченні. Дозвольте користувачу розповісти про його успіхи. Не перебивайте. Не намагайтесь допомогти. Постійно запитуйте себе "Чому він робить саме так?".

Перше, що ви помітите -- це те, що користувачі роблять більшість речей однаково. Вони намагаються виконати завдання в одному й тому ж порядку і роблять однакові помилки в тих самих місцях. Слід взяти цю базову поведінку за основу. Це не те саме, що відбувається на нарадах з проектування, де люди схильні слухати, коли хтось каже: "А якщо користувач захоче те-то і те-то?". Це призводить до появи хитромудрих функцій і непорозумінь щодо вимог користувача. Спостереження за користувачами допоможе уникнути цих непорозумінь.

Ви побачите, як користувачі потрапляють у глухий кут. Коли ви потрапляєте в таку ситуацію, ви оглядаєтесь навколо. Користувач же, коли опиняється в тупику, навпаки, зосереджується на місці виникнення проблеми. Йому стає важче побачити рішення деінде на екрані. Ось чому тексти допомоги є поганим рішенням проблеми неякісно розробленого інтерфейсу. Якщо необхідно подати інструкції або текст допомоги, обов’язково розташуйте їх поряд з проблемними місцями. Через вузьке поле уваги користувача спливаючі підказки ефективніші, ніж меню допомоги.

Користувачі як-небудь справляються з труднощами. Вони знаходять робочий спосіб і постійно ним користуються, навіть якщо він дуже заплутаний. Краще забезпечити один очевидний спосіб виконання завдання, ніж декілька посилань на спосіб вирішення проблеми.

Ви також побачите, що між тим, що користувач каже, хоче та робить насправді, є певна різниця. Саме це і хвилює найбільше, бо найпоширеніший спосіб збирати користувацькі вимоги -- це задавати їм запитання. Ось чому найкращий метод вловлювати вимоги до продукту -- це спостерігати за користувачами. Провести годину, спостерігаючи за процесом роботи користувачів, краще, ніж витратити весь день, роблячи припущення про те, чого вони хочуть.

Aucun commentaire:

Enregistrer un commentaire