Скоро наш журнал обновит свой дизайн
Close
Будь в курсе
Подпишитесь на рассылку, чтобы не пропускать новые выпуски журнала
лекция
Управление и результаты
Летающий асфальтоукладчик
Я вам расскажу небольшую историю из жизни бюро. Когда бюро только открылось, оно работало как многие веб‑студии: рисовали картинки, эти картинки отдавали клиенту, а клиент отдавал их разработчикам. Разработчики превращали картинки в продукт — внедряли дизайн.

Когда этап дизайна заканчивался, и начинали появляться первые результаты его внедрения, дизайнеры хватались за голову, писали огромные баглисты о том, что всё сломалось, отвалилось, разъехалось. Эти баглисты передавали клиенту, а клиент передавал их разработчикам. Разработчики как‑то исправляли баги и выкатывали новую версию, к которой появлялись новые претензии. Время шло, проект затягивался.

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

Тогда решили, что в бюро очень сложные интерфейсы и надо самим разрабатывать фронтенд. Ввели правило, что бюро никогда не делает картинки, а клиенту отдаётся живая вёрстка, к которой надо подключить бэкенд. Удивительно, но результат был практически такой же. Финальный продукт оказывался сломанным и испорченным как и тогда, когда делали просто картинки.

Почему так? Секрет в том, что большая часть дизайнерских решений принимается во время «прикрутки» дизайна.

Когда разработчик внедряет дизайн, у него появляется масса вопросов: не влезает текст, картинки не того формата, страница тормозит. Всё это — дизайнерские задачи.

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

Мы в бюро это называем «летающим асфальтоукладчиком». Легко придумать что угодно, например, летающий асфальтоукладчик, нарисовать его в Фотошопе или даже в 3Д‑редакторе. Но реально построить его, чтобы он летал и укладывал асфальт — очень сложно, потому что всё упрётся в реализацию.

В схеме «Дизайнеры ↔ Клиент ↔ Программисты» дизайнеры были где‑то далеко, а программисты варились в собственном соку. В лучшем случае они обсуждали проект с клиентом:
Всё изменилось, когда мы изменили схему «Клиент ↔ Дизайнеры ↔ Программисты»:
В такой схеме клиент приходит к дизайнерам, они обсуждают задачу с точки зрения бизнеса, дизайнеры создают макеты, и сами передают их программистам. Когда у программистов возникают вопросы, эти вопросы они задают напрямую дизайнерам. Дизайнеры дают ответы. Это и есть разработка, управляемая дизайном.

Схема универсальная. Вы можете поставить сюда любых исполнителей. Представьте, что вы делаете журнал: вместо дизайнеров будут какие‑нибудь метранпажи, а вместо программистов — полиграфисты, которые знают, что больше трёх красок смешивать нельзя. Это, кстати, реальный пример. Мы делали печатный журнал Главбух. Дизайнеры нарисовали красивые макеты, а потом человек, который разбирается в особенностях печати, макеты завернул. Потому что там были трёхкомпонентные цвета. И когда их печатаешь, они плохо совмещаются. Дизайнеры потом подбирали новые цвета.

Макеты — не результат. Их нарисовали и выбросили. В лучшем случае, опубликовали в портфолио. А результат — это сайт, установленный на домене, или журнал, лежащий на столе. Результат — это всегда пуск продукта. Поэтому, чем бы вы ни занимались, вы должны контролировать сам запуск продукта. Когда вы строите дом, работайте с рабочими: ведь от того, как рабочий кидает цемент мастерком, зависит результат.