Irina Kovalenko
3 975
Блоги

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

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

Поделиться

В избранное

В избранном

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

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

  • Названия товаров оказываются значительно длиннее одной строки. Иногда строк оказывается целых три — а на такое издевательство ваши макеты уже не рассчитаны.
  • В фильтре товаров появились новые элементы, например — ползунки, которые вы не рисовали, но появились они в самом неприглядном месте, в самой «вырвиглазной» форме.
  • Появлялись разные поп-апы, про которые вы даже и не думали, например, поп-ап с выбором города.
  • При заполнении формы вылезает страшненькое сообщение об ошибках, которое вы забыли нарисовать.
  • Картинка товара вместо сочного красочного изображения на белом фоне содержит куда менее сочное и без белого фона.
  • На макете детальной страницы товара вам удалось разместить изображение 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 — это не панацея, а скорее ещё один инструмент в вашем наборе. Применяйте его правильно, и вам станет значительно проще, а ваши клиенты будут счастливее.

#дизайн

{ "author_name": "Irina Kovalenko", "author_type": "self", "tags": ["\u0434\u0438\u0437\u0430\u0439\u043d"], "comments": 23, "likes": 18, "favorites": 25, "is_advertisement": false, "section_name": "blog", "id": "37850", "is_wide": "" }
{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Подписаться на push-уведомления
[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "create", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } } ]