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

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

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

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

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

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

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

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

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

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

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

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

Programming-first подход

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

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

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

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

Пример
Чтобы было понятно, расскажу как мы делали сайт https://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 - это не панацея, а скорее ещё один инструмент в вашем наборе. Применяйте его правильно и вам станет значительно проще, а ваши клиенты будут счастливее.

Материал подготовил: Роман Бобров (CEO turbo>)