[Веб-дизайн, Дизайн, Дизайн мобильных приложений, Интерфейсы] Продуктовый дизайнер: правила эксплуатации

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
23-Сен-2020 16:31

Цитировать

Дизайнеры продолжают эволюционировать.
В ширь, ввысь и даже вкось.
Если раньше было достаточно назваться дизайнером и научиться без запинки произносить слово «Фотошоп», то сейчас этих навыков уже явно недостаточно для поиска приличной работы.
Один из видов дизайнеров достаточно нового направления — продуктовый.
В статье именно о нем я и хочу поговорить.
Ударю по теории и практике.
В теории хочу разобраться кто это такой и что от него хотят.
На практике — описать процесс работы этого самого дизайнера над тем самым продуктом.
Поехали!

Часть первая. Теоретическая.
Кто такой, сколько стоит и чего ожидают
Итак, в первых строках своего письма, уважаемая публика, хочу все-таки пояснить, что ж это за зверь такой «Продуктовый дизайнер» и чего от него хотят компании, принимая в ряды свои славные.
Перво-наперво, обратилась к курсам, которые учат этому самому продуктовому дизайну.
Вот что говорят курсы.
Нетология обещает зарплату от 120 тыщ. рублей

«UX/UI дизайнер, дизайнер продукта — одна из самых востребованных digital-профессий с широкими возможностями для роста и высокой заработной платой
Она сочетает в себе аналитику и творчество, инженерный подход и нестандартность решений. Грамотная работа дизайнера увеличивает прибыль клиента и улучшает взаимодействие пользователя с продуктом.»

Skillbox приманивает зарплатой от 80 тысяч.

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

Bangbangeducation скромно умалчивая о наградах в денежном эквиваленте.

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

Вообщем достаточно размыто все в описаниях.
Теперь кинем взор на hh.ru и посмотрим, чего же реально ждут работодатели от человека, именуемого продуктовый дизайнер.
Действовала я топорно и без изысков: вбила в поисковую строку «Продуктовый дизайнер» и выписала часто встречающиеся требования.
Хозяйке на заметку: в вакансиях уровень зарплат часто не указывают, поэтому реальную картину понять достаточно тяжело.
Но могу огорчить обещателей и ожидателей зп от 100 тыщ.
Есть, есть компании, которые хотят много, но платить за это много совсем не готовы.
Ну и погнали теперь по общим требованиям:

Опыт работы в дизайнерских и около того программах (Sketch, Zeplin, Figma, InVision, Adobe Photoshop и пр.);
Опыт работы с web, iOS и Android (потому что есть шанс, что будешь и там, и тут);
Разбираться в современных трендах дизайна;
Красиво визуализировать что дадут. А дать могут не только сложные и интересные фичи, но и баннеры, лендинги, иконки или иллюстрации. Отсюда, соответственно, вытекает знание основ композиции, типографики, и прочих таких необходимых простому дизайнеру штук;
Шарить в паттернах человеческого поведения. Быть в курсе того, что в мире проектирования интерфейсов твориться, что бы не только спроектировать, но и свою гипотезу выдвинуть, а чужую аргументированно задвинуть. На основе чего ты будешь выдвигать и задвигать это уже тебе либо скажут, либо сам придумаешь;
Быть ux-аудитором — проверить то, что уже есть и исправить это в лучшую сторону, естественно;
Бодро отслеживать конкурентов, постоянно держа руку на пульсе;
Уметь общаться с пользователями. Это про проведение разного рода исследований и тестирований;
Уметь дизайн-систему если не создать, то руку к уже готовой приложить;
Где-то надо будет заняться еще и аналитикой (тут в зависимости от ситуации: либо понимать, что тебе говорит и показывает аналитик, либо быть тем самым аналитиком);
Грамотно писать тексты, так что местами надо будет совмещать роль и ux писателя;
Уметь быстрого прототипировать. Что бы идеи показать, проверить, оттащить пользователю на тест;
Понимать что frontend могет, а чего не могет. А так как сейчас frontend могет практически все, только дай ему время и вдохновение, то лучше понимать время, которое займет у разраба твой дизайнерский или интерфейсный креатив; Не забываем следить за качеством того, что все-таки front накреативит в итоге по твоим макетам;
Кстати, про креатив. Этот свой креатив лучше всего совмещать с логическим мышление на одних плечах;

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

