Блог Михаила Озорнина: заметки с тегом гайдлайны

Как выглядит хороший макет

Михаил Озорнин — Tue, 11 May 2021 10:19:02 +0300

В продолжении тредов Романа Шамина про дружбу дизайнеров и фронтендеров решил вытащить в блог одну из статей наших гайдов — про то, что такое «хорошо переданный макет». Все вытащенные из гайдов статьи доступны по тегу гайдлайны.

Треды Романа Шамина:
teletype.in/@romanshamin/what-design-want-from-frontend
teletype.in/@romanshamin/what-frontend-want-from-design

Дальше привожу статью из наших командных договоренностей.

О чем эта статья

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

Эта статья описывает как хорошо передать макет в разработку.

Хранение и состав макетов

Список самих экранов

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

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

Договоренности команды о процессе выкладывания макетов записаны.

При обновлении макетов уведомляется проектная команда (аналитик, фронтенд, тех. писатель, QA).

Состав экранов

Уровень «Минимально достаточный»
Для фичи понятен набор экранов, на которые вносятся изменения: какие экраны новые, какие экраны дорабатываются.

Если экранов несколько, то понятны переходы между экранами.

Уровень «Хорошо»
Доступна актуальная схема экранов продукта (карта сайта).

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

Экраны

Структура экранов

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

Как ведут себя блоки экрана при прокрутке и ресайзе.

Уровень «Хорошо»
У продукта есть понятная сетка, описаны типовые лейауты страниц: список, дашборд, форма редактирования, страница просмотра и т. д.

Элементы на странице

Уровень «Минимально достаточный»
По каждому визуальному элементу на макете понятно, что это такое: текст, компонент, иконка, паттерн.

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

Понятны размеры элемента, его взаимоотношения с соседними элементами.

Понятно как элемент тянется, что будет, если в элементе будет меньше или больше контента.

Уровень «Хорошо»
Все элементы описаны, разработчик знает где искать документацию на каждый используемый тип элемента: текст, компонент, иконку, паттерн.

Размеры элементов и отступы между элементами логичны, ожидаемы и понятны.

Примеры:

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

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

Хорошо: Размеры блоков понятны

Хорошо: Размеры блоков понятны, блоки расположены предсказуемо по сетке

Кегли

Уровень «Минимально достаточный»
Для каждого текста на странице понятен стиль или mixin, который нужно взять, эти стили и mixin’ы однозначно определяются из самого макета.

Эти mixin’ы не противоречат компонентам, паттернам или аналогичным элементам других экранов продуктов.

Уровень «Хорошо»
Есть актуальная таблица миксинов, описаны общие принципы их использования.

Примеры:

Плохо: Кегль не замапплен, неясно какой типографический миксин взять

Хорошо: Кегль и цвет замапплен, понятно что указать

Цвета

Речь идет про цвет любого интерфейсного элемента: текста, иконки, рамки, фона, блока, линии.

Уровень «Минимально достаточный»
Не используются цвета не из палитры проекта.

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

Уровень «Хорошо»
Составлена таблица цветовых токенов: default text, disabled text, error icon для всех используемых в проекте тем.

В макетах прилинкованы цвета из этой таблицы (не error-500, а validation-text-color).

Примеры:

Плохо: Цвета не замаплены, неясно какой цвет выбирать

Хорошо: Цвета замаплены, понятно что указать

Отступы

Уровень «Минимально достаточный»
Понятны сами отступы между всеми блоками на странице и их внутренняя логика.

Отступы на макете не противоречат компонентам (например, в компоненте «кнопка» отступы 6 16, а на макете 6 12).

Уровень «Хорошо»
Описана интерфейсная микросетка и описание модулей.

Логика отступов описана, есть типовые отступы и их завязка на сетку.

Пиктограммы

Уровень «Минимально достаточный»
Разработчик знает, как вообще подключаются пиктограммы в проект.

