Применение навигации, модульной сетки, типографики и цветовой палитры в интерфейсных моделях

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

Первая часть текста. Материал в блоге на Medium.

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

Очень скоро нам пригодится расширенный набор с иконками и дополнительными текстовыми полями.

Кстати, обращаю внимание, что начинается матрешка — я вкладываю компоненты друг в друга, переключатели и иконки. И это прекрасно, когда не только экраны переиспользуют ваши компоненты, но и компоненты внутри себя тоже. Со временем это приводит к тому, что вы просто играете с ними, как с конструктором лего — аналогия потому еще уместная, что все пронизано модульной сеткой, о чем я позже подробнее расскажу.

Еще потребуется модификация с двумя строками.

И все, теперь меня не остановить.

Всплывающие подсказки, вложенные меню и выпадающие формы всех мастей тоже собираются из списка.

Дальше еще интереснее. Потому что если подумать, то списки — частный случай таблицы.

Тот же факт, что таблица — это столбчатый список, намекает на обратное преобразование, полезное при адаптировании таблиц под мобильные экраны.

А еще из списка можно собрать календарь.

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

• Макет или спецификация попадает в задачу на разработку.
• Разработчики проводят оценку: видят много знакомых конструкций, радуются и не завышают сроки (слышали о правиле «умножить на три и добавить неделю»?).
• Если встречается какой-то новый компонент, вы прилагаете к нему матрицу состояний — и его разрабатывают отдельно, в песочнице вроде Storybook.
• Там же компонент документируют, покрывают тестами (пишут отдельный код или конфиги, проверяющие работоспособность перед каждым релизом).
• Новый компонент принимают отдельно от родительской задачи, с кодревью и прочими проверками коллег.
• А после возвращаются к исходной задаче.

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

Изолированная разработка компонента позволяет себя органично параллелить, упрощает тестирование, обосабливает потенциальные проблемные места — как бы сложно ни звучало, но на долгих дистанциях это всё ускоряет и упрощает. Однако без содействия со стороны дизайна процесс и правда напоминает карго-культ — корпоративный GitHub купили, на React все переписали, Scrum-мастера наняли, а продукту лучше не становится, и кода меньше писать тоже не стали.

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

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

По такому дереву можно последовательно перемещаться двумя способами: переключение между соседними узлами и погружение вглубь узла — я их называю свитч и стек. Для маркировки свитч-навигации я использую всевозможные переключатели.

Для стек-навигации в основном тулбар.

Последовательная навигация открывает минимум две возможности.

• Линейное адаптирование на мобильную платформу (или наоборот, неважно).
• Фрактальная структура приложения (я поясню).

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

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

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

Теперь фрактальность — понятие относительно недавно появилось в веб-разработке. Значит оно то, что каждый контекст приложения должен вести себя как отдельное приложение. Это логично вытекает из одного из основных паттернов программирования — инкапсуляции. Какие привилегии дает фрактальность:

• Гибкая топология приложения — какая-нибудь форма регистрации или корзина не привязаны к контексту и могут возникнуть в любом фрагменте любого экрана. Это явление часто можно наблюдать в iOS.
• Изолированная разработка — уже писал выше про параллелизм, автономную приемку и тестирование.

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

Фрактальными площадками в моем словаре служат несколько видов контейнеров, куда я складываю мини-приложения. Тут главное — расслабиться и получать удовольствие, не стесняться класть в контейнеры что угодно.

В «Таксометр» это приземлилось так.

Вот я складываю в нотификации DMS все, что посчитаю нужным — даже фрагмент заявки с полями.

Семантику контейнеров можно делать хитрее, добавлять сразу несколько на экран, разрешать пролистывать, скроллить и так далее.

Вернусь к последовательной навигации с новыми сведениями о фрактальности.

Мне можно возразить, что теория игнорирует практику, лишает продукт удобного сценария быстрого перехода. В каком классе интерфейсов последовательную навигацию хочется нарушить — например, в почтовых клиентах, когда пишешь письмо, иногда надо перейти в контактную книгу или в прошлое письмо, что-то скопировать и вернуться; частный случай оконного интерфейса.

Безопасно нарушать последовательную навигацию можно между автономными контекстами — когда определены границы каждого (замкнуты в некотором визуальном слое) — тогда они могут взаимодействовать друг с другом как независимые приложения.

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

Снова вернемся к кнопке: я разделил ее на абстрактное описание и доопределение бренда. В самом же деле речь шла о двух типах компонентов — абстрактном и чистом. А позже я показывал множество примеров третьего типа, но никак их не называл. Давайте наводить порядок.

Я разделяю компоненты на типы (терминология снова моя).

• Абстрактный — описание состояний и поведения без графического воплощения.
• Чистый — графическое воплощение, лишенное знания о предметной области.
• Доменный — представляющие знание о предметной области.

С абстрактными выше мы разобрались, переходим к чистым. Чистым от лишнего знания. Некоторые разработчики предлагают термин dumb, некоторые — presentational. У меня не получилось перевести термины на русский так, чтобы я хотел их использовать в разговоре.

И думаю, мне влетело бы еще и за то, что компонент в узком смысле определяется функцией, и существует термин «чистая функция», который лежит в иной плоскости, и все это может запутать.

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

И сразу примеры компонентов доменных (отсылка к доменным объектам; в статьях выше их еще называют smart или containers).

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

Такая классификация помогает инвестировать в конструктор, оставлять полезные артефакты от рутинных задач. Вы работаете на трех уровнях абстракции и переключаетесь по ситуации.

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

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

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

Доменные компоненты не подлежат переиспользованию по своему определению — отсюда правило: стремиться к тому, чтобы они целиком состояли из чистых компонентов. Каждое исключение будет повисать мертвым знанием, взрывоопасным фрагментом кода, разбитым окном, если хотите.

Если работу организовать так, то и вы меньше сил на переключения тратить будете, и обсуждения с командой будут идти по нужному руслу: заметность кнопок обсуждается и проверяется при разработке чистого компонента кнопки (можно вспомнить мое определение компонента, собирающего знания о себе), и подобные вопросы больше не всплывают при обсуждении формы авторизации.

Если все-таки всплывут — вы переключаетесь в режим номер два, чините проблему и возвращаетесь в режим номер три.

Проиллюстрирую оптимизацию еще на одном примере. В «Таксометре» в режиме проектирования чистого компонента я описываю прилипшую к низу карточку, где продумываю обе темы и обе ориентации.

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

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

В начале рассказа я сформулировал задачу:

Вроде начало получаться. Теперь добавлю еще один вопрос: как отделить найденные отношения цветов, форм и пропорций от их частных воплощений?

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

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

Впрочем, многие компании, пока им хватает финансовой подушки, эту проблему не признают — но нам и не нужно их признание, когда можно посмотреть на степень рассинхрона по платформам. Мне бы возразили: «Телефон — это другое» или «Android — это другое», но различия платформ, по-моему, выглядят как-то так:

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

С сетками та же ситуация, что с кнопками и навигацией, — вещи до боли знакомые, но чтобы прийти к новым интересным выводам, придется начать с самого начала. Впрочем, пересматривать аксиоматику полезно. Начну, как обычно, с определения.

Ее роль — сделать расположение графических элементов объяснимым, вычислимым. Сетка (в моем определении) сама по себе композиционной ценности не имеет и никаких подсказок не дает.

Зачем композицию формализовывать, я скоро объясню; а сейчас снова о трудностях перевода. Когда я говорил о типах компонентов, то извинялся перед разработчиками за столкновение терминологий. Сейчас, думаю, происходит то же самое с любителями бумаги цвета шамуа.

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

Для общего развития взглянем, как сетку применяют в кино.

Там она целиком служит образной задумке режиссера, слегка подгоняя кадр под несложные геометрические закономерности. Зачем подгонять — есть мнение, что человеческий глаз интуитивно отдает предпочтение посчитанным пропорциям.

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

Вообще, сетки я использую двух масштабов: модульную и направляющую.

Модульная сетка определяет основные размеры: минимальный отступ, высоту активного элемента, размеры иконок и иллюстраций. Базовый модуль на старте я уточняю до 8 px (но это значение может меняться — позже покажу, как и зачем). Почему именно это число:

• Оно четное — иногда приходится оперировать отступами 0,5 или 1,5 модуля.
• Кратности этого модуля образуют удобный ряд: 16, 24, 32, 48 (популярные размеры иконок и кнопок).
• Ряд этот не слишком быстро растет, обеспечивая универсальную степень дискретности. В отличии, скажем, от ряда «10, 20, 30…», который растет слишком быстро.