На самом деле все у всех по-разному.
Но я точно знаю, что какая-то часть грозно составленных требований, без которых ну вот никак вам работу не потянуть, на деле оказывается либо не нужна, либо в совсем малом объеме.
Но это лично мой опыт. Может у кого-то совсем и не так.
Причина же такого положения дел бывает достаточно банальной: просто не хватает времени на все вот эти сюсю-пусю с исследованиями, тестированиями и прочей лабудой. Потому что уж замуж невтерпеж и партия сказала надо, а мы сказали есть.
А когда ты в одном лице и швец, и жнец, и на дуде игрец, то, понятное дело, разорваться из одного большого продуктового дизайнера на кучки мелких ux и ui -дизайнерика, ux-исследовательчика, копиральщичка, художничка и аналитичка просто сил нет никаких. Кстати, времени тоже. Но тут все, опять же, зависит от времени, сложности и прочих небесных тел.
Честно, я думаю, что когда-нибудь человек-оркестр закончится и один продуктовый дизайнер развалится на отдельные специальности. Потому, что и нагрузка бывает достаточно высока, и склад мозгов у всех разный.
Это как история с дизайнерами-верстальщиками.
В теории звучало хорошо. На практике, я не видела ни одного верстальщика, который мог бы качественно сделать дизайн с нуля и наоборот. Возможно, плохо искала или зрение меня подводит.
Но а пока я сижу, болтаю ножкой, жалуюсь на жизнь и называюсь продуктовым дизайнером, хочу поделиться опытом, как выстраивала процессы, что бы потом не было мучительно больно…
Потому что делать все равно надо.
Ну а как?
Во-первых, искать время и выстраивать процесс работы над продуктом так, что бы после запуска не падать в нервный обморок от осознания того, что вместо счастливого смеха пользователя ты слышишь его отборный мат. Ну и разрабы, опять же, как то нехорошо косятся в твою сторону.

Часть вторая. Практическая.
Основана на реальных событиях.
Не скажу, что на всех проектах у меня получилось сделать так, как задумывалось. Но были… были в моей биографии светлые пятна, когда получалось.
И об этих светлых пятнах и будет мой рассказ.
Тут стоит отдельно обратить внимание на то, что последние года четыре я занимаюсь разработкой проектов с нуля. Поэтому описание процесса будет касаться их. Но что-то мне подсказывает, что процесс можно примерить и к уже готовым продуктам.
И да, в статье я коснусь только процесса разработки и запуска именно нового функционала. Про генерацию гипотез, сбор обратной связи и прочее потом, иначе совсем много будет.
Итак…
Сбор требований с заказчика
Требования можно собирать от Product Owner, заказчика, или другого ответственного лица.
На этом этапе важно понять как это работает сейчас и как это видится ответственному лицу. Причем не только здесь и сейчас, а и с зазором на будущее.
Ведь когда видишь картину целиком, а не кусками, всегда проще закладывать основы на дальнейшее масштабирование и доработки.
Требования надо собирать тщательно, не оставляя ни одного белого пятна.
По хорошему, этим должен заниматься бизнес-аналитик. Узнал, записал, принес, сделал «Чмоки» и махнул ручкой на прощание.
Но, имея за плечами горький опыт сломанного телефона, уверена, что этим должен заниматься продуктовый дизайнер. Ну или присутствовать при сборе требований.
Потому, как есть вещи, которые аналитику не так важны, а вот при проектировании интерфейса без них никак. Поэтому сам и только сам, ну или рядом, как рояль в кустах с блокнотом, ручкой и диктофоном.
О диктофоне, кстати, хочу сказать отдельно: если не используете его в своей работе — начинайте использовать. Функция полезная до безобразия. Когда ты знаешь, что весь разговор записывается, ты можешь на нем сосредоточиться, не растеряв по пути фокус внимания, отвлекаясь на записи и прочее.
Сбор требований с пользователя
Это уже другая сторона медали.
Вот ты сейчас понял как это работает наверху, а теперь надо пойти и копнуть глубже. Копать надо в сторону тех, кто знает не только вершки, но еще и корешки.
Посидеть и посмотреть как он работает с тем, что уже есть.
Спросить что устраивает, а что нет. А как хотелось бы. Что важно при совершении определенного действия, принятия решения и прочее.
Даже если делаем то, чего еще нет, все равно они каким-то образом решают эти задачи.
Потыкав палкой в обе стороны, уже имеешь более-менее внятную картинку с которой можно работать.
Еще из важного: про то, как работает и что не так, лучше узнавать ни у экспертов, а у конечных пользователей. Потому, что у экспертов может оказаться только теория или воспоминания минувших дней, а у конечных пользователей реальная практика, боль и слезы.
Почему я обращаю на это внимание? Потому что опять же шишки из практики. Собрал проблемы от экспертов, выпустился и поехал смотреть, насколько рады конечные пользователи свалившемуся на них счастью в виде решения их проблем.
И вдруг, внезапно, оказалось, что часть проблем не валидна, часть возникает не тут и не в это время, а часть вообще звучит странно и хз им бедным, что с этим делать. Короче, спасибо, решили, правда только хуже сделали.
Схема пути пользователя
Эту часть можно назвать CJM, можно еще как-то.
Ее суть состоит в том, что после полученной кучи знаний, эту кучуя нужно преобразовать в какой-то удобряемый для дальнейшей работы вид, это раз. Два — решить, все ли понято, учтено и записано со слов потерпевшего верно.
Напоминаю, что сейчас рассказываю про разработку нового продукта. Как я это делала. Возможно, кто-то делает по другому или не делает совсем.
А я брала и раскладывала весь пользовательский путь употребления какой-то функцией от точки А до Б, от Б до С и так далее.
Так как часто приходилось делать то, чего еще нет, то реальные проблемы, радости и прочее передать не могла.
Прикидывала, в теории, что там может быть, в какой момент они рискуют свернуть на темную сторону зла, пройти не по тому пути и прочее.
Продумывая каждый шаг с возможными вариантами проблем, ответвлений и прочее, легко увидеть, понял ли ты сам, что собрался делать (да-да, даже на этом этапе, после всех разговоров можно наткнуться на неизвестный рояль в кустах, после чего пойти и еще что-то уточнить). Каким оружием в виде кнопок, инфы, картинок и котиков ты снабдишь своего будущего бойца.
Когда весь путь чист, как слеза младенца, можно уже и к прототипу приступать.
Прототип первый: бумажный
Не знаю, может для кого-то этот шаг не обязательный, но я его делаю всегда. Помогает быстро накидывать и исправлять решения, не отвлекаясь на красоту кнопок и градиентов.
Бумажки можно разложить в ряд и оценить логику и понятность будущего продукта.
На бумажках можно даже выписать какие-то моменты, которые нужно еще подумать или сразу выписывать возникающие вопросы, которые нужно будет уточнить у разработки, например.
Прототип второй: динамический
Я его делаю в Axure.
Честно, пробовала в других программах, но мне элементарно не удобно, особенно когда будет достаточно большое количество экранов.
Динамический прототип нужен для того, что бы показать высшим силам, что все идет как надо и пользователю в момент тестирования.
Не скажу, что я его прям дизайню, но какие-то важные акценты и цвета делаю.
Тестирование прототипа
Прогон по сценарию с прототипом помогает убедиться, что вы таки попали туда, куда целились. А может попали, но не туда. А может вообще не попали.
В любом случае, все правки прототип переносит легче, чем продукт, запущенный в прод.
Тестирую на проход по определенным сценариям, насколько пользователь понимает значение символов, удобно ли ему представлена информация и прочее.
Не скажу, что все проходит гладко и правильно.
Были и ограничения по времени, когда просто приходишь и показываешь итог своей работы. Типа, вот смотрите: вы просили, а мы вот чего сделали. Потом сидишь и слушаешь обратную связь.
Первый раз думала, что фиг из такого подхода что хорошее получится, но нет. Ошибки, непонятные и спорные моменты найти все-таки удалось.
Поэтому сделала вывод, что если уж не получается выделить время «на поговорить», то можно ограничиться показом, собрав обратную связь.
Это точно лучше, чем ничего.
Показ прототипа разработке
Вообще, получается такой фокус не всегда, но считаю важным находить на это время двум сторонам.
Часто, когда время ограничено, что-то можно упростить, не теряя при этом качества.
Можно еще отметить места, которые потребуют более детального описания логики работы, чтобы разработчикам потом жилось легче.
Тадам! Финишная прямая: дизайн
Тут рассказывать особенно нечего. Садишься, открываешь программулину и начинаешь рисовать хорошо или не очень то, над чем трудился в предыдущих сериях.
Позволяет время — идешь набираться визуального и прочего вдохновения на ресурсах, названия которых нельзя произносить, потому что последнее время их часто хают.
Передача в разработку
Раньше описывала сценарии в формате user story.
Звучало это примерно так:
Я, как …., хочу…
Далее описывалась сама функция, действия с ней пользователем, дополнительные возможности и пр.
Оказалось, что иногда получается много и никто это читать не желает, поэтому стала лепить примечания в самом прототипе и раскладывать в miro путь уже надизайненными экранами.
Оказалось, что разработчикам так работать значительно удобней.
Они видят все сразу, могут задать вопросы или наклеить стикеры, что бы что-то не забыть.
Собственно, это практически все, что я хотела поведать о том, как продуктовый дизайнер должен работать с задачей.

Заключение
Повторюсь, что это мое виденье и мой опыт.
Каждый из шагов важен для того, что бы получилось хорошо. И на каждый из шагов необходимо время.
Наверно, поэтому я не очень верю в историю о том, что позиция продуктовый дизайнер проживет долго. Ну или у каждого будет по мешку времени, или что-то будет прорабатываться не так тщательно.
Очень хотелось бы узнать ваше мнение о построении процессов работы, обязанностях и возможностях продуктового дизайнера.
Будет ли актуальна эта профессия в будущем или распадется, в конце-концов, на отдельных узких специалистов.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_vebdizajn (Веб-дизайн), #_dizajn (Дизайн), #_dizajn_mobilnyh_prilozhenij (Дизайн мобильных приложений), #_interfejsy (Интерфейсы), #_razvitie_produkta (развитие продукта), #_produktovyj_dizajn (продуктовый дизайн), #_produktovyj_dizajner (продуктовый дизайнер), #_opyt_raboty (опыт работы), #_interfejsy (интерфейсы), #_interfejs (интерфейс), #_opyt (опыт), #_opyt_vnedrenija (опыт внедрения), #_vebdizajn (
Веб-дизайн
), #_dizajn (
Дизайн
), #_dizajn_mobilnyh_prilozhenij (
Дизайн мобильных приложений
), #_interfejsy (
Интерфейсы
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 00:42
Часовой пояс: UTC + 5