Понятно, что это за конкретная пиктограмма, как ее подключить и вставить.

Уровень «Хорошо»
Есть общий список пиктограмм, их коды, параметры вставки в код продукта и документацию.

Иконки версионируются, к продукту или в документацию можно подключить нужную версию пакета иконок.

Примеры:

Плохо: Иконка не замаплена, нужно искать её в наборе самостоятельно

Хорошо: Указано какая иконка и из какого набора. Примечание: mc — префикс одного из наших наборов иконок.

Текст

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

Уровень «Минимально достаточный»
Рыба в макете правильная с точки зрения состояний, смысла и точная с точки зрения чисел и значений.

Нет никаких Значение-1, Значение-2, Значение-3 и Лорем ипсумов.

Из текста понятно, о чем он: это важно, чтобы техписатели могли его понять и улучшить.

Уровень «Хорошо»
Текст в состоянии production-не стыдно, техписатели только полируют его.

Состояния

Другие состояния

Уровень «Минимально достаточный»
Понятно, как сделать все остальные состояния: переключенные вкладки, переключатели, чекбоксы и радиокнопки (если они влияют на компоновку интерфейса).

Отрисованы или описаны (если этого достаточно) все варианты дропдаунов, селектов и других выпадаек.

Кроме самих этих состояний описаны переходы между ними.

Уровень «Хорошо»
Если блоки меняются значительно, то лучше не пытаться описать отдельные выпадайки, а нарисовать блоки целиком, чтобы было меньше путаницы

Пример:

Хорошо: Нарисованы альтернативные состояний экрана

Загрузка

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

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

Пустое состояние

Уровень «Минимально достаточный»
Понятно, как выглядит пустое состояние всех блоков и элементов, когда в них нет данных.

Уровень «Хорошо»
Пустые состояния систематизированы, используются типовые решения.

Пример:

Валидация

См. Валидация данных

Уровень «Минимально достаточный»
Понятно, когда и как срабатывает валидация.

Как и когда показывается.

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

Уровень «Хорошо»
Валидация соответствует общему гайдлайну.

Валидация способствует не попаданию с ситуацию срабатывания валидации.

Много данных

Уровень «Минимально достаточный»
Понятно как работает экран, когда во всех потенциальных местах (текст, списки, таблицы) будет много данных.

Все вытащенные из гайдов статьи доступны по тегу гайдлайны.

См. также

Гайд Контура: guides.kontur.ru/principles/layouts/
Чек-лист Prit4er1: notion.so/5c03c7554ff542da9c77a6f420935282

Как писать дату и время в интерфейсах

Михаил Озорнин — Thu, 28 Jun 2018 02:24:02 +0300

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

Общие правила

В интерфейсе:

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

В бумажных отчетах:

год допустимо указывать даже тогда, когда он совпадает с текущим.

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

1 Абсолютные даты

1.1 Полный + время

Русский	English
1 ноября, 12:25	November 1, 12:25
1 ноября 2014, 12:25	November 1, 2014, 12:25

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

1.2 Короткий + время

Русский	English
1 янв, 12:25	Jan 1, 12:25
1 дек 2015, 12:25	Dec 1, 2015, 12:25

1.3 Полный без времени

Русский	English
1 ноября	November 1
1 ноября 2014	November 1, 2014

1.4 Короткий без времени

Русский	English
1 янв	Jan 1
2 ноя 2014	Nov 2, 2014

2 Относительные даты

2.1 Время в прошлом, длинно

Что	Русский	English
< 1 мин	1 секунду назад	1 second ago
	5 секунд назад	5 seconds ago
< 59 мин	1 минуту назад	1 minute ago
	2 минуты назад	2 minutes ago
	5 минут назад	5 minutes ago
Сегодня	16:25	16:25
Вчера	Вчера, 13:25	Yesterday, 13:25
Позавчера и старше	20 декабря, 13:25	December 20, 13:25
Позавчера и старше, если год не совпадает с текущим	20 декабря 2017	December 20, 2017

