Когда Дес попросил меня написать для Inside Intercom, я как раз только что познакомила своих сооснователей в Aim — рекламном маркетплейсе для рынка недвижимости — с подходом Jobs-to-be-Done.
Наш дизайн-процесс был полон неясностей и отсутствия единства. У меня, у CEO, у CTO и у руководителя дизайна были разные предложения по дизайну. Но у нас не было эффективного способа обосновать одну идею и оспорить другую.
И тут меня осенило. Не ссылаясь напрямую на Jobs-to-be-Done, я начала выделять самые удачные предложения, которые предлагали мои сооснователи. Я описала затруднённый момент, с которым сталкивались наши пользователи, и объяснила, как изменится их жизнь, когда проблема будет решена. Затем я показала, как их предложение хорошо соответствует этой задаче дизайна. По сути, я описала работу, которую пользователи пытаются «нанять» наш продукт выполнить, и как выглядит их опыт, когда работа выполнена.
Используя язык Jobs-to-be-Done, мы за считаные минуты утвердили первый дизайн. И с тех пор никогда не возвращались к прежнему подходу.
Персоны и пользовательские истории имели смысл, когда между клиентами и продуктными командами была большая дистанция. Сейчас это уже не так.
Раньше понимание того, кто такие клиенты и что им нужно, было задачей маркетинга, бизнес-девелопмента или даже отдела продаж. Когда информация собиралась, её переводили в удобный формат и передавали «через забор» команде разработки продукта.
Жертвой этого каскадного процесса становились тонкие, но критически важные детали: причинность, тревоги, мотивации. Jobs-to-be-Done — это философия, которая фокусируется именно на этих нюансах. А конкретный инструмент, позволяющий внедрить этот подход в продукт, — это Job Stories, которые помогают проектировать фичи, интерфейсы и пользовательский опыт.
Как уже упоминал Дес, персоны часто описываются через атрибуты, которые не имеют отношения к причинности. Например, возраст, пол, раса и привычки на выходных человека не объясняют, почему он съел батончик Snickers. А вот наличие 30 секунд на покупку и перекус, который утолит голод на ближайшие полчаса — объясняет.
Как пользователь, я могу указать папки, которые не нужно сохранять, чтобы мой диск для резервных копий не заполнялся ненужными файлами.
Пользовательские истории, вроде этой, имеют три серьёзные проблемы:
Фичи часто проваливаются. Если фича была описана через user story, понять, почему она не сработала, будет сложно, потому что мотивации и реализация в ней жёстко сцеплены. А значит, неясно: проблема была в реализации или в том, что мы неправильно поняли мотивацию?
Впервые упомянутые Полом Адамсом в блоге Intercom и далее развёрнутые здесь, Job Stories представляют собой иной подход к проектированию фич. Но как внедрить их в рабочий процесс команды?
