2,5
рейтинг
16 января 2015 в 12:06

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

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



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


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

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

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


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

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


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

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

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

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


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

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

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

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


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

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

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


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

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


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

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


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

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

PS: Сами мы ещё толком не применяем ни один из этих принципов полностью (но очень хотим) и будет интересно, если те, кто читал эту книгу, поделятся своим опытом внедрения этих принципов в комментариях.
Владимир Варнавский @navff
карма
7,0
рейтинг 2,5
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (10)

  • +6
    Основной тезис книги — нужно создавать интерфейс для того, кто будет им пользоваться. Метод персон — хороший старт. Но разрабатывать интерфейс нужно в плотной связи с теми, кто будет им пользоваться. Если у вас в голове есть возможность моделировать поведение этих персон достаточно точно — то это хорошо. Но если вы этим и ограничитесь — то уже рискуете.

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

    Но это вектор. Его тоже надо уравновешивать неким «режиссёром» проекта, иначе можно завалиться в сторону капризов пользователя, и прошляпить новые сильные решения, к которым пользователи не привыкли. Как говорил Форд «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь.»

    Держать правильный баланс между этими противонаправленными векторами требует и опыта, и понимания, и силы воли.
    • 0
      Если у вас в голове есть возможность моделировать поведение этих персон достаточно точно — то это хорошо

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

      А, как вы думаете, кто может стать таким режиссёром? Менеджер проекта? Или кто-то, опять же, из команды проектировщиков интерфейса?
      • 0
        Ну стать может любой, у кого есть опыт и умение. А это с неба не падает, надо нарабатывать, сначала конечно учиться, такие книжки тоже, а потом уже практика. Умение слышать, а не слушать — тоже обязательно. Об этом можно долго говорить, но я не настоящий сварщик, так что не буду.
    • +1
      Вот про более быструю лошадь вы верно подметили. Люди редко видят нешаблонные решения своих задач. И не зря об обратной связи и ориентированности на пользователя говорят сейчас практически везде, только так можно почерпнуть хоть что-то о реальных (истинных) потребностях человека. И здесь очень важно работать с любыми мыслями и отзывами, в том числе — негативными. Ведь так люди проговаривают то, что их реально волнует, и этим надо суметь воспользоваться, чтобы улучшить свой продукт/услугу.
  • +1
    Благодарю, укрепилось желание таки дойти до чтения этой книги
  • 0
    Книга давно лежит на полке. Теперь точно прочитаю
    • +1
      Спасибо, что об этом написали. Мотивирует продолжать.
  • 0
    Программисты обычно заостряют внимание на исключительных ситуациях

    Сложно с этим согласиться. Заостряют, но тогда, когда первые два пункта реализованы. И не заостряют, а стараются реализовать, хотя это редко бывает обязательным.
    В общем, вы про каких-то сферических программистов пишете. Если нет в ТЗ задачи сделать экранную клавиатуру для кейса, когда у пользователя клавиатуры/нужной раскладки нет — программист ограничится обработкой исключения — выведет сообщение «подключите рабочую клавиатуру». Разумеется, если реализация не от безделия и бесконечного времени.
    • 0
      Я бы скорее даже ситуации реформатировал. Есть повседневные ситуации (собственно, основной функционал) и исключительные ситуации, которые происходят редко. При этом есть исключительные ситуации, которые необходимо реализовать (например, восстановление пароля) и исключительные ситуации, которые реализовывать не обязательно (например, пользователи с ограниченными возможностями или под IE6).
      Конечно, в самом лучшем случае должно быть реализовано всё, но тут уже встаёт вопрос планирования и разумного разбиения на итерации. Ну и профит, конечно.
    • 0
      Пишу не я, а Алан Купер, но я с ним согласен. Когда программисту дали недостаточно подробное ТЗ, он начинает делать так как считает нужным. Не являясь хорошим проектировщиком взаимдействия он наделает неудобных штук.
      А ещё бывает когда ТЗ пишет программист. Это совсем плохо, потому что пока он пишет ТЗ он думает о реализации, что неизбежно вносит ошибки с точки зрения UX.

      Основная идея Купера в том, что проектирование взаимодействия должно быть ДО программирования. Соответственно, если в ТЗ отражено всё то, что задумали проектировщики, то вот оно настоящее программистическое счастье. Остаётся только выполнить задуманное.

      Фраза, которую вы совершенно справедливо выделили больше относится к неправильному процессу. Если же в ваш процесс сразу включены хорошие UX-специалисты, то у вас всё хорошо и читать книгу можно по-диагонали.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.