Как передать макет программистам так, чтобы дизайн не «протух» и проект запустился в два раза быстрее

Если вы веб-дизайнер, то наверняка сталкивались с ситуацией, когда после «прикрутки к движку» ваш макет довольно сильно ломался. Вам часто приходится говорить фразу: «В макете всё было красиво, но клиент всё сломал», ставить в портфолио изображения вместо скриншотов сайта и убирать прямую ссылку, чтобы потенциальные заказчики не видели, во что в итоге превратился ваш макет.

Если вы узнали себя, то добро пожаловать под кат, в котором я расскажу о методе, с помощью которого можно избежать этого, сократив при этом срок разработки проекта.

Вот несколько примеров того, что могут сделать с вашими макетами программисты:

  • Названия товаров оказываются значительно длиннее одной строки. Иногда строк оказывается целых три — а на такое издевательство ваши макеты уже не рассчитаны.
  • В фильтре товаров появились новые элементы, например — ползунки, которые вы не рисовали, но появились они в самом неприглядном месте, в самой «вырвиглазной» форме.
  • Появлялись разные поп-апы, про которые вы даже и не думали, например, поп-ап с выбором города.
  • При заполнении формы вылезает страшненькое сообщение об ошибках, которое вы забыли нарисовать.
  • Картинка товара вместо сочного красочного изображения на белом фоне содержит куда менее сочное и без белого фона.
  • На макете детальной страницы товара вам удалось разместить изображение 800х600, но у клиента есть картинки только 300х300, поэтому программисты просто растянули маленькую картинку и обрезали.

Список далеко не полный, это лишь пара примеров, когда из своего красивого и опрятного макета вы получаете франкенштейна, которого стыдно показать даже своей маме, не то что потенциальным клиентам. Мы в компании Turbo> называем это «протуханием дизайна» — процессом, в результате которого дизайн увядает и портится.

Конечно, можно откреститься от проблемы и своей ответственности фразой: «Мне никто не сказал, что картинки есть только в плохом качестве, в брифе про это не писали, а я не телепат…» или «Клиент утвердил мой макет, а ведь он должен был знать, что у него картинки в плохом качестве». Но давайте попробуем снять эту боль с клиента и подумаем, как решить проблему самостоятельно.

Вариант №1: заранее всё досконально продумать, проанализировать и прописать в техническом задании. К сожалению, этот вариант не работает: на анализ и уточнение уходит слишком много времени, а на выходе получается ТЗ на 100 с лишним страниц, которое никто не читает.

Мало того, невозможно предусмотреть всё: аналитик всё равно что-нибудь забудет, даже если на этапе написания ТЗ у него будет полный доступ к внутренней базе товаров с картинками. А это — фантастика, потому что картинки хранятся в «1С» (или другой внутренней системе), которая «святая святых» — финансовая система, где хранится информация «про бабки»! Чего уж говорить, если контента нет, и его планируется готовить параллельно с разработкой сайта.

Вариант №2: программисты могут дозапросить у дизайнеров все недостающие материалы. Этот вариант имеет смысл, но только для критичных ситуаций. Обычно, когда подключаются программисты, дизайнеры уже работают над другими проектами, у них полностью забронировано время, и не хочется возвращаться к работе, которую они сдали два месяца назад.

Поэтому программисты или менеджеры проектов предпочитают дорисовывать мелочи самостоятельно и на свой вкус. Кроме того, в некоторых случаях, придётся вносить колоссальные правки. Например, чтобы сжать лаконично вписанную в сетку детальной страницы картинку 800х600 до размеров 300х300, потребуется переделать всю сетку. А это — уже новый макет, который потребуется заново апрувить с клиентом.

Вариант №3: дизайнер должен сам всё продумать и предусмотреть.

Ну, это вообще фантастика: для этого надо быть телепатом и ясновидящим, чтобы знать, какие картинки предоставит клиент. Хотя предусмотреть длинные названия и выводить сообщения об ошибках в форме действительно не повредит.

Решение

Я хочу рассказать ещё об одном методе, который позволяет полностью избавиться от «протухания» дизайна на этапе программирования. Используя его, вы станете реже говорить: «Это клиент испортил», сэкономите уйму времени, нервов и сил, а клиент получит качественный результат без напряга своих аналитических способностей.

Итак, в большинстве дизайн-студий по разработке сайтов есть три глобальных этапа: дизайн, вёрстка и программирование, которые водопадом идут друг за другом.

Три этапа разработки сайта: дизайн, верстка, программирование

Забегая немного вперёд скажу, что такая схема идеально подходит для сайтов, не требующих сложной технической разработки с большим количеством данных и интеграций. Используйте на здоровье на промо и корпоративных сайтах. Но если у вас много данных, и сайтом будут пользоваться как сервисом, и вы не знаете, как именно (например — стартап с непонятной механикой), то можно пойти другим путём.

Programming-first подход

Это немного радикальное изменение, но не пугайтесь. Дальше я подробно объясню на примере, как это работает. Смысл в том, чтобы стартовать программирование технически-сложной части без вёрстки и без дизайна. Эту часть можно запрограммировать в чёрно-белом варианте, реализовав все интеграции и получив все данные из «1С», Axapta, CRM, ERP и клиента, дать всем участникам проекта покликать настоящие данные в настоящей механике.

В это время дизайнер может разрабатывать дизайн-концепцию, цветовую схему, шрифты и всё остальное. А когда приступит к сервисному разделу, то сможет делать это на рабочем примере, учитывая весь объём настоящих данных, а не то, что написано в брифе.

Это распараллеливание значительно уменьшает срок разработки проекта, при этом участники не мешают, а помогают друг другу. Это тот самый случай, когда две роженицы могут родить за 4,5 месяца.

Кроме того, появляется лёгкость внесения правок в механику: клиент может прокликать чёрно-белый вариант и прислать корректировки. Программистам не сложно менять логику, так как не приходится перерисовывать дизайн и менять вёрстку.

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

Пример

Чтобы было понятно, расскажу, как мы делали сайт kdl.ru который мы в Turbo> сверстали и запрограммировали по заказу агентства ONY, разработавшего дизайн, креатив и стратегию.

KDL (клинико-диагностические лаборатории) — это компания с федеральной сетью офисов, где можно быстро сдать и получить результаты самых разных медицинских анализов. Компания быстро растёт в конкурентной среде, и от нас требовался свежий, удобный и понятный сайт в максимально сжатые сроки.

На этапе брифа стало ясно, что раздел «Каталог анализов» является технически сложным, в нём будет много данных, и вначале никто не мог сказать, каких именно, — требовалось анализировать информацию в ERP-системе. Кроме того, совершенно непонятна требуемая функциональность: с одной стороны, он похож на каталог товаров с корзиной, но с другой, анализы — это услуги, а не товары.

Это значит, что фактически нет количества (нет остатков по складам), зато есть наличие (в некоторых регионах не делают редкие анализы). Также на этапе брифа присутствовала непонятная механика: при добавлении в корзину услуги «Общий анализ крови» в корзину автоматически должна была добавиться услуга «Взятие крови из вены» как неотъемлемая часть общего анализа.

Если «Взятие крови» уже есть в корзине, то добавлять услугу второй раз не требуется. Для некоторых же анализов пользователь может выбрать тип биоматериала: из вены, пальца или из роговицы глазного яблока.

Таких непонятных нюансов было много, но так как это не классический интернет-магазин, мы не могли просто сделать «как у всех». Дело в том, что конкурентов у KDL не так много, и у них подобная функциональность не автоматизирована, они просто сделали приписку под звёздочкой: «* — если вам нужен другой тип, предупредите медсестру». Было очевидно, что если мы пойдём классическим способом «дизайн — вёрстка — программирование», то наш дизайн однозначно «протухнет» на последнем этапе. Что же делать?

Мы предложили рабочей группе начать разработку с программирования. Это звучало странно для дизайн-агентства, но нам удалось договориться, и мы распараллелили процесс: дизайнеры принялись разрабатывать концепцию дизайна главной страницы, тогда как программисты начали интеграцию с внутренней ERP-системой, агрегацию и нормализацию получаемых из неё данных и разработку всей механики.

Мы очень быстро сделали всё, что описано в ТЗ, но без дизайна в простом чёрно-белом варианте: категории анализов, фильтры, морфологический поиск с учётом ошибок и синонимов, комплексы анализов, мультирегиональные цены, наличие в регионах, взятие биоматериалов, корзина и оформление заказа. Всё это выгружалось из ERP-системы, то есть все данные были настоящими.

Главная страница раздела
Страница одного комплекса
Страница одного анализа, показан выбор региона
Корзина с несколькими анализами и биоматериалами

Все ссылки кликабельны, вся механика полностью реализована. В разных регионах разные цены и наличие. Все данные — настоящие.

Мы отправили этот вариант клиенту, чтобы он мог проверить всю механику и функциональность и… у вас когда-нибудь были макеты без правок? Вот и наша механика не обошлась. Точно так же, как клиенты просят «поиграться со шрифтами» на макетах, наш клиент попросил «поиграться с механикой», прислав несколько корректировок.

Сделать их на этом этапе ещё было достаточно просто. Например, выяснилось, что на детальной странице некоторых анализов нужно показать PDF-файл с инструкцией; некоторые услуги не имеют артикула; в фильтре «Для детей» не оказалось ни одного анализа. И тогда нас попросили изменить фильтры.

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

Правок было много, но все они вносились достаточно легко, буквально за полчаса-час одним человеком. Без дизайнера и без верстальщика, без тестировщика с множеством тестовых устройств. Это был очень продуктивный и полезный этап для получения качественной функциональности.

Параллельно с программированием дизайнеры разработали и утвердили макеты главной страницы.

Макет главной страницы

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

Дизайнер в процессе создания макетов для «Каталога анализов» мог сам кликать, смотреть — что и как работает, очень быстро получать всю интересующую информацию прямо у сидевшего рядом программиста. Пример диалога между ними:

一 Сколько у вас категорий?

一 34.

一 Какое самое длинное название?

一 Сейчас поищу в базе… Вот, нашёл: 371 символ вот это: «Предварительное определение наркотических, психотропных и сильнодействующих веществ (качественно): Опиаты (героин, морфин, кодеин), Опиоиды (метадон, фенциклидин, трамадол), Амфетамин и его производные (амфетамин, метамфетамин и др.), Каннабиоиды, Кокаин, Бензодиазепины (диазепам, феназепам, нитразепам и т.д), Барбитураты (фенобарбитал, циклобарбитал, барбитал и т.д)».

一 А много таких? Если откинуть 1% самых длинных, то какой останется самый длинный?

В итоге из этого.

После работы дизайнера стало красиво.

Кстати, на этом проекте у нас было ТЗ всего на 18 страницах. В них мы описали только глобальные задачи, не пытаясь всё проанализировать и детально расписать каждую кнопочку и поля всех сущностей. Все детали мы выясняли прямо во время программирования и при необходимости вносили правки.

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

Итого

  • Мы значительно ускорили срок разработки сайта, потому что на момент утверждения макетов у нас уже было готово: интеграция с пятью системами и вся механика. Вся функциональность была оттестирована и отлажена. Оставалось только обернуть её дизайном.
  • Дизайн не успел «протухнуть», и теперь нам не стыдно указывать ссылку на сайт в своем портфолио.
  • ТЗ на 18 страницах.
  • Клиент мог легко корректировать работу и вносить изменения.
  • Клиент получил идеальный дизайн, а не красивую картинку.
  • Мы сэкономили бюджет проекта, так как снизили объём правок (не количество, а именно объём) за счёт того, что все правки были простыми.

Применимость

На самом деле, ничего нового мы не придумали. Для многих дизайнеров описанный в статье метод является обыденным. Например, в компаниях-интеграторах при разработке сложных технических систем о внешнем виде никто не думает или думает в самый последний момент.

При разработке CRM- и ERP-систем всегда в первую очередь создают функциональность, пытаются получить максимум данных при минимуме усилий и свести их в аналитических отчётах как признак того, что система работает правильно. И только когда вся функциональность готова, просят дизайнера поработать над внешним видом.

Классический подход design-first (дизайн — вёрстка — программирование) появился не просто так. Если к вам приходит клиент, для которого важнее всего внешний вид проекта, то готовьтесь больше работать над дизайном: играть со шрифтами и переставлять телефон из «подвала» в «шапку» — то есть вносить много правок на этапе дизайна.

Но если клиент приходит к вам за технической функциональностью, готовьтесь вносить больше правок именно в неё и механику. Соответственно, планируя этапы, старайтесь сделать этап с максимальным количеством правок первым, иначе все правки придётся провести через все предыдущие этапы. Просто помните о том, что кроме design-first существует ещё и programming-first-подход.

На проекте KDL нам удалось соединить оба этих подхода в разных разделах: на главной странице нет технически сложных элементов, поэтому был применён design-first; в разделе «Каталог анализов» функциональность была неким абстрактным «конём в вакууме», поэтому мы применили programming-first.

Не пытайтесь использовать programming-first при разработке промо-сайтов — там просто нечего программировать без дизайна. А на корпоративных сайтах обычно мало данных, а те, что есть являются достаточно тривиальными и понятными: список новостей, вакансий, сертификатов и так далее. Поэтому дизайн там имеет большее значение, и именно на этапе дизайна правок будет больше всего.

Programming-first — это не панацея, а скорее ещё один инструмент в вашем наборе. Применяйте его правильно, и вам станет значительно проще, а ваши клиенты будут счастливее.

0
24 комментария
Написать комментарий...
Konstantin Petrov

Дичь какая-то, ну или я чего-то не понял ... :(

В первую очередь этап «дизайна» — это не про картинки. Но про планирование и проектирование. Вы упорно опускаете этап сбора и анализа данных, на основе которых разрабатывается интерактивный прототип. Это и есть design-first.

Данные + анализ --> прототип --> дизайн [...] --> профит!
Параллельно: прототип --> оценка тех. стороны --> front-end + back-end --> [...]

Весь описанный вами «варианты» — это какая-то притянутая за уши хурма.
Если дизайнер не предусмотрел название товара больше одной строки или забыл отрисовать попапы, то ему надо дать п[не баньте меня за мат]ы.

Ну или это просто плохой дизайнер / личинка-дизайнера (начинающий). Это вопросы у человеку, который его нанимал.

Аналитик же на то и аналитик, чтобы «знать-всё», а если чего-то не знает, то есть отработанный метод «познания»: спросить у клиента.

Итерационным методом он вместе с ux-спецом приближается к итоговому виду прототипа, который после согласования отправляется технарям на-посмотреть.

Логику продумывают специально обученные люди, а не программисты. Это исключает ворох ошибок и косяков.

И да, после согласования прототипа, можно уже пилить тех. сторону, так как все подводные камни выявлены и четко ясна структура, логика и функционал.

Если тут возникнут какие-то вопросы связанные с реальными данными, то их действительно будет легко решить, так как бОльшая часть головняка скорее всего вскроется на этапе прототипа, и будет устранена на одной из итераций.

Вы же, получается, просто пропустили весь этап проектирования и тупо решили в продакшн всё отправить. А дизайнер пусть уже парится с тем, что мы напридумывали. Лол-кек-чебурек.

Заметьте, вы пишете, что было очень много правок, пусть и решали вы их быстро, но ведь не бесплатно? А еще и с дизайном были проблемы ... а не из-за предложенной ли вами структуры/функционала/логики?

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

Еще меня смутило, что вы пишите, что контента и данных вообще не было в начале, и всю инфу приходилось буквально с боем выдавливать из клиента. Но потом вы переобуваетесь на лету и такие «мы тип сэкономили время всем».

Так получается, что время вы не экономили, а занимались двойной работой:
* продумывали/додумывали логику и структуру;
* верстали веб-мордру и пилили бекенд;

То есть тем, чем должен занимается аналитик и проектировщик — еб[не баньте меня за мат]ей с заказчиком, сбором информации, анализом, проектированием.

Так что вы точно лукавите, а статья притянут за уши к конкретному кейсу и с нужной вам стороны.

Ответить
Развернуть ветку
Roman Bobrov

Кликабельные прототипы у нас тоже были, и данные в них были - со слов клиента. А когда нам сделали выгрузку из ERP, оказалось... упс... Не совсем то. Банально, справочник биоматериалов не мэтчился со справочником локусов - просто не существовало поля id, которое бы их объединяло.

Первоначальный кликабельный прототип выполнял больше роль ФТ - то, к чему хотелось прийти, и то, каким клиент видел результат. И мы все стремились получить это.

Ответить
Развернуть ветку
Konstantin Petrov

Так значит прототип был и по нему работали и вы и ui-дизайнеры?
Тогда о чем ваш кейс? :)

Вы, рассказывая о том, что где-то отвалился id, жалуетесь на свою работу, за которую вам платят. Это же обычный рабочий момент при разработке чего-то нового.

Опять таки, не ясно, почему вы считаете, что прототип — это то, каким клиент видит результат? Прототип делается не для клиента, а для двух огромных этапов впереди — дизайн и тех. сторона. Это типа дорожной карты.

Обычно, клиент приходит и просит сделать ему «за;бись», потому что сам не может. И при нормальном процессе клиенту говорят, что надо и как надо, а не наоборот. Клиент стоит в сторонке и лишь наблюдает за магией, подсказывая в нужный момент.

Вы или сознательно опустили момент с проектированием, что лишь подтверждает моё предположении о притянутом за уши кейсе, либо одно из двух :)

- - -

В целом, лично я понял что вы имеете ввиду и что сделали.
До;бываюсь именно по структуре статьи, так как в заголовке обещается одно, в первой части другое, а в заключении третье.

У вас был прототип, желание рассказать о себе историю, скучный кейс про то, как вы меняли id, 12 принципов agile, несколько херовых дизайнеров, которые постоянно забывали за что им платят деньги и девочка-редактор, которой дали невнятную задачу.
Не то, чтобы это всё было нужно для написания статьи на vc, но когда читаешь об успехах 15-летних школьников, остановиться уже невозможно.
Единственное, что вызывало беспокойство — это выгрузка из ERP и комментарии к статьи.
В мире нет ничего более безответственно и безнравственного, чем комментарии на вц от чуваков, которые шарят.
Но вы знали, что довольно скоро окунётесь в это дерьмо.

Такой же сумбур и после прочтения вашей статьи, когда начинаешь её разбирать ... А так, вы молодцом!

Ответить
Развернуть ветку
Danila Danilaa

Парни научидись эффективно взаимодействовать в команде. Что тут плохого? Много времени потратил на свои пять копеек? Главное, чтоб клиент был доволен результатом работ.

Ответить
Развернуть ветку
Konstantin Petrov

Нет, Данила.

Данная статья не для клиента написана, а для тех, «кто-в-теме», и с целью демонстрации достижений во внутренних процессах тех. команды Turbo>.

И тут больше вопросов, чем полезных советов по эффективному взаимодействию в команде.

Ну, у меня много :)
Возможно, я чего-то не понимаю ... :3

Ответить
Развернуть ветку
Danila Danilaa

Ну порадуйтесь лучше за ребят. О них вон на вц написали. Зачем разносить всех и вся

Ответить
Развернуть ветку
Kazimir Malevich

Преклоняюсь перед здравомыслящим человеком

Ответить
Развернуть ветку
Vladislav Baranov

Про Figma / Zeplin не слышали?

Ответить
Развернуть ветку
Darina Borisova

Есть "волшебное" сочетание - технический бриф. Клиенты о нем знать не обязаны, но вы - должны. Статья - типичный пример криворукого выполнения заказа.

Ответить
Развернуть ветку
Alex M

Пишите сразу книгу

Ответить
Развернуть ветку
Алексей Зорин

Неплохая статья. Действительно, о наболевшем. Было прям точь-в-точь такое. Когда дизайнер рисует сайт с большими классными картинками, а клиент даёт 200х200. И на этом ломается ВСЁ абсолютно.

