От продуктового дизайна к full stack

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

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

Full stack design
Full stack design

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

Не проси новых прав – проси новой ответственности.

Только через 10 лет до меня начал доходить смысл этой фразы. Действительно, новые права и свободы автоматически даются лишь тем, кто взваливает на себя новые обязанности и трудности, и никак иначе.

Вот как это может работать:

  • Дизайнер сам взвалил на себя сам работу с анимацией, за пару выходных сделал кучу крутых примеров – и получил полную свободу влиять на продукт через новый инструмент коммуникаций с пользователями.
  • Дизайнер сам взвалил на себя сам встречу и адаптацию новичков в команде, сам сверстал небольшой приветственный буклет, и начал вести субботний Clubhouse от лица своей команды – и вот он уже не просто джун, а дизайн-менеджер.

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

Утеря квалификации

Однако, перед тем, как взваливать на себя новую ношу и получать больше власти над продуктом, каждый дизайнер должен честно ответить себе на один вопрос:

А достаточно ли я компетентен для выполнения этой новой задачи? Не провалю ли я весь проект?

Ответить честно – это не значит заглянуть в свое резюме и портфолио, где сегодня у всех и каждого записан и продуктовый дизайн, и UI/UX, и motion, и брендинг упаковок...

Ответить честно – это посмотреть, чем действительно регулярно занимался последние полгода. Регулярно, то есть каждый день, в худшем случае пару раз в неделю. Каждую неделю.

Приведу себя в пример: пару лет назад я не только сам хорошо знал юнит-анализ, отлично умел строить различные его модели и проверять десятки продуктовых гипотез прямо в Excel без отрисовки макетов; но я еще и учил этому других, много и часто.

Открыв недавно собственные же таблички по юнит-анализу, я уже не мог вспомнить половину тонкостей и собственных лайфхаков. Поскольку за последний год (так уж вышло) эта экспертиза не была регулярно и ежедневно востребована – я утратил эту квалификацию. Да, можно вспомнить, восстановить, почитать – но чем это сейчас отличается от «научиться заново»?

В текущем моменте моя экспертиза ушла, остались только поверхностные знания, то есть лишь горизонтальная, а не вертикальная плашка из T-shape. По-честному теперь будет удалить слово «продуктовый» из своего резюме и все те проекты из портфолио, которые выросли благодаря им. Поскольку делал их не Я-сегодняшний, а Я-вчерашний, человек с другим жизненным опытом, иным набором ежедневных навыков и знаний тонкостей профессии. К счастью, на смену старому навыку пришли несколько новых, но тоже только в кратковременную память.

Скажу еще проще:

  • Если дизайнер не проводит сам пару раз в неделю исследования, опросы, тестирования в полях – то он не UX, а все его знания о «глубинном народе» выветрились полгода назад, когда он последний раз заглядывал на чай в UX-лабораторию,
  • Если дизайнер не открывает каждое утро цифровые метрики продукта, не считает регулярно деньги, клики, минуты и возвраты – то он не продуктовый дизайнер. Сертификат годичной давности от GoPractice протухает без ежедневного применения.
  • Если дизайнер не чаще раза в месяц от скуки тыкается в анимацию и в шрифты, то он не motion и не шрифтовик, чудес не бывает.

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

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

От продуктового дизайна к full stack

Доверили бы вы такому «дизайнеру презентаций» сходу новый и сложный продукт уровня CRM, несмотря на самое героическое прошлое?

Сшибание лбами

Итак, экспертиза – это то, за что ты ежедневно отвечаешь. Но есть еще один важный момент, который нельзя упускать – это когда компании уже есть человек или даже несколько, которые выделены и точечно направлены на ту сферу, в которой хотелось бы самому получить больше влияния. Скажем проще:

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

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

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

Учитывая огромную проблему «глухих телефонов», когда одна и та же информация искажается на 15-30% при каждом новом звене передачи по живой цепи, то совмещать в одном человеке и продуктовое видение, и навык сразу воплощать его в макеты – может дать до 30% роста эффективности работы в команде.

Не терять время на совещания, объяснения и переводы, а сразу делать в дизайне быстро и максимально круто в соотвествии с собственным продуктовым видением и отталкиваясь от собственного прочтения аналитики – что может быть лучше и быстрее! Но для этого дизайнер должен перестать быть просто визуализатором чужой воли и опыта, а превратить себя в full stack эксперта по продукту, по пользовательскому опыту, по целевой аудитории. И по проверке гипотез через юнит-анализ в Excel -ке, разумеется))

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

Идея прекрасная, да и на практике получается пока неплохо, и никто никому не мешает, и все чувствуют собственное громадное влияние на итоговый продукт.

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

А вы готовы к появлению в вашей компании full stack дизайнеров?

11
2 комментария

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

5
Ответить

Хороший пост

Ответить