2.2 Время в прошлом, коротко

Что	Русский	English
< 1 мин	5 с назад	5 s ago
< 59 мин	5 мин назад	5 min ago
Сегодня	16:25	16:25
Вчера	Вчера, 13:25	Yesterday, 13:25
Позавчера и старше	20 дек, 13:25	Dec 20, 13:25
Позавчера и старше, если год не совпадает с текущим	20 дек 2017	Dec 20, 2017

3 Диапазоны дат

В русском: если обе даты без пробелов, то среднее тире (–) без пробелов, если внутри даты есть пробелы, то между датами  —  (длинное тире отбитое тонкими пробелами). Если вы не используете среднее тире, то замените его на длинное.

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

3.1 Полный со временем

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

Русский	English
С 1 ноября, 12:25 по 5 ноября, 13:35	From November 1, 12:25 to November 5, 13:35
С 1 ноября 2014, 12:25 по 12 мая, 13:35	From November 1, 2014, 12:25 to May 12, 13:35
С 1 ноября 2013, 12:25 по 12 мая 2014, 13:35	From November 1, 2013, 12:25 to May 12, 2014, 13:35
Когда один и тот же день:
1 ноября, с 12:25 по 13:35	November 1, from 12:25 to 13:35
1 ноября 2014, с 12:25 по 13:35	November 1, 2014, from 12:25 to 13:35

3.2 Средний (с тире) со временем

Отличие от 3.1: этот лучше использовать в таблицах и аналогичных конструкциях.

Русский	English
1 ноября, 12:25 — 5 ноября, 13:35 ( — )	November 1, 12:25 — November 5, 13:35 ( – )
1 ноября 2014, 12:25 — 12 мая, 13:35 ( — )	November 1, 2014, 12:25 — May 12, 13:35 ( – )
1 ноября 2013, 12:25 — 12 мая 2014, 13:35 ( — )	November 1, 2013, 12:25 — May 12, 2014, 13:35 ( – )
Когда одна дата:
12:25—13:35, 1 ноября (12:25–13:35)	12:25—13:35, November 1
12:25—13:35, 1 ноября 2014 (12:25–13:35)	12:25—13:35, November 1, 2014

3.3 Короткий со временем

Русский	English
1 янв, 12:25 — 5 ноя, 13:35 ( — )	Jan 1, 12:25 — Nov 5, 13:35 ( – )
1 дек 2015, 12:25 — 3 янв, 13:35 ( — )	Dec 1, 2015, 12:25 — Jan 3, 13:35 ( – )
Когда одна дата:
12:25—13:35, 1 ноя (12:25–13:35)	12:25—13:35, Nov 1
12:25—13:35, 1 ноя 2014 (12:25–13:35)	12:25—13:35, Nov 1, 2014

3.4 Полный без времени

Русский	English
В одном месяце
1—5 ноября (1–5)	November 1—5 (1–5)
1—5 ноября 2014 (1–5)	November 1—5, 2014 (1–5)
В разных месяцах
1 ноября — 12 декабря ( — )	November 1 — December 12 ( – )
1 ноября 2014 — 12 января ( — )	November 1, 2014 — January 12 ( – )
1 ноября 2013 — 12 января 2014 ( — )	November 1, 2013 — January 12, 2014 ( – )

3.5 Короткий без времени

Русский	English
1 янв — 2 июня ( — )	Jan 1 — Jun 2 ( – )
2 ноя 2014 — 12 дек ( — )	Nov 2, 2014 — Dec 12 ( – )
2 ноя 2014 — 12 дек 2014 ( — )	Nov 2, 2014 — Dec 12, 2014 ( – )

4 Длительность

Как делают другие:

