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

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

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

    Ищу одного или двух дизайнеров, которым близки логика, ритм, простота и масштабируемость в дизайне. С опытом работы в векторе (Illustrator), Figma, Photoshop и сборке сайтов на Tilda. Способных осмыслить и адаптировать удачный мировой опыт навигации к локальному контексту.

    Если вам интересно поработать со мной над городской навигацией — пишите в телеграм или на почту.

    Телега @twelvetoeleven
    Почта anv1288@gmail.com

    Школа Бюро

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

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

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

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

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

    Если ты диз и любишь читануть, то вот ссылки:

https://intuition.team/ru/complex-designer
есть и бумажная версия

    Очень уютное вышло чтиво. Ращу в себе мечту однажды написать, сверстать и выпустить такое своё.

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

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

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

По сути, «Белый флаг» — это визуальный комментарий к мета-дискуссии сообщества. Он не предлагает ответа и не навязывает позицию, а лишь подчёркивает главный вопрос ARC Raiders: является ли противостояние между рейдерами неизбежным элементом жанра или осознанным выбором каждого игрока.

Макеты с делал с использованием Sora и Figma

Подписывайтесь на мой телеграм https://t.me/twlvtolvn

https://infinitemac.org/

Обои в их стиле

https://basicappleguy.com/haberdashery/macintoshwallpapers

Кому полезно?

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

С чего начать?

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

«В итоге мы хотим иметь библиотеку иконок, в которой будет порядка 230 компонентов. Их можно будет добавлять из ассетов и менять иконки внутри уже созданных макетов. В паке должны быть иконки с обводкой и залитые. размеры 24×24px и 16×16px.»

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

Определяем пул иконок

Это можно сделать вместе с командой:

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

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

Готовим драфт в Figma

Сначала определимся с размером иконок. Я рекомендую отталкиваться от атома вашей дизайн-системы или используйте стандартные размеры, например 24 или 16px.

Теперь обводка и скругления. Подбирайте в зависимости от используемого в интерфейсе шрифта.

Мы для своего продукта выбрали размер фрейма 20×20px по размеру атома. Скругление определили через тесты с меню, кнопками и другими частями интерфейса.

Определим структуру будущей библиотеки.
IconsProduct\
\Outline20
\Fill20
\Outline16
\Fill16

Назовем fig-файл «IconsProduct» — это заглушка, у вас будет своё. Создадим страницу draft. В ней будем работать все ближайшие дни.Важно сразу её грамотно организовать.

Пиксельная сетка и хинтинг

Сразу можно включить:

ctrl+’ — пиксельная сетка. Если не видите изменений по нажатию — приблизьте на максимум. Должна появиться квадратная сетка.

ctrl+shift+’ — привязываем наши объекты к пиксельной сетке. Так наши фреймы, а главное объекты и контуры будут занимать положения в край или в целый пиксель. Это важно для хинтинга.

Хинтинг — это понятие из шрифта, но относительно иконок я бы сформулировал его так:

Хинтинг (англ. hinting, от hint «намёк, совет») — сглаживание контура при его обработке браузером или устройством с помощью специальных программных инструкций. Обеспечивает чёткое отображения контуров на устройствах с низким разрешением экрана или при отображении в мелком формате.

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

Чтоб увидеть наглядно можете посмотреть и подвигать свою иконку в пиксельном превью фигмы. Для этого нажмите ctrl+shift+p. Это отлично показывает принцип по которому будет производиться хинтование, но помните, в разных операционных системах и браузерах будет выглядеть иначе. Сохраняйте .svg в размере 1к1, закидывайте в нужный браузер и проверяйте на масштабе 100%, если есть такая необходимость в процессе работы.

Сетка

Сетка должна включать:

• отступы от краёв;
• окружность
• примитив под квадрат;
• примитивы под вертикальный и горизонтальный прямоугольники.

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

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

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

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

Логика

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

Драфт рекомендую организовать так:

1. Каждая новая иконка — новая строка по вертикали с фиксированным отступом
2. Всё что относится к иконе — в строке справа от нее в хронологическом порядке.

Для чего так делать?

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

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

Сохраняйте базы

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

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

Последовательность

Будьте последовательны. Сначала определите зону для outline20, 16 и fill20, 16. Иконки создавайте так же: сначала все с обводкой или все залитые, потом то же, но в 16px.

Отведите отдельную зону в драфте, где будете тестировать иконки на реальных интерфейсах.

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

Нейминг

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

Создали фрейм для новой иконки — сразу назвали согласно структуре и выбранному синтаксису, например: DocumentOutline20

Вектор

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

