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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一 34.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#дизайн