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

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

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

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

С момента прошлого рассказа со мной произошли две вещи:

1. Я переключился на новые продукты.
2. И делал их параллельно.

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

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

Чем конкретно я занимался последнее время:

• Яндекс.Такси — приложение для водителей, интерфейсы сателлитов.
• Яндекс.Еда — концепция бренда.
• DMS — логистика грузоперевозок.
• Emex — экосистема инструментов вокруг рынка автозапчастей.

Пункты прилично разнесены: у каждого своя технология (android, ios, веб), свой контекст использования (устройство на столе, устройство в руке, устройство на панели автомобиля), своя аудитория (водители, курьеры, диспетчеры, аналитики, руководители бизнесов и голодные люди). Застал я каждый продукт на разных стадиях развития: Такси уже работало на высоких оборотах, DMS пробовал запуститься, а Emex перерождался. У каждого была своя команда: это люди не из разных этажей одной организации, а из разных индустрий (читайте, планет).

Обо что сразу бьешься лбом: ценности, процессы и технологии у вас совершенно разные. К этому я мог сколько угодно готовиться, но пока не окунулся, сложно было воспринимать себя иначе, чем «дизайнер из команды Яндекс.Поиска»: у тебя в голове веб-технологии с их возможностями и проблемами, n-мерное пространство экспериментов, закон больших чисел, пробирки с оттенками синего и так далее. У других: «Учти, что на четверке тени не работают», «Высота строки не настраивается», «Давай раскатим и отзывы почитаем», «Что такое сетки? У нас есть лейауты — это оно?», «Вот зачем ты нагородил своих окон — смотри, какой есть jquery-плагин».

Так возникла интересная задача: ранее я декомпозировал интерфейсы, а как декомпозировать собственный опыт? Как отделить находки методологические от технологических, образные от графических? Разные проекты нуждаются в подмножестве моих экспертиз, и мне отводится определенная роль. Кроме того, возникает риск стать вечным евангелистом единственной конфигурации (графического стиля, инфраструктуры — не важно), а это остановит и развитие, и cпрос.

В своей работе я увидел три пласта:

1. Образ
2. Модель
3. Технология

Что я подразумеваю под этими тремя пластами на примере своих записей:

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

Образы

Читаем «Карту Птолемея» Герца Франка:

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

«Статьи, дневники, замыслы» документалиста Вертова:

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

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

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

• Какую пропорцию отступов сделать
• В какой цвет покрасить основные кнопки
• Какую иллюстрацию заказать у подрядчика
• Каким тоном сообщить об ошибке ввода
• Как кадрировать снимок для баннера
• …

И не я один принимаю решения: почти всегда есть другие дизайнеры. А результат после длинной череды микрорешений должен получится цельным и производить нужное и однозначное впечатление.

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

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

А правда, проверьте себя и коллег, поинтересуйтесь любой мелочью в своем продукте: почему кнопка синяя? почему заголовок капсом? почему все такое округлое? почему мы с человеком на ты?

— А вопросы уже можно задавать?

— Пожалуйста.

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

— А на какой стадии ваш бизнес?

— Ну вот мы запустились и уверенно растем.

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

— Если я объясню всем, почему кнопки синие, я сохраню контроль?

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

— А что с первой задачей?

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

Как я воспитывал в себе привычку поиска и анализа образов:

• Mike Hill (видеоканал)
• Nerdwriter1 (видеоканал)
• Every Frame a Painting (видеоканал)
• Старые WWDC с Джобсом: 1997, 2002, 2010
• Ануар (видеоканал)
• Арзамас: Я так вижу (подкаст)
• Арзамас: Как понимать живопись XIX века (видеолекции)
• Петрик (статьи)
• artlebedev/закулисы (статьи)
• Карта Птолемея (книга)
• О языке композиции (книга)

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

• DOOM: Behind the Music
• RA: Burial’s Untrue
• The mad science behind inside’s soundtrack
• The Most Disturbing Painting

Но анализ найденных образов позволяет с минимальными потерями перенести их в инженерию и построить модель.

Почему я говорю «поиск и создание образов», почему не просто поиск? Этим, на мой взгляд, отличаются документальные и художественные продукты: первые «проникают в природу за образными открытиями», вторые эти образные открытия компилируют из контекста и переживаний (кстати, compilatio с лат. — кража).

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

• Даже для логотипа неплохо иметь стопку примеров использования; логотип при этом могут взять, а примеры использования — нет.
• Полезно бежать впреди паровоза, перебирать концепции, показывать команде разные варианты будущего.
• У меня есть фетиш: не всегда делать только то, о чем попросили; или делать то, о чем не просили вовсе. Так веселее.
• Ну и, конечно, технологические компромиссы, устранение которых — отдельная работа.

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

Образы для Яндекс.Еды

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

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

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

1. Живет ли знак в среде бренда? Или это наклейка в углу?Хотелось не выдумывать знак, а найти, рассмотреть: наблюдая за работой курьеров, за прилавками с едой, за посетителями в кафе. Не новую форму, а что-то, что лежит перед носом, но ты упорно это игнорируешь. Чтобы простой и очевидный знак рифмовался с простым названием сервиса.

2. Нет ли перекоса в ту или иную метафору? Яндекс.Еда будет взаимодействовать со всеми кухнями и продуктами: если знак будет слишком десертным или слишком «восточным» или слишком фастфудным, это может усложнить дистрибуцию бренда на все ниши.

3. Как много производных образов даёт знак? Если на старте в голову лезет не одна и не две ассоциации, то и дальше будет не сложно придумывать.

4. Оставляет ли знак продукту запасы по ходам? Хорошо, когда есть возможность делать разную рекламу каждый сезон, где знак играет новую роль, сохраняя ассоциацию с брендом.

В общем, проникаю в природу с художественной целью (пункт 1 в моих рассуждениях выше):

И вынимаю оттуда образ спирали:

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

Покрытие по кухням (пункт 2):

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

Буква «Е», диффузия и тарелка (далее пункты 3 и 4). Продолжаю игру с образом тарелки:

Перебираю разные жанры картинок, на которых фигурирует тарелка, бросаю поверх спираль и смотрю:

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

Одну из них снимем в ролике и заберем в интерфейс:

Про диффузию еще такой прием нашелся:

И осталась буква «Е». Но тут я сделаю небольшое отступление про логотипы вообще:

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

Либо со знаками и подписями, разнесенными по опорным точкам макета:

Поэтому, е-спираль я ставлю внутрь «Яндекс.Еды», вместо точки:

Конечно, это не исключает использование знака и без логотипного шрифта

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

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

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

Видео и фото. Тут я работал в паре с Тарасом Шаровым (далее просто Тарас) — он у нас большой любитель поснимать. Говорю ему: «Собралась у меня такая вот концепция, давай попробуем поснимать?» И сразу полезли вопросы: что, как и для каких контекстов? Это просто еда, еда и руки, еда и люди, просто довольные сытые люди? Образная концепция требовала развития, и я пошел искать референсы.

Из замученной спирали ответов на эти вопросы не вытянешь, но я запомнил раскиданные кадры с тарелкой и людьми:

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

Покопался в пинтересте, там нашелся король жанра — Юрген Теллер. Это помогло лучше понять правила игры: пленка, вспышка, нарочито неправильные углы съемки, псевдослучайное кадрирование и смакование деталей.

Но мы не стремились в точности воспроизвести референсы — они скорее давали вектор, показывали, как ещё бывает. От вспышки в процессе отказались, от пережаренных контрастов тоже. Тарас мне ещё рассказал про color grading — инстаграм-фильтры для богатых; с помощью них (и не только) режиссеры добиваются узнаваемости фильма в каждом кадре:

Со этим багажом новых знаний и отсылок мы начали искать почерк фотографий Яндекс.Еды.

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

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

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

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

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

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

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

На этом моменте у вас должны возникнуть вопросы:

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

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

Пару слов о цвете (подробнее будет в моделях):

• Раз пришли к теплому тону фотографии, то же самое справедливо для интерфейса: монохромный ряд уводим в теплое.
• Помимо монохрома и основного оранжевого, мне захотелось «второй серый», цвет печенья — gold graphite мы его назвали. Функция этого цвета — создавать субакценты, добавлять глубины картинке (как с полутонами в начертаниях шрифтовых семейств).

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

Отдельно расскажу о языке. Экран оживает в тот момент, когда начинает разговаривать. Вес слова не меньше, чем вся проделанная работа выше — то есть кривыми фразами можно как уничтожить впечатление, так и возвести его в квадрат. Характер продукта, его забота, его образы — во-многом они там же, в языке.

Посмотрите на Яндекс.Драйв. Даже если вы не водите, все равно рекомендую скачать приложение, чтобы ощутить языковой контакт с продуктом. Это забытое чувство. И на всякий случай: я к Драйву отношения не имею, делает его мой друг Рома.

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

Образная концепция, как я и обещал, получила развитие:

— У меня вопрос!

— Самое время.

— Вы всё это показали Яндекс.Еде, и что она?

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

— А в чем вы делали прототипы?

— Flinto.

— А блок-схемы?

— MindNode

Образы для Такси