• сtrl+alt+O — преобразует обводки в кривые;
• ctrl+shift+O — уберет всю графику и покажет только контуры — это на случай, если вы запутались или хотите себя проверить;
• shift+alt+U — объединит выделенные контуры. Создаст новый слой с вложенными контурами, которые можно редактировать. Таких слоев в финальной библиотеке быть не должно.
• shift+alt+S — исключит один контур из другого и сделает все то же, что описано выше в объединении.
• ctrl+E — сведет все виды контуры в единый — то, что надо когда иконка готова.

Все фреймы называют и описывают иконку, а все векторы иконок называются одинаково. Мы называем «f».

Драфтим

Самая длинная и ответственная часть работы. В большинстве своем монотонная, но местами, медитативная.

На этом этапе я бы держал в голове что-то вроде Jobs to Be Done для иконок. Базовая формула JTBD: «Когда [контекст], я хочу [действие], чтобы [результат]». Применяйте это к иконкам — и получите ясные цели для их создания и проверки.

Пример JTBD для иконок:

1. Для интерфейсного дизайнера
   Когда я делаю макет интерфейса, я хочу быстро вставить нужную иконку, чтобы сделать элемент визуально понятным, а не отвлекаться на правки, поиски, адаптацию и доработки. Это про готовую библиотеку, где всё подписано, структурировано, в одном стиле и не нужно доделывать «на лету».
2. Для фронтенд-разработчика
   Когда я собираю компонент на фронте, я хочу использовать иконку без артефактов в .svg из библиотеки, чтобы не тратить время на её поиск экспорт, адаптацию или правки. Это про названия, структуру и формат, которые легко подключить к коду.
3. Для продакт-менеджера
   Когда я согласовываю визуальную часть продукта, я хочу быть уверен, что иконки читаются и работают в интерфейсе, чтобы не было срывов сроков из-за переделок и жалоб пользователей. Это про качество, читаемость, единую визуальную логику и соблюдение сроков.
4. Для нового дизайнера в команде
   Когда я подключаюсь к проекту, я хочу быстро разобраться в библиотеке иконок, чтобы сразу использовать её по правилам, не нарушая стиль. Это про документацию, понятную структуру, нейминг и воспроизводимость.

Коммуникация

1. Показывайте коллегам и обсуждайте
   Работы много, она мелкая, глаз «замыливается». Планируйте созвоны, показывайте, тестируйте метафоры и считываемость образов.
2. Держите в курсе и будьте в курсе
   Созванивайтесь с руководителем. Дайте ему понять, успеваете ли, и на сколько в процентах сейчас готова задача. Пример: «Вова, привет, сделал еще 30 иконок. Давай посмотрим. Вместе с ними готово примерно 30% от всей задачи. Становится понятно, что мы не успеем. Возможно скорректировать дедлайн и оценку? Я думаю, что понадобится столько-то времени сверху…» Или наоборот: «Саш, привет, поставь созвон по иконкам, давай посмотрим, синканемся, что там у нас готово…»
3. Дробите
   Особенно на страте. Не делайте сразу сто штук. Согласуйте детали: скругления, обводки. Покажите в интерфейсе. Взгляните критически. Согласовали детали на примере 5-10 иконок — делайте итерацию побольше. Не согласовали — правьте на этих 5-10. Если не можете долго сохранять концентрацию — дробите время. Pomodoro и другие таймеры в помощь. Концентрация понадобится.
4. Смиритесь
   Потратили много времени на иконку? Придумали классную метафору? Отрисовали? Покажите коллегам, а лучше вообще не дизайнерам и спросите, для чего эта иконка. Если вы рисовали колокольчик, а вам говорят, что это нос — смиритесь. Увы, первая ассоциация — самая верная. Помните, цель коммуникации — реакция. Если реакция не совпадает с ожидаемой, значит коммуникация была проведена не верно. Это полностью актуально для иконок. Конечно, вам будет казаться, что вы сделали классно, образ и метафора верны и считываются, но нет. Оставьте амбиции и переделывайте. Помните о том, для чего и для кого вы создаете иконки. Пользователь должен считывать образ на подсознании, не отвлекаясь на иконку и не разгадывая ребус.
5. Все иконки одинаково важны
   Не делите, иконки на важные и неважные, основные и второстепенные или другие группы, в которых можно сделать получше и похуже. Каждая иконка должна быть сделана с одинаковым техническим уровнем и вниманием к деталям.

Создаем и наполняем библиотеку

Организация

Правила организации библиотеки похожи на те, что я описывал для драфта.

Создаем в нашем fig-файле новую страницу. Теперь уже IconsProduct — подставьте своё. Там добавляем строки с группами иконок. Например:

• Documents
• Folders
• Users
• Arrows и так далее

Подготовка иконок

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

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

