20 частых ошибок продуктовых дизайнеров. Мнение

Привет! Меня зовут Руслан, я ведущий проектировщик интерфейсов в Ростелеком ИТ плюс. В статье расскажу про то, какие ошибки допускают многие продуктовые дизайнеры

20 частых ошибок продуктовых дизайнеров. Мнение

1. Делать дизайн для дизайнеров, а не для целевой аудитории

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

Это заметно, когда на командном ревью диалог сразу уходит в сторону висячих предлогов, кавычек и скруглений углов вместо того, чтобы задуматься «А точно ли нужен этот сценарий в таком виде? Какую проблему мы решаем? На какие бизнесовые метрики должна повлиять наша задача?»

2. Быть абсолютно уверенным, что полученные во время исследования результаты — правда

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

3. Зацикливаться только на UX/UI и не думать о бизнес-целях продукта

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

Иногда доходит до абсурда. У продукта клиентская база полтора землекопа, потому что еще не найден Product-Market fit, а дизайнеры упорно пытаются впихнуть в роадмап UI-редизайны, ребрендинги, красивые иллюстрации, анимации и прочие вишенки для торта.

Вместо этого стоит задуматься «А что сейчас мешает нашему продукту быстрее набирать клиентскую базу и зарабатывать?». И помогите команде решить эти проблемы.

Мальчики делают продукты, которые всем нравятся. Мужчины делают продукты, которые все ненавидят, но пользуются.

4. Не покрывать полностью макеты компонентами

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

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

Возможности Figma и Pixso сейчас позволяют собирать макеты полностью из компонентов без каких-либо проблем

5. Не синхронизировать макеты с продом

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

О том, как поддерживать макеты в актуальном виде, писал в статье «Как поддерживать актуальность макетов в Figma или Pixso»

6. Не следить за порядком в таск-трекере

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

7. Не пользоваться продуктом, над которым работаешь

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

8. Выстраивать макеты не по пользовательским сценариям

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

9. Не знать краткосрочные и долгосрочные цели продукта

Понимание целей продукта — ключ к созданию эффективного дизайна. Именно из-за отсутствия понимания целей дизайн-команда зачастую не имеет значимого влияния на принятие решений по продукту. Например, на формирование и приоритизацию бэклога

10. Не помогать отлавливать баги

Баги играют большую роль в пользовательском опыте, поэтому важно не лениться и сообщать о них тестировщикам, если обнаруживаете

11. Считать, что твоя зона ответственности ограничивается макетами

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

12. Не думая, сразу проектировать строго по постановке аналитиков

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

13. Выполнять работы без задачи в таск-трекере

Каждая задача должна быть зафиксирована в таск-трекере, чтобы работы и планирование было прозрачным для всей команды, а макеты были актуальными

14. При принятии дизайн-решений ставить на первое место своё эго, а не интересы продукта

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

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

15. Не знать кто ваша целевая аудитория

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

16. Преувеличивать важность красивости дизайна

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

17. Не участвовать в развитии дизайн-системы

С дизайн-системой как с политикой. Если вы не занимаетесь ею, то она займётся вами.

От дизайн-системы будет зависеть насколько будут подходить компоненты под ваши сценарии, насколько быстро будут работать файлы, насколько много макетов будет умещаться в файлы, насколько хороший UI будет в продукте, насколько удобно будет собирать макеты и многое другое.

Поэтому важно активно следить за тем, что происходит у команды дизайн-системы и влиять на её развитие

18. Не задумываться о том, а точно ли наши инициативы стоят потраченного на них времени

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

19. Иметь напряженные отношения с другими функциональными командами

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

20. Не думать об оптимизации файлов в Figma или Pixso

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

Спасибо, что прочитали до конца! ❤‍🔥
Буду рад вашим лайкам и подпискам на VC, если статья была полезной :)

А какие ошибки часто допускают дизайнеры на ваш взгляд? Пишите в комментариях)

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