Как правильно критиковать работу дизайнера?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

«Обидеть художника может каждый,» — грустно вздыхает дизайнер, в ответ на правки. Так ли плоха критика? Давайте разберёмся!

Из-за боязни показать другому свою интеллектуальную/творческую работу, многие проекты и инициативы так и остаются в голове. Частая причина — неприятные эмоции от критики и замечаний. Рассмотрим эту ситуацию.

Мы придерживаемся такой идеи: «Конструктивная критика — возможность расти как профессионал»????????

В Telegram есть наш внутренний чат, где команды продуктового и графического дизайна смотрят работы друг друга. UX-еры смотрят сквозь призму пользователя, а графики оценивают визуал. Как это происходит?

  • Дизайнер скидывает работу и объясняют контекст,

  • его работу аргументированно критикуют,

  • предлагают улучшения,

  • скидывают полезные референсы.

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

Ещё важный момент, правки вносятся на усмотрение дизайнера, отвечающего за задачу. Но чаще всего мнение команды совпадает.

Анализируя внесённые правки, вы понимаете, что следует улучшить в следующий раз, и делаете сразу хорошо.

Для этого критика и обратная связь должны быть экологичными.

Как это обычно у нас происходит
Как это обычно у нас происходит

Если критикуете вы:

Аргументируйте. Самое важное на мой взгляд в критике, это аргументированно указать на ошибки. «Ваш дизайн — говно» — субъективизм. Сказать, чтО конкретно не работает и почему вы так считаете, — это уже половина решения проблемы.

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

Не переходите на личности. Критикуйте работу, а не человека. Комментарии в духе «тебе лень сделать макет лучше» — необъективны. Вы не видели, сколько времени дизайнер потратил на работу и почему пришёл к такому решению. Это только деморализует показывать свою работу в дальнейшем.

Если критикуют вас:

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

Задавайте вопросы. Главный вопрос, который стоит вам задать — это «почему?» Так вы поймёте, почему принятые вами решения не сработали и какую задачу вам не удалось решить. Часто за мелкими правками скрывается что-то большее.

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

Вывод

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

Источник: https://habr.com/ru/company/kolesa/blog/576426/


Интересные статьи

Интересные статьи

В этом году, так вышло, я два раза находился в поиске работы. Мне довелось испытать приключение в виде полностью удалённого устройства на работу, полностью удалённой адаптации и таког...
«Если не стыдно за первую версию продукта — вы вышли на рынок слишком поздно» Всем привет, я долго тянул, и вот решил выложить даже не MVP, а идею, над которой я сейчас работаю. Выкристалл...
Мы сделали 2 подсистемы внутри Apache Ignite. В статье расскажу про их архитектуру: Как сделали подсистему метрик и подсистему system view. Что сделано и что собираемся сделать? ...
Источник Обработка ошибок в любой разработке играет важнейшую роль. В программе может пойти не так практически всё: пользователь введёт некорректные данные, или они могут прийти такими по http...
Если Вы используете в своих проектах инфоблоки 2.0 и таблицы InnoDB, то есть шанс в один прекрасный момент столкнуться с ошибкой MySQL «SQL Error (1118): Row size too large. The maximum row si...