Быстрая проверка

1. Цвет
   Выделите все фреймы с иконками. Если в панели Fill видите лишние цвета — исправялйте.
2. Scale и скругленияТут чуть дольше. Нужно выделить не фреймы, а векторы. Сделать это можно если тянуть выделение мышкой с зажатым контролом по строке с иконками. Высота области выделения, которую вы тянете должна быть меньше высоту фрейма, чтобы выбрались именно иконки. Выбрали — смотрим Position. Если там Mixed — исправляем. Сталкивался с багами — на конкретных иконках не выставлялсся Scale. Выделял, объединял shift+alt+u, сливал ctrl+e, называл ctrl+r «f» и тогда scale выставлялся. То же со скруглениями: если в панели Appearance, есть скругление или Mixed — исправляем.
3. Дубли и неймингВыделяем вообще все фреймы с иконками в панели экспорт смотрим количество. Допустим, 200. Нажимааем ctrl+f или лупу над слоями. Вводим название иконок, в моем случае «f». В фильтре добавляю Match case и Whole word. Если рузельтатов в поиске больше, чем в экспорте, значит есть дубли слоев. Если меньше, значит часть слоев названа некорректно.
   Подобный поиск проведите с учетом регистра. В моем пример «F» вместо «f». Так же поищите, что забыли слить: Union и Substract — автоматические названия для слоев со вложенностью после действий с вектором.
   Если не можете отыскать попробуйте снова найти все варианты по запросу «f» и в панели слоев выберите все через ctrl+a. Глазами найдите невыделенные фреймы. С ними что-то не так.

Публикуем библиотеку

Слева над панелью слоев есть вкладки. File и Assets. Выбираем Assets. Справа в той же строке появится иконка книжки. Жмем её. В открывшемся окне выбираем This file, видим нашу либу и жмем Publish.
После обновления иконка либы находится внизу левой панели.

По этим же путям можно обновить библиотеку, нажимая Update и подтверждая публикацию изменений.

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

Чтобы заменить иконку надо нажать на фрейм с ней, в правой панели в самом верху кликнуть на её название со стрелочкой и ввести ключевые слова или выбрать руками нужную.

Поддерживаем

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

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

О красоте

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

Базовые знания о композиции и свето-теневом рисунке сделают иконки более качественными.

Заключение

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

Статью написал:

Никитин Александр — дизайнер команды Экзон

Отредактировал Владимир Калинин — руководитель отдела.
С иконками мне помогали Михаил Лисин — ведущий проектировщик и вся команда дизайнеров Экзон.

Всем спасибо, всем пока 👋
Хабр Экзон https://habr.com/ru/companies/exon_group/profile/
Мой ТГ https://t.me/+9QBueZEXMb1iOGYy

Хотите работать у нас? Вакансии:
https://hh.ru/employer/12047264?hhtmFrom=vacancy&customDomain=1&overRideDomainAreaId=1

Я очень рекомендую)

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

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

Что такое список в UI-дизайне?

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

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

Прочитайте также: How to Design a Table UX

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

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

Типы дизайна списков

Существует три основных типа дизайна списков:

- Текстовые списки
- Списки с изображениями
- Карточные списки

Текстовые списки

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

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

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

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

Списки с изображениями

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

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

Карточные списки

Карточные списки обычно содержат изображения и текст, а также могут включать CTA (призыв к действию). Чаще всего такие списки встречаются в eCommerce — списки товаров содержат картинку, название, краткое описание, теги категории, цену и кнопку «Добавить в корзину».

---

Как проектировать списки в UI

Шаг 1: Сначала думайте о контенте

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

У UX-дизайнеров есть три основных способа структурировать списки: по горизонтали, по вертикали и в виде сетки.

Пример: Instagram
- Основная лента — вертикальный список
- Лента сторис — горизонтальный список
- Поиск — «masonry grid» (плиточная сетка)

В рамках этих трёх структур у дизайнеров есть практически бесконечное количество вариаций.

Шаг 2: Следуйте принципам Atomic Design

У дизайна списка есть три составляющих:

Список (List): все элементы списка вместе.
Элемент списка (List item): отдельный пункт внутри списка.
Содержимое элемента (List content): наполнение элемента — изображение, текст, метаданные, заголовок, подзаголовки и другие элементы интерфейса.

Полезно применять подход Atomic Design, решая, как собрать эти части воедино:

Атомы (Atoms): содержимое внутри элемента списка — отдельные картинки и текст.
Молекулы (Molecules): компоненты внутри элемента — например, компонент с аватаркой.
Организмы (Organisms): каждый элемент списка.
Шаблоны (Templates): весь список целиком, включая поле поиска, фильтры и прочее.

---

