Мы делаем здесь amazing customer service (c)

  • aug 10, 2024
  • #work
  • читать 4 минуты

Продуктовый дизайн.
Что к чему.

Если вы так и не разобрались в чём разница UI, UX и продуктового дизайна, то бросьте эту затею:
UI — это интерфейс, UX — это пользовательский опыт, дизайн продукта — это проектирование его интерфейса (UI) с учётом пользовательского опыта (UX).
Это всё. Зря мучились много лет.

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

Что такое дизайн продукта/продуктовый дизайн мы поняли, а что считать продуктом?

Максимально авторитетные люди из интернета 🙂 считают, что продукт — это результат деятельности, который удовлетворяет потребности потребителей.
Ничего конкретного. Под это определение можно загнать хоть свои посты в соцсетях.
Так и есть, если ваши посты дают читателям возможность закрыть какую-то пользовательскую потребность.
Получается, что я CPO своего продукта в соцсети?
— Да 🙂.

Но мы же понимаем, что с таким заявлением меня никто на собеседование не пригласит?
— Снова, да.
Есть теория и определения, а есть практика и специфика локального рынка.
И эта специфика определяет тенденции и требования к кандидатам и к должности.
Иногда вы можете фактически быть дизайнером продукта, но вашу вакансию обозвали senior ux/ui-designer, а в трудовой записали как дизайнер интерфейсов. Такова реальность — пока эта отрасль не имеет обязательных к исполнению стандартов в нэйминге, как, например, электрик 1-го разряда.

А что в итоге называют продуктами в IT?
Со стороны пользователя — приложения/сервисы, которыми вы пользуетесь.
Внутри продуктовых компаний — любое количество направлений бизнеса, которые выделили в отдельную самостоятельную продуктовую единицу.
Например, в маркетплейсах люди работают над одним большим продуктом — платформой предоставления товаров/услуг, а внутри есть десятки мелких направлений — поставки, внутренние сервисы, приложение для продавцов, для покупателей, видео и т.п.
Или продукты выполняют один функционал, но работают в разных странах и сделаны под локальные рынки. И продуктовые команды развивают их под нужды местных пользователей.

А теперь про дизайн продукта.

Дизайн — это процесс. И, как любой процесс, он состоит из последовательности действий.
Эта последовательность называется дизайн-процессом.

Что там внутри:

  • Дизайнер участвует в предварительной оценке всей нагрузки на него на предстоящий отчётный период, квартал, например (в идеальном мире)
  • В обычном мире процесс начинается с оценки задач на следующий спринт. Если у вас есть шаблон постановки задачи на дизайн и заказчики приучены его придерживаться, то этот шаг идёт без лишних ресурсозатрат на собрания, переписки, выяснения, поиск информации
  • Затем задача берётся в работу, проверяется вся аналитика по описанной проблеме
  • Если проблема актуальна — проектируется решение
  • Решение проходит дизайн-ревью внутри команды
  • Чекается по чек-листу передачи фронтам
  • Едет к фронтам

Этот шаг со звёздочкой: передача задачи дизайн-фронт должна фиксироваться (нет, посмотреть в жиру не достаточно). Чтобы реализация шла логично и вовремя, СРАЗУ после закрытия на дизайне заводится задача на фронт.
Это должно быть организовано лидом/ПМ-ом/кем угодно в вашей структуре, кто отвечает за логистику задач в продукте.
На этом шаге просирают больше всего, актуальность дизайна-фронта можно соблюсти только чёткой последовательностью.

Самые слабые места в разработке чего-либо это кросс-функциональные взаимодействия. Направьте в эти места всю свою менеджерскую магию.

  • После реализации собирается аналитика «было-стало» и делается вывод — хорошо ли поправилось.
  • Если плохо — цикл повторяется, если хорошо — радость.

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

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

Не забывайте обедать 🍏.