Сетки объясняют не красоту макета, а его закономерности. Это ускоряет дизайнера в принятии решений и помогает разработчику однозначно считать макет. Я хочу подробно объяснить свою точку зрения на сетки, потому что есть иное мнение, будто весь интерфейс надо согласовывать с этими клеточками — а это создает множество неудобств в разработке и не помогает эстетике.

Если присмотреться к верхней картинке, к низу клетки съехали — почему так происходит:

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

Типографика: я не подгоняю ее под миллиметровку; она живет своими размерами, в которых шрифт работает наилучшим образом (о ней я еще напишу отдельно).

При этом отступы между строками текста и соседними блоками или другими строками кратны модулю.

Я считаю отступ не от базовой линии текста, а от края текстового бокса, потому что учитывать baseline в разработке бесполезно дорого: она, во-первых, скачет у разных шрифтов.

Во-вторых, в браузерах текст выравнивается не по нижней границе, а по середине строки — придется делать магические компенсирующие смещения строк, которые все равно будут дрожать из-за разных алгоритмов округления браузерных движков. То есть отступ я считаю не так, «как положено».

Я просто ставлю кнопку вплотную к текстовому боксу, и если элементам тесно, увеличиваю отступ до 8, 16, 24 и так далее, пока глазу не начнет нравиться.

В этом, кстати, и заключается экономия умственных усилий — у меня ограниченный дискретный выбор между тесно, ритмично и воздушно.

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

Размеры экранов устройств тоже могут сбить с толку. Например, iPhone SE идеально ложится в сетку, кратную восьми, а iPhone X вообще имеет нечетную ширину.

Лечится это отключением глобальной сетки и выражением всего в абсолютно-относительных ширинах.

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

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

Чтобы понять всю его прелесть, разберем фрагмент системы. Вот компонент иконки, кратный трем модулям (3m).

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

Кроме стандартного модуля в арсенале появляется тройной модуль. Поэтому любым небольшим объектам есть смысл тяготеть к тройному модулю: радиокнопки, ячейки списка и так далее. Кроме того, вложенный компонент иконки может быть настраиваемым параметром.

То же самое можно провернуть и с тумблером.

Начинаю собирать список, появляются два новых типа модуля: 6m (48 px) — эту же кратность используют остальные стандартные активные элементы (кнопки, инпуты, табы); и 2m — стандартные поля. Элемент списка включает в себя модульные ячейки, описанные ранее, — 3m и 4m.

В пустые ячейки могут вставать иконки и мелкие контролы.

Позже мне потребуется кратность 9m (72 px) — мини-иллюстрации, крупные значки, счетчики и тому подобное. Предусматриваю эту кратность в элементе списка и в диалоговом окне.

В будущем если я придумаю еще какой-нибудь компонент и выберу его кратность из ранее использованных — 3m, 4m, 6m, 9m, — я автоматически получу совместимость с другими компонентами. Например, кнопка с полями и высотой, унаследованной от списка.

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

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

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

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

Та же технология используется в «Таксометре» — там чем больше дисплей, тем крупнее водители просят делать элементы интерфейса. Если просто тянуть всю картинку в полтора раза, возникает риск выйти за поля; увеличение кнопок будет тянуть за собой увеличение текста, что не всегда требуется; размеры, указанные не в модулях, поедут, что тоже нежелательно.

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

Я хочу очень скромно коснуться этой темы, основных пунктов, без учета которых интерфейсные тексты приходят в упадок.

• Семантика размерной шкалы.
• Смысл начертаний шрифтового семейства.
• Масштабы в типографике.

Семантика размерной шкалы для всех интерфейсов, с которыми я работал, примерно одинаковая — меняются только абсолютные значения.

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

Каждое начертание имеет название, намекающее на контекст использования: body 1 — основной текст, caption — что-то не очень важное, локальный и основной заголовки и еще пара начертаний про запас, caps в основном для пунктов меню и body 2, о котором я расскажу позже.

