Вичавки з «Психлікарні в руках пацієнтів»

Нещодавно я прочитав книгу Алана Купера «Психлікарня в руках пацієнтів». З неї мені вдалося почерпнути ряд ідей на тему «як покращити розробку». Нижче ряд рекомендацій з книги, які я беру на озброєння.
Надихнув мене Milfgard ось цим постом. Спробую прочитати всі цікаві для мене книги з цього списку.



1. Метод персон
Я чув про нього раніше в презентаціях Дмитра Сатину та інших шановних товаришів, але ніколи не брав як за керівництво до дії. Проте Алан Купер говорить, що це потрібно робити обов'язково.

Отже, суть у тому, щоб відійти від поняття «користувач» і перейти до реально-нереальним людям. Тобто ми придумуємо персонажів з реальної цільової аудиторії нашого продукту, але, при цьому, вони не повинні бути реальними людьми. Наприклад, для сайту готелю це буде так:

Марина, 25 років. Офіс-менеджер невеликої компанії з 30 чоловік. Працює вдень у світлому московському офісі і їй все подобається. Обов'язки: підтримувати хорошу атмосферу в офісі, стежити за тим, щоб все працювало, готувати відрядження і оформлювати для цього документи: бронювати номери в готелях і замовляти квитки. Більшість рішень приймає самостійно, віддаючи на підпис лише підсумковий рахунок. Хороший чоловік і трирічна дочка.


Для такої людини вже набагато простіше проектувати, ніж для сферичного користувача у вакуумі, і коли виникне питання, чи потрібна їй функція виводу на друк, ми відповімо, що так, потрібна: Марина роздрукує інформацію про броні і пройдеться по людям, які їдуть у відрядження. Чи збереже в PDF і розішле співробітникам поштою.

2. Пам'ятати про цілі
У кожної людини, яка користується нашим продуктом є якісь цілі. Це:
  1. особисті (не відчувати себе нерозумно, не робити помилок, виконати адекватний обсяг роботи, розважитися);
  2. практичні (уникати зборів, задовольняти вимогам клієнта, зберігати історію замовлень, передзвонювати клієнтам);
  3. корпоративні (збільшити прибуток, перемогти конкурентів, набрати персонал, відкрити ще два магазини);
  4. помилкові (простота в освоєнні, економія пам'яті, поліпшення зовнішнього вигляду, прискорення введення даних).
Ці цілі є в порядку пріоритетів для людей. В першу чергу особисті, а потім все інше. Якщо особисті цілі будуть конфліктувати з корпоративними, — у довгостроковій перспективі переможуть особисті.

Важливо відрізняти від мети завдань. Для виконання однієї мети ми можемо виконати безліч маленьких завдань, однак, ніколи не потрібно забувати про кінцевої мети.

3. Складати сценарії
Добре концентруватися на сценаріях роботи людей. Це та штука, яка дозволяє нам поставити себе на місце Марини з попереднього прикладу. Звучить десь так: «Мені кажуть дати відрядження, співробітників, яких потрібно надіслати, і місце, куди потрібно відправити. Я шукаю готелів в цьому місті через інтернет, дізнаюся ціни, вільні номери і, якщо мене все влаштовує, — я бронюю».

А сценарії бувають трьох видів:
  1. Повсякденні (Вони самі корисні і важливі. Дії, описані в них, виконуються найчастіше);
  2. Обов'язкові (Вони можуть використовуватися рідко, але можливість їх використання обов'язково повинна бути. Наприклад, термінова бронювання з передоплатою готівкою від юр. особи або скасування броні);
  3. Виняткових ситуацій (Вони розробляються в останню чергу і їх можна заховати в глибини інтерфейсу. Приклад: у Марини зламалася клавіатура, але їй потрібно забронювати номер негайно).
Програмісти зазвичай загострюють увагу на виняткових ситуаціях, однак у випадку сценаріїв потрібно зосередитися на повсякденних, часто повторюваних діях.

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

Правильним буде розраховувати на середнячків. Попередньо, звичайно, визначивши, хто ці самі середнячки.

5. Головне — головне
Важливо пам'ятати про часто використовуваних функцій і зробити їх максимально доступними. Рідко використовуваний функціонал можна сховати. Microsoft спробували впровадити такий підхід у своєму MS Word, починаючи з 2007 версії, правда, з шкодою для рідкісного функціоналу, який тепер не знайти.

6. Домовитися про загальному словнику
Часто одні і ті ж поняття різними учасниками процесу можуть бути витлумаченими по-різному. Клієнт може мати на увазі одне, а розробник зовсім інше. Наприклад: «На моєму сайті повинна бути можливість купити замовне дослідження». Якщо запитати клієнта про можливість оплати, то він відповість, що ціна на замовне дослідження не визначена заздалегідь і, тому, за неї не можна заплатити на сайті. Краще, якщо заявка відправиться на пошту. Таким чином, ми тільки що відмовилися від функціоналу покупки/оплати з усіма наслідками, просто уточнивши термін «купити».

7. Проектування взаємодії і детальна документація
Одна з найважливіших штук — це проектування взаємодії. За успішність проекту повинні відповідати саме проектувальники взаємодії, які готують сценарії, думають про персони і т. д. З програмістів при підході «Проектування UI → Дизайн → Програмування → Тестування» відповідальність за загальний успіх продукту знімається.

Важливо, щоб всі що напроектіровалі проектувальники було ретельно задокументовано. Тоді завжди можна перечитати і зрозуміти, чи в правильному напрямку ми рухаємося. В документації обов'язково використовуються імена персонажів, розроблених методом персон.

PS: ми Самі ще до пуття не застосовуємо жоден з цих принципів повністю (але дуже хочемо) і буде цікаво, якщо ті, хто читав цю книгу, поділяться своїм досвідом впровадження цих принципів у коментарях.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.