Сегодня мы поговорим о том, как с помощью понимания кода можно влиять на продукт и быть ближе к сокомандникам. Чтобы не быть голословным, постараюсь привести примеры из работы.
Так получилось, что я хорошо понимаю код: вместе с дизайном в 2010 я начал изучать и программирование на ПХП. Было классно разбираться с бэкендом и версткой, чтобы получалось воплотить макеты в жизнь. Но в какой-то момент моих навыков верстальщика перестало хватать, чтобы запрограммировать свои макеты, тогда я уже подзабил и стал меньше уделять этому времени.
Потом был вуз, где я учился на программиста (самое близкое, что смог найти к интерфейсам). Хотя программистом я и не стал, такой бэкграунд помогает декомпозировать задачи, общаться с разработчиками на одном языке и уметь сделать что-то самостоятельно.
Позволю себе привести цитату из монолога Сергея Сурганова, дизайнера из Notion, для Bang Bang Education:
Мне очень важно было понимать материал, с которым мы работаем, экран и пиксели, которые за ним стоят, и код, который выполняется, когда ты нажимаешь на кнопку. Мне очень важно было понимать как это на самом деле устроено. Потому что вот это естественное сопротивление материала, когда ты рисуешь просто макет, почти отсутствует, но когда ты пытаешься его имплементировать, воплотить в жизнь, ты сразу сталкиваешься с огромным количеством ограничений, которые тебе не видны, если ты не будешь делать это сам руками. И ты начинаешь совершенно по-другому на это смотреть.
— Сергей Сурганов
Когда работаешь в режиме концептов на дрибл, не видишь материала: делаешь статичные или анимированные картинки с летающими конями, параллаксом и эффектами. Работа уходит на сайт, собирает лайки и комменты и погибает в пучине одинаковых дрибловских шотов.
На реальных проектах, с настоящими разработчиками все печальнее: эффект сделать долго и дорого, таких данных нет и никогда не будет, такое взаимодействие почти невозможно реализовать. В общем, печаль и грусть :c Но такова жизнь, не любую фантазию дизайнера можно воплотить.
Так вот, понимание принципов работы технологий (HTML/CSS/JS/API для веба, Swift для iOS и Kotlin/Java для Android) помогает сразу делать макеты более жизнеспособными, а иногда, при возникающих сложностях у разработчиков, ухищряться и выдавать оптимизированное решение, которое достигает того же эффекта, но заметно дешевле.
Что такое понимание принципов работы? Для дизайнеров интерфейсов в большей степени нужно понимать верстку макетов, а вот серверная часть необязательна. А верстка — это процесс перевода макета в разметку, чтобы все тянулось, адаптировалось, кликалось и вот это все.
Понимать != уметь писать код. Код напишут разработчики, а вот найти, где поправить ширину элемента, изменить цвет и размер шрифта, что-то подвигать — очень полезные навыки.
Также, понимание материала позволяет дизайнеру искать подходящие библиотеки для реализации той или иной механики самому, то есть подкреплять свои слова и помогать разработчикам. Но тут уже вступает в игру некий айти-бекграунд, который помогает вообще все в айти.
Часто дизайнерам приходится рисовать не только интерфейс, но и наполнять этот интерфейс контентом. Например, на новом сайте нашей компании мы перешли от ПХП и Друпала на Реакт и новомодные технологии. Если раньше портфолио на сайте наполняли через текстовый редактор в админке, то теперь нужно было придумать что-то свое.
Для упрощения в каждом проекте я выделил основные элементы верстки:
- Заголовок 1
- Заголовок 2
- Параграф
- Картинка на ширину контейнера
- Картинка на всю ширину
Разработчики сверстали эти элементы компонентами, а затем мы вместе определили структуру JSON-файла для хранения контента. Получается, при изменении каких-то параметров в файле, верстка пересобирается. Ниже будет иллюстрация к такому подходу. Слева показана часть JSON-файла, где описывается мета-информация (на иллюстрации нет), а в параметре contents задается набор компонентов, которые должны появиться на странице. Порядок сохраняется.
С таким подходом сложнее выстрелить себе в ногу: у дизайнера нет доступа до очень гибких HTML-тегов и стилей, но он может выбирать, какие компоненты, в каком порядке и с каким контентом показать. Это достаточно близко к символам в Скетче с оверрайдами, но здесь сложнее создать новый символ, зато работают «стеки».
К тому же, если через время мы захотим переделать компоненты, нам не придется бороться с пользовательской версткой, которая появляется из-за WYSIWYG-редакторов в Вордпрессах.
Вам может показаться, что это уже за гранью. Ставить редактор кода дизайнеру? Копаться в джейсонах? Во-первых, это все-таки не код, а лишь формат для хранения данных: думать тут особо не надо. Уметь программировать тоже пока не надо. Зато у дизайнера появляется инструмент для быстрой сборки экранов, причем, не в прототипном качестве, а в финальном. И не нужно ждать, пока ребята разработчики полезут в код, поправят, выкатят, а потом опять поправят. Можно править контент самому!
Если посмотреть на опыт коллег, то на недавней Mail.ru Design Conf × Dribbble Meetup 2019 Александр Артсвуни и Павел Лаптев из Farfetch рассказывали, как дизайнеры у них собирают разные экраны на компонентах в Xcode через JSON и даже иногда сами верстают новые простые компоненты. Смотреть запись трансляции с 1:02:00.
Когда знаешь код, страх уходит. Если нужно поправить что-то на сайте, не страшно залезть в гит, стянуть код, починить что-то и слить обратно. Если разработчики предлагают поиграться с с анимациями через параметры в коде, то запросто. Когда появляется интересная гипотеза, появляются новые инструменты, чтобы собрать прототип.
Настройка параметров в коде. С анимациями легко натупить: сделал слишком долгую и вся магия потерялась. У разработчиков есть максимальный доступ к анимациям: они могут подвигать конкретные параметры в коде, типа длительности, функции, ускорения и т. д. Почему же дизайнеры должны от этого отстраняться?
Примерка графики. В верстке участвует много графики. Те же фавиконки, картинки для шера, медиа-контент. Такая графика не всегда работает с первого раза: можно не угадать с расположением логотипа, отступами или цветом. Не просить же разработчиков миллион раз подгонять картинки под ваши хотелки?
Сборка прототипа. Высший пилотаж для дизайнера, который понимает код, — собирать интерактивные прототипы. Конечно, они не будут рабочими продуктами, но их можно потрогать, наполнить живым контентом с АПИ и получить новые знания о том, как себя чувствует интерфейс. Например, посмотрите на эксперименты Павла Лаптева на CodePen.
Правка контента. Чуть ранее я вам рассказывал про наш сайт, когда мы сделали JSON-файл для хранения контента. Так бывает не всегда. Часто контент хранится в верстке, и тут пригодились бы знания кода, чтобы быстро его поправить и посмотреть, что получилось в браузере. Если такие правок мало, то это можно поручать разработчикам. Но если мелких «правочек» контента появляется достаточно много, процесс будет похож на итальянскую забастовку (код для разработчиков, макеты для дизайнеров, скайрим для нордов).
После того, как картинки передаются разработчикам, начинается интересный процесс: эти ребята с помощью магии превращают статичные картинки в живые приложения, которые можно потыкать.
Бывает, что дизайнер забыл отрисовать какое-то состояние, или отступы у него поехали. Крутые разработчики сразу видят косяки и предлагают решение, либо же подсказывают, что что-то тут не так.
Еще бывает, что разработчики пытались сделать верстку идеальной и как на макете, но они не Ванги, поэтому не смогли привести все граничные случаи к мечтам дизайнера.
Обычно все проблемы решаются перекидыванием мяча: разработчики пишут дизайнеру про его косяки в макете, а дизайнер, наоборот, строчит баг-репорты со списком мелких правок. Но иногда «хакнуть» процесс и не испугаться потрогать код.
Ну так вот. Однажды нам в KODE нужно было запустить сайт для стажировки дизайнеров. Я нарисовал простой макет: две колонки, правая фиксирована, а левая скроллится. Адаптив здесь не совсем обычный: нужно, чтобы на определенных брейкпоинтах шрифт уменьшился, и только когда совсем стало мало места — верстка стала мобильной. Словами это передать сложно, а рисовать все состояния не хотелось, поэтому я передал макеты Максу, нашему фронту, а он запилил основную страницу со всеми элементами и адаптивом.
Иногда вылезали висящие предлоги, отступы шалили, адаптив был не всегда «идеальный», а только на основных разрешениях. Поэтому я взял Chrome DevTools начал править моменты на ходу, а потом применять их в CSS. Получилось добиться «красоты» — чтобы верстка выглядела «по-дизайнерски» хорошей.
Если бы мы работали по классическому процессу «это моя зона, а это твоя», Макс либо возненавидел меня за кучу правок, либо сайт вышел в продакшен с мелкими огрехами, которые заметны точному глазу.
Тут еще вспомился разговор с моей знакомой Надей, которая работала дизайнером в томской конторе. Она мне где-то год назад рассказывала, как правила верстку на ходу в девтулс, а я удивлялся и офигевал. Так вот, Надя, передаю тебе привет 👋
Мне кажется, что дизайнеры в будущем получат одну среду для создания и разработки компонентов, такую же простую, как и графические редакторы, но со всеми фичами кода: доступом к АПИ, относительным позиционированием, изменением состояния и всем таким.
Кажется, что сейчас ближе всего к такому инструменту подобрался Framer X. Там пока только реактовские компоненты, но наверняка ребята придумают что-то и для мобилок.
Загрузка...
