Выжимки из «Психбольницы в руках пациентов»

Недавно я прочитал книгу Алана Купера «Психбольница в руках пациентов». Из нее мне удалось почерпнуть ряд идей на тему «как улучшить разработку». Ниже ряд рекомендаций из книги, которые я беру на вооружение.
Вдохновил меня Milfgard ^[1] вот этим постом ^[2]. Попробую прочитать все интересные для меня книги из этого списка.

1. Метод персон

Я слышал о нем раньше в презентациях Дмитрия Сатина и других уважаемых товарищей, но никогда не принимал как за руководство к действию. Однако Алан Купер говорит, что это нужно делать обязательно.

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

Марина, 25 лет. Офис-менеджер небольшой компании из 30 человек. Работает днём в светлом московском офисе и ей всё нравится. Обязанности: поддерживать хорошую атмосферу в офисе, следить за тем, чтобы всё работало, готовить командировки и оформлять для этого документы: бронировать номера в отелях и заказывать билеты. Большинство решений принимает самостоятельно, отдавая на подпись лишь итоговый счёт. Хороший муж и трёхлетняя дочь.

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

2. Помнить о целях

У каждого человека, который пользуется нашим продуктом есть какие-то цели. Это:

1. ​личные (не чувствовать себя глупо, не совершать ошибок, выполнить адекватный объём работы, развлечься);
2. практические (избегать собраний, удовлетворять требованиям клиента, хранить историю заказов, перезванивать клиентам);
3. корпоративные (увеличить прибыль, победить конкурентов, набрать персонал, открыть ещё два магазина);
4. ложные (простота в освоении, экономия памяти, улучшение внешнего вида, ускорение ввода данных).

Эти цели даны в порядке приоритетов для людей. В первую очередь личные, а потом всё остальное. Если личные цели будут конфликтовать с корпоративными, — в долгосрочной перспективе победят личные.

Важно отличать цели от задач. Для выполнения одной цели мы можем выполнить множество маленьких задач, однако, никогда не нужно забывать о конечной цели.

3. Составлять сценарии

Хорошо концентрироваться на сценариях работы людей. Это та штука, которая позволяет нам поставить себя на место Марины из предыдущего примера. Звучит где-то так: «Мне говорят даты командировки, сотрудников, которых нужно отправить, и место, куда нужно отправить. Я ищу отели в этом городе через интернет, узнаю цены, свободные номера и, если меня всё устраивает, — я бронирую».

А сценарии бывают трёх видов:

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

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

4. Продукт для средних представителей аудитории

Программисты склонны предполагать, что люди открыли наш сайт/программу и знают, что тут делать. Но чем больше функций при этом мы сделаем, тем выше порог вхождения. Будет вполне определённый крен в сторону подготовленной аудитории.
С другой стороны, руководители и менеджеры-продажники, наоборот, недооценивают способности пользователей. Они думают, что им нужно всё разжевать, показать и сделать максимально просто. Крен в сторону неподготовленной аудитории.

Правильным же будет рассчитывать на середнячков. Предварительно, конечно, определив, кто эти самые середнячки.

5. Главное — главное

Важно помнить о часто используемых функциях и сделать их максимально доступными. Редко используемый функционал можно спрятать. Microsoft попытались внедрить такой подход в своём MS Word, начиная с 2007 версии, правда, с ущербом для редкого функционала, который теперь не найти.

6. Договориться об общем словаре

Часто одни и те же понятия разными участниками процесса могут быть истолкованными по-разному. Клиент может иметь ввиду одно, а разработчик совершенно другое. Например: «На моём сайте должна быть возможность купить заказное исследование». Если спросить клиента про возможность оплаты, то он ответит, что цена на заказное исследование не определена заранее и, поэтому, за неё нельзя заплатить на сайте. Лучше, если заявка отправится на почту. Таким образом, мы только что отказались от функционала покупки/оплаты со всеми вытекающими, просто уточнив термин «купить».

7. Проектирование взаимодействия и подробная документация

Одна из самых важных штук — это проектирование взаимодействия. За успешность проекта должны отвечать именно проектировщики взаимодействия, которые готовят сценарии, думают о персонах и т.д. С программистов при подходе «Проектирование UI → Дизайн → Программирование → Тестирование» ответственность за общий успех продукта снимается.

Важно, чтобы всё что напроектировали проектировщики было тщательно задокументировано. Тогда всегда можно перечитать и понять, в правильном ли направлении мы движемся. В документации обязательно используются имена персонажей, разработанных методом персон.

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

Автор: navff

Источник ^[3]