На дня я писал про обсуждение дизайна или реализации<\/a>. Есть ещё близкая ситуация, когда тоже надо прояснить, что именно мы обсуждаем. Тут уже проблема именно в дизайне, и я хочу поделиться тем, как вести себя дизайнеру.<\/p>\n Итак, дизайн давно принят, вовсю идёт разработка, и вот в ходе очередной плановой встречи в обсуждении каких-то деталей к дизайну возникает вопрос. Программисты видят непоследовательность и спрашивают: «Как это должно работать?». Дизайнер начинает объяснять, и в этот момент сам понимает, что дизайн небезупречен.<\/p>\n Недавно сам был в такой ситуации. Это довольно некомфортно: ты должен объяснять, как что-то работает, когда уже сам видишь, что не прям волшебно-то оно работает. Говоришь такой: «А если нажать вот сюда, то открывается то-то», а программисты такие вкрадчиво: «а если у меня экран прокручен ниже?..» И ты начинаешь метаться между тем, чтобы объяснить, как задумано, и тем, чтобы придумать улучшение.<\/p>\n Если вы чувствуете, что такое происходит, стоит явно сказать: Иначе можно легко оказаться в положении, когда ты должен заниматься редизайном принятого дизайна в своё время за свой счёт, да ещё и виноват будешь, что сроки затягиваются и программистам переделывать приходится.<\/p>\n Дорогие дизайнеры! Ошибки случаются, это нормально. Признание ошибки в уже принятом дизайне не означает, что вы становитесь должны всё переделать. Важно, чтобы и вы, и клиент это понимали. Иначе чтобы защититься от внеурочной работы вам придётся усиленно делать вид, что ошибки нет, а это некоторое безумие. Надо говорить уверенно: «Да, я накосячил, готов исправить за сто тыщ» (например). Ну и стремиться не косячить в следующий раз, конечно.<\/p>\n",
"date_published": "2025-08-07T12:12:31+05:00",
"date_modified": "2025-08-07T12:12:26+05:00",
"tags": [
"переговоры",
"профессия дизайнера"
],
"author": {
"name": "Илья Бирман",
"url": "https:\/\/ilyabirman.ru\/meanwhile\/",
"avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
},
"_date_published_rfc2822": "Thu, 07 Aug 2025 12:12:31 +0500",
"_rss_guid_is_permalink": "false",
"_rss_guid": "137015",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": null,
"og_images": []
}
},
{
"id": "136994",
"url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/my-obsuzhdaem-dizayn-ili-realizaciyu\/",
"title": "Мы обсуждаем дизайн или реализацию?",
"content_html": " Бывает ситуации, когда встречи о дизайне с программистами идут туго. Программисты накидывают непонятные претензии к дизайну: В ходе обсуждения преимуществ того или друго дизайна становится ясно, что у программистов на самом деле нет доводов сверх «а почему бы», и они вымучивают какие-то соображения со словами «юзабилити», просто чтобы не говорить, что им проще сделать штуку Y вместо штуки X. Кажется, программисты боятся сказать, что что-то сложно, и им хочется как-нибудь поменять дизайн, чтобы получилось, что они молодцы и делают всё, как задумано.<\/p>\n Если вы чувствуете, что такое происходит, стоит задать прямой вопрос: Потому что если явной проблемы нет, то это просто обмен мнениями с непонятной перспективой. Да, любой дизайн можно сделать ещё и по-другому, и третьим способом тоже. Кто будет принимать решение о дизайне, программисты?<\/p>\n Если же проблема в сложности реализации, то тут нужно не между вариантами X и Y выбирать, а разобраться, в чём сложность. Возможно, дизайнеры предложат вообще вариант Z с учётом технических ограничений.<\/p>\n Дорогие программисты! Не бойтесь говорить сразу о технических ограничениях, не пытаясь замаскировать их под разговоры о дизайне. Чем смелее вы будете в этом, тем быстрее дизайнеры начнут разбираться в том, что у вас там происходит, и тем проще вам в будущем будет находить общий язык. Возможно, дизайнеры сразу начнут приносить удобный для реализации дизайн. А с другой стороны, принося неудобный, они будут вынуждены убедительнее защищать его и обосновывать необходимость приложения особых усилий. Тогда и вы лучше начнёте лучше разбираться в том, что у нас тут происходит.<\/p>\n",
"date_published": "2025-08-05T18:03:22+05:00",
"date_modified": "2025-08-07T12:06:11+05:00",
"tags": [
"переговоры",
"профессия дизайнера"
],
"author": {
"name": "Илья Бирман",
"url": "https:\/\/ilyabirman.ru\/meanwhile\/",
"avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
},
"_date_published_rfc2822": "Tue, 05 Aug 2025 18:03:22 +0500",
"_rss_guid_is_permalink": "false",
"_rss_guid": "136994",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": null,
"og_images": []
}
},
{
"id": "135367",
"url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/neskolko-variantov-dizayna\/",
"title": "Несколько вариантов дизайна",
"content_html": " Некоторые дизайнеры любят приносить по несколько вариантов дизайна, когда об этом не просили. Не надо так делать: это вызывает фрустрацию и недоверие.<\/p>\n Если вы сели рисовать второй вариант дизайна, значит вы не уверены, что первый решает задачу. Из-за чего вы сомневаетесь? Какие вопросы о задаче у вас остались непрояснёнными? Нужно задать их арт-директору или клиенту, доразобраться в задаче и принести одно решение — лучшее, на которое вы способны. Иначе получается, что вы подменяете качество работы её количеством.<\/p>\n В каких случаях несколько вариантов — это окей?<\/p>\n Во-первых, если сама задача состоит в выборе направления. Заказчик сам не знает точно, чего хочет, и ваша помощь нужна именно в этом прояснении. Вас буквально попросили показать несколько вариантов, причём вы обсудили, каких именно. Например, арт-директор говорит: «примерь вот эти 4 шрифта к макету, пожалуйста». В этом случае несколько вариантов — это и есть единственное решение поставленной задачи, которое вы и приносите.<\/p>\n Во-вторых, если вам так самим проще прояснить задачу. Например, вы начали рисовать макеты; пошли в одну сторону, потом засомневались в своём понимании, пошли в другую... И думаете: «надо бы показать, чтобы понять, то ли я вообще делаю». В этом случае вы приходите к заказчику и говорите не «посмотри варианты», а задаёте конкретный вопрос: «смотри, вариант с Колобком получается привлекательным, но с Чубаккой по идее юридически корректнее; помоги выбрать?»<\/p>\n",
"date_published": "2025-03-27T23:54:37+05:00",
"date_modified": "2025-03-27T23:54:27+05:00",
"tags": [
"профессия дизайнера"
],
"author": {
"name": "Илья Бирман",
"url": "https:\/\/ilyabirman.ru\/meanwhile\/",
"avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
},
"_date_published_rfc2822": "Thu, 27 Mar 2025 23:54:37 +0500",
"_rss_guid_is_permalink": "false",
"_rss_guid": "135367",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": null,
"og_images": []
}
},
{
"id": "135098",
"url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/think-on-34\/",
"title": "Думаем дальше № 34 — «Раньше вообще без штанов бегали» с Женей Арутюновым",
"content_html": " С Женей Арутюновым обсуждаем похвалу дизайнерам и как стать дизайнером.<\/p>\n Все выпуски подкаста:
\n— Я вижу, что дизайн проблематичный, но давайте решим, что мы сейчас обсуждаем. Вы спросили, как должно работать. Я могу рассказать, как всё задумано изначально, хотя с этим и есть проблемы, и мы тогда решим, что делать дальше — или планировать редизайн, или реализовывать пока так.<\/p>\n
\n— Зачем нужна штука X? А почему бы не сделать вместо неё штуку Y.<\/p>\n
\n— Что мы сейчас обсуждаем, дизайн или реализацию? Если вам кажется, что в дизайне проблема, давайте вы её явно назовёте, и тогда мы в команде дизайна подумаем над решением. А если ваш вариант проще в реализации, это тоже можно обсудить, но давайте тогда и обсуждать это, а не «юзабилити».<\/p>\n
\nЭпл<\/a> · Ютюб<\/a> · Я.Музыка<\/a> · Мейв<\/a> · РСС для подкастного приложения<\/a><\/p>\n