Обычно, когда предлагаешь такую скромную шкалу, тебе сразу показывают макеты, где, по их мнению, между body 1 и body 2 ну очень нужны 15 и 16 размеры — дело, конечно, не в абсолютах, а в стремлении занять все целочисленные ниши. Я сталкивался с двумя типами объяснений.

• «Я так чувствую» или «Кажется, что в этом макете все-таки лучше 15».
• «Эксперимент показал, что чаще кликают, когда размер цены 15».

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

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

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

Второй момент, о котором я не раз упоминал, — экономия сил при принятии рутинных решений: когда перед дизайнером веер из 14, 15, 16, 17 и других размеров, ему не на что опереться при выборе, и это здорово изматывает.

Третий момент — считываемость макета разработкой: моя практика показывает, что любая неконтрастная разница обязательно будет перенесена с ошибкой.

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

• Разлад в системе тоже будет иметь финансовые последствия (поддержка исключений в дизайне и в коде, мотивация сотрудников).
• Можно попробовать поднять статистику: компонентный подход ускоряет и дизайн, и разработку — то есть в продукте проворачивается множество итераций за единицу времени, проверяется большее число гипотез. Локальные бессистемные улучшения могут вставить свои две копейки сегодня, но будущего у них нет.
• Возможно, это сигнал о том, что масштаб в принципе мелковат, и надо не в одном месте размер подтянуть. Правда, ждите новых экспериментов, в которых меньше данных уместится на экран, и тоже упадет какой-нибудь показатель.
• Попробуйте устроить размен, добейтесь сравнимых результатов эксперимента иными способами: композицией, цветом или начертанием.

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

Смысл начертаний шрифтового семейства — балансировка акцентов в композиции. Часто слышу «у нас в продукте все заголовки жирные» — мое мнение, что заголовки надо набирать тем начертанием, которого просит контекст. На примерах будет понятнее.

Среднестатистическое семейство имеет минимум четыре начертания: основное наборное, полужирное, жирное и легкое (Regular, Medium, Bold, Light). Я не привязываю начертания к семантической шкале, но вношу ограничения: например, наборные тексты body 1 и body 2 не представлены в Light.

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

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

Вообще, баланс штрихов касается не только Light-начертаний. В свежих промо наши друзья вот так балансируют текст с рамкой телефона.

Нюансировка при этом не механическая — с увеличением рамки меняется и текст.

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

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

В свободное время раньше я регулярно собирал визуальные концепции поисковой выдачи «Яндекса» на базе тех данных, которые уже выдаются сервером. Начиналось все с аккуратного белесого списка, и вот что у меня созрело к лету 2017 года.

Масштабы в типографике помогают, когда работаешь над универсальным компонентным конструктором: не для одного продукта, а для бренда с целым семейством продуктов и зоопарком платформ.

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

Я эту задачу решаю так: в типографику добавил стиль Body 2 (крупный наборный текст) и в направляющей сетке межколонник указал не один модуль, а два — стало просторнее (прочие отступы тоже получили дополнительный модуль). Получилось два масштаба типографики, основанные на Body 1 и Body 2.

Body 2 при этом касается только текстов — в компонентах так и остался Body 1. Один масштаб не исключает другой, они могут дружить на одной странице. Вот я тренируюсь на кошках, два экрана — два масштаба.

В конец добавил примеры мобильных экранов — все тот же масштаб Body 1 и контролы, увеличенные на модуль.

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

Я давно хотел начать работать с цветом осмысленно, как с сетками и типографикой. Но у меня не было способа ориентироваться в цветовом пространстве, я не мог себе объяснить выбор того или иного цвета и по каким принципам из цвета получить ряд.

О цвете я говорю в моделях, но он едва ли поддается какой-либо формализации, его почти бесполезно сводить к числам, равномерным смещениям, пропорциям и прочим привычным приемам. И все-таки некоторые рецепты есть — найти их помог опыт Тараса в полиграфии и цветокоррекции кадров.

Работу с цветом (как и любую другую) стоит начинать с поиска образов: Bold Yellow из Нью-Йорка для «Такси», горячие углеводы и золотой графит для «Еды». Помимо того, очень помогут наблюдения за поведением цвета в природе: как одну и ту же краску блики разогревают, а тени охлаждают; как природа гармонизирует цвета по соседству.

Раньше я воспринимал палитру как ограниченный набор корпоративных цветов, данный кем-то свыше. Например, цвета «Яндекса» были когда-то вот такими.