Кто	Что советует	Где
Гугл	0:30, 1:01:05	https://material.io/design/communication/data-formats.html#date-time
Атлассиан	—	https://atlassian.design/server/patterns/date-formats/
САП	—	https://experience.sap.com/fiori-design-web/formatting-dates/

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

4.1 Цифрами

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

Стоит помнить, что 1 секунда и 1,0 секунда — не одно и то же, нельзя их путать.

С секундами	Только минуты
0:12,256		Ведущий 0: для минут обязателен
0:12		Ведущий 0: для минут обязателен
2:25	0:02	Для варианта Только минуты ведущий 0: для часов обязателен
25:25	0:25	В этом и ниже миллисекунды скорей всего не нужны, если речь идет не о спортивных соревнованиях
25:00	0:25
2:25:25	2:25
21:25:25	21:25
1:02:25:25	1:02:25	Только минуты в этом случае смотрится особенно неудачно
48:25:25	48:25

4.2 Буквами полный

Все числа округляются до целых. Написать 25 минут и 25,5 секунд — нельзя.

Русский	English
—	—	Если хотите миллисекунды, см. 4.1
12 секунд	12 seconds
2 минуты и 25 секунд	2 minutes 25 seconds
25 минут и 25 секунд	25 minutes 25 seconds
25 минут	25 minutes	Обратите внимание, здесь не написаны секунды, так и надо
2 часа и 25 минут	2 hours 25 minutes
21 час и 25 минут	21 hours 25 minutes
1 день и 2 часа	1 day 2 hours
48 часов и 25 минут	48 hours 25 minutes
10 дней	10 days
2 недели и 5 дней	2 weeks 5 days	Если нужно понедельное деление
6,5 месяцев	6.5 months

4.3 Буквами короткий

Русский	English
12,256 с	12.256 s
12 с	12 s
2 мин 25 с	2 min 25 s
25 мин 25 с	25 min 25 s
25 мин	25 min	Обратите внимание, здесь не написаны секунды, так и надо
2 ч 25 мин	2 h 25 min
21 ч 25 мин	21 h 25 min
1 д 2 ч	1 d 2 h
48 ч 25 мин	48 h 25 min
10 д	10 d
2 нед 5 д	2 w 5 d	Если нужно понедельное деление
6,5 мес	6.5 mo

С десятичной дробью — лучше не надо

С десятичной дробью можно писать только месяцы и годы и только с округлением до половины. Минуты, часы, дни и недели нельзя даже с округлением до половины. В таком виде сложно понять, сколько это, если дробная часть не 0,5.

Лучше не использовать ~~зачеркнутые~~ варианты.

Десятичная	Сколько это на самом деле
~~3,10 часа~~	3:06
~~3,20 часа~~	3:12
~~3,25 часа~~	3:15
~~3,30 часа~~	3:18
~~3,33 часа~~	3:20
~~3,40 часа~~	3:24
~~3,50 часа~~	3:30
~~3,60 часа~~	3:36
~~3,67 часа~~	3:40
~~3,70 часа~~	3:42
~~3,80 часа~~	3:48
~~3,90 часа~~	3:54
3,5 года
~~3,8 года~~	3 года, 9 месяцев и около 22 дней
~~3,2 месяца~~	3 месяца и около 6 дней

5 Выбор периода показа чего-нибудь

5.1. Говорите по-человечески

Неделя лучше 7 дней, месяц лучше 30 дней, это более по-человечески. С этим есть проблема: месяц менее однозначно, чем 30 дней, вариант 30 дней безопасней. Если вы уверены (например, проверили), что у вас разногласия нет, или что оно допустимо, то месяц, лучше последние 30 дней.

Пример: Яндекс в достаточно строгом продукте Яндекс.Метрика использует неделю и месяц. Они точно тестировали разные формулировки и сделали так:

Можно Яндексу, можно и вам

5.2 Пишите «дней», а не «суток»

