{"id":14270,"url":"\/distributions\/14270\/click?bit=1&hash=a51bb85a950ab21cdf691932d23b81e76bd428323f3fda8d1e62b0843a9e5699","title":"\u041b\u044b\u0436\u0438, \u043c\u0443\u0437\u044b\u043a\u0430 \u0438 \u0410\u043b\u044c\u0444\u0430-\u0411\u0430\u043d\u043a \u2014 \u043d\u0430 \u043e\u0434\u043d\u043e\u0439 \u0433\u043e\u0440\u0435","buttonText":"\u041d\u0430 \u043a\u0430\u043a\u043e\u0439?","imageUuid":"f84aced9-2f9d-5a50-9157-8e37d6ce1060"}

Как этим пользоваться, или почему дизайн не работает?

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

Ошибки бизнеса

Основная ошибка заключается в том, что UX/UI дизайнер воспринимается как творческая единица, хотя согласно специфики профессии — дизайнер подобного типа гораздо ближе к инженеру, нежели к художнику. Допускаю, что это происходит из-за наиболее популярного перевода слова "Designer" с английского языка.

Чаще всего задача, поступившая дизайнеру, должна была быть готова еще вчера, но переживать не о чем, реализация уже продумана PO, либо другими отделами, нужно просто отрисовать. Это в корне не верный подход. Техническое задание для специалиста подобного профиля должно давать ему представление о цели со стороны бизнеса и пользователя, сопроводительную информацию, отвечать на вопрос «Что?". В свою очередь, при построении информационных систем UX/UI Дизайнер отвечает на вопрос »Как?" и самостоятельно продумывает возможные пути достижения цели. Следовательно, ТЗ в теории не может содержать в себе однозначного решения для достижения цели.

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

Итог:

Процесс работы отдела дизайна так же важен, как и процесс разработки или построения маркетинговой стратегии. Без продуманной системы, без этапа валидации не стоит ожидать, что продукт станет сильным конкурентом на рынке, способным оправдать собственные ожидания. Существует достаточное количество примеров, когда новый продукт переманивал пользователей на свою сторону, просто потому что он был более понятен и продуман, наиболее ярким примером можно взять кейс Sketch и Figma. Вложения в UX/UI работают гораздо дольше, чем может показаться на первый взгляд.

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

Желаю всем успешных, продуманных продуктов: )

0
3 комментария
Иван Иванов

Посмотрите что будет тут дальше

Ответить
Развернуть ветку
Анни М.

Строго говоря, если у человека были за два года такие задания, где надо отрисовать интерфейс по требованию, то человек не UX/UI, а просто UI. И если должность человека пишется через дробь, это значит, что он, как часть своей работы, и должен просто отрисовывать интерфейс.

Ответить
Развернуть ветку
Kirill Yudin
Автор

Я где-то сказал, что у меня были исключительно такие задания? Я говорю о бизнес процессах и том, как они выстраиваются в СНГ, а не о том, что происходило лично у меня.

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

И все это не отменяет, что в 70% случаев (по моим личным ощущениям), когда СНГ компания не достигла масштабов Яндекса, будет именно так, как я описал в статье.

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда