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