Пять моих ошибок на старте карьеры продуктового дизайнера

Описание ошибок и способы их избежать.

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

До сих пор помню легкое напряжение, которое было между дизайном (мной) и командой разработки. Мы были как будто два лагеря. Я, как дизайнер, считал, что разработчики не могут нормально реализовать мои идеи. Разработчики считали, что я слишком много уделяю внимания мелочам.

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

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

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

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

* Пример из опыта работы над сервисом для тайных покупателей, где пользователи посещали магазины, записывали аудио визита и отвечали на вопросы анкеты.

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

Если хотите отточить навык проведения интервью, прочитайте отличную книгу «Спроси маму» Роберта Фитцпатрика.

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

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

Как мы помним, Basecamp и Slack — изначально внутренние продукты, которые решили вывести в публичный доступ. Но самый забавный пример — дизайнеры Figma улучшают свой продукт в Figma.

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

Как надо: находить критические места продукта и пытаться их улучшить. Я верю в то, что лучшие продукты сначала копают вглубь (оттачивают ключевые сценарии), а не вширь (добавляют новые функции).

Определить критические места помогут CJM, интервью и аналитика.

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

Как надо: заранее определить, какая метрика описывает выбранную проблему, а после реализации решения сравнить цифры до и после. Если цифры улучшились, решение сработало.

В больших корпоративных продуктах в первую очередь фокус лучше делать на качественных данных (интервью), а не количественных (аналитика). Ведь такие продукты люди будут использовать в любом случае (руководство купило, значит, надо).

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

Если не знаете как помочь продукту — поговорите с пользователем и выясните их основные боли, а дальше тесно взаимодействуйте с разработчиками, чтобы решить их лучшим образом. А после определите, решили или нет. Вот и все.

Мой Telegram-канал и Instagram, где я делюсь опытом развития продукта, прочитанными книгами и размышлениями, а так же отвечаю на вопросы читателей. Другие полезные материалы на iskros.com.

Спасибо за внимание, друзья.
Не повторяйте моих ошибок.