Откуда они взялись: существовало раньше понятие таблицы безопасных цветов, поэтому хорошим тоном считалось выбирать цвет оттуда; нужно было найти такой желтый цвет, который бы на белом фоне был максимально ярким, хорошо держал форму и не уходил в красноту — в таблице только один такой кандидат.

Остальные два цвета тоже из таблицы, максимально красный и максимально черный, которые способны выдать мониторы. Эта троица дала начало всему остальному.

История этих трех цветов — хороший стартовый образ, но не тянет на палитру. Я покажу, как создавалась универсальная палитра для «Такси» — на ее примере раскрою понятия расширяемой палитры, групп цветов и цветового ряда; приведу сильные и слабые стороны разных участков спектра.

Начну с оттенков серого — в интерфейсе их больше всего. Идеальный ахроматический ряд без примесей в природе не встречается (условия фотостудии не рассматриваю), а оттого и на экране выглядит ненатурально и пресно.

В естественных условиях все объекты влияют друг на друга. Давайте представим серый цвет асфальтом. Что его могло бы окрашивать? «Температурными отражателями» выступят здания, деревья и небо.

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

Получили ряд теплых оттенков серого. Теперь подробнее про алгоритм преобразования. С цветом будем работать в HSV-модели — человекопонятный формат, в котором поворот трех ручек интуитивно предсказуемый.

Так вот, охровый градиент на всём протяжении сохраняет оттенок (Hue) 35º, меняется только насыщенность (Saturation) — это проявляет характер выбранного оттенка охры. Как дальше замешиваем его с серым:

Ахроматический серый в HSV-модели характеризуется исключительно тоном (Value, количество чернил), поэтому остальное по нулям. В охре нас интересует только значение оттенка 35º — переносим его в чистый серый и получаем «35 0 88», а дальше по вкусу крутим ручку насыщенности, получаем разные степени прожарки.

По мере приближения к черному насыщенность цвета следует увеличивать, потому что чернила будут перекрикивать оттенок.

В районе белого хватает минимально возможной примеси в 1%, но чем дальше в лес, тем больше охры подмешиваем.

Кстати, у вас в графических редакторах периодически будут спрыгивать HSV-значения из-за того, что оригинальный цвет хранится в RGB-модели, которая более полная (HSV: 360×100×100 = 3 600 000; RGB: 256×256×256 = 16 777 216) — возникает проблема обратных преобразований.

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

С холодным рядом Тарас предложил более сложный ход с меняющимся оттенком градиента.

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

— А что насчет «серого, как у Apple»? Кажется, ребята не заморачиваются и используют чистый ахроматический ряд.

— Они очень даже заморачиваются: попробуйте на досуге потыкать пипеткой в их Notes: внутри спрятана какая-то мощная система, синтезирующая цвет из оттенка, акцента и компенсации визуальной массы.

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

Видится мне, что ребята используют ахроматическую шкалу осознанно, чтобы показать объект сам по себе, без влияния окружения. Это фокусирует зрителя на предмете съемки, на безупречности форм (то же подчеркивают точно подобранные углы камеры).

Тон съемкам техники Apple задал Эндрю Цукерман, автор концепции изъятия объекта из контекста, — можно посмотреть на его работы и сделать вывод, что случайных ходов там нет. И например, когда надо поместить объект в среду, его туда помещают, и стерильность ахроматического ряда пропадает.

Ecли понаблюдать за цветопередачей разных моделей iPhone — ребята все время экспериментируют с балансом белого, который влияет на восприятие ахроматического ряда в том числе. В общем, я что сказать пытаюсь: дизайнеры Apple контролируют цветовое пространство на всех уровнях и решают какое-то свое уравнение со множеством переменных.

С хроматическими цветами все еще интереснее: один оттенок можно бить на несколько типов, и для каждого строить свой ряд.

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

В случае с «Такси» всё равняется на желтый. Поиск образа для желтого я уже описывал, но опустил нюансы ручной доводки. Наш капризный желтый живет в приблизительном диапазоне Hue 53º—60º (левее краснота начинает уводить в оранжевый, а правее зеленый тащит в салатовый). Цвет быстро пачкается, поэтому чернила не должны опускаться ниже 95%. Настоятельно рекомендую прямо сейчас открыть редактор и потрогать этот цвет.