Ответить
Развернуть ветку
Тимофей Белоглазов

А проектирование и аналитика где?
Смысл рисовать картинки, если требований нет, а потом удивляться, что у компании нет возможности работать с "большими классными картинками"?

Ответить
Развернуть ветку
Konstantin Petrov

Видимо вы не дочитали статью. Хотя о чем это я:

Зарегистрировался сегодня в 12:56
Комментарии 1

В ней нет никакой полезной информации для дизайнеров, которые сталкиваются с ситуацией, когда их красивая работа упрощается или уродуется. Заголовок вводит в заблуждение, мягко говоря.

Если это редизайн, то дизайнер должен заранее поинтересоваться, в каком виде находится старый контент и предложить варианты или исходить из того, что имеется.

Если же это проект с нуля, тогда клиенту, опять таки, озвучиваются варианты, что мы можем херачить картинки 200х200, а можем подобрать для вас просто ох;;тительные альпийские виды, но это будет +% к расходам.

Ответить
Развернуть ветку
Иван Максимов

Так а как программирование до дизайна помогает решить эту проблему?
Выведет программист плейсхолдер.
Все посмотрят-потыкают, одобрят.
Потом дизайнер нарисует боьшую классную картинку. А потом клиент даст 200на200.

Ответить
Развернуть ветку
Roman Bobrov

Программист выведет не плейсхолдер, а настоящие картинки из ERP. Это будет уже настоящая полноценная работающая система с реализованной интеграцией, но без визуального дизайна.

Ответить
Развернуть ветку
Иван Максимов

Это если они там есть. И при условии, что клиент вдруг не расширит предлагаемый ассортимент.

Но ведь конкретно проблемы с картинками возникают в ситуации, когда у клиента есть контент для одного раздела, а потом он начинает наполнять остальные и узнает много нового.

Ответить
Развернуть ветку
Roman Bobrov

Клиент в будущем может загружать какие угодно картинки и контент. Может на сайте матерные слова писать. Может всем анализам поставить цену 1 рубль и обанкротится. Он может делать со своим сайтом всё что угодно, но к нам это уже не будет иметь никакого отношения.

Когда мы сдавали наш проект, в нём были настоящие актуальные данные из ERP-системы и всё это отлично смотрелось в современном дизайне.

Ответить
Развернуть ветку
Иван Максимов

Так о том и речь.
Что ваш метод вполне себе хорош и может показывать отличные результаты, но только в привязке к конкретному кейсу.
А заголовок и некоторые комменты выглядят как некое обобщение практики:
"Рисуйте дизайн в последнюю очередь, и у вас не будет никаких проблем с картинками".

Хотя мы ж все взрослые люди и понимаем, что основной профит от этого подхода не в улучшении визуальной составляющей дизайна, а в оптимизации процесса.
Когда клиент видит, работающий и выведенный функционал, его гораздо проще убедить, что вот эта завитушка, которая приснилась его коту, здесь непросто не нужна, а вообще лишняя, потому что под неё нет функционала.

Ну, или когда мы сами изначально плохо представляем, какие именно элементы страницы будут необходимы и достаточны (как раз помянутый вами случай сложных систем), то неплохо бы сначала увидеть что получится, а не менять сетку и элементы уже согласованного дизайна.

Ответить
Развернуть ветку
Иван Максимов

Хорошая статья.
Норм подход.
Но вы ведь лукавите мальца.

У вас примеры идеальные. Когда есть все данные и у клиента есть точное представление о его реальных бизнеспроцесах и механизмах взаимодействия.

Т.е. годится только для зрелого отлаженного бизнеса. Да и целью служит не столько улучшение или актуализация дизайна, сколько сокращение трудозатрат на его создание.

Так то диз и сам может посмотреть 5000 детальных фоток и понять, какая из них самая маленькая, или какое название самое длинное, но долго.

И подход совершенно не годится для тех проблем, которые ставятся в начале статьи.

Когда нет контента, нет представления о необходимом функционале - такой подход ничего не даст.
Более того, будет вреден, в ситуации, когда диз не просто "играет шрифтами и цветами", а конструирует логику использования продукта и его работы.

А статья подаёт метод как универсальную панацею от всего. Ну, из серии "agile ради agile".

Ответить
Развернуть ветку
Roman Bobrov

Не лукавим. Изначально никто не знал какие есть данные и в какой форме. Даже сам клиент. Диз не мог посмотреть 5000 детальных картинок из ERP-системы. Даже мы не могли - нас не пускали в эту систему. Нам пришлось "выбивать" эту информацию из программистов, разрабатывающих эту ERP. Это типовой процесс интеграции двух сложных систем. В статьей не расписано, как мы собирали контент по крупицам, потому что статья не об этом.

Статья о том, что часто креативные и дизайн-агентства сначала разрабатывают визуальный дизайн, а потом узнают какие данные есть, каких нет и пытаются их подогнать под утверждённый дизайн.

И да, programming-first - это не панацея, а скорее ещё один инструмент в вашем наборе.

Ответить
Развернуть ветку
Владислав Воробьёв

Не читал, но уверен, что проблема решается с помощью доверия

Ответить
Развернуть ветку
Shustry

С помощью любви

Ответить
Развернуть ветку
Miroslav Tsarev

Сам подход нормальный. Только в статье много противоречий и оправданий, а не решений. В начале статьи пишите о задаче где ничего нет, а в середине оказывается, что информации было достаточно + был прототип с рабочей логикой. Так какие проблемы вообще могли быть?

Дизайн сайта, это не картина на которую будут все тупо пялится отрисованную статикой, это интерфейс с которым будут взаимодействовать пользователи.
Как человек который технически ничего не понимает в сайтах, может делать дизайн тех же сайтов и после, быть недовольным результатом? Потом и появляются такие статьи)

Давайте по пунктам, начну с самого основного на мой взгляд:

+ "Вариант №2: ... дизайнеры уже работают над другими проектами, у них полностью забронировано время, и не хочется возвращаться к работе, которую они сдали два месяца назад."
- Полное противоречие. Будто у разрабов времени аж целая гора, чтобы дорабатывать все недочеты за дизайнерами?) Если материалов недостаточно и что-то отсутствует, то работу невозможно считать законченной.
Но, все "занятые" и ждать можно недостающих материалов очень долго, поэтому, разрабы могут уже забить и доделать мелочи на свое усмотрение. Разрабы не дизайнеры и действительно может получится так себе, только стоит ли винить в этом разрабов, что они выполнили работу которую должен был выполнить дизайнер, даже если результат получился не самым лучшим?

+ "Названия товаров оказываются значительно длиннее одной строки."
- самый частый косяк когда дизайн делается в вакууме, а о практичности никто не думает.

+ "Появлялись разные поп-апы, про которые вы даже и не думали, например, поп-ап с выбором города."
- естественно) не редко бывает, что кнопка в макете "выбрать город" есть, а самого элемента для выбора города никто и не думал рисовать.

+ "При заполнении формы вылезает страшненькое сообщение об ошибках, которое вы забыли нарисовать."
- ситуация как и с поп-апами).

+ "На макете детальной страницы товара вам удалось разместить изображение 800х600, но у клиента есть картинки только 300х300, поэтому программисты просто растянули маленькую картинку и обрезали."
- тут 50/50. Дизайн рассчитан на определенный размер, а когда при наполнении суют туда картинки не тех размеров, естественно получается иначе. Это больше проблема наполнения и причем тут программисты совсем не ясно.

Я не отрицаю, разрабы тоже не святые, косячат еще как, только это относится к технической части, а все что касается дизайна, ответственность дизайнеров. Конечно, при условии что верстка нормальная и сделана не криво, так то любой дизайн можно запоганить.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Дима Абрамов

Привет, спасибо за статью. В итоге сколько времени потратили на весь проект? какого размера была команда? Сколько примерно в часах получили экономию по отношению к схеме, которую назвали водопадом (дизайн - верстка - программирование)?

Ответить
Развернуть ветку
21 комментарий
Раскрывать всегда