Всегда вместо суток употреблять дней. Так тоже более человечно, в жизни не говорят позвоню через трое суток, говорят позвоню через три дня. Фразу последние 7 дней нельзя понять иначе как последние 7 суток. Никто не поймет её как последние 7 суток за вычетом последних 7 ночных периодов.

5.3 Будьте последовательны

Хорошо: Неделя, Месяц, Квартал
Хорошо: Последние 7 дней, 30 дней, 90 дней
Плохо: Неделя, 30 дней, Квартал.

Примечание
90 дней и кварталы могут быть вместе и использоваться в разных частях системы одновременно. Если кому-то нужна поквартальная отчетность, должны быть точно кварталы. 1 квартал, 2 квартал, Q1, Q2, и так далее.

5.4 Используйте адекватные величины

Используйте те величины, какими бы назвали этот период в жизни. Вместо 48 часов лучше 2 дня, вместо 3600 секунд — 1 час, вместо 1440 минут — 1 день. 24 часа, 60 минут — норм. Могут быть исключения, но обычно так.

5.5 Не делайте слишком много

Это искусственный макет, так не надо:

Вот тут ↑ перебор вариантов. Такое количество пунктов сложно сверстать, из него непросто выбрать (с учетом того, они почти все одинаковые по тексту).

Что делать, если пунктов много:

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

5.6 Не дублируйте везде «последние»

И Мильчин, и другие люди советуют не дублировать в списках одинаковое начало.

5.7 Итого

Кажется, что выбирать надо из следующих вариантов (использовать все не надо):
секунды: 1, 5, 10, 15, 30, 60
минуты: 1, 5, 10, 15, 30, 60
часы: 1, 2, 4, 6, 8, 12, 24
дни: 1, 5, 7, 10, 14, 15, 30, 90, 180
недели: 1, 2, 4
месяцы: 1, 2, 3, 6, 12
лет: 1, 2, 5, 10

Если вашего интервала тут нет, может он и не очень осмысленен? Наличие в интерфейсе интервалов последние 5 часов, 18 минут, 13 дней, — вызывает вопросы. Такое может быть из-за особой специфики (например 5-часовые смены операторов), но обычно такого не должно быть.

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

Проще один раз отладить и сделать эталонную реализацию.

Подобные посты отмечены тегом гайдлайны

Как делать подписи для таймсерий

Михаил Озорнин — Mon, 04 Jun 2018 02:21:35 +0300

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

В чем проблема

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

Библиотека отрисовки почему-то решила не подписывать даты и подписала только время. На самом деле пеньки 3:00 21 мая, 15:00 23 мая, 3:00 26 мая, 15:00 28 мая, 3:00 31 мая, 15:00 2 июня. Понять это из подписей почти невозможно.

Я перерисую скриншот, чтобы можно было менять и иллюстрировать:

Первое, что нужно сделать — всегда писать даты:

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

Пурпурные линии — границы дней

В посте я расскажу что с этим всем делать.

Общие правила

Подписи отметок соотносятся с масштабом. При показе данных за год показывать время с точностью до минут не имеет смысла.
Всегда выбирается максимально детальный разумный масштаб. Если без проблем указывается с точностью до дней, то не надо укрупнять отметки до 5-дневных просто так.
Отметки должны быть регулярны. Разный шаг не позволит удобно прикинуть промежуточное значение. Если регулярные метки не получаются, то основную часть отметок лучше сделать регулярными, а нерегулярные остатки сложить к одному из концов интервала.
Смысловые отметки лучше несмысловых. Отметка 22:12 — странно, 22:30 — норм. Вряд ли имеет смысл использовать что-то, не попадающее в этот список:
1, 5, 10, 15, 30 секунд,
1, 5, 10, 15, 30 минут,
1, 2, 4, 6, 12, 24 часов,
1, 2, 5, 10, 15 дней,
1, 2 недели (если нужны именно календарные недели),
1, 2, 3, 6 месяцев,
1, 2 года, 5, 10 лет.
Дробными числами, не подходящими под указанные выше, допустимо подписывать только начало и конец.

