Сервис развивается: тестируем формат, собираем идеи, улучшаем сервис. Есть идеи? Написать
Войти
Метод персонажей: гипотетический архетип вместо среднего пользователя

Метод персонажей: гипотетический архетип вместо среднего пользователя

Чтобы сделать программы человечными, проектировщики используют специализированный арсенал. Главным инструментом выступает метод персонажей (Personas). Начиная проект, команды часто попадают в ловушку: пытаются найти реального пользователя и проектировать систему под него. Этот подход ошибочен. Любой реальный человек обладает набором случайных привычек и странностей. Проектируя для него, команда подстраивает интерфейс под чужие индивидуальные причуды.

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

Персонаж как гипотетический архетип

Вместо поиска реального индивида создается вымышленный пользователь с четко выверенными свойствами — гипотетический архетип. Он конструируется на основе качественных исследований: глубинных интервью и полевых наблюдений за людьми в их естественной среде.

В практике велик соблазн создать несколько персонажей, чтобы «угодить всем». Однако попытка сделать софт удобным и для клерка, и для пожилой домохозяйки гарантирует создание монстра, непригодного для обоих. Возникает феномен «эластичного пользователя», когда разработчики мысленно растягивают образ клиента под инженерные удобства: то приписывают ему любовь к тонким настройкам, то нежелание думать. Проектирование всегда ведется строго под одного главного персонажа.

Правило одного главного персонажа

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

Кейс чемодана на колесиках: от узкой роли к мировому стандарту

Опыт показывает: продукт, идеально оптимизированный под одну специализированную группу, естественным образом завоевывает массовый рынок. Хрестоматийный пример — изобретение чемодана на колесиках.

Пилот авиакомпании Northwest Airlines Роберт Платт в конце 1980-х сконструировал дорожный чемодан с выдвижной ручкой и колесиками (Rollaboard) строго для членов экипажей самолетов. Летчикам и стюардессам требовалось быстро ходить по узким проходам авиалайнеров. Платт решил задачу конкретного персонажа. В результате чемодан на колесиках покорил миллионы обычных путешественников, став глобальным мировым стандартом багажа.

Кейс чемодана Rollaboard Роберта Платта

Изобретатель проектировал вещь исключительно для летных экипажей, решавших задачу перемещения в узких салонах. Фокусировка на потребностях одной роли породила решение, ставшее мировым эталоном.

Сила предельной конкретизации

Чтобы персонаж работал эффективно, он обязан быть предельно конкретным. Его описывают во всех жизненных мелочах: имя, возраст, профессия, доход, марка автомобиля и привычный распорядок дня. Детали помогают понять, что для этого человека является по-настоящему удобным.

Сила конкретных деталей

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

Три фундаментальных преимущества метода персонажей

  1. Реальное понимание компьютерной грамотности. Персонаж показывает подлинный уровень подготовки аудитории, развеивая иллюзии о «продвинутых пользователях».
  2. Беспощадное закрытие споров о функциях. В дискуссии о добавлении кнопки проектировщик оперирует фактами о персонаже: «Персонажу Джейн не нужна выгрузка в XML, ее задача — за две секунды распечатать чек на кассе».
  3. Единая система координат и Definition of Done. Персонаж дает команде общую точку опоры. Продукт готов только тогда, когда удовлетворены цели персонажа.

Критерии жизнеспособности персонажа

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