Сначала давайте разберемся с желтым. Откуда этот мем про желтое такси? Из США, точнее, из Нью-Йорка. В Европе желтого такси не больше чем черного или белого; а то желтое, что есть, выглядит невыразительно: оно то лимонное, то грязное, то с зеленоватым отливом. Статистика подтверждает эти ощущения: существует корпорация PPG, один из мировых лидеров по производству красок и эмалей для всех видов транспорта; у ребят есть открытые данные кто, когда и какую краску заказывает.

Откуда я все это знаю? Это не я, это снова Тарас — у этого человека много неожиданной информации в голове, вроде той, как грамотно себя вести, если начнется зомби-апокалипсис.

Американцы годов с 70-х полюбили стандартизацию всего на свете. Думаю, из-за бума урбанистики и социологии как способов борьбы с накопившимися проблемами мегаполисов; и я, кстати, рад наблюдать подобный процесс сегодня в Москве

Насколько я понял, в 1967 ребята выбрали для такси bold yellow (или цвет очень на него похожий) и красят им до сих пор:

Этот цвет в лучах солнца можно поразглядывать на фотках все той же статьи. Безумно сложный и красивый:

Воспроизвести это в интерфейсе не так-то просто: реальный цвет нестабилен и наша память хранит богатый собирательный образ, а не #FFB000.

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

Мы назвали их Amber и Yellow и из каждого достроили цветовой ряд:

О цветовых рядах в палитре я подробно расскажу в разделе про модели, но вообще это явление обычное для дизайн-фреймворков: те же Material design colors (они, кстати, тоже отличают yellow, amber и orange).

Вот как этот сложный желтый прорастает в интерфейсе Таксометра:

У Amber есть особое свойство — держать форму на мелком масштабе, тогда как обычный желтый не выдерживает никакой критики.

На больших площадях (кнопки, плашки) цвета меняются местами: Amber становится слишком тяжелым и на помощь приходит Yellow.

Эта цветовая пара может смело применяться и дальше, например, в значке Такси:

Таксометр

Это инструмент для водителей такси. Инструмент со сложной судьбой:

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

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

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

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

• Destiny
• GTAV
• MGSV
• Hitman
• Battlefield

Мне можно возразить, мол, а как же мобильные платформы

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

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

Что можно рассмотреть на этих примерах: всё как будто просто служит функции, обосновано исключительно функцией, но отовсюду сочится эмоция. Как? Тут я хочу, чтобы у вас появилась своя версия, и с ней вы продолжили чтение.

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

Так это начало прорастать в интерфейсе Таксометра:

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

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

С иллюстрациями вообще странная история: многие заказчики никак не вырастут из почерка Пикассо.

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

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

И для интерфейса, и для фотографии, и для иллюстрации нужна история, нужны отсылки и образы — только так получится сформулировать исполнителю внятный заказ. Так, с Олей Барановой мы начали рисовать первые картинки для Таксометра. С чего начать? Ну я рассуждал так:

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

Пока что вырисовывались такие вот скетчи из учебника по ОБЖ:

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

Захотелось живого персонажа с неровной прической, эмоцией на лице и чуть менее формальным подходом к цвету. Так у нас нарисовался свой vault guy:

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

А чуть позже эстафету принял иллюстратор Женя Семиряков:

Образы инструментов для бизнеса

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

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

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

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

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

• Родительский бренд (если есть).
• Отличительные черты их бизнеса, уникальная терминология.
• Внутренние ценности компании.

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

Куда приводит терминология: мы с Тарасом работали над логистическим продуктом DMS (delivery management system) — бренда-родителя у него не было, культурного слоя тоже; полезли искать зацепки в самом бизнесе. Этот случай еще был удобен тем, что заказчик решение намеревался распространять — поэтому какой-то характер был нужен. Я делал интерфейсную часть, Тарас возился с брендом и графикой.

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

У ребят был еще один внутренний термин — матрица тарификации 3×3 (три типа грузов, три типа сроков). Их тоже вытаскиваем на холст:

Если соединить геотарифные зоны и матрицу, можно получить такой набор форм:

Кажется, вы замешиваете все подряд до появления ощущения смысла.

— Когда предпосылок нет вообще никаких, их надо создавать.

— Почему бы тогда не взять что-то с потолка?

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

Следом под микроскоп попало название. Вообще так себе название на первый взгляд: три буквы, которые могут значить все что угодно. Обсуждали даже его замену, ничего внятного не родили, потом вспомнили про MTC, SMS, IBM — и как-то успокоились.

Осталось сложить первое, второе и третье:

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

Теперь попробуем вырастить образы из внутренних ценностей бизнеса. Есть такие ребята — Emex. Ничего особенного на первый взгляд, однако, это одна из основных торговых площадок автозапчастями в России. И дело не в этом:

