Картинки никому не нужны
Про разные миры в команде, понимание материала, наведение красоты и эксперименты
Вот есть какая-то команда. Пусть будет Маша — дизайнер, Коля — разработчик и Света — менеджер. И каждый день ребята что-то делают: задачи там, строчки кода комиттят, картинки отправляют клиенту, выясняют кто чем занят.
Каждый человек в команде выполняет свою роль: то есть берет на себя ответственность за определенный тип задач и пытается эту ответственность нести и что-то делать в рамках. Роли помогают не залезать на чужие зоны ответственности, меньше спорить (а еще винить кого-то, потому что ну это же он так нарисовал/запрограммировал/договорился).
Есть один постулат, который помогает принимать нормальные решения и всегда думать.
Ваши картинки никому не нужны
Под картинками понимаются макеты, кликабельные прототипы, примеры анимаций и вообще все артефакты, которые производит каноничный дизайнер.
Людям неважно, используете вы компонентный подход, или нет, по какой методологии работаете и какой прикольный у вас дизайн-процесс. Сами подумайте: какая разница, в Фигме или Скетче вы нарисовали этот сайт, который потом реализовали разработчики и отдали пользователям?
Никому нет дела даже до того, каким образом вы придумали какую-то функцию. Главное, что она есть и приносит пользу (приносит ведь?).
Мы рисуем картинки, да. По-умолчанию под дизайнером как раз понимается человек, который производит джипеги (ну или что-то получше). Но джипеги/псдхи/скетчи нельзя потрогать, они вообще бессмысленны. По сути, эти картинки — инструкция для разработчиков. И ответственность за конечный продукт возлагается на этих ребят, а еще на клиента, потому что он тексты плохие написал.
Ответственность должна быть на всей команде. Чем качественнее картинки, тем меньше будет помех при передаче в разработку. Чем лучше дизайнер понимает код, тем ближе его картинки будут к реальности. А если дизайнер может помочь довести продукт до красоты, то не пострадают и мелкие детали.
Конечно, не только дизайнеры должны понимать разработку, но и наоборот. Разработчики ведь реализуют компоненты, а затем смотрят на все их возможные состояния на разных данных. Компонент как бы приоткрывает душу. Такой силы у дизайнера нет, потому что у нас деревянный Скетч, в который ты кладешь компоненты и можешь их перекрасить. Компоненты? Всё круто, но только не изменение данных и позиционирования.
Бывает, команда вовсе не команда, а какая-то группа фрилансеров, которых соединяет «менеджерский клей». Ну типа:
— Маша, вот тебе задача: нарисуй, пожалуйста, страницу форму обратной связи.
— Свет, а какие поля должны быть?
— Ну, глянь как у конкурентов сделано.
— Ок. Вот картинка.
— Спасибо, Маш. Коля, вот дизайн от Маши, запрограммируешь?
— А что если случится ошибка валидации? Как будет выглядеть интерфейс?
— Сейчас запрошу у Маши. Вот, она поправила макет.
— Супер. Сделал, вот зипка с кодом.
— Всё, спасибо всем!
Круто, да? Никто даже не поинтересовался, для чего это всё, какую проблему задача решает. Вот реально какой-то фриланс в офисе: менеджер выдал сухую задачу дизайнеру, она запилила картинку, такую же бездушную, как и задача, а разработчик просто это запрогал.
Почти наверняка такая задача не дойдет даже до продакшена, потому что никто не думал ни на каком из этапов. Каждый человек живет в своем мире, куда прилетают задачи, а он их откидывает обратно с пометкой «сделано».
Может показаться, что я топлю за конечный результат любой ценой, но это не так: я считаю, что нужно стремиться к прекрасному результату, но чтобы достигать хорошего качества, придется вкладываться в дизайн-процесс. Например, проводить рефакторинг макетов.
Если сделать некачественные исходники, наговнокодить и потерять артефакты, может получиться пару раз сделать хороший продукт. Но вот поддерживать эти продукты или делать все новые и новые вещи с приемлемым качеством будет невозможно.
Окай, я тут типа поставил под сомнение важность картинок. От рисования джипегов мы пока не уйдем, но как можно стать ближе к продукту?
Сегодня мы поговорим о том, как с помощью понимания кода можно влиять на продукт и быть ближе к сокомандникам. Чтобы не быть голословным, постараюсь привести примеры из работы.
Так получилось, что я хорошо понимаю код: вместе с дизайном в 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. Там пока только реактовские компоненты, но наверняка ребята придумают что-то и для мобилок.
В картинках нет жизни, в них нет души. Они не принесут пользователям счастья (если это не открытки). С кодом не лучше: он нужен только команде разработки. Людям же нужно то, что можно потрогать; они хотят такую штуку, которая закроет потребность, или сделает их лучше, или развеселит в трудную минуту.
Зачем нужны картинки? Они помогают дизайнеру перенести воображение в какой-то осмысленный вид. Дизайнер может использовать картинки, чтобы проверить гипотезы, прежде чем команда потратит миллионы нефти на разработку плохого дизайна. Дальше этими картинками воспользуется разработчик, чтобы оживить их и сделать приложение или сайт. Но это все еще не продукт.
Приложение становится продуктом, когда у него появляются пользователи. Когда оно выходит из вакуума, встречается с реальным миром. Одновременно с этим появляются новые знания: этот сценарий не сработал, тут непонятный текст, а эта хрень никому не нужна. Если команда не забрасывает продукт, а работает над ним, то продукт начинает жить: выходят новые версии, часть пользователей уходит, новые пользователи узнают о продукте; продукт становится людям полезнее конкурентов и все такое.
Не все делают продукты в привычном понимании слова. Заказные проекты похожи на продукты. Только если продукт — это условно бесконечный проект, то у проекта есть какой-то конечный результат. И этот результат тоже можно делать хорошо. Например, уделять больше времени исследованиям и пытаться сделать сразу так, чтобы не нужно было потом тестировать миллион гипотез на живых пользователях.
Превращайте картинки в продукты
Добавляйтесь ко мне в друзья в Фейсбуке. Еще у меня есть телеграм-канал, где я делюсь мыслями про работу, дизайн, и продуктивность:
