Мэтью Стендедж написал о применении неактивных кнопок [English].

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

Например, есть форма с обязательными полями и кнопка отправки формы, которая остаётся неактивной, пока пользователь не заполнит форму.

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

#form #button

Руни Госвами написала, как в Lyft упорядочили использование сегментированных контролов.

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

В Apple определяют Segmented Control как линейный набор из двух или более сегментов, которые работают как взаимоисключающие кнопки. Часто его используют для переключения различных представлений (например, отображение карты в формате схемы, снимков со спутника или гибридном).

В Material Design для навигации есть табы, а сегментированные Toggle Buttons используют для группировки кнопок и не относят к контролам выбора (среди которых только чекбоксы, радиокнопки и переключатели). Кнопки могут не быть взаимоисключающими.

Аудит выявил 14 разных сегментированных контролов в 10 продуктах Lyft. Они различались стилистически и семантически (для навигации и выбора). Компонент дизайн-системы оказался невостребованным из-за недостаточной гибкости.

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

https://ux.pub/kak-my-uluchshili-segmentirovannye-elementy-upravleniya-segmented-control/

Кроме эвристик Якоба Нильсена при создании дизайна можно ориентироваться и на принципы хорошего дизайна Дитера Рамса.

Эрик Дрейк поразмышлял о самом сложном для понимания принципе, о котором Рамс сказал так:

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

Честный дизайн:
— Новая штаб-квартира Vitsoe;
— Кассетная дека Braun C301. Сразу понятны её возможности;
— Раздел пользовательских настроек Google Now. Позволяет управлять работой алгоритмов.

Нечестный:
— Манипуляции антивируса McAfee, направляющие пользователя к продлению лицензии;
— Бесполезные уведомления от приложения Restaurant 2, которые нужны только для привлечения внимания.

#heuristic

Роман Шамин написал, что может сделать дизайнер, чтобы обеспечить 80% доступности экранных интерфейсов. Например:

— Почти всегда полезно иметь раздельные текстовые стили: Paragraph — покрупнее, со свободным интерлиньяжем, для набора текста и чтения; UI — помельче, с плотным интерлиньяжем, для интерфейсных элементов;
— Помните, что Contrast Ratio считается относительно фона, и когда вы помещаете текст на цветную плашку, контрастность снижается;
— Чтобы отделить менее важный текст от основного, вместо сильного изменения цвета или размера комбинируйте умеренное изменение цвета и размера. Также можно использовать курсивное или сжатое (Condensed) начертание;
— Дополняйте выделение элементов в ряду подобных чем-то кроме цвета: начертанием шрифта, контрастным графическим элементом, пиктограммой;
— Применяйте принцип «тексту — собственный этаж». Он может в любой момент занять больше места, чем было в макете, потому что пользователь увеличил шрифт в настройках ОС. Или из-за изменения текста и локализации;
— По возможности откажитесь от усечения текста многоточием или фейдом;
— Передавая разработчикам макеты с нетекстовыми контролами, указывайте, какой глагол экранная читалка должна прочитать незрячим людям для каждой пиктограммы.

https://teletype.in/@romanshamin/a11y-for-designers

Анна Кейли из Nielsen Norman Group написала о листбоксах и раскрывающихся списках: из чего состоят, как работают, когда их лучше использовать.

— Листбокс состоит из контейнера, списка вариантов для выбора, текстовой подписи. Пользователь может выбрать один или несколько вариантов, нажимая на них. Если вариантов много и размер листбокса небольшой, в контейнере может быть прокрутка;
— Типы: 1) С выбором одного варианта; 2) С выбором нескольких вариантов через нажатие Control или Command; 3) С чекбоксами; 4) С двумя контейнерами;
— Вариант с чекбоксами часто встречается в фильтрах интернет-магазинов;
— Вариант с двумя контейнерами иногда можно встретить, например, при настройке состава и порядка столбцов в таблице. Пользователи могут переносить элементы списка из одного контейнера в другой и менять их порядок;
— Листбоксы и раскрывающиеся списки используют, когда места мало, а вариантов для выбора больше 5;
— Листбоксы хорошо подходят для отдельных задач (см. выше) и если надо обратить внимание пользователя на основные варианты для выбора;
— С ними проще взаимодействовать, чем с раскрывающимися списками: часть вариантов можно выбрать сразу, остальные — после прокрутки контейнера. При прокрутке длинного и узкого раскрывающегося списка пользователь может случайно сдвинуть курсор в сторону и закрыть список;
— Минусы: они непривычны пользователям и занимают больше места, чем раскрывающиеся списки.

https://school.usabilitylab.ru/ulblog_8_2368/

Игорь Сидоренко побеседовал с Евгением Яровым из Pragmatica.

— Как учился дизайну? По наитию, в то время доступной информации было мало;
— Стал бы заниматься веб-дизайном сейчас? Да, профессия включает разные аспекты: инженерные решения, творчество, коммуникацию с людьми;
— Как учился бы дизайну сейчас? Теоретические и практические курсы, стажировки, менторы. Надо сочетать теорию с практикой, а также разбираться, кто есть на рынке и какие работы делает, чтобы понять, у кого можно учиться;
— Совет новичкам: если хотите быть дизайнерами, не ждите стажировки, сразу начинайте делать работы;
— Евгений не ждёт от работ новичка проработанного UX, учёта технологических и бизнес-требований. Надо просто показать, что вы достаточное количество раз открывали редактор и можете сделать что-то посвежее, посовременнее, попонятнее, чем есть сейчас. Дальнейшие требования будут зависеть от места, где вы хотите работать;
— Каких соискателей не рассматривает? 1) Когда складывается впечатление, что человек пытается обмануть или просто неадекватно оценивает свои скилы и их стоимость. 2) Когда не видно, что человек действительно решил заниматься дизайном (хотя бы год в теме или проходит интенсивы студии);
— Как оценивать свой рост? Фриланс — самая вредная форма существования, без сообщества сложно оценивать себя. В хорошей студии дизайнера выдавливают наверх новички, либо с ним что-то не так. Есть руководитель, который помогает с развитием;
— Менторы — вариант обучения на мидл-уровне. Арт-директор в студии работает на студию, а не персонально на дизайнера;
— Как найти ментора? Не стоит сразу обсуждать менторство, напишите опытному дизайнеру и попросите созвониться, чтобы показать работы и обсудить, заплатите за время.

https://www.youtube.com/watch?v=mWhDax7ivqI

Сергей Петров поделился системным взглядом на проектирование сложных программных продуктов (на примере программ для сотрудников отделений почтовой связи).

«Часто многие требования на самом деле являются не требованиями, а ограничениями. В чём же отличие? Требования — это чёрный ящик, они ничего не говорят про устройство системы внутри. А любые требования, предъявляемые к тому, как система устроена внутри, ограничивают инженерные и конструкторские решения. Это уже не требования к системе, а требования к подсистемам внутри неё. Такие ограничения надо выявлять, отслеживать и обсуждать, а часто — снимать».

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

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

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

https://habr.com/ru/company/posttech/blog/567170/

Тэмми Чжоу написала о степпере для ввода числовых данных.

Степпер — контрол из 2 сегментов, нажатие на которые с определённым шагом увеличивает или уменьшает число. Аналоги степперов есть в голосовых интерфейсах, например, команда «Сделай громче/тише».

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

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

Рекомендации:
— Значения по умолчанию должны соответствовать тому, что пользователи вводят чаще всего. Например, стоит установить «2» для количества гостей при заказе столика в ресторане;
— Не используйте степпер, если сложно выбрать подходящий шаг. Например, для ввода цен и расстояний;
— Обозначайте чётко, что значением конкретного поля управляет степпер;
— Используйте большие контролы на мобильных и настольных устройствах. Например, на мобильных область нажатия должна быть не менее 1×1 см;
— На мобильных устройствах лучше использовать горизонтальный степпер, на него проще нажимать пальцем;
— Размещайте символы + и − на горизонтальных степперах и стрелки вверх и вниз (шевроны) на вертикальных;
— При необходимости давайте изменить число с помощью текстового поля, поддерживайте нажатие кнопок вверх, вниз, вправо и влево на клавиатуре, а также долгое нажатие на контролы для быстрого и значительного изменения.

[English] https://www.nngroup.com/articles/input-steppers/

Илона Саркисова написала о тупых и умных компонентах.

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

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

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

UI-кит из тупых компонентов сокращает их количество и облегчает работу над дизайном.

https://habr.com/ru/company/epam_systems/blog/519856/

Владимир Бугаев написал о метафорах вырезания и перемещения в Windows и macOS.

— В macOS, в отличие от Windows, нельзя вырезать папку или файл: сочетание клавиш Command+X не работает, в меню нет пункта «Вырезать»;
— Чтобы их переместить, надо файл или папку скопировать и вставить командой Command+Option+V;
— В реальном мире (и macOS) можно вырезать часть текста или изображения и куда-нибудь вставить, но в реальном мире файлы из папок или папки с рабочих столов не вырезают, а просто перемещают. В macOS метафоры вырезания и перемещения разделены;
— Плюс такого подхода: в момент вставки файла можно решить, копировать его или переместить. То есть пользователь сначала берёт файл со стола и потом решает, что с ним делать. В Windows решать надо в самом начале;
— Минус: конечное действие (перемещение) не соответствует изначальной команде (скопировать).

https://vc.ru/design/264550

Эрик Кеннеди написал о формах регистрации и входа.

— По умолчанию размещайте фокус на первом поле формы, но проверяйте, что это не портит опыт пользователям со скринридерами;
— Отображайте сообщение о неправильной электронной почте сразу после перемещения фокуса на другое поле;
— Переводите фокус на поле после клика на текстовую подпись к этому полю;
— Если это законно в вашей стране, не требуйте поставить флаг в чекбокс согласия с юридическими документами;
— На английском не пишите очень похожие Sign up и Sign in для регистрации и входа, используйте синонимы Register, Create account и Log in;
— В нижней части формы входа ставьте ссылку на регистрацию и наоборот, чтобы пользователь легко мог переключиться;
— Вместе с сообщением о неправильном пароле показывайте требования к нему в вашем продукте;
— После неуспешной попытки входа не очищайте поля с почтой и паролем, чтобы пользователь мог быстро их исправить;
— В форме восстановления пароля по умолчанию заполняйте поле с почтой, если пользователь её вводил в форме входа.

https://ux.pub/15-sovetov-dlya-uluchsheniya-ux-form-registratsii-i-vhoda-v-sistemu/

Грэм Фултон написал о жанре простых дизайн-советов: так не делайте, делайте так.

— Таких статей появляется всё больше и больше;
— Обычно дизайнеры всё это и так знают, но заглядывают в эти подборки, чтобы проверить, вдруг они что-то упускают;
— На первый взгляд дизайн-советы выглядят довольно информативными, но часто это базовые приёмы и поверхностные идеи, высосанные из пальца;
— Иногда мнения в них поданы как факты;
— Возможно, формат «Так не делайте, делайте так» берёт начало с дизайн-советов Apple и руководства Material Design, и это лучшие образцы его применения;
— В хороших советах берут проблемы, которые часто встречаются в реальных интерфейсах, помечают их «так не делайте» и показывают, как исправить («делайте так»);
— Кажется, что в советах, высосанных из пальца, берут нормальный интерфейс и делают на его основе антипример;
— Если вы только учитесь, проверяйте, что дизайн-советы написаны дизайнером с опытом и портфолио.

[English] https://prototypr.io/post/are-ui-ux-tips-the-new-clickbait-for-designers✨/

Георгий Тимофеев написал об использовании референсов при проектировании.

— Обращаясь к референсам, можно найти интересные решения и адаптировать их к своей задаче, а также вдохновиться стилями;
— Появляется соблазн слепо скопировать понравившееся решение, не углубляясь в суть своей задачи;
— Например, нужна форма подключения инстаграм-профиля к CRM, чтобы в неё попадали сообщения из директа;
— В референсах запрашивают основную информацию: номер телефона (или имя пользователя) и пароль;
— Особенность CRM — с ней могут работать разные менеджеры с разных IP-адресов, а Инстаграм может блокировать профили, если в них входят с разных IP;
— Чтобы блокировки не произошло, профиль надо подключать через прокси;
— В итоге получится форма из 2 шагов: ввод информации о прокси, подключение инстаграм-профиля.

https://designpub.ru/ddbfe72fda2

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

— Если значение метрики ниже планового, покажите текстовую подсказку, что можно сделать. Здорово, если у рекомендаций будут сложные древа условий, но достаточно подсказать, что проверить или к кому обратиться, чтобы разобраться в ситуации. «Конверсия снизилась на 69,1%. Срочно проверьте посадочную страницу»;
— Добавьте процент выполнения плана, таймер обратного отсчёта и подстегивающие подсказки («Нужно ускоряться»), чтобы пробудить азарт и заставить команду активнее искать в данных ответы на вопросы;
— Не больше 4 визуализаций на одном листе;
— Текст зачастую можно заменить на иконку или изображение;
— Изменение показателей можно обозначать цветом или эмодзи, а не только процентами;
— Выделяйте ключевые показатели, на которые надо обращать внимание в первую очередь;
— Неаккуратная вёрстка, отсутствие логики в цветовой гамме, несоблюдение принципов дизайна может вызвать недоверие к данным.

https://vc.ru/marketing/280512

Гоша Кобалия рассказал о подготовке и проведении глубинного интервью.

— При составлении списка вопросов не стоит учитывать все пожелания стейкхолдеров. Придерживайтесь цели исследования и убирайте лишнее. Иначе получите огромный список вопросов для 3-часовой беседы;
— Обычно интервью длится 40–60 минут. 30 минут закладывают на перерыв между интервью. Не пренебрегайте им, общаться с людьми непросто, особенно, если попался сложный респондент;
— Вопросы тестируйте на коллегах, чтобы найти некорректные или сложные формулировки. Это особенно полезно перед беседой с представителем новой целевой аудитории;
— Установите личный контакт с респондентом, поговорите на общие темы: узнайте как дела, как проходит рабочая неделя и расскажите, что интересного происходит у вас. Кто-то готов перейти к делу сразу, обычно это представители B2B;
— Сразу дайте понять, что ваша задача — пообщаться и узнать про опыт собеседника, а не решать его проблемы. Дизайнерам не рекомендуем представляться дизайнерами;
— Некоторые респонденты приходят за деньгами или просто поговорить. У них нет подходящего опыта, и пользы от них мало. Например, такой респондент может говорить подозрительно спокойно и рационально о том, что обычно бесит других. Нужны квалифицирующие вопросы, чтобы задать в начале интервью и не терять времени;
— Будущее — всегда гипотеза, а релевантную информацию даёт только прошлый и настоящий опыт. Лучше не спрашивайте о будущем, если хотите разобраться в какой-то актуальной проблеме.

https://sense23.com/post/gajd-kak-podgotovitsya-k-glubinnym-intervyu-i-provesti-ih-maksimalno-effektivno

В «Собаке Павловой» написали о подготовке к тестированию профессиональных интерфейсов.

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

https://vc.ru/design/282325

Алита Джойс из Nielsen Norman Group написала о помощи и документации в цифровом продукте.

— Документация должна быть доступной для поиска, ориентированной на пользовательскую задачу, не слишком объёмной, а также содержать список конкретных действий;
— Проактивная помощь предоставляется до того, как пользователь столкнулся с проблемой: онбординг, контекстные подсказки, шаблоны, визарды;
— Реактивная помощь предоставляется, когда пользователь столкнулся с проблемой и пытается её решить: часто задаваемые вопросы, документация, обучающие материалы;
— Они могут служить и для проактивной помощи, но люди редко читают документацию перед использованием продукта;
— Push-подсказки — сообщения, не связанные с текущей пользовательской задачей. Например, оверлеи, появляющиеся при старте работы и рассказывающие о новых функциях;
— Pull-подсказки  — контекстные сообщения, относящиеся к текущей задаче. Могут появляться при наведении курсора на элементы интерфейса или запуске конкретного сценария. Пользователи меньше игнорируют такие подсказки;
— Давайте возможность легко пропускать push-подсказки (закрывать их);
— Размещайте сообщения проактивной помощи где-нибудь ещё. Пользователь может вспомнить о пропущенном сообщении и захотеть его посмотреть потом;
— Помогайте сканировать документацию: разбивайте на части, соблюдайте визуальную иерархию, выделяйте ключевые слова, используйте списки;
— Описывая сложное взаимодействие, в дополнение к тексту записывайте видеоинструкции;
— Выделяйте часто просматриваемые статьи в документации.

#heuristic #support

В Markswebb написали о лучших практиках чекаута в российских интернет-магазинах.

— Определяйте локацию покупателя и заранее предупреждайте об условиях доставки (Связной) и доступности товара в его регионе (антипример — AliExpress);
— Позволяйте заказать отдельные товары и сохранить остальные (Wildberries). Часто клиенты используют корзину как список покупок и экран сравнения — собирают несколько вариантов, а затем заказывают отдельные позиции;
— Организуйте лёгкий вход по номеру телефона и коду (Ozon). Пользователю не надо запоминать параметры входа и совершать лишние действия, импульс к покупке сохраняется;
— Давайте выбрать способ доставки по цене, положению точки выдачи, времени ожидания, дополнительным услугам вроде примерки и возврата (220 Вольт);
— Стимулируйте предоплату по карте, начисляя бонусы (СберМегаМаркет). Это снижает риск неоплаты товара;
— На экране предпросмотра позволяйте изменить способ и место доставки, тип оплаты и получателя (Детский мир);
— Предусмотрите возможность управления заказом уже после оформления и оплаты. Например, в DNS можно заменить самовывоз на платную курьерскую доставку, доплатить и получить заказ удобным способом.

https://vc.ru/trade/282339

Райан Тэн написал о повышении доступности при использовании эмодзи и смайликов.

— Не размещайте в призывах к действию на кнопках одни лишь эмодзи. Например, вместо 👍 пишите Like. Слова всё ещё важны, эмодзи лишь помогают улучшить впечатление;
— Не используйте эмодзи в объёмном тексте. У них есть альтернативный текст, который будут озвучивать скринридеры, и это может помешать восприятию текста;
— По той же причине размещайте эмодзи после призыва к действию и в конце предложения;
— Используйте понятные эмодзи. Например, вместо вулканского салюта 🖖 пишите 👋;
— Не используйте текстовые смайлики. Скринридеры будут читать их как знаки препинания :(
— Проверяйте контрастность эмодзи. Жёлтая рука одинаково хорошо видна на тёмном и светлом фоне.

https://design-glory.com/7081/smajly-i-dostupnost-kak-ih-pravilno-ispolzovat

Таннер Кристенсен написал о ступоре при поиске идеального решения задачи.

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

https://ux.pub/razrabotka-nailuchshego-vozmozhnogo-resheniya/

Тарас Бакусевич написал, как улучшить визуализацию данных.

— Располагайте положительные и отрицательные значения по разные стороны базовой линии диаграммы;
— Гистограмму начинайте с нулевых значений. Усечение приводит к искажению данных;
— Для линейной диаграммы адаптируйте масштаб оси Y, чтобы она не была слишком плоской;
— В линейной диаграмме маркеры, представляющие данные, соединены линиями. Люди могут ошибочно принимать за данные также и эти линии. Если ваши данные и временная шкала провоцируют такое восприятие, используйте вертикальную гистограмму;
— Не используйте сглаженные линейные диаграммы. Они искажают стоящие за ними данные;
— Ограничивайте количество секторов (5–7) на круговой диаграмме. Самые маленькие сегменты можно сгруппировать в «Другое»;
— Вместо легенды наносите метки прямо на диаграмму, но не наносите их на сегменты круговой диаграммы;
— Есть общепринятые способы упорядочить сегменты: 1) Самый большой на 12 часов, остальные в порядке убывания по часовой стрелке; 2) Самый большой на 12 часов, второй по величине после него по часовой стрелке, третий на 11 часов, остальные в порядке убывания по часовой стрелке;
— Не сортируйте данные по алфавиту. Размещайте самые большие значения в начале диаграммы;
— Не используйте тонкие кольцевые диаграммы. Их сложно читать;
— Выберите подходящую цветовую палитру. Типы палитр: 1) Качественная; 2) Последовательная; 3) Дивергентная;
— Старайтесь не поворачивать метки. Возможно, для этого придётся вертикальную гистограмму заменить на горизонтальную;
— Помогайте пользователям исследовать данные, изменяя параметры, тип визуализации, временную шкалу.

#data_visualization