Как передать макет программистам так, чтобы дизайн не «протух» и проект запустился в два раза быстрее
Если вы веб-дизайнер, то наверняка сталкивались с ситуацией, когда после «прикрутки к движку» ваш макет довольно сильно ломался. Вам часто приходится говорить фразу: «В макете всё было красиво, но клиент всё сломал», ставить в портфолио изображения вместо скриншотов сайта и убирать прямую ссылку, чтобы потенциальные заказчики не видели, во что в ит…
Дичь какая-то, ну или я чего-то не понял ... :(
В первую очередь этап «дизайна» — это не про картинки. Но про планирование и проектирование. Вы упорно опускаете этап сбора и анализа данных, на основе которых разрабатывается интерактивный прототип. Это и есть design-first.
Данные + анализ --> прототип --> дизайн [...] --> профит!
Параллельно: прототип --> оценка тех. стороны --> front-end + back-end --> [...]
Весь описанный вами «варианты» — это какая-то притянутая за уши хурма.
Если дизайнер не предусмотрел название товара больше одной строки или забыл отрисовать попапы, то ему надо дать п[не баньте меня за мат]ы.
Ну или это просто плохой дизайнер / личинка-дизайнера (начинающий). Это вопросы у человеку, который его нанимал.
Аналитик же на то и аналитик, чтобы «знать-всё», а если чего-то не знает, то есть отработанный метод «познания»: спросить у клиента.
Итерационным методом он вместе с ux-спецом приближается к итоговому виду прототипа, который после согласования отправляется технарям на-посмотреть.
Логику продумывают специально обученные люди, а не программисты. Это исключает ворох ошибок и косяков.
И да, после согласования прототипа, можно уже пилить тех. сторону, так как все подводные камни выявлены и четко ясна структура, логика и функционал.
Если тут возникнут какие-то вопросы связанные с реальными данными, то их действительно будет легко решить, так как бОльшая часть головняка скорее всего вскроется на этапе прототипа, и будет устранена на одной из итераций.
Вы же, получается, просто пропустили весь этап проектирования и тупо решили в продакшн всё отправить. А дизайнер пусть уже парится с тем, что мы напридумывали. Лол-кек-чебурек.
Заметьте, вы пишете, что было очень много правок, пусть и решали вы их быстро, но ведь не бесплатно? А еще и с дизайном были проблемы ... а не из-за предложенной ли вами структуры/функционала/логики?
Тут у меня складывается ощущение, что вся статья призвана оправдать вас за этот не хитрый ход ...
Еще меня смутило, что вы пишите, что контента и данных вообще не было в начале, и всю инфу приходилось буквально с боем выдавливать из клиента. Но потом вы переобуваетесь на лету и такие «мы тип сэкономили время всем».
Так получается, что время вы не экономили, а занимались двойной работой:
* продумывали/додумывали логику и структуру;
* верстали веб-мордру и пилили бекенд;
То есть тем, чем должен занимается аналитик и проектировщик — еб[не баньте меня за мат]ей с заказчиком, сбором информации, анализом, проектированием.
Так что вы точно лукавите, а статья притянут за уши к конкретному кейсу и с нужной вам стороны.
Кликабельные прототипы у нас тоже были, и данные в них были - со слов клиента. А когда нам сделали выгрузку из ERP, оказалось... упс... Не совсем то. Банально, справочник биоматериалов не мэтчился со справочником локусов - просто не существовало поля id, которое бы их объединяло.
Первоначальный кликабельный прототип выполнял больше роль ФТ - то, к чему хотелось прийти, и то, каким клиент видел результат. И мы все стремились получить это.
Парни научидись эффективно взаимодействовать в команде. Что тут плохого? Много времени потратил на свои пять копеек? Главное, чтоб клиент был доволен результатом работ.
Преклоняюсь перед здравомыслящим человеком
Комментарий недоступен
Есть "волшебное" сочетание - технический бриф. Клиенты о нем знать не обязаны, но вы - должны. Статья - типичный пример криворукого выполнения заказа.
Пишите сразу книгу
Неплохая статья. Действительно, о наболевшем. Было прям точь-в-точь такое. Когда дизайнер рисует сайт с большими классными картинками, а клиент даёт 200х200. И на этом ломается ВСЁ абсолютно.
А проектирование и аналитика где?
Смысл рисовать картинки, если требований нет, а потом удивляться, что у компании нет возможности работать с "большими классными картинками"?
Видимо вы не дочитали статью. Хотя о чем это я:
Зарегистрировался сегодня в 12:56 Комментарии 1
В ней нет никакой полезной информации для дизайнеров, которые сталкиваются с ситуацией, когда их красивая работа упрощается или уродуется. Заголовок вводит в заблуждение, мягко говоря.
Если это редизайн, то дизайнер должен заранее поинтересоваться, в каком виде находится старый контент и предложить варианты или исходить из того, что имеется.
Если же это проект с нуля, тогда клиенту, опять таки, озвучиваются варианты, что мы можем херачить картинки 200х200, а можем подобрать для вас просто ох;;тительные альпийские виды, но это будет +% к расходам.
Так а как программирование до дизайна помогает решить эту проблему?
Выведет программист плейсхолдер.
Все посмотрят-потыкают, одобрят.
Потом дизайнер нарисует боьшую классную картинку. А потом клиент даст 200на200.
Хорошая статья.
Норм подход.
Но вы ведь лукавите мальца.
У вас примеры идеальные. Когда есть все данные и у клиента есть точное представление о его реальных бизнеспроцесах и механизмах взаимодействия.
Т.е. годится только для зрелого отлаженного бизнеса. Да и целью служит не столько улучшение или актуализация дизайна, сколько сокращение трудозатрат на его создание.
Так то диз и сам может посмотреть 5000 детальных фоток и понять, какая из них самая маленькая, или какое название самое длинное, но долго.
И подход совершенно не годится для тех проблем, которые ставятся в начале статьи.
Когда нет контента, нет представления о необходимом функционале - такой подход ничего не даст.
Более того, будет вреден, в ситуации, когда диз не просто "играет шрифтами и цветами", а конструирует логику использования продукта и его работы.
А статья подаёт метод как универсальную панацею от всего. Ну, из серии "agile ради agile".
Не лукавим. Изначально никто не знал какие есть данные и в какой форме. Даже сам клиент. Диз не мог посмотреть 5000 детальных картинок из ERP-системы. Даже мы не могли - нас не пускали в эту систему. Нам пришлось "выбивать" эту информацию из программистов, разрабатывающих эту ERP. Это типовой процесс интеграции двух сложных систем. В статьей не расписано, как мы собирали контент по крупицам, потому что статья не об этом.
Статья о том, что часто креативные и дизайн-агентства сначала разрабатывают визуальный дизайн, а потом узнают какие данные есть, каких нет и пытаются их подогнать под утверждённый дизайн.
И да, programming-first - это не панацея, а скорее ещё один инструмент в вашем наборе.
Не читал, но уверен, что проблема решается с помощью доверия
С помощью любви
Сам подход нормальный. Только в статье много противоречий и оправданий, а не решений. В начале статьи пишите о задаче где ничего нет, а в середине оказывается, что информации было достаточно + был прототип с рабочей логикой. Так какие проблемы вообще могли быть?
Дизайн сайта, это не картина на которую будут все тупо пялится отрисованную статикой, это интерфейс с которым будут взаимодействовать пользователи.
Как человек который технически ничего не понимает в сайтах, может делать дизайн тех же сайтов и после, быть недовольным результатом? Потом и появляются такие статьи)
Давайте по пунктам, начну с самого основного на мой взгляд:
+ "Вариант №2: ... дизайнеры уже работают над другими проектами, у них полностью забронировано время, и не хочется возвращаться к работе, которую они сдали два месяца назад."
- Полное противоречие. Будто у разрабов времени аж целая гора, чтобы дорабатывать все недочеты за дизайнерами?) Если материалов недостаточно и что-то отсутствует, то работу невозможно считать законченной.
Но, все "занятые" и ждать можно недостающих материалов очень долго, поэтому, разрабы могут уже забить и доделать мелочи на свое усмотрение. Разрабы не дизайнеры и действительно может получится так себе, только стоит ли винить в этом разрабов, что они выполнили работу которую должен был выполнить дизайнер, даже если результат получился не самым лучшим?
+ "Названия товаров оказываются значительно длиннее одной строки."
- самый частый косяк когда дизайн делается в вакууме, а о практичности никто не думает.
+ "Появлялись разные поп-апы, про которые вы даже и не думали, например, поп-ап с выбором города."
- естественно) не редко бывает, что кнопка в макете "выбрать город" есть, а самого элемента для выбора города никто и не думал рисовать.
+ "При заполнении формы вылезает страшненькое сообщение об ошибках, которое вы забыли нарисовать."
- ситуация как и с поп-апами).
+ "На макете детальной страницы товара вам удалось разместить изображение 800х600, но у клиента есть картинки только 300х300, поэтому программисты просто растянули маленькую картинку и обрезали."
- тут 50/50. Дизайн рассчитан на определенный размер, а когда при наполнении суют туда картинки не тех размеров, естественно получается иначе. Это больше проблема наполнения и причем тут программисты совсем не ясно.
Я не отрицаю, разрабы тоже не святые, косячат еще как, только это относится к технической части, а все что касается дизайна, ответственность дизайнеров. Конечно, при условии что верстка нормальная и сделана не криво, так то любой дизайн можно запоганить.