Шаг 3: Дизайн с учётом последовательности

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

Шаг 4: Оптимизация под разные устройства

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

Шаг 5: Тестирование доступности

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

---

Лучшие практики дизайна списков

1. Учитывайте потребности пользователей

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

2. Следуйте принципам Material Design

В Material Design есть три принципа для списков: они должны быть **логичными, функциональными и последовательными**.

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

3. Делайте списки удобными для сканирования

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

4. Используйте визуальную иерархию

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

Пример: eCommerce
В списке товаров используется цвет, размер и типографика для разделения контента и выстраивания иерархии:
- Название товара: крупный чёрно-белый текст в верхней части.
- Описание: серый текст меньшего размера.
- Цена: крупный тёмный текст.
- Отзывы: мелкий текст со звёздочками яркого цвета.
- Изображение: большая круглая картинка товара.

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

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

5. Обеспечьте доступность

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

Рекомендуемая литература по доступности списков:
- [Lists in HTML — Penn State](https://accessibility.psu.edu/listshtml/)
- [Lists — NC State](https://accessibility.oit.ncsu.edu/it-accessibility-at-nc-state/developers/html/lists/)
- [Lists Accessibility — Oregon State University](https://accessibility.oregonstate.edu/lists)

---

Паттерны и взаимодействия в дизайне списков

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

Чекбоксы и радиокнопки

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

Скролл и свайпы

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

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

Выпадающие списки (Select Lists)

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

Сворачиваемые и раскрывающиеся списки

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

Перестановка и сортировка

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

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

Фильтрация

Фильтры помогают пользователям быстрее находить нужное. Платформы бронирования вроде Airbnb или Booking.com позволяют накладывать сразу несколько фильтров для выбора подходящих объектов.

Разделители

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

Дизайн списков в UXPin

С помощью UXPin (code-based tool) UX-дизайнеры могут создавать прототипы списков, максимально похожие на финальный продукт. Например, в примере Multilevel Dropdown Navigation показано, как с помощью States и Interactions собрать работающий дропдаун-список всего в одном фрейме.

Создание списка с компонентами MUI в UXPin Merge

С помощью UXPin Merge можно подключить кодовые компоненты, например MUI (Material-UI), и использовать их в интерактивных прототипах.

Шаг 1. Импортируйте компоненты MUI

Убедитесь, что библиотека MUI интегрирована в UXPin через Merge. Это позволит перетаскивать готовые закодированные компоненты прямо в дизайн.

Шаг 2. Добавьте компонент List

В UXPin откройте библиотеку MUI.
Перетащите компонент **List** на рабочую область — это будет контейнер для элементов списка.

Шаг 3. Настройте элементы списка

Внутри контейнера разместите компоненты **ListItem** — они будут отдельными пунктами списка.
С помощью **ListItemText** добавьте основной контент (например, заголовок или описание).

Шаг 4. Кастомизация с помощью свойств MUI

Через Merge можно менять свойства компонентов: стиль, макет, поведение. Например:
- **Typography:** настройка шрифтов, цветов, размеров для создания иерархии.
- **Icons:** с помощью **ListItemIcon** можно добавить иконки (галочки, стрелки навигации и т. д.).

Шаг 5. Добавьте интерактивность

Через Interaction Panel в UXPin настройте действия: клики, hover-состояния, динамическое поведение. Например, при клике на элемент можно открывать модалку или переходить на другую страницу.

Шаг 6. Протестируйте прототип

В режиме Preview проверьте работу списка как полноценного прототипа. Убедитесь в адаптивности и удобстве на разных устройствах.

Шаг 7. Передача разработчикам

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

---

Повышение точности и функциональности с UXPin Merge

С помощью технологии **Merge** можно вывести прототипы на новый уровень: подключать дизайн-системы продукта или открытые библиотеки прямо в UXPin и собирать прототипы из готовых кодовых компонентов.

Пример — интеграция библиотеки MUI. Используя React-компоненты MUI, дизайнеры создают полностью рабочие списки. Компоненты включают состояния и взаимодействия, так что дизайнеру остаётся сосредоточиться на продукте, а не на коде. Всё, что есть в документации MUI, можно воспроизвести в UXPin — и без единой строчки кода.

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

Я рофлю, а вот суть:
Рассмотрю три очевидных и массовых сценария прослушивания и добавления во «Мне нравится» на примере ЯндексМузыки.

Сценарии:
|→ в авто; в транспорте; на прогулке →
→ ставим лайки и треки летят во «Мне нравится»
→ Единичные непоследовательные треки из массы добавленных хочу добавить в плей лист →
не могу сделать этого
×|
К Р И Н Ж

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

Приходите в ТГ Теперь — так.