В Яндекс.Деньгах мы сделали БЭМ-платформу основным инструментом дизайнеров для построения интерфейсов, дополнив ее всем необходимым арсеналом для масштабирования.

Тысячи часов были инвестированы мной вхолостую. Если верить правилу 10 000 часов, то еще немного и я смог бы стать сносным скрипачом, ремесленником, спортсменом или еще кем-то. Но в разработке и дизайне это не работает. Весь шлак удаляется и часы обнуляются. А число ошибок и скорость изменения настолько велика, что мысли о приобретенном опыте можно отбросить.

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

Мне, как дизайнеру, не хочется тратить 90% времени на формирование окружения (структуру, сборщики и другие подобные вещи). А писать HTML и CSS по старинке, я позволить себе не могу. Таким образом, появляется необходимость в среде для «умного» дизайна.

Анти-кастомщина

Какое-то время я был горд проделанной работой. То, тем как поменялись процессы в нашей команде, как мы выходили из полного дизайн-хаоса. Я описывал это в статье «Дизайн масштабируемых проектов». Но меня беспокоило несколько моментов. И ощущение того, что мы написали свою кастомщину (хоть и достойно справляющуюся со своими задачами) все чаще напрягало.

Дизайн в браузере — Параметрический дизайн — Автоматический дизайн

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

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

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

Откатимся немного назад. Буквально года полтора назад, камнем преткновения были отрисованные макеты. Так, как основной проблемой, была разница в отображении/поведении возможностях графического редактора и живого кода. Затем многие «тру» дизайнеры, в основном проектные, перешли на сторону «Дизайна в браузере» и планка логики стала возрастать в довольно быстром темпе. Все синхронизировались в понятиях. Стало понятней общаться с интерфейсными спецами разных уровней и разных ролей (в интерфейсном процессе). Дизайн в браузере само собой точка не возврата, но это всего лишь отправной пункт долгого пути.

Боль

Как не странно, но по самому процессу разработки визуальной части мы в компании отстаем как минимум на года 2-3. Во-первых, классическая, изолированная, универсальная модель: Проектирование — Дизайн — Верстка. Во-вторых, один и тот же подход остается как для страниц мелких акций (заглушек), так и для масштабных сервисов вроде, где трудно предугадать сценарий развития. Но мы метем все под одну гребенку. Я лично не знаю в нашей компании персонажа, который глобально бьется над улучшением процесса и самой системы разработки визуальной части. В основном звучат умелые фразы, по поводу сроков и складывается впечатление, что все мастера по тайм менеджменту. Многие из резких фраз, как «Процент времени», напрочь убивают всю логику, и наивно полагаться на сохранение продуктивности на том же уровне. Когда разрабатываешь крупный проект, 5-7 глобальных переключений в день на другие задачи, полностью парализуется и сбивает весь процесс разработки основного проекта. Ну, впрочем, это менеджерская магия с выгодой в одну сторону.

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

Теперь о вытекающее из этого «боли»…. Ситуация, которая сейчас выглядит так:

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

Первая эйфория закончилась и я отправился на поиск более комфортной среды. Для меня не было принципиально какая это будет компания. Главное чтоб была верстка, а все остальные условия должны были быть хоть малость адекватны с небольшим намеком на перспективы. Опять же буквально после пары интервью я попал на проект. Собственно поэтому и хочется подвести осмысленное сравнение.

Для прогрессивной визуальной разработки нельзя просто внедрить пару тройку фишек. Нужно радикально изменить сознание и фундаментально поменять подход. Я не буду разбивать процесс на избитые заезженные этапы. Опишу более свежо. Две основных составляющих агрессивно нового подхода: «Дизайн в Браузере» и «Автоматизация фронт-энда».

Начнем с первого — «дизайна». Тут проблема в отношении к дизайну как к статической .psd. По ощущению это должно было потерять свою актуальность в тот момент, когда появился адаптив, добавилась динамика и доработка на живую макета стала привычным делом. Теоретически смерть статичных .psd-шек наступила вместе с отходом табличной верстки. Зачем пытаться оживить то, что отслужило?! Тогда это было актуально, так как фактически в таблицу запахивалась картинка макета, только в нарезанном виде. Сейчас же макет выполняет роль ориентира. В большинстве случаев мы не вырезаем ни пикселя. А просто держим макет открытым в соседнем окошке. Для того, чтобы написать всю эту «красоту» кодом.