А в этом:

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

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

Так мы увидели, что Emex собран из металлоконструкций, коробок, желтых лент и дотошного учета.

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

Попробуем представить кнопку для таких прагматичных ребят. Она какая? Теплая или холодная? Круглая или прямоугольная? Высокая или приплюснутая?

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

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

Ход со свичами показывает, что Emex живет не в мире черно-белых коробок, а в мире необходимого и достаточного. И, разумеется, я не собирал с ребят мнения о кнопках — им некогда думать о подобной ерунде.

— А в каком виде вы храните все эти рассуждения? Как о них узнают ваши коллеги?

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

— Информация при пересказах не искажается? Не теряются ли объяснения в чатах?

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

Модели

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

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

Модель — это описание в пространстве формального языка.

Конечный продукт дизайна — модель, которая передается технологии для реализации. Качество дизайна — это качество модели. Что определяет качество модели:

1. Имеет ли модель связь с образом.
2. Описана ли модель на формальном языке (соответствует ли модель определению, которое я дал выше).

— Ой, ну нет. Извините, но качество дизайна определяется только тем, решает ли он задачу. Остальное вторично.

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

— В этих диалогах последнее слово всегда за вами. А я вот не согласен.

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

естественного языка (пускай и в обертке спецификаций).

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

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

Второй язык

Будем разбираться как подступиться к формальному описанию дизайн-моделей. Новый термин:

Компонент — изолированные знания об интерфейсной модели.

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

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

Технология добавляет свои ветки:

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

И вот оно, сложноподчиненное воплощение компонента кнопки:

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

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

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

Абстрактные компоненты

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

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

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

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

Например, вот матрица состояний, описывающая кнопку для Emex:

А вот ее производная матрица, кнопка для DMS:

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

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

Словарь абстрактных компонентов

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

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

Кстати, помимо всех состояний, я сразу продумываю обе платформы:

И обе темы, если они предусмотрены в продукте (например, в Таксометре):

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

— А не получится ли в итоге так, что все продукты будут слишком похожи друг на друга? Я уже сейчас, глядя на контролы, вижу много общего.

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

— А вы пробовали ходить совсем в другую сторону? Крупная типографика, менее строгие шрифты, неправильные формы и так далее.

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

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

Но эти вещи не бесплатны: не каждое слово и не каждое состояние элемента или их комбинация будут хорошо смотреться:

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

— И куда же девать все эти модные ходы?

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

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

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

С этим столкнулись не одни мы. Вот другие ребята тоже работают в зрелищном жанре:

Приемы которого ломаются в тех же местах:

Мы сильно отвлеклись, давайте продолжим позже.

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

Абстрактный словарь: Списки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Абстрактный словарь: Навигация

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

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

Для stack-навигации в основном тулбар:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Три типа компонентов

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

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

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

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

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

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

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

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

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

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

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

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

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

Ноумен и феномен

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

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

Как декомпозировать собственный опыт? Как отделить находки методологические от технологических, образные от графических?

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

Давайте сначала поясню, зачем это делать. Любое количество макетов

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

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

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

Модульная сетка

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

Сетка — формализация композиционного решения компонента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типографика

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

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

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

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

Каждое начертание имеет название, намекающее на контекст использования: 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, в них прослеживается рифма и иерархия вообще всех толщин на экране, не только шрифтовых:

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

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

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

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

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

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

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

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

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

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

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

Цветовая палитра

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

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

Работу с цветом (как и любую другую) стоит начинать с поиска образов: 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 задал Эндрю Цукерман, автор концепции изъятия объекта из контекста — можно посмотреть на его работы и сделать вывод, что случайных ходов там нет. И, например, когда надо поместить объект в среду, его туда помещают, и стерильность ахроматического ряда пропадает:

Еще, если понаблюдать за цветопередачей разных моделей айфонов — ребята все время экспериментируют с балансом белого, который влияет на восприятие ахроматического ряда в том числе. В общем, я что сказать пытаюсь: дизайнеры 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%. В такую квоту поместится не более 10 экспериментов. Экспериментам, чтобы избавиться от шума и девиаций, нужно накопить достаточное количество статистических данных — поэтому крутить могут неделями. По дороге могут обнаружить, что счетчик не настроили или в коде нашелся баг, который лишает результаты смысла. Когда эксперимент признан удачным, его ветка должна еще влиться в релизную и ничего там не сломать.

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

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

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

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

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

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

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

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

• Если релиз слишком радикальный и роняет все метрики, то оставьте одну-две, которые вы ронять не в праве (для них см. пункт выше), а для остальных установите новую норму, которая возникнет с релизом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упаковка дизайна

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что же мы нашли?

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

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