Остановились мы пока на HSV: 53 78 98. Из-за образа Bold Yellow хотелось подальше уйти от лимонных тонов.

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

Цвет выше получил название Yellow Normal, с тем же оттенком 53º, но с выкрученной до 100º насыщенностью появился Yellow Toxic. Спокойный желтый подходит для заливки больших площадей, а токсичный будет гореть ярким индикатором чего-либо.

Оставалось понять, как для каждой группы цветов достроить ряд светлых и темных. Тут мы снова обращаемся к природе за советом и смотрим, как ведет себя асфальт в тени и на свету.

Левая часть освещена теплой охрой, а правая уходит в холодную синеватую тень. То есть свет, взаимодействуя с абсолютно серым асфальтом (HSV: 0 0 ~50), бликами склоняет его оттенок в красно-желтый (теплый) спектр, а тенью уводит в синий (холодный).

Итак, нужно получить из основного цвета ряд от светлого к темному. Натуральным кажется его «осветить» и снять цвета с контрольных точек градиента — в середине при этом должен оказаться нетронутый оригинальный цвет. Описанный выше физический процесс со смещением оттенка в сторону желтого или синего отсылает к алгоритму Overlay Blending, который есть в каждом графическом редакторе.

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

Десатурация полученного ряда (уменьшение количества цвета) позволяет получить семейство Fades.

Итого: один базовый хроматический цвет распадается на три семейства, в каждом из которых температурным градиентом раскладывается на ряд от светлого к темному.

Построенный на температурном контрасте цветовой ряд дает живые и осязаемые сочетания — что очень кстати для наших тактильных интерфейсов.

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

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

Карту хотелось сделать не какой-то, а именно картой «Яндекса», которая узнается так же, как желтая стрелка или красная «Я».

Основной цвет подложки определяется землей и зданиями и лежит в диапазоне оттенка 45—50º. Делаем из этого градиент и замешиваем с ахроматическим рядом в той же пропорции, что и реки.

Так получаем прямого потомка «Яндекс.Карт», вписанного в палитру продукта и в требования быть спокойной подложкой.

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

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

Обратите внимание, что там два синих, два зеленых, два желтых; в чем тут дело: я уже отмечал, что у каждого диапазона спектра (параметр Hue) есть свои особенности, свой ассоциативный ряд: охра, вода, Нью-Йоркское такси, горячий хлеб — поэтому цвет зеленого светофора не то же самое, что съедобный лаймовый.

Любой участок спектра можно включать в палитру, если возникает потребность. А характер самой палитры определяется оставшимися двумя параметрами (Saturation и Value) и алгоритмом вычисления ряда: температурные или иные градиенты и степень их проникновения в основной цвет.

Любой продукт, набравший вес и аудиторию на рынке, сталкивается с основной проблемой развития — ценой ошибки. Когда вы маленький и вас штормит ±5% прибыли от релиза к релизу — это нормально и даже весело. А вот когда капитализация перевалила за миллиард долларов, к ответственным за потерю процента возникнут серьезные вопросы. Отчасти поэтому большие продукты избегают больших релизов и изменения вносят так, что вы их не замечаете.

Решения в таких случаях принимаются по результатам экспериментов.

Проверка, понятное дело, должна быть безопасной, поэтому существует понятие экспериментальной выборки — репрезентативной доли аудитории продукта (обычно в районе 1—2%). Эта доля получает новую версию продукта с изменением, проверяющим гипотезу.

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

Если ожидаемых изменений не сформировано — это ставит под вопрос адекватность всей затеи, так как проверка гипотезы оборачивается выстрелами наугад и попыткой объяснить пользу от обратного, уже имея на руках результаты.

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

Задач полно, поэтому в одно и то же время проводят много экспериментов — но тогда каждому надо выделять по 2%. Если процесс не ограничивать, то все 100% аудитории вскоре распределят по тем или иным экспериментам — будет окончательно размыто понятие релиза и версии, состояние и очертание продукта станут чем-то неуловимым.

Поэтому экспериментальную квоту ограничивают какими-нибудь 20%. В такую квоту поместится не более десяти экспериментов. Экспериментам, чтобы избавиться от шума и девиаций, нужно накопить достаточное количество статистических данных — поэтому крутить могут неделями.

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

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

N-мерное пространство экспериментов рождает новую задачу: нужно следить, чтобы проверяемые гипотезы не пересекались, иначе эксперименты начнут влиять друг на друга, и аналитики не смогут интерпретировать результат каждого по отдельности.

А еще представьте, что гипотеза решения проблемы состоит из X, Y и Z мер. Вы можете захотеть проверить все комбинации: XYZ, XY, XZ, YZ, X, Y, Z. Чтобы было понятнее: вы улучшаете выдачу авиабилетов, добавляете каждому результату информацию об авиакомпании с логотипом, рейтингом и фирменным цветом — но вы не уверены, как размер логотипа или фирменный цвет перераспределят нажатия на «Купить»; вдруг оно начнет отвлекать, а вдруг информацию, наоборот, не заметят.

Можно критиковать такой нерешительный подход, но до тех пор, пока волшебная комбинация параметров не увеличит прибыль бизнеса на четверть.

Что может пойти не так:

• В какой-то момент система выходит на пик производительности, и любые изменения, хорошие или плохие, будут выводить ее из равновесия. Это заблокирует появление новой функциональности.
• Легко разменять всю волю на статистику и перестать принимать решения вообще. Продукт превратится в черный ящик, который будет как-то работать, но никто не будет понимать, как. Такую штуку непонятно, как развивать или чинить.

Как с этим бороться:

• Пересматривайте аксиоматику метрик и помните, что их трактовка субъективна (сессия стала короче, потому что сразу нашли нужное или что-то людей отпугивает?). Некоторые метрики приходят в норму спустя месяц или два (у людей формируется новая привычка) — это бесполезно предсказывать, но если вдруг нужна будет надежда.
• Если новая функциональность роняет метрику, надо найти изменение, которое эту метрику вернет на место. Полезно иметь в рукаве козыри, которые ранее в эксперименте эту метрику поднимали — просто не торопитесь сливать такие находки в релиз.
• Если релиз слишком радикальный и роняет все метрики, то оставьте одну-две, которые вы ронять не в праве (для них смотри пункт выше), а для остальных установите новую норму, которая возникнет с релизом.

Теоретически эксперимент может проверять что угодно, вплоть до теплоты оттенка серого — однако я бы ограничился перебором компонентов и их параметров. Выше я уже разбирал последствия ситуации «системное решение против показаний эксперимента». Помимо того, раз компоненты экономят когнитивные усилия дизайнера, фокусируя его на решении задачи бизнеса, — почему бы схожим образом не ускорить проверку гипотез?

Давайте разберем пример. Есть случай А — это текущая версия продукта, у которой обнаружили проблему: люди часто не находят кнопки с действиями (не доматывают, потому что не ожидают увидеть их в конце списка), поэтому заваливают техподдержку одними и теми же вопросами.

В рамках системы компонентов можно предложить гипотезу B — прибитые к низу кнопки, одна из которых раскрывает полный список действий. Но бывает велик соблазн пойти по пути С — утрамбовать всё настолько, чтобы в первый экран влезли нужные кнопки.

Почему так происходит: вариант С «дешевле» проверить в условиях отсутствия интерфейсного конструктора, он не подразумевает разработку новой функциональности (прибитые к низу кнопки, выпадающий список, рисование новых иконок и т. п.) — это просто «поправить отступы». И может так случиться, что ни B, ни С не решат проблему, нужна будет иная гипотеза — в таком случае функциональность для B делали как будто зря, а пару строк кода для С и не жалко.

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

Еще важный момент. Компонент собирает в себе знания об интерфейсной модели, в том числе ее UX-характеристики: удобство для нажатия пальцем, предсказуемость поведения и прочее accessibility. И когда тот позволяет менять себя через входные параметры, он гарантирует, что любая конфигурация покрыта тестами и беспокоиться не о чем. И даже если вскроется новый непроверенный случай, его учтут, и дополненное знание распространится с компонентом по всем контекстам использования. Так вот, эксперименты типа С делают накапливание этих знаний бессмысленной затеей — следовательно, бьют по качеству продукта.

UX-исследования помогают понять, почему что-то пошло не так — ведь числа всегда молчат. Как примерно устроен процесс:

• Составляется сценарий, по которому будут вести человека (поиск книги, покупка авиабилета). Сценарий часто включает список вопросов, взывающих к рефлексии испытуемого: почему вы сделали именно этот выбор, почему вы проигнорировали рекомендацию?
• Набирается репрезентативная группа респондентов: от пяти до восьми человек. Репрезентативная — равномерно покрывающая типажи целевой аудитории продукта. При этом наблюдается закономерность: после пятого человека остальные начинают повторяться. Людей ищут в соцсетях, рассылками или предлагают заполнить анкету на будущее.
• По одному каждого из приглашенных проводят по сценарию, происходящее на экране и в комнате полезно записывать — классический формат скринкаста.
• Позже собранные материалы отсматривают и составляют отчет.

На что обращается внимание:

• Сценарий должен быть у всех респондентов одинаковый, иначе не получить сравнимых результатов.
• С респондентом должно общаться лицо незаинтересованное, не желающее склонить его к определенному выбору.
• Выводы делаются только по записям, а не во время исполнения сценария. Так сохраняется холодный ум и позиция стороннего наблюдателя.
• Избегайте наводящих вопросов: ничего странного не заметили? быть может надо поискать там-то? — человек изменит свое естественное поведение и переключится в режим ожидания ваших инструкций и подсказок.

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

Для UX-исследований я вижу два основных применения:

• Ранняя проверка гипотез.
• Анализ найденной в эксперименте проблемы.

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

Как UX-исследования берегут ресурсы: раннюю проверку гипотез можно проводить еще до разработки, на прототипах; анализ проблем эксперимента можно проводить до разработки следующего эксперимента.

Как UX-исследования вправляют мозги, рассказал однажды Олег Левчук — мы работали вместе в тот период.

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

• Накопившиеся со временем различия в интерфейсе будут относить к возможным катализаторам иного поведения у людей.
• Отсматривать отчеты и видеозаписи чужих исследований — не самое интересное в мире занятие.
• Разметить или проиндексировать исследования для быстрого поиска нужного фрагмента записи или отчета — задача нетривиальная.

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

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

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

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

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

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

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

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

Мой алгоритм действий:

1. Я заранее публикую спецификацию компонентов с матрицами состояний в общий доступ. Кто-то использует Zeppelin, мне пока удобнее связка GitHub Pages и Sketch Measure — приходится больше делать руками, но зато контролируешь ситуацию, и не нужно покупать всем лицензии. Надеюсь, когда-нибудь все переедет в Sketch Cloud. Главное — иметь стабильную ссылку на эталонные компоненты, чтобы все в любом споре могли к ней обратиться.
2. Если команда новая, нужно хотя бы раз объяснить ребятам на общей встрече, что всё у вас не просто так, что есть конструктор, есть модульная сетка, типографика и палитра. Показать, как эти принципы применяются на практике, собрать-разобрать пару экранов у всех на глазах. Важно показать, что ваш дизайн вычислим, состоит из модулей, пропорций, из конечного набора цветов, блоков и состояний; и что все эти концепции переносимы в их среду. Еще замечал невысказанные опасения разработчиков о том, что завтра дизайнеры все поменяют — здесь стоит и себе, и им пообещать, что революций не будет; а будут согласованные и постепенные изменения.
3. В дальнейшем почти в каждой задаче на разработку я прилагаю такую стопку материалов:

• Ссылка на спецификацию всех компонентов.
• Ссылка на спецификацию экранов для задачи.
• Ссылка на прототип в Sketch Cloud или видеоролик из Flinto.
• PDF со всеми экранами наглядной простыней — важно, чтобы у разработчика сложилась в голове та же топология экранов, что и у дизайнера.

Хотя бы раз в квартал стоит собираться вместе, проводить ретроспективы, интересоваться судьбой и структурой компонентов в среде разработчиков.

Если вас часто отвлекают уточняющими вопросами — лучше не строить стены — значит, от вас изначально исходит недостаточное количество информации.

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

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

Mapbox API и JS творят чудеса — к извечному вопросу о том, что должен или не должен уметь дизайнер. В пределе дизайнер, автор модели, должен выступать заказчиком технологии, как архитектор или конструктор. Но это тема для другого разговора.

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

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