Информативность

Дублировать одно и то же — плохо. Не надо писать у отметок так: 01.01.2015, 01.02.2015, 01.03.2015, 01.05.2015. Но и 01.01, 01.02, 01.03, 01.05 тоже плохо (см. следующий пункт). Кстати, кто-нибудь заметил, что я пропустил апрель?
Для дат лучше всего использовать формат 1 мая, 2 июня, 13 ноя. Месяцы сокращаются до трех букв без точки (кроме мая, июня и июля), ведущий ноль у числа не пишется.

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

Секунды у времени не пишутся, если не сказано обратного — 22:12. Любое время, кроме полуночи лучше писать без ведущих нулей: 6:25, 9:13, 12:56, но 00:00. Для секунд, там где они нужны, допускается писать только секунды: 10:55, :56, :57, :58, :59, 11:00, :01, :02.

Оформление

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

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

Края интервала

Когда левая и правая границы важны, нужно подписать эти отметки явно. Скорей всего для этого придется убрать подписи у ближайших отметок: отметки 6:00 (между 3:52 и 8:00) и 2:00 (между 00:00 и 3:12) как бы должны быть, но не влезли:

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

Если края не принципиальны, то можно не подписывать оба конца:

Примеры

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

Если применить все рекомендации к примеру из начала поста, то получится как-то так:

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

Как подписывать скриншоты

Михаил Озорнин — Mon, 12 Feb 2018 12:19:47 +0300

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

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

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

Общие правила

Про оформление подписей есть бюрошный совет: bureau.ru/bb/soviet/20140728. В нем Артём рассказывает о роли подписей, о том, как их ставить и как рисовать выноски. Подписчики учебника «Типографика и верстка» могут дополнительно посмотреть разворот 71.

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

Прием 1: УВЛ (убрать все лишнее)

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

Слово button встречается 12 раз и все они используются, чтобы сказать «это — кнопка». Вообщем почти все элементы на этом скриншоте — кнопки, поэтому button безболезненно убирается:

Прием 2: вынести общее за скобки

Иногда от повторений нельзя избавиться совсем. В примере ниже повторяется не просто button, а filter button.

Убрать button можно, а вот от filter избавиться нельзя. Если убрать слово filter, то потеряется важный смысл. При этом filter button относится ко всем четырем действиям, все они — действия над сохраненными фильтрами. Нет необходимости писать про сохраненные фильтры 4 раза, можно написать один раз и больше не повторяться.

Например, так:

Фактически мы вынесли filter button за скобки, как в математическом выражении.

Прием 3: соблюдать теории близости

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

Прием 4: использовать естественное соответствие

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

На этом куске скриншота все 4 иконки стоят ровно в ряд с одинаковыми отступами:

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

Прием 5: выравнивать текст осмысленно

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

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

За выравниваем всегда следят на транспортных схемах: правильное расположение названия станции помогает понять, где какая станция. Посмотрите, например, линейные схемы Московского метро: artlebedev.ru/metro/line-map.

Прием 6: убрать «почти, но не совсем»

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

Посмотрим на картинку:

Здесь много почти, но не совсем, всего 6 видов разного выравнивания:

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

Ещё примеры «почти, но не совсем» в посте Ильи Бирмана.

Прием 7: следить за типографикой

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

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

Про интерлиньяж:
bureau.ru/bb/soviet/20140310/
bureau.ru/bb/soviet/20140310/

Прием 8: редактировать текст

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

Прием 9: рассказывать по частям

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

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

Приемы

Убрать все лишнее
Вынести общее за скобки
Соблюдать теории близости
Использовать естественное соответствие
Выравнивать текст осмысленно
Убрать «почти, но не совсем»
Следить за типографикой
Редактировать текст
Рассказывать по частям

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

Размеры и линейки
Коротко о выносках и подписях — на самом деле не коротко