Кто такой пользователь и его задача

Люди покупают не дрель, а отверстие в стене. Дизайн начинается с понимания, какую «работу» человек поручает продукту.

«Никто не хочет купить четвертьдюймовое сверло. Люди хотят четвертьдюймовое отверстие». — Теодор Левитт

Главная ошибка начинающих — проектировать функции вместо задач. Функция — это «кнопка экспорта в PDF». Задача — «мне нужно отправить отчёт начальнику так, чтобы он открылся на его телефоне». Один и тот же человек в разных ситуациях «нанимает» продукт под разные задачи, и интерфейс должен это учитывать.

Фреймворк Jobs to Be Done

Подход JTBD (Jobs to Be Done, «работа, которую нужно сделать») предлагает описывать пользователя через формулу: «Когда [ситуация], я хочу [мотив], чтобы [результат]». Например: «Когда я еду в метро без интернета, я хочу заранее скачать билет, чтобы пройти турникет без паники». Эта формула важнее, чем возраст и пол.

  ФОРМУЛА ЗАДАЧИ (JTBD)

  Когда [ситуация]  ->  Я хочу [мотив]  ->  Чтобы [результат]
       |                    |                     |
   еду в метро        скачать билет        пройти турникет
   без интернета      заранее              без паники

Контекст важнее портрета

Раньше дизайнеры рисовали «персону»: «Аня, 27 лет, любит йогу». Сегодня этого мало — важнее ситуация использования. Один человек утром в спешке и вечером на диване — это два разных пользователя с разными задачами, хотя возраст у него один.

Как делают ПЛОХО

Команда добавляет фичи списком: «давайте сделаем экспорт, импорт, шаринг, тёмную тему». Никто не спросил, какую задачу человек решает. Получается швейцарский нож с 40 функциями, в котором невозможно найти ту одну, что нужна сейчас.

Как делают ХОРОШО

Команда формулирует 3-5 ключевых задач и проектирует так, чтобы каждая решалась за минимум шагов. Остальное прячут глубже или не делают. Интерфейс получается простым, потому что он отвечает на конкретные вопросы людей.

Чек-лист

• Я могу записать задачу пользователя по формуле «Когда… хочу… чтобы…».
• Я знаю ситуацию (контекст), а не только возраст и пол.
• Каждая функция привязана к конкретной задаче.
• Я готов выкинуть фичу, если за ней нет реальной задачи.

Теория Jobs To Be Done переворачивает вопрос: люди не «покупают продукт», они «нанимают» его на работу. Знаменитая история про молочный коктейль: сеть фастфуда долго улучшала вкус, пока не выяснила, что коктейли «нанимают» утром водители в скучной пробке — чтобы было чем занять руки и не проголодаться до обеда. Густой напиток, который долго тянется через трубочку, побеждал не банан и не пончик, а скуку дороги.

У любой задачи три слоя. Функциональный — что объективно нужно сделать (доехать сытым). Эмоциональный — как человек хочет себя чувствовать (спокойно, без спешки). Социальный — как он хочет выглядеть в глазах других (заботливый родитель, а не тот, кто кормит ребёнка чем попало). Один и тот же продукт нанимают на разные работы в зависимости от ситуации: тот же коктейль вечером покупают как лакомство ребёнку — и тут важны уже совсем другие свойства.

Главная опасность — строить список фич вместо понимания работ. Команда добавляет функции, потому что их просят конкуренты или сам пользователь, и продукт пухнет, не становясь нужнее. Спрашивайте не «какую кнопку добавить», а «ради какого прогресса меня сюда наняли» — иначе вы конкурируете не с тем, с чем думаете.

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

Итог

Дизайн начинается не с экрана, а с человека и его задачи в конкретной ситуации. Сформулируйте задачу — и половина решений об интерфейсе придёт сама собой.

Начинайте любой проект не с экрана, а с работы, на которую вас наняли: запишите её словами пользователя и сверяйтесь с ней при каждом решении. Это самый дешёвый способ не построить никому не нужный набор функций.