писал<\/a> о том, что при запросе обратной связи важно указать контекст работы, описать, что готово\/не готово, и сформулировать вопросы для участников обсуждения. Но важно ещё и рассказать о самой работе, презентовать её.<\/p>\nПрезентация — это не просто слайды из PowerPoint или Keynote. Это рассказ о том, что было сделано, почему и как всё работает, и почему именно так.<\/p>\n
Так что же делать?
\nВ своём подкасте Илья Бирман рассказывал, что когда он работает над чем-то, то сразу представляет, как будет это презентовать. Это помогает увидеть свою работу совершенно по-другому. Начинаешь учитывать такие детали, которые раньше и в голову бы не пришли: почему именно это решение, какие были альтернативы, для кого это вообще сделано, какую проблему решает. Ты как будто заранее продумываешь все вопросы, которые тебе могут задать, и ответы на них уже встраиваешь в саму работу или её описание.<\/p>\n
По сути, презентация из какой-то обязательной «повинности» превращается в полноценную часть процесса, где ты уже на старте продумываешь, как твоё решение будет взаимодействовать с миром. И это, поверьте, дорогого стоит. А бонусом вы получаете описание для кейса в портфолио. Все мы знаем, что портфолио лучше делать во время работы, а не потом, вымучивая детали проекта из недр памяти.<\/p>\n
В конечном итоге, хорошо продуманная презентация — это не просто способ «продать» дизайн. Это инвестиция в понимание, доверие и, что самое ценное, в сокращение количества правок. Чем яснее вы объясните свою работу, тем меньше шансов, что её попросят «перекрасить в зелёный».<\/p>\n",
"date_published": "2025-06-25T10:04:30+00:00",
"date_modified": "2025-06-25T10:04:23+00:00",
"_date_published_rfc2822": "Wed, 25 Jun 2025 10:04:30 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "42",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "30",
"url": "https:\/\/pages.reushkin.ru\/all\/kak-ya-izmenil-podhod-k-zaprosu-obratnoy-svyazi\/",
"title": "Как я изменил подход к запросу обратной связи",
"content_html": "
Раньше, когда был ещё юным дизайнером, я просил фидбек так: скидывал макет с вопросом «Ну как?» — и в ответ получал кучу комментариев. Иногда они противоречили друг другу, иногда касались мелочей, а главное — я не понимал, что с этим делать. В итоге страдали все: я, заказчик, и проект никак не мог сдвинуться с мёртвой точки.<\/p>\n
Надо всё переделать, подумал я. И теперь делаю по-другому.<\/p>\n
Даю контекст<\/b>. Перед тем как показать работу, напоминаю, какая была задача и цель проекта. Что мы хотим этим дизайном решить? Какого эффекта достичь? Если есть несколько вариантов, объясняю, почему сделал их именно так и какой считаю наиболее удачным. Это помогает сфокусировать внимание на главном и избежать лишних уточняющих вопросов.<\/p>\n
Обозначаю, что ещё не готово<\/b>. Если какая-то часть в процессе, сразу об этом говорю. Так не получаю комментарии на то, что и сам планировал переделать. А иногда заказчик сразу подсказывает, в каком направлении лучше двигаться.<\/p>\n
Формулирую вопросы под каждого участника<\/b>. Разные люди смотрят на работу по-разному. Бизнесу важно, решает ли дизайн задачу продукта. Например: «Отражает ли этот экран ценность предложения?» или «Передаёт ли визуализация ключевую мысль?»
\nДля маркетологов — насколько это влияет на конверсии: «Достаточно ли заметен CTA?»
\nДля разработчиков — реалистичность и понятность вёрстки: «Нет ли технических сложностей в этой анимации?»<\/p>\n
Так мне стало проще разбирать комментарии, а обратная связь реально помогает улучшить работу.<\/p>\n",
"date_published": "2025-03-25T05:17:35+00:00",
"date_modified": "2025-03-25T05:17:01+00:00",
"_date_published_rfc2822": "Tue, 25 Mar 2025 05:17:35 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "30",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
}
],
"_e2_version": 3794,
"_e2_ua_string": "E2 (